Informationen zur Implementierung von Microsoft Windows 2000 tcp/IP

Wenn eine TCP-Verbindung geschlossen wird, wird das Socketpaar in einen Zustand versetzt, der als TIME-WAIT bezeichnet wird. Dies erfolgt, damit eine neue Verbindung nicht dasselbe Protokoll, dieselbe Quell-IP-Adresse, Ziel-IP-Adresse, denselben Quellport und Zielport verwendet, bis genug Zeit vergangen ist, um sicherzustellen, dass alle Segmente, die möglicherweise falsch geroutet wurden oder verspätet sind, nicht falsch zugestellt werden. Die Zeitdauer, während der das Socketpaar nicht verwendet werden sollte, wird von RFC 793 als 2 MSL (zweimal die maximale Gültigkeitsdauer des Segments) oder vier Minuten angegeben. Dies ist die Standardeinstellung für Windows NT und Windows 2000. Mit dieser Standardeinstellung können einige Netzwerkanwendungen, die viele ausgehende Verbindungen in einer kurzen Zeit durchführen, alle verfügbaren Ports belegen, bevor die Ports wieder freigegeben werden.

Windows NT und Windows 2000 bieten zwei Methoden zum Steuern dieses Verhaltens. Erstens kann der Registrierungsparameter TcpTimedWaitDelay verwendet werden, um diesen Wert zu ändern. Unter Windows NT und Windows 2000 kann dieser auf bis zu 30 Sekunden herabgesetzt werden, was in den meisten Umgebungen keine Probleme verursachen dürfte. Zweitens kann die Anzahl der für den Benutzer zugänglichen kurzlebigen Ports, die zum Aufbau von ausgehende Verbindungen verwendet werden können, mit dem Registrierungsparameter MaxUserPorts konfiguriert werden. Standardmäßig wird ein Port zwischen 1024 und 5000 bereitgestellt, wenn eine Anwendung beim System irgendein Socket für einen ausgehenden Anruf anfordert. Mit dem Parameter MaxUserPorts kann der Wert des obersten Ports für ausgehende Verbindungen auf den vom Administrator gewählten festgelegt werden. Wenn dieser Wert z. B. auf 10.000 (Dezimal) gesetzt wird, würden damit ca. 9000 Benutzerports für ausgehende Verbindungen verfügbar. Weitere Einzelheiten zu diesem Konzept finden Sie in RFC 793. Siehe auch RegistrierungsparameterMaxFreeTcbs und MaxHashTableSize.

TCP-Verbindungen zu und von mehrfach vernetzten Computern

Wenn TCP-Verbindungen zu einem mehrfach vernetzten Host aufgebaut werden, versuchen sowohl der WINS-Client als auch der DNR (Domain Name Resolver) festzustellen, ob sich eine der vom Namenserver bereitgestellten Ziel-IP-Adressen in demselben Subnetz wie eine der Schnittstellen im lokalen Computer befindet. Wenn dies der Fall ist, werden diese Adressen ganz oben auf die Liste gesetzt, damit die Anwendung diese zuerst versuchen kann, bevor sie die Adressen versucht, die sich nicht in demselben Subnetz befinden. Wenn keine der Adressen sich in demselben Subnetz wie der lokale Computer befindet, ist das Verhalten, je nach Namespace, anders. Mit dem TCP/IP-Registrierungsparameter PrioritizeRecordData kann verhindert werden, dass die DNR-Komponente die lokalen Subnetzadressen ganz oben auf die Liste setzt.

Im WINS-Namespace ist der Client für die zufällige Verteilung oder den Lastenausgleich zwischen den bereitgestellten Adressen zuständig. Der WINS-Server gibt die Adressliste immer in derselben Reihenfolge zurück, und der WINS-Client sucht sich eine davon pro Verbindung zufällig heraus.

Im DNS-Namespace wird der DNS-Server gewöhnlich so konfiguriert, dass er die Adressen nach der Round-Robin-Methode bereitstellt. Der DNR versucht nicht, die Adressen noch weiter zufällig zu verteilen. In manchen Fällen ist es wünschenswert, dass eine Verbindung mit einer bestimmten Schnittstelle eines mehrfach vernetzten Computer aufgebaut wird. Dies wird am besten erreicht, indem die Schnittstelle mit einem eigenen DNS-Eintrag versehen wird. Beispielsweise könnte ein Computer mit dem Namen Raincity einen DNS-Eintrag haben, der beide IP-Adressen aufführt (eigentlich zwei separate Einträge im DNS mit demselben Namen), und auch Einträge im DNS für Raincity1 und Raincity2, die jeweils nur einer der IP-Adressen zugeordnet sind, die dem Computer zugeteilt wurden.

Wenn TCP-Verbindungen von einem mehrfach vernetzten Host aufgebaut werden, ist die Lage etwas komplizierter. Wenn es sich bei der Verbindung um eine Winsock-Verbindung handelt, die den DNS-Namespace verwendet, versucht TCP, nachdem die Ziel-IP-Adresse für die Verbindung bekannt ist, über die beste verfübare Quell-IP-Adresse eine Verbindung herzustellen. Diese Entscheidung wird wiederum aufgrund der Routingtabelle getroffen. Wenn es eine Schnittstelle in dem lokalen Computer gibt, die sich in demselben Subnetz befindet wie die Ziel-IP-Adresse, wird ihre IP-Adresse als die Quelle in der Verbindungsanforderung verwendet. Wenn keine beste Quell-IP-Adresse verfügbar ist, wählt das System zufällig eine Adresse aus.

Wenn es sich bei der Verbindung um eine NETBIOS-basierte Verbindung handelt, die einen Redirectordienst verwendet, sind wenig Routinginformationen auf der Anwendungsebene verfügbar. Die NetBIOS-Schnittstelle unterstützt Verbindungen über verschiedene Protokolle und hat keine Kenntnis von IP. Stattdessen platziert der Redirectordienst Aufrufe in allen Transporte, die an ihn gebunden sind. Wenn auf dem Computer zwei Schnittstellen und ein Protokoll installiert sind, stehen dem Redirectordienst zwei Transporte zur Verfügung. In beiden werden Aufrufe platziert, und NetBT schickt Verbindungsanforderungen an den Stapel, wobei eine IP-Adresse von jeder Schnittstelle verwendet wird. Es ist möglich, dass beide Aufrufe erfolgreich sind. Wenn dies der Fall ist, storniert der Redirectordienst einen Aufruf. Die Entscheidung, welcher Aufruf storniert wird, richtet sich nach dem Registrierungswert ObeyBindingOrder des Redirectordienstes ⁶ . Wenn dieser auf 0 (Standardwert) gesetzt ist, ist der primäre Transport (durch eine verbindliche Reihenfolge bestimmt) der bevorzugte, und der Redirectordienst wartet auf eine Zeitüberschreitung beim primären Transport, bevor er die Verbindung über den sekundären Transport akzeptiert. Wenn dieser Wert auf 1 gesetzt ist, wird die verbindliche Reihenfolge ignoriert, und der Redirectordienst akzeptiert die erste Verbindung, die erfolgreich aufgebaut wird, und storniert die andere(n).

TCP wurde konzipiert mit dem Ziel, eine optimale Leistung bei wechselnden Verbindungsbedingungen bereitzustellen, und Windows 2000 enthält Verbesserungen wie Unterstützung der RFC 1323. Der tatsächliche Durchsatz für eine Verbindung hängt von einer Reihe von Variablen ab, aber die wichtigsten Faktoren sind:

• 
  Geschwindigkeit der Verbindung ( Bits pro Sekunde, die übertragen werden können)
  
• 
  Verzögerung der Ausbreitung
  
• 
  Fenstergröße (Menge der nicht bestätigten Daten, die bei einer TCP-Verbindung noch offen sind)
  
• 
  Zuverlässigkeit der Verbindung
  
• 
  Überlastung des Netzwerkes und der Zwischengeräte
  
• 
  PMTU
  

• 
  Die Kapazität einer Pipe ist die Bandbreite multipliziert mit der RTT. Dies wird als das Bandbreite-Verzögerungs-Produkt bezeichnet. Wenn die Verbindung zuverlässig ist, sollte die Fenstergröße zwecks bester Leistung mindestens so groß sein wie die Kapazität der Pipe, so dass der sendende Stapel sie ausfüllen kann. Die größte Fenstergröße, die verwendet werden kann, ist aufgrund des 16-Bit-Feldes im TCP-Header 65535, aber größere Fenster können durch das Skalieren des Fensters ausgehandelt werden, wie zuvor in diesem Dokument beschrieben. Siehe TcpWindowSize in Anhang A.
  
• 
  Der Durchsatz kann nie über der Fenstergröße dividiert durch die Round-Trip Time liegen.
  
• 
  Wenn die Verbindung unzuverlässig oder stark überlastet ist und Pakete verloren gehen, verbessert das Verwenden einer größeren Fenstergröße nicht unbedingt den Durchsatz. Zusammen mit der Fensterskalierung unterstützt Windows 2000 SACK (Selective Acknowledgments; beschrieben in RFC 2018) zur Verbesserung der Leistung in Umgebungen, in denen Paketverluste auftreten. Außerdem werden Zeitstempel (beschrieben in RFC 1323) zur besseren RTT-Schätzung verwendet.
  
• 
  Die Verzögerung der Ausbreitung hängt ab von der Lichtgeschwindigkeit, Latenzzeiten in den Übertragungsgeräten usw.
  
• 
  Die Verzögerung der Übertragung hängt von der Geschwindigkeit der Medien ab.
  
• 
  Für einen angegebenen Pfad liegt die Verzögerung der Ausbreitung fest, aber die Verzögerung der Übertragung hängt von der Paketgröße ab.
  
• 
  Bei niedrigen Geschwindigkeiten ist die Verzögerung der Übertragung der begrenzende Faktor. Bei hohen Geschwindigkeiten kann die Verzögerung der Ausbreitung der begrenzende Faktor werden.
  

UDP stellt einen verbindungslosen, unzuverlässigen Transportdienst bereit. Es wird häufig für zu viele Kommunikationen verwendet, die IP-Datagramme per Broadcast oder Multicast verwenden. Da die Lieferung des UDP-Datagramms nicht garantiert ist, müssen Anwendungen, die UDP verwenden, bei Bedarf ihre eigenen Mechanismen zur Gewährleistung der Zuverlässigkeit bereitstellen. Das Microsoft-Netzwerk verwendet UDP zur Anmeldung, zum Durchsuchen und für die Namensauflösung. UDP kann auch zur Beförderung von IP-Multicastdatenströmen verwendet werden.

UDP wird für die NetBIOS-Namensauflösung per Unicast an einen NetBIOS-Namenserver oder per Subnetz-Broadcasts verwendet und für die Auflösung von DNS-Hostnamen in die IP-Adresse. Die NetBIOS-Namensauflösung erfolgt über den UDP-Port 137. DNS-Abfragen verwenden den UDP-Port 53. Da UDP selbst die Auslieferung der Datagramme nicht garantiert, verwenden beide Dienste ihre eigenen Schemas zur Neuübertragung, wenn sie auf ihre Anfragen keine Antworten erhalten. Broadcast-UDP-Datagramme werden normalerweise nicht über IP-Router weitergeleitet, so dass die NetBIOS-Namensauflösung in einer gerouteteten Umgebung irgendeine Art von Namenserver oder die Verwendung von statischen Datenbankdateien erfordert.

Viele NetBIOS-Anwendungen verwenden Mailslot-Meldungen. Ein Mailslot zweiter Klasse ist ein einfacher Mechanismus für das Versenden einer Nachricht von einem NetBIOS-Namen an einen anderen über UDP. Mailslot-Nachrichten können über ein Subnetz per Broadcast gesendet oder an den Remotehost gerichtet werden. Um eine Mailslot-Nachricht an einen Host zu richten, muss irgendeine Art der NetBIOS-Namensauflösung möglich sein. Microsoft stellt hierfür WINS (Windows Internet Name Server) bereit.

Die Implementierung von NetBIOS über TCP/IP in Windows NT und Windows 2000 wird als NetBT bezeichnet. NetBT verwendet die folgenden TCP- und UDP-Ports:

• 
  UDP-Port 137 (Namensdienste)
  
• 
  UDP-Port 138 (Datagrammdienste)
  
• 
  UDP-Port 139 (Sitzungsdienste)
  

Microsoft hat TDI (Transport Driver Interface) entwickelt, um größere Flexibilität und Funktionalität als bei den bestehenden Schnittstellen, wie z. B. NetBIOS und Windows Sockets, bereitzustellen. Alle Windows-Transportanbieter bieten TDI. Die TDI-Spezifikation beschreibt die Gruppe primitiver Funktionen, durch die Transporttreiber und TDI-Clients kommunizieren, und die verwendeten Aufrufmechanismen für den Zugriff darauf. Gegenwärtig gibt es TDI nur im Kernelmodus.

Der Windows 2000-Redirectordienst und der Dienst Server verwenden beide TDI direkt, anstatt über die NetBIOS-Zuordnungsschicht zu gehen. Dadurch unterliegen sie nicht den vielen Einschränkungen, die durch NetBIOS auferlegt werden, wie der veralteten Beschränkung auf 254 Sitzungen.

TDI-Funktionen

TDI ist wahrscheinlich von allen Windows-Netzwerk-APIs am schwierigsten zu verwenden. Es ist eine einfache Leitung (conduit), so dass Programmierer das Format und die Bedeutung der Meldungen bestimmen müssen.

TDI umfasst die folgenden Funktionen:

• 
  Die meisten Windows NT oder Windows 2000-Transporte unterstützen TDI (DLC unterstützt es jedoch nicht.)
  
• 
  Ein offenes Schema für die Vergabe von Namen und Adressen
  
• 
  Datentransfer im Meldungs- und Datenstrommodus
  
• 
  Asynchroner Betrieb
  
• 
  Unterstützung für die unaufgeforderte Anzeige von Ereignissen
  
• 
  Erweiterbarkeit - Clients können private Anforderungen an den Transporttreiber senden, der sie unterstützt.
  
• 
  Unterstützung der eingeschränkten Verwendung von standardmäßigen Kernelmodus-E/A-Funktionen zum Senden und Empfangen von Daten.
  
• 
  32-Bit-Adressierung und -Werte
  
• 
  Unterstützung von Zugriffssteuerungslisten (Access Control Lists, ACLs, für Sicherheitszwecke) zu TDI-Adressobjekten
  

Die Netzwerksicherheit ist ein wichtiges Thema für Administratoren, bei denen Computer über öffentliche Netzwerke zugänglich sind. Der Microsoft TCP/IP-Stapel ist gegen viele Angriffe gewappnet und bewältigt in seinem Standardzustand die meisten der üblichen Angriffe. Ein gewisser zusätzlicher Schutz gegen beliebte Denial of Service-Angriffe lässt sich durch das Aktivieren des Schlüssels SynAttackProtect in der Registrierung erreichen. Bei diesem Schlüssel kann der Administrator Schutz gegen SYN-Attacken auf einer von mehreren Ebenen auswählen.

Hier lesen Sie einige allgemeine Richtlinien, die Ihnen helfen, bei Attacken weniger verwundbar zu werden:

• 
  Deaktivieren Sie unnötige oder optionale Dienste (z. B. Client für Microsoft-Netzwerke auf einem IIS-Server).
  
• 
  Aktivieren Sie die TCP/IP-Filterung, und beschränken Sie den Zugang nur auf die Ports, die nötig sind, damit der Server funktioniert. (Siehe Microsoft Knowledge Base-Artikelnummer Q150543 [englischsprachig]. Dort finden Sie eine Liste der Ports, die von Windows-Diensten verwendet werden.)
  
• 
  Entkoppeln Sie NetBIOS über TCP/IP, wo es nicht benötigt wird.
  
• 
  Konfigurieren Sie statische IP-Adressen und Parameter für öffentliche Adapter.
  
• 
  Konfigurieren Sie die Einstellungen der Registrierung für maximalen Schutz (siehe Anhang D).
  

Es gibt verschiedene Wege, wie Netzwerkanwendungen mithilfe eines TCP/IP-Protokollstapels kommunizieren können. Einige von ihnen, wie z. B. Named Pipes, gehen über den Netzwerk-Redirectordienst, der Teil des Arbeitsstationsdienstes ist. Viele ältere Anwendungen wurden für die NetBIOS-Schnittstelle geschrieben, die von NetBIOS über TCP/IP unterstützt wird.

Die Windows Sockets-Schnittstelle ist gegenwärtig sehr verbreitet. Nachfolgend ein kurzer Überblick über die Schnittstellen Windows Sockets und NetBIOS.

Windows Sockets

Windows Sockets bezeichnet eine Programmierschnittstelle, die auf der bekannten Socketschnittstelle der University of California in Berkeley beruht. Sie enthält eine Reihe von Erweiterungen, die von dem meldungsgesteuerten Charakter von Microsoft Windows profitieren sollen. Version 1.1 der Spezifikation kam im Januar 1993 heraus, und Version 2.2.0 wurde im Mai 1996 veröffentlicht.⁸ Windows 2000 unterstützt die Version 2.2, allgemein als Winsock2 bezeichnet.

Es stehen zahlreiche Windows Sockets-Anwendungen zur Verfügung. Eine Reihe von Dienstprogrammen, die im Lieferumfang von Windows 2000 enthalten sind, basieren auf Windows Sockets, einschließlich der FTP- und DHCP-Clients und -Server, des Telnet-Clients usw. Es gibt höhere Programmierschnittstellen, die auf Winsock basieren, wie z. B. die Windows Internet-API (WinInet), die von Internet Explorer verwendet wird.

Windows Sockets-Anwendungen verwenden in der Regel die Funktion gethostbyname(), um einen Hostnamen einer IP-Adresse zuzuordnen. Die Funktion gethostbyname() verwendet die folgende (Standard-) Sequenz zur Namenssuche:

1. 
   Überprüfe den Namen des lokalen Hosts auf einen passenden Namen
   
2. 
   Überprüfe die Datei hosts auf einen passenden Namenseintrag.
   
3. 
   Wenn ein DNS-Server konfiguriert ist, frage diesen ab.
   
4. 
   Wenn keine Entsprechung gefunden wird, versuche die NetBIOS-Namensauflösung bis zu dem Punkt, ab dem die DNS-Auflösung versucht wird.
   

1. 
   Überprüfe die Datei hosts auf einen passenden Namenseintrag.
   
2. 
   Wenn ein DNS-Server konfiguriert ist, wird dieser abgefragt.
   
3. 
   Sende eine NetBIOS-Adapterstatusanforderung an die abgefragte IP-Adresse. Wenn sie mit einer Liste von NetBIOS-Namen antwortet, die für den Adapter registriert sind, suche darin den Computernamen.
   

Winsock2 unterstützt IP-Multicasting. Das Multicasting wird in der Spezifikation für Windows Sockets 2.0 und im Abschnitt über IGMP dieses Dokuments beschrieben. Das IP-Multicasting wird gegenwärtig nur auf AF_INET-Sockets vom Typ SOCK_DGRAM und SOCK_RAW unterstützt.

Windows Sockets-Serveranwendungen erstellen in der Regel ein Socket und verwenden dann die Funktion listen(), um sie auf Verbindungsanforderungen abzuhören. Einer der beim Aufruf von listen() übergebenen Parameter ist die Anzahl der zurückgestellten Verbindungsanforderungen, die die Anwendung von Windows Sockets in die Warteschlange stellen lassen will. Dieser Wert steuert die Anzahl der nicht akzeptierten Verbindungen, die in der Warteschlange stehen können. Nachdem eine Anwendung eine Verbindung akzeptiert hat, wird er aus den zurückgestellten Verbindungsanforderungen herausgenommen und zählt nicht mehr. Die Spezifikation zu Windows Sockets 1.1 sieht vor, dass der höchstzulässige Wert für die Zahl der Zurückstellungen 5 ist. Windows NT 3.51 akzeptiert jedoch bis zu 100 Zurückstellungen, Windows NT 4.0 und Windows 2000 Server akzeptieren 200 Zurückstellungen, und Windows NT 4.0 Workstation und Windows 2000 Professional akzeptieren 5 Zurückstellungen (was den Speicherbedarf verringert).

Standardmäßig beendet Windows 2000 TCP/IP einen Aufruf recv(), wenn eine der folgenden Bedingungen erfüllt ist:

• 
  Daten kommen mit gesetztem PUSH-Bit an.
  
• 
  Der recv-Puffer des Benutzers ist voll.
  
• 
  Seit 0,5 Sekunden sind keine weiteren Daten eingetroffen
  

NetBIOS definiert eine Softwareschnittstelle und eine Namenskonvention, kein Protokoll. Frühe Versionen der Microsoft Networking-Produkte stellten nur das NetBEUI-Protokoll für das LAN mit einer NetBIOS-API (Schnittstelle für Anwendungsprogrammierung) bereit. NetBEUI ist ein kleines, schnelles Protokoll ohne Netzwerkschicht; daher ist es nicht routingfähig und oftmals nicht für WAN-Implementierungen geeignet. NetBEUI stützt sich auf Broadcasts für die Namensauflösung und die Suche nach Diensten. NetBIOS über TCP/IP stellt die NetBIOS-Programmierschnittstelle über das TCP/IP-Protokoll bereit, wodurch die Reichweite des NetBIOS-Client- und Serverprogramms auf das WAN erweitert und Interoperabilität mit verschiedenen anderen Betriebssystemen erreicht wird.

Der Arbeitsstationsdienst, der Dienst Server, Computerbrowser, Nachrichtendienst, und Anmeldedienst sind alle (direkte) NetBT-Clients. Sie verwenden TDI (weiter oben in diesem Whitepaper beschrieben) für die Kommunikation mit NetBT. Windows NT und Windows 2000 enthalten auch einen NetBIOS-Emulator. Der Emulator nimmt Standard-NetBIOS-Anforderungen von NetBIOS-Anwendungen entgegen und übersetzt sie in äquivalente TDI-Grundfunktionen.

Windows 2000 verwendet NetBIOS über TCP/IP noch zur Kommunikation mit früheren Versionen von Windows NT und anderen Clients, wie z. B. Windows 95. Jedoch unterstützen der Windows 2000-Redirectordienst und die Serverkomponenten nun auch Direct Hosting, um mit allen anderen Computern zu kommunizieren, auf denen Windows 2000 ausgeführt wird. Beim direkten Hosting wird der DNS für die Namensauflösung verwendet. Es wird keine NetBIOS-Namensauflösung (WINS oder Broadcast) verwendet, und das Protokoll ist einfacher. Direct Host TCP verwendet Port 445 statt des NetBIOS TCP-Ports 139.

Standardmäßig ist sowohl das NetBIOS als auch Direct Hosting aktiviert, und beide werden parallel versucht, wenn eine neue Verbindung aufgebaut wird. Verwendet wird die zuerst zustande kommende Verbindung. Die Unterstützung von NetBIOS kann deaktiviert werden, um den gesamten Verkehr zur Verwendung von Direct Hosting zu zwingen.

So deaktivieren Sie die Unterstützung von NetBIOS

1. 
   Zeigen Sie im Menü Start auf Einstellungen, und klicken Sie dann auf Netzwerk und DFÜ-Verbindungen Verbindung. Klicken Sie mit der rechten Maustaste auf LAN-Verbindung und dann auf Eigenschaften.
   
2. 
   Wählen Sie Internetprotokoll (TCP/IP) aus, und klicken Sie auf Eigenschaften.
   
3. 
   Klicken Sie auf Erweitert.
   
4. 
   Klicken Sie auf die Registerkarte WINS und wählen Sie NetBIOS über TCP/IP deaktivieren aus.