RFC 3135: 프록시 ACK가 애플리케이션 전달이 아니었을 때

요약

RFC 3135는 위성 및 무선 링크에서 TCP를 개선하기 위해 승인(ACK)을 간격 조정하거나 필터링·생성하고, 로컬에서 재전송하며, 연결을 분할하고, 트래픽을 압축하고, 끊김을 은닉하는 프록시들을 조사했다.
로컬 TCP ACK는 프록시가 데이터를 인수했음을 의미할 수 있으며, 먼 곳의 TCP 스택이나 애플리케이션이 바이트를 받았다는 뜻이 아니다. 따라서 속도 이득은 새로운 증거·신뢰·운명 공유 및 진단 경계를 만들어냈다.

승인이 절반에서 멈췄다

송신자는 긴 위성 구간을 넘어 멀리 있는 애플리케이션 쪽으로 데이터를 전송한다. 어려운 링크에 가장 가까운 중개자가 먼저 응답한다. 송신자의 관점에서 진행이 승인된 셈이다. 신호가 전체 왕복을 거치기를 기다리지 않고도 혼잡 윈도우를 전진시킬 수 있다. 느린 경로가 짧아 보인다.

하지만 데이터에 마법 같은 거리 단축이 생긴 것은 아니다. 그 데이터는 프록시의 버퍼에 있을 수도 있고, 여전히 위성 구간, 무선 중단, 두 번째 프록시, 수신자의 TCP 스택, 그 위의 애플리케이션을 통과해야 한다. 로컬 승인 이후에 손실이 발생하면 원래 송신자는 이미 자신의 평범한 복구 증거 일부를 넘겨준 상태다. 프록시는 손실을 복구할 수 있을 만큼의 상태와 데이터를 보유해야 한다.

이것이 2001년 6월 RFC 3135가 조사한 메커니즘 중 하나였다. 이 문서는 그 부류를 성능 향상 프록시(Performance Enhancing Proxy, PEP)라고 불렀다. 그 목적은 특정 제품을 표준으로 만드는 것도, 모든 중개자를 비난하는 것도 아니었다. 지연, 대역폭, 비대칭, 오류 패턴 또는 끊김 때문에 순수 성능이 만족스럽지 않은 링크에서 인터넷 프로토콜이 더 잘 동작하게 하는 방식들을 목록화한 뒤, 그 최적화가 무엇을 대가로 치를 수 있는지를 목록화했다.

가장 중요한 대가는 의미적 거리였다. 승인이 더 일찍 도착할 수 있었던 것은 정확히 그것이 더 가까운 주체로부터 왔기 때문이었다. 송신자는 유용한 전송 계층 이벤트를 얻었지만, 그 권위가 바뀌었다. 그 신호는 목적 엔드포인트로의 전달을 설명하지 않았고, 애플리케이션의 수용에 대해서는 더욱 그렇지 않았다.

PEP라 불리는 단일 기계가 아니었다

RFC 3135는 단일 아키텍처를 기술하지 않았다. '프록시'라는 단어가 서로 다른 메커니즘을 교환 가능한 것처럼 들리게 할 수 있으므로, 이 절제는 중요하다.

PEP는 전송 계층에서 동작해 TCP를 관찰하고 전송 동작만 바꾸면서 애플리케이션 프로토콜을 엔드투엔드로 유지할 수 있다. 애플리케이션 계층에서 동작해 애플리케이션 교환을 종단하고 그 프로토콜에 대한 지식을 활용할 수도 있다. 유선 네트워크가 무선 링크를 만나는 지점의 하나의 통합 구성 요소일 수도, 위성 구간을 감싸는 분산형 쌍일 수도 있다. 순방향과 역방향 경로의 용량이 다르므로 두 반쪽은 서로 다른 일을 할 수 있다.

PEP는 TCP 연결을 분할할 수 있다. 들어오는 연결은 중개자에서 끝나고, 중개자는 목적지를 향해 두 번째 연결을 새로 만든다. 분산된 두 프록시는 그들 사이에 세 번째, 링크 특화 연결—변형된 TCP일 수도, UDP 위의 독점 프로토콜일 수도—을 사용하고 여러 사용자 연결을 그 안에서 멀티플렉싱할 수 있다.

아니면 메커니즘이 훨씬 덜 침습적일 수도 있다. ACK 간격 조정은 데이터 수신을 주장하지 않으면서 승인 폭주를 매끄럽게 할 수 있다. ACK 필터링은 희소한 반환 채널에서 중복 승인을 제거하고 나중에 유용한 스트림을 재구성할 수 있다. Snoop 방식의 링크 계층 기능은 잃어버린 무선 세그먼트를 캐시해 재전송하면서 중복 승인을 억제할 수 있다. 압축은 제약된 링크를 건너는 바이트를 줄일 수 있다. 이런 설명만으로는 엔드투엔드 의미가 살아남았는지 알 수 없다.

그래서 RFC 3135는 투명성과 의미 보존을 분리했다. 어떤 메커니즘은 호스트에게 보이지 않으면서도 누가 연결을 종단했는지를 바꿀 수 있다. 다른 메커니즘은 사용자에게 보이면서도 애플리케이션 수신을 엔드투엔드로 남길 수 있다. '투명'은 누가 알았는지에 답했다. 누가 승인했는지, 상태가 어디에 있었는지, 엔드포인트가 어떤 장애를 관찰할 수 있었는지에는 답하지 않았다.

더 빠른 피드백은 책임을 옮겼다

로컬 승인은 시간과 의무를 동시에 바꾸기 때문에 드러내는 사례였다.

평범한 TCP 승인도 이미 유한한 증거다. RFC 3135는 TCP ACK가 상대 엔드 시스템의 TCP 구현으로의 전달을 나타낼 뿐, 애플리케이션이 데이터를 받았거나 저장했거나 처리했다는 보장이 아니라고 상기시켰다. 신뢰할 수 있는 완료가 필요한 애플리케이션은 자기 작업에 맞는 자체 엔드투엔드 확인 또는 승인이 필요하다.

PEP는 그 제한된 상대 수신보다 앞서 또 하나의 경계를 삽입했다. PEP가 데이터를 로컬에서 승인하면, 송신자는 PEP가 그 데이터를 인수했다는 것을 알게 된다. 메모는 그 결과를 명시적으로 밝혔다: 그 승인 이후에 유실된 데이터를 복구할 책임은 프록시에게 있다.

그 책임은 은유가 아니다. 프록시에는 아래 방향으로 승인되지 않은 데이터를 위한 버퍼, 손상 구간용 타이머, 시퀀스 상태, 아래 방향 승인에 대한 관점, 로컬 재전송 규칙이 필요하다. 링크가 끊기면 분할 프록시는 새 데이터 수용을 중단하고 송신자 쪽으로 닫힌 윈도우를 광고하며, 상태를 보존하고 링크가 돌아오면 재개할 수 있다. 송신자의 TCP 연결은 그렇지 않았다면 장애로 해석했을 정전에서도 살아남을 수 있다.

이 메커니즘은 가치 있을 수 있다. 국소적 무선 손실에 전역 혼잡 반응을 강제하는 일을 피할 수 있다. 일시적인 끊김을 넘어 세션을 사용 가능하게 유지할 수 있다. 긴 전파 지연이 모든 피드백 루프를 지배하는 일을 막을 수 있다. RFC 3135는 엔드투엔드 원리가 장식적 원칙이어서가 아니라 운영자와 사용자에게 실제 성능 문제가 있었기 때문에 작성되었다.

그러나 이제 인수(custody)는 프로토콜의 운영적 진실의 일부다. 프록시가 목적지보다 먼저 '수신'이라고 말한다면, 시스템은 프록시가 약속한 것을 보유했고 나중에 그 약속을 이행했다는 증거가 필요하다. 그 증거 없이는 로컬 ACK가 신뢰성 의미를 입증이 아니라 가정으로 삼는 속도 신호가 된다.

하나의 바이트 스트림에 대한 다섯 개의 영수증

이 아키텍처를 읽는 가장 깨끗한 방법은 영수증들을 분리해 두는 것이다.

첫째, 송신 애플리케이션이 바이트를 자신의 로컬 전송 계층에 넘긴다. 그것은 로컬 시스템이 작업을 수용했다는 뜻이다. 둘째, PEP가 그 바이트를 승인하고 버퍼링할 수 있다. 그것은 어떤 중개자가 일부 책임을 맡았다는 뜻이다. 셋째, 데이터가 열화된 하위 경로를 건넌다. 그것은 그 자체의 손실과 지연을 지닌 네트워크 관찰이다. 넷째, 원격 TCP 구현이 수신을 승인한다. 그것은 프록시의 인수 영수증보다 강하지만 여전히 애플리케이션 아래에서 끝난다. 다섯째, 원격 애플리케이션이 자신의 프로토콜이 관심을 두는 이벤트—명령의 구문 분석, 메시지 저장, 트랜잭션 커밋 또는 전송 완료—를 확인한다.

다섯 번째 영수증조차 선언된 의미가 필요하다. 애플리케이션 ACK는 프로토콜에 따라 '구문 분석됨', '대기열에 넣음', '영구 저장됨' 또는 '완료됨'을 의미할 수 있다. RFC 3135의 메일 릴레이 예는 책임 이전을 구체적으로 만들었다. 릴레이 메일 전송 에이전트는 메시지를 받아 비휘발성 저장소에 기록하고, 애플리케이션 계층에서 승인하고, 나중에 전달할 의무를 맡을 수 있었다. 그 아키텍처는 단일 엔드투엔드 교환을 포기했지만, 인계와 재시도 의무를 명시적으로 만들었다.

보이지 않는 전송 계층 PEP는 다르다. 그것은 보통 애플리케이션 승인을 엔드투엔드로 남겨 애플리케이션의 최종 확인을 보호한다. 그러나 송신자는 여전히 전송 진행을 원격 엔드포인트와 시간적·권위적으로 분리된 채 볼 수 있다. 모니터링이 송신자 쪽 ACK나 겉보기 RTT만 기록한다면, 프록시가 여전히 리스크를 들고 있는 동안 성공을 선언할 수 있다.

교훈은 로컬 ACK가 거짓이라는 것이 아니다. 그것들은 더 가까운 주체의 진실한 진술이다. 문제는 대시보드, 테스트 또는 운영자가 그 주체의 영수증을 조용히 목적지가 소유한 증거로 승격시킬 때 시작된다.

연결은 링크를 살아남고 옵티마이저와 함께 죽을 수 있다

상태를 경로 안으로 옮기는 것은 운명 공유를 바꾸었다. 평범한 엔드포인트 보유 연결 상태에서는, 다른 경로가 생기면 실패한 라우터가 연결을 파괴할 필요가 없다. 엔드포인트들이 전송 상태를 보존하는 동안 패킷은 다른 경로를 택할 수 있다.

PEP가 필수적인 연결별 상태와 버퍼링된 데이터를 들고 있다면, 그 중개자의 실패는 대체 네트워크 경로가 여전히 존재할 때에도 연결을 종료시킬 수 있다. 경로는 살아남았지만 옵티마이저는 그렇지 않았다. 옵티마이저가 연결의 기억의 일부가 되었기 때문에, 그것의 크래시는 애플리케이션이 볼 수 있는 이벤트가 되었다.

RFC 3135는 그 트레이드오프를 자동으로 비합리적인 것으로 보지 않았다. PEP는 종종 대체 경로가 실질적으로 없는 마지막 홉 또는 사설 네트워크에 놓였다. 무선 중단은 이미 세션을 위협하고 있을 수 있다. 사용자는 사용 가능한 서비스를 대가로 추가 프록시 리스크를 합리적으로 수용할 수 있었다. 이 문서의 조건은 거버넌스였다: 사용자 또는 책임 관리자가 그 함의를 알고, 선택을 통제하고, 향상 없이 평범한 엔드투엔드 IP를 사용할 수 있는 능력을 유지해야 한다.

그 조건은 운영에서 잃기 쉽다. PEP가 투명하고, 항상 켜져 있고, 접속 네트워크가 소유하게 되면, 총합 성능 이득을 누리는 주체와 애플리케이션 리스크를 지는 주체가 달라질 수 있다. 버퍼 고갈, 프로세스 재시작, 상태 손실은 사용자가 '승인된 데이터가 왜 완료되지 않았는가'를 묻기 전까지는 내부 이벤트로 남는다.

암호화는 옵티마이저의 시력을 빼앗았다

많은 PEP 기법은 가시성에 의존했다. ACK 간격을 조정하려면 중개자가 ACK를 인식해야 했다. TCP를 분할하려면 전송 상태를 종단해야 했다. 애플리케이션 헤더를 압축하거나 애플리케이션 동작을 바꾸려면 더 많은 것을 읽어야 했다.

엔드투엔드 IPsec ESP는 그 배열에 도전했다. TCP 헤더와 페이로드가 실제 엔드포인트들 사이에서 보호되면, 중간 PEP는 자신의 최적화가 의존하는 정보를 신뢰할 수 있게 검사하거나 수정할 수 없었다. RFC 3135는 많은 설계에 대해 냉정하게 선택을 기술했다: 엔드투엔드 IPsec 아니면 PEP.

한 가지 우회책은 프록시에서 보안을 종단하고 별도의 보호 구간들을 수립하는 것이었다. 링크에서 암호화는 유지되었지만 엔드투엔드 보안은 유지되지 않았다. 트래픽은 처리를 위해 PEP 내부에 노출되었다. 엔드포인트는 네트워크 중개자를 신뢰해야 했고, 두 구간의 서로 다른 보호 수준은 연결이 협상한 것에 대한 오해를 만들 수 있었다.

다른 완화책들—PEP 처리를 선택적으로 우회시키기, 프록시 간 구간만 보호하기, PEP까지의 터널 만들기—은 경계를 지우는 대신 옮겼다. 각각은 구성과, 누가 평문을 볼 수 있고 누가 전송 동작을 변경할 권한이 있는지에 대한 새 진술을 더했다.

이후 문서들은 그 갈등이 초기 위성 시대와 함께 사라지지 않았음을 보여준다. RFC 3449는 여러 비대칭 메커니즘의 전제 조건으로 헤더 가시성과 흐름별 식별을 요구했다. RFC 8404와 RFC 8517은 나중에 암호화가 전송 중심 네트워크 기능을 어떻게 제한하는지, 그리고 운영자들이 왜 그것들을 배치했는지를 기록했다. RFC 8684는 심지어 Multipath TCP의 재전송 규칙에서 선제적 PEP 승인을 고려해야 했다. 이후 자료들이 2001년의 채택을 증명하는 것은 아니다. RFC 3135가 명명한 경계가 반복되는 프로토콜 설계 사실이 되었음을 보여준다.

프록시는 운영자가 꼭 봐야 할 장애를 정확히 숨길 수 있었다

PEP는 종종 장애를 은닉하도록 설계되었다. 무선 끊김 동안 프록시는 송신자의 진행을 동결하고, 데이터를 보존하고, 연결이 붕괴하지 않게 할 수 있었다. 사용자에게는 그것이 기능일 수 있었다.

진단에게는 모호성일 수 있었다. 송신자가 그럴듯한 전송 상태에 머물러 있는 동안 원격 엔드포인트는 도달 불가능할 수 있다. 장애 탐지는 대체 통신 경로로 전환하는 트리거를 포함해 지연될 수 있었다. 중개자는 엔드포인트가 연속성 실패를 학습할 수 있게 되는 시점을 바꿈으로써 연속성을 개선했다.

흔한 도구들은 프록시된 TCP 흐름과 다른 이야기를 할 수 있다. ping은 PEP를 우회해 라우팅될 수 있다. TCP와 동일한 처리를 받지 못한 채 통과할 수도 있다. PEP가 먼 시스템을 대신해 응답할 수도 있다. traceroute는 네트워크 홉을 드러내면서 연결 분할이나 그 안에 보유된 상태는 드러내지 않을 수 있다. 성공한 프로브는 프록시까지의 도달성, 또는 ICMP에 대한 도달성을 증명하면서 애플리케이션 경로는 여전히 막혀 있을 수 있다.

비대칭 라우팅은 배치를 더 복잡하게 했다. 분산 메커니즘은 양방향이 자신의 두 구성 요소를 모두 통과해야 할 수 있지만, 라우팅은 트래픽을 다른 경로로 되돌릴 수 있다. 이동성은 호스트를 새 서빙 노드로 옮기고 PEP 상태의 빠른 이전을 요구할 수 있다. 확장은 프록시가 상위 계층을 검사하고 흔히 연결별 상태를 보유하므로 평범한 포워딩보다 더 많은 처리와 메모리를 필요로 했다. 병렬 프록시는 흐름을 올바른 상태에 붙잡아 두기 위한 또 다른 제어 시스템을 필요로 했다.

각 최적화는 두 번째 질문을 만들었다: 어떤 증거가 그것 자신의 실패를 드러낼 것인가? 그 영수증이 없다면, 나쁜 링크를 숨기기 위해 설치된 장치는 자기 자신도 숨길 수 있다.

보편적 판정이 아니라 조사

RFC 3135는 자신의 권위에 신중했다. Informational이었다. 메커니즘과 환경을 조사했다. PEP를 일반적으로 추천하지 않았고, 모든 링크 문제를 어떤 대가를 치르더라도 엔드투엔드로 풀어야 한다고 주장하지도 않았다.

예들—VSAT 위성 네트워크, 무선 WAN 시스템, WAP 구성, Snoop 방식 무선 LAN 복구—은 설계 계열을 보여주었다. 그것들은 인터넷의 인구 조사도, 통제된 제품 비교도, 이름 지어진 모든 메커니즘이 같은 결과를 낸다는 증거도 아니었다. 이 문서는 또한 새 링크 기술은 가능한 한 PEP 기법이 불필요하도록 설계되어야 한다고 말했다.

그 균형이 이 메모를 여전히 유용하게 만든다. 논쟁을 순수성 대 성능으로 축소하지 않았다. 어떤 기능이 네트워크 안으로 옮겨졌는지, 사용자가 그 이동을 통제했는지, 어떤 보안이 불가능해졌는지, 필수 상태가 이제 어디에 있는지, 승인이 무엇을 의미하는지, 장애를 여전히 어떻게 진단할 수 있는지를 물었다.

RFC 3234는 나중에 PEP를 더 넓은 미들박스 분류 안에 놓았다. RFC 3426은 RFC 3135를 아키텍처상 이득과 비용을 저울질하는 사례 연구로 사용했다. 그 문서들도 같은 규율을 지켰다: 개선은 그 새로운 실패 및 제어 표면까지 세어 봐야 완성된다.

영수증을 세탁하지 않고 이득을 측정하라

신뢰할 수 있는 평가는 성능 문제에서 시작한다. 경로, 방향, 링크 특성, 순수 RTT, 오류와 끊김 패턴, 제공 워크로드, 애플리케이션 목표를 기록한다. PEP의 버전, 소유자, 배치, 활성화된 메커니즘을 확인한다. 통합형 또는 분산형, 투명 또는 명시적, 분할 또는 엔드투엔드 여부와 사용자가 우회할 수 있는지를 밝힌다.

그다음 증거 사슬을 기록한다. 송신자는 언제 전송했는가? 프록시는 언제 승인했는가? 몇 바이트가 버퍼에 들어갔는가? 그 버퍼는 휘발성이었는가? 데이터는 언제 손상된 링크를 건넜는가? 손실 후 어느 구성 요소가 재전송했는가? 원격 TCP ACK는 언제 도착했는가? 그 뒤 어떤 애플리케이션 응답이 왔는가? 결과는 단지 구문 분석, 대기열 또는 영구 커밋 중 어느 것이었는가?

로컬과 엔드투엔드 재전송을 모두 측정한다. 프록시 재시작과 버퍼 압박 이벤트를 보존한다. 보안 엔드포인트와 매 세그먼트에서 어떤 헤더나 페이로드가 보였는지를 기록한다. 양방향 트래픽, 흐름 선호성, 모바일 상태 이전, 대체 경로 동작을 검증한다. 애플리케이션 완료와 정확성을 처리량, 겉보기 RTT, 혼잡 윈도우 성장과 비교한다.

붉은 신호는 불일치들이다. 로컬 ACK가 영구 인수에 앞선다. 프록시 재시작이 송신자가 수용됐다고 믿는 바이트를 잃는다. ping은 녹색인데 TCP 흐름은 멈춘다. 암호화가 최적화를 무력화한다. 반환 트래픽이 분산 쌍의 한쪽을 우회한다. 송신자 처리량은 좋아지는데 애플리케이션 완료는 나빠진다. 장애가 페일오버를 지연시킬 만큼 오래 숨겨진다.

그 관찰 중 어느 것도 이전 ACK를 무효로 만들지 않는다. 그것은 그 ACK의 관할권을 보이게 만든다.

RFC 3135의 프록시는 루프를 짧게 만들기 위해 설계되었다. 역사적으로, 그것은 또한 인터넷에게 루프가 무엇을 증명할 수 있는지를 명명하도록 강요했다. 중간에서 나온 전송 승인은 유용하고 정직하고 성능을 높일 수 있었다. 그래도 여전히 먼 애플리케이션의 영수증은 아니었다. 아키텍처는 그 빠진 거리가 측정될 때만 신뢰할 수 있었다.

프록시는 바이트를 승인했다. 애플리케이션은 아직 받지 못했다: RFC 3135

왜 중요한가

요약

승인이 절반에서 멈췄다

PEP라 불리는 단일 기계가 아니었다

더 빠른 피드백은 책임을 옮겼다

하나의 바이트 스트림에 대한 다섯 개의 영수증

연결은 링크를 살아남고 옵티마이저와 함께 죽을 수 있다

암호화는 옵티마이저의 시력을 빼앗았다

프록시는 운영자가 꼭 봐야 할 장애를 정확히 숨길 수 있었다

보편적 판정이 아니라 조사

영수증을 세탁하지 않고 이득을 측정하라

출처

프로필 심층 컨텍스트

Strategic Circle

Leadership Alliance

Strategic Circle 브리핑

Leadership Alliance 브리핑

요약

승인이 절반에서 멈췄다

PEP라 불리는 단일 기계가 아니었다

더 빠른 피드백은 책임을 옮겼다

하나의 바이트 스트림에 대한 다섯 개의 영수증

연결은 링크를 살아남고 옵티마이저와 함께 죽을 수 있다

암호화는 옵티마이저의 시력을 빼앗았다

프록시는 운영자가 꼭 봐야 할 장애를 정확히 숨길 수 있었다

보편적 판정이 아니라 조사

영수증을 세탁하지 않고 이득을 측정하라

출처

프로필 심층 컨텍스트

Strategic Circle

Leadership Alliance

추천 읽을거리