Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel werden die TCP-Features in Windows beschrieben.
Ursprüngliche KB-Nummer: 224829
Übersicht
In diesem Artikel werden die folgenden TCP-Features in Windows beschrieben:
- TCP-Fenstergröße
- TCP-Optionen werden jetzt unterstützt
- Windows-Skalierung – RFC 1323
- Zeitstempel – RFC 1323
- Schutz vor umbrochenen Sequenznummern (PAWS)
- Selektive Bestätigungen (SACKS) – RFC 2018
- TCP-Retransmissionsverhalten und schnelle Übertragung
Die TCP-Features können durch Ändern der Einträge in der Registrierung geändert werden.
Wichtig
Die folgenden Abschnitte, Methoden oder Aufgaben enthalten Schritte, die Ihnen mitteilen, wie Sie die Registrierung ändern. es können jedoch schwerwiegende Probleme auftreten, wenn Sie die Registrierung nicht ordnungsgemäß ändern. Daher müssen Sie sicherstellen, dass Sie diese Schritte sorgfältig ausführen. Für weiteren Schutz sichern Sie die Registrierung, bevor Sie sie ändern. Sie können die Registrierung wiederherstellen, wenn ein Problem auftritt. Weitere Informationen zum Erstellen und Wiederherstellen einer Sicherungskopie der Registrierung finden Sie im folgenden Artikel der Microsoft Knowledge Base:
322756 Sichern und Wiederherstellen der Registrierung in Windows
TCP-Fenstergröße
Die GRÖßE des TCP-Empfangsfensters ist die Menge der Empfangendaten (in Byte), die während einer Verbindung gepuffert werden kann. Der sendende Host kann nur diese Datenmenge senden, bevor er auf eine Bestätigung und Eine Fensteraktualisierung vom empfangenden Host warten muss. Der Windows TCP/IP-Stapel ist so konzipiert, dass er sich in den meisten Umgebungen selbst optimieren und größere Standardfenstergrößen als frühere Versionen verwendet.
Anstatt eine hartcodierte Standardgröße des Empfangsfensters zu verwenden, passt TCP sogar in Schritten der maximalen Segmentgröße (MSS) an. MsS wird während der Verbindungseinrichtung ausgehandelt. Durch Das Anpassen des Empfangsfensters auf gleichmäßige Inkremente der MSS erhöht sich der Prozentsatz der tcp-Segmente in voller Größe, die bei Massendatenübermittlungen verwendet werden.
Die Größe des Empfangsfensters wird wie folgt bestimmt:
- Die erste an einen Remotehost gesendete Verbindungsanforderung kündigt eine Empfangsfenstergröße von 16 KB an (16.384 Bytes).
- Wenn die Verbindung hergestellt wird, wird die Größe des Empfangsfensters auf einen gleichmäßigen Schritt des MSS aufgerundet.
- Die Fenstergröße wird auf viermal das MSS, auf eine maximale Größe von 64 K angepasst, es sei denn, die Fensterskalierungsoption (RFC 1323) wird verwendet.
Notiz
Weitere Informationen finden Sie im Abschnitt "Windows-Skalierung".
Bei Ethernet-Verbindungen wird die Fenstergröße normalerweise auf 17.520 Bytes festgelegt (16K wird auf zwölf 1460-Byte-Segmente aufgerundet). Die Fenstergröße kann reduziert werden, wenn eine Verbindung mit einem Computer hergestellt wird, der erweiterte TCP-Kopfoptionen unterstützt, z. B. selektive Bestätigungen (SACKS) und Zeitstempel. Diese beiden Optionen erhöhen die TCP-Headergröße auf mehr als 20 Bytes, was zu weniger Platz für Daten führt.
In früheren Versionen von Windows NT betrug die Fenstergröße für eine Ethernet-Verbindung 8.760 Bytes oder sechs 1460-Byte-Segmente.
Um die Größe des Empfangsfensters auf einen bestimmten Wert festzulegen, fügen Sie den TcpWindowSize-Wert dem Registrierungsunterschlüssel hinzu, der für Ihre Windows-Version spezifisch ist. Führen Sie dazu die folgenden Schritte aus:
Wählen Sie "Ausführen starten">, geben
RegeditSie "Ok" ein, und wählen Sie dann "OK" aus.Erweitern Sie den registrierungsspezifischen Unterschlüssel für Ihre Windows-Version:
Erweitern Sie für Windows 2000 den folgenden Unterschlüssel:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\InterfacesErweitern Sie für Windows Server 2003 den folgenden Unterschlüssel:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Zeigen Sie im Menü Bearbeiten auf Neu und wählen Sie dann DWORD-Wert.
Geben Sie
TcpWindowSizedas Feld "Neuer Wert " ein, und drücken Sie dann die EINGABETASTE.Wählen Sie im Menü "Bearbeiten" die Option "Ändern" aus.
Geben Sie die gewünschte Fenstergröße in das Feld "Wert"-Daten ein.
Notiz
Der gültige Bereich für die Fenstergröße beträgt 0-0x3FFFC000 Hexadezimalzahl.
Dieser Wert ist standardmäßig nicht vorhanden. Wenn Sie den TcpWindowSize-Wert hinzufügen, wird der oben beschriebene Standardalgorithmus für die Fenstergröße außer Kraft gesetzt.
Notiz
TcpWindowSize kann auch dem Parameterschlüssel hinzugefügt werden, um die Fenstergröße für alle Schnittstellen global festzulegen.
TCP-Optionen werden jetzt unterstützt
Zuvor wurden TCP-Optionen hauptsächlich für die Aushandlung maximaler Segmentgrößen verwendet. In Windows werden TCP-Optionen für die Fensterskalierung, den Zeitstempel und die selektive ACK verwendet.
Es gibt zwei Arten von TCP-Optionen:
- Eine einzelne Oktett-TCP-Option, die verwendet wird, um eine bestimmte Optionsart anzugeben.
- Eine TCP-Option mit mehreren Oktetts, die aus einer Optionsart, einer Optionslänge und einer Reihe von Options octets besteht.
In der folgenden Liste sind die einzelnen TCP-Optionsarten, Längen, Namen und Beschreibungen aufgeführt.
Art: 0
Länge:1
Option: Ende der Optionsliste
Beschreibung: Wird beim Auffüllen für die letzte TCP-Option verwendet.
Art: 1
Länge:1
Option: Kein Vorgang
Beschreibung: Wird verwendet, wenn Der Abstand benötigt wird und weitere TCP-Optionen innerhalb desselben Pakets folgen.
Art: 2
Länge:4
Option: Maximale Segmentgröße
Beschreibung: Gibt die maximale Größe für ein TCP-Segment an, das über das Netzwerk gesendet werden kann.
Art: 3
Länge: 3
Option: Fensterskalaoption
Beschreibung: Gibt den Skalierungsfaktor an, der bei Verwendung von Fenstergrößen verwendet werden soll, die größer als 64k sind.
Art: 8
Länge: 10
Option: Zeitstempeloption
Beschreibung: Wird verwendet, um die Roundtrip-Zeit (RoundTrip Time, RTT) von übertragenen Paketen zu berechnen.
Art: 4
Länge:2
Option: TCP-SACK zulässig
Beschreibung: Informiert andere Hosts, dass selektive Acks zulässig sind.
Art: 5
Länge: Variiert
Option: TCP-SACK-Option
Beschreibung: Wird von Hosts verwendet, um zu ermitteln, ob Out-of-Order-Pakete empfangen wurden.
Windows-Skalierung
Für eine effizientere Verwendung von Netzwerken mit hoher Bandbreite kann eine größere TCP-Fenstergröße verwendet werden. Das Feld "TCP-Fenstergröße" steuert den Datenfluss und ist auf 2 Bytes oder eine Fenstergröße von 65.535 Bytes beschränkt.
Da das Größenfeld nicht erweitert werden kann, wird ein Skalierungsfaktor verwendet. Die TCP-Fensterskala ist eine Option, die verwendet wird, um die maximale Fenstergröße von 65.535 Bytes auf 1 Gigabyte zu erhöhen.
Die Fensterskalaoption wird nur während des DREI-Wege-Handshakes von TCP verwendet. Der Fensterskalierungswert stellt die Anzahl der Bits dar, um das 16-Bit-Fenstergrößefeld nach links zu verschieben. Der Fensterskalierungswert kann von 0 (keine Schicht) auf 14 festgelegt werden.
Um die tatsächliche Fenstergröße zu berechnen, multiplizieren Sie die Fenstergröße mit 2^S, wobei S der Skalierungswert ist.
Beispiel:
Wenn die Fenstergröße 65.535 Byte mit einem Fensterskalierungsfaktor von 3 beträgt.
True Fenstergröße = 65535*2^3
True Fenstergröße = 524280
Die folgende Netzwerküberwachungsüberwachung zeigt, wie die Fensterskalaoption verwendet wird:
TCP: ....S., len:0, seq:725163-725163, ack:0, win:65535, src:1217 dst:139(NBT Session)
TCP: Source Port = 0x04C1
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 725163 (0xB10AB)
TCP: Acknowledgement Number = 0 (0x0)
TCP: Data Offset = 44 (0x2C)
TCP: Reserved = 0 (0x0000)
+ TCP: Flags = 0x02 : ....S.
TCP: Window = 65535 (0xFFFF)
TCP: Checksum = 0x8565
TCP: Urgent Pointer = 0 (0x0)
TCP: Options
+ TCP: Maximum Segment Size Option
TCP: Option Nop = 1 (0x1)
TCP: Window Scale Option
TCP: Option Type = Window Scale
TCP: Option Length = 3 (0x3)
TCP: Window Scale = 3 (0x3)
TCP: Option Nop = 1 (0x1)
TCP: Option Nop = 1 (0x1)
+ TCP: Timestamps Option
TCP: Option Nop = 1 (0x1)
TCP: Option Nop = 1 (0x1)
+ TCP: SACK Permitted Option
Die im tatsächlichen Drei-Wege-Handshake verwendete Fenstergröße entspricht nicht der skalierten Fenstergröße gemäß RFC 1323 Abschnitt 2.2:
"Das Fensterfeld in einem SYN -Segment (z. B. ein [SYN] oder [SYN,ACK]) selbst wird nie skaliert."
Dies bedeutet, dass das erste Datenpaket, das nach dem dreiseitigen Handshake gesendet wurde, die tatsächliche Fenstergröße ist. Wenn ein Skalierungsfaktor vorhanden ist, wird die anfängliche Fenstergröße von 65.535 Byte immer verwendet. Die Fenstergröße wird dann mit dem Skalierungsfaktor multipliziert, der im dreiseitigen Handshake identifiziert wird. Die folgende Tabelle stellt die Skalierungsfaktorgrenzen für verschiedene Fenstergrößen dar.
| Skalierungsfaktor | Skalierungswert | Anfangsfenster | Fensterskala skaliert |
|---|---|---|---|
| 0 | 1 | 65535 oder weniger | 65535 oder weniger |
| 1 | 2 | 65.535 | 131.070 |
| 2 | 4 | 65.535 | 262.140 |
| 3 | 8 | 65.535 | 524.280 |
| 4 | 16 | 65.535 | 1,048,560 |
| 5 | 32 | 65.535 | 2,097,120 |
| 6 | 64 | 65.535 | 4,194,240 |
| 7 | 128 | 65.535 | 8,388,480 |
| 8 | 256 | 65.535 | 16,776,960 |
| 9 | 512 | 65.535 | 33,553,920 |
| 10 | 1024 | 65.535 | 67,107,840 |
| 11 | 2048 | 65.535 | 134,215,680 |
| 12 | 4096 | 65.535 | 268,431,360 |
| 13 | 8192 | 65.535 | 536,862,720 |
| 14 | 16384 | 65.535 | 1,073,725,440 |
Zum Beispiel:
Wenn die Fenstergröße in der Registrierung als 2690000000 (269M) dezimal eingegeben wird, beträgt der Skalierungsfaktor während des dreiseitigen Handshakes 13. Ein Skalierungsfaktor von 12 erlaubt nur eine Fenstergröße von bis zu 268.431.360 Bytes (268M).
Die ursprüngliche Fenstergröße in diesem Beispiel wird wie folgt berechnet:
65.535 Byte mit einem Fensterskalierungsfaktor von 13.
True Fenstergröße = 65535*2^13
True Fenstergröße = 536,862,720
Wenn der Wert für die Fenstergröße der Registrierung hinzugefügt wird und seine Größe größer als der Standardwert ist, versucht Windows, einen Skalierungswert zu verwenden, der die neue Fenstergröße berücksichtigt.
Der Wert "Tcp1323Opts" im folgenden Registrierungsschlüssel kann hinzugefügt werden, um Skalierungsfenster und Zeitstempel zu steuern:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
Wählen Sie auf der Symbolleiste "Start>ausführen" aus, und geben
RegeditSie dann den Registrierungs-Editor ein.Wählen Sie im Registrierungs-Editor "Bearbeiten" aus, zeigen Sie auf "Neu", und wählen Sie dann "DWORD-Wert" aus.
Geben Sie
Tcp1323Optsim Feld "Neuer Wert" die EINGABETASTE ein, und wählen Sie dann im Menü "Bearbeiten" die Option "Ändern" aus.Notiz
Der gültige Bereich ist 0, 1, 2 oder 3, wobei:
0 (RFC 1323-Optionen deaktivieren)
1 (nur Fensterskala aktiviert)
2 (nur zeitstempel aktiviert)
3 (beide Optionen aktiviert)
Dieser Registrierungseintrag steuert RFC 1323-Zeitstempel und Fensterskalierungsoptionen. Zeitstempel und Fensterskalierung sind standardmäßig aktiviert, können jedoch mit Flagbits bearbeitet werden. Bit 0 steuert die Fensterskalierung. Bit 1 steuert Zeitstempel.
Zeitstempel
Zuvor verwendete der TCP/IP-Stapel pro Datenfenster ein Beispiel pro Datenfenster, um die Roundtripzeit (Roundtrip Time, RTT) zu berechnen. Beim Senden des Pakets wurde ein Timer (Timer erneut übertragen) festgelegt, bis die Bestätigung empfangen wurde. Wenn die Fenstergröße beispielsweise 64.240 Byte (44 vollständige Segmente) in einem Ethernet-Netzwerk betrug, wurden nur eines der 44 Pakete verwendet, um die Roundtripzeit neu zu berechnen. Mit einer maximalen Fenstergröße von 65.535 Bytes reichte diese Samplingrate aus. Bei Verwendung der Fensterskalierung und einer maximalen Fenstergröße von 1 Gigabyte reicht diese RTT-Samplingrate nicht aus.
Die TCP-Zeitstempeloption kann jetzt für Segmente (Daten und ACK) verwendet werden, die vom Stapel als angemessen erachtet werden, um Vorgänge wie:
- RTT-Berechnung
- PFOTEN-Check
Mithilfe dieser Daten kann das RTT mit großen Fenstergrößen exakt berechnet werden. RTT wird verwendet, um Retransmissionsintervalle zu berechnen. Genaue RTT- und Retransmissionstimeouts sind für einen optimalen Durchsatz erforderlich.
Wenn der TCP-Zeitstempel in einer TCP-Sitzung verwendet wird, sendet der Absender der Sitzung die Option in seinem ersten Paket des TCP-Drei-Wege-Handshake (SYN-Paket). Beide Seiten können dann die TCP-Option während der Sitzung verwenden.
TCP-Zeitstempeloption (TSopt):
| Art = 8 | Länge = 10 | TS-Wert (Tsval) | TS Echo Reply (Tsecr) |
|---|---|---|---|
| 1 Byte | 1 Byte | 4 Bytes | 4 Bytes |
Das Zeitstempeloptionsfeld kann in einer Netzwerküberwachungsablaufverfolgung angezeigt werden, indem das Feld "TCP-Optionen" erweitert wird, wie unten dargestellt:
TCP: Timestamps Option
TCP: Option Type = Timestamps
TCP: Option Length = 10 (0xA)
TCP: Timestamp = 2525186 (0x268802)
TCP: Reply Timestamp = 1823192 (0x1BD1D8)
Schutz vor umbrochenen Sequenznummern (PAWS)
Das Feld "TCP-Sequenznummer" ist auf 32 Bit beschränkt, wodurch die Anzahl der verfügbaren Sequenznummern begrenzt wird. Mit Hochkapazitätsnetzwerken und einer großen Datenübertragung ist es möglich, Sequenznummern umzuschließen, bevor ein Paket das Netzwerk durchläuft. Wenn Daten in einem Giga-Byte pro Sekunde (Gbps)-Netzwerk gesendet werden, können die Sequenznummern in bis zu 34 Sekunden umgebrochen werden. Wenn ein Paket verzögert wird, könnte ein anderes Paket möglicherweise mit derselben Sequenznummer vorhanden sein. Um Verwechslungen doppelter Sequenznummern zu vermeiden, wird der TCP-Zeitstempel als Erweiterung der Sequenznummer verwendet. Pakete verfügen über aktuelle und fortschrittsverwendende Zeitstempel. Ein altes Paket hat einen älteren Zeitstempel und wird verworfen.
Selektive Bestätigungen (SACKs)
Windows bietet Unterstützung für ein Leistungsfeature, das als selektive Bestätigung oder SACK bezeichnet wird. SACK ist besonders wichtig für Verbindungen, die große TCP-Fenstergrößen verwenden. Vor SACK konnte ein Empfänger nur die neueste Sequenznummer eines zusammenhängenden Datenstroms erkennen, der empfangen wurde, oder den "linken Rand" des Empfangsfensters. Wenn SACK aktiviert ist, verwendet der Empfänger weiterhin die ACK-Nummer, um den linken Rand des Empfangsfensters zu bestätigen, aber er kann auch andere Blöcke empfangener Daten einzeln bestätigen. SACK verwendet TCP-Headeroptionen, wie unten dargestellt.
SACK verwendet zwei Arten von TCP-Optionen.
Die TCP-Sack-Zulässige Option wird nur in einem SYN-Paket (während der TCP-Verbindungseinrichtung) verwendet, um anzugeben, dass sie selektive ACK ausführen kann.
Die zweite TCP-Option, TCP-Sackoption, enthält die Bestätigung für einen oder mehrere Datenblöcke. Die Datenblöcke werden mithilfe der Sequenznummer am Anfang und am Ende dieses Datenblocks identifiziert. Es wird auch als linker und rechter Rand des Datenblocks bezeichnet.
Art 4 ist die TCP-Sack-Zulässige Option. Art 5 ist TCP-Sackoption. Länge ist die Länge in Bytes dieser TCP-Option.
Tcp-SACK zulässig:
| Art = 4 | Länge = 2 |
|---|---|
| 1 Byte | 1 Byte |
TCP-SACK-Option:
| Art = 5 | Länge = Variable |
|---|---|
| 1 Byte | Linker Rand des ersten Blocks bis zum rechten Rand des ersten Blocks ... Linker Rand des Nth-Blocks bis zum rechten Rand des Nth-Blocks |
Mit aktiviertem SACK (Standard) kann ein Paket oder eine Reihe von Paketen verworfen werden. Der Empfänger informiert den Absender darüber, welche Daten empfangen wurden und wo es möglicherweise "Löcher" in den Daten gibt. Der Absender kann dann die fehlenden Daten selektiv erneut übertragen, ohne dass datenblöcke erneut übertragen werden, die bereits erfolgreich empfangen wurden. SACK wird vom Registrierungsparameter SackOpts gesteuert.
Der Wert "SackOpts" im folgenden Registrierungsschlüssel kann bearbeitet werden, um die Verwendung selektiver Bestätigungen zu steuern:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
- Wählen Sie auf der Symbolleiste "Start>ausführen" aus, und geben
RegeditSie dann den Registrierungs-Editor ein. - Suchen Sie den obigen Schlüssel im Registrierungs-Editor, und wählen Sie ihn aus, und wählen Sie dann im Menü "Bearbeiten" die Option "Ändern" aus.
- Geben Sie den gewünschten Wert in das Feld "Wert"-Daten ein.
Notiz
Der gültige Binärwert ist 0 oder 1, der Standardwert ist 1. Dieser Parameter steuert, ob die Unterstützung selektiver ACK (SACK – RFC 2018) aktiviert ist.
Die folgende Netzwerküberwachungsablaufverfolgung veranschaulicht einen Host, der alle Daten bis zur Sequenznummer 54857341 sowie die Daten aus der Sequenznummer 54858789-54861685 bestätigt. Die fehlenden Daten stammen aus 54857341 bis 54858788.
TCP: .A...., len:0, seq:925104-925104, ack:54857341, win:32722, src:1242 dst:139
TCP: Source Port = 0x04DA
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 925104 (0xE1DB0)
TCP: Acknowledgement Number = 54857341 (0x3450E7D)
TCP: Data Offset = 44 (0x2C)
TCP: Reserved = 0 (0x0000)
+ TCP: Flags = 0x10 : .A....
TCP: Window = 32722 (0x7FD2)
TCP: Checksum = 0x4A72
TCP: Urgent Pointer = 0 (0x0)
TCP: Options
TCP: Option Nop = 1 (0x1)
TCP: Option Nop = 1 (0x1)
+ TCP: Timestamps Option
TCP: Option Nop = 1 (0x1)
TCP: Option Nop = 1 (0x1)
TCP: SACK Option
TCP: Option Type = 0x05
TCP: Option Length = 10 (0xA)
TCP: Left Edge of Block = 54858789 (0x3451425)
TCP: Right Edge of Block = 54861685 (0x3451F75)
TCP-Retransmissionsverhalten und schnelle Übertragung
TCP-Erneute Übertragung
Als Überprüfung des normalen Retransmissionsverhaltens startet TCP einen Retransmissionstimer, wenn jedes ausgehende Segment an das Internetprotokoll (IP) übergeben wird. Wenn keine Bestätigung für die Daten in einem bestimmten Segment empfangen wurde, bevor der Timer abläuft, wird das Segment erneut übermittelt.
Das Timeout (Retransmission Timeout, RTO) wird kontinuierlich angepasst, um die Eigenschaften der Verbindung mithilfe von SRTT-Berechnungen (Smoothed Round Trip Time) abzugleichen, wie in RFC 793 beschrieben. Der Timer für ein bestimmtes Segment wird nach jeder erneuten Übertragung dieses Abschnitts verdoppelt. Bei Verwendung dieses Algorithmus wird TCP an die normale Verzögerung einer Verbindung gestimmt.
Schnelle Neuübertragung
TCP überschreibt Daten, bevor der Zeitgeber für die erneute Übertragung unter bestimmten Umständen abläuft. Die häufigste Ursache ist ein Feature, das als schnelle Übertragung bezeichnet wird. Wenn ein Empfänger, der die schnelle Neuübertragung unterstützt, Daten mit einer Sequenznummer über die aktuelle erwartete empfängt, wurden einige Daten wahrscheinlich verworfen. Um den Absender dieses Ereignisses zu informieren, sendet der Empfänger sofort eine ACK, wobei die ACK-Nummer auf die Sequenznummer festgelegt ist, die er erwartet hat. Dies geschieht weiterhin für jedes zusätzliche TCP-Segment, das eingeht. Wenn der Absender beginnt, einen Datenstrom von ACKs zu empfangen, der die gleiche Sequenznummer bestätigt, wurde möglicherweise ein Segment verworfen. Der Absender sendet das vom Empfänger erwartete Segment sofort erneut, ohne darauf zu warten, dass der Zeitgeber für die erneute Übertragung abläuft. Diese Optimierung verbessert die Leistung erheblich, wenn Pakete häufig verworfen werden.
Standardmäßig sendet Windows ein Segment unter den folgenden Bedingungen erneut:
- Es empfängt drei ACKs für dieselbe Sequenznummer: ein ACK und zwei Duplikate.
- Die Sequenznummer liegt bei der aktuellen.
Dieses Verhalten kann mit dem TcpMaxDupAcks Registrierungsparameter gesteuert werden.
Der TcpMaxDupAcks-Wert im folgenden Registrierungsschlüssel kann bearbeitet werden, um die Anzahl der ACKs zu steuern, die zum Starten einer schnellen Übertragung erforderlich sind:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
- Wählen Sie auf der Symbolleiste "Start>ausführen" aus, und geben
RegeditSie dann den Registrierungs-Editor ein. - Suchen Sie den obigen Schlüssel im Registrierungs-Editor, und wählen Sie ihn aus, und wählen Sie dann im Menü "Bearbeiten" die Option "Ändern" aus.
- Geben Sie den gewünschten Wert in das Feld "Wert"-Daten ein.
Notiz
Der gültige Bereich ist 1-3, der Standardwert ist 2.
Dieser Parameter bestimmt die Anzahl doppelter ACKs, die für dieselbe Sequenzanzahl gesendeter Daten empfangen werden müssen, bevor fast retransmit das Segment erneut gesendet wird, das bei der Übertragung verworfen wurde.