TCP — это протокол обеспечения надежности прямых соединений, созданный для многоуровневой иерархии протоколов, поддерживающих межсетевые приложения. Протокол TCP обеспечивает надежность коммуникаций между парами процессов на узлах, включенных в различные компьютерные коммуникационные сети, которые объединены в единую систему.
В отношении надежности протоколов более низкого уровня TCP предъявляет весьма скромные запросы. TCP предполагает, что он может получить простой, потенциально ненадежный сервис для своих датаграмм со стороны протоколов нижнего уровня. В принципе, протокол TCP должен быть работоспособен на большом наборе коммуникационных систем, начиная с кабельных соединений и кончая сетями с коммутацией пакетов или электрических цепей.
TCP занимает в многоуровневой архитектуре протоколов нишу непосредственно над IP, который позволяет протоколу TCP отправлять и получать сегменты информации переменной длины, заключенные в оболочку IP датаграмм. IP датаграмма предоставляет средства для адресации отправителя и получателя сегментов TCP в различных сетях. IP также осуществляет любую фрагментацию и сборку сегментов TCP, необходимую для осуществления передачи и доставки через множество сетей и промежуточных шлюзов. IP также обрабатывает информацию о приоритете, классификации безопасности, а также осуществляет разграничение TCP сегментов. Так что информация с помощью TCP может быть передана напрямую через множество сетей.
Протокол TCP взаимодействует с одной стороны с пользователем или прикладной программой, а с другой — с протоколом более низкого уровня, таким как IP.
Взаимодействие между протоколом TCP и протоколами более низкого уровня формализовано достаточно слабо, за исключением того, что должен существовать некий механизм, с помощью которого эти два уровня могут асинхронно обмениваться информацией друг с другом. Обычно полагают, что протокол нижнего уровня задает это взаимодействие. Протокол TCP спроектирован так, чтобы работать с весьма разнообразной средой объединенных компьютерных сетей. Поскольку в данном цикле работ рассматривается набор протоколов TCP/IP, то далее предполагается, что протокол более низкого уровня — это IP.
Чтобы обеспечить надежное и безопасное обслуживание в ненадежной коммуникационной среде, TCP должен решать задачи в следующих областях:
Ниже этот перечень рассматривается более подробно.
Протокол TCP способен передавать непрерывные потоки октетов между своими клиентами в обоих направлениях, пакуя некое количество октетов в сегменты для передачи через сеть. В общем случае протокол TCP решает по своему усмотрению, когда производить блокировку и передачу данных.
Иногда пользователям бывает необходимо убедиться в том, что все данные, переданные ими протоколу TCP, уже отправлены. Для этой цели определена функция проталкивания (PUSH). Чтобы убедиться в том, что данные, отправленные протоколу TCP, действительно переданы, отправитель указывает, что их следует протолкнуть к получателю.
Проталкивание приводит к тому, что программы протокола TCP сразу осуществляют отправление и, соответственно, получение остающихся данных. Правильно осуществленное проталкивание может быть невидимо для получателя, а сама функция проталкивания может не иметь маркера границы записи.
Протокол TCP должен иметь защиту от разрушения данных, потери, дублирования и нарушения очередности получения, вызываемых коммуникационной средой. Это достигается присвоением очередного номера каждому передаваемому октету, а также требованием подтверждения (ACK) от программы TCP, принимающей данные. Если подтверждения не получено в течении контрольного интервала времени, то данные посылаются повторно. Со стороны получателя номера очереди используются для восстановления очередности сегментов, которые могут быть получены в неправильном порядке, а также для ограничения возможности появления дубликатов.
Повреждения фиксируются посредством добавления к каждому передаваемому сегменту контрольной суммы, проверки ее при получении и последующей ликвидации дефектных сегментов.
До тех пор, пока программы протокола TCP продолжают функционировать корректно, а сеть не распалась полностью на составные части, ошибки пересылки не будут влиять на правильное получение данных. Протокол TCP защищает от ошибок коммуникационной среды.
Протокол TCP дает средства получателю управлять количеством данных, посылаемых ему отправителем. Это достигается возвратом так называемого «окна» (window) вместе с каждым подтверждением, которое указывает диапазон приемлемых номеров, следующих за номером последнего успешно принятого сегмента. Окно определяет количество октетов, которое отправитель может послать до получения дальнейших указаний.
Чтобы позволить на отдельно взятом узле многим процессам одновременно использовать коммуникационные возможности уровня TCP, протокол TCP предоставляет на каждом узле набор адресов или портов. Вместе с адресами сетей и узлов на коммуникационном уровне они образуют сокет (socket).
Каждое соединение уникальным образом идентифицируется парой сокетов. Таким образом, любой сокет может одновременно использоваться во многих соединениях.
Соотнесение портов и процессов осуществляется каждым узлом самостоятельно. Однако, для часто используемых процессов, таких как HTTP серверы или серверы электронной почты, используются фиксированные документированные порты.
Механизмы управления потоком и обеспечения достоверности, описанные выше, требуют, чтобы программы протокола TCP инициализировали и поддерживали определенную информацию о состоянии каждого потока данных. Набор такой информации, включающий сокеты, номера очереди, размеры окон, называется соединением. Каждое соединение уникальным образом идентифицируется парой сокетов на двух концах.
Если два процесса желают обмениваться информацией, соответствующие процессы протокола TCP должны сперва установить соединение, то есть инициализировать информацию о статусе на каждой стороне. По завершении обмена информацией соединение должно быть расторгнуто или закрыто, чтобы освободить ресурсы для предоставления другим пользователям.
Поскольку соединения должны устанавливаться между ненадежными узлами и через ненадежную коммуникационную среду, то во избежание ошибочной инициализации соединений используется механизм подтверждения связи с хронометрированными номерами очереди.
Пользователи протокола TCP могут затребовать для своего соединения приоритет и безопасность. Предусмотрены принимаемые по умолчанию характеристики соединений, когда такие параметры не требуются.
Коммуникационная среда состоит из узлов, включенных в сети, которые в свою очередь соединятся друг с другом через шлюзы.
TCP может применяться как в локальных так и в больших сетях, но в любом случае они должны основываться на технологии коммутации пакетов. Реальными агентами, создающими и потребляющими сообщения, циркулирующие в сети, являются процессы.
Термин пакет используется здесь в общем случае для обозначения порции данных, участвующей в отдельном элементарном акте взаимодействия между сетью и соединенным с ней узлами.
Cогласно наиболее общему определению процессов как исполняющихся программ, они рассматриваются как активные элементы на узлах. Говоря о TCP, любые коммуникации рассматриваются как коммуникации между процессами.
Поскольку процесс может контролировать несколько коммуникационных потоков, ведущих от него к другому процессу или процессам, каждый процесс может иметь набор портов, через которые он общается с портами других процессов.
Процесс пересылает данные, вызывая программу протокола TCP и передавая ей в качестве аргументов буферы с данными. Протокол TCP пакует данные из этих буферов в сегменты, а затем вызывает модуль IP для передачи каждого сегмента программе протокола TCP, являющейся адресатом. Этот адресат в свою очередь помещает данные из сегмента в буферы получателя и затем оповещает своего клиента о прибытии предназначенных ему данных. Программы протокола TCP помещают в сегменты контрольную информацию, которая затем используется ими для проверки очередности передачи данных.
Модель Internet коммуникаций состоит в том, что с каждой программой протокола TCP связан модуль IP, обеспечивающий ей интерфейс с локальной сетью. Данный модуль IP помещает сегменты TCP в IP датаграммы, а затем направляет их на другой IP модуль или на промежуточный шлюз. Для передачи датаграммы по локальной сети она в свою очередь помещается в пакет соответствующего типа.
Коммутаторы пакетов могут осуществлять дальнейшую упаковку, фрагментацию или другие операции с тем, чтобы в локальной сети осуществить передачу пакетов по назначению на модуль IP.
На шлюзах между локальными сетями датаграмма Internet освобождается от пакета локальной сети и исследуется с тем, чтобы определить, по какой сети она должна в дальнейшем идти. Затем IP датаграмма упаковывается в пакет, соответствующий выбранной локальной сети, и посылается на следующий шлюз или же прямо к конечному получателю.
Шлюз имеет возможность разбивать IP датаграмму на более мелкие датаграммы — фрагменты, если это необходимо для передачи по очередной локальной сети. Чтобы осуществить это, шлюз сам создает набор IP датаграмм, помещая в каждую по одному фрагменты. В дальнейшем фрагменты могут быть снова разбиты следующими шлюзами на еще более мелкие части. Формат фрагмента IP датаграммы спроектирован так, чтобы адресат — модуль IP смог собрать фрагменты снова в исходные IP датаграммы.
IP модуль, являющийся адресатом, выделяет сегмент из датаграммы, предварительно собрав ее в случае необходимости, и затем передает его по назначению на программу протокола TCP.
Поток данных, посылаемый на TCP соединение, принимается получателем гарантированно и в соответствующей очередности.
Гарантированная передача осуществляется благодаря использованию подтверждений и номеров очереди. Концептуально каждому октету данных присваивается номер очереди. Номер очереди для первого октета данных в сегменте передается вместе с этим сегментом и называется номером очереди для сегмента. Сегменты также несут номер подтверждения, который является номером для следующего ожидаемого октета данных, передаваемого в обратном направлении. Когда протокол TCP передает сегмент с данными, он помещает его копию в очередь повторной передачи и запускает таймер. Когда приходит подтверждение для этих данных, соответствующий сегмент удаляется из очереди. Если подтверждение не приходит до истечения срока, то сегмент посылается повторно.
Подтверждение протокола TCP не гарантирует, что данные достигли конечного получателя, оно гарантирует лишь, что программа протокола TCP на узле-получателе берет на себя ответственность за это.
Для направления потока данных между программами протоколов TCP используется механизм управления потоками. Получающая программа протокола TCP сообщает «окно» посылающей программе. Данное окно указывает количество октетов, начиная с номера подтверждения, которое принимающая программа TCP готова в настоящий момент принять.
Чтобы идентифицировать отдельные потоки данных, поддерживаемые протоколом TCP, последний определяет идентификаторы портов. Поскольку идентификаторы портов выбираются каждой программой протокола TCP независимо, то они не уникальны. Чтобы обеспечить уникальность адресов для каждой программы протокола TCP, объединяют идентифицирующий эту программу IP адрес и идентификатор порта. В результате получается сокет, который будет уникален во всех локальных сетях, объединенных в единое целое.
Соединение полностью определяется парой сокетов на своих концах. Отдельный сокет может принимать участие во многих соединениях с различными удаленными сокетами. Соединение можно использовать для передачи данных в обоих направлениях, иными словами, оно является полнодуплексным (full duplex).
Протокол TCP волен произвольным образом связывать порты с процессами. Однако все реализации протокола придерживаются нескольких основополагающих концепций:
Процедура соединения начинается после того, как для сокета был выполнен запрос на открытие.
Существуют два вида открытия соединения: пассивное и активное.
Запрос на пассивное открытие соединения означает, что процесс ждет получения извне запросов на соединение, вместо того, чтобы пытаться самому установить его. Часто процесс, сделавший запрос на пассивное открытие, будет принимать запросы на соединение от любого другого процесса. В этом случае чужой сокет указывается как состоящий целиком из нулей, что означает неопределенность. Неопределенные чужие сокеты могут присутствовать лишь в командах пассивного открытия.
Сервисный процесс, желающий обслужить другие, неизвестные ему процессы, должен осуществить запрос на пассивное открытие с указанием неопределенного сокета. В этом случае соединение может быть установлено с любым процессом, запросившим соединения с этим локальным сокетом. Именно так работает большинство стандартных TCP сервисов.
Общеизвестные порты представляют собой удобный механизм априорного привязывания адреса сокета к какиму-либо стандартному сервису. Например, процесс «Telnet сервер» жестко связан с портом 23.
Процессы могут осуществлять пассивные открытия соединений и ждать, пока от других процессов придут соответствующие запросы на активное открытие, а протокол TCP проинформирует их об установлении соединения. Два процесса, сделавшие друг другу одновременно запросы на активное открытие, получат корректное соединение. Гибкость такого подхода становится критичной при поддержке распределенных вычислений, когда компоненты системы взаимодействуют друг с другом асинхронным образом.
Когда осуществляется подбор сокетов для локального запроса пассивного открытия и чужого запроса на активное открытие, то принципиальное значение имеют два случая. В первом случае местное пассивное открытие полностью определяет чужой сокет. При этом подбор должен осуществляться очень аккуратно. Во втором случае во время местного пассивного открытия чужой сокет не указывается. Тогда в принципе может быть установлено соединение с любых чужих сокетов. Во всех остальных случаях подбор сокетов имеет частичные ограничения.
Если на один и тот же местный сокет осуществлено несколько ждущих пассивных запросов на открытие, записанных в TCB, и осуществляется извне активный запрос на открытие, то чужой активный сокет будет связываться с тем блоком TCB, где было указание именно на этот запросивший соединения сокет. И только если такого блока TCB не существует, выбор партнера осуществляется среди блоков TCB с неопределенным чужим сокетом.
Процедура установки соединения использует флаг управления синхронизацией (SYN) и трижды обменивается сообщениями. Такой обмен называется трехвариантным подтверждением.
Соединение инициируется при встрече пришедшего сегмента, несущего флаг синхронизации (SYN), и ждущей его записи в TCB. И сегмент и запись создаются пришедшими от пользователей запросами на открытие. Соответствие местного и чужого сокетов устанавливается при инициализации соединения. Соединение признается установленным, когда номера очередей синхронизированы в обоих направлениях между сокетами.
Отмена соединения также включает обмен сегментами, несущими на этот раз управляющий флаг FIN.
Набор данных, передаваемых по соединению, можно рассматривать как поток октетов. Пользователь, отправляющий данные, указывает при запросе на посылку, следует ли данные, отправляемые при этом запросе, немедленно доставлять получателю немедленно. Указание осуществляется установкой флага PUSH (проталкивание).
Реализация TCP может собирать данные, принимаемые от пользователя, а затем передавать их в сеть по своему усмотрению в виде сегментов. Если же выставлен запрос на немедленную доставку, то протокол должен передать все не отправленные ранее данные. Когда программа протокола TCP, принимающая данные, сталкивается с флагом немедленной доставки, ей не следует ожидать получения новых данных по сети до тех пор, пока уже имеющиеся данные не будут переданы ждущему их местному процессу.
Нет нужды привязывать функции немедленной доставки к границам сегмента. Данные, содержащиеся в каком-либо сегменте, могут быть результатом одного или нескольких запросов на посылку. Или же один запрос может породить несколько сегментов.
Существует связь между функцией немедленной доставки и использованием буферов данных в конкретной реализации TCP. Каждый раз, когда в буфер получателя приходят данные с флагом PUSH, содержимое этого буфера передается пользователю на обработку, даже если буфер и не был заполнен. Если приходящие данные заполняют буфер пользователя до того, как получена команда срочной доставки, пользователю отправляется блок данных, соответствующий размеру буфера. Протокол TCP имеет также средства для сообщения получателю, что с некоторого момента он имеет дело со срочными данными. Протокол TCP не пытается определить, что именно пользователь делает со ждущими обработки срочными данными. Однако обычно предполагается, что получающий данные процесс будет предпринимать усилия для быстрой обработки таких данных.
Протокол TCP не имеет встроенных средств обеспечения безопасности и установки приоритетов, в общем случае для этого он использует возможности IP.
Передача TCP сегментов осуществляется в виде IP датаграмм. Заголовок датаграммы в IP имеет несколько информационных полей, включая адреса отправляющего и принимающего узлов. Заголовок TCP следует за IP заголовком и дополняет его информацией, специфичной для 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 |
R S T |
S Y N |
F I N |
Window | |||||||||||||||||||||||
| Checksum | Urgent Pointer | ||||||||||||||||||||||||||||||
| Options | Padding | ||||||||||||||||||||||||||||||
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 бит.
Биты этого поля слева направо:
Window (окно) 16 бит.
Количество октетов данных, начиная с октета, чей номер указан в поле подтверждения. Количество октетов, получения которых ждет отправитель настоящего сегмента.
Checksum (контрольная сумма) 16 бит.
Контрольная сумма, помимо всего прочего, учитывает 96 бит псевдозаголовка, который для внутреннего употребления ставится перед TCP заголовком. Этот псевдозаголовок содержит адрес отправителя, адрес получателя, протокол и длину TCP сегмента. Такой подход обеспечивает защиту протокола TCP от ошибшихся в маршруте сегментов. Эту информацию обрабатывает IP.
Urgent Pointer (срочный указатель) 16 бит.
Это поле сообщает текущее значение срочного указателя. Последний является положительной величиной — смещением относительно номера очереди данного сегмента. Срочный указатель сообщает номер очереди для октета, следующего за срочными данными. Это поле интерпретируется только в том случае, когда в сегменте выставлен контрольный бит URG.
Options (опции) поле переменной длины.
Опции могут располагаться в конце TCP заголовка, а их длина кратна 8 бит. Все опции учитываются при расчете контрольной суммы.
Битовая последовательность 00000000 определяет окончание поля опций. Окончание поля опций может не совпадать с концом TCP заголовка, указанным в поле Data Offset. В этом случае, оставшееся место в заголовке должно быть заполнено нулями.
Соединение за время функционирования проходит через серии промежуточных состояний. Это состояния LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, а также фиктивное состояние CLOSED. Состояние CLOSED является фиктивным, поскольку оно представляет состояние, когда не существует блока TCB, а потому нет и соединения.
В следующей таблице приведены состояния 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, а также истечение выделенного времени.
Следующая диаграмма иллюстрирует смену состояний.
Основополагающей идеей в проектировании протокола является то, что каждый октет данных, посылаемый на TCP соединение, имеет номер очереди. Поскольку каждый октет пронумерован, то каждый из них может быть опознан. Приемлемый механизм опознания является накопительным, так что опознание номера X означает, что все октеты с предыдущими номерами уже получены. Этот механизм позволяет регистрировать появление дубликатов в условиях повторной передачи. Нумерация октетов в пределах сегмента осуществляется так, чтобы первый октет данных сразу вслед за заголовком имел наименьший номер, а следующие за ним октеты имели номера по возрастающей.
Протокол TCP должен осуществлять следующие типы сравнения для номеров очереди:
Во время установления или инициализации какого-либо соединения обе программы протокола TCP должны синхронизировать друг с другом первоначальные номера очередей. Это осуществляется посредством обмена сегментами, устанавливающими соединения, несущими контрольный бит SYN (for synchronize — для синхронизации), несущими исходные номера для очередей. Для краткости, сегменты, несущие бит SYN, также называются SYN сегментами. Следовательно, решение проблемы требует приемлемого механизма для подбора первоначального номера очереди и немногочисленных сигналов подтверждения при обмене номерами ISN.
Синхронизация требует, чтобы каждая сторона, участвующая в соединении, посылала свой собственный первоначальный номер очереди, а также получала подтверждение на это от напарника. Каждая сторона должна также получить первоначальный номер очереди от напарника и послать подтверждение.
Поскольку шаги 2 и 3 можно объединить в одно сообщение, такая процедура называется трехвариантным подтверждением.
Для установки соединения используется процедура трехвариантного подтверждения, описанная выше. Эта процедура обычно инициируется программой протокола TCP в ответ на запрос другой программы TCP. Данная процедура также работает, если две программы TCP инициируют ее одновременно. Когда попытка инициализации осуществляется с обоих концов одновременно, каждая программа протокола TCP получает SYN-сегмент, который не несет подтверждения для уже отправленного ею SYN. Конечно, прибытие старых дубликатов SYN-сегмента может произвести создать у получателя ложное впечатление, будто осуществляется одновременное открытие соединения. Корректно обрабатывать такие ситуации помогает импользование RST-сегментов.
Ниже приведен пример простейшей процедуры трехвариантного подтверждения. Процедура именно такого вида в подавляющем большинстве случаев используется на практике.
| Состояние стороны A | TCP сегмент | Состояние стороны B | ||||
| Направление пересылки | Номер очереди | Номер подтверждения | Флаги | Содержит ли данные | ||
| CLOSED | Состояние до обмена данными | LISTEN | ||||
| SYN-SENT | от A к B | 100 | нет | SYN | нет | SYN-RECEIVED |
| ESTABLISHED | от B к A | 300 | 101 | SYN, ACK | нет | SYN-RECEIVED |
| ESTABLISHED | от A к B | 101 | 301 | ACK | нет | ESTABLISHED |
| ESTABLISHED | от A к B | 101 | 301 | ACK | да | ESTABLISHED |
В приведенном примере на строке 2 программа сторона A начинает с посылки сигнала SYN, показывая тем самым, что она будет использовать номера очереди, начиная с номера 100. На строке 3 сторона B посылает сигнал SYN, а также подтверждение о том, что сигнал SYN от стороны A получен. Поле подтверждения информирует о том, что сторона B в данный момент ожидает получение номера 101.
На строке 4 для отправленного стороной B в строке 3 сигнала SYN сторона A дает ответ с помощью пустого сегмента, содержащего сигнал ACK. В строке 5 сторона A передает по сети уже некую порцию данных. Заметим, что сегмент в строке 5 имеет тот же номер очереди, что был у сегмента в строке 4, поскольку сигнал ACK в очереди места не занимает, если бы это было не так, необходимо бы было подтверждение ACK для самого подтверждения.
В тех случаях, когда при установке соединения некорректная передача сегментов по сети приводит к получению одной из сторон сегмента с флагом, не соответствующим ее текущему состоянию, эта сторона посытает RST-сегмент, что приводит к переходу второй стороны в состояние LISTEN или CLOSED.
Состояние CLOSED означает «я не имею данных для передачи». Конечно, закрытие полнодуплексного соединения является предметом множества интерпретаций, поскольку не очевидно, как интерпретировать в соединении сторону, получающую информацию. В случае же TCP клиент, находящийся в состоянии CLOSED, еще может получать информацию до тех пор, пока другая сторона также не сообщит, что переходит в состояние CLOSED. Каждая сторона гарантированно получит все буферы с информацией, отправленные до того, как соединение было закрыто. Поэтому клиенту, не ждущему информации с соединения, следует лишь ждать сообщения об успешном закрытии этого соединения, что означает, что все данные получены стороной, принимающей информацию. Клиенты должны сохранять уже закрытые ими для чтения информации соединения до тех пор, пока программа протокола TCP не сообщит им, что такой информации больше нет.
Существет три основных сценария закрытия соединения:
В этом случае создается FIN-сегмент и помещается в очередь сегментов, ждущих отправления. После этого программа TCP уже не будет принимать от этого клиента каких-либо команд на отправку данных по закрытому соединению, а сама переходит в состояние FIN-WAIT-1. Тем не менее, в этом состоянии еще возможно получение клиентом данных с этого соединения. Все сегменты, стоящие в очереди, и сам сегмент с сигналом FIN будут в случае необходимости посылаться другой стороне вновь и вновь, пока не получат своего подтверждения.
Когда программа TCP партнера подтвердит получение сигнала FIN, и сама отправит в ответ свой сигнал FIN, местная программа может подтвердить получение последнего. Программа TCP, получающая сигнал FIN, будет подтверждать его, но не будет посылать своего собственного сигнала FIN до тех пор, пока ее клиент тоже не закроет соединения.
Когда от удаленной стороны приходит FIN-сегмент, принимающая его программа TCP может подтвердить получение такого сигнала и оповестить своего клиента о том, что соединение закрыто. Клиент ответит командой CLOSE, по факту которой программа TCP может после пересылки оставшихся данных послать удаленной стороне свой FIN-сегмент. После этого программа TCP ждет, пока не придет подтверждение на отправленный ею сигнал FIN, после чего она ликвидирует соединение. Если подтверждения не было по истечении отведенного времени, то соединение ликвидируется в принудительном порядке, о чем сообщается клиенту.
Одновременное закрытие соединения клиентами на обоих концах приводит к обмену FIN-сегментами. Когда все сегменты, стоящие в очереди перед сегментом с FIN, будут переданы и получат подтверждение, каждая сторона может послать подтверждение на полученный ею сигнал FIN. Обе программы по получении этих подтверждений ликвидируют соединение.
После того, как соединение было установлено, передача данных осуществляется с помощью обмена сегментами. Так как сегменты могут быть потеряны в результате ошибок или перегрузки сети, стороны использует механизм повторной посылки по истечении определенного времени с тем, чтобы убедиться в получении каждого сегмента.
Отправитель данных отслеживает следующий номер в очереди, подлежащий отправке. Получатель данных отслеживает следующий номер, прибытие которого он ожидает, а так же значение самого старого номера, который был отправлен, но еще не получил подтверждения. Когда поток данных иссякает, а все отправленные данные получают подтверждение, эти переменные имеют одинаковое значение.
Поскольку соединения находятся в состоянии ESTABLISHED, все сегменты, в дополнение к данным, несут информацию о подтверждении ранее отправленных сегментов.
Механизм срочной передачи протокола TCP предназначен для того, чтобы клиент, отправляющий данные, мог побудить получателя принять некую срочную информацию, а также позволить программе TCP, принимающей данные, информировать своего клиента, когда вся имеющаяся на настоящий момент информация будет получена.
Данный механизм позволяет помечать некую точку в потоке данных как конец блока срочной информации. Когда в программе TCP, принимающей данные, данная точка окажется впереди индикатора номера в очереди получения, эта программа TCP должна дать команду своему клиенту перейти в «срочный режим». Когда номер в очереди получения догонит срочный указатель в потоке данных, программа TCP должна дать команду клиенту прийти в «нормальный режим». Если срочный указатель сменит свое положение, когда клиент находится в «срочном режиме», последний не узнает об этом.
Данный метод использует поле флага срочности, который присутствует во всех передаваемых сегментах. Единица в поле контрольного флага URG означает, что задействовано поле срочности. Чтобы получить указатель этого поля в потоке данных, необходимо дополнить его номером рассматриваемого сегмента в очереди. Отсутствие флага URG означает отсутствие у отправителя не посланных срочных данных.
При указании срочности клиент должен также послать по крайней мере один октет данных. Если клиент, помещающий данные, дополнительно закажет функцию проталкивания (флаг PSH), то передача срочной информации ждущему ее процессу многократно ускорится.
Окно, посылаемое с каждым сегментом, указывает диапазон номеров очереди, которые отправитель окна, он же получатель данных, готов принять в настоящее время. Предполагается, что такой механизм связан с наличием в данный момент места в буфере данных.
Указание окна большого размера стимулирует передачу. Но если пришло большее количество данных, чем может быть принято программой TCP, данные будут отброшены. Это приведет к излишним пересылкам информации и ненужному увеличению нагрузки на сеть. Указание окна малого размера может ограничить передачу данных скоростью, которая определяется временем путешествия по сети после каждого посылаемого сегмента.
TCB — блок управления передачей (Transmission Control Block).
Термин TCB веден в спецификации TCP и представляет собой структуру, содержащую следующие данные:
Теоретическая часть построена на основе: