요약

  • RFC 1986은 많은 패킷을 하나의 버퍼와 버스트로 묶어, 단 한 번의 비용이 큰 채널 접속으로 상당한 데이터를 실어 보낼 수 있게 했습니다. 수신자는 버퍼당 한 번만 응답하며, 누락된 패킷 번호만 지정했습니다.
  • CONTROL_OK,CONTROL_RESEND, 최고 연속 제어 시퀀스 번호,NULL-ACK은 정밀한 로컬 영수증이었지만, 그 어느 것 하나만으로 전체 파일 완료, 상대방 신원, 보안 또는 손실 원인을 증명하지는 못했습니다.
  • 1993년의 결과는 하나의 실험용 지점 간 설정을 보여준 것이지 일반적 채택을 보여준 것이 아니었습니다. RFC 자체가 인증이 없으며 보안이 간과되었다고 명시했습니다.

하나의 확인 응답은 또 하나의 동기화 비용이 될 수 있었다

RFC 1986은 물리적 사실에서 출발합니다. 묘사된 전술 위성 경로에서는 송신 전에 무선 및 암호 동기화에 약 1.25초가 걸렸습니다. 위성 전파 지연이 왕복에 약 반 초를 더했습니다. 반이중 링크에서 응답은 데이터와 함께 흘러가는 값싼 패킷이 아니었습니다. 한 방향을 내려놓고, 반대 방향을 다시 구축하고, 채널 접속을 한 번 더 소모하는 일이었습니다.

따라서 ETFTP는 방향 전환을 하나의 예산으로 다루었습니다. 파일은 버퍼로 읽히고, 각 버퍼는 블록으로 나뉘고, 블록은 DATA 패킷이 되며, 패킷들은 버스트로 연결됩니다. 버퍼의 마지막 블록은 LDATA로 표시됩니다. 패킷마다 확인하는 대신, 수신자는 버퍼 경계에서 응답했습니다. 버퍼가 완전하면CONTROL_OK를 보냈습니다. 구멍이 남아 있으면CONTROL_RESEND가 버퍼 번호와 다시 보내야 할 패킷 번호를 명시적으로 담았습니다.

이것은 단순히 "확인 응답 수를 줄인 것"이 아니었습니다. 증거의 단위가 바뀐 것입니다. 패킷 체크섬은 하나의 데이터그램을 서술했습니다. 누락 패킷 목록은 수신자의 현재 시점에서 한 버퍼에 대한 관점을 서술했습니다. OK는 그 버퍼를 닫았습니다. 최종 전송 종결에는 여전히 송신자의QUIT과 수신자의DONE이 필요했습니다.

버퍼, 버스트, 패킷은 서로 다른 제어 단위였다

이 세 단위의 구별은 중요했습니다. 더 큰 버퍼는 확인 경계의 수, 즉 채널 방향 전환의 수를 줄였습니다. 더 큰 버스트는 여러 패킷이 경로로 들어가는 동안 송신기를 계속 송신 상태로 유지했습니다. 패킷 크기는 오버헤드와 오류 노출 사이의 절충이었습니다. 큰 패킷은 깨끗한 경로에서 처리량을 높일 수 있지만, 높은 비트 오류율이 손상을 주면 더 큰 비용을 치렀습니다.

RFC 1986은 이러한 매개변수를 조정 가능하게 했습니다. 자동 적응이 활성화된 상태에서, 블록의 절반 이상이 재전송을 필요로 하는 버퍼는 하향 시퀀스를 트리거했습니다. 패킷 크기를 절반으로 줄이고, 그다음 버스트 크기를 줄이고, 그다음 제공하는 버스트 비율을 측정된 타이트 타이머 비율 쪽으로 낮추는 방식이었습니다. 패킷의 99퍼센트가 재전송 없이 도착하면 패킷 크기를 상향 제안할 수 있었습니다.CONTROL_OK는 제안된 새 값을 담았고, 송신자는 유효한 변경을NULL-ACK으로 확인했습니다.

이 교환은 작고 결정론적인 공통 계층을 형성했습니다. 양쪽 구현 모두 버퍼 번호, 누락된 패킷 번호, 제안된 매개변수 값을 검사할 수 있었습니다. 그러나 확인은 실행의 증명이 아니었습니다.NULL-ACK은 송신자가 변경 요청을 수용했음을 보여줄 뿐이며, 양쪽이 같은 경계에서 그 변경을 적용했는지는 다음 패킷들만이 보여줄 수 있었습니다.

연속된 번호는 완전한 파일이 아니었다

DATA 및 LDATA 패킷은 수신된 것 중 최고 연속 CONTROL 시퀀스 번호를 담았습니다. 이 필드는 제어 측이 관찰된 메시지의 어느 연속 접두부까지를 알았는지 확인하는 데 도움이 되었습니다. 그러나 모든 데이터 패킷이 도착했는지, 이후의 모든 제어 메시지가 존재하는지, 표시된 파일 길이가 디스크에 도달한 것과 일치하는지를 말해주지는 않았습니다.

같은 원칙이CONTROL_RESEND에도 적용됩니다. 이것은 수신자의 현재 버퍼 상태 아래에서 명명된 패킷 번호가 없었다는 것을 증명했습니다. 송신자가 그 패킷들을 한 번도 내보내지 않았다는 것을 증명하지는 않았습니다. 무선 오류인지, 경합인지, 큐 넘침인지, 타이밍 오류인지, 구현 지연인지 구별할 수 없었습니다. 타이머들 역시 추정치였습니다. 전송 속도와 무선 지연은 제공되거나 추론된 값이었고, 반복된 읽기 타임아웃은 5초씩 선형적으로 추가되었습니다. 타임아웃은 충족되지 않은 타이밍 기대의 증거이지 진단이 아니었습니다.

Lu Heng의 Running-Code Primacy를 통해 읽으면, 중요한 구분은 공표된 형식과 실행된 전이 사이의 구분입니다. RFC 1986은 영수증이 무엇을 의미하는지 정확히 명세할 수 있었습니다. 구현이 그 의미를 실제로 존중했는지를 보이려면 운영자는 여전히 트래픽과 상태 증거가 필요했습니다.

실험은 교훈보다 좁았다

성능 표는 16 kbps 암호화 경로를 통과한 101,306바이트 파일에서 나왔습니다. 무선기는 동축 케이블로 연결되어, 저자들이 깨끗한10e-5BER 링크라고 부른 환경을 이루었습니다. 보고된 표 중 최고 결과는 131,072바이트 버퍼, 2,048바이트 패킷, 버스트당 16패킷 조합에서 10,432 bps였습니다. 이 수치에는 사용자 관점에서 접속, 복구, 연결 해제 시간이 포함되어 있었습니다.

이것들은 유용한 결과였지만, 경계가 있는 결과였습니다. 멀티캐스트 동작, 공유 채널의 공정성, 현대 무선 성능 또는 광범위한 배포를 확립하지는 못했습니다. 문서 자체가 점대점 지속 설정은 더 많은 사용자가 채널을 공유할 때 적절하지 않을 것이라고 경고했습니다. 문서에는 드러나는 패킷 크기 모순도 있었습니다. 조정 가능한 범위는 16바이트에서 1,448 사용자 바이트로 서술되어 있지만, 테스트 표에는 2,048바이트 패킷이 포함되어 있었습니다. 기록은 그 불일치를 조용히 수습하지 말고 그대로 보존해야 합니다.

보안은 추론만 하면 되는 함축된 속성이 아니었습니다. RFC 1986은 ETFTP에 사용자/비밀번호 검증이 없었고, TFTP의 보안 문제를 반복했으며, 프로토타입에서 root 소유의 setuid 서버를 사용했다고 서술했습니다. 연결 ID, 포트, 체크섬, 시퀀스 값은 프로토콜 상태를 상호 연관시켰지만, 사람을 인증하거나 파일 작업을 승인하지는 않았습니다.

RFC 1986의 지속적 기여는 숨겨진 물리적 비용을 프로토콜 구조 안에서 가시화한 것입니다. 이것은 더 적은 방향 전환으로 긴 데이터 실행을 사들이고, 구멍은 압축된 목록으로 수복했습니다. 그 영수증들이 가치가 있었던 것은 정확히 그 주장이 제한적이었기 때문입니다. 버퍼 OK는 버퍼 OK였습니다. 완료, 신원, 원인, 보안은 별개의 사실로 남았습니다.

출처