티스토리 뷰
IP 주소의 기본
HTTP 메시지를 만들면 이후에는 OS에 의뢰하여 액세스 대상의 웹 서버에게 송신한다. 앞서 설명한 것처럼 브라우저는 URL을 읽고 HTTP 메시지를 만들지만, 메시지를 네트워크에 송출하는 기능은 없으므로 운영체제에 네트워크에 송출하도록 위임한다.
이때 URL안에 쓰여있는 서버의 도메인 명에서 IP 주소를 획득해야 한다. IP 주소는 TCP/IP의 개념에 기초해서 만들어졌고, TCP/IP는 서브넷이라는 작은 네트워크를 라우터로 접속하여 전체 네트워크가 만들어진다고 생각할 수 있다. 쉽게 생각하면 하나의 허브에 여러 컴퓨터가 접속되었다는 것이다.
IP 주소는 OO동 OO번지 라는 형태로 네트워크 주소를 할당받는데, 여기서 동에 해당하는 번호가 서브넷에 할당되고, 번지에 해당하는 호스트 번호가 컴퓨터에 할당된다. 서브넷 + 호스트 번호로 이뤄진 것이 IP 주소이다. 액세스 대상의 서버까지 메시지를 운반할 때는 이 IP 주소에 따라 대상이 어디 있는지 판단하고 운반한다.
송신 측이 메시지를 보내면 서브넷 안에 있는 허브가 운반하고, 송신측에서 가장 가까운 라우터에 도착한다. 라우터는 다음 목적지로 이동할 수 있는 라우터를 탐색하고 해당 라우터로 보내도록 지시하며 허브가 다음 라우터까지 메시지를 보낸다. 이런 과정을 반복하면 최종적으로 데이터가 목적지(수신 측)에 도착한다. 이것이 TCP/IP와 IP 주소의 기본적인 개념이다.
도메인명과 IP 주소를 구분해 사용하는 이유
TCP/IP는 IP 주소로 통신 상대를 지정하므로 IP 주소를 모르면 상대에게 데이터를 전달할 수 없다. 그러므로 OS에 메시지 송신을 의뢰할 때는 상대의 IP 주소를 알아내 반드시 전달해줘야 한다. 그렇다면 왜 URL에 IP 주소를 쓰지 않고 도메인명을 사용할까?
www.abc.co.kr이라는 도메인명이 있고 해당 IP 주소는 192.168.123.456 이라고 하면, 도메인 명으로도 접속할 수 있고 IP 주소를 브라우저에 입력해도 접속할 수 있다. 우리가 전화번호를 외우기 어려워서 전화번호부에 저장해 사용하는 것처럼 IP 주소도 외우기 어렵습니다. 따라서 192.168.123.456라는 주소를 www.abc.co.kr을 이용해 접속할 수 있다.
하지만 컴퓨터의 입장에서는 도메인 명을 사용하는 것은 불필요한 낭비라고 할 수 있다. IP 주소는 32비트, 즉 4바이트에 해당하는 개수밖에 없지만, 도메인 명은 적어도 수십 바이트부터 최대 255바이트나 있다. 그러면 그만큼 라우터가 부하되어 데이터를 운반하는 동작에 더 많은 시간이 걸리면서 네트워크 속도가 느려진다. 그러므로 도메인 명을 통해서 IP 주소를 반환할 수 있는 매핑 테이블 같은 시스템이 존재하면 중재자의 역할을 할 수 있을 것이고, 해당 시스템이 DNS(Domain Name System)이다.
DNS 서버 조회
IP 주소를 알아내는 방법은, 가장 가까운 DNS 서버에 도메인에 해당하는 IP 주소 내놔! 라고 요청하는 것이다. DNS 서버에 조회한다는 것은 DNS 서버에 조회 요청을 보내고 거기에 따른 응답 메시지를 받는다는 것이다. 그러므로 DNS 서버에 대해 클라이언트로 동작한다고도 할 수 있다. 이 DNS 클라이언트에 해당하는 것을 DNS 리졸버 또는 리졸버라고 부른다. 그리고 DNS의 원리를 사용해 IP 주소를 조사하는 것을 네임 리졸루션(name resolution)이라 하는데, 이 리졸루션을 실행하는 것이 리졸버이다.
네트워크 애플리케이션(브라우저)이 리졸버를 호출하면 제어가 리졸버의 내부로 넘어간다. 그러면 애플리케이션의 동작이 일시적으로 정지하고 Socket 라이브러리 내용에 있는 리졸버가 움직이기 시작해 애플리케이션에서 의뢰받은 작업을 실행한다. 리졸버에 제어가 넘어가면 여기에서 DNS 서버에 문의하기 위한 메시지를 만든다. 이 과정은 브라우저가 웹 서버에 보내는 HTTP 요청 메시지를 만드는 것과 유사하다.
www.abc.co.kr이라는 서버의 주소를 가르쳐 주세요라는 메시지를 DNS 서버에 보내면, 메시지 송신 동작은 리졸버가 스스로 실행하는 것이 아니라 OS 내부에 포함된 프로토콜 스택(TCP/IP 소프트웨어)을 호출해 실행을 의뢰한다. 왜냐하면 리졸버도 브라우저와 같이 네트워크에 대해 송, 수신하는 기능이 없기 때문이다.
액세스 대상의 웹 서버가 DNS에 등록되어 있으면 해당 값을 응답 메시지에 써서 클라이언트에게 전달한다. 그러면 메시지를 네트워크를 통해 클라인언트 측에 도달하고 프로토콜 스택을 경유해 리졸버에 건네져서 리졸버가 내용을 해독한 후 IP 주소를 추출해 애플리케이션에게 IP 주소를 건네준다.
nslookup을 이용해 도메인의 public IP 주소를 찾아볼 수 있다. 여기서 Server와 Address 정보는 어느 DNS 서버에 쿼리를 요청했는지를 의미한다. 별도로 DNS 서버를 지정하지 않으면 시스템에서 사용중인 DNS 서버에서 DNS 정보를 조회한다.
여기서 Non-authoriative answer이란 '신뢰할 수 없는 답변' 이라는 뜻인데, 이는 사용자가 이용하는 DNS 서버가 도메인 소유자가 등록한 1차 정보원이 아니기 때문이다. 이게 무슨 말인지 와닿지 않아 찾아봤는데 DNS 서버는 상위 DNS 서버에 쿼리를 하고 다시 이를 캐시 해서 가지고 있다고 한다. 따라서 캐시에 따라서 최신 정보와 다르거나, 혹은 DNS 서버 자체를 신뢰할 수 없는 경우 악의적인 조작을 하는 것이 가능하기 때문에 신뢰할 수 없다고 보여주는 것 같다.
신뢰할 수 있는 답변을 얻기 위해서는 SOA 레코드를 조회해서 해당 도메인의 정보가 등록되어 있는 DNS 서버를 확인하고, 이 서버에 조회를 해보면 된다고 한다.
여기서 origin으로 출력되는 서버를 DNS 서버로 지정해서 조회해보면
Non-authoriative answer이 표시되지 않는 것을 볼 수 있다.
반대로 IP 주소를 이용해서 도메인명을 찾아볼 수도 있다.
'Network' 카테고리의 다른 글
[Network] 프로토콜 스택과 메시지 송신 (2) | 2023.04.30 |
---|---|
[Network] DNS 서버 동작 방법 (0) | 2023.04.21 |
[Network] 웹 브라우저 - HTTP 메시지 (7) | 2023.04.16 |
[HTTP] Request 요청 데이터를 전달하는 방법 (0) | 2022.01.29 |
[HTTP] 헤더 - 캐시, 조건부 요청 (0) | 2022.01.10 |
- Total
- Today
- Yesterday
- java
- 알림개선기
- 스프링MVC
- 3차 데모데이
- CI/CD
- dm-zoned 코드분석
- ZNS SSD
- 피움 6주차 회고
- Spring
- jpa
- 알림기능개선기
- 피움
- 네트워크
- 우테코
- 파이썬
- 프로젝트
- 팀프로젝트
- 스프링 Logback
- ZNS
- 런칭 페스티벌
- 5주차 회고
- 스프링 프레임워크
- 백준
- dm-zoned
- 우테코 회고
- 스프링 부트
- 회고
- 2차 데모데이
- 환경 별 로깅 전략 분리
- 8주차 회고
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |