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