알려드릴 내용은 다음과 같다.
사람은 각자 집주소를 가진다. 그리고 집에는 책, 가방, 옷과 같은 여러 리소스들이 있다.
(리소스란? 텍스트, 이미지, 동영상 같이 웹에서 사용되는 식별할 수 있는 모든 자원을 가리킨다.)
집 안에서도 책이 있는 위치, 가방이 있는 위치, 옷이 있는 위치가 다 다르다.
그래서 찾고자하는 리소스에 따라 주소가 바뀔 수 있다.
이렇게 간단하게 생각하고 접근해보자!
URI, URL, URN이 있다. 하나씩 이야기해보기 전에,
URI는 URL과 URN을 모두 포함한다고 생각하면 된다.
URL을 먼저 살펴보자.
URL안에는 스킴, 호스트, 포트, 경로, 질의, 등으로 구성되어 있다.
모두 다 들어있지 않은 경우도 많기에, 크게 '스킴, 호스트, 경로' 가 포함된다고 생각하면 좋을 듯하다.
URL주소 안에는 '어떻게', '어디로', '무엇을' 통해 전달되는지 모두 알 수 있다.
먼저 '어떻게' 라는 부분인 '스킴'에 대해 살펴보자.
http와 https의 차이는 보안의 차이이다.
http로 접속한다면, 공용 와이파이를 연결한 당신의 컴퓨터에 개인 통장정보 카드 정보를 알 수도 있다.
그렇기 떄문에 보안설정이 되어있는 https로 접속하거나 도메인을 생성하는 것이 좋다.
mailto의 경우는 바로 메일로 연결되는 URL이다.
주소창에 위와 같이 쓴다면, 맥의 경우 맥 기본 메일 어플리케이션이 열리게 된다.
(IE의 경우, 다른 웹 어플리케이션을 이용한다고 한다.)
ftp, file 이 두 가지 스킴의 차이점은 file은 말 그대로 파일을 여는 것이고, ftp는 주소를 따라가면 그 서버에 접속해 디렉토리들을 확인할 수 있다.
예시로 제공된 링크를 따라 들어가보자.
맥의 경우에는 finder(window탐색기)를 열겠냐고 물어본다.
열어보게 되면,
위와 같이, ftp서버로 연결되는 것을 볼 수 있다.
그리고 나면 위와 같이 ftp서버의 디렉토리에 접근할 수 있게 된다.
그렇다면 스킴의 문법에 대해 알아보자.
URL주소는 위의 카테고리들을 포함한다.
사용자 이름과 비밀번호의 경우, 오픈 소스가 아니라 보안이 필요하거나 private한 접근을 원한다면 사용자 이름과 비밀번호를 입력하면 된다.
사용자이름의 기본값은 'anonymous'이며, 비밀번호는 브라우저마다 다르다.
호스트와 포트를 통해서 서버의 위치와 호스팅하고 있는 장비의 정보를 얻을 수 있다. URL주소는 호스트명으로도 가능하고 IP주소로도 가능하다.
경로를 통해 리소스의 위치를 정확히 알 수 있다.
리소스는 다양하고 셀 수 없을 만큼 많기 때문에 더 정확하고 깊이있는 정보를 제공해주어야 한다. 이 때 파라미터가 이용된다. 이름/값의 쌍으로 구성되어 있다.
프래그먼트는 html을 공부했다면 알다시피, 간단하게 페이지 내의 id값을 정확히 표시한다고 생각하면 된다. 페이지 내의 특정 부분을 찾아갈 수 있는 방법이다. 하지만 이 프래그먼트는 서버와 따로 소통하지 않고 보내지지 않는다. 서버로부터 페이지를 받으면 브라우저 내에서 프래그먼트를 확인해 유저에게 특정 부분을 보여준다.
스킴을 통해 URL의 구성 컴포넌트들을 살펴보았다.
URN은 객체가 옮겨지더라도(웹 서버 내, 웹 서버 간 모두) 항상 객체를 가리킬 수 있는 이름을 제공하는 것이다.
말이 어렵다면 이렇게 생각해보자.
민영이의 주민등록번호은 집에 있지 않아도 나를 실제로 증명하고 리소스에 변함이 없다. 그렇다면 주민등록번호가 URN 주소가 되는 것이다.
(예시 : 김민영 봉천동 거주 930323-1xxxxxx => URN)
그렇다면 URL보다 좋은 게 아닌가 라고 생각할 수 있다.
맞다. 그래서 URL을 대신하기 위해 나온 것이다. URL은 리소스의 위치가 바뀌어 버리면 그 주소는 무용지물이 된다. 가방을 매고 나온다면 내 가방의 위치는 더 이상 집안의 옷장이라는 주소에 없게 된다. 그렇기 떄문에 실제로 리소스를 증명하고 연결할 수 있는 URN이 나온 것이다.
URN이 한동안 채택되었지만, URL에서 URN으로 주소체계를 바꾸는 것은 매우 큰 작업이었다, 표준화는 매우 중요하고 큰 작업이기에 느리게 진행되었고 표준제정 및 벤더들과의 합의 엄청난 작업량 등으로 아직까지 상용화가 이루어지지 않고 있다. 그래서 현재도 URL을 사용하고 있다. 미래에는 URN이 상용화되지 않을까?
(만약 URN을 사용하고 싶다면, PURL:Persistent Uniform Resource Locators 에 대해 확인해보아라. URL로 URN기능을 제공한다.)