2장. [HTTP - 웹의 기초] URL과 리소스

• URL 문법, 여러 URL 컴포넌트가 어떤 의미를 가지며 무엇을 수행하는지.
• 여러 웹 클라이언트가 지원하는 상대 URL과 확장 URL 같은 단축 URL에 대해서.
• URL의 인코딩과 문자 규칙.
• 여러 인터넷 정보 시스템에 적용되는 공통 URL 스킴.
• 기존 이름은 유지하면서 객체들을 다른 장소로 옮기는 것을 가능하게 해주는
  URN(Uniform Resource Name)을 포함한 URL의 미래.

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

---

1-1. URL이 있기 전 암흑의 시대

URL 이전의 리소스 접근 방식

• 애플리케이션마다 서로 다른 접근 방법과 명령어 사용
• 리소스 위치와 접근 방법을 사람이 직접 설명해야 했음

사용자와 애플리케이션의 부담

• FTP, 뉴스, 이메일 등 각각 전용 클라이언트 필요
• 일반 사용자가 네트워크 리소스를 다루기 어려웠음

❐ 2. URL 문법

---

2-1. 스킴

스킴(Scheme)

• 리소스에 접근하기 위해 사용할 프로토콜을 명시
• URL의 가장 앞부분에 위치
• 대소문자를 구분하지 않음

2-2. 호스트와 포트

호스트(Host)

• 리소스를 제공하는 서버의 위치
• 도메인 이름 또는 IP 주소로 표현

포트(Port)

• 서버 내에서 접근할 네트워크 포트
• 스킴마다 기본 포트가 존재 (HTTP: 80)

2-3. 사용자 이름과 비밀번호

사용자 정보(Userinfo)

• 서버 접근 전에 요구되는 인증 정보
• user:password@host 형태로 표현
• 현대 웹에서는 거의 사용되지 않음

2-4. 경로

경로(Path)

• 서버 내에서 리소스가 위치한 계층적 경로
• / 문자를 기준으로 분리됨

2-5. 파라미터

파라미터(Parameters)

• 서버 요청을 보완하기 위한 추가 정보
• ; 문자로 경로와 구분
• 이름/값 쌍으로 구성

2-6. 질의 문자열

질의 문자열(Query String)

• 서버 또는 게이트웨이에 전달하는 질의 조건
• ?로 시작하며 &로 여러 항목 구분

2-7. 프래그먼트

프래그먼트(Fragment)

• 리소스 전체가 아닌 특정 부분을 가리킴
• 서버로 전달되지 않고 클라이언트에서만 해석

❐ 3. 단축 URL

---

3-1. 상대 URL

상대 URL의 개념

• 절대 URL의 일부만을 사용한 표현 방식
• 기저 URL을 기준으로 해석됨
• HTML 문서 작성 시 URL을 간결하게 만듦

기저 URL(Base URL)

• 상대 URL을 절대 URL로 변환할 때 기준이 되는 URL
• 상대 참조 해석의 출발점

리소스에서 명시적으로 제공되는 기저 URL

• HTML의 <base> 태그로 지정 가능
• 문서 내 모든 상대 URL에 적용됨

리소스를 포함하고 있는 기저 URL

• <base>가 없는 경우, 문서 자체의 URL이 기저 URL이 됨

기저 URL이 없는 경우

• 상대 URL 해석이 불가능
• 불완전하거나 깨진 URL이 될 수 있음

상대 참조 해석 알고리즘

• 상대 URL을 절대 URL로 변환하는 표준 절차
• RFC 1808, RFC 2396에 정의됨

3-2. URL 확장

URL 자동 확장

• 사용자의 입력을 보완하여 URL 전체를 자동 완성
• 브라우저 편의 기능

호스트 명 확장

• yahoo → www.yahoo.com과 같은 자동 보완
• 간단한 휴리스틱 사용

히스토리 확장

• 과거 방문 URL 기록을 기반으로 자동 완성
• 사용자는 전체 URL을 입력할 필요 없음

❐ 4. 안전하지 않은 문자

---

4-1. URL과 안전한 전송

URL은 다양한 프로토콜을 통해 안전하게 전달되어야 한다.

• URL은 여러 프로토콜을 통해 인터넷 상의 리소스를 전달하기 위해 설계되었다.
• 각 프로토콜은 데이터를 전송하는 방식이 서로 다르다.
• 어떤 프로토콜에서도 URL이 손상되지 않고 전달되도록 설계하는 것이 중요하다.
• 안전한 전송이란 URL 정보가 유실되거나 변형되지 않는 것을 의미한다.

안전하지 않은 문자의 문제

• SMTP와 같은 일부 프로토콜은 특정 문자를 제거하거나 변형할 수 있다.
• URL에 포함된 문자가 전송 중 사라지면 리소스를 정확히 식별할 수 없다.
• 이를 방지하기 위해 URL에는 일반적으로 안전한 알파벳 문자만 허용되었다.

이스케이프의 필요성

• URL은 완벽해야 하며, 모든 리소스를 표현할 수 있어야 한다.
• 이진 데이터나 안전하지 않은 문자를 포함해야 하는 경우가 발생한다.
• 이를 위해 안전하지 않은 문자를 안전한 문자로 변환하는 이스케이프 기능이 도입되었다.

4-2. URL 문자 집합

URL의 기본 문자 집합은 US-ASCII이다.

• 초기 인터넷 애플리케이션은 US-ASCII 문자 집합을 기반으로 설계되었다.
• US-ASCII는 7비트 문자 집합으로 영문자 중심이다.
• 제어 문자와 출력되지 않는 문자를 포함한다.
• 전 세계 언어의 문자나 특수 문자를 표현하기에는 한계가 있다.

이진 데이터와 비영문 문자

• URL에는 이진 데이터나 비영문 문자를 포함해야 하는 경우도 있다.
• US-ASCII만으로는 이를 표현할 수 없다.
• 이를 해결하기 위해 URL 인코딩이 필요해졌다.

4-3. 인코딩 체계

안전하지 않은 문자를 퍼센트 인코딩으로 변환한다.

• 인코딩은 % 문자로 시작한다.
• 뒤에 ASCII 코드를 16진수 두 자리로 표현한다.
• 이를 통해 안전하지 않은 문자를 URL에서 안전하게 표현할 수 있다.

퍼센트 인코딩의 예

• ~ → %7E
• 공백 → %20
• % → %25

4-4. 문자 제한

일부 문자는 URL 내에서 특별한 의미로 예약되어 있다.

• 어떤 문자는 URL 구조를 구분하는 용도로 사용된다.
• 예약 문자를 다른 용도로 사용하려면 반드시 인코딩해야 한다.

예약 문자와 제한 문자

• / : 경로 세그먼트 구분
• . , .. : 경로 의미
• ? : 질의 문자열 구분자
• # : 프래그먼트 구분자
• : : 스킴, 사용자 정보, 포트 구분자
• ; : 파라미터 구분자
• @, &, = : 특정 스킴에서 의미를 가짐
• <, >, ", {}, |, \, ^ 등은 반드시 인코딩 필요

제어 문자와 비 US-ASCII 문자

• 0x00–0x1F, 0x7F는 제어 문자로 사용이 제한된다.
• 8비트 문자는 US-ASCII 범위를 벗어나므로 인코딩이 필요하다.

4-5. 좀 더 알아보기

인코딩은 누가, 언제 해야 하는가

• URL을 생성하는 애플리케이션이 인코딩을 책임지는 것이 가장 적절하다.
• 브라우저는 입력된 URL을 그대로 처리하는 경우가 많다.
• 스킴에 따라 인코딩 규칙도 달라질 수 있다.

모든 문자를 인코딩하는 전략

• 모든 문자를 인코딩하면 가장 안전하다.
• 그러나 이미 안전한 문자까지 인코딩하면 혼란을 일으킬 수 있다.
• 일부 애플리케이션은 이를 올바르게 처리하지 못한다.

보안과 패턴 매칭 문제

• 악의적인 사용자는 URL 인코딩을 이용해 필터를 우회할 수 있다.
• 안전한 URL 컴포넌트를 인코딩하면 보안 필터가 이를 인식하지 못할 수 있다.
• URL을 해석하는 애플리케이션은 디코딩 후 처리해야 한다.

❐ 5. 스킴의 바다

---

5-1. 웹에서 사용되는 일반 스킴들

URL 스킴은 리소스에 접근하는 방법을 정의한다.

• URL 스킴은 웹에서 다양한 프로토콜을 통해 리소스에 접근할 수 있도록 한다.
• 각 스킴은 고유한 문법과 목적을 가진다.
• 웹에서 자주 사용되는 대표적인 스킴들의 형식을 이해하는 것이 중요하다.

주요 스킴 요약

• http : 하이퍼텍스트 전송을 위한 기본 웹 프로토콜로, 포트가 생략되면 기본값은 80이다.
• https : HTTP에 보안 계층(SSL/TLS)을 추가한 스킴으로, 기본 포트는 443이다.
• mailto : 이메일 주소를 가리키는 스킴으로, RFC 822 형식의 주소를 사용한다.
• ftp : FTP 서버의 파일을 업로드·다운로드하거나 디렉터리 목록을 조회하는 데 사용된다.
• rtsp / rtspu : 실시간 스트리밍 미디어 리소스를 식별하기 위한 스킴이다.
• file : 로컬 파일 시스템이나 네트워크 파일 시스템의 파일에 접근하기 위한 스킴이다.
• news : 뉴스 그룹이나 뉴스 문서를 식별하기 위한 스킴으로, 위치 정보는 포함하지 않는다.
• telnet : 원격 대화형 서비스에 접속하기 위한 스킴이다.

❐ 6. URL의 미래

---

6-1. URL의 한계

URL은 ‘이름’이 아니라 ‘위치’를 가리킨다.

• URL은 인터넷에 존재하는 모든 객체에 이름을 붙일 수 있도록 설계되었다.
• 새로운 프로토콜과 포맷을 쉽게 추가할 수 있는 강력한 도구다.
• URL은 리소스의 실제 이름이 아니라, 특정 시점의 위치를 나타낸다.
• URL은 리소스를 찾기 위해 필요한 서버 이름과 포트를 제공한다.

위치 기반 식별의 문제점

• 리소스가 이동하면 기존 URL은 더 이상 유효하지 않다.
• URL이 가리키던 객체를 다시 찾을 방법이 사라진다.
• 이는 ‘이름’으로서의 URL이 가지는 근본적인 한계다.

6-2. 이상적인 해결책: 이름과 위치의 분리

객체의 위치와 무관한 영구적인 이름이 필요하다.

• 이상적인 방법은 객체의 위치와 상관없이 객체를 식별하는 것이다.
• 사람의 이름처럼, 객체의 이름만 알면 위치가 바뀌어도 찾을 수 있어야 한다.
• 객체의 이름과 위치 정보를 분리하면 이러한 문제가 해결된다.

6-3. URN (Uniform Resource Name)

위치와 무관하게 객체를 식별하는 영구적인 이름

• IETF는 URN이라는 새로운 표준을 정의하기 시작했다.
• URN은 객체가 이동하더라도 항상 같은 객체를 가리킨다.
• 웹 서버 내부나 서버 간 이동과 무관하게 객체를 식별할 수 있다.
• URN은 ‘이름’에 집중한 식별자다.

6-4. PURL (Persistent URL)

URL에 URN의 개념을 결합한 실용적인 절충안

• PURL은 URL을 사용해 URN과 같은 기능을 제공한다.
• 실제 리소스의 URL 목록을 관리하는 중개 서버를 둔다.
• 클라이언트는 영구적인 URL(PURL)을 요청한다.
• 중개 서버는 현재 리소스의 실제 URL로 클라이언트를 연결해준다.

PURL의 동작 방식

• 1단계: 클라이언트가 PURL 서버에 리소스의 위치를 요청한다.
• 2단계: PURL 서버가 실제 리소스 URL을 반환한다.
• 3단계: 클라이언트가 실제 URL로 리소스를 가져온다.

6-5. 지금이 아니면, 언제?

URN은 이상적이지만, 도입 비용이 매우 크다.

• URN 방식은 오랫동안 논의되었지만 널리 채택되지 않았다.
• URL에서 URN으로 전환하는 것은 매우 큰 변화다.
• 표준 정의뿐 아니라 HTTP 애플리케이션 전반의 수정이 필요하다.
• 벤더 간 합의와 방대한 구현 작업이 요구된다.

현실적인 선택: URL의 지속 사용

• URL은 여전히 단순하고 강력하다.
• 대부분의 인터넷 사용자는 URL 사용법에 익숙하다.
• URL의 한계는 인지되고 있지만, 긴급한 문제로 여겨지지는 않는다.
• 당분간 URL은 계속 사용될 것이다.

미래의 가능성

• URL은 당분간 리소스를 명명하는 핵심 수단으로 남을 것이다.
• 다만 URL의 한계를 보완하는 새로운 표준(URN 계열)이 등장할 수 있다.
• URL은 대체되기보다는 확장·보완될 가능성이 크다.