🌱 도메인 네임과 네임 서버
일반적으로 사용자는 상대 호스트를 특정하기 위해 IP 주소보다는 도메인 네임을 많이 사용합니다.
도메인 네임
호스트의 IP 주소와 대응되는 문자열 형태의 호스트 특정 정보입니다.
DNS 서버
도메인 네임을 관리하는 네임 서버입니다. 도메인 네임과 IP 주소는 DNS 서버에서 관리합니다.
DNS 서버는 도메인 네임에 대한 IP 주소를 알려줍니다. 도메인 네임은 IP 주소에 기억하기 쉽고 IP 주소가 바뀌더라도 그 주소에 도메인 네임을 다시 대응하면 되기 때문에 IP 주소만으로 호스트를 특정하는 것보다 더 간편합니다.
ex)
www.google.com
도메인 네임의 구조는 최상단에 루트 도메인이 있고, 그 다음 단계인 최상위 도메인입니다.
그 아래로 다음 단계의 도메인이 있는 형태입니다. 위 도메인 네임 예시는 전체 주소 도메인 네임 FQDN 형태입니다.
일반적으로 알고 있는 도메인 네임의 마지막 부분은 최상위 도메인 TLD입니다.
www.example.com의 최상위 도메인은 'com'입니다. 최상위 도메인의 종류는 다양하지만 com, net, org, kr, jp, cn, us 등이 존재합니다. company, lawyer 같은 형식도 존재합니다.
루트 도메인은 도메인 네임의 일부이므로 잘못 입력하여 www.google.com. 이렇게 입력하더라도
웹 사이트에 접속이 가능합니다. (루트 도메인은 .)
2단계 도메인
최상위 도메인에서 하부 도메인. 영어로는 세컨드 레벨 도메인입니다. google이 2단계 도메인에 해당합니다. www는 3단계 도메인입니다. 뒷부분이 겹치는 도메인은 많을 수 있는데 FQDN의 첫 번째 부분까지 고려한 도메인 네임은 www.google.com 하나만 세상에 존재합니다. 그래서 www 첫 번째 부분, 3단계 도메인을 호스트 네임이라고 부르기도 합니다.
정리
| 단계 | 도메인 형태 | 부분 |
|---|---|---|
| 1단계 | TLD | com |
| 2단계 | 세컨드 레벨 도메인 | example |
| 3단계 | 호스트 네임 | www |
🌱 계층적 네임 서버
도메인 네임 풀이
IP 주소를 모르는 상태에서 도메인 네임에 대응되는 IP 주소를 알아내는 과정입니다. 영어로는 '리졸빙 한다'라고 표현합니다. 중요한 역할을 담당하는 네임 서버의 유형은 로컬 네임 서버, 루트 네임 서버, TLD 네임 서버, 책임 서버로 표현합니다.
로컬 네임 서버
클라이언트와 맞닿아 있는 네임 서버입니다. 클라이언트가 도메인 네임을 통해 IP 주소를 알아내고자 할 때 가장 먼저 찾게 되는 네임 서버입니다. 클라이언트가 로컬 네임 서버를 찾을 수 있으려면 로컬 네임 서버의 주소를 알아야 합니다.
공개 DNS 서버
공개 DNS 서버의 대표적인 예로는 구글의 8.8.8.8., 8.8.4.4, Cloudflare의 1.1.1.1.이 있습니다. 정적 IP 주소를 설정할 때 DNS 주소를 설정하려면 8.8.8.8.을 입력하면 됩니다.
루트 네임 서버
클라이언트가 로컬 네임 서버에게 특정 도메인 네임에 대응되는 IP 주소가 무엇인지 질의하는 서버입니다. 루트 네임 서버는 루트 도메인을 관장하는 네임 서버로, 질의에 대해 TLD 네임 서버의 IP 주소를 반환 가능합니다.
TLD 네임 서버
TLD를 관리하는 네임 서버입니다. 질의에 대해 TLD의 하위 도메인 네임을 관리하는 네임 서버 주소를 반환 가능합니다. 하위 도메인을 관리하는 네임 서버는 마찬가지로 그보다 하위 도메인 네임을 관리하는 네임 서버 주소를 반환 가능합니다.
책임 네임 서버
특정 도메인 영역을 관리하는 네임 서버로, 자신이 관리하는 도메인 영역의 질의에 대해서는 다른 네임 서버에게 떠넘기지 않고 곧바로 답할 수 있는 네임 서버입니다. 책임 네임 서버는 로컬 네임 서버가 마지막으로 질의하는 네임 서버입니다.
일반적으로 로컬 네임 서버는 책임 네임 서버로부터 원하는 IP 주소를 얻어냅니다. 루트 도메인을 관리하는 루트 네임 서버부터 TLD를 관리하는 TLD 네임 어섭, 최종 IP 주소를 답해주는 책임 네임 서버까지 네임 서버들은 계층적인 구조를 띠고 있습니다.
🌱 로컬 서버가 네임 서버들에게 질의하는 방법
재귀적 질의
클라이언트가 로컬 네임 서버에게 도메인 네임을 질의하면 로컬 네임 서버가 루트 네임 서버에게
질의하고, 루트 네임 서버가 TLD 네임 서버에게 질의하고, TLD 네임 서버가 다음 단계에 질의하는
과정을 반복하며 최종 응답 결과를 역순으로 전달받는 방식입니다.
과정
클라이언트 → 로컬 네임 서버 → 루트 네임 서버 → TLD 네임 서버 → 책임 네임 서버 → TLD 네임 서버 → 루트 네임 서버 → 로컬 네임 서버 → 클라이언트 → …
반복적 질의
클라이언트가 로컬 네임 서버에게 IP 주소를 알고 싶은 도메인 네임을 질의하면, 로컬 네임 서버는 루트 도메인 서버에게 질의해서 다음으로 질의할 네임 서버의 주소를 응답받고, TLD 네임 서버에게 질의해서 다음으로 질의할 네임 서버의 주소를 응답받는 과정을 반복하다가 최종 응답 결과를 클라이언트에게 알려주는 방식입니다.
과정
클라이언트 → 로컬 네임 서버 → 루트 네임서버 → 로컬 네임 서버 → TLD 네임 서버 → 로컬 네임 서버 → 책임 네임 서버 → 로컬 네임 서버 → 클라이언트
반복적 질의에서는 리졸빙하기 위해 8개의 단계를 거쳐야 해서 시간이 오래 걸리고 네트워크 상의 메세지 수가 지나치게 늘어날 수 있다는 문제가 있습니다.
전 세계 모든 호스트가 도메인 네임 리졸빙을 위해 루트 네임 서버에 도메인 네임을 한꺼번에 질의한다면 루트 네임 서버에 과부하가 생길 수 있습니다. 그래서 실제로는 네임 서버들이 기존에 응답받은 결과를 임시로 저장했다가 추후 같은 질의에 활용하는 경우가 일반적입니다. 임시로 저장하는 것을 DNS 캐시라고 합니다. DNS 캐시를 저장하는 용도로만 사용하는 서버도 있습니다.
DNS 캐시를 활용하면 더 짧은 시간 안에 원하는 IP 주소를 얻을 수 있습니다. DNS 캐시는 영원히 남아있는 것은 아니고 임시 저장된 TTL이라는 값과 함께 저장되는데 이 값은 캐시되어있는 시간을 의미입니다.
🌱 자원을 식별하는 URI
자원
네트워크 상의 메세지를 통해 주고받는 대상입니다. HTML, 이미지, 동영상, 텍스트가 해당됩니다.
두 호스트가 네트워크를 통해 서로 정보를 주고받을 때 송수신하는 대상이 바로 자원입니다.
HTTP 요청 메세지의 대상이라고도 표현합니다. 자원을 식별할 수 있는 정보를 URI라고 명칭. 자원을 식별하는 통일된 방식이라는 의미입니다. 위치를 이용해 자원을 식별하면 URL, 이름을 이용해 자원을 식별하면 URN입니다.
URL
URN보다 URL이 대중적입니다.
Scheme
sheme은 자원에 접근하는 방법을 의미합니다.
일반적으로 사용될 프로토콜이 명시되어있고, HTTP를 사용하여 자원에 접근할 때 http://를 적는 것과 동일합니다.
Authority
호스트를 특정할 수 있는 정보를 의미합니다.
IP 주소 혹은 도메인 네임이 명시되어있고, : 뒤에 포트 번호를 덧붙일 수 있습니다.
Path
자원이 위치한 경로가 명시되어있습니다.
자원의 위치는 /를 기준으로 계층적으로 표현되고 최상위 경로 또한 /로 표현합니다.
URL에서의 경로도 이와 같습니다.
Query
HTTP는 요청-응답 기반의 프로토콜입니다.
클라이언트는 서버에게 URI가 포함된 HTTP 요청 메세지를 보내고, HTTP 서버에는 이에 대해 HTTP 응답 메세지를 보냅니다.
URL에서 현재의 구문으로 담을 수 있는 정보보다 더 많이 필요할 때가 존재합니다.
그 때는 쿼리 스트링, 쿼리 파라미터라고 부르는 값을 사용하여 정보를 포함합니다.
?code= 로 시작하는 키=값 형태의 데이터로 &를 사용하여 여러 쿼리 문자열을 연결할 수 있습니다.
Fragment
자원의 한 조각을 가리키기 위한 정보를 의미합니다.
#section-1.1.2와 같은 형태를 하고 있고 HTML 파일 자원 내의 특정 부분을 나타내는 정보입니다.
URN
자원에 고유한 이름을 붙이는 이름 기반 식별자이기 때문에 자원의 위치와 무관하게 자원을 식별 가능합니다.
