Данный документ описывает Протокол управления передачей данных в DoD стандарте (TCP). Данный стандарт основывается на девяти предыдущих изданиях ARPA спецификации TCP, данный текст сильно отличается от них. В него внесены большие изменения как в отношении концепций, так и в отношении текста. Данное издание проясняет некоторые детали протокола и не включает выравнивания по размеру буфера в конце письма, а также переопределяет механизм писем как push функцию.

Джон Постел (Jon Postel)
Редактор
RFC: 793
заменяет RFC 761 и IENs: 129, 124, 112, 81, 55, 44, 40, 27, 21, 5
Протокол управления передачей
Протокол DARPA Internet
Спецификация протокола
1. Введение

Протокол управления передачей (TCP) предназначен для использования в качестве надежного протокола общения между хост-компьютерами в коммуникационных компьютерных сетях с коммутацией пакетов, а также в системах, объединяющих такие сети.

Данный документ описывает функции, которые должны выполняться протоколом управления передачей, программу, которая реализует протокол, а также ее интерфейс с программами или пользователями, нуждающимися в ее услугах.

1.1 Мотивация

Компьютерные коммуникационные системы играют все более важную роль в военных, правительственных и гражданских приложениях. Этот документ в первую очередь освещает требования к компьютерным коммуникациям в военной области, и особенно к устойчивости в условиях недостаточной надежности коммуникаций и возможности перегрузок. Тем не менее, многие из этих проблем имеют место также в гражданском и правительственном секторе.

В условиях, когда стратегические и тактические сети компьютерных коммуникаций возникают и исчезают, важно обеспечить средства для их со единения, а также стандартные протоколы коммуникации между процессами, которые бы поддерживали большой диапазон прикладных программ. Предвидя потребность в таких стандартах, Представительство Секретариата Обороны по научно-исследовательским и опытно- конструкторским работам предъявило протокол управления передачей (Transmission Control Protocol - TCP), описанный здесь, на основе стандартизации DoD протокола коммуникаций между процессами.

TCP - это протокол обеспечения надежности прямых соединений, созданный для многоуровневой иерархии протоколов, поддерживающих межсетевые приложения. Протокол TCP обеспечивает надежность коммуникаций между парами процессов на хост-компьютерах, включенных в различные компьютерные коммуникационные сети, которые объединены в единую систему.

В отношении надежности протоколов более низкого, чем TCP, уровня сделаны весьма скромные запросы. TCP предполагает, что он может получить простой, потенциально ненадежный сервис для своих датаграмм со стороны протоколов нижнего уровня. В принципе, протокол TCP должен быть работоспособен на большом наборе коммуникационных систем, начиная с кабельных соединений и кончая сетями с переключением пакетов или электрических цепей.

Протокол TCP основывается на концепциях, впервые описанных авторами Cerf и Kahn в документе [1]. TCP занимает в многоуровневой архитектуре протоколов нишу непосредственно над протоколом Internet, который позволяет протоколу TCP отправлять и получать сегменты информации переменной длины, заключенные в оболочку Internet датаграмм. Internet датаграмма предоставляет средства для адресации отправителя и получателя сегментов TCP в различных сетях. Протокол Internet также осуществляет любую фрагментацию и сборку сегментов TCP, необходимую для осуществления передачи и доставки через множество сетей и промежуточных шлюзов. Протокол Internet также обрабатывает информацию о приоритете, классификации безопасности, а также осуществляет разграничение TCP сегментов. Так что данная информация может быть передана напрямую через множество сетей.

Уровни протоколов
верхний уровень
TCP
протокол Internet
коммуникационная сеть

Рис. 1

Большая часть этого документа написана в связи с реализациями TCP протокола, которые вместе с протоколами более высокого уровня присутствуют на хост-компьютере. Некоторые компьютерные системы будут включаться в сети через главные компьютеры, содержащие протоколы уровней TCP и Internet, а также специфическое сетевое программное обеспечение.

Спецификация TCP описывает ее интерфейс с протоколами более высокого уровня, которые оказались осуществимы даже в случае главного компьютера, если реализован соответствующий протокол общения между хост-компьютером и главным компьютером.

1.2 Цель

Протокол TCP обязан обеспечить надежный сервис для коммуникаций между процессами в многосетевой системе. Протокол TCP должен быть общим протоколом для коммуникаций между хост-компьютерами во множестве сетей.

1.3 О данном документе

Данный документ предоставляет описание поведения, ожидаемого от любой реализации протокола TCP, а также его взаимодействия как с протоколами более высокого уровня, так и с протоколами TCP на других компьютерах. Оставшаяся часть данной главы дает очень краткий обзор действия протокола и его интерфейсов. Глава 2 суммирует идейный базис для создания протокола TCP. Глава 3 дает как детальное описание поведения, требуемого от протокола TCP при появлении различных событий (прибытие новых сегментов, запрос от пользователя, ошибки и т.д.), так и описание деталей форматов TCP сегментов.

1.4 Интерфейсы

Протокол TCP взаимодействует с одной стороны с пользователем или прикладной программой, а с другой - с протоколом более низкого уровня, таким как протокол Internet.

Интерфейс между прикладным процессом и протоколом TCP мы поясняем с приемлемой детализацией. Этот интерфейс состоит из набора вызовов, которые похожи на вызовы операционной системы, предоставляемые прикладному процессу для управления файлами. Например, в этом случае имеются вызовы для открытия и закрытия соединений, для отправки и получения данных на установленных соединениях. Предполагается также, что протокол TCP сможет асинхронно взаимодействовать с прикладными программами. Хотя разработчикам TCP протокола и предоставлена значительная свобода в создании интерфейсов, которые соответствуют свойствам конкретной операционной системы, все же от любой приемлемой реализации требуются некие обязательные минимальные функции интерфейса между протоколом TCP и пользователем.

Интерфейс между протоколом TCP и протоколами более низкого уровня за дан в значительно меньшей степени, за исключением того, что должен существовать некий механизм, с помощью которого эти два уровня могут асинхронно обмениваться информацией друг с другом. Обычно полагают, что протокол нижнего уровня задает данный интерфейс. Протокол TCP спроектирован так, чтобы работать с весьма разнообразной средой объединенных компьютерных сетей. В данном документе предполагается, что протокол более низкого уровня - это Internet [2].

1.5 Действие

Как указывалось ранее, главной целью протокола TCP является обеспечение надежного, безопасного сервиса для логических цепей или соединений между парами процессов. Чтобы обеспечить такой сервис, основываясь на менее надежных коммуникациях Internet, система должна иметь возможности для работы в следующих областях:

    базовая передача данных
    достоверность
    управление потоком
    разделение каналов
    работа с соединениями
    приоритет и безопасность

Основные действия протокола TCP в каждой из этих областей описаны в следующих параграфах.

Базовая передача данных
Протокол TCP способен передавать непрерывные потоки октетов между своими клиентами в обоих направлениях, пакуя некое количество октетов в сегменты для передачи через системы Internet. В общем случае протоколы TCP решают по своему усмотрению, когда производить блокировку и передачу данных.

Иногда пользователям бывает необходимо убедиться в том, что все данные, переданные ими протоколу TCP, уже отправлены. Для этой цели определена функция проталкивания (push). Чтобы убедиться в том, что данные, отправленные протоколу TCP, действительно переданы, отправитель указывает, что их следует протолкнуть к получателю.

Проталкивание приводит к тому, что программы протокола TCP сразу осуществляют отправление и, соответственно, получение остающихся данных. Правильно осуществленное проталкивание может быть невидимо для получателя, а сама функция проталкивания может не иметь маркера границы записи.

Достоверность
Протокол TCP должен иметь защиту от разрушения данных, потери, дублирования и нарушения очередности получения, вызываемых коммуникационной системой Internet. Это достигается присвоением очередного номера каждому передаваемому октету, а также требованием подтверждения (ACK) от программы TCP, принимающей данные. Если подтверждения не получено в течении контрольного интервала времени, то данные посылаются повторно. Со стороны получателя номера очереди используются для восстановления очередности сегментов, которые могут быть получены в неправильном порядке, а также для ограничения возможности появления дубликатов.

Повреждения фиксируются посредством добавления к каждому передаваемому сегменту контрольной суммы, проверки ее при получении и последующей ликвидации дефектных сегментов.

До тех пор, пока программы протокола TCP продолжают функционировать корректно, а система Internet не развалилась полностью на составные части, ошибки пересылки не будут влиять на правильное получение данных. Протокол TCP защищает от ошибок коммуникационной системы Internet.

Управление потоком
Протокол TCP дает средства получателю управлять количеством данных, посылаемых ему отправителем. Это достигается возвратом так называемого "окна" (window) вместе с каждым подтверждением, которое указывает диапазон приемлемых номеров, следующих за номером последнего успешно принятого сегмента. Окно определяет количество октетов, которое отправитель может послать до получения дальнейших указаний.

Разделение каналов
Чтобы позволить на отдельно взятом компьютере многим процессам одновременно использовать коммуникационные возможности уровня TCP, протокол TCP предоставляет на каждом хост-компьютере набор адресов или портов. Вместе с адресами сетей и хост-компьютеров на коммуникационном уровне Internet они образуют сокет (socket - разъем).

Каждое соединение уникальным образом идентифицируется парой сокетов. Таким образом, любой сокет может одновременно использоваться во многих соединениях.

Соотнесение портов и процессов осуществляется каждым хост- компьютером самостоятельно. Однако оказывается полезным связывать часто используемые процессы (такие как "logger" или сервис с разделением времени) с фиксированными документированными сокетами.

Этот сервис можно впоследствии использовать через известные адреса. Установка и настройка адресов портов для других процессов может включать более динамичные механизмы.

Работа с соединениями
Механизмы управления потоком и обеспечения достоверности, описанные выше, требуют, чтобы программы протокола TCP инициализировали и поддерживали определенную информацию о состоянии каждого потока данных. Набор такой информации, включающий сокеты, номера очереди, размеры окон, называется соединением. Каждое соединение уникальным образом идентифицируется парой сокетов на двух концах.

Если два процесса желают обмениваться информацией, соответствующие программы протокола TCP должны сперва установить соединение (на каждой стороне инициализировать информацию о статусе). По завершении обмена информацией соединение должно быть расторгнуто или закрыто, чтобы освободить ресурсы для предоставления другим пользователям.

Поскольку соединения должны устанавливаться между ненадежными хост-компьютерами и через ненадежную коммуникационную систему Internet, то во избежание ошибочной инициализации соединений используется механизм подтверждения связи с хронометрированными номерами очереди.

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

2. Идеология протокола

2.1 Элементы системы объединенных сетей

Среда объединенных сетей состоит из хост-компьютеров, включенных в сети, которые в свою очередь соединятся друг с другом через шлюзы.

Здесь предполагается, что компьютерные сети могут быть либо локальными (например, ETHERNET), либо большими сетями (например ARPANET), но в любом случае они основываются на технологии коммутации пакетов. Реальными агентами, создающими и потребляющими сообщения, циркулирующие в сети, являются процессы. Протоколы различных уровней в сетях, на шлюзах и на хост-компьютерах поддерживают систему коммуникаций между процессами, которая обеспечивает двунаправленный поток данных по логическим соединениям между портами процессов.

Термин пакет используется здесь в общем случае для обозначения порции данных, участвующей в отдельном элементарном акте взаимодействия между сетью и соединенным с ней хост-компьютером. В общем случае нас не будет касаться формат блоков данных, циркулирующих в сети.

С точки зрения коммуникационных сетей, хост-компьютеры - это компьютеры, связанные с сетью и являющиеся отправителями и получателями пакетов. Процессы рассматриваются как активные элементы на хост- компьютерах (согласно наиболее общему определению процессов как исполняющихся программ). Предполагается, что даже терминалы, файлы и другие устройства ввода-вывода взаимодействуют друг с другом посредством процессов. Таким образом, любые коммуникации рассматриваются как коммуникации между процессами.

Поскольку процесс может контролировать несколько коммуникационных потоков, ведущих от него к другому процессу (или другим процессам), то мы постулируем, что каждый процесс может иметь набор портов, через которые он общается с портами других процессов.

2.2 Модель действия

Процесс пересылает данные, вызывая программу протокола TCP и передавая ей в качестве аргументов буферы с данными. Протокол TCP пакует данные из этих буферов в сегменты, а затем вызывает модуль Internet для передачи каждого сегмента на программу протокола TCP, являющуюся адресатом. Этот адресат в свою очередь помещает данные из сегмента в буферы получателя и затем оповещает своего клиента о прибытии предназначенных ему данных. Программы протокола TCP помещают в сегменты контрольную информацию, которая затем используется ими для проверки очередности передачи данных.

Модель Internet коммуникаций состоит в том, что с каждой программой протокола TCP связан модуль протокола Internet, обеспечивающий ей интерфейс с локальной сетью. Данный модуль Internet помещает сегменты TCP в Internet датаграммы, а затем направляет их на другой Internet модуль или же промежуточный шлюз. Для передачи датаграммы по локальной сети она в свою очередь помещается в пакет соответствующего типа.

Коммутаторы пакетов могут осуществлять дальнейшую упаковку, фрагментацию или другие операции с тем, чтобы в локальной сети осуществить передачу пакетов по назначению на модуль Internet.

На шлюзах между локальными сетями датаграмма Internet освобождается от пакета локальной сети и исследуется с тем, чтобы определить, по какой сети она должна в дальнейшем идти. Затем Internet датаграмма упаковывается в пакет, соответствующий выбранной локальной сети, и посылается на следующий шлюз или же прямо к конечному получателю.

Шлюз имеет возможность разбивать Internet датаграмму на более мел кие датаграммы-фрагменты, если это необходимо для передачи по очередной локальной сети. Чтобы осуществить это, шлюз сам создает набор Internet датаграмм, помещая в каждую по одному фрагменты. В дальнейшем фрагменты могут быть снова разбиты следующими шлюзами на еще более мелкие части. Формат фрагмента Internet датаграммы спроектирован так, чтобы адресат - модуль Internet смог собрать фрагменты снова в исходные Internet датаграммы.

Internet модуль, являющийся адресатом, выделяет сегмент из датаграммы (после ее сборки в случае необходимости) и затем передает его по назначению на программу протокола TCP.

Данная простая модель действия протокола зачастую замалчивает множество деталей. Одной из важных характеристик является тип сервиса. Этот признак дает указание шлюзу (или модулю Internet) о выборе параметров сервиса, которые должны использоваться при передаче датаграммы в очередной локальной сети. Приоритет датаграммы указывается среди информации о типе сервиса. Датаграммы также могут нести информацию о безопасности с тем, чтобы позволить хост-компьютерам и шлюзам, действующим в многоуровневой системе безопасности, подвергать проверке соответствующие датаграммы.

2.3 Программное обеспечение хост-компьютера

Предполагается, что программа протокола TCP является модулем операционной системы. Клиенты обращаются к протоколу TCP в значительной степени так же, как если бы они обращались к файловой системе. Сам протокол TCP может обращаться к другим функциям операционной системы, к примеру, для управления структурами данных. Предполагается, что собственно интерфейс с локальной сетью осуществляется драйвером устройства. Протокол TCP не обращается непосредственно к драйверам сетевых устройств, а вместо этого делает вызов для модуля Internet протокола, который в свою очередь и обращается к драйверу устройства.

Механизм протокола TCP не исключает его реализации на входном процессоре. Однако, при такой реализации протокол общения между входными процессорами должен обеспечивать средства для поддержки описанного в этом документе интерфейса между пользователем и протоколом TCP.

2.4 Интерфейсы

Для запросов со стороны пользователя к протоколу TCP интерфейс TCP/пользователь обеспечивает открытие и закрытие соединения, посылку и получение данных или же получение статуса соединения. Эти запросы похожи на другие запросы программы пользователя к операционной системе, например, на запросы открытия, чтения и закрытия файла.

Интерфейс между протоколами TCP и Internet поддерживает запросы на посылку и получение датаграмм, адресованных на модули TCP в хост- компьютерах в любом месте сети Internet. Рассматриваемые запросы имеют аргументы для указания адреса, типа сервиса, приоритета, безопасности, а также передачи другой управляющей информации.

2.5 Связь с другими протоколами

Нижеприведенная диаграмма иллюстрирует место протокола TCP в иерархии протоколов

Рис.2 Взаимосвязь протоколов

Предполагается, что протокол TCP будет в состоянии эффективно поддерживать протоколы более высокого уровня. Протокол TCP должен легко взаимодействовать с такими протоколами более высокого уровня, как ARPANET Telnet или AUDIN II THP to the TCP.

2.6 Надежные коммуникации

Поток данных, посылаемый на TCP соединение, принимается получателем надежно и в соответствующей очередности.

Передача осуществляется надежно благодаря использованию подтверждений и номеров очереди. Концептуально каждому октету данных присваивается номер очереди. Номер очереди для первого октета данных в сегменте передается вместе с этим сегментом и называется номером очереди для сегмента. Сегменты также несут номер подтверждения, который является номером для следующего ожидаемого октета данных, передаваемого в обратном направлении. Когда протокол TCP передает сегмент с данными, он помещает его копию в очередь повторной передачи и запускает таймер. Когда приходит подтверждение для этих данных, соответствующий сегмент удаляется из очереди. Если подтверждение не приходит до истечения срока, то сегмент посылается повторно.

Подтверждение протокола TCP не гарантирует, что данные достигли конечного получателя, а только то, что программа протокола TCP на компьютере у получателя берет на себя ответственность за это.

Для направления потока данных между программами протоколов TCP используется механизм управления потоками. Получающая программа протокола TCP сообщает "окно" посылающей программе. Данное окно указывает количество октетов (начиная с номера подтверждения), которое принимающая программа TCP готова в настоящий момент принять.

2.7 Установка соединения и его отмена

Чтобы идентифицировать отдельные потоки данных, поддерживаемые протоколом TCP, последний определяет идентификаторы портов. Поскольку идентификаторы портов выбираются каждой программой протокола TCP независимо, то они не будут уникальны. Чтобы обеспечить уникальность адресов для каждой программы протокола TCP, мы объединяем идентифицирующий эту программу Internet адрес и идентификатор порта. В результате получаем сокет, который будет уникален во всех локальных сетях, объединенных в единое целое.

Соединение полностью определяется парой сокетов на своих концах. Локальный сокет может принимать участие во многих соединениях с различными чужими сокетами. Соединение можно использовать для передачи данных в обоих направлениях, иными словами, оно является "полностью дуплексным".

Протокол TCP волен произвольным образом связывать порты с процессами. Однако при любой реализации протокола необходимо придерживаться нескольких основополагающих концепций. Должны присутствовать общеизвестные сокеты, которые протокол TCP ассоциирует исключительно с "соответствующими им" процессами. Мы представляем себе, как будто процессы могут "владеть" портами и что процессы могут инициировать соединения только с тех портов, которыми они владеют. (С точки зрения реализации протокола "владение" ограничивается хост-компьютером, однако мы можем представить себе команду пользователя по запросу порта (Request Port) или же метод выделения группы уникальных портов данному процессу, например посредством ассоциирования старших байтов в имени порта с данным процессом).

Соединение задается командой OPEN (открыть), сделанной с локального порта и имеющей аргументом чужой сокет. В ответ на такой запрос программа протокола TCP предоставляет имя локального (короткого) со единения. По этому имени пользователь адресуется к данному соединению при последующих вызовах. О соединениях следует помнить кое-какие вещи.

Мы предполагаем, что имеется некая структура данных, называемая блоком управления передачей (Transmission Control Block -TCB), предназначенная для сохранения описанной выше информации. Можно было бы реализовать протокол таким образом, чтобы локальное имя для соединения было бы указателем на структуру TCB последнего. Запрос OPEN указывает также, осуществляется ли соединение активным образом, или же происходит пассивное ожидание соединения извне.

Запрос на пассивное открытие соединения означает, что процесс ждет получения извне запросов на соединение, вместо того, чтобы пытаться самому установить его. Часто процесс, сделавший запрос на пассивное открытие, будет принимать запросы на соединение от любого другого процесса. В этом случае чужой сокет указывается как состоящий целиком из нулей, что означает неопределенность. Неопределенные чужие сокеты могут присутствовать лишь в командах пассивного открытия.

Сервисный процесс, желающий обслужить другие, неизвестные ему процессы, мог бы осуществить запрос на пассивное открытие с указанием неопределенного сокета. В этом случае соединение может быть установлено с любым процессом, запросившим соединения с этим локальным сокетом. Такая процедура будет полезна, если известно, что выбранный локальный сокет ассоциирован с определенным сервисом.

Общеизвестные сокеты представляют собой удобный механизм априорного привязывания адреса сокета с каким-либо стандартным сервисом. Например, процесс "сервер для программы Telnet" жестко связан с конкретным сокетом. Другие сокеты могут быть зарезервированы за передатчиком файлов, Remote Job Entry, текстовым генератором, эхо-сервером, а также Sink-процессами (последние три пункта связаны с обработкой текстов). Адрес сокета может быть зарезервирован для доступа к процедуре "просмотра", которая могла бы указывать сокет, через который можно было бы получить новообразованные услуги. Концепция общеизвестного сокета является частью TCP спецификации, однако собственно асоциирование сокетов с услугами выходит за рамки данного описания протокола (см. Документ [4]).

Процессы могут осуществлять пассивные открытия соединений и ждать, пока от других процессов придут соответствующие запросы на активное открытие, а протокол TCP проинформирует их об установлении соединения. Два процесса, сделавшие друг другу одновременно запросы на активное открытие, получат корректное соединение. Гибкость такого подхода становится критичной при поддержке распределенных вычислений, когда компоненты системы взаимодействуют друг с другом асинхронным образом.

Когда осуществляется подбор сокетов для локального запроса пассивного открытия и чужого запроса на активное открытие, то принципиальное значение имеют два случая. В первом случае местное пассивное открытие полностью определяет чужой сокет. При этом подбор должен осуществляться очень аккуратно. Во втором случае во время местного пассивного открытия чужой сокет не указывается. Тогда в принципе может быть установлено соединение с любых чужих сокетов. Во всех остальных случаях подбор сокетов имеет частичные ограничения.

Если на один и тот же местный сокет осуществлено несколько ждущих пассивных запросов на открытие (записанных в блоки TCB), и осуществляется извне активный запрос на открытие, то чужой активный сокет будет связываться с тем блоком TCB, где было указание именно на этот запросивший соединения сокет. И только если такого блока TCB не существует, выбор партнера осуществляется среди блоков TCB с неопределенным чужим сокетом.

Процедура установки соединения использует флаг управления синхронизацией (SYN) и трижды обменивается сообщениями. Такой обмен называется трехвариантным подтверждением [3].

Соединение инициируется при встрече пришедшего сегмента, несущего флаг синхронизации (SYN), и ждущей его записи в блоке TCB. И сегмент и запись создаются пришедшими от пользователей запросами на открытие. Соответствие местного и чужого сокетов устанавливается при инициализации соединения. Соединение признается установленным, когда номера очередей синхронизированы в обоих направлениях между сокетами.

Отмена соединения также включает обмен сегментами, несущими на этот раз управляющий флаг FIN.

2.8 Коммуникация данных

Набор данных, передаваемых по соединению, можно рассматривать как поток октетов. Пользователь, отправляющий данные, указывает при запросе по посылку, следует ли данные, отправляемые при этом запросе, немедленно проталкивать через сеть к получателю. Указание осуществляется установкой флага PUSH (проталкивание).

Программа протокола TCP может собирать данные, принимаемые от пользователя, а затем передавать их в сеть по своему усмотрению в виде сегментов. Если же выставлен запрос на проталкивание, то протокол должен передать все не отправленные ранее данные. Когда программа протокола TCP, принимающая данные, сталкивается с флагом проталкивания, ей не следует ожидать получения новых данных по сети до тех пор, пока уже имеющиеся данные не будут переданы ждущему их местному процессу.

Нет нужды привязывать функции проталкивания к границам сегмента. Данные, содержащиеся в каком-либо сегменте, могут быть результатом одного или нескольких запросов на посылку. Или же один запрос может породить несколько сегментов.

Целью функции проталкивания и флага PUSH является проталкивание данных через сеть от отправителя к получателю. Функция не осуществляет обработки самих данных.

Существует связь между функцией проталкивания и использованием буферов данных в интерфейсе между пользователем и протоколом TCP. Каждый раз, когда в буфер получателя приходят данные с флагом PUSH, содержимое этого буфера передается пользователю на обработку, даже если буфер и не был заполнен. Если приходящие данные заполняют буфер пользователя до того, как получена команда проталкивания, пользователю отправляется блок данных, соответствующий размеру буфера. Протокол TCP имеет также средства для сообщения получателю, что с некоторого момента он имеет дело со срочными данными. Протокол TCP не пытается определить, что именно пользователь делает со ждущими обработки срочными данными. Однако обычно предполагается, что получающий данные процесс будет предпринимать усилия для быстрой обработки срочных данных.

2.9 Приоритет и безопасность

Протокол TCP использует тип сервиса и опцию безопасности протокола Internet с тем, чтобы пользователям протокола TCP обеспечить приоритет и безопасность на каждом соединении. Не все модули протокола TCP обязательно будут действовать в многоуровневой системе обеспечения безопасности. Некоторые модули ограничиваются только обычными, неспецифическими соединениями, другие ограничиваются лишь первым уровнем безопасности и закрытости. Следовательно, некоторые реализации протокола TCP и услуг для пользователей могут использовать лишь часть многоуровневой системы безопасности.

Модули TCP, действующие в многоуровневой системе безопасности, должны адекватным образом выставлять в отсылаемых сегментах флаги безопасности и приоритета. Такие модули TCP должны также позволять своим клиентам или вышестоящим протоколам, таким как Telnet и THP, указывать требуемый уровень безопасности, закрытости и приоритета для устанавливаемых соединений.

2.10 Принцип устойчивости

Все реализации протокола TCP будут следовать общему принципу устойчивости: быть консервативным в своих действиях и предоставлять свободу для других.

3 Спецификация для функций протокола

3.1 Формат заголовка

Передача TCP сегментов осуществляется в виде Internet датаграмм. Заголовок датаграммы в Internet протоколе имеет несколько информационных полей, включая адреса отправляющего и принимающего хост- компьютеров [2]. Заголовок TCP следует за Internet заголовком и дополняет его информацией, специфической для TCP протокола. Такое деление допускает использование на уровне хост-компьютеров протоколов, иных нежели TCP.

Формат TCP заголовка

0     1     2     3     4     5     6     7     8     9     0     1     2     3     4     5     6     7     8     9     0     1     2     3     4     5     6     7     8     9     0     1
Source Port
   
Destination Port
Sequence Number
Acknowledgment Number
Data
Offset
   

Reserved
    U
R
G     A
C
K     P
S
H     P
S
T     S
Y
N     F
I
N    

Window
Checksum
   
Urgent Pointer
Options
   
Padding
Data

Рис. 3 Формат TCP заголовка

Отметим, что каждая метка указывает здесь место для соответствующего бита.

Source Port (порт отправителя) 16 бит
номер порта отправителя

Destination Port (порт получателя) 16 бит
номер порта получателя

Sequence Number (номер очереди) 32 бита
Номер очереди для первого октета данных в данном сегменте (за исключением тех случаев, когда присутствует флаг синхронизации SYN). Если же флаг SYN присутствует, то номер очереди является инициализационным (ISN), а номер первого октета данных - ISN+1.

Acknowledgment Number (номер подтверждения) 32 бита
Если установлен контрольный бит ACK, то это поле содержит следующий номер очереди, который отправитель данной датаграммы желает получить в обратном направлении. Номера подтверждения посылаются постоянно, как только соединение будет установлено.

Data Offset (смещение данных) 4 бита
Количество 32-битных слов в TCP заголовке. Указывает на начало поля данных. TCP заголовок всегда кончается на 32-битной границе слова, даже если он содержит опции.

Reserved 6 бит
Это резервное поле, должно быть заполнено нулями.

Control Bits (контрольные биты) 6 бит
Биты этого поля слева направо
URG:     поле срочного указателя задействовано
ACK:     поле подтверждения задействовано
PSH:     функция проталкивания
RST:     перезагрузка данного соединения
SYN:     синхронизация номеров очереди
FIN:     нет больше данных для передачи

Window (окно) 16 бит
Количество октетов данных, начиная с октета, чей номер указан в поле подтверждения. Количество октетов, получения которых ждет отправитель настоящего сегмента.

Checksum (контрольная сумма) 16 бит
Поле контрольной суммы - это 16-битное дополнение суммы всех 16- битных слов заголовка и текста. Если сегмент содержит в заголовке и тексте нечетное количество октетов, подлежащих учету в контрольной сумме, последний октет будет дополнен нулями справа с тем, чтобы образовать для предоставления контрольной сумме 16-битное слово. Возникший при таком выравнивании октет не передается вместе с сегментом по сети. Перед вычислением контрольной суммы поле этой суммы заполняется нулями.

Контрольная сумма, помимо всего прочего, учитывает 96 бит псевдозаголовка, который для внутреннего употребления ставится перед TCP заголовком. Этот псевдозаголовок содержит адрес отправителя, адрес получателя, протокол и длину TCP сегмента. Такой подход обеспечивает защиту протокола TCP от ошибшихся в маршруте сегментов. Эту информацию обрабатывает Internet протокол. Она передается через интерфейс протокол TCP/локальная сеть в качестве аргументов или результатов запросов от протокола TCP к протоколу IP.

Адрес отправителя
Адрес получателя
нули     PTCL     длина TCP

Длина TCP сегмента - это длина TCP заголовка и поля данных, измеренная в октетах. Это не является точным указанием количества передаваемых по сети октетов, она не учитывает 12 октетов псевдозаголовка, но тем не менее расчет этого параметра все же производится.

Urgent Pointer (срочный указатель) 16 бит
Это поле сообщает текущее значение срочного указателя. Последний является положительной величиной - смещением относительно номера очереди данного сегмента. Срочный указатель сообщает номер очереди для октета, следующего за срочными данными. Это поле интерпретируется только в том случае, когда в сегменте выставлен контрольный бит URG.

Options (опции) длина переменная
Опции могут располагаться в конце TCP заголовка, а их длина кратна 8 бит. Все опции учитываются при расчете контрольной суммы.

Опции могут начинаться с любого октета. Они могут иметь два формата:

    однооктетный тип опций;
    октет типа опции, октет длины опции и октеты данных рассматриваемой опции.

В октете длины опции учитываются октет типа опции, сам октет длины, а также все октеты с данными.

Заметим, что список опций может оказаться короче, чем можно указать в поле Data Offset. Место в заголовке, остающееся за опцией "End-of-Option", должно быть заполнено нулями. Протокол TCP должен быть готов обрабатывать все опции.

В настоящее время определены следующие опции:
Тип     Длина     Значение
0     -     конец списка опций
1     -     нет операций
2     4     максимальный размер сегмента

Определения указанных опций

Конец списка опций
00000000     тип 0

Этот код опции определяет конец списка опций. Конец списка может не совпадать с концом TCP заголовка, указанным в поле Data Offset.

Эта опция используется после всех опций, но не после каждой из них. Опцию необходимо использовать только в том случае, если иначе не будет совпадения с концом TCP заголовка.

Нет операций
00000001     тип 1

Опции этого типа могут ставиться между опциями. Целью при этом может служить выравнивание очередной опции по границе слова. Нет гарантии, что отправители будут использовать данную опцию. Поэтому получатели должны быть готовы обрабатывать опции, даже если они не будут начинаться на границе слова.

Максимальный размер сегмента
00000010     00000100     макс.разм.сегм.
тип 2     длина 4     .

Поле данных опции - 16 бит. Если опция присутствует в списке, то она указывает для программы протокола TCP максимальный размер получаемого сегмента, отправившей сегмент с этой опцией. Эту опцию следует посылать лишь при первоначальном запросе на установление соединения (т.е. в сегментах с установленным контрольным битом SYN). Если данная опция не была использована, ограничения на размер отсутствуют.

Padding (выравнивание) длина переменная Выравнивание TCP заголовка осуществляется с тем, чтобы убедиться в том, что TCP заголовок заканчивается, а поле данных сегмента начинается на 32-битной границе. Выравнивание выполняется нулями.

3.2 Терминология

Прежде чем мы сможем обсудить многие детали действия TCP протокола, нам необходимо ввести подробную терминологию. Для поддержания TCP соединения необходимо иметь несколько переменных. Мы решили, что эти переменные будут помещены в соответствующую запись - блок управления передачей (Transmission Control Block - TCB). Среди переменных блока TCB имеются номера местного и чужого сокетов, флаги безопасности и приоритета для данного соединения, указатели буферов посылки и получения, указатели текущего сегмента и очереди повторной посылки. Кроме всего этого в TCB имеются несколько переменных, имеющих отношение к номерам очередей отправителя и получателя.

Отправление
SND.UNA     посылка неподтверждена
SND.NXT     послать следующий сегмент
SND.WND     отправить окно
SND.UP     отправить срочный указатель
SND.WL1     номер очереди сегмента, использованный для обновления последнего окна
SND.WL2     номер подтверждения в сегменте, используемый для обновления последнего окна
ISS     первоначальный номер очереди отправления

Получение
RCV.NXT     - получить следующий сегмент
RCV.WND     - получить окно
RCV.UP     - получить срочный указатель
IRS     - первоначальный номер очереди получения

Нижеприведенные диаграммы могут помочь связать некоторые из этих переменных с местом в очереди

Очередь отправления

    старые номера очереди, которые получили подтверждение
    номера очереди для данных, не получивших подтверждения
    номера очереди, допущенные к новой передаче
    следующие номера очереди, чья передача еще не разрешена

Рис. 4 Очередь отправления

Окно отправления - это участок очереди, отмеченный меткой 3 на рисунке 4.

Очередь получения

    старые номера очереди, которые получили подтверждение
    номера очереди, допущенные к очередному этапу получения
    следующие номера очереди, еще не получившие разрешения

Рис. 5 Очередь получения

Окно получения - это участок очереди, отмеченный меткой 2 на рисунке 5.

В обсуждении также часто используются некоторые переменные, берущие свое значение из полей очередного сегмента.

Переменные для очередного сегмента
SEG.SEQ     номер очереди для сегмента
SEG.ACK     номер подтверждения для сегмента
SEG.LEN     длина сегмента
SEG.WND     окно для сегмента
SEG.UP     срочный указатель для сегмента
SEG.PRC     приоритет для сегмента

Соединение во время функционирования проходит через серии промежуточных состояний. Это состояния LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, а также фиктивное состояние CLOSED. Состояние CLOSED является фиктивным, поскольку оно представляет состояние, когда не существует блока TCP, а потому и нет соединения. Краткое описание состояний:

LISTEN     Ожидание запроса на соединение со стороны чужих портов и программ TCP
SYN-SENT     Ожидание парного запроса на установление соединения. С нашей стороны запрос уже сделан.
SYN-RECEIVED     Ожидание подтверждения после того, как запрос соединения уже принят и отправлен.
ESTABLISHED     Состояние открытого соединения, принимаемые данные можно представить пользователю. Это нормальное состояние соединения в фазе передачи данных.
FIN-WAIT-1     Ожидание запроса от чужой программы TCP, или подтверждения ранее отправленного запроса на закрытие соединения.
FIN-WAIT-2     Ожидание запроса на закрытие соединения со стороны чужой программы TCP.
CLOSE-WAIT     Ожидание запроса на закрытие соединения со стороны своего клиента.
CLOSING     Ожидание подтверждения со стороны чужой программы TCP запроса о закрытии соединения.
LAST-ACK     Ожидание запроса на закрытие соединения, ранее отправленного чужой программе TCP (запрос включал также подтверждение получения чужого запроса на закрытие соединения).
TIME-WAIT     Ожидание когда истечет достаточное количество времени и можно быть уверенным, что чужая программа TCP получила подтверждение своего запроса на закрытие соединения.
CLOSED     Состояние полного отсутствия соединения.

Соединение TCP переходит с одного состояния на другое в ответ на события. Событие - это запросы клиента (открытие, посылка, получение, закрытие, отказ, получение состояния соединения), приход сегментов, и особенно тех, которые содержат флаги SYN, ACK, RST и FIN, а также истечение выделенного времени.

Диаграмма состояний на рисунке 6 иллюстрирует лишь смену состояний, а также вызвавшие это события, производимые действия, но не адреса, условия ошибок, не действия, не связанные прямо с изменением состояния.

Более подробные сведения о действиях программы протокола TCP в ответ на события приведены в последней главе.

Замечание. Данная диаграмма является лишь сводной, но не должна восприниматься как полная спецификация.

3.3 Номер очереди

Основополагающей идеей в проектировании протокола является то, что каждый октет данных, посылаемый на TCP соединение, имеет номер очереди. Поскольку каждый октет пронумерован, то каждый из них может быть опознан. Приемлемый механизм опознания является накопительным, так что опознание номера X означает, что все октеты с предыдущими номерами уже получены. Этот механизм позволяет регистрировать появление дубликатов в условиях повторной передачи. Нумерация октетов в пределах сегмента осуществляется так, чтобы первый октет данных сразу вслед за заголовком имел наименьший номер, а следующие за ним октеты имели номера по возрастающей.

Важно помнить о том, что количество номеров для очереди, хоть и велико, но ограничено. Диапазон номеров - от 0 до 2**32-1. Поскольку набор ограничен, то все арифметические операции с номерами очередей должны осуществляться по модулю 2**32. Это совсем не означает всякий раз предварительную арифметическую проверку номеров очереди на попадание в диапазон от 2**32-1 до 0. В работе с модульной арифметикой есть некие тонкости, поэтому нужно аккуратно программировать сравнение столь больших величин. Так символ '=<' означает "меньше или равно" (по модулю 2**32).

Протокол TCP должен осуществлять следующие типы сравнения для номеров очереди:
(a)     является ли номер в подтверждении номером очереди для октетов, уже отправленных, но еще не получивших подтверждения;
(b)     получили ли все октеты в сегменте подтверждение своих номеров (т.е. следует ли удалить данный сегмент из очереди на повторную посылку);
(c)     содержит ли пришедший сегмент ожидаемые нами номера (т.е. "перекрывает" ли этот сегмент окно получателя).

В ответ на посылку данных протокол TCP будет получать их подтверждение. Для работы с полученным подтверждением необходимо уметь делать сравнение для
SND.UNA     самого старого из номеров, не имевших подтверждения,
SND.NXT     следующего номера очереди, ждущего посылки,
SEG.ACK     номера подтверждения, полученного от чужой принимающей программы TCP (следующего номера очереди, ожидаемого чужой программой TCP),
SEG.SEQ     номера очереди первого октета в сегменте,
SEG.LEN     количества октетов в поле данных сегмента (учитывая SYN и FIN),
SEG.SEQ+SEG.LEN-1     номера очереди последнего октета из сегмента.

Новое подтверждение (называемое "подтверждением приемлемости") - это подтверждение выполнимости неравенств
SND.UNA < SEG.ACK =< SND.NXT

Сегмент из очереди повторной посылки получает полное подтверждение, если сумма его номера в очереди и длины поля данных меньше или равна номеру подтверждения из пришедшего сегмента.

При получении данных необходимо производить операции сравнения для следующих величин:
RCV.NXT     следующий номер из очереди приходящих сегментов, а также левая или нижняя граница окна получения,
RCV.NXT+RCV.WND-1     номер очереди последнего сегмента, ожидаемого в приходящем сегменте, а также правая или верхняя граница окна получения,
SEG.SEQ     первый номер в очереди, принесенный пришедшим сегментом,
SEG.SEQ+SEG.LEN-1     последний номер в очереди, принесенный пришедшим сегментом.

Считается, что сегмент перекрывает часть разрешенных номеров в очереди получения, если
RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND или
RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND

Первая часть этого текста смотрит, попадает ли начало сегмента на окно, а вторая часть - попадает ли в окно задняя часть сегмента. Если выполняется какая-либо часть теста, то сегмент попадает в окно.

Действительность несколько сложнее. Выбирая окно нулевой длины или сегмент нулевой длины, мы получаем четыре варианта проверки на приемлемость для приходящих сегментов

длина
сегмента     окно
получения    
тест
0     0     SEG.SEQ = RCV.NXT
0     >0     RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
>0     0     неприемлемо
>0     >0     RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND или
RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND

Заметим, что когда окно, получения нулевое, никакие сегменты приниматься не будут за исключением ACK сегментов. Таким образом, протокол TCP может устанавливать нулевое окно получения при передаче данных и получении подтверждений. Однако даже когда окно получения нулевое, программа протокола TCP обязана обрабатывать поля RST и URG всех приходящих сегментов.

Мы получили преимущество данной схемы нумерации в том, что она допускает также защиту для определенной управляющей информации. Это достигается косвенным образом посредством включения некоторых контрольных флагов в очередь, так что они могут быть повторно посланы и подтверждены без сбоя (т.е. будет задействована одна или несколько копий).

Управляющая информация реально находится не в поле данных сегмента. Следовательно, мы должны принять правила косвенного присвоения номеров очереди сегментам управления. SYN и FIN являются единственными управляющими сигналами, приемлемыми для такой защиты, и они используются только при открытии и закрытии соединения. Для целей поддержания очередности, сигнал SYN рассматривается как стоящий перед первым действительным октетом данных в сегменте, куда оба они были помещены. В то же время FIN считается стоящим после последнего реального октета данных в сегменте. Длина сегмента (SEG.LEN) учитывает как данные, так и номера очереди, отведенные под управление. В случае, когда присутствует SYN, значение SEG.SEQ соответствует номеру в очереди для сигнала SYN.

Выбор первоначального номера для очереди

Протокол не накладывает ограничения на многократное повторное использование конкретного соединения. Соединение задается подбором пары сегментов. Новые запросы на установление какого-либо соединения будут рассматриваться как повторные реализации этого соединения. Вследствие такого подхода возникает следующая проблема: "Как протокол TCP отличает дубликаты сегментов, оставшиеся от предыдущей реализации этого соединения?" Эта проблема становится явной, если соединение быстро открывается и закрывается несколько раз подряд, или же если соединение прерывает свою работу с потерей информации, хранившейся в оперативной памяти компьютера, и затем устанавливается повторно.

Чтобы избежать сбоя, мы должны избегать использования сегментов данной реализации соединения, когда в сети еще присутствуют те же самые номера очереди, оставшиеся от предыдущей реализации соединения. Мы желаем застраховаться от этого, даже если программа протокола TCP даст сбой и потеряет всю информацию об используемых ею номерах очередей. При создании новых соединений применяется генератор первоначальных номеров очереди (ISN), который выбирает новые 32 битные значения ISN. Генератор привязан к 32-битным часам (вероятно, фиктивным), чье значение меняется каждые 4 микросекунды. Таким образом, полный цикл часов ISN составляет примерно 4.55 часа. Поскольку мы полагаем, что сегменты будут существовать в сети не более максимального времени жизни сегмента (Maximum Segment Lifetime - MSL), и что MSL меньше, чем 4.55 часа, то мы можем с основанием полагать, что номера ISN будут уникальны.

Для каждого соединения существует номер в очереди отправления и номер в очереди получения. Первоначальный номер в очереди отправления (ISS) выбирается программой TCP, посылающей данные в этой очереди, а первоначальный номер в очереди получения (IRS) выясняется во время установления соединения.

Во время установления или инициализации какого-либо соединения обе программы протокола TCP должны синхронизировать друг с другом первоначальные номера очередей. Это осуществляется посредством обмена сегментами, устанавливающими соединения, несущими контрольный бит, называемый "SYN" (for synchronize - для синхронизации), несущими исходные номера для очередей. Для краткости, сегменты, несущие бит SYN, также называются SYN сегментами. Следовательно, решение проблемы требует приемлемого механизма для подбора первоначального номера очереди и немногочисленных сигналов подтверждения при обмене номерами ISN.

Синхронизация требует, чтобы каждая сторона, участвующая в соединении, посылала свой собственный первоначальный номер очереди, а также получала подтверждение на это от напарника. Каждая сторона должна также получить первоначальный номер очереди от напарника и послать подтверждение.

1) A --> B сигнал SYN: мой номер очереди X
2) A <-- B сигнал ACK: ваш номер очереди X
3) A <-- B сигнал SYN: мой номер очереди Y
4) A --> B сигнал ACK: ваш номер очереди Y

Поскольку шаги 2 и 3 можно объединить в одно сообщение, последнее называется подтверждением трех путей (трех сообщений).

Подтверждение трех путей необходимо, поскольку номера очереди не привязываются к неким глобальным часам данной компьютерной сети, и программы TCP могут иметь различные механизмы для подбора номеров ISN. Получатель первого сигнала SYN не может знать, задержался ли этот сигнал и уже устарел, или это не так, даже если получатель не помнит последний номер очереди, использованный этим соединением (что тоже не всегда возможно). Так что он должен попросить отправителя проверить этот сигнал SYN. Подтверждение трех путей и преимущества хронометрированной схемы обсуждаются в статье [3].

Период молчания

Чтобы быть уверенным в том, что программа TCP не создает сегмента, несущего номер очереди, который уже используется старым сегментом, все еще "ходящим" по сети, программа TCP должна сохранять молчание по крайней мере в течении времени жизни сегмента (MSL) до тех пор, пока она не назначит какие-либо номера очереди при запуске или восстановлении после сбоя, когда записи в памяти для прежних номеров из очереди были потеряны. В данной спецификации MSL берется равным 2 минуты.

Это значение выбрано разработчиками и может быть изменено, если практика покажет необходимость в этом. Заметим, что если программа протокола в некотором смысле повторно инициализируется, но при этом в памяти остались применявшиеся ранее номера очереди, то в ожидании нужды нет; следует лишь убедиться в том, что новые рабочие номера очередей больше, чем применявшиеся ранее.

Концепция периода молчания в протоколе TCP

Данная спецификация ставит условие что компьютеры, потерпевшие крах с потерей всей информации о последних номерах очередей, передаваемых по открытым (т.е. не закрытым специальной командой) соединениям, будут воздерживаться от посылки каких-либо TCP сегментов в течении по крайней мере максимального времени жизни сегмента (Maximum Segment Lifetime - MSL) в системе Internet, чей частью и является данный хост. В последующих параграфах приводится объяснение для этой спецификации. Некоторые реализации протокола TCP могут нарушать соглашение о периоде молчания, рискуя при этом тем, что некоторые получатели в системе Internet будут воспринимать старые данные как новые, или новые данные будут отброшены словно дубликаты в действительности устаревших сегментов.

Программы протокола используют новые номер очереди всякий раз, когда какой-либо сегмент формируется и помещается на хосте в очередь отправления по сети. Процедура фиксирования дубликатов и алгоритм очереди в протоколе TCP полагаются на уникальное связывание данных сегмента с местом в очереди. Номера очереди не успевают пройти весь диапазон в 2**32 значения, прежде чем связанные с ними данные из отправленного сегмента получат подтверждение от получателя, а все копии-дубликаты упомянутого сегмента покинут сеть Internet. Без этого условия можно предположить, что двум отдельным TCP сегментам могут быть назначены одинаковые или перекрывающиеся номера, что вызовет проблему у получателя при определении, какие данные являются новыми, а какие устаревшими. Напомним, что каждый сегмент привязан как ко множеству следующих друг за другом номеров очереди, так и к имеющимся в этом сегменте октетам данных.

При обычных условиях программы TCP отслеживают текущий номер очереди, подлежащий отправке, а также самое старое из ожидаемый подтверждений, что позволяет избежать ошибочного использования номера очереди, прежде чем будет получено подтверждение от более раннего использования этого же номера. Одно это не гарантирует, что старые данные - дубликаты будут удалены из сети, поэтому номера очереди сделаны очень большими, чтобы уменьшить вероятность того, что странствующие по сети дубликаты вызовут сбой по прибытии. При скорости обмена 2 мегабайта/сек очереди в 2**32 октета хватает на 4.5 часа. Поскольку максимальное время жизни сегмента в сети вряд ли превышает несколько десятков секунд, это считается достаточной защитой для будущих сетей, даже если скорости передачи данных возрастут до десятков мегабит/сек.

При скорости 100 мегабит/сек один цикл использования всех номеров очереди составляет 5.4 минуты, что может быть достаточно мало, но еще остается приемлемым.

Однако основной механизм регистрации дублей и поддержания очередей может быть отменен, если программа протокола TCP, посылающая данные, не имеет места в памяти для хранения номеров в очереди, которые она использовала в последний раз для конкретного соединения. Например, если программа TCP при создании всех соединений начинает с номера очереди 0, то при сбое и повторном запуске программа TCP может повторно сформировать прежнее соединение (возможно, после анализа наполовину открытого соединения) и послать по нему пакеты, чьи номера в очереди полностью совпадают или лишь частично перекрывают номера пакетов, которые еще присутствуют в сети и были отправлены предыдущей реализацией этого же соединения. В отсутствие сведений о номерах очереди, прежде использовавшихся для передачи информации по данному конкретному соединению, спецификация протокола TCP рекомендует отправителю воздержаться на MSL секунд от посылки сегментов по этому со единению, что даст возможность сегментам, запущенным в сеть старой реализацией соединения, покинуть систему.

От этой проблемы не защищены даже те хост-компьютеры, которые могут отслеживать текущее время и использовать его при выборе исходных номеров очереди (т.е. даже если время используется для выбора исходного номера при реализации каждого нового соединения).

В качестве примера предположим, что соединение открыто со стартовым номером очереди S. Предположим также, что это соединение используется не столь часто и возможно, функция определения исходного номера очереди (ISN(t)) принимает значение (скажем, S1), равное номеру последнего сегмента, отправленного данной программой TCP, по этому конкретному соединению, Теперь предположим, что именно в этот момент хост-компьютер дал сбой, восстановился и устанавливает новую реализацию этого соединения. Первоначальный номер очереди при этом будет S1=ISN(t), а это последний номер очереди в старой реализации соединения! Если восстановление произойдет достаточно быстро, то старые дубликаты, созданные с номером очереди, близким к номеру S1, могут быть получены своим адресатом и обработаны так, как будто бы это новые пакеты в новой реализации соединения.

Проблема состоит в том, что хост-компьютер - получатель может не знать, как долго он был в состоянии сбоя и существуют ли еще в системе старые дубликаты, оставшиеся от прежних реализаций соединений.

Одним из путей решения этой проблемы является преднамеренная задержка в отправлении сегментов в течении времени MSL после восстановления вслед за крахом - это спецификация периода молчания. Хост-компьютеры, предпочитающие избегать паузы, рискуют получить проблему столкновения старых и новых пакетов на каком-либо адресате, пожелавшем не прибегать к периоду молчания.

Реализации протокола могут предложить пользователям TCP возможность выбора между ожиданием в соединениях после сбоя и несоблюдением периода молчания для любых соединений. Очевидно, что для тех программ, где пользователь выбрал режим ожидания, в действительности, в этом нет нужды после того, как компьютер был выключен по крайней мере MSL секунд.

Итак, каждый отправленный сегмент занимает один или несколько номеров в очереди ожидания. Номера, отведенные под сегмент, являются "занятыми" или "в работе", пока не истекут MSL секунд. При сбое определенное место в очереди в течении определенного времени продолжает оставаться занятым октетами из последнего отправленного сегмента. Если вскоре создается новое соединение и оно использует какие-либо номера из очереди в момент, когда ими еще пользуется сегмент из предыдущей реализации соединения, то следовательно эта область перекрывания номеров очередей может являться причиной проблем у получателя.

3.4 Установление соединения

"Подтверждение трех путей" - это процедура, используемая при установлении соединения. Эта процедура обычно инициируется программой протокола TCP в ответ на запрос другой программы TCP. Данная процедура также работает, если две программы TCP инициируют ее одновременно.