웹 브라우저에서 https://naver.com같은 URL을 입력하면 브라우저는 인터넷에서 사이트를 호스팅하는 서버를 식별해야 합니다.
이것은 naver.com 도메인을 검색하고 주소를 찾는 것입니다.
서버, 휴대폰, 스마트 냉장고 등 인터넷의 각 장치에는 IP 주소라는 네 개의 숫자로 구성된 고유 주소가 있습니다.
그러나 이러한 번호는 기억하기 어렵기 때문에 DNS(Domain Name System)를 통해 쉽게 도메인 이름으로 서버의 IP 주소를 찾을 수 있습니다.
빅스비 또는 시리에게 ‘홍길동에게 전화해달라’고 했을 때 ‘홍길동’은 DNS 조회를 수행하기 위한 도메인명이 되며 ‘홍길동’에 해당하는 전화번호가 IP 주소가 된다.
✏️ 1. 웹 브라우저에 URL을 입력하고 Enter 키를 입력합니다.
https://naver.com
URL의 일부를 분류
통신규약(프로토콜)
https://는 통신 프로토콜입니다.
HTTPS는 Hypertext Transfer Protocol Secure를 나타냅니다.
이 스키마는 브라우저에 전송 계층 보안(TLS)을 사용하여 서버에 연결하도록 지시합니다.
TLS는 인터넷을 통한 통신을 보호하는 암호화 프로토콜입니다.
HTTPS를 사용하면 암호와 신용카드 정보와 같이 브라우저와 서버 간에 교환되는 데이터가 암호화됩니다.
도메인(Domain)
naver.com는 웹사이트의 도메인 이름입니다.
기억하기 쉬운 주소로 특정 서버의 IP 주소를 가리킵니다.
경로(Path)
https://w00ye0l./manage/posts의 경우 manage는 서버에 요청된 자원인 posts로 이어지는 경로입니다.
이것은 컴퓨터의 파일 디렉토리 구조와 다른 디렉토리처럼 생각할 수 있습니다.
리소스(Resource)
이 URL을 브라우저에 입력하면 posts는 표시할 웹 사이트의 리소스 이름입니다.
.html이러한 파일 확장자로 볼 수 있습니다.
이는 HTML 콘텐츠가 포함된 서버의 정적 파일임을 나타냅니다.
이 URL과 같은 확장자가 없으면 일반적으로 서버가 이 콘텐츠를 생성했음을 나타냅니다.
예를 들어 뉴스 사이트에는 맞춤, 최신 및 로컬 뉴스 콘텐츠가 표시됩니다.
이는 사용자나 요청의 출처를 알고 있는 경우에만 수행할 수 있습니다.
✏️ 2. 웹 브라우저가 도메인 이름의 IP 주소를 검색합니다.
브라우저에 URL을 입력하고 Enter 키를 누른 후 브라우저는 인터넷에서 연결할 서버를 식별해야 합니다.
DNS 검색을 사용하여 입력한 도메인을 사용하여 웹 사이트를 호스팅하는 서버의 IP 주소를 검색합니다.
DNS는 복잡하고 매우 빠르기 때문에 DNS 데이터는 웹 브라우저 간의 다른 계층과 인터넷의 여러 위치에 일시적으로 저장됩니다.
이것을 캐시라고합니다.
웹 브라우저는 자체 캐시, 운영 체제 캐시, 라우터의 로컬 네트워크 캐시, 기업 네트워크 또는 인터넷 서비스 공급자(ISP)의 DNS 서버 캐시를 확인합니다.
웹 브라우저가 캐시 계층에서 IP 주소를 찾을 수 없는 경우 회사 네트워크 또는 ISP의 DNS 서버가 재귀 DNS 조회를 수행합니다.
재귀 DNS 조회는 인터넷에서 여러 DNS 서버를 요청하고 검색될 때까지 DNS 레코드에 대해 더 많은 DNS 서버에 요청합니다.
웹 브라우저가 IP 주소로 DNS 레코드를 가져온 후에는 인터넷에서 서버를 찾아 연결을 설정해야 합니다.
특정 웹 브라우저에는 사용자가 링크를 따라가기 전에 도메인 이름을 미리 확인하는 DNS 프리페치라는 기능이 있습니다.
웹 페이지에서 도메인 이름이 미리 확인된 경우 사용자가 해당 도메인으로 이동할 때 DNS 확인 시간으로 인한 지연이 발생하지 않습니다.
DNS 프리페치가 유용한 경우는 검색결과 페이지와 같은 다양한 도메인 이름의 링크가 있는 페이지를 보는 경우입니다.
✏️ 3. 웹 브라우저가 서버와의 TCP 연결을 시작합니다.
인터넷에 접속된 웹 브라우저 요구 패킷은, 통상 TCP/IP(Transmission Control Protocol/Internet Protocol)라고 하는 전송 제어 프로토콜을 사용해 라우터 기기, 인터넷 서비스 프로바이더 교환기를 통해 이동되어, 통신사간의 경로 라우팅 테이블을 따라 연결할 IP 주소가 있는 웹 서버를 찾습니다.
그러나 웹 서버에 직접 도달하는 방법은 위치에 따라 효율적이지 않을 수 있습니다.
하자.
예를 들어, 비디오 및 음악 파일 등은 외국 웹 서버에서 멀리 제공하는 것이 아니라 Google이 사용하는 인터넷 서비스 제공업체의 데이터 센터에 있는 콘텐츠 전송 서버에 있을 가능성이 높습니다.
그것만으로 버퍼링 없이 서비스를 즐길 수 있기 때문입니다.
즉, CDN은 콘텐츠를 사용자에게 접근하여 사이트의 소스 연결 성능을 향상시키는 캐시 서버의 글로벌 분산 네트워크입니다.
웹 브라우저 요청은 인터넷 라우팅 테이블에 따라 경로를 따라 순서대로 이동합니다.
각 요청은 가장 실적이 우수한 위치를 통해 지능적으로 라우팅되며 브라우저로 콘텐츠를 보냅니다.
이 경우 웹 서버는 소스 서버나 CDN이 아니라 로드 밸런싱(ELB) 기능을 활용하고 있음을 알 수 있습니다.
로드 밸런서는 여러 웹 서버를 로드 밸런싱하는 기능을 제공합니다.
웹 브라우저가 인터넷에서 서버를 찾으면 웹 서버와 TCP 연결을 설정하고 HTTP를 통해 일반 텍스트 통신을 시작합니다.
그러나 HTTPS를 사용하는 경우 보내고 받는 데이터를 암호화하는 TLS(Transport Layer Security) 핸드셰이크라는 추가 프로세스를 실행합니다.
TLS 핸드셰이크는 암호화할 상호 대상을 확인하는 것입니다.
HTTP 통신이 이루어질 때 웹 브라우저와 웹 서버 간의 통신이 어떻게 발생하는지 알기 위해 웹 브라우저 개발자 도구를 사용하십시오.
Chrome의 경우, 보기 > 개발자 > 개발자 도구에서 볼 수 있습니다.
특정 리소스를 검색하는 데 필요한 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 상태로 응답할 수 있지만 리소스에서 아무 작업도 수행하지 않을 수 있습니다.
요청 헤더는 요청을 라우팅하는 데 도움이 되는 추가 정보를 클라이언트에서 전달하고, 어떤 유형의 클라이언트(사용자 에이전트)가 요청을 수행하는지 표시하며, 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): 클라이언트 요청에 오류가 있음을 의미합니다.
- 5xx(서버 오류): 서버 측 오류로 요청을 실행할 수 없음
전송된 리소스는 텍스트입니다(예: index.html) 또는 텍스트 이외의 데이터(예: logo.img)의 정적 파일입니다.
그러나 웹 브라우저가 항상 정적 파일을 요청하는 것은 아닙니다.
대부분의 경우 웹 서버는 동적 리소스를 생성하고 코드 스니펫이나 템플릿에서 HTML을 빌드한 다음 동적 데이터와 함께 응답으로 텍스트로 되돌려 웹 브라우저가 페이지를 렌더링할 수 있습니다.
✏️ 6. 웹 브라우저가 콘텐츠를 렌더링
웹 브라우저가 서버에서 응답을 받으면 응답 헤더를 검토하여 리소스를 렌더링하는 방법에 대한 정보를 확인합니다.
Content-Type 헤더는 브라우저에 응답 본문에서 HTML 리소스를 받았음을 알립니다.
처음 GET 요청은 페이지 구조인 HTML을 반환합니다.
하지만 웹 브라우저 개발 도구를 사용하여 페이지(또는 웹 페이지)의 HTML을 살펴보면 다른 자바스크립트, CSS, 이미지 리소스를 찾아 웹 페이지를 디자인 대로 렌더링하기 위해 추가 데이터를 요청합니다.
하는 것을 알 수 있습니다.
브라우저가 HTML을 구문 분석하고 렌더링할 때 자바스크립트, CSS, 이미지 및 데이터를 검색하기 위한 추가 요청을 하고 있습니다.
이들 대부분은 병렬로 실행할 수 있지만 반드시 그런 것은 아닙니다.
HTML은 CSS 또는 JS 파일 리소스를 참조합니다.
웹 브라우저는 페이지에 스타일을 지정하기 위해 CSS 리소스를 검색하도록 서버에 후속 요청을 발행합니다.
CSS 리소스 요청 Content-Type 헤더는 브라우저에 CSS를 렌더링하도록 지시합니다.
웹 브라우저가 이미지 리소스를 요청하면 Content-Type 헤더가 브라우저에 텍스트가 아닌 데이터임을 알리고 그에 따라 렌더링하도록 지시합니다.