개념 사전 · 프로토콜

FTP와 FTPS

File Transfer Protocol · 파일 전송 프로토콜

FTP는 명령을 주고받는 제어 연결과 파일·목록을 보내는 데이터 연결을 따로 사용하는 이다. FTPS는 FTP에 를 적용한 방식이며 SSH 기반의 별도 파일 전송 프로토콜인 SFTP와 구별한다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

01무엇이고, 어떤 일을 하나

계정 인증과 파일·디렉터리 작업 명령을 처리한다.
· 방식으로 별도 데이터 연결을 구성한다.
응답 코드로 전송 시작·완료·오류를 구분한다.

02어떤 순서로 동작하나

제어 연결
클라이언트가 서버의 제어 포트에 연결하고 인사·인증·필요한 승격을 수행한다.
데이터 접점 협상
이면 서버가 기다릴 포트를 알려 주고 클라이언트가 접속한다. 이면 클라이언트가 접점을 알리고 서버가 접속한다.
전송 수행
RETR·STOR·LIST 등 작업에 따라 별도 연결로 파일이나 목록을 주고받는다.
완료 확인
데이터 연결 종료와 제어 연결의 최종 응답을 함께 확인한다. 일부 파일 수신만으로 정상 완료를 단정하지 않는다.

03먼저 알아둘 용어와 구성요소

: mode에서 클라이언트는 데이터 연결을 받을 주소와 포트를 PORT 또는 EPRT로 전달한다.
: mode에서는 서버가 데이터 수신 포트를 열고 클라이언트가 그 포트로 연결한다.
: 의 227 응답에는 주소와 두 포트 바이트가 들어가며 포트는 p1×256+p2로 계산한다. 예를 들어 (192,0,2,10,117,48)은 문서용 서버 주소의 포트 30000을 뜻한다.
: 의 229 응답은 보통 포트만 알려 주고 제어 연결의 서버 주소를 사용하므로 주소 계열과 처리를 단순하게 만들 수 있다.
: TYPE I의 image 전송은 바이트 보존이 필요한 파일에 사용한다. TYPE A는 텍스트 표현·줄바꿈 변환을 포함할 수 있어 로컬 파일 길이와 전송 바이트 수가 다를 수 있다.
: RFC 3659의 REST STREAM 지원은 스트림의 바이트 위치를 이용해 전송을 이어갈 수 있게 한다. 서버 지원 여부와 모드·파일 구조를 확인하고 모든 FTP 서버에 무조건 있다고 가정하지 않는다.

LEARN THROUGH PRACTICE

FTP 로그인과 PORT·STOR·226 전송 완료를 나누어 읽기

제어 연결의 인증, 별도 데이터 연결, 전송 완료 응답과 파일 로그를 한 처리 흐름에 대입한다.

실습 구성과 전제

로그인 패킷과 파일 업로드·xferlog 화면은 서로 다른 연결 사례다. 동일 세션의 처음부터 끝까지라고 묶지 않는다.
평문 FTP의 구조를 해석하는 격리 실습이다. 실제 자격 정보는 전재하지 않고 업로드 파일도 무해한 테스트 자료로 한정한다.

제어 연결에서 인증 상태의 변화를 찾는다
- 서버의 220 인사 뒤 USER에 대한 331은 추가 암호가 필요하다는 응답이고 PASS 뒤 230은 해당 로그인의 성공이다. 아직 파일 데이터가 전달된 것은 아니다.
- 평문 FTP에서는 이 명령들이 패킷에 보일 수 있다. SFTP는 SSH 기반의 다른 프로토콜이며, FTPS는 FTP에 를 적용하므로 용어를 구분해야 한다.
원본 크기로 보기 ↗
- 캡처에 vsFTPd의 220 인사와 USER·PASS 명령 흐름이 보인다.
- 응답은 USER 뒤 331, PASS 뒤 230으로 바뀌어 인증 단계의 진행을 보여 준다.
확인 기준
로그인 성공을 파일 읽기·쓰기 권한의 성공으로 확대하지 않는다. 자격 정보 값은 학습 본문에 복사하지 않는다.
PORT 협상 뒤 별도 데이터 전송을 시작한다
- 업로드 사진은 PORT 성공 응답 뒤 파일 전송 준비와 완료가 이어지는 방식 사례다. PORT는 서버가 접속할 클라이언트 데이터 수신 지점을 알린다.
- 150은 전송을 시작할 준비를 나타내며 최종 성공이 아니다. 이때 제어 연결과 별도의 데이터 연결이 성립해야 실제 파일 내용이 이동한다.
text
```
C: PORT 192,0,2,50,195,80
S: 200 PORT command successful
C: STOR lab.txt
S: 150 Ok to send data
... 별도 데이터 연결로 파일 바이트 전송 ...
S: 226 Transfer complete
```
문서용 주소로 재구성한 대화다. 포트 값은 195×256+80=50000이며 실제 사진의 할당 포트가 아니다.
원본 크기로 보기 ↗
- put 명령 뒤 200 PORT command successful과 PASV 사용을 고려하라는 안내가 보인다.
- 150 Ok to send data 뒤 226 Transfer complete와 2156 bytes가 표시된다.
확인 기준
인증은 되는데 데이터 전송이 멈추면 데이터 연결 방향과 ·방화벽을 확인한다. PORT 성공만으로 데이터 연결까지 성공했다고 단정하지 않는다.
완료 응답과 전송 로그를 파일 내용에 연결한다
- 업로드 화면과 xferlog에는 2156바이트라는 전송량을 대조할 수 있다. 같은 시각·방향·파일을 확인한 뒤 일치 여부를 읽는다.
- 파일명에 보이는 이스케이프나 문자 표현만으로 곧바로 URL 인코딩이라고 단정하지 않는다. FTP 클라이언트와 로그 표현·문자 인코딩의 차이를 구분하고 필요하면 파일 해시도 확인한다.
bash
```
stat -c "%s %n" ./lab.txt
sha256sum ./lab.txt
```
허용된 양 끝 시스템에서 준비한 테스트 파일의 크기와 해시를 비교하는 조회 예시다.
확인 기준
226과 바이트 수 일치는 전송 완료의 근거다. 내용 무결성까지 요구한다면 서버에 저장된 크기·해시를 원본과 비교하며, 텍스트 전송 모드의 변환 가능성도 확인한다.

실습에서 확인한 동작 원리

FTP 인증, PORT/ 협상, 데이터 전송, 최종 완료 응답은 서로 다른 단계다.
화면·응답 코드·전송 로그·파일 해시를 연결하면 전송 성공의 의미와 한계를 구체적으로 설명할 수 있다.

관련 개념·전체 실습 화면 이어서 읽기 →

동작·명령 참고 문서

RFC 959 · FTP 제어와 데이터 연결 ↗

04예제로 따라가기

의 포트 값 두 바이트가 195와 80이면 195×256+80=50000번 데이터 포트이다.
바이너리 파일 1000바이트 중 검증된 동일 파일의 앞 400바이트를 받았다면 지원되는 재시작으로 남은 600바이트를 받을 수 있다.
로그인은 되지만 LIST가 멈추면 제어 연결 인증 성공과 데이터 포트··방화벽 경로를 나누어 본다.

05혼동하기 쉬운 점과 확인 기준

중단 후 원격 파일이 교체됐다면 과거 접두 부분과 새 파일의 뒷부분을 이어 잘못된 파일을 만들 수 있다. 재시작 전에 파일 버전·크기·시간 등 사용 가능한 동일성 근거를 확인한다.
전송 뒤 제어 연결이 끊겨 최종 226을 받지 못했다면 서버 쪽 결과가 불명확할 수 있다. 업로드를 반복하기 전에 원격 파일 상태를 조회해 덮어쓰기·중복 이름 생성을 구분한다.
제어 연결에 를 적용했더라도 데이터 보호 정책이 별도이면 파일 내용 보호가 다를 수 있다. FTPS의 PROT 조건을 함께 확인한다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

FTP·FTPS: 두 연결의 원리와 vsftpd·IIS 권한 구조제어 연결과 데이터 연결을 분리해 active·passive 동작을 추적하고, FTP 계정·파일 권한·TLS 정책이 연결되는 방식을 설명한다.상세 노트 읽기 →Linux 방화벽과 패킷 경로서비스가 듣는 소켓, 호스트 방화벽, 라우팅을 구분하고 패킷이 지나가는 경로에 맞춰 규칙을 해석합니다.상세 노트 읽기 →SSH 인증·호스트 키와 연결 진단SSH에서는 서버가 누구인지 확인하는 단계와 사용자가 접속 권한을 증명하는 단계를 구분합니다.상세 노트 읽기 →

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.