요약

  • RFC 3081은 BEEP 세션을 하나의 TCP 연결에 매핑하면서도, TCP의 연결 전체 흐름 제어를 개별 멀티플렉스 채널 각각이 진행될 수 있다는 증거로 받아들이지 않았습니다.
  • 모든 채널은 4096옥텟의 수신 크레딧으로 시작했습니다.SEQ프레임은 그 로컬 경계를 이동시키며 스케줄링 우선순위를 부여받았고, 구현체들은 채널을 라운드로빈 방식으로 처리하도록 권고받았습니다.

신뢰성이 다음에 누구의 작업이 움직일지를 결정하지는 않았다

네 개의 애플리케이션 채널이 깨끗한 TCP 연결을 공유한다고 가정해 봅시다. 세 소비자는 즉시 읽습니다. 네 번째는 데이터를 느리게 수용하는 반면 그 송신자는 전달할 훨씬 많은 데이터를 보유하고 있습니다. TCP는 자신이 약속한 것을 정확히 계속 수행할 수 있습니다: 바이트 순서 유지, 손실 복구, 상대방 수신 용량에 맞춘 연결 조절. 그럼에도 느린 애플리케이션이 공유 경로를 충분히 점유하여 무관한 채널들이 그 뒤에서 대기하게 될 수 있습니다.

이 상황에 깨진 패킷이나 실패한 연결은 필요하지 않습니다. 이것은 신뢰할 수 있는 운반체 내부에서의 수용과 서비스에 관한 분쟁입니다.

2001년 3월 표준 트랙(Standards Track)으로 공표된 RFC 3081은 Blocks Extensible Exchange Protocol이 TCP를 사용하는 방식을 정의했습니다. 그 매핑은 간소했습니다. 하나의 BEEP 세션이 하나의 확립된 TCP 연결 위에 놓이고, BEEP 메시지는 그 스트림의 페이로드 옥텟이 되었습니다. 그러나 이 문서는 단순한 매핑을 완전한 격리 정책으로 오해하지 않았습니다. 여러 논리 채널이 TCP의 단일 흐름 제어 컨텍스트를 공유할 때 발생하는 기아(starvation)와 교착(deadlock)을 위험으로 명시했습니다.

하나의 연결에는 하나의 TCP 윈도우가 있었다

TCP는 연결 단위로 시퀀스 공간과 용량을 다룹니다. 어떤 바이트가 관리 교환에 속하고 어떤 바이트가 빠른 요청에, 또 어떤 바이트가 대량 애플리케이션 응답에 속하는지는 알지 못합니다. 이러한 구분은 TCP 위의 계층에 존재합니다.

따라서 RFC 3081은 각 BEEP 채널에 별도의 슬라이딩 윈도우를 할당했습니다. 채널 생성 시, 채널은 4096개의 페이로드 옥텟을 보낼 권한을 갖습니다. 수신자는 이후 자신이 기대하는 다음 시퀀스 번호와 수용할 준비가 된 윈도우 크기를 담은SEQ프레임을 발행할 수 있습니다. 이 두 값이 함께 채널 로컬 상한을 광고합니다.

이 메커니즘은 두 번째 신뢰성 프로토콜이 아니었습니다. TCP는 이미 하위 바이트를 재전송하고 순서를 정렬합니다. BEEP의 시퀀스 회계는 다른 질문에 답했습니다: 이 특정 채널이 공유 연결에 얼마나 더 많은 애플리케이션 페이로드를 유입할 수 있는가? 경계에 도달한 송신자는 TCP 자체가 여전히 쓰기 가능하더라도 해당 채널을 멈추어야 했습니다.

일련번호 산술이 중요한 이유는 카운터가 랩(감김)하기 때문입니다. RFC 3081은 RFC 1982의 산술을 참조하고 윈도우를 경계로 묶어 비교가 모호해지지 않도록 했습니다. 그 작은 수식은 실제로 하나의 제어 경계였습니다. 랩된 숫자가 오래된 크레딧을 새로운 권한으로 바꾸어서는 안 되는 것입니다.

크레딧은 자신이 제어하는 큐를 벗어나야 했다

흐름 제어 갱신은 송신자에게 도달할 수 있을 때만 유용합니다. 만약SEQ가 자신이 풀어 주려는 바로 그 채널이나 연결의 일반 페이로드 뒤에서 대기한다면, 피드백 루프는 얼어붙을 수 있습니다. 이에 RFC 3081은SEQ프레임에 다른 트래픽보다 우선순위를 부여했습니다.

그 우선순위는 관리 정보가 애플리케이션 콘텐츠보다 가치 있다는 뜻이 아니었습니다. 제어 정보가 추가 전송의 인과적 상류에 놓여 있다는 뜻입니다. 수신자는 더 많은 자료가 그 차선에 유입되기 전에 “이 차선은 진행할 수 있다”고 말할 수 있어야 했습니다.

RFC는 또한 동일한 우선순위의 채널들 사이에서 라운드로빈 방식의 서비스를 권고했습니다. 이 권고는 의도적으로 절제된 것이었습니다. 라운드로빈은 모든 운영체제 버퍼와 혼잡 패턴에서 동일한 지연 시간, 동일한 메시지 크기, 완벽한 공정성을 보장하지 않습니다. 그것은 명백한 실패 모드에 대한 기준선을 구현체에 제공한 것입니다: 준비된 이웃 채널에게는 차례가 오지 않는 채 바쁜 하나의 채널을 무한히 비우는 실패 말입니다.

느린 읽기 측은 프로토콜 경계 바깥에 있었다

수신자는 BEEP 채널에 바이트가 도착했음을 인정하면서도 그 위의 애플리케이션이 느릴 수 있습니다. 겉보기 성공이 오해를 낳는 지점이 바로 여기입니다. TCP 수신, BEEP 윈도우로의 수용, 목적지 애플리케이션의 소비는 서로 다른 세 가지 관찰입니다.

RFC 1122는 이미 TCP가 애플리케이션 트랜잭션 완료가 아니라 신뢰할 수 있는 바이트 스트림 서비스를 제공함을 명확히 했습니다. 최신 TCP 사양인 RFC 9293도 그 경계를 유지합니다. RFC 3081은 TCP에 BEEP의 채널을 인식하도록 요구하는 대신 그 위에 구축되었습니다.

이후의 매핑들은 이 구분이 왜 중요했는지를 보여줍니다. RFC 3195의 BEEP 기반 신뢰성 syslog는 BEEP의 교환 및 전송 기계를 사용했고, RFC 4744의 BEEP 기반 NETCONF는 네트워크 관리 시맨틱을 하나의 프로필에 결합했습니다. 어느 애플리케이션도 바이트가 TCP를 통과하거나 채널 크레딧이 진행했다는 이유만으로 최종 운영 효과를 추론할 수 없습니다.

윈도우는 증거였지, 영구적인 자격이 아니었다

광고된 용량의 소유자는 수신자였습니다. 버퍼링과 전달의 비용을 부담하는 주체이기 때문입니다. 다음에 어느 크레딧 보유 채널을 스케줄할지 선택하는 권한은 송신자에게 있었고, 여기에는 각 채널의 현재 크레딧과 매핑의 우선순위 규칙이 제약으로 작용했습니다. TCP는 여전히 연결 수준의 혼잡 제어와 신뢰할 수 있는 전송을 담당했습니다. 수신된 자료가 유의미한 효과를 낳았는지는 애플리케이션이 결정했습니다.

이 권한들은 인접해 있었지만 서로 교체 가능하지 않았습니다. 열린 TCP 송신 버퍼가 채널 윈도우를 넘는 BEEP 페이로드를 정당화하지 않았습니다. 새 BEEP 크레딧이 이전 데이터의 애플리케이션 처리를 증명하지 않았습니다. 라운드로빈 구현은 차례를 제공했다는 사실은 보여줄 수 있지만, 하류 작업이 완료되었다는 증거가 되지는 않았습니다.

이것이 RFC 3081의 지속적인 기여입니다. 멀티플렉싱은 차선에 이름을 붙인다고 독립성을 만들어 내지 않습니다. 독립성에는 별도의 예산, 자신이 지배하는 트래픽 뒤에 갇힐 수 없는 피드백, 공유 기반의 합법적 사용자 하나가 조용히 소유자가 되는 것을 막는 스케줄링이 필요합니다.

출처

  1. https://www.rfc-editor.org/info/rfc3081
  2. https://www.rfc-editor.org/rfc/rfc3081.html
  3. https://datatracker.ietf.org/doc/rfc3081/
  4. https://www.rfc-editor.org/rfc/rfc3080.html
  5. https://www.rfc-editor.org/rfc/rfc1982.html
  6. https://www.rfc-editor.org/rfc/rfc1122.html
  7. https://www.rfc-editor.org/rfc/rfc9293.html
  8. https://www.rfc-editor.org/rfc/rfc3195.html
  9. https://www.rfc-editor.org/rfc/rfc4744.html
  10. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  11. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  12. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/