Show HN: 컴퓨터는 내 서버에 어떻게 도달했나?

 (how-did-i-get-here.net)
4P by GN⁺ | ★ favorite | 댓글 1개
  • 접속자가 웹사이트를 열면 서버가 공개 IP를 대상으로 traceroute를 실행해, 패킷이 라우터와 네트워크를 거쳐 이동하는 경로를 실시간 텍스트처럼 보여줌
  • 자체 도구 ktr는 ICMP 패킷의 TTL 값을 늘려가며 각 홉의 오류 응답을 모으고, 동시에 홉별 네트워크 정보를 조회함
  • 화면 갱신은 JavaScript가 아니라 열린 HTTP 응답에 HTML과 CSS를 계속 흘려보내는 방식으로 구현되어, 페이지가 로드되는 동안 결과가 점진적으로 나타남
  • 표시 경로는 서버에서 접속자 IP로 보낸 역방향 traceroute를 뒤집은 것이어서, 양방향 라우팅 차이 때문에 실제 경로와 완전히 같지 않을 수 있음
  • 인터넷 경로는 자율 시스템(AS) 사이의 BGP 피어링과 라우팅 테이블 전파로 만들어지며, 트래픽은 서로 연결된 네트워크를 따라 이동함

접속할 때마다 생성되는 개인화 traceroute

  • 페이지 상단의 초록색 텍스트는 미리 저장된 예제가 아니라, 웹사이트 로딩 중 접속자에게 맞춰 즉석 생성된 traceroute임
  • traceroute는 접속자의 컴퓨터 또는 패킷이 인터넷을 거쳐 이 웹사이트를 호스팅하는 서버에 도달하는 여정을 보여줌
  • 예시 경로는 접속자의 라우터에서 시작해 ISP 네트워크를 지나고, 여러 네트워크를 거쳐 Hetzner 내부 네트워크에 들어간 뒤 서버에 도달함
    • 첫 라우터가 ping에 응답하지 않을 수 있으며, 공용 라우터나 VPN 뒤에서는 흔한 상황임
    • 중간에 (no response)가 나타날 수 있고, 모든 서버가 항상 응답하는 것은 아님
  • core3.sto.hetzner.com 같은 이름은 traceroute에서 나온 IP 213.239.252.74에 역방향 DNS 조회를 수행해 사람이 읽기 쉬운 이름으로 바꾼 결과임
    • 역방향 DNS 이름은 주로 디버깅을 쉽게 하기 위한 것이며, 원래 IP로 다시 매핑되지 않는 경우도 많음

ktr와 ICMP 기반 traceroute

  • 웹사이트 구현에는 자체 traceroute 프로그램 ktr가 사용됨
    • 사이트 소스 코드도 GitHub에 공개되어 있음
    • ktr는 결과를 실시간으로 스트리밍하면서 각 홉 정보를 동시에 조회함
  • 인터넷 라우팅에서는 패킷을 처리하는 컴퓨터나 라우터가 다음 전달 장치를 선택하고, 목적지에 직접 보낼 수 있는 라우터에 도달할 때까지 이 과정이 이어짐
  • ktr 구현은 ICMP를 사용함
    • ICMP는 인터넷에서 진단 정보를 보내기 위해 설계된 프로토콜임
    • 거의 모든 인터넷 연결 장치가 ICMP를 지원함
  • ICMP 패킷의 TTL(time to live) 필드는 실제 시간이 아니라 카운트다운 값임
    • 라우터가 ICMP 패킷을 전달할 때마다 TTL을 1 줄여야 함
    • TTL이 0이 되면 라우터는 패킷 전달을 멈추고, 최대 홉 수에 도달했다는 오류 메시지를 원래 출발지 IP로 보냄
  • traceroute는 TTL을 1, 2, 3처럼 점점 늘린 ICMP 패킷을 보내 각 홉에서 돌아오는 오류 응답을 수집함
    • 오류 패킷에는 오류를 보낸 장치의 IP 주소 같은 진단 정보가 들어 있음
    • 이를 통해 인터넷을 가로지른 대략적인 패킷 경로를 추적할 수 있음

JavaScript 없이 실시간처럼 보이는 화면

  • 페이지는 JavaScript 비활성화 상태에서도 동작함
    • 브라우저 입장에서는 웹사이트가 천천히 로드되는 것처럼 보임
    • 사용자에게는 traceroute가 실시간으로 나타나는 것처럼 보임
  • 접속 시 서버는 접속자 IP 주소에서 들어온 HTTP 요청을 받고, 즉시 그 IP로 traceroute를 실행함
  • 서버는 HTTP 응답의 앞부분을 먼저 보낸 뒤 연결을 열린 상태로 유지함
    • ktr가 traceroute 업데이트를 서버에 전달함
    • 서버는 관련 HTML을 렌더링해 접속자의 컴퓨터로 전송함
    • traceroute가 끝나면 나머지 텍스트와 웹사이트 내용을 보낸 뒤 연결을 닫음
  • traceroute 줄이 아래가 아니라 위쪽에서 점진적으로 갱신되는 것처럼 보이는 이유는 CSS 블록 삽입 때문임
    • 웹페이지는 기본적으로 앞으로만 로드될 수 있음
    • 매번 traceroute 표시를 갱신할 때 이전 표시를 숨기는 CSS를 함께 삽입함
    • 브라우저가 로딩 중 CSS를 렌더링하므로 화면이 시간이 지나며 편집되는 것처럼 보임

역방향 traceroute의 한계

  • 페이지가 보여주는 경로는 “접속자의 패킷이 서버에 도달한 경로”와 완전히 같지는 않음
  • 실제 경로를 계산하려면 접속자의 컴퓨터에서 서버로 traceroute를 실행할 수 있어야 함
  • 구현은 서버에서 접속자 컴퓨터로 traceroute를 실행한 뒤, 그 결과를 뒤집어서 표시함
    • 그래서 상단 traceroute가 역순으로 로드되는 것처럼 보임
  • 역방향 traceroute는 정확도를 일부 희생함
    • 패킷이 반대 방향으로 이동하면 각 장치가 다른 라우팅 결정을 내릴 수 있음
    • 한 장치만 다른 결정을 내려도 이후 경로가 달라질 수 있음
  • 그래도 경로는 대략 비슷하며, 차이는 주로 어떤 특정 라우터가 패킷을 보느냐 수준일 가능성이 있음

자율 시스템과 WHOIS 조회

  • traceroute에 등장하는 “네트워크”는 자율 시스템(AS) 을 가리킴
    • AS는 서로 사적으로 연결된 라우터와 서버의 모음임
    • 일반적으로 같은 회사가 소유함
  • AS 소유자는 어떤 다른 AS와 연결할지 선택해 인터넷의 형태를 결정함
    • 인터넷 트래픽은 서로 피어링 계약이 있는 AS들을 지나 이동함
  • 인터넷은 열린 네트워크처럼 보이지만, 실제로는 기업이 소유한 네트워크들의 네트워크이며 접근과 제어가 금융 거래와 관료 절차에 좌우됨
  • 자체 자율 시스템을 원하면 다섯 개 지역 인터넷 레지스트리(RIR) 중 하나에 ASN을 신청할 수 있음
    • 회사의 뒷받침이 없거나 충분한 인터넷 접점이 없으면 받아들여지기 어려움
    • traceroute의 AS4766 같은 숫자가 ASN임
  • ktr는 각 홉 IP를 소유한 AS 정보를 얻기 위해 WHOIS 프로토콜을 사용함
    • 여러 조직이 어떤 AS가 어떤 IP 주소를 포함하는지 추적함
    • 많은 조직이 WHOIS로 ASN 조회를 제공함
  • 회사 정보를 파악하는 데는 PeeringDB도 쓰임
    • PeeringDB는 전체 자율 시스템의 약 1/3에 대한 정보를 가짐
    • 조회 결과와 수백 줄의 if 문을 함께 사용해 네트워크 통과 설명을 생성함
  • WHOIS 프로토콜 명세은 구조를 거의 정하지 않음
    • TCP 연결을 만들고 조회할 내용을 보내면, 서버가 정보를 돌려준 뒤 연결을 종료한다는 정도만 정함
    • 실제 WHOIS 응답 구조는 서버 관리자가 만든 관례에 가깝고, 필요한 필드 이름도 origin, originas처럼 달라질 수 있음
    • ktr의 파서는 엄밀한 파서라기보다 사람이 WHOIS 결과를 읽으며 필요한 ASN을 찾는 방식에 가까움

BGP가 인터넷 경로를 만드는 방식

  • 네트워크 경계에 있는 라우터는 패킷을 다음에 어느 네트워크로 보낼지 결정하고, 목적지 장치가 있는 네트워크에 도달할 때까지 같은 과정이 이어짐
  • 이런 경계 라우터들은 Border Gateway Protocol(BGP) 로 서로 연결 가능한 네트워크 정보를 주고받음
    • BGP는 인터넷의 형태를 만드는 프로토콜임
    • 일반 사용자가 직접 BGP를 말할 수는 없음
  • BGP의 초기 버전은 1989년 Cisco와 IBM 엔지니어가 낸 RFC 1105에 기술됨
    • 1969년 ARPANET 프로토타입에서 메시지가 부분적으로 전송된 뒤, 여러 대학·정부기관·회사들이 각자의 네트워크를 만들고 서로 연결하기 시작함
    • 1990년에 BGP v2가 나옴
    • 1994년에 BGP v4가 RFC 1654로 지정됨
    • BGP v4는 1995년과 2006년에 개정과 패치를 거쳤으며, 현대 인터넷의 상호 연결 네트워크 경로 선택에 여전히 사용됨

BGP 경로, 피어링, 라우팅 테이블

  • 자율 시스템 경계의 라우터인 border gateway는 자신이 아는 모든 BGP 경로 목록인 라우팅 테이블을 유지함
  • 각 BGP 경로는 특정 IP 주소 집합을 제어하는 AS에 도달하기 위해 따라갈 수 있는 ASN 경로를 지정함
  • BGP 경로는 AS 간 피어링 관계를 통해 형성됨
    • 두 AS의 border gateway가 peer하면, 두 라우터 사이로 트래픽이 이동할 수 있음
    • 서로 알고 있는 BGP 경로 정보를 최신 상태로 공유함
  • 예시로 AS0001의 Router A와 AS0002의 Router B가 물리적으로 연결되어 피어링하려면 BGP 메시지를 주고받아 BGP 세션을 설정함
    • Router A는 AS0002로 시작하는 BGP 경로에 대해 Router B를 통해 가야 한다는 사실을 알게 됨
    • Router B도 반대 방향 정보를 알게 됨
  • peer들은 경로 광고(route advertisement) 과정으로 자신이 아는 경로를 공유함
    • Router A가 Router B에 자신이 아는 모든 경로를 알리면, Router B는 AS0001로 시작하는 경로를 라우팅 테이블에 추가함
    • Router A의 다른 peer가 새 경로를 광고하면 Router A는 이를 Router B에도 전달함
  • 이 광고가 AS 네트워크 전체로 퍼지면서, 각 border gateway는 인터넷상의 어떤 IP에 도달할 수 있는 하나 이상의 AS path를 알게 됨
  • 라우터가 특정 IP로 패킷을 보낼 때는 라우팅 테이블에서 해당 IP를 제어하는 AS로 가는 경로를 찾음
    • 이후 여러 휴리스틱으로 “가장 좋은” 경로를 선택함
    • 휴리스틱에는 최단 경로 탐색과 특정 AS에 대한 하드코딩된 선호 또는 비선호가 포함됨
    • 라우터는 선택한 경로의 첫 번째 AS와 피어링된 gateway router로 패킷을 보냄

traceroute 결과를 BGP 관점에서 읽기

  • 예시 traceroute의 AS path는 AS4766 → AS201011 → AS24940임
  • 어느 시점에 패킷은 AS4766의 라우터 중 하나에 도달했고, 그 라우터는 AS201011의 라우터와 피어링되어 있었음
    • 라우터는 라우팅 테이블에서 목적지 IP가 AS201011로 시작하는 경로를 통해 도달 가능하다고 판단함
    • 이후 패킷을 연결된 AS201011 라우터로 보냄
  • 같은 ASN 안에서도 여러 홉이 나타날 수 있음
    • Hetzner Online을 통과하는 여섯 홉처럼 traceroute는 AS 경계 라우터뿐 아니라 패킷이 지나간 모든 라우터를 보여줌
  • AS 내부 라우터들은 효율적인 내부 경로를 알고 있으면 외부 BGP 경로보다 내부 경로를 우선할 수 있음
    • 내부 경로는 내부 BGP, 다른 내부 라우팅 프로토콜, 또는 하드코딩으로 학습될 수 있음
  • 인터넷의 도달 가능성을 결정하는 핵심은 내부 홉이 아니라 서로 다른 AS 간 피어링 계약임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 안녕하세요, Lexi입니다. 17살이고, 요즘 관심사는 컴퓨터가 어떻게 동작하는지 더 깊이 이해하고 그걸 새로운 방식으로 보여주는 것임
    몇 달 전에 https://cpu.land를 공개했고, 관련 토론은 https://news.ycombinator.com/item?id=37062422에 있음
    cpu.land 이후 또 다른 거대한 결과물을 만들어야 한다는 압박이 컸지만 딱히 끌리는 아이디어가 없어서 개인 프로젝트를 이것저것 해보다가, 인터넷 동작 방식을 우연히 배우는 과정에서 웹사이트로 실시간 스트리밍되는 traceroute 프로그램을 처음부터 만들게 됨
    이런 형태를 웹에서 본 적이 없었고, 인터넷 구조를 시각화하는 꽤 새롭고 멋진 방식이라 생각해 다듬고 예쁜 사이트로 만들었음
    그 과정에서 BGP와 인터넷 구조에 대해 흥미로운 걸 많이 배워서, traceroute 도구와 그 지식을 공유하는 글을 합쳤음
    아직 계속 손보고 있고 코드가 어딘가에서 깨질 게 분명하니 제안이 있으면 알려주면 좋겠음
    덧붙여 왜 Rust냐면, 프로그래밍 언어 선택이 아주 중요하다고 보진 않지만 신뢰성 높은 저수준 프로그램을 빨리 쓰고 싶었고 Rust의 오류 처리 기본 요소가 마음에 들었기 때문임

    • “웹에서 이런 걸 본 적이 없다”면 looking glass bgp를 검색해보면 비슷한 것들이 나옴
      거의 30년 전에 처음 만든 CGI 프로그램 중 하나가 Perl로 traceroute를 감싸고 서버 푸시로 결과를 스트리밍하는 스크립트였음
      오래된 것이 다시 새로워지는 법이지만, 그래도 사이트의 표현은 아주 좋음
      참고로 IPv4 TTL은 법적으로는 초 단위지만, 어떤 라우터도 1초 이상 잡아먹지 않고 최소 감소값이 1이라 사실상 홉 수로 쓰임. 숨어 있고 싶은 미들박스는 아예 감소시키지 않기도 함
      또 Linux/Unix traceroute는 기본적으로 탐사용 패킷에 ICMP 대신 높은 번호의 보통 닫힌 포트로 가는 UDP를 쓰는데, 역사적으로 UDP가 ICMP보다 드롭되거나 필터링될 가능성이 낮았기 때문임
      traceroute가 어떻게 동작하는지 묻는 건 면접 질문 중 하나인데, 대부분 모르고 알아도 질문 가치가 떨어짐. TCP/IP에 대해 질문을 아무리 받아도 첫 원리에서 추론하지 못하는 경우가 많고, 그래도 풀어낼 수 있는지는 합리적인 문제 해결 질문이라고 봄
      예: https://www.bgplookingglass.com/
      https://www.oreilly.com/openbook/cgi/ch06_06.html
    • 멋진 프로젝트임. 진지한 제안 하나와 가벼운 제안 하나가 있음
      ICMP 대신 TCP나 UDP를 쓰면 더 정확한 결과를 얻을 수 있을지 궁금함. 전통적인 traceroute도 UDP 옵션이 있고, mtr [1]은 TCP나 UDP를 쓸 수 있으며, tcptraceroute [2]는 TCP를 쓸 수 있음
      그리고 Talking Heads 인용을 넣기 딱 좋음. “And you may ask yourself, well, how did I get here?” [3]
      [1] https://github.com/traviscross/mtr
      [2] https://linux.die.net/man/1/tcptraceroute
      [3] https://en.wikipedia.org/wiki/Once_in_a_Lifetime_(Talking_He...
    • 17살 때의 나보다 훨씬 멋진 걸 많이 하고 있음. “I, Robot”을 재미있게 봤다면 Ted Chiang의 Stories of Your Life and Others도 추천함. 영화 Arrival이 이 단편집의 한 작품을 바탕으로 만들어졌음
    • traceroute를 설명하는 좋은 사이트라 유용함. 회사 네트워크를 유지보수하도록 교육하는 여러 기술자에게 traceroute의 용도를 설명할 때 쓸 수 있을 것 같음
      이제 특정 워크스테이션에서 회사 Cisco 액세스 스위치, 코어 스위치, AWS transit gateway로 가는 BGP 터널을 거쳐 EC2 인스턴스의 VPC 라우팅 테이블에 도달할 때까지 각 홉에서 traceroute가 동작하게 하는 법만 알아내면 네트워크 담당자라고 부를 수 있을 듯함
    • 멋짐. Tor 회로가 보일까 봐 긴장했음
      아쉽게도 너무 많은 노드가 traceroute 패킷을 무시해서, 내 출구 노드가 Linode에 연결되고 Linode가 네 컴퓨터에 연결된 것처럼만 나왔음
      정방향 traceroute에서도 비슷하게 라우터가 응답하고 서버가 응답하며, 운이 좋으면 ISP 네트워크의 노드 하나 정도만 보임. 나머지는 단단히 막혀 있음

  • “BGP는 인터넷에 형태를 부여하는 프로토콜이고, 직접 말할 수는 없다”고 했지만, 실제로는 개인이 ASN을 얻고 BGP를 말하는 게 놀랄 만큼 쉬움
    이런 도구를 만드는 게 흥미롭다면 한번 해볼 만함. 관심 있다면 예전에 쓴 입문 글도 있음: https://qt.ax/asn

  • 이건 “내 컴퓨터가 네 서버에 도달하는 방식”이라기보다 네 서버가 내 컴퓨터에 도달하는 방식의 역방향에 가까움. 양방향 라우팅은 대부분 꽤 다를 가능성이 큼

    • 글 안에 실제로 이 내용을 다룬 Front to Back, Back to Front 섹션이 있음
      요약하면, 내 경험상 거치는 네트워크는 보통 매우 비슷했고 어느 방향이든 내용은 관련 있고 흥미로움
    • bang path 시절에는 발신자의 bang path와 답장용 bang path가 얼마나 다른지 보고, 어떤 네트워크 연결 차이가 비대칭성을 만드는지 추론하는 게 재미있었음

  • traceroute가 어떻게 동작하는지와 관련해 흥미로울 논문이 있음. 네트워크 쪽이 아닌 사람들이 자주 놓치는 점은 traceroute가 반드시 대칭적이지 않다는 것임. 반환 경로가 다를 수 있음
    https://archive.nanog.org/sites/default/files/traceroute-201...

    • 오늘 이집트에서 Telecom Egypt 문제로 인터넷 장애가 있었는데, 같은 목적지로 가는 traceroute가 8개의 서로 다른 경로를 탔음
      지금까지 인터넷에서 본 ECMP 수의 두 배라 할 만함
      그리고 카이로 사무실에서 영국 코어로 가는 트래픽과 반대 방향 트래픽도 서로 다른 경로를 탐. London→Cairo는 직통이고 여전히 대량 손실이 있지만, Cairo→London은 이제 ntt를 거쳐 가며 괜찮아 보임. 내일까지 고쳐지지 않으면 로컬 선호도를 바꿔야 할 수도 있음
    • 드물지만 데이터 경로 자체도 비대칭일 수 있음. 예를 들면 지상 업링크를 쓰는 위성 같은 경우임
    • 고마움, 읽어보겠음. 이 이중성은 글에서도 다뤘음

  • “WHOIS는 파서를 만들기에 흥미로운 프로토콜”이라고 했지만, 실제로는 불가능에 가까움
    응답이 본질적으로 자유 형식이고, 서버가 응답하지 않을 수도 있음. 나도 시도해봤는데 10년 전 기준으로 주소나 도메인의 90%에 동작하는 임시 파서는 만들 수 있었지만 나머지는 처리 불가능했음
    요즘은 더 나빠졌고, 거의 모든 것이 개인정보 보호막 뒤에 숨겨져 있음. PII를 보호한다고 주장하지만, WHOIS 레코드는 원래 개인 정보를 담는 것이 아니라 네트워크 운영자 연락처를 담도록 되어 있었음
    이건 ICANN 탓이라고 봄. ICANN에는 네트워크가 공개 WHOIS 서버를 제공해야 한다는 규칙이 있었지만 집행하지 않았고, 이제는 그 규칙을 폐기했음

    • WHOIS에는 이메일, 전화번호, 실제 주소가 들어가야 하지 않나? 회사라면 PII가 아닐 수 있지만, 개인 웹사이트의 WHOIS라면 어떻게 개인정보가 아니라고 볼 수 있는지 모르겠음
    • RDAP는 WHOIS 정보 일부를 기계가 읽을 수 있는 JSON 형식으로 담고 있음. 전부는 아니지만 더 낫다고 봄
      다만 모든 곳이 RDAP 서버를 운영하지는 않음. ICANN/IANA든 누군가가 이를 강제해주면 좋겠음
      네트워크 운영자 정보도 PII일 수 있음. 내 정보는 PII이고, 도메인 이름을 가지고 있으니 내 정보를 WHOIS에 넣는 건 PII를 WHOIS에 넣는 것임
      개인정보 보호 서비스는 스팸을 제외하고 모든 것을 나에게 전달해줄 뿐임
      회사라면 개인정보 보호 서비스를 허용할 좋은 이유가 없다고 보지만, 아직 모든 도메인이 대기업 소유는 아님
    • 주소나 도메인의 90%에 맞는 임시 파서는 만들 수 있지만 나머지는 난해하다는 부분에서, 요즘은 생성형 AI가 도움이 될 수 있지 않을까? “여기 whois가 있으니 내가 원하는 정보를 뽑아줘” 같은 식으로

  • 별도 ICMP ECHO 추적 대신, 클라이언트 브라우저와 웹 서버 사이의 기존 HTTP TCP 연결을 활용하면 한 단계 더 나아갈 수 있음
    그러면 클라이언트 쪽 NAT나 상태 저장 방화벽을 통과할 수 있음

    • 흥미롭다. 실제 traceroute로는 어떻게 동작할지 궁금함
    • 그걸 parasitic traceroute라고 부름

  • reverse traceroute에 관한 이전 작업들이 있음
    https://research.cs.washington.edu/networking/astronomy/reve...
    논문: http://www.cs.washington.edu/homes/ethan/papers/reverse_trac...
    영상: http://www.usenix.org/multimedia/nsdi10katz-bassett

  • TCP 세션의 패킷이 인터넷을 지나며 비대칭 경로를 타는 경우가 많다는 것도 알아둘 만함. 내 경험상 가장 흔한 이유는 비용과 관련된 비즈니스 규칙, 그리고 사람의 실수였음
    IP가 어떻게 동작하는지 생각해보면 이 자체는 특별히 문제가 되지 않지만, 라우팅을 이해하기는 더 어려워질 수 있음

    • 재미있는 일화가 있음
      Boise State University와 University of Idaho는 Idaho 주 양 끝에 있는 학교임. 북쪽의 UIdaho는 Spokane에 가깝고 연결 대부분이 Seattle에서 오며, Boise는 Salt Lake 쪽에 가까워 Portland나 Salt Lake City를 통해 연결되는 경우가 많음
      두 학교 사이의 주 중앙부는 산악 지형이라 대규모 연결이 거의 없었지만, 예전에 UofIdaho가 남부 지역 원격 강의실을 두고 있어서 작은 회선 하나가 있었음
      90년대 후반 어느 시점에 BSU 네트워크 엔지니어와 UofI 엔지니어가 같은 건물에 스위치와 라우팅 장비를 두고 있다는 걸 알고 둘 사이에 이더넷 케이블을 연결했음
      결과는 재앙이었음. 두 네트워크가 서로에게 BGP를 광고하기 시작했고, 그 연결이 인터넷 전체에 알려졌음. 갑자기 Seattle 쪽 네트워크와 Salt Lake City 쪽 네트워크 사이에 아주 짧은 점프가 생겼고, 그 불쌍한 작은 T1 회선이 완전히 포화됐음
      흥미롭게도 한 방향에서만 그랬음. Boise는 경로를 광고했지만 Idaho는 그렇지 않아서 트래픽이 사실상 한 방향으로만 망가졌음
      당연히 케이블은 뽑혔고, 몇 년 뒤 내가 UofIdaho에서 일할 때도 두 네트워크는 절대 다시 연결하면 안 된다는 게 잘 알려져 있었음. 아이러니하게도 당시 나는 두 대학에 I2를 구축하는 프로그램을 진행 중이었음

  • 내 기기에서는 내 기기와 서버 사이의 중간 단계가 전혀 보이지 않음. 참고용임

    • 맞음, 미안함. Hacker News 때문에 서버가 꽤 버거워졌음
      지금 바로 작업 중이고 곧 더 잘 동작하길 바람. 그동안 타임아웃을 늘려서 로딩은 길어지겠지만 더 잘 작동할 것임
    • Linode 데이터센터 안에서 HN을 보지 않으면 더 잘 동작할지도 모름 :P

  • mtr도 언급할 가치가 있음. 나는 traceroute보다 훨씬 자주 씀
    간헐적 패킷 손실을 진단하는 데 도움이 되고, 흐름을 평균적으로 파악할 수 있게 해줌
    APNIC의 이 글은 mtr과 그 결과를 읽는 법을 더 자세히 설명하고, MPLS가 실제 경로를 어떻게 흐릴 수 있는지도 다룸
    https://blog.apnic.net/2022/03/28/how-to-properly-interpret-...
    UDP로 추적하는 것도 때때로 유용하고, 많은 라우터가 부하를 받을 때 ICMP를 선택적으로 드롭한다는 점도 알아둘 만함
    좋은 글이고 표현도 훌륭함

답변달기