CSAPP 11장 공부 기록 1편

CSAPP 11장을 처음 읽을 때 가장 먼저 막힌 지점은 소켓 코드가 아니었다. Ethernet, bridge, router, LAN, WAN, frame, packet 같은 말이 현실 장비와 바로 연결되지 않았다. 이 글은 그 혼동을 풀기 위해, 데이터가 내 컴퓨터 밖에서 어떤 이름과 포장으로 이동하는지 정리한 1편이다.

이번 글에서 다루는 것

클라이언트-서버 트랜잭션이 정확히 무엇인지
현실 장비 기준으로 Ethernet, hub, switch, bridge, router, LAN, WAN을 구분하는 법
데이터가 TCP/IP 4계층을 내려가며 어떤 헤더를 얻는지
frame, packet, segment가 왜 같은 듯 다른 말인지
IP는 최종 주소이고, MAC은 이번 구간 주소라는 감각
라우터가 next hop을 고르고, TTL이 줄고, ARP가 MAC 주소를 찾는 이유
IPv4, IPv6, endian, DNS, Cloudflare, NAT까지 주소 문제가 어떻게 확장되는지

2편에서는 이 데이터가 내 컴퓨터 안에서 write(sockfd, buf, n) 이후 커널, 버퍼, NIC, DMA를 거쳐 나가는 흐름을 다룬다. 3편에서는 HTTP, CGI, Tiny Web Server 코드로 이어진다.

1. 출발점: 트랜잭션은 요청 하나의 왕복 과정이다

클라이언트-서버 모델에서 클라이언트는 서비스를 요청하는 프로세스이고, 서버는 그 요청을 처리해 응답하는 프로세스다. 여기서 중요한 점은 서버가 반드시 큰 물리 장비를 뜻하지 않는다는 것이다. 같은 노트북 안에서도 클라이언트 프로세스와 서버 프로세스가 동시에 돌 수 있다.

CSAPP 11장에서 말하는 트랜잭션(transaction)은 데이터베이스 트랜잭션처럼 원자성, 롤백을 말하는 것이 아니다. 여기서는 클라이언트와 서버가 한 번의 목적을 달성하기 위해 주고받는 요청, 처리, 응답, 완료의 전체 흐름을 말한다.

1. 요청: 브라우저가 서버에 GET /home.html HTTP/1.0 같은 요청을 보낸다.

2. 처리: 서버가 요청을 읽고, 파일을 찾거나 CGI 프로그램을 실행한다.

3. 응답: 서버가 상태 줄, 헤더, 본문을 클라이언트에게 돌려준다.

4. 완료: 클라이언트가 응답을 읽고 화면에 렌더링하거나 다음 요청으로 넘어간다.

주의할 점은 트랜잭션과 TCP 연결이 같은 말이 아니라는 것이다. HTTP keep-alive에서는 하나의 TCP 연결 위에서 여러 요청/응답 트랜잭션이 일어날 수 있다.

2. 현실 장비로 다시 보기: hub, switch, router는 같은 상자가 아니다

공부하면서 가장 도움이 된 질문은 이것이었다. 집 공유기에는 WAN 포트가 있고 나머지는 LAN 포트라고 써 있다. 어떤 스위치는 포트 이름이 따로 없는데 아무 데나 꽂아도 알아서 된다. 그럼 책에서 말하는 hub, bridge, router는 현실에서 무엇에 가까운가?

정답은 장비 이름보다 어떤 주소를 보고, 어느 범위까지 전달하는가로 나누어야 한다.

개념	현실에서 떠올릴 장비	판단 기준	비유
Hub	옛날 더미 허브	주소를 거의 보지 않고 모든 포트에 뿌린다.	확성기
Bridge/Switch	일반적인 유선 스위치	MAC 주소를 학습하고 같은 LAN 안에서 필요한 포트로만 보낸다.	동네 교차로
Router	가정용 공유기의 라우터 기능, 회사/통신사 라우터	IP 주소와 라우팅 테이블을 보고 다른 네트워크로 넘긴다.	지역 물류센터

더미 허브가 헷갈렸던 이유

더미 허브는 들어온 비트를 다른 포트로 거의 그대로 복사해 뿌리는 장비에 가깝다. 누가 누구에게 보내는지 똑똑하게 나누지 못한다. 그래서 같은 세그먼트의 모든 장비가 같이 듣고, 대역폭도 나눠 쓴다. 오늘날 흔히 보는 스위치는 MAC 주소를 학습하므로 책의 bridge에 더 가깝게 이해하는 편이 좋다.

3. LAN과 WAN: 장비 이름이 아니라 범위와 역할의 말이다

LAN(Local Area Network)은 집, 건물, 캠퍼스처럼 상대적으로 좁은 범위에서 구성되는 네트워크다. WAN(Wide Area Network)은 도시, 국가, 대륙처럼 더 넓은 범위의 네트워크다.

가정용 공유기 뒷면을 보면 WAN 포트와 LAN 포트가 나뉘어 있다. 물리적으로는 같은 랜선처럼 보여도 의미는 다르다. LAN 포트는 집 안 장치들을 묶는 내부망 쪽이고, WAN 포트는 통신사 장비를 거쳐 더 큰 외부망으로 나가는 입구다.

내 노트북
↓ LAN, Wi-Fi, Ethernet
집 공유기: LAN 쪽과 WAN 쪽을 이어 주는 작은 라우터
↓ WAN 포트, 통신사망
ISP 라우터와 더 큰 인터넷망

따라서 "WAN은 정해져 있고 나머지가 LAN인가?"라는 감각은 가정용 공유기 기준에서는 꽤 맞다. 다만 더 정확하게는, WAN은 더 큰 외부 네트워크 쪽으로 나가는 연결이고 LAN은 내가 관리하는 내부 네트워크 쪽이다.

4. 비트 뭉치의 정체: frame, packet, segment

호스트들이 결국 비트를 주고받는다는 말은 맞다. 하지만 선로에 의미 없는 0과 1이 아무렇게나 흘러가는 것은 아니다. 데이터는 계층마다 자기 헤더를 붙인 덩어리로 포장된다.

이름	계층	핵심 주소	무엇을 해결하는가
Segment	Transport	Port, Sequence Number	어느 프로세스에게 줄지, TCP라면 순서와 신뢰성을 어떻게 관리할지
Packet	Internet	Source IP, Destination IP	최종 호스트까지 어느 네트워크 방향으로 갈지
Frame	Link	Source MAC, Destination MAC	이번 물리 구간에서 다음 장비까지 어떻게 보낼지

포장 구조 예시

[ Ethernet Header: dst MAC, src MAC, type ]
  [ IP Header: src IP, dst IP, TTL, protocol ]
    [ TCP Header: src port, dst port, seq, ack, flags ]
      [ Payload: "GET /home.html HTTP/1.0\r\n..." ]
  [ Ethernet FCS/CRC ]

여기서 수신자는 바깥쪽부터 확인한다. NIC는 MAC 주소를 보고 자기 프레임인지 판단하고, IP 계층은 목적지 IP를 확인하고, TCP/UDP 계층은 포트 번호를 보고 어떤 소켓으로 줄지 결정한다.

5. TCP/IP 4계층과 프로토콜 소프트웨어

처음에는 "IP 주소에 목적지가 다 들어 있는데 왜 또 Ethernet header가 필요하지?"라는 질문이 생겼다. 이 질문은 계층을 나누어 보면 풀린다. IP는 최종 목적지를 담는 논리 주소이고, Ethernet은 현재 링크에서 다음 장비까지 실제로 보내기 위한 물리 구간 주소를 담는다.

이 포장을 응용 프로그램이 직접 하지 않는다. 브라우저나 Tiny 서버는 보통 소켓에 데이터를 쓰고, 운영체제 커널 안의 프로토콜 소프트웨어가 TCP/IP 규칙에 맞게 데이터를 포장한다.

계층	예시	붙이는 정보	읽는 사람
Application	HTTP	GET, URI, header	웹 서버, 브라우저
Transport	TCP/UDP	port, sequence, checksum	커널의 TCP/UDP 계층
Internet	IP	src/dst IP, TTL, protocol	라우터와 호스트의 IP 계층
Link	Ethernet, Wi-Fi	src/dst MAC, EtherType, FCS	NIC, switch, 같은 링크의 다음 장비

핵심 비유

IP header는 상자 안쪽에 붙은 최종 주소 송장이다. Ethernet header는 이번 구간에서 어떤 트럭에 실을지 적은 운송장이다. 최종 주소가 있어도, 이번 구간 트럭 번호판이 없으면 물류센터 밖으로 나갈 수 없다.

5-1. 1000바이트 데이터는 실제로 어떻게 포장되는가

위 표만 보면 "header가 붙는다"는 말이 아직 추상적이다. 그래서 우리가 공부할 때 썼던 숫자 예시를 그대로 한 번 따라가 보자. 응용 프로그램은 1000바이트만 보낸다고 생각하지만, 네트워크로 나가기 전에는 계층마다 주소와 제어 정보가 붙어서 더 큰 덩어리가 된다.

예시 조건

내 PC 내부 IP = 172.21.100.89
내 PC port    = 50001
서버 IP       = 93.184.216.34
서버 port     = 443
보낼 데이터   = 1000 byte

캡슐화 진행도

[User Process]
write(sockfd, "1000B data", 1000)
        |
        v

[Kernel TCP/IP Stack]
        |
        | TCP header 20B 추가
        v
[TCP Segment]
+----------------+----------------+
| TCP Header 20B | Data 1000B     |
| src port 50001 |                |
| dst port 443   |                |
+----------------+----------------+
총 1020B
        |
        | IP header 20B 추가
        v
[IP Packet]
+--------------+----------------+----------------+
| IP Header 20B| TCP Header 20B | Data 1000B     |
| src IP       | src port 50001 |                |
| 172.21.100.89| dst port 443   |                |
| dst IP       |                |                |
| 93.184.216.34|                |                |
+--------------+----------------+----------------+
총 1040B
        |
        | Ethernet header 14B + FCS 4B 추가
        v
[Ethernet Frame]
+---------------------+--------------+----------------+--------------+--------+
| Ethernet Header 14B | IP Header 20B| TCP Header 20B | Data 1000B   | FCS 4B |
| src MAC = 내 PC MAC | src IP       | src port 50001 |              | CRC    |
| dst MAC = 라우터 MAC| 172.21.100.89| dst port 443   |              |        |
|                     | dst IP       |                |              |        |
|                     | 93.184.216.34|                |              |        |
+---------------------+--------------+----------------+--------------+--------+
총 1058B
        |
        v
[네트워크 어댑터]
랜카드 / Wi-Fi 칩이 실제 비트 신호로 내보낸다.

이 예시에서 가장 중요한 부분은 IP packet 안의 목적지 IP는 최종 서버를 가리키지만, Ethernet frame의 목적지 MAC은 일단 우리 집 라우터를 가리킨다는 점이다. 서버가 멀리 있으면 내 PC의 랜카드는 서버 MAC을 알 수도 없고, 같은 링크에 있지도 않다. 그래서 "최종 목적지는 93.184.216.34인데, 이번 구간에서는 라우터 MAC에게 넘긴다"는 두 주소 체계가 동시에 존재한다.

택배로 다시 말하면, IP header는 상자 안쪽에 적힌 최종 배송지이고, Ethernet header는 이번 차례에 이 상자를 실어 갈 트럭 번호다. 라우터에 도착하면 이 트럭 번호는 버려지고, 다음 구간용 트럭 번호로 새로 붙는다.

단순화한 계산이라는 점

위 예시는 흐름을 보기 위한 최소 형태다. 실제 TCP header나 IP header에는 옵션이 붙을 수 있고, HTTPS라면 TCP 안쪽의 payload에는 TLS record가 들어간다. 또한 Ethernet FCS는 보통 NIC 하드웨어가 마지막에 붙이고 검사하므로, 운영체제 버퍼에서 보이는 바이트 수와 선로 위의 바이트 수는 관찰 위치에 따라 다르게 보일 수 있다. 그래도 공부할 때는 이 예시처럼 "Data -> TCP segment -> IP packet -> Ethernet frame"으로 커지는 그림을 먼저 잡는 것이 가장 중요하다.

6. 라우터를 지나면 IP는 유지되고 MAC은 바뀐다

라우터는 들어온 frame의 바깥 Ethernet header를 벗긴다. 그 안쪽의 IP packet을 보고 목적지 IP를 확인한다. 라우팅 테이블을 통해 다음으로 보낼 네트워크나 next hop을 고른 뒤, 새 Ethernet header를 붙여 내보낸다.

라우터 R을 지날 때의 변화

[라우터 R에 들어오기 전: LAN1 구간]
Ethernet header:
  src MAC = 호스트 A의 MAC
  dst MAC = R의 LAN1 쪽 MAC

IP header:
  src IP = 128.2.194.242
  dst IP = 208.216.181.15
  TTL    = 64

        라우터 R이 Ethernet header를 벗김
        IP header의 dst IP를 보고 next hop 결정
        TTL을 1 감소시킴
        새 Ethernet header를 붙임

[라우터 R에서 나간 후: LAN2 또는 다음 링크 구간]
Ethernet header:
  src MAC = R의 나가는 쪽 인터페이스 MAC
  dst MAC = next hop 또는 서버 B의 MAC

IP header:
  src IP = 128.2.194.242     유지
  dst IP = 208.216.181.15    유지
  TTL    = 63                라우터 1개 통과로 감소

여기서 가장 중요한 문장은 이것이다. IP는 끝점 주소이고, MAC은 홉마다 바뀌는 구간 주소다. 상자 안쪽의 최종 주소표는 그대로 두고, 물류센터를 지날 때마다 이번 구간을 달릴 트럭 번호만 바꾸는 셈이다.

TTL(Time To Live)은 packet이 라우터를 지날 때마다 1씩 줄어든다. 경로가 꼬여 packet이 인터넷 안에서 영원히 도는 일을 막기 위한 수명 카운터다. 0이 되면 라우터는 packet을 폐기한다.

7. 라우팅 테이블은 모든 방 번호를 외우지 않는다

라우터가 목적지 IP를 보고 다음 경로를 고른다고 하면, 처음에는 이런 의문이 생긴다. 전 세계 모든 컴퓨터 주소를 다 외우는 것은 불가능하지 않은가?

맞다. 그래서 라우터는 보통 개별 호스트가 아니라 네트워크 prefix 단위로 경로를 가진다. 물류센터가 모든 집의 방 번호를 외우지 않고, "경기도 방향은 A 물류센터", "미국 방향은 B 게이트웨이"처럼 큰 방향만 잡는 것과 비슷하다.

목적지 128.2.194.242: 앞 16비트가 128.2면 어느 방향으로 보낼지 판단한다.

라우팅 테이블: 모든 host 주소가 아니라 prefix와 next hop의 매핑을 가진다.

최종 LAN: 목적지 네트워크에 도착한 뒤에야 실제 host MAC으로 frame을 보낸다.

이 관점으로 보면 주소는 "경기도 성남시 분당구..."처럼 계층적으로 좁혀지는 지도에 가깝다. 중간 라우터는 전체 상세 주소를 몰라도 다음 물류센터만 잘 고르면 된다.

8. ARP: next hop IP를 실제 MAC으로 바꾸는 동네 주소록

IP 계층이 라우팅 테이블로 next hop을 정해도 아직 하나가 남는다. Ethernet frame을 만들려면 목적지 MAC 주소가 필요하다. 그런데 라우팅 결과는 보통 "다음 라우터의 IP"다. 이 IP에 해당하는 MAC을 알아내는 과정이 필요하다.

그 역할을 하는 대표적인 메커니즘이 ARP(Address Resolution Protocol)다. 같은 LAN 안에서 "이 IP를 쓰는 장비의 MAC 주소가 뭐야?"라고 묻고, 응답을 받아 ARP cache에 저장한다.

IP와 MAC의 차이를 다시 잡기

IP는 택배 상자에 적힌 최종 주소다. MAC은 지금 내 앞 도로에서 누구에게 넘길지 정하는 장비 번호다. next hop을 골랐다는 것은 "다음 물류센터를 정했다"는 뜻이고, ARP는 "그 물류센터 트럭 번호판을 알아내는 과정"에 가깝다.

9. IPv4와 IPv6: 주소 크기부터 다르다

IPv4 주소는 32비트 정수 하나다. 사람이 읽기 편하게 8비트씩 끊어 128.2.194.242처럼 점-십진수 표기법으로 쓴다. 가능한 주소 수는 약 42.9억 개다.

이 숫자는 처음에는 커 보였지만, 오늘날의 PC, 스마트폰, 서버, IoT 장비 수를 생각하면 부족하다. 그래서 IPv6는 128비트 주소를 사용한다. 주소 공간이 훨씬 커서 NAT 없이도 각 장비가 직접 공인 주소를 가질 수 있는 방향을 목표로 한다.

구분	IPv4	IPv6
크기	32비트, 4바이트	128비트, 16바이트
표기	`a.b.c.d`	16비트 단위 8개를 `:`로 연결
예시	`128.2.194.242`	`2001:db8:85a3::8a2e:370:7334`
C 구조체	`struct in_addr`	`struct in6_addr`

CSAPP에서 getaddrinfo를 강조하는 이유도 여기에 있다. 코드를 IPv4에만 묶어두지 않고, IPv4와 IPv6를 모두 다룰 수 있는 프로토콜 독립적 인터페이스를 쓰기 위해서다.

10. Endian: 같은 숫자도 메모리에 놓는 순서가 다르다

네트워크 프로그래밍에서 갑자기 htons, htonl 같은 함수가 등장하는 이유는 바이트 순서 때문이다. 여러 바이트로 이루어진 값을 메모리에 놓을 때, 어떤 바이트를 낮은 주소에 먼저 둘지 컴퓨터마다 다를 수 있다.

네트워크는 표준 바이트 순서로 big-endian을 사용한다. 반면 우리가 흔히 쓰는 x86 계열은 little-endian이다. 그래서 포트 번호나 IPv4 주소처럼 네트워크 헤더에 들어가는 멀티바이트 값은 변환해서 넣어야 한다.

포트 80 예시

port 80 = 0x0050

little-endian 메모리에 그냥 저장:
  [0x50, 0x00]

network byte order(big-endian)로 보내야 하는 모습:
  [0x00, 0x50]

htons(80)을 쓰지 않으면 상대는 0x5000 = 20480으로 해석할 수 있다.

함수	의미	주 용도
`htons`	host to network short	16비트 포트 번호
`htonl`	host to network long	32비트 IPv4 주소
`ntohs`	network to host short	수신한 포트 번호 해석
`ntohl`	network to host long	수신한 IPv4 주소 해석

11. inet_pton, inet_ntop: 문자열 주소와 이진 주소 사이의 번역

사람은 128.2.194.242처럼 문자열 IP 주소를 읽는다. 커널과 네트워크 헤더는 32비트 이진 주소를 쓴다. 이 둘을 바꾸는 함수가 inet_pton과 inet_ntop이다.

#include <arpa/inet.h>

int inet_pton(AF_INET, const char *src, void *dst);
const char *inet_ntop(AF_INET, const void *src, char *dst, socklen_t size);

pton은 presentation to network다. 사람이 보는 문자열을 네트워크가 쓰는 이진 주소로 바꾼다. ntop은 network to presentation이다. 이진 주소를 사람이 보는 문자열로 다시 바꾼다.

다만 실제 소켓 코드에서는 더 상위 함수인 getaddrinfo를 많이 쓴다. 도메인 이름 해석, IPv4/IPv6 후보 주소 생성, 소켓 주소 구조체 준비까지 한 번에 처리하기 때문이다.

12. DNS: 목적지 IP를 모를 때 먼저 찾는 주소록

목적지 IP를 이미 알고 있다면 DNS를 거칠 필요가 없다. 하지만 우리는 보통 숫자 IP가 아니라 www.example.com 같은 도메인 이름을 입력한다. 이때 DNS가 이름을 IP 주소로 바꿔 준다.

1. 브라우저가 www.example.net에 접속하려고 한다.

2. OS의 resolver가 캐시와 /etc/hosts를 확인한다.

3. recursive resolver가 root, TLD, authoritative nameserver를 따라간다.

4. authoritative nameserver가 A/AAAA record로 IP를 응답한다.

5. 브라우저가 그 IP와 port로 TCP 연결을 시작한다.

여기서 또 하나의 자연스러운 질문이 생긴다. DNS 서버의 IP는 어떻게 아는가? 일반적으로 네트워크에 연결될 때 DHCP 설정을 통해 DNS 서버 주소를 함께 받거나, 사용자가 직접 1.1.1.1, 8.8.8.8 같은 DNS 서버를 지정한다.

Cloudflare에서 도메인을 사고 DNS record를 등록하면, Cloudflare가 registrar, authoritative DNS, CDN proxy 역할을 함께 할 수 있다. 특히 proxied 상태에서는 사용자에게 origin server IP가 아니라 Cloudflare edge IP가 응답되고, Cloudflare가 뒤에서 origin으로 요청을 전달한다.

13. NAT: IPv4 43억 개 문제를 버티게 만든 주소 변환

공동 질문에서 인상 깊었던 주제는 IPv4 주소가 약 43억 개뿐인데 어떻게 아직 쓰고 있느냐였다. 핵심 답은 NAT(Network Address Translation)다.

집 안의 노트북, 스마트폰, 태블릿은 보통 192.168.x.x 같은 사설 IP를 쓴다. 바깥 인터넷으로 나갈 때 공유기는 이 사설 IP를 자기 공인 IP로 바꿔서 내보낸다. 동시에 포트 번호를 이용해 "이 응답은 집 안의 어느 기기, 어느 연결로 돌려줘야 하는지"를 기억한다.

NAT 비유

아파트 전체가 하나의 대표 주소를 쓰고, 경비실이 동호수와 방문 목적을 기록해 두는 구조와 비슷하다. 외부에서는 대표 주소만 보이지만, 경비실은 내부의 어느 집으로 응답을 돌려보낼지 알고 있다.

NAT가 실제로 바꾸는 값

집 안 노트북:
  172.21.100.89:50001

외부 서버:
  93.184.216.34:443

[공유기 통과 전]
  172.21.100.89:50001  ->  93.184.216.34:443

[공유기 NAT 후]
  203.0.113.10:62001  ->  93.184.216.34:443

NAT table:
  203.0.113.10:62001  <->  172.21.100.89:50001

여기서 203.0.113.10은 바깥 인터넷에서 보이는 집의 대표 주소라고 생각하면 된다. 응답이 203.0.113.10:62001로 돌아오면 공유기는 NAT table을 보고 "이건 집 안의 172.21.100.89:50001로 돌려줘야 한다"고 판단한다. 그래서 내부 장비가 여러 대여도 하나의 공인 IP를 나눠 쓸 수 있다.

구분	역할	헷갈리면 안 되는 점
DNS	이름을 IP 주소로 찾는다.	packet의 주소를 바꾸는 기술은 아니다.
NAT	나가는 packet의 IP/port를 바꾸고 매핑을 기억한다.	도메인 이름을 해석하는 주소록이 아니다.

14. 실제 요청 하나로 모든 포장을 합쳐 보기

마지막으로 브라우저가 Tiny 서버에 정적 파일을 요청한다고 생각해 보자.

Application:
  GET /home.html HTTP/1.0\r\n
  Host: example.com\r\n
  \r\n

Transport(TCP):
  src port = 임시 포트
  dst port = 80
  seq/ack/flags = TCP 연결 상태 관리

Internet(IP):
  src IP = 내 공인 IP 또는 NAT 이후 주소
  dst IP = DNS로 얻은 서버 IP
  TTL = 예: 64
  protocol = 6(TCP)

Link(Ethernet):
  src MAC = 내 NIC 또는 공유기 쪽 MAC
  dst MAC = next hop MAC
  EtherType = IPv4

이 구조를 잡으면 CSAPP 11장의 앞부분이 훨씬 덜 흩어진다. 네트워크는 단순히 선을 타고 비트를 보내는 장치가 아니라, 각 계층이 자기 주소 문제를 해결하며 데이터를 포장하고 전달하는 시스템이다.

이번 글에서 기억할 것

트랜잭션은 요청, 처리, 응답, 완료의 한 사이클이다.
hub는 뿌리고, switch/bridge는 MAC으로 나누고, router는 IP로 다음 네트워크를 고른다.
frame, packet, segment는 각각 링크, 인터넷, 전송 계층의 포장 단위다.
IP는 최종 목적지 주소이고, MAC은 이번 hop에서 다음 장비로 가기 위한 주소다.
프로토콜 소프트웨어는 응용 프로그램 대신 TCP/IP 규칙에 따라 헤더를 붙이고 벗긴다.
DNS는 이름을 IP로 바꾸고, NAT는 나가는 packet의 주소와 port를 바꿔 여러 내부 장비가 공인 IP를 공유하게 한다.

스스로 점검

목적지 IP가 있는데도 Ethernet header의 목적지 MAC이 필요한 이유를 설명할 수 있는가?
라우터를 하나 지날 때 IP header, TTL, Ethernet header 중 무엇이 바뀌는가?
DNS와 NAT는 둘 다 주소와 관련되지만, 정확히 무엇이 다른가?
htons(80)을 쓰지 않으면 왜 엉뚱한 포트로 해석될 수 있는가?

힌트: 1번은 "최종 주소"와 "이번 구간 주소"를 나누면 풀린다. 4번은 값이 바뀐 것이 아니라 바이트 배열을 읽는 순서가 달라진 문제다.

다음 글 예고

다음 글에서는 같은 데이터를 컴퓨터 안쪽에서 본다. 응용 프로그램이 write(sockfd, buf, n)을 호출하면 fd는 어떤 커널 객체로 이어지고, user buffer의 데이터는 왜 kernel socket buffer로 복사되며, NIC는 DMA로 무엇을 가져가는지 따라간다.

한 줄 정리

CSAPP 11장의 첫 관문은 장비 이름 암기가 아니라, 데이터가 계층별 주소 문제를 해결하며 TCP segment, IP packet, Ethernet frame으로 포장되어 이동한다는 그림을 잡는 것이다.

CSAPP 11장 공부 기록 3편:HTTP, CGI, Tiny Web Server: 요청이 코드가 되는 과정 (1)	2026.04.25
CSAPP 11장 공부 기록: 2편소켓과 커널 내부: fd에서 NIC/DMA까지 (6)	2026.04.25
컴퓨터 시스템 9장 핵심 정리 (1)	2026.04.16
[파이썬 기초 문법 총정리 #4] 실전 도구 완전 정복 — Arrays, Iterators, Modules, Dates, Math (Ch.21~25) (3)	2026.03.08
[파이썬 기초 문법 총정리 #3] 제어문과 함수 완전 정복 — if, while, for, def, lambda (Ch.16~20) (1)	2026.03.08

cedis 님의 블로그