📅 스터디 정보

1. 🗺️ 개념 지도 (Overview)

이 주제를 한 문장으로 설명하면?

전송 계층(4계층)에서 데이터를 어떻게 전달할 것인지를 결정하는 두 프로토콜로,
신뢰성을 보장하는 TCP와 속도를 우선하는 UDP 중 상황에 맞게 선택

이 주제가 왜 중요한가?

• 매일 쓰는 fetch, axios 가 내부적으로 HTTP → TCP 위에서 동작한다. HTTP/3는 UDP 위에서 동작한다. 왜 그런지 설명할 수 있어야 한다.
• OSI 7계층을 물어보면 거의 반드시 꼬리질문으로 TCP vs UDP 가 따라온다.
• WebSocket, DNS, 스트리밍 등 실무에서 마주치는 기술들이 어떤 프로토콜을 쓰는지, 왜 그런지 이해하는 기반이 된다.

[TCP vs UDP]
├── TCP
│   ├── 연결 지향형 (각 연결은 1:1 점대점)
│   ├── 3-way handshake (연결) / 4-way handshake (해제)
│   ├── 흐름 제어 (Flow Control) - 슬라이딩 윈도우
│   ├── 혼잡 제어 (Congestion Control) - Slow Start
│   ├── 오류 제어 (Error Control) - 재전송(ARQ)
│   └── Sequence Number / ACK Number
├── UDP
│   ├── 비연결형 (멀티캐스트·브로드캐스트 가능)
│   ├── 데이터그램 단위 전송
│   ├── 체크섬(CheckSum)으로 최소한의 오류 검출만
│   └── 상위 레이어에서 필요한 기능을 직접 구현 가능
├── 공통
│   ├── 전송 계층 (4계층) 프로토콜
│   └── 포트 번호 사용
└── 연관 개념
    ├── HTTP/1.1, HTTP/2 → TCP
    ├── HTTP/3, QUIC → UDP 기반
    └── DNS → 기본 UDP (조건에 따라 TCP)

2. 📖 핵심 개념 정리

⚠️ 단순 복붙 금지! 반드시 자신의 말로 재작성할 것

2-1. TCP (Transmission Control Protocol)

상대방과 연결을 먼저 확인한 뒤 데이터를 주고받는 연결 지향형 프로토콜이다. 데이터가 순서대로, 빠짐없이 도착하도록 보장하는 것이 최우선이다. 그 대신 연결을 맺고 끊는 과정, 재전송, 속도 조절 등 여러 단계를 거치기 때문에 UDP보다 느리다.

1. 연결 수립 — 3-way handshake

   1. 클라이언트 → 서버     : SYN     (연결 요청 + 시퀀스 번호 전달)
   2. 서버     → 클라이언트 : SYN-ACK (수신 확인 + 서버 시퀀스 번호 전달)
   3. 클라이언트 → 서버     : ACK     (서버 시퀀스 번호 확인)
   
   ⇒ 이 3번의 통신이 끝나야 비로소 데이터 전송 시작

   이 과정을 통해 양측이 "통신 준비 완료"를 확인하고, 이후 패킷 재조립에 사용할 시퀀스 번호를 서로 교환한다.

2. 데이터 전송

   송신 측          수신 측
     │── 세그먼트 1 ──▶ │
     │◀─── ACK 2 ──── │  "1번 잘 받았어, 2번 줘"
     │── 세그먼트 2 ──▶ │
     │◀─── ACK 3 ──── │  "2번 잘 받았어, 3번 줘"
     │── 세그먼트 3 ─ X │  (유실!)
     │    타임아웃...   │
     │── 세그먼트 3 ──▶ │  → 송신 측이 3번을 다시 보냄
     │◀─── ACK 4 ──── │

   데이터를 세그먼트(Segment) 단위로 쪼개 Sequence Number를 붙여 순서를 보장한다. 수신 측은 받은 세그먼트마다 ACK를 보내고, 송신 측이 일정 시간 내에 ACK를 받지 못하면 해당 패킷을 재전송한다.

// HTTP/HTTPS는 모두 TCP 위에서 동작한다
// fetch를 호출하는 순간 내부적으로 TCP 3-way handshake가 먼저 일어난다
// 개발자 도구 Timing 탭의 "Initial connection" = TCP handshake 시간
const response = await fetch('https://api.example.com/data');

// WebSocket도 TCP 기반
// HTTP 핸드셰이크 후 TCP 연결을 업그레이드해 양방향으로 유지한다
const socket = new WebSocket('wss://chat.example.com');

핵심 포인트:

• TCP는 전이중(Full-Duplex), 점대점(Point to Point) 방식이다. 쉽게 말하면 양방향으로 데이터를 주고받을 수 있고, 연결 하나는 항상 두 컴퓨터 사이 1:1이다. (서버가 여러 클라이언트와 동시에 연결할 수 있지만, 그건 연결이 여러 개 있는 거지 하나의 연결이 1:N인 건 아니다)
• 패킷이 유실되면 반드시 재전송한다. 영상 스트리밍처럼 약간의 손실이 괜찮은 서비스에는 오히려 비효율적이다.
• 3-way handshake의 취약점으로 SYN Flooding 공격이 있다. SYN 패킷을 대량으로 보내 서버 자원을 고갈시키는 DoS 공격의 일종이다.

2-2. UDP (User Datagram Protocol)

연결 확인 없이 데이터를 일방적으로 전송하는 비연결형 프로토콜이다. 상대방이 준비됐는지 확인하지 않고 바로 보내기 때문에 빠르다. 전송 계층 수준에서는 데이터가 도착했는지, 순서가 맞는지를 보장하지 않는다. 그 대신 헤더가 8byte로 매우 단순해서, 필요한 기능을 상위 레이어에서 직접 구현할 수 있다는 것이 핵심이다.

1. 비연결 전송

   : 연결 설정 없이 데이터그램(Datagram) 단위로 바로 전송한다. 각 패킷은 독립적으로 처리되며 서로 다른 경로로 전달될 수 있다.

2. 최소한의 오류 검출

   : 헤더의 체크섬(CheckSum)으로 데이터 손상 여부만 확인한다. 오류가 있으면 버릴 뿐, 재전송 요청은 하지 않는다.

3. 큰 데이터 처리

   : UDP는 한 번에 보낼 수 있는 데이터 크기에 이론상 상한선이 있지만, 그것보다 더 현실적인 제약은 네트워크가 한 번에 전달할 수 있는 크기(MTU, 보통 1,500바이트)다. 이걸 넘으면 중간에 알아서 잘리긴 하는데, 잘린 조각 중 하나라도 유실되면 전체를 다시 보내야 하는 문제가 생긴다. 그래서 실무에서는 처음부터 적당한 크기로 쪼개서 보내는 방식을 쓴다.

// DNS 조회는 기본적으로 UDP를 사용한다
// 브라우저에서 fetch 호출 전, 도메인을 IP로 변환하는 과정이 UDP로 이뤄진다
// 개발자 도구 Timing 탭 > "DNS Lookup" = 이 과정의 시간

// WebRTC는 UDP 기반 (실시간 화상/음성 통신)
const peerConnection = new RTCPeerConnection();
// 약간의 패킷 유실보다 낮은 지연 시간이 더 중요하기 때문

// HTTP/3(QUIC)도 UDP 기반
// 개발자 도구 Network 탭 Protocol 컬럼에서 "h3"로 확인 가능

핵심 포인트:

• UDP는 멀티캐스트·브로드캐스트를 통해 데이터 하나를 여러 수신자에게 동시에 보내는 1:N 통신이 가능하다. TCP는 연결 자체가 항상 1:1이라 이게 안 된다.
• UDP는 "신뢰성이 없다"고 표현하는데, 정확히는 전송 계층(4계층) 수준에서는 신뢰성을 제공하지 않는다는 의미다. 못 하는 게 아니라 안 하는 것이고, 필요하면 그 위 레이어인 애플리케이션(개발자가 짜는 코드 영역) 에서 직접 구현할 수 있다. 예를 들면 이런 것들:
  • 패킷이 안 오면 일정 시간 후 다시 요청하는 재전송 로직
  • 패킷에 번호를 붙여서 순서가 뒤바뀌면 재조립하는 로직
  • 중복 패킷이 오면 버리는 로직

  이걸 직접 다 구현한 대표적인 예가 바로 HTTP/3의 QUIC이다. UDP 위에서 신뢰성·순서 보장·암호화까지 직접 만들어서, TCP의 단점은 없애고 UDP의 속도는 살린 프로토콜이다.

3. 🔍 깊이 이해하기

왜 이렇게 설계됐을까? (Design Decision)

이 기술/개념이 왜 이런 방식으로 만들어졌는지 배경을 이해하자

• TCP : 초기 인터넷 환경은 물리적으로 불안정한 회선이 많았다. 데이터가 중간에 유실되는 일이 잦은 환경에서 "어떻게 신뢰성을 보장할 것인가"가 전송 계층의 핵심 과제였다. 그래서 연결 수립, 재전송, 흐름·혼잡 제어 등 필요한 기능을 프로토콜 자체에 담아 설계됐다.
• UDP : 반대로 데이터 전송 기능만 남기고 나머지는 비워둔 '백지 상태' 프로토콜로 설계됐다. 헤더가 8바이트로 단순한 덕분에 오버헤드가 적고, 필요한 기능을 상위 레이어(애플리케이션)에서 선택적으로 구현할 수 있어 유연하다.

다른 개념과의 비교

HTTP 버전별로 어떤 전송 프로토콜을 쓰는지 비교

실무에서는 어떻게 쓰이나?

프론트엔드 관점에서 마주칠 수 있는 상황

• HTTP/1.1, HTTP/2 → TCP

  : fetch나 axios로 API를 호출할 때, 내부적으로는 TCP 위에서 동작한다. 그런데 TCP는 패킷을 반드시 순서대로 처리해야 해서, 중간에 하나가 막히면 뒤에 오는 것들이 줄 서서 기다려야 한다. 이걸 HOLB(Head of Line Blocking) 라고 한다. HTTP/2가 한 연결에서 여러 요청을 동시에 처리하는 멀티플렉싱으로 개선했지만, TCP 자체의 HOLB는 여전히 남아있다.

• HTTP/3 → UDP 기반 QUIC

  : TCP의 한계를 넘기 위해 UDP 위에서 만든 프로토콜이 QUIC이고, HTTP/3는 이 위에서 동작한다. 개발자 도구 Network 탭 Protocol 컬럼에서 h3로 확인할 수 있다.

  1. HOLB 해결: 스트림마다 독립적으로 처리해서, 이미지 하나가 느려도 다른 리소스 로딩에 영향 없음
  2. 연결이 빠르다: 재연결 시 이전 연결 정보를 재사용해 handshake를 생략할 수 있다 (0 RTT). 페이지 재방문 시 로딩이 빠른 이유 중 하나
  3. 업데이트가 쉽다: TCP는 OS 안에 박혀있어서 수정이 어렵지만, QUIC은 브라우저 안에서 동작하니까 브라우저 업데이트만으로 개선 가능
• DNS → 기본 UDP

  : 브라우저 주소창에 도메인을 입력하면, fetch가 실행되기도 전에 IP로 변환하는 DNS 조회가 먼저 일어난다. 요청·응답이 짧고 빠른 응답이 중요하기 때문에 UDP로 동작한다. 개발자 도구 Timing 탭의 DNS Lookup 항목이 바로 이 과정이다. 다만 응답 데이터가 매우 크거나 보안이 필요한 경우엔 TCP로 전환하기도 한다.

• WebRTC → UDP

  : 화상 통화나 음성 통화를 브라우저에서 구현할 때 사용하는 WebRTC가 UDP 기반이다. 1초에 수십 프레임이 오가는데 패킷 하나 유실됐다고 멈추고 기다리면 통화가 끊기는 것처럼 느껴진다. 약간의 손실이 있더라도 끊기지 않고 빠르게 흘러가는 게 더 중요해서 UDP를 사용한다.

4. 🎤 구두 설명 연습

면접관 앞에서 말하듯이 작성. 읽는 용도가 아니라 말하는 연습을 위한 섹션

"~이 뭔가요?" 질문에 대한 답변 스크립트

[도입 - 핵심 정의 먼저]
"TCP와 UDP는 모두 OSI 7계층 중 전송 계층(4계층)에서 사용되는 프로토콜입니다.
가장 큰 차이는 신뢰성과 속도의 트레이드오프입니다."

[부연 - 왜/어떻게]
"TCP는 연결 지향형으로, 
3-way handshake를 통해 연결을 수립한 뒤 데이터를 주고받습니다. 
흐름·혼잡·오류 제어를 통해 데이터가 순서대로, 빠짐없이 도착하도록 보장하지만 
그만큼 느립니다.

UDP는 비연결형으로, 
연결 확인 없이 데이터를 바로 전송합니다.
전송 계층 수준에서는 신뢰성을 제공하지 않아 패킷이 유실될 수 있지만,
그만큼 빠르고 오버헤드가 적습니다."

[마무리 - 실무 연결]
"그래서 HTTP, 파일 전송처럼 데이터 무결성이 중요한 곳에는 TCP를,
DNS 조회, 스트리밍, WebRTC처럼 속도가 중요한 곳에는 UDP를 사용합니다.
최근에는 HTTP/3가 TCP의 HOLB 문제와 연결 지연을 해결하기 위해
UDP 기반의 QUIC 프로토콜을 채택했다는 점도 중요한 포인트입니다."

⏱️ 1분 요약 버전

면접관이 바쁠 때, 딱 1분 안에 설명하는 버전

TCP는 3-way handshake로 연결을 맺고 흐름·혼잡·오류 제어를 통해
데이터의 신뢰성을 보장하는 연결 지향형 프로토콜입니다.

UDP는 이런 절차 없이 바로 데이터를 전송하는 비연결형 프로토콜로,
전송 계층 수준에서는 신뢰성을 보장하지 않지만 속도가 빠릅니다.

HTTP/HTTPS는 TCP, DNS와 HTTP/3는 UDP 기반이며,
특히 HTTP/3의 QUIC은 TCP의 HOLB와 연결 지연 문제를 해결하기 위해 UDP를 선택했습니다.

5. ❓ 예상 면접 질문 & 답변

기본 질문

심화 질문 (꼬리질문 대비)

🧨 함정/난이도 높은 질문

6. 📝 나만의 요약 노트

공부하고 나서 진짜 내 머릿속에 남은 것들만 정리

오늘 이 주제에서 가장 중요한 것 3가지

1. TCP = 신뢰성, UDP = 속도

   : TCP는 3-way handshake + 흐름/혼잡/오류 제어로 데이터가 순서대로 빠짐없이 도착하도록 보장하고, UDP는 이 과정을 생략해 빠르게 전송한다.

2. UDP는 전송 계층에서 신뢰성을 제공하지 않지만, 상위 레이어에서 구현할 수 있다

   : 전송 계층에서 제공하지 않을 뿐, 필요하면 애플리케이션 레벨에서 직접 구현할 수 있다. QUIC이 그 대표적인 예다.

3. HTTP/3가 UDP를 선택한 이유

   : TCP는 패킷 하나가 막히면 뒤가 전부 대기하고(HOLB), 연결 맺는 데 시간이 걸리고, OS 안에 있어서 고치기도 어렵다. QUIC은 이 세 가지를 UDP 위에서 직접 해결했다

헷갈렸던 부분 & 해결

더 공부하고 싶은 것

7. 📚 참고 자료

💡 작성 팁

• 2번 핵심 개념은 공식 문서나 블로그를 보고 나서, 반드시 탭을 닫고 자신의 말로 재작성하기
• 4번 구두 설명 스크립트는 실제로 소리 내어 읽어보기
• 5번 질문은 최소 5개 이상 준비하기 (기본 2~3개 + 심화 2개 이상)
• 발표 전날 밤에 전체를 한 번 소리 내어 읽어보기