Файл трассировки Wireshark RST после пакета FIN
У меня есть клиент и сервер приложений, которые обмениваются сертификатами друг с другом и устанавливают безопасное соединение TLS.
В конце такого соединения, после приложения данные передаются. Клиент отправляет пакет FIN на сервер, в ответ сервер отвечает зашифрованным пакетом предупреждения TLSV1.2.
Это дополнительно подтверждается клиентом, и клиент на этот раз отправляет пакет RST. Не могли бы вы помочь мне расшифровать это поведение. Я пытаюсь определить исходный трафик между этими конечными точками, а затем принять эти записи в качестве входных данных.
По этой ссылке здесь, https://faultserver.ru/questions/854692/client-sends-rst-after-fin-ack, похоже, что сокет не отключается до его закрытия, что приводит к плохому программированию. Мне любопытно подтвердить, так ли это.
1 ответ
Согласно "Руководству по TCP" по завершению, обычный порядок событий:
- ---> FIN
- <--- ACK
- <--- Ожидает, что приложение с сокетом подтвердит закрытие соединения
- <--- FIN
- ---> ACK
Шаги 2 и 3 часто выполняются одновременно для пакета FIN/ACK. Хороший, величественный танец.
Тем не менее, TCP имеет другой способ разорвать соединение, и это быстрее, чем эта статная процедура. Бросить RST пакет на это. Это грубый способ сделать это, но HTTP может сойти с рук, так как передача данных имеет два потока, и если второй поток завершен (ответ сервера), то все готово. Для HTTP-соединений, которые общеизвестно медленны (то есть, у них есть трудолюбивый человек, часто ожидающий отображения страницы, в то время как браузер обрабатывает более 50 запросов на ресурсы), небольшие изменения скорости - это то, как все делается вовремя.
В этом случае 185 хозяин пытается быть милым об этом, но 172 хозяин это все что я сделал, уходи.
Как администратор сетевой безопасности, распространенность RST пакеты в таких потоках выделяются как аномалии сети. Это одна из областей, где протоколы используются во имя оптимизации. Это ожидаемый поток для трафика HTTP в эти дни.