주소창에 www.naver.com을 입력하면 무슨 일이 일어날까?

당연히 네이버 화면이 뜬다. 하지만 어떤 과정을 통해서 네이버 화면이 띄워지는지는 모르는 사람이 더 많을 것이다.

그렇다면 웹 브라우저는 어떤 원리로 네이버 화면을 찾아서 띄워주는 걸까?

 

(1) 도메인 네임을 웹 서버의 IP주소로 변환

네이버의 홈 화면을 사용자에게 보여주고 싶다면 무엇이 필요할까? 네이버 홈 화면의 HTML 파일, CSS 파일, 스크립트 파일, 이미지 파일... 필요한 건 많은데 설치될 때부터 이걸 갖고있는 브라우저는 없을 것이다. 이런 정보들은 네이버의 웹 서버에 존재하기 때문에, 브라우저는 네이버 웹 서버와 통신하여 필요한 정보들을 받아와야 한다.

 

그럼 네이버의 웹 서버는 어떻게 찾을까? 우리가 길을 찾을 때 주소를 통해서 찾듯 컴퓨터도 각자 주소를 갖고 있는데, 바로 IP주소이다.

IP 주소는 일반적으로 12자리 숫자로 되어 있다. 전화번호도 못 외우는 세상에 다음, 네이버, 구글 등 수많은 웹사이트의 IP를 외우기란 쉽지 않다. 그래서 우리는 평소에 IP주소 대신 naver.com과 같은 도메인 네임을 사용한다. 이 도메인 네임은 사람의 편의성을 위해 만든 주소라서, 0과 1밖에 모르는 컴퓨터는 이해하지 못한다. 컴퓨터를 위해서는 도메인 네임을 IP 주소로 바꿔줘야 한다.

💡 IP주소란?
- 컴퓨터들이 인터넷 상에서 서로를 식별하기 위해 부여받는 번호.
- IPv4와 IPv6 두 종류가 있는데, IPv4 주소의 고갈 우려로 인해 더 긴 주소 체계인 IPv6가 고안되었다. IPv4는 4byte, IPv6는 16byte로 이루어져 있다.
- 테스트 용도로 자주 사용하는 127.0.0.1이라는 IP는 사실 루프백 주소로, 모든 컴퓨터에서 자기 자신을 의미한다. 주소에 '우리집'이라고 적는 꼴.

 

 

만약 네이버의 웹 서버와 통신한 적이 있다면, 네이버의 IP주소를 이미 알고 있을 것이다. 그래서 브라우저는 먼저 캐시에 도메인 네임(www.naver.com)에 대응하는 IP주소(125.209.222.142)가 있는지를 확인한다.

캐시에 네이버의 IP주소가 없다면, 브라우저는 DNS(Domain Name Server)에게 www.naver.com에 대응되는 IP주소를 알려달라는 요청을 보낸다.

💡캐시 확인 순서
    1. 가장 먼저 브라우저 캐시를 확인한다.
    2. 브라우저 캐시에 대응되는 IP주소가 없으면, systemcall을 통해 운영체제의 캐시를 확인한다.
    3. 그 다음에는 라우터에 캐싱된 DNS 기록을 확인한다.
    4. IP 주소 요청을 받은 DNS도 먼저 캐시에 해당 도메인 네임에 대응되는 IP주소가 있는지를 찾아본다.

 

 

ISP(Internet Service Provider)의 DNS 서버는 네이버의 IP주소를 찾기 위해 다른 DNS 서버들에게 'www.naver.com의 IP주소를 알고 있는지'를 물어본다.

네임 서버는 계층 구조로 되어있다. 가장 먼저 루트 네임 서버에게 가서 물어보면, 루트 네임 서버는 .com 도메인 담당 네임 서버의 IP주소를 알려주고, ISP의 DNS는 그 네임 서버에게 다시 묻는다. 이런 식으로 . → .com → naver.com  → www.naver.com 에  대응되는 네임서버를 찾아다니다가, 네이버의 IP주소를 아는 네임 서버를 만나면 답장을 받는다.

 

(2) 웹 서버에게 HTTP Request 전송

주소를 알아냈으니 택배를 보낼 차례이다. 클라이언트의 브라우저는 OS를 호출하여 웹 서버에게 전송할 메세지를 넘긴다. 그러면 클라이언트의 컴퓨터는 통신을 위해 TCP 소켓을 개방하고, 3-way handshaking*을 통해 연결을 요청한다. 메세지는 프로토콜 계층을 내려가며 패킷으로 쪼개지고, 수신자 및 발신자의 포트번호, IP주소, MAC주소 등의 정보가 덧붙여진다. 그리고 패킷을 라우터에게 넘기면, 라우터는 수신 주소를 보고 그에 맞는 Next Hop Address*를 찾아 다음 라우터로 패킷을 전송해준다.

 

 

* 3-way handshaking: 클라이언트가 서버에게 연결을 요청하고, 연결이 잘 되었는지 확인하는 일련의 과정이다.

* Next Hop Address: 다음 라우터의 주소. 패킷은 라우터를 징검다리 삼아 네트워크를 폴짝폴짝 이동하는데, '폴짝'에 해당하는 것이 바로 Hop이다.

 

(3) 웹 서버가 WAS를 호출하여 요청 처리

수많은 라우터를 거쳐 웹 서버가 있는 LAN에 도착한 패킷은 방화벽에 의해 검사된다. 방화벽을 통과하면 캐시 서버가 해당 요청에 대한 응답이 캐시에 존재하는지를 먼저 체크한 뒤, 없으면 웹 서버로 요청을 전달한다.드디어 웹 서버에 도착한 패킷은 TCP/IP 계층을 역순으로 거쳐 올라가며 앞에 붙어있던 헤더를 떼고, 패킷 속에 들어있던 메세지들이 조합되어 웹 서버의 어플리케이션 계층에 전달된다.

 

웹 서버가 모든 일을 혼자서 처리할 수 있다면 좋겠지만, 그러기엔 웹 서버가 할 일이 너무 많다. 때문에 일반적으로 웹 어플리케이션 서버, WAS를 두게 된다. 웹 서버는 DB가 필요한 작업 등은 WAS를 호출하여 처리한다. WAS는 동적인 컨텐츠(JSP, ASP, PHP 등)를 처리하여 웹 서버에게 반환해주고, 웹 서버가 WAS의 응답을 받아 정적인 컨텐츠(HTML, CSS, 이미지 등)를 처리한다.

💡WAS에는 DB에 대한 접속 정보가 있다. 이러한 정보는 외부에 노출되면 보안 문제가 생길 수 있기 때문에, WAS는 웹 서버를 통해 요청을 전달받는다.

 

(4) 클라이언트에게 HTTP Response 전송

이제 클라이언트가 요청한 데이터가 모두 준비되었다. 웹 서버의 어플리케이션은 요청받았던 html 문서를 응답 메세지에 넣어 HTTP Response로 만든 다음, 클라이언트에게 전송한다. 응답 메세지도 요청 메세지처럼 패킷으로 쪼개져 라우터들 사이를 폴짝폴짝 이동한다.

 

(5) 웹 브라우저가 html 문서를 화면에 렌더링

 

HTML 문서를 전달받은 웹 브라우저는 먼저 브라우저 엔진을 이용해 응답 데이터에 악성 코드가 있는지를 검사한다. 악성 코드가 없다면 렌더링 엔진에게 해당 문서를 해석하여 웹 페이지를 화면에 렌더링할 것을 요청한다. 그러면 렌더링 엔진이 응답받은 문서를 바탕으로 렌더링을 수행하고, 작업이 완료되면 브라우저 엔진이 사용자에게 화면을 보여준다.

 

---

지금까지 웹 브라우저가 웹 서버와 통신하며 웹 페이지를 화면에 보여주는 과정을 알아보았다.

(2)에서 브라우저는 OS를 호출하여 메세지를 넘기고, 메세지는 패킷으로 쪼개져 전송된다고만 설명했다. 하지만 이는 매우 간단하게 설명한 것이고, 실제로는 웹 브라우저 내의 소켓 라이브러리를 통해, 운영체제의 프로토콜 스택을 호출한다. 그리고 실제 프로토콜 스택에서는 더 많은 일이 일어난다.

메세지가 어떻게 쪼개지고, 어떻게 포장되고, 어떻게 회선을 통해 전송되는지를 파악하려면 먼저 OSI 7계층에 대해 알아야 한다. 1주차 스터디 범위가 여기까지인 관계로, OSI 7계층에 대해서는 다음에 알아보자.