
Проведем анализ: первые три сегмента – обычная установка соединения, в ходе которой
стороны договариваются об использовании последовательных номеров, эти сегменты при анализе
можно опустить, тем более, что в Ethereal используется относительная нумерация байтов, начиная с
единицы, поэтому даже анализ установленных номеров из трех первых сегментов не является
нужным. В четвертом сегменте клиент передает 15 байт данных, начиная с относительного номера
1, следовательно, ожидаемая квитанция на этот сегмент будет иметь номер 16. Далее клиент без
паузы (точнее столь быстро, как это возможно) передает серверу сегмент 5, в котором предлагает
серверу закрыть полусоединение, направленное от клиента к серверу. Сервер в сегменте 6
квитирует и полезные данные, переданные в сегменте 4 и флаг FIN, переданный в сегменте 5, что
видно из анализа номера подтверждения сегмента 6 – этот относительный номера равен 17. Затем
проходит достаточно большая пауза (кстати, не вполне соответствующая той, которая требовалась
параметром –P), после которой сервер передает клиенту свои полезные данные в сегменте 7, клиент
в это время уже полностью закрыл свое полусоединение. Клиент квитирует эти данные в сегменте
8, демонстрируя нам желаемый пример – обмен данными в полузакрытом соединении в одном
направлении, после чего проходит еще одна пауза, вызванная ключом –Q (снова не
соответствующая параметру, с которым утилита была запущена), после чего сервер так же решает
закрыть свое полусоединение, что и происходит в сегментах 9 и 10.
И, наконец, последний на сегодня пример – разрыв TCP соединение с помощью сегмента с
флагом RST в случае аварийного завершения работы приложения, использующего данное TCP
соединение. Для иллюстрации такой ситуации на практике, запустим в качестве клиента и сервера
утилиту sock обычным образом, передадим какие то данные в соединение и снимем процесс sock на
клиентской системе. При этом на экране сервера мы получим следующее сообщение:
C:\>sock -s 192.168.0.89 999
123456789
read error: Connection reset by peer
Проанализируем трафик, генерируемый в этом примере (файл TCP9.cap)