Проведем  анализ:  первые  три  сегмента – обычная  установка  соединения,  в  ходе  которой 

стороны договариваются об использовании последовательных номеров, эти сегменты при анализе 
можно опустить, тем более, что в 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)