Транспортный протокол TCP

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

Таб. 7.8. Формат пакета TCP

Заголовок пакета TCP состоит из нескольких (обычно 6) 32-х битных слов, и в этом похож на формат дейтаграммы IP. Поясним значение некоторых полей:

• Порядковый номер первого октета в сегменте необходим для определения места пакета для сборки блока переданных данных после сегментации (если она была проведена перед передачей).
• Номер подтверждения содержит значение следующего порядкового номера, который отправитель сегмента рассчитывает получить.
• Смещение данных - 4-х битовое поле, указывающее число 32-х битовых слов в заголовке пакета, или начало поля данных.
• Резерв - зарезервированное поле размером в 6 бит.
• Поле флагов управления. U (URG) - значимое поле указателя важности, A (ACK) - значимое поле подтверждения, P (PSH) - функция push, R (RST) - сброс соединения, F (FIN) - нет данных от отправителя.
• Окно, это 16-битовое поле, которое содержит число октетов данных, которые отправитель данного сегмента будет отправлять без немедленного подтверждения доставки. Отсчет ведется, начиная с октета, указанного в поле номер подтверждения.
• Уровень важности - значение смещения до октета, с которого начинаются важные (urgent) данные. Разумеется, поле принимается во внимание только для пакетов с установленным флагом "U".

Различия в величине заголовка пакета TCP и дейтаграммы UDP сразу обращают на себя внимание. Объяснение кроется в сложности обеспечения гарантированной и эффективной доставки (да еще и с заданным уровнем качества). Для этого можно использовать метод квитирования с повторной передачей.

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

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

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

От размера окна очень много зависит, но его выбор - не слишком тривиальная задача. На практике алгоритм пошел немного "от противного", не от максимальной скорости передачи. Каждое сообщение подтверждения доставки пакета содержит значение размера окна, которое может быть предоставлено принимающим узлом (window advertisement). Обычно, оно определяется размером свободного в данный момент буфера принимающего адаптера.

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

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

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

Чем более высокий уровень OSI используется, тем больше возможностей предоставляют протоколы для управления. Описать их все - большая, но отдельная задача. Поэтому, рассматривать сеансовый и более высокие уровни (или уровень приложений стека TCP/IP) в рамках данной главы не целесообразно. Разумеется, необходимые для работы простых сетей протоколы (такие как NetBios, DNS, FTP, Telnet, http) будут описаны в следующих главах.

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

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