Объяснение трехстороннего подтверждения через TCP/IP
В этой статье рассматривается трехсторонняя процедура подтверждения передачи между клиентом и сервером при запуске или завершении TCP-подключения.
Исходный номер базы знаний: 172983
Итоги
Эта статья предназначена для аудиторий, знакомых с протоколом управления передачей или интернет-протоколом (TCP/IP). Он обсуждает процесс трехстороннего подтверждения TCP между клиентом и сервером при запуске или завершении TCP-подключения.
Дополнительная информация
Уровень TCP транспортного протокола TCP/IP ориентирован на подключение. Ориентированное на подключение означает, что перед передачей любых данных необходимо получить и подтвердить надежное подключение. Передачи данных уровня TCP, создание подключения и завершение подключения поддерживают определенные параметры управления, которые управляют всем процессом. Биты элемента управления перечислены следующим образом:
URG: важное поле срочного указателя
ACK: поле подтверждения значительно
PSH: push-функция
RST: сброс подключения
SYN: синхронизация порядковых номеров
FIN: больше данных от отправителя не будет
Существует два сценария, в которых будет проходить трехсторонняя рукопожатие:
Установка подключения (активное открытие)
Завершение подключения (активное закрытие)
Приведенные ниже примеры сведений были получены из записи сетевого монитора. Сетевой монитор — это анализатор протокола, который можно получить с сервера управления системами Майкрософт.
Установка подключения
В следующей последовательности показан процесс установки TCP-подключения:
Кадр 1:
Как видно в первом кадре, клиент NTW3 отправляет сегмент SYN (TCP ....S.). Это запрос на сервер для синхронизации порядковых номеров. Он указывает начальный порядковый номер (ISN). IS увеличивается на 1 (8221821+1=8221822) и отправляется на сервер. Чтобы начать подключение, клиент и сервер должны синхронизировать порядковые номера друг друга. Также можно задать максимальный размер сегмента (MSS), который определяется длиной (len: 4). Этот параметр сообщает MSS, что отправитель хочет получить. Поле подтверждения (ack: 0) равно нулю, так как это первая часть трехстороннего подтверждения.
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 .........
Кадр 2:
Как видно во втором кадре, сервер, BDC3, отправляет сегмент ACK и SYN (TCP .A..S.). В этом сегменте сервер подтверждает запрос клиента на синхронизацию. Между тем сервер также отправляет запрос клиенту для синхронизации его порядковых номеров. В этом сегменте имеется одна основная разница. Сервер передает клиенту номер подтверждения (8221823). Подтверждение является просто доказательством того, что ACK относится к SYN, инициированный клиентом. Процесс подтверждения запроса клиента позволяет серверу увеличивать порядковый номер клиента по одному и использовать его в качестве номера подтверждения.
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.-......
Кадр 3:
Как видно в третьем кадре, клиент отправляет сегмент ACK (TCP .A....). В этом сегменте клиент подтверждает запрос от сервера для синхронизации. Клиент использует тот же алгоритм, что и сервер, реализованный при предоставлении номера подтверждения. Подтверждение клиента о запросе сервера на синхронизацию завершает процесс установления надежного подключения и трехстороннего подтверждения.
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....
Завершение подключения
Хотя для трехстороннего подтверждения требуется передавать только три пакета через сетевой носитель, завершение этого надежного подключения должно передавать четыре пакета. Так как TCP-подключение является полно дуплексным (данные могут передаваться в каждом направлении независимо от другого), каждое направление должно быть завершено независимо.
Кадр 4:
В этом сеансе кадров отображается клиент, отправляющий FIN, который сопровождается ACK (TCP .A...F). Этот сегмент имеет две основные функции. Во-первых, когда параметр FIN задан, он сообщит серверу, что у него больше нет данных для отправки. Во-вторых, ACK имеет важное значение для идентификации определенного соединения, который они установили.
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..
Кадр 5:
В этом кадре вы не видите ничего специального, за исключением сервера, подтверждаюющего FIN, который был передан от клиента.
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...........
Кадр 6:
После получения FIN с клиентского компьютера сервер будет ACK. Несмотря на то, что TCP установил соединения между двумя компьютерами, подключения по-прежнему не зависят друг от друга. Поэтому сервер также должен передавать FIN (TCP .A...F) клиенту.
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...........
Кадр 7:
Клиент отвечает в том же формате, что и сервер, путем ACKing ФИН сервера и добавив порядковый номер на 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..
Клиент, содержащий уведомление FIN с сервера, идентифицирует корректное закрытие TCP-подключения.
Ссылки
Получите RFC 793.
RfCs могут быть получены через Интернет следующим образом:
Бумажные копии всех RFC доступны в сетевом адаптере по отдельности или по подписке (для получения дополнительных сведений).NIC@NIC.DDN.MIL Сетевые копии доступны через FTP или Kermit из NIC.DDN.MIL как rfc/rfc####.txt или rfc/rfc####.PS (#### — это номер RFC без начальных нулей).