Возникает вопрос – если соединения можно разрывать одним сегментом, зачем использовать
для этого целых четыре? Во-первых такой разрыв соединения происходит без квитирования,
поэтому если партнер НЕ получит сегмента с флагом RST, он так и не узнает о завершении
соединения. Во-вторых, такой разрыв соединения является по своей сути аварийным и TCP
генерирует для приложения на другой стороне соединения специальный код завершения операции,
на основании этого второе приложение, скорее всего, уведомит пользователя/администратора об
аварийном завершении сеанса. Так что использование такого метода разрыва соединения в
обычных случаях крайне не желательно.
Подытожим, что мы изучили:
• Использование флагов и полей Sequence Number и Acknowledged Number в процессе
открытия TCP соединения
• Принципы использования поле Sequence Number и Acknowledged Number для квитирования
в процессе обмена данными в рамках установленного TCP соединения
• Использование флагов и полей Sequence Number и Acknowledged Number в процессе
закрытия TCP соединения
Еще раз отмечу, что пока мы не претендуем на то, чтобы утверждать, что мы
полностью изучили темы «Установка TCP соединения», «Разрыв TCP соединения»,
«Квитирование данных в TCP соединении». Мы изучили лишь формальное использование трех
флагов и полей Sequence Number и Acknowledged Number при установке, разрыве соединение, а так
же при передаче данных в соединении. На самом деле в процессе установки TCP соединения часто
используют опции для оговаривания ряда параметров, процесс установки и разрыва соединения
может несколько отличаться от рассмотренных нами примеров, квитирование вообще весьма
сложная и громоздкая тема, когда речь идет об эффективных стратегиях квитирования. Мы
рассмотрели пока лишь ЭЛЕМЕНТАРНЫЕ, БАЗОВЫЕ вопросы установки/разрыва соединений и
квитирования, в дальнейшем эти темы будут нами полностью раскрыты. Как мы уже говорили,
сначала мы рассмотрим самые базовые принципы работы TCP, а уже затем перейдем к
рассмотрению всех тонкостей и нюансов работы данного протокола. ОЧЕНЬ важно, чтобы Вы
ориентировались в том, какую часть материала Вы уже знаете, понимали, в какой области Вы еще
не имеете знаний и видели четкий план дальнейших действий.
Теперь продемонстрируем на практике работу протокола TCP. Начнем с рассмотрения
процесса установки TCP соединения. В качестве сервера и клиента будем использовать утилиту
sock, которой мы пользовались при изучении протокола UDP. Запустим на одном из узлов сети
утилиту sock в качестве сервера на некотором порту и подключимся к этому серверу с помощью
клиента. На сервере запустим утилиту sock следующей командой:
c:\sock –s 555
На клиенте дадим команду:
c:\sock 192.168.0.89 555
Проанализируем трафик установки соединения (файл TCP1.cap) с помощью привычного
анализатора Sniffer Pro. Отметим, что в первом сегменте клиент устанавливает флаг SYN, передает
свой ISN, после чего анализатор демонстрирует нам Next Expected Sequence Number. Важно
отметить, что такого поля в заголовке TCP НЕТ, это анализатор предсказывает, каким именно будет
следующий Sequence Number на основании количества данных, передаваемых в сегменте и
установленных флагов (напоминаем, что флаги SYN и FIN увеличивают на единицу ожидаемый
Acknowledged Number). В данном случае анализатор информирует нас о том, что следующее
значение поля Sequence Number будет на единицу больше текущего, так как в этом сегменте
установлен флаг SYN. Важно понимать, что некоторый полей в заголовке НЕТ, и анализатор
демонстрирует нам соответствующую информацию для облегчения анализа протокола. Отметим,
что поле Acknowledged Number в этом сегменте заполнено нулями (а флаг ACK не установлен), это
видно из анализа сырых байтов сегмента, но анализатор не показывает нам этого поля. Так же
отметим, что в заголовке данного сегмента используются опции суммарной длиной 8 байт, с их
помощью клиент предлагает серверу оговорить некоторые дополнительные параметры, которые мы
рассмотрим позже.