Кратко

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

В феврале 1986 года Brian Kantor и Phil Lapsley опубликовали RFC 977 — предложение протокола Network News Transfer Protocol. Его важная мысль заключалась не в том, что один транспорт должен подчинить себе Usenet. Цена дубликата зависела от соединения, по которому он передавался. При интерактивном обмене два узла могли сравнить свои коллекции и решить, что отправлять. Если канал открывался лишь раз в сутки, разговор для принятия решения мог занять больше времени, чем передача самого дубликата.

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

NNTP добавил предварительный обмен запросами. Клиент мог узнать о новых группах, запросить идентификаторы статей в выбранных группах и получить те, которых у него не было. В обратном направлении узел сообщал соседу, какие статьи недавно получил; сервер отличал уже имеющиеся копии от тех, которые ещё следовало передать. Тело статьи перестало быть первым подтверждением того, что сообщение прошло по каналу: узлы могли сначала сравнить идентификаторы.

Выбор зависел от маршрута. RFC 977 отмечает, что хорошо связанные по локальной сети или другому быстрому каналу узлы могли распространять новости через NNTP эффективнее, чем традиционными методами вроде UUCP. Но документ объясняет и смысл пакетного режима UUCP: при канале с одной транзакцией, особенно при сеансе раз в день, отправка всех статей с последующим удалением дублей могла сократить общее время доставки. Интерактивные переговоры не становились автоматически дешевле только потому, что передавали меньше байтов.

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

RFC 850 уже стандартизовал формат статей USENET, оставив способы передачи гибкими: сайты выбирали оборудование, программное обеспечение и пакетную отправку. RFC 977 развивал подход в этой неоднородной среде. Он задавал обмен по надёжному потоку для запросов, получения, публикации и передачи статей, одновременно признавая преимущества другого транспорта на прерывистых линиях. Правило было условным: вести диалог, если сеть это позволяет, и сохранять пакеты, когда они экономят время.

Эти документы подтверждают замысел протокола, но не всеобщий переход. RFC 977 не показывает, какая доля узлов Usenet использовала NNTP в 1986 году, не измеряет экономию полосы и не доказывает, что каждая реализация исключала дубликаты. Его более узкий вклад — выбор статей стал обменом между узлами: получатель мог сообщить, что ему нужно и что у него уже есть, до отправки очередной копии.

Источники: RFC 977, Network News Transfer Protocol; RFC 850, формат обмена сообщениями USENET; RFC 1036, формат обмена сообщениями USENET.