1. TCP vs UDP, 그리고 HTTP/3
TCP
- 연결 지향적 (3-way handshake)
- 패킷 손실 시 재전송 → 신뢰성 보장
- HTTP/1.1, HTTP/2에서 사용
UDP
- 비연결성, 빠름, 신뢰성 낮음
- 스트리밍, 게임, DNS 등에서 활용
HTTP/3 (QUIC 기반)
- TCP 대신 UDP 사용
- 장점:
- 연결 복구가 빠름 (모바일 네트워크 전환 시 유리)
- 지연시간 감소
- TLS 1.3 내장
- 패킷 순서 보장 + 손실 복구 지원
- 스트림 단위 멀티플렉싱
💡 실무 팁
HTTP/3는 모바일 환경에서 특히 효과적이며, CDN과 함께 쓰면 성능 향상이 큼.
2. Keep-Alive와 연결 재사용
- HTTP/1.0: 요청마다 연결 종료
- HTTP/1.1: Keep-Alive로 한 연결에서 여러 요청 가능
- HTTP/2: 멀티플렉싱으로 동시 요청/응답 처리
- HTTP/3: 스트림 단위 처리로 지연 및 혼잡 제어 최적화
💡 실무 팁
API 서버 부하가 크다면 Nginx나 AWS ALB에서 Keep-Alive 및 커넥션 풀 최적화 필요.
3. TLS(HTTPS) 동작 원리
- Handshake
- 서버 인증서 교환
- 대칭키 교환을 위한 비대칭키 사용
- 대칭키 암호화 전환
- 이후 데이터는 대칭키로 암호화 (속도 향상)
- 세션 재사용
- TLS 세션 ID로 재접속 시 핸드셰이크 단축
💡 실무 팁
HTTP/2 + TLS 세션 재사용 + CDN 캐싱 조합 → TLS 오버헤드 최소화 가능.
4. Stateless와 인증 토큰
- 쿠키: 브라우저 저장, 자동 전송. 서버 부하 없음. (단, 탈취 위험)
- 세션: 서버 저장. 보안 우수. (확장 시 세션 공유 필요)
- JWT: 인증 정보 자체를 토큰에 담아 클라이언트 보관. 무상태 유지 가능.
Refresh Token 전략
- Access Token: 15~30분
- Refresh Token: 2주~1달
- Refresh 시 서버에서 재발급 및 로그 기록
💡 실무 팁
JWT는 스케일 아웃에 유리하지만, 탈취 시 만료 전까지 취소 불가하므로 블랙리스트 관리 필요.
5. 실무 트러블 예시
“사용자는 로그인했는데 특정 API에서 401 발생”
가능한 원인:
- Access Token 만료 + Refresh 실패
- 서버와 클라이언트의 시계(clock) 불일치
- 로드 밸런서에서 Authorization 헤더 필터링
- HTTPS → HTTP 리다이렉트 시 쿠키 손실
6. HTTP/3가 UDP 기반인 이유
- TCP는 연결 복구 과정에서 지연 발생
- UDP는 연결 설정이 빠르고 네트워크 전환 시 끊김이 적음
- 단점 보완: QUIC이 패킷 순서 보장, 손실 복구, TLS 1.3 내장 기능 제공