웹 브라우저에 URL을 입력하면?

웹 브라우저에서 https://naver.com과 같은 URL을 입력하면 브라우저는 인터넷에서 사이트를 호스팅하는 서버를 파악해야 합니다.

이는 naver.com 도메인을 검색하여 주소를 찾는 것입니다.

서버, 휴대폰, 스마트 냉장고 등 인터넷의 각 디바이스에는 모두 IP 주소라는 4개의 숫자로 이루어진 고유 주소가 있습니다.

 

하지만 이러한 숫자는 기억하기 어렵기 때문에 도메인 이름 시스템(DNS)을 통해 쉽게 도메인 이름으로 서버의 IP 주소를 찾을 수 있습니다.

빅스비 혹은 시리에게 '홍길동에게 전화해줘'라고 했을 때 '홍길동'은 DNS 조회를 수행하기 위한 도메인 이름이 되고 '홍길동'에 해당하는 전화번호가 IP 주소가 된다.

 

✏️ 1. 웹 브라우저에 URL을 입력하고 Enter 키 입력

https://naver.com

URL의 일부 분류하기

 

통신 규약 (Protocol)

https://는 통신 프로토콜입니다.

HTTPS는 Hypertext Transfer Protocol Secure를 나타냅니다.

이 스키마는 브라우저에 전송 계층 보안(TLS)을 사용하여 서버에 연결하도록 지시합니다.

TLS는 인터넷을 통한 통신을 보호하는 암호화 프로토콜입니다.

HTTPS를 사용하면 암호나 신용 카드 정보와 같이 브라우저와 서버 간에 교환되는 데이터가 암호화됩니다.

 

도메인 (Domain)

naver.com은 웹 사이트의 도메인 이름입니다.

기억하기 쉬운 주소이며 특정 서버의 IP 주소를 가리킵니다.

 

경로 (Path)

https://w00ye0l.tistory.com/manage/posts의 경우 manage는 서버에 요청된 리소스인 posts로 이어지는 경로입니다.

이는 컴퓨터에 있는 파일의 디렉토리 구조나 기타 디렉토리처럼 생각할 수 있습니다.

 

리소스 (Resource)

이 URL을 브라우저에 입력하면 posts는 보려는 웹 사이트의 리소스 이름입니다.

.html과 같은 파일 확장자도 볼 수 있는데, 이는 HTML 콘텐츠가 있는 서버의 정적 파일임을 나타냅니다.

이 URL과 같이 확장자가 없으면 일반적으로 서버가 이 콘텐츠를 생성했음을 나타냅니다.

예를 들어 뉴스 사이트는 사용자 지정, 최신 및 지역 뉴스 콘텐츠를 표시하며, 이는 사용자 또는 요청의 출처를 알 때만 수행할 수 있습니다.

 

✏️ 2. 웹 브라우저가 도메인명의 IP 주소 조회

브라우저에 URL을 입력하고 Enter 키를 누른 후 브라우저는 인터넷에서 연결할 서버를 파악해야 합니다.

DNS 조회를 사용하여 입력한 도메인을 사용하여 웹 사이트를 호스팅하는 서버의 IP 주소를 조회합니다.

 

DNS는 복잡하고 매우 빨라야 하기 때문에 DNS 데이터는 웹 브라우저 사이의 서로 다른 계층과 인터넷의 다양한 위치에 임시로 저장됩니다. 이를 캐시(Cache)라고 부르는데, 웹 브라우저는 고유한 캐시, 운영 체제 캐시, 라우터의 로컬 네티워크 캐시, 회사 네트워크 또는 인터넷 서비스 제공업체(ISP)의 DNS 서버 캐시를 확인합니다.

 

만약, 웹 브라우저가 캐시 계층에서 IP 주소를 찾을 수 없는 경우 회사 네트워크 또는 ISP의 DNS 서버가 재귀적 DNS 조회를 수행합니다.

재귀적 DNS 조회는 인터넷에 있는 여러 DNS 서버를 요청하며, 검색될 때까지 DNS 레코드에 대해 더 많은 DNS 서버에 요청합니다. 웹 브라우저가 IP 주소로 DNS 레코드를 가져오면 인터넷에서 서버를 찾아 연결을 설정해야 합니다.

 

특정 웹 브라우저는 사용자가 링크를 따라가기 전에 미리 도메인 네임을 확인하는 DNS 프리페치(Prefetch)라는 기능을 가지고 있기도 합니다.

웹 페이지 내에 도메인명이 미리 확인되면 사용자가 해당 도메인으로 이동할 때, DNS 확인 시간으로 인한 지연이 발생하지 않습니다.

DNS 프리페치가 도움이 될 수 있는 사례는 검색 결과 페이지와 같이 다양한 도메인명의 링크가 있는 페이지를 보고 있는 경우입니다.

 

✏️ 3. 웹 브라우저가 서버와의 TCP 연결 시작

인터넷에 연결된 웹 브라우저 요청 패킷은 일반적으로 TCP/IP(Transmission Control Protocol/Internet Protocol)라고 하는 전송 제어 프로토콜을 사용하여 라우터 장비, 인터넷 서비스 제공회사 교환기를 통해 이동되어, 통신 회사간 경로인 라우팅 테이블을 따라서 연결할 IP 주소가 있는 웹 서버를 찾습니다.

 

하지만, 웹 서버에 직접 도달하는 방법은 위치에 따라 효율적이지 않을 수 있습니다.요즘에는 많은 웹 사이트들이 직접 서버에 연결하기 보다는 콘텐츠 전송 네트워크(CDN)를 사용하여 정적 및 동적 콘텐츠를 웹 브라우저 가까이에 위치 시킵니다.

 

예를 들면, 동영상이나 음악 파일 같은 것은 멀리 외국에 있는 웹 서버에서 제공하기 보다는 우리가 사용하는 인터넷 서비스 제공자들의 데이터 센터에 있는 콘텐츠 배포 서버에 위치해 있을 확률이 큽니다. 그래야만 버퍼링 없이 서비스를 즐길 수 있기 때문입니다.

 

즉, CDN은 콘텐츠를 사용자에게 더 가까이 제공하여 사이트의 원본 연결 성능을 개선하는 캐싱 서버의 글로벌 분산 네트워크입니다.

 

웹 브라우저 요청은 인터넷 라우팅 테이블에 따라 경로를 따라서 순서대로 이동합니다. 각 요청은 가장 성능이 좋은 위치를 통해 지능적으로 라우팅되어 브라우저에 콘텐츠를 전송합니다.

이 경우, 웹 서버는 원본 서버도 CDN도 아닌 로드밸런싱(Elastic Load Balancing, ELB) 기능을 이용하고 있음을 알 수 있습니다. 로드밸런서는 여러 웹 서버의 부하 분산을 해주는 기능을 합니다.

 

웹 브라우저가 인터넷에서 서버를 찾으면 웹 서버와 TCP 연결을 설정하고, HTTP를 통해 평문 통신을 시작합니다. 그러나, HTTPS를 사용하는 경우 주고 받는 데이터의 암호화를 위한 TLS (Transport Layer Security) 핸드쉐이크라는 추가 과정을 수행합니다.

TLS 핸드쉐이크는 암호화할 상호 대상을 확인하는 것입니다.

 

HTTP 통신이 진행될 때, 웹 브라우저와 웹 서버 간의 통신이 어떻게 일어나는지 알아보기 위해서는 웹 브라우저의 개발자 도구를 사용하면 됩니다.

크롬의 경우, 보기 > 개발자 > 개발자 도구에서 볼 수 있습니다.

 

특정 리소스를 가져오는데 필요한 DNS 찾기 시간, 연결 시간 등을 볼 수 있습니다.

웹 브라우저가 서버와의 연결을 설정했으면 다음 단계는 리소스 또는 페이지를 가져오기 위해 HTTP 요청을 전송하는 것입니다.

 

✏️ 4. 웹 브라우저가 HTTP 요청을 서버로 전송

웹 브라우저가 서버에 연결되면, HTTP(s) 프로토콜에 대한 통신 규칙을 따릅니다.

웹 브라우저가 페이지의 콘텐츠를 요청하기 위해 서버에 HTTP 요청을 전송하는 것으로 시작합니다.

HTTP 요청에는 요청 라인, 헤더(또는 요청에 대한 메타데이터) 및 본문이 포함됩니다.

요청 라인에는 클라이언트(이 경우 브라우저)가 수행하려는 작업을 서버가 결정하는데 사용할 수 있는 정보가 포함되어 있습니다.

 

요청 라인에 포함되는 것은 아래와 같습니다.

• GET, POST, PUT, PATCH, DELETE 또는 몇 가지 다른 HTTP 동사 중 하나인 요청 메서드
• 요청된 리소스를 가리키는 경로
• 통신할 HTTP 버전

 

URL 요청에 대한 요청 라인은 다음과 같습니다.

GET /blog/1620 HTTP/1.1

요청 라인은 서버에 /blog/1620에서 리소스를 가져오고 HTTP/1.1과 통신하기를 원한다고 알립니다.

 

HTTP 동사는 요청의 의도를 표현합니다.

POST, PUT 또는 PATCH 메서드를 사용하여 요청 경로에서 새 데이터를 생성하거나 기존 데이터를 업데이트하기 위해 저장할 서버로 데이터를 전송할 수도 있습니다.

DELETE 메서드는 지정된 경로에서 리소스를 삭제합니다.

서버는 DELETE 메서드에 200 OK 상태로 응답할 수 있지만 리소스로는 아무 작업도 하지 않을 수 있습니다.

 

요청 헤더(Request Header)는 요청을 라우팅하는데 도움이 되는 추가 정보를 클라이언트에서 전달하고, 어떤 유형의 클라이언트(사용자 에이전트)가 요청을 수행하는지 나타내며, A/B 테스트, 블루/그린 배포 및 카나리 배포를 지원하는데 사용할 수 있습니다.

헤더는 키-값의 형태로 나타냅니다.

 

요청의 마지막 부분은 본문입니다.

본문은 (보통) GET 요청에서는 비어있습니다. POST, PUT 또는 PATCH와 같은 리소스를 조작하는 요청의 경우 본문에는 생성하거나 업데이트할 클라이언트의 데이터가 포함됩니다.

요청 본문은 서로 다른 형식일 수 있으며 서버는 요청 헤더인 Content-Type을 기반으로 형식을 이해합니다.

 

✏️ 5. 웹 서버가 요청을 처리하고 응답을 다시 전송

웹 서버는 요청을 받고 요청 라인, 헤더 및 본문의 정보를 기반으로 요청 처리 방법을 결정합니다.

GET /blog/1620 HTTP/1.1 요청에 대해 서버는 이 경로의 콘텐츠를 가져오고 응답을 생성하여 클라이언트로 다시 전송합니다.

 

응답에는 다음이 포함됩니다.

• 클라이언트에게 요청 상태를 알려주는 상태 라인
• 브라우저에 응답 처리 방법을 알려주는 응답 헤더
• 해당 경로에서 요청된 리소스 (HTML, CSS, Javascript, 이미지 파일과 같은 콘텐츠 또는 데이터)

 

상태 라인에는 HTTP 버전과 요청 상태의 숫자 및 텍스트 표현이 모두 포함됩니다.

• 1xx (Information Response) : 정보 메시지만을 나타낸다. 서버가 요청을 받았으며 서버에 연결된 클라이언트는 계속해서 작업을 하라는 뜻
• 2xx (Successful Response) : 서버와의 요청이 성공함을 나타냄
• 3xx (Redirection Message) : 요청 완료를 위해 추가 작업 조치가 필요함
• 4xx (Client Error Response) : 클라이언트의 Request에 에러가 있음을 의미함
• 5xx (Server Error) : 서버 측의 오류로 request를 수행할 수 없음

 

전송 받은 리소스는 텍스트(예: index.html) 또는 텍스트가 아닌 데이터(예: logo.img)의 정적 파일일 수 있습니다. 하지만 웹 브라우저가 항상 정적 파일을 요청하는 것은 아닙니다.

대부분 웹 서버가 동적 리소스를 생성하여 코드 조각이나 템플릿에서 HTML을 구축하고 동적 데이터와 결합하여 응답으로 텍스트로 다시 전송하여, 웹 브라우저가 페이지를 렌더링할 수 있습니다.

 

✏️ 6. 웹 브라우저가 콘텐츠 렌더링

웹 브라우저가 서버로부터 응답을 받으면 응답 헤더를 검사하여 리소스를 렌더링하는 방법에 대한 정보를 확인합니다.

Content-Type 헤더는 브라우저에 응답 본문에서 HTML 리소스를 수신했음을 알립니다.

 

첫 번째 GET 요청은 페이지의 구조인 HTML을 반환합니다. 그러나, 웹 브라우저의 개발 도구를 사용하여 페이지(또는 웹 페이지)의 HTML을 검사하면 다른 Javascript, CSS, 이미지 리소스를 참조하고 웹 페이지를 설계된 대로 렌더링하기 위해 추가 데이터를 요청하는 것을 볼 수 있습니다.

 

브라우저가 HTML을 파싱하고 렌더링할 때 Javascript, CSS, 이미지 및 데이터를 가져오라는 추가 요청을 하고 있습니다. 이 중 많은 부분을 병렬로 수행할 수 있지만 항상 그런 것은 아닙니다.

 

HTML은 CSS나 JS 파일 리소스를 참조합니다. 웹 브라우저는 페이지에 스타일을 지정하기 위해 CSS 리소스를 가져오도록 서버에 후속 요청을 합니다. CSS 리소스에 대한 요청 Content-Type 헤더는 브라우저에 CSS를 렌더링하도록 지시합니다.

 

만약, 웹 브라우저가 이미지 리소스를 요청하면 Content-Type 헤더가 브라우저에 텍스트가 아닌 데이터임을 알려주고 그에 따라 렌더링하도록 지시합니다.