2. URL과 리소스

• URL(Uniform Resource Locator) : 인터넷의 리소스를 가리키는 표준이름

2.1 인터넷의 리소스 탐색

URL은 브라우저가 정보를 찾는데 필요한 리소스의 위치를 가리킵니다.

URL은 URI의 부분집합입니다. URI는 URL과 URN으로 구성된 종합개념입니다.

다음의 예시를 보면 기본적인 URL의 구성을 확인할 수 있습니다.

http://www.joes-hardware.com/seasonal/index-fall.html

• 첫 번째 부분, http : URL의 스킴
• 두 번째 부분, www.~ : 서버의 위치
• 세 번째 부분, /seasonal/~ : 리소스의 경로

URL 이전.

각기 다른 룰을 사용했기 때문에 사용하기 불편했습니다.

URL을 통해서 정보를 찾는데 필요한 모든 것을 제공하며, 원하는 리소스가 어디에 위치하고 가져오는지 정의합니다.

2.2 URL 문법

일반적으로 URL 스킴의 문법은 다음과 같습니다.

<스킴>://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>

이를 간략하게 설명하면 다음과 같습니댜.

컴포넌트	설명	기본 값
스킴	리소스를 가져오려면 어떤 프로토콜을 사용하여 서버에 접근해야 하는지 가리킵니다.	없음
사용자 이름	몇몇 스킴은 리소스에 접근을 하기 위해 사용자 이름을 필요로 합니다.	anonymous
비밀번호	사용자의 비밀번호를 가리키며, 사용자 이름에 콜론(:)을 이어서 기술합니다.	<이메일주소>
호스트	리소스를 호스팅하는 서버의 호스트 명이나 IP 주소	없음
포트	리소스를 호스팅하는 서버가 열어놓은 포트번호, 많은 스킴이 기본 포트를 가지고 있습니다.	스킴에 따라 다름
경로	이전 컴포넌트와 빗금으로 구분되어 있으며, 서버 내 리소스가 서버 어디에 있는지를 가리킵니다.	없음
파라미터	특정 스킴들에서 입력 파라미터를 기술하는 용도로 사용합니다.	없음
질의	스킴에서 애플리케이션에 파라미터를 전달하는데 쓰입니다.	없음
프래그먼트	리소스의 조각이나 일부분을 가리키는 이름입니다.	없음

스킴 : 사용할 프로토콜

대표적인 예시로 http, https, ftp 등이 있습니다. :로 구별하며, 대소문자를 가리지 않습니다.

호스트와 포트

애플리케이션이 인터넷에 있는 리소스를 찾으려면 리소스를 호스팅하고 있는 장비와 그 장비 내에서 리소스에 접근할 수 있는 서버가 어디있는지 알아야합니다. URL의 호스트와 포트 컴포넌트는 그 두가지 정보를 제공합니다

호스트 명으로, IP 주소로 같은 리소스를 나타냅니다.

• http://www.joes-hardware.com:80/index.html
• http://161.58..228.45:80/index.html

사용자 이름과 비밀번호

많은 서버가 자신이 가지고 있는 데이터에 접근을 허용하기 전에 사용자 이름과 비밀번호를 요구합니다.

대표적인 예시는 다음과 같습니다.

• ftp://ftp.prep.ai.mit.edu/pub/gnu
• ftp://anonymous@ftp.prep.ai.mit.edu/pub/gnu
• ftp://anonymous:my_passwd@ftp.prep.ai.mit.edu/pub/gnu
• http://joe:joespasswd@www.joes-hardware.com/sales_info.txt

경로

URL의 경로 컴포넌트는 리소스가 서버의 어디에 있는지 알려줍니다. 해당 경로는 아래 예와 같이 계층적 파일 시스템 경로와 유사한 구조를 가집니다.

http://www.joes-hardware.coem:80/seasonal/index-fall.html

여기서 URL의 경로는 /seasonal/index-fall.html입니다. 이러한 경로는 서버가 리소스의 위치를 찾는데 사용하는 정보입니다.

파라미터

많은 스킴은 객체에 대한 호스트 및 경로 정보만으로 리소스를 찾지 못합니다. 따라서 많은 정보를 얻기 위해서 다른 정보도 필요합니다. 일반적으로 이름/값 쌍의 리스트를 받으며 ; 문자로 구분합니다.

다음과 같은 예시가 있습니다.

• ftp://prep.ai.mit.edu/pub/gnu;type=d
• http://www.joes-hardware.com/hammers;sale=false/index.html;graphics=true
  • hammers와 index.html라는 두개의 경로조작이 있으며, false인 sales이라는 파라미터를 가집니다.

질의 문자열

데이터베이스와 같은 서비스들은 요청받을 리소스 형식의 범위를 좁히기 위해서 질문이나 질의를 받을 수 있습니다.

대표적인 예시는 다음과 같습니다.

• http://www.joes-hardware.com/inventory-check.cgi?item=12731
• http://www.joes-hardware.com/inventory-check.cgi?item=12731&color=blue

편의상 많은 게이트웨이가 &로 나뉜 이름-값 쌍 형식의 질의 문자열을 원합니다.

프래그먼트

HTML 같은 리소스 형식들은 본래의 수준보다 더 작게 나뉠 수 있습니다. 프래그먼트는 URL의 오른쪽에 # 문자에 이어서 옵니다.

• http://www.joes-hardware.com/tools.html#drills

2.3 단축 URL

웹 클라이언트는 몇몇 단축 URL을 인식하고 사용합니다. 이러한 상대 URL은 리소스 안에 있는 리소스를 간결하게 기술하는데 사용할 수 있습니다.

상대 URL

URL은 상대 URL과 절대 URL 두가지로 나뉩니다. 앞서 나온 내용은 절대 URL이며, 리소스에 접근하는데 필요한 모든 정보를 가지고 있습니다. 그러나, 상대 URL은 모든 정보를 담고 있지않으며, 필요한 정보를 얻기 위해서는 base라고 하는 다른 URL을 사용해야합니다.

ex) <a href="./hammers.html">

이를 좀더 보면 다음과 같습니다.

• 기저 URL : http://www.jeos-hardware.com/
• 상대 URL : ./hammers.html
• 새로운 절대 URL : http://www.jeos-hardware.com/hammers.html

상대 URL은 프래그먼트이거나 URL 일부입니다. URL을 처리하는 브라우저 같은 애플리케이션은 상대 URL과 절대 URL 간에 상호 변환을 할 수 있어야합니다.

기저 URL

변환 과정의 첫 단계는 기저 URL을 찾는 것입니다. 이를 찾는 방법은 여러가지가 있습니다.

• 리소스에서 명시적으로 제공
• 리소스를 포함하고 있는 기저 URL
• 기저 URL이 없은 경우
• 상대 참조 해석

URL 확장

어떤 브라우저들은 URL을 입력한다음 자동으로 URL을 확장합니다. 이를 통해서 전체를 입력하지 않아도 됩니다.

• 호스트 명 확장
  • 단순한 휴리스틱만을 제공
  • yahoo를 www.yahoo.com으로 만듭니다.
• 히스토리 확장
  • 과거에 사용자가 방문햇던 URL의 기록을 저장합니다.

2.4 안전하지 않은 문자

모든 프로토콜이 데이터를 전송하기 위해서 여러 다른 장치를 가지고 있기 때문에 이를 안전하게 전송할 수 있도록 URL을 설계하는 것이 중요합니다.

안전한 전송이란 정보가 유실될 위험 없이 URL을 전송할 수 있다는 것을 의미합니다. 이를 위해 이스케이프 등의 기능을 추가했습니다.

URL 문자 집합

옛날의 컴퓨터 애플리케이션은 US-ASCII(7bit) 문자 집합을 사용했습니다. 이는 현대에서는 지원하지 않는 언어가 많기 때문에 이스케이프 문자열을 쓸수 있게 설계하였습니다. 이릍 통해서 특정 문자나 데이터를 인코딩할 수 있게 함으로써 이동성과 완성도를 높일 수 있습니다.

인코딩 체계

여러 예시가 있으며 다음과 같은 예시가 있습니다.

문자	ASCII 코드	URL의 예
-	126(0x7E)	~/%7Ejoe
	32(0x20)	~/more%20tools.html
%	37(0x25)	~/%100%25satisfaction.html

문자 제한

다음은 예약이 되어 있습니다.

• %(이스케이프 토큰), /, ., ..
• #, ?, ;, :, $, +, @ & =
• {} | \ ~ [ ] < > "
• 0x00-0x1F, 0x7F

2.5 스킴의 바다

대표적인 예시는 다음과 같습니다.

• http
• https
• mailto
• ftp
• rtsp, rtspu
• file
• news
• telnet

2.6 미래

URL은 강력한 도구이며, 세상에 존재하는 모든 객체에 이름을 지을 수 있고 새로운 포멧을 쉽게 추가할 수 있습니다. 다만, 완벽한 것은 아닙니다. 즉, 리소스가 옮겨지면 URL을 더 사용할 수 없는 문제점이 제공합니다.

이를 해결하기 위해서 URN(Uniform Resource Names)이나 PURL(Persistent uniform resource locator) 등을 통해서 리소스를 우회적으로 제공합니다.

다만, URN 방식이 현재 활용되지 않은 이유는 이는 매우 큰 작업이고, 많은 변화가 필요합니다. 그리고, 긴급한 사항이 아니기 때문에 변화가 적습니다.

추가 정보

• URI와 URL의 작명 및 할당에 대한 W3C 웹페이지
• RFC
• 지속 통합 자원 지시자, PURL