Операционная система UNIX
Шрифт:
Расшифровка состояний приведена в табл. 6.5.
Таблица 6.5. Состояния TCP-сеанса
| Состояние | Описание |
|---|---|
| LISTEN | Готовность узла к получению запроса на соединение от любого удаленного узла. |
| SYN-SENT | Ожидание ответного запроса на соединение. |
| SYN-RECEIVED | Ожидание подтверждения получения ответного запроса на соединение. |
| ESTABLISHED | Состояние канала, при котором возможен дуплексный обмен данными между клиентом и сервером. |
| CLOSE-WAIT | Ожидание запроса на окончание связи от локального процесса, использующего данный коммуникационный узел. |
| LAST-ACK | Ожидание
|
| FIN-WAIT-1 | Ожидание подтверждения запроса на окончание связи, отправленного удаленному узлу (инициирующий запрос, канал переходит в симплексный режим). |
| FIN-WAIT-2 | Ожидание запроса на окончание связи от удаленного узла |
| CLOSING | Ожидание подтверждения от удаленного узла на запрос окончания связи. |
| TIME-WAIT | Таймаут перед окончательным разрушением канала, достаточный для того, чтобы удаленный узел получил подтверждение своего запроса окончания связи. Величина тайм-аута составляет 2 MSL (Maximum Segment Lifetime). [73] |
| CLOSED | Фиктивное состояние, при котором коммуникационный узел и канал фактически не существуют. |
73
Значение MSL, рекомендованное в RFC 793 "Transmission Control Protocol", составляет 2 минуты. Однако в реальных системах типичными значениями MSL являются 30 секунд, 1 или 2 минуты.
Для обеспечения правильной обработки данных для каждого логического TCP-канала хранится полная информация о его состоянии, различных таймерах и о текущих порядковых номерах переданных и принятых октетов. Это необходимо, например, для корректной обработки служебных сегментов
Передача данных
После создания виртуального канала взаимодействующие процессы получают возможность обмениваться данными в дуплексном режиме.
74
Эта информация представлена соответствующими структурами данных, называемыми TCB (Transmission Control Block). Как правило, коммуникационный узел, представляющий сетевой интерфейс для взаимодействующих процессов, хранит указатель на эти управляющие данные. Более подробно архитектура сетевых интерфейсов UNIX описана в следующих разделах.
Хотя фактически передача данных осуществляется в виде сегментов, ее логический вид представляет собой последовательный поток октетов, каждый из которых адресуется порядковым номером. Каждый сегмент хранит в заголовке порядковый номер первого октета данных. Данные буферизуются обоими коммуникационными узлами TCP-канала. Как правило, модуль TCP самостоятельно принимает решение, когда именно сформировать сегмент для отправки и когда передать полученные данные процессу- адресату.
В случае, когда требуется немедленная передача данных, без ожидания заполнения сегмента определенного размера, протокол верхнего уровня (приложение) устанавливает флаг
Как уже говорилось, протокол TCP обеспечивает надежный последовательный виртуальный канал передачи данных между приложениями. Поскольку нижележащий сетевой протокол IP является по определению ненадежным, а среда передачи вносит дополнительные ошибки, переданные данные могут быть утеряны, продублированы или испорчены, при этом порядок их доставки может быть нарушен. В случае ошибочности полученного сегмента модуль TCP узнает об этом, проверив контрольную сумму. Другие ошибки являются более сложными, и TCP должен обеспечить их определение и исправление.
Рассмотренные выше порядковый номер и номер подтверждения играют ключевую роль в обеспечении надежности доставки. По существу порядковый номер адресует каждый октет логического потока данных между источником и получателем, позволяя последнему определить правильность доставки (порядок доставки и потерю отдельных октетов). TCP является протоколом с позитивным подтверждением и повторной передачей (Positive Acknowledgement and Retransmission, PAR). Это означает, что если данные доставлены без ошибок, получатель подтверждает это сегментом
В качестве примера рассмотрим передачу данных между двумя хостами сети А и В, проиллюстрированную на рис. 6.13. Для простоты предположим симплексную передачу большого количества данных от хоста А к B. Начиная с
75
На самом деле ситуация, скорее всего, окажется более печальной, поскольку хост А продолжит отправку последующих сегментов в пределах окна отправки, не дожидаясь подтверждений. Не получив подтверждения на второй сегмент, хост А по таймауту вынужден будет повторно передать все сегменты, начиная со второго. Более подробно мы рассмотрим этот аспект в разделе "Стратегии реализации TCP" далее в этой главе.
Рис. 6.13. Повторная передача
Говоря об управлении потоком данных, следует отметить, что TCP представляет собой протокол со скользящим окном. Окно определяет объем данных, который может быть послан (send window — окно передачи) или получен (receive window — окно приема) TCP-модулем. Размеры окон фактически отражают состояние буферов приема коммуникационных узлов. Так окно приема свидетельствует о количестве данных, которое принимающая сторона готова получить, а окно передачи определяет количество данных, которое отправителю позволяется послать, не ожидая подтверждения о получении. Несомненно, между этими двумя параметрами существует связь — окно передачи одного узла отражает состояние буферов другого (его окно приема) и наоборот. Принимающая сторона имеет возможность изменять окно передачи отправителя (с помощью подтверждения или явного обновления значения окна в поле Window заголовка передаваемого сегмента), и, таким образом, регулировать трафик.
Интерпретация отправителем окна передачи показана на рис. 6.14. Размер окна передачи отправителя в данном случае покрывает с 4 по 8 байт. Это означает, что отправитель получил подтверждения на все байты, включая 3, а получатель анонсировал размер окна равным 5 байтам. Это также означает, что отправитель может еще передать 2 байта (7 и 8). По мере подтверждения получения данных окно будет смещаться вправо, открывая новые "горизонты" для передачи. Однако окно может изменять свои размеры, при этом имеет значение, смещение какого края окна (правого или левого) приводит к изменению размера.
Окно закрывается по мере смещения левого края вправо. Это происходит при отправлении данных.
Окно открывается по мере смещения правого края вправо. Это происходит в соответствии с освобождением буфера приема получателя данных.
Окно сжимается, когда правый край смещается влево. Хотя такое поведение не рекомендуется, модуль TCP должен быть готов к обработке этой ситуации.
Рис. 6.14. Окно передачи TCP
Если левый край окна достигает правого, размер окна становится равным нулю, что запрещает дальнейшую передачу данных.
Суммируя вышесказанное, можно отметить, что размер окна, сообщаемый получателем данных отправителю, является предлагаемым окном (offered window), которое в простейшем случае равно размеру свободного места в буфере приема. При получении этого значения отправитель данных вычисляет фактическое, доступное для использования окно (usable window), которое равно предлагаемому за вычетом объема отправленных, но не подтвержденных данных. Таким образом, доступное для использования, или просто доступное, окно меньше или равно предлагаемому. Неэффективная стратегия подтверждений может привести к чрезвычайно малым значениям доступного окна и, как следствие, к низкой производительности передачи данных. Это явление, известное под названием синдром "глупого окна" (Silly Window Syndrome, SWS), будет рассмотрено ниже.
Стратегии реализации TCP
Рассмотренный стандарт протокола TCP определяет взаимодействие между удаленными объектами, достаточное для обеспечения совместимых реализаций. Другими словами, модуль протокола, в точности следующий спецификации стандарта, является гарантированно совместимым с модулями TCP, разработанными другими производителями. Тем не менее ряд вопросов функционирования протокола остается за рамками стандарта и допускает различные реализации, в конечном итоге влияющие не на совместимость, а на производительность приложений, использующих этот протокол. В данном разделе мы рассмотрим различные подходы к реализации TCP, направленные на повышение его производительности.