우리 집에서 구글까지 가는 길

이번 포스팅에서는 우리 집에서 구글까지 어떤 과정을 통해 통신을 하는지에 대해서 간략하게 얘기해보려고 한다. 필자가 대학에서 배운 것 중 재밌다고 생각했던 것이 몇 개 있는데, 그 중 대표적인 것이 바로 인터넷에 연결되어 있는 모든 컴퓨터는 실제로 케이블을 통해 연결되어있다는 사실이었다.

혹자는 당연하다고 생각할 수 있는 이 사실이 그땐 굉장히 신기했던 것 같다. 매일매일 인터넷을 사용하고 있지만 너무 생활 속에 자연스레 녹아있는 요소이다 보니 그 원리에 대해서는 그다지 신경쓰지 않았기 때문이다.

그러다가 학교에서 네트워크에 대해 점점 자세히 배우면서 “내가 당연하게 사용하고 있는 이 혜택들이 사실은 굉장히 체계적이고 복잡한 시스템이구나”라는 사실을 알게 되었다.

그래서 이번 포스팅에서는 필자의 집에서 구글 서버에 접속하는 과정을 통해 그 시스템에 대해서 간단하게 풀어보려고 한다. 물론 IP 주소를 기반으로 대략적인 추정을 하는 것이기 때문에 정확한 정보는 아니겠지만 대략적으로 이런 과정을 통해 해외에 있는 서버에 접속할 수 있다는 사실을 중심으로 풀어갈 것이다.

IP, Internet Protocol

먼저 우리 집에서 구글까지의 경로를 알기 위해서 인터넷하면 빠질 수 없는 IP에 대해서 간단하게 알아보자. IP 주소라는 단어는 컴퓨터 관련 전공을 하신 분이 아니더라도 굉장히 익숙한 단어이다.

일반적인 환경에서 우리가 인터넷에 접속할 때 이 IP 주소가 우리 집 주소의 역할을 한다고 생각하면 된다. 마찬가지로 우리 집에서 구글까지 가는 길목에 있는 지점들도 모두 IP 주소를 가지고 있고, 우리는 그 IP 주소를 기반으로 이 지점이 어디인지 대략적으로 추측해볼 수 있다.

IP에 관해서 굉장히 기본적인 내용을 설명할 예정이므로 이미 다 아시는 분은 그냥 건너뛰셔도 무방하다.

IPv4의 구조

일반적으로 우리가 접할 수 있는 192.168.0.1과 같은 형태는 IPv4이다. IPv4는 8비트로 구성된 4개의 필드로 구성되고 이 하나하나의 필드를 옥탯(Octet)이라고 부른다(참고로 Oct으로 시작하는 용어는 8을 뜻하는 게 많다). 예를 들어 192.168.0.1은 이진법으로 전환하면 다음과 같이 나타낼 수 있다.

10진법: 192.168.0.1
2진법: 11000000.10101000.00000000.00000001

한 옥탯에 8비트밖에 가지지 못하기 때문에 옥탯은 00000000 ~ 11111111, 즉 십진법으로는 0~255의 수를 가지게 되는 것이다. 그렇기 때문에 IPv4로 생성할 수 있는 주소의 개수는 $2^{32} = 4,294,967,296$로 약 43억개이다. 43억개라니… 꽤 큰 숫자 같아 보인다. 처음에 이 주소 체계를 만들 때만 해도 이런 생각을 했던 것 같다.

에이 43억개나 있는데 어느 정도는 버티겠지?

생각보다 전세계의 인터넷 사용자가 빠르게 늘면서 결국 2011년 2월 4일부로 모든 주소가 소진되어 현재는 IPv4의 할당이 중지되었다. 다행히 그 동안 손놓고 있지는 않았고, 전세계의 똑똑한 분들이 이미 대책을 다 세워두었으니 너무 걱정하진 말자.

IPv4의 클래스

이렇게 IP 주소는 무제한으로 막 퍼줄 수 있는 자원이 아니라 유한한 자원이다 보니, 특정 대역마다 사용처를 나누어서 관리하게 된다. 이때 나누어진 대역을 클래스라고 부르며 A~E의 총 5개의 클래스로 나누어서 관리한다. 각 클래스는 이진법으로 표현한 IPv4인 00000000.00000000.00000000.00000000 중 첫번째 필드에 있는 8비트에 제한을 만들어서 표기하기 때문에 첫번째 필드의 숫자만 보면 해당 IPv4 주소가 어느 클래스에 속해있는 지 알 수 있다.

이 제한은 바로 첫번째 필드의 최상위 비트를 강제하는 방식이다. 예를 들어 A 클래스는 무조건 비트가 0으로 시작해야하기 때문에 00000000(0)에서 01111111(127)사이의 첫번째 필드를 사용할 수 있고 C 클래스는 무조건 비트가 110로 시작해야하기 때문에 11000000(192)부터 11011111(223)까지의 첫번째 필드를 사용할 수 있는 식이다.

특수한 목적의 IPv4 주소

이렇게 클래스를 나누고 그 클래스 내부에서도 특수한 용도를 위해 미리 예약해놓은 IPv4 주소들이 있다. 이 예약 주소들은 RFC 5735에 의해 정의되어 있으며 목적에 벗어난 용도로 할당 받는 것이 불가능하다. 이 포스팅에서는 간략하게 대표적인 몇가지만 설명하고 넘어가겠다.

우리 집에서 구글까지의 경로를 보자

자, 드디어 이 포스팅의 메인 내용을 시작할 수 있게 되었다.

집에서 맥북을 열고 웹 브라우저에 google.com을 입력하면 웹 브라우저는 전 세계 어딘가에 있는 구글 서버에 페이지를 보내달라는 요청을 보낼 것이다. 하지만 필자의 맥북과 구글 서버까지는 직접 연결되어 있지 않다.

그렇기 때문에 필자가 보낸 요청은 구글 서버까지 가기 위해 여기저기를 들러가면서 험난한 여정을 겪는다. 그렇다면 이제 필자가 집에서 보낸 요청이 구글 서버까지 도달하기 전에 어디를 들리는 지 한번 알아보자.

traceroute 사용하기

필자는 Unix 기반의 MacOS를 사용하고 있기 때문에 MacOS 기준으로 설명하겠다. traceroute 유틸리티를 사용하면 내가 보낸 패킷이 어떤 경로를 통해 구글 서버까지 도달하는 지 알아볼 수 있다.

$ traceroute -q 1 google.com
traceroute to google.com (172.217.25.196), 64 hops max, 52 byte packets
 1  192.168.25.1 (192.168.25.1)  3.077 ms
 2  211.0.0.0 (211.0.0.0)  5.928 ms
 3  100.71.51.17 (100.71.51.17)  4.693 ms
 4  10.44.255.240 (10.44.255.240)  4.328 ms
 5  10.222.18.10 (10.222.18.10)  7.319 ms
 6  10.222.16.201 (10.222.16.201)  4.883 ms
 7  10.222.16.41 (10.222.16.41)  3.853 ms
 8  72.14.204.124 (72.14.204.124)  34.784 ms
 9  108.170.242.193 (108.170.242.193)  37.751 ms
10  108.170.233.79 (108.170.233.79)  36.643 ms
11  nrt13s50-in-f4.1e100.net (172.217.25.68)  35.416 ms

두번째 홉은 필자의 디테일한 위치가 노출될 수 있는 공인 IP를 출력하므로 보안 상 마스킹했다. 사실 필자가 사용하고 있는 ISP(Internet Service Provider)인 SK 브로드밴드는 관리 지역 내 IP 주소 임대기간이 1시간이기도 하고 필자는 인구밀도가 높은 곳에 거주하고 있으므로 저 IP 주소가 노출된다고 해도 위치를 알기는 쉽지 않지만 그래도 불안하기 때문에 가린다.

누가 우리 집 알아내면 어떡해...

traceroute의 결과로 출력되는 하나의 row를 홉(Hop)이라고 부르는데, 필자의 집에서부터 구글의 서버까지 필자의 패킷이 거쳐간 경로를 의미하는 것이다. 홉의 IP 주소 오른쪽에 출력된 시간은 홉이 응답한 시간을 의미한다. 재밌는 것은 8번 홉부터 갑자기 응답 시간이 한자리 수에서 두자리 수로 확 뛴다는 것인데, 여기서부터는 패킷이 국내를 벗어나 해외로 빠져나간 것이다.

그렇다면 이 IP 주소들은 어디를 의미하는 걸까?

좀 더 자세히 알아보자!

이제 이 IP 주소들이 각각 어디를 의미하는지, 어떤 회사가 소유하고 있는 어떤 디바이스인지 좀 더 자세히 알아보고 싶다. 간단하게 알아보는 방법은 whois 유틸리티를 사용하는 방법이 있다.

$ whois 172.217.25.68
NetRange:       172.217.0.0 - 172.217.255.255
CIDR:           172.217.0.0/16
NetName:        GOOGLE
NetHandle:      NET-172-217-0-0-1
Parent:         NET172 (NET-172-0-0-0-0)
NetType:        Direct Allocation

MacOS의 whois 유틸리티는 5개의 whois 서비스에 요청을 보내 받아온 결과를 출력해주는 방식이다. 참고로 대한민국의 whois 서비스는 KISA(한국인터넷진흥원)의 후이즈검색에서 제공하고 있다.

그러나 whois 서비스는 기본적으로 도메인이 등록된 IP 주소의 소유주에 대한 정보를 보여주는 서비스라서 도메인이 등록되지 않은 게이트웨이나 라우터에 대한 정보는 나오지 않는다. 그래서 필자는 IP2Location이라는 사이트를 이용하여 한번 찾아볼 것이다.(근데 이것도 잘 나올 것 같지는 않다)

먼저 첫번째 홉인 192.168.25.*은 필자 집의 공유기에서 할당해준 사설 IP 이고 두번째 홉은 ISP(Internet Service Provider)가 필자에게 부여해준 공인 IP이나, 보안 상 마스킹 했으므로 세번째 홉인 100.71.51.17부터 한번 살펴보겠다.

100.71.51.17

앗 역시 생각보다 정보가 별로 안나왔다. 대신 해당 IP 주소가 Carrier Grade NAT에 사용된다는 정보를 출력했다. 위에서 설명한 대로 A 클래스의 100.64.0.0 ~ 100.127.255.255 대역이 Carrier Grade NAT에 사용된다는 것은 이미 표준으로 정의된 것이기 때문에 사실 뻔한 결과를 출력한 것이다. 그럼 Carrier Grade NAT이 뭐길래 중간에 필자의 패킷이 들렀다 가는걸까?

Carrier Grade NAT

우선 NAT은 Network Address Translation의 약자로 대개 사설 네트워크에 속한 여러 개의 호스트가 하나의 공인 IP를 사용하여 인터넷에 접속하기 위한 기술이다. 필자는 SK 브로드밴드의 IPTV나 Wi-Fi 등 여러 개의 서비스를 사용 중이다. 그렇다고 IP 주소를 가입한 서비스마다 나눠주기에는 주소가 매우 부족한 상황이기 때문에 SK 브로드밴드는 필자에게 단 하나의 공인 IP 주소를 할당해주고 NAT 기능이 있는 공유기를 집에 설치해, 필자의 집에 사설 네트워크(Private Network)를 구축해준 것이다.

Carrier Grade NAT(CGN)은 NAT의 스케일 큰 버전이라고 생각하면 된다. 필자의 집에 설치된 공유기는 필자의 집 내부에 사설망을 구성하는 데에 그치지만 CGN은 백본망에 구성되는 NAT이다. 쉽게 말하면 거대 공유기랄까…?

필자가 알기로는 원래 스마트폰의 LTE같이 모바일 망에 직접 연결되는 무선 인터넷 디바이스를 NAT로 관리하기 위해 백본망에서 CGN을 운영한다고 알고 있었는데, 왜 집에 있는 공유기를 사용 중인 필자의 패킷이 CGN을 타는지는 잘 모르겠다. SK 브로드밴드가 IPv4가 많은 편은 아니긴 한데… 너무 모자라서 유선 인터넷에도 CGN을 달았나…?(혹시 아시는 분은 좀 알려주세요…궁금해요…)

10.44.255.240 ~ 10.222.16.41

여기서부터는 A클래스 사설망에 할당되는 IP이므로, 추측하건데 SK 브로드밴드의 백본망 내부인 것 같다. ISP들은 자신들의 망 구조를 자세히 알려주지 않기 때문에 정확히 어디에 위치한 노드인지는 알 수 없지만 SK 브로드밴드의 망 구조 상 대략 이쯤 되는 것 같다.

여기서 부터 다른 국내 ISP와 연결되거나 해외망으로 연결된다

72.14.204.124 ~ 108.170.233.79

드디어 구글이 소유하고 있는 디바이스가 나타났다! 근데 위치가 네덜란드 암스테르담이다. 구글은 미국 캘리포니아에 있는 회사인데 왜 뜬금없이 암스테르담이 출현했는지 모르겠다. 뭔가 이상하기 때문에 유럽을 담당하는 whois 서비스인 whois.ripe.net에 물어봐야겠다.

whois -h whois.ripe.net 72.14.204.124

inetnum:        69.194.128.0 - 76.255.255.255
netname:        NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK
descr:          IPv4 address block not managed by the RIPE NCC

역시 여기서 관리하고 있는 주소가 아니라고 한다. 그렇다면 아메리카를 담당하는 whois.arin.net에 물어보자.

whois -h whois.arin.net 72.14.204.124

NetRange:       72.14.192.0 - 72.14.255.255
CIDR:           72.14.192.0/18
NetName:        GOOGLE
NetHandle:      NET-72-14-192-0-1
Parent:         NET72 (NET-72-0-0-0-0)
NetType:        Direct Allocation
OriginAS:
Organization:   Google LLC (GOGL)
RegDate:        2004-11-10
Updated:        2012-02-24
Ref:            https://rdap.arin.net/registry/ip/72.14.192.0

오 이번에는 제대로 된 정보가 나왔다. 72.14.204.124 주소를 가진 디바이스는 구글이 소유하고 있는 무언가인듯하다. IP2Location은 이제 필자에게 신뢰를 잃었기 때문에 가차없이 버리기로 하고 DB IP라는 새로운 솔루션을 사용하겠다. DB IP를 사용하여 검색해보니 위치가 Ashburn, Loudoun, Virginia, United States로 잡히고 Connection Type은 Hosting으로 되어있다.

그 이후 9번 홉인 108.170.242.193과 10번 홉인 108.170.233.79 또한 버지니아 주에 위치한 호스팅 서버인 것으로 표시되었다. 여기에 도대체 뭐가 있길래 다 여기에 옹기종기 모여있는걸까…? 조금 구글링을 해보니 구글이 Ashburn에서 일할 사람을 찾고 있는 공고를 발견했다. 또한 같은 버지니아 주의 옆 동네인 Sterling과 Reston으로도 채용공고가 많이 올라와있다.

날 뽑아줘요...엉엉

공고를 쭉 스캔해보니 주로 Network Engineer, Administrative Business Partner, Data Center, Google Cloud와 같은 키워드가 많이 보이는 걸로 봐서는 아무래도 여기에 구글 데이터센터가 있나보다. 좀 더 정보를 찾아보니 구글이 버지니아에서 일하는 인원을 두배 늘린다는 기사도 올해 2월에 작성되었었다.

여기에 구글 데이터센터가 있는 것은 아무래도 확실한 것 같다.

172.217.25.68(google.com)

자 드디어 마지막 google.com 도메인의 종착점인 172.217.25.68 주소를 가진 서버이다. 이 주소도 역시 DB IP를 통해 검색해본 결과 일본에 있는 서버라고 한다.

사실 한국에 있는 필자가 미국에 있는 서버에서 계속 정보를 받는 것보다 가까운 일본에 있는 서버에서 정보를 받는 게 훨씬 빠르기 때문에 이건 당연하긴 하다. 필자의 패킷은 태평양을 건너 미국에 갔다가 다시 일본으로 건너가는 기묘한 루트를 그리고 있었다는 것이다…

자세하게 파고 들어가면 왜 이런 루트를 그리는지 알 수 있겠지만 너무 포스팅이 길어질 것 같아 여기까지만 파보겠다.(다음에 좀 더 자세히 파보는 걸로…) 늘 아무 생각없이 접속하던 구글도 자세히 들여다보면 이렇게 다양한 경로를 통해 나에게 전달된다. 새삼 신기한 사실이다.

이상으로 우리 집에서 구글까지 가는 길 포스팅을 마친다.

• IP, Internet Protocol

  • IPv4의 구조
  • IPv4의 클래스
  • 특수한 목적의 IPv4 주소

• 우리 집에서 구글까지의 경로를 보자

  • traceroute 사용하기
  • 좀 더 자세히 알아보자!