8-900-374-94-44
В этой статье рассматривается трехфакторное подтверждение протокола 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 .). Это запрос к серверу для синхронизации порядкового номера. Он задает начальный порядковый номер (ISN). Значение ISN увеличивается на 1 (8221821+1 =8221822) и отправляется на сервер. Чтобы начать подключение, клиент и сервер должны синхронизировать порядковые номера друг друга. Также можно задать максимальный размер сегмента (MSS), который определяется длиной (len: 4). Этот параметр сообщает MSS, который отправитель хочет получить. Поле подтверждения (подтверждение: 0) имеет нулевое значение, так как это первая часть трехфакторного подтверждения.
...S.
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 .,[email protected] 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.). В этом сегменте сервер подтверждает запрос клиента на синхронизацию. В то же время сервер также отправляет клиенту запрос на синхронизацию порядкового номера.
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: .
Фрейм 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 .([email protected] 00020: 02 D3 04 0D 00 8B 00 7D 74 7F 00 10 EE 8E 50 10 .
Хотя трехстороннее подтверждение требует передачи только трех пакетов через сетевой носитель, завершение этого надежного подключения должно передавать четыре пакета. Так как TCP-подключение является полным дуплексным (данные могут выполняться в каждом направлении независимо от другого), каждое направление должно быть прервано независимо друг от друга.
Фрейм 4.
В этом сеансе кадров вы увидите, что клиент отправляет fin, который сопровождается подтверждением (TCP .A...F). Этот сегмент имеет две основные функции. Во-первых, когда параметр FIN задается, он сообщает серверу, что у него больше нет данных для отправки. Во-вторую, подтверждение важно для определения конкретного установленного соединения.
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.
Фрейм 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 .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: .
Фрейм 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 .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..
Клиент acKing уведомление FIN с сервера определяет корректное закрытие TCP-подключения.
Получите RFC 793.
RFC можно получить через Интернет следующим образом:
В сетевом адаптере доступны копии всех RFC по отдельности или по подписке (для получения дополнительных сведений [email protected]). Сетевые копии доступны через FTP или Kermit из NIC.DDN.MIL как rfc/rfc####.txt или rfc/rfc####.PS (#### — это номер RFC без начальных нулей).
Основные промежуточные результаты :
На данном этапе у нас работает http сервер на LWIP 1.4.1. Вариант именно RAW на FreeRTOS. Динамическое выделение памяти мы убрали отовсюду (malloc) , используем только диспетчер памяти от LWIP (HTTPD_USE_MEM_POOL ).
FreeRTOS мы делаем static и таким образом FreeRTOS у нас не занимается динамическим выделением памяти.
К сожалению вынужден признать , что LWIP 2.1.2 похоже не просто глюк на глюке , а что-то еще похуже….
У нас есть указатель на цепочку структур tcp_active_pcbs , tcp_tw_pcbs , tcp_listen_pcbs. Это сути цепочки элементов (структур), где каждый головной элемент указывает на следующий и так далее. Общее число элементов меняется во время работы.
В tcp_active_pcbs хранится указатель на цепочку активных соединений.
Но еще есть и соединения , у которых истекло время ожидания активной работы. Эти соединения хранятся в tcp_tw_pcbs цепочке.
Можно сразу обратится к функции tcp_input, именно она изучает поступающие tcp пакеты. Сначала она ищет по параметрам поступившего пакета (remote_port, local_port , remote_ip , local_ip ) пакет в цепочке активных соединений tcp_active_pcbs.
Далее если не нашли в tcp_active_pcbs ищем в tcp_tw_pcbs и если находим вызываем tcp_timewait_input и выходим.
Далее если не нашли и в tcp_tw_pcbs мы ищем просто в списке прослушиваемых портов tcp_listen_pcbs.listen_pcbs ( по local_port и local_ip) . Если находим то вызываем tcp_listen_input и на выход.
И наконец остается только вариант одного из активных соединений. Тут мы вызываем tcp_process и получаем данные (флаг PSH).
Эта цепочка tcp_listen_pcbs. Здесь просто собраны прослушиваемые порты. Состояние LISTEN , то есть когда соединение еще не установлено.
Вот в какие состояния переходят в процессе обмена TCP пакетами сервер и клиент:
Чтобы разобраться с tcp надо обязательно разобраться с вариантами все возможных состояний tcp соединения .
К счастью их не так много.
...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 .,
....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 .,[
......}t....P.
00030: 22 38 18 EA 00 00 20 20 20 20 20 20 "8....
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..
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...........
const char * const tcp_state_str [ ] =
{ "CLOSED" , "LISTEN" , "SYN_SENT" , "SYN_RCVD" , "ESTABLISHED" , "FIN_WAIT_1" ,
"FIN_WAIT_2" , "CLOSE_WAIT" , "CLOSING" , "LAST_ACK" , "TIME_WAIT" };
Первый tcp пакет , который мы получим , это SYN . В этот момент у нас (на сервере) нет еще активного соединения и мы попадаем в tcp_listen_input. Если у принятого пакета флаг TCP_SYN установлен мы создаем новое соединение tcp_alloc (выделяем память) и инициализируем свойства нового соединения и заносим созданную структуру npcb в цепочку активных соединений tcp_active_pcbs с свойством состояния SYN_RCVD. И отсылаем обратно ответ через tcp_output с флагами TCP_SYN | TCP_ACK.
Клиент передает первый пакет SYN. В пакете клиента Seq установлен в конкретное значение.
Ack не становлен (то просто 0).
Сервер отвечает клиенту пакетом SYN/ACK, где придумывает Seq сервера !=0. Cервер устанавливает обязательно ack сервера = последний seq клиента+1.
Клиент отвечает пакетом ACK , где seq (клиента) = последний ack сервера +1.
Таким образом каждый (клиент и сервер) придумывают себе seq (каждый сам себе). Ack — ом они подтверждают прием от оппонента.
В отсылаемом обратно ответе сервера клиенту есть несколько важных опций : например Window size value. В коде LWIP этот параметр устанавливается дефайном #define TCP_SND_BUF (2 * TCP_MSS) и у нас при TCP_MSS=1460 получается 2920.
TCP_MSS — это максимальный размер передаваемого сегмента (одного пакета).
Таким образом клиент узнает , что подряд можно передать не больше 2920 байт или (2 сегмента) и надо обязательно ждать ответа с подтверждением ACK от сервера.
Все далее со вторым пакетом мы в tcp_listen_input не попадем, а попадем уже в tcp_process для обработки пакета в уже созданном активном соединении.
Это цепочка tcp_active_pcbs . Здесь наше соединение в состоянии SYN_RECV. Идет обмен данными. Отрабатывает функция tcp_process.
Второй пакет , который придет, это ACK является ответом клиента на TCP_SYN |TCP_ACK и просто подтверждает установление соединения клиентом. Здесь сервер ничего не отвечает (если все в порядке с переданными параметрами) и устанавливает состояние соединению ESTABLISHED.
Третий пакет — это уже сами данные , передаваемый клиентом запрос. Принимаем данные (запрос) также в tcp_process case ESTABLISHED : функция tcp_receive(). Здесь клиент передает в пакете флаги PSH & ACK.
PSH как раз означает — передача данных. В tcp_receive есть макрос TCP_EVENT_RECV , тут как раз и вызывается http_recv и начинается подготовка ответа на HTTP запрос.
Далее подготавливаем пакет данных (контент страницы) через http_send , http_write , tcp_write и отсылаем данные через tcp_output (причем получилось два пакета). В первом пакете ответа флаг ACK, во втором (завешающем) FIN , ACK , PSH .
ACK — это подтверждение клиенту , что запрос принят и выполнен.
PSH — понятно , это передаются данные ,которые надо принять клиенту.
FIN — это требование завершения соединения от сервера клиенту.
Далее клиент отвечает тремя пакетами [ACK] [ACK] [FIN,ACK] .
В этих передачах соблюдется особый алгоритм контроля через поля Seq и Ack.
Эта технология защищает от путаницы пакетов, первый пришел позже второго и т.д.
С каждым новым соединением инициатор устанавливает новые произвольные значения для Seq и Ack. Надо еще учесть , что в программе Winshark Seq и Ack пересчитываются как будто они идут с нуля.
После того как клиент запросил данные у HTTP сервера и сервер отдал контент запрашиваемой страницы, клиент посылает команду закрытия соединения с флагом FIN, ACK и сервер отвечает ACK и закрывает соединение со свой стороны. Тут тоже задействован механихм Seq/Ack:
Теперь осталось разобрать только состояние TIME-WAIT соединения.
Здесь собираются все соединения, переведенные LWIP в статус TIME-WAIT . Зачем это надо?
Инициатором закрытия соединения может быть любой участник : и клиент и сервер. Мы являемся сервером и если мы инициатор закрытия соединения , то мы должны перейти в конце в состояние TIME-WAIT на 1-2 минуты.
Это делается для того , чтобы если клиент не закрыл соединение (на самом деле) или какие-то пакеты еще в пути (не дошли), чтобы все это гарантировано принять и отработать. На это и дается 1-2 минуты.
Таймер для соединения TIME_WAIT устанавливается в 1 — 2 минуты. После чего соединение должно быть уничтожено (у сервера). На картинке ниже Хост 1 это наш сервер.
Кстати в нашем случае у нас соединение закрывает клиент и поэтому механизм TIME_WAIT (у сервера) не используется.
По изучению кода реализации tcp протокола можно сказать , что объем кода немалый и мелочей там нет. Значит надо запастись терпением и заставить себя хотя бы проанализировать основные части кода.
Не надо путать Seq клиента и Seq сервера. И не надо путать Ack клиента и Ack сервера.
*
USB_RNIDS1.4.1_http_server_log [zip]
Это лог , где хорошо видна иерархия вызываемых функциий
Задавать вопрос
спросил
Изменено 3 года, 8 месяцев назад
Просмотрено 384 раза
Недавно я начал работать в сфере ИТ, и в качестве первого задания они хотят, чтобы я связался с удаленной платой с помощью простого сокета с использованием Java.
Сегодня я выполнил всю работу, но заметил, что мои сообщения не были правильно получены … Поэтому я начал копать и начал использовать wirehark для лучшего понимания «Что происходит?».
Я знаю, что перед отправкой данных клиент и сервер выполняют трехстороннее рукопожатие, затем клиент отправляет свои данные, а когда это делается, он закрывает соединение и говорит серверу. Теперь вот мой вопрос: я отправляю пакет на удаленную плату с помощью Packet Sender (идеально подходит для отладки и тестирования), и вот что я вижу:
Первые 3 сообщения - рукопожатие 1. клиент SYN сервер 2. сервер SYN, клиент ACK 3. клиентский ACK-сервер тогда я получил это сообщение 4. клиентский PSH, сервер ACK 5. клиент ACK сервера 6. клиент FIN, сервер ACK 7. клиент ACK сервера 8. сервер FIN, клиент ACK 9. клиентский ACK-сервер
PSH — это фаза, когда я отправляю байт в сокет сервера, затем сервер отвечает, поэтому я закрываю (FIN) соединение, а затем сервер делает то же самое. Этот порядок очень важно соблюдать, чтобы иметь правильное общение? Это результат моего пакета, отправленного с помощью моей программы в JAVA:
Рукопожатие 1.
Что вы думаете? Как я могу решить эту проблему? Это действительно раздражает, потому что сервер вообще ничего не делал. Должен ли я попытаться открыть сокет на несколько миллисекунд? Всегда ли протокол TCP работает так, как описано выше в примере с отправителем пакетов, или его можно смешивать с большим количеством запросов, как это происходит в моей программе? Спасибо всем
Я решил проблему, установив задержку в 300 мс перед закрытием потока и сокета, чтобы клиент и сервер имели подходящее время для разговора друг с другом. Более низкая задержка заставляет их снова рассинхронизироваться! Может этот пост кому-нибудь поможет 😀
Зарегистрируйтесь с помощью Google
Зарегистрироваться через Facebook
Зарегистрируйтесь, используя электронную почту и пароль
Электронная почта
Требуется, но никогда не отображается
Электронная почта
Требуется, но не отображается
Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания, политикой конфиденциальности и политикой использования файлов cookie
У меня есть несколько запросов HEAD в неделю, которые выглядят так (я предполагаю, что это какая-то попытка взлома):
289 24133.
787750 81.94.192.233 -> 95.85.35.251 HTTP 118 HEAD / HTTP/1.1
290 24133.987861 81.94.192.233 -> 95.85.35.251 TCP 118 [Повторная передача TCP] 53341 → 80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=5
291 24134.215884 81.94.192.233 -> 95.85.35.251 TCP 118 [Повторная передача TCP] 53341 → 80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=5
292 24134.442721 81.94.192.170 -> 95.85.35.251 TCP 118 [Повторная передача TCP] 36843 → 80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=5
293 24134.671833 81.94.192.233 -> 95.85.35.251 TCP 118 [Повторная передача TCP] 53341 → 80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=5
294 24135.583822 81.94.192.233 -> 95.85.35.251 TCP 118 [Повторная передача TCP] 53341 → 80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=5
295 24136.110698 81.94.192.170 -> 95.85.35.251 TCP 118 [Повторная передача TCP] 36843 → 80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=5
296 24137.411821 81.94.192.233 -> 95.85.35.251 TCP 118 [Повторная передача TCP] 53341 → 80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=5
297 24139.442873 81.94.192.170 -> 95.
85.35.251 TCP 118 [Повторная передача TCP] 36843 → 80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=5
298 24141.063860 81.94.192.233 -> 95.85.35.251 TCP 118 [Повторная передача TCP] 53341 → 80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=5
299 24146.114817 81.94.192.170 -> 95.85.35.251 TCP 118 [Повторная передача TCP] 36843 → 80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=5
300 24148.375866 81.94.192.233 -> 95.85.35.251 TCP 118 [Повторная передача TCP] 53341 → 80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=5
301 24159.458755 81.94.192.170 -> 95.85.35.251 TCP 118 [Повторная передача TCP] 36843 → 80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=5
302 24162.983859 81.94.192.233 -> 95.85.35.251 TCP 118 [Повторная передача TCP] 53341 → 80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Лен=5
303 24186.146998 81.94.192.170 -> 95.85.35.251 TCP 118 [Повторная передача TCP] 36843 → 80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=5
304 24192.231838 81.94.192.233 -> 95.85.35.251 TCP 118 [Повторная передача TCP] 53341 → 80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=5
305 24192.
клиент SYN сервер
2. сервер SYN, клиент ACK
3. клиентский ACK-сервер
тогда я получил это сообщение
4. клиентский PSH, сервер ACK
5. клиент FIN, сервер ACK
6. клиент ACK сервера
7. клиент ACK сервера
8. сервер FIN, клиент ACK
9. клиентский ACK-сервер