02 웹서버의 IP 주소를 DNS 서버에 조회한다.
본 설명은 책 “성공과 실패를 결정하는 1%의 네트워크 원리”를 읽으며 제 나름대로 해석하고 정리해 보았습니다.
1. IP 주소의 기본
브라우저가 HTTP 리퀘스트 메시지를 만들지만, 메시지를 네트워크에 송출할 수 는 없다. 따라서 이를 OS에 의뢰하여 송신하는데, 이때 URL 에 써있는 도메인명 즉, IP 주소 값을 알아야한다. (즉, 내가 편지를 부친다고 치면 우체부(OS)가 편지를 배달하기 위해 편지에 적혀져있는 주소(IP)를 확인하는 것이다).
먼저, 이 개념을 설명하기 전에 IP 주소 에 대해 간략하게 짚고 넘어가보자.
여기서 알아야 할 개념이 서브넷, 허브, 라우터 이다. 간단하게 설명하자면 서브넷은 허브에 몇대의 컴퓨터가 접속한 것인지의 한개의 단위를 서브넷 이라고 한다. 그리고 이 서브넷들이 라우터에 연결되면 네트워크가 형성되는 것이다.
.png)
다시 편지 개념을 생각해서 네트워크 주소를 ‘A동 B번지’ 라고 생각했을때 서브넷이 A동이 되고, 컴퓨터(PC)를 B번지라고 할당한 것이 네트워크의 주소인 것이다. A동에 해당하는 것을 네트워크 번호 라고 하고, B번지에 해당하는 것을 호스트 번호 라고 한다. 그리고 이 두 주소를 합친것이 IP 주소 인 것이다. (참고로 헷갈리면 안되는 게 예를 들면 네이버주소 즉 얘네도 서버, 하나의 PC일 뿐이다. 때문에 “오잉 컴퓨터..? 사용자만 컴퓨터 즉 IP주소가 있는거아니야 ? “ 라고 생각하지말자)
그래서 이제 어떠한 순서대로, 리퀘스트 메시지가 전송되냐 ?
- 송신측(사용자) 에서 메시지를 보내면 서브넷 안에 있는 허브가 이 메시지를 운반한다. (위의 그림에서 하단 왼쪽 PC라 생각하자)
- 그리고 송신측(사용자)에서 가장 가까운 라우터까지 도착한다. (왼쪽 하단위에 연결된 라우터)
- 그다음 라우터가 메시지를 보고 판단하여 다음 다음 라우터 어디에 보내야할지 판단하고
- 메시지를 보낸뒤, 해당 서브넷(예를들면 네이버쪽)의 허브가 라우터까지 메시지를 보낸다.
IP 주소 표기 방법에 대해는 아직 이해가 가지않는다.. 추후 업데이터 예정
2. 도메인명과 IP 주소를 구분하여 사용하는 이유
“그러면 그냥 IP 주소를 사용해서 굳이 도메인명에 해당하는 IP 주소 값을 찾지 않고, 그냥 IP 주소를 때려박으면 되는거 아니냐?” 라고 말할 수 있다.
그에 대한 답변은 “ 그래 그렇게 할 수 있는데, 굳이..? 너 그 번호 다 기억할 수 있어? 기억할 수 있다면 짱이고뭐..” 라고 말할 수 있겠다. 당연히 네이버를 네이버라고 기억하는게 쉽지 32비트짜리 IP 주소를 외우는건 참 비효율적이다.
또 그럼 이렇게 물어볼 수 있다.
“아니 그러면 그냥 IP주소 자체를 비트값말고 문자로 취급해버려~ 그럼 샐행효율도 좋고 사용자도 좋고 윈윈 아니야? “ 라고 말이다.
그렇지만, 인터넷 내부에는 규칙이라는 게 있다. 그래서 IP 주소에 의해 목적지가 어디인지 판단하면서 데이터를 들고다니는데 IP 주소 대신 이름을 쓰면? IP 주소는 32비트, 즉 4바이트 개수밖에 없지만, 도메인명은 적어도 수십 바이트 ~ 255바이트까지 될 수 있다. 그럼 결국 라우터가 당연히 부하되고 네트워크 속도는 똥망이 되는 것이다.
그럼 또 “아니 요새 기술도 발전했겠다.. 고성능 라우터 쓰면 되는거아냐?” 라고 물어볼 수 있다.
하지만 라우터 속도에는 아쉽게도 한계다. 사실 뭐 기술이 그렇게 발전했다 하지만들, 라우터 동작 속도는 향상됬지만 왔다갔다 하는 데이터 양도 그에 비해 엄청나게 증가하였기 때문에 위의 질문에 대한 대답은 “삐 —- 나가리입니다.” 라고 할 수 있다.
아 근데 생각해보니까 NAVER.COM에서 IP주소를 알게해주는게 누구야?
바로 DNS다.
DNS 이 녀석이 이름을 알면 IP주소를 알 수 있고, IP 주소를 알면 이름을 알 수 있게 해주는 참 좋은 친구다.
3. Socket 라이브러리가 IP 주소를 찾는 기능을 제공한다.
그래서, 결국에 우리가 www.naver.com 주소를 DNS한테 “이거 IP 주소 알려줘” 라고 물어보면 “그래 그 IP 주소는 xxx.xxx.xxx.xxx야~ “ 라고 알려줄 것이다. 음 여기까지 굉장히 간단해보이지만 또 다른 의문은 그럼 브라우저는 도대체 어떻게 DNS 서버를 조회할 수 있는 거지 ? 브라우저와 DNS는 어떻게 연결되는 것일까? 라고 의문이 들것이다.
사실, DNS 서버 조회라는 것도 그냥 비슷하다 조회 메시지를 보내고, DNS에게 응답 메시지를 받는 것이다. 이건 DNS 서버에 대해 클라이언트로 동작하는 것인데 이 DNS 클라이언트에 해당하는 것이 DNS 리졸버 단순하게 리졸버 라고 부른다. 그리고 DNS의 원리를 사용하여 IP 주소를 조사하는 것이 네임 리졸루션 인데 이 리졸루션을 실행하는 것이 리졸버가 하는 일이다.
리졸버는 Socket 라이브러리 에 들어있는 부품 프로그램이다.
4. 리졸버를 이용하여 DNS 서버를 조회한다
그래서 결국, 도메인명에서 IP를 조사할때 브라우저가 Socket 라이브러리의 리졸버 를 활용하여 리졸버를 호출하고 > 리졸버가 DNS 서버에 조회 메시지를 보내고 > DNS 서버에서 응답 메시지가 돌아오는 것이다.
그리고 리졸버가 이 응답메시지 내용 즉, IP 주소를 추출하여 브라우저에서 지정한 메모리 영역에 넣는 것이다.
1
2
3
4
5
6
# 리졸버를 호출하는 방법
<어플리케이션 프로그램 이름> (<매개변수>)
{
<메모리영역> = gethostbyname("www.naver.com")
<HTTP 메시지 송신>
}
5. 리졸버 내부의 작동
리졸버를 호출하게 되면 이제 제어가 리졸버에게 넘어간다. (프로그래밍 해본 사람은 이 의미가 무슨말인지 쉽게 알아들을 것이다) 그럼이 제어가 넘어간 리졸버 내부에서 어떻게 동작하는지 살펴보자.
먼저, DNS 서버에 문의하기 위한 메시지를 만든다. (HTTP 리퀘스트 메시지와 유사)
그러면 메시지를 DNS 서버에 보낸다.
그런데 이 메시지 송신 작업은 리졸버도 브라우저와 마찬가지로 네트워크에 대해 데이터를 송.수신하는 기능이 없기 때문에 OS 내부에 포함된 프로토콜 스택 을 호출하여 실행을 의뢰한다.
프로토콜 스택 OS 내부에 내장된 네트워크 제어용 소프트웨어. ‘프로토콜 드라이버’, ‘TCP/IP 소프트웨어’ 등으로 부른다.
리졸버가 프로토콜 스택을 호출하면 다시 제어가 넘어가고 결국 LAN 어댑터를 통해서 메시지가 DNS 서버를 향해 송신 되게 되는 것이다. 응답은 반대 방향으로 가서 결국 메모리 영역에 IP주소를 저장하게 되는 것이다. 이렇게 되면 리졸버의 동작이 끝나고 제어가 어플리케이션(브라우저)에게 다시 돌아오는 것이다.
그리고 참고로 DNS 서버도 서버니까 당연히 DNS 서버의 IP 주소가 필요하다. 이 경우 TCP/IP 설정 항목의 하나하나로 컴퓨터에 미리 설정되어 있기때문에 따로 조사할 필요 없다.
참고로 그럼 누가 내 DNS 서버 주소를 찾아주냐 ? OS 내부에서 자동으로 연결된 통신사 인터넷의 DNS IP 주소를 할당해준다. 물론 수동으로 내가 임의로 설정도 가능하다.
.png)