브라우저 주소창에 URL을 입력하면 웹사이트가 뜨기까지 무슨 일이 일어날까

브라우저가 패킷을 보내려면 먼저 단말에 어떤 설정이 준비되어 있어야 할까↑

브라우저가 먼저 만드는 것은 Ethernet 프레임이 아니라 목적지 이름을 해석할 준비입니다. 단말에는 자신의 IP 주소와 Prefix, Default Gateway, DNS 서버가 있어야 합니다. 이 값은 수동으로 넣거나 DHCP와 IPv6 라우터 Advertisement 같은 절차로 받습니다.

DNS 결과와 연결 정보가 캐시에 남아 있으면 일부 질의는 생략될 수 있습니다. 따라서 패킷 캡처에 DNS가 보이지 않는다고 DNS가 전혀 사용되지 않았다고 결론 내리면 안 됩니다.

고정 사례로 단말 10.0.0.25/24, Default Gateway 10.0.0.1, DNS 서버 10.0.0.53을 사용하겠습니다. 브라우저가 이름을 Resolver에 넘길 때 운영체제는 DNS 서버로 보낼 Route와 Next Hop부터 찾습니다. 즉 DNS는 웹 접속의 준비 단계이지만, DNS Query 자체도 이미 IP Route와 L2 전달을 필요로 합니다. 설정값 가운데 하나라도 빠지면 “웹 패킷”을 만들기 전 준비 통신에서 멈출 수 있습니다.

Cache는 이 순서를 화면에서 숨깁니다. DNS Cache가 남아 있으면 Query가 보이지 않고, ARP Cache가 남아 있으면 Gateway를 묻는 Broadcast가 생략됩니다. 이미 열린 HTTP/2 Connection을 재사용하면 새 TCP Handshake도 보이지 않을 수 있습니다. 패킷 캡처를 해석할 때는 보이지 않는 단계가 실패한 것인지, 이전에 완료되어 저장된 결과를 재사용한 것인지 Cache·Connection 상태와 함께 판단해야 합니다.

관찰한 캡처에 준비 과정이 항상 나타나는 것은 아닙니다. DHCP Lease, DNS Answer, ARP Entry와 기존 연결이 Cache에 남아 있으면 브라우저는 그 결과를 재사용합니다. 따라서 어떤 패킷이 보이지 않을 때는 “그 단계가 없었다”고 단정하기 전에 Cache와 상태의 생성 시각·만료 시각을 확인해야 합니다.

이 절의 근거 IETF RFC 1034 · IETF RFC 2131 · IETF RFC 4861

도해에서 확인할 내용 단말의 자동 할당과 수동 설정을 서로 다른 대안으로 비교합니다. DHCP DORA의 네 메시지와 고정 IP·Mask·Gateway 값을 읽고, 수동 주소 10.0.0.25를 동적 풀에서 제외하는 조건을 확인합니다. DNS 값은 이 도해에 별도로 표시하지 않았습니다.

브라우저에 입력한 이름은 DNS를 거쳐 어떤 IP 주소가 될까↑

브라우저는 운영체제의 Resolver에 www.imbizcorp.com의 주소를 요청합니다. Resolver는 캐시를 확인하고 필요하면 설정된 DNS 서버에 질의합니다. 응답에는 IPv4의 A 레코드나 IPv6의 AAAA 레코드가 올 수 있습니다.

DNS는 서버까지 패킷을 운반하지 않습니다. 다음 단계가 사용할 목적지 IP 주소를 알려 줍니다. 여러 주소가 오면 운영체제와 애플리케이션이 주소 선택과 연결 시도 순서를 결정합니다.

www.imbizcorp.com이 CNAME을 거쳐 여러 A·AAAA Record로 이어질 수도 있습니다. Resolver는 응답의 TTL 동안 결과를 Cache에 보관하고, 클라이언트는 주소 선택 정책과 연결 성공 여부에 따라 어느 주소를 먼저 사용할지 결정합니다. 따라서 같은 이름을 입력한 두 단말이 같은 순간에도 다른 서버 IP를 선택할 수 있습니다. CDN과 Load Balancer 환경에서는 이 차이가 정상 동작일 수 있습니다.

DNS Answer가 있다는 사실과 그 주소의 서비스가 열린다는 사실은 별개입니다. 2026-09-03 확인 당시 www.imbizcorp.com의 A 레코드 응답 가운데 하나는 104.21.30.148이었습니다. 이 주소가 선택됐다면 다음 단계부터는 이 IP와 포트를 가진 새로운 흐름을 추적해야 합니다. 잘못된 Record라면 네트워크는 그 잘못된 목적지까지 패킷을 정확히 전달할 수도 있습니다. 장애 조사에서는 Query Name, Record Type, 선택된 IP와 TTL을 기록해야 “이름 해석 성공”이라는 표현 안에 잘못된 목적지 문제가 숨지 않습니다.

DNS의 책임은 서버까지 패킷을 전달하는 것이 아니라 다음 단계가 사용할 목적지 정보를 제공하는 데 있습니다. 여러 주소 가운데 무엇을 먼저 시도할지, 실패 뒤 다른 주소로 언제 전환할지는 운영체제와 애플리케이션의 정책에 달려 있습니다. 장애 분석에서는 Query 이름, 응답 주소, TTL, 응답 Code와 브라우저가 실제 선택한 주소를 같은 것으로 가정하지 않고 각각 기록합니다.

이 절의 근거 IETF RFC 1034

도해에서 확인할 내용 본문의 DNS 서버 10.0.0.53과 달리 공유기 DNS 프록시가 8.8.8.8에 질의를 전달하는 별도 예시입니다. Stub Resolver에서 Recursive Resolver를 거쳐 Root·TLD·Authoritative 서버를 조회하는 DNS 탐색을 따라갑니다. 캐시에 답이 없는 경우의 세 질의와 A 레코드 104.21.30.148을 돌려받아 단말 캐시에 저장하는 과정을 확인합니다.

서버의 IP를 알아낸 뒤에도 TCP와 TLS가 준비해야 할 것이 남아 있다↑

HTTPS라면 브라우저는 보통 서버의 TCP 포트 443에 연결합니다. TCP의 SYN, SYN-ACK, ACK는 양쪽이 사용할 순서 번호와 연결 가능 상태를 맞춥니다. 그 위에서 TLS가 암호 알고리즘과 키를 합의하고 서버 인증서를 검증합니다.

DNS가 성공해도 이 단계는 실패할 수 있습니다. 방화벽이 포트를 막거나 서버 프로세스가 듣고 있지 않으면 TCP 연결이 완성되지 않습니다. 인증서 이름이나 신뢰 체인이 맞지 않으면 TCP는 연결되어도 TLS가 중단될 수 있습니다.

클라이언트가 임시 Source 포트 51514를 골라 104.21.30.148:443으로 SYN을 보내면 두 끝점은 이 4개의 주소·포트와 TCP라는 프로토콜을 기준으로 흐름을 구분합니다. SYN-ACK이 돌아오고 ACK가 전달되어야 애플리케이션 데이터를 안정적으로 주고받을 TCP 상태가 만들어집니다. RST가 오면 목적지나 중간 장비에서 연결을 거부했을 가능성이 있습니다. 해당 포트의 상태와 경로상 정책을 확인하되, 수신만으로 최종 목적지에 도달했다고 단정하지 않습니다. 아무 응답이 없으면 폐기와 반환 경로를 더 확인해야 합니다.

TLS Handshake에서는 ClientHello의 서버 Name과 지원 Cipher, 서버의 Certificate와 Key 합의가 오갑니다. 이 단계에서 실패하면 TCP 캡처에는 정상적인 연결 뒤 Alert 또는 종료가 보일 수 있습니다. 현대 브라우저는 HTTP/3를 위해 UDP 기반 QUIC을 사용할 수도 있지만, 이 글의 TCP/TLS 사례에서 중요한 원리는 같습니다. DNS 성공, Transport 연결, 암호화된 애플리케이션 세션은 서로 다른 완료 조건을 가지므로 어느 단계까지 진행되었는지 구분해야 합니다.

DNS가 성공해도 방화벽이 TCP/443을 막거나 서버 Process가 Listen하지 않으면 연결은 그 다음으로 가지 못합니다. TCP가 성공해도 인증서 또는 TLS 정책 때문에 중단될 수 있습니다. HTTP/3처럼 QUIC와 UDP를 쓰는 경우에는 Transport 형태가 달라지므로, 이 글의 TCP 흐름은 대표 경로이지 모든 브라우저 연결의 고정 순서가 아닙니다.

이 절의 근거 IETF RFC 9293 · IETF RFC 8446

도해에서 확인할 내용 TCP 3-Way Handshake 메시지의 Seq·Ack 값과 서버 Kernel의 SYN 큐·Accept 큐 처리를 비교합니다. 연결이 완성된 뒤 애플리케이션이 소켓을 꺼내고 TLS 1.3 Handshake를 시작하는 위치를 확인합니다. Linux·nginx의 일반적인 처리 예이며, 대상 사이트의 실제 서버 구성을 확인한 도해는 아닙니다.

패킷은 라우터를 지날 때마다 다음에 건널 링크를 새로 준비한다↑

각 라우터는 목적지 IP를 자신의 전달 테이블과 비교해 Next Hop과 출력 인터페이스를 고릅니다. 가정이나 기업 경계에서 NAT/PAT를 사용하면 출발지 주소·포트의 대응 관계가 만들어지고 패킷 헤더와 Checksum이 조정될 수 있습니다.

라우터는 전체 인터넷 경로를 패킷에 적어 두지 않습니다. 현재 장비가 아는 Next Hop으로 한 단계씩 보냅니다. 중간 장비마다 TTL 또는 홉 Limit가 줄어드는 이유도 무한 전달을 막기 위해서입니다.

첫 라우터는 104.21.30.148과 가장 길게 일치하는 FIB Entry를 찾아 출력 인터페이스와 Next Hop을 선택합니다. Ethernet 링크라면 Next-Hop MAC을 알아내 새 프레임을 만들고, 기존 프레임 헤더는 버립니다. 다음 라우터도 같은 IP Destination을 자신의 FIB에서 독립적으로 조회합니다. 패킷에는 “남은 라우터 목록”이 들어 있지 않으므로 중간의 한 라우터가 다른 Route를 선택하면 요청 경로가 바뀔 수 있습니다.

경계 NAT가 Source를 10.0.0.25:51514에서 198.51.100.8:40001로 바꾸면 바깥 캡처에서는 내부 주소가 보이지 않습니다. 그러나 Destination 104.21.30.148:443과 TCP 흐름의 연속성은 유지됩니다. 각 홉에서 줄어드는 TTL, L2 헤더 교체, 경계의 NAT Mapping을 시간순으로 놓으면 동일한 패킷이 어디에서 어떤 값으로 바뀌었는지 확인할 수 있습니다. 이 기록이 여러 장비의 로그를 한 통신으로 연결하는 기준이 됩니다.

경계에서 NAT/PAT를 사용한다면 Source IP·포트의 대응 관계가 생성되고 헤더와 Checksum이 바뀔 수 있습니다. 캡처의 안쪽 Tuple과 바깥쪽 Tuple이 다르더라도 TCP Sequence Number·Flag·시각을 맞추면 같은 패킷임을 확인할 수 있습니다. Route 선택, L2 재캡슐화와 주소 변환은 한 장비에서 연속해 일어날 수 있지만 서로 다른 판단입니다.

이 절의 근거 IETF RFC 3022 · IETF RFC 1812

도해에서 확인할 내용 단말·Gateway·DNS/ISP Backbone·Web 서버 사이의 전체 End-to-End 패킷 경로를 기능별 0~8번으로 정리한 도해입니다. 번호가 전체 통신의 단일 시간 순서를 뜻하지는 않습니다. L2/L3 전달과 필요한 NAT 변환은 DNS 질의·TCP 연결 설정 등 각 교환의 패킷에 반복 적용됩니다. DNS 주소 8.8.8.8은 본문의 10.0.0.53과 구분한 별도 예시입니다. 공유기 상자의 요청 출발지와 응답 목적지에서 10.0.0.25:51514 ↔ 198.51.100.8:40001 대응을 비교합니다.

서버의 응답은 어떤 기록을 따라 다시 처음의 브라우저까지 돌아올까↑

서버는 HTTP 요청을 처리해 응답 바이트를 TCP 세그먼트에 실어 보냅니다. 응답 경로가 요청 경로와 완전히 같을 필요는 없지만, 단말까지 도달하고 경계 장비의 상태·정책과 맞아야 합니다. NAT를 거쳤다면 경계 장비는 기존 NAT Mapping을 조회해 Destination IP·포트를 원래 내부 값으로 다시 바꿉니다.

브라우저는 받은 바이트를 HTML, CSS와 JavaScript로 해석하며 추가 자원을 다시 요청할 수 있습니다. 사용자가 보는 한 화면은 연결 하나가 아니라 여러 DNS·TCP·TLS·HTTP 흐름의 결과일 수 있습니다.

서버의 응답은 Source 104.21.30.148:443, Destination 198.51.100.8:40001로 경계에 도착합니다. NAT 장비는 이 외부 쪽 Tuple을 기존 매핑과 대조해 내부 Destination을 10.0.0.25:51514로 복원합니다. 방화벽 기능이 함께 있다면 해당 응답이 허용된 흐름의 방향과 TCP 상태에 맞는지도 별도로 판단할 수 있습니다. 주소 변환과 허용 결정이 한 장비에서 일어나도 두 질문은 구분해야 합니다.

요청과 응답의 인터넷 경로가 달라도 끝점의 TCP 상태만 맞으면 통신할 수 있습니다. 다만 한쪽 경로만 보는 Stateful 장비가 있거나 ECMP 경로마다 NAT 상태가 공유되지 않으면 응답이 폐기될 수 있습니다. 그래서 “서버에서 응답을 보냈다” 다음에는 경계 바깥, 경계 안쪽, 클라이언트 캡처를 차례로 비교합니다. 응답 패킷이 사라진 지점과 그 직전의 헤더 값을 찾으면 반환 경로·정책·매핑 중 무엇을 조사할지 좁힐 수 있습니다.

브라우저가 첫 HTML을 받았다고 화면의 모든 통신이 끝난 것도 아닙니다. CSS·JavaScript·Font·Image와 외부 API를 위해 추가 이름 해석과 연결이 생길 수 있고, HTTP/2 또는 HTTP/3는 하나의 연결 안에서 여러 요청을 다중화할 수 있습니다. 따라서 “페이지가 느리다”는 현상은 최초 연결과 후속 자원 가운데 어느 흐름이 시간을 썼는지 나누어 측정해야 합니다.

이 절의 근거 IETF RFC 9293 · IETF RFC 3022

도해에서 확인할 내용 WAF·Reverse Proxy 배치를 일반적인 예로 둔 서버 처리, 응답 방향 PAT 역매핑, 브라우저 해석의 세 상자를 따라갑니다. 목적지 198.51.100.8:40001 → 10.0.0.25:51514 변환과 DOM·CSSOM 처리 항목을 확인합니다. 대상 사이트의 실제 내부 배치를 확인한 도해는 아닙니다.

여러 장비의 캡처에서 같은 통신을 찾으려면 5-Tuple과 시각을 함께 맞춘다↑

상황: 이름은 정상적으로 해석되지만 HTTPS 연결이 일정 시간 뒤 실패합니다.

1. DNS 응답에서 선택된 서버 IP를 기록합니다.
2. 단말 캡처에서 그 IP의 TCP/443 SYN이 나가는지 확인합니다.
3. SYN-ACK, RST 또는 ICMP 오류가 돌아오는지 확인합니다. TCP 응답은 송수신 방향을 뒤집은 5-Tuple과 시간으로 대조하고, ICMP 오류는 그 안에 인용된 원래 패킷의 헤더 정보로 해당 흐름과 연결합니다.
4. 경계 장비에서 변환 전후 흐름과 방화벽 정책 로그를 확인합니다.
5. 수정 뒤 TCP 연결과 TLS Handshake가 어느 단계까지 진행되는지 다시 캡처합니다.

이 과정은 “인터넷이 느리다”는 느낌을 DNS 시간, TCP 재전송, TLS 협상과 서버 응답 시간으로 나누어 줍니다.

5-Tuple은 Source IP·Source 포트·Destination IP·Destination 포트·프로토콜입니다. 여기에 캡처 시각과 TCP Sequence Number를 더하면 여러 장비에서 본 패킷을 훨씬 정확히 대조할 수 있습니다. NAT 경계에서는 안쪽 Tuple과 바깥쪽 Tuple을 한 줄에 나란히 기록합니다. 단순히 “443 트래픽”이라고 검색하면 동시에 열린 수백 개의 HTTPS 흐름이 섞이지만, 이 값들을 고정하면 문제의 한 연결만 따라갈 수 있습니다.

시간축도 단계별로 나눕니다. DNS Query에서 Answer까지, 첫 SYN에서 SYN-ACK까지, TCP 완료에서 TLS 완료까지, 애플리케이션 Request에서 첫 응답 Byte까지를 각각 측정합니다. 전체가 5초 걸렸다는 값만으로는 어느 단계가 지연되었는지 알 수 없습니다. 같은 시험을 정상 단말과 비교하고 재전송·Timeout 지점을 표시하면 네트워크 지연, 패킷 손실, 이름 해석과 서버 처리 지연을 서로 다른 근거로 설명할 수 있습니다.

5-Tuple은 흐름을 찾는 출발점이지만 NAT를 지나면 값이 바뀝니다. 그래서 캡처 시각, Sequence·Flag와 Translation Entry를 함께 사용해야 여러 지점의 기록을 한 왕복으로 묶을 수 있습니다.

이 절의 근거 IETF RFC 9293 · IETF RFC 3022

FAQ↑