역주: 실시간 결과는 원문에서 확인하실 수 있습니다.
위의 텍스트 덤프는 traceroute입니다. 이 traceroute는 당신의 여정 — 또는 적어도 당신의 패킷이 — 이 웹사이트를 호스팅하는 서버에 도달하기 위해 인터넷 네트워크를 가로질러 이동한 경로를 보여줍니다. 위의 traceroute와 앞으로 나올 화면의 모든 녹색 빛나는 텍스트는 웹사이트를 로드할 때 실시간으로 여러분에게 맞춰 생성된 것입니다.
이 여정은 당신의 컴퓨터가 라우터와 통신하는 것에서 시작됩니다. ISP 네트워크로의 진입점인 그 라우터는 당신의 공인 IP인 121.138.49.112와 함께 traceroute에서 가장 먼저 보게 될 항목입니다.
그 라우터에서 시작하여, 여정의 첫 부분은 Korea Telecom 네트워크의 장치들을 통과했습니다. 아마도 그것이 당신의 ISP일 것이며, 돈을 받고 인터넷에 연결해 주는 역할을 합니다.
다음으로, 당신은 두 개의 네트워크를 거쳤습니다: KT Corporation (Korea Telecom) (또 다른 ISP)과 AS201011 (???).
참고로, "(no response)"가 보이시나요? traceroute에서 이런 것들이 종종 몇 개씩 나타납니다 — 모든 서버가 일관되게 응답하지는 않으며 인터넷은 불안정하기 때문입니다! 아쉽지만, 응답하는 서버들로부터 무슨 일이 일어나고 있는지 꽤 잘 파악할 수 있습니다.
결국, 제 서버에 도달하기 위해 그 네트워크의 영역을 벗어나야 했습니다. 저는 호스팅 제공업체로 Hetzner를 이용하고 있으며, 당신이 그들의 네트워크로 진입한 지점은 core3.sto.hetzner.com이었습니다. 당신은 거기서부터 Hetzner의 내부 네트워크를 조금 돌아다닌 후 마침내 제 서버에 도달했습니다.
(참고로, core3.sto.hetzner.com이라는 것은 제가 DNS 서버에 traceroute에서 실제로 반환된 IP인 213.239.252.74와 연관된 이름이 있는지 물어본 역방향 DNS 조회의 결과입니다. 있었기 때문에 숫자 대신 "예쁜" 사람이 읽을 수 있는 이름을 사용했습니다. 역방향 DNS 이름은 보통 디버깅을 더 쉽게 하기 위해 설계된 것이며, 원래 IP로 다시 매핑되지 않는 경우도 많습니다.)
무대 뒤에서
이 웹사이트에 도달하기 위해, 당신의 컴퓨터는 인터넷을 통해 몇 개의 패킷을 보냈습니다. 그 경로가 무엇인지 궁금하다면, traceroute — 패킷이 목적지에 도달하기 위해 거친 모든 서버의 대략적인 목록 — 를 생성하는 도구를 실행할 수 있습니다. 이 웹사이트를 만들기 위해 (GitHub의 소스 코드), 저는 ktr이라는 자체 traceroute 프로그램을 작성했으며 (역시 오픈 소스) 각 홉에 대한 흥미로운 정보를 동시에 조회하면서 결과를 실시간으로 스트리밍할 수 있습니다.
ktr은 어떻게 작동할까요? 인터넷 라우팅에 대한 간단한 설명부터 시작하겠습니다.
소스 장치에서 시작하여, 패킷을 처리하는 각 컴퓨터는 그것을 전달할 최적의 장치를 선택해야 합니다. 이러한 라우팅 결정이 어떻게 이루어지는지는 잠시 후에 설명하겠습니다. 모든 것이 올바르게 작동한다고 가정하면, 패킷은 결국 목적지로 직접 보내는 방법을 알고 있는 라우터에 도달하게 됩니다.
저의 traceroute 구현은 ICMP라는 프로토콜을 사용합니다. ICMP는 인터넷을 통해 진단 정보를 보내기 위해 특별히 설계되었으며, 거의 모든 인터넷에 연결된 장치가 이를 사용합니다. 흥미롭게도, ICMP 패킷에는 "TTL" (time to live) 필드가 있습니다. 이것은 이름이 암시하는 것처럼 실제로 "시간"이 아닙니다 — 카운트다운입니다! 라우터가 ICMP 패킷을 전달할 때마다 TTL 숫자를 감소시켜야 합니다. TTL이 0이 되면, 라우터는 더 이상 전달하지 않고 대신 패킷이 최대 홉 수에 도달했다는 오류 메시지를 패킷의 소스 IP로 보내야 합니다.
이 TTL 기능을 활용할 수 있습니다! traceroute를 하려면, 점점 더 큰 TTL을 가진 ICMP 패킷을 여러 개 보낼 수 있습니다. TTL이 1인 첫 번째 패킷은 도달하는 첫 번째 장치에서 오류가 발생하고, 이런 식으로 계속되어 패킷을 건드린 모든 라우팅 장치에서 오류를 받을 수 있기를 바랍니다. 이러한 오류 패킷에는 오류를 보낸 장치의 IP 주소와 같은 진단 정보가 포함되어 있어 인터넷을 통한 패킷의 대략적인 경로를 추적할 수 있습니다.
프런트엔드의 재미
이 페이지는 자바스크립트가 비활성화되어 있어도 완벽하게 작동합니다. 브라우저의 관점에서 이 웹사이트는 단순히 느리게 로드된 것입니다. 당신의 관점에서는 traceroute가 마법처럼 보일 것입니다.
이 웹사이트를 로드할 때, 제 프로그램은 당신의 IP 주소에서 오는 HTTP 요청을 받았습니다. 즉시 당신의 IP로 traceroute를 실행하기 시작했습니다. 그런 다음, 서버는 HTTP 요청에 응답하기 시작했습니다: 이 웹 페이지의 시작 부분을 보내고, 연결을 열어 두었습니다. 제 traceroute 프로그램인 ktr이 서버에 당신의 traceroute에 대한 업데이트를 제공할 때마다, 관련 HTML을 렌더링하여 당신의 컴퓨터로 보냈습니다. traceroute가 완료되면, 서버는 모든 텍스트를 생성하고 연결을 닫기 전에 웹사이트의 나머지 부분을 보냈습니다.
traceroute가 맨 아래 줄 위에 줄들을 점진적으로 로드하는 것을 눈치챘을 수 있습니다. 웹 페이지는 위에서 아래로만 로드할 수 있습니다. 자바스크립트를 사용하고 싶지 않았기 때문에, 가능한 가장 해킹스러운 방법을 사용했습니다: traceroute 표시를 업데이트할 때마다, 이전 버전을 숨기는 CSS 블록을 삽입합니다! 브라우저가 페이지가 로드되는 동안 CSS를 렌더링하기 때문에, 이것은 traceroute가 시간이 지남에 따라 편집되는 것처럼 보이게 만들었습니다.
앞에서 뒤로, 뒤에서 앞으로
이 웹사이트의 traceroute가 당신의 패킷이 제 서버에 도달하기까지의 경로라는 주장은 다소 선의의 거짓말이었습니다. 그것을 계산하려면, 당신의 컴퓨터에서 제 서버로 traceroute를 실행할 수 있어야 했을 것입니다. 대신, 저는 제 서버에서 당신의 컴퓨터로 traceroute를 실행하고 그것을 뒤집었습니다. 그래서 상단의 traceroute가 역순으로 로드되는 것처럼 보이는 것입니다.
"서버에서 여러분의 컴퓨터 방향으로 traceroute를 실행하는 방식은 일부 정확도가 떨어질 수 있습니다.
인터넷 라우팅을 설명할 때 말했듯이, 패킷이 통과하는 각 장치는 최종 목적지에 도달할 때까지 패킷을 다음에 어디로 보낼지 결정합니다. 다른 방향으로 패킷을 보내면, 장치들이 다른 라우팅 결정을 내릴 수 있습니다… 그리고 한 장치가 하나의 다른 결정을 내리면, 나머지 경로는 확실히 달라질 것입니다.
이 역방향 traceroute는 여전히 유용합니다. 경로는 대략적으로 동일할 것이며, 아마도 당신의 패킷을 보는 특정 라우터만 다를 것입니다.
그래서, 그 모든 네트워크는 무엇인가요?
이 사이트는 내 서버에 도달하기 위해 통과한 "네트워크"에 대한 이야기로 시작했습니다. 구체적으로 이 네트워크는 무엇일까요?
각 네트워크는 자율 시스템(AS, autonomous system)이라고도 불리며, 서로 비공개로 연결되어 있고 일반적으로 같은 회사가 소유한 라우터와 서버의 집합입니다. 이러한 자율 시스템의 소유자들은 어떤 다른 자율 시스템과 연결할지 선택함으로써 인터넷의 형태를 결정합니다. 인터넷 트래픽은 서로 "피어링 계약"을 맺은 자율 시스템들을 통해 이동합니다.
인터넷은 종종 당신과 저 같은 사람들이 소유한 컴퓨터와 회사들이 소유한 컴퓨터를 연결하는 개방적이고 거의 무정부적인 네트워크로 묘사됩니다. 실제로, 인터넷은 기업이 소유한 네트워크들의 네트워크이며, 그에 대한 접근과 통제는 금융 거래에 의해 지배되고 관료주의로 가득 차 있습니다.
자신만의 자율 시스템을 원한다면, 인터넷의 숫자를 관리하는 다섯 개의 지역 인터넷 레지스트리(RIR) 중 하나에 자율 시스템 번호(ASN)를 신청할 수 있습니다. 주의하세요, 회사의 지원이 없거나 인터넷에 충분한 접속점이 없다면 아마 당신의 말을 듣지 않을 것입니다. 우리가 IP 주소를 사용하여 —
잠깐, IP 주소가 정확히 무엇을 식별하나요? 음… 인터넷에 접속할 수 있는 장치를 나타낸다고 합시다.
… 우리가 IP 주소를 사용하여 인터넷에 접속할 수 있는 장치를 식별하는 것처럼, ASN을 사용하여 인터넷의 네트워크를 식별합니다. 처음의 traceroute에서 "AS4766"과 같은 숫자가 그것입니다.
WHOIS에 대한 참고 사항
제가 직접 멋진 traceroute 프로그램을 작성한 이유 중 하나는 당신의 traceroute 경로에 있는 IP를 소유한 자율 시스템에 대한 정보를 가져올 수 있기 때문입니다. 몇몇 조직이 어떤 AS가 어떤 IP 주소를 포함하는지 추적하려고 합니다. 그들 중 많은 곳이 WHOIS 프로토콜을 사용하여 ASN 조회를 수행할 수 있게 해주므로, 저는 임의로 선택한 몇몇 서버의 응답을 파싱하는 작은 클라이언트를 작성했습니다.
그런 다음 PeeringDB라는 멋진 데이터베이스를 사용하여 ASN 뒤에 있는 회사를 알아냈습니다. PeeringDB는 모든 자율 시스템의 약 1/3에 대한 정보를 가지고 있습니다. 저는 이 모든 정보와 수백 줄의 if 문을 사용하여 당신을 위한 네트워크 경로 설명을 생성해냈습니다.
WHOIS는 사실 파서를 만들기에... 흥미로운 프로토콜입니다. WHOIS 프로토콜 명세가 실제로 많은 것을 명시하지 않는다는 것이 밝혀졌습니다. WHOIS 서버에 TCP 연결을 하고, 조회하고 싶은 것을 보내면, 서버가 정보를 보내고 연결을 종료한다고 명시합니다. 그게 전부입니다.
그럼에도 불구하고, 많은 WHOIS 서버가 구조화된 것처럼 보이는 정보로 응답합니다:
이 구조는 WHOIS 서버 관리자가 만든 것이며 서버들 사이에 공유된 관습이 있을 뿐입니다. 이 정도의 구조에도 불구하고, 원하는 필드가 종종 다른 이름으로 나타나거나 (origin? originas?) 여러 곳에 한꺼번에 나타나기도 합니다.
제 "파서"는 결국 파서라기보다는 제가, 한 인간이, 필요한 ASN을 찾기 위해 WHOIS 결과를 읽는 방식을 가볍게 시뮬레이션한 것이 되었습니다.
BGP
인터넷을 통해 패킷을 보낼 때, 이러한 네트워크가 연결되는 경계에 있는 라우터들이 목적지 장치가 있는 네트워크에 도달할 때까지 패킷을 다음에 어떤 네트워크로 보낼지 결정합니다.
이 경계 라우터들은 Border Gateway Protocol (BGP)이라는 프로토콜을 사용하여 연결할 수 있는 네트워크에 대해 서로 대화합니다.
BGP는 인터넷의 형태를 결정하는 프로토콜이며, 직접 사용할 수는 없습니다.
역사 시간
1969년, 닐 암스트롱이 달에 착륙한 같은 해에, ARPANET의 프로토타입에서 메시지가 (부분적으로) 전송되었습니다. 다음 20년 동안, 이 "상호 연결된 컴퓨터 네트워크"는 꽤 인기를 얻었고 모두가 이 열차에 타고 싶어했습니다. 여러 대학, 정부 기관, 그리고 몇몇 회사들이 여기저기서 컴퓨터 네트워크를 만들기 시작했습니다.
이 조직들 중 일부는 데이터를 더 쉽게 공유할 수 있도록 네트워크를 서로 연결하기 시작했습니다. 우리가 알고 있는 인터넷은 아직 존재하지 않았지만, 이러한 네트워크 상호 연결은 통제 불능이 되어가고 있었고 이를 조정할 좋은 표준이 없었습니다. 1989년, Cisco와 IBM의 엔지니어들이 RFC 1105를 발표하여 최초 버전의 BGP를 설명했습니다.
다음 몇 년 동안, 상호 연결된 네트워크 사람들은 "인터넷"이 급속히 현실이 되면서 매우 바빠졌습니다. BGP v1 RFC가 나온 지 불과 1년 후, Cisco가 상장하여 네트워킹 산업에 많은 돈을 가져왔고, "IANA"라는 용어가 인터넷의 숫자를 추적하고 있던 어떤 사람과 그의 대학 부서를 지칭하는 데 처음 사용되었으며, ARPANET이 영구적으로 종료되었고, BGP v2가 출시되었습니다.
1994년, 인터넷이 급격히 현실이 되어가던 소용돌이가 막 진정되기 시작할 때, BGP의 최종 주요 버전인 v4가 RFC 1654에 명시되었습니다. 두 번 개정되었고 (1995년과 2006년) 몇 가지 패치를 받았지만, BGP v4는 여전히 현대 인터넷을 구성하는 상호 연결된 네트워크를 통한 경로를 선택하는 데 사용하는 프로토콜입니다.
이 BGP는 어떻게 작동하나요?
자율 시스템 사이의 경계에 있는 라우터("경계 게이트웨이")는 자신이 알고 있는 모든 BGP 경로 목록을 유지하며, 이를 라우팅 테이블이라고 합니다. 각 BGP 경로는 특정 IP 주소 집합을 제어하는 자율 시스템에 도달하기 위해 따를 수 있는 ASN 경로를 지정합니다.
이러한 인터넷을 통한 경로는 자율 시스템 간의 피어링 관계에 의해 형성됩니다. 두 자율 시스템의 경계 게이트웨이가 피어링할 때, 일반적으로 다음에 동의합니다:
-
두 라우터 사이에 트래픽이 이동할 수 있도록 허용합니다. 이는 BGP 경로가 두 ASN 사이를 직접 갈 수 있다는 것을 의미합니다.
-
서로 알고 있는 BGP 경로에 대해 최신 상태를 유지합니다.
예를 들어 봅시다! AS0001의 라우터 A가 AS0002의 라우터 B와 물리적으로 연결되어 있고 서로 피어링하고 싶어합니다. 그들은 BGP 메시지를 서로 보내 BGP 세션을 설정합니다. 라우터 A는 이제 AS0002로 시작하는 모든 BGP 경로에 대해 라우터 B를 통해야 한다는 것을 알고, 그 반대도 마찬가지입니다.
BGP 피어는 경로 광고라는 과정을 통해 서로 알고 있는 경로를 공유합니다. 위의 예에서, 라우터 A가 라우터 B에 연결할 때, 라우터 B에게 "이봐, 내가 알고 있는 모든 경로야, 내 ASN을 통해 (그리고 확장해서, 나를 통해) 그것들 모두에 도달할 수 있어"라고 말할 것입니다. 라우터 B는 라우터 A를 통한 모든 경로를 — 그래서 AS0001로 시작하여 — 라우팅 테이블에 추가합니다. 라우터 A의 다른 피어가 새 경로를 광고할 때마다, 라우터 A는 그것들을 라우터 B에게 전달 광고합니다.
AS0001은 아마도 직접 일부 IP 주소를 제어할 것입니다. 라우터 A는 그것들도 라우터 B에게 광고할 것입니다. 그러면 라우터 B는 그 직접 경로를 전달 광고하여, 자신의 피어들에게 AS0002 → AS0001이 그 IP에 도달하는 유효한 경로라고 말할 것입니다. 피어들에게 경로 광고를 전달하는 이 과정을 통해, BGP 경로는 자율 시스템의 전체 네트워크에 전파되어 어떤 경계 게이트웨이든 인터넷의 모든 IP에 도달하는 하나 이상의 AS 경로를 알 수 있기를 바랍니다.
특정 IP로 패킷을 라우팅하려면, 경계 게이트웨이는 먼저 라우팅 테이블에서 그 IP를 제어하는 AS로 가져다 줄 모든 경로를 검색합니다. 그런 다음 라우터는 가장 짧은 경로를 찾고 특정 자율 시스템에 대한 하드코딩된 선호도를 가중치로 두는 것을 포함한 다양한 휴리스틱으로 "최적의" 경로를 선택합니다. 마지막으로, 피어링된 해당 AS의 게이트웨이 라우터에 보내서 해당 경로의 첫 번째 AS로 패킷을 라우팅합니다. 그 라우터는 차례로 자신의 라우팅 테이블을 보고 패킷을 다음에 어디로 보낼지 자체적으로 결정합니다.
Traceroute 회고
처음의 traceroute에서, 당신의 패킷이 결국 취한 AS 경로는 AS4766 → AS201011 → AS24940이었습니다. 이것은 예를 들어, 어느 시점에 당신의 패킷이 AS201011의 라우터 중 하나와 피어링된 AS4766의 라우터 중 하나에 도달했고, 그 라우터가 라우팅 테이블을 보고 목적지 IP가 AS201011로 시작하는 어떤 경로를 통해 도달할 수 있다는 것을 보고, 당신의 패킷을 연결된 라우터로 보냈다는 것을 의미합니다.
같은 ASN 내에서 몇 개의 홉이 있었습니다; KT Corporation (Korea Telecom)을 통과하는 여섯 개를 보세요. Traceroute는 자율 시스템의 경계에 있는 라우터뿐만 아니라 패킷이 거치는 모든 라우터를 보여줍니다. 라우터가 내부 네트워크를 통한 효율적인 경로를 알고 있다면, 종종 외부 BGP 경로를 그것으로 덮어씁니다. 그러한 내부 경로는 BGP의 내부 버전, 다른 내부 라우팅 프로토콜, 또는 단순히 하드코딩을 통해 학습될 수 있습니다.
이러한 내부 홉은 인터넷이 어떻게 작동하는지 이해하는 데 그다지 중요하지 않습니다. 다른 자율 시스템 간의 피어링 계약만이 도달 가능성을 결정합니다.
요약
-
이 웹사이트를 로드할 때, 제 커스텀 traceroute 프로그램을 사용하여 당신의 공인 IP (121.138.49.112)로 traceroute를 실행하고, HTTP를 통해 스트리밍한 다음, traceroute의 텍스트 설명을 렌더링했습니다.
-
traceroute는 인터넷의 두 장치 사이에 통과한 라우터의 경로를 보여줍니다. 제 특정 구현은 증가하는 TTL 필드를 가진 ICMP 패킷을 보내는 방식으로 작동합니다.
-
이러한 라우터는 자율 시스템이라는 네트워크에 있습니다. 이 AS의 가장자리에 있는 라우터는 BGP를 사용하여 서로 피어링합니다. 경계 라우터는 BGP를 사용하여 라우팅 테이블을 서로 공유하고, 이 지식을 사용하여 라우팅 결정을 내립니다.
-
BGP 피어링 세션은 자율 시스템 소유자 간의 (종종 비공개인) 계약에 따라 생성됩니다. 트래픽은 피어링된 네트워크 사이에서만 통과할 수 있으므로, 이러한 계약이 인터넷에서의 도달 가능성의 유일한 지배자입니다.
에필로그
저는 인터넷 구조에 대한 이해 상태에 좌절했고, 프로토콜의 관점에서 그 역사와 정치를 다루는 포괄적이고 대화형인 글을 쓰고자 했습니다. 그러나 삶에서 많은 복잡한 일들에 휘말리고, 빠듯한 마감에 직면하여, 스스로 설정한 높은 목표에 도달할 시간이 없었습니다.
Hack Club의 친구들의 격려 덕분에, 제가 가진 것으로 최선을 다했습니다. "거대한 크루즈 요트를 영영 진수하지 않는 것보다 작은 뗏목이라도 출항시키는 것이 낫습니다!" 다른 것은 몰라도, 이 사이트의 가장 빛나는 부분을 구동하는 멋진 traceroute 프로그램을 활용할 수 있었습니다 :)
이것이 웹에서 오래 지속되고, 공유되고, 사람들에게 영감을 줄 수 있는 또 하나의 재미있고, 유익하고, 잘 만들어진 것이 되기를 바랍니다.
사랑을 담아,
Lexi
기타 자료
확인해 볼 것들:
자랑스러운 오픈 소스:
🚀 한국어로 된 프런트엔드 아티클을 빠르게 받아보고 싶다면 Korean FE Article을 구독해주세요!
cool