URL과 리소스
URL은 인터넷 리소스를 가리키는 표준이름이다.
전자정보 일부를 가리키고 그것이 어디에 있고 어떻게 접근할 수 있는지 알려준다.
2.1 인터넷의 리소스 탐색하기
URI은 통합 자원 식별자(Uniform Resource Identity)로 불린다.
URI는 URL과 URN으로 구성된 종합적인 개념이다.
URL : 리소스가 어디있는지 설명해서 리소스를 식별
URN : 리소스 위치에 상관없이 이름만으로 리소스를 식별
아래 예시를 통해 URL이 어떻게 동작하는지 살펴보자.
- URL의 첫 부분인 "http"는 URL의 스킴으로 리소스에 어떻게 접근하는지 알려준다.
- 두번째 부분인 "www.joes-hardware.com"은 서버의 위치이다. 이를 통해 리소스가 어디에 호스팅 되어있는지 알 수 있다.
- 세번째 부분인 /seasonal/index-fall.html은 리소스의 경로이다. 서버에 존재하는 로컬 리소스 요청받은 리소스가 무엇인지 알려준다.
URL 구조
<스킴>://<서버위치>/<리소스 경로>
URL이 있기 전 암흑의 시대
오늘날 사용자는 URL을 통해 다양한 어플리케이션들에서 하나의 공통된 인터페이스를 통해 일관된 방식으로 리소스에 접근할 수 있다.
하지만 이런 URL이 존재하기 전에는 각각의 어플리케이션마다 가지고 있는 분류 방식을 따라야해서 매우 복잡했다.
예시
- complete-catalog.xls 파일을 공유
- FTP로 접속
- 사용자 로그인 후 pub 디렉토리 이동 후 바이너리 형식으로 전환
- complete-catalog.xls 로컬 파일 시스템에 다운
2.2 URL 문법
URL은 스킴을 통해 다양한 형태의 리소스에 접근을 할 수 있다.
그렇다면 다른 스킴을 사용하면 다른 URL 문법을 적용해야 될까?
그렇지 않다. 대부분의 URL 스킴 문법은 일반적으로 9개 부분으로 나뉜다.
대부분 URL은 아래와 같은 구조로 이루어졌다.
<스킴>://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>
스킴: 사용할 프로토콜 : HOW TO
스킴은 리소스에 어떻게 접근하는지 알려주는 중요한 정보다.
- ':' 문자로 구분한다.
- 대소문자를 가리지 않는다. (HTTP == http)
호스트와 포트 : WHERE
리소스를 찾으려면, 리소스를 호스팅하고 있는 장비와 그 장비 내에서 해당 리소스에 접근할 수 있는 서버가 어디에 있는지 알아야 한다.
URL의 호스트와 포트 컴포넌트 해당 정보들을 제공해준다.
호스트 : 인터넷 상 호스트 장비
포트 : 서버가 열어놓은 네트워크 포트
사용자 이름과 비밀번호 : WHO
많은 서버가 리소스에 접근을 허용하기 전에 사용자 이름과 비밀번호를 요구한다.
해당 컴포넌트는 누가 해당 리소스에 접근하는지 표현하기 위해 사용된다.
ex) http://joe:joespasswd@www.joes-hardware.com/sales_info.txt
경로 : WHAT
URL의 호스트와 포트 컴포넌트를 통해 호스팅 서버를 정확히 식별할 수 있다.
경로는 해당 서버 내부에서 어떤 리소스에 접근하려는지 알려준다.
ex) http://www.joes-hardware.com:80/seasonal/index-fall.html
위의 예시에서 사용자는 '/seasonal/index-fall.html' 경로를 통해 seasonal 폴더 안에 있는 index-fall.html 리소스를 요구한 것을 확인할 수 있다.
파라미터
많은 스킴이 객체에 대한 호스트 및 경로 정보만으로 리소스를 찾지 못한다.
많은 프로토콜에서 이 외에도 더 많은 정보를 요구하는 경우가 많다.
URL 파라미터 컴포넌트는 애플리케이션이 서버에 정확한 요청을 하기 위해 필요한 입력 파라미터를 받을 때 사용한다.
이 컴포넌트는 이름, 값 쌍의 리스트로 구성되며 ';' 문자로 구분한다.
ex)ftp://prep.ai.mit.edu/pub/gnu;type=d
위의 예시를 보면, 이름은 'type'이고, 값은 'd'인 단 한 개의 파라미터를 전달한다.
질의 문자열
데이터베이스 같은 서비스들은 요청받을 리소스 형식 범위를 좁히기 위해 질문이나 질의를 받을 수 있다.
아래 URL은 아이템 번호 12731의 재고가 있는지 확인하기 위한 URL이다.
ex) http://www.joes-hardware.com/inventory-check.cgi?item=12731
질의 컴포넌트는 '?' 문자를 사용한다.
'?' 우측에 있는 값들을 통해 특정 질의를 데이터베이스 서버에 보낸다.
질의 텀포넌트 포맷에 제약사항은 따로 존재하지 않는다.
하지만 많은 게이트웨이가 '&'로 나뉜 '이름=값' 쌍 형식의 질의 문자열을 사용한다.
ex) http://www.joes-hardware.com/inventory-check.cgi?item=12731&color=blue
프래그먼트
HTML같은 리소스 형식들은 본래 더 작은 컴포넌트로 이루어져있다.
이때 프래그먼트 컴포넌트를 통해 리소스의 특정 부분을 가리킬 수 있다.
프래그먼트는 '#'문자 오른쪽에 위치한다.
일반적으로 HTTP 서버는 객체 전체를 다루기 때문에 일부만 요청해도 전체 리소스를 내려받은 후, 해당 프래그먼트 부분만 보여준다.
2.3 단축 URL
웹 클라이언트는 몇몇 단축 URL을 인식하고 사용한다.
상대 URL은 리소스 안에 있는 리소스를 간결하게 기술하는데 사용된다.
상대 URL
URL은 상대 URL과 절대 URL 두 가지로 나뉜다.
절대 URL은 리소스를 접근하는데 필요한 모든 정보를 가지고 있는 반면에, 상대 URL은 모든 정보를 담고있지 않다.
상대 URL은 URL을 짧게 표기하는 방식이다.
ex) <a href=“./hammers.html”>hammers</a>위의 a 태그 안에는 './hammers.html' 이라는 URL 정보가 담겨져있다.
이는 미완성 URL로 보이지만, 올바른 문법인 상대 URL이다.
상대 URL은 컴포넌트가 포함된 리소스의 기저 URL에서 정보를 얻어올 수 있어서 스킴과 호스트 및 다른 컴포넌트를 모두 입력하지 않아도 된다.
이와 같은 상대 URL을 처리하기 위해선 브라우저 같은 애플리케이션은 상대 URL를 절대 URL로 변환할 수 있어야 한다.
2.3.2 URL 확장
브라우저들은 URL을 입력하는 동안에 자동으로 URL을 확장하는 기능을 제공한다.
이를 통해 사용자는 URL를 전부 입력하지 않고도 빠르게 입력할 수 있다.
확장 기능은 크게 두 가지로 나뉜다.
호스트명 확장
호스트명 확장 기능은 단순한 휴리스틱만을 사용해서 입력한 호스트명을 전체 호스트명으로 확장해준다.
- yahoo라고 입력하면, 자동으로 www.yahoo.com로 URL을 확장해준다.
하지만 호스트명 확장 기능은 프락시와 다른 HTTP 애플리케이션에 장애를 발생시킬 수 있다.
이에 대해서는 6장에서 다룬다.
히스토리 확장
과거에 사용자가 방문한 URL 기록을 통해 URL를 확장해준다.
- http://www.joes를 입력하면 과거에 방문한 URL 중 앞부분이 일치하는 URL로 확장해준다.
2.4 안전하지 않은 문자
URL은 인터넷에 있는 모든 리소스가 여러 프로토콜을 통해 전달되기 때문에 어떤 프로토콜이든 안전하게 전송될 수 있도록 설계하는 것이 매우 중요했다.
안정한 전송이란, 정보의 유실 위험이 없이 URL이 전송되는 것을 의미한다.
- 예를 들어, 전자메일에 사용되는 SMTP 프로토콜은 특정 문자를 제거할수도 있기때문에 URL이 제거되지 않도록 설계해야 한다.
- 또한 사용자가 특수문자, 보이지 않는 문자, 알파벳 외의 문자 등을 URL에 포함할수도 있으므로 이스케이프 기능을 추가했다.
- 이를 통해 안전하지 않은 문자를 안전한 문자로 인코딩한다.
URL 문자 집합
컴퓨터 시스템의 기본 문자는 영어이다.
하지만 인터넷은 영어 국가만이 사용하는 것이 다양한 나라에서 다양한 언어로 사용한다.
따라서 이스케이프 문자열을 통해 영어가 아닌 특정 문자나 데이터를 인코딩하여 안전한 전송이 가능하게 했다.
인코딩 체계
인코딩은 안전하지 않은 문자를 '%' 문자로 시작해 ASCII 코드로 표현되는 두 개의 16진수 숫자로 이루어진 이스케이프 문자로 바꾼다.
'~'이 포함된 URL 인코딩 예시
문자 제한
URL 내에 몇몇 문자는 특별한 의미로 예약되어 있다.
또한 어떤 문자는 인터넷 게이트웨이와 프로토콜에서 혼동되는 것으로 알려져 있어 꺼려진다.
즉, 이러한 금지된 문자를 사용하려면 반드시 인코딩해야 한다.
ex) %, /, #, ?, @, &, =...
사실 위의 ~,/,# 같은 금지된 문자를 사용해도 문제가 없던 적이 있을 것이다.
하지만 이는 어떤 프로토콜에서는 되고 특정 프로토콜에서는 작동이 안되는 위험성이 있어서 인코딩을 해줘야 한다.
URL의 미래
URL은 인터넷 세상에서 리소스에 접근할 수 있는 강력한 도구이다.
하지만 리소스는 주소이지 이름이 아니므로 리소스가 옮겨지면 해당 URL은 더이상 사용할 수 없다는 단점이 존재한다.
URN은 리소스의 이름을 명시함으로써 이러한 단점을 해결할 수 있다.
하지만 현재 많은 표준 웹사이트들이 URL을 이미 사용하고 있고, 사용자들도 이에 익숙해졌다.
무엇보다도 URN을 사용하려면 많은 부분에서 변화가 필요하므로 URL은 한동안 사용될 것이다.
기타
- 인터넷 기술 테스크 포스(IEFT)에서 URN이라는 새로운 표준을 만듦.
- 지속 통합 자원 지시자(PURL)을 사용하면 URL을 URN처럼 사용가능.
