📡 백엔드 통신 및 프로토콜 완전 정리¶
백엔드 개발자가 반드시 알아야 할 통신 원리, 프로토콜, 디자인 패턴을 한 곳에 정리한 문서입니다.
목차¶
- 통신 기초 개념
- OSI 모델과 네트워크 계층
- 인터넷 프로토콜 (IP)
- UDP (User Datagram Protocol)
- TCP (Transmission Control Protocol)
- TLS / SSL
- HTTP/1.1
- HTTP/2
- HTTP/3 (QUIC)
- WebSocket
- gRPC
- WebRTC
- 통신 디자인 패턴
- 백엔드 실행 패턴
- 프록시와 로드 밸런서
- 정리 & 프로토콜 비교표
- 학습 팁
- 추가 학습 자료
1. 통신 기초 개념¶
클라이언트-서버 모델¶
백엔드 통신의 가장 기본적인 구조입니다.
- 클라이언트: 서비스를 요청하는 쪽 (브라우저, 모바일 앱, 다른 서버 등)
- 서버: 요청을 받아 처리하고 응답하는 쪽
연결(Connection)이란?¶
두 프로세스 사이에 데이터를 주고받기 위한 논리적 통로입니다. 물리적인 전선이 아니라 소프트웨어적으로 맺어진 약속입니다.
- 연결 수립: 서로 "통신할 준비가 됐어"라고 확인하는 과정
- 연결 유지: 데이터를 주고받는 동안 연결 상태를 유지
- 연결 종료: 통신이 끝났음을 알리고 자원을 해제
포트(Port)¶
하나의 컴퓨터에서 여러 서비스를 동시에 돌릴 수 있는 이유는 포트 번호 덕분입니다.
- IP 주소 = 건물 주소, 포트 = 건물 안의 호실 번호
- 범위: 0 ~ 65535
- 잘 알려진 포트: HTTP(80), HTTPS(443), SSH(22), MySQL(3306), PostgreSQL(5432)
프로토콜 속성¶
프로토콜은 두 당사자가 통신할 수 있게 하는 시스템으로, 다음과 같은 속성을 가집니다:
- 데이터 형식: 텍스트(JSON, XML) vs 바이너리(Protobuf, HTTP/2)
- 전송 모드: 메시지 기반(UDP, HTTP) vs 스트림 기반(TCP)
- 방향성: 양방향(TCP) vs 단방향(HTTP)
- 상태: Stateful(TCP, gRPC) vs Stateless(UDP, HTTP)
- 흐름 제어 & 혼잡 제어: TCP는 지원, UDP는 없음
2. OSI 모델과 네트워크 계층¶
네트워크 통신을 7개 계층으로 나눠서 이해하는 모델입니다.
┌─────────────────────────────────┐
│ 7계층 - 응용 (Application) │ ← HTTP, WebSocket, gRPC, DNS
├─────────────────────────────────┤
│ 6계층 - 표현 (Presentation) │ ← 암호화, 압축, 인코딩
├─────────────────────────────────┤
│ 5계층 - 세션 (Session) │ ← 연결 관리, TLS
├─────────────────────────────────┤
│ 4계층 - 전송 (Transport) │ ← TCP, UDP
├─────────────────────────────────┤
│ 3계층 - 네트워크 (Network) │ ← IP, 라우팅
├─────────────────────────────────┤
│ 2계층 - 데이터링크 (Data Link) │ ← MAC 주소, 이더넷
├─────────────────────────────────┤
│ 1계층 - 물리 (Physical) │ ← 전기 신호, 광케이블
└─────────────────────────────────┘
데이터 캡슐화¶
데이터가 전송될 때 각 계층을 거치며 "헤더"가 추가됩니다:
원본 데이터
↓ 응용 계층 → [HTTP 헤더 | 데이터]
↓ 전송 계층 → [TCP 헤더 | HTTP 헤더 | 데이터]
↓ 네트워크 계층 → [IP 헤더 | TCP 헤더 | HTTP 헤더 | 데이터]
↓ 데이터링크 계층 → [프레임 헤더 | IP 헤더 | TCP 헤더 | HTTP 헤더 | 데이터]
이것을 캡슐화(Encapsulation) 라고 부르며, 받는 쪽에서는 반대로 헤더를 하나씩 벗기며 데이터를 읽습니다.
OSI 모델 vs TCP/IP 모델¶
| OSI (7계층) | TCP/IP (4계층) | 예시 |
|---|---|---|
| Application (7) + Presentation (6) + Session (5) | Application | HTTP, gRPC, FTP |
| Transport (4) | Transport | TCP, UDP |
| Network (3) | Internet | IP |
| Data Link (2) + Physical (1) | Data Link | 이더넷, MAC |
TCP/IP 모델의 장점: OSI보다 훨씬 단순하고 실무에서 더 많이 사용됩니다.
3. 인터넷 프로토콜 (IP)¶
IP 주소¶
네트워크상에서 장치를 식별하는 주소입니다.
- IPv4:
192.168.0.1형태, 약 43억 개 주소 (부족함) - IPv6:
2001:db8::1형태, 사실상 무한대
IP 패킷 구조¶
┌──────────────────────────────────────────┐
│ IP 헤더 │
│ - 출발지 IP (Source IP) │
│ - 도착지 IP (Destination IP) │
│ - TTL (Time to Live) │
│ - 프로토콜 (TCP/UDP 등) │
├──────────────────────────────────────────┤
│ 데이터 (Payload) │
└──────────────────────────────────────────┘
IP의 특징¶
- 비연결형(Connectionless): 패킷 하나하나가 독립적으로 경로를 선택
- 비신뢰성(Unreliable): 패킷이 도착하는지 보장하지 않음
- 순서 보장 없음: 패킷이 보낸 순서대로 도착하지 않을 수 있음
💡 "IP만으로는 신뢰할 수 있는 통신이 안 됩니다. 그래서 TCP가 필요합니다."
4. UDP (User Datagram Protocol)¶
UDP란?¶
빠르지만 신뢰성을 보장하지 않는 Layer 4 전송 프로토콜입니다.
┌────────────────────────────┐
│ UDP 헤더 (8바이트) │
│ - 출발지 포트 │
│ - 도착지 포트 │
│ - 길이 │
│ - 체크섬 │
├────────────────────────────┤
│ 데이터 │
└────────────────────────────┘
UDP의 특징¶
- 연결 수립 과정 없음: 바로 데이터를 보냄 (핸드셰이크 없음)
- 순서 보장 없음: 패킷이 뒤섞여 올 수 있음
- 재전송 없음: 패킷이 유실되어도 다시 보내지 않음
- 무상태(Stateless): 연결 상태를 저장하지 않음
- 빠름: 오버헤드가 적어 낮은 지연 시간
멀티플렉싱 & 역다중화¶
- 송신자: 모든 앱을 UDP로 다중화
- 수신자: UDP 데이터그램을 각 앱으로 역다중화
- UDP는 멀티캐스트도 지원 — 하나의 패킷을 여러 수신자에게 동시에 전송 가능
사용 사례¶
- 실시간 게임 (약간의 데이터 유실 허용)
- 영상/음성 스트리밍 (지연이 더 큰 문제)
- DNS 조회 (한 번의 요청/응답으로 끝남)
- VPN, WebRTC, IoT 센서 데이터
장단점¶
| 장점 | 단점 |
|---|---|
| 작은 헤더(8바이트), 낮은 오버헤드 | 전달 보장 없음 |
| 낮은 지연 시간 | 순서 보장 없음 |
| 무상태 (메모리 소비 적음) | 흐름/혼잡 제어 없음 |
| 멀티캐스트 지원 | 보안 취약 (스푸핑 가능) |
5. TCP (Transmission Control Protocol)¶
TCP란?¶
신뢰성 있는 데이터 전송을 보장하는 Layer 4 프로토콜입니다. 스트림 기반으로 동작하며, 20~60바이트 헤더를 가집니다.
3-Way Handshake (연결 수립)¶
클라이언트 서버
│ │
│──── SYN (연결 요청) ────────▶│ ① "연결하고 싶어"
│◀── SYN + ACK (수락+확인) ───│ ② "좋아, 나도 준비됐어"
│──── ACK (확인) ─────────────▶│ ③ "알겠어, 시작하자!"
│ │
│ 🔗 연결 수립 완료 │
💡 비유: 전화 걸기와 비슷합니다. "여보세요?" → "네, 말씀하세요" → "네, 알겠습니다"
TCP 연결은 4가지 속성으로 식별됩니다: SourceIP:SourcePort ↔ DestinationIP:DestinationPort
TCP 세그먼트 구조¶
┌──────────────────────────────────────┐
│ TCP 헤더 (20~60바이트) │
│ - 출발지 포트 / 도착지 포트 │
│ - 시퀀스 번호 (Sequence Number) │
│ - 확인 번호 (Acknowledgment Number) │
│ - 윈도우 크기 (Window Size) │
│ - 플래그 (SYN, ACK, FIN 등) │
├──────────────────────────────────────┤
│ 데이터 │
└──────────────────────────────────────┘
TCP의 핵심 기능들¶
① 순서 보장 (Ordering)¶
각 바이트에 시퀀스 번호가 부여되어 받는 쪽에서 올바른 순서로 재조립합니다.
보낸 순서: [패킷1] [패킷2] [패킷3]
도착 순서: [패킷2] [패킷1] [패킷3] ← 네트워크에서 뒤섞임
재조립: [패킷1] [패킷2] [패킷3] ← TCP가 시퀀스 번호로 정렬
② 재전송 (Retransmission)¶
패킷이 유실되면 자동으로 다시 보냅니다.
클라이언트 서버
│── 패킷1 ──────────▶│ ✅ 수신
│── 패킷2 ───── ✖ ───│ ❌ 유실!
│── 패킷3 ──────────▶│ ✅ 수신
│ (타임아웃 발생) │
│── 패킷2 (재전송) ───▶│ ✅ 재수신
③ 흐름 제어 (Flow Control)¶
수신자가 처리할 수 있는 속도에 맞춰 전송량을 조절합니다.
- 윈도우 크기(Window Size): "나는 이만큼 받을 수 있어"라고 알려주는 값
- 수신자의 버퍼가 가득 차면 윈도우 크기를 0으로 보내서 "잠깐 멈춰!"라고 알림
④ 혼잡 제어 (Congestion Control)¶
네트워크가 혼잡할 때 전송 속도를 줄여 네트워크 붕괴를 방지합니다.
- 슬로우 스타트(Slow Start): 처음에 천천히 시작해서 점점 속도를 올림
- 혼잡 회피(Congestion Avoidance): 일정 수준 이후 천천히 증가
- 패킷 유실 감지 시: 전송 속도를 급격히 줄임
4-Way Handshake (연결 종료)¶
클라이언트 서버
│──── FIN (종료 요청) ────────▶│ ① "끝낼게"
│◀── ACK (확인) ──────────────│ ② "알겠어"
│◀── FIN (종료 요청) ─────────│ ③ "나도 끝낼게"
│──── ACK (확인) ─────────────▶│ ④ "알겠어"
│ 🔓 연결 종료 완료 │
TCP의 단점¶
- 연결 수립 오버헤드: 매 연결마다 3-Way Handshake 필요
- Head-of-Line Blocking: 앞의 패킷이 유실되면 뒤의 패킷도 대기
- 느린 시작: 연결 초기에는 속도가 느림
- TCP Meltdown: VPN에 적합하지 않음 (TCP over TCP 문제)
6. TLS / SSL¶
TLS(Transport Layer Security)란?¶
TCP 위에서 동작하며 데이터를 암호화하여 안전한 통신을 가능하게 합니다. HTTPS = HTTP + TLS입니다.
TLS가 보호하는 것¶
- 기밀성(Confidentiality): 데이터를 암호화하여 도청 방지
- 무결성(Integrity): 데이터가 중간에 변조되지 않았음을 보장
- 인증(Authentication): 통신 상대가 진짜 그 서버인지 확인 (인증서)
TLS 1.2 핸드셰이크¶
클라이언트 서버
│── ClientHello ──────────────────▶│ 지원하는 암호화 방식 목록 전송
│◀── ServerHello ─────────────────│ 암호화 방식 선택 + 인증서 전송
│ [인증서 검증] │
│── Key Exchange ──────────────────▶│ Diffie-Hellman 키 교환
│◀── Finished ────────────────────│
│── Finished ──────────────────────▶│
│ 🔐 암호화된 통신 시작 │
TLS 1.3의 개선점¶
- 핸드셰이크가 1-RTT(1 왕복)으로 단축 (TLS 1.2는 2-RTT)
- 불안전한 암호화 알고리즘 제거
- 0-RTT: 이전에 연결했던 서버에는 핸드셰이크 없이 바로 데이터 전송 가능
TLS 1.2: TCP 핸드셰이크(1-RTT) + TLS 핸드셰이크(2-RTT) = 3-RTT
TLS 1.3: TCP 핸드셰이크(1-RTT) + TLS 핸드셰이크(1-RTT) = 2-RTT
7. HTTP/1.1¶
HTTP란?¶
HyperText Transfer Protocol — 웹에서 가장 널리 쓰이는 응용 계층 프로토콜입니다.
요청(Request) 구조¶
GET /api/users HTTP/1.1 ← 요청 라인 (메서드 / 경로 / 버전)
Host: example.com ← 헤더
Content-Type: application/json
Authorization: Bearer abc123
{"name": "홍길동"} ← 본문 (Body)
응답(Response) 구조¶
HTTP/1.1 200 OK ← 상태 라인 (버전 / 상태코드 / 메시지)
Content-Type: application/json
Content-Length: 27
{"id": 1, "name": "홍길동"} ← 본문
주요 HTTP 메서드¶
| 메서드 | 용도 | 특징 |
|---|---|---|
| GET | 리소스 조회 | 본문 없음, 캐시 가능, 멱등 |
| POST | 리소스 생성 | 본문 있음, 멱등성 없음 |
| PUT | 리소스 전체 교체 | 본문 있음, 멱등성 있음 |
| PATCH | 리소스 부분 수정 | 본문 있음 |
| DELETE | 리소스 삭제 | 멱등성 있음 |
💡 멱등성(Idempotent): 같은 요청을 여러 번 보내도 결과가 같다는 뜻.
주요 상태 코드¶
| 코드 | 의미 | 설명 |
|---|---|---|
| 200 | OK | 성공 |
| 201 | Created | 리소스 생성됨 |
| 301 | Moved Permanently | 영구 이동 |
| 304 | Not Modified | 캐시된 버전 사용 |
| 400 | Bad Request | 잘못된 요청 |
| 401 | Unauthorized | 인증 필요 |
| 403 | Forbidden | 권한 없음 |
| 404 | Not Found | 리소스 없음 |
| 500 | Internal Server Error | 서버 오류 |
| 502 | Bad Gateway | 게이트웨이 오류 |
| 503 | Service Unavailable | 서비스 불가 |
HTTP/1.1의 핵심 기능¶
Keep-Alive (지속 연결)¶
HTTP/1.0: 연결 → 요청 → 응답 → 종료 → 연결 → 요청 → 응답 → 종료 (비효율!)
HTTP/1.1: 연결 → 요청 → 응답 → 요청 → 응답 → 요청 → 응답 → 종료 (효율적!)
Pipelining (파이프라이닝)¶
응답을 기다리지 않고 여러 요청을 한 번에 보낼 수 있지만, 응답은 요청 순서대로 와야 합니다.
Head-of-Line Blocking 문제¶
요청1 (이미지, 5초) → 요청2 (CSS, 0.1초) → 요청3 (JS, 0.2초)
응답1 (5초 대기 중...)
응답2 (응답1이 끝날 때까지 대기) ← 😫 이미 준비됐는데 기다려야 함
응답3 (응답2가 끝날 때까지 대기)
브라우저는 보통 하나의 도메인에 6개의 TCP 연결을 동시에 열어 병렬 요청으로 이를 우회합니다.
8. HTTP/2¶
HTTP/2가 해결하려는 문제¶
HTTP/1.1의 Head-of-Line Blocking과 비효율적인 헤더 전송 문제를 해결합니다.
핵심 기능¶
① 멀티플렉싱 (Multiplexing)¶
하나의 TCP 연결에서 여러 요청/응답을 동시에 주고받습니다.
HTTP/1.1 (6개 연결 필요):
연결1: 요청A → 응답A
연결2: 요청B → 응답B
HTTP/2 (1개 연결로 충분):
연결1: [요청A] [요청B] [요청C] → [응답B] [응답A] [응답C]
└── 하나의 TCP 연결에서 동시 처리 ──┘
② 스트림 (Stream)¶
각 요청/응답 쌍이 독립적인 스트림 채널로 관리됩니다.
하나의 TCP 연결 안:
┌──────────────────────────────────────┐
│ 스트림 1: GET /index.html │
│ 스트림 3: GET /style.css │
│ 스트림 5: GET /app.js │
│ (스트림 번호는 홀수 = 클라이언트 시작) │
└──────────────────────────────────────┘
③ 헤더 압축 (HPACK)¶
자주 쓰는 헤더는 인덱스 번호로 대체하고, 이전에 보낸 헤더와 차이점만 전송합니다.
④ 서버 푸시 (Server Push)¶
클라이언트가 요청하기 전에 서버가 필요한 리소스를 미리 보내줍니다.
⑤ 바이너리 프레이밍 (Binary Framing)¶
HTTP/1.1은 텍스트 기반이었지만, HTTP/2는 바이너리 프레임으로 파싱이 더 빠르고 효율적입니다.
HTTP/2의 한계¶
TCP 수준의 Head-of-Line Blocking은 여전히 존재합니다. TCP에서 패킷 하나가 유실되면, 그 패킷이 재전송될 때까지 모든 스트림이 막힙니다.
💡 "HTTP/2는 HTTP 수준의 HOL Blocking은 해결했지만, TCP 수준의 HOL Blocking은 해결 못했습니다. 이것이 HTTP/3가 나온 이유입니다."
9. HTTP/3 (QUIC)¶
HTTP/3란?¶
TCP 대신 QUIC 프로토콜(UDP 기반)을 사용하는 HTTP의 최신 버전입니다.
QUIC 프로토콜의 특징¶
① 연결 수립이 빠름¶
TCP + TLS 1.3: 1-RTT(TCP) + 1-RTT(TLS) = 2-RTT
QUIC: 1-RTT (연결 + 암호화 동시!)
QUIC 재연결: 0-RTT (이전에 연결한 적 있다면!)
② TCP HOL Blocking 해결¶
QUIC의 스트림은 완전히 독립적입니다. 하나의 스트림에서 패킷이 유실되어도 다른 스트림에 영향을 주지 않습니다.
③ 연결 마이그레이션 (Connection Migration)¶
TCP는 IP + 포트로 연결을 식별하지만, QUIC은 연결 ID로 식별합니다. IP 주소가 바뀌어도 연결이 유지됩니다.
10. WebSocket¶
WebSocket이란?¶
HTTP의 요청-응답 모델과 달리, 클라이언트와 서버가 양방향으로 자유롭게 메시지를 주고받을 수 있는 프로토콜입니다.
HTTP:
클라이언트 → "데이터 줘" → 서버
클라이언트 ← "여기 있어" ← 서버
(매번 클라이언트가 먼저 요청해야 함)
WebSocket:
클라이언트 ↔ 서버
(아무 때나 양쪽 다 메시지를 보낼 수 있음)
WebSocket 연결 과정¶
HTTP 업그레이드 요청으로 시작합니다.
① 클라이언트 → 서버 (HTTP 요청)
GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade
② 서버 → 클라이언트 (HTTP 응답)
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
③ 이후부터는 WebSocket 프레임으로 양방향 통신
사용 사례 및 주의점¶
사용 사례: 실시간 채팅, 주식 시세, 멀티플레이어 게임, Google Docs 동시 편집
주의점: - 연결을 계속 유지해야 하므로 서버 리소스를 많이 사용 - 수평 확장이 어려움: 같은 사용자의 연결이 같은 서버로 가야 함 (Sticky Session) - 재연결 로직 필요: 네트워크 끊김에 대비한 클라이언트 측 재연결 구현
11. gRPC¶
gRPC란?¶
Google이 만든 고성능 RPC(Remote Procedure Call) 프레임워크입니다. HTTP/2 위에서 동작하며, Protocol Buffers(Protobuf)를 사용합니다.
REST vs gRPC¶
REST:
- JSON (텍스트, 사람이 읽기 쉬움)
- HTTP/1.1 또는 HTTP/2
- URL 기반 리소스 접근: GET /api/users/1
gRPC:
- Protobuf (바이너리, 더 작고 빠름)
- HTTP/2 필수
- 함수 호출처럼 사용: userService.GetUser(id=1)
Protocol Buffers (Protobuf) 예시¶
// user.proto (스키마 정의)
syntax = "proto3";
service UserService {
rpc GetUser (GetUserRequest) returns (User);
rpc ListUsers (ListUsersRequest) returns (stream User);
}
message User {
int32 id = 1;
string name = 2;
string email = 3;
}
gRPC의 4가지 통신 패턴¶
① Unary (단일 요청-응답)
클라이언트 ─요청─▶ 서버
클라이언트 ◀─응답── 서버
② Server Streaming (서버 스트리밍)
클라이언트 ─요청─▶ 서버
클라이언트 ◀─응답1, 응답2, 응답3─ 서버
③ Client Streaming (클라이언트 스트리밍)
클라이언트 ─요청1, 요청2, 요청3─▶ 서버
클라이언트 ◀─응답── 서버
④ Bidirectional Streaming (양방향 스트리밍)
클라이언트 ↔ 서버 (양쪽에서 동시에 스트리밍)
gRPC의 장단점¶
| 장점 | 단점 |
|---|---|
| 빠른 직렬화/역직렬화 | 브라우저에서 직접 사용 어려움 (gRPC-Web 필요) |
| 작은 데이터 크기 | 디버깅이 어려움 (바이너리) |
| 강타입 & 코드 자동 생성 | 학습 곡선 |
| 다양한 언어 지원 | - |
12. WebRTC¶
WebRTC란?¶
Web Real-Time Communication — 브라우저 간 또는 앱 간의 P2P 실시간 통신을 지원하는 기술입니다.
구성 요소¶
- NAT: Network Address Translation
- STUN: Session Traversal Utilities for NAT — NAT 뒤의 공개 IP 주소/포트 확인
- TURN: Traversal Using Relays around NAT — Symmetric NAT 환경에서 패킷 중계
- ICE: Interactive Connectivity Establishment — 최적의 연결 경로 탐색
- SDP: Session Description Protocol — 미디어 형식 협상
NAT 유형¶
| NAT 유형 | 특징 |
|---|---|
| Full Cone NAT | 가장 개방적, STUN으로 처리 가능 |
| Address Restricted NAT | 통신한 주소만 허용, STUN으로 처리 가능 |
| Port Restricted NAT | 통신한 주소:포트만 허용, STUN으로 처리 가능 |
| Symmetric NAT | 가장 제한적, TURN 서버 필요 |
WebRTC 연결 과정 (Signaling)¶
1. A가 B에 연결하려 함
2. A가 Offer 생성 (SDP)
3. A가 B에게 Offer 전송 (Signaling 서버 경유)
4. B가 Answer 생성
5. B가 A에게 Answer 전송
6. ICE Candidate 교환 → 최적 경로 결정
7. 데이터 채널로 P2P 통신 시작
장단점¶
| 장점 | 단점 |
|---|---|
| P2P 연결로 낮은 지연 시간 | STUN & TURN 서버 유지 필요 |
| 표준화된 브라우저 API | 다수의 참가자에게는 P2P가 비효율적 (SFU/MCU 필요) |
| 내장 암호화 (DTLS, SRTP) | Symmetric NAT 환경에서 복잡해짐 |
13. 통신 디자인 패턴¶
백엔드에서 클라이언트와 서버가 데이터를 주고받는 다양한 방식입니다.
① 요청-응답 (Request-Response)¶
가장 기본적인 패턴입니다. HTTP, DNS, SSH, RPC, 데이터베이스 프로토콜 등에서 사용됩니다.
장점: 간단하고 명확한 구조, 확장성 우수 단점: 여러 수신자에게 동시 전송 어려움, 높은 결합도
② 동기 vs 비동기 (Synchronous vs Asynchronous)¶
동기 I/O: 요청을 보낸 후 응답이 올 때까지 대기 (블로킹)
비동기 I/O: 요청을 보낸 후 응답을 기다리지 않고 다른 작업 수행 - 주기적으로 응답이 준비되었는지 확인 (epoll) - 응답이 준비되면 콜백 함수 호출 (io_uring)
비유: 동기 = 회의에서 질문하고 답을 기다림 / 비동기 = 이메일을 보내고 다른 일을 하다가 나중에 확인
③ Push (푸시)¶
서버가 클라이언트에게 데이터를 능동적으로 전송합니다.
장점: 실시간 데이터 전송 단점: 클라이언트가 항상 온라인 상태여야 함, 양방향 프로토콜 필요 사용 예시: 사용자 로그인 알림, RabbitMQ
④ Short Polling (짧은 폴링)¶
클라이언트가 주기적으로 서버에 상태를 확인합니다.
매 5초마다:
클라이언트: "새 메시지 있어?" → 서버: "아니"
클라이언트: "새 메시지 있어?" → 서버: "아니"
클라이언트: "새 메시지 있어?" → 서버: "응! 여기"
장점: 구현이 간단, 클라이언트가 연결을 끊을 수 있음 단점: 너무 많은 요청, 네트워크 대역폭 낭비 사용 예시: YouTube 비디오 업로드 진행 상태 확인
⑤ Long Polling (긴 폴링)¶
클라이언트가 요청을 보내면 서버가 응답할 준비가 될 때까지 연결을 유지합니다.
클라이언트: "새 메시지 있어?" → 서버
서버: (새 메시지가 올 때까지 대기... 30초 동안 응답하지 않음)
서버: (새 메시지 도착!) → "여기 새 메시지!"
클라이언트: (바로 다시 요청)
장점: Short Polling보다 통신량 적음, 거의 실시간 단점: 완전한 실시간은 아님, 타임아웃 처리 필요 사용 예시: Kafka에서 사용
⑥ Server-Sent Events (SSE)¶
서버에서 클라이언트로 단방향으로 이벤트를 보내는 방식입니다. HTTP 기반으로 동작합니다.
클라이언트: "이벤트 스트림 연결" → 서버
서버: ── event: update ── data: {"price": 50000} ──▶ 클라이언트
서버: ── event: update ── data: {"price": 50100} ──▶ 클라이언트
(서버가 원할 때마다 계속 보냄, 연결은 유지)
장점: HTTP 기반이라 기존 인프라와 호환, 자동 재연결 지원 단점: 단방향(서버→클라이언트)만 가능, HTTP/1.1에서는 연결 6개 제한 사용 예시: 실시간 뉴스 피드, 주식 시세, 알림
⑦ Publish-Subscribe (Pub/Sub, 발행-구독)¶
메시지 브로커를 통해 발행자가 보낸 메시지를 여러 구독자에게 전달합니다.
장점: 여러 수신자에게 확장 가능, 마이크로서비스에 적합, 느슨한 결합 단점: 메시지 전달 보장 문제, 복잡도 증가 사용 예시: 비디오 업로드 → 압축/변환/알림 서비스가 각각 처리
⑧ Multiplexing & Demultiplexing (다중화 & 역다중화)¶
- Multiplexing: 여러 스트림을 하나의 연결로 합치는 것 (예: HTTP/2)
- Demultiplexing: 하나의 연결을 여러 스트림으로 나누는 것
⑨ Stateful vs Stateless¶
| Stateful (상태 저장) | Stateless (무상태) | |
|---|---|---|
| 개념 | 서버가 클라이언트 상태를 메모리에 저장 | 클라이언트가 모든 요청에 상태 정보를 포함 |
| 예시 | TCP, gRPC | UDP, HTTP, JWT |
| 장점 | 빠른 응답 (상태 재전송 불필요) | 서버 재시작해도 워크플로우 지속, 확장성 우수 |
| 단점 | 서버 장애 시 상태 손실 | 요청 크기 증가 |
⑩ Sidecar Pattern (사이드카 패턴)¶
각 서비스 옆에 프록시를 배치하여 복잡한 프로토콜 처리를 대신 담당하는 패턴입니다.
장점: 언어에 독립적(Polyglot), 프로토콜 업그레이드 쉬움, 추적/모니터링/보안 강화 단점: 복잡도 증가, 지연 시간 증가 (추가 홉) 사용 예시: Service Mesh — Linkerd, Istio, Envoy
통신 패턴 선택 가이드¶
| 패턴 | 사용 시기 |
|---|---|
| Request-Response | 일반적인 API, 단순 요청-응답 |
| Push | 실시간 알림, 클라이언트가 항상 온라인 |
| Short Polling | 간단한 상태 확인, 주기적 업데이트 |
| Long Polling | 서버 Push가 안 되지만 실시간성 필요 |
| SSE | 서버에서 클라이언트로 실시간 이벤트 스트림 |
| Pub/Sub | 마이크로서비스, 여러 수신자 |
| WebSocket | 양방향 실시간 통신 |
14. 백엔드 실행 패턴¶
Process vs Thread¶
| Process (프로세스) | Thread (쓰레드) | |
|---|---|---|
| 메모리 | 독립적인 메모리 공간 | 부모 프로세스와 메모리 공유 |
| 식별자 | PID | Thread ID |
| 격리 | 완전 격리 | Race Condition 가능 |
실행 모델¶
1. Single-Threaded Process¶
- 하나의 프로세스, 하나의 쓰레드
- 간단함 / 예: Node.js
2. Multi-Process¶
- 여러 프로세스, 각각 독립적인 메모리
- 멀티코어 활용, 격리되어 안전
- 예: NGINX, PostgreSQL
3. Multi-Threaded¶
- 하나의 프로세스, 여러 쓰레드 (메모리 공유)
- Race Condition 가능 → Lock과 Latch 필요
- 예: Apache, Envoy
최적 개수: 경험 법칙 — 코어 개수 = 프로세스/쓰레드 개수 너무 많으면 CPU 컨텍스트 스위칭 오버헤드 증가
SYN/Accept Queue (연결 수립 흐름)¶
클라이언트 → SYN → [SYN Queue]
↓ 서버가 SYN/ACK 전송
클라이언트 → ACK → [Accept Queue]
↓ 애플리케이션이 accept() 호출
[파일 디스크립터 생성]
Receive / Send Buffer¶
- Receive Buffer: 커널이 수신 데이터를 임시 저장, 앱이 read() 호출하여 읽음
- Send Buffer: 앱이 send() 호출, 커널이 큐에 저장 후 전송
백엔드가 충분히 빠르게 읽지 못하면 Receive Queue가 가득 차고 클라이언트 속도가 저하됩니다.
Idempotency (멱등성)¶
동일한 요청을 여러 번 보내도 결과가 같고, 백엔드 상태에 중복 영향을 주지 않는 성질입니다.
구현 방법: Request ID를 사용하여 이미 처리된 ID면 결과만 반환
| HTTP 메서드 | 멱등성 |
|---|---|
| GET | ✅ 멱등적 (브라우저가 자동 재시도) |
| POST | ❌ 멱등적이지 않음 (구현으로 가능) |
| PUT / DELETE | ✅ 멱등적 |
중요: 금융 시스템에서 매우 중요 — 중복 결제 방지
15. 프록시와 로드 밸런서¶
Forward Proxy vs Reverse Proxy¶
포워드 프록시: [클라이언트] → [프록시] → [인터넷] → [서버]
(클라이언트 IP 숨김, 접근 제어)
리버스 프록시: [클라이언트] → [인터넷] → [리버스 프록시] → [서버1, 서버2, ...]
(서버 IP 숨김, 로드 밸런싱)
대표적 도구: Nginx, HAProxy, AWS ALB
로드 밸런싱 알고리즘¶
| 알고리즘 | 설명 |
|---|---|
| 라운드 로빈 | 순서대로 돌아가며 분배 (1→2→3→1→...) |
| 가중 라운드 로빈 | 성능 좋은 서버에 더 많이 분배 |
| 최소 연결 | 현재 연결이 가장 적은 서버에 분배 |
| IP 해시 | 클라이언트 IP 기반으로 항상 같은 서버 (Sticky Session) |
| 최소 응답 시간 | 응답이 가장 빠른 서버에 분배 |
Layer 4 vs Layer 7 로드 밸런서¶
| L4 로드 밸런서 | L7 로드 밸런서 | |
|---|---|---|
| 동작 수준 | TCP/UDP (IP + 포트만 확인) | HTTP (URL, 헤더, 쿠키 등 확인) |
| 속도 | 빠름 (데이터 내용 미확인) | 약간 느림 |
| 캐싱 | ❌ | ✅ |
| 마이크로서비스 | 제한적 | ✅ 적합 |
| 예시 | AWS NLB | AWS ALB, Nginx |
L7 로드 밸런서 라우팅 예시:
16. 정리 & 프로토콜 비교표¶
전체 프로토콜 스택 흐름¶
사용자가 https://example.com/api/data 에 접속하면:
1. DNS → example.com의 IP 주소를 알아냄
2. TCP → 3-Way Handshake로 연결 수립
3. TLS → 암호화 협상
4. HTTP → GET /api/data 요청 전송
5. 서버 → 요청 처리 후 응답 반환
6. TCP → 데이터의 순서 보장 및 재전송
7. TLS → 응답 데이터 복호화
8. 브라우저 → 데이터를 화면에 표시
프로토콜 비교표¶
| 항목 | HTTP/1.1 | HTTP/2 | HTTP/3 | WebSocket | gRPC |
|---|---|---|---|---|---|
| 전송 계층 | TCP | TCP | QUIC(UDP) | TCP | HTTP/2(TCP) |
| 데이터 형식 | 텍스트 | 바이너리 | 바이너리 | 바이너리/텍스트 | Protobuf(바이너리) |
| 멀티플렉싱 | ❌ | ✅ | ✅ | N/A | ✅ |
| 서버 푸시 | ❌ | ✅ | ✅ | ✅ (양방향) | ✅ (스트리밍) |
| HOL Blocking | 있음 | TCP 수준 있음 | 없음 | 있음 | TCP 수준 있음 |
| 헤더 압축 | ❌ | HPACK | QPACK | ❌ | HPACK |
| 주 사용처 | 일반 웹 | 웹, API | 모바일, 웹 | 실시간 통신 | 마이크로서비스 |
프로토콜 선택 가이드¶
"일반적인 웹 API를 만든다" → HTTP/1.1 또는 HTTP/2 + REST
"고성능 마이크로서비스 통신이 필요하다" → gRPC
"실시간 양방향 통신이 필요하다" → WebSocket
"서버→클라이언트 단방향 알림이 필요하다" → SSE
"모바일 환경에서 빠른 통신이 필요하다" → HTTP/3 (QUIC)
"P2P 실시간 음성/영상 통신이 필요하다" → WebRTC
"속도 중요, 일부 패킷 손실 허용" → UDP
핵심 키워드 요약¶
| 키워드 | 한줄 설명 |
|---|---|
| TCP | 신뢰성 있는 전송, 순서 보장 |
| UDP | 비신뢰성, 순서 무관, 빠름 |
| TLS | 데이터 암호화, HTTPS의 S |
| HTTP/2 | 멀티플렉싱, 헤더 압축, 바이너리 |
| HTTP/3 | QUIC 기반, TCP HOL Blocking 해결 |
| WebSocket | 양방향 실시간 통신 |
| gRPC | 고성능 RPC, Protobuf, HTTP/2 기반 |
| SSE | 서버→클라이언트 단방향 스트리밍 |
| WebRTC | P2P 실시간 음성/영상 |
| Pub/Sub | 이벤트 기반, 느슨한 결합 |
| 리버스 프록시 | 서버 앞단에서 대리, 로드밸런싱 |
| 멱등성 | 동일 요청 여러 번 보내도 결과 동일 |
| HOL Blocking | 앞의 데이터가 막히면 뒤도 막히는 현상 |
| Sidecar | 서비스 옆 프록시, Service Mesh 구성 요소 |
17. 학습 팁¶
-
기초부터 차근차근: OSI 모델, TCP/IP 모델부터 이해한 뒤 프로토콜을 공부하세요.
-
실습이 중요: 각 통신 패턴과 프로토콜을 직접 구현해보세요. curl, Wireshark, Postman 등의 도구를 활용하세요.
-
Trade-off 이해: 각 방법의 장단점을 이해하고 상황에 맞게 선택하세요. 항상 복잡한 것이 좋은 것은 아닙니다.
-
성능 vs 복잡도: 단순한 HTTP/1.1이 많은 경우에 충분합니다. 성능이 필요할 때 HTTP/2, gRPC로 올라가세요.
-
실무 사례 학습: 실제 서비스들이 어떤 방식을 사용하는지 조사해보세요. Netflix는 gRPC, Slack은 WebSocket, YouTube는 HTTP/2 등.
18. 추가 학습 자료¶
- TCP/IP 상세: RFC 793 (TCP), RFC 768 (UDP)
- HTTP/2, HTTP/3: RFC 7540 (HTTP/2), RFC 9114 (HTTP/3)
- WebRTC: MDN Web Docs — WebRTC API
- gRPC: grpc.io 공식 문서
- 로드 밸런싱: NGINX, HAProxy 공식 문서
- Service Mesh: Istio, Linkerd 공식 문서
- Kafka (Pub/Sub): kafka.apache.org