요약

  • 트레일러 캡슐화는 가변 길이의 상위 계층 헤더를 링크 패킷 내부에서 데이터 뒤로 옮겨, 적합한 수신 시스템이 페이지 정렬 메모리를 활용할 기회를 제공했다. 수신 시스템은 상위 계층 처리 전에 정상적인 패킷을 재구성했다.
  • 복사를 피하는 것은 수신 측 아키텍처와 그 비용에 따라 조건부였다. 헤더가 뒤로 밀리면, 다른 구현이 패킷 앞부분에서 먼저 검사할 수 있는 정보를 사용하기 전에 패킷 전체를 버퍼링해야 했다.
  • 선택적 사용에는 링크 피어의 지원 여부에 대한 확정적 지식이 필요했다. 1989년까지 호스트 요구사항은 목적지별 협상을 명시하고, 동적 협상이 없을 경우 기본값을 꺼진 상태로 둘 것을 요구했다.

유용한 블록 앞에 놓인 불편한 바이트들

네트워크 수신 시스템이 모든 바이트를 복사하는 대신 페이지 매핑을 변경하여 프로그램에 데이터를 제공할 수 있다고 가정해 보자. 그 가능성은 데이터가 어디서 시작하는지에 달려 있다. 메모리 페이지 중간에서 시작하는 블록은 페이지 단위 보호와 재매핑을 위해 정렬된 블록과 서로 교환할 수 없다.

그 앞에 가변 길이 헤더를 놓아 보자. 링크 접두어의 크기가 예측 가능하더라도, 변하는 상위 계층 헤더들이 유용한 데이터를 계속 밀어낸다. 데이터를 정렬 상태로 복사하는 일은 수신 시스템이 피하고자 했던 바로 그 작업을 소모할 수 있다.

1984년 4월에 발표된RFC 893은 이 장애물을 우회하는 방법을 기술했다. 링크상에서 가변 헤더를 데이터 뒤로 옮기는 것이다. 그러면 수신 시스템은 더 유리한 정렬 조건에서 대용량 데이터 블록을 처리하고, 더 작은 헤더들을 상위 계층 프로토콜이 기대하는 위치로 되돌려 놓을 수 있었다.

이 문서는 당시 4.2BSD UNIX 및 기타 시스템에서 사용되던 형식을 기술했다. 공식 ARPA 인터넷 프로토콜이 아니라 명시적으로 정보 제공용이었다. 그 주제는 인터넷 트래픽의 강제적 재배치가 아니라, 수신 구현에 대한 조건부 개선이었다.

도착이 복사 비용의 끝은 아니었다

네트워크 데이터는 장치와 메모리 사이, 또는 운영체제와 사용자 주소 공간 사이에서 복사될 수 있었다. 적합한 가상 메모리 아키텍처에서는 페이지 테이블을 변경하는 것이 내용을 다시 옮기는 대안이 될 수 있었다.

RFC 893의 논의는 일반적으로 페이지 정렬된 데이터와 페이지 크기의 배수이거나 페이지 경계까지 채워진 크기, 그리고 페이지 단위 보호를 요구했다. 또한 하드웨어 아키텍처가 이 전제 조건을 바꿀 수 있음을 인정했다. 그 형식은 보편적인 제로카피 수신을 약속하지 않았다.

헤더를 방해 위치에서 치워두면 이 기회를 활용하기 쉬워졌다. 하지만 이더넷 전송 속도를 빨라지게 하거나, 모든 헤더 복사를 없애거나, 재매핑 비용이 무시할 수준이라는 것을 증명하지는 않았다. 이 문서의 512바이트 데이터를 다룬 VAX 예시는 그 아키텍처적 환경에 속한다. 현대의 페이지 크기에 적용되는 규칙이 아니며, IP와 TCP 헤더의 결합 길이가 항상 고정이라는 주장도 아니다.

이 구분이 중요한 이유는 역사적 구현 보고서가 재전해지는 과정에서 쉽게 시대를 초월한 성능 주장으로 변할 수 있기 때문이다. 저자들은 자신들의 구현에 대한 이점을 보고했다. 이 글은 현행 하드웨어에 대한 새로운 벤치마크, 개선 비율 또는 측정치를 제공하지 않는다.

같은 패킷 안의 꼬리

트레일러는 나중에 도착하는 지시를 실은 두 번째 패킷이 아니었다. 또한 응용 프로그램이 파일에 덧붙이는 푸터도 아니었다. 그것은 동일한 링크 계층 패킷의 일부였으며, 상위 계층에서 논리적으로 앞서는 헤더들이 데이터 뒤에 배치된 형태였다.

링크 타입 정보가 이 특수 형식을 식별하고 수신 시스템이 트레일러의 위치를 찾도록 했다. 꼬리 부분은 원래 프로토콜과 헤더 길이에 대한 정보를 포함했고, 그 뒤에 원래의 상위 계층 헤더들이 따라왔다. 수신 시스템은 캡슐화 전용 자료를 제거하고 일반적인 헤더-데이터 관계를 재구성했다.

따라서 TCP는 다른 시퀀스 의미를 갖게 되지 않았다. 응용 프로그램은 그 바이트들이 회선에서 먼저 도착했다는 이유만으로 미처리 데이터를 소비할 허가를 받지 않았다. 올바른 재구성은 이 로컬 재배치를 상위 프로토콜의 시야에서 벗어나게 유지했다.

역시 1984년 4월에 발표된RFC 894의 기준선은 단순한 이더넷 상의 IP였다. IP 헤더 바로 뒤에 IP 데이터가 이어지는 배열이었다. 그 배열을 읽을 수 있는 호스트가 대안적 배열을 해석할 수 있다는 보장은 없었다. 동일한 프로토콜을 실는다고 해서 표현 방식의 차이가 사라지지 않았다.

재배치가 링크의 용량을 늘리지도 않았다. 확인된 기술적정정 사항 570은 RFC 894의 1500 옥텟 기술을 최소값에서 최대값으로 바로잡는다. 이더넷 최소 데이터 길이까지의 패딩은 IP 총 길이에서 별도로 제외된다. 메모리 정렬, 패딩, 링크 용량은 하나의 숫자로 뭉뚱그려져서는 안 된다.

헤더를 늦게 찾는 대가

RFC 893은 이 거래의 조건을 제시했다. 수신 시스템은 트레일러를 사용할 의사와 능력이 있어야 했다. 정렬을 얻는 비용이 절감분보다 작아야 했다. 꼬리 헤더는 데이터에 비해 작아야 했고, 피해가는 복사는 추가 소프트웨어 복잡성을 정당화할 만큼 가치 있어야 했다.

타이밍 비용도 있었다. 수신 시스템은 이제 끝에 놓인 정보를 처리하기 전에 패킷 전체를 버퍼링해야 했다. 헤더를 일찍 검사하는 구현은 원치 않는 트래픽을 거부하거나 패킷 전체가 도착하기 전에 자원을 배정할 기회를 잃을 수 있었다.

이 문서는 지연된 타입 인식을 타당한 비판으로 인정했다. 그 대답은 제한적이었다. 문서가 논의한 DMA 사례에서는 완전한 패킷이 그 처리가 시작되기 전에 이미 수신된 상태였다는 것이다. 이것은 왜 그 거래가 그 환경에서 타당할 수 있었는지 설명한다. 모든 DMA 하드웨어, 특히 현행 하드웨어가 동일한 수신 경로를 갖는다는 것은 확립하지 않는다.

발신자에게 작은 재배치처럼 보이는 것이 수신자마다 다른 결과를 낳을 수 있었다. 어느 수신자는 상당한 복사를 피할 수 있었다. 다른 수신자는 상응하는 이득 없이 추가 버퍼링이나 복잡성만 떠안을 수 있었다. 수신자 동의가 엔지니어링의 일부였다. 그 계산의 한쪽 면을 소유한 쪽이 수신자였기 때문이다.

한 인터페이스가 모든 이웃을 대변할 수는 없었다

RFC 894는 같은 이더넷상의 합의한 시스템들이 트레일러를 사용하도록 허용하면서도, 어떤 호스트도 이를 구현할 의무가 없다고 했다. 발신자는 수신자가 그 형식을 해석할 수 있다는 확정적 지식이 필요했다. 일반 캡슐화가 호환 가능한 기준선으로 남았다.

1984년의 기술은 실질적 한계를 드러냈다. 당시 기술된 4.2BSD의 선택은 부팅 시 인터페이스별로 이루어졌다. 공유 매체상의 필요한 협조를 갖추고 트레일러를 사용하거나, 아니면 그 인터페이스를 통해 절대 전송하지 않는 것 중 하나였다. ARP를 이용한 호스트별 협상이 가능하거나 기대되는 개선으로 논의되었다.

1989년 10월까지RFC 11222.3.1절은 더 엄격히 경계지어진 배치를 명시했다. 링크 교환의 양쪽 참여자, 즉 호스트든 게이트웨이든, 트레일러 지원 여부가 확인되어야 했다. 동적 목적지별 협상이 없다면 기본 구성은 그 사용을 비활성화해야 했다.

이 문서들은 인터페이스 전역 가정이 기술된 사례 뒤에 목적지별 교환이 명시된 사례를 보여준다. 모든 구현의 최초 출하 시점을 확립하지 않으며, 1989년까지 모든 BSD 릴리스가 변함없이 유지되었음을 보여주지도 않는다. 방어 가능한 역사적 비교는 문서화된 요구사항과 메커니즘 사이의 비교이다.

주소를 아는 것은 형식을 아는 것이 아니었다

ARP의 평범한 성공이 새로운 호환성 질문에 답하지는 않았다.RFC 826은 다음 홉 결정 이후에 선택된 링크에서 프로토콜 주소를 하드웨어 주소로 매핑했다. 프레임을 어디로 보낼지 안다는 것이 이웃이 그 프레임이 담을 수 있는 모든 선택적 형식을 해석할 수 있음을 증명하지는 않았다.

필드들도 서로 다른 역할을 했다. ARP를 가리키는 외부 이더넷 타입, ARP 내부의 프로토콜 주소 공간 필드, 요청과 응답을 구분하는 연산 코드는 서로 교환 가능한 하나의 타입 값이 아니었다. 트레일러 협상은 이 의미들을 분리해 유지하는 데 의존했다.

RFC 1122에 기술된 구현은 평범한 IP ARP 교환을 그대로 유지했다. 트레일러 수신을 의사가 있는 시스템은 추가로 Trailer ARP 응답을 보냈는데, 평범한 응답 형식을 사용하면서 ARP 내부에서 트레일러 프로토콜을 식별했다. 이것은 기본 IP 응답을 대체하지 않았고, 선행하는 Trailer ARP 요청을 필요로 하지도 않았다.

양쪽 역할 모두 수신 능력을 알릴 수 있었다. 평범한 ARP 요청의 수신자는 IP 응답과 함께 추가 응답을 보낼 수 있었다. 최초의 요청자는 짝이 맞는 평범한 IP 응답이 도착했을 때 자신의 능력을 알릴 수 있었다. 각 통지는 자신의 발신자를 잠재적 트레일러 수신자로 기술했다.

이 형식을 사용하도록 구성된 호스트는 이웃의 능력을 기록할 수 있었다. 예를 들어 ARP 항목의 플래그로 기록하는 방식이다. 이것은 응용 프로그램의 전달 확인도, 성능 보장도, 암호학적 인증도 아니었다. 링크 피어에 관한 한 가지 구체적 지식이었다.

게이트웨이 맥락은 이 범위를 중요하게 만든다. 1987년 6월에 발표된RFC 1009는 게이트웨이가 링크 밖의 도달 가능한 목적지에 대해 자신의 인터페이스 주소로 응답하는 프록시 ARP 사례를 설명한다. 그 교환을 통해 학습된 링크 피어가 응용 프로그램의 최종 통신 상대일 필요는 없다. 그 피어의 능력은 전체 경로를 인증할 수 없었다.

응답에는 완료되지 않은 질문이 필요했다

추가 응답은 작지만 결과가 큰 상태 문제를 가져왔다. 오동작하는 호스트가 Trailer ARP 응답에 대해 평범한 IP ARP 응답으로 답할 수 있었다. 이웃이 모든 IP 응답에 또 다른 트레일러 통지로 답한다면, 응답이 응답을 계속 낳을 수 있었다.

RFC 1122는 교환의 이 분기를 제한했다. IP 응답에 대한 응답으로 보내지는 Trailer ARP 응답은 그 IP 응답이 아직 처리되지 않은 요청에 대한 답일 때만 발생해야 했다. 즉 그 응답을 처리하기 전에 하드웨어 주소가 아직 미해결 상태여야 했다. 들어오는 요청에 대한 평범한 답과 함께 추가 통지를 보내는 것은 별개의 허용 사례였다.

이 가드는 발명된 재시도 횟수, 타이머, 인증 체계를 필요로 하지 않았다. 그것은 로컬 이력에 의존했다. 이 응답이 해소하는 아직 걸려 있는 질문이 존재하는가? 그 일이 더 이상 걸려 있지 않게 되면, 들어오는 응답이 그 자체로 대화를 계속할 근거가 되지 않았다.

이것은 추론에 대한 두 번째 경계였다. 평범한 ARP가 트레일러 지원을 증명하지 않았고, 임의의 IP ARP 응답이 또 다른 트레일러 응답이 필요함을 증명하지도 않았다. 구현은 익숙한 패킷 모양을 단순히 인식하는 데 그치지 않고 자신의 행동 뒤에 있는 이유를 보존해야 했다.

일부 트래픽은 불일치를 감출 수 있었다

RFC 1122는 트레일러가 특정 크기 속성을 가진 패킷에만 선택된다고 경고했고, 그 논의에서 그러한 패킷은 대체로 작은 비율에 그쳤다. 따라서 불일치가 일부 패킷은 통과시키면서 다른 패킷을 블랙홀로 보낼 수 있었다. 짧게 성공한 교환은 특수 수신 경로를 전혀 시험하지 못했을 수 있다.

이것은 모든 큰 패킷이 실패했다는 주장도, 크기 관련 손실이 무엇이든 트레일러 캡슐화를 입증한다는 주장도 아니다. 실제 형식과 피어의 상태에 대한 증거가 필요했다. 역사적 실패 메커니즘은 수신자가 읽을 수 없는 표현의 조건부 선택이었으며, 반드시 MTU 부족일 필요는 없었다.

이 경고는 피어별 지식의 논거를 완성한다. 이웃이 도달 가능하다는 거친 관찰은 세밀한 비호환성을 감출 수 있었다. 평범한 네트워크가 작동하는 것처럼 보이더라도, 예외적 형식에는 그 자체의 증거가 필요했다.