이번 장에서 살펴볼 주제
- URL 문법, URL 컴포넌트가 어떤 의미를 가지며 무엇을 수행하는지
- 여러 웹 클라이언트가 지원하는 상대 URL과 확장 URL 같은 단축 URL에 대해서
- URL의 인코딩과 문자 규칙
- 여러 인터넷 정보 시스템에 적용되는 공통 URL 스킴
- 기존 이름은 유지하면서 객체들을 다른 장소로 옮겨주는 URN을 포함한 URL의 미래
위 다섯 가지의 주제를 살펴보면서 이번 장을 학습해보도록 하겠습니다!✍
인터넷의 리소스 탐색하기
URL은 브라우저가 정보를 찾는데 필요한 리소스의 위치를 가리키며, 이로 인해서 유저들은 셀 수 없이 많은 리소스를 찾아내고, 활용할 수 있습니다.
URL은 URN과 합쳐져 URI라는 종합적인 개념의 부분 집합입니다. 여기서 URN이란 이름만을 통해 리소스를 식별하는 방법입니다.
하나의 URL 예제를 통해 구조를 살펴보겠습니다.
- http : URL의 스킴으로서 웹 클라이언트가 리소스에 어떻게 접근하는지 알려줍니다.
- www.joes-hardware.com : 서버의 위치로서 웹 클라이언트가 리소스가 어디에 호스팅 되어있는지 알려줍니다.
- seasonal/index-fall.html : 리소스의 경로로서 서버에 존재하는 리소스 중 요청 받은 리소스가 무엇인지 알려줍니다.
또한 URL은 HTTP 뿐만 아니라 FTP(File Transfer Protocol)과 같은 프로토콜을 사용할 수도 있습니다.
위와 같이 URL은 스킴://서버위치/경로 구조로 이루어져 있습니다. 하지만 이런 구조가 처음부터 일관적으로 이루어 지진 않았습니다.
정말 말하기도, 보기도 힘든 방법으로 URL을 명명했었지만, 지금의 명명법이 자리잡은 후엔 보다 편하고 일관적으로 리소스에 접근할 수 있습니다.
URL 문법
대부분의 URL 문법은 일반적으로 9개 부분으로 나뉩니다.
<스킴>://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>
위 모든 컴포넌트를 가지는 URL은 사실 거의 없다고 봐도 무방하지만 가장 중요한 컴포넌트는 스킴, 호스트, 경로입니다.
스킴: 사용할 프로토콜
스킴은 리소스에 대해 어떻게 접근하는지 알려주는 아주 중요한 정보입니다. 어떤 프로토콜을 사용하여 리소스를 요청해야하는지 알려줍니다.
예제에서는 http를 사용하며 ':'문자로 구분하고, 대소문자를 구분하지 않습니다.
호스트와 포트
애플리케이션이 인터넷의 리소스를 찾으려면, 리소스를 가지고 있는 서버를 찾아야 합니다. URL의 호스트와 포트는 그 정보를 제공해줍니다.
위 예제에서는 **www.joes-hardware.com**가 호스트입니다.
어? 뭔가 이상한데요? 왜 호스트만 있고 포트번호는 없죠..??
포트번호는 바로 TCP 프로토콜을 사용하는 HTTP는 기본 포트를 *80*을 가리키기 때문에 만약 포트번호가 보이지 않는다면 80이라는 것을 알고계시면 됩니다.
사용자 이름과 비밀번호
보통의 서버들은 유저의 이름과 비밀번호 데이터를 가지고 접근을 허용합니다.
위 URL에서 이름:비밀번호를 명시하였습니다.
만약 비밀번호를 입력하지 않았다면 비밀번호는 브라우저의 기본값을 사용하게 되어있습니다.
경로
URL의 경로 컴포넌트는 리소스가 서버의 어디에 있는지 알려줍니다.
이 URL의 경우에는 www.joes-hardware.com라는 호스트를 가진 서버의 index.html라는 리소스를 나타냅니다.
파라미터
많은 스킴이 객체에 대한 호스트 및 경로만으로는 리소스를 찾지 못합니다. 서버가 어떤 포트를 열어놓았는지, 사용자 이름과 비밀번호가 있는지 등 많은 요소가 있기 때문입니다.
URL을 사용하는 애플리케이션이 리소스에 접근하기 위해서는 파라미터가 필요합니다. 만약 파라미터가 없다면, 서버는 그 요청을 잘못 처리하거나 알아듣지 못할 것입니다.
그래서 서버에서 정확한 요청을 위해 필요한 입력 파라미터를 받는데 사용합니다.이름/값 쌍의 리스트로 ; 문자로 구분하여 URL에 기술합니다.
http://www.joes-hardware.com/hammers;sale=false/index.html;graphics=true
위 예제의 URL에서는 hammers, index 두 개의 경로조각이 있고 각각 false, true라는 파라미터를 가지게 됩니다.
질의 문자열
데이터베이스 같은 서비스에서 요청받을 리소스 형식의 범위를 좁히기 위해 질문이나 질의를 받을 수 있습니다.? 문자로 구분하며 ?의 우측에 있는 값이 범위를 좁힌 값입니다. 이 것을 질의 컴포넌트라고 합니다.
http://www.joes-hardware.com/inventory-check.cgi?item=930917
위 예제에서는 930917이라는 번호를 가진 상품의 재고를 체크하는 URL입니다.
또한 & 문자를 통해 두 개의 질의 컴포넌트를 사용할 수도 있습니다.
http://www.joes-hardware.com/inventory-check.cgi?item=930917&color=black
930917이라는 번호와 색이 검정색인 상품을 체크하는 URl입니다.
프래그먼트
HTML 같은 리소스 형식들을 본래의 수준보다 더 작게 나누어 표현이 가능합니다. # 문자를 사용하여 특정 이미지나 일부분을 가리킬 수 있습니다.
위 예제에서는 drills라는 프래그먼트를 가리키고 있고 tools.html 내부에 있는 일부입니다.
즉, 프래그먼트를 사용하면 가져온 전체 리소스 중 일부를 보여주는 것입니다.
단축 URL
웹 클라이언트는 단축 URL을 인식하고 사용합니다. 브라우저가 사용자가 기억하고 있는 URL을 입력하게 되면 나머지를 자동으로 입력하는 자동 확장합니다.
여기서 알아볼 URL은 상대 URL을 학습할 것입니다.
상대 URL
상대 URL은 URL을 짧게 표기하는 방식입니다. 절대 URL과 같이 모든 정보를 가지고 있지 않기 때문에 기저(base) URL을 사용해야합니다.
하나의 URL을 예제로 살펴보겠습니다.
위의 URL이 있다면 tools.html 이라는 리소스를 바라보고 있을 것입니다.
여기서 ./hammers.html URL을 가리키는 하이퍼링크를 선언했다면 과연 옳은 문법일까요❓
뭔가 이상하다고 느끼시겠지만 옳은 문법입니다. 이유는 /tools.html을 기준으로 상대 URL로 명시한 것이기 떄문입니다.
현재 기저 URL은 http://www.joes-hardware.com/tools.html 이기 때문에 스킴, 호스트는 기저 URL의 것을 사용할 것이라는 것을 예측하고 자동으로 리소스를 가져와 새로운 절대 URL을 만들어냅니다.
위 URL처럼 자동으로 기저 URL을 가져와 새로운 절대 URL을 만들어냅니다.
URL 확장
브라우저들은 URL을 입력한 다음이나 입력 중 자동으로 URL을 확장하여 사용자가 URL을 빠르게 입력할 수 있도록 도와줍니다.
이런 확장 가능은 총 ✌가지로 나뉩니다.
호스트 명 확장
단순 휴리스틱만을 사용하여 입력한 호스트 명으로 확장이 가능합니다.
예를들어 주소창에 'naver'를 입력하면 브라우저는 자동으로 'www.'과 '.com'을 붙여 "www.naver.com" 을 만들게 됩니다.
히스토리 확장
사용자가 URL을 입력하는 시간을 줄이기 위해 과거에 사용자가 방문했던 URL의 기록을 저장해 놓습니다.
그래서 사용자는 주소를 다 작성하기 전에 기록해 놓은 URL을 선택만 하면 됩니다.
안전하지 않은 문자
URL설계자들은 URL에 담긴 정보를 안전하게 전송하기 위해 이스케이프라는 기능을 추가하여 안전한 문자로 인코딩 하도록 하였습니다.
그에 따른 사용할 수 있는 알파벳과 URL의 인코딩 규칙에 대해 알아보겠습니다.
URL 문자 집합
컴퓨터의 기본 문자 집합은 영어 중심으로 설정되어 있기 때문에 US-ASCII 문자 집합을 사용해왔습니다.
US-ASCII 문자열에서 사용이 금지된 문자들을 모은 것이 이스케이프 문자열로 특정 문자나 데이터를 인코딩할 수 있게 함으로써 이동성과 완성도를 높였습니다.
인코딩 체계
안전한 문자 집합을 이용하는 경우 그 표현의 한계를 넘기 위해서 URL에 있는 안전하지 않은 문자들을 표현할 수 있는 인코딩 방식을 사용합니다.%기호로 시작하여 ASCII 코드로 표현되는 두 개의 16진수 숫자로 이루어진 이스케이프문자로 바꿉니다.
문자 제한
몇몇 문자는 URL 내에서 특별한 의미로 예약이 되어있어 다른 용도로 사용하기 위해서는 반드시 인코딩을 해야하는 문자들이 있습니다.
| 문자 | 선점 및 제한 |
|---|---|
| % | 인코딩된 문자에 사용할 이스케이프 토큰으로 선점 |
| / | 경로 컴포넌트에 있는 경로 세그먼트를 나누는 용도로 선점 |
| . | 경로 컴포넌트에서 선점 |
| .. | 경로 컴포넌트에서 선점 |
| # | 프래그먼트의 구획 문자로 선점 |
| ? | 질의 문자열의 구획 문자로 선점 |
| ; | 파라미터의 구획 문자로 선점 |
| : | 스킴, 사용자 이름/비밀번호, 호스트/포트의 구획 문자로 선점 |
| \$ , + | 선점 |
| @ % = | 특정 스킴에서 특별한 의미가 있기 때문에 선점 |
| {} \ ~ [] ` | 게이트웨이와 같은 여러 전송 에이전트에서 불안전하게 다루기 때문에 제한됨 |
| <> " | 안전하지 않음. 웹 문서에서 URL을 구분지어 표시하듯이, URL 범위 밖에서 역할이 있는 문자이기 때문에 반드시 인코딩 해야한다. |
| 00x00-0x1F , 0x7F | 제한됨. 이 16진수 범위에 속하는 문자들은 인쇄되지 않은 US-ASCII 문자다. |
| > 0x7F | 제한됨. 이 16진수 범위에 속하는 문자들은 7비트 US-ASCII 문자가 아니다. |
스킴
웹에서 일반적으로 사용하는 스킴에 대해서 알아보겠습니다.
| 스킴 | 설명 |
|---|---|
| HTTP | 일반 URL 포맷을 지키는 스킴입니다. 포트값이 생략되어 있다면 80입니다. 기본형식 : http://<호스트>:<포트>/<경로>?<질의>#<프래그먼트> 예 : http://www.joes-hardware.com:80/index.html |
| https | HTTP와 거의 같으며 차이는 SSL(보안 소켓 계층)을 사용하는 것 뿐입니다. 기본 포트값는 443입니다. 기본형식 : http://<호스트>:<포트>/<경로>?<질의>#<프래그먼트> 예 : http://www.joes-hardware.com/secure.html |
| mailto | 이메일 주소를 가리키며 표준 URL과 다른 문법을 가집니다. 기본형식 : mailto: RFC-822-addr-spec 예 : mailto: junjang@gmail.com |
| ftp | 파일 전송 프로토콜 URL은 FTP 서버에 있는 파일을 내려 받거나 올리고, FTP 서버의 디렉터리에 있는 콘텐츠 목록을 가져오는데 사용합니다. 기본형식 : http://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터> 예 : ftp://junjang:1234%40joes-hardware.com@prep.ai.mit.edu:21/pub/gnu/ |
| rtsp, rtspu | 실시간 스트리밍 프로토콜을 통해서 읽을 수 있는 오디오 및 비디오와 같은 미디어 리소스 식별자입니다. 기본형식 : rtsp(u)://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로> 예 : rtsp(u)://www.joes-hardware.com/interview/cto_video |
| file | 주어진 호스트 기기에서 바로 접근할 수 있는 파일들을 나타냅니다. 기본형식 : file://<호스트>/<경로> 예 : file://OFFICE-FS/policies/casual-fridays.doc |
| news | 특정 문서나 뉴스 그룹에 접근하는데 사용합니다. 기본형식 : news: newsgroup 예 : news:rec.arts.startrek |
| telnet | 대화형 서비스에 접근하는데 사용합니다. 기본형식 : telnet://<사용자 이름>:<비밀번호>@<호스트>:<포트>/ 예 : telnet://junjang:webhound@joes-hardware.com:23/ |
미래의 URI는?
현재 사용하는 URL은 단지 주소일 뿐 실제 이름이 아닙니다. 여기서 단점은 리소스가 옮겨지면 URL을 더이상 찾을 수 없게 됩니다. 그렇다면 URL이 가리키고 있던 객체를 다신 찾을 수 없게 됩니다.
이런 문제를 예방할 수 있는 이상적인 방법은 객체의 위치와 관계 없이 객체 자체의 이름으로 찾는 방법입니다. 그래서 나온 방식이 URN 방식으로 객체가 옮겨지더라도 객체를 가리킬 수 있는 이름을 제공합니다.
한동안 URN이 사용이 되었지만 기존의 URL을 바꾸는 작업과 인프라 문제 등 많은 변화가 필요하기 때문에 당장 URN으로 전환하기는 많은 어려움이 있을 것입니다.