This lesson is only available in Korean for now.
Lesson 6 of 20

TCP와 UDP — 등기우편과 엽서

누가 '잘 받았는지' 확인해 주는가

TCP와 UDP — 등기우편과 엽서
TCP는 등기우편, UDP는 엽서. 결제는 등기로, 영상은 엽서로.

2강에서 패킷 하나가 깨지면 그 조각만 다시 보내면 된다고 했습니다. 그런데 누가 깨진 걸 알아채고, 누가 다시 보내 달라고 할까요?

IP는 그런 일을 하지 않습니다. IP는 "여기로 보내 봐" 까지가 전부예요. 도착 확인도, 순서 보장도, 재전송도 없습니다. 그 위에 한 층이 더 필요합니다.

TCP — 등기우편 📮
· 받았다는 확인(ACK)을 받는다
· 순서가 뒤바뀌면 제자리로 맞춘다
· 안 오면 다시 보낸다
· 시작 전에 악수부터 한다
웹·결제·DB·SSH — 정확함이 생명
UDP — 엽서 📬
· 보내고 끝. 확인 없음
· 순서 안 맞춰 줌
· 잃어버려도 모름
· 대신 빠르다
DNS·화상통화·게임 — 빠름이 생명

3-way 핸드셰이크 — 대화 전의 악수

TCP는 데이터를 보내기 전에 세 번 인사를 주고받습니다.

손님── SYN ──▶서버 말 걸어도 될까요? (내 번호는 118)
손님◀─ SYN+ACK ─서버 좋아요, 118 받았습니다. (내 번호는 991)
손님── ACK ──▶서버 991 받았습니다. 시작하죠.

이 세 번이 끝나야 GET / 이 갑니다. 그래서 연결을 새로 맺는 것 자체가 비용이에요. 20강에서 이 비용을 아끼는 방법을 배웁니다.

[S] → [S.] → [.] 세 줄이 바로 그 악수입니다.
🖥️ My virtual server Runs in your browser (for the arithmetic)
핸드셰이크·재전송 실험실 — 손실을 일으켜 보세요
Loading…

운영자가 만나는 TCP 상태들

ss 로 연결을 보면 상태 이름이 붙어 있습니다. 셋만 알면 충분합니다.

상태뜻많으면?
LISTEN손님을 기다리는 중정상. 서비스가 떠 있다는 증거
ESTAB지금 실제로 물려 있는 연결대략 동시 접속자 수
TIME-WAIT끊고 나서 잠시 남는 흔적많아도 대개 정상. 짧은 연결이 많다는 뜻
SYN-RECV악수 중간에 멈춤많으면 SYN flood 공격 의심 (19강)
estab 숫자가 지금 접속 중인 손님 수의 지표입니다.
🖥️ My virtual server Runs in your browser (for the arithmetic)
🤔 Check yourself
curl 이 즉시 'Connection refused' 를 냅니다. 가장 가능성 높은 원인은?
🤔 Check yourself
DNS 조회가 TCP가 아니라 UDP를 쓰는 주된 이유는?