프로토콜 설계에서 왜 2 개의 포트를 사용하겠습니까?

https://stackoverflow.com/questions/626823

06-07-2019
|

문제

TCP 서버가 포트에서 소켓을 허용하면 해당 클라이언트와 함께 새로운 소켓이 작동합니다.
수락 소켓은 해당 포트에 유효하며 해당 포트의 추가 클라이언트를 수락 할 수 있습니다.

원래 FTP 사양이 된 이유는 무엇입니까? RFC 959 제어 포트와 데이터 포트를 모두 작성하기로 결정 하시겠습니까?

유사한 사용자 정의 프로토콜 에서이 작업을 수행 할 이유가 있습니까?

이것은 단일 포트에서 쉽게 지정 될 수있는 것 같습니다.

FTP가있는 방화벽과 NAT의 모든 문제를 감안할 때 단일 포트가 훨씬 나아 졌을 것 같습니다.

일반적인 프로토콜 구현의 경우, 귀하 가이 작업을 수행하고 싶다고 생각할 수있는 유일한 이유는 명령과 다른 호스트의 파일을 제공 할 수 있다는 것입니다.

해결책

이것의 초기 근거는 당신이 할 수있는 것입니다.

데이터를 전송하는 동안 제어 연결에 대한 제어 명령을 계속 보내고 받으십시오.
동시에 둘 이상의 데이터 연결을 활성화해야합니다.
서버는 언제 데이터를 보낼 준비가되었는지 결정합니다.

사실, 그들은 FTP 프로토콜에 통합 된 복잡한 멀티플렉싱 프로토콜을 지정하여 동일한 결과를 달성 할 수 있었지만 그 당시 NAT는 이미 존재했던 것을 사용하기로 선택했습니다. TCP 포트.

예는 다음과 같습니다.

Alice는 Bob의 두 파일을 원합니다. Alice는 Bob Port 21에 연결하여 파일을 요청합니다. Bob 준비가 준비되면 Alice Port 20에 연결을 열고 파일을 보냅니다. 한편 Charles는 Alice의 서버에 파일이 필요합니다. Charles는 Alice에서 21에 연결하여 파일을 요청합니다. Alice는 준비가되면 Charles의 포트 20에 연결하고 파일을 보냅니다.

보시다시피, 포트 21은 서버에 연결하는 클라이언트를위한 것이며 포트 20은 클라이언트와 연결하는 서버를위한 것이지만 해당 클라이언트는 여전히 21에 파일을 제공 할 수 있습니다.

두 포트 모두 완전히 다른 목적을 제공하며 단순성을 위해 다시 협상 프로토콜을 구현하는 대신 두 개의 다른 포트를 사용하기로 결정했습니다.

다른 팁

FTP는 별도의 제어 및 데이터를 허용하기 때문입니다. IIRC, 원래 디자인 된대로 3 개의 호스트를 가질 수 있습니다. 호스트 A는 호스트 B를 호스트 C에 보내도록 요청할 수 있습니다.

FTP는 현대 방화벽의 어리 석음을 상상할 수없는시기에 설계되었습니다. TCP 포트는이 기능을위한 것입니다. 단일 IP에서 여러 연결을 다중화합니다. 그들은 아니다 액세스 제어 목록을 대체합니다. 그들은 아니다 IPv4를 48 비트 주소로 확장하기위한 것입니다.

새로운 비 IPV6 프로토콜은 현재 혼란을 처리해야하므로 작은 연속 포트 범위를 고수해야합니다.

FTP는 70 년대 초반에 최초의 Arpanet 프로토콜 중 하나 인 매우 긴 역사를 가지고 있습니다 (예 : 참조하십시오. 1971 년 RFC114). 이상하게 보일 수있는 디자인 결정은 이제 더 의미가있었습니다. 연결은 훨씬 느려졌으며 "대역에서"연결 컨트롤을 수행하는 것은 아마도 사용 가능한 네트워크 기술과 함께 좋은 움직임처럼 보였을 것입니다.

전류 RFC959 약간의 고고학을 좋아한다면 이전 RFC와 연결되는 역사에 대한 좋은 섹션을 포함합니다 ...

많은 구형 와이어 프로토콜과 마찬가지로 FTP는 인간이 사용하기에 적합합니다. 즉, 터미널 세션에서 FTP를 사용하기가 매우 쉽습니다. FTP의 디자이너는 사용자가 데이터를 전송하는 동안 원격 호스트와 계속 작업하기를 원할 것으로 예상했습니다. 명령과 데이터가 동일한 채널을 넘어서는 경우 어려웠을 것입니다.

IETF는 새로운 프로토콜에 대해 둘 이상의 포트를 할당하는 관행을 금지 했으므로 앞으로는이를 볼 수 없을 것입니다.

SCTP와 같은 최신 IP 프로토콜은 여러 포트를 사용할 수있는 TCP의 일부 바로 가계를 해결하도록 설계되었습니다. TCPS 'Head-of-Line'차단은 비행 중에 여러 개의 별도 요청/스트림이 있지 않아 일부 실시간 응용 프로그램에 문제가 될 수 있습니다.

IIRC, 문제는 FTP가 두 개의 포트 (즉, 하나 이상) 포트를 사용한다는 것이 아닙니다. 문제는 클라이언트가 제어 연결을 시작하고 데이터 채널이 서버에 의해 시작된다는 것입니다. FTP와 HTTP의 가장 큰 차이점은 HTTP에서 클라이언트가 데이터를 가져오고 FTP에서 서버가이를 푸시한다는 것입니다. NAT 문제는 연결을 기대하지 않는 방화벽을 통해 데이터를 푸시하는 서버와 관련이 있습니다.

제어 및 데이터를위한 별도의 포트를 FTP의 사용은 다소 우아합니다. 제어 및 데이터의 멀티플렉싱을 둘러싼 HTTP의 모든 두통을 생각해보십시오. 후행 헤더, 파이프 라인 요청을 둘러싼 규칙, 연결 유지 관리 및 그렇지 않은지 생각하십시오. 그 중 상당수는 제어를 명시 적으로 분리하여 피하며 데이터를 암호화하는 것과 같은 흥미로운 일을 할 수 있고 다른 하나는 아니거나 제어 채널이 데이터보다 QoS가 더 높습니다.

RTSP + RTP Protcol을 살펴 봐야합니다. 비슷한 디자인입니다. 각 스트림은 다른 포트에서 전송 될 수 있으며 지터, 재정렬 등에 대한 통계는 또 다른 포트에서 전송됩니다.

또한 UDP이기 때문에 연결이 없습니다. 그러나 이미 평범한 방화벽 (영어에 대해 죄송합니다)이있는 방화벽이 개발되었으므로 HTTP 구문과 하나의 TCP 연결 에이 연결이 포함될 수있는 모드가 개발되었습니다.

뭔지 맞춰봐 ? 멀티 포트 프로토콜은 HTTP 다중화 된 것보다 구현하기가 훨씬 간단하고 (IMO)가 훨씬 더 단순하며 더 많은 기능이 있습니다. 방화벽 문제에 관심이없는 경우 기존 (TCP 포트)이 이미있을 때 복잡한 멀티플렉싱 체계를 선택하는 이유는 무엇입니까?

FTP는 오래된 프로토콜입니다. 그것이 정말로 유일한 이유입니다. 설계자들은 데이터 포트를 통해 흐르는 데이터의 양이 적시에 제어 명령을 보낼 수 없도록하여 두 개의 포트로 수행했다고 생각했습니다. 방화벽, 특히 NAT는 훨씬 나중에 나왔습니다.

전송이 발생하는 동안 서버와 계속 협력하고 쉽게 새로운 전송을 시작할 수 있도록이 작업을 수행했다고 생각합니다 (클라이언트가이를 지원할 수있는 경우).

수동 모드는 거의 모든 방화벽/NAT 문제를 해결합니다.

내 생각에, 그것은 처음에는 나쁜 디자인 선택 일뿐입니다. 발명 된 오래된 시대에는 방화벽과 NAT가 존재하지 않았습니다 ... 요즘 실제 질문은 "사람들이 여전히 FTP를 사용하고 싶어하는 이유"입니다. 모든 FTP가 HTTP를 사용하여 더 나은 방법으로 수행 할 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow