Кратко
- Опция Alternate Checksum Request, Kind 14, была предложением в SYN. Альтернативный алгоритм включался лишь тогда, когда оба SYN содержали один и тот же номер; отсутствие, несовпадение или молчаливое игнорирование старым стеком оставляли стандартную сумму на всю сессию.
- SYN и RST всегда проверялись стандартным способом. Для 32-битного Fletcher часть результата переносилась в Kind 15 на обычных сегментах. Позднее RFC 4614 отметил отсутствие интереса, а RFC 6247 перевёл RFC 1146 в Historic и закрепил за обеими опциями статус obsolete.
Первая ступень: в SYN заметен номер 14
В трассе появляется TCP option kind 14. Самый узкий корректный вывод: отправитель сформировал Alternate Checksum Request. Длина опции по RFC 1146 равна трём октетам; последний октет называет алгоритм.
Ноль означал стандартную TCP checksum. Единица — 8-bit Fletcher с 16-битным результатом. Двойка — 16-bit Fletcher с 32-битным результатом. Позже IANA сохранила также номер 3 для Redundant Checksum Avoidance.
На этой ступени неизвестно, понял ли опцию адресат. Неизвестно, предложил ли он тот же номер. Неизвестно, дошёл ли ответный SYN до точки наблюдения. Видимый запрос — факт о действии одного конца, а не о состоянии всей связи.
Эта осторожность особенно важна из-за правила совместимости. RFC 1122 предписывает без ошибки игнорировать неизвестную TCP-опцию, если её длина позволяет перейти к следующей. Старый стек мог принять SYN, пропустить Kind 14 и продолжить обычное установление соединения.
Такой успех не подтверждал альтернативу. Напротив, он мог быть результатом того, что экспериментальная часть не состоялась.
Вторая ступень: два предложения совпали
RFC 1146 задавал симметричное условие. В SYN от каждого конца должна была присутствовать Kind 14, а номера алгоритма обязаны были совпасть точно. Только тогда альтернативная checksum применялась к соединению.
Если один SYN не содержал запроса, действовала стандартная сумма. Если один конец просил алгоритм 1, а другой алгоритм 2, действовала стандартная сумма. Выбора по приоритету, списка предпочтений и компромисса между ними не было.
Поэтому два пакета образуют минимальный протокольный документ решения. Первый фиксирует предложение, второй — отдельное согласное действие другой стороны. Настройка хоста, знание номера или удачная предыдущая сессия не заменяют эту пару.
Даже на этой ступени доказано соглашение по тексту спецификации, но не обязательно правильное исполнение. Реализация могла ошибиться при вычислении, а наблюдение могло потерять часть потока. Следующая ступень требует данных.
Старая сумма удостоверяла собственную замену
Почему запрос находился в SYN, проверенном прежним алгоритмом? Иначе получатель должен был бы довериться формату, о котором сообщение только собиралось его уведомить.
RFC 793 определил базовую TCP checksum как 16-битное дополнение до единицы суммы заголовка, текста и псевдозаголовка. Современный RFC 9293 сохраняет обязательность: отправитель должен вычислять значение, получатель должен его проверять.
До согласия это была единственная общая проверочная грамматика. SYN с Kind 14 оставался обычным проверяемым SYN. Адресат сначала устанавливал целостность письма по старому правилу и лишь затем читал просьбу изменить правило для будущих сегментов.
В этом смысле новая checksum не отменяла старую одним флагом. Она получала ограниченную делегацию внутри одной сессии. Доказательство легитимности предложения зависело от механизма, который предложение хотело заменить.
Третья ступень: обычные сегменты читаются иначе
После совпадения алгоритма 1 его 16-битный Fletcher-результат занимал стандартное поле checksum. Те же 16 бит в заголовке теперь имели другую вычислительную семантику. Наблюдателю нужен контекст рукопожатия, иначе число нельзя проверить правильно.
Для алгоритма 2 результат имел 32 бита. Часть A помещалась в обычное поле, а часть B — в Alternate Checksum Data option Kind 15. Эта опция повторялась на применимых сегментах с данными и занимала дополнительное место в TCP header.
Kind 15 не являлась вторым голосованием. Она была материальным следствием уже принятого выбора. Её корректное присутствие вместе с проверяемым результатом поднимает доказательство от «стороны договорились» к «данный сегмент оформлен по договорённой схеме».
Ошибочная Kind 15 имела жёсткую судьбу. Неверная длина или появление в неподходящем состоянии должны были привести к отбрасыванию сегмента, отправке RST и прерыванию соединения. До соглашения неизвестное можно было проигнорировать; после соглашения неоднозначное представление целостности терпеть было нельзя.
Исключение, которое не опровергает соглашение
SYN и RST по RFC 1146 всегда использовали стандартную checksum. Поэтому стандартное значение в этих типах сегментов не доказывает возврат и не противоречит согласованной альтернативе.
Для SYN причина очевидна: он переносит предложение до существования общего состояния. RST сложнее и важнее. Reset может прийти от узла, у которого нет состояния конкретного соединения. Требовать от него восстановить альтернативный алгоритм означало бы лишить TCP универсального способа отказаться от неизвестной сессии.
Старая сумма стала не только входом, но и аварийным выходом. Это ограничивало область новой политики обычными сегментами известного соединения.
При анализе трассы необходима матрица: тип сегмента, направление, наличие состояния, выбранный номер и наличие Kind 15. Простое правило «после Kind 14 все checksum другие» даст ложные ошибки именно на SYN и RST.
Четвёртая ступень: историческое использование
Пакетная трасса одной сессии не отвечает, насколько широко механизм был развёрнут. Для этого нужны независимые исторические источники.
RFC 1146 вышел в марте 1990 года со статусом Experimental и прямо не рекомендовал использование в production systems. Документ задавал опыт, а не объявлял обязательную миграцию TCP.
RFC 4614 в 2006 году описал ландшафт TCP-документов и отметил, что Alternate Checksum не привлёк интереса. Формулировка важна своей ограниченностью. Она не доказывает отсутствие каждого прототипа и не является математическим опровержением Fletcher.
RFC 6247 в 2011 году формально переместил RFC 1146 в Historic, указав, что механизм не получил широкого распространения. Он поручил IANA пометить Kind 14 и Kind 15 как obsolete. Подробное security-обсуждение spoofing в RFC 6247 относится к T/TCP; переносить его как причину отказа от Alternate Checksum нельзя.
Исторический вывод поэтому точен, но не драматичен: экспериментальная двусторонняя опция не стала заметной частью практики TCP и была официально закрыта как актуальный путь стандартизации.
Пятая ступень: что говорит реестр сегодня
Реестр TCP Parameters IANA по-прежнему показывает номера 14 и 15 и отмечает их obsolete. Там же сохранена таблица Alternate Checksum Algorithms.
Это доказательство назначения и нынешнего статуса кодовых точек. Реестр предотвращает забывание и повторное присвоение старых чисел другому смыслу. Он позволяет анализатору распознать старый пакет.
Но реестр не является телеметрией. Строка не свидетельствует о текущей поддержке в реализациях или количестве соединений. Obsolete не означает, что каждый старый бит исчез; наличие записи в реестре не означает, что его следует генерировать.
Так возникают две независимые оси: семантика номера и распространённость поведения. IANA хорошо отвечает на первую. Для второй нужны наблюдения, где различаются предложение, совпадение и фактическая проверка.
Базовый алгоритм тоже требует аккуратного чтения
RFC 1071 собрал свойства Internet checksum и приёмы её эффективной реализации. Он помогает понять привычную математическую и инженерную базу, на фоне которой предлагалась альтернатива.
Однако пример кода не равен доказательству развёртывания, а held errata вокруг отдельных реализационных примеров дополнительно требуют отделять нормативную функцию от конкретного листинга. История RFC 1146 должна опираться на его собственный handshake и поздние статусные документы.
Точно так же нельзя заключать, что Experimental автоматически значит «не работало», а Historic — «опасно». Эти метки описывают место документа в стандартизации. Фактические причины, которые источники поддерживают, — отсутствие заметного интереса и широкого развёртывания.
Такая дисциплина сохраняет границы доказательства. Она не делает рассказ беднее; она показывает, какой документ имеет право отвечать на какой вопрос.
Совместимость скрыла несостоявшийся переход
Молчаливое игнорирование Kind 14 было сильным свойством. Старый узел не ломался. Новый распознавал отсутствие совпадающего ответа и возвращался к стандартной checksum на всю связь.
Но оператор видел успешное TCP-соединение и мог не видеть провала экспериментальной функции. Одностороннее обновление создавало совместимость, а не накопление пользы. Чтобы новая схема давала результат, нужно было обновить обе стороны, выбрать одно число и сохранить варианты в каждом участке пути.
Без отдельного счётчика предложение могло годами оставаться предложением. Надёжный fallback превращал отсутствие координации в нормальный сервисный результат.
Новая контрольная сумма просила разрешения у старой не из церемонии. Старый алгоритм был единственной проверкой, которой уже доверяли оба конца. Согласие требовало двух читаемых действий. Когда массового второго действия не появилось, старая проверка не победила в споре — она просто продолжила выполнять обязанность, от которой эксперимент никогда не позволял отказаться.
Источники
- IANA TCP Parameters, опции и номера алгоритмов: https://www.iana.org/assignments/tcp-parameters/tcp-parameters.txt
- RFC 1071, свойства Internet checksum: https://www.rfc-editor.org/rfc/rfc1071.txt
- RFC 1122, игнорирование неизвестных TCP options: https://www.rfc-editor.org/rfc/rfc1122.txt
- RFC 1146, Alternate TCP Checksums: https://www.rfc-editor.org/rfc/rfc1146.txt
- RFC 4614, TCP Roadmap и отсутствие интереса: https://www.rfc-editor.org/rfc/rfc4614.txt
- RFC 6247, Historic и obsolete: https://www.rfc-editor.org/rfc/rfc6247.txt
- RFC 793, исходное определение TCP checksum: https://www.rfc-editor.org/rfc/rfc793.txt
- RFC 9293, современная спецификация TCP: https://www.rfc-editor.org/rfc/rfc9293.txt
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
