웹 서버의 IP주소를 DNS 서버에 조회한다. - [Ch 01. 웹 브라우저가 메시지를 만든다]

  HTTP의 메시지를 만들면 이것을 OS에 의뢰하여 액세스 대상의 웹 서버에게 송신한다. 브라우저는 URL을 해독하거나 HTTP 메시지를 만들지만, 메시지를 네트워크에 송출하는 기능이 없기 때문에 OS에 의뢰하여 송신하는 것이다.

 

  OS에 송신을 의뢰할 때는 도메인명이 아니라 IP 주소로 메시지를 받을 상대를 지정해야 한다. 그래서 URL 안에 쓰여있는 서버의 도메인명으로 IP 주소를 조사해야 한다.

  그래서 이번 글에서는 도메인명에서 IP 주소를 조사하는 방법을 알아보고자 한다.

 

📙 1. IP 주소의 기본

🚩 1. 기본 동작

  우선, TCP/IP 개념과 함께 IP 주소에 대해서 알아보자.

 

  TCP/IP는 서브넷이라는 작은 네트워크를 라우터로 접속하여 전체 네트워크가 만들어진다고 생각할 수 있다.

  서브넷이란 허브에 몇 개의 PC가 접속된 것이라고 생각하면 되겠다.

 

  여기에 'XX 동 OO번지'라는 형태로 네트워크 주소를 할당한다. 동에 해당하는 번호를 서브넷에 할당하고, 번지에 해당하는 번호를 컴퓨터에 할당하는 것이다.

  동에 해당하는 번호를 네트워크 번호, 번지에 해당하는 번호를 호스트 번호라고 하며, 두 주소를 합쳐서 IP 주소라고 한다.

• IP 주소 = 네트워크 번호 + 호스트 번호

액세스 대상의 서버까지 메시지를 운반할 때는 이 IP 주소에 따라 아래와 같이 액세스 대상이 어디에 있는지 판단하고 운반한다.

1. 송신 측이 메시지를 보내면 서브넷 안에 있는 허브가 운반하고, 송신 측에서 가장 가까운 라우터까지 도착한다.
2. 그리고 라우터가 메시지를 보낸 상대를 확인하여 다음 라우터를 판단하고, 거기에 보내도록 지시하여 송신 동작을 실행한 후 다시 서브넷의 허브가 라우터까지 메시지를 보낸다.
3. 이런 동작을 반복하여 최종적으로 데이터가 목적지에 도착한다.

 

🚩 2. IP 주소 분석

IP 주소는 32비트의 디지털 데이터다.

00001010.00000001.00000010.00000011
→ 10.11.12.13

  위와 같이 8비트(1바이트)씩 점으로 구분하여 10진수로 표기한다.

  하지만, 이것만으로는 어느 부분이 네트워크 번호인지 호스트 번호인지를 알 수 없다. 그저 네트워크 번호와 호스트 번호를 합쳐서 32비트로만 표현되어 있을 뿐이다.

 

  그래서 네트워크를 구축할 때 사용자가 직접 내역을 결정할 수 있다. 이 내역을 나타내는 정보를 필요에 따라 IP 주소에 덧붙이는데, 이 정보를 '넷마스크'라고 한다.

 

  넷마스크는 IP 주소와 같이 32비트 부분의 디지털 데이터이며, 왼쪽에는 1이 나열되고 오른쪽에는 0이 나열된 값이다.

1인 부분은 '네트워크 번호', 0인 부분은 '호스트 번호'를 나타낸다.

11111111.11111111.11111111.00000000
→ 255.255.255.0

넷마스크도 IP 주소와 같이 8비트씩 구분하여 표기한다.

 

  IP주소의 오른쪽에 넷마스크를 붙이면 아래와 같다.

{IP 주소}/{넷마스크}
10.1.2.3/255.255.255.0

그러나 위와 같이 적으면 표기가 너무 길어지므로 한 부분의 비트 수를 10진수로 나타내어 아래와 같이 표기한다.

{IP 주소}/{넷마스크}
10.1.2.3/24

호스트 번호 부분의 비트 값이 모두 0 또는 1인 경우는 아래와 같이 특별한 의미를 가진다.

• 호스트 번호 부분이 모두 0인 IP 주소
  각각의 기기를 나타내는 것이 아니라 서브넷 자체를 나타낸다.
• 호스트 번호 부분이 모두 1인 IP 주소
  서브넷에 있는 기기 전체에 패킷을 보내는 브로드캐스트를 나타낸다.

 

 

📙 2. 도메인명과 IP 주소를 구분하여 사용하는 이유

  URL에 서버명 대신 IP 주소를 써도 올바르게 동작한다. 그러나 전화번호를 기억하기 어려운 것처럼 서버명을 이용하는 게 더 편리하다.

 

  그러면 IP 주소로 통신하는 게 아니라 서버명으로 통신하면 되지 않을까라는 생각을 할 수 있다. 기술적으로 구현한다고 하면 불가능한 방법은 아니다.

  하지만, 실행 효율이라는 관점에서 보면 이것은 좋은 방법이 아니다. IP 주소는 32비트를 사용하지만, 도메인명은 적어도 수십 바이트부터 최대 255바이트를 사용하기 때문이다.

 

  그렇기 때문에 서버명을 그래도 사용하여 상대와 통신하는 것은 현명한 방법이 아니다.

 

 

📙 3. Socket 라이브러리가 IP 주소를 찾는 기능을 제공한다.

  IP 주소를 찾는 방법은 간단하다. 가장 가까운 DNS 서버에 'www.naver.com'이라는 서버의 IP 주소를 알려달라고 요청하면 된다. 그러면 DNS 서버가 도메인의 IP주소를 알려준다.

 

  그렇다면 브라우저는 어떻게 해서 DNS 서버를 조회할 수 있을까?

  DNS 서버를 조회한다는 것은 DNS 서버에 조회 메시지를 보내고 그에 해당하는 응답 메시지를 받는 것이다. 그래서 DNS 서버에 클라이언트로 동작한다고 할 수 있는데, 이것을 DNS 리졸버 또는 리졸버라고 부른다.

  그리고 리졸버가 DNS의 원리를 사용하여 IP 주소를 조사하는 것을 네임 레졸루션(Name Resolution)이라고 한다.

 

  리졸버의 실체는 Socket 라이브러리에 들어있는 부품화된 프로그램이다.

  Socket 라이브러리는 OS에 포함되어 있는 네트워크 기능을 애플리케이션에서 호출하기 위한 부품을 모아놓은 것이고, 리졸버는 그 속에 들어있는 프로그램 부품의 하나인 것이다.

 

 

📙 4. 리졸버를 이용하여 DNS 서버를 조회한다.

  Socket 라이브러리에 들어있는 프로그램은 부품화되어 있고 애플리케이션에서 간단히 호출하여 이용할 수 있다.

  브라우저 등의 애플리케이션 프로그램을 만들 때 다음과 같이 리졸버의 프로그램명(gethostbyname)과 웹 서버의 이름(www.naver.com)을 쓰기만 하면 리졸버를 호출할 수 있다.

<애플리케이션 프로그램의 이름>(<매개변수>)
{
    ...
    <메모리 영역> = <리졸버의 프로그램명>(<조회하는 서버의 도메인명>)
    ...
    <HTTP 메시지 송신>
    ...
}

 

그러면 리졸버가 호출되고, 리졸버가 DNS 서버에 조회 메시지를 보내고, DNS 서버에서 응답 메시지가 돌아온다.

 

 

📙 5. 리졸버 내부의 작동

리졸버의 자세한 내부 동작은 다음과 같다.

 

1. 리졸버를 호출하는 부분에 이르면 애플리케이션의 동작은 일시적으로 정지하고, 리졸버에 제어가 넘어간다.
2. 리졸버는 DNS 서버에 문의하기 위한 메시지를 만든다.
3. 메시지를 DNS 서버에 보낸다.
4. 메시지 송신 동작을 리졸버 스스로 실행하는 것이 아니라 OS의 내부에 포함된 프로토콜 스택을 호출하여 실행을 의뢰한다.
   리졸버도 브라우저와 같이 네트워크에 대해 데이터를 송수신하는 기능이 없기 때문이다.
5. OS 내부의 프로토콜 스택으로 제어가 넘어가고, LAN 어댑터를 통해 메시지가 DNS 서버를 향해 송신된다.
6. 응답 메시지가 프로토콜 스택을 거쳐 리졸버로 간다.
7. 리졸버가 내용을 해독하여 IP 주소를 추출하고, 해당 IP 주소를 애플리케이션에게 건네준다.
   실제로는 리졸버를 호출할 때 지정한 메모리 영역에 IP 주소를 저장한다.
8. 제어가 애플리케이션으로 돌아오고 애플리케이션은 IP 주소를 획득한다.

 

  그러면 "DNS 서버의 IP 주소는 어떻게 알고 있는 거지?"라는 한 가지 의문점이 생길 수 있다. 이것은 TCP/IP 설정 항목의 하나하나로 컴퓨터에 미리 설정되어 있다.

  윈도우의 경우 명령 프롬프트를 켜고 'ipconfig /all'이라고 입력하면 DNS 서버의 주소를 확인할 수 있다.

 

해당 글은 Tsutomu Tone 님의 '성공과 실패를 결정하는 1%의 네트워크 원리'를 참고하였습니다.

[이미지 출처]
Hoyeon 님의 '[Network] 어떻게 DNS 서버가 IP 주소를 조회할까'