Кратко

  • RFC 1025 разложил совместимость на наблюдаемые шаги: установить соединение, передать данные, корректно его закрыть, повторить без перезапуска и связаться с другими реализациями через шлюз.
  • Система очков помогала упорядочить свидетельства, но не превращала успешный результат в доказательство всеобщей корректности, рейтинг производительности или факт внедрения.

Что считать «правильным», ещё обсуждали

В сентябре 1987 года Джон Постел опубликовал короткий и необычно прямой рассказ о том, как проверяли TCP и IP, пока программы и спецификации продолжали меняться. Когда реализаций было мало, пишет RFC 1025, практический способ выяснить, «правильно» ли работает одна из них, состоял в испытании с другой реализацией и последующем споре о значении результата. Тест мог привести к изменению программы. Обсуждение могло изменить и саму спецификацию.

Эта мысль показывает, что ранний bake-off был далёк от современной сертификационной лаборатории. Готовый продукт не сравнивали с закрытым сводом правил. Проверяли протокол, который ещё создавался силами небольшой группы разработчиков и должен был проявить себя на разных машинах, прежде чем его описание устоится. Сбой обмена был свидетельством, но не готовым вердиктом. Требовалось выяснить, неверно ли реализация поняла правило, не хватало ли самого правила или тест задавал не тот вопрос.

RFC 1025 — ретроспектива, а не поминутная хроника всех встреч. В ней ранний список тестов связывается с IEN 69 за октябрь 1978 года; демонстрация четырёх реализаций TCP прошла в Рестоне 4 декабря того же года; шесть реализаций встретились в Институте информатики Университета Южной Калифорнии 27–28 января 1979-го; в апреле 1980 года состоялся распределённый bake-off по сети. Документ 1987 года с небольшими редакционными изменениями воспроизводит процедуру, тесты и подсчёт очков именно для события 1980 года. Это была практика, сложившаяся через серию встреч, а не официальная итоговая проверка уже завершённых протоколов. RFC 1025, IEN 69, IEN 77

У разговора было несколько стадий

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

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

Средняя категория явно переходила от проверки самого себя к совместной работе реализаций. Открытие, обмен данными и штатное закрытие соединения с другим TCP приносили по два балла; повтор без перезапуска — четыре; полный обмен через тестовый шлюз — десять. RFC 1025 поясняет, что очки начислялись за каждого отдельного TCP, с которым удалось связаться: в примере можно было получить до двадцати баллов за каждую другую реализацию. Целью была связь N-квадрат — проверка всей сетки возможных пар, а не демонстрация одной заранее выбранной связи.

Меняется и единица свидетельства. Результат относится к паре реализаций, определённому пути и конкретному условию. Если A говорит с B, это не доказывает, что B правильно работает с C, или что A продолжит работу через шлюз, меняющий доставку пакетов. Матрица обнаруживала стыки, которые единичная демонстрация могла скрыть.

Шлюзу разрешалось намеренно портить путь

Самое запоминающееся устройство в RFC 1025 — «flakeway», намеренно ненадёжный шлюз. Его параметры можно было менять на ходу: задавать долю датаграмм, которые он отбросит, повредит и всё-таки передаст или доставит не в исходном порядке. Название шутливое, задача серьёзная: сам путь становился частью эксперимента. Если соединение работало только на чистом маршруте, это был более узкий результат, чем обмен, сохранявшийся при потере, изменении или перестановке пакетов.

Правило контрольных сумм мешало получить поверхностный успех. RFC 1025 требовал, чтобы проверка контрольных сумм оставалась включённой; если её отключали, баллы не начислялись. Нельзя было выключить именно тот механизм, который должен замечать повреждения, и объявить тест пройденным.

Тяжёлая категория TCP выходила далеко за рамки обычного обмена. Баллы давали за несколько одновременных соединений с разными узлами, обработку срочных данных, переход через границу циклической нумерации последовательности и приём сегмента «Kamikaze», собиравшего сразу множество характеристик заголовка. Кроме того, таблица различала «легальные» атаки — сегменты, соответствовавшие спецификации, — и «грязные», нарушавшие её требования: вывести соперника из строя сегментом, соответствующим спецификации, стоило 30 баллов, а сегментом, нарушающим её, — 20.

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

Отдельная категория IP предназначалась для хостов и шлюзов. В ней оценивали фрагментацию и сборку датаграмм, маршрутизацию от источника, обратный маршрут, рекомендации по маршрутизации, сообщения source quench, указания типа обслуживания и параметры IP. Очки давали и за обнаружение шлюза, который не уменьшал TTL, пересылал датаграмму с нулевым TTL или неправильно проверял контрольную сумму. Разделение отражало разные задачи: TCP обеспечивал обмен между хостами, а IP переносил датаграммы через соединённые сети и шлюзы. RFC 793, RFC 791

Список продолжал проверять жизненный цикл и крайние случаи: многократно открывать и закрывать соединение; одновременно открыть несколько и убедиться, что данные не смешиваются; аварийно завершить локальный TCP и снова открыть то же соединение; обратиться к сокету, который не принимает соединения; отправить данные получателю с нулевым окном; устроить поток данных «из пожарного шланга»; проверить срочные данные; провести номер последовательности через точку возврата к нулю. Последний тест сочетал некорректный сегмент с полуоткрытым соединением накануне переполнения номера.

Сети не работают только в удобных условиях: испытания должны были показать, что происходит, когда встречаются правила, которые по отдельности казались простыми.

У суммы очков были пределы

Баллы присуждались за самый долгий разговор, наибольшее число одновременных соединений и даже за лучшую отговорку. Это делало bake-off запоминающимся, но мешало считать общий итог универсальным рейтингом. Одни очки относились к базовому циклу соединения, другие — к функциям, прохождению через шлюз или числу одновременно поддерживаемых разговоров. Они измеряли разные свойства.

RFC 1025 признаёт это в заключительном разделе. Предыдущие тесты проверяли базовую работу и некоторые трудные случаи, но не учитывали производительность и не выясняли, внедрены ли новые на тот момент идеи. Отдельно названы процедуры Джона Нейгла, slow start и измерения времени кругового обхода Вэна Джейкобсона, а также процедуры SQuID. Затем перечислены возможные тесты производительности: передать файл размером один мегабайт по FTP или NETBLT через Ethernet либо ARPANET и измерить время кругового обмена одним символом с Echo Server. RFC предупреждает, что такие результаты сильно зависят от условий испытания. RFC 896, RFC 862

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

Тест был частью практической жизни протокола

Культура реализации раннего Интернета не ждала, пока спецификация и эксплуатация окажутся в строго разделённых сферах. Bake-off создавал повторяемую площадку для наблюдения разногласий: этот узел открывал соединение, тот — нет; эта пара продолжала работу после перезапуска; тот шлюз неверно обрабатывал заголовок; повреждённый пакет обнаруживался — или не обнаруживался. Наблюдения могли привести к исправлению кода, уточнению текста или изменению правила.

Этот цикл обратной связи важнее самого подсчёта очков. Арифметика не делала сеть правильной. Она позволяла людям, отвечавшим за независимые реализации, обсуждать конкретное поведение. Общее правило приобретало смысл, когда его могли применить разные системы; тест был полезен, когда его границы оставались видимыми и инженеры могли спорить, что именно показывает результат.

Позднейший RFC сохранил срез этой практики. Совместимость здесь — это сетка разговоров, восстановление — последовательность отдельных стадий, а обработку отказов следует проверять не только на конечных узлах, но и на пути между ними. Собственные оговорки документа не позволяли выдать эту матрицу за полную оценку производительности или всех новых идей TCP. RFC 1025 — не отчёт о победе и не современный сертификат соответствия. Это свидетельство о том, как молодой Интернет пытался превратить фразу «работает» в вопрос, который могли оспорить другие реализации.

Источники