시작하며
인터넷을 볼만한 장소와 할 것이 많은 거대한 도시라고 생각해보자.
박물관, 레스토랑, 사람들의 집을 설명하기 위해 길거리 주소를 사용하고 소방서, 사장의 비서, 가족에게 연락하기 위해 전화번호를 사용한다.
책은 ISBN 번호를, 버스는 노선 번호를, 은행 계좌는 계좌번호를, 사람은 주민등록번호를 가진다.
모두가 이렇게 각기 다른 이름들에 대한 작명 표준에 동의하기 때문에, 도시에 있는 소중한 리소스를 모두 쉽게 공유할 수 있다.
리소스는 텍스트, 이미지, 동영상 같이 웹에서 사용되는 식별할 수 있는 모든 자원을 가리킨다.
URL(Uniform Resource Locator)은 인터넷의 리소스를 가리키는 표준이름이다. URL은 전자정보 일부를 가리키고 그것이 어디에 있고 어떻게 접근할 수 있는지 알려준다.
이 장에서 다룰 것들
•
URL 문법, 여러 URL 컴포넌트가 어떤 의미를 가지며 무엇을 수행하는지.
•
여러 웹 클라이언트가 지원하는 상대 URL과 확장 URL 같은 단축 URL에 대해서.
•
URL의 인코딩과 문자 규칙.
•
여러 인터넷 정보 시스템에 적용되는 공통 URL 스킴.
•
기존 이름은 유지하면서 객체들을 다른 장소로 옮기는 것을 가능하게 해주는 URN(Uniform Resoutce Name) 을 포함한 URL의 미래.
2.1 인터넷의 리소스 탐색하기
URL은 브라우저가 정보를 찾는데 필요한 리소스의 위칠르 가리키며, URL을 이용해 사람과 애플리케이션이 인터넷상의 수십억 개의 리소스를 찾고 사용하며 공유할 수 있다.
URL은 통합 자원 식별자(Uniform Resource Identifier) 혹은 URI라고 불리는 더 일반화된 부류의 부분집합이다. URI는 두 가지 주요 부분집합인, URL과 URN으로 구성된 종합적인 개념이다.
HTTP 명서에서는 URI를 더 일반화된 개념의 리소스 식별자로 사용한다. 하지만 실제로 HTTP 애플리케이션은 URL을 URI의 한 부분으로 취급한다.
예시) http://www.joes-hardware.com/seasonal/index-fall.html 이라는 URL을 불러오고 싶다고 해보자.
URL은 HTTP 프로토콜이 아닌 다른 가용한 프로토콜을 사용할 수도 있다.
•
mailto:president@whitehouse.gov 는 이메일 주소를 가리킨다.
•
ftp://ftp.lots-o-books.com/pub/complete-price-list.xls는 FTP(File Trasfer Protocol) 서버에 올라가 있는 파일을 가리킨다.
•
rtsp://www.joes-hardware.com:554/interview/.cto_video는 스트리밍을 제공하기 위해 비디오 서버에 호스팅하고 있는 영화를 가리킨다.
대부분의 URL은 동일하게 '스킴://서버위치/경로' 구조로 이루어져 있다.
2.1.1 URL이 있기 전 암흑의 시대
웹고 URL이 있기 전에 사람들은 네트워크상에 산재해 있는 데이터에 접근하기 위해서 애플리케이션마다 달리 가지고 있는 분류 방식을 사용했다.
URL이 없던 시절의 복잡성 예
URL은 사용자와 브라우저에게 정보를 찾는데 필요한 모든 것을 제공하며, 당신이 원하는 리소스가 어디에 위치하고 어떻게 가져오는지 정의한다.
2.2 URL 문법
URL로 인터넷상의 모든 리소스를 찾을 수 있지만, 그 리소스들은 다른 스킴(예, HTTP, FTP, SMTP)을 통해서 접근할 수 있으며, URL 문법은 스킴에 따라서 달라진다.
대부분의 URL은 일반 URL 문법을 따르며, 서로 다른 URL 스킴도 형태와 문법 면에서 매우 유사하다.
대부분의 URL 스킴 문법은 일반적으로 9개 부분으로 나눈다.
<스킴>://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>
이 모든 컴포넌트를 가지는 URL은 거의 없다. URL의 가장 중요한 세 가지 컴포넌트는 스킴, 호스트, 경로다.
컴포넌트 중에서 스킴, 호스트와 포트, 경로에 대한 설명을 이어간다. 나머지는 책이나 위의 표를 참조
2.2.1 스킴: 사용할 프로토콜
스킴은 주어진 리소스에 어떻게 접근하는지 알려주는 중요한 정보다. URL을 해석하는 애클리케이션이 어떤 프로토콜을 사용하여 리소스를 요청해야 하는지 알려준다.
스킴 컴포넌트는 알파벳으로 시작해야 하고 URL의 나머지 부분들과 첫 번째 ':'(콜론) 문자로 구분한다.
스킴 명은 대소문자를 가리지 않으므로 'http://www.naver.com'와 'HTTP://www.naver.com'은 같다.
2.2.2 호스트와 포트
애플리케이션이 인터넷에 있는 리소스를 찾으려면, 리소스를 호스팅하고 있는 장비와 그 장비 내에서 리소스에 접근할 수 있는 서버가 어디에 있는지 알아야 한다.
URL의 호스트와 포트 컴포넌트는 그 두 가지 정보를 제공한다. 호스트 컴포넌트는 접근하려고 하는 리소스를 가지고 있는 인터넷상의 호스트 장비를 가리킨다.
해당 값은 호스트명이나 IP주소로 제공한다. 예를 들어 아래 두 개의 URL은 같은 리소스를 가리킨다.
•
http://www.joes-hardware.com:80/index.html
•
http://161.58.228.45:80/index.html
포트 컴포넌트는 서버가 열어놓은 네트워크 포트를 가리킨다. 내부적으로 TCP 프로토콜을 사용하는 HTTP 기본 포트로 80을 사용한다.
HTTPS는 기본 포트로 443을 사용한다.
2.2.4 경로
URL의 경로 컴포넌트는 리소스가 서버의 어디에 있는지 알려준다. 해당 경로는 아래 예와 같이 계층적 파일 시스템 경로와 유사한 구조를 가진다.
•
http://www.joes-hardware.com:80/seasonal/index-fall.html
이 URL의 경로는 '/seasonal/index-fall.html'로 유닉스 파일 시스템의 파일 경로와 유사하다.
HTTP URL에서 경로 컴포넌트는 '/' 문자를 기준으로 경로조각으로 나뉜다.
2.3 단축 URL
웹 클라이언트는 몇몇 단축 URL을 인식하고 사용한다. 상대 URL은 리소스 안에 있는 리소스를 간결하게 기술하는데 사용할 수 있다.
많은 브라우저가 사용자가 기억하고 있는 URL 일부를 입력하면 나머지 부분을 자동으로 입력해주는 URL '자동 확장'을 지원한다.
2.3.1 상대 URL
URL은 상대 URL과 절대 URL 두 가지로 나뉜다. 지금까지 우리가 본 것들은 절대 URL뿐이었다.
절대 URL은 리소스에 접근하는데 필요한 모든 정보를 가지고 있다. 그와 달리 상대 URL은 모든 정보를 담고 있지는 않다.
상대 URL로 리소스에 접근하는데 피요한 정보를 얻기 위해서는 기저(Base)라고 하는 다른 URL을 사용해야 한다.
상대 URL은 URL을 짧게 표기하는 방식이다. 직접 HTML을 작성해 본 경험이 있다면 알 것이다.
위 예는 http://www.joes-hardware.com/tools.html 가 가리키는 리소스인 HTML 문서의 내용이다. 해당 문서에서는 하이퍼링크로 './hammers.html'을 사용한다.
이 URL은 미완성인 것처럼 보이지만, 올바른 문법의 상대 URL이다.
상대 URL 문법에 따르면, HTML 작성자는 URL에 스킴과 호스트 그리고 다른 컴포넌트들을 모두 입력하지 않아도 된다. 정보는 컴포넌트가 포함된 기저 URL에서 알아낼 수 있다.
•
예 2-1의 기저 URL : http://www.joes-hardware.com/tools.html
이 URL을 기저로 사용하여, 상대 URL에서는 기술하지 않은 정보를 추측할 수 있다.
상대 URL은 프로그먼트이거나 URL 일부다. URL을 처리하는 브라우저 같은 애플리케이션은 상대 URL과 절대 URL 간에 상호 변환을 할 수 있어야 한다.
•
기저 URL
◦
변환 과정의 첫 단계는 기저 URL을 찾는 것이다. 기저 URL은 상대 URL의 기준이 된다.
•
리소스에서 명시적으로 제공
◦
어떤 리소스들은 기저 URL을 명확하게 기술하기도 한다. 예를 들어 HTML 문서에서는 그 안에 있는 모든 상대 URL을 변경하기 위해서 기저 URL을 가리키는 <BASE> 태그를 기술 할 수 있다.
•
리소스를 포함하고 있는 기저 URL
◦
상대 URL이 예 2-1에서와 같이 기저 URL이 명시되지 않은 리소스에 포함된 경우, 해당 리소스의 URL을 기저 URL로 쓸 수 있다.
•
기저 URL이 없는 경우
◦
기저 URL이 없는 경우도 있다. 보통 이런 경우는 절대 URL만으로 이루어져 있다는 뜻이다.
앞에서 URL의 기본 컴포넌트와 문법에 대해서 알아보았다. 상대 URL을 절대 URL로 변환하기 위한 다음 단계는 상대 URL과 기저 URL을 각각의 컴포넌트 조각으로 나누는 것이다.
이 작업을 URL 분해하기라고 부르기도 한다. 기저 URL과 상대 URL을 컴포넌트로 분리하고 나면, 변환을 끝내기 위해 그림 2-5에서 설명하고 있는 알고리즘을 사용할 수 있다.
1.
경로는 ./hammers.html 기저 URL은 http://www.joes-hardware.com/tools.html
2.
스킴은 비어 있다. 도표의 왼쪽으로 따라 내려가면, 알고리즘에 따라 기저 URL의 스킴을 상속받는다.(HTTP)
3.
적어도 한 개의 컴포넌트는 비어 있지 않다. 아래로 내려가서 호스트와 포트 컴포넌트를 상속받는다.
4.
상대 URL 컴포넌트와 상속받은 컴포넌트를 합치면 새로운 절대 URL인 http://www.joes-hardware.com/hammers.html을 얻을 수 있다.
2.3.2 URL 확장
어떤 브라우저들은 URL을 입력한 다음이나 입력하고 있는 동안에 자동으로 URL을 확장한다. 이는 사용자가 URL을 빠르게 입력하게 도와준다. 자동으로 URL이 확장되기 때문에 전체를 입력하지 않아도 된다.
이러한 확장 기능은 두가지로 나뉜다.
호스트 명 확장
히스토리 확장
2.4 안전하지 않은 문자
URL은 잘 호환되도록 설계되었다. 그리고 인터넷에 있는 모든 리소스가 여러 프로토콜을 통해서 전달될 수 있도록, 각 리소스에 유일한 이름을 지을 수 있게 설계되었다.
모든 프로토콜이 데이터를 전송하기 위해서 서로 다른 장칠르 가지고 있기 때문에 어떤 인터넷 프로토콜을 통해서든 안전하게 전송될 수 있도록 URL을 설계하는 것은 중요했다.
안전한 전송이란, 정보가 유실될 위험 없이 URL을 전송할 수 있다는 것을 의미한다. 전자메일에 사용되는 SMTP(Simple Mail Transfer Protocol) 같은 프로토콜은 특정 문자를 제거할 수도 있는 전송 방식을 사용한다.
이는 메시지에 대해 7비트 인코딩을 사용하기 때문이다. 만약 소스가 8비트 이상으로 인코딩되어 있으면 정보가 소실될 수 있다.
URL 설계자들은, 모든 인터넷 프로토콜로 URL이 전송될 수 있기를 바랐고 이와 함께 가독성도 있기를 바랬다. URL에 이진 데이터나 일반적으로 안전한 알파벳 외의 문자도 포함하려고 할 때가 있다는 것을 알게 되어 이스케이프라는 기능을 추가하여, 안전하지 않은 문자를 안전한 문자로 인코딩할 수 있게 하였다.
2.4.1 URL 문자 집합
컴퓨터 시스템의 기본 문자 집합은 보통 영어 중심으로 설정되어 있다. 역사적으로 많은 컴퓨터 애플리케이션이 US-ASCII 문자 집합을 사용해왔다. US-ASCII는 문자를 서식화하고 하드웨어상에서 신호를 주고받기 위해, 7비트를 사용하여 영문 자판에 있는 키 대부분과 몇몇 출력되지 않는 제어 문자를 표현한다.
URL이 특정 이진 데이터를 포함해야 하는 경우도 있다. 이런 것들을 지원하기 위해서 URL 설계자들은 URL에 이스케이프 문자열을 쓸 수 있게 설계하였다.
이스케이프 문자열은 US-ASCII에서 사용이 금지된 문자들로, 특정 문자나 데이터를 인코딩할 수 있게 함으로써 이동성과 완성도를 높였다.
2.4.2 인코딩 체계
안전한 문자 집합을 이용하는 경우 그 표현의 한계를 넘기 위해, URL에 있는 안전하지 않은 문자들을 표현할 수 있는 인코딩 방식이 고안되었다.
인코딩은 안전하지 않은 문자를 퍼센티지 기호(%)로 시작해 ASCII 코드로 표현되는 두 개의 16진수 숫자로 이루어진 '이스케이프' 문자로 바꾼다.
2.4.3 문자 제한
몇몇 문자는 URL 내에서 특별한 의미로 예약되어 있다. 어떤 문자는 US-ASCII의 출력 가능한 문자 집합에 포함되어 있지 않다.
아래의 표2-3은 URL에서 예약된 문자들을 본래의 목적이 아닌 다른 용도로 사용하려면, 그 전에 반드시 인코딩해야 하는 문자들을 나열해 놓았다.
2.4.4 좀 더 알아보기
애플리케이션은 정해진 방식대로 구현해야 한다. 어떤 애플리케이션에 어떤 URL을 보내든지, 그 전에 클라이언트 애플리케이션에서 안전하지 않거나 제한된 문자를 변환하는 것이 좋다.
여기서는 Proxy 같은 HTTP 중개 애플리케이션이 아닌 클라이언트 애플리케이션에 대해서만 이야기한다. 6장의 '전송 중 URI 변경'에서는 클라이언트 애플리케이션 대신 Proxy나 다른 중개 애플리케이션이 URL을 수정할 경우 발생할 수 있는 문제에 대해 논의한다.
입력받은 URL에서 어떤 문자를 인코딩해야 하는지 결정하는 데는 브라우저 같이 사용자로부터 최초로 URL을 입력받는 애플리케이션에서 하는 것이 가장 적절하다.
물론 극단적인 방법은 애플리케이션이 모든 문자를 인코딩하는 것이다. 이 방식을 추천하지는 않지만, 이미 안전한 것으로 판단되는 문자를 재차 인코딩하는 것보다 더 완벽하고 빠른 규칙은 없다.
하지만 실제로 이 방식은 안전한 문자들을 인코딩하지 않는 애플리케이션도 있기 때문에 오작동을 일으킬 수 있다.
스킴 같은 몇몇의 URL 컴포넌트는 쉽게 알아볼 수 있어야 하며 알파벳 문자로 시작 되어야 한다.
2.5 스킴의 바다
웹에서 쓰이는 일반 스킴들의 포맷에 대해 알아본다. 부록 A에는 스킴 목록이 상당히 자세히 나열되어 있으며 스킴 각각에 대한 문서 정보가 기술되어 있다.
아래 표2-4에는 가장 유명한 스킴들을 요약해 놓았다.
2.6 미래
URL은 강력한 도구다. URL은 세상에 존재하는 모든 객체에 이름을 지을 수 있고, 새로운 포맷을 쉽게 추가할 수 있게 설계됐다. URL은 인터넷 프로토콜 간에 공유할 수 있는 일관된 작명 규칙을 제공한다.
하지만 URL이 완벽한 것은 아니다. URL은 주소이지 실제 이름이 아니라 특정 시점에 어떤 것이 위치한 곳을 알려주는 것이다. URL은 리소스를 찾는데 필요한 포트와 서버 이름을 제공하는데 이런 스킴의 단점은 리소스가 옮겨지면 URL을 더는 사용할 수 없다는 것이다. 그리고 그 시점에 기존 URL이 가리키고 있던 객체를 찾을 방법이 없어진다.
이런 문제를 해결하기 위한 이상적인 방법은 객체의 위치와 상관없이, 그 객체를 가리키는 실제 객체 이름을 사용하는 것이다.
인터넷 기술 태스크 포스(Internet Engineering Task Force, IETF)는 한동한 고심한 끝에 URN(Unoform Resource Names) 이라는 새로운 표준 작업에 착수했다.
URN은 객체가 옮겨지더라도 항상 객체를 가리킬 수 있는 이름을 제공한다.
PURL(Persistent Uniform Resource Locators)을 사용하면 URL로 URN의 기능을 제공할 수 있다. PURL은 리소스의 실제 URL 목록을 관리하고 추적하는 리소스 위치 중개 서버를 두고, 해당 리소스를 우회적으로 제공한다.
클라이언트는 위치 할당자에게 리소스를 가져올 수 있는 영구적인 URL을 요청할 수 있으며, 영구적인 URL은 클라이언트를 리소스의 실제 URL로 연결해준다.
2.6.1 지금이 아닌면, 언제?
한동안 URN 방식이 활용되었었다. URL에서 URN으로 주소 체계를 바꾸는 것은 매우 큰 작업이다. 표준화는 매우 중요한 작업인 만큼 느리게 진행될 때도 있다.
URN을 지원하려면 많은 변화가 필요할 것이다. 표준을 제정하는 것에서부터 여러 HTTP 애플리케이션을 수정하기 위한 벤더들과의 합의도 필요하다. URN으로 전환되기 위한 모든것이 준비되려면 시간이 걸리기 때문에, URL은 당분간 계속 사용될 것이다.
2.7 추가 정보
URL에 대한 더 자세한 정보는 다음을 참고하기 바란다.
•
http://www.w3.org/Addressing/ : URI와 URL의 작명 및 할당에 대한 W3C 웹페이지
•
http://www.ietf.org/rfc/rfc1738 : RFC 1738, "Uniform, Resource Locators(URL)" by T.Berners-Lee, L.Masinter and M.McCahill
•
http://www.ietf.org/rfc/rfc2396.txt : RFC 2396, “Uniform Resource Identifiers (URI): Generic Syntax,” by T. Berners- Lee, R. Fielding, and L. Masinter.
•
•
•
http://www.ietf.org/rfc/rfc1808.txt : RFC 1808, “Relative Uniform Resource Locators,” by R. Fielding.
