주소창에 URL 을 입력했을 때 발생하는 일들

개요

주소창에 URL 을 입력할 때 발생하는 일련의 과정을 설명합니다.

 

간편 내용

인터넷 주소창에 URL 을 입력한 뒤 어떤 과정을 거쳐 tistory 화면이 스크린에 보여지는 걸까요?

간략히 설명하자면

 

1. 브라우저가 URL 을 해독한 후 HTTP 리퀘스트 메시지를 만듬
2. OS 는 메시지를 상대측 웹 서버로 송신하기 위해 IP 주소를 조사함
3. 가장 가까운 DNS 서버를 찾아 IP 주소를 알려달라고 함, 이때 다수의 DNS 서버가 연대하여 어디에 정보가 등록되어 있는지 찾음
4. 최종적으로 원하는 DNS 서버에 도달하면 본래 요청(IP 주소 조회)에 대한 답이 돌아오며 IP 주소를 찾게됨
5. IP 주소를 찾은 뒤엔 OS 에 위치한 프로토콜 스택에 의뢰하여 메시지를 송신함, 이때 소켓을 상대측 소켓과 연결하는 과정을 가짐
6. 브라우저가 데이터 수신을 완료하면 송수신 동작은 끝이 나면서 소켓 연결을 끊게 됨.

 

상세 내용

각 순서에 대한 내용을 상세히 알아보겠습니다.

 

1. 브라우저가 URL 을 해독한 후 HTTP 리퀘스트 메시지를 만듬

URL을 해독한다는 것은 요청한 데이터가 어느 경로에 있는지 파악하는 것을 의미합니다.

해독하는 과정을 가지면 리퀘스트 메시지를 보내는데, 이 메시지는 '무엇을'(URI), '어떻게 해서'(메소드) 하겠다는 내용이 쓰여져있습니다. 정리하면 이 메소드를 통해 웹 서버에서 어떻게 동작하고 싶은지를 전달합니다.

리퀘스트 메시지가 서버에 도착하면 웹 서버는 그 속에 쓰여있는 내용을 해독하며 '무엇을', '어떻게 하는지' 판단하여 요구에 따라 동작하고 결과 데이터를 응답 메시지에 저장합니다. 이때 스테이터스 코드(status code)라고 불리는 동작의 이상여부를 표시하는 코드를 같이 담아서 보냅니다.

클라이언트가 리퀘스트 메시지를 보낼 때 첫번째 행에는 메소드, URI(ex. 프로그램의 경로명)을

두번째 행에는 메시지 헤더라는 행을 담습니다. 메시지 헤더는 요청하는 정보의 부가적인 자세한 정보가 필요한 경우가 있는데 이런 경우에 쓰이는 것입니다. (Date, Pragma, Cache-Control, Connection, Transfer-Encoding, Via, Authorization, From...)

메시지 헤더를 쓰면 그 뒤에 공백 행을 넣고 송신할 데이터(메시지 본문)를 씁니다.

 

2. OS 는 메시지를 상대측 웹 서버로 송신하기 위해 IP 주소를 조사함

브라우저는 메시지를 해독하고 만들 수 있지만 네트워크에 송출할 수 없으므로 OS에 의뢰합니다. 이때 tistory.com 과 같이 쓰여진 이름(도메인명)의 IP 주소를 구해야 하는데 OS는 도메인명이 아닌 IP주소를 통해서 메시지를 보낼 수 있기 때문입니다. 

인터넷은 TCP/IP 에 기반하여 만들어졌으므로 TCP/IP 의 동작구조에 대해 어느정도 알 필요가 있습니다. TCP/IP 는 IP 주소에 따라 액세스 대상이 어디에 있는지 판단하고 운반합니다. 이때 송신측이 메시지를 보낼 땐 서브넷(허브를 통해 구축된 가상의 망)안에 허브가 운반하고 송신측에서 가까운 곳에 있는 라우터까지 도달합니다. 허브 -> 라우터 로 보내는 과정을 거쳐 최종적으로 상대의 데이터가 도착합니다.

IP 주소를 조사할 땐 가장 가까운 DNS 서버에 tistory.com 이라는 서버의 IP 주소를 알려주세요 라는 식으로 질문을 하여 알아냅니다. 이때 DNS 서버에 조회를 요청하는 클라이언트를 DNS 리졸버 라고 부르고 DNS 원리를 사용해 IP 주소를 알아내는 것을 네임 리졸루션이라고 합니다.

DNS 조회를 하는 메시지에는 이름, 클래스, 타입 이라는 세 가지 정보가 포함되어 있습니다.

 

3. 가장 가까운 DNS 서버를 찾아 IP 주소를 알려달라고 함, 이때 다수의 DNS 서버가 연대하여 어디에 정보가 등록되어 있는지 찾음

DNS 서버에 등록한 정보엔 도메인명 이라는 계층적 구조를 가진 이름이 붙어져 있습니다. 예를 들어 www.tistory.ki.tae.co 라고 한다면 co 자체는 하나의 도메인입니다, 이 링크에서 구조는 co 라는 도메인 아래 tae 라는 도메인, 그 아래 ki 라는 도메인 아래 tistory, 그 아래 www가 있는 셈입니다. www 라는 하나의 도메인은 하나의 DNS 서버에 등록합니다.

인터넷 도메인은 com 이나 kr 보다 더 상위 도메인인 루트 도메인이 있습니다. 루트 도메인은 도메인명이 없어 도메인을 쓸 때는 생략합니다.

아래는 DNS 서버를 거쳐 원하는 DNS 서버에 도달하는 과정을 대략적으로 나타냅니다.

hello.world.com 도메인을 찾는 과정을 계층적으로 표시

실제로 원하는 DNS 서버에 도달하는 과정은, 위 그림과는 살짝 다릅니다.

1. 가장 가까운 DNS 서버에 먼저 원하는 웹 서버에 대한 조회 요청을 합니다.
2. 가장 가까운 DNS 서버에서 알 수 없다는 회신이 오고, 원하는 도메인에 대한 정보를 찾을 때까지 차례로 따라 위로 올라가면서 찾습니다. 그리고 가장 가까운 DNS 서버에는 루트 도메인의 DNS 정보도 있으므로 이를 통해 루트 도메인한테도 조회 요청을 합니다. 
3. 그 결과 루트 도메인은 자체에 등록되어 있는 com 도메인의 IP 주소를 반송합니다.
4. 이어서 가장 가까운 DNS 서버는 com 도메인의 DNS 서버에 조회 메시지를 보내고 com 도메인은 hello.com 도메인에 대한 DNS 서버의 IP 주소를 반송합니다. 이 과정을 반복하면 원하는 DNS 서버에 도달하게 됩니다.

 

4. 최종적으로 원하는 DNS 서버에 도달하면 본래 요청(IP 주소 조회)에 대한 답이 돌아오며 IP 주소를 찾게됨

클라이언트에 조회 메시지를 받은 DNS 서버는 이렇게 해서 IP 주소를 조사하고 결과를 클라이언트에 회답합니다. 이로써 클라이언트는 상대 웹 서버의 IP 주소를 알게되어 서로 통신을 할 수 있습니다.

 

5. IP 주소를 찾은 뒤엔 OS 에 위치한 프로토콜 스택에 의뢰하여 메시지를 송신함, 이때 소켓을 상대측 소켓과 연결하는 과정을 가짐

이를 상세히 설명하자면 데이터를 주고 받을 땐 파이프라는 통로를 거쳐갑니다. 이때 클라이언트와 서버간에 파이프를 연결하는 과정이 필요한데 파이프의 양 끝단을 소켓이라고 부르며 이 소켓을 만들고 연결해야 합니다. 과정을 간략히 설명하면 아래와 같습니다.

1. 소켓을 만듬 (서버측이 먼저 만들고 그 후에 클라이언트 측이 만듬, 서버측은 클라이언트 측이 연결할 때가지 기다림)
2. 서버측의 소켓에 파이프를 연결함
3. 데이터를 송수신 함
4. 파이프를 분리하고 소켓을 말소함

상세히 설명하면 소켓이 생기면 디스크립터라는 것이 생기는데 이는 소켓을 식별하기 위한 용도입니다. 디스크립터를 포함해 서버 IP 주소, 포트 번호 세 가지를 가지고 상대방과 연결을 시도하고 데이터 송수신이 가능한 상태가 됩니다.

데이터 연결이 가능한 상태가 되면 데이터를 서로 주고 받습니다.

 

6. 브라우저가 데이터 수신을 완료하면 송수신 동작은 끝이 나면서 소켓 연결을 끊게 됨.

HTTP 프로토콜은 응답 메시지의 송신 완료했을 때 웹 서버측에서 연결 끊기 동작을 실행합니다. 그래서 웹 서버측에서 먼저 연결을 끊습니다. 이에 따라 클라이언트도 연결 끊기 단계로 들어가면서 송수신이 완료되어 연결이 끊겼다는 것을 브라우저에 통지합니다. 이에 따라 브라우저도 연결 끊기 단계에 들어갑니다.

 

 

출처

성공과 실패를 결정하는 1%의 네트워크 원리