파일 전송 프로토콜의 역사: Kermit부터 rsync까지

파일 전송 프로토콜이 계속 변화해 온 이유

각 파일 전송 프로토콜은 해당 시대의 장애 모드에 대응하도록 설계되었습니다. Kermit은 통신 회선이 바이트를 손상시킬 것이라고 가정했습니다. XMODEM과 ZMODEM은 연결 속도가 느리고 매 분마다 비용을 지불해야 하는 환경을 가정했습니다. FTP(file transfer protocol)는 중간 네트워크가 협조적일 것이라고 가정했습니다. SSH는 네트워크가 적대적일 것이라고 가정했습니다. 마지막 가정이 승리했고, 이것이 오늘날 VPS에서 SFTP와 rsync over SSH 외에는 거의 사용하지 않는 이유입니다.

지금 이 시점에서 이를 되돌아볼 계기가 있습니다. C-Kermit 11.0.506이 2026년 8월 3일에 출시되었습니다. 이는 2011년 8월 20일에 출시된 C-Kermit 9.0.302 이후 첫 비베타 릴리스이며, 이 프로토콜이 구현하는 방식은 1981년 5월에 설계되었습니다. 45년이라는 시간은 하나의 기술 범주가 발명되고, 표준화되고, 실행되는 네트워크에 의해 파괴되고, 결국 SSH에 흡수되는 과정을 지켜보기에 충분히 긴 시간입니다.

Kermit, 1981: 바이트를 유실하는 회선을 위해 설계되다

Kermit은 1981년 5월 컬럼비아 대학교 컴퓨터 센터에서 Frank da Cruz와 Bill Catchings에 의해 개발되었습니다. 이름은 커밋 더 프로그(Kermit the Frog)에서 따왔습니다. Da Cruz의 설명에 따르면, 그룹이 이름을 고민하던 중 벽에 걸려 있던 머펫 달력을 보고 이름을 정했으며, 당시에는 이 프로토콜이 이렇게 널리 퍼질 것이라고는 아무도 예상하지 못했습니다.

Kermit이 해결하고자 했던 문제는 속도가 아니었습니다. 터미널과 메인프레임 사이의 경로는 임의의 바이트를 그대로 전달할 수 있는 파이프가 아니었습니다. 해당 경로는 고유한 특성을 가진 문자 장치였습니다. 7비트 환경일 수도 있었고, 반이중(half-duplex) 방식일 수도 있었습니다. 제어 문자를 임의로 삼켜버리거나, 특정 문자를 명령으로 오인하여 처리하기도 했습니다. 따라서 이진 파일을 수정 없이 그대로 전송하는 것은 불가능했습니다.

이러한 제약 사항을 바탕으로 설계가 이루어졌습니다. Kermit 프로젝트의 공식 기록은 다음과 같은 제약 사항을 명시합니다.

• 짧은 패킷: 대부분의 메인프레임은 터미널로부터 들어오는 긴 데이터 버스트를 처리할 수 없었기 때문입니다.
• 반이중 정지-대기(stop-and-wait) 방식: IBM 메인프레임이 전이중 통신을 지원하지 않았기 때문입니다.
• 제어 문자 및 8비트 문자를 위한 출력 가능한 인코딩: 메인프레임의 터미널 드라이버가 이를 그대로 통과시키지 못했기 때문입니다.
• 패킷별 체크섬 및 수신 측의 응답: 손상된 패킷이 발생할 경우 파일 전체가 아닌 해당 패킷만 재전송하기 위함입니다.

세 번째 항목이 가장 흥미로운 부분입니다. Kermit은 파일 자체를 보내는 대신 파일의 텍스트 안전 인코딩을 전송합니다. 제어 바이트는 접두사 문자와 출력 가능한 문자의 조합으로 변환되며, 7비트 링크를 위해 상위 비트가 설정된 바이트도 동일한 방식으로 인코딩될 수 있습니다. 중간에 위치한 모든 장비는 출력 가능한 텍스트만 인식하므로 문제없이 데이터를 처리합니다. 그 대가는 크기 증가입니다. 이진 파일은 전송 과정에서 용량이 커집니다. 하지만 전송을 완전히 망가뜨릴 수 있는 메인프레임 프론트엔드 환경에서는 이것이 올바른 선택이었습니다.

Kermit의 또 다른 독특한 점은 그 범위입니다. XMODEM은 파일의 정의에 대해 이미 합의된 두 기기 사이에서 파일을 이동시켰습니다. 반면 Kermit은 서로 다른 문자 집합, 레코드 구조, 텍스트 줄 끝에 대한 정의 등 합의가 이루어지지 않은 시스템들 사이의 최소 공통 분모로서 작성되었습니다. 이것이 바로 메인프레임에서 클라우드 서버로의 긴 여정에서 설명하는 세상이며, 네트워크 계층이 이를 대신 처리해주기 이전의 상호 운용성이란 바로 이런 모습이었습니다.

컬럼비아 대학교는 2011년 후원을 종료하고 C-Kermit을 개정된 3-clause BSD 라이선스로 공개했습니다. Frank da Cruz는 1981년 설계부터 2025년까지 44년간 프로젝트를 지켰습니다. 2026년 릴리스는 OpenKermit 프로젝트에 의해 유지보수되고 있으며, John Goerzen이 현재 이 글을 읽는 대부분의 사람보다 오래된 C 코드베이스를 현대화하는 작업을 수행하고 있습니다.

XMODEM과 ZMODEM: 전화 요금이 설계를 결정하던 시절

Ward Christensen은 1977년에 MODEM.ASM을 작성했으며, 이 프로그램이 도입한 프로토콜이 바로 XMODEM입니다. 1978년 그와 Randy Suess는 최초의 공공 게시판 시스템인 CBBS를 온라인에 올렸습니다. Christensen은 2024년 10월 11일에 사망했습니다.

XMODEM은 프로토콜로서 구현할 수 있는 가장 작은 규모에 가깝습니다. 데이터는 128바이트 블록 단위로 이동합니다. 각 블록은 1바이트의 체크섬을 포함하며, 이는 128바이트 데이터의 합을 256으로 나눈 나머지입니다. 수신 측은 각 블록을 확인하거나 재전송을 요청합니다. 이러한 구조를 취한 이유는 경제성 때문입니다. 다이얼업 회선은 사용 시간에 따라 요금이 부과되므로, 회선 오류가 발생했을 때 전체 전송이 아닌 블록 하나만큼의 비용만 치르도록 설계한 것입니다.

이 설계의 약점 또한 같은 문장에 있습니다. XMODEM은 128바이트마다 확인 응답을 기다립니다. Chuck Forsberg는 ZMODEM 사양서에서 이를 명확히 지적했습니다. "짧은 블록 길이는 시분할 시스템, 패킷 교환망, 위성 회선에서 사용할 때 처리량을 저하시킨다." 정지-대기(stop-and-wait) 방식을 무력화하는 것은 대역폭이 아니라 지연 시간입니다. 왕복 시간(round trip)이 발생할 때마다 요금이 부과되는 회선에서 아무런 데이터도 오가지 않는 유휴 시간이 생기기 때문입니다.

그다음으로 YMODEM이 등장했으며, Ward Christensen은 1985년에 이 이름을 만들었습니다. YMODEM의 기여는 일괄 전송(batch transfer)이었습니다. 송신 측이 데이터 전송 전에 파일 이름과 크기를 알리기 때문에, 한 세션에서 여러 파일을 전송할 수 있고 수신 측은 각 파일의 끝 지점을 알 수 있게 되었습니다.

ZMODEM은 Omen Technology에서 Chuck Forsberg가 내놓은 해답입니다. 1988년 10월 14일 개정된 사양서에는 "ZMODEM은 Telenet과의 계약 하에 퍼블릭 도메인으로 개발되었다"고 명시되어 있습니다. Telenet은 공공 패킷 교환 데이터 네트워크를 운영했으며, 그 계약의 흔적이 설계에 나타나 있습니다. ZMODEM은 네트워크 제어 문자를 이스케이프 처리하여 중간의 패킷 네트워크가 이를 가로채지 못하게 합니다. 또한 침묵을 통해 프레임 경계를 추론하는 대신 고유한 문자 시퀀스로 모든 프레임의 시작을 표시하므로, 타임아웃을 기다리지 않고도 노이즈로부터 복구할 수 있습니다. 또한 명시적인 이어받기(resume) 기능을 갖추고 있어 중단된 전송을 멈춘 지점부터 다시 시작할 수 있습니다.

가장 중요한 점은 대기를 멈췄다는 것입니다. 사양서 자체의 설명에 따르면 "ZMODEM은 사실상 파일 전체를 윈도우로 사용한다"고 합니다. 송신 측은 데이터를 계속 스트리밍하며, 수신 측이 문제를 보고할 때만 멈춥니다. 이는 TCP가 윈도우 개념을 통해 구현한 것과 같은 통찰이며, 모뎀이 유휴 상태로 대기하는 것을 지켜보던 누군가에 의해 다른 방향에서 도달한 결론입니다.

FTP의 두 연결 방식이 시대에 뒤처진 이유

FTP는 이 모든 것보다 오래되었습니다. A. Bhushan이 작성한 RFC 114 "A File Transfer Protocol"은 1971년 4월 16일자로 발행되었습니다.

알아두어야 할 중요한 사실은 RFC 114가 이미 두 개의 연결을 사용하는 설계를 검토하고 거부했다는 점입니다. Bhushan은 "제어 정보용과 데이터용으로 두 개의 전이중 링크를 사용하는 방식"을 검토한 뒤 다음과 같이 결론지었습니다. "데이터와 제어 정보 교환을 위해 단일 전이중 연결을 사용할 것을 권장합니다." 연결 분리는 나중에 도입되었습니다. 1972년 7월 8일자로 발행된 RFC 354는 "데이터와 파일은 데이터 연결을 통해서만 전송된다"고 명시하며, 명령은 별도의 Telnet 연결을 통해 전달되도록 했습니다. 1985년 10월 Postel과 Reynolds가 작성한 RFC 959는 현재 모든 시스템이 구현하고 있는 버전입니다.

RFC 959는 포트도 고정했습니다. 서버의 기본 데이터 포트는 "제어 연결 포트와 인접한 포트(즉, L-1)"이며, 제어 연결이 포트 21일 때 데이터 포트는 20번이 됩니다.

여기서 살아남지 못한 부분이 있습니다. FTP의 원래 모드에서는 서버가 클라이언트로 데이터 연결을 다시 엽니다. NAT(네트워크 주소 변환) 뒤에 있는 클라이언트는 서버가 도달할 수 있는 주소가 없으며, 방화벽 뒤에 있는 클라이언트는 인바운드 연결을 허용하지 않습니다. 따라서 데이터 연결이 성립되지 않아 목록이나 파일을 요청하는 즉시 전송이 중단됩니다. 이에 대한 해결책으로 PASV가 등장했습니다. RFC 959는 이를 서버가 "기본 데이터 포트가 아닌 다른 데이터 포트에서 '대기(listen)'하고, 전송 명령을 받으면 직접 연결을 시작하는 대신 연결을 기다리도록" 하는 요청으로 정의합니다. 서버는 연결할 주소와 포트를 다음과 같이 응답합니다.

PASV
227 Entering Passive Mode (203,0,113,10,195,80)

이 응답은 호스트 203.0.113.10, 포트 195 곱하기 256 더하기 80, 즉 50000번 포트를 의미합니다. 다시 읽어보면 구조적인 문제가 드러납니다. 두 번째 연결의 종단점이 첫 번째 연결의 페이로드 내부에서 공지됩니다. NAT 장비나 방화벽은 제어 채널을 분석하여 그 안에서 확인된 포트를 열어주지 않는 한 해당 연결을 통과시킬 수 없습니다. Linux는 정확히 이 작업을 수행하는 연결 추적 헬퍼를 제공합니다. 이 헬퍼는 제어 연결이 평문일 때만 작동하므로, FTP를 TLS(전송 계층 보안)로 감싸면 FTP를 사용 가능하게 만들던 중간 장비(middlebox)가 내용을 볼 수 없게 됩니다.

이것이 FTP가 주는 교훈을 한 문장으로 요약한 것입니다. FTP는 네트워크를 프로토콜의 참여자로 만들었습니다. 네트워크가 프로토콜을 이해해야만 작동하는 방식은, 네트워크가 더 이상 해당 프로토콜을 신뢰하지 않게 되었을 때 살아남을 수 없습니다.

결말은 기록에 남아 있습니다. Firefox는 2021년 7월 버전 90에서 FTP 지원을 제거했습니다. Chrome은 2021년 10월 Chrome 95에서 FTP 코드를 제거했습니다.

rcp 및 r-명령어: 호스트 이름 기반 신뢰

1983년 DARPA의 자금 지원을 받아 Berkeley에서 출시한 4.2BSD는 rcp, rsh, rlogin을 도입했습니다. 이 도구들은 단일 네트워크 내의 Unix 머신들로 구성된 캠퍼스 환경을 위해 구축되었으며, 인증 모델에서도 이러한 배경이 드러납니다. 호스트는 어떤 사용자가 호출을 시도하는지 주장하는 방식을 취했습니다. /etc/hosts.equiv 또는 사용자의 ~/.rhosts 파일에 해당 호스트가 신뢰할 수 있는 대상으로 명시되어 있으면, 그 주장을 수락하고 비밀번호를 요구하지 않았습니다.

이 메커니즘이 왜 사라졌는지 명확히 이해해야 합니다. 신뢰는 주소와 주장이라는 두 가지 요소에 기반했기 때문입니다. 이 정보들은 모두 네트워크를 통해 평문으로 전송되므로, 경로상의 누구든 이를 읽거나 위조할 수 있습니다. 이러한 모델은 Unix에서 Linux로 이어지는 경로에서 설명된 것처럼 네트워크가 건물 하나에 국한되었던 환경에서는 타당했습니다. 하지만 네트워크가 인터넷으로 확장되는 순간, 이 모델은 더 이상 유효하지 않게 되었습니다.

rcp가 성공적이었던 점은 인터페이스입니다. 원본과 대상만 지정하면 작업이 완료됩니다. 세션을 열거나, 전송 모드를 협상하거나, 두 번째 연결을 준비할 필요가 없습니다. 경로에 콜론을 사용하는 방식은 cp와 유사하게 동작합니다. 이 인터페이스는 그 기반이 된 프로토콜보다 40년 더 오래 살아남았습니다.

SSH가 전체 범주를 흡수하다

1995년 헬싱키 공과대학교의 연구원이었던 Tatu Ylonen은 대학 네트워크에서 발생한 패스워드 스니핑 공격에 대응하기 위해 SSH를 작성했습니다. 그는 1995년 7월 이를 소스 코드와 함께 자유 소프트웨어로 공개했습니다. 그해 말까지 50개국에서 약 20,000명의 사용자가 이를 사용한 것으로 추정되며, 1995년 12월 그는 SSH를 지속적으로 개발하기 위해 SSH Communications Security를 설립했습니다.

이후 버전부터 라이선스 조건이 강화되자, OpenBSD 개발자들은 자유롭게 라이선스가 허용된 마지막 버전인 ssh 1.2.12를 포크했습니다. 1999년 9월 26일 초기 임포트가 이루어졌고, 1999년 12월 1일 OpenBSD 2.6과 함께 OpenSSH 1.2.2가 출시되었습니다. 이 포크는 오픈 소스 라이선스 조항이 실제 환경에서 왜 중요한지를 보여주는 간결한 사례 연구입니다. 오늘날 거의 모든 사람이 사용하는 SSH 구현체는 라이선스가 허용되었던 바로 그 버전에서 파생되었기 때문입니다.

SSH가 등장하면서 파일 전송은 더 이상 별도의 문제가 아니게 되었습니다. 인증되고 암호화된 스트림이 여러 채널을 전달하는 방식은 이전 프로토콜들이 스스로 구현해야 했던 무결성, 순서 보장, 그리고 두 번째 TCP 연결이 필요 없는 데이터 경로를 이미 제공했기 때문입니다. 이러한 메커니즘이 생소하다면, 더 진행하기 전에 SSH의 본질에 대해 먼저 확인하십시오.

이로부터 두 가지 도구가 탄생했습니다. scp는 SSH 세션 내부에서 실행되는 rcp의 와이어 프로토콜이었으며, 이것이 rcp의 명령행 인터페이스를 그대로 계승한 이유입니다. SFTP는 다른 설계 방식을 취합니다. 디렉터리 목록 조회, 파일 속성 확인, 임의 접근이 가능한 실제 파일 프로토콜로서 SSH 채널을 통해 전달됩니다. SFTP는 RFC 표준이 되지 못했습니다. IETF 초안인 draft-ietf-secsh-filexfer는 2006년 7월 18일 버전 13에 도달한 후 만료되었습니다. OpenSSH는 해당 초안의 버전 3을 구현합니다. 세계에서 가장 널리 사용되는 보안 파일 전송 프로토콜은 폐기된 초안의 특정 버전이며, 그럼에도 불구하고 잘 작동합니다.

레거시 scp 프로토콜 역시 이제는 퇴출되었습니다. 2021년 9월 26일에 출시된 OpenSSH 8.8은 "가까운 미래의 OpenSSH 릴리스에서 scp(1)가 레거시 scp/rcp 프로토콜 대신 기본적으로 SFTP를 사용하도록 전환될 것"이라고 경고했습니다. 2022년 4월 8일에 출시된 OpenSSH 9.0은 이를 실행에 옮겼습니다. "이번 릴리스부터 scp(1)는 레거시 scp/rcp 프로토콜 대신 SFTP 프로토콜을 기본으로 사용합니다."

이러한 변화의 이유는 하나의 기술적 관습을 설명해 줍니다. 과거의 scp 프로토콜은 원격 파일명의 와일드카드를 원격 셸에 전달하여 확장했기 때문에, 사용자들이 원격 경로의 모든 메타 문자를 이중 따옴표로 감싸야 했습니다. 8.8 릴리스 노트에 따르면 SFTP 기반의 scp는 "더 이상 까다롭고 취약한 따옴표 처리가 필요하지 않습니다." 따라서 현재의 서버에서 scp는 rcp의 명령행 인터페이스를 사용하는 SFTP 클라이언트일 뿐입니다. 1983년의 인터페이스는 살아남았지만, 1983년의 와이어 프로토콜은 사라졌습니다.

rsync, 1996: 파일 전체가 아닌 차이점만 전송

Andrew Tridgell과 Paul Mackerras는 1996년 6월 19일 호주 국립 대학교(Australian National University)에서 기술 보고서 TR-CS-96-05인 "The rsync algorithm"과 함께 rsync를 발표했습니다.

이전의 모든 프로토콜은 파일을 손상 없이 이동하는 방법에 집중했습니다. 반면 rsync는 상대방이 이미 파일의 어느 부분을 가지고 있는지 확인하는 방식을 택했습니다. 해당 보고서는 대상 환경을 "대역폭이 낮고 지연 시간이 긴 양방향 통신 링크"로 정의하며, 목표를 "소스 파일 중 대상 파일과 동일한 부분을 식별"하여 일치하지 않는 부분만 전송하는 것으로 설정했습니다.

이 메커니즘을 이해하면 rsync의 동작 방식을 파악할 수 있습니다. 수신 측은 기존 파일을 고정 크기 블록으로 나눈 뒤, 각 블록마다 약하고 비용이 적은 체크섬과 강력하고 비용이 큰 체크섬을 각각 계산합니다. 이 목록을 송신 측에 보냅니다. 송신 측은 자신의 파일 위에서 윈도우를 1바이트씩 이동하며 약한 체크섬을 점진적으로 업데이트하는데, 이 과정 덕분에 바이트 단위의 스캔이 가능해집니다. 약한 체크섬이 일치하면 강력한 체크섬으로 다시 확인합니다. 확인된 일치 부분은 블록 참조로 처리됩니다. 나머지 데이터는 리터럴 바이트로 전송됩니다. 수신 측은 이미 보유한 블록 참조와 새로 받은 리터럴을 조합하여 파일을 재구성합니다.

대용량 파일의 시작 부분에 1바이트만 삽입해도 일반적인 차이점 분석 도구는 모든 오프셋이 밀리기 때문에 파일 전체를 다시 전송해야 합니다. 하지만 rsync의 롤링 윈도우는 새로운 오프셋에서 동일한 블록을 찾아내므로, 1바이트와 약간의 메타데이터만 전송하면 됩니다. 이러한 특성 덕분에 rsync는 여러 번 복사해야 하는 디렉터리를 다룰 때 여전히 가장 적합한 도구입니다.

사용자들이 자주 혼동하는 두 가지 동작이 있으며, 이는 모두 매뉴얼에 명시되어 있습니다. 첫째, rsync는 파일을 살펴볼지 결정할 때 체크섬을 사용하지 않습니다. 기본적으로 "파일 크기나 최종 수정 시간이 변경된 파일을 찾는 '퀵 체크(quick check)' 알고리즘"을 사용합니다. 따라서 파일 내용은 바뀌었으나 크기와 타임스탬프가 동일하면 해당 파일은 건너뜁니다. --checksum 옵션을 사용하면 이 동작이 변경되어 양쪽 모두 모든 후보 파일을 전체적으로 읽게 됩니다. 둘째, 두 경로가 모두 로컬인 경우 델타 알고리즘은 기본적으로 비활성화됩니다. 한 기기 내에서 두 사본을 읽고 체크섬을 계산하는 비용이 바이트를 그대로 복사하는 비용보다 크기 때문입니다. 이 방식은 네트워크 링크가 병목 구간일 때만 효율적입니다.

VPS에서 실제로 사용하는 도구와 그 이유

요약하자면, 파일 몇 개를 옮길 때는 SFTP를 사용하고, 반복해서 복사해야 하는 디렉터리에는 SSH 기반의 rsync를 사용합니다.

두 도구 모두 SSH를 기반으로 작동하므로, 별도의 설정 없이도 호스트 키 검증과 암호화 기능을 그대로 상속받습니다. 이는 50년간의 기술적 성과가 기본 설정으로 압축된 결과입니다. Kermit의 설계자들은 회선이 데이터를 손상시킬 것이라 가정하고 프로토콜 내부에 체크섬과 재전송 기능을 구축해야 했습니다. 오늘날에는 TCP가 이 역할을 수행합니다. Christensen과 Forsberg는 모든 바이트에 비용이 발생한다고 가정하고 이어받기(resume)와 스트리밍 기능을 구축했습니다. 오늘날에는 rsync의 델타 알고리즘이 이를 더 효율적으로 처리합니다. FTP의 저자들은 협력적인 호스트들로 구성된 네트워크를 가정했는데, 이 가정만이 프로토콜 수준의 노력으로는 해결할 수 없는 방식으로 틀린 것으로 판명되었습니다.

체크섬이 여전히 유효한 이유

"체크섬(checksum)"이라는 용어는 역사적으로 세 가지 서로 다른 역할을 수행해 왔으며, 이들은 상호 교환할 수 없습니다.

Kermit과 XMODEM의 패킷별 체크섬은 전송 과정에서의 데이터 손상을 감지했습니다. 오늘날에는 TCP 체크섬과 링크 계층의 오류 수정 기능이 이를 담당하므로, 현대의 전송 도구 중 이를 사용자가 직접 고려하게 만드는 것은 없습니다.

rsync의 블록 체크섬은 "이 데이터가 올바른가"라는 질문에 답하지 않습니다. 대신 "이 블록을 이미 가지고 있는가"라는 질문에 답합니다. 여기서 강력한 체크섬은 파일의 출처를 증명하는 것이 아니라, 데이터를 찾기 위한 조회 키(lookup key) 역할을 합니다.

세 번째 역할은 여전히 사용자에게 남아 있습니다. 릴리스 파일에 게시된 체크섬은 TLS가 해결할 수 없는 질문에 답합니다. TLS는 올바른 서버와 통신했음을 증명할 뿐, 해당 서버에 올바른 파일이 있었는지까지는 증명하지 못하며, 미러 사이트에서 가져온 파일에 대해서는 아무런 역할도 하지 못합니다. 이것이 바로 릴리스 체크섬과 서명을 확인하는 데 30초를 투자할 가치가 있는 이유이며, 습관을 들이기도 쉽습니다. 설치하는 모든 다운로드 파일의 체크섬을 확인하십시오.

이 이야기에서 다른 모든 문제는 하위 계층에 의해 해결되었습니다. 하지만 이 문제만큼은 해결되지 않았는데, 이는 애초에 네트워크 문제가 아니었기 때문입니다.

FAQ

VPS에서 FTP를 사용하는 것은 여전히 안전합니까?

아니요. 일반 FTP는 자격 증명과 파일 내용을 평문으로 전송하므로 경로상의 누구나 이를 읽을 수 있습니다. 또한 FTP는 제어 채널을 해석하는 방화벽에 의존하는데, TLS로 제어 채널을 암호화하는 순간 이러한 방식은 불가능해집니다. 브라우저들은 이미 FTP 지원을 중단했습니다. Firefox는 2021년 7월 버전 90에서, Chrome은 2021년 10월 버전 95에서 FTP 코드를 제거했습니다. 하나의 포트만 사용하며 프로토콜을 인식하는 중간 장비가 필요 없는 SSH 기반의 SFTP를 사용하십시오.

FTP는 왜 수동(passive) 모드가 필요한 것입니까?

FTP의 원래 모드에서는 서버가 클라이언트로 데이터 연결을 다시 시도하기 때문입니다. RFC 959는 서버의 기본 데이터 포트를 "제어 연결 포트와 인접한 포트(즉, L-1)"로 규정하므로, 제어 포트가 21번일 때 데이터 포트는 20번이 됩니다. NAT(네트워크 주소 변환) 뒤에 있는 클라이언트는 서버가 접근할 수 있는 주소를 가지고 있지 않으므로 연결이 도달하지 못하고 전송이 중단됩니다. PASV는 이 방향을 반전시킵니다. 서버가 대신 대기 상태가 되고, 클라이언트가 연결할 수 있도록 227 Entering Passive Mode 응답 내에 주소와 포트를 전달합니다.

scp는 여전히 자체 프로토콜을 사용합니까?

아니요. 2022년 4월 8일에 출시된 OpenSSH 9.0부터는 "scp(1)가 기존의 scp/rcp 프로토콜 대신 SFTP 프로토콜을 기본으로 사용하도록" 변경되었습니다. OpenSSH 8.8은 2021년 9월에 이 변경 사항을 예고했습니다. 눈에 띄는 차이점은 인용(quoting) 방식입니다. 기존 프로토콜은 원격 와일드카드를 원격 셸로 전달하여 확장했지만, SFTP 기반 프로토콜은 그렇지 않습니다. 따라서 해당 셸 확장에 의존하던 경로들은 이제 다르게 동작합니다.

VPS 환경에서 scp보다 rsync가 더 나은 경우는 언제입니까?

동일한 디렉터리 구조를 두 번 이상 복사할 때입니다. rsync는 대상에 이미 존재하는 부분을 제외하고 변경된 부분만 전송하므로, 두 번째 복사부터는 첫 번째보다 훨씬 효율적입니다. 대상에 한 번도 복사한 적 없는 단일 파일의 경우, scp와 rsync가 전송하는 데이터 양은 거의 비슷하며 scp가 더 간단합니다. rsync는 기본적으로 크기와 수정 시간을 기준으로 변경 여부를 판단한다는 점을 기억하십시오. 따라서 크기와 타임스탬프는 그대로인 채 내용만 변경된 파일은 rsync가 이를 감지할 수 있도록 --checksum 옵션이 필요합니다.

Kermit은 왜 파일을 원시 바이트로 보내지 않고 출력 가능한 텍스트로 인코딩했습니까?

Kermit이 대상으로 했던 연결은 바이트 파이프가 아니라 메인프레임으로 향하는 터미널 라인이었기 때문입니다. 해당 연결은 7비트일 수 있었고, 메인프레임의 터미널 드라이버는 제어 문자를 그대로 통과시키는 대신 이를 실행해 버렸습니다. Kermit은 제어 바이트와 상위 비트 바이트를 출력 가능한 문자로 인코딩하여 중간의 어떤 장치도 이를 오작동하게 하지 않도록 했습니다. 이 인코딩은 바이너리 파일을 전송 시 더 크게 만들지만, 데이터가 손상되어 도착하는 상황을 방지하기 위한 올바른 선택이었습니다.