UNIX: разработка сетевых приложений

Стивенс Уильям Ричард

Два типичных генератора небольших пакетов — клиенты Rlogin и Telnet, поскольку обычно они посылают каждое нажатие клавиши в отдельном пакете. В быстрой локальной сети мы обычно не замечаем действия алгоритма Нагла с этими клиентами, потому что время, требуемое для подтверждения небольшого пакета, составляет несколько миллисекунд — намного меньше, чем промежуток между вводом двух последовательных символов. Но в глобальной сети, где для подтверждения небольшого пакета может потребоваться секунда, мы можем заметить задержку в отражении символов, и эта задержка часто увеличивается при включении алгоритма Нагла.

Рассмотрим следующий пример. Мы вводим строку из шести символов

hello!

либо клиенту Rlogin, либо клиенту Telnet, промежуток между вводом символов составляет точно 250 мс. Время обращения к серверу (RTT) составляет 600

мс и сервер немедленно отправляет обратно отражение символа. Мы считаем, что сегмент ACK, подтверждающий получение клиентского символа, отправляется обратно клиенту с отражением символа, а сегменты ACK, которые клиент отправляет для подтверждения приема отраженного сервером символа, мы игнорируем. (Мы поговорим о задержанных сегментах ACK далее.) Считая, что алгоритм Нагла отключен, получаем 12 пакетов, изображенных на рис. 7.7.

Рис. 7.7. Шесть символов, отраженных сервером при отключенном алгоритме Нагла

Каждый символ отправляется в индивидуальном пакете: сегменты данных слева направо, а сегменты ACK справа налево.

Но если алгоритм Нагла включен (по умолчанию), у нас имеется 8 пакетов, показанных на рис. 7.8. Первый символ посылается как пакет, но следующие два символа не отправляются, поскольку у соединения есть небольшой пакет, ожидающий подтверждения. Эти пакеты отправляются, когда прошло 600 мс, то есть когда прибывает сегмент ACK, подтверждающий прием первого пакета, вместе с отражением первого символа. Пока второй пакет не будет подтвержден сегментом ACK в момент времени 1200, не будет отправлен ни один небольшой пакет.

Рис. 7.8. Пакеты, отправляемые при включенном алгоритме Нагла

Алгоритм Нагла часто взаимодействует с другим алгоритмом TCP: алгоритмом задержанного сегмента ACK( delayed ACK). Этот алгоритм заставляет TCP не отправлять сегмент ACK сразу же при получении данных — вместо этого TCP ждет в течение небольшого количества времени (типичное значение 50-200 мс) и только после этого отправляет сегмент ACK. Здесь делается расчет на то, что в течение этого непродолжительного времени появятся данные для отправки собеседнику, и сегмент ACK может быть вложен в пакет с этими данными. Таким образом можно будет сэкономить на одном сегменте TCP. Это обычный случай с клиентами Rlogin и Telnet, поэтому сегмент ACK клиентского символа вкладывается в отражение символа сервером.

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

TCP_NODELAY

.

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

write

, отправляя 4 байт, и затем функцию

write

, отправляя остальные 396 байт, вторая часть не будет отправлена со стороны клиента, пока TCP сервера не подтвердит получение первых 4 байт. Кроме того, поскольку сервер не может работать с 4 байтами данных, пока не получит оставшиеся 396 байт, TCP сервера задержит сегмент ACK, подтверждающий получение 4 байт данных (то есть не будет данных от сервера клиенту, в которые можно вложить сегмент ACK). Есть три способа решить проблему с таким клиентом.

1. Использовать функцию

writev

(раздел 14.4) вместо двух вызовов функции

write

. Один вызов функции

writev

приводит к отправке только одного сегмента TCP в нашем примере. Это предпочтительное решение.

2.

Скопировать 4 байт и 396 байт данных в один буфер и вызвать один раз функцию

write

для этого буфера.

3. Установить параметр сокета

TCP_NODELAY

и продолжать вызывать функцию

write

дважды. Это наименее желательное решение.

Упражнения 7.8 и 7.9 продолжают этот пример.

7.10. Параметры сокетов SCTP

Относительно большое количество параметров, определенных для сокетов SCTP (17 на момент написания этой книги), дают возможность разработчику приложения более точно контролировать его поведение. Параметр

level

для сокетов SCTP должен принимать значение

IPPROTO_SCTP

.

Несколько параметров, используемых для получения сведений об SCTP, требуют передачи данных ядру (например, идентификатора ассоциации или адреса собеседника). Не все реализации

getsockopt

поддерживают передачу данных в обе стороны. Интерфейс сокетов SCTP определяет функцию

sctp_opt_info

(раздел 9.11), которая устраняет эту проблему. В некоторых системах, где

getsockopt

поддерживает передачу данных в ядро, функция

sctp_opt_info

является не более, чем оболочкой для

getsockopt

. В других системах она может вызывать функцию

ioctl

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

sctp_opt_info

, так как в этом случае обеспечивается максимальная переносимость. В табл. 7.2 соответствующие параметры отмечены знаком «

+

»:

SCTP_ASSOCINFO

,

SCTP_GET_PEER_ADDR_INFO

,

SCTP_PEER_ADDR_PARAMS

,

SCTP_PRIMARY_ADDR

,

SCTP_RTOINFO

и

SCTP_STATUS

.

Параметр сокета SCTP_ADAPTION_LAYER

При инициализации ассоциации любой собеседник может указать на наличие уровня-адаптора. Это указание должно представлять из себя 32-разрядное беззнаковое целое, которое может использоваться двумя приложениями для координации локального уровня-адаптора приложений. Параметр сокета позволяет получать или устанавливать указание на наличие уровня-адаптора, которое будет предоставляться данной конечной точкой будущим собеседникам. Чтобы получить соответствующее значение, установленное собеседником, приложение должно подписаться на события уровня-адаптора.

Параметр сокета SCTP_ASSOCINFO

Параметр сокета

SCTP_ASSOCINFO

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

getsockopt

следует использовать

sctp_opt_info

. Вместе с параметром при вызове функции указывается структура

sctp_assocparams

:

struct sctp_assocparams {

sctp_assoc_t sasoc_assoc_id;

uint16_t sasoc_asocmaxrxt;

uint16_t sasoc_number_peer_destinations;

uint32_t sasoc_peer_rwnd;

uint32_t sasoc_local_rwnd;

uint32_t sasoc_cookie_life;

};

Поля структуры имеют следующий смысл:

sasoc_assoc_id

хранит идентификатор ассоциации. Если при вызове

setsockopt

параметр установлен в нуль, поля

sasoc_asocmaxrxt

и

sasoc_cookie_life

трактуются как новые значения по умолчанию для сокета. Вызов

getsockopt

вернет сведения об ассоциации, если при вызове указать ее идентификатор; если же поле оставить нулевым, будут возвращены значения по умолчанию;