В дизайне протокола, зачем вам использовать 2 порта?

Question

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

Почему исходная спецификация FTP RFC 959 решила создать как порт управления, так и порт данных?

Будет ли какая-либо причина делать это в аналогичном пользовательском протоколе?

Мне кажется, что это можно было легко указать на одном порту.

Учитывая все проблемы с брандмауэрами и NATS с FTP, кажется, что один порт был бы намного лучше.

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

Answer 1

Первоначальное обоснование этого было так, чтобы вы могли:

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

Правда, они могли бы достичь того же результата, указав сложный протокол мультиплексирования, интегрированный в протокол FTP, но поскольку в то время NAT не создавал проблем, они решили использовать уже существующие порты TCP.

Вот пример:

Алиса хочет два файла от Боба. Алиса подключается к порту Боба 21 и запрашивает файлы. Боб откроет соединения с портом Алисы 20, когда он будет готов, и отправит туда файлы. Тем временем Чарльзу нужен файл на сервере Алисы. Чарльз подключается к 21 на Алисе и просит файл. Алиса подключается к порту 20 на Чарльзе, когда готово, и отправляет файлы.

Как видите, порт 21 предназначен для подключения клиентов к серверам, а порт 20 - для серверов, подключающихся к клиентам, но эти клиенты могут по-прежнему обслуживать файлы в 21.

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

Answer 2

Поскольку FTP допускает раздельное управление и данные. Во IIRC, как изначально было задумано, у вас может быть 3 хоста: Хост A может попросить хост B отправить данные на хост C.

Answer 3

FTP был разработан в то время, когда глупость современного брандмауэра была немыслима. Порты TCP предназначены для этой функции; мультиплексирование нескольких соединений на одном IP. Они НЕ заменяют списки контроля доступа. Они НЕ предназначены для расширения IPv4 до 48-битных адресов.

Любой новый протокол не-IPv6 должен иметь дело с текущим беспорядком, поэтому он должен придерживаться небольшого непрерывного диапазона портов.

Answer 4

FTP имеет очень длинную историю, будучи одним из первых протоколов ARPANET еще в начале семидесятых (например, см. RFC114 от 1971 ). Дизайнерские решения, которые могут показаться странными, теперь имеют больше смысла. Соединения были намного медленнее, и выполнение контроля соединений «вне диапазона», вероятно, показалось хорошим ходом с доступной сетевой технологией.

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

Answer 5

Как и многие старые проводные протоколы, FTP подходит для использования людьми. То есть довольно просто использовать FTP из терминальной сессии. Разработчики FTP ожидали, что пользователи могут продолжить работу с удаленным хостом во время передачи данных. Это было бы трудно, если бы команда и данные передавались по одному и тому же каналу.

Answer 6

IIRC, проблема заключалась не в том, что FTP использует два (т. Е. Более одного) порта. Проблема заключается в том, что управляющее соединение инициируется клиентом, а канал данных - сервером. Самая большая разница между FTP и HTTP заключается в том, что в HTTP клиент извлекает данные, а в FTP сервер их проталкивает. Проблема NAT связана с тем, что сервер проталкивает данные через брандмауэр, который не знает, ожидать ли соединение.

Использование FTP отдельных портов для управления и передачи данных довольно элегантно, ИМХО. Подумайте обо всех головных болях в HTTP, связанных с мультиплексированием управления и данных - подумайте о концевых заголовках, правилах, связанных с конвейерными запросами, сохраняющих соединениях и т. Многое из этого избегается за счет явного разделения управления и данных, не говоря уже о том, что можно делать интересные вещи, такие как шифрование одного, а не другого, или заставить канал управления иметь более высокое QoS, чем данные.

Answer 7

IETF запретила практику выделения более одного порта для новых протоколов, поэтому мы, вероятно, не увидим этого в будущем.

Более новые IP-протоколы, такие как SCTP, предназначены для устранения некоторых недостатков TCP, которые могут привести к использованию нескольких портов. Блокировка заголовков TCP не позволяет иметь несколько отдельных запросов / потоков в полете, что может быть проблемой для некоторых приложений реального времени.

Answer 8

Вы должны взглянуть на протокол RTSP + RTP. Это схожий дизайн: каждый поток может быть отправлен на другой порт, а статистика о дрожании, переупорядочении и т. Д. Отправляется на еще один порт.

Плюс нет соединения, так как это UDP. Однако он был разработан, когда брандмауэр был уже чем-то банальным (извините за мой английский), поэтому был разработан режим, когда все это соединение могло быть встроено в одно TCP-соединение с HTTP-синтаксисом.

Угадай что? Многопортовый протокол намного проще (IMO) реализовать, чем мультиплексированный http, и у него гораздо больше функций. Если вас не беспокоит проблема с брандмауэром, зачем выбирать сложную схему мультиплексирования, если она уже существует (порт TCP)?

Answer 9

Я думаю, что они сделали это так, чтобы во время передачи вы могли продолжать работать с сервером и легко начинать новые передачи (если ваш клиент мог это поддерживать).

Обратите внимание, что пассивный режим решает почти все проблемы брандмауэра / NAT.

Answer 10

FTP - это старый протокол. Это действительно единственная причина. Разработчики думали, что объем данных, проходящих через порт данных, сделает их невозможными для своевременной отправки управляющих команд, поэтому они сделали это как два порта. Брандмауэры, и особенно NAT, появились намного позже.