Читаем без скачивания TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) - Сидни Фейт

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

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

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

Не менее важно исключение синдрома "бестолкового окна" и применение алгоритмов Джекобсона, Керна и Партриджа (эти интересные алгоритмы будут рассмотрены ниже).

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

10.13 Алгоритмы повышения производительности

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

■ Медленный старт (slow start) мешает использованию большой доли сетевого трафика для нового сеанса, что может привести к непроизводительным потерям.

■ Излечение от синдрома "бестолкового окна" (silly window syndrome) предохраняет плохо разработанные приложения от перегрузки сети сообщениями.

■ Задержанный ACK (delayed ACK) снижает перегрузку посредством сокращения количества независимых сообщений подтверждения пересылки данных.

■ Вычисляемый тайм-аут повторной пересылки (computing retransmission timeout) основывается на согласовании реального времени сеанса, уменьшая объем ненужных повторных пересылок, но при этом не вызывает больших задержек для реально необходимых обменов данными.

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

■ Отправка дублированных ACK (duplicate ACK) при получении сегмента вне последовательности отправки позволяет партнерам выполнить повторную пересылку до наступления тайм-аута.

10.13.1 Медленный старт

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

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

Нагрузочное окно (congestion window) начинается с размера в 1 сегмент. Для каждого сегмента с успешно полученным ACK размер нагрузочного окна увеличивается на 1 сегмент, пока оно остается меньше, чем приемное окно. Если сеть не перегружена, нагрузочное окно постепенно достигнет размера приемного окна. При нормальном состоянии пересылки размеры этих окон будут совпадать.

Отметим, что медленный старт — не такой уж и медленный. После первого ACK размер нагрузочного окна равен 2-м сегментам, а после успешного получения ACK для двух сегментов размер может увеличиться до 8 сегментов. Другими словами, размер окна увеличивается экспоненциально.

Предположим, что вместо получения ACK возникла ситуация тайм-аута. Поведение нагрузочного окна в таком случае рассматривается ниже.

10.13.2 Синдром "бестолкового окна"

В первых реализациях TCP/IP разработчики столкнулись с феноменом синдрома "бестолкового окна" (Silly Window Syndrome — SWS), который проявлялся достаточно часто. Для понимания происходящих событий рассмотрим следующий сценарий, приводящий к нежелательным последствиям, но вполне возможный:

1. Передающее приложение быстро отсылает данные.

2. Принимающее приложение читает из входного буфера по 1 байту данных (т.е. медленно).

3. Входной буфер после чтения быстро заполняется.

4. Принимающее приложение читает 1 байт, и TCP отправляет ACK, означающий "Я имею свободное место для 1 байта данных".

5. Передающее приложение отправляет по сети пакет TCP из 1 байта.

6. Принимающий TCP посылает ACK, означающий "Спасибо. Я получил пакет и не имею больше свободного места".

7. Принимающее приложение опять читает 1 байт и отправляет ACK, и весь процесс повторяется.

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

Реальные ситуации, конечно, не столь экстремальны. Быстрый отправитель и медленный получатель будут обмениваться небольшими (относительно максимального размера сегмента) кусками данных и переключаться по почти заполненному приемному окну. На рис. 10.18 показаны условия для появления синдрома "бестолкового окна".

Рис. 10.18. Буфер приемного окно с очень малым размером свободного пространства

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

minimum(1/2 входного буфера, Максимальный размер сегмента)

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

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

10.13.3 Алгоритм Нейгла

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

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

10.13.4 Задержанный ACK

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

■ Можно подтвердить прием нескольких сегментов одним ACK.

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