Beskrivning av Windows TCP-funktioner

Den här artikeln beskriver TCP-funktionerna i Windows.

Gäller för: Windows 10 – alla utgåvor, Windows Server 2012 R2
Ursprungligt KB-nummer: 224829

Sammanfattning

I den här artikeln beskrivs följande TCP-funktioner i Windows:

  • TCP-fönsterstorlek
  • TCP-alternativ stöds nu
  • Windows-skalning – RFC 1323
  • Tidsstämpel – RFC 1323
  • Skydd mot omslutna sekvensnummer (PAWS)
  • Selektiva bekräftelser (SACKS) – RFC 2018
  • TCP-återöverföringsbeteende och snabb omöverföring

TCP-funktionerna kan ändras genom att ändra posterna i registret.

Viktigt

Följande avsnitt, metoder eller uppgifter innehåller steg som beskriver hur du ändrar registret. Det kan uppstå allvarliga problem om du gör detta felaktigt. Följ därför instruktionerna noga, och säkerhetskopiera registret innan du gör några ändringar i det. Då kan du återställa registret om det uppstår problem. Om du vill veta mer om hur du säkerhetskopierar och återställer registret klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
322756 Hur man säkerhetskopierar och återställer registret i Windows

TCP-fönsterstorlek

Storleken på TCP-mottagningsfönstret är mängden mottagna data (i byte) som kan bufferas under en anslutning. Den sändande värden kan bara skicka den mängden data innan den måste vänta på en bekräftelse och en fönsteruppdatering från den mottagande värden. Windows TCP/IP-stacken är utformad för att finjustera sig själv i de flesta miljöer och använder större standardfönsterstorlekar än tidigare versioner.

I stället för att använda en hårdkodad standardstorlek för mottagningsfönster justerar TCP till jämna steg med den maximala segmentstorleken (MSS). MSS förhandlas under anslutningskonfigurationen. Om du justerar mottagningsfönstret till jämna ökningar av MSS ökar procentandelen fullstora TCP-segment som används vid massöverföring av data.

Storleken på mottagningsfönstret bestäms på följande sätt:

  1. Den första anslutningsbegäran som skickas till en fjärrvärd annonserar en mottagarfönsterstorlek på 16 000 (16 384 byte).
  2. När anslutningen upprättas avrundas storleken på mottagningsfönstret upp till en jämn ökning av MSS.
  3. Fönsterstorleken justeras till fyra gånger MSS, till en maximal storlek på 64 K, såvida inte alternativet för fönsterskalning (RFC 1323) används.

Obs!

Se avsnittet "Windows-skalning".

För Ethernet-anslutningar anges fönsterstorleken normalt till 17 520 byte (16 000 avrundade upp till tolv segment på 1 460 byte). Fönsterstorleken kan minska när en anslutning upprättas till en dator som stöder utökade TCP-huvudalternativ, till exempel selektiva bekräftelser (SACKS) och tidsstämplar. Dessa två alternativ ökar storleken på TCP-huvudet till mer än 20 byte, vilket ger mindre utrymme för data.

I tidigare versioner av Windows NT var fönsterstorleken för en Ethernet-anslutning 8 760 byte eller sex segment på 1 460 byte.

Om du vill ange storleken på mottagningsfönstret till ett specifikt värde lägger du till TcpWindowSize-värdet i registerundernyckeln som är specifik för din version av Windows. Gör så här:

  1. Välj Starta>körning, skriv Regeditoch välj sedan OK.

  2. Expandera registerundernyckeln som är specifik för din version av Windows:

    • För Windows 2000 expanderar du följande undernyckel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces

    • För Windows Server 2003 expanderar du följande undernyckel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

  3. redigera-menyn pekar du på Nytt och väljer sedan DWORD-värde.

  4. Skriv TcpWindowSize i rutan Nytt värde och tryck sedan på Retur

  5. Välj Ändra redigera-menyn.

  6. Ange önskad fönsterstorlek i datarutan Värde .

    Obs!

    Det giltiga intervallet för fönsterstorleken är 0 0x3FFFC000 hexadecimalt.

Det här värdet finns inte som standard. När du lägger till TcpWindowSize-värdet åsidosätter det standardalgoritmen för fönsterstorlek som beskrivs ovan.

Obs!

TcpWindowSize kan också läggas till i parameternyckeln för att ange fönsterstorleken globalt för alla gränssnitt.

TCP-alternativ stöds nu

Tidigare användes TCP-alternativ främst för att förhandla om maximala segmentstorlekar. I Windows används TCP-alternativ för fönsterskalning, tidsstämpel och selektiv ACK.

Det finns två typer av TCP-alternativ:

  1. Ett TCP-alternativ med en oktett som används för att ange en specifik alternativtyp.
  2. Ett TCP-alternativ med flera oktetter, som består av en alternativtyp, en alternativlängd och en serie alternativoktets.

I följande lista visas varje TCP-alternativtyp, längd, namn och beskrivning.

Typ: 0
Längd: 1
Alternativ: Alternativlistans slut
Beskrivning: Används när utfyllnad behövs för det senaste TCP-alternativet.

Typ: 1
Längd: 1
Alternativ: Ingen åtgärd
Beskrivning: Används när utfyllnad behövs och fler TCP-alternativ följer i samma paket.

Typ: 2
Längd: 4
Alternativ: Maximal segmentstorlek
Beskrivning: Anger den maximala storleken för ett TCP-segment som kan skickas över nätverket.

Typ: 3
Längd: 3
Alternativ: Alternativ för fönsterskalning
Beskrivning: Identifierar skalningsfaktorn som ska användas när du använder fönsterstorlekar som är större än 64 000.

Typ: 8
Längd: 10
Alternativ: Tidsstämpelalternativ
Beskrivning: Används för att beräkna rtt (Round Trip Time) för överförda paket.

Typ: 4
Längd: 2
Alternativ: TCP SACK tillåts
Beskrivning: Informerar andra värdar om att selektiva acks är tillåtna.

Typ: 5
Längd: Varierar
Alternativ: TCP SACK-alternativ
Beskrivning: Används av värdar för att identifiera om out-of-order-paket togs emot.

Windows-skalning

För effektivare användning av nätverk med hög bandbredd kan en större TCP-fönsterstorlek användas. Fältet TCP-fönsterstorlek styr dataflödet och är begränsat till 2 byte eller en fönsterstorlek på 65 535 byte.

Eftersom storleksfältet inte kan utökas används en skalningsfaktor. TCP-fönsterskala är ett alternativ som används för att öka den maximala fönsterstorleken från 65 535 byte till 1 Gigabyte.

Alternativet för fönsterskalning används endast under TCP-trevägshandskakningen. Fönstrets skalningsvärde representerar antalet bitar som ska vänsterförskjuta fältet med 16-bitars fönsterstorlek. Skalningsvärdet för fönstret kan anges från 0 (inget skift) till 14.

Om du vill beräkna den sanna fönsterstorleken multiplicerar du fönsterstorleken med 2^S där S är skalningsvärdet.

Till exempel:

Om fönsterstorleken är 65 535 byte med en fönsterskalningsfaktor på 3.
Sann fönsterstorlek = 65535*2^3

Sann fönsterstorlek = 524280

Följande nätverksövervakningsspårning visar hur alternativet för fönsterskalning används:

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  

Fönsterstorleken som används i den faktiska trevägshandskakningen är inte den fönsterstorlek som skalas, enligt RFC 1323 avsnitt 2.2:

"Fältet Fönster i en SYN (till exempel ett [SYN] eller [SYN,ACK])-segment skalas aldrig."

Det innebär att det första datapaketet som skickas efter trevägshandskakningen är den faktiska fönsterstorleken. Om det finns en skalningsfaktor används alltid den ursprungliga fönsterstorleken på 65 535 byte. Fönsterstorleken multipliceras sedan med skalningsfaktorn som identifieras i trevägshandskakningen. Tabellen nedan representerar skalningsfaktorgränserna för olika fönsterstorlekar.

Skalningsfaktor Skalningsvärde Inledande fönster Fönster skalat
0 1 65535 eller mindre 65535 eller mindre
1 2 65535 131,070
2 4 65535 262,140
3 8 65535 524,280
4 16 65535 1,048,560
5 32 65535 2,097,120
6 64 65535 4,194,240
7 128 65535 8,388,480
8 256 65535 16,776,960
9 512 65535 33,553,920
10 1024 65535 67,107,840
11 2048 65535 134,215,680
12 4096 65535 268,431,360
13 8192 65535 536,862,720
14 16384 65535 1,073,725,440

Till exempel:

Om fönsterstorleken i registret anges som 2690000000 (269 M) i decimaltal är skalningsfaktorn under trevägshandskakningen 13. En skalningsfaktor på 12 tillåter endast en fönsterstorlek på upp till 268 431 360 byte (268 M).

Den inledande fönsterstorleken i det här exemplet beräknas på följande sätt:
65 535 byte med en skalningsfaktor för fönster på 13.
Verklig fönsterstorlek = 65535*2^13
Verklig fönsterstorlek = 536 862 720

När värdet för fönsterstorlek läggs till i registret och dess storlek är större än standardvärdet försöker Windows använda ett skalningsvärde som passar den nya fönsterstorleken.

Värdet Tcp1323Opts i följande registernyckel kan läggas till för att styra skalningsfönster och tidsstämpel:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

  1. I verktygsfältet väljer du Starta>körning och skriver Regedit sedan för att starta Editor.

  2. I register Editor väljer du Redigera, pekar på Ny och väljer sedan DWORD-värde.

  3. I rutan Nytt värde skriver du Tcp1323Opts, trycker på RETUR och väljer sedan Ändrapå redigera-menyn.

    Obs!

    Det giltiga intervallet är 0, 1, 2 eller 3 där:
    0 (inaktivera RFC 1323-alternativ)
    1 (endast fönsterskalning aktiverat)
    2 (endast tidsstämplar aktiverade)
    3 (båda alternativen är aktiverade)

Den här registerposten styr RFC 1323-tidsstämplar och skalningsalternativ för fönster. Tidsstämplar och fönsterskalning är aktiverade som standard, men kan ändras med flaggbitar. Bit 0-kontroller fönsterskalning. Bit 1 styr tidsstämplar.

Tidsstämplar

Tidigare använde TCP/IP-stacken ett exempel per fönster med data som skickades för att beräkna tur och retur-tiden (RTT). En timer (återöverföringstimer) angavs när paketet skickades tills bekräftelsen togs emot. Om fönsterstorleken till exempel var 64 240 byte (44 fullständiga segment) i ett Ethernet-nätverk användes bara ett av 44 paket för att beräkna om tur och retur-tiden. Med en maximal fönsterstorlek på 65 535 byte var samplingsfrekvensen tillräcklig. Med hjälp av fönsterskalning och en maximal fönsterstorlek på 1 Gigabyte räcker inte den här RTT-samplingsfrekvensen.

Alternativet TCP-tidsstämpel kan nu användas på segment (data och ACK) som anses lämpliga av stacken för att utföra åtgärder som:

  • RTT-beräkning
  • PAWS-kontroll

Med hjälp av dessa data kan RTT beräknas korrekt med stora fönsterstorlekar. RTT används för att beräkna återöverföringsintervall. Korrekta RTT- och återöverföringstidsutgånger behövs för optimalt dataflöde.

När TCP-tidsstämpeln används i en TCP-session skickar sessionens upphovsman alternativet i sitt första paket i TCP-trevägshandskakningen (SYN-paket). Båda sidor kan sedan använda TCP-alternativet under sessionen.

TCP-tidsstämplar (TSopt):

Typ = 8 Längd = 10 TS-värde (Tsval) TS Echo-svar (Tsecr)
1 byte 1 byte 4 byte 4 byte

Tidsstämpelalternativfältet kan visas i en nätverksövervakningsspårning genom att expandera fältet TCP-alternativ enligt nedan:

TCP: Timestamps Option  
TCP: Option Type = Timestamps  
TCP: Option Length = 10 (0xA)  
TCP: Timestamp = 2525186 (0x268802)  
TCP: Reply Timestamp = 1823192 (0x1BD1D8)

Skydd mot omslutna sekvensnummer (PAWS)

TCP-sekvensnummerfältet är begränsat till 32 bitar, vilket begränsar antalet tillgängliga sekvensnummer. Med nätverk med hög kapacitet och en stor dataöverföring går det att omsluta sekvensnummer innan ett paket passerar nätverket. Om du skickar data i ett Giga-byte per sekund (Gbit/s) nätverk kan sekvensnumren radbryts in så lite som 34 sekunder. Om ett paket fördröjs kan ett annat paket finnas med samma sekvensnummer. För att undvika förvirring av dubblettsekvensnummer används TCP-tidsstämpeln som ett tillägg till sekvensnumret. Paket har aktuella tidsstämplar och tidsstämplar för förlopp. Ett gammalt paket har en äldre tidsstämpel och tas bort.

Selektiva bekräftelser (SACK:er)

Windows introducerar stöd för en prestandafunktion som kallas selektiv bekräftelse eller SACK. SACK är särskilt viktigt för anslutningar som använder stora TCP-fönsterstorlekar. Före SACK kunde en mottagare bara bekräfta det senaste sekvensnumret för en sammanhängande dataström som hade tagits emot eller "vänsterkanten" i mottagningsfönstret. När SACK är aktiverat fortsätter mottagaren att använda ACK-numret för att bekräfta den vänstra kanten av mottagningsfönstret, men den kan också bekräfta andra block med mottagna data individuellt. SACK använder alternativ för TCP-huvuden enligt nedan.

SACK använder två typer av TCP-alternativ.

TCP-Sack-Permitted-alternativet används endast i ett SYN-paket (under TCP-anslutningsetableringen) för att indikera att det kan utföra selektiv ACK.

Det andra TCP-alternativet, TCP Sack Option, innehåller bekräftelse för ett eller flera datablock. Datablocken identifieras med sekvensnumret i början och i slutet av datablocket. Det kallas även vänster och höger kant för datablocket.

Typ 4 är TCP-Sack-Permitted alternativ. Typ 5 är TCP-säckalternativ. Längden är längden i byte för det här TCP-alternativet.

Tcp SACK tillåts:

Typ = 4 Längd = 2
1 byte 1 byte

Tcp SACK-alternativ:

Typ = 5 Längd = variabel
1 byte Vänster kant av första blocket till höger kant av första blocket
...
Vänster kant av Nth block till höger kant av Nth block

Med SACK aktiverat (standard) kan ett paket eller en serie paket tas bort. Mottagaren informerar avsändaren om vilka data som har tagits emot och var det kan finnas "hål" i data. Avsändaren kan sedan selektivt överföra de saknade data utan vidaresändning av datablock som redan har tagits emot. SACK styrs av registerparametern SackOpts.

SackOpts-värdet i följande registernyckel kan redigeras för att styra användningen av selektiva bekräftelser:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

  1. I verktygsfältet väljer du Starta>körning och skriver Regedit sedan för att starta Editor.
  2. Leta upp och välj ovanstående nyckel i register Editor och välj sedan Ändrapå redigera-menyn.
  3. Ange önskat värde i rutan Värdedata .

Obs!

Det giltiga binära värdet är 0 eller 1, standardvärdet är 1. Den här parametern styr om stöd för selektiv ACK (SACK – RFC 2018) är aktiverat.

Följande network monitor-spårning visar en värd som bekräftar alla data upp till sekvensnummer 54857341, plus data från sekvensnummer 54858789-54861685. De data som saknas är från 54857341 till 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-återöverföringsbeteende och snabb omöverföring

TCP-återöverföring

Som en genomgång av normalt återöverföringsbeteende startar TCP en timer för återöverföring när varje utgående segment delas ut till Internet Protocol (IP). Om ingen bekräftelse har tagits emot för data i ett visst segment innan timern upphör att gälla, överförs segmentet igen.

Timeouten för återöverföring (RTO) justeras kontinuerligt för att matcha anslutningens egenskaper med hjälp av SRTT-beräkningar (Smoothed Round Trip Time) enligt beskrivningen i RFC 793. Timern för ett visst segment fördubblas efter varje återöverföring av segmentet. Med den här algoritmen justerar sig TCP till den normala fördröjningen för en anslutning.

Snabb omöverföring

TCP återöverför data innan timern för återöverföring upphör att gälla under vissa omständigheter. Den vanligaste orsaken är en funktion som kallas snabb omöverföring. När en mottagare som har stöd för snabb vidareöverföring tar emot data med ett sekvensnummer som är längre än det förväntade, togs sannolikt vissa data bort. För att informera avsändaren om den här händelsen skickar mottagaren omedelbart en ACK, med ACK-numret inställt på det sekvensnummer som förväntades. Det fortsätter att göra det för varje ytterligare TCP-segment som kommer. När avsändaren börjar ta emot en ström med ACL:er som bekräftar samma sekvensnummer kan ett segment ha tagits bort. Avsändaren skickar omedelbart det segment som mottagaren förväntar sig, utan att vänta på att återöverföringstimern upphör att gälla. Den här optimeringen förbättrar prestanda avsevärt när paket ofta tas bort.

Som standard skickar Windows ett segment igen under följande villkor:

  • Den tar emot tre ACL:er för samma sekvensnummer: en ACK och två dubbletter.
  • Sekvensnumret släpar efter det aktuella.

Det här beteendet kan styras med registerparametern TcpMaxDupAcks .

TcpMaxDupAcks-värdet i följande registernyckel kan redigeras för att styra antalet ACL:er som krävs för att starta en snabb omöverföring:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

  1. I verktygsfältet väljer du Starta>körning och skriver Regedit sedan för att starta Editor.
  2. Leta upp och välj ovanstående nyckel i register Editor och välj sedan Ändrapå redigera-menyn.
  3. Ange önskat värde i rutan Värdedata .

Obs!

Det giltiga intervallet är 1–3, standardvärdet är 2.

Den här parametern bestämmer antalet duplicerade ACL:er som måste tas emot för samma sekvensantal skickade data innan fast retransmit utlöses för att skicka om segmentet som har släppts under överföring.