Kann TCP mehr als 65535 Ports bereitstellen?

Ist es möglich, ein Linux-System so einzurichten, dass es mehr als 65.535 Ports bietet? Die Absicht wäre, dass mehr als 65.000 Daemons ein bestimmtes System überwachen.

Offensichtlich werden Ports verwendet, daher ist dies aus diesen Gründen nicht möglich. Stellen Sie sich dies als theoretische Übung vor, um zu verstehen, wo TCP diesbezüglich Einschränkungen aufweisen würde.

Betrachtet man den RFC für TCP: RFC 793 - Transmission Control Protocol , scheint die Antwort Nein zu sein, da ein TCP-Header für das Quell- / Ziel-Portfeld auf 16 Bit begrenzt ist.

Verbessert IPv6 die Dinge?

Nein. Auch wenn IPv6 uns einen viel größeren IP-Adressraum zur Verfügung stellt (32-Bit gegenüber 128-Bit), wird nicht versucht, die TCP-Paketbeschränkung von 16-Bit für die Portnummern zu verbessern. Interessanterweise musste beim RFC für IPv6: Internet Protocol, Version 6 (IPv6) das IP-Feld erweitert werden.

Wenn TCP über IPv6 ausgeführt wird, wird die Methode zur Berechnung der Prüfsumme gemäß RFC 2460 geändert :

Jedes Transport- oder andere Protokoll der oberen Schicht, das die Adressen aus dem IP-Header in seine Prüfsummenberechnung einbezieht, muss für die Verwendung über IPv6 geändert werden, um die 128-Bit-IPv6-Adressen anstelle von 32-Bit-IPv4-Adressen einzuschließen.

Wie kann man also mehr Ports bekommen?

Ein Ansatz wäre, zusätzliche IP-Adressen mit mehr Schnittstellen zu stapeln. Wenn Ihr System über mehrere Netzwerkkarten verfügt, ist dies einfacher, aber selbst mit nur einer Netzwerkkarte können Sie virtuelle Schnittstellen (auch als Aliase bezeichnet ) verwenden, um bei Bedarf weitere IP- Adressen zuzuweisen.

HINWEIS: Die Verwendung von Aliasnamen wurde ersetzt, mit iproute2denen Sie eth0stattdessen IP-Adressen auf einer einzelnen Schnittstelle (dh ) stapeln können .

Beispiel

$ sudo ip link set eth0 up
$ sudo ip addr add 192.0.2.1/24 dev eth0
$ sudo ip addr add 192.0.2.2/24 dev eth0
$ ip addr show dev eth0
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
      pfifo_fast state DOWN qlen 1000
    link/ether 00:d0:b7:2d:ce:cf brd ff:ff:ff:ff:ff:ff
    inet 192.0.2.1/24 brd 192.0.2.255 scope global eth1
    inet 192.0.2.2/24 scope global secondary eth1

Quelle: iproute2: Leben nach ifconfig

Verweise

• OpenWrt Wiki »Dokumentation» Netzwerk »Linux-Netzwerkschnittstellen
• Einige nützliche Befehle mit iproute2
• Linux Advanced Routing & Traffic Control HOWTO
• Mehrere Standardrouten / öffentliche Gateway-IPs unter Linux
• iproute2 Spickzettel - Daniil Baturins Website

Ist es möglich, ein Linux-System so einzurichten, dass es mehr als 65.535 Ports bietet?

Nee.

Die Absicht wäre, dass mehr als 65.000 Daemons auf einem bestimmten System empfangsbereit sind.

Dann brauchen Sie:

• eine iptablesKonfiguration, die auf Verkehrsinhalte umleitet oder

• Ein "Service Broker-Dienst" oder "Multiplexer-Dienst", der eingehende Verbindungen auf einem einzelnen Port akzeptiert und diese an den entsprechenden Daemon "dahinter" weiterleitet. Wenn Standardprotokolle unverändert weitergegeben werden sollen, müssen Sie möglicherweise Protokoll-Sniffing / -Erkennung in diesem Multiplexer-Dienst so implementieren, dass eine IDS- oder Layer-7-Firewall nicht mehr funktioniert. Mit den meisten Protokollen durchaus möglich.

Ab dem zweiten Element können Sie diesen Dienst so gestalten, dass er mehr als 2 ^ 16 "Ports" verarbeitet, wenn Sie dies wirklich möchten. Ich bin mir sicher, dass die Auswirkungen auf die Leistung im Vergleich zur Belastung von 2 ^ 16 + Hörern, die ausgeführt werden, minimal sein werden.

Da unter Linux Daemons auf Unix-Sockets lauschen können, die im Dateisystem vorhanden sind, kann Ihr "Multiplexer-Dienst" eine interne Zuordnung des externen Ports <-> interner Unix-Sockets aufrechterhalten. Sie werden wahrscheinlich auf ein Kernel-Prozesslimit (32-KByte-Prozesse?) Stoßen, bevor Ihnen auf einem modernen Dateisystem die Inodes ausgehen.

Nur weil es keine gute Antwort gibt, wollte ich mitmachen.

Eine Möglichkeit hierfür ist das Hinzufügen einer IP-Option, die die Porterweiterung angibt. Die Option muss so konzipiert sein, dass sie in den optionalen Teil des IP-Headers passt und von unbekannten Hops übersprungen wird.

Sie würden diese Option und ihre Informationen verwenden, um die Quell-, Ziel- oder beide Portnummern zu erweitern.

Die Einschränkungen werden in vorhandener Software nicht automatisch wirksam, wenn die Option hinzugefügt wird. Sie müssen neu geschrieben werden, um die Option zu nutzen, unabhängig davon, wie sie implementiert ist. Vorhandene Software und Firewalls ignorieren das Paket oder verarbeiten es wie gewohnt Verwenden Sie den Wert in den Feldern für den Quell- und Zielport.

Kurz gesagt, dies ist nicht einfach und sollte besser mit einem einzigen wiederverwendbaren Listener und den in der Nutzlast des Pakets enthaltenen Daten durchgeführt werden.

Sie können die Wiederverwendung von Ports in der Software auch einfacher zulassen. Dies kann dazu beitragen, diese Einschränkung zu überwinden, indem Sie die Ports des Servers für mehrere Clientverbindungen wiederverwenden.

Rtsp kann beispielsweise den SessionId-Header in Verbindung mit verschiedenen anderen Headern in der Nutzlast des IP-Pakets verwenden, um zu bestimmen, für welche Verbindung die Anforderung ausgegeben wurde, und entsprechend zu handeln, z. B. wenn der Socket, von dem die Nachricht zugestellt wurde, nicht mit dem Socket identisch ist entfernte Adresse, der die Sitzung entspricht, dann kann man entweder zulassen, dass eine Sitzung mit dem neuen Socket zur Verarbeitung aktualisiert wird, die Nachricht ablehnen oder eine Vielzahl anderer Aktionen je nach Anwendung ausführen.

Ein HTTP-Server kann auch diesen oder einen anderen Servertyp ausführen.

Wenn Sie die Wiederverwendung von Ports zulassen, ist es wichtig, dass Sie auch die Quell-IP-Adresse berücksichtigen.

Ja, du kannst !

Dies wurde bereits getan, beispielsweise auf dem Edgehill-Verschlüsselungsserver, auf dem> 25.000.000 Deamons online ausgeführt werden.