Wyjaśnienie uzgadniania trójstopnienego za pośrednictwem protokołu TCP/IP
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.
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).