URL(Uniform Resource Location)은 인터넷의 리소스를 가리키는 표준이름입니다, URL은 전자정보 일부를 가리키고 그것이 어디에 있고 어떻게 접근할 수 있는지 알려줍니다.
이번 글에서 다룰 내용
- URL 문법, 여러 URL 컴포넌트가 어떤 의미를 가지며 무엇을 수행하는지
- 여러 웹 클라이언트가 지원하는 상대 URL과 확장 URL 같은 단축 URL에 대해서
- URL의 인코딩과 문자 규칙
- 여러 인터넷 정보 시스템에 적용되는 공통 URL 스킴
- 기존 이름은 유지하면서 객체들을 다른 장소로 옮기는 것을 가능하게 해주는 URN(Uniform Resource Name)을 포함한 URL의 미래
URL은 브라우저가 정보를 찾는데 필요한 리소스의 위치를 가리키며, URL을 이용해 사람과 애플리케이션이 인터넷상의 수십억 개의 리소스를 찾고 사용하며 공유할 수 있습니다. 그리고 URL을 통해 사람이 HTTP 및 다른 프로토콜을 통해 접근할 수 있습니다. 사용자는 브라우저에 URL을 입력하고 브라우저는 화면 뒤에서 사용자가 원하는 리소스를 얻기 위해서 적절한 프로토콜을 사용하여 메세지를 전송합니다.
http://www.joes-hardware.com/seasonal/index-fall.html 이라는 URL을 불러오고 싶다고 해보자
- URL의 첫 부분인
http는 URL의 스킴입니다. 스킴은 웹 클라이언트가 리소스에 어떻게 접근하는지 알려줍니다. 이 경우에, URL이 HTTP 프로토콜을 사용합니다. - URL의 두 번째 부분인
www.joes-hardware.com은 서버의 위치입니다. 이는 웹 클라이언트가 리소스를 어디에 호스팅 되어 있는지 알려줍니다. - URL의 세 번째 부분인
/seasonal/index-fall.html은 리소스의 경로입니다. 경로는 서버에 존재하는 로컬 리소스들 중에서 요청받은 리소스가 무엇인지 알려줍니다.
URL은 HTTP 프로토콜이 아닌 다른 가용한 프로토콜을 사용할 수도 있습니다.
mailto:president@whitehouse.gov 는 이메일 주소를 가리키며,
ftp://ftp.lots-o-books.com/pub/complete-price-list.xls 는 FTP(File Transfer Protocol) 서버에 올라가 있는 파일을 가리키고,
rtsp://www.joes-hardware.com:554/interview/cto_video 는 스트리밍을 제공하기 위해 비디오 서버에 호스팅하고 있는 영화를 가리킵니다.
이렇게 URL은 인터넷에 있는 어떤 리소스든지 가리킬 수 있습니다.
URL을 사용하면 리소스를 일관된 방식으로 지칭할 수 있습니다. 대부분의 URL은 동일하게 스킴://서버위치/경로 구조로 이루어져 있습니다. 따라서 인터넷상의 모든 리소스를 가리키고 가져오기 위해, 그리고 모든 사람이 같은 방식으로 이름을 써서 리소스를 찾을 수 있도록, 단일 방식의 작명 규칙을 가진 것입니다.
URL로 인터넷 상의 모든 리소스를 찾을 수 있지만, 그 리소스들은 다른 스킴(예를 들어 HTTP, FTP, SMTP)을 통해 접근할 수 있으며, URL 문법은 스킴에 따라서 달라집니다. 하지만 대부분의 URL은 일반 URL 문법을 따르며, 서로 다른 URL 스킴도 형태와 문법 면에서 매우 유사합니다.
<스킴>://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>
대부분의 URL 스킴의 문법은 위와 같이 9개 부분으로 나뉩니다. 하지만 이 모든 컴포넌트를 가지는 URL은 거의 없고, 가장 중요한 세가지 컴포넌트는 스킴, 호스트, 경로입니다.
스킴은 주어진 리소스에 어떻게 접근하는지 알려주는 중요한 정보입니다. 이는 URL을 해석하는 애플리케이션이 어떤 프로토콜을 사용하여 리소스를 요청해야 하는지 알려줍니다.
애플리케이션이 인터넷에 있는 리소스를 찾으려면, 리소스를 호스팅하고 있는 장비와 그 장비 내에서 리소스에 접근할 수 있는 서버가 어디에 있는지 알아야 합니다. URL의 호스트와 포트 컴포넌트는 그 두 가지 정보를 제공해줍니다.
호스트 컴포넌트는 접근하려고 하는 리소스를 가지고 있는 인터넷상의 호스트 장비를 가리킵니다.
해당 값은 위에서와 같이(www.joes-hardware.com) 호스트 명이나 IP 주소로 제공합니다.
포트 컴포넌트는 서버가 열어놓은 네트워크 포트를 가리킵니다. 내부적으로 TCP 프로토콜을 사용하는 HTTP는 기본 포트로 80을 사용합니다.
많은 서버가 자신이 가지고 있는 데이터에 접근을 허용하기 전에 사용자 이름과 비밀번호를 요구합니다. 좋은 예로 FTP 서버가 있습니다.
- ftp://ftp.prep.ai.mit.edu/pub/gnu
: 사용자 이름이나 비밀번호 컴포넌트가 없이 표준 스킴, 호스트, 경로만 있습니다. 애플리케이션이 FTP와 같이 사용자 이름과 비밀번호를 요구하는 URL 스킴을 사용한다면, 그 값들이 삽입되어 있지 않을 경우 기본 사용자 이름과 비밀번호 값을 넣어놓을 것입니다. 예를 들어, 사용자 이름과 비밀번호를 기술하지 않고 FTP URL에 접근하면, 기본 사용자 이름 값으로
anonymous, 비밀번호는 브라우저마다 가지고 있는 기본 값을 사용합니다. - ftp://anonymous@ftp.prep.ai.mit.edu/pub/gnu
: 사용자 이름이
anonymous로 되어 있습니다.@문자는 URL로부터 사용자 이름과 비밀번호 컴포넌트를 분리합니다. - ftp://anonymous:my_passwd@ftp.prep.ai.mit.edu/pub/gnu
: 사용자 이름(
anonymous)과 비밀번호(my_passwd)를:문자로 분리하여 모두 기술하였습니다. - http://joe:joespasswd@www.joes-hardware.com/sales_info.txt
URL의 경로 컴포넌트는 리소스가 서버의 어디에 있는지 알려줍니다. 해당 결로는 아래의 예와 같이 계층적 파일 시스템 경로와 유사한 구조를 가집니다.
이 경로는 /seasonal/index-fall.html로 유닉스 파일 시스템의 파일 경로와 유사합니다. 경로는 서버가 리소스의 위치를 찾는데 사용하는 정보입니다. HTTP URL에서 경로 컴포넌트는 / 문자를 기준으로 경로조각으로 나뉩니다. 각 경로조각은 자체만의 파라미터 컴포넌트를 가질 수 있습니다.
많은 스킴이 객체에 대한 호스트 및 경로 정보만으로는 리소스를 찾지 못합니다. 서버가 어떤 포트를 열어놓고 있는지, 리소스에 접근하기 위해 사용자 이름과 비밀번호를 명시했는지 여부 외에도 많은 프로토콜이 더 많은 정보를 요구합니다.
URL을 사용하는 애플리케이션이 리소스에 접근하려면 프로토콜 파라미터가 필요합니다. 프로토콜 파라미터가 없으면, 다른 한편에 있는 서버는 그 요청을 잘못 처리하거나 처리를 하지 않을 것입니다.
URL의 파라미터 컴포넌트는, 애플리케이션이 서버에 정확한 요청을 하기 위해 필요한 입력 파라미터를 받는데 사용합니다. 이 컴포넌트는 이름/값 쌍의 리스트로 URL 나머지 부분들로부터 ; 문자로 구분하여 URL에 기술합니다. 이를 통해 애플리케이션이 리소스에 접근하는데 필요한 어떤 추가 정보든 전달할 수 있습니다.
http://www.joes-hardware.com/hammers;sale=false/index.html;graphics=true
위 URL에는 hammers와 index.html이라는 두 개의 경로조각이 있습니다. Hammers 경로조각은 값이 false인 sale이라는 파라미터를 가집니다. index.html 경로조각은 값이 true인 graphics란 파라미터를 가집니다.
데이터베이스 같은 서비스들은 요청받을 리소스 형식의 범위를 좁히기 위해서 질문이나 질의를 받을 수 있습니다.
죠의 컴퓨터 가게가 판매되지 않은 상품의 재고 리스트가 있고, 어떤 상품들이 비축되어있는지 조회할 수 있다고 해봅시다. 다음 URL은 아이템 번호 12731의 재고가 있는지 확인하기 위해서 웹 데이터베이스 게이트웨이에 질의하는데 사용됩니다.
물음표(?)의 우측에 있는 값들을 질의 컴포넌트라 부릅니다. URL의 질의 컴포넌트는 게이트웨이를 가리키는 URL의 경로 컴포넌트와 함께 전달하고 있습니다. 보통 게이트웨이는, 다른 애플리케이션에 접근하려고 할 때 거치는 통로라고 할 수 있습니다.
HTML 같은 리소스 형식들은 본래의 수준보다 더 작게 나뉠 수 있습니다. 예를 들어 절(paragraph)이 포함된 용량이 큰 한 개의 텍스트 문서의 경우, 그 리소스에 대한 URL은 텍스트 문서 전체를 가리키겠지만, 이상적으로는 리소스 안에 있는 특정 절을 가리킬 수 있어야 합니다.
리소스의 특정 부분을 가리킬 수 있도록, URL은 리소스 내의 조각을 가리킬 수 있는 프래그먼트 컴포넌트를 제공합니다. 예를 들어 URL은 HTML 문서에 있는 특정 이미지나 일부분을 가리킬 수 있습니다.
프래그먼트는 URL의 오른쪽에 # 문자에 이어서 옵니다. 예를 들면 다음과 같습니다.
이 예에서 drills라는 프래그먼트는 죠의 컴퓨터 가게 웹 서버에 위치한 /tools.html 웹페이지의 일부를 가리킵니다. 그 부분을 'drills'라고 기술하였습니다.
일반적으로 HTTP 서버는 객체 일부가 아닌 전체만 다루기 때문에, 클라이언트는 서버에 프래그먼트를 전달하지 않습니다. 브라우저가 서버로부터 전체 리소스를 내려받은 후, 프래그먼트를 사용하여 당신이 보고자 하는 리소스의 일부를 보여줍니다.
웹 클라이언트는 몇몇 단축 URL을 인식하고 사용합니다. 상대 URL은 리소스 안에 있는 리소스를 간결하게 기술하는데 사용할 수 있습니다. 많은 브라우저가 사용자가 기억하고 있는 URL 일부를 입력하면 나머지 부분을 자동으로 입력해주는 URL '자동 확장'을 지원합니다.
URL은 상대 URL과 절대 URL 두 가지로 나뉩니다. 절대 URL는 리소스에 접근하는데 필요한 모든 정보를 가지고 있습니다.
그와 달리 상대 URL은 모든 정보를 담고 있지는 않습니다. 상대 URL로 리소스에 접근하는데 필요한 모든 정보를 얻기 위해서는, 기저(base)라고 하는 다른 URL을 사용해야 합니다.
상대 URL은 URL을 짧게 표기하는 방식입니다. 아래는 상대 URL이 포함된 HTML 문서 중 일부입니다.
<p>Joe's Hardware Online has the largest selection of <a href="./hammers.html"> hammers </a>a> on earth</p>위는 http://www.joes-hardware.com/tools.html가 가리키는 리소스인 HTML 문서의 내용을 보여줍니다. ./hammers.html URL을 가리키는 하이퍼링크가 있습니다. 이는 문서의 URL을 기준으로 상대경로로 해석될 수 있습니다. 이 경우 죠의 컴퓨터 가게 웹 서버의 /tools.html 리소스를 기준으로 상대경로로 명시되었습니다.
상대 URL 문법에 따르면, HTML 작성자는 URL에 스킴과 호스트 그리고 다른 컴포넌트들을 모두 입력하지 않아도 됩니다. 그 정보는 컴포넌트가 포함된 리소스의 기저 URL에서 알아낼 수 있습니다. 다른 리소스에 대한 URL 역시 이 상대 URL로 기술할 수 있습니다.
위의 기저 URL은 다음과 같습니다.
이 URL을 기저 URL로 사용하여, 상대 URL에서는 기술하지 않은 정보를 추측할 수 있습니다. 필요한 리소스가 ./hammers.html 이라는 것을 알지만 스킴이나 호스트는 모릅니다. 기저 URL을 사용하면 스킴은 http이고 호스트는 www.joes-hardware.com라는 것을 추측할 수 있습니다.
상대 URL은 프래그먼트이거나 URL의 일부입니다. URL을 처리하는 브라우저 같은 애플리케이션은 상대 URL과 절대 URL 간에 상호 변환을 할 수 있어야 합니다.
상대 URL을 사용하면 리소스 집합을 쉽게 변경할 수 있습니다. 그리고 문서 집합의 위치를 변경하더라도, 새로운 기저 URL에 의해서 해석될 것이기 때문에 위치를 변경하더라도 잘 동작할 것입니다.
변환 과정의 첫 단계는 기저 URL을 찾는 것입니다. 기저 URL은 상대 URL의 기준이 됩니다. 그것을 가져오는 몇 가지 방법이 있습니다.
어떤 리소스들은 기저 URL을 명확하게 기술하기도 합니다. 예를 들어 HTML 문서에서는 그 안에 있는 모든 상대 URL을 변경하기 위해서 기저 URL을 가리키는 HTML 태그를 기술할 수 있습니다.
만약 상대 URL이 기저 URL이 명시되지 않은 리소스에 포함된 경우, 해당 리소스의 URL을 기저 URL로 쓸 수 있습니다.
기저 URL이 없는 경우도 있습니다. 이런 경우는 절대 URL만으로 이루어져 있다는 뜻입니다. 하지만 불완전하거나 깨진 URL일 수도 있습니다.
