Андрей Робачевский - Операционная система UNIX

В качестве примера рассмотрим передачу данных между двумя хостами сети А и В, проиллюстрированную на рис. 6.13. Для простоты предположим симплексную передачу большого количества данных от хоста А к B. Начиная с SEQ=100хост А посылает хосту В 200 октетов. Первый посланный сегмент ( SEQ=300) доставлен без ошибок и подтвержден хостом В ( ACK=301). Следующий сегмент передан с ошибкой и не доставлен получателю. Таким образом, хост А не получает подтверждения на второй сегмент и повторно посылает его после определенного тайм-аута. [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, направленные на повышение его производительности.