Кратко

  • RFC 675 предупреждал, что независимо выбранные идентификаторы портов могут совпасть; адрес TCP придавал имени сокета область действия в связанных сетях.
  • Соединение задавалось парой сокетов на его концах, поэтому один локальный сокет мог участвовать во множестве разных соединений.
  • Поздние спецификации поместили адресацию узлов и выбор протокола в IP, а порты процессов — в транспорт. Документы не показывают, когда эту модель приняла каждая реализация.

Соединение получалось из имён двух концов

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

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

В тексте видна и практическая граница: спецификация задаёт имя конечной точки, а каждый хост сам связывает свои порты с локальными процессами. Именование точки через сети и выбор локального процесса-получателя связаны, но это разные решения.

Поздняя модель разделила адрес и порт по уровням

Спецификация TCP 1980 года описывала порты внутри каждого хоста и их объединение с сетевым и хостовым адресами уровня межсетевого взаимодействия в сокет. Пара сокетов по-прежнему идентифицировала соединение, один сокет мог использоваться в нескольких соединениях. RFC 761 также говорит, что каждый хост независимо управляет привязкой портов к процессам. RFC 761, разделы 1.4 и 2.7

Соответствующая спецификация IP поместила адресацию хостов и выбор протокола в интернет-заголовок. Адреса обозначали исходный и целевой хосты, а поле Protocol указывало протокол следующего уровня. RFC 791 сохранил это отдельное поле; словарь RFC 793 определил TCP-сокет как адрес Интернета, соединённый с TCP-портом. Вместе документы помещают сетевую достижимость и передачу следующему протоколу в IP, а выбор процесса — в транспорт. RFC 760, разделы 1.1 и 3.1 · RFC 791, раздел 3.1 · RFC 793, раздел 3.1 и словарь

UDP показывает это разделение в другом транспортном протоколе. Его спецификация задаёт поля порта отправителя и получателя, а интерфейс UDP/IP получает адреса Интернета и поле протокола из IP-заголовка. Значение порта имеет смысл в контексте адреса и транспорта; это не универсальный номер приложения для всех сетей и протоколов. RFC 768, разделы «Fields» и «IP Interface»

Порт сам по себе не задавал сетевую область

Порту не нужно быть уникальным во всём мире. Ему достаточно различать процессы в системе, которая его интерпретирует. RFC 675, опубликованный в декабре 1974 года, обозначил эту границу прямо: операционные системы, TCP и пользователи выбирали идентификаторы портов независимо, поэтому значения могли совпасть. Дело было не обязательно в неверно выбранном числе; проблема возникала, когда от локального имени требовали указать объект за пределами его области.

Представим два разных TCP, использующих одно значение. Сам номер не говорит, какой TCP имеется в виду и к какой из связанных сетей относится адресат. Поэтому RFC 675 объединил адрес Интернета, идентифицирующий TCP, с идентификатором порта. Полученное имя сокета должно было быть уникальным во всех соединённых сетях. Спецификация добавляла недостающую область к имени, а не предполагала, что каждый локальный порт уникален повсюду. RFC 675, раздел 2.7

Имя обозначило границу уровней

Сокет RFC 675 решил задачу координации имён без всемирного органа распределения портов. Он добавил к локально полезному числу адресный контекст, необходимый для различения концов за пределами исходного TCP. Позднейшие спецификации яснее разделили обязанности: IP обозначал узлы и следующий протокол, транспортные порты выбирали процессы, а пара имён конечных точек описывала соединение.

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

Источники и пределы

Первичные источники: RFC 675, RFC 760, RFC 761, RFC 768, RFC 791 и RFC 793. Они подтверждают текст и терминологию спецификаций, но не внедрение, хронологию развёртывания, аутентификацию, постоянную идентичность машины или сегодняшнее поведение в эксплуатации.