2-1 네트워크 기초 · JUNSEOK CS study

**"URL을 치면 무슨 일이 일어나나"**의 가장 낮은 레이어. 네트워크가 무엇인지부터 시작해서, OSI 계층 · TCP/UDP · DNS까지 한 번에 이해한다. 면접에서 갑자기 튀어나와도 당황하지 않을 수 있는 수준이 목표다.

1. 네트워크란 무엇인가

1-1. 가장 단순한 정의

"둘 이상의 컴퓨터가 서로 데이터를 주고받을 수 있도록 연결된 것."

두 대의 컴퓨터를 랜선으로 직접 연결하기만 해도 그것은 이미 네트워크다. 거기에 세 번째 컴퓨터가 들어오고, 그 묶음이 다른 건물의 묶음과 연결되고, 결국 전 세계가 연결된 것이 **인터넷(Internet = Inter-Network)**이다.

1-2. 물리적 실체

네트워크는 추상적 개념처럼 들리지만, 실제로는 전기/빛/전파 신호가 물리 매체 위를 흐르는 일이다.

구리선 (Ethernet 케이블): 전기 신호로 0과 1을 표현
광섬유 (Fiber): 빛의 점멸로 0과 1을 표현. 장거리 · 대용량에 쓰임
전파 (Wi-Fi, 5G): 공기 중 전자기파로 전송

서울에서 뉴욕으로 패킷을 보내면, 실제로 해저 광케이블을 타고 간다. 인터넷은 "구름"이 아니라 물리적 선의 집합이다.

1-3. 왜 FE 개발자가 알아야 하는가

프론트엔드가 하는 거의 모든 일은 네트워크 위에서 일어난다.

페이지 로딩: HTTP 요청으로 HTML/CSS/JS를 받음
API 호출: fetch()로 서버에 데이터 요청
이미지, 폰트, 동영상 로딩
로그인, 결제, 실시간 채팅

"왜 이 페이지가 느린가?", "왜 로그인이 풀리지?", "왜 이 요청만 CORS에 막히지?" — 이 질문들에 답하려면 네트워크의 바닥을 알아야 한다.

2. 클라이언트와 서버

2-1. 역할 분리

웹의 기본 구조는 **요청(Request)과 응답(Response)**이다.

[클라이언트]  ── "뭐 주세요" ──▶  [서버]
              ◀── "여기요" ────

클라이언트(Client): 요청하는 쪽. 브라우저, 모바일 앱, 다른 서버
서버(Server): 요청을 받아 응답하는 쪽. 24시간 켜져 있고, 인터넷 어디서나 접근 가능한 위치에 있음

식당 비유가 잘 맞는다. 손님이 메뉴를 주문하고, 주방이 음식을 만들어 내준다. 손님끼리는 직접 얘기하지 않는다 — 주방을 통해 간접적으로 연결될 수는 있어도.

2-2. "서버"라는 단어의 두 가지 의미

하드웨어로서의 서버: 데이터센터에 있는 물리적 컴퓨터
소프트웨어로서의 서버: 그 컴퓨터 위에서 돌아가는, 요청을 받는 프로그램 (nginx, Node.js 앱 등)

한 대의 하드웨어 서버가 여러 개의 소프트웨어 서버를 돌린다. 이게 가능한 이유가 바로 다음에 나올 "포트" 개념이다.

2-3. P2P는 예외

요즘은 P2P (Peer-to-Peer) 구조도 있다. 클라이언트-서버 구분 없이 서로가 서로에게 데이터를 준다. 비트토렌트, WebRTC가 그렇다. 하지만 웹의 99%는 클라이언트-서버 모델이다.

3. IP 주소 · 포트 · URL — 목적지를 찾아가는 법

3-1. IP 주소 — "어느 컴퓨터"

인터넷에 연결된 모든 컴퓨터는 IP 주소를 가진다. 우편 주소처럼, 패킷이 도착할 정확한 목적지를 식별한다.

142.250.204.46    ← 구글의 IP 중 하나 (IPv4)

이 숫자 하나로 지구상 수십억 대 중 하나의 컴퓨터가 특정된다.

3-2. 포트 — "그 컴퓨터의 어느 프로그램"

한 컴퓨터 위에는 여러 프로그램이 돌 수 있다. 웹 서버, SSH 서버, 메일 서버, 데이터베이스... 이 중 어느 프로그램에 데이터를 전달할지 구분하는 숫자가 **포트(Port)**다. 0~65535 범위.

142.250.204.46 : 443
  ↑              ↑
  IP 주소        포트 (HTTPS)

비유: IP가 아파트 주소라면, 포트는 호수다. "101동 502호" = IP:포트.

알아둬야 할 포트 번호

포트	프로토콜	용도
80	HTTP	일반 웹
443	HTTPS	보안 웹
22	SSH	원격 접속
25, 587	SMTP	메일 발송
53	DNS	이름 ↔ IP 변환
3000, 5173, 8080	(임의)	로컬 개발 서버로 흔히 씀

브라우저는 http://...면 기본 80, https://...면 기본 443을 쓴다. 그래서 URL에 포트를 안 써도 된다.

3-3. URL 해부

https://api.example.com:443/users/1?active=true#section
└─┬─┘   └─────┬─────┘ └┬┘└──┬──┘└────┬────┘ └──┬──┘
 스킴     호스트      포트  경로      쿼리     프래그먼트
(프로토콜)              (생략 가능)           (서버 전송 X)

스킴(Scheme): 어떤 프로토콜로 통신할지 (http, https, ws, ftp, file, mailto)
호스트(Host): 도메인 또는 IP 주소
포트: 스킴의 기본값과 다를 때만 명시
경로(Path): 그 서버 안에서의 리소스 위치
쿼리(Query): ?key=value&key2=value2 형태의 추가 파라미터
프래그먼트(Fragment): #something. 서버로 전송되지 않음, 브라우저 내부에서 페이지 내 위치 지정용

⚠️ 함정: 프래그먼트는 서버에 전송 안 됨

fetch("/api/data#section1")  // 서버는 "/api/data"만 본다

해시 라우터(/#/about)가 새로고침 시 서버에 /about이 아니라 /로 가는 이유가 여기 있다.

3-4. 도메인과 IP의 관계

사람이 142.250.204.46을 외울 순 없다. 그래서 **도메인(Domain)**이라는 이름을 쓴다: google.com. 이 이름을 실제 IP로 바꿔주는 것이 DNS다 (7장에서 다룸).

4. 패킷 — 데이터가 쪼개져서 가는 이유

4-1. 패킷이란

큰 데이터를 그대로 한 번에 보내지 않는다. 작은 조각(패킷, Packet)으로 쪼개서 각각을 독립적으로 전송한다.

원본 파일 (100MB)
      ↓ 쪼갠다
[패킷1][패킷2][패킷3]...[패킷N]   ← 각자 헤더를 붙여 따로 출발

각 패킷에는 "어디로 가는지(목적지 IP), 몇 번째인지(시퀀스 번호), 어디서 왔는지(출발지 IP)" 정보가 붙는다.

4-2. 왜 쪼개는가

오류 회복: 큰 덩어리 중 일부가 손상되면 전체를 다시 보내야 한다. 쪼개두면 손상된 조각만 재전송.
공정성: 한 통신이 네트워크를 독점하지 않고, 여러 통신이 패킷 단위로 끼어들 수 있음.
경로 유연성: 각 패킷이 서로 다른 경로로 갈 수 있음. 한 경로가 혼잡하면 다른 길로.

4-3. 재조립

수신 측은 시퀀스 번호를 보고 순서대로 재조립한다. 중간에 몇 개가 늦게 도착해도, 빠진 번호를 기다렸다가 순서대로 합친다. 이 작업을 하는 레이어가 TCP다.

5. LAN · WAN · 인터넷

LAN (Local Area Network): 집, 사무실 같은 좁은 범위. 공유기 하나에 묶인 기기들.
WAN (Wide Area Network): LAN을 넘어선 넓은 범위. 도시, 국가, 전 세계.
인터넷: 전 세계의 WAN이 연결된 거대한 네트워크.

[내 PC] ── [공유기] ── [ISP] ── [인터넷 백본] ── [구글 ISP] ── [구글 서버]
         LAN          WAN          인터넷         WAN         LAN

ISP(Internet Service Provider, KT/SKB/LG U+ 등)가 집의 LAN을 인터넷에 연결해주는 사업자다.

6. 왜 계층으로 나누는가

네트워크는 복잡하다. 전기 신호, 프레임, 패킷, 세션, 암호화, 애플리케이션 프로토콜 — 이걸 한 덩어리로 이해하는 것은 불가능하다. 그래서 역할별로 계층(Layer)을 쪼갠다. 각 계층은 위/아래 계층의 내부 구현을 몰라도 된다.

FE 개발자에게 이 추상화는 익숙하다. <Button> 컴포넌트는 div의 내부 렌더링을 몰라도 되고, fetch()는 TCP 재전송을 몰라도 된다.

6-1. OSI 7계층

이론적 모델. 외울 필요 없고 흐름으로 이해한다.

계층	이름	담당	예시
7	응용 (Application)	앱이 보는 데이터	HTTP, DNS, SMTP
6	표현 (Presentation)	인코딩, 암호화	TLS, JPEG
5	세션 (Session)	연결 세션 관리	(거의 전송 계층에 흡수됨)
4	전송 (Transport)	종단 간 신뢰성	TCP, UDP
3	네트워크 (Network)	라우팅	IP
2	데이터 링크	프레임, MAC 주소	Ethernet, Wi-Fi
1	물리	전기 신호	구리선, 광케이블

6-2. TCP/IP 4계층

현실에서 실제로 구현되는 모델. OSI를 단순화한 것.

계층	OSI 매핑	예시
응용	5-7	HTTP, DNS, TLS
전송	4	TCP, UDP
인터넷	3	IP, ICMP
네트워크 접근	1-2	Ethernet, Wi-Fi

6-3. 캡슐화 (Encapsulation)

데이터는 하위 계층으로 내려갈 때마다 헤더가 붙는다.

[HTTP 요청]                                        ← 응용 레이어
[TCP 헤더][HTTP 요청]                              ← 전송 레이어
[IP 헤더][TCP 헤더][HTTP 요청]                     ← 네트워크 레이어
[Ethernet 헤더][IP 헤더][TCP 헤더][HTTP 요청][꼬리] ← 링크 레이어

수신 측에서는 역순으로 헤더를 벗겨낸다. 이 "캡슐화" 덕분에 각 계층이 서로의 내부를 몰라도 되는 것이다.

비유: 편지를 봉투에 넣고, 봉투를 택배 상자에 넣고, 상자를 트럭에 싣는다. 받는 쪽은 트럭에서 상자를 꺼내고, 봉투를 꺼내고, 편지를 읽는다. 각 단계는 자기 층만 알면 된다.

7. IP 주소와 라우팅

7-1. IPv4와 IPv6

IPv4: 32비트. 192.168.0.1 형태. 약 43억 개 — 이미 고갈.
IPv6: 128비트. 2001:db8::1 형태. 사실상 무한.

IPv4 고갈로 **NAT (Network Address Translation)**을 쓴다. 공유기 하나가 공인 IP 1개 뒤로 수십 대의 내부 기기를 숨긴다. 그래서 집의 PC가 192.168.x.x 같은 사설 IP를 가지는 것이다.

구분	공인 IP	사설 IP
범위	인터넷 전체에서 유일	LAN 내부에서만 유일
예	`142.250.204.46`	`192.168.0.10`
용도	서버, 공유기의 외부 면	집 PC, 스마트폰

localhost와 127.0.0.1

127.0.0.1 = localhost = "내 컴퓨터 자기 자신"

로컬 개발 서버를 http://localhost:3000으로 여는 것은 내 컴퓨터의 3000번 포트에 접속한다는 뜻.

7-2. 라우팅

패킷은 목적지 IP만 들고 길을 찾아간다. 각 라우터는 "목적지가 이쪽이면 저쪽으로" 테이블을 유지하고 전달한다. 홉(hop) 단위로 이동한다.

[내 PC] → [공유기] → [ISP 라우터] → [백본 라우터 1] → ... → [구글]
                        ↑
                     각 홉마다 다음 경로 결정

traceroute google.com을 해보면 내 요청이 몇 홉을 거쳐 가는지 실제로 보인다. 보통 10~20 홉, 해외 서버는 30 홉 이상.

7-3. 게이트웨이

LAN의 기기가 외부로 나갈 때 거치는 출입구 역할의 라우터. 집의 공유기가 LAN의 게이트웨이다. 패킷의 목적지가 LAN 내부가 아니면 게이트웨이로 보낸다.

8. TCP vs UDP — 전송 계층의 두 얼굴

8-1. 비교

	TCP	UDP
연결	3-way handshake 필요	비연결
신뢰성	순서, 재전송 보장	없음
혼잡 제어	O (느려질 수 있음)	X
오버헤드	큼 (헤더 20~60B)	작음 (8B)
용도	HTTP, SSH, 파일 전송	DNS, 영상 스트림, 게임, HTTP/3

8-2. TCP: "신뢰성 있는 파이프"

데이터는 순서대로 도착
유실되면 재전송
수신자가 버거우면 송신자가 속도 늦춤 (흐름 제어)
네트워크가 혼잡하면 알아서 느려짐 (혼잡 제어)

비유: 등기 우편. 받는 사람이 도장 찍어야 완료되고, 못 받았다 하면 다시 보낸다. 대신 느리고 절차가 많다.

대가: 연결 수립에 RTT가 필요, 헤더가 크다, 재전송 대기가 생긴다.

8-3. UDP: "그냥 던진다"

연결 수립 없이 바로 전송
유실돼도 모른다
순서 섞일 수 있다

비유: 엽서. 주소 적고 그냥 우체통에 넣는다. 도착 확인 없음. 대신 빠르고 간단.

장점: 빠르고 가볍다. 실시간 영상 스트림은 한 프레임 빠진 게 낫지, 재전송 기다리는 동안 화면 멎는 게 더 나쁘다.

HTTP/3이 UDP 위에서 동작하는 이유도 여기에 있다 — "TCP의 신뢰성을 UDP 위에 앱 레이어(QUIC)에서 다시 구현"해서, TCP의 구식 혼잡 제어를 벗어났다.

8-4. RTT (Round Trip Time)

왕복 시간. 패킷이 상대까지 갔다 오는 데 걸리는 시간. TCP 연결 수립이 "1-RTT"라는 건 패킷이 한 번 왕복할 시간이 걸린다는 뜻.

같은 도시: 5~20ms
한국 ↔ 일본: 30~50ms
한국 ↔ 미국 서부: 100~150ms
한국 ↔ 유럽: 250~350ms

RTT는 빛의 속도와 지리적 거리에 묶여 있어, 아무리 최적화해도 물리적으로 줄일 수 없다. 그래서 CDN(엣지 서버)을 사용자 근처에 둔다.

9. 3-way / 4-way Handshake

9-1. 3-way Handshake (연결 수립)

클라이언트              서버
   │─────── SYN ──────→│    (연결 요청, 시퀀스 번호 x)
   │←──── SYN+ACK ─────│    (수락, 시퀀스 번호 y, ack=x+1)
   │─────── ACK ──────→│    (확정, ack=y+1)

3번의 왕복으로 양쪽이 "상대가 내 신호를 받을 수 있음"을 확인한다. 이제 데이터 전송 시작.

SYN (Synchronize): "연결 시작하자"
ACK (Acknowledge): "알았음"

9-2. 왜 3번인가

1번: 클라→서버 방향만 확인
2번: 서버가 클라의 응답 능력을 확인 못 함
3번: 양쪽 다 상대의 송수신 가능 확인
4번: 2, 3번째를 합쳐(SYN+ACK) 불필요

9-3. 4-way Handshake (연결 종료)

클라이언트              서버
   │─────── FIN ──────→│    (더 보낼 것 없음)
   │←─────── ACK ──────│    (알았음)
   │                   │    (서버 쪽 나머지 데이터 전송)
   │←─────── FIN ──────│    (서버도 종료)
   │─────── ACK ──────→│    (알았음)

양방향 종료를 독립적으로 처리한다. 한쪽이 먼저 끝나도 다른 쪽은 계속 보낼 수 있다.

9-4. `TIME_WAIT` 상태

마지막 ACK를 보낸 쪽은 잠시 (보통 2×MSL, 약 4분) TIME_WAIT 상태에 머문다. 왜?

마지막 ACK가 유실됐을 경우, 상대가 FIN을 재전송할 수 있음 → 내가 응답해야 함
같은 포트로 새 연결이 열렸을 때, 예전 연결의 지연된 패킷과 섞이는 걸 방지

MSL (Maximum Segment Lifetime): 패킷이 네트워크에서 살아 있을 수 있는 최대 시간. 표준은 2분.

서버에 TIME_WAIT이 대량으로 쌓이면 포트가 부족해 새 연결을 못 맺는 문제가 생긴다. SO_REUSEADDR, tcp_tw_reuse 등으로 튜닝.

10. 흐름 제어와 혼잡 제어

10-1. 흐름 제어 (Flow Control)

수신자 버퍼 기준. 수신자가 "지금 창이 N바이트 남았다"고 광고(Window Size). 송신자는 그 이상 안 보낸다.

비유: 접시 한 개를 닦는 속도로만 설거지통에 접시를 내준다. 쌓이면 받아낼 수 없으니까.

10-2. 혼잡 제어 (Congestion Control)

네트워크 전체 기준. 손실이 감지되면 "네트워크가 혼잡하다"고 판단하고 속도를 줄인다.

Slow Start: 시작은 작게, 매 RTT마다 2배로 올림
Congestion Avoidance: 어느 임계점(threshold) 이후 1씩 증가
Fast Retransmit / Fast Recovery: 손실 감지 시 빠른 복구

AIMD (Additive Increase Multiplicative Decrease)

잘 되면 1씩 증가 (더하기)
손실이 나면 반으로 뚝 떨어뜨림 (곱하기)

이 패턴 덕분에 여러 TCP 연결이 있어도 자동으로 대역폭이 공평하게 분배된다.

10-3. 흐름 vs 혼잡

	흐름 제어	혼잡 제어
대상	종단 (end-to-end)	네트워크 전체
트리거	수신자 버퍼	손실 감지
광고 방식	Window Size	암묵적 (손실로 추론)

11. DNS — 이름을 IP로 바꾸는 인터넷 전화번호부

11-1. DNS는 무엇인가

이름 → IP 주소 변환 서비스. google.com → 142.250.204.46.

google.com을 직접 외워 치는 사람은 없다. 하지만 컴퓨터는 IP로만 통신할 수 있다. 이 갭을 메우는 게 DNS다.

11-2. 계층 구조

.              ← 루트 (Root)
com            ← TLD (Top-Level Domain)
google.com     ← SLD (Second-Level Domain)
www.google.com ← 호스트

DNS 서버도 이 계층을 그대로 따른다. **Root 서버 13개(실제론 Anycast로 수백 대)**가 TLD 서버를 안내, TLD 서버가 권한 서버(Authoritative)를 안내, 권한 서버가 실제 IP를 안다.

11-3. 실제 DNS 조회 흐름

www.google.com을 쳤을 때:

1. 브라우저 캐시 확인         → 없으면
2. OS hosts 파일 확인         → 없으면
3. OS DNS 캐시 확인           → 없으면
4. ISP DNS 서버에 질의        → ISP 캐시에 없으면
5. ISP DNS가 Root에 질의      → "com 서버는 여기"
6. ISP DNS가 com TLD에 질의   → "google.com 권한 서버는 여기"
7. ISP DNS가 권한 서버에 질의 → "www.google.com은 142.250.204.46"
8. 응답을 각 단계에서 캐시하며 브라우저까지 전달

11-4. 재귀 질의 vs 반복 질의

재귀 질의: "어떻게든 답을 가져와라"는 요청. 내 로컬 DNS(ISP 등)에게 하는 질의.
반복 질의: 로컬 DNS가 Root → TLD → Authoritative로 단계별로 질의하는 것.

11-5. 캐싱 계층

브라우저 캐시 → OS 캐시 → ISP DNS 캐시 → 권한 서버
(가장 짧음)                              (가장 긺, TTL 따름)

각 캐시가 TTL (Time To Live) 동안 응답을 기억한다. TTL이 짧으면 변경이 빨리 전파되지만 DNS 조회가 잦아지고, 길면 반대.

11-6. DNS 레코드 타입

타입	용도
`A`	IPv4 주소
`AAAA`	IPv6 주소
`CNAME`	다른 도메인의 별칭
`MX`	메일 서버
`TXT`	임의 텍스트 (SPF, DKIM 등)
`NS`	이 도메인의 권한 서버

11-7. ⚠️ 함정: DNS 변경이 즉시 반영되지 않는 이유

배포 때 도메인을 새 서버로 옮겨도 기존 TTL이 만료되기 전까지 옛 IP로 가는 사용자가 있다. 마이그레이션 직전에 TTL을 짧게 줄이고, 바뀐 뒤 원복하는 관례가 있다.

11-8. DNS over HTTPS (DoH)

기존 DNS는 평문. ISP가 질의를 엿보거나 변조 가능. DoH는 HTTPS로 감싼 DNS. Cloudflare 1.1.1.1, Google 8.8.8.8이 DoH를 제공한다.

12. URL을 치면 일어나는 일 (전체 흐름)

지금까지의 내용을 묶은 시간 순서.

1. URL 파싱
   "https://www.google.com/search?q=cs"
   → scheme=https, host=www.google.com, path=/search, query=q=cs

2. DNS 조회
   브라우저 캐시 → OS 캐시 → ISP DNS → (필요시) Root → TLD → 권한 서버
   결과: 142.250.204.46

3. TCP 3-way handshake (142.250.204.46:443 으로)
   SYN → SYN+ACK → ACK

4. TLS 핸드셰이크 (HTTPS이므로)
   ClientHello → ServerHello + 인증서 → 키 교환 → Finished

5. HTTP 요청 전송
   GET /search?q=cs HTTP/1.1
   Host: www.google.com
   ...

6. 서버 처리 + 응답
   HTTP/1.1 200 OK
   Content-Type: text/html
   <html>...</html>

7. 브라우저가 HTML 수신 → 파싱 시작
   (3~7 단계는 keep-alive로 연결을 재사용할 수 있음)

8. HTML 속 리소스 (CSS, JS, 이미지) 추가 요청
   → 2~7 반복 (하지만 DNS·TCP·TLS는 재사용)

9. 연결 종료 (또는 keep-alive 유지)
   4-way handshake

이후 응답 HTML을 파싱하고, 필요한 리소스를 다시 요청하고, 렌더링 — 여기부터는 2-5. 브라우저 렌더링 과정의 영역.

연습 문제

fetch('https://api.example.com/data')가 데이터를 받기까지 거치는 모든 단계를 계층별로 나열하라.
TCP가 신뢰성을 보장하는 메커니즘 3가지를 들고 각각이 필요한 이유를 설명하라.
3-way handshake가 왜 3번인가? 2번이면 왜 안 되는가?
TIME_WAIT이 존재하는 이유 2가지를 설명하라.
DNS 레코드 변경 후 사용자에게 즉시 반영되지 않는 이유를 TTL과 캐싱 계층으로 설명하라.
영상 스트리밍이 UDP를 쓰는 이유를, "한 프레임 빠지는 것 vs 기다리는 것" 관점에서 설명하라.
HTTP/3이 UDP 위에서 동작함에도 신뢰성을 제공할 수 있는 이유를 설명하라.
집의 PC가 192.168.0.10을 쓰는데도 외부 사이트에 접속할 수 있는 이유를 NAT 관점에서 설명하라.
URL에서 프래그먼트(#section)가 서버로 전송되지 않는 사실이 SPA 라우팅에 어떤 영향을 주는가?
한국에서 미국 서버까지의 RTT가 왜 물리적으로 줄어들 수 없는지 설명하라.

연습 문제 정답

1. fetch의 전체 단계

0. URL 파싱
1. DNS 조회 (브라우저→OS→ISP→권한 서버, TTL 동안 캐시 재사용)
2. TCP 3-way handshake (대상 IP:443)
3. TLS 1.3 핸드셰이크 (1-RTT)
4. HTTP 요청 전송 (GET ... HTTP/1.1 ... 헤더 ... body)
5. 서버 처리 + 응답 수신
6. 연결 유지(keep-alive) 또는 4-way 종료

계층별로는:
- 응용: HTTP, TLS, DNS
- 전송: TCP
- 네트워크: IP 라우팅
- 링크: Ethernet/Wi-Fi

2. TCP 신뢰성 3가지

시퀀스 번호 + ACK: 패킷 순서 보장 및 수신 확인. 없으면 순서가 뒤섞임.
재전송 타이머: ACK가 일정 시간 안 오면 재전송. 네트워크가 불안정해도 데이터 전달 보장.
체크섬: 패킷 오류 감지 → 폐기 후 재전송 유도. 비트 변조를 잡음.

흐름 제어(버퍼 오버플로우 방지), 혼잡 제어(네트워크 전체 공정성)도 TCP의 역할.

3. 왜 3-way

1-way: 클라→서버 방향만 확인
2-way: 서버가 클라의 응답 능력을 확인 못 함
3-way: 양쪽 다 상대의 송수신 가능 확인
4번째는 2, 3번째와 합쳐 보낼 수 있어 불필요

4. TIME_WAIT 이유

지연된 마지막 ACK가 유실됐을 때 상대의 FIN 재전송에 응답해야 함
같은 포트를 재사용하는 새 연결에 예전 연결의 지연 패킷이 섞이는 것을 방지

5. DNS 변경 지연

TTL 동안 각 중간 계층(브라우저, OS, ISP)이 옛 IP를 캐시. TTL 만료 전까지 옛 IP로 응답. 예: TTL이 3600(1시간)이면 최악의 경우 1시간 동안 옛 서버로 트래픽이 간다.

6. UDP와 영상

재전송을 기다리면 화면 정지. 프레임 하나 잃고 다음 프레임 띄우는 게 체감 품질이 낫다. 실시간성이 신뢰성보다 중요한 맥락.

7. HTTP/3과 UDP

UDP는 단지 "전송 파이프". HTTP/3은 UDP 위에서 QUIC이라는 애플리케이션 레이어 프로토콜로 TCP가 하던 일(순서, 재전송, 혼잡 제어)을 재구현. 장점은:

스트림별 독립성 → TCP 레벨 HOL Blocking 없음
TLS와 연결 수립을 합쳐 더 적은 RTT
연결 마이그레이션 (Wi-Fi ↔ LTE 전환에서 연결 유지)

네트워크의 물리적 실체(케이블·전파·해저케이블)를 설명할 수 있다
클라이언트-서버 모델의 기본 흐름을 그릴 수 있다
IP 주소와 포트의 관계를 "아파트 주소와 호수"로 설명할 수 있다
URL의 각 부분(스킴/호스트/포트/경로/쿼리/프래그먼트)을 구분할 수 있다
패킷으로 쪼개서 보내는 이유를 3가지 이상 들 수 있다
LAN/WAN/인터넷의 관계를 설명할 수 있다
OSI 7계층과 TCP/IP 4계층의 매핑을 안다
캡슐화가 각 계층을 독립시키는 원리를 안다
IPv4와 IPv6의 차이, NAT의 존재 이유, 사설 IP 개념을 안다
TCP와 UDP의 특성과 용도를 구분할 수 있다
RTT의 개념과 물리적 하한을 안다
3-way handshake를 그릴 수 있다
4-way handshake와 TIME_WAIT의 이유를 설명할 수 있다
흐름 제어와 혼잡 제어를 구분할 수 있다
AIMD와 Slow Start의 개념을 안다
DNS의 계층 구조와 캐싱 단계를 안다
재귀 질의와 반복 질의의 차이를 안다
DNS 레코드 타입 (A/AAAA/CNAME/MX/TXT) 용도를 안다
URL 입력부터 응답까지의 전체 흐름을 순서대로 말할 수 있다

다음: 2-2. HTTP와 HTTPS