Объяснение трехстороннего подтверждения через TCP/IP
В этой статье рассматривается процесс трехстороннего подтверждения протокола TCP между клиентом и сервером при запуске или завершении TCP-подключения.
Применяется к: Windows Server 2012 R2
Исходный номер базы знаний: 172983
Сводка
Эта статья предназначена для аудиторий, знакомых с протоколом TCP/IP. В ней описывается процесс трехстороннего подтверждения TCP между клиентом и сервером при запуске или завершении TCP-подключения.
Дополнительная информация
Уровень TCP транспортного протокола TCP/IP ориентирован на подключение. Ориентированный на подключение означает, что перед передачей любых данных необходимо получить и подтвердить надежное соединение. Передача данных на уровне TCP, установка и завершение подключения поддерживают определенные параметры управления, которые управляют всем процессом. Биты элемента управления перечислены следующим образом:
URG: поле срочного указателя имеет значение
ACK: поле подтверждения имеет важное значение
PSH: функция push-уведомлений
RST: сброс подключения
SYN: синхронизация порядковых номеров
FIN: больше нет данных от отправителя
Существует два сценария, в которых будет выполняться трехстороннее рукопожатие:
Установка подключения (активное открытое)
Завершение подключения (активное закрытие)
Приведенные ниже примеры сведений были получены из записи сетевого монитора. Сетевой монитор — это анализатор протокола, который можно получить на сервере Microsoft Systems Management Server.
Установка подключения
В следующей последовательности показан процесс установки 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 с клиентского компьютера сервер будет атаковывать. Несмотря на то, что 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 сервера FIN и увеличения последовательного номера на 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.
RFC можно получить через Интернет следующим образом:
Бумажные копии всех RFC доступны из сетевого адаптера по отдельности или по подписке (для получения дополнительных сведений обратитесь к ).NIC@NIC.DDN.MIL Сетевые копии доступны через FTP или Kermit из NIC.DDN.MIL в виде rfc/rfc###.txt или rfc/rfc####.PS (#### — это номер RFC без начальных нулей).
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по