Почему в пассивном режиме FTP используется ряд временных портов, а не один хорошо известный порт? [закрыто]

В пассивном режиме FTP я прочитал, что сервер отправляет клиенту случайный номер порта, где он может установить канал данных.
Затем клиент устанавливает канал данных от своего случайного номера порта до этого номера порта, отправленного сервером.

Мой вопрос: почему сервер отправляет клиенту случайный номер порта? Почему клиент не может напрямую установить канал данных для порта № 20 на стороне сервера?

tcp зефир
источник

Я думал, что это было не по теме.

К сожалению, вопросы о протоколах выше уровня 4 OSI здесь не по теме.

Рон Мопин

Ответы:

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

На порту подключения к данным нет протокола. Все, что знает сервер - единственное, что несет какую-либо информацию в этом соединении - это номер порта, к которому вы подключаетесь.

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

Если два клиента будут запрашивать передачу одновременно, когда сервер принимает подключение к одному порту, сервер не сможет определить, какой файл передать. Конечно, сервер может использовать IP-адрес клиента для принятия решения (на самом деле многие FTP-серверы проверяют, что IP-адрес клиента совпадает с IP-адресом, используемым в контрольном соединении, для безопасности).

Но это не будет работать для:

Несколько подключений с одного компьютера (большинство FTP-клиентов поддерживают параллельные передачи / очереди, и вы можете запустить несколько разных FTP-клиентов на одном компьютере);
Соединение с разных машин в одной (корпоративной) сети, так как у них один и тот же внешний IP.

Частично скопировано из моего ответа на вопрос: почему в пассивном режиме FTP требуется диапазон портов, а не только один порт? Ошибка сервера.

Мартин Прикрыл
источник

Номер порта, используемого на стороне сервера, также может быть 20, верно? В каждом ответе номер порта на стороне сервера отличается от 20

Zephyr

Мой ответ объясняет, почему номер порта должен быть уникальным для каждого соединения / передачи. Так что это нельзя исправить до 20.

Мартин Прикрыл

Да, это не может быть исправлено, но один из них может быть 20 правильно?

Зефир

Да, но все остальные порты должны быть выше 1024. И с практической точки зрения непрерывный диапазон портов лучше. Большинство межсетевых экранов / NAT поддерживают основанные на диапазоне правила. Вы не хотите добавлять специальное правило для изолированного порта 20. Также большинство FTP-серверов поддерживают только непрерывный диапазон портов.

Мартин Прикрыл

@ Zac67 нет, клиент откроет новое соединение (кроме управляющего), чтобы извлечь файл в пассивном режиме, поэтому сервер не может использовать номер порта источника (клиента) для различения клиентских соединений. Кроме того, NAT часто искажает порт источника клиента (и / или IP-адрес), что делает этот подход непригодным на практике.

jjmontes

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

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

Zac67
источник

Так может быть и 20, верно? На каждом веб-сайте номер порта сервера для данных отличается от 20.

Zephyr

20 - это исходящий порт с сервера для активного FTP (который больше не используется).

Zac67

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

Марка