웹 브라우저 요청 흐름

브라우저 주소창에 https://example.com을 입력하면 화면에 페이지가 뜨기까지 생각보다 많은 단계가 지나간다.
개발자로서 이 흐름을 이해하면 장애 분석, 성능 튜닝, 네트워크 문제 디버깅이 훨씬 쉬워진다.

1) 사용자가 URL을 입력한다

예: https://api.example.com/users/123?sort=desc

브라우저는 URL을 파싱해서 아래 정보를 뽑는다.

• scheme: https (HTTPS로 통신)
• host: api.example.com (접속할 서버)
• path/query: /users/123?sort=desc (요청할 자원)

2) DNS 조회로 IP를 찾는다

브라우저는 api.example.com을 바로 통신에 쓸 수 없기 때문에 DNS로 IP를 구한다.

대략 흐름:

1. 브라우저/OS 캐시 확인
2. 설정된 DNS 서버(리졸버)에게 질의
3. IP 응답을 받음(캐시/TTL 영향 가능)

결과 예:

• api.example.com → 203.0.113.10

3) (필요하면) PORT를 결정한다

URL에 포트가 없으면 기본값을 사용한다.

• HTTP: 80
• HTTPS: 443

예: https://api.example.com → 203.0.113.10:443

4) TCP 연결을 만든다 (HTTP의 “길” 만들기)

대부분의 HTTP 통신은 TCP 위에서 이뤄진다.
브라우저는 서버와 TCP 연결(3-way handshake) 을 맺어 데이터가 오갈 통로를 만든다.

5) HTTPS라면 TLS 핸드셰이크가 추가된다

URL이 https://라면, TCP 연결 후에 TLS(암호화) 핸드셰이크가 한 번 더 일어난다.

• 서버 인증서 검증
• 암호화 키 협상
• 이후부터는 데이터가 암호화된 채로 전송됨

즉, HTTPS는 “TCP 연결 + TLS 보안 설정”까지 끝나야 HTTP 메시지를 주고받을 수 있다.

6) 브라우저가 HTTP 요청을 보낸다

이제 실제 요청이 날아간다.

예시(개념):

• Method: GET
• Path: /users/123?sort=desc
• Headers: Host, Accept, Cookie, Authorization 등

7) 서버 처리 → HTTP 응답 반환

서버는 요청을 받아서 로직을 처리하고 응답을 만든다.

• Status code: 200/301/404/500…
• Headers: Content-Type, Cache-Control…
• Body: HTML/JSON/이미지 등

8) 브라우저가 응답을 해석하고 화면에 반영한다

• HTML이면 파싱해서 DOM 생성
• CSS 적용, JS 실행
• 추가 리소스(이미지/CSS/JS)가 있으면 추가 요청이 계속 발생한다

여기서 성능 이슈가 자주 생긴다:

• 리소스가 많을수록 요청 횟수 증가
• 캐시 정책에 따라 재요청 발생
• API 호출이 많으면 렌더링 지연

디버깅 체크포인트

문제가 생기면 어느 단계가 막혔는지 구분하는 게 핵심이다.

• DNS 문제: 도메인이 IP로 안 바뀜(“서버를 못 찾음”)
• TCP 문제: 연결 자체가 안 됨(방화벽/포트/서버 다운)
• TLS 문제: 인증서 오류/암호화 협상 실패(HTTPS만)
• HTTP 문제: 4xx/5xx, 응답 지연, CORS 등

한 줄 요약

URL 입력 → DNS로 IP 획득 → (포트 결정) → TCP 연결 → (HTTPS면 TLS) → HTTP 요청/응답 → 렌더링