@DavidPostill Извините, меня действительно интересовали только PASV и EPSV.
CGCampbell
Ответы:
20
Разница лишь в том, что PORT/PASVони ограничены IPv4 , а EPRT/EPSVработают с любым сетевым протоколом (хотя на практике используется только IPv6).
Стандартные PORT(активные) и PASV(пассивные) команды в протоколе управления FTP обмениваются адресом и информацией о порте в виде шести 1-байтовых десятичных знаков , из которых другой конец должен восстановить четырехбайтовый IP-адрес и двухбайтовый номер порта TCP.
PORT <address[4]>,<port[2]>
PORT 132,235,1,2,24,131
Но затем стали появляться другие протоколы. IPv4 собирался заменить на «IPng», в котором было довольно много конкурирующих предложений по замене (OSI CLNP, TUBA, SIP, SIPP, CATNIP - в разное время в истории), некоторые с более короткими, длинными и даже переменными размерами адресов хостов, пока IPv6 с 16-байтовыми адресами, наконец, не будет определен.
Просто отправка большего количества байтов не сработала бы - нельзя было ожидать, что серверы и клиенты будут знать правильный протокол, основанный исключительно на длине адреса. (Например, что если у вас есть один протокол с 16-байтовым адресом + 4-байтовый порт, другой с 12-байтовым адресом + 12-байтовый порт?)
Кроме того, хотя 20 лет назад это было не так важно, в наши дни в Интернете существуют миллионы устройств NAT , которые проверяют и манипулируют управляющими соединениями FTP, чтобы «внешний» хост видел только глобальные адреса IPv4, даже если «внутри» хост отправил RFC1918 локальный. Даже без NAT межсетевые экраны с отслеживанием состояния часто следят за командами управления, чтобы автоматически разрешить соединение для передачи данных без ручных правил.
Это в основном означает, что просто отправка большего числа номеров PORTили PASVгарантированно сломается для многих людей. Возможно, некоторые брандмауэры будут спокойно неверно истолковывать некоторые байты адреса как порт и тихо отбрасывать остальные; другие могут разорвать соединение или просто сломаться.
Чтобы избежать различных проблем, подобных описанным выше, необходимо было ввести новые команды для поддержки нескольких протоколов в FTP.
В 1993 RFC 1639 (первоначально RFC 1545 ) представил «длинный адрес» LPRTиLPSV команды, которые были похожи на PORT&, PASVно имели переменную длину адреса ; они также включали идентификатор типа протокола. (Хотя синтаксис не изменился - адрес IPv6: порт будет просто отправлен как 21 число, а не шесть.)
Однако это все еще не решило некоторые проблемы, например, запрос сервера использовать протокол, отличный от управляющего соединения. RFC также быстро устарел; когда IPv6 вышел только через год, его нельзя было использовать с LPRT, потому что для него не был назначен идентификатор протокола LPRT (только для различных ранних предложений).
Чтобы исправить это, в RFC 2428 в 1998 году добавлены EPRTи EPSV, также называемые «расширенный порт» и «расширенный пассив» , которые также имели метод согласования протокола, который поддерживают оба конца. «Расширенные» команды также отправляют адреса в удобочитаемой форме - для IPv6, что означает использование шестнадцатеричной и двоеточия, а не серии отдельных десятичных чисел.
Ух ты, все сайты, которые я читал, и до этого я не нажимал. Спасибо вам за это. Я приму это (вероятно) через час или два, хочу посмотреть, если кто-то еще делает это по-другому. Кроме того, причина, по которой я попросил Active, также заключалась в том, что из-за тегов, хорошо работающих с Google, этот вопрос / ответ будет найден в результатах поиска. Если никто не добавит ответ (делая его более полным для ответа Google), я отредактирую свой исходный вопрос и текст, чтобы отразить содержание вашего ответа, по существу, подгоняя мой вопрос к вашему ответу.
CGCampbell
3
Другое отличие состоит в том, что EPSVответ не включает IP-адрес (что PASVделает ответ). Это позволяет избежать распространенной проблемы, когда FTP-сервер, расположенный за NAT, не знает своего внешнего IP-адреса и сбивает с толку FTP-клиента, отправляя ему свой внутренний адрес.
Мартин Прикрыл
В дополнение к тому, что говорит @MartinPrikryl, другая причина заключается в том, что при использовании FTP-over-TLS брандмауэр / NAT не может перехватить IP-адрес в команде PASV, чтобы перезаписать его (по крайней мере, без MITMing управляющего соединения.) В то время как в Люди из Unix обычно используют SFTP вместо FTP-over-TLS, FTP-over-TLS обычно используется с мэйнфреймами IBM, поскольку FTP поддерживает файлы, ориентированные на записи (STRU R, MODE B), тогда как SFTP поддерживает только потоково-ориентированные файлы
Саймон Киссейн
1
Разница между активным и пассивным уже устранена. Расширенная пассивная (EPSV) просто пассивна с IPv4 и IPv6, потому что синтаксис ответа на PASV был специфичен для IPv4, и, следовательно, для IPv6 потребовалась новая команда. То же самое с EPTR против PORT в активном режиме. EPRT и EPSV ведут себя несколько иначе, поскольку они могут содержать только порт, а не IP и порт, как это делают PORT и PASV. Таким образом, передача данных может осуществляться только между системами, имеющими управляющее соединение. С помощью PORT и PASV можно создать соединение для передачи данных между другими системами (хотя сегодня это считается плохим дизайном и угрозой безопасности).
Такой ответ я не хотел. Это говорит мне ровно столько, сколько я мог найти в другом месте, а именно, что EPSV был создан для IPv6, но не объяснил почему. (то есть я не принимаю вашу причину как достаточно хорошее объяснение) Я говорю вам это в надежде, что вы, возможно, сделаете свой ответ еще лучше.
CGCampbell
Отредактировал ответ, чтобы было ясно, что ответ на команду PASV не поддерживает IPv6 и, следовательно, необходима новая команда.
Ответы:
Разница лишь в том, что
PORT/PASVони ограничены IPv4 , аEPRT/EPSVработают с любым сетевым протоколом (хотя на практике используется только IPv6).Стандартные
PORT(активные) иPASV(пассивные) команды в протоколе управления FTP обмениваются адресом и информацией о порте в виде шести 1-байтовых десятичных знаков , из которых другой конец должен восстановить четырехбайтовый IP-адрес и двухбайтовый номер порта TCP.Но затем стали появляться другие протоколы. IPv4 собирался заменить на «IPng», в котором было довольно много конкурирующих предложений по замене (OSI CLNP, TUBA, SIP, SIPP, CATNIP - в разное время в истории), некоторые с более короткими, длинными и даже переменными размерами адресов хостов, пока IPv6 с 16-байтовыми адресами, наконец, не будет определен.
Просто отправка большего количества байтов не сработала бы - нельзя было ожидать, что серверы и клиенты будут знать правильный протокол, основанный исключительно на длине адреса. (Например, что если у вас есть один протокол с 16-байтовым адресом + 4-байтовый порт, другой с 12-байтовым адресом + 12-байтовый порт?)
Кроме того, хотя 20 лет назад это было не так важно, в наши дни в Интернете существуют миллионы устройств NAT , которые проверяют и манипулируют управляющими соединениями FTP, чтобы «внешний» хост видел только глобальные адреса IPv4, даже если «внутри» хост отправил RFC1918 локальный. Даже без NAT межсетевые экраны с отслеживанием состояния часто следят за командами управления, чтобы автоматически разрешить соединение для передачи данных без ручных правил.
Это в основном означает, что просто отправка большего числа номеров
PORTилиPASVгарантированно сломается для многих людей. Возможно, некоторые брандмауэры будут спокойно неверно истолковывать некоторые байты адреса как порт и тихо отбрасывать остальные; другие могут разорвать соединение или просто сломаться.Чтобы избежать различных проблем, подобных описанным выше, необходимо было ввести новые команды для поддержки нескольких протоколов в FTP.
В 1993 RFC 1639 (первоначально RFC 1545 ) представил «длинный адрес»
LPRTиLPSVкоманды, которые были похожи наPORT&,PASVно имели переменную длину адреса ; они также включали идентификатор типа протокола. (Хотя синтаксис не изменился - адрес IPv6: порт будет просто отправлен как 21 число, а не шесть.)Однако это все еще не решило некоторые проблемы, например, запрос сервера использовать протокол, отличный от управляющего соединения. RFC также быстро устарел; когда IPv6 вышел только через год, его нельзя было использовать с LPRT, потому что для него не был назначен идентификатор протокола LPRT (только для различных ранних предложений).
Чтобы исправить это, в RFC 2428 в 1998 году добавлены
EPRTиEPSV, также называемые «расширенный порт» и «расширенный пассив» , которые также имели метод согласования протокола, который поддерживают оба конца. «Расширенные» команды также отправляют адреса в удобочитаемой форме - для IPv6, что означает использование шестнадцатеричной и двоеточия, а не серии отдельных десятичных чисел.В заключение, поддержка IPv6 является единственным отличием.
источник
EPSVответ не включает IP-адрес (чтоPASVделает ответ). Это позволяет избежать распространенной проблемы, когда FTP-сервер, расположенный за NAT, не знает своего внешнего IP-адреса и сбивает с толку FTP-клиента, отправляя ему свой внутренний адрес.Разница между активным и пассивным уже устранена. Расширенная пассивная (EPSV) просто пассивна с IPv4 и IPv6, потому что синтаксис ответа на PASV был специфичен для IPv4, и, следовательно, для IPv6 потребовалась новая команда. То же самое с EPTR против PORT в активном режиме. EPRT и EPSV ведут себя несколько иначе, поскольку они могут содержать только порт, а не IP и порт, как это делают PORT и PASV. Таким образом, передача данных может осуществляться только между системами, имеющими управляющее соединение. С помощью PORT и PASV можно создать соединение для передачи данных между другими системами (хотя сегодня это считается плохим дизайном и угрозой безопасности).
источник