▲

여기까지 어떻게 왔을까?

 (how-did-i-get-here.net)
1P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • 사용자의 패킷이 인터넷을 통해 웹사이트 서버에 도달하는 경로를 실시간으로 시각화한 인터랙티브 페이지
  • 자체 제작한 traceroute 프로그램 ‘ktr’ 이 ICMP 패킷의 TTL 값을 활용해 각 네트워크 홉의 정보를 수집
  • 웹사이트는 JavaScript 없이도 작동하며, 서버가 traceroute 결과를 스트리밍 형태로 HTML에 반영
  • 경로 분석에는 WHOIS·PeeringDB 데이터를 이용해 각 IP가 속한 자율 시스템(AS) 과 기업 정보를 표시
  • traceroute와 BGP 기반 인터넷 구조를 결합해, 인터넷이 기업 간 피어링 관계로 구성된 네트워크의 집합임을 보여줌

당신의 패킷이 지나온 여정

  • 페이지 상단의 traceroute는 사용자의 컴퓨터에서 서버까지의 패킷 이동 경로를 나타냄
    • 라우터, ISP, Amazon, NTT Global IP Network, Hetzner 등의 네트워크를 순차적으로 통과
    • 일부 구간은 “(no response)”로 표시되며, 이는 응답하지 않는 서버 때문임
  • Hetzner 네트워크 내부에서는 여러 라우터를 거쳐 최종 서버에 도달
  • IP 주소 213.239.252.10은 역방향 DNS 조회를 통해 core0.fra.hetzner.com으로 표시됨

Behind the Scenes

  • 웹사이트는 사용자의 요청을 받으면 서버에서 traceroute를 실행하고 결과를 실시간으로 전송
  • traceroute는 ICMP 프로토콜을 사용하며, TTL(Time To Live) 값을 1씩 증가시키며 각 홉의 응답을 수집
  • TTL이 0이 되면 해당 라우터가 오류 메시지를 반환, 이를 통해 패킷이 거친 경로를 추적
  • ktr는 traceroute 결과를 스트리밍하면서 각 홉의 IP·ASN·소유 네트워크 정보를 동시에 조회

Frontend Fun

  • JavaScript 없이도 작동하며, 브라우저는 단순히 느리게 로딩되는 페이지처럼 인식
  • 서버는 HTTP 연결을 유지한 채 traceroute 결과를 순차적으로 HTML에 삽입
  • 각 업데이트마다 CSS 블록을 삽입해 이전 결과를 숨기는 방식으로 실시간 갱신 효과 구현

Front to Back, Back to Front

  • 실제로는 서버에서 사용자의 IP로 traceroute를 실행하고 결과를 역순으로 표시
  • 이는 “reverse traceroute”로, 양방향 경로가 완전히 동일하지는 않지만 대체로 유사한 경로를 보여줌

네트워크와 자율 시스템(AS)

  • 인터넷은 자율 시스템(Autonomous System, AS) 이라 불리는 기업 단위 네트워크들의 연결망
  • 각 AS는 고유한 ASN(Autonomous System Number) 을 가지며, 상호 피어링(peering) 을 통해 트래픽을 교환
  • 인터넷은 개인이 아닌 기업이 소유한 네트워크들의 집합으로, 연결은 금전적 계약과 행정 절차에 의해 결정됨
  • ASN은 5개 지역 인터넷 등록기관(RIR) 중 하나를 통해 신청 가능

WHOIS와 PeeringDB

  • traceroute의 각 IP가 속한 AS를 찾기 위해 WHOIS 프로토콜과 PeeringDB 데이터베이스를 사용
  • WHOIS는 TCP 연결 후 질의어를 보내면 서버가 정보를 반환하는 단순한 구조
  • 서버마다 필드명과 형식이 달라, 파서는 사람이 읽는 방식에 가까운 단순 시뮬레이터 형태로 구현
  • PeeringDB는 전체 AS의 약 1/3에 대한 기업 정보를 제공

BGP(Border Gateway Protocol)

  • BGP는 인터넷의 형태를 결정하는 핵심 프로토콜로, AS 간 경로 정보를 교환
  • 경계 라우터(border router)는 BGP 라우팅 테이블을 유지하며, 각 경로의 ASN 목록을 저장
  • 두 AS가 피어링하면 서로의 라우터가 BGP 세션을 맺고 경로 광고(route advertisement) 를 교환
  • 라우터는 여러 경로 중 가장 짧거나 선호도가 높은 경로를 선택해 패킷을 전달

BGP의 역사

  • 1969년 ARPANET에서 시작된 네트워크 실험이 1989년 Cisco와 IBM의 RFC 1105로 이어져 BGP v1 등장
  • 이후 BGP v2(1990) , v4(1994) 가 발표되었으며, v4는 현재까지 사용 중
  • BGP는 인터넷 상의 모든 네트워크 간 연결 경로를 결정하는 표준 프로토콜로 자리잡음

Traceroute와 BGP의 관계

  • 예시 경로: AS16509 → AS2914 → AS24940
    • Amazon(AS16509) → NTT Global IP Network(AS2914) → Hetzner(AS24940) 순서
  • 동일 ASN 내에서도 여러 홉이 존재하며, 이는 내부 라우팅 프로토콜이나 고정 경로로 처리됨
  • AS 간 피어링 관계가 인터넷 상의 실제 도달 가능성을 결정

Recap 요약

  • 웹사이트는 사용자의 IP로 traceroute를 실행하고, 결과를 HTTP 스트림으로 전송
  • traceroute는 ICMP 패킷의 TTL을 활용해 라우터 간 경로를 시각화
  • 각 라우터는 자율 시스템(AS) 에 속하며, BGP를 통해 상호 연결
  • 피어링 관계가 인터넷의 도달성과 구조를 결정

Epilogue

  • 작성자는 인터넷 구조에 대한 이해 부족을 느끼고, 프로토콜 중심의 교육용 인터랙티브 글을 제작
  • 완성도 높은 대형 프로젝트 대신 작은 형태라도 공개하는 것을 선택
  • Hack Club 커뮤니티의 격려로 완성되었으며, 오픈소스 traceroute 프로그램을 활용
  • “작더라도 완성된 것이 낫다”는 메시지와 함께, 지속 가능한 웹 콘텐츠로 남기를 희망
▲
GN⁺ 5시간전  [-]
Hacker News 의견

  • 이 reverse traceroute 기능이 여전히 유용하다고 생각함
    하지만 실제로는 AS 경로가 같더라도 피어링 포인트는 거의 항상 다름
    대부분의 AS는 hot-potato routing을 사용해서 트래픽의 출발지에 가장 가까운 피어링 지점으로 패킷을 넘김
    cold-potato를 써도 비대칭적임. 또 AS-path 길이가 같을 때는 hot-potato 정책 때문에 다른 경로를 선택할 수도 있음
    (편집: hot/cold 혼동 수정)

    • 여러 번 traceroute와 reverse traceroute를 돌려봤는데, 대부분 AS 경로는 비슷하게 나왔음
      다만 traceroute 쪽이 ISP 내부 경로를 더 많이 보여주는 경우도 있었음
      전반적으로 네 말이 맞고, 나중에 hot-potato vs cold-potato 라우팅 차이에 대해 더 자세히 설명해보고 싶음
      어쨌든 이 reverse traceroute 결과만으로도 인터넷 구조를 설명하기엔 충분하다고 생각함
    • 참고로 네가 말한 게 바로 hot-potato routing임
      각 AS가 가능한 한 빨리 패킷을 넘기는 구조임
      불공평하게 느껴질 수 있지만, 목적지 AS 내부의 세부 경로를 모르기 때문에 합리적인 선택임
      예를 들어 베를린과 함부르크에 네트워크가 있고, 상대방도 두 도시에 피어링이 있다면, 가까운 곳에서 넘기는 게 불필요한 왕복을 피하는 방법임

  • traceroute가 아래에서 위로 한 줄씩 로드되는 이유를 설명한 부분이 흥미로웠음
    JavaScript 없이 CSS 블록을 주기적으로 삽입해서 이전 상태를 숨기는 방식이라니 정말 해킹스럽고 창의적임

    • JavaScript 없이도 Declarative Shadow DOM을 이용하면 순서가 뒤섞인 HTML 스트리밍을 구현할 수 있음
      예시와 설명은 이 블로그 글에 잘 정리되어 있음

  • “This is not my beautiful website.”라는 문구가 재치 있게 느껴졌음

    • “This is not my beautiful home-page.”로 응수한 것도 센스 있었음

  • 혹시 아직 안 해봤다면

    tracepath -m60 bad.horse

    그리고

    openssl s_client -connect signed.bad.horse:443 -servername signed.bad.horse

    를 실행해보길 추천함

    • 멋짐! Dr. Horrible에게 바치는 geeky 오마주 같음
      tracepath 결과가 “bad.horse”에서 시작해 “he.rides.across.the.nation” 등으로 이어지는 식으로 나와서 정말 재미있음
    • 또 이런 것도 있음 
      ssh funky.nondeterministic.computer
    • 그리고 
      ssh watch.ascii.theater
      도 시도해볼 만함

  • 이 프로젝트가 다시 Hacker News 메인 페이지에 올라서 서버가 잠시 버벅였다고 함
    Lexi가 “내일 다시 확인해보라”고 공지했음

    • 지금은 좀 나아졌다고 함. 동시성(concurrency) 을 조금 더 추가했으며, 다음엔 Tokio를 쓰겠다는 교훈을 얻었다고 함

  • 제목을 보고 Talking Heads 노래가 나올 줄 알았음

    • “letting the days go by”라는 가사가 자동으로 떠올랐음
    • HTML을 보면 뭔가 숨겨진 게 있을지도 모름 :)

  • “Once in a Lifetime” 링크가 뇌에 각인된 느낌임
    제목만 봐도 그 베이스 라인이 자동으로 재생됨

    • 나도 즉시 존재론적 위기감이 몰려왔음

  • 직접 실행해봤는데, 내 주 인터넷 연결이 끊겨서 백업 회선으로 전환된 걸 발견했음
    오늘 정전이 있었는데, 이 도구 덕분에 그걸 알아챔. 꽤 유용했음

    • 정말 덜 알려진 경로(route less travelled) 를 발견한 셈임

  • 가끔 “You are here” 상단 정보가 이렇게 나옴

    Host               ASN   Network         Region
123-456-789-101.static.kc.net.uk AS19905 UltraDDoS Protect    Global

    그런데 또 어떤 때는

    Host               ASN   Network         Region
123-456-789-101.static.kc.net.uk AS12390 Kingston Communications Europe

    이렇게 번갈아 나옴. 같은 IP인데 왜 ASN이 50:50 비율로 바뀌는지 궁금함. 무작위로 바뀌는 것처럼 보임

  • 페이지가 처음엔 JavaScript 없이 잘 작동했는데, 나중에 교체된 HTML이 텍스트로 인코딩되어버림

    <noscript>
 <style>#strYQt8 { display: none; }</style>
 <div id='stro29i'>

    이런 식으로 나와서 깨졌음
    관련 수정 PR을 GitHub에 올림

답변달기