[학습] HTTP/1.1 vs HTTP/2 심화 + WebSocket + TLS

TL;DR — HTTP/1.1은 TCP 연결당 요청 하나씩 순차(HOL blocking). HTTP/2는 단일 연결에서 스트림 병렬. gRPC를 선택하는 실질 이유는 Protobuf(3~5배 payload 절감) + 타입 계약이고, HTTP/2 멀티플렉싱은 부차적. WebSocket은 HTTP Upgrade(101) 후 양방향 상시 연결. TLS는 비대칭으로 세션키 교환 → 이후 대칭키 암호화.

---

1. HTTP/1.1 연결 모델

"한 번에 1개"는 하나의 TCP 연결에서 그렇다는 뜻. 서버 스레드 블로킹이 아니라, TCP 연결 자체가 응답이 올 때까지 다음 요청을 못 보냄.

```

TCP 연결 1개: [요청1] → (대기) → [응답1] → [요청2] → ...

↑ 이 동안 이 연결에서 다른 요청 불가

```

서버: thread-per-connection. 연결 100개 = 스레드 100개
브라우저 우회: TCP 연결 6~8개 동시에 열어서 병렬

HTTP/1.1 vs 2 요약

	HTTP/1.1	HTTP/2
단위	TCP 연결당 요청 1개 순차	TCP 연결 1개 위에 스트림 N개
동시성	HOL blocking	스트림 병렬, 응답 순서 자유
서버 모델	thread-per-connection	비동기/이벤트 루프 최적
헤더	평문 반복	HPACK 압축

---

2. gRPC의 실질적 이점

OpenAPI codegen(OkHttp, Feign) 기본값 = HTTP/1.1. HTTP/2는 의도적 선택이 필요.

서비스 간 통신에서 gRPC 선택 이유의 실질 우선순위:

1. Protobuf — JSON 대비 payload 3~5배 작음, 직렬화 빠름 → 실질 성능 차이의 주원인

2. 강한 타입 계약 — .proto 파일이 단일 진실의 원천, 컴파일 타임 검증

3. 양방향 스트리밍 — HTTP/1.1로는 불가능한 패턴

4. HTTP/2 멀티플렉싱 — 초고부하(수만 동시 요청)에서만 체감, 일반 케이스 부차적

> HTTP/1.1도 keep-alive + connection pool이면 연결 재사용. 멀티플렉싱이 극적인 차이는 연결 수 자체가 병목인 수천 req/s 이상.

ConnectRPC (Trillion Labs 스택)

Buf가 만든 gRPC 상위 호환:

gRPC: HTTP/2 전용, 브라우저 직접 불가 (grpc-web 프록시 필요)
ConnectRPC: HTTP/1.1·2·3 모두, 브라우저 직접 호출 가능

TypeScript 프론트 + Go 백엔드 조합에서 .proto 하나로 브라우저·서버 양쪽 타입 코드젠.

---

3. WebSocket

HTTP는 클라이언트가 요청해야 서버가 응답. 서버가 먼저 push해야 할 때(실시간 채팅, 알림) WebSocket.

연결 원리

```

클라이언트 → 서버: HTTP/1.1 GET /chat

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Key: dGhlIHNhbXBsZQ==

서버 → 클라이언트: 101 Switching Protocols

Upgrade: websocket

← 이후 양방향 상시 연결 (HTTP 아님)

```

HTTP Upgrade로 시작, 101 응답 이후 같은 TCP 연결을 양방향 프레임 전송으로 전환.

**Long Polling vs WebSocket**: Long Polling은 클라이언트가 요청, 서버가 이벤트까지 안 끊는 방식. WebSocket은 서버가 먼저 push 가능
**채널톡 문맥**: 상담원 실시간 알림. 수만 연결을 유지해야 해서 Go/Node.js(고루틴/이벤트 루프) 레이어 담당
**wss://**: TLS 위의 WebSocket. Upgrade가 TLS 채널 위에서 일어남

AWS API Gateway + WebSocket 이슈

API Gateway는 클라이언트-백엔드 사이의 프록시 레이어. idle 상태에서 timeout 발생.

**대응**: heartbeat ping/pong을 20~25초 간격으로 전송해 idle 판정 방지
**디버깅 라인**: ① heartbeat 존재 여부 → ② close code(1001/1006) → ③ ALB idle timeout → ④ GC로 연결 객체 소멸

---

4. TLS Handshake

HTTPS = HTTP + TLS. 암호화 채널 먼저, 그 위에서 HTTP.

```

1. ClientHello → 지원 암호화 방식 목록

2. ServerHello ← 방식 선택 + 인증서

3. 인증서 검증 → CA 체인으로 서버 신원 확인

4. 키 교환 → 공개키로 세션키(대칭키) 교환

5. 이후 통신 → 대칭키로 암호화 (빠름)

```

비대칭+대칭 혼용 이유: 비대칭(RSA/ECDH)은 안전하지만 느림. 핸드셰이크에서만 쓰고, 이후는 세션키(대칭)로 고속 처리.

---

면접 핵심 포인트

주제	한 줄
HTTP/1.1 vs 2	TCP 연결당 순차 vs 스트림 병렬. 서비스 간은 1.1 기본
gRPC 선택 이유	Protobuf + 타입 계약. 멀티플렉싱은 부차적
WebSocket	HTTP Upgrade → 101 → 양방향. heartbeat 필수
TLS	비대칭으로 세션키 교환 → 대칭키 고속 통신

면접 함정 질문

Q: "HTTP/2가 항상 빠른가요?" → A: 서비스 간 통신은 1.1 + connection pool로 충분. HTTP/2는 초고부하 또는 gRPC 도입 시 부수효과
Q: "gRPC = HTTP/2 이점인가요?" → A: 실질 이점은 Protobuf(바이너리) + 타입 계약. HTTP/2는 수단
Q: "WebSocket 연결이 자꾸 끊어지면?" → A: heartbeat 유무 먼저, 다음 LB idle timeout (ALB 60초), close code 확인

복습 일정

단계	날짜	완료
Day 0 (초학습)	2026-05-24	☐
Day 7	2026-05-31	☐
Day 37	2026-06-30	☐
Day 127	2026-09-28	☐

참고

See also: extends: [채널톡 면접 준비 전체](../synthesis/2026-05-24-channeltalk-interview-prep.md)