RFC 1122 (часть 2)

Please enter banners and links.

Часть 1

4. Транспортные протоколы

4.1 Протокол пользовательских дейтаграмм UDP

4.1.1 Введение

Протокол пользовательских дейтаграмм UDP⁴⁵ [UDP:1] обеспечивает лишь минимальный транспортный сервис – негарантированную доставку дейтаграмм – и предоставляет приложениям прямой доступ к службе дейтаграмм уровня IP. UDP используется приложениями, которым не нужен высокий уровень сервиса TCP, или требуемые приложению коммуникационные службы не поддерживаются протоколом TCP (например, групповая или широковещательная адресация).

Протокол UDP не добавляет почти ничего к службам уровня IP – лишь поддержку контрольных сумм и мультиплексирование по номерам портов. Следовательно, прикладные программы, использующие UDP должны сами решать все задачи сквозного обмена данными, которые обычно обслуживаются протоколами, основанными на соединениях (т. е., обеспечивать повторную передачу при неудачах, управлять потоком данных, контролировать насыщение и т. п). Сложность взаимодействия между IP и TCP заменяется на сложное взаимодействие между UDP и приложениями, использующими протокол UDP.

4.1.2 Общие вопросы

В спецификации UDP ошибки отсутствуют.

4.1.3 Частные вопросы

4.1.3.1 Порты

Общеизвестные порты UDP подчиняются тем же правилам, что и общеизвестные порты для протокола TCP (см. параграф 4.2.2.1).

Если принятая дейтаграмма адресована порту UDP, для которого нет прослушивания, протоколу UDP следует передать отправителю сообщение ICMP Port Unreachable.

4.1.3.2 Опции IP

Протокол UDP должен передавать прикладным программам все опции IP, полученные от уровня IP.

Приложениям должна предоставляться возможность установки опций IP для передаваемых дейтаграмм UDP и протокол UDP должен передавать эти опции уровню IP.

Обсуждение

В настоящее время через UDP передаются только опции Source Route, Record Route и Time Stamp. Однако в будущем число таких опций может быть расширено (например, за счет опций безопасности IP) и реализации протокола UDP, поэтому, не должны делать каких-либо предположений о формате или содержимом передаваемых опций.

Приложениям на основе UDP может потребоваться получение информации source route из дейтаграмм с запросами и установка обратного маршрута в передаваемых откликах.

4.1.3.3 Сообщения ICMP

Протокол UDP должен передавать на уровень приложений все сообщения ICMP об ошибках, полученные от уровня IP. Для реализации этого может использоваться вызов процедуры ERROR_REPORT (см. 4.2.4.1).

Обсуждение

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

4.1.3.4 Контрольные суммы UDP

Хост должен поддерживать механизмы генерации и проверки контрольных сумм UDP. Приложения могут управлять процессом генерации контрольных сумм UDP, но по умолчанию протокол должен самостоятельно работать с контрольными суммами.

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

Обсуждение

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

Реализация

В реализации контрольных сумм UDP часто допускают одну и ту же ошибку. В отличие от контрольных сумм TCP контрольные суммы UDP не являются обязательными – нулевое значение поля контрольной суммы в заголовке UDP говорит об отсутствии контрольной суммы. Если отправитель получает для контрольной суммы реальной дейтаграммы UDP нулевое значение, он должен установить в поле контрольной суммы значение 65535 (все биты имеют значение 1). От получателя не требуется в таких случаях каких-либо дополнительных действий, поскольку значения 0 и 65535 эквивалентны с точки зрения арифметики с дополнением до 1.

4.1.3.5 Многодомные хосты UDP

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

Обсуждение

Приложения на основе запросов/откликов, использующие протокол UDP, должны устанавливать для откликов в качестве адреса отправителя тот же адрес, который был задан для получателя запроса (см. параграф «Общие вопросы» в [INTRO:1]).

4.1.3.6 Некорректная адресация

Дейтаграммы UDP, принятые с некорректным IP-адресом отправителя (например, широковещательный или групповой адрес) должны отбрасываться на уровне UDP или IP (см. 3.2.1.3).

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

4.1.4 Интерфейс между уровнем UDP и прикладным уровнем

Интерфейс между приложениями и UDP должен полностью обеспечивать службы, описанные в параграфе 3.4. Таким образом, приложениям на основе UDP требуются функции GET_SRCADDR(), GET_MAXSIZES(), ADVISE_DELIVPROB() и RECV_ICMP(), описанные в 3.4. Например, функция GET_MAXSIZES() может использоваться для определения эффективного значения максимального размера дейтаграмм UDP для конкретной триады {интерфейс, удаленный хост, TOS}.

Программы прикладного уровня должны иметь возможность установки значений TTL и TOS, а также опций IP при передаче дейтаграмм UDP и установленные значения должны прозрачно передаваться на уровень IP. UDP может передавать полученные значения TOS на уровень приложений.

4.1.5 Требования к протоколу UDP

Функция	Параграф	Требование
UDP передает сообщения Port Unreachable	4.1.3.1	Следует
Опции IP в UDP
Передача полученных опций на уровень приложений	4.1.3.2	Обязательно
Приложения могут устанавливать опции при передаче	4.1.3.2	Обязательно
UDP передает опции на уровень IP	4.1.3.2	Обязательно
Передача сообщений ICMP на прикладной уровень	4.1.3.3	Обязательно
Контрольные суммы UDP:	4.1.3.4	Обязательно
Генерация и проверка контрольных сумм	4.1.3.4	Обязательно
Отбрасывание дейтаграмм с ошибкой в контрольной сумме	4.1.3.4	Обязательно
Передача дейтаграмм без контрольной суммы	4.1.3.4	Возможно
По умолчанию контрольная сумма используется	4.1.3.4	Обязательно
Получатель может требовать контрольную сумму	4.1.3.4	Возможно
Многодомные хосты UDP:
Передача указанного адреса получателя приложениям	4.1.3.5	Обязательно
Возможность задания локального адреса отправителя на прикладном уровне	4.1.3.5	Обязательно
Возможность задания шаблона локального адреса отправителя на прикладном уровне	4.1.3.5	Обязательно
Уведомление приклад. уровня об используемом локальном адресе	4.1.3.5	Возможно
Дейтаграммы с некорректным IP-адресом отправителя отбрасываются UDP/IP	4.1.3.6	Обязательно
При передаче дейтаграмм используется только корректный. адрес IP	4.1.3.6	Обязательно
Службы интерфейса UDP c приложениями:
Полный интерфейс IP (см. 3.4) для приложений	4.1.4	Обязательно
Возможность задания TTL, TOS и опций IP при передаче	4.1.4	Обязательно
Передача принятого TOS на уровень приложений	4.1.4	Возможно

4.2 Протокол управления передачей – TCP

4.2.1 Введение

Протокол управления передачей – TCP⁴⁶ [TCP:1] представляет собой транспортный протокол стека Internet для работы с виртуальными соединениями. TCP обеспечивает гарантированную доставку с сохранением порядка для полнодуплексных потоков данных (октеты или байты). Протокол TCP используется теми приложениями, которым нужен ориентированный на соединения транспортный сервис с гарантией доставки (например, электронная почта SMTP, передача файлов по протоколу FTP, служба виртуальных терминалов Telnet); требования к таким протоколам прикладного уровня описаны в работе [INTRO:1].

4.2.2 Общие вопросы

4.2.2.1 Общеизвестные порты: RFC 793, параграф 2.7

Обсуждение

TCP резервирует номера от 0 до 255 для общеизвестных портов, которые служат для использования стандартных служб через Internet. Остальные номера портов могут свободно распределяться между прикладными процессами. Текущий список общеизвестных портов можно найти в документе Assigned Numbers [INTRO:6]. Предпосылкой задания новых общеизвестный номеров является подготовка для новой службы RFC, достаточно детально описывающего сервис для обеспечения возможности его реализации.

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

4.2.2.2 Использование флага Push: RFC 793, параграф 2.8

Когда приложение использует серию вызовов SEND без установки флага PUSH, TCP может объединять (агрегировать) данные внутренними средствами, не передавая их. Подобно этому, при получении серии сегментов без бита PSH, TCP может помещать данные во внутреннюю очередь без передачи их принимающему приложению.

Бит PSH не является маркером записи и не связан с границами сегментов. Отправителю рекомендуется удалять последовательные биты PSH при пакетировании данных для передачи сегментов максимального размера.

TCP может реализовать флаги PUSH при вызовах функции SEND. Если флаги PUSH не реализованы, требуется выполнение двух условий при передаче TCP: (1) буфер данных не должен быть бесконечным и (2) должен устанавливаться бит PSH в последнем буферизованном сегменте (т. е., при отсутствии в очереди данных для передачи).

В RFC 793 на страницах 48, 50 и 74 ошибочно указано, что принятый бит PSH должен передаваться прикладному уровню – передача прикладному уровню полученного флага PSH не является обязательной.

От прикладных программ требуется установка флага PUSH при вызове SEND, если требуется форсировать доставку во избежание простоя соединения. Однако протоколу TCP рекомендуется по возможности передавать сегменты максимального размера в целях повышения производительности (см. 4.2.3.4).

Обсуждение

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

В общем случае интерактивный прикладной протокол должен устанавливать флаг PUSH по крайней мере при последнем вызове SEND для каждого набора команд или откликов. Протоколы, передающие большие объемы данных (типа FTP), должны устанавливать флаг PUSH для последнего сегмента файла или при возникновении необходимости предотвратить «застой» буфера.

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

4.2.2.3 Размер окна: RFC 793, параграф 3.1

Размер окна должен трактоваться как беззнаковое целое – если большое окно будет представляться, как окно с отрицательным размером, TCP просто не будет работать. Рекомендуется использовать 32-битовые поля для размера окна передачи и приема в записи с параметрами соединения.

Обсуждение

Известно, что поле размера окна в заголовке TCP слишком мало для высоких скоростей и путей с большой задержкой. Для расширения окна TCP определены экспериментальные опции (см. например, [TCP:11]). С учетом такого расширения при реализации TCP следует рассчитывать на 32-битовые значения размера окна.

4.2.2.4 Указатель срочности: RFC 793, параграф 3.1

Второе предложение этого параграфа содержит ошибку – urgent pointer указывает на порядковый номер последнего (а не следующего за ним) октета в последовательности срочных данных. Описание на стр. 56 (последнее предложение) корректно.

Протокол TCP должен поддерживать последовательности срочных данных любой длины.

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

Обсуждение

Хотя механизм Urgent может использоваться для любых приложений, обычно он применяется для передачи «прерываний» типа команд Telnet (см. параграф Using Telnet Synch Sequence в [INTRO:1]).

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

Реализация

Базовый механизм ERROR-REPORT(), описанный в параграфе 4.2.4.1, может использоваться для информирования приложений о приходе важных данных.

4.2.2.5 Опции TCP: RFC 793, параграф 3.1

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

4.2.2.6 Максимальный размер сегмента: RFC 793, параграф 3.1

Протокол TCP должен поддерживать опции максимального размера сегмента – MSS⁴⁷ для приема и передачи [TCP:4].

Для TCP рекомендуется передавать опцию MSS в каждом сегменте SYN при получении MSS, отличного от принятого по умолчанию значения 536; можно передавать эту опцию во всех случаях.

Если опция MSS не получена при организации соединения, протокол TCP должен использовать принятое по умолчанию значение MSS = 536 (576-40) [TCP:4].

Максимальный размер сегмента, реально передаваемого TCP – эффективное значение MSS для передачи, – должен быть меньше MSS для передачи (отражает доступный размер буфера сборки на удаленном хосте) и максимального размера, поддерживаемого уровнем IP:

Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize - Ipoptionsize,

где:

• SendMSS – значение MSS, полученное от удаленного хоста или принятое по умолчанию значение 536, если опция MSS не была получена;
• MMS_S – максимальный размер сообщений транспортного уровня, которые может передавать TCP;
• TCPhdrsize – размер заголовка TCP (обычно 20, но может быть больше за счет опций TCP);
• IPoptionsize – размер всех опций IP, которые TCP будет передавать на уровень IP с этим сообщением.

Значение MSS, которое будет передано в опции MSS, не должно быть больше

MMS_R - 20

где MMS_R – максимальный размер для сообщений транспортного уровня, которые могут быть приняты (и собраны); TCP получает значения MMS_R и MMS_S от уровня IP (см. описание функции GET_MAXSIZES в 3.4).

Обсуждение

Размер сегмента TCP оказывает существенное влияние на производительность. Увеличение сегментов повышает пропускную способность за счет снижения объема заголовков в общем потоке данных и уменьшения времени на обработку этих заголовков. Однако, если пакеты столь велики, что требуется фрагментация IP, эффективность существенно снижается при потере любого фрагмента [IP:9].

Некоторые реализации TCP передают опцию MSS только в тех случаях, когда хост-получатель относится к подключенной сети. Однако в общем случае уровень TCP может не иметь достаточно информации для определения такой принадлежности, поэтому разумно передать уровню IP решение вопроса определения приемлемого значения MTU для пути Internet. Рекомендуется использовать опцию MSS во всех случаях, когда значение отличается от 536 (тогда уровень IP определяет MMS_R в соответствии с параграфами 3.3.3 и 3.4). Предлагаемые для уровня IP механизмы определения MTU в этом случае не будут оказывать влияния на TCP.

4.2.2.7 Контрольная сумма TCP: RFC 793, параграф 3.1

В отличие от контрольных сумм UDP (см. 4.1.3.4), контрольные суммы TCP использовать обязательно. Отправитель должен генерировать контрольную сумму, а получатель должен ее проверять.

4.2.2.8 Диаграмма состояния соединения TCP: RFC 793 параграф 3.2, стр. 23

С диаграммами состояния связано несколько проблем:

1. Стрелка от SYN-SENT к SYN-RCVD должна помечаться snd SYN,ACK, в соответствии с текстом на стр. 68 и рисунком 8.
2. Возможна стрелка от состояния SYN-RCVD к состоянию LISTEN при условии получения RST после пассивного открытия (см. стр 70 в RFC 793).
3. Возможно прямо перейти из FIN-WAIT-1 в состояние TIME-WAIT (см. стр. 75 в RFC 793).

4.2.2.9 Выбор начального порядкового номера: RFC 793, параграф 3.3, стр. 27

Протокол TCP должен использовать начальный порядковый номер, генерируемый в соответствии с текущим временем.

4.2.2.10 Число последовательных попыток открытия: RFC 793, параграф 3.4, стр. 32

На рисунке 8 допущена ошибка – пакет в строке 7 должен быть идентичен пакету в строке 5.

Протокол TCP должен поддерживать одновременные попытки организации соединения.

Обсуждение

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

4.2.2.11 Восстановление по старым дубликатам SYN: RFC 793, параграф 3.4, стр. 33

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

4.2.2.12 Сегмент RST: RFC 793, параграф 3.4

Для протокола TCP следует допускать прием сегментов RST, содержащих данные.

Обсуждение

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

4.2.2.13 Завершение соединений: RFC 793, параграф 3.5

Соединения TCP могут завершаться двумя способами: (1) нормальная процедура завершения TCP с использованием FIN и (2) разрыв в результате передачи одного или нескольких сегментов RST, приводящих к немедленному закрытию соединения. Если соединение TCP закрыто удаленной стороной, локальное приложение должно получить информацию об использованном варианте завершения (1 или 2).

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

Хост может реализовать «полудуплексные» последовательности закрытия TCP так, что приложение, вызвавшее функцию CLOSE, не сможет после этого читать данные из соединения. Если такой хост вызывает CLOSE в процессе приема данных через соединение TCP или новые данные получены уже после вызова CLOSE, протоколу TCP следует передать сегмент RST для информирования о потере данных.

При активном закрытии соединения оно должно сохраняться в состоянии TIME-WAIT (ожидание) в течение времени 2 x MSL⁴⁸. Однако возможно восприятие новых вызовов SYN от удаленного TCP для повторного открытия соединения непосредственно из состояния TIME-WAIT, если выполняются следующие условия:

1. начальный порядковый номер для нового соединения больше максимального порядкового номера, использованного в предыдущем соединении;
2. происходит возврат в состояние TIME-WAIT, если SYN оказывается дубликатом старого вызова.

Обсуждение

Полнодуплексное завершение соединений TCP для сохранения данных не включено в аналогичный транспортный протокол TP4 стека ISO.

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

Изящный алгоритм завершения TCP требует, чтобы активное состояние сохранялось (по крайней мере) на одной из сторон в течение времени 2 x MSL (4 минуты). В течение этого периода пара (удаленный сокет, локальный сокет), определяющая соединение, остается занятой и не может быть повторно использована. Для сокращения периода занятости данной пары портов некоторые реализации TCP позволяют воспринимать новые вызовы SYN в состоянии TIME-WAIT.

4.2.2.14 Передача данных: RFC 793, параграф 3.7, стр. 40

С момента выхода RFC 793 алгоритмы TCP постоянно совершенствовались для повышения эффективности обмена данными. В последующих параграфах этого документа описаны обязательные и рекомендуемые алгоритмы TCP, позволяющие определить, когда следует передавать данные (4.2.3.4) и подтверждения (4.2.3.2) или обновлять окно (4.2.3.3).

Обсуждение

Одним из важных вопросов производительности является «синдром глупого окна» (SWS⁴⁹), описанный в [TCP:5] – стабильное небольшое увеличение окна, в результате которого происходит существенное снижение производительности TCP. Алгоритмы предотвращения SWS описаны ниже как для передающей (4.2.3.4), так и для приемной стороны (4.2.3.3).

Кратко говоря, причиной SWS является получение информации о расширении окна вправо всякий раз, когда есть буферное пространство, доступное для приема данных, и отправитель использует увеличение окна (невзирая на его незначительность) для передачи большего объема данных [TCP:5]. Результатом этого может стать непрерывная передача крошечных сегментов даже при наличии больших буферов на приемной и передающей стороне. SWS может возникать только при передаче больших объемов данных; если соединение стабильно (передается постоянный поток данных), проблема исчезает. Причиной проблемы является типичная реализация прямого управления окном – ниже описаны алгоритмы для получателя и отправителя, позволяющие решить эту проблему.

Другим важным вопросом производительности TCP является то, что некоторые приложения (особенно системы удаленного входа) на хостах с посимвольным вводом имеют тенденцию передавать потоки однооктетных сегментов данных. Во избежание застоя каждый вызов TCP SEND от таких приложений должен выталкиваться приложением явно или в неявной форме с помощью TCP. В результате может возникнуть поток сегментов TCP, содержащих лишь по одному октету, что ведет к снижению эффективности использования Internet и вносит существенный вклад в насыщение. Алгоритм Nagle, описанный в параграфе 4.2.3.4, обеспечивает простое и эффективное решение этой проблемы. Алгоритм обеспечивает группировку символов для соединений Telnet (это может удивить пользователей, ожидающих эхо после каждого символа, но восприятие пользователей не является проблемой).

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

В осторожных реализациях может передаваться два или более подтверждений для каждого принятого сегмента. Предположим для примера, что получатель незамедлительно подтверждает прием каждого сегмента. Когда прикладная программа «потребит» данные и снова увеличит доступное пространство в буфере приема, получатель может передать второе подтверждение отправителю для обновления окна. Экстремальная ситуация возникает при 1-октетных сегментах в соединениях TCP, использующих протокол Telnet для удаленного входа в систему. Встречаются реализации, где на каждое нажатие клавиши пользователем генерируется три передаваемых в ответ сегмента: (1) подтверждение, (2) однобайтовое расширение окна и (3) эхо-символ.

4.2.2.15 Тайм-аут повторной передачи: RFC 793, параграф 3.7, стр. 41

Сейчас известно, что предложенный в RFC 793 алгоритм расчета тайм-аута для повторной передачи не является адекватным (см параграф 4.2.3.1).

Недавняя работа Якобсона [TCP:7] по вопросам насыщения Internet и стабильности повторной передачи TCP предлагает новый алгоритм, объединяющий механизмы slow start (замедленный старт) и congestion avoidance (предотвращение насыщения). Протокол TCP должен реализовать эти алгоритмы.

Если повторный пакет идентичен исходному (сохранены не только границы данных, но также окно и поля подтверждения в заголовке), можно использовать прежнее значение поля идентификации IP (см. 3.2.1.5).

Реализация

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

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

4.2.2.16 Управление окном: RFC 793, параграф 3.7, стр. 41

Получателям TCP не рекомендуется отсекать часть окна (т. е., перемещать правый край окна влево). Однако отправитель TCP должен быть устойчивым к уменьшению окна, при котором значение «useable window» (см. 4.2.3.4) становится отрицательным.

Если такое происходит, отправителю не следует передавать новые данные, но следует повторить передачу неподтвержденных данных между SND.UNA и SND.UNA+SND.WND. Отправитель также может повторить передачу данных за пределами SND.UNA+SND.WND, но не следует прерывать соединение по тайм-ауту, если доставка данных за пределами правого края окна не подтверждена. Если окно сокращается до нуля, протокол TCP должен проверить его стандартным способом (см. ниже).

Обсуждение

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

4.2.2.17 Проверка нулевого окна: RFC 793, параграф 3.7, стр. 42

Должна поддерживаться проверка нулевого (предлагаемого) окна.

TCP может сохранять свои предлагаемые приемные окна закрытыми в течение неопределенного времени. До тех пор, пока TCP на приемной стороне продолжает слать подтверждения в ответ на проверочные сегменты, протокол TCP на передающей стороне должен сохранять соединение открытым.

Обсуждение

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

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

Передающему хосту рекомендуется посылать первую пробу нулевого окна, когда такое окно существовало в течение периода, равного тайм-ауту для передачи (см. 4.2.2.15); интервалы передачи последующих проб рекомендуется экспоненциально увеличивать.

Обсуждение

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

4.2.2.18 Пассивные вызовы OPEN: RFC 793, параграф 3.8

Каждый пассивный вызов OPEN создает новую запись о соединении в состоянии LISTEN или возвращает ошибку – это не должно оказывать влияния на любые ранее созданные записи соединений.

Реализации TCP, поддерживающие множество пользователей одновременно, должны обеспечивать вызовы OPEN, функционально позволяющие приложениям прослушивать (LISTEN) порт, пока не будет блокировано соединение с таким же номером локального порта в состоянии SYN-SENT или SYN-RECEIVED.

Обсуждение

Некоторые приложения (например, серверы SMTP) могут требовать обслуживания множества одновременных попыток организации соединения. Вероятность отказа при таких попытках может быть снижена за счет предоставления программе возможности прослушивания соединения одновременно с попыткой согласования параметров для ранее организованного соединения.

Реализация

Приемлемые реализации одновременных попыток соединения могут разрешать множество открытых пассивных вызовов OPEN или «клонирование» соединений в состоянии LISTEN из одного пассивного вызова OPEN.

4.2.2.19 Время жизни: RFC 793, параграф 3.9, стр. 51

В RFC 793 указано, что TCP будет запрашивать у IP-уровня передачу сегментов TCP со значением TTL = 60. Это требование устарело и значение TTL для передачи сегментов TCP должно быть настраиваемым (см. 3.2.1.7).

4.2.2.20 Обработка событий: RFC 793, параграф 3.9

Хоть это и не является обязательным, следует поддерживать для TCP очереди с нарушением порядка сегментов TCP (в RFC 793 на стр. 70 сказано возможно).

Обсуждение

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

В общем случае обработка принятых сегментов должна быть построена так, чтобы сегменты ACK по возможности объединялись. Например, если TCP обрабатывает группу сегментов из очереди, передача сегмента ACK должна происходить только после обработки всех таких сегментов.

Ниже приведены некоторые поправки к параграфу «Обработка событий» в RFC 793.

1. Вызов CLOSE, состояние CLOSE-WAIT (стр. 61): следует читать LAST-ACK взамен CLOSING.
2. Состояние LISTEN, проверка SYN (стр. 65, 66): При наличии бита SYN передача сбрасывается, если для сегмента некорректны значения security/compartment или precedence. В документе допущена ошибка. Правильная команда сброса показана ниже:

   <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>

3. Состояние SYN-SENT, проверка SYN (стр. 68): При переходе соединения в состояние ESTABLISHED должны быть установлены следующие переменные:

   SND.WND <- SEG.WND
   SND.WL1 <- SEG.SEQ
   SND.WL2 <- SEG.ACK

4. Проверка защиты и предпочтений (стр. 71): Первый заголовок ESTABLISHED STATE реально должен быть списком всех состояний, кроме SYN-RECEIVED – ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT.
5. Вместо «check the SYN bit» (стр. 71) следует читать «In SYN-RECEIVED state and if the connection was initiated with a passive OPEN, then return this connection to the LISTEN state and return. Otherwise check the SYN bit⁵⁰».
6. Проверка поля ACK, состояние SYN-RECEIVED (стр. 72: При переходе соединения в состояние ESTABLISHED должны быть установлены переменные, указанные в п. (c).
7. Проверка поля ACK, состояние ESTABLISHED (стр. 72): ACK является дубликатом, если SEG.ACK =< SND.UNA (знак = пропущен). Аналогичный пропуск в условии обновления окна – должно быть: SND.UNA =<SEG.ACK =< SND.NXT.
8. USER TIMEOUT (стр. 77):

Лучше будет уведомлять приложение о тайм-ауте, а не о разрешении TCP закрыть соединение (см. также параграф 4.2.3.5).

4.2.2.21 Подтверждение для сегментов из очереди: RFC 793, параграф 3.9

TCP может передавать сегмент ACK, подтверждающий RCV.NXT, когда приходит корректный сегмент, который находится в окне, но не на его левой границе.

Обсуждение

В RFC 793 (стр. 74) нет ясности по вопросу передачи сегмента ACK при получении сегментов с нарушением порядка (т. е., SEG.SEQ не равно RCV.NXT).

Одной из причин передачи подтверждений для сегментов с нарушением порядка доставки может быть поддержка экспериментального алгоритма, названного fast retransmit (ускоренный повтор передачи). При использовании этого алгоритма отправитель передает избыточные подтверждения ACK для указания потери сегмента до истечения тайм-аута повторной передачи. Подсчитывается число полученных подтверждений ACK с одинаковым значением SEG.ACK и одинаковой правой границей окна. При получении большего числа ACK, нежели заданное пороговое значение, предполагается потеря сегмента, начинающегося с SEG.ACK, и выполняется повторная передача без ожидания тайм-аута. Пороговое значение выбирается таким образом, чтобы компенсировать максимальное разупорядочивание сегментов в Internet. Использование этого алгоритма пока слишком непродолжительно, чтобы сделать выводы о его полезности.

4.2.3 Частные вопросы

4.2.3.1 Расчет тайм-аута для повторной передачи

Хост TCP должен поддерживать алгоритмы Karn и Jacobson для расчета тайм-аута повторной передачи RTO.

• алгоритм Jacobson для расчета взвешенного времени кругового обхода (RTT) включает простое измерение вариаций [TCP:7];
• алгоритм Karn для выбора способа измерения RTT гарантирует, что случайные значения времени кругового обхода не будут уничтожать результат расчета взвешенного времени обхода [TCP:6].

Такая реализация должна также включать экспоненциальный рост последовательных значений RTO для одного сегмента. Для повторной передачи сегментов SYN рекомендуется использовать такой же алгоритм, как для сегментов данных.

Обсуждение

Известны две проблемы, связанные с расчетом RTO, описанным в RFC 793. Во-первых, при наличии повторов точное измерение RTT становится затруднительным. Во-вторых, алгоритм расчета взвешенного времени кругового обхода неадекватен [TCP:7], поскольку использует некорректное предположение о малости и постоянстве вариаций RTT. Для решения этих проблем используются алгоритмы Karn и Jacobson, соответственно.

Повышение производительности в результате использования этих алгоритмов может колебаться от незначительного до гигантского. Алгоритм Jacobson для включения вариаций измеренных значений RTT особенно важен для низкоскоростных каналов, где естественные вариации размера пакетов приводят к значительным вариациям RTT. Один из разработчиков отметил рост эффективности использования канала 9.6 кбит/с с 10% до 90% в результате реализации алгоритма Jacobson для TCP.

Для инициализации оценочных параметров новых соединений рекомендуется использовать значения:

1. RTT = 0 секунд;
2. RTO = 3 секунды (взвешенные вариации инициализируются значением, которое будет влиять на RTO).

Известно, что рекомендованные значения верхней и нижней границ RTO неадекватны для больших сетей. Рекомендуется задавать нижнюю границу в долях секунды (для работы со скоростными ЛВС), а в качестве верхней границы использовать значение 2*MSL (240 секунд).

Обсуждение

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

4.2.3.2 Когда передавать сегмент ACK

Хост, получающий поток сегментов данных TCP, может повысить эффективность работы (хостов и Internet) за счет передачи меньшего числа подтверждений ACK для принятых сегментов. Такой метод называется задержкой подтверждений [TCP:5].

Для TCP рекомендуется реализовать задержку ACK, но такая задержка не должна быть слишком большой. В частности, задержка должна быть меньше 0.5 сек. и в потоке сегментов полного размера подтверждения должны передаваться по крайней мере для каждого второго сегмента.

Обсуждение

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

В дополнение к этому на некоторых крупных, многопользовательских хостах задержка ACK может существенно снизить затраты на обработку заголовков за счет уменьшения общего числа обрабатываемых пакетов [TCP:5]. Однако, чрезмерная задержка ACK может нарушать определение времени обхода и работу алгоритмов «тактирования» пакетов [TCP:7].

4.2.3.3 Когда передавать Window Update

Протокол TCP должен включать алгоритм предотвращения SWS на приемной стороне [TCP:5].

Реализация

Алгоритм предотвращения SWS на приемной стороне определяет, когда может быть анонсировано расширение правого края окна (обновление окна). Этот алгоритм используют совместно с задержкой подтверждений ACK (см. 4.2.3.2) для определения момента передачи получателю сегмента ACK, содержащего текущее окно. При описании мы будем использовать обозначения, принятые в RFC 793 (см. рис. 4 и 5 в этом документе).

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

Предположим, что на приемной стороне имеется буфер RCV.BUFF. В любой момент времени RCV.USER октетов из этого буфера может быть связано с данными, которые уже получены и подтверждены, но еще не восприняты пользовательским процессом. Когда соединение находится в статичном состоянии, RCV.WND = RCV.BUFF и RCV.USER = 0.

Сохранение правого края окна неподвижным при получении и подтверждении данных требует чтобы получатель анонсировал пространство, которое меньше его реального буфера, т. е., получатель должен задавать значение RCV.WND, которое позволит сохранить постоянной сумму RCV.NXT+RCV.WND при возрастании RCV.NXT. Таким образом, общее пространство буфера RCV.BUFF в общем случае делится на три части:

    |<------- RCV.BUFF ---------------->|
         1              2            3
----|---------|------------------|------|----
           RCV.NXT               ^

(фиксированная часть)

1. RCV.USER – полученные, но не воспринятые приложением данные;
2. RCV.WND – пространство, анонсируемое отправителю;
3. Reduction – доступное, но еще не анонсированное пространство.

Предлагаемый алгоритм предотвращения SWS для приемной стороны сохраняет фиксированное значение RCV.NXT+RCV.WND до тех пор, пока выполняется условие:

RCV.BUFF - RCV.USER - RCV.WND >= min(Fr * RCV.BUFF, Eff.snd.MSS)

гле Fr – часть, рекомендуемое значение которой составляет 1/2, а Eff.snd.MSS – эффективное значение MSS для передачи в данном соединении (см. 4.2.2.6). При выполнении условий неравенства устанавливается RCV.WND = RCV.BUFF-RCV.USER.

Отметим, что общим эффектом этого алгоритма является анонсирование RCV.WND с инкрементом Eff.snd.MSS (для разумных буферов на приемной стороне Eff.snd.MSS < RCV.BUFF/2). Отметим также, что приемная сторона должна использовать свое значение Eff.snd.MSS, предполагая, что оно совпадает со значением для передающей стороны.

4.2.3.4 Когда передавать данные

Протокол TCP должен поддерживать механизм предотвращения SWS на приемной стороне.

Для протокола TCP рекомендуется реализация алгоритма Nagle [TCP:9], позволяющего объединять короткие сегменты. Однако, приложениям должен обеспечиваться способ запрета алгоритма Nagle для отдельных соединений. Во всех случаях для передачи данных действуют также ограничения, вносимые алгоритмом Slow Start (см. 4.2.2.15).

Обсуждение

Алгоритм Nagle в общем случае действует следующим образом:

При наличии неподтвержденных данных (т. е., SND.NXT > SND.UNA) в буферы TCP передаются все пользовательские данные (не принимая во внимание бит PSH), пока остающиеся данные не будут подтверждены или пока TCP не сможет передать сегмент полного размера (Eff.snd.MSS байтов; см. 4.2.2.6).

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

Реализация

Алгоритм предотвращения SWS на передающей стороне реализуется сложней, нежели на приемной, поскольку отправитель не знает (явно) размер буферного пространства RCV.BUFF на приемной стороне. Проверенным вариантом является расчет отправителем значения максимального окна передачи для соединения Max(SND.WND) и использование полученного значения для оценки RCV.BUFF. К сожалению, возможна только оценка буфера, поскольку приемная сторона может время от времени менять значение RCV.BUFF. Чтобы избежать застоя соединений в результате этого, необходимо использовать значение тайм-аута для форсирования передачи данных, имеющего преимущество перед алгоритмом предотвращения SWS. На практике форсирование передачи по тайм-ауту должно происходить редко.

Доступное окно имеет размер ([TCP:5]):

U = SND.UNA + SND.WND - SND.NXT

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

1. при достижении максимального размера передаваемого сегмента, т. е.:

   min(D,U) >= Eff.snd.MSS;

2. или установлен флаг push и все данные из очереди могут быть переданы, т. е.:

   [SND.NXT = SND.UNA and] PUSHED and D <= U

   (условие в квадратных скобках вносится алгоритмом Nagle);

3. или по крайней мере Fs-ая часть максимального окна может быть передана, т. е.:

   [SND.NXT = SND.UNA and] min(D.U) >= Fs * Max(SND.WND);

4. или установлен флаг PUSH и достигнут тайм-аут.

Fs представляет собой часть, рекомендуемое значение которой составляет 1/2. Значение тайм-аута должно составлять 0.1 – 1.0 сек. Может оказаться удобным объединение этого таймера с таймером проверки нулевого окна, описанным в параграфе 4.2.2.17.

В заключение отметим, что использование алгоритма предотвращения SWS рекомендуется взамен алгоритма sender-side, описанного в работе [TCP:5].

4.2.3.5 Сбои в соединениях TCP

Многократные повторы передачи одного сегмента TCP свидетельствуют о наличии сбоев на удаленном хосте или пути через Internet. Эти сбои могут быть кратковременными или продолжительными. При возникновении таких ситуаций хост должен использовать перечисленные ниже процедуры [IP:11]:

1. Существуют два пороговых значения R1 и R2 для измерения числа повторов передачи одного сегмента. Для задания R1 и R2 могут использоваться единицы времени или число повторов передачи.
2. При достижении числа повторов R1 передается негативный анонс (см. 3.3.1.4) на уровень IP для включения диагностики работоспособности шлюзов.
3. При достижении порога R2 (превышает R1) соединение закрывается.
4. Приложениям должна обеспечиваться возможность установки порога R2 для отдельного соединения. Например, интерактивные соединения могут устанавливать для R2 «бесконечное» значение, предоставляя пользователю самостоятельно решать вопрос о разрыве соединения.
5. Протоколу TCP следует информировать приложения о проблемах с доставкой (если это не запрещено приложением; см. 4.2.4.1), при достижении порога R1, но до порога R2. Такая информация позволяет программам удаленного доступа (типа Telnet) информировать пользователя о проблемах.

Следует устанавливать для R1 значение, соответствующее по крайней мере 3 повторам при текущем значении RTO. Для R2 следует задавать значение не менее 100 секунд.

При попытке создать соединение TCP может наблюдаться сбой с многократным повтором сегмента SYN, получением сегмента RST или сообщения ICMP Port Unreachable. Повторные передачи SYN должны обрабатываться обычным способом (как для данных), включая уведомление прикладного уровня.

Однако, значения R1 и R2 для сегментов SYN могут отличаться от значения для сегментов данных. В частности, значение R2 для SYN должно быть достаточно велико, чтобы обеспечивать повторные передачи по крайней мере в течение 3 минут. Приложение может закрыть соединение и раньше (например, задав число попыток).

Обсуждение

Для некоторых путей Internet время организации соединения достаточно велико и число таких путей может существенно возрасти в будущем.

4.2.3.6 TCP Keep-Alive

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

Пакеты keep-alive должны передаваться только при отсутствии пакетов данных или подтверждений в течение заданного интервала. Значение этого интервала должно быть настраиваемым и по умолчанию должно составлять не менее 2 часов.

Очень важно помнить, что для сегментов ACK, не содержащих данных, протокол TCP не обеспечивает гарантии доставки. Следовательно, при реализации механизма keep-alive сбои в ответ на специфические проверки не должны интерпретироваться как «умирание» соединения.

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

Обсуждение

Механизм keep-alive периодически проверяет удаленную сторону при простое соединения, даже если отсутствуют неподтвержденные данные. Спецификация TCP не включает механизма keep-alive, поскольку он: (1) может обрывать нормальные соединения в результате транзитных сбоев Internet, (2) приводит к ненужному расходу полосы и (3) повышает расходы для соединений Internet с платным трафиком.

Некоторые реализации TCP все же включают механизм keep-alive. Для подтверждения работоспособности бездействующего соединения такие реализации передают пробные сегменты, предназначенные для получения отклика удаленной стороны. Такие сегменты в общем случае включают поле SEG.SEQ=SND.NXT-1 и могут также содержать один произвольный октет данных. Отметим, что для бездействующих соединений SND.NXT=RCV.NXT, поэтому значение SEG.SEQ будет выходить за пределы окна. Следовательно, пробный сегмент будет заставлять приемник вернуть сегмент подтверждения, говорящий о том, что соединение сохраняет работоспособность. Если удаленная сторона разорвала соединение, она будет возвращать RST вместо подтверждающего сегмента.

К несчастью, в некоторых не вполне корректных реализациях TCP возникают сбои при получении сегмента с SEG.SEQ = SND.NXT-1, если такой сегмент не содержит данных. Приложение может дополнительно проверить, способна ли удаленная сторона корректно отвечать на пакеты keep-alive без вставленного в них произвольного октета данных.

Механизм TCP keep-alive следует использовать только в серверных приложениях, которые могут неограниченно долго сохранять соединения, потребляя без нужды сетевые ресурсы, даже если клиент по тем или иным причинам разорвал или потерял соединение.

4.2.3.7 Многодомные хосты TCP

Если приложение на многодомном хосте не указывает локальный IP-адрес при активной организации соединения TCP, протокол TCP должен запрашивать уровень IP для получения локального IP-адреса до (первой) передачи SYN. Более подробные сведения приведены в параграфе 3.4 – функция GET_SRCADDR().

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

4.2.3.8 Опции IP

При передаче опций на уровень TCP со стороны IP, протокол TCP должен игнорировать непонятные опции.

TCP может поддерживать опции Time Stamp и Record Route.

Приложениям должна обеспечиваться возможность задания source route при активной организации соединения TCP и этот маршрут должен иметь преимущество перед source route из принятой дейтаграммы.

При пассивной организации соединения TCP и достижении пакетом конечной точки, указанной опцией IP Source Route (содержащей путь возврата), протокол TCP должен сохранить маршрут возврата и использовать его для всех сегментов, передаваемых через это соединение. Если в последующих сегментах приходит иной маршрут source route, новый маршрут следует использовать взамен прежнего.

4.2.3.9 Сообщения ICMP

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

• Source Quench Протокол TCP должен реагировать на сообщения Source Quench замедлением передачи через соединение. Для реализации этого следует использовать процедуру как при тайм-ауте повторной передачи.
• Destination Unreachable – коды 0, 1, 5 Поскольку такие сообщения говорят о кратковременных ошибках, протокол TCP не должен прерывать соединение; рекомендуется передать эту информацию приложению.

Обсуждение

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

• Destination Unreachable – коды 2-4 Эти сообщения говорят о серьезных ошибках, поэтому следует разрывать соединения TCP.
• Time Exceeded – коды 0, 1 Эти ошибки трактуются аналогично Destination Unreachable с кодами 0, 1, 5 (см. выше).
• Parameter Problem Эти ошибки трактуются аналогично Destination Unreachable с кодами 0, 1, 5 (см. выше).

4.2.3.10 Проверка корректности удаленного адреса

Реализация TCP должна отбрасывать (как ошибочные) локальные вызовы OPEN с некорректным IP-адресом удаленной стороны (например, широковещательный или групповой адрес).

Входящие запросы SYN с некорректным адресом отправителя должны игнорироваться уровнем TCP или IP (см. 3.2.1.3).

Реализация TCP должна без уведомления отбрасывать все входящие сегменты SYN с широковещательными или групповыми адресами.

4.2.3.11 Картины трафика TCP

Реализация

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

• Односимвольные сегменты Даже при использовании передающей стороной алгоритма Nagle соединения TCP для удаленного входа в систему через ЛВС с малой задержкой будут порождать поток односимвольных сегментов. Если на удаленном терминале включен режим эхо-символов, принимающая сторона будет в общем случае генерировать отклик на каждый принятый символ.
• Передача больших объемов данных При использовании TCP для передачи большого объема данных поток почти полностью будет состоять из сегментов размером MSS (эффективное значение). Хотя TCP использует пространство порядковых номеров с байтовой (октетной) гранулярностью, при передаче больших объемов данных должны учитываться только сегменты.

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

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

4.2.3.12 Эффективность

Реализация

На основании накопленного опыта выработаны рекомендации для разработчиков TCP.

1. Не копируйте данные При передаче больших объемов данных наибольшую нагрузку на процессор создает копирование данных из одного места в другое для определения контрольной суммы. Важно минимизировать число копий данных TCP. Поскольку передача данных через шину памяти может существенно ограничивать скорость, полезно объединять копирование данных с вычислением контрольных сумм.
2. Внимательно относитесь к вычислению контрольных сумм Хорошие программы вычисления контрольных сумм TCP обычно в 2-5 раз быстрее, по сравнению с простой реализацией определений CRC. Для эффективного вычисления контрольных сумм требуется программирование высокого класса (см. [TCP:10]).
3. Код общего назначения Обработка протокола TCP может быть сложной, но для большинства сегментов используется лишь несколько простых решений. Посегментная обработка существенно ускоряется за счет эффективного кодирования основной линии с минимизацией числа принимаемых решений для наиболее вероятных ситуаций.

4.2.4 Интерфейс между TCP и прикладным уровнем

4.2.4.1 Асинхронные отчеты

Должен обеспечиваться механизм информирования приложений о некритичных ошибках TCP. В общем случае это реализуется с помощью прикладной процедуры ERROR_REPORT, которая может асинхронно [INTRO:7] вызываться с транспортного уровня:

ERROR_REPORT(local connection name, reason, subreason)

Кодирование причин ошибок не рассматривается здесь, однако сообщения, асинхронно передаваемые приложениям, должны включать:

• полученные сообщения ICMP об ошибках (см. 4.2.3.9);
• информацию о многократных повторах передачи (см. 4.2.3.5);
• анонсы указателей срочности (см. 4.2.2.4).

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

Обсуждение

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

4.2.4.2 Тип обслуживания

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

Значение TOS задается независимо для каждого направления в соединении, поэтому принимающее приложение будет задавать TOS для сегментов ACK.

TCP может передавать приложениям последнее использованное значение TOS из принятых сегментов.

Обсуждение

Некоторые приложения (например, SMTP) меняют тип обмена данными во время соединения и, следовательно, могут пожелать изменить значение TOS.

Отметим также, что вызов OPEN в соответствии с RFC 793 включает параметр options, в котором могут быть заданы опции IP (source route, record route, timestamp).

4.2.4.3 Вызов Flush

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

4.2.4.4 Многодомные хосты

Пользовательский интерфейс, описанный в параграфах 2.7 и 3.8 RFC 793, требует расширения для многодомных хостов. Функция OPEN должна поддерживать необязательный параметр с локальным адресом:

OPEN( ... [local IP address,] ... )

Обсуждение

Некоторые приложения на базе TCP (например, FTP) требуют указывать локальный IP-адрес, который используется для организации соединения.

Реализация

Пассивный вызов OPEN с заданным локальным адресом IP будет ждать входящего запроса на соединение с этим адресом. Если параметр не указан, пассивный вызов OPEN будет ждать запроса на входящее соединение по любому локальному адресу IP и потом связывать локальный IP-адрес с этим соединением.

Для активных вызовов OPEN указанный локальный IP-адрес будет использоваться для организации соединения. Если параметр не задан, сетевая программа будет выбирать подходящий локальный адрес IP (см. 3.3.4.2) для организации соединения.

4.2.5 Требования к протоколу TCP

Функция	Параграф	Требование
Флаг Push
Объединение или очередь при отсутствии флага Push	4.2.2.2	Возможно
Передающая сторона удаляет последовательные флаги Push	4.2.2.2	Следует
При вызове функции SEND можно установить Push	4.2.2.2	Возможно
При отсутствии Push бесконечный буфер передачи	4.2.2.2	Недопустимо
При отсутствии Push установка PSH для последнего сегмента	4.2.2.2	Обязательно
Уведомление принимающей программы о PSH	4.2.2.2	Возможно
Передача по возможности сегментов максимального размера	4.2.2.2	Следует
Окно
Размер трактуется как беззнаковое целое	4.2.2.3	Обязательно
Поддержка 32-битового поля размера	4.2.2.3	Следует
Сокращение окна справа	4.2.2.16	Не следует
Устойчивость к сокращению окна	4.2.2.16	Обязательно
Неопределенное закрытие окна приемником	4.2.2.17	Возможно
Отправитель проверяет нулевое окно	4.2.2.17	Обязательно
Первая проверка после RTO	4.2.2.17	Следует
Экспоненциальное увеличение интервала проверки	4.2.2.17	Следует
Возможность неопределенного обнуления окна	4.2.2.17	Обязательно
Тайм-аут для нормального соединения с нулевым окном	4.2.2.17	Недопустимо
Срочные данные
Указатель на последний октет	4.2.2.4	Обязательно
Последовательности срочных данных произвольной длины	4.2.2.4	Обязательно
Асинхронное уведомление приложений о срочных данных	4.2.2.4	Обязательно
Приложение может узнавать о наличии срочных данных	4.2.2.4	Обязательно
Опции TCP
Получение опций в любом сегменте	4.2.2.5	Обязательно
Игнорировать неподдерживаемые опции	4.2.2.5	Обязательно
Устойчивость к опциям некорректного размера	4.2.2.5	Обязательно
Реализация приема и передачи опции MSS	4.2.2.6	Обязательно
Передача опции MSS, если максимальный размер не равен 536	4.2.2.6	Следует
Передача опции MSS во всех случаях	4.2.2.6	Возможно
Значение MSS для передачи по умолчанию равно 536	4.2.2.6	Обязательно
Расчет эффективного размера сегмента передачи	4.2.2.6	Обязательно
Контрольные суммы TCP
Отправитель рассчитывает контрольную сумму	4.2.2.7	Обязательно
Получатель проверяет контрольную сумму	4.2.2.7	Обязательно
Установка начального номера по текущему времени	4.2.2.9	Обязательно
Организация соединений
Поддержка одновременных попыток	4.2.2.10	Обязательно
SYN-RCVD помнит последнее состояние	4.2.2.11	Обязательно
Пассивные вызовы CALL могут мешать друг другу	4.2.2.18	Недопустимо
Функция одновременного прослушивания для одного порта	4.2.2.18	Обязательно
Запрос адреса отправителя на уровне IP при необходимости	4.2.3.7	Обязательно
В противном случае использовать локальные адреса соединения	4.2.3.7	Обязательно
OPEN для групповых и широковещательных IP-адресов	4.2.2.14	Недопустимо
Отбрасывание сегментов для групповых/широковещательных адресов	4.2.2.14	Обязательно
Завершение соединений
Сегмент RST может содержать данные	4.2.2.12	Следует
Информирование приложений о разрыве соединения	4.2.2.13	Обязательно
Полудуплексное закрытие соединений	4.2.2.13	Возможно
Передача RST для индикации потери данных	4.2.2.13	Следует
Сохранять состояние TIME-WAIT в течение 2 x MSL	4.2.2.13	Обязательно
Восприятие новых SYN во время TIME-WAIT	4.2.2.13	Возможно
Повторная передача
Алгоритм Jacobson Slow Start	4.2.2.15	Обязательно
Алгоритм Jacobson Congestion-Avoidance	4.2.2.15	Обязательно
Повторная передача с сохранением идентификации IP	4.2.2.15	Возможно
Алгоритм Karn	4.2.3.1	Обязательно
Алгоритм Якобсона для оценки RTO	4.2.3.1	Обязательно
Экспоненциальное увеличение тайм-аута	4.2.3.1	Обязательно
Расчет SYN RTO как для данных	4.2.3.1	Следует
Рекомендуемые начальные значения и границы	4.2.3.1	Следует
Генерация подтверждений (ACK)
Очередь для сегментов с нарушением порядка	4.2.2.20	Следует
Обработка всей очереди до передачи подтверждения	4.2.2.20	Обязательно
Передача ACK для сегментов с нарушением порядка	4.2.2.21	Возможно
Отложенные подтверждения	4.2.3.2	Следует
Задержка < 0.5 сек	4.2.3.2	Обязательно
Подтверждается каждый 2-ой сегмент полного размера	4.2.3.2	Обязательно
Алгоритм предотвращения SWS на приемной стороне	4.2.3.3	Обязательно
Передача данных
Настраиваемое значение TTL	4.2.2.19	Обязательно
Алгоритм предотвращения SWS на передающей стороне	4.2.3.4	Обязательно
Алгоритм Nagle	4.2.3.4	Следует
Приложение может отключить алгоритм Nagle	4.2.3.4	Обязательно
Сбои в соединениях
Негативный анонс для IP при достижении R1	4.2.3.5	Обязательно
Закрытие соединения при достижении R2	4.2.3.5	Обязательно
Приложения могут устанавливать R2	4.2.3.5	Обязательно
Информировать прикладной уровень после R1, но до R2	4.2.3.5	Следует
Рекомендуемые значения для R1 и R2	4.2.3.5	Следует
Поддержка такого же механизма для SYN	4.2.3.5	Обязательно
Значение R2 для SYN не менее 3 минут	4.2.3.5	Обязательно
Передача пакетов Keep-Alive	4.2.3.6	Возможно
Приложение может передавать запросы	4.2.3.6	Обязательно
По умолчанию механизм отключен	4.2.3.6	Обязательно
Возможность передачи только во время бездействия	4.2.3.6	Обязательно
Возможность настройки интервала	4.2.3.6	Обязательно
По умолчанию интервал не менее 2 часов	4.2.3.6	Обязательно
Устойчивость к потере подтверждений	4.2.3.6	Обязательно
Опции IP
Игнорировать опции, не понятные TCP	4.2.3.8	Обязательно
Поддержка временных меток	4.2.3.8	Возможно
Поддержка записи маршрута	4.2.3.8	Возможно
Source Route
Возможность задать из приложения	4.2.3.8	Обязательно
Переписывание Source Route в дейтаграммах	4.2.3.8	Обязательно
Построение маршрута возврата по исходному	4.2.3.8	Обязательно
Изменение Source Route дял новых сегментов	4.2.3.8	Следует
Прием сообщений ICMP от уровня IP	4.2.3.9	Обязательно
Destination Unreach (0,1,5) => информировать приложение	4.2.3.9	Следует
Destination Unreach (0,1,5) => разорвать соединение	4.2.3.9	Недопустимо
Destination Unreach (2-4) => разорвать соединение	4.2.3.9	Следует
Source Quench => замедленный старт	4.2.3.9	Следует
Time Exceeded => информировать приложение без разрыва соединения	4.2.3.9	Следует
Param Problem => информировать приложение без разрыва соединения	4.2.3.9	Следует
Проверка адресов
Отказ для вызовов CALL с неверным адресом IP	4.2.3.10	Обязательно
Отказ для SYN от некорректных адресов IP	4.2.3.10	Обязательно
Отбрасывание без уведомления SYN с широковещательными/групповыми адресами	4.2.3.10	Обязательно
Интерфейс между TCP и приложениями
Механизм информирования об ошибках	4.2.4.1	Обязательно
Приложение может отключать информирование об ошибках	4.2.4.1	Следует
Приложение может задавать TOS для передачи	4.2.4.2	Обязательно
Передача без изменений на уровень IP	4.2.4.2	Следует
Приложение может менять TOS для действующего соединения	4.2.4.2	Следует
Передача приложению полученного TOS	4.2.4.2	Возможно
Вызов FLUSH	4.2.4.3	Возможно
Адрес IP как необязательный параметр OPEN	4.2.4.4	Обязательно

5. Литература

Введение

[INTRO:1] “Requirements for Internet Hosts — Application and Support⁵¹,” IETF Host Requirements Working Group, R. Braden, Ed., RFC 1123, October 1989.

[INTRO:2] “Requirements for Internet Gateways,” R. Braden and J. Postel, RFC 1009⁵², June 1987.

[INTRO:3] “DDN Protocol Handbook,” NIC-50004, NIC-50005, NIC-50006, (three volumes), SRI International, December 1985.

[INTRO:4] “Official Internet Protocols,”⁵³ J. Reynolds and J. Postel, RFC 1011, May 1987.

[INTRO:5] “Protocol Document Order Information,” O. Jacobsen and J. Postel, RFC 980, March 1986.

[INTRO:6] “Assigned Numbers,” J. Reynolds and J. Postel, RFC 1010¹, May 1987.

[INTRO:7] “Modularity and Efficiency in Protocol Implementations,” D. Clark, RFC 817, July 1982.

[INTRO:8] “The Structuring of Systems Using Upcalls,” D. Clark, 10th ACM SOSP, Orcas Island, Washington, December 1985.

Дополнительная информация

[INTRO:9] “A Protocol for Packet Network Intercommunication,” V. Cerf and R. Kahn, IEEE Transactions on Communication, May 1974.

[INTRO:10] “The ARPA Internet Protocol,” J. Postel, C. Sunshine, and D. Cohen, Computer Networks, Vol. 5, No. 4, July 1981.

[INTRO:11] “The DARPA Internet Protocol Suite,” B. Leiner, J. Postel, R. Cole and D. Mills, Proceedings INFOCOM 85⁵⁴, IEEE, Washington DC, March 1985.

[INTRO:12] “Final Text of DIS8473, Protocol for Providing the Connectionless Mode Network Service,”⁵⁵ ANSI, March 1986.

[INTRO:13] “End System to Intermediate System Routing Exchange Protocol,” ANSI X3S3.3⁵⁶, April 1986.

Канальный уровень

[LINK:1] “Trailer Encapsulations,” S. Leffler and M. Karels, RFC 893, April 1984.

[LINK:2] “An Ethernet Address Resolution Protocol,” D. Plummer, RFC 826⁵⁷, November 1982.

[LINK:3] “A Standard for the Transmission of IP Datagrams over Ethernet Networks,” C. Hornig, RFC 894, April 1984.

[LINK:4] “A Standard for the Transmission of IP Datagrams over IEEE 802 Networks,” J. Postel and J. Reynolds, RFC 1042, February 1988.

Уровень IP

[IP:1] “Internet Protocol (IP),” J. Postel, RFC 791, September 1981.

[IP:2] “Internet Control Message Protocol (ICMP),” J. Postel, RFC 792, September 1981.

[IP:3] “Internet Standard Subnetting Procedure,” J. Mogul and J. Postel, RFC 950, August 1985.

[IP:4] “Host Extensions for IP Multicasting,” S. Deering, RFC 1112⁵⁸, August 1989.

[IP:5] “Military Standard Internet Protocol,” MIL-STD-1777⁵⁹, Department of Defense, August 1983.

[IP:6] “Some Problems with the Specification of the Military Standard Internet Protocol,” D. Sidhu, RFC 963, November 1985.

[IP:7] “The TCP Maximum Segment Size and Related Topics,”⁶⁰ J. Postel, RFC 879, November 1983.

[IP:8] “Internet Protocol Security Options,” B. Schofield, RFC 1108, October 1989.

[IP:9] “Fragmentation Considered Harmful,”⁶¹ C. Kent and J. Mogul, ACM SIGCOMM-87, August 1987. Published as ACM Comp Comm Review, Vol. 17, no. 5.

[IP:10] “IP Datagram Reassembly Algorithms,”⁶² D. Clark, RFC 815, July 1982.

[IP:11] “Fault Isolation and Recovery,” D. Clark, RFC 816, July 1982.

Дополнительная информация

[IP:12] “Broadcasting Internet Datagrams in the Presence of Subnets,” J. Mogul, RFC 922⁶³, October 1984.

[IP:13] “Name, Addresses, Ports, and Routes,” D. Clark, RFC 814, July 1982.

[IP:14] “Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQUID)⁶⁴,” W. Prue and J. Postel, RFC 1016, July 1987.

Протокол UDP

[UDP:1] “User Datagram Protocol,” J. Postel, RFC 768, August 1980.

Протокол TCP

[TCP:1] “Transmission Control Protocol,” J. Postel, RFC 793, September1981.

[TCP:2] “Transmission Control Protocol,” MIL-STD-1778⁶⁵, US Department of Defense, August 1984.

[TCP:3] “Some Problems with the Specification of the Military Standard Transmission Control Protocol,” D. Sidhu and T. Blumer, RFC 964, November 1985.

[TCP:4] “The TCP Maximum Segment Size and Related Topics,” J. Postel, RFC 879, November 1983.

[TCP:5] “Window and Acknowledgment Strategy in TCP,” D. Clark, RFC 813, July 1982.

[TCP:6] “Round Trip Time Estimation,” P. Karn & C. Partridge, ACM SIGCOMM-87, August 1987.

[TCP:7] “Congestion Avoidance and Control,” V. Jacobson, ACM SIGCOMM-88, August 1988.

Дополнительная информация

[TCP:8] “Modularity and Efficiency in Protocol Implementation,” D. Clark, RFC 817, July 1982.

[TCP:9] “Congestion Control in IP/TCP,” J. Nagle, RFC 896, January 1984.

[TCP:10] “Computing the Internet Checksum,” R. Braden, D. Borman, and C. Partridge, RFC 1071¹¹, September 1988.

[TCP:11] “TCP Extensions for Long-Delay Paths,” V. Jacobson & R. Braden, RFC 1072⁶⁶, October 1988.

Вопросы безопасности

С программами различных коммуникационных уровней хостов связано множество вопросов безопасности, но их обсуждение выходит за рамки данного RFC.

Архитектура Internet в общем случае обеспечивает весьма слабую защиту против подмены IP-адресов отправителя, поэтому любой механизм обеспечения безопасности на основе IP-адресов отправителей должен применяться с осторожностью. Однако в ограниченной среде некоторая проверка адресов отправителей становится вполне возможной. Например, можно создать безопасную ЛВС, входной маршрутизатор которой будет отбрасывать любые дейтаграммы, где в качестве отправителя указан внутренний адрес локальной сети. В этом случае хост ЛВС может различать внешние и внутренние хосты по адресу отправителя. Проблема усложняется при задании маршрута отправителем и существуют предложения запретить хостам рассылку дейтаграмм source-route из соображений безопасности (см. 3.3.5).

Вопросы безопасности рассматриваются в параграфах, связанных с опцией IP Security (см. 3.2.1.8), сообщениями ICMP Parameter Problem (см. 3.2.2.5), опциями IP в дейтаграммах UDP (см. 4.1.3.2) и резервированием портов TCP (см. 4.2.2.1).

Адрес автора

Robert Braden USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695 Телефон: (213) 822 1511 EMail: Braden@ISI.EDU

---

Перевод на русский язык Николай Малых nmalykh@gmail.com