FTP 수동 모드가 잘 알려진 단일 포트가 아닌 임시 포트 범위를 사용하는 이유는 무엇입니까? [닫은]


9

FTP 수동 모드에서는 서버가 데이터 채널을 설정할 수있는 임의의 포트 번호를 클라이언트에 보냅니다.
그런 다음 클라이언트는 임의 포트 번호에서 서버가 보낸이 포트 번호로 데이터 채널을 설정합니다.

내 질문은 서버가 클라이언트에 임의의 포트 번호를 보내는 이유는 무엇입니까? 클라이언트가 서버 측에서 포트 번호 20으로 데이터 채널을 직접 설정할 수없는 이유는 무엇입니까?


2
나는 이것이 주제가 아닌 것으로 생각했다.

불행히도 OSI 레이어 4 이상의 프로토콜에 대한 질문은 여기서 다루지 않습니다.
Ron Maupin

답변:


13

이것이 FTP 프로토콜이 수동 모드에서 작동하도록 설계된 방식입니다. 이 모델이 다른 프로토콜에서 다시 반복되지 않는다고 생각하지 않기 때문에 아마 좋은 생각이 아니 었습니다 (FTP 활성 모드에 대해서는 더 그렇습니다).


데이터 연결 포트에는 프로토콜이 없습니다. 해당 연결에 정보를 전달하는 유일한 서버 인 서버가 알고있는 것은 연결하는 포트 번호입니다.

매번 같은 포트에 연결했다면 서버는 어떤 파일을 연결할지 알 수 없습니다. 포트 번호는 제어 연결의 전송 요청과 데이터 연결 간의 링크 역할을합니다. 포트 번호는 PASV명령 에 대한 응답에 포함됩니다 .

두 클라이언트가 동시에 전송을 요청한 경우 서버가 단일 포트에서 연결을 허용하면 서버는 전송할 파일을 말할 수 없습니다. 물론 서버는 결정을 위해 클라이언트 IP를 사용할 수 있습니다 (실제로 많은 FTP 서버는 클라이언트 IP가 보안을 위해 제어 연결에 사용 된 IP와 일치하는지 검증합니다).

그러나 이것은 작동하지 않습니다.

  • 동일한 머신에서 여러 연결 (대부분의 FTP 클라이언트는 병렬 전송 / 큐를 지원하며 실제로 한 머신에서 여러 다른 FTP 클라이언트를 실행할 수 있음);
  • 동일한 외부 IP를 가지므로 동일한 (기업) 네트워크 내의 다른 컴퓨터에서 연결

부분적으로 내 대답에서 복사 단 하나 개의 포트에 반대 FTP 패시브 모드 포트 범위를 필요로 않는 이유는 무엇입니까? 서버 결함.


서버 측에서 사용되는 포트 번호는 20 개입니까? 모든 답변에서 서버 쪽의 포트 ​​번호는 20이 아닙니다
Zephyr

내 대답은 포트 번호가 각 연결 / 전송마다 고유 해야하는 이유를 설명합니다. 그래서 그것은 20으로 고정 될 수 없습니다.
Martin Prikryl

그렇습니다. 고칠 수는 없지만 그중 하나는 20이 될 수 있습니까?
Zephyr

1
예, 그러나 다른 모든 포트는 1024 이상이어야합니다. 실제적인 관점에서 인접한 포트 범위가 더 좋습니다. 대부분의 방화벽 / NAT는 범위 기반 규칙을 지원합니다. 격리 된 포트 20에 대해 특별한 규칙을 추가하지 않으려는 경우-대부분의 FTP 서버는 인접한 포트 범위 만 지원합니다.
Martin Prikryl

1
@ Zac67 아니요, 클라이언트는 새 연결 (제어 연결 제외)을 열어 수동 모드에서 파일을 검색하므로 서버는 소스 (클라이언트) 포트 번호를 사용하여 클라이언트 연결을 구별 할 수 없습니다. 또한 NAT는 종종 클라이언트 소스 포트 (및 / 또는 IP 주소)를 조작하여 해당 방법을 실제로 사용할 수 없게 만듭니다.
jjmontes

4

일반적으로 서버는 임의의 포트를 보내지 않지만 정의 된 (설치에 의해) 범위 / 풀에서 무료 포트를 보냅니다. 클라이언트의 경우이 포트가 무작위로 보입니다. 이 포트는 범위를 정의해야하는 방화벽에서 전달되어야합니다.

불행히도 FTP는 고대입니다. 고대 서버는 포트를 제외하고 여러 클라이언트의 데이터 세션을 구별 할 수 없었습니다. 일반적으로 단일 소켓 세션 내에서 모든 것이 깔끔하게 패킷 화되는 최신 프로토콜로 이동하는 것이 좋습니다.


따라서 20도 될 수 있습니까? 모든 웹 사이트에서 데이터의 서버 포트 번호는 20이 아닙니다.
Zephyr

20은 활성 FTP를 위한 서버에서 나가는 포트 입니다 (더 이상 사용하지 않음).
Zac67

고대 서버 에는 문제가 없었습니다. 프로토콜 디자이너는 여전히 원시 요청-응답보다 복잡한 작업을 수행하는 가장 좋은 방법을 찾으려고 노력했습니다.
Mark
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.