네트워크 레이턴시 진단 & 최적화 — CDN·DNS·TCP/TLS 튜닝
응답이 느린 원인이 항상 서버 코드에 있는 것은 아닙니다. 네트워크 구간 레이턴시가 전체 응답 시간의 50% 이상을 차지하는 경우도 흔합니다.
레이턴시 구성 요소 분해
섹션 제목: “레이턴시 구성 요소 분해”전체 응답 시간 = DNS 조회 + TCP 연결 (handshake) + TLS 협상 + 요청 전송 + 서버 처리 (TTFB) + 응답 수신브라우저 DevTools → Network 탭의 Timing 패널에서 각 구간을 확인할 수 있습니다.
DNS 최적화
섹션 제목: “DNS 최적화”TTL 설정
섹션 제목: “TTL 설정”# 운영 환경 DNS TTL 권장값A 레코드: 300초 (5분)CNAME 레코드: 300초 (5분)MX 레코드: 3600초 (1시간)DNS Prefetch
섹션 제목: “DNS Prefetch”HTML에서 미리 DNS를 조회해 둡니다.
<link rel="dns-prefetch" href="//api.testforge.kr"><link rel="preconnect" href="https://api.testforge.kr" crossorigin>preconnect는 DNS + TCP + TLS까지 미리 수행합니다.
TCP 최적화
섹션 제목: “TCP 최적화”Keep-Alive 설정
섹션 제목: “Keep-Alive 설정”매 요청마다 TCP 연결을 새로 맺는 것은 낭비입니다.
# Nginx Keep-Alive 설정http { keepalive_timeout 65; # 65초간 연결 유지 keepalive_requests 1000; # 연결당 최대 요청 수}
# 업스트림 서버와도 Keep-Alive 사용upstream backend { server api:8080; keepalive 32; # 최대 32개 유휴 연결 유지}Connection Pool (애플리케이션 레벨)
섹션 제목: “Connection Pool (애플리케이션 레벨)”import httpx
# 클라이언트 재사용 (연결 풀링)client = httpx.Client( limits=httpx.Limits( max_connections=100, max_keepalive_connections=20, keepalive_expiry=30, ))
# 매 요청마다 새 클라이언트를 만들지 마세요response = client.get("https://api.testforge.kr/scan")TLS 최적화
섹션 제목: “TLS 최적화”TLS 1.3 사용
섹션 제목: “TLS 1.3 사용”TLS 1.3은 핸드셰이크가 1-RTT로 단축됩니다 (TLS 1.2는 2-RTT).
ssl_protocols TLSv1.2 TLSv1.3;ssl_prefer_server_ciphers off; # TLS 1.3에서는 클라이언트 우선Session Resumption
섹션 제목: “Session Resumption”이전 TLS 세션을 재사용해 핸드셰이크를 생략합니다.
ssl_session_cache shared:SSL:10m;ssl_session_timeout 1d;ssl_session_tickets off; # 보안상 tickets보다 session cache 권장CDN으로 물리적 거리 단축
섹션 제목: “CDN으로 물리적 거리 단축”서울 서버가 뉴욕 사용자에게 응답하면 RTT만 150ms 이상 발생합니다. CDN의 엣지 노드가 지리적으로 가까운 곳에서 응답합니다.
Cloudflare 설정 체크리스트
섹션 제목: “Cloudflare 설정 체크리스트”✅ Proxy 활성화 (오렌지 구름 아이콘)✅ HTTP/2 활성화✅ HTTP/3 (QUIC) 활성화✅ Brotli 압축 활성화✅ Early Hints 활성화✅ Argo Smart Routing (유료) — 최적 경로 선택압축 설정
섹션 제목: “압축 설정”# Nginx Gzip/Brotli 압축gzip on;gzip_types text/plain application/json application/javascript text/css;gzip_min_length 1000;gzip_comp_level 6;압축 효과: JSON API 응답 기준 60~80% 크기 감소.
HTTP/2 & HTTP/3
섹션 제목: “HTTP/2 & HTTP/3”| 프로토콜 | 특징 | 권장 상황 |
|---|---|---|
| HTTP/1.1 | 연결당 1요청 | 레거시 환경 |
| HTTP/2 | 멀티플렉싱, 헤더 압축 | 기본값으로 사용 |
| HTTP/3 (QUIC) | UDP 기반, 패킷 손실에 강함 | 모바일, 불안정한 네트워크 |
레이턴시 측정 도구
섹션 제목: “레이턴시 측정 도구”# curl로 구간별 레이턴시 측정curl -w "\n namelookup: %{time_namelookup}s connect: %{time_connect}s tls: %{time_appconnect}s pretransfer: %{time_pretransfer}s ttfb: %{time_starttransfer}s total: %{time_total}s\n" \ -o /dev/null -s https://api.testforge.kr/health# 전 세계 레이턴시 확인mtr api.testforge.kr # 패킷 경로 추적traceroute api.testforge.kr # 홉별 레이턴시부하테스트로 레이턴시 검증
섹션 제목: “부하테스트로 레이턴시 검증”최적화 후 실제 부하 상황에서 레이턴시 변화를 측정하세요.
목표 지표:- P50 (중앙값) < 100ms- P95 < 300ms- P99 < 500ms다음 단계
섹션 제목: “다음 단계”이 가이드를 내 서비스에 직접 적용해 보세요.
TestForge 무료 스캔 시작 →