Packet Bench

1986년 10월, 인터넷에 첫 ’혼잡 붕괴’가 찾아왔습니다. 로런스 버클리 연구소(LBL)와 UC 버클리는 370m쯤 떨어져 있었고, 두 곳 사이의 경로는 세 홉이었습니다. 그 사이의 전송 속도가 초당 32킬로비트에서 초당 40비트로 떨어졌습니다.

LBL의 연구원 반 제이콥슨은 마이크 캐럴스와 함께 원인을 파고들었습니다. 그는 훗날 논문에 이 “갑작스러운 천 배의 대역폭 하락”에 매료되었다고 적었습니다. 1988년 8월 SIGCOMM 학회에서 발표한 「혼잡 회피와 제어(Congestion Avoidance and Control)」에는 TCP에 새로 넣은 장치 일곱 가지가 나옵니다. 그중 하나가 슬로 스타트(slow start)입니다. 연결을 처음 열 때는 세그먼트 하나만 보내고, 확인 응답(ACK)이 돌아올 때마다 한 번에 보내는 양을 늘립니다. 패킷이 사라지면 다시 줄입니다. 이 규칙은 지금도 TCP 표준(RFC 5681)에 들어 있습니다.

교과서에서 슬로 스타트는 대개 그래프 한 장으로 나오고, 네트워크 전체는 상자를 쌓은 그림으로 나옵니다. 상자 그림은 응용, 전송, 네트워크, 링크로 나뉜 계층마다 맡은 역할을 알려 주지만, 주소를 입력하고 엔터를 누르는 순간 실제로 무슨 일이 벌어지는지는 보여 주지 않습니다. 내 컴퓨터는 네트워크 장비와 어떻게 소통할까요? 라우터는 패킷의 어느 부분을 보고, 어떤 행동을 할까요? 세그먼트 하나가 사라지면 보내는 쪽은 이를 어떻게 알아차리고, 왜 갑자기 전송량을 줄일까요? Packet Bench는 이런 통신 과정을 작은 네트워크에서 직접 실행하고, 한 홉씩 따라가며 답을 확인할 수 있게 해 줍니다. 혼잡 제어 시나리오의 그래프에서는 슬로 스타트가 윈도를 두 배씩 키워 가다 손실을 만나 줄이는 모습을 볼 수 있습니다.

네트워크는 시뮬레이션이지만 패킷은 실제와 같습니다. Rust로 작성해 WebAssembly로 컴파일한 이산 사건(discrete-event) 시뮬레이터가 Ethernet, ARP, IPv4, UDP, TCP, DNS, TLS 레코드, HTTP의 실제 헤더 형식에 맞춰 프레임을 만들고, 체크섬도 실제로 계산합니다. 라우터는 최장 접두사 일치(longest prefix match)로 경로를 고르고, TTL을 1 줄인 다음, 새 Ethernet 헤더를 붙여 다음 장비로 전달합니다. TCP 송수신 양쪽은 순서 번호, 누적 ACK, 순서가 뒤바뀐 데이터를 보관하는 버퍼, 재전송 타이머, NewReno 혼잡 제어를 모두 갖춘 상태 머신으로 동작합니다. 같은 입력에는 언제나 같은 결과가 나오므로, 어느 시점으로 되돌아가도 똑같은 장면을 다시 볼 수 있습니다.

무엇을 볼 수 있나요

• 네트워크 토폴로지. 클라이언트, 라우터 세 대, DNS 서버, 웹 서버로 구성된 네트워크입니다. 링크마다 지연 시간이, 인터페이스마다 주소가 표시되어 있습니다. 패킷은 시뮬레이션 시간에 맞춰 움직이므로 25ms 링크를 지나는 데는 5ms 링크보다 다섯 배 오래 걸립니다. 패킷 주위의 고리는 그 패킷이 어떤 계층들로 감싸여 있는지 나타냅니다. 토폴로지 아래쪽에는 라우터들이 방금 내린 경로 결정이 표시됩니다.
• 시퀀스 다이어그램. 같은 실행 과정을 시간 순서대로 화살표로 그립니다. 화살표 하나가 홉 하나이고, 기울기는 그 링크를 지나는 데 걸린 시간을 나타냅니다. 손실된 패킷은 ✖ 표시로 끝나며, 화살표를 누르면 해당 패킷의 내용을 볼 수 있습니다.
• 패킷 계층. 선택한 패킷의 헤더를 실제 전송 순서대로 겹겹이 보여 줍니다. 바이트는 계층별 색으로 구분하고, 필드마다 값을 해석해 보여 줍니다. 라우터가 Ethernet 헤더는 통째로 바꾸지만, 안쪽의 IP와 TCP 헤더는 TTL과 체크섬만 빼고 그대로 두는 것을 확인할 수 있습니다.
• TCP 상태. 연결 양쪽의 상태(SYN_SENT, ESTABLISHED, FIN_WAIT_1 …)와 순서 번호, 보냈지만 아직 응답받지 못한 데이터, 순서가 뒤바뀌어 보관 중인 데이터를 보여 줍니다. 혼잡 윈도가 시간에 따라 어떻게 변하는지는 차트로 그립니다.
• 라우팅 테이블과 C 코드. 라우터마다 라우팅 테이블을 보여 주고, 방금 일치한 항목을 강조합니다. 각 통신을 시작할 때 C 프로그램이 호출하는 소켓 함수(socket, connect, send, recvfrom …)도 함께 보여 줍니다.
• 입문자를 위한 용어 설명. cwnd, MSS, TTL, SNI 같은 약어에는 앱 어디서나 밑줄이 있습니다. 마우스를 올리거나 누르면 쉬운 말로 설명해 줍니다.

시나리오

시나리오는 모두 여덟 가지이며, 각각 시뮬레이션 시간으로 수백 밀리초 분량입니다.

• DNS. 클라이언트가 ARP로 게이트웨이의 MAC 주소를 알아낸 다음, UDP로 DNS 서버에 www.example.com의 IP 주소를 묻습니다.
• UDP. 핸드셰이크 없이 데이터그램 세 개를 보냅니다. 그중 하나가 손실되어도 아무도 알아차리지 못합니다.
• 라우팅. 최장 접두사 일치에 따라 /16보다 /24 경로가 선택되고, TTL이 0이 된 패킷은 버려지며, 링크가 끊기면 트래픽이 다른 경로로 우회합니다.
• TCP 연결 설정과 종료. 3-way 핸드셰이크, 짧은 데이터 전송, 4-way 종료와 TIME_WAIT.
• 순서 제어. 세그먼트 하나는 손실되고, 다른 하나는 늦게 도착합니다. 받는 쪽은 순서가 뒤바뀐 데이터를 보관하면서 같은 ACK를 반복해서 보내고, 보내는 쪽은 중복 ACK를 세 번 받으면 곧바로 재전송합니다.
• 혼잡 제어. 슬로 스타트, 혼잡 회피, 손실 후의 빠른 회복, 그리고 타임아웃이 발생해 윈도가 세그먼트 하나 크기로 줄어드는 과정.
• HTTP. 이름 조회부터 연결, 요청과 응답, 종료까지 페이지 하나를 불러오는 전체 과정.
• HTTPS. 같은 페이지를 TLS 1.3으로 불러옵니다. ServerHello 이후에는 인증서를 포함한 모든 내용이 암호화된 레코드로 전송되므로, 라우터가 읽을 수 있는 것은 레코드 헤더뿐입니다.

할 수 없는 것

실제 인터넷으로 패킷을 보낼 수는 없습니다. 웹 페이지에서는 raw 소켓을 쓸 수 없어서 google.com에 ping을 보낼 수 없고, 네트워크는 항상 같은 여섯 대의 장비로 구성됩니다. 실제 암호화도 하지 않습니다. TLS 메시지와 레코드 헤더는 TLS 1.3 형식을 따르고, 암호화된 부분은 암호문처럼 보이도록 흉내 낸 값입니다. AES-GCM 같은 실제 암호 알고리즘은 쓰지 않습니다. IPv6, IP 단편화, SACK 같은 TCP 옵션도 지원하지 않습니다.

시작하기

이 페이지에서 앱을 열면 HTTP 시나리오가 나옵니다. 재생을 누르면 전체 과정이 재생되고, 화살표 버튼으로 한 홉씩 앞뒤로 이동할 수 있습니다. 속도 슬라이더를 가장 느리게 하면 한 홉에 3초가 걸립니다. 위쪽 목록에서 다른 시나리오를 고를 수 있고, 토폴로지의 패킷이나 시퀀스 다이어그램의 화살표를 누르면 그 패킷의 내용을 볼 수 있습니다. 화면은 영어, 한국어, 일본어를 지원하며, 오른쪽 위의 달 모양 버튼으로 밝은 테마와 어두운 테마를 전환할 수 있습니다.