65535 Port-Limit

Die magische Zahl bei Servern ist 65535 und das hat sich  mit IPv6 auch nicht geändert. Port 80/TCP für Webverkehr und 443/TCP für verschlüsselte Daten per HTTPS dürfte zumindest meinen Lesern bekannt sein. Und wer als Exchange Administrator nichts mit 25/TCP für SMTP,  110/TCP für POP3 anfangen kann, ist sicher genauso fehl am Platz wie ein Lync Administrator der bei 5061/TLS (SIP) nur Fragezeichen an die Wand malt.

Ok, damit haben wir eine kleine Zahl von Ports genannt und bis 65535 (das Limit bei 16bit) sollte doch noch garn viel Platz für mehr sein. Fakt ist aber, dass dies doch nicht so einfach ist. für einen Exchange Admin kann diese magische Grenze nämlich schon bei kleinen Benutzerzahlen zu einem Problem werden. Hier vier Beispiele, die ich später genauer erkläre:

Wenn Sie nun noch nicht ahnen, wovon ich auf dieser Seite schreibe, sollte vielleicht bis zum Ende lesen.

TCP-IP-Port-Grundlagen

Schauen wir uns erst mal die Technik an. Er mit dem NETMON ein TCP oder UDP-Paket mitgeschnitten hat, wird sehr einfach "Ports" erkennen.

Hier eine Quittung von einem Client mit der 192.168.0.28 an einen Webserver aus "mesh.com"  (Windows SkyDrive). Doch was ist an den Ports so interessant, dass diese es auf die MSXFAQ geschafft haben ?

Eingehende Ports

Ports können Sie sich als Türen in einem großen Gebäude vorstellen, hinter denen sich Dienste befinden. Der Anbieter (z.B. ein Rathaus) hat eine Adresse bestehend aus Land, Ort, Straße, Hausnummer, welche als Analogie die IP-Adresse AAA.BBB.CCC.DDD darstellen kann. In dem Gebäude drin gibt es dann Räume mit verschiedenen Dienstleistungen. Der Einwurf für den Briefkasten ist Raum 25 während die Mitarbeiter ihre Post dann im Raum 110 abholen. Und Raum 80 ist dann die Bücherei, die aber die Schriften als Kopie ausliefert. Bestimmte Raumnummern sind als "Well Known Ports" schon länger definiert. Hier könnte es nur dann zum Engpass kommen, wenn sie mehr Dienste als Räume bereit stellen wollen. In den Anfangstagen des Internet wurden die Port 1-1024 für "Dienste" definiert. Heute ist es schon normal, dass Dienste auch auf höheren Ports angeboten werden (RDP = 3389, MSSQL=1433, Lync=5061, AD GC = 3268). Solange der Dienst den Port belegen kann, ehe eine ausgehende Verbindung den Port verwendet, ist dies auch kein Problem.

Ausgehende Ports / HighPorts

Aber wer etwas sendet, muss natürlich ebenfalls eine gültige "Socket"-Kombination vorweisen, damit Antworten zurück kommen können. Der Initiator der Kommunikation muss ebenfalls eine Kombination aus seiner IP-Adresse und einem Port, der aber in der Regel dynamisch ist, bereit stellen. Also gibt es auch hier eine Beschränkung auf 65535 Ports. Und die ist eigentlich der kritische Faktor bei verschiedenen Diensten. Allerdings sind es nicht mal 65535 Port, sondern weniger. Früher wurden zumindest die ersten 1024 Ports für Dienste reserviert, so dass ausgehende Verbindungen z.B. mit Port 1025 gestartet hatten. Jede neue Verbindung hat einen höheren Port verwendet. heute werden die Ports dynamisch und zufällig aus einem definierten Bereich vergeben. Dazu müssen Sie aber pro Betriebssystem wissen, welche "dynamischen Ports" denn für ausgehende Verbindungen genutzt werden. Bei Vista und höher hilft hier ein NETSH:

netsh int ipv4 show dynamicport tcp
netsh int ipv4 show dynamicport udp
netsh int ipv6 show dynamicport tcp
netsh int ipv6 show dynamicport udp

Betriebssystem Start (TCP) Anzahl Ende (TCP)

Windows 2003 und früher

1025

64511

65535

Windows 2008 RTM

49152

16384

65535

Windows 2008 R2 Standard

49152

16384

65535

Windows 2008 R2 mit Exchange 2010

6005

59530

65535

Windows 7 SP1

1025

64510

65534

Windows 10, Server 2016

49152

16384

65535

Die Bereiche für UDP können abweichend sein. Exchange ist eines der Produkte, welche diese Systemeinstellungen zu seinen Wünschen verändert. Ein sehr aktiver SMTP-Server kann z.B. schon mehr ausgehende "Source-Ports" benötigen.

Miteinander Reden

Eine Verbindung zwischen zwei Systemen über TCP oder UDP basiert also nicht nur auf der IP-Adresse der Partner sondern auch den Ports des Senders und Empfängers. Damit ist auch erklärt, warum ein Webserver eben mehr als 65535 gleichzeitige Verbindungen bedienen kann. Zumindest solange ausreichend freie Ports gibt. 

Es gibt noch eine weitere Komponente im Spiel. Eine Verbindung, die genutzt wurde, wird am Ende nicht sofort wieder frei gegeben, sondern verbleibt 2 Minuten im Status TIME_WAIT. So lange kann dieser Port also ebenfalls nicht mehr genutzt werden.

Es ist zudem durchaus üblich, dass eine Applikation mehr als nur eine Verbindung aufbaut. So öffnen die meisten Browser mehrere TCP-Verbindungen und auch Outlook ist sehr kommunikativ, wie ein Blick in den Windows 7 Ressource Manager oder Sysinternals TCPView ( http://technet.microsoft.com/de-de/sysinternals/bb897437.aspx )aufzeigen

Natürlich können sie die Verbindungen auch klassisch per Kommandozeile erhalten.

netstat -n

Auch hier sehen Sie, dass mein Client mit der 192.168.0.28 (private Adresse am DSL-Anschluss) mehrere Verbindungen zu der 80.66.20.20 und anderen Servern aufgebaut hat. Wer aber die Liste genau anschaut erkennt auch, dass ein lokaler Port nie mehrfach verwendet wird, auch nicht zu unterschiedlichen Zielen.

Wissenskontrolle

Mit all dem Wissen können wir nun ein paar Fragen direkt beantworten. Wer möchte, schaut sich die Antwort erst an, wenn er die Frage für sich selbst beantwortet hat

Frage Antwort

Wie viele unterschiedliche Quellen kann ein Ziel über einen Ziel-Port bedienen

>656635. Die Grenze ist eher Bandbreite, CPU, Speicher oder Applikation

Wie viele Verbindungen kann eine Quelle mit einer IP ausgehend aufbauen

xx bis yyy je nach Betriebssystem

Was limitiert die Anzahl der 1:1 Verbindungen zwischen einer Quelle und einem Ziel ?

Die verfügbaren Source-Ports des Clients

Was limitiert die Anzahl der 1:1 Verbindungen zwischen einer Quelle und vielen Zielen

Die verfügbaren Source-Ports des Clients

Zu wie vielen Zielen kann ein Client von einem Quellport eine Verbindung aufbauen

Die Verbindung ist (mit wenigen Ausnahmen wie z. B. UDP) eine 1:1 Beziehung

Technisch wäre es ja denkbar, dass ein Client mit einem Quellport auch unterschiedliche Ziele anspricht. Faktisch ist dies aber nicht der Fall.

Ich habe bislang noch nie gesehen, dass ein Client mit einem Quellport verschiedene Server angesprochen hat, obwohl das ja auch möglich sein sollte. Hat jemand Informationen warum dies nicht genutzt wird ?. Es könnte ja zumindest für Server interessant sein, die selbst viele ausgehende Verbindungen initiieren.

Problemkinder

Kommen wir nun zu ein paar Beispielen, wo diese Beschränkung von Ports zu Problemen führen könnte. Wir wissen, dass der Server seinen Dienst in der Regel unter einem Port anbietet und daher zumindest bezüglich IP-Adresse und Port nicht der Engpass darstellen kann. Die Probleme sind also eher beim Client zu sehen.

NAT in der Verbindung (Homeoffice, UMTS-Provider, WiFi-APs, IPv6-Transition)

Ich denke dass jeder sich mit der Thematik "NAT" auseinandergesetzt hat. Denken Sie einfach an ihren DSL-Anschluss mit einem Router, der die privaten Adressen ihrer Computer extern auf die eine offizielle IP-Adresse umsetzen. Sie haben weiter oben schon gesehen, dass ein Client durchaus mehrere Verbindungen nach Extern gleichzeitig offen hat. Outlook hat je nach Anzahl der Stellvertreter auch gerne mal ein paar Verbindungen mehr offen. Wenn dann mehrere Personen hinter dem gleichen System sitzen, dann kann es schon mal "eng" werden.

Ich spreche dabei nicht vom heimischen DSL-Anschluss, sondern alle Umgebungen, in denen gerne mit privaten Adressen gearbeitet wird. Das können also WiFi-Accesspoint sein, die von einem Cafe, einer Firma oder temporär bei Veranstaltungen gerne mal bereit gestellt werden. Bei der Menge an Endgeräten, die heute schon WiFi nutzen kann eine mittlere Veranstaltungshalle einer Messe schon schnell die Portgrenzen sprengen. Da auch immer mehr Mobilfunkprovider private Adressen verteilen, ist dort die Thematik sicher bekannt.

Diverse NAT-Systeme erlauben daher die Nutzung mehrerer IP-Adressen für ausgehende Verbindungen, so dass die 65535-Grenze mit der Anzahl der IP-Adressen multipliziert werden kann.

Ein relativ neues Gebiet ist natürlich auch der Wechsel auf IPv6. Wenn Systeme mit IPv6-Only noch weiterhin IPv4-Systeme erreichen wollen, dann kommt auch hier eine AdressUmsetzung mit NAT64 zum Einsatz. Ein Gateway wie z.B. UAG setzt die Verbindung um, und nutzt dazu seine IPv4-Adresse. Alle IPv6-Clients verbergen sich beim Zugriff auf IPv4-Systeme daher hinter der IPv4-Adresse von UAG und einem zugewiesenen Port.

Load Balancer und Reverse NAT (SNAT/DNAT)

Denken Sie aber auch an einfache "Reverse-NAT"-Funktionen, wenn Sie ihren Service über eine Firewall oder Loadbalancer veröffentlichen, die nicht nur die Zieladresse sondern auch die Quelladresse umschreiben. Gerade bei Loadbalancern ist dies im "Single-Arm"-Betrieb der Standard, damit das Antwortpaket auch wieder am Loadbalancer ankommen und nicht direkt zum Client geht.

Proxy-Server

Das gleiche Problem gilt auch für Umsetzungen auf Protokollen (Layer 7) Am bekanntesten ist hier der HTTP-Proxy zu nennen, über den gerne viele Personen innerhalb einer Firma im Internet surfen. Auch wenn bei 65535 Port scheinbar viel Luft ist und die Bandbreite zum Internet eher ein Limit darstellen könnte (100MBit/655535 sind ca. 152 Byte/Sek/Verbindung), so kann dies doch zu den ein oder anderen "Aussetzern" führen. z.B. wenn viele Verbindungen auf "Close-Wait" stehen oder interne Prozesse (z.B. Filesharing und P2P) viele Verbindungen öffnen oder offen halten.

Auch in der Gegenrichtung kann das Limit durchaus erreicht werden, wenn Sie über einen "Reverse Proxy" ihre Server im Internet veröffentlichen. Auch hier wird meist nicht die IP-Adresse des Internet-Clients zum Server weiter gegeben, sondern der Zugriff auf dem Reverse Proxy terminiert und eine zweite neue Verbindung zum eigentlichen Servern geöffnet. Und schon haben wir wieder eine 1:1 Beziehung, bei der aus Sicht des Server ein Client, der Reverse Proxy Server, viele Verbindungen auf den eigentlichen Server mit nur einer IP-Adresse öffnet. Auch hier erlauben einige Systeme die Konfiguration mehrerer IP-Adressen um den Pool der verfügbaren Ports anzuheben.

Exchange CAS zu Mailbox

Eine ganz besondere Bedeutung hat diese Limit bei Exchange 2010 mit MOMT bekommen. Outlook spricht nicht mehr direkt mit "seinem" Mailboxserver, sondern verbindet sich nun mit dem CAS-Server, welcher sich dann mit dem richtigen Mailboxserver im Hintergrund verbindet. Damit können mehrere CAS-Server vorne die Verbindungen der Clients bedienen und speziell OWA, ActiveSync aber auch OAB-Downloads etc. abwickeln und den Mailboxserver entlasten.

Aber die Verbindung vom Client zum Server ist zumindest aus TCP/IP-Sicht ja kein Problem, solange die Clients mit unterschiedlichen IP/Port-Kombinationen kommen. Aber auf der anderen Seite kann es nun zu Problemen kommen, wenn der CAS-Server seinerseits zum Mailboxserver Verbindungen aufbaut. Hier ist es wieder eine 1:1 Verbindung und da der CAS-Server nur eine IP-Adresse hat, kann er maximal so viele IP Verbindungen nach extern aufbauen, wie er verfügbare Source-Ports hat.

Zum Glück hat Microsoft hier vorgesorgt, indem nicht für jede Verbindung eines Clients zum CAS auch eine Verbindung von CAS zum Mailbox-Server aufgebaut wird, sondern hier ein Pooling stattfindet.

Überwachen

Die wenigsten Programme, die ausgehende Verbindungen aufbauen, liefern eine aussagekräftige Fehlermeldung. Das liegt sicher auch daran, das die meisten Entwickler davon ausgehen, dass dieser Fall sehr selten ist. Als Betreiber von Servern sollten Sie aber die Möglichkeiten des Betriebssystems nutzen, die kritischen Counter zu überwachen. Bei Windows ist dies leider gar nicht einfach. ich habe keinen passenden Performancecounter gefunden.

Die hier exemplarisch angezeigten Counter gehen zwar in die Richtung aber sind kumulierte Werte.

Weitere Links