책 “HTTP 완벽 가이드”를 읽고 정리한 글입니다.
모든 것에는 표준화 된 이름이 있다. 책의 ISBN 번호, 버스의 노선 번호, 은행 계좌의 계좌 번호 처럼 말이다. 이러한 표준 덕에 한 사람이 특정 대상을 지칭할 때, 다른 사람들도 그 사람이 무엇을 가리키는 것인지를 알 수 있다.
마찬가지로 URL(Uniform Resource Locators)은 인터넷 자원의 표준화 된 이름이다.
인터넷 리소스 탐색
브라우저가 정보를 찾는데에는 리소스의 위치인 URL이 필요하다. 사용자가 브라우저에게 URL을 주면 브라우저는 리소스를 얻기 위해 해당 경로로 적절한 프로토콜 메시지를 보낸다.
URL은 URI(Uniform Resource Identifier)의 일종이다. 다른 하나는 URN. HTTP 명세에는 URI를 사용하지만 실제 HTTP 애플리케이션들은 그중 URL만을 사용한다.
http://www.joes-hardware.com/seasonal/index-fall.html과 같은 URL이 있다고 하자.
- 첫 번째 부분인
http는 URL 스킴으로, 웹 클라이언트에게 어떻게 리소스에 접근해야하는지를 알려준다. - 두 번째 부분인
www.joes-hardware.com은 서버의 위치로, 웹 클라이언트에게 리소스가 어디에서 호스팅되는지를 알려준다. - 세 번째 부분인
/seasonal/index-fall.html은 리소스 경로로, 서버의 어떤 리소스를 요청하는지를 알려준다.
URL 문법
URL의 문법은 해당 URL이 사용하는 스킴(HTTP, FTP, SMTP 등)에 따라 달라진다. 하지만 대부분의 URL은 다음의 일반적인 형식을 따른다.
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
| 컴포넌트 | 설명 | 기본값 |
|---|---|---|
| scheme(스킴) | 리소스를 얻기 위해 서버에 접근할 때 사용하는 프로토콜 | None |
| user(사용자명) | 리소스에 액세스하는 데 필요한 사용자 이름 | anonymous |
| password(비밀번호) | 사용자 이름 뒤에 포함될 수 있는 암호로, 콜론(:)으로 구분됨 | 이메일 주소 |
| host(호스트) | 리소스를 호스팅하는 서버의 호스트명 또는 IP 주소 | None |
| port(포트) | 리소스를 호스팅하는 서버가 수신하는 포트 번호. 많은 스킴이 기본 포트를 가짐.(HTTP : 80번) | 스킴에 따라 다름 |
| path(경로) | 리소스에 대한 로컬 이름. 이전 URL 구성요소들과 슬래시(/)로 구분됨 | None |
| params(파라미터) | 일부 스킴에서 입력 파라미터를 지정하는 데 사용됨 | None |
| query(질의) | 일부 스킴에서 애플리케이션에 파라미터를 전달하는 데 사용됨 | None |
| frag(프래그먼트) | 리소스의 조각이나 일부분을 가리키는 이름 | None |
단축 URL
리소스를 편리하게 명시하기 위해 사용되는 것으로 상대 URL과 URL 확장이 있다.
상대 URL
URL은 절대 URL와 상대 URL로 나뉜다.
절대 URL은 리소스에 접근하기 위한 모든 정보가 담겨있는 반면 상대 URL은 불완전하다.
위와 같이 ./hammers.html 만 나와있는 상대 경로가 있을 때, 전체 정보를 얻으려면 base URL이 추가적으로 필요하다. 만약 base URL이 http://www.joes-hardware.com/tools.html이라고 할 때, 이를 통해 기존에 알지못했던 스킴(http)과 호스트(www.joes-hardware.com)을 알 수 있다. 이를 통해 알게 된 이 URL의 절대 URL은 http://www.joes-hardware.com/hammers.html 이 된다.
URL 확장
일부 브라우저에서 지원하는 기능으로, 완전한 URL을 입력하지 않아도 자동으로 확장된다.
URL 확장에는 다음의 두 종류가 있다.
호스트명 확장
사용자가 입력한 불완전한 호스트명을 완전한 호스트명으로 확장해준다. 가령 사용자가
naver를 입력하면 브라우저는 자동으로www.과.com을 호스트명에 붙여준다.히스토리 확장
사용자가 URL을 입력할 때, 미리 저장해둔 방문 기록을 통해 앞부분이 일치하는 URL을 제안한다.
안전하지 않은 문자
URL은 어떤 인터넷 프로토콜로도 안전하게 전송될 수 있도록 설계되어야 한다. 안전하게 전송된다는 것은 URL이 정보의 유실 위험 없이 전송되는 것을 말한다.
SMTP와 같은 일부 프로토콜은 특정 문자를 잃어버릴 수 있는 전송 방식을 사용한다. 따라서 URL에는 상대적으로 작고 안전한 문자인 알파벳의 사용만이 가능하다.
또한 사람들이 URL을 읽을 수 있도록 하기 위해 보이지 않거나 출력할 수 없는 문자 또한 URL에 금지된다.
여기에 더해 URL은 완전해야하기 때문에 이진 데이터를 포함하려면 안전한 문자로의 부호화(encoding)를 거쳐야한다.
URL Character Set
초기 컴퓨터는 영국 중심의 시스템을 가졌기 때문에 US-ASCII를 사용했다. 하지만 시간이 지남에 따라 비영어권 사람들의 사용과 이진 데이터 포함의 요구가 있어왔고, 이를 이스케이프 시퀀스(escape sequences)를 통해 해결했다.
부호화 메커니즘(Encoding Mechanisms)
안전하지 않은 URL 상의 문자를 안전한 문자로 변환하는데 부호화(encoding)가 사용된다. 부호화는 %기호와 뒤따르는 16진수로 이루어진 이스케이프 표기법(escape notation)이다.
다음은 부호화의 예시이다.
| 문자 | ASCII 코드 | URL 예시 |
|---|---|---|
| ~ | 126 (0x7E) | http://www.joes-hardware.com/~joe |
| 스페이스 | 32 (0x20) | http://www.joes-hardware.com/more tools.html |
| % | 37 (0x25) | http://www.joes-hardware.com/100%25satisfaction.html |
문자의 제한
몇 가지 문자들은 URL 상에서 특정 목적으로 예약되어있다.
| 문자 | 예약/제한 |
|---|---|
| % | 이스케이프 토큰으로 예약됨 |
| / | path 세그먼트들을 구분짓기 위해 예약됨 |
| . | 경로 구성요소로 예약됨 |
| .. | 경로 구성요소로 예약됨 |
| # | 프래그먼트 구분자로 예약됨 |
| ? | 쿼리 문자열 구분자로 예약됨 |
| ; | 파라미터 구분자로 예약됨 |
| : | 스킴, 유저/암호, 호스트/포트의 구분자로 예약됨 |
| $ , + | 예약됨 |
| @ & = | 특정 스킴에서 특별한 의미를 지니기 때문에 예약됨 |
| { } | \ ^ ~ ‘ | 안전하지 않아서 제한됨 |
| < > “ | 안전하지 않아서 제한됨 |
| 0x00–0x1F, 0x7F | US-ASCII 문자 상에서 nonprintable하기 때문에 제한됨 |
| > 0x7F | US-ASCII 문자 상에서 7비트 범위를 넘어서기 때문에 제한됨 |