RFC: 4413
Оригинал: TCP/IP Field Behavior
Категория: Информационный
Дата публикации:
Авторы: ,
Перевод: Николай Малых

5.3. Доля заголовков TCP

При передаче больших объемов данных TCP доля заголовков TCP невелика по сравнению с общим размером пакетов (например, < 3% для пакетов размером 1460 октетов) и сравнима с долей заголовков в типичном голосовом потоке RTP. Очевидно, что спектральная эффективность является важной целью. Однако «выжимание последних битов» при компрессии дает незначительное повышение эффективности при существенном росте сложности. При создании профилей компрессии TCP нужно искать компромисс между эффективностью и сложностью.

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

Существует множество схем работы с подтверждениями TCP, позволяющих снизить расход полосы на передачу ACK. Многие из таких схем описаны в документах [33] и [32]. Большинство этих схем полностью совместимо с компрессией заголовков без каких-либо дополнительных усилий. Хотя и не предполагается оптимизация схем компрессии для экспериментальных опций, полезно учитывать эти опции при разработке схем компрессии (и наоборот, учитывать схемы компрессии при создании новых опций). Схема компрессии заголовков должна быть способна поддерживать любые опции, включая те, которые еще не определены.

5.4. Независимость полей и поведение пакетов

Ясно, что прямое сравнение с сильно ориентированной на пакеты компрессией RTP достаточно сложно. Поля заголовков RTP имеют тенденцию регулярных изменений от пакета к пакету, а многие поля (например, IPv4 IP ID, порядковый номер RTP, временные метки RTP) изменяются в зависимости одно от другого. Однако поля TCP (такие, как порядковый номер) менее предсказуемы отчасти в результате влияния внешних факторов (размеры окна TCP, поведение приложение и т. п.). Значения полей также изменяются независимо. Все это в целом дает дополнительные стимулы для выполнения компрессии и осложняет выбор набора вариантов кодирования, который обеспечит эффективность в сочетании с устойчивостью к ошибкам.

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