프로토콜과 계층

프로토콜: 통신의 약속

전화를 걸면 우리는 자연스럽게 정해진 순서를 따른다. 신호가 가고, 상대가 “여보세요?” 하고, 내가 누구인지 밝히고, 용건을 말하고, “끊을게요” 하고 끊는다. 상대가 아무 말이 없으면 “여보세요? 들리세요?” 하고 다시 묻는다. 이런 약속이 없다면 두 사람이 동시에 말을 시작하거나, 상대가 끊은 줄도 모르고 혼자 이야기하게 된다.

컴퓨터끼리의 약속을 프로토콜(protocol)이라 한다. 사람과 달리 컴퓨터는 눈치가 없으므로 약속을 아주 엄밀하게 정해야 한다. 모든 프로토콜은 세 가지를 정한다.

• 형식(syntax): 메시지의 몇 번째 바이트에 무엇을 적는가. “앞 2바이트는 받는 쪽 포트 번호, 큰 자리부터.”
• 순서(timing·sequence): 누가 먼저 무엇을 보내고, 무엇을 받은 뒤에야 다음으로 넘어가는가. “연결 요청 → 수락 → 확인을 주고받은 뒤에만 데이터를 보낸다.”
• 오류 시 행동(semantics): 답이 안 오거나 이상한 값이 오면 어떻게 하는가. “1초 안에 확인이 없으면 다시 보낸다. 체크섬이 틀리면 버린다.”

왜 계층으로 나누나

웹 페이지 하나를 받는 데 풀어야 할 문제를 늘어놓아 보자. 전선 위에서 0과 1을 어떤 전압으로 표현할까? 같은 선을 쓰는 여러 장치 중 누구에게 줄까? 지구 반대편까지 어느 길로 갈까? 중간에 잃어버린 조각은 누가 다시 보내나? 받은 바이트가 웹 페이지인지 메일인지 어떻게 아나? 이걸 프로그램 하나가 전부 처리한다면 Wi-Fi가 새로 나올 때마다 세상의 모든 브라우저를 고쳐야 한다.

그래서 통신은 일을 계층(layer)으로 나눈다. 각 계층은 바로 아래 계층이 주는 서비스만 믿고 자기 문제 하나를 푼다. 이것이 관심사의 분리다. 브라우저는 “이 바이트들을 저 서버의 443번 포트로 믿을 수 있게 보내 줘”라고 TCP에 부탁할 뿐, 그 바이트가 구리선을 타는지(4장), 빛이 되는지(5장), 전파가 되는지(11장) 모른다. 그래서 집 공유기를 Wi-Fi 7로 바꿔도, 회사 회선을 광으로 바꿔도 HTTP는 한 글자도 바뀌지 않는다.

OSI 7계층과 TCP/IP

계층을 나누는 방법에는 두 가지 유명한 지도가 있다. 국제표준화기구(ISO)가 1984년에 정리한 OSI 7계층(OSI reference model)은 꼼꼼한 교과서용 지도이고, 실제 인터넷이 쓰는 것은 그보다 단순한 TCP/IP 모델(Internet protocol suite)이다. OSI 방식의 프로토콜은 시장에서 졌지만 “L2 스위치”, “L4 로드밸런서”, “L7 방화벽”처럼 계층 번호는 OSI 것을 그대로 쓴다. 그래서 둘 다 알아야 한다.

이 책은 실무에서 가장 흔한 5계층 모델(응용·전송·네트워크·링크·물리)로 설명한다. 단위 이름도 기억해 두자. 같은 바이트 덩어리라도 TCP 입장에서는 세그먼트(segment), IP 입장에서는 패킷(packet), 이더넷 입장에서는 프레임(frame)이라 부른다. 무엇을 기준으로 보느냐에 따라 이름이 달라질 뿐이다.

캡슐화: 상자 속 상자

보내는 쪽에서는 데이터가 위에서 아래로 내려가며 계층마다 자기 헤더(때로는 꼬리말, 트레일러(trailer))를 붙인다. 이를 캡슐화(encapsulation)라 한다. 받는 쪽은 아래에서 위로 한 겹씩 벗기며 각 계층이 자기 헤더만 읽는다(역캡슐화). 각 계층에게 위 계층의 헤더와 데이터는 그냥 내용물, 즉 페이로드(payload)다.

헤더 크기는 프로토콜마다 정해져 있다. TCP 20바이트(옵션이 붙으면 최대 60), UDP 8바이트, IPv4 20바이트(최대 60), IPv6 40바이트, 이더넷 헤더 14바이트에 끝의 오류 검사값 FCS(frame check sequence) 4바이트. 선로 위에서는 프레임 앞에 동기용 프리앰블 8바이트가 붙고, 프레임 사이에 최소 12바이트만큼 쉬는 간격(IFG)을 둔다. 또 이더넷 프레임은 최소 64바이트여야 해서, 내용이 짧으면 0으로 채운다(패딩). 이렇게 실제 데이터가 아닌데 함께 실려 가는 바이트의 비율을 오버헤드(overhead)라 한다.

패킷 해부: 바이트 하나하나 읽기

이제 진짜 패킷을 열어 보자. 아래는 노트북(192.168.0.7)이 웹 서버(203.0.113.10)의 80번 포트로 보내는 HTTP 요청 프레임이다. 와이어샤크(Wireshark) 같은 패킷 분석기가 보여 주는 화면을 본떴다. 왼쪽은 계층별 필드 목록, 오른쪽은 실제로 선을 타는 바이트의 16진 덤프다. 바이트나 필드에 마우스를 올리거나 눌러 보자. 특히 두 가지를 눈여겨보자. 라우터를 지날 때마다 1씩 줄어드는 TTL(time to live), 그리고 헤더가 깨지지 않았는지 검사하는 체크섬(checksum)이다. 체크섬은 바이트들을 정해진 방식으로 더한 값으로, 한 비트만 바뀌어도 값이 달라진다.

표준은 누가 만드나

서로 다른 회사의 칩·장비·소프트웨어가 말이 통하려면 약속을 문서로 남기고 모두 따라야 한다. 이 문서를 표준(standard)이라 하고, 분야마다 표준을 만드는 기구가 다르다.

IETF의 문서 이름 RFC(Request for Comments)는 1969년 아파넷 시절 “의견을 구합니다”라는 겸손한 메모에서 시작했다. 지금은 9,000번이 넘었고, 한번 번호가 붙으면 고치지 않고 새 번호의 문서로 대체한다. 예를 들어 1981년의 TCP 명세 RFC 793은 2022년 RFC 9293으로 대체되었다.

종단 간 원칙: 중간은 단순하게

인터넷 설계의 중요한 철학이 종단 간 원칙(end-to-end principle)이다(Saltzer·Reed·Clark, 1981). 신뢰성, 암호화, 순서 맞추기 같은 기능은 결국 양 끝의 컴퓨터만 완벽하게 해낼 수 있으니, 망 중간은 “최선을 다해 패킷을 나를 뿐(best effort)” 단순하게 두고 똑똑한 일은 끝에서 하자는 생각이다. 덕분에 라우터는 빠르고 값싸게 만들 수 있었고, 새 앱을 내놓을 때 망 사업자의 허락이 필요 없었다. 웹, 스카이프, 비트토렌트가 모두 이렇게 태어났다.

현실의 인터넷에는 NAT, 방화벽, 캐시, 통신사의 트래픽 관리 장비처럼 원칙을 어기고 깊이 들여다보는 중간 장비(미들박스(middlebox))가 많다. 이들은 자기가 모르는 TCP 옵션이나 새 프로토콜을 버리기 일쑤라서, 새 전송 프로토콜을 만들기가 매우 어려워졌다(“프로토콜 경직화”). QUIC(9장)이 UDP 위에 올라타고 헤더 대부분을 암호화한 이유가 바로 이것이다. 중간 장비가 볼 수 없으니 간섭할 수도 없다.