ActYourValue 님의 블로그

브라우저는 웹 서버로부터 첫 번째 HTML 파일(예: index.html) 응답을 받으면, 이를 화면에 바로 그리지 않고 **파싱(parse)**하기 시작합니다. 파싱하면서 HTML 안에 추가로 필요한 **자원들(css, js, image 등)**에 대한 참조를 만나면, 브라우저는 추가 요청들을 발생시킵니다. 이로 인해 사용자 시점에서 “웹 페이지가 모두 완성”되기까지 여러 개의 HTTP 요청/응답이 연이어 또는 동시다발적으로 일어납니다. 예를 들어 HTML 섹션에 다음과 같은 내용이 있다고 가정해봅시다: rel="stylesheet" href="/static/styles/main.css" /> src="https://cdn.example.com/libs/jquery.js">> src="/images/..

요청이 최종적으로 도달한 Pod(컨테이너) 안에는 실제 웹 서버 소프트웨어(또는 웹 애플리케이션)가 동작하고 있습니다. 예를 들어 Nginx 웹서버, 혹은 Node.js 기반의 Express 애플리케이션 등이 있을 수 있습니다. 이 웹 서버 프로세스가 클라이언트의 HTTP 요청을 받아 처리하는 마지막 단계를 살펴보겠습니다. 웹 서버는 **소프트웨어(프로그램)**이며, 컨테이너나 VM 안에서 특정 포트(예: 80 또는 443)로 들어오는 **HTTP 요청을 리스닝(listening)**하고 있습니다. 앞서 Ingress/Service를 통해 Pod의 해당 포트로 요청이 전달되었으므로, 이제 웹 서버는 OS 소켓을 통해 HTTP 패킷을 수신합니다. 웹 서버 소프트웨어 (nginx든 express든) 요청을 ..

사용자의 웹 요청 경로에는 CDN 외에도 다양한 프록시 서버나 방화벽이 개입할 수 있습니다. 이러한 요소들은 네트워크 안전과 효율을 위해 트래픽을 필터링하거나 중계합니다. 대표적으로 **포워드 프록시(forward proxy)**와 **리버스 프록시(reverse proxy)**가 있습니다.포워드 프록시 (예: 회사 내부 프록시 서버): 회사나 기관에서는 내부 사용자의 웹 접속을 대리 서버를 통해서만 하도록 설정하기도 합니다. 사용자의 브라우저는 인터넷으로 직접 나가는 대신 프록시 서버에 요청을 보내고, 프록시가 대신 외부 웹서버와 통신한 뒤 결과를 돌려줍니다. 이 과정에서 접근 제어나 캐싱, 로그 기록, 콘텐츠 필터링(예: 유해 사이트 차단)을 수행할 수 있습니다. HTTPS 트래픽의 경우 일반적으로 ..

현대의 웹 아키텍처에서는 **CDN(Content Delivery Network)**이 중요한 역할을 합니다. 사용자가 요청한 도메인이 CDN을 사용 중인 경우, DNS 단계에서 그 도메인이 가리키는 IP가 원본 서버가 아닌 CDN 엣지(edge) 서버로 설정됩니다. 예를 들어 Cloudflare나 Akamai CDN을 적용한 사이트라면, 해당 도메인의 DNS 응답이 전세계에 분산된 CDN 서버 중 사용자와 가까운 노드의 IP를 반환합니다. 결과적으로 브라우저는 CDN 서버와 TCP/TLS 연결을 맺고 콘텐츠를 요청하게 됩니다. CDN은 지리적으로 분산된 캐시 서버 네트워크로, 사용자와 지리적으로 가까운 위치에서 콘텐츠를 제공함으로써 웹 성능을 향상시킵니다. 전세계의 주요 도시에 캐시 서버를 두고, 사용..

TCP 연결이 열렸다면, 다음으로 HTTPS의 “S” 즉 TLS 보안 세션을 수립해야 합니다. HTTPS는 **HTTP + TLS(SSL)**를 의미하며, 웹 통신 내용을 암호화하고 통신 상대(서버)의 신원을 보장하기 위해 TLS 핸드셰이크 과정을 거칩니다. 이 단계에서는 클라이언트와 서버가 암호화 알고리즘 협상, 인증서 교환 및 검증, 세션 키 생성 등을 수행하며, 모두 TCP 위에서 진행되는 TLS 프로토콜 메시지 교환으로 이루어집니다. TLS 핸드셰이크의 주요 흐름은 다음과 같습니다 (TLS 1.2 기준으로 설명하고, TLS 1.3에선 일부 최적화가 있음):Client Hello – 클라이언트(브라우저)가 서버로 ClientHello 메시지를 보냅니다. 여기에는 지원하는 TLS 버전들, 암호화 알고..

브라우저(클라이언트)는 목적지 IP와 통신하기 위해 TCP 연결을 설정합니다. **TCP(Transmission Control Protocol)**는 신뢰성 있는 전송을 보장하기 위해 3-way 핸드셰이크라는 과정을 통해 통신 세션을 수립합니다. 이 단계에서는 아직 암호화되지 않은 TCP 레벨 패킷들이 오가며, IP 프로토콜 위에 TCP 세그먼트로 캡슐화되어 전송됩니다.TCP 3-way 핸드셰이크의 세부 단계는 다음과 같습니다:SYN (Synchronize) – 클라이언트가 서버에 연결을 요청하는 SYN 패킷을 보냅니다. 이 패킷에는 초기 **시퀀스 번호(sequence number)**가 포함되어 있는데, 예를 들어 x라는 임의의 시퀀스 넘버를 제안합니다. 이를 통해 클라이언트는 “seq=x로 통신을 ..

DNS를 통해 목적지 서버의 IP 주소(예: 93.184.216.34)를 얻었다면, 이제 브라우저는 해당 IP를 향해 웹 요청 패킷을 전송해야 합니다. 이때 브라우저(정확히는 OS의 TCP/IP 스택)는 먼저 로컬 네트워크의 기본 게이트웨이인 가정용 라우터를 향해 패킷을 보냅니다. 일반 가정 환경에서 PC나 스마트폰은 사설 IP(예: 192.168.0.x)를 쓰고 있으므로, **라우터가 PC의 사설 IP를 공인 IP로 변환(NAT)**하여 인터넷으로 내보내게 됩니다.NAT(Network Address Translation): 라우터는 내부망의 여러 기기가 공유하는 하나의 공인 IP를 사용해 통신할 수 있도록 IP를 변환합니다. 예를 들어 PC의 사설 IP 192.168.0.2에서 온 패킷을 라우터의 공인..

사용자가 웹 브라우저 주소창에 https://www.example.com과 같은 도메인을 입력하고 Enter를 치면, 브라우저는 먼저 해당 도메인 이름을 IP 주소로 변환해야 합니다. 인터넷 통신은 IP 주소를 통해 이루어지므로, 사람이 기억하기 쉬운 도메인(example.com)을 컴퓨터가 통신 가능한 숫자 주소로 바꾸는 과정이 DNS 조회입니다. DNS(Domain Name System)는 일종의 인터넷 전화번호부로, 도메인 이름을 입력하면 그에 대응하는 IP 주소를 찾아줍니다. 브라우저는 DNS 조회를 할 때 성능 향상을 위해 **여러 계층의 캐시(cache)**를 순차적으로 확인합니다:브라우저 내부 캐시: 이전에 방문했던 적이 있다면 브라우저가 DNS 응답을 일정 시간 보관하고 있을 수 있습니다...

브라우저에 URL을 입력하면 무슨 일이 일어날까?IT 기술 면접에서 자주 등장하는 질문 중 하나가 “브라우저 주소창에 URL을 입력하고 Enter를 누르면 무슨 일이 발생하나요?” 입니다. 이 질문에 답하려면 DNS 조회, 네트워크 경로, TCP/IP 연결 설정, TLS 보안 핸드셰이크, CDN 활용, 프록시/방화벽 통과, 클라우드 인프라 동작, 로드밸런서 및 Kubernetes Ingress 라우팅, 웹 서버의 요청 처리, 리소스 로딩 및 페이지 렌더링까지 전 과정을 체계적으로 이해해야 합니다. 이번 블로그 시리즈에서는 이 질문에 대해 10단계로 나누어 아주 상세하게 설명드리겠습니다. 각 단계에서 사용되는 프로토콜, 개입하는 장비/소프트웨어, 과정의 목적, 보안 측면 등을 함께 다루어, 마치 블로그 글..