Wyjaśnienie trójkierunkowego uzgadniania za pośrednictwem protokołu TCP/IP
W tym artykule omówiono trzystopniowy proces uzgadniania protokołu TRANSMISSION Control Protocol (TCP) 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ół TCP/IP (Transmission Control Protocol/Internet Protocol). W tym artykule omówiono proces trójkierunkowego uzgadniania protokołu TCP między klientem a serwerem podczas uruchamiania lub kończenia połączenia TCP.
Więcej informacji
Poziom TCP protokołu transportowego TCP/IP jest zorientowany na połączenie. Zorientowane na połączenie oznacza, że przed przesłaniem jakichkolwiek danych należy uzyskać i potwierdzić niezawodne połączenie. Transmisje danych na poziomie TCP, ustanowienie połączenia i kończenie połączenia zachowują określone parametry sterowania, które zarządzają całym procesem. Bity sterowania są wyświetlane w następujący sposób:
URG: Istotne pole pilnego wskaźnika
ACK: istotne pole potwierdzenia
PSH: funkcja wypychania
RST: Resetowanie połączenia
SYN: Synchronizowanie numerów sekwencji
FIN: Nie ma więcej danych od nadawcy
Istnieją dwa scenariusze, w których odbędzie się trzykierunkowe uzgadnianie:
Ustanawianie połączenia (aktywne otwarcie)
Kończenie połączenia (aktywne zamknięcie)
Poniższe przykładowe informacje zostały uzyskane z przechwytywania monitora sieci. Network Monitor to analizator protokołu, który można uzyskać z programu Microsoft Systems Management Server.
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 w celu zsynchronizowania numerów sekwencji. Określa swój początkowy numer sekwencji (ISN). Element IS jest zwiększany o 1 (8221821+1=8221822) i jest wysyłany do serwera. Aby uruchomić połączenie, klient i serwer muszą synchronizować ze sobą numery sekwencji. Istnieje również opcja ustawienia maksymalnego rozmiaru segmentu (MSS), która jest definiowana przez długość (len: 4). Ta opcja komunikuje usługę MSS, którą nadawca chce odebrać. Pole Potwierdzenie (ack: 0) jest ustawione na zero, ponieważ jest to pierwsza część trójkierunkowego uzgadniania.
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 klienta synchronizacji. Tymczasem serwer wysyła również żądanie do klienta w celu synchronizacji numerów sekwencji. Istnieje jedna główna różnica w tym segmencie. Serwer przesyła do klienta numer potwierdzenia (8221823). Potwierdzenie jest tylko potwierdzeniem dla klienta, że usługa ACK jest specyficzna dla syn inicjowanego przez 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 na potrzeby synchronizacji. Klient używa tego samego algorytmu, który serwer zaimplementował w podaniu numeru potwierdzenia. Potwierdzenie żądania serwera na potrzeby synchronizacji kończy proces ustanawiania niezawodnego połączenia i trzykierunkowe uzgadnianie.
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....
Kończenie połączenia
Chociaż trzykierunkowe uzgadnianie wymaga tylko trzech pakietów, które mają być przesyłane za pośrednictwem naszych sieciowych nośników, zakończenie tego niezawodnego połączenia musi przesyłać cztery pakiety. Ponieważ połączenie TCP jest w trybie pełnodupleksowym (dane mogą przepływać w każdym kierunku niezależnie od siebie), każdy kierunek musi zostać przerwany niezależnie.
Ramka 4:
W tej sesji ramek zobaczysz klienta wysyłającego FIN, któremu towarzyszy ACK (TCP .A...F). Ten segment ma dwie podstawowe funkcje. Najpierw po ustawieniu parametru FIN zostanie wyświetlony komunikat o tym, że serwer nie ma więcej danych do wysłania. Po drugie, usługa ACK jest niezbędna 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 widzisz żadnych specjalnych elementów, z wyjątkiem serwera uznają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 fin serwera i zwiększanie numeru 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:
Kopie papieru wszystkich RFC są dostępne z karty sieciowej pojedynczo lub na podstawie subskrypcji (aby uzyskać więcej informacji kontaktowych 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 (#### jest liczbą RFC bez zer wiodących).