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

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

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

• 0: End of Option List — конец списка опций
• Этот тип указывает на завершение списка опций, которое может не совпадать с концом заголовка TCP, определяемым полем Data Offset. Эта опция указывается после завершения всех опций, а не какой-то отдельной опции, но ее необходимо использовать лишь в тех случаях, когда точки завершения заголовка TCP и списка опций не совпадают. Опция определена в RFC 793 [2]. С этой опцией не связано никаких данных, поэтому схеме компрессии достаточно просто закодировать присутствие опции. Однако, следует помнить о возможном присутствии после опции битов заполнения для выравнивания заголовка TCP по 4- октетной границе (биты заполнения имеют значение 0 в соответствии с документом [2]).
• 1: No-Operation — нет операции
• Эта опция может включаться между другими опциями заголовка (например, для выравнивания следующей опции по границе слова). Использование такого выравнивания на передающей стороне не гарантируется, поэтому получатель должен быть готов к обработке опций, которые начинаются не на границе слова (RFC 793 [2]). С этой опцией не связано никаких данных, поэтому схеме компрессии достаточно показать наличие опции. Это можно сделать путем обозначения наличия выравнивания и необходимости передачи информации о нем. В этом случае биты заполнения могут быть удалены.
• 2: Maximum Segment Size — максимальный размер сегмента

• При наличии этой опции она определяет максимальный размер сегмента, который может быть передан данному конечному хосту. Этот поле следует устанавливать только в стартовом запросе на организацию соединения (т. е., в сегменте с флагом SYN). Если опция не используется, можно использовать сегменты любого размера в соответствии с RFC 793 [2].

  Эта опция применяется очень часто. Размеры сегментов задаются с гранулярностью 16 битов. Теоретически может использоваться любой размер, однако на практике обычно применяется небольшой ряд значений. Например, значение 1460 байтов характерно для использования TCP/IPv4 в сетях Ethernet (хотя с ростом популярности туннелей все чаще используется значение 1400). По умолчанию для MSS используется значение 536. Распространенные значения поля могут кодироваться более эффективно.

• 3: Window Scale Option (Wsopt) — опция масштабирования окна

• Эта опция может передаваться в сегменте SYN конечным хостом TCP для

  1. индикации передающему хосту TCP возможности масштабирования окон приема и передачи;
  2. индикации коэффициента масштабирования окна приема.

  Коэффициент масштабирования окна задается в виде двоичного логарифма (возможно потому, что используется битовый сдвиг). Отметим, что окно в самом сегменте SYN никогда не масштабируется (RFC 1072 [4]). Данная опция может передаваться в начальном сегменте (т. е., в сегменте с установленным флагом SYN и сброшенным флагом ACK). Возможно использование опции и в последующих сегментах, но только при условии получения опции Window Scale в начальном сегменте. Опции Window Scale в сегментах без флага SYN следует игнорировать. Поле Window в самом сегменте SYN никогда не масштабируется (RFC 1323 [7]).

  Масштабирование окна не влияет на кодирование других полей в течение срока существования соединения. Важно лишь кодирование самой опции масштабирования окна. Значения размера окна должны находиться в диапазоне от 0 до 14 (включительно). В общем случае следует ожидать не слишком больших значений, поскольку 14 соответствует размеру окна 1 Гбайт (слишком много).

• 4: SACK-Permitted — возможность использования SACK
• Эта опция может передаваться при организации соединения в пакетах SYN узлами TCP, которые готовы принимать (и, вероятно, обрабатывать) опцию SACK RFC 2018 [12]. Опция не включает каких-либо данных, которые нужно было бы сохранять при ее кодировании.
• 5: SACK — частичное подтверждение

• Эта опция может использоваться для передачи в существующих соединениях расширенных подтверждений доставки. В частности получатель блоков данных с нарушением порядка может с помощью этой опции уведомить отправителя о приеме и буферизации таких блоков. Получатель ждет приема недостающих блоков в повторных пакетах для заполнения имеющихся в данных пропусков. В это же время получатель подтверждает данные, обычно указывая левый край окна в поле Acknowledgment Number заголовка TCP. Важно понимать, что опция SACK не меняет трактовку поля Acknowledgment Number, значение которого по прежнему указывает на левый край окна (т. е., на один байт больше порядкового номера последних данных, которые получены полностью RFC 2018 [12]).

  Если использование SACK согласовано сторонами (путем обмена опциями SACK-Permitted), данная опция может применяться в тех случаях, когда получатель уведомляет о потерянных сегментах. Поскольку опция идентифицирует диапазоны блоков в окне приема, она может рассматриваться как базовое значение и набор значений смещения. Базовое значение (левый край первого блока) можно рассматривать как смещение от номера подтверждения TCP. В одной опции может указываться до 4 блоков SACK. Блоки SACK могут возникать во многих сегментах (если в сети часто нарушается порядок доставки) и будут, таким образом, расширять размер уже указанных блоков или добавлять новые блоки.

  Дополнительные расширения типа DSACK RFC 2883 [17] не меняют существенно поведения блоков SACK в плане содержащейся в этих блоках информации.

• 6: Echo — эхо

• Эта опция содержит информацию, которую принимающая сторона TCP может вернуть в последующей опции TCP Echo Reply (см. ниже). TCP может передать опцию TCP Echo в любом сегменте при условии, что в сегменте SYN при организации соединения была получена опция TCP Echo. При использовании опции TCP echo для измерения RTT эта опция включается в сегменты данных, а четыре информационных байта будут определять время передачи сегмента данных в удобном для отправителя формате (см. RFC 1072 [4]).

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

• 7: Echo Reply — эхо-отклик

• Модуль TCP, получивший опцию TCP Echo, содержащую 4 байта данных, будет возвращать эти байты ы опции TCP Echo Reply. Опция TCP Echo Reply должна возвращаться при передаче следующего сегмента (например, ACK). Если до отправки следующего сегмента будут получены новые опции Echo, модуль TCP должен выбрать только одну из них, игнорируя остальные (доkжен выбираться самый новый сегмент с самым старым порядковым номером — RFC 1072 [4]).

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

• 8: Timestamps — временные метки

• Эта опция передает два 4-байтовых поля с временными метками. Поле Timestamp Value (TSval) содержит текущее значение временной метки передавшего опцию модуля TCP. Поле Timestamp Echo Reply (TSecr) имеет смысл только при наличии в заголовке TCP флага ACK и в этом случае содержит временную метку, переданную удаленным модулем TCP в поле TSval опции Timestamps. Когда поле TSecr не имеет смысла, оно должно содержать 0. В общем случае значение TSecr берется из последней принятой опции Timestamp, однако ниже рассмотрено несколько исключений из этого правила. TCP может включать опцию Timestamps (TSopt) в начальный сегмент (сегмент с флагом SYN, но без флага ACK), а также может передавать TSopt в других сегментах, если в начальном сегменте соединения было получено поле TSopt (см. RFC 1323 [7]).

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

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

  Одной из важных причин использования временных меток является детектирование повторного использования порядковых номеров (защита от PAWS, см. RFC 1323 [7]). Для соединений, использующих компрессию заголовков TCP такая угроза обычно отсутствует, но важно обеспечить целостность опции. Этот вопрос рассматривается в документе RFC 3150 [32]. Однако предложенный алгоритм Эйфеля (Eifel) [35] рекомендует использовать временные метки на каналах сотовых сетей [34].

  В части компрессии отметим, что диапазон разрешения для временных меток, предложенный в RFC 1323 [7] достаточно широк (от 1 мсек до 1 сек на «тик»). Вкупе с возможностью значительных вариаций RTT это осложняет выбор кодирвания, которое было бы оптимальным для всех случаев.

• 9: Partial Order Connection (POC) permitted — возможность неполного упорядочивания

• Эта опция является простым индикатором, с помощью которого обе стороны соединения могут согласовать использование протокола POC (см. RFC 1693 [9]).

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

• 10: POC service profile — профиль POC

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

• 11: Connection Count (CC) — счетчик соединений

• Эта опция является частью реализации TAO (TCP Accelerated Open), которая позволяет обойтись без трехэтапного согласования TCP Three-Way Handshake (3WHS). TAO использует 32-битовый номер инкарнации, называемый счетчиком соединений (connection count или CC), который передается в опции TCP каждого сегмента. Для каждого из направлений соединения TCP используется свое значение CC. Реализации присваивают монотонно возрастающие значения CC для последующих соединений, которые открываются активно или пассивно 9см. RFC 1644 [8]). Эта опция редко используется (а может быть не используется совсем) в современной сети Internet, поэтому единственным требованием к схеме компрессии является обеспечение возможности кодирования этой опции.

• 12: CC.NEW

• Для корректной работы механизма TAO от клиентов требуется генерация монотонно возрастающих значений CC при успешной организации соединений. Получение опции CC.NEW заставляет сервер объявить некорректной кэшированную запись и выполнить процедуру 3WHS (см. RFC 1644 [8]). Эта опция редко используется (а может быть не используется совсем) в современной сети Internet, поэтому единственным требованием к схеме компрессии является обеспечение возможности кодирования этой опции.

• 13: CC.ECHO
• Когда сервер передает сегмент, он возвращает значение счетчика соединений из начальной опции CC.ECHO, которое используется клиентом для проверки корректности сегмента (см. RFC 1644 [8]). Эта опция редко используется (а может быть не используется совсем) в современной сети Internet, поэтому единственным требованием к схеме компрессии является обеспечение возможности кодирования этой опции.
• 14: Alternate Checksum Request — запрос на изменение алгоритма расчета контрольной суммы

• Эта опция может быть передана в сегменте SYN для индикации того, что модуль TCP готов генерировать и принимать контрольные суммы, рассчитанные с использованием альтернативного алгоритма. В течение срока существования соединения такие суммы будут использоваться в заголовках TCP вместо обычных контрольных сумм TCP. Если нестандартная контрольная сумма имеет размер более 2 октетов, она может полностью помещаться в поле опции TCP Alternate Checksum Data Option с установкой нулевого значения в поле контрольной суммы заголовка TCP или указываться по частям в поле заголовка и опции. Для расчета контрольный сумм по иному алгоритму используется тот же набор данных, что и для обычных контрольных сумм TCP (см. RFC 1146 [5]).

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

• 15: Alternate Checksum Data — альтернативная контрольная сумма

• Это поле используется лишь в тех случаях, когда согласованная контрольная сумма имеет размер более 16 битов. Такие суммы не помещаются в стандартное поле заголовка TCP и должны по крайней мере частично указываться в данной опции. При расщеплении контрольной суммы между заголовком TCP и данной опцией или включении всей контрольной суммы в поле опции определяется независимо для каждой контрольной суммы. Размер этой опции будет зависеть от выбранного механизма генерации контрольных сумм для данного соединения (см. RFC 1146 [5]).

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

• 16 — 18:
• Эти опции, не включенные в RFC, не рассматриваются в данном документе.
• 19: MD5 Digest — сигнатура MD5

• Каждый сегмент, передаваемый в соединение TCP будет защищаться от подмены путем включения в него 16-битовой сигнатуры MD5, получаемой с помощью алгоритма MD5 для собранного вместе (concatenate) блока данных [13].

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

  В отличие от других расширений TCP (например, от опции Window Scale [7]), отсутствие данной опции в сегменте SYN-ACK не должно заставлять отправителя отключать использование подписей в своих сегментах. Такое согласование обычно делается для предотвращения некорректного поведения некоторых реализаций TCP при получении опции в отличных от SYN сегментах. Это не вызывает проблем для данной опции, поскольку сегменты SYN-ACK, передаваемые в процессе организации соединений, не будут подписаны и, следовательно, будут игнорироваться. В результате этого соединение не будет организовано и опция просто не сможет появиться в сегментах без флага SYN. Более важно то, что передача сигнатур должна вестись под полным контролем приложения, а не по милости удаленного хоста, который не понимает эту опцию. Сигнатуры MD5 следует, подобно любым криптографически защищенным данным, передавать без использования компрессии. Следовательно, схема компрессии должна просто обеспечивать прозрачную передачу этой опции.

• 20 — 26;
• Эти опции, не включенные в RFC, не рассматриваются в данном документе. Это означает, что детали их поведения не описываются и не ожидается, что схема компрессии оптимизирована для работы с такими опциями. Однако любые нераспознанные опции должны прозрачно передаваться схемой компрессии TCP для обеспечения эффективной работы с редкими и новыми опциями.

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

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