При разработке протокола, зачем вам вообще использовать 2 порта?

Question

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

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

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

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

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

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

Answer 1

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

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

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

Вот такой пример:

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

Как вы можете видеть, порт 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

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

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

Answer 7

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

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

Answer 8

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

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

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

Answer 9

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

Answer 10

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

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

Answer 11

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