브라우저 주소창에 URL을 입력하면?
- 개발자로서 웹이 어떤 과정을 거쳐 우리의 요청을 처리하는 지 정도는 간단히라도 알고 있어야 해요.
- 전체적인 단계는 간단히 설명하고, 알아두어야 할 세부적인 내용이 있으면 조금 자세히 설명드릴 예정이에요. 양이 많지 않으니 가벼운 마음으로 읽어주세요!
처리 과정
사용자가 주소창에 이동하기를 원하는 도메인을 입력한다.
- 특정 웹사이트에 접속하기 위해서 도메인이 아닌 IP 주소가 필요해요. 모든 URL들에는 고유의 IP 주소가 지정되어있는데, 이 IP 주소를 통해서 해당 웹사이트를 호스팅하고 있는 서버 컴퓨터에 접근할 수 있어요.
- DNS(Domain Name System)은(는) URL의 이름과 IP주소를 저장하고 있는 데이터베이스에요. 도메인의 Hostname을 IP주소로 바꾸거나, 반대의 변환을 수행할 수 있도록 도와줘요.
- 내용을 정리해보면, "사용자가 특정 URL을 입력하면, 그에 매핑되는 DNS에 저장된 IP주소를 얻게 되고, 브라우저는 해당 과정을 통해 해당 IP주소로 접속할 수 있게 되는 것이다." 정도에요. 일단 해당 단계에서는 사용자가 브라우저 주소창에 URL을 입력한다는 과정이라고 이해하고 넘어가도록 해요.
브라우저는 캐싱된 DNS기록이 있는지 체크한다.
- DNS기록을 찾기 위해서, 브라우저는 네 개의 캐시를 확인해요. 그 순서는 아래와 같아요.
- 우선 브라우저 캐시를 확인해요. 브라우저는 내가 이전에 방문한 웹 사이트의 DNS기록을 일정 기간 저장해요.
- 브라우저 캐시에서 원하는 DNS 기록을 찾지 못하면, 브라우저는 OS 캐시를 확인해요. 이 과정은 브라우저가 OS에 System Call을 통해 DNS기록을 가져와요.
- OS 캐시에서 원하는 DNS 기록을 찾지 못하면, 브라우저는 라우터 캐시를 확인해요.
- 라우터 캐시에서 원하는 DNS 기록을 찾지 못하면, 마지막으로 ISP 캐시를 확인해요. ISP는 인터넷 서비스 제공자, 즉 인터넷 서비스를 제공하는 주체를 의미해요
- 여기서 캐시란, 자주 사용하는 데이터나 값을 미리 복사해 놓은 임시 장소로, 네트워크 트래픽을 조절하고 데이터 전송 시간을 줄여줘요.
요청한 URL이 캐시에 없으면 ISP의 DNS server가 재귀적으로 도메인 이름을 찾는다.
만약 캐시에 사용자가 입력한 URL과 관련된 DNS기록이 없으면, ISP의 DNS서버는 Root DNS에게 해당 도메인에 해당하는 IP주소를 어디서 찾을 수 있는지 물어보며 조회해요.
만약에 [.com]으로 끝나는 도메인이면, Root DNS는 [.com]으로 끝나는 도메인들을 담당하는 Top-Level 서버의 IP주소를 반환해요.
이후, Top-Level서버에게 같은 방법으로 요청하고, google.com으로 끝나는 도메인 정보를 가진 Second-Level 서버의 IP주소를 반환해요. 이렇게 원하는 IP주소를 얻을 때까지 검색을 반복해요.
이렇게 재귀적으로, 여러 다른 DNS 서버들을 검색하며 연결하기를 원하는 사이트의 IP 주소를 찾는 과정을 Recursive Search라고 불러요.
브라우저가 서버와 TCP Connection을 진행한다.
브라우저가 원하는 IP주소를 얻게 되면, 해당 IP주소를 가진 서버와 TCP Connection을 시도해요. 이 TCP Connection이 완료되면 HTTP 통신을 진행할 수 있어요.
클라이언트와 서버 간에 데이터가 오가기 위해서는 TCP Connection 상태가 되어야 해요. 이 상태를 만들기 위해, 클라이언트와 서버는 TCP/IP three-way handshake라는 프로세스를 사용해요.
TCP는 장치들 사이에 논리적인 접속을 성립(establish)하기 위해 사용하는(신뢰성을 중시하는) 프로토콜이에요. 위의 사진과 함께, TCP/IP three-way handshake를 이해하기 쉽게 설명해볼게요.
- 클라이언트는 서버에게 접속 요청을 한다는 메시지인 SYN 패킷을 보내요. 이 때, 클라이언트는 서버로부터 SYN/ACK 패킷을 받기를 기다리는 상태가 되는데, 이 상태가 SYN_SENT 이에요.
- 서버는 SYN요청을 받고 클라이언트에게 요청을 수락한다는 ACK와 SYN 패킷을 전송해요. 그리고 다시 클라이언트가 ACK 패킷을 보내주기를 기다리는 상태가 되는데, 이 상태가 SYN_RECEIVED 이에요.
- 클라이언트가 서버로부터 SYN/ACK 패킷을 받으면, 다시 서버에게 ACK 패킷을 보내요. 이 때부터 논리적 연결(establish)이 이루어지고, 데이터가 오갈 수 있는 상태가 되요.
브라우저가 웹 서버에게 HTTP Request를 한다.
TCP Connection 상태가 되었으니, 이제 클라이언트와 서버는 HTTP 프로토콜을 사용하여 데이터를 전송하고 받을 수 있어요.
원래의 사용자 목적인 웹 페이지를 받아와야 하니, 브라우저(클라이언트)는 GET 요청을 통해 서버로부터 웹 페이지 www.google.com에 대한 리소스를 달라고 요청해요.
이 때 생성된 HTTP Request Message는 TCP 프로토콜을 사용하여 IP 주소의 컴퓨터로 전송되요.
Request Message에는 요청을 위한 여러 정보 등이 담겨 있어요. HTTP 요청에 대해 좀 더 자세히 언급해보면 아래와 같아요.
- Request Line : URL정보, 요구 동작(GET), HTTP 버전 정보가 담겨요.
- Request Header : 요청에 대한 추가 정보를 서버에 전달하기 위해 사용되요. Host, User-Agent, Accept, Cookie 등 다양한 요소가 있어요. 궁금하면 "여기"를 클릭해주세요.
- Request Body : 추가 컨텐츠를 서버로 보내기 위해 사용되는 부분이에요. JSON이나 XML과 같은 파일 유형이 있어요.
서버가 요청을 처리하고 Response를 생성한다.
서버는 브라우저(클라이언트) 측의 요청을 전달받아 내용을 읽고, Response를 생성해요.
서버는 브라우저(클라이언트) 요청이 무엇인지 파악하고, 그 요청을 실행해요. 클라이언트 요청이 무슨 종류인지에 따라 서버 정보를 업데이트(POST)할 수도 있고, 쿠키와 헤더를 읽을 수도 있어요.
마지막으로, 서버는 브라우저(클라이언트)에게 응답할 Response를 특정 포맷(JSON, XML, HTML) 형태로 작성해 만들어요. 이제 응답을 보낼 일만 남았어요.
서버가 브라우저(클라이언트)에게 HTTP Response를 한다.
서버는 이제 브라우저(클라이언트)에게 요청에 대한 응답메시지를 전송해요.
서버의 response에는 요청한 페이지, Status-Code, Content-Type, Cache-Control, 쿠키, 개인정보 등 여러가지가 포함되요. 구조는 아래와 같아요.
- Status Line : HTTP 버전, 상태 코드, 상태 메시지(상태 코드에 대한 간략한 설명)를 포함해요.
- Response Header : Request처럼 Response에서도 추가적인 정보를 전달하기 위해 Header를 사용해요. Content-Type, Server(웹 서버의 종류), Age, Access-Control-Allow-Origin 등 다양한 요소가 있어요. 궁금하면 "여기"를 클릭해주세요.
- Response Body : Content-Type Header 정보 형식에 따라 클라이언트가 요청한 리소스 데이터를 서버가 이곳에 담아요. 만약, Content-Type: application/json이라면, Response Body에는 JSON형식의 데이터가 포함되는 것이죠.
브라우저가 HTML Content를 보여준다.
브라우저는 서버에게서 받은 Resource(요청한 웹 페이지)를 이용하여, HTML Content를 렌더링하고 사용자가 볼 수 있도록 노출시켜요.
이전에 배웠던 렌더링 과정이 기억나시나요? 지금부터 그 과정이 시작되는거에요. 잘 모르겠다면 "여기"를 클릭해주세요.