Wyjaśnienie uzgadniania trójstopnienego za pośrednictwem protokołu TCP/IP

Artykuł
12/26/2023

W tym artykule omówiono trzykierunkowy proces uzgadniania protokołu TCP (Transmission Control Protocol) między klientem a serwerem podczas uruchamiania lub kończenia połączenia TCP.

Dotyczy: Windows Server 2012 R2
Oryginalny numer KB: 172983

Podsumowanie

Ten artykuł jest przeznaczony dla odbiorców, którzy znają protokół kontroli transmisji/protokół internetowy (TCP/IP). Podczas uruchamiania lub kończenia połączenia TCP omówiono proces trójstopnienego uzgadniania protokołu TCP między klientem a serwerem.

Więcej informacji

Poziom TCP protokołu transportowego TCP/IP jest zorientowany na połączenie. Połączenie zorientowane oznacza, że przed przesłaniem jakichkolwiek danych należy uzyskać i potwierdzić niezawodne połączenie. Transmisje danych na poziomie TCP, ustanowienie połączenia i zakończenie połączenia obsługują określone parametry kontroli, które regulują cały proces. Bity kontrolek są wyświetlane w następujący sposób:

Urg: pilne pole wskaźnika znaczące
ACK: Istotne pole potwierdzenia
PSH: funkcja wypychania
RST: Resetowanie połączenia
SYN: Synchronizowanie numerów sekwencji
FIN: Brak więcej danych od nadawcy

Istnieją dwa scenariusze, w których odbędzie się uzgadnianie trójstopnie:

Nawiązywanie połączenia (aktywne otwarcie)
Zakończenie połączenia (aktywne zamknięcie)

Poniższe przykładowe informacje uzyskano z przechwytywania monitora sieci. Monitor sieci to analizator protokołów, który można uzyskać z serwera zarządzania systemami firmy Microsoft.

Nawiązywanie połączenia

Poniższa sekwencja przedstawia proces nawiązywania połączenia TCP:

Ramka 1:

Jak widać w pierwszej ramce, klient NTW3 wysyła segment SYN (TCP ....S.). Jest to żądanie do serwera, aby zsynchronizować numery sekwencji. Określa początkowy numer sekwencji (ISN). Wartość IS jest zwiększana o 1 (8221821+1=8221822) i jest wysyłana na serwer. Aby rozpocząć połączenie, klient i serwer muszą zsynchronizować numery sekwencji. Istnieje również opcja ustawienia maksymalnego rozmiaru segmentu (MSS), która jest definiowana przez długość (len: 4). Ta opcja komunikuje mss nadawca chce otrzymać. Pole Potwierdzenie (ack: 0) jest ustawione na zero, ponieważ jest to pierwsza część uzgadniania trójstopnienego.


1 2.0785 NTW3 --> BDC3 TCP ....S., len: 4, seq: 8221822-8221825, ack: 0,
win: 8192, src: 1037 dst: 139 (NBT Session) NTW3 --> BDC3 IP

TCP: ....S., len: 4, seq: 8221822-8221825, ack: 0, win: 8192, src: 1037
dst: 139 (NBT Session)

TCP: Source Port = 0x040D
 TCP: Destination Port = NETBIOS Session Service
 TCP: Sequence Number = 8221822 (0x7D747E)
 TCP: Acknowledgement Number = 0 (0x0)
 TCP: Data Offset = 24 (0x18)
 TCP: Reserved = 0 (0x0000)
 TCP: Flags = 0x02 : ....S.

TCP: ..0..... = No urgent data
 TCP: ...0.... = Acknowledgement field not significant
 TCP: ....0... = No Push function
 TCP: .....0.. = No Reset
 TCP: ......1. = Synchronize sequence numbers
 TCP: .......0 = No Fin

TCP: Window = 8192 (0x2000)
 TCP: Checksum = 0xF213
 TCP: Urgent Pointer = 0 (0x0)
 TCP: Options

TCP: Option Kind (Maximum Segment Size) = 2 (0x2)
 TCP: Option Length = 4 (0x4)
 TCP: Option Value = 1460 (0x5B4)

TCP: Frame Padding

00000: 02 60 8C 9E 18 8B 02 60 8C 3B 85 C1 08 00 45 00 .`.....`.;....E.
00010: 00 2C 0D 01 40 00 80 06 E1 4B 83 6B 02 D6 83 6B .,..@....K.k...k
00020: 02 D3 04 0D 00 8B 00 7D 74 7E 00 00 00 00 60 02 .......}t~....`.
00030: 20 00 F2 13 00 00 02 04 05 B4 20 20 .........

Ramka 2:

Jak widać w drugiej ramce, serwer BDC3 wysyła segment ACK i SYN (TCP .A..S.). W tym segmencie serwer potwierdza żądanie synchronizacji klienta. Tymczasem serwer wysyła również swoje żądanie do klienta w celu synchronizacji jego numerów sekwencji. Istnieje jedna główna różnica w tym segmencie. Serwer przesyła do klienta numer potwierdzenia (8221823). Potwierdzenie jest tylko dowodem dla klienta, że pakiet ACK jest specyficzny dla syn zainicjowanego klienta. Proces potwierdzania żądania klienta umożliwia serwerowi zwiększanie liczby sekwencji klienta o jeden i użycie go jako numeru potwierdzenia.


2 2.0786 BDC3 --> NTW3 TCP .A..S., len: 4, seq: 1109645-1109648, ack:
8221823, win: 8760, src: 139 (NBT Session) dst: 1037 BDC3 --> NTW3 IP

TCP: .A..S., len: 4, seq: 1109645-1109648, ack: 8221823, win: 8760,
src: 139 (NBT Session) dst: 1037

TCP: Source Port = NETBIOS Session Service
 TCP: Destination Port = 0x040D
 TCP: Sequence Number = 1109645 (0x10EE8D)
 TCP: Acknowledgement Number = 8221823 (0x7D747F)
 TCP: Data Offset = 24 (0x18)
 TCP: Reserved = 0 (0x0000)
 TCP: Flags = 0x12 : .A..S.

TCP: ..0..... = No urgent data
 TCP: ...1.... = Acknowledgement field significant
 TCP: ....0... = No Push function
 TCP: .....0.. = No Reset
 TCP: ......1. = Synchronize sequence numbers
 TCP: .......0 = No Fin

TCP: Window = 8760 (0x2238)
 TCP: Checksum = 0x012D
 TCP: Urgent Pointer = 0 (0x0)
 TCP: Options

TCP: Option Kind (Maximum Segment Size) = 2 (0x2)
 TCP: Option Length = 4 (0x4)
 TCP: Option Value = 1460 (0x5B4)

TCP: Frame Padding

00000: 02 60 8C 3B 85 C1 02 60 8C 9E 18 8B 08 00 45 00 .`.;...`......E.
00010: 00 2C 5B 00 40 00 80 06 93 4C 83 6B 02 D3 83 6B .,[.@....L.k...k
00020: 02 D6 00 8B 04 0D 00 10 EE 8D 00 7D 74 7F 60 12 ...........}t`.
00030: 22 38 01 2D 00 00 02 04 05 B4 20 20 "8.-......

Ramka 3:

Jak widać w trzeciej ramce, klient wysyła segment ACK (TCP .A....). W tym segmencie klient potwierdza żądanie z serwera dotyczące synchronizacji. Klient używa tego samego algorytmu, który serwer zaimplementował w celu podania numeru potwierdzenia. Potwierdzenie przez klienta żądania synchronizacji serwera kończy proces ustanawiania niezawodnego połączenia i uzgadniania trójstopnie.


3 2.787 NTW3 --> BDC3 TCP .A...., len: 0, seq: 8221823-8221823, ack:
1109646, win: 8760, src: 1037 dst: 139 (NBT Session) NTW3 --> BDC3 IP

TCP: .A...., len: 0, seq: 8221823-8221823, ack: 1109646, win: 8760,
src: 1037 dst: 139 (NBT Session)

TCP: Source Port = 0x040D
 TCP: Destination Port = NETBIOS Session Service
 TCP: Sequence Number = 8221823 (0x7D747F)
 TCP: Acknowledgement Number = 1109646 (0x10EE8E)
 TCP: Data Offset = 20 (0x14)
 TCP: Reserved = 0 (0x0000)
 TCP: Flags = 0x10 : .A....

TCP: ..0..... = No urgent data
 TCP: ...1.... = Acknowledgement field significant
 TCP: ....0... = No Push function
 TCP: .....0.. = No Reset
 TCP: ......0. = No Synchronize
 TCP: .......0 = No Fin

TCP: Window = 8760 (0x2238)
 TCP: Checksum = 0x18EA
 TCP: Urgent Pointer = 0 (0x0)
 TCP: Frame Padding

00000: 02 60 8C 9E 18 8B 02 60 8C 3B 85 C1 08 00 45 00 .`.....`.;....E.
00010: 00 28 0E 01 40 00 80 06 E0 4F 83 6B 02 D6 83 6B .(..@....O.k...k
00020: 02 D3 04 0D 00 8B 00 7D 74 7F 00 10 EE 8E 50 10 .......}t....P.
00030: 22 38 18 EA 00 00 20 20 20 20 20 20 "8....

Zakończenie połączenia

Chociaż uzgadnianie trójstopnie wymaga przesyłania tylko trzech pakietów za pośrednictwem naszych nośników sieciowych, zakończenie tego niezawodnego połączenia musi przesyłać cztery pakiety. Ponieważ połączenie TCP jest pełnodupleksowe (dane mogą przepływać w każdym kierunku niezależnie od drugiego), każdy kierunek musi zostać zakończony niezależnie.

Ramka 4:

W tej sesji ramek zobaczysz, że klient wysyła fin, któremu towarzyszy ACK (TCP .A...F). Ten segment ma dwie podstawowe funkcje. Po pierwsze po ustawieniu parametru FIN poinformuje on serwer, że nie ma więcej danych do wysłania. Po drugie, pakiet ACK jest niezbędny do identyfikowania określonego połączenia, które nawiązali.


4 16.0279 NTW3 --> BDC3 TCP .A...F, len: 0, seq: 8221823-8221823,
ack:3462835714, win: 8760, src: 2337 dst: 139 (NBT Session) NTW3 --> BDC3
IP

TCP: .A...F, len: 0, seq: 8221823-8221823, ack: 1109646, win: 8760, src:
1037 dst: 139 (NBT Session)

TCP: Source Port = 0x040D
 TCP: Destination Port = NETBIOS Session Service
 TCP: Sequence Number = 8221823 (0x7D747F)
 TCP: Acknowledgement Number = 1109646 (0x10EE8E)
 TCP: Data Offset = 20 (0x14)
 TCP: Reserved = 0 (0x0000)
 TCP: Flags = 0x11 : .A...F

TCP: ..0..... = No urgent data
 TCP: ...1.... = Acknowledgement field significant
 TCP: ....0... = No Push function
 TCP: .....0.. = No Reset
 TCP: ......0. = No Synchronize
 TCP: .......1 = No more data from sender

TCP: Window = 8760 (0x2238)
 TCP: Checksum = 0x236C
 TCP: Urgent Pointer = 0 (0x0)

00000: 00 20 AF 47 93 58 00 A0 C9 22 F5 39 08 00 45 00 . .G.X...".9..E.
00010: 00 28 9B F5 40 00 80 06 21 4A C0 5E DE 7B C0 5E .(..@...!J.^.{.^
00020: DE 57 09 21 05 48 0B 20 96 AC CE 66 AE 02 50 11 .W.!.H. ...f..P.
00030: 22 38 23 6C 00 00 "8#l..

Ramka 5:

W tej ramce nie widać nic specjalnego, z wyjątkiem serwera potwierdzającego fin, który został przesłany z klienta.


5 16.0281 BDC3 --> NTW3 TCP .A...., len: 0, seq: 1109646-1109646,
ack: 8221824, win:28672, src: 139 dst: 2337 (NBT Session) BDC3 --> NTW3
IP

TCP: .A...., len: 0, seq: 1109646-1109646, ack: 8221824, win:28672, src:
139 dst: 2337 (NBT Session)

TCP: Source Port = 0x040D
 TCP: Destination Port = NETBIOS Session Service
 TCP: Sequence Number = 1109646 (0x10EE8E)
 TCP: Acknowledgement Number = 8221824 (0x7D7480)
 TCP: Data Offset = 20 (0x14)
 TCP: Reserved = 0 (0x0000)
 TCP: Flags = 0x10 : .A....

TCP: ..0..... = No urgent data
 TCP: ...1.... = Acknowledgement field significant
 TCP: ....0... = No Push function
 TCP: .....0.. = No Reset
 TCP: ......0. = No Synchronize
 TCP: .......0 = No Fin

TCP: Window = 28672 (0x7000)
 TCP: Checksum = 0xD5A3
 TCP: Urgent Pointer = 0 (0x0)
 TCP: Frame Padding

00000: 00 A0 C9 22 F5 39 08 00 02 03 BA 84 08 00 45 00 ...".9........E.
00010: 00 28 D2 82 00 00 3F 06 6B BD C0 5E DE 57 C0 5E .(....?.k..^.W.^
00020: DE 7B 05 48 09 21 CE 66 AE 02 0B 20 96 AD 50 10 .{.H.!.f... ..P.
00030: 70 00 D5 A3 00 00 90 00 01 00 86 00 p...........

Ramka 6:

Po otrzymaniu fin z komputera klienckiego, serwer będzie ACK. Mimo że protokół TCP nawiązał połączenia między dwoma komputerami, połączenia są nadal niezależne od siebie. Dlatego serwer musi również przesyłać fin (TCP .A...F) do klienta.


6 17.0085 BDC3 --> NTW3 TCP .A...F, len: 0, seq: 1109646-1109646, ack:
8221824, win:28672, src: 139 dst: 2337 (NBT Session) BDC3 --> NTW3 IP

TCP: .A...F, len: 0, seq: 1109646-1109646, ack: 8221824, win:28672, src:
139 dst: 2337 (NBT Session)

TCP: Source Port = 0x0548
 TCP: Destination Port = 0x0921
 TCP: Sequence Number = 1109646 (0x10EE8E)
 TCP: Acknowledgement Number = 8221824 (0x7D7480)
 TCP: Data Offset = 20 (0x14)
 TCP: Reserved = 0 (0x0000)
 TCP: Flags = 0x11 : .A...F

TCP: ..0..... = No urgent data
 TCP: ...1.... = Acknowledgement field significant
 TCP: ....0... = No Push function
 TCP: .....0.. = No Reset
 TCP: ......0. = No Synchronize
 TCP: .......1 = No more data from sender

TCP: Window = 28672 (0x7000)
 TCP: Checksum = 0xD5A2
 TCP: Urgent Pointer = 0 (0x0)
 TCP: Frame Padding

00000: 00 A0 C9 22 F5 39 08 00 02 03 BA 84 08 00 45 00 ...".9........E.
00010: 00 28 D2 94 00 00 3F 06 6B AB C0 5E DE 57 C0 5E .(....?.k..^.W.^
00020: DE 7B 05 48 09 21 CE 66 AE 02 0B 20 96 AD 50 11 .{.H.!.f... ..P.
00030: 70 00 D5 A2 00 00 02 04 05 B4 86 00 p...........

Ramka 7:

Klient odpowiada w tym samym formacie co serwer, przez acking serwera FIN i zwiększania liczby sekwencji o 1.


7 17.0085 NTW3 --> BDC3 TCP .A...., len: 0, seq: 8221824-8221824, ack:
1109647, win: 8760, src: 2337 dst: 139 (NBT Session) NTW3 --> BDC3 IP

TCP: .A...., len: 0, seq: 8221824-8221824, ack: 1109647, win: 8760, src:
2337 dst: 139 (NBT Session)

TCP: Source Port = 0x0921
 TCP: Destination Port = 0x0548
 TCP: Sequence Number = 8221824 (0x7D7480)
 TCP: Acknowledgement Number = 1109647 (0x10EE8F)
 TCP: Data Offset = 20 (0x14)
 TCP: Reserved = 0 (0x0000)
 TCP: Flags = 0x10 : .A....

TCP: ..0..... = No urgent data
 TCP: ...1.... = Acknowledgement field significant
 TCP: ....0... = No Push function
 TCP: .....0.. = No Reset
 TCP: ......0. = No Synchronize
 TCP: .......0 = No Fin

TCP: Window = 8760 (0x2238)
 TCP: Checksum = 0x236B
 TCP: Urgent Pointer = 0 (0x0)

00000: 00 20 AF 47 93 58 00 A0 C9 22 F5 39 08 00 45 00 . .G.X...".9..E.
00010: 00 28 BA F5 40 00 80 06 02 4A C0 5E DE 7B C0 5E .(..@....J.^.{.^
00020: DE 57 09 21 05 48 0B 20 96 AD CE 66 AE 03 50 10 .W.!.H. ...f..P.
00030: 22 38 23 6B 00 00 "8#k..

Klient ACKing powiadomienie FIN z serwera identyfikuje bezproblemowe zamknięcie połączenia TCP.

Informacje

Uzyskaj RFC 793.

RFC można uzyskać za pośrednictwem Internetu w następujący sposób:

Papierowe kopie wszystkich RFC są dostępne z karty sieciowej indywidualnie lub w ramach subskrypcji (aby uzyskać więcej informacji, skontaktuj się z użytkownikiem NIC@NIC.DDN.MIL). Kopie online są dostępne za pośrednictwem protokołu FTP lub Kermit z NIC.DDN.MIL jako rfc/rfc####.txt lub rfc/rfc####.PS (#### to numer RFC bez zer wiodących).