📡 네트워크 한 입에

Chapter 04네트워크 계층 — 데이터 평면

트랜스포트 계층까지는 양 끝의 호스트만 등장했어요. TCP가 혼잡 제어를 하든 UDP가 막 던지든, 가운데 라우터들은 그냥 "패킷이 흘러가는 어떤 통로"로 추상화돼 있었죠. 4장에서는 그 통로를 직접 열어봅니다. 이 안에는 굉장히 부지런한 친구들이 한 무리 살고 있는데, 이들이 패킷을 받아서 다음 어디로 보낼지 0.000001초 단위로 결정하고 있어요.

네트워크 계층(network layer)의 일은 의외로 간단하게 한 줄로 정의됩니다. "송신 호스트의 패킷을 수신 호스트까지 전달하는 것." 그런데 이걸 전 세계 수십억 대의 기기 사이에서, 다양한 링크와 사업자, 정책을 거치며 해야 하니까 단순할 수가 없어요. 그래서 네트워크 계층은 두 평면(plane)으로 쪼개어 생각합니다. 이번 장은 그중 데이터 평면(data plane), 즉 패킷이 도착했을 때 라우터가 즉시 무엇을 하는가에 집중해요. 제어 평면(control plane), 즉 "라우팅 테이블을 어떻게 만들어 두는가"는 다음 장의 몫입니다.

이번 장의 여정은 이렇습니다. 우선 두 평면을 가르는 기준선을 잡고(4.1), 라우터 안을 직접 뜯어봐요(4.2). 그다음 인터넷의 고전 IP 헤더와 주소 체계(4.3), 그리고 주소 고갈을 둘러싼 IPv6와 NAT(network address translation) 이야기(4.4)로 넘어갑니다. 마지막으로 IP를 넘어선 일반화된 포워딩과 SDN(software-defined networking)(4.5), 그리고 종단간(end-to-end) 원칙을 살짝 흔드는 미들박스(middlebox) 이야기(4.6)로 마무리해요. 슬슬 가봅시다.

4.1 네트워크 계층 개요

네트워크 계층의 일을 정확히 가르는 두 단어가 있어요. 포워딩(forwarding)과 라우팅(routing)이에요. 둘 다 한국어로 옮기면 "패킷을 보낸다"는 비슷한 느낌이라 헷갈리기 쉬운데, 시간 스케일과 주체가 완전히 다릅니다.

비유 한 입

우체국으로 비유하면, 라우팅은 "전국 우편 노선표를 짜는 본사 회의"이고 포워딩은 "지금 들어온 편지 한 통을 어느 분류함에 던질지 정하는 분류원의 손짓"이에요. 본사 회의는 가끔 열리지만, 분류원은 1초에도 수천 번 손을 움직입니다.

이 둘을 코드 구조처럼 두 평면(plane)으로 나누면 이렇습니다.

둘이 인터페이스로 만나는 자리가 바로 포워딩 테이블입니다. 제어 평면이 "이 목적지 IP 대역은 출력 포트 2번"이라고 적어두면, 데이터 평면은 들어온 패킷마다 그 표를 쓱 보고 2번으로 토스해요. 분업이 깔끔하죠.

+------------------------------------------------+ | CONTROL PLANE | | (라우팅 알고리즘, OSPF/BGP/SDN 컨트롤러) | +------------------------------------------------+ | | 포워딩 테이블 갱신 v +------------------------------------------------+ | DATA PLANE | | (라우터 하드웨어 — 들어온 패킷을 룩업하고 | | 적절한 출력 포트로 즉시 토스) | +------------------------------------------------+ ^ | | | 패킷 입력 패킷 출력

한 가지 미리 약속해둘 것. 이 책에서 "라우터(router)"라고 하면 IP 패킷을 다루는 3계층 장비를, "스위치(switch)"라고 하면 보통 2계층 이더넷 프레임을 다루는 장비를 가리킵니다. 6장에서 다시 정리하니, 지금은 "라우터 = IP를 보고 결정하는 친구"로만 새기고 가요.

그리고 인터넷의 네트워크 계층 서비스는 최선형(best-effort)입니다. 도착 보장 없음, 순서 보장 없음, 지연 보장 없음, 대역폭 보장 없음. 신뢰성이 필요하면 그건 위 계층에서 책임지라는 약속이죠. 이 미니멀한 약속 덕분에 네트워크 계층 코어는 단순하고 빠르게 굴러가요. 다음 장에서 제어 평면을 다룰 때 다시 만나요. 지금은 기계 자체로 들어가 봅시다.

4.2 라우터 내부

라우터를 한 마디로 그리면 "입력 포트 N개와 출력 포트 N개를 매트릭스로 연결한 박스 + 그 안에서 패킷을 옮겨주는 스위칭 패브릭(switching fabric) + 모든 걸 감독하는 라우팅 프로세서"예요. 패킷이 들어오면 입력 포트가 받아서 어디로 갈지 정하고, 패브릭이 그 자리로 옮기고, 출력 포트가 회선으로 내보내요.

+---------------- ROUTING PROCESSOR ----------------+ | (제어 평면. 포워딩 테이블 만들어서 뿌림) | +-----------------------+--------------------------+ | +-------------+-------------+ | SWITCHING FABRIC | | (메모리 / 버스 / 크로스바) | +---+-------+-------+-------+ | | | | IN --[link layer]---+ | | | | +--[link layer]-- OUT | | | | | | IN --[input port 1]-+-----+ | | +-----+-[output port 1]-- OUT IN --[input port 2]-+-------------+ | +-[output port 2]-- OUT IN --[input port 3]-+---------------------+ +-[output port 3]-- OUT ^ ^ | | 헤더 룩업/큐잉 큐잉/스케줄/송출

입력 포트의 일

입력 포트는 단순한 케이블 꽂는 자리가 아니에요. 다음 일들을 빠르게 처리해야 합니다.

고성능 라우터는 룩업을 라우팅 프로세서까지 안 가고 입력 포트의 전용 칩(예: TCAM)에서 끝내요. 그래야 회선 속도(line rate)를 따라잡을 수 있거든요.

스위칭 패브릭의 세 가지 형태

패브릭은 입력 포트에서 결정된 출력 포트로 패킷을 옮기는 내부 도로예요. 구현은 크게 셋입니다.

  1. 공유 메모리 방식 — 1세대 라우터의 방식. 입력 포트가 패킷을 시스템 메모리에 쓰고, 라우팅 프로세서가 목적지를 정한 뒤, 출력 포트가 메모리에서 다시 읽어가요. 단순하지만 메모리 대역폭이 곧 라우터 처리량의 한계예요.
  2. 버스 방식 — 모든 입력 포트가 하나의 공유 버스를 통해 출력 포트로 직접 보냄. 라우팅 프로세서를 매번 거치지 않으니 빨라요. 하지만 한 번에 한 패킷만 버스를 쓸 수 있어 버스 자체가 병목.
  3. 크로스바(crossbar) 방식 — 입력 N개와 출력 N개를 격자로 연결한 스위치. 충돌만 없으면 동시에 여러 패킷을 병렬로 옮길 수 있어요. 현대 고급 라우터의 표준.

출력 포트와 큐잉

패브릭을 건넌 패킷은 출력 포트의 큐로 들어가, 자기 차례에 회선으로 내보내져요. 출력 회선의 속도가 들어오는 패킷의 합보다 느리면 큐가 쌓이고, 큐 버퍼가 넘치면 패킷이 드롭(drop)됩니다. 3장에서 본 TCP 혼잡 제어가 이 드롭을 신호로 삼아 속도를 늦췄던 거죠.

스케줄링 정책도 출력 포트의 일이에요. 단순한 FIFO부터, 클래스마다 가중치를 주는 WFQ(weighted fair queuing), 우선순위 큐, 능동 큐 관리(AQM, 예: RED/CoDel)까지 다양합니다.

HOL 블로킹 — 입력 큐의 함정

패브릭이 충분히 빠르면 입력 큐는 거의 비어 있겠지만, 그렇지 않으면 입력 포트에도 큐가 쌓여요. 이때 골치 아픈 현상이 HOL 블로킹(head-of-line blocking)입니다.

입력 큐 1: [ A->출력1 ] [ B->출력3 ] [ C->출력2 ] ... ^ | 출력1이 지금 다른 패킷 처리 중이라 대기 v 맨 앞 A가 못 빠져나가니 뒤의 B, C도 같이 묶임

큐의 맨 앞 패킷이 자기 출력 포트가 막혔다는 이유로 멈추면, 그 뒤에 있는 다른 출력 포트행 패킷들까지 죄다 같이 멈춰요. 한 명이 늦으면 줄 전체가 늦어지는 식. 해법은 가상 출력 큐(virtual output queue) 같은 구조로, 입력 포트마다 출력 포트별로 큐를 따로 두는 거예요.

팁

라우터의 처리 속도를 이해할 때 가장 중요한 수치는 각 포트의 회선 속도예요. 스위칭 패브릭은 그보다 보통 몇 배 빠르게 설계돼요. 안 그러면 패브릭 자체가 병목이 되니까요.

4.3 IP — 인터넷 프로토콜

라우터가 들어온 패킷을 보고 결정을 내릴 때, 그 패킷의 형식을 정해두는 게 IP(internet protocol)예요. 인터넷의 모든 노드가 합의한 단 하나의 약속, 그게 IP입니다. 좋은 소식은 IP 헤더가 의외로 단순하다는 거고, 안 좋은 소식은 IPv4 주소가 32비트라는 거예요. 32비트면 약 43억 개. 인터넷 초창기엔 천문학적이었지만 21세기엔 모자라요.

IPv4 헤더

IPv4 헤더는 20바이트(옵션 없을 때)예요. 비트 단위로 보면 이렇습니다.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL | TOS/DSCP | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (선택) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

주요 필드만 짚자면.

IP 주소와 CIDR

IPv4 주소는 32비트지만, 사람이 쓰기 편하게 8비트씩 끊어서 점으로 잇습니다. 192.0.2.17 같은 형태죠. 옛날에는 주소를 클래스 A/B/C로 1·2·3바이트씩 잘라 쓰는 방식이었지만, 이건 너무 낭비가 심했어요. 회사 하나가 클래스 B를 받으면 65,536개 주소가 한 번에 묶이니, 5,000명짜리 회사도 65,000개를 그냥 쥐고 앉아 있는 식.

그래서 1990년대에 CIDR(classless inter-domain routing)이 도입됩니다. 주소를 a.b.c.d/x처럼 쓰는데, x가 네트워크 접두사 길이예요. 예를 들어 203.0.113.0/24는 앞 24비트가 네트워크, 뒤 8비트가 호스트라는 뜻이라, 256개 주소를 가리켜요. 클래스의 8/16/24 칸막이를 떼고, 어디서든 자유롭게 자를 수 있게 한 거죠.

이걸 사람이 보기 편하게 풀어 쓴 게 서브넷 마스크(subnet mask)예요. /24는 마스크 255.255.255.0과 같아요. AND 연산을 걸면 네트워크 주소가 떨어지죠. 

IP 주소:        203.0.113.42
바이너리:       11001011 00000000 01110001 00101010
서브넷 마스크:  11111111 11111111 11111111 00000000  (= /24)
AND 결과:       11001011 00000000 01110001 00000000
네트워크:       203.0.113.0/24
호스트 부분:                              00101010 (= 42)

최장 접두사 일치

라우터의 포워딩 테이블에는 여러 CIDR 항목이 들어가는데, 한 패킷의 목적지 주소가 여러 항목에 동시에 매치될 수 있어요. 그때 라우터는 가장 긴 접두사를 가진 항목을 고릅니다. 우편으로 치면 "서울특별시"보다 "서울특별시 강남구"가 더 구체적이니 후자에 적힌 분류함을 쓰는 격이죠. 

포워딩 테이블 예시:
  203.0.113.0/24    -> 출력 포트 2
  203.0.113.128/25  -> 출력 포트 3
  0.0.0.0/0         -> 출력 포트 1   (디폴트 라우트)

도착 패킷 목적지: 203.0.113.200
  매치: /24 (예), /25 (예), /0 (예)
  최장 접두사 = /25
  -> 출력 포트 3 으로 포워딩

분할과 재조립

2계층 링크마다 MTU(maximum transmission unit)가 정해져 있어요. 이더넷은 보통 1500바이트. 그런데 IP 패킷이 이 MTU보다 크면? IPv4는 라우터가 그 패킷을 작은 조각으로 분할(fragmentation)해서 보내고, 최종 수신 호스트가 다시 재조립(reassembly)해요. 이때 헤더의 Identification, Flags(MF=more fragments), Fragment Offset 필드가 활약합니다. 같은 Identification을 가진 조각들끼리 묶고, Offset 순서대로 이어 붙여 원본을 복원해요.

주의

IPv4의 라우터 분할은 라우터에 부담을 주고, 한 조각만 잃어도 전체가 무용지물이 되는 등 문제가 많아요. 그래서 IPv6는 라우터의 분할을 아예 금지하고, 분할이 필요하면 송신 호스트가 직접 작게 쪼개도록 정책을 바꿉니다(다음 절에서).

DHCP — 주소를 자동으로 받기

호스트가 막 부팅했을 때 자기 IP가 뭔지 어떻게 알까요? 수동으로 입력해도 되지만, 보통은 DHCP(dynamic host configuration protocol)로 자동 할당받아요. 호스트가 브로드캐스트로 "주소 주세요" 하면, DHCP 서버가 IP 주소·서브넷 마스크·기본 게이트웨이·DNS 서버 정보를 한 묶음으로 던져줍니다. 카페 와이파이에 접속하자마자 인터넷이 되는 게 이 친구 덕분이에요.

4.4 IPv6와 NAT

IPv4 주소 32비트는 약 43억 개. 모바일 폭증과 IoT 시대에 진작에 모자랐어요. 해결책은 두 갈래로 갔습니다. (1) 주소 공간 자체를 늘리는 IPv6, (2) 한 공인 주소 뒤에 사설망을 잔뜩 숨기는 NAT.

IPv6 — 정공법

IPv6 주소는 128비트입니다. 산술적으로 2^128개. 지구 표면 1제곱밀리미터마다 수억 개를 깔아도 남아요. 표기는 16비트씩 8조각을 콜론으로 잇고, 0이 연속되면 ::로 한 번 줄여요. 예: 2001:db8::1.

헤더도 갈아엎었어요. IPv4 헤더의 잡다한 필드를 정리해 40바이트 고정 길이로 만들었고, 라우터가 빠르게 처리하도록 다음을 빼거나 옮겼습니다.

IPv4 vs IPv6 한눈 비교

항목 IPv4 IPv6
주소 길이 32비트 128비트
헤더 길이 20바이트(가변, 옵션 시 더) 40바이트 고정
분할 송신지 또는 라우터 송신지만
헤더 체크섬 있음 없음
옵션 표현 헤더 안의 가변 옵션 확장 헤더 체인
주소 자동 설정 DHCP 위주 SLAAC 또는 DHCPv6
브로드캐스트 있음 없음 (멀티캐스트로 대체)

IPv6 전환은 한 번에 스위치를 바꿀 수 있는 일이 아니어서, 듀얼 스택(host가 v4/v6 둘 다 사용), 터널링(v6 패킷을 v4 안에 캡슐화) 같은 점진 전략을 씁니다. 그러는 동안 IPv4를 더 길게 살리는 임시 처방이 NAT예요.

NAT — 한 주소 뒤에 동네를 숨기기

가정용 공유기는 통신사에서 공인 IP 하나만 받고, 그 안의 휴대폰·노트북·TV에는 사설(private) IP를 따로 줘요. 사설 대역은 RFC1918에서 정한 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 등이에요. 외부에서는 안 보이는 주소죠.

그렇다면 안쪽 기기가 외부 인터넷으로 패킷을 보낼 땐? 공유기가 패킷의 출발지 IP를 자기 공인 IP로 바꿔치고, 출발지 포트도 적당히 다른 값으로 바꿉니다. 답이 돌아오면 미리 적어둔 변환표를 보고 원래 내부 기기에게 되돌려줘요. 이게 NAT(network address translation)의 핵심이에요.

내부 LAN 192.168.1.0/24 공인 인터넷 +-------------------+ +-----------------+ | PC 192.168.1.10 | | | | src:1.10:5500 | NAT 라우터 | 웹서버 | | dst:서버:80 | (공인 203.0.113.5) | 203.0.113.99 | +---------+---------+ +--------+--------+ | (1) 내부 -> 외부 | | src=192.168.1.10:5500 | | dst=203.0.113.99:80 | +---->[ NAT 출발지 변환 ]---------------->+ src=203.0.113.5:40021 | dst=203.0.113.99:80 | | (2) 외부 -> 내부 (응답) | +<-----[ NAT 도착지 역변환 ]<-------------+ | src=203.0.113.99:80 | dst=203.0.113.5:40021 변환표 룩업 v (실제 PC: 192.168.1.10:5500)

공유기의 NAT 변환표는 보통 이렇게 생겼어요. 

NAT translation table
+---------------------+---------------------+---------------------+
| WAN side            | LAN side            | 만료 시각            |
+---------------------+---------------------+---------------------+
| 203.0.113.5:40021   | 192.168.1.10:5500   | T+120s              |
| 203.0.113.5:40022   | 192.168.1.11:55310  | T+90s               |
| 203.0.113.5:40023   | 192.168.1.10:6010   | T+60s               |
+---------------------+---------------------+---------------------+

포트 번호로 흐름을 구분하기 때문에 정식으로는 NAPT(network address port translation)라고 불러요. 가정용 공유기가 다 이 방식이에요.

NAT 트래버설 문제

NAT는 안에서 밖으로 시작한 통신은 잘 알아채는데, 밖에서 안으로 새로 거는 통신은 누구에게 줘야 할지 모릅니다. 그래서 P2P 통신, 서버를 집에 두는 일, 화상 통화 등이 까다로워져요. 해법으로 UPnP/NAT-PMP(공유기에 포트 매핑 요청), STUN/TURN/ICE(공인 IP·포트 발견 후 양쪽이 동시에 펀치홀), 응용 계층 릴레이 같은 걸 써요. 쉽게 말해, 종단간 원칙이 깨진 자리를 메우는 우회로들이죠.

4.5 일반화된 포워딩과 SDN

지금까지 본 IP 포워딩은 "목적지 IP를 보고 출력 포트를 정한다"는 단일 규칙이었어요. 그런데 현실의 네트워크는 더 복잡한 결정을 자주 합니다. 출발지 주소로 트래픽을 분리하고, TCP 포트로 우선순위를 다르게 주고, 특정 프로토콜은 차단하고, 어떤 트래픽은 다른 라우터로 우회시키고….

그래서 등장한 추상이 일반화된 포워딩(generalized forwarding)의 매치-액션(match-action) 모델이에요. 한마디로 "들어온 패킷의 어떤 필드들이 이 패턴에 매치되면, 이 동작을 해라." 

flow_table = [
  match {
    in_port = 1,
    eth_type = 0x0800,            # IPv4
    ip_src = 192.168.1.0/24,
    ip_dst = 10.0.0.0/8,
    ip_proto = 6,                 # TCP
    tcp_dst = 80
  } -> action: forward(out_port = 3),

  match {
    in_port = *,
    eth_type = 0x0800,
    ip_dst = 10.0.0.5/32
  } -> action: drop,

  match {
    eth_type = 0x0806            # ARP
  } -> action: send_to_controller,

  match { /* 그 외 모두 */ } -> action: forward(out_port = 1)
]

이런 추상의 대표적 구현이 OpenFlow예요. OpenFlow는 패킷의 다양한 헤더 필드(입력 포트, 이더넷 MAC, IP 주소, IP 프로토콜, TCP/UDP 포트 등)를 키로 삼아 여러 테이블을 통과시키며 매치/액션을 적용합니다. IP 라우터가 "목적지 IP만 봐서 출력 포트 결정"의 한 가지 매치-액션이라면, OpenFlow는 그 일반화 버전이에요.

SDN — 제어를 분리해 외부로 빼기

매치-액션 테이블을 누가 채울까요? 전통 라우터에선 라우터마다 박힌 라우팅 프로세서가 OSPF/BGP 같은 분산 알고리즘을 돌려서 채웠어요. SDN(software-defined networking)은 이 일을 라우터 밖의 중앙 컨트롤러로 옮깁니다.

+-----------------------------+ | SDN 컨트롤러 | | (네트워크 OS, 앱 호스팅) | +---+----------+----------+---+ | | | control | (예: OpenFlow API) | channel | | | v v v +----------+ +----------+ +----------+ | 스위치 1 | | 스위치 2 | | 스위치 3 | |(매치- | |(매치- | |(매치- | | 액션 표)| | 액션 표)| | 액션 표)| +----------+ +----------+ +----------+ | | | <----+-------------+-------------+----> 데이터 평면 (호스트들 사이의 패킷 흐름)

장점은 "전체를 한눈에 보는 두뇌"가 생긴다는 점이에요. 분산 라우팅 프로토콜의 수렴 시간을 줄이고, 네트워크 정책(보안·QoS·트래픽 엔지니어링)을 코드로 작성할 수 있고, 새 기능을 라우터 펌웨어 업그레이드 없이 컨트롤러 앱으로 빠르게 배포할 수 있어요. 데이터센터 운영자들이 SDN을 일찍 받아들인 이유죠.

관점 정리

전통 IP 포워딩 = "목적지 IP 한 필드 매치 → 출력 포트 한 액션"의 하드코딩된 매치-액션. 일반화된 포워딩 = "여러 필드 임의 매치 → 임의 액션 시퀀스"로 확장. SDN = 그 매치-액션 테이블을 채우는 두뇌를 라우터 밖에 두는 아키텍처. 셋이 서로 다른 차원의 이야기예요.

4.6 미들박스

고전 인터넷의 설계 철학은 종단간(end-to-end) 원칙이었어요. 똑똑함은 양 끝의 호스트에 두고, 가운데 코어는 단순한 패킷 전달자로만 두자는 약속이죠. 그런데 현실에서는 코어가 그렇게 단순하기만 하지 않아요. 패킷이 흘러가는 길목에 미들박스(middlebox)라 부르는 친구들이 잔뜩 서 있습니다.

이들이 종단간 원칙과 부딪히는 이유가 뭘까요. 원칙대로면 IP 코어는 "패킷의 헤더만 보고 다음 홉으로" 보내야 합니다. 그런데 미들박스는 헤더는 물론 페이로드까지 들여다보거나, 패킷을 변형하거나, 흐름을 막거나, 새 흐름을 만들기도 해요.

미들박스의 부작용

새 프로토콜 도입을 어렵게 만듭니다. 예: 미들박스가 "TCP 옵션은 우리가 아는 것만 통과"라고 박혀 있으면, 새로운 TCP 옵션을 쓰려는 시도가 길에서 막혀요. 디버깅이 까다로워져요. 양 끝에서 보면 멀쩡한데 가운데에서 변형되거나 드롭되거든요. 보안 가정을 흔듭니다. 종단 암호화가 깨지거나, 사용자가 기대한 적 없는 검사를 받기도 해요.

그래도 미들박스를 없앨 수는 없어요. 보안·확장성·운영 편의에서 실질적 이득이 너무 크거든요. 그래서 최근 흐름은 두 갈래입니다.

  1. 종단 측이 미들박스를 의식해 설계: 예를 들어 QUIC(3장 끄트머리에서 잠깐 봤던 친구)은 트랜스포트 헤더 대부분을 암호화해, 가운데서 함부로 만지지 못하도록 합니다.
  2. 미들박스를 SDN/NFV로 통합: 미들박스 기능을 전용 박스가 아닌 가상 기능(VNF)으로 풀어, 컨트롤러가 일관되게 관리하도록 만들어요. 4.5의 일반화된 포워딩과 자연스럽게 맞물리는 방향이에요.

결국 핵심은, 인터넷의 가운데는 더 이상 "단순한 전달자"가 아니라 "조건부로 똑똑한 전달자들의 군집"이라는 거예요. 데이터 평면을 이해한다는 건 IP 헤더 비트뿐 아니라 이 친구들의 행동까지 함께 그릴 수 있다는 뜻입니다.

한 줄 요약