[Http 완벽 가이드] 02장: URL과 리소스

이 포스트는 HTTP 완벽 가이드의 02장 "URL과 리소스" 를 읽고 정리한 내역입니다.

---

1. 인터넷의 리소스 탐색하기

1.1 URL 이란?

• URL은 정보를 찾는데 필요한 리소스의 위치를 가리킨다
• URL을 통해 인터넷 상의 리소스를 찾고 사용하며 공유할 수 있다
• URL을 통해 사람이 HTTP 및 다른 프로토콜을 통해 접근할 수 있다
• URI, URL, URN
  • URI : 통합 자원 식별자(URL, URN을 아우르는 개념)
  • URL : 위치를 기반으로 리소스를 식별
  • URN : 이름을 통해 리소스 식별

1.2 URL의 구조

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

<스킴>://서버위치/경로

• 스킴(어떻게) : 클라이언트가 리소스에 어떻게 접근하는 지를 알려줌. 어떤 프로토콜을 통해 접근할지를 명시함
• 호스트(어디에) : 서버의 위치. 리소스가 어디에 호스팅 되어있는 지 알려줌.
• 경로(무엇을) : 서버에 존재하는 로컬 리소스들 중에서 요성받은 리소스가 무엇인지

1.3 URL이 있기 전 암흑시대

• 리소스에 접근하기 위해 애플리케이션마다 달리 가지고 있는 분류 방식을 사용했음

1.4 URL 덕분에…

• URL을 통해 일관된 방식으로 리소스에 접근할 수 있다
• URL은 애플리케이션이 리소스에 접근할 수 있는 방식을 제공한다
• URL은 브라우저가 더 영리하게 리소스에 접근하고 그것을 다루게 함으로써 온라인 세상을 단순화 시킨다.
• URL 만으로, 브라우저에게 정보를 찾는데 필요한 모든 것을 제공하며, 원하는 리소스가 어디에 위치하고 어떻게 가져오는 지 정의한다.

---

2. URL 문법

 

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

2.1 스킴

• 리소스에 어떻게 접근하는가?
• 리소스를 가져오려면 어떤 프로토콜을 사용하여 서버에 접근해야하는 지 가리킨다
• 알파벳으로 시작해야하고 대소문자를 구분하지 않음.
• 예) http, ftp, …

2.2 호스트와 포트

• 호스트 : 리소스를 호스팅하는 서버의 호스트명 또는 IP 주소
• 포트 : 호스팅하는 서버가 열어놓은 포트 번호. 많은 스킴이 기본 포트 번호를 가지고 있음
  • HTTP 프로토콜은 80, HTTPS는 443

2.3 사용자 이름과 비밀번호

• 사용자 이름 : 몇몇 스킴은 리소스에 접근하기 위해 사용자 이름을 필요로 한다
• 비밀번호 : 사용자의 비밀번호를 가리키며, 사용자 이름에 콜론(:)으로 이어서 기술

2.4 경로(Path)

• 이전 컴포넌트와 빗금으로 구분되어 있으며, 서버 리소스가 서버 어디에 있는지 기술
• 서버가 리소스의 위치를 찾는데 사용하는 정보(우리 서버의 어디에 해당하는 리소스인가)
• 계층형 파일 시스템의 경로와 유사한 구조를 가진다.
• 경로 컴포넌트의 문법은 서버와 스킴에 따라 다르다.
  • HTTP URL에서 경로 컴포넌트는 슬러시(/) 를 기준으로 경로 조각으로 나뉜다.
  • 이것은 유닉스 파일 시스템의 파일 경로와 유사하게 짜여져 있다.

2.5 파라미터

<ftp://prep.ai.mit.edu/pub/gnu;**type=d**>

<http://www.joes-hardware.com/hammers;**sale=false**/index.html;**graphics=true**>

• 특정 스킴들에서 입력 파라미터를 기술하는 용도로 사용
• 이름/값 을 쌍으로 가진다.
• 다른 파라미터나 경로의 일부와 세미콜론으로 구분하여 기술하며, 여러 개를 가질 수 있다
• 경로 컴포넌트는 경로 조각으로 나뉘는데 각각의 경로 조각마다 파라미터를 가질 수 있다.

2.6 질의 문자열(Query String)

<http://www.joes-hardware.com/inventory-check.cgi?**item=12731**>

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

• 스킴에서 애플리케이션(데이터베이스, 게시판, 검색엔진, 기타 인터넷 게이트웨이)에 파라미터를 전달하는데 쓰인다.
• 질의 컴포넌트를 작성하는 데 쓰이는 공통 포맷은 없다.
  • 편의 상 많은 게이트웨이가 & 로 나뉜 이름=값 쌍 형태 질의 문자열을 원한다.
• URL 끝에 물음표(?)로 구분한다.

2.7 프래그먼트

<http://www.joew-hardware.com/tools.html#drills>

• 리소스의 조각이나 일부분을 가리키는 이름
• URL이 특정 객체를 가리킬 경우 프래그먼트 필드는 서버에 전달되지 않는다
• 주로 클라이언트에서만 사용한다. URL의 끝에서 샵(#) 문자로 구분한다.

<h1 id="my-title">제목</h2>
<a href="#my-title">제목으로</a>

참고로 HTML에서 a 태그의 요소 href 속성값으로 #id 를 전달하면 해당 위치로 이동할 수 있다.

 

---

3. 단축 URL

3.1 상대 URL

• 상대 URL을 통해 리소스 안에 있는 리소스를 간결하게 기술하는 데 사용할 수 있다
• 절대 URL vs 절대 URL
  • 절대 URL : 리소스에 접근하는데 필요한 모든 정보를 가진 URL
  • 상대 URL : URL을 짧게 표기하는 방식.
• 스킴, 호스트, 그리고 다른 컴포넌트를 모두 입력하지 않아도 된다.
• 컴포넌트가 포함된 리소스의 기저 URL에서 얻어낼 수 있다.
  • 상대 URL을 절대 URL로 변경하려면 기저 URL이 필요하다.
  • 상대 URL의 기준이 되는 URL이다
• 프래그먼트이거나, URL 일부이다.
• URL을 처리하는 브라우저와 같은 애플리케이션은 상대 URL과 절대 URL 간 상호변환을 할 수 있어야 한다.
• 절대 URL은 리소스에 접근하는 모든 정보를 기술해야하기 때문에 리소스 위치가 변경되면 잘 동작하지 않지만, 상대 URL은 리소스 집합채로 이동하더라도 기저 URL에 의해 해석되므로 위치를 변경하더라도 잘 동작된다.

3.2 기저 URL 얻어오기

• 리소스에서 명시적으로 제공
  • 기저 URL을 리소스에 명시적으로 기술하는 방식
  • 예) HTML base 태그
• 리소스를 포함하고 있는 기저 URL
  • 기저 URL이 명시되지 않았을 경우, 리소스의 URL을 기저 URL로 사용한다.
• 기저 URL이 없을 경우
  • 보통 절대 URL로 이루어져 있다는 뜻이다.
  • 하지만 불완전하거나 깨진 URL일 수 있다

3.3 상대 참조 해석하기

• URL 파싱(분해) : 상대 URL과 기저 URL을 각각의 컴포넌트 조각으로 나눈다.
• 컴포넌트 분리 후, 상대 URL, 기저 URL을 기반으로 변환 알고리즘을 거쳐서 절대 URL을 구성한다.
• RFC 1808에 최초 기술되고, RFC 2396에 포함된 알고리즘

3.4 URL 확장

• 어떤 브라우저들은 URL을 입력한 다음 또는 입력 도중 자동 URL을 확장한다
• 이를 통해 사용자라 URL을 빠르게 입력하게 도와준다.
• 종류
  • 호스트명 확장 : 입력한 호스트명 일부를 전체 호스트명으로 확장
    • 예) yahoo → www.yahoo.com
    • 어떤 브라우저는 yahoo 란 단어를 포함한 단어를 찾지 못 하면 확장을 포기하기 전에 몇 가지 URL을 추가 제시한다.
    • 프록시 같은 HTTP 애플리케이션에 문제를 발생시킬 수 있다 → 6장
  • 히스토리 확장 : 사용자가 과거 방문한 URL을 기록으로 저장하고 확장
    • 예) http://www.joes- → 이전에 방문한 기록을 기반으로 전체 URL 완성
    • 프록시를 사용할 경우 다르게 동작할 수 있다. → 6장

---

4. 안전하지 않은 문자

4.1 URL과 안전성

• 안전한 전송 : 정보가 유실될 위험 없이 URL을 전송할 수 있어야한다
• 일부 프로토콜에서는 특정 문자가 제거될 수 있는 전송방식을 이용한다.
• 문자가 제거되는 일을 피하고자 URL은 상대적으로 작고 일반적으로 안전한 알파벳 문자만 포함하도록 허용한다.

4.2 URL 문자 집합

• ASCII는 만들어진 지 오래된 문자집합이기 때문에 적은 수의 문자만을 포함하고 있다
• 하지만 중국어, 일본어, 유럽어, 비 라틴계 언어, … 등까지 ASCII가 지원하지는 않는다
• 그뿐만 아니라 이진 데이터까지 포함해야하는 경우도 있다.
• URL 설계자들은 이스케이프 문자열을 쓸 수 있게 설계하여, ASCII 이외의 특정 문자나 데이터를 인코딩할 수 있게 하여 이동성과 완성도를 높였다.

4.3 인코딩 체계

• URL 인코딩 : 안전하지 않은 문자를 퍼센티지 기호(%)로 시작해 ASCII 코드로 표현되는 두 개의 16진수 숫자로 이루어진 이스케이프 문자로 변환
• 예)
  • ~ → %7E
  • 빈문자 → %20
  • % → %25
  • 가 → %EA%B0%80

4.4 문자 제한

• 몇 몇 문자는 URL내에서 특별한 의미로 예약되어 있어 사용될 수 없다.
• 본래 예약된 의미 이외로 사용하려면 인코딩해야한다.
• 예) % , / , . , .. , # , …

4.5 좀 더 알아보기

• 어떤 애플리케이션에 URL을 보내든지, 클라이언트 애플리케이션에서 안전하지 않거나 제한된 문자를 변환하는 것이 좋다.
  • 다른 애플리케이션 입장에서는 혼동할 일이 없어진다.
• 브라우저와 같이 최초로 URL을 입력받는 애플리케이션에서 인코딩 하는 것이 가장 적절하다.
  • URL 을 구성하는 컴포넌트마다 사용할 수 있거나 없는 문자들이 있고, 어떤 문자는 스킴에 따라서 가용성이 달라지기 때문에 해당 문자들을 직접 받는 애플리케이션에서 어떤 문자를 인코딩할지 결정하기 가장 좋다.
• 극단적으로 애플리케이션이 모든 문자를 인코딩하는 방식도 있겠으나, 안전한 문자도 같이 인코딩하지 않는 애플리케이션도 있기 때문에 오동작을 일으킬 수 있다
• URL 패턴매칭(필터링)을 회피하여 필터링 대상을 다른 문자들을 인코딩하는 경우도 존재하므로, URL을 해석하는 애플리케이션은 처리하기 전에 URL을 디코드 해야한다.
• 스킴과 같은 몇몇 URL 컴포넌트는 쉽게 알아볼 수 있어야 하며 알파벳으로 시작되어야 한다

---

5. 스킴의 바다

자주 사용되는 스킴들이 기술되어 있다.

• http : 80
  • 사용자 이름, 비밀번호가 없다
  • http://<호스트>:<포트>/<경로>?<질의>#프래그먼트
• https : 443
  • http 커넥션 양 끝단에서 암호화를 위해 SSL을 사용
  • https://<호스트>:<포트>/<경로>?<질의>#프래그먼트
• mailto
• ftp
• rtsp, rtspu
• file
• news
• telnet

---

6. 미래… (feat. URN)

• URL 은 위치 기반이다. 리소스가 이동되면 더 이상 URL을 사용할 수 없다
• 가장 이상적인 방법은 실제 객체 이름을 사용하는 것이다(URN)
• PURL : 지속 통합 자원 지시자
  • 실제 URL 목록을 관리하고 추적하는 리소스 위치 중개 서버를 두고 해당 리소스를 우회적으로 제공
  • 클라이언트는 위치 할당자에게 리소스를 가져올 수 있는 영구적인 URL을 요청할 수 있으며, 영구적인 URL은 클라이언트 리소스의 실제 URL로 연결해준다
  • https://purl.archive.org/
• URN은…
  • URL에서 URN으로 주소체계를 바꾸는 것은 매우 큰 작업이다
  • 표준 재정의, 벤더간 합의, 여러 HTTP 애플리케이션 수정, …
  • 아마 별 일이 없으면 아주 먼 미래까지 URL은 계속 사용될 것이다…

---

이어서

이상으로 HTTP 완벽가이드의 02장, URL과 리소스에 대해 살펴봤습니다.

이어지는 글에서는 '03장 HTTP 메시지'에 대해 학습 내역을 정리해보겠습니다.