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

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

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

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

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

ток RFC959 включает хороший раздел по истории, связываясь с ранее RFCs, если Вы представляете себе делать немного археологии...

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

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

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

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

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

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

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

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

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

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

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

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