패킷이 길을 찾는 방법

라우터는 지날 때마다 패킷의 TTL을 1씩 줄입니다. 0이 되면 패킷을 버리므로, 고리에 빠진 패킷이 영원히 돌 수 없습니다.

읽기 전에 아래 시뮬레이터부터 만져 보세요. TTL을 2로 두고 보내기를 누른 다음, 64로 바꿔 한 번 더 보냅니다. 처음 보냈을 때 패킷이 어디서 멈추는지 눈여겨보면 됩니다. 여유가 있으면 TTL을 3, 4, 5로도 바꿔 보세요. 패킷이 버려지는 라우터가 한 칸씩 뒤로 물러나다가, 5에서는 서버까지 닿습니다.

방금 본 것: 패킷마다 붙은 카운트다운

TTL 2로 보냈을 때는 모든 패킷이 두 번째로 만난 라우터에서 버려지고 빨간 메시지가 돌아왔습니다. 64로 보냈을 때는 라우터 넷을 지나 60이 남은 채 서버에 닿았습니다. IPv4 헤더에는 TTL(Time to Live)이라는 8비트 칸이 있어서 가장 큰 값이 255입니다. RFC 791은 라우터마다 이 값을 적어도 1씩 줄이라고 정했고, 많은 컴퓨터는 64에서 시작합니다. 집에서 보낸 패킷이라면 집 공유기가 그 값을 처음 줄이는 라우터입니다. 값이 0이 되면 라우터는 패킷을 버리고 보낸 쪽에 ICMP 「시간 초과」 메시지(RFC 792)를 돌려보냅니다. 화면에 돌아온 빨간 메시지가 바로 그 메시지입니다.

카운트다운은 왜 필요할까요? 라우터 표에 실수가 있으면 패킷이 같은 곳을 빙빙 돌 수 있고, 한도가 없다면 그 패킷이 연결을 끝없이 차지합니다. 이름에 「시간」이 들어 있고, RFC 791도 문서상으로는 초 단위라고 적었습니다. 하지만 라우터마다 적어도 1씩 빼므로 실제로는 지나온 라우터 수를 세는 숫자처럼 움직입니다. IPv6는 같은 칸에 더 알기 쉬운 이름을 붙였습니다. 홉 제한(Hop Limit)입니다.

traceroute 단추는 이 규칙으로 경로 지도를 그립니다. 먼저 TTL 1인 시험 패킷을 보냅니다. 첫 번째 라우터가 이 패킷을 버리면서 답을 보내고, 그 답에서 라우터 주소가 드러납니다. TTL 2를 보내면 두 번째 라우터가 드러나고, 목적지가 답할 때까지 이렇게 이어 갑니다. 단추를 누르고 만들어지는 목록을 읽어 보세요. R1-R3를 끊고 다시 보내면 패킷이 다른 길로 돌아가는 모습도 보입니다.

라우터는 표에서 한 줄만 찾습니다

내 노트북에서 다른 대륙의 서버까지 가는 길 전체를 아는 라우터는 하나도 없습니다. 라우터는 저마다 결정을 딱 하나 내립니다. 받는 주소가 이것이면 이웃 가운데 누구에게 넘길까? 패킷이 한 칸(한 홉) 움직이면, 거기서 다음 라우터가 다시 정합니다. 경로는 이렇게 그 자리에서 내린 선택들이 사슬처럼 이어진 결과입니다.

결정은 전달 표에서 나옵니다. 전달 표는 접두사마다 넘겨줄 이웃을 적어 둔 목록입니다. 라우터는 받는 주소와 맞는 항목 가운데 접두사가 가장 긴 것을 고릅니다. 접두사가 길수록 더 꼭 맞는 항목이기 때문입니다. 표에 203.0.0.0/16은 이웃 B로, 203.0.113.0/24는 이웃 A로 적혀 있다고 합시다. 203.0.113.9로 가는 패킷은 두 항목에 다 맞지만 더 긴 /24가 이겨서 A로 갑니다. 203.0.7.1로 가는 패킷은 /16에만 맞으니 B로 갑니다. 주소를 위아래로 맞춰 적어 보면 203.0.113.9가 두 접두사로 모두 시작한다는 것이 눈에 보입니다. 표에는 대개 「나머지 전부」를 위한 기본 항목도 있는데, 집 공유기에서는 이 항목이 통신사(ISP)를 가리킵니다.

표는 누가 채울까

한 회사 안에서는 라우터들이 라우팅 프로토콜로 자기가 닿을 수 있는 곳을 서로 알려 주고, 연결이 끊기면 길을 새로 계산합니다. 인터넷을 이루는 수만 개의 독립된 네트워크 사이에서는 경계 경로 프로토콜(BGP, RFC 4271)이 「나는 198.51.100.0/24에 닿을 수 있다」 같은 알림을 전합니다. 케이블이 끊기면 그 케이블을 지나던 경로가 철회되고, 트래픽은 남은 길로 옮겨 갑니다. 통신사끼리 주고받는 이런 알림 덕분에 우리나라 통신사 네트워크에서 다른 나라 서버까지 길이 이어집니다. 시뮬레이터에서 R1-R3를 끊었을 때도 같은 일이 일어났습니다.

사라지는 패킷은 대부분 꽉 찬 대기열에서 떨어집니다

라우터는 패킷을 기다리게도 합니다. 붐빌 때는 나가는 연결이 실어 나를 수 있는 것보다 패킷이 빨리 들어오므로, 라우터마다 메모리에 대기열을 둡니다. 대기열이 가득 차면 다음에 들어온 패킷은 그냥 버려집니다. 버렸다고 누구에게 알리지도 않습니다. 보낸 쪽이 나중에 스스로 알아챌 뿐이고, 그것도 대개 기다리던 확인 응답이 오지 않아서 드러납니다. 인터넷에서 패킷이 사라지는 가장 흔한 까닭이 이것이고, 케이블이 끊기는 일보다 잦습니다. 와이파이 신호가 약하면 프레임이 망가져 버려야 하는 일도 생깁니다. IP 자체는 아무것도 약속하지 않습니다. RFC 791은 IP가 믿을 수 있는 통신 수단을 제공하지 않으며, 받았다는 확인도 다시 보내기도 없다고 적어 두었습니다. 사라진 데이터를 되찾는 일은 양 끝 컴퓨터의 몫이고, 그 이야기는 다음 단원에서 이어집니다.

3,000,000바이트 사진은 패킷 2055개

연결마다 패킷 하나의 최대 크기가 정해져 있습니다. 이더넷에서 프레임 하나에 실을 수 있는 데이터는 최대 1500바이트입니다(RFC 894). 여기서 IPv4 헤더 20바이트와 TCP 헤더 20바이트를 빼면 패킷 하나에 내 데이터가 약 1460바이트 들어갑니다. 그러니 3,000,000바이트짜리 사진에는 3,000,000 ÷ 1460 ≈ 2054.8, 올림해서 패킷 2055개가 필요하고, 이 패킷들은 하나하나 따로 길을 찾습니다. 1단원에서 지하철에서 올린 사진이 이 크기였다면 작은 배달이 2055번 일어났습니다.