AAA

RFC 4413 — Поведение полей TCP/IP

Статус документа

В этом документе содержится информация для сообщества Internet. Документ не задает каких-либо стандартов Internet. Допускается свободное распространение документа.

Тезисы

В этом документе описано поведение полей TCP/IP в контексте сжатия заголовков. Такое сжатие возможно благодаря тому, что большинство полей заголовка незначительно отличается от пакета к пакету. Многие из полей являются статическими или меняются более или менее предсказуемо. При разработке схем компрессии заголовков весьма важно понимать поведение полей. Примером такого анализа может служить RFC 3095. Данный документ играет аналогичную роль для сжатия заголовков TCP/IP.

Оглавление

1. Введение

В этом документе описывается формат заголовков TCP/IP и поведение полей заголовка (т. е., изменение этих полей в потоке TCP). Описание приводится в контексте сжатия заголовков.

Поскольку поведение заголовков IP несколько отличается от описанного ранее в RFC 3095 [31] для протоколов UDP и RTP, эти заголовки также рассматриваются здесь.

Этот документ заимствует множество классификационных фрагментов из RFC 3095 вместо включения ссылок на этот документ.

Согласно формату, представленному в RFC 3095 [31], поля заголовков TCP/IP классифицируются и анализируются в два этапа. Сначала мы проводим общую классификацию (глава 2), в которой поля подразделяются на основе установившихся сведений и допущений. Эта общая классификация не принимает во внимание изменение характеристик полей, в той или иной степени зависящее от реализации или используемого приложения. В главе 3 рассматривается вопрос использования значений полей для оптимизации короткоживущих потоков. Более детальный анализ изменения характеристик приводится в главе 4. В заключение глава 5 описывает обработку полей заголовков с учетом их оптимального сжатия.

Основным вопросом является определение базы для рассмотрения имеющихся реализаций TCP/IP. Этот обзор основан на анализе развернутых в настоящее время реализаций TCP, которые поддерживают стандартизованные IETF механизмы.

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

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

2. Общая классификация

Приведенные ниже определения (и часть текста) скопированы из Приложения A в RFC 3095 [31]. Отличия в поведении полей IP от RFC 3095 [31] (например, поведение IP/UDP/RTP для аудио и видео-приложений) явно указываются в этом документе.

Далее в документе термин «сессия» будет использоваться для потока пакетов TCP, представляющего собой серию пакетов с одинаковыми адресами IP и номерами портов. Поток пакетов определяется некими полями (см. ниже STATIC-DEF) и может рассматриваться как подмножество сессии. Более детально разделение сессий на потоки пакетов для сжатия заголовков рассматривается в документе [31].

Заголовки пакетов делятся на 5 классов:

В этой главе каждое поле заголовков IP и TCP относится к тому или иному классу. Для всех полей, кроме класса CHANGING, приводится также обоснование этой классификации. В главе 4 проводится дополнительное рассмотрение и классификация полей CHANGING на основе их предполагаемого поведения.

2.1. Поля заголовка IP

2.1.1. Поля заголовка IPv6

ПолеРазмер в битахКласс
Version4STATIC
DSCP6ALTERNATING
Флаг ECT1CHANGING
Флаг CE1CHANGING
Flow Label20STATIC-DEF
Payload Length16INFERRED
Next Header8STATIC
Hop Limit8CHANGING
Source Address128STATIC-DEF
Destination Address128STATIC-DEF
Рисунок 1: Поля заголовка IPv6

Differs from RFC 3095 [31]. (The DSCP, ECT, and CE flags were amalgamated into the Traffic Class octet in RFC 3095).

Суммарные размеры полей каждого класса показаны на рисунке 2:

КлассРазмер в октетах
INFERRED2
STATIC1,5
STATIC-DEF34,5
STATIC-KNOWN0
CHANGING2
Рисунок 2: Размеры полей

2.1.2. Поля заголовка IPv4

ПолеРазмер в битахКласс
Version4STATIC
Header Length4STATIC-KNOWN
DSCP6ALTERNATING
Флаг ECT1CHANGING
Флаг CE1CHANGING
Packet Length16INFERRED
Identification16INFERRED
Reserved Flag1CHANGING
Флаг запрета фрагментирования1CHANGING
Флаг наличия дополнительных фрагментов1STATIC-KNOWN
Fragment Offset13STATIC-KNOWN
Time To Live8CHANGING
Protocol8STATIC
Header Checksum16INFERRED
Source Address32STATIC-DEF
Destination Address32STATIC-DEF
Рисунок 3: Поля заголовка IPv4

Общие размеры заголовков разного класса показаны на рисунке 4:

КлассРазмер в октетах
INFERRED4
STATIC1,5
STATIC-DEF8
STATIC-KNOWN2,25
CHANGING4,25
Рисунок 4: Размеры полей

2.2. Поля заголовка TCP

ПолеРазмер в битахКласс
Source Port16STATIC-DEF
Destination Port16STATIC-DEF
Sequence Number32CHANGING
Acknowledgement Num32CHANGING
Data Offset4CHANGING
Резерв4CHANGING
Флаг CWR1CHANGING
Флаг ECE1CHANGING
Флаг URG1CHANGING
Флаг ACK1CHANGING
Флаг PSH1CHANGING
Флаг RST1CHANGING
Флаг SYN1CHANGING
Флаг FIN1CHANGING
Window16CHANGING
Checksum16CHANGING
Urgent Pointer16CHANGING
Options0(-352)CHANGING
Рисунок 5: Поля заголовка TCP

2.3. Общие размеры для IP/TCP

В целом поля разных классов в заголовках IP/TCP имеют следующие размеры:

КлассЧисло октетов
IPv6IPv4
INFERRED2,54,5
STATIC1,51,5
STATIC-DEF38,512
STATIC-KNOWN-2,25
CHANGING17,2519,75
Всего6040
Рисунок 6: Суммарные размеры полей

Опции класса CHANGING не учитывались.

3. Классификация повторяющихся полей заголовков

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

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

Отметим, что репликация основывается на контексте (а не просто на значениях полей) и созданные при сжатии (compressorcreated0 поля также могут включаться в этот контекст. Эти поля, естественно, зависят от используемого протокола сжатия (профиля ROHC).

Варианты возможности репликации для полей TCP/IP перечислены ниже:

3.1. Заголовок IPv4 (внутренний и/или внешний)

ПолеКлассРепликация
VersionSTATICN/A
Header LengthSTATIC-KNOWNN/A
DSCPALTERNATINGNo (1)
Флаг ECTCHANGINGNo (2)
Флаг CECHANGINGNo (2)
Packet LengthINFERREDN/A
IdentificationINFERREDYes (3)
Reserved FlagCHANGINGNo (4)
Флаг DFCHANGINGYes (5)
Флаг MFSTATIC-KNOWNN/A
Fragment OffsetSTATIC-KNOWNN/A
Time To LiveCHANGINGYes
ProtocolSTATICN/A
Header ChecksumINFERREDN/A
Source AddressSTATIC-DEFYes
Destination AddressSTATIC-DEFYes
Рисунок 7: Заголовок IPv4
  1. Поле DSCP маркируется в соответствии с требованиями приложения. Если можно предположить, что реплицируемые соединения относятся к одному классу diffserv, очевидно, что значения DSCP будут реплицируемыми. Значение DSCP может устанавливать не только отправитель, но и любой, кому позволено маркировать пакеты. Таким образом, пакет может использовать множество значений DSCP в разных точках сети. Однако компрессия заголовках используется на соединениях «точка-точка», поэтому значение данного можно считать сравнительно стабильным. Если выполняется перемаркировка на основе состояния измерителя, значение поля может измениться посреди потока. В целом мы полагаем, что репликация DSCP будет полезна для сжатия заголовков.

  2. Поле ECN невозможно реплицировать (отметим, что ожидается использование схемы ECN nonce [19]). Однако представляется очевидным, что все потоки TCP между хостами, поддерживающими ECN, будут применять ECN, поэтому использование ECN (или отказ от него) для потоков между одной парой хостов можно рассматривать как реплицируемое. См. также (4).

  3. Реплицируемый контекст для этого поля включает флаги IP-ID, NBO и RND (как описано в ROHC RTP). Это подчеркивает, что репликация происходит для контекста, а не просто для отдельных значений полей и, таким образом, должна рассматриваться с учетом точной природы компрессии, используемой для каждого поля.

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

  5. Теоретически бит DF можно реплицировать. Однако, практическая польза этого не очевидна. С точки зрения сжатия заголовков очевидно, что явная передача этого 1-битового флага не потребует большего объема, нежели индикация возможности реплицирования. Мы не включаем флаг DF в число реплицируемых.

3.2. Заголовок IPv6 (внутренний и/или внешний)

ПолеКлассРепликация
VersionSTATICN/A
Traffic ClassCHANGINGYes (1)
Флаг ECTCHANGINGNo (2)
Флаг CECHANGINGNo (2)
Flow LabelSTATIC-DEFN/A
Payload LengthINFERREDN/A
Next HeaderSTATICN/A
Hop LimitCHANGINGYes
Source AddressSTATIC-DEFYes
Destination AddressSTATIC-DEFYes
Рисунок 8: Заголовок IPv6
  1. См. примечание для поля DSCP в заголовке IPv4 (п. 1, выше).
  2. См. примечание для флагов ECT и CE в заголовке IPv4 (п. 2, выше).

3.3. Заголовок TCP

ПолеКлассРепликация
Source PortSTATIC-DEFYes (1)
Destination PortSTATIC-DEFYes (1)
Sequence NumberCHANGINGNo (2)
Acknowledgement NumCHANGINGNo
Data OffsetCHANGINGN/A
РезервCHANGINGNo (3)
Флаг CWRCHANGINGNo (4)
Флаг ECECHANGINGNo (4)
Флаг URGCHANGINGNo
Флаг ACKCHANGINGNo
Флаг PSHCHANGINGNo
Флаг RSTCHANGINGNo
Флаг SYNCHANGINGNo
Флаг FINCHANGINGNo
WindowCHANGINGYes
ChecksumCHANGINGNo
Urgent PointerCHANGINGYes (5)
Рисунок 9: Заголовок TCP
  1. Очевидно, что номер порта на серверной стороне относится к числу общепринятых (well-known). На клиентской стороне номер порта обычно выбирается стеком протоколов автоматически. Возможность репликации номера зависит от того, как стек протоколов выбирает номера портов. Хотя наиболее популярные реализации используют последовательное выделение номеров, расчет на такое поведение может оказаться нежелательным.

  2. Рекомендация (и ожидаемое развертывание) использования случайных значений для начальных порядковых номеров TCP в соответствии с RFC 1948 [10] делает невозможным совместное использование порядковых номеров. Таким образом, это поле не может считаться реплицируемым.

  3. См. выше комментарий (4) для полей заголовка IPv4.

  4. См. выше комментарий (2) для флага ECN в заголовке IPv4.

  5. Указатель срочности используется очень редко. Это означает, что на практике поле может рассматриваться как реплицируемое.

3.4. Опции TCP

ОпцияТолько SYN (1)Репликация
End of Option ListNoNo (2)
No-OperationNoNo (2)
Maximum Segment SizeYesYes
Window ScaleYesYes
SACK-PermittedYesYes
SACKNoNo
TimestampNoNo
Рисунок 10: Опции TCP
  1. Эта колонка показывает, что данная опция может использоваться только в пакетах SYN (Yes) или в других пакетах также (No). Многие опции TCP используются только в пакетах SYN. Некоторые опции (например, MSS, Window Scale и SACKPermitted) имеют тенденцию сохранять свои значения в потоке пакетов.

    Таким образом, для поддержки контекста совместного использования системе компрессии следует такие опции TCP в контексте (даже если они появляются только в сегментах SYN).

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

3.5. Сводные данные по репликации

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

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

4. Анализ картины изменения полей заголовков

Для создания подходящего механизма эффективной компрессии всех полей заголовка следует проанализировать картину изменения этих полей. Для такого анализа здесь вводится дополнительная классификация полей, которые в главе 2 были отнесены к классу CHANGING (изменяющиеся).

Поля класса CHANGING разделены на 5 дополнительных субклассов:

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

При классификации полей принимались во внимание дополнительные сведения и/или диапазоны возможных изменений. Для полей класса STATIC или SEMISTATIC значение поля может относиться не только к классу STATIC но быть также заранее известным (KNOWN) общепринятым значением (два состояния для полей SEMISTATIC). Для полей с непредсказуемым поведением может быть известно, что обычно изменения происходят в ограниченном (LIMITED) диапазоне всех возможных значений. Для остальных полей значения совершенно неизвестны (UNKNOWN).

На рисунке 11 показана классификация полей класса CHANGING на основе предполагаемой картины их изменения. (4) относится к полям IPv4, а (6) — к полям IPv6.

ПолеЗначение/диапазонКлассДополнительные сведения
DSCP(4) / Traffic-Class (6)ЗначениеALTERNATINGUNKNOWN
Флаг IP ECT (4)ЗначениеRCUNKNOWN
Флаг IP CE (4)ЗначениеRCUNKNOWN
IP Id (4) последовательныйДиапазонSTATICKNOWN
IP Id (4) — увеличениеДиапазонRCLIMITED
IP Id (4) случайныйЗначениеIRREGULARUNKNOWN
Флаг IP DF (4)ЗначениеRCUNKNOWN
IP TTL(4) / Hop Lim(6)ЗначениеALTERNATINGLIMITED
Порядковый номер TCPДиапазонIRREGULARLIMITED
Номер подтверждения TCPДиапазонIRREGULARLIMITED
TCP ReservedЗначениеRCUNKNOWN
Флаг ECNЗначениеIRREGULARUNKNOWN
Флаг CWRЗначениеIRREGULARUNKNOWN
Флаг ECEЗначениеIRREGULARUNKNOWN
Флаг URGЗначениеIRREGULARUNKNOWN
Флаг ACKЗначениеIRREGULARKNOWN
Флаг PSHЗначениеIRREGULARUNKNOWN
Флаг RSTЗначениеIRREGULARUNKNOWN
Флаг SYNЗначениеIRREGULARKNOWN
Флаг FINЗначениеIRREGULARKNOWN
Окно TCPЗначениеALTERNATINGKNOWN
Контрольная сумма TCPЗначениеIRREGULARUNKNOWN
Указатель срочности TCPЗначениеIRREGULARKNOWN
Опции TCPЗначениеIRREGULARUNKNOWN
Рисунок 11: Классификация полей CHANGING

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

4.1. Заголовок IP

4.1.1. IP Traffic-Class / Type-Of-Service (TOS)

Предполагается, что поля Traffic-Class (IPv6) и Type-Of-Service/DSCP (IPv4) могут изменять свои значения в течение срока существования потока пакетов. Этот анализ принимает во внимание несколько RFC, описывающих изменения исходной спецификации протокола в RFC 791 [1].

Байт TOS описан в исходной спецификации RFC 791 [1] как 3-битовое поле уровня предпочтения, за которым следует 3 бита TOS и 2 резервных бита (по определению равные 0). В RFC 1122 [21] размер поля TOS расширен до 5 битов, но значения двух добавленных битов не определены. RFC 1349 [23] определяет четвертый бит TOS как 'minimize monetary cost'. Следующее важное изменение содержится в RFC 2474 [14] (этот документ отменяет действие RFC 1349 [23]). RFC 2474 переопределяет октет TOS как 6-битовое поле DSCP (DiffServ Code Point), за которым следует 2 неиспользуемых бита. Позднее в RFC 2780 [30] эти два резервных бита октета TOS (или traffic class — класс трафика) определены для экспериментов с ECN.

Поэтому предполагается классифицировать октет TOS (или traffic class) как 6 битов DSCP и 2 дополнительных бита. Эти два бита могут предполагаться нулевыми или содержащими данные ECN. С учетом перспективы предпочтительней предполагать использование ECN, особенно в случае TCP.

Следует также обеспечить работу профиля со старыми вариантами стека, поскольку они будут применяться еще достаточно долго. Для простоты мы будем рассматривать поле как 6 битов TOS и 2 бита данных ECN во всех случаях.

Значение DSCP (как TOS в ROHC RTP) не предполагается изменяющимся часто (хотя оно может смениться посреди потока, например, в результате изменения маршрута).

4.1.2. Флаги ECN

Сначала мы опишем флаги ECN в соответствии со спецификациями RFC 2481 [15] и RFC 3168 [18]. После этого будет описаное предлагаемое обновление, которое будет менять поведение флагов.

В RFC 2481 [15] определены 2 отдельных флага — ECT (ECN Capable Transport) и CE (Congestion Experienced). Флаг ECT, если он согласован стеком TCP, будет иметь значение 1 для всех пакетов с данными и 0 — для пакетов, содержащих только подтверждения. Это означает, что поведение флага ECT связано с поведением стека TCP. Непонятно, можно ли это использовать для компрессии.

Флаг CE используется только при установке ECT = 1. Отправитель устанавливает для флага значение 0, которое может быть заменено на 1 поддерживающим ECN маршрутизатором при возникновении в сети насыщения. Таким образом, предполагается, что флаг CE может быть в любой момент установлен в 1 в зависимости от состояния насыщения сети и местоположения системы компрессии на пути. Следовательно, система компрессии, расположенная близко к перегруженной сети часто будет видеть установленных флаг CE, а система сжатия, расположенная вблизи отправителя будет редко (или не будет совсем) видеть CE = 1.

Недавние экспериментальные предложения [19] используют иную трактовку этих битов, рассматривая их совместно как код, способный принимать 4 значения:

Использование двух кодов ECT позволяет отправителю детектировать ситуации, когда получатель не может надежно отвечать на информацию о перегрузке.

С точки зрения компрессии это изменение означает, что значения ECT(0) и ECT(1) равновероятны (для поддерживающего ECN потока), а значение 11 будет встречаться достаточно редко. Вероятность увидеть индикацию насыщения обсуждалась выре при описании флага CE.

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

4.1.3. Идентификация IP

Поле Identification (IP ID) в заголовке IPv4 показывает какой фрагмент содержит дейтаграмма при сборке фрагментов пакета. Спецификация IPv4 не задает порядок присвоения значений идентификатора, указывая лишь, что каждому пакету следует давать уникальное для пары отправитель-получатель и используемого протокола значение IP ID. Уникальность должна обеспечиваться в течение интервала времени, которое дейтаграмма (или любой из ее фрагментов) могут находиться в сети. Это означает, что присвоение значений IP ID может выполняться различными путями, которые мы будем делить на три класса:

Отметим, что эти идентификаторы используются только в IPv4 и, следовательно, не рассматриваются в IPv6. Для IPv4 поля ID могут обрабатываться тремя разными способами. Во-первых, имеется малоэффективное, но надежное решение, в котором поле идентификации передается без изменений во всех пакетах, что ведет к увеличению сжатых заголовков на 2 октета. Этот способ является наилучшим вариантом обработки полей ID в иех случаях, когда отправитель использует случайные значения ID. Во-вторых, может использоваться более гибкий механизм, который обеспечит снижение числа битов для полей ID при нарастающей (sequential jump) нумерации. Такие механизмы могут в некоторых случаях увеличивать число требуемых битов при использовании отправителем случайных значений идентификаторов. Следовательно, информация об используемом отправителем механизме выделения идентификаторов полезна при выборе между двумя упомянутыми выше решениями. Наконец, даже для IPv4 могут быть созданы схемы компрессии, не включающие в сжатый заголовок никакой дополнительной информации о поле ID. Для использования таких схем нужно знать какой из механизмов выделения значений поля ID применяется отправителем. Получение такой информации возможно не во всех случаях, что ведет к весьма редкому применению таких механизмов. Однако разработчикам стеков IPv4 для терминалов сотовых сетей следует использовать политику выделения идентификаторов, близкую к последовательной.

В контексте компрессии TCP поведение поля IP ID остается таким же. Однако в RFC 3095 [31] значения IP ID в общем случае получаются из порядковых номеров RTP. Для случая TCP нет подходящего кандидата на роль «ведущего порядкового номера».

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

4.1.4. Флаг запрета фрагментации (DF)

Механизм Path-MTU discovery (RFC 1191 для IPv4 [6] и RFC 1981 для IPv6 [11]) широко используется для протокола TCP, но весьма редко применяется сегодня для потоков пакетов UDP. Этот механизм использует флаг DF = 1 для определения необходимости фрагментирования на сквозном пути и нахождения минимального значения MTU вдоль этого пути. Можно предполагать, что конечные хосты, использующие этот механизм, будут передавать все пакеты с DF = 1, хотя хост может прекратить использование PMTU, установив DF = 0. С точки зрения компрессии мы считаем значение этого флага стабильным.

4.1.5. IP Hop-Limit / Time-To-Live (TTL)

Поля Hop-Limit (IPv6) и Time-To-Live (IPv4) предполагаются постоянными в течение всего срока существования потока пакетов или чередующими значения из небольшого набора при изменении маршрутов.

4.2. Заголовок TCP

Обсуждение сжимаемости полей TCP заимствовано из RFC 1144 [22]. Однако условия компрессии несколько отличаются, а используемые протоколы изменились.

4.2.1. Порядковый номер

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

Для последовательно передаваемых пакетов порядковые номера будут увеличиваться для каждого пакета на величину от 0 до верхнего предела, определяемого значением MSS (Maximum Segment Size) и, если этот механизм используется, Path-MTU discovery.

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

Отметим, что увеличение порядковых номеров пакетов определяется размером данных в этом пакете (включая флаги SYN и FIN). Естественно, существуют точные соотношения, которые RFC 1144 [22] использует для сжатия порядковых номеров в наиболее эффективном случае. Этот метод не применим напрямую для устойчивых к ошибкам систем, но рассмотреть его полезно.

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

Желательно иметь возможность предсказания порядковых с некоторой регулярностью. Однако сделать это сложно. Например, при передаче большого объема данных порядковые номера имеют тенденцию увеличения на величину MSS для каждого пакета (если предположить отсутствие потерь). Параметры вышележащих уровней также могут оказывать влияние — поведение порядковых номеров может повторяться с интервалом 8 кбайт — 5 сегментов по 1460 байтов, за которыми следует 1 сегмент размером 892 байта. Реализация TCP и управления буферами в стеке протоколов могут воздействовать на поведение порядковых номеров.

Система компрессии может отслеживать размер окна TCP, что позволяет ограничить размер этих переходов.

Для интерактивных потоков (например, telnet), порядковые номера будут увеличиваться на небольшие и нерегулярные значения. В этом случае обычно применим алгоритм Nagle [3], объединяющий по возможности мелкие пакеты для снижения объема служебного трафика (заголовков). Это может также вести к тому, что предсказать изменение порядковых номеров станет сложнее. Алгоритм Nagle предназначен для оптимизации и его не требуется использовать (приложения могут отключать этот алгоритм). Однако он включен по умолчанию во всех популярных реализациях TCP.

Отметим также, что флаги SYN и FIN (которые будут подтверждаться) также занимают 1 байт пространства порядковых номеров.

4.2.2. Номер подтверждения

Большая часть информации, относящейся к порядковым номерам, применима и для номеров подтверждений. Однако имеются и некоторые важные отличия.

При передаче больших объемов данных обычно передается 1 подтверждение для каждой пары сегментов данных. Этот алгоритм описан в RFC 2581 [16]. Пакеты ACK не требуется передавать сразу же после получения сегмента данных, но подтверждения должны передаваться в течение 500 мсек и их следует генерировать по крайней мере для каждого второго полноразмерного (MSS) сегмента принятых данных. Может показаться, что увеличение номеров подтверждений приблизительно вдвое больше увеличения порядковых номеров. Однако это верно не во всех случаях и нерегулярность изменения порядковых номеров должна приниматься во внимание.

Отметим также распространенную ошибку реализаций 'stretch ACKs' [33] (подтверждения могут генерироваться реже, чем для каждого второго полноразмерного сегмента данных). Такая же картина может возникать при потерях на пути возврата подтверждений.

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

4.2.3. Резерв

Значение резервного поля должно быть нулевым. Но это поле может использоваться в будущем и делать предположения о его значении не следует.

4.2.4. Флаги

4.2.5. Контрольная сумма

Контрольная сумма служит для сквозного контроля отсутствия ошибок в данных TCP. Обсуждение вопросов работы с контрольными суммами содержится в RFC 1144 [22]. Схемам компрессии заголовков не следует полагаться на контрольную сумму TCP, хотя им следует применять свой подходящий механизм детектирования ошибок. Контрольные суммы TCP рассматриваются как произвольно изменяющиеся значения.

4.2.6. Окно (Window)

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

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

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

4.2.7. Указатель срочности (Urgent)

С точки зрения компрессии поле Urgent Pointer представляет интерес по той причине, что оно служит показательным примером того, как «семантически идентичная» компрессия отличается от идентичной на битовом уровне. Это связано с тем, что поле указателя срочности имеет смысл только при установленном флаге URG.

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

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

4.3. Опции

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

Необязательные поля заголовка идентифицируются полем типа опции. Опции типа 0 и 1 занимают один октет. Все остальные опции имеют 1-октетное поле типа, за которым следует октет размера (length) и поле данных, размером length-2 октета.

4.3.1. Обзор опций

Агентство IANA поддерживает официальный список определенных опций TCP. На рисунке 12 показан список опций, определенных на момент публикации документа. Любая опция имеет идентификатор типа, выделенный IANA. Список опций доступен на сайте [20]. В тех случаях, когда это применимо, список опций содержит ссылки на RFC.

ТипРазмер в октетахЗначениеRFCПрименение
0-End of Option ListRFC 793*
1-No-OperationRFC 793*
24Maximum Segment SizeRFC 793*
33WSopt — Window ScaleRFC 1323*
42SACK PermittedRFC 2018*
5NSACKRFC 2018*
66Echo (отменено опцией 8)RFC 1072
76Echo Reply (отменено опцией 8)RFC 1072
810TSopt — Time Stamp OptionRFC 1323*
92Partial Order Connection PermittedRFC 1693*
103Partial Order Service ProfileRFC 1693
116CCRFC 1644
126CC.NEW RFC1644
136CC.ECHO RFC1644
143Alternate Checksum RequestRFC 1146
15NAlternate Checksum DataRFC 1146
16Skeeter
17Bubba
183Trailer Checksum Option
1918MD5 Signature OptionRFC 2385
20SCPS Capabilities
21Selective Negative Acks
22Record Boundaries
23Corruption experienced
24SNAP
25Unassigned (с 18.12.2000)
26TCP Compression Filter
Рисунок 12: Опции TCP общего назначения

Знак * в колонке «Применение» отмечает опции, которые чаще встречаются в потоках TCP. Отметим также, что RFC 1072 [4] был заменен RFC 1323 [7], хотя исходное использование битов определено в 1072.

4.3.2. Поведение поля опций

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

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

Современная модель использования опций TCP включает согласование опций в процессе обмена сегментами SYN и последующее использование согласованных сторонами опций. Это ведет к возможности некоторых допущений о присутствии тех или иных опций (только в пакетах с флагом SYN, в каждом пакете и т. п.). Когда такие допущения корректны, они помогают несколько оптимизировать сжатие заголовков. Однако такие допущения нежелательны, поскольку нет гарантии, что обработка и согласование опций не изменится в будущем. Отметим также, что система компрессии может не обрабатывать SYN-пакеты потока и, следовательно, не может знать о том, какие опции согласованы для использования.

5. Другие наблюдения

5.1. Неявные подтверждения

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

Для систем компрессии существует четкое требование независимости от топологии. Это означает, на практике невозможно гарантировать, что просмотр пакетов данных на уровне системы компрессии позволяет гарантированно судить о получении пакета SYN системой декомпрессии (поскольку пакет SYN может идти по иному пути).

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

5.2. Совместно используемые данные

Представляется разумным рассмотреть два случая — (i) когда прямой (данные) и обратный (ACK) путь проходят по общему каналу и (ii) когда прямой (данные) и обратный (ACK) путь проходят по разным каналам, каждый из которых используется только для определенного направления.

В первом случае компрессор и декомпрессор могут располагаться в одном месте. Тогда компрессор и декомпрессор на каждой стороне соединения могут обмениваться информацией. Такой обмен может повысить уровень эффективности.

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

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

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

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

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

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

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

5.5. Короткоживущие потоки

Сложно предположить, как можно повысить производительность для отдельного, непредсказуемого и короткоживущего соединения. Однако существует множество типовых ситуаций, когда организуется множество соединений TCP между одной парой хостов. Одним из таких примеров может служить web-серфинг (это более относится к HTTP/1.0 [25], нежели к HTTP/1.1 [26]).

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

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

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

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

5.6. Master Sequence Number

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

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

5.7. Ограничение размера опций TCP

Как можно видеть из приведенного выше обсуждения, большинство опций TCP, таких, как MSS, Wsopt или SACK-Permitted может появляться только в сегментах SYN. Каждой реализации следует (и предполагается, что это выполняется на практике) игнорировать неизвестные опции в сегментах SYN. Опции TCP будут передаваться в сегментах без флага SYN лишь в тех случаях, когда обмен опциями в SYN-сегментах показал, что обе стороны понимают данное расширение. Другие опции TCP, такие, как MD5 Digest или Timestamp, также обычно передаются в процессе организации соединений (т. е., в пакетах SYN).

Общий размер заголовка также является предметом обсуждения. Заголовок TCP показывает начало сегмента данных с помощью 4-битового поля, определяющего общий (с учетом опций) размер заголовка в 32-битовых словах. Это означает, что общий размер заголовка и опций не может превышать 60 байтов (т. е., на опции остается не более 40 байтов).

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

Поскольку этот документ лишь описывает поведение полей TCP, он не создает новых проблем безопасности.

Документ предназначен для использования в целях компрессии заголовков TCP/IP. При работе с механизма аутентификации типа IPsec AH [24] важно обеспечить прозрачность сжатия. При использовании шифрования (например, IPsec ESP [27]) поля TCP могут стать невидимыми, что будет препятствовать их сжатию.

7. Благодарности

Множество посвященных протоколам IP и TCP документов RFC (надеемся, что ниже перечислены все эти документы), вместе с посвященными схемам компрессии RFC 1144 [22], RFC 3544 [36] и RFC 3095 [31], а также подробный анализ RTP/UDP/IP в RFC 3095 послужили источниками идей и информации для этой работы. Дополнительная информация по основам компресии содержится также в документах [28] и [29].

Этот документ основан также на обсуждениях в почтовой конференции ROHC и различных коридорах (виртуальных и иных) множества ключевых вопросов. Особая благодарность Qian Zhang, Carsten Bormann и Gorry Fairhurst.

Qian Zhang и Hongbin Liao внесли свой вклад по анализу используемых совместно полей заголовков.

Все ошибки и погрешности представления и интерпретации остаются на совести авторов этого документа.

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

8.1. Нормативные документы

  1. Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981
  2. Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
  3. Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
  4. Jacobson, V. and R. Braden, "TCP extensions for long-delay paths", RFC 1072, October 1988.
  5. Zweig, J. and C. Partridge, "TCP alternate checksum options", RFC 1146, March 1990.
  6. Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
  7. Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
  8. Braden, B., "T/TCP — TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
  9. Connolly, T., Amer, P., and P. Conrad, "An Extension to TCP: Partial Order Service", RFC 1693, November 1994.
  10. Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
  11. McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
  12. Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
  13. Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
  14. Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
  15. Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
  16. Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
  17. Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
  18. Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001
  19. Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003

8.2. Дополнительная литература

  1. IANA, "IANA", IANA TCP options, February 1998, http://www.iana.org/assignments/tcp-parameters.
  2. Braden, R., "Requirements for Internet Hosts — Communication Layers", STD 3, RFC 1122, October 1989
  3. Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
  4. Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
  5. Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
  6. Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol — HTTP/1.0", RFC 1945, May 1996.
  7. Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
  8. Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, "Hypertext Transfer Protocol — HTTP/1.1", RFC 2068, January 1997.
  9. Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
  10. Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
  11. Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
  12. Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
  13. Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001.
  14. Balakrishnan, Padmanabhan, V., Fairhurst, G., and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", RFC 3449, December 2002.
  15. Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A., and F. Khafizov, "TCP over Second (2.5G) and Third (3G) Generation Wireless Networks", RFC 3481, February 2003.
  16. Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
  17. Engan, M., Casner, S., Bormann, C., and T. Koren, "IP Header Compression over PPP", RFC 3544, July 2003.
  18. Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.

Адреса авторов

Mark A. West
Siemens/Roke Manor Research
Roke Manor Research Ltd.
Romsey, Hants SO51 0ZN UK
Phone: +44 (0)1794 833311
URI: http://www.roke.co.uk
EMail: ku.oc.ekor@tsew.a.kram

Stephen McCann
Siemens/Roke Manor Research
Roke Manor Research Ltd.
Romsey, Hants SO51 0ZN UK
Phone: +44 (0)1794 833341
URI: http://www.roke.co.uk
EMail: ku.oc.ekor@nnaccm.nehpets

Перевод на русский язык

Николай Малых, moc.milib@hkylamn