브라우저에 URL을 입력하면 무슨 일이 일어날까?

브라우저에 URL을 입력하면 무슨 일이 일어날까? 

간단히 정리하자면 브라우저는 입력된 URL의 의미를 조사하고 Request 메시지를 만든 후 이것을 웹 서버에 보낸다. 그러나 이 메시지는 브라우저 자체가 송신하는 것이 아니라 OS에 내장된 네트워크 제어용 소프트웨어에 의뢰하여 메시지를 서버측까지 도착하게 하는 것이다. 

본 포스팅에서는 브라우저가 이 메시지를 '의뢰하는 동작'에 대해 다룬다. 

 

 

브라우저에 URL을 입력했을때 브라우저가 하는 일에 대해 간단한게 표현해 보자면 아래 그림과 같다. (정확하게 말하자면 HTTP Request를 송신하는 역할은 브라우저가 하는게 아니다) 

 

응답 메시지를 받기까지의 과정을 좀 더 세부적으로 표현해 보자면 아래 그림과 같다. 

 

1. URL을 해독한다. 

 

URL은 어떤 일정한 요소들로 구성되어 있는데, 그 요소들은 아래와 같다. 

프로토콜 + // + 웹서버명 + / + 데이터 출처(파일)의 경로명(디렉토리명과 파일명으로 구분됨) 

 

예를 들어 

http://www.tmon.co.kr/best.html

위의 URL은 http 프로토콜을 이용하여 www.tmon.co.kr  이라는 웹 서버에 있는 best.html 파일에 엑세스 하라는 의미이다. 브라우저는 이런 URL를 분해하고 해독하는 역할을 가장 먼저 수행한다. 

 

 

2. HTTP Request를 만들고 브라우저 내부의 DNS 리졸버를 호출한다.

 

HTTP Request를 만들기 전 이 Request의 목적지를 알아내기 위해 입력한 도메인에 해당하는 IP주소를 조사한다. 

이때 가장 가까운 DNS서버에 IP를 조회하는데, DNS 서버에 조회하는 행위는 DNS서버에 대해 클라이언트로 동작한다고 볼 수 있다. 

이 DNS 클라이언트에 해당하는 것을 DNS 리졸버라 부른다. 그리고 DNS의 원리를 사용하여 IP 주소를 조사하는 것을 네임 리졸루션(name resolution)이라고 한다. 

 

리졸버의 실체는 OS에 포함되어 있는 네트워크의 기능을 호출하기 위한 Socket 라이브러리의 요소 중 하나다. 그 말인즉슨 애플리케이션(브라우저)을 만들 때 도메인명을 입력받아 DNS서버에 조회하는 부분을 Socket라이브러리의 리졸버를 호출하는 방식으로 만들어졌다는 뜻이다.

 

 

3. DNS 리졸버는 OS의 네트워크 기능을 이용하여 DNS서버에 해당 도메인에 대한 IP 조회를 요청한다. 

 

DNS리졸버 역시 브라우저와 마찬가지로 그 자체로는 메시지를 송신하는 기능이 없으므로 OS의 내부에 포함된 프로토콜 스택을 호출하여 실행을 의뢰한다. 리졸버의 역할은 그저 DNS 서버에 문의하기 위한 메시지를 만들고 프로토콜 스택을 호출하여 그 메시지의 송신을 의뢰하는 것 뿐이다. 

 

- 프로토콜 스택 : OS 내부에 내장된 네트워크 제어용 소프트웨어. '프로토콜 드라이버', 'TCP/IP 소프트웨어' 등으로 불린다. 
- HTTP는 메시지를 문자로 작성하지만, DNS의 메시지는 문자가 아니라 바이너리 데이터로 표현한다. 
- DNS 서버에 메시지를 송신할 때도 DNS 서버의 IP 주소가 필요한데, 이는 TCP/IP 설정 항목의 하나로 컴퓨터에 미리 설정되어 있다.(윈도우의 경우 TCP/IP 설정에서 기본 설정 DNS 서버를 확인할 수 있다.) 

 

4. DNS 서버로부터 받은 응답 메시지 안의 IP주소를 추출하여 HTTP Request와 함께 OS에게 건네주어 송신을 의뢰한다. 

 

액세스 대상의 웹 서버가 DNS 서버에 등록되어 있으면 DNS서버는 응답 메시지를 써서 클라이언트에게 반송한다. 네트워크를 통해 클라이언트에게 도착한 응답 메시지는 프로토콜 스택을 경유하여 리졸버에게 건네지고, 리졸버는 내용을 해독한 후 여기에서 IP 주소를 추출하여 지정한 메모리 영역에 저장한다.

 

브라우저 자체는 위에 언급했다시피 스스로 메시지를 송신하는 기능은 없으므로, 액세스 대상 웹 서버에 메시지를 송신하기 위해 프로토콜 스택에게 의뢰해야 한다. 이때도 DNS서버에 조회를 요청하는 것과 마찬가지로 Socket 라이브러리의 기능을 이용한다. 

 

Socket 라이브러리를 이용한 데이터 송수신 동작을 표현해보면 서버 컴퓨터와 클라이언트 컴퓨터 사이에 데이터의 통로(파이프) 같은 것이 있고, 이를 통해 양방향으로 데이터를 주고받는다고 할 수 있는데, 최초부터 그 파이프가 존재하는 것이 아닌, 양자 사이를 파이프로 연결하는 동작이 필요하다. 

요는 양 끝에 있는 데이터의 출입구인데, 이 출입구를 소켓이라고 부른다. 데이터 송,수신 동작을 네단계로 요약해 보면 아래와 같다.  

 

(1) 소켓을 만든다(소켓 작성, socket)

(2) 서버측의 소켓에 파이프를 연결한다(접속, connect)

: 서버측에서 소켓을 만들고, 소켓에 클라이언트가 파이프를 연결하기를 기다린다. 서버측이 기다리고 있는 동안 클라이언트측에서 파이프를 연결한다. 구체적으로는 클라이언트측에도 소켓을 만들고, 소켓에서 파이프를 늘려 서버측의 소켓에 연결하는 것이라고 할 수 있다. 

(3) 데이터를 송,수신한다(송, 수신, write,read)

(4) 파이프를 분리하고 소켓을 말소한다(연결 끊기, close) 

: 데이터를 전부 보내고 나면 연결했던 파이프가 분리된다. 파이프를 연결할 때는 클라이언트측에서 서버측을 향해 연결했지만, 분리는 어느 쪽에서 실행해도 상관 없다. 파이프를 분리하면 소켓을 말소하여 통신 동작이 종료된다. 

 

이 네가지 동작을 실행하는 것은 OS 내부의 프로토콜 스택이다. 브라우저는 자체적으로 파이프를 연결하거나 데이터를 보내지 않고 프로토콜 스택에 의뢰를 한다. 정확히는 Socket 라이브러리를 이용해 프로토콜 스택에 의뢰를 하는 것이다. 

 

- 디스크립터 : 애플리케이션은 소켓을 생성하면 돌아오는 디스크립터를 메모리에 기록한다. 디스크립터는 소켓을 식별하기 위한 식별자인데, 이것이 필요한 이유는 컴퓨터 내부에서 복수의 데이터 송,수신 동작이 동시에 실행되는 경우 각각의 소켓을 구분하기 위함이다.(ex. 브라우저에 2개의 창을 열어 2개의 웹 서버에 동시에 액세스를 시도할 경우)

 

파이프를 연결하는 접속단계(그림의(2)) 에서는 디스크립터와 DNS 서버에서 조회한 액세스 대상 서버의 IP주소, 그리고 포트번호가 필요한데, 서버측의 포트 번호는 애플리케이션의 종류에 따라 미리 결정된 값을 사용한다. 웹은 80번, 메일은 25번 이런식으로 미리 결정된 포트 번호를 지정하면 번호에 대응하는 서버 애플리케이션의 소켓에 접속할 수 있다. 즉 브라우저에서 웹 서버에 액세스할 때의 포트번호는 80번으로 결정되어있다. 

 

애플리케이션은 사용자가 입력한 URL을 바탕으로 만든 HTTP Request 메시지를 메모리에 준비하고 디스크립터와 송신데이터(HTTP Request)를 지정한다. 프로토콜 스택은 디스크립터를 이용해 연결된 상대방을 찾아 데이터를 송신한다.(그림의 (3)) 서버 측은 수신 동작을 실행하여 적절한 응답 메시지를 반송한다.

 

5. 응답 메시지를 받는다.  

 

프로토콜 스택에게 메시지 수신을 의뢰할때(그림의 (4)) 수신한 응답 메시지를 저장하기 위한 메모리 영역을 지정하는데, 이 메모리 영역을 수신 버퍼라고 부른다. 수신 버퍼는 애플리케이션 프로그램의 내부에 마련된 메모리 영역으로, 수신 버퍼에 메시지를 저장한 시점에서 메시지를 애플리케이션에게 건네준다. 

 

브라우저가 데이터 수신을 완료하면 송,수신 동작은 종료되고 연결을 끊도록 의뢰한다.(그림의 (5)) 그러면 프로토콜 스택은 소켓 사이를 연결한 파이프를 분리시키고 소켓을 말소시킨다. 

웹에서 사용하는 HTTP 프로토콜에서는 응답 메시지의 송신을 완료했을 때 웹 서버측에서 연결을 끊는데 이것이 클라이언트측에 전달되어 클라이언트의 소켓도 연결 끊기 단계로 들어가는 것이다. 

 

HTTP 프로토콜은 HTML 문서나 이미지 등의 데이터를 하나하나 별도의 것으로 취급하여 1개의 데이터를 읽을 때마다 접속, 데이터 송수신, 연결 끊기 동작을 반복한다. 그러나 같은 서버에서 복수의 데이터를 읽을 때 접속과 해제를 반복하는 것은 비효율적이므로 한 번 접속한 후 연결을 끊지 않고 복수의 HTTP Request와 응답을 주고받을수 있는 방법도 마련되었는데, HTTP 1.1에서 이 방법을 사용할 수 있다. 

 

 

 

 

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