[1%의 네트워크 원리] Ch01. 웹 브라우저가 메시지를 만든다

1. HTTP 리퀘스트 메세지를 작성한다

사용자가 구글 크롬이나 파이어폭스와 같은 웹 브라우저에 URL(ex. http://www.naver.com)을 입력하면 웹 브라우저는 이 URL을 해독한다. URL의 모양새와 관련해서는 전세계적으로 모두가 합의된 규칙이 정해져있기 때문에 가능한 일. 

 

URL에는 어떠한 통신 프로토콜을 사용할 것인지 표기되어 있는데(ex. HTTP, FTP) 대개의 경우 웹 브라우저는 HTTP 통신을 다룬다. 다른 프로토콜을 이용한 통신을 지원하기도 하지만 일반적으로는 HTTP에 한정지어 생각해도 괜찮다.

여튼 사용자가 만든 URL을 해독해서 웹 브라우저는 HTTP Request Message를 구성한다. 이 역시도 모양새에 대한 규칙이 정해져 있기 때문에 어떠한 웹 브라우저를 사용해도 만들어지는 HTTP Request Message의 큰 틀은 동일하다. (물론 세부 내용은 브라우저마다 조금씩 다를 수 있다.) 

 

2. 웹 서버의 IP 주소를 DNS 서버에 조회한다

1번 단계에서 HTTP Request Message를 만든 다음에는 이 메세지를 서버에 보내야 한다. 예를 들어, 우리들은 별 생각없이 브라우저 창에 http://www.naver.com을 입력하지만, 실제로는 웹 브라우저가 이 URL을 해독해서 HTTP Request Message를 만들고, 이 메세지를 네이버 서버에 전송하여 그에 대한 응답을 받는다. 그리고 그 응답을 웹 브라우저가 다시 해독해서 우리 눈에 보이는 화면을 뿌려준다. 

 

여튼 이때 네이버 서버에게 메세지를 보내기 위해 네트워크 세상에서는 서버의 IP 주소를 알아야 한다. http://www.naver.com은 도메인 주소지 IP 주소가 아니다. 사람들이 도메인 주소를 작성하면 웹 브라우저가 사람들 대신에 도메인 주소를 통해 IP 주소를 알아내는 서비스를 제공해준다고 생각하면 된다. 

 

그렇다면 웹 브라우저는 어떻게 도메인 주소를 통해 IP 주소를 알아낼까?

웹 브라우저가 모든 도메인과 IP 주소의 매핑관계를 가지고 있을 수는 없다. 이러한 역할을 대신 해주는 것이 DNS 서버이다.

정말 단순하게 추상화해서 이야기하자면 DNS 서버에 이 세상의 모든 도메인과 IP 주소의 매핑관계가 기록되어 있다. 웹 브라우저가 DNS 서버한테 'http://www.naver.com의 IP주소가 뭐야?'라고 물어보면 DNS 서버는 그에 대한 답을 주고, 웹 브라우저는 그 IP 주소를 받아서 HTTP Request Message를 전달한다. 

하지만 조금 더 정확히 이야기하자면 웹 브라우저가 DNS 서버한테 다이렉트로 질문을 던지지는 않는다. 각 OS마다 DNS 서버한테 질문을 던지는 역할을 담당하는 리졸버(Resolver)가 있다. 웹 브라우저가 이 리졸버에게 도메인 주소의 IP를 알아봐달라고 부탁하면, 리졸버는 DNS 서버한테 물어봐서 답을 전달해준다.

 

3. 전 세계의 DNS 서버가 연대한다

추상화해서 이야기하면 DNS 서버에 이 세상의 모든 도메인과 IP 주소가 기록되어 있다고 했지만, DNS 서버 하나에 모든 데이터가 몰빵으로 들어가있지는 않다. 도메인을 보면 http://www.naver.com과 같이 구성되어 있는데 .com  도메인에 해당하는 데이터를 가지고 있는 DNS 서버가 있고, .kr 도메인에 해당하는 데이터를 가지고 있는 DNS 서버가 별도로 있다. 그리고 루트 도메인 서버라고 해서 이 모든 도메인 서버들과 연결되어있는 최상위 서버가 있다. 

 

여튼 리졸버는 여러 대의 DNS 서버 중에서 자신과 가장 가까이 있는 DNS 서버에 리졸브 요청을 보낸다. 이 세상에 있는 모든 DNS 서버에는 루트 DNS 서버의 주소를 알고 있기 때문에, 하위 DNS 서버는 자기가 받은 요청을 루트 도메인 서버에 다시 날린다. 그러면 루트 도메인 서버는 URL을 보고서는 '아 얘는 .com을 관장하는 도메인 서버가 알고 있을거야. 그 도메인 서버 IP주소가 xxx.xxx.xxx.xxx니까 여기로 다시 요청 날려봐'라고 답을 준다. 그러면 그 하위 DNS 서버는 다시  xxx.xxx.xxx.xxx로 요청을 날려서 실제 사용자가 적은 URL의 IP 주소를 찾아간다. 

 

4. 프로토콜 스택에 메시지 송신을 의뢰한다

3번까지 해서 상대 서버의 IP 주소를 알아냈으면 이제 진짜로 HTTP Request Message라는 데이터를 보내야 한다. 그런데 이 데이터를 보내는 일 자체도 웹 브라우저가 직접 수행하지 않는다. OS의 내부에 있는 프로토콜 스택(OS에 이미 개발되어 있는 TCP/IP 소프트웨어라고 생각하면 된다)에게 그 일을 의뢰한다. 

 

일단 데이터를 보내려면 데이터를 보내는 쪽과 받는 쪽 사이에 파이프라인이 구축되어야 한다. 그 작업을 수행하기 위해서는 다음과 같은 단계를 거친다.

1. 브라우저에서 프로토콜 스택한테 소켓 생성을 요청한다.

2. 소켓이 생성되면 디스크립터(Descriptor)라는 데이터가 브라우저에 반환되고, 브라우저는 이를 메모리에 들고 있는다.

3. 1에서 받은 디스크립터, 이전 단계에서 얻은 상대 IP 주소, (대체로 모두가 공공연하게 알고 있는) 포트번호를 가지고 브라우저는 프로토콜 스택에게 connect 작업을 요청한다. 이 단계에서 파이프라인의 구성이 완료된다고 보면 된다. 

 

이제 연결된 파이프라인을 통해 데이터가 서버에 넘어간다.