요약

  • NNTP는 뉴스 배포, 검색, 게시를 하나의 스트림 프로토콜 뒤에 두었지만, 배포된 서버가 모든 연결에 세 가지 역할을 모두 제공하지는 않았습니다.
  • MODE READER를 사용하면 클라이언트가 모드 전환 서버에게 트랜짓 모드를 벗어나 리더 기능을 노출해 달라고 요청할 수 있었습니다. 새로운CAPABILITIES응답이 해당 연결이 이제 무엇을 할 수 있는지에 대한 근거가 되었습니다.
  • 전환은 세션 상태를 초기화할 수 있었고, 파이프라이닝하거나 반복 실행할 수 없었으며, 그 자체로 게시 권한, 인증 또는 프라이버시를 부여하지 않았습니다. 역할, 권한, 보안은 서로 구별되는 개념으로 남았습니다.

소켓은 그대로, 서비스는 달라졌다

뉴스 클라이언트는 TCP 포트 119에 접속해 기능을 요청합니다. 응답에는 다른 뉴스 서버에 기사를 제안하는 데 쓰이는 명령인IHAVE와MODE-READER가 포함됩니다. 그러나READER는 포함되지 않습니다. 클라이언트가MODE READER를 보내면 응답은 성공입니다. 이후 두 번째 기능 목록에는READER,NEWNEWS, 리더 중심 형태의LIST가 포함되고,IHAVE는 사라질 수 있습니다. 동일한 엔드포인트와 순서가 유지되는 바이트 스트림이 이제 다른 서비스 표면을 기술합니다.

이것은 작은 전환이지만 큰 아키텍처적 함의를 갖습니다. 엔드포인트 이름과 포트 번호는 대화를 어디서 시작할지 식별해 줍니다. 그러나 그 대화가 무엇이 될 수 있도록 승인되는지를 온전히 식별하지는 못합니다. 그것을 알려주는 것은 현재 상태입니다.

NNTP가 이 구분을 필요로 한 이유는 원래 담당 범위가 비정상적으로 넓었기 때문입니다. 1986년에 발표된RFC 977은 네트워크 뉴스의 배포, 조회, 검색, 게시를 규정했습니다. 워크스테이션은 중앙 저장소에서 선별한 기사를 읽을 수 있었고, 협력 호스트들은 로컬 저장을 위해 기사 복사본을 교환할 수도 있었습니다. 동일한 프로토콜 계열이 사람과 데이터베이스를 연결하면서 동시에 뉴스 시스템끼리도 연결했습니다.

이 통합 문법의 어떤 부분도 하나의 구현이 이런 워크로드를 동일하게 취급하도록 요구하지 않았습니다. 리더 트래픽은 그룹, 기사 번호, 헤더, 본문을 요청합니다. 트랜짓 트래픽은 피어 사이에서 기사를 제안하거나 스트리밍합니다. 전송이 같은 만남 지점에서 시작하더라도 신뢰 관계, 인덱스, 속도 제한, 저장 경로는 달라질 수 있습니다.

표준이 역할 이름을 붙이기 전에 배포 환경이 먼저 역할을 발견했다

명시적 전환 명령은 백지에서 설계된 추상화가 아니었습니다.RFC 2980은 이미 운용 중인 소프트웨어에서 발견된 NNTP 확장을 모았습니다. 이 문서에 따르면MODE READER는 처음 INN에서 등장했으며, 클라이언트가 자신이 뉴스 읽기 클라이언트임을 알리기 위해 사용했습니다. 일부 서버는 이 정보를 이용해 리더 명령을 더 잘 처리하도록 자신을 재구성했습니다.

이 역사가 중요합니다. 이 명령은 표준 커뮤니티가 모달 프로토콜을 선호해서 만들어진 것이 아닙니다. 하나의 리스너가 서로 다른 내부 역할을 담당할 수 있고, 클라이언트는 실제로 원하는 역할을 선택할 방법이 필요하다는 운영상의 사실을 기록한 것입니다.

RFC 2980은MODE READER를 RFC 977의SLAVE와 대비했는데,SLAVE는 널리 구현되지 않았습니다. 이 대비를 과대평가하기 쉽습니다.SLAVE와MODE READER는 하나의 대칭적 설계 안에서 정반대 설정이 아닙니다. 유용한 근거는 더 좁습니다. 배포 환경은 "이 연결을 리더로 취급하라"고 말할 필요를 여전히 유지했지만, 종속 서버에 대한 이전 힌트는 지배적 메커니즘이 되지 못했다는 것입니다.

기능 목록이 구현 세부 사항을 근거로 바꾸었다

RFC 3977은 이 구분을 정밀하게 만들었습니다. 이 문서는 읽기 서버, 트랜짓 서버, 모드 전환 서버를 기술합니다. 전환 전에 모드 전환 서버는 트랜짓 모드에 있습니다.MODE-READER를 광고하고READER는 광고하지 않습니다. 성공적인MODE READER이후에는MODE-READER광고를 중단하고READER를 광고하며, 이전에 제공되었던 전송 명령이라 하더라도IHAVE광고를 중단할 수 있습니다.

이 변화는 단순한 외형 문제가 아닙니다. RFC 3977은 기능 목록이 서버의 현재 상태에서 사용 가능한 기능을 반영하도록 요구합니다. 이로써CAPABILITIES는 시간 경계가 있는 진술이 됩니다. 이 세션에서, 이러한 선행 명령들 뒤에서, 지금 이 시점에 참인 진술입니다.

첫 번째 목록을 캐시한 뒤 전환 이후에도 계속 사용하는 클라이언트는 서버 정체성과 세션 근거를 혼동한 것입니다. 소프트웨어 패키지가IHAVE를 구현하고 있을 수 있지만, 현재 연결은 더 이상 허용하지 않을 수 있습니다. "NNTP를 지원한다"는 이분법은 더욱 약합니다. 어떤 역할, 어떤 명령, 어떤 권한이 활성 상태인지에 대해서는 아무것도 말해 주지 않습니다.

IANANNTP Parameters 레지스트리는 이 어휘를 보존합니다.MODE-READER는 전환 서버와 해당 명령을 명명하고,READER는 리더 명령의 가용성을 명명하며,IHAVE와STREAMING은 피드 메커니즘을 식별합니다. 등록은 라벨을 조정할 뿐입니다. 특정 엔드포인트가 지금 그것들을 제공한다고 약속하지는 않습니다.

역할 전환은 파서 경계이다

RFC 3977은MODE READER를 파이프라이닝해서는 안 된다고 규정합니다. 이 규칙은 클라이언트가 경계가 수락되었는지, 어떤 상태가 나타났는지 확인하기 전에 전환 명령과 여러 리더 명령을 연속으로 보내는 것을 막습니다.

클라이언트가MODE READER,GROUP comp.protocols.tcp-ip,NEXT를 한 번에 몰아 보낸다고 상상해 보십시오. 모드 변경 주변에 수신된 텍스트를 버릴 수도 있고, 잘못된 명령 표면에서 해석할 수도 있습니다. 그러면 클라이언트는 서버가 결코 수락하지 않은 명령과 응답을 짝지어 버립니다. 파이프라이닝은 대기 중인 명령이 어떤 상태에서 해석될지 양측이 합의했을 때에만 효율적입니다.

이 명령은 세션에서 한 번 이상 발행될 수 없으며, 보안 또는 프라이버시 명령 뒤에 올 수도 없습니다. 서버는 리더 모드에 들어가기 전에 초기 접속 직후의 상태로 자신의 상태를 초기화할 수 있습니다. 이 규칙들은 매력적인 약속, 즉 역할을 바꿔도 이전 역할에서 쌓인 모든 사실이 보존될 것이라는 약속을 거부합니다.

따라서 선택된 그룹, 현재 기사, 인증 가정, 확장 가용성은 명시적 계약에 따라 다루어야 하며, TCP 연결이 살아남았다는 이유로 넘겨서는 안 됩니다. 전송의 연속성은 애플리케이션 상태의 연속성이 아닙니다.

리더가 곧 발행자는 아니었다

성공적인MODE READER에는 두 가지 정상 응답이 있습니다.200은 게시가 허용됨을,201은 게시가 금지됨을 나타냅니다. 둘 다 읽기 모드가 사용 가능함을 의미합니다.502는 읽기 서비스가 영구적으로 사용 불가능함을 의미하며, 이후 서버는 연결을 닫습니다.

이 세 갈래 결과는 서로 다른 질문을 서로 분리해 유지합니다. 이 연결이 리더 명령 표면에 들어갈 수 있는가? 새 기사를 제출할 수 있는가? 이 서비스가 여기서 사용 불가능한가? "리더"를 "게시 가능"으로 취급하는 클라이언트는 승인을 조용히 확대한 셈입니다.

인사말 텍스트조차 전체 답이 아닙니다. 현재 기능 목록은POST가 실제로 가용한지 표현할 수 있고, 이후 상태 전환에 따라 변할 수 있습니다. 교훈은 응답 코드가 무용하다는 것이 아니라, 느슨한 입장 허가와 세분화된 기능 근거는 범위가 다르다는 것입니다.

보안은 모드의 부산물이 아니라 또 다른 축이었다

RFC 3977에는 서버가 읽기 모드에 들어간 뒤에만STARTTLS가 나타나는 예가 있습니다.RFC 4642는 프라이버시 전환을 별도로 정의하고,RFC 4643은 인증을 정의합니다. 각각은 그 이후의 기능을 바꿀 수 있습니다.

MODE READER는 어느 쪽도 제공하지 않습니다. 전환에 동의하는 서버에게 원하는 서비스 역할을 식별할 뿐입니다. 클라이언트가 누구인지 증명하지 않고, 스트림을 암호화하지 않으며, 게시를 승인하지 않습니다. 반대로 인증되었거나 암호화된 연결이 곧 리더 세션인 것도 아닙니다. 이 차원들을 하나의 플래그로 취급하면 최소 권한 원칙과 장애 진단 모두가 흐려집니다.

RFC 4644는 트랜짓용 스트리밍 피드 명령을 추가합니다. 그 존재는 피드 역할에 대한 근거이지 서버의 보편적 속성이 아닙니다. 프로토콜은 하나의 포트가 하나의 영구적 페르소나를 의미한다고 가정하는 대신, 역할과 보안과 명령 가용성이 명명된 전환을 통해 바뀌도록 함으로써 더 이해하기 쉬워졌습니다.

경계가야말로 오래 지속되는 발명이다

모드 있는 프로토콜은 숨겨진 상태가 클라이언트를 취약하게 만든다는 이유로 자주 비판받습니다.MODE READER가 가치를 갖는 지점은 바로 상태를 덜 숨겨지게 만드는 곳입니다. 이 명령은 요청된 전환을 명명하고, 응답이 그것을 수락하거나 거부하며, 새 기능 목록이 결과 표면을 기술합니다.

그렇다고 이 설계가 공짜인 것은 아닙니다. 하나의 엔드포인트가 피어 피드와 사람의 읽기를 동시에 처리하면 정책 오류가 집중될 수 있습니다. 클라이언트는 가정을 다시 평가해야 합니다. 서버는 명령, 자격 증명, 선택된 개체가 역할 사이에서 유출되지 않도록 해야 합니다. 별도의 리스너가 일부 배포를 단순화할 수도 있습니다.

표준들은 어떤 아키텍처가 보편적으로 더 나은지 증명하지 않습니다. 다만 더 좁은 운영상의 법칙을 보존합니다. 연결이 역할을 바꿀 때, 프로토콜은 양측이 이전 역할에 의존하는 것을 멈출 수 있도록 경계를 충분히 강하게 노출해야 합니다.

출처와 근거의 한계

이 문서들은 규정된 동작, 표준화 역사, 등록된 기능 이름을 확립합니다. 현재의 배포 점유율, 현재 서버 아키텍처, 트래픽량 또는 운영자의 정책을 확립하지는 않습니다. 따라서 이 기사는 등록 내용으로부터 구현 보급률을 추론하지 않으며,MODE READER를 인증, 암호화 또는 게시 권한으로 취급하지 않습니다.