[WEB] 도메인과 URL

 웹에 노출된 수많은 사이트에 대한 서버는 IPv4 혹은 IPv6 체계로 정의된 일련의 숫자로 구성된 주소값에 기반하여 식별된다. 따라서 이론적으로 웹에 노출된 모든 사이트들은 이러한 숫자들에 기반하여 접근할 수 있다. 그러나 각 사이트 및 서버에 접근하기 위해 일련의 숫자를 모두 외워두는 것은 너무나도 비효율적이다. 당장 일주일 전에 무엇을 먹었는지도 제대로 기억하지 못하는 사람들에게 몇백개의 숫자 배열을 외우도록 하는 것은 스트레스만 쌓게 만들지 않겠는가?

 다행히도 사람은 연상하여 기억하는 것은 잘한다. 길거리의 작은 꽃에도 이름을 붙이고, 새로 발견한 벌레에도 이름이 생긴다. 학자들이 생물 및 무생물에 이름을 붙여 각종 정보를 "기록" 하면, 우리는 해당 존재를 칭할 방법을 얻게 된다.

 웹에서의 기조도 그리 다르지 않다. 20세기 네트워크 개발자들은 일련의 숫자를 통해 웹사이트에 접근하도록 사람들을 고문하는 대신에, 인간 친화적인 평문을 이용하여 사이트에 접근할 수 있는 기능을 개발했다. 이때 사람이 이해하기 쉬운 평문을 도메인이라 하며, 도메인 및 일련의 숫자인 IP 주소를 연결하는 기술을 DNS( Domain Name System ) 이라고 한다. 도메인 및 IP 정보는 전세계 많은 도메인 네임 서버에 쌍을 이뤄 기록되어 있으며, 각각을 일종의 키로 이용하여 반대 정보를 얻어낼 수 있다. 우리는 DNS및 도메인 정보를 이용하여 특정 IP로 식별되는 서버에 접근할 수 있다.

 다만 현대 사회에서 흔히 생각하는 주소는 도메인과 1대 1로 대응되지는 않는다. 도메인을 통해 접근할수 있는 IP는 단순히 해당 서버를 식별하는 논리적 주소일 뿐이기 때문이다. 특정 서버에서 수행하는 서비스는 다양하며, 해당 서비스의 특징에 따라 효율적인 데이터 전송 및 관리 방식이 존재한다. 따라서 다양한 서비스들은 각기 다른 데이터 전송을 위한 통신 규약을 필요로 하며, 어떤 통신 규약에 기반하여 서버에 접근하는가에 따라 다른 서비스에 접근하게 된다. 이때 사용되는 다양한 통신 규약을 프로토콜이라 한다. 현재 웹에 접근하기 위해서는 http, https, http/2 등의 프로토콜을 따라야 한다. "https://www.tistory.com" 이라고 한다면 https 는 프로토콜, "www.tistory.com" 은 도메인에 속한다. 이때 도메인의 경우 우측으로 갈수록 상위에 해당한다.

 http 프로토콜 및 도메인 네임 정도의 정보가 있다면 웹사이트의 index 페이지 ( 기본 페이지 ) 에 접근할 수 있다. 이때 이러한 정보들을 이용해 서버에 접근하는 것은 도메인에 해당하는 서버에 제시된 프로토콜을 기반으로 정보를 요청 (request) 하는 것을 의미한다. 예를 들어 "tistory.com" 도메인에 해당하는 서버에서 구독한 피드에 접근하기 위해서는 "https://tistory.com/feed" 라는 주소가 필요하다. 이때 '/' 이후에 오는 내용을 경로(path)라고 하며, 통상적으로 서버에 특정 정보를 요청하기 위해서는 해당 정보를 위한 경로가 필요하다. 서버의 기본 경로는 ' / ' 이지만 보통 표현하지 않으며, 요구하는 정보의 논리적 구조에 따라 다양한 경로 정보가 연달아 나타날 수 있다. 위키피디아에서 apple을 찾는다면, /wiki 이후 찾는 대상인 /apple이 와서 /wiki/apple 이라는 경로를 이루는 것이 논리 구조에 맞을 것이다.

 특정 정보를 단순히 논리 구조로 나타내기 어려운 상황도 존재한다. 경로를 통해 서버에서 20세 이상, 40세 이하에 속하면서 담배를 피우지 않는 모든 회원 정보를 가져오고 싶은 상황을 생각해보자. /list 경로를 통해 회원의 정보에 접근한다고 하더라도 20세 이상 / 40세 이하 / 비흡연자 정보를 논리적인 구조로 나눌 수 있을까? 이런 상황에서는 차라리 서버에게 이런 정보를 질문 할 수 있다면 좋을 것 같다. 쿼리는 논리 구조로 나타내기 어려운 정보를 나열할 때 사용할 수 있으며, 쿼리의 시작을 알리는 ? 이후 key=value 꼴로 나타나는 각종 정보를 & 또는 : 로 연결하여 사용한다. 예를 들어 위 예시는 /list?min_age=20&max_age=40&smoke=false 같이 나타낼 수 있다.

 페이지 상의 특정 위치를 가리키기 위해 사용되는 요소도 있다. 보통 해시(hash)라 칭하는데, 주로 a 태그 등을 이용해 하나의 페이지 내의 위치를 지정하는데 사용다고 한다.

현대 웹에서는 위에서 언급한 프로토콜(protocol), 도메인(domain), 경로(path), 쿼리(query) 및 해시(hash) 등의 정보를 이용하여 주소를 만들고, 만들어진 주소를 통해 특정 서버에 정보를 요청한다. 이렇듯 요소를 논리 및 물리적으로 식별하고, 해당 리소스의 위치를 지정하는 웹주소를 URL(Uniform Resource Location) 이라고 한다. URL은 리소스를 찾고, 식별하기 위한 식별자인 URI(Uniform Resource Identifier)의 일종으로, URI에는 경로 기반으로 자원을 설명하는 URL 이외에 네임 스페이스 기반으로 자원을 식별하는 URN(Uniform Resource Name)도 존재하나 (ex. ISBN ), 보통 웹상에서는 URL만이 독보적으로 많이 사용된다.

URI의 대략적인 구조

 

결론 및 정리

 현재 글의 주제인 도메인과 URL은 둘다 "주소" 라는 배경을 가지고 있다는 점에 있어서 유사해보인다. 그러나 도메인은 서버 등 특정 기기를 식별하기 위한 IP 주소와 대응되는 평문의 개념으로, 최근에는 URL의 요소 중 하나로 사용된다. URL은 특정 서버에 어떤 리소스를 요청하기 위해 프로토콜, 도메인, 경로, 쿼리 및 해시 등의 정보를 이용하여 나타낸 주소로, 서버 내의 특정 리소스에 대한 논리적 "위치" 를 나타낸다. 일반적인 사람들이 인터넷을 사용할때 가리키는 주소는 거의 다 URL에 해당한다. 

---

추가

DNS의 등장 이유는 기존의 호스트 이름 - 주소 대응 시스템에서 발생한 문제점(NIC 서버 1대에서 중앙 처리하기 때문에 트래픽 / 호스트 충돌 등 문제 발생)을 개선하여 호스트들을 개별 기관이 담당하는 영역(domain)으로 분류하기 위해서이다. 이를 통해 호스트 정보를 분산하여 관리하고, 호스트에 대한 정보 검색을 자동화할 수 있다.

https://library.gabia.com/contents/domain/4129

 DNS 이전에도 호스트(컴퓨터)에 대한 이름 - 주소 대응 체계가 존재했다. NIC(Network Information Center)에 각 호스트에 대한 이름 - 주소 쌍, 즉 일종의 호스트 명부를 저장해두고 해당 명부 파일을 네트워크 사용자들이 FTP로 다운받아 사용했다고 한다 (hosts.txt 파일).

 호스트 수가 증가함에 따라 명부 관리 용 중앙 컴퓨터의 hosts.txt 파일을 단순 업데이트하는 방식에 문제가 발생했다.

• 트래픽 & 로드 문제: 중앙 컴퓨터 한대에 트래픽이 집중 + 문제 발생 시 접속 리스트 다운로드 불가.
• 호스트 이름 충돌: 중앙 관리 센터에는 호스트 명에 대한 생성 / 삭제 권한 없다. 누가 기존에 명부 상에 존재하는 동일한 호스트 명을 이용하면 하면 통제할 수 없다.
• 업데이트 지연 & 정보 불일치: 새로운 호스트 및 정보가 계속 갱신되어, 리스트를 최신으로 유지하기 어렵다.

전체 호스트 이름을 한 NIC에서 관리 / 유지 / 갱신해서는 인터넷 증가를 막을 수 없다. -> DNS 등장

DNS(Domain Name System)

 도메인 이름을 IP 주소로 변환해주는 시스템. 기존 중앙 서버 기반 호스트 명부 시스템의 문제점( 한대의 NIC에서 전부 관리 )을 극복하고, 확장에 대응하기 위해 도입되었다.

• 호스트 정보 분산 관리
  • 기관 별로 도메인(책임 영역)에 대한 호스트 정보를 유지 관리
• 호스트 정보 검색 자동화(도메인 네임 서버를 기반으로 

DNS는 다음과 같은 3가지 요소로 구성된다.

• Domain Name Space: 도메인 이름 공간
• Domain Name Server: 도메인 이름 서버
• Resolver: 이름 - 주소를 대응시키는 프로그램. 기본적으로 호스트에 프로그램으로 동작 중

Domain

• 호스트에 대한 정보를 유지하고 관리하는 업무의 구획, 책임 범위
• 물리적 실체인 호스트를 관리하는 책임 / 권한
• 호스트 정보 관리 기관의 관리 영역. 일반적으로 관리 기관 이름 = 관리 영역(네이버가 관리 -> naver)

예시

• naver.com: naver 기관이 관리하는 호스트 시스템 영역(domain)

도메인 개념 도입 이후 도메인(영역) 내 호스트 정보는 관리 기관 수준에서 파일 / DB 형태로 유지한다. 이때, 누군가 특정 호스트를 요구하게 되면 해당 호스트에 대한 길을 알려줄 시스템이 필요한데, 이것이 Domain Name Server이다.

 각 관리 기관은 자신이 책임지는 영역의 호스트 정보 데이터를 zone 파일에 관리한다. Domain Name Server은 zone 파일을 관리하고 있다가, 다른 호스트로부터 자신의 영역에 대한 호스트 정보를 요청받았을 때 정보를 찾아 제공한다.

 하위 도메인(naver)은 자신의 호스트 정보를 관리하며, 상위 도메인(com)에게 네임서버 정보(NS Record)를 제공한다.

우리가 ISP 네임 서버에 특정 URL을 입력하면, 최상위 네임서버(IANA)부터 하위로 차례대로(COM -> naver)도메인 네임을 질의한다. 하위 도메인 네임 서버에 도착하면 해당 기관이 관리하는 호스트에 대한 IP 주소(A Record)를 제공받아 호스트에 접속할 수 있게 된다. 이때 ISP 서버는 내부적으로 캐시를 운영하여 모든 요청에 대해 iteration을 진행하는 대신 자주 방문하는 주소를 저장해 두었다가 바로 제공한다.

DNS 동작 방식