RFC: 1122
Оригинал: Requirements for Internet Hosts - Communication Layers
Категория: Стандарт Интернета
Дата публикации:
Автор:
Перевод: Николай Малых
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 использует эвристические методы для выбора последнего обновления окна вопреки возможному изменению порядка дейтаграмм. В результате может быть проигнорировано обновление окна на меньшее, которое было предложено ранее, если не увеличивается ни порядковый номер, ни номер подтверждения.

Страница 66 из 86

2007 - 2022 © Русские переводы RFC, IETF, ISOC.