요약

  • 초기 FTP 재시작은 송신 측과 수신 측의 체크포인트를 짝지었으며, 여기에는 저장 상태와 변환 상태까지 포함되었습니다. 이후REST STREAM은 마커를 전송 옥텟 오프셋으로 만들었습니다.
  • 마커는 동일한 전송 맥락 안에서 어디서부터 계속할지를 알려줄 뿐입니다. 그 경로명이 여전히 같은 버전을 가리키는지, 저장된 접두부가 그 버전과 일치하는지는 증명하지 못합니다.
  • RFC 3659의 예시는 재개에 앞서 서버 측 파일이 변경되지 않았음을 확인하는 절차를 보여줍니다. 이 문장이 대역폭 회복과 객체 무결성의 경계를 표시합니다.

안심시키는 중간 응답

FTP 다운로드가 802,816옥텟 이후 중단되었다고 가정해 봅시다. 클라이언트는 재접속하여 Image 타입을 선택하고REST 802816을 보내며350응답을 받은 뒤RETR을 이어서 보냅니다. 전송은 처음부터 다시 시작되지 않고 이어집니다.

이것은 완전한 복구 프로토콜처럼 보입니다. 그러나 그렇지 않습니다.350응답은 서버가 다음 전송 명령을 위해 재시작 값을 저장했다는 의미일 뿐입니다. 원격 파일이 같은 버전인지, 로컬 접두부가 그 파일에서 온 것인지, 802,817번째 옥텟이 의도한 접미부의 시작인지는 말해 주지 않습니다.

이 숫자가 유용한 이유는 나머지 사실들이 참으로 유지된다고 가정되기 때문입니다. 그 단순함은 그런 사실들을 숫자 밖에 두는 데서 나옵니다.

마커가 오프셋이 되기 전

RFC 765는 이미 재시작을 오류 복구로 다루고 있었습니다. 이 규격의REST명령은 파일 데이터를 이동시키지 않았습니다. 서버에게 마커 위치에 자신을 놓으라고 요청할 뿐이며, 그 뒤에는 끊긴 서비스 명령이 반드시 따라와야 했습니다.

이 마커는 의도적으로 보편적인 바이트 번호로 정의되지 않았습니다. FTP는 워드 크기, 문자 인코딩, 행 규약, 레코드 구조가 서로 다른 파일을 사용하는 기기들을 연결했습니다. 프로토콜은 저장된 파일의 논리적 바이트와 8비트 전송 바이트를 분리했으며, TYPE, STRUcture, MODE가 함께 데이터 연결에 나타날 내용을 결정했습니다.

RFC 959도 이 이질적 모델을 유지했습니다. 블록 모드와 압축 모드는 형식화된 데이터 스트림 속에 식별 가능한 재시작 마커 블록을 삽입할 수 있었습니다. 송신 측은 마커 안에 나중에 자신의 위치를 찾을 수 있을 만큼의 정보를 넣을 수 있었고, 수신 측은 그 마커를 도착한 파일을 저장한 방식과 대응시킬 수 있었습니다.

이 설계는 서로 다른 두 파일시스템이 하나의 보편적 좌표계에 동의할 것을 요구하지 않았습니다. 각 측이 자신의 좌표를 다시 인식할 것만 요구했습니다.

하나의 체크포인트, 두 가지 로컬 의미

RFC 1123은 RFC 959의 재시작 응답 서술에 있던 오류를 바로잡았습니다. 수정된 형식은 송신 측 시스템에서의 위치를 나타내는ssss와 수신 측 시스템에서의 대응 위치를 나타내는rrrr를 짝지었습니다. 각 값은 나중에 자신을 만든 시스템으로 되돌아가기 때문에 인코딩은 구현 고유의 형태로 남을 수 있었습니다.

이 짝은 진행 상황 이상을 담았습니다. 체크포인트 중 자기 측을 보고하기 전에 수신 측은 그 앞의 모든 데이터를 안정 저장소에 강제로 기록하도록 권고되었습니다. 그렇지 않으면 마커가 전송을 중단시킨 바로 그 충돌과 함께 사라진 바이트로부터의 복구를 약속할 수 있습니다.

변환 상태도 중요했습니다. RFC 1123은 정확한 예시를 들었습니다. TYPE A 변환 과정에서 수신 측은 회선상의 CR LF를 로컬 LF 하나로 바꿀 수 있습니다. 재시작 마커가 CR과 LF 사이에 도착하면, 수신 위치는 CR이 이미 보고 버려졌다는 사실을 기억해야 합니다. 단순한 디스크 오프셋으로는 디코더의 상태를 재구성할 수 없습니다.

이 문서는 또한 복원할 수 없는 위치에 대해554를, 기존 부분 파일과 현재 TYPE 또는 STRUcture의 불일치에 대해555를 정의했습니다. 문법적으로 유효한 마커조차 조건부였습니다.

스트림 모드는 불투명함을 셈하기로 교환했다

마커 시스템은 유능했지만 무거웠습니다. RFC 1123은 재시작, ABOR, 블록 모드를 1989년 당시 널리 구현되지 않은 가치 있는 견고성 기능으로 서술했고,REST는 최소 FTP 명령 집합에 포함되지 않았습니다.

평범한 스트림 모드는 더 단순한 기회를 만들었습니다. 그 데이터 연결에는 형식화되지 않은 데이터 옥텟이 흐르므로, 삽입된 마커는 파일 내용과 구별될 수 없습니다.RFC 3659는 또 다른 해석을 표준화했습니다.REST STREAM의 경우 10진수 값은 다음 전송이 건너뛸 옥텟 수입니다.

이 확장은 발견 가능해야 했습니다. 이 형식을 지원하는 서버는RFC 2389가 정의한 기능 협상 메커니즘인FEAT를 통해REST STREAM을 공지합니다. 따라서 클라이언트는 브랜드나 실패한 시도로부터 지원 여부를 추측할 필요가 없습니다.

셈하기가 표현 문제를 없애지는 않았습니다. RFC 3659는 저장된 한 텍스트 파일의SIZE가 TYPE I에서는 1,830이지만 TYPE A에서는 1,942가 되는 예를 보여줍니다. 행 끝이 추가 전송 옥텟을 갖기 때문입니다. 재시작 숫자는 선택된 매개변수로 전송될 스트림에 속하며, 자동으로 로컬 파일의 원래 바이트 배치에 속하지는 않습니다.

재개된 업로드에서 이 구분은 실무적으로 중요합니다. 클라이언트는 서버가 얼마를 올바르게 받아 저장했는지 알아야 합니다.SIZE는 현재 TYPE에서 전송 길이를 알려줄 수 있지만 그것도 길이일 뿐입니다. 저장된 접두부의 다이제스트는 아닙니다.

위치는 자신의 객체를 식별할 수 없다

RFC 3659의 예시는 보기 드물게 솔직합니다. 802,816에서 재개하기 전에, 이전 전송이 TYPE I를 사용했으며 서버의 파일이 변경되지 않았음이 확인되었다고 명시합니다.

이 확인은REST가 수행하는 것이 아닙니다. 그 경로명이 이제 충분한 길이의 다른 파일로 해석된다면 같은 오프셋이 그대로 받아들여질 수 있고, 클라이언트는 낡은 접두부와 새 접미부를 이어붙일 수 있습니다. 크기가 같다고 문제가 해결되지 않습니다. 두 버전이 같은 길이를 가질 수 있습니다. 마지막 성공 응답은 요청된 FTP 동작이 완료되었음을 증명할 뿐, 조립된 바이트가 운영자가 의도한 동일성을 가졌음을 증명하지 않습니다.

업로드 재개에는 더 예리한 한계가 있습니다. RFC 3659는 이를 이전에 실패한 전송의 완성으로 정의합니다. 재시작 지점이 이미 저장된 바이트의 끝이 아니거나, 새 데이터가 객체를 최소한 이전 크기까지 확장하지 못하면 결과는 정의되지 않습니다.APPE는 그 계약을 우회하는 지름길이 아닙니다.REST이후에 허용된다면 선택된 위치에서STOR처럼 동작해야 합니다.

순서 지정도 상태의 일부다

REST는 반드시 전송 명령 바로 앞의 마지막 명령이어야 합니다. 서버는 마커를350으로 받아들인 뒤에도, 위치가 범위를 벗어났거나 적용할 수 없음을 발견하면 뒤따르는RETR이나STOR를 거부할 수 있습니다. 전송 명령이 성공적으로 보내지지 않았다면, 신중한 클라이언트는 저장된 값이 무관한 대화를 사이에 두고 살아남았다고 가정하지 않고REST를 다시 보냅니다.

따라서 프로토콜은 복구 상태를 여러 곳에 분산시킵니다. 로컬 부분 데이터, 선택된 표현, 서버 능력, 저장된 마커, 다음 명령, 경로명을 둘러싼 동일성 검사가 그 대상입니다. 오프셋을 상태 기계 전체로 다루는 것이 바로 실수입니다.

출처와 근거의 한계

원래 체크포인트 모델은 RFC 765에, 고전적 명령 및 전송 모드는 RFC 959에, 수정된 짝지은 마커와 안정 저장소 절차는 RFC 1123에, 기능 발견은 RFC 2389에, STREAM 재시작,SIZE, 명령 순서 및 예시는 RFC 3659에 문서화되어 있습니다. 이 규격들은 의미를 확립할 뿐, 현재 배포 비중이나 특정 서버가 버전을 보존한다는 증거를 제공하지 않습니다. FTP 재시작은 인증도, 콘텐츠 해시도, 정확히 한 번 전송도, 저장소 스냅샷도 아닙니다.