요약

  • RFC 816은 호스트에 특별한 라우팅 의무 하나를 부여했다. 더 이상 ICMP 조언을 반환할 수 없는 직전 게이트웨이의 죽음을 감지하는 일이었다. 더 멀리 떨어진 장애는 주로 경로를 재구성하는 게이트웨이의 몫이었다.
  • 수렴 과정에서 고립된 ICMP 오류는 최종 판단이 아니라 증거였다. 재전송과 사용자 타임아웃은 문제가 심각하다는 사실을 보여 주었고, 오류 조언은 그럴듯한 원인을 설명하는 데 도움을 주었다.
  • TCP 확인응답은 여전히 애플리케이션이 작업을 완료했다는 증거가 아니었다. 초기 SMTP와 유휴 Telnet의 실패 사례는 애플리케이션 수준의 수신 확인, 타이머, 생존성 규칙이 왜 여전히 필요한지를 보여 주었다.

스스로를 보고할 수 없었던 장애

RFC 816이 그린 인터넷에서 대부분의 장애는 라우팅 시스템 뒤로 사라지도록 되어 있었다. 게이트웨이는 인접 네트워크와 게이트웨이에 대한 최신 견해를 교환했다. 장애가 발생한 뒤에는 잠시 혼란스러울 수 있었지만, 이내 새로운 토폴로지에 안착했다. 호스트는 몇 홉 떨어진 고장 게이트웨이를 진단할 필요가 없었다. 그 장애 옆에 있는 게이트웨이들이 우회 경로를 만들 수 있었기 때문이다.

첫 홉은 달랐다. 호스트가 이미 작동이 멈춘 직전 게이트웨이로 계속 패킷을 보내면, 그 게이트웨이는 ICMP 리디렉트, 목적지 도달 불가 또는 다른 유용한 조언을 반환할 수 없었다. 다른 게이트웨이들은 이미 인터넷을 완벽하게 재구성했을 수도 있다. 그러나 침묵하는 장비에 넘겨진 패킷에는 아무 도움이 되지 않았다. 패킷은 그저 사라졌다.

그래서 David D. Clark은 호스트의 장애 격리 임무를 좁혔다. 호스트가 인터넷 전체 지도를 갖춘 두 번째 라우팅 시스템이 된 것은 아니었다. 직접 사용 중인 게이트웨이가 죽었음을 인식하고, 즉시 도달 가능한 다른 게이트웨이를 선택하는 전략이 필요했다. 책임은 관측 가능성을 따랐다. 더 넓은 라우팅 대화가 실패한 참여자를 통해 되돌려 보고할 수 없는 하나의 장애를 로컬 호스트가 처리하는 방식이었다.

이 경계는 편의주의적 과잉 반응도 막았다. 원격 장애는 모든 엔드포인트가 경로를 다시 만들어야 할 이유가 아니었다. 첫 홉의 침묵은 목적지가 죽었다고 선언할 이유도 아니었다. 로컬 사실은 로컬 대체를 정당화했다.

메시지는 너무 이르게 참이었다가 잠시 뒤 거짓이 될 수 있었다

RFC 816은 리디렉트와 목적지 도달 불가를 조언 메시지라고 불렀다. 리디렉트는 다른 직전 게이트웨이가 더 나은 선택이며, 이를 촉발한 데이터그램이 이미 전달되었다고 알려 주었다. 도달 불가는 목적지에 현재 도달할 수 없다고 말했다. 둘 다 시대를 초월한 진리는 아니어도 유용할 수 있었다.

네트워크나 게이트웨이가 실패한 직후에는 라우팅 정보가 움직이고 있었다. 한 게이트웨이는 여전히 이전 견해를 갖고 있고 다른 게이트웨이는 새 경로를 학습했을 수 있었다. 그 간격을 지나는 패킷은 인터네트워크가 곧 엔드포인트를 다시 연결하려는 상황에서도 고립된 도달 불가를 만들어낼 수 있었다. 그 하나의 메시지 때문에 TCP 연결을 중단하면, 엔드포인트가 그대로 있는 동안 인터넷이 내부적으로 복구할 능력을 버리게 된다.

그 오류가 무의미한 것은 아니었다. 증거 가치는 언제 도착했는지, 어떤 작업이 이를 유발했는지, 어떤 유형과 코드를 담고 있었는지, 다른 신호가 일치하는지에 달렸다. 새 연결 시도 중이라면 오류는 잘못된 주소나 접근 불가능한 서비스를 강하게 시사할 수 있었다. 오래 유지된 연결이 일시적 라우팅 이벤트 하나를 겪은 뒤라면, 그것은 치명적 실패의 더 약한 증거였다.

이것은 맹목적 신뢰나 맹목적 무시보다 더 까다로운 설계다. 메시지는 보존되어 상위로 전달되어야 하지만, 그 권한은 제한된 채로 남는다. 메시지는 한 계층이 한 순간에 관측한 것을 설명할 뿐, 모든 상위 계층의 결과를 결정할 권리를 얻지는 않는다.

진단이 완벽해지기 전에 복구가 시작될 수 있었다

RFC 816은 죽은 게이트웨이를 찾는 여러 방법을 비교했다. 일부 연결된 네트워크는 다음 장비가 죽었다고 보고할 수 있었다. 호스트는 ICMP 에코로 게이트웨이를 계속 폴링할 수 있었지만, 충분히 잦은 폴링은 호스트, 네트워크, 게이트웨이에 부하를 주었다. 이 문서는 특정 분석을 통해 오버헤드가 감내 가능하다고 입증되지 않는 한 그 접근을 금지했다.

트리거된 폴링은 뭔가 잘못된 것처럼 보인 뒤에만 그 비용을 지불했다. 반복된 TCP 재전송은 IP에 힌트를 내려보낼 수 있었고, IP는 그때 게이트웨이를 탐사했다. 그러나 확인은 나중에 이루어졌고, TCP는 이미 인내심을 다했을 수 있었다.

트리거된 재선택은 불확실성에 대해 다른 입장을 취했다. 상위 계층의 불만이 있으면 IP는 먼저 폴링하지 않고 알려진 다음 게이트웨이를 시도할 수 있었다. 원래 게이트웨이가 정말 죽었다면 새 선택은 복구 시간을 줄였다. 원래 게이트웨이가 멀쩡했고 전환이 불필요했다면, 살아 있는 대체 게이트웨이가 패킷을 전달하고 더 나은 경로로 향하는 리디렉트를 반환할 수 있었다. 잘못된 선택은 되돌릴 수 있었다.

중요한 메커니즘은 무모한 장애 조치가 아니었다. 같은 조언 시스템으로 실패를 교정할 수 있는 경계 있는 실험이었다. 로컬 조치는 전역적 확실성을 기다리지 않았지만, 그 실험을 영구적인 경로 권한으로 바꾸지도 않았다.

이후 RFC 1122는 다음 홉 요구사항을 더 명시적으로 만들었다. IP는 경로 캐시에서 실패한 게이트웨이를 감지하고 대체 경로를 선택해야 했다. 또한 완전히 만족스러운 보편적 알고리즘은 나오지 않았다고 인정했다. 첫 홉에 대한 지속적 핑은 여전히 금지되었고, 인터페이스 복잡성이 늘어나더라도 계층 간 긍정적 또는 부정적 조언이 선호되었다.

타임아웃은 원인이 아니라 심각성을 입증했다

TCP에서 RFC 816은 더 작은 복구 조치 집합을 보았다. TCP는 확인응답을 받거나 연결 타이머가 만료될 때까지 확인되지 않은 세그먼트를 재전송했다. 재전송은 IP에 해당 경로를 조사할 가치가 있다고 알려 줄 수 있었다. 반대 방향으로 IP와 연결된 네트워크는 ICMP 또는 링크 오류를 상위로 보고할 수 있었다.

이 신호들은 서로 다른 질문에 답했다. 반복된 재전송은 기대한 진전이 일어나지 않았다고 말했다. 사용자 타임아웃은 TCP의 클라이언트에게 최종 대기 경계를 제공했다. ICMP 메시지는 진전이 왜 실패했는지 시사했다. 어느 것도 단독으로 완전한 진단은 아니었다.

이 문서는 메일 발신자 같은 프로그램과 Telnet을 사용하는 사람을 구분했다. 프로그램에는 대기가 끝나는 정의된 지점이 필요했다. 사람은 한 종류의 실패 직후 포기하기로 결정할 수도 있고, 다른 실패를 견디며 기다릴 수도 있었다. 따라서 RFC 816은 비동기 보고를 주장했다. 타임아웃과 하위 계층 오류가 유용한 형태로 클라이언트에 도달하게 하여, 연결의 목적을 아는 곳에서 최종 결정을 내릴 수 있게 하자는 것이었다.

이후의 호스트 요구사항은 소프트 오류 원칙을 유지했다. RFC 1122는 TCP가 특정 소프트 목적지 도달 불가 오류를 받았다는 이유만으로 확립된 연결을 중단해서는 안 되며, 그 정보를 애플리케이션에 제공해야 한다고 말했다. RFC 5461은 그 거래를 설명했다. 인내심은 연결이 일시적 재구성을 견디게 하지만, 영구적으로 도달 불가능한 첫 주소는 다른 주소 시도를 지연시킬 수 있다. 정보성 RFC는 연결 시작 시 배포된 지름길을 문서화했지만 표준 동작을 명시적으로 변경하지는 않았다.

RFC 9293은 여전히 재전송 타임아웃과 사용자 타임아웃을 분리한다. 하나는 재전송 큐의 맨 앞 세그먼트를 다시 보낸다. 다른 하나는 큐를 비우고 연결이 중단되었음을 보고하며 상태를 삭제하고 닫는다. 따라서 타이머는 ‘타임아웃’이라는 하나의 일반적 사실이 아니라 특정 결정 경계에 속한다.

작업이 실패하기 전에 모든 바이트가 도착할 수 있었다

RFC 816의 메일 사례는 전송 성공의 한계를 드러냈다. 일부 초기 수신 프로그램은 메일 본문을 모두 받은 뒤 SMTP 수준의 확인응답을 반환하기 전에 충돌했다. TCP에는 확인되지 않은 미결 데이터가 없었으므로 재전송 타이머가 감지할 것이 없었다. 발신자는 애플리케이션만 만들 수 있는 응답을 무기한 기다릴 수 있었다.

SMTP 타이머를 추가하는 것은 필요했지만 기계적으로 단순하지는 않았다. 짧은 간격은 느린 호스트로 정상 전송 중인 큰 메시지를 거부할 수 있었다. 긴 간격은 오경보를 줄였지만 실제 실패를 발견하는 비용을 높였다. 일부 메일러는 메시지 크기에 따라 간격을 바꿨다. 역사적 선택 자체보다 중요한 것은 그 위치였다. SMTP는 어떤 응답이 메일 수준의 완료를 뜻하는지, 어떤 작업 부하 특성이 합리적 대기 시간에 영향을 주는지 알고 있었다.

ACK는 확인된 TCP 시퀀스 공간이 상대방의 전송 계층에 도달했음을 입증했다. 그러나 수신 프로세스가 살아 있었는지, 메시지를 커밋했는지, 내구성 있는 상태를 기록했는지, 비즈니스 의무를 이행했는지는 입증하지 않았다. 전송 계층의 수신 확인을 ‘배달’이라고 부르면 마지막으로 중요한 결정이 지워졌다.

미결 데이터가 없으면 전송 경보도 없었다

반대 방향의 실패는 서버 Telnet에서 나타났다. 사용자가 생각하는 동안 트래픽이 흐르지 않는 사이 통신 경로가 죽을 수 있었다. 다음 키 입력이 끊어진 세션을 사용자에게 드러냈다. 보낼 것이 없는 서버는 TCP 타이머를 구동할 확인되지 않은 데이터가 없었기 때문에 알지 못한 채 남을 수 있었다.

애플리케이션 수준의 질의로 상대방을 시험할 수 있었지만, 모든 유휴 사용자를 높은 빈도로 폴링하면 오버헤드 문제를 한 계층 위에서 다시 만들게 된다. RFC 816은 비활동이나 다른 조건 때문에 의심이 합리적일 때 그러한 점검을 사용하라고 제안했다. 올바른 생존성 메커니즘은 애플리케이션의 침묵 패턴과 오래된 상태의 비용에 달려 있었다.

두 사례는 반대 방향을 가리킨다. 메일은 애플리케이션 완료 없이도 완전한 전송 확인응답을 가질 수 있었다. Telnet은 실패할 활성 전송이 없었기 때문에 전송 실패 신호가 없을 수 있었다. 어느 경우에도 TCP가 결함이 있었던 것은 아니다. TCP는 설계된 전송 질문에 답하고 있었다.

조언이 살아남은 것은 마지막 말을 주장하지 않았기 때문이다

RFC 816은 ICMP 오류를 무시하라고 말하지 않았다. 타임아웃 후에는 그럴듯한 원인을 제공하고, 연결 개설 중에는 유력한 실수를 식별하며, 가능한 구현 문제를 드러내야 한다고 말했다. 또한 그것들이 절대적으로 신뢰할 수 있는 것은 아니라고 말했다.

지속 가능한 구조는 조합이었다. 라우팅 조언은 네트워크의 현재 견해를 설명했다. 첫 홉의 침묵은 로컬 재선택을 정당화했다. TCP 재전송과 사용자 타임아웃은 정체된 전송과 소진된 인내심을 설명했다. 애플리케이션은 자체 확인응답과 유휴 상태 정책을 정의했다. 각 관측은 다음 계층의 결정을 빼앗지 않고 위로 이동했다.

그래서 오류 메시지는 판결이 아니라 조언이었다. 제한된 권한은 그 유용성을 줄이지 않고 오히려 높였다. 인터넷은 로컬 증거에 빠르게 반응하고, 일시적 모순을 견디며, 결과를 약속한 계층이 그 결과 자체를 입증하도록 요구할 수 있었다.

출처