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

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

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

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

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

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

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

Ответ 1

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

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

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

Вот пример:

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

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

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

Ответ 2

Поскольку FTP позволяет осуществлять отдельный контроль и данные. IIRC, как первоначально было разработано, у вас могло бы быть 3 хоста: Host A мог попросить хоста B отправить данные на хост C.

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

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

Ответ 11

На мой взгляд, это просто плохой выбор дизайна в первую очередь. В старые времена, когда он был изобретен, брандмауэр и NAT не существовали... В настоящее время реальный вопрос - это больше "почему люди все еще хотят использовать FTP"? Все, что делает FTP, можно сделать с помощью HTTP лучше.