HTTP 완벽 가이드 | URL과 리소스

URL과 리소스

URL은 인터넷의 리소스를 가리키는 표준이름이다.
URL은 전자 정보 일부를 가리키고 그것이 어디에 있고 어떻게 접근할 수 있는지 알려준다.

인터넷의 리소스 탐색하기

URL은 통합 자원 식별자(Uniform Resource Identifier) 혹은 URI라고 불리는 더 일반화된 부류의 집합이다. URI는 두가지 주요 부분집합인 URL과 URN으로 구성된 종합적인 개념이다.

URL을 사용하면 리소스를 일관된 방식으로 지칭할 수 있다. 대부분의 URL은 동일하게 '스킴://서버위치/경로' 구조로 이루어져있다. 따라서 인터넷 상의 모든 리소스를 가리키고 가져오기 위해, 그리고 모든 사람이 같은 방식으로 이름을 써서 리소스를 찾을 수 있도록 단일 방식의 작명 규칙을 가진 것이다.

URL은 애플리케이션이 리소스에 접근할 수 있는 방법을 제공한다. 사실 많은 사용자는 브라우저가 그들이 요청하는 리소스를 가져오는데 사용되는 프로토콜과 접근 방식이 뭔지 모른다. 웹 브라우저를 사용하면, 인터넷 뉴스를 읽으려고 뉴스 리더를 사용할 필요가 없고, FTP 서버에 있는 파일에 접근하려고 FTP 클라이언트를 사용할 필요가 없다. URL은 영리하게 리소스에 접근하고 그것을 다루게 함으로써 온라인 세상을 단순화 시킨다.

URL은 당신과 브라우저에게 정보를 찾는데 필요한 모든 것을 제공하며, 당신이 원하는리소스가 어디에 위치하고 어떻게 가져오는지 정의한다.

URL 문법

대부분의 URL 스킴의 문법은 일반적으로 9개의 부분으로 나뉜다.

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

• 스킴: 리소스를 가져오려면 어떤 프로토콜을 사용하여 서버에 접근해야하는지 가리킨다.
• 사용자이름: 몇몇 스킴은 리소스에 접근을 하기 위해 사용자 이름을 필요로 한다.
• 비밀번호: 사용자의 비밀번호를 가리키며, 사용자 이름에 콜론으로 이어서 기술
• 호스트: 리소스를 호스팅하는 서버의 호스트명이나 IP 주소
• 포트: 리소스를 호스팅하는 서버가 열어놓은 포트번호
• 경로: 이전 컴포넌트와 빗금으로 구분되어있으며, 서버 내의 리소스가 어디에 있는지 가리킴.
• 파라미터: 특정 스킴들에서 입력 파라미터를 기술하는 용도로 사용. 파라미터는 이름/값을 쌍으로 가짐. 파라미터는 다른 파라미터나 경로의 일부와 세미콜론으로 구분하여 기술하며 여러개를 가질 수 있다.
• 질의: 스킴에서 애플리케이션에 파라미터를 전달하는데 쓰임
• 프래그먼트: 리소스의 조각이나 일부분을 가리킴. URL이 특정 객체를 가리킬 경우에 프래그먼트 필드는 서버에 전달되지 않는다. 이는 클라이언트에서만 사용한다. URL의 끝에서 #문자로 구분.

스킴

스킴은 주어진 리소스에 어떻게 접근하는지 알려주는 중요한 정보다.
이는 URL을 해석하는 애플리케이션이 어떤 프로토콜을 사용하여 리소스를 요청해야 하는지 알려준다.

스킴 컴포넌트는 알파벳으로 시작해야 하고 URL의 나머지 부분들과 첫 번째 ':'로 구분.
스킴명은 대소문자를 가리지 않는다.

호스트와 포트

애플리케이션이 인터넷에 있는 리소스를 찾으려면, 리소스를 호스팅하고 있는 장비와 그 장비 내에서 리소스에 접근할 수 있는 서버가 어디에 있는지 알아야한다.

URL의 호스트와 포트 컴포넌트는 그 두가지 정보를 제공한다.
호스트 컴포넌트는 접근하려고 하는 리소스를 가지고 있는 인터넷 상의 호스트 장비를 가리킴.

URL 확장

• 호스트명 확장: 호스트명 확장 기능을 지원하는 브라우저는 단순한 휴리스틱만을 사용해서 입력한 호스트 명을 전체 호스트 명으로 확장할 수 있다. 브라우저는 이런 간단한 기능을 제공하여 사용자의 시간을 절약하고 혼란을 막아준다. 하지만 호스트명에 대한 확장 기능은 프락시와 같은 다른 HTTP 애플리케이션에 문제를 발생시킬 수 있다.
• 히스토리 확장: 사용자가 URL을 입력하는 시간을 줄이고자, 브라우저가 사용하는 또 다른 기술은 과거에 사용자가 방문했던 URL의 기록을 저장해 놓는 것이다. URL을 입력하면 그 입력된 URL의 앞글자들을 포함하는 완결된 형태의 URL을 선택하게 해준다.

안전하지 않은 문자

URL은 잘 호환되도록 설계되었다. 그리고 URL은 인터넷에 있는 모든 리소스가 여러 프로토콜을 통해서 전달될 수 있도록, 각 리소스에 유일한 이름을 지을 수 있게 설계되었다. 모든 프로토콜이 데이터를 전송하기 위해서 서로 다른 장치를 가지고 있기 때문에 어떤 인터넷 프로토콜을 통해서든 안전하게 전송될 수 있도록 URL을 설계하는 것은 중요.

안전한 전송이란, 정보가 유실될 위험 없이 URL을 전송할 수 있다는 것을 의미.

컴퓨터 시스템의 기본 문자 집합은 보통 영어 중심으로 설정되어있다.
URL이 특정 이진 데이터를 포함해야하는 경우도 있는데 이런 것들을 지원하기 위해서 URL 설계자들은 URL에 이스케이프 문자열을 쓸 수 있게 했다.

URL에 있는 안전하지 않은 문자들을 표현할 수 있는 인코딩 방식이 고안되었다. 인코딩은 안전하지 않은 문자를 퍼센티지 기호(%)로 시작해, ASCII 코드로 표현하는 두개의 16진수 숫자로 이루어진 '이스케이프' 문자로 바꾼다.

애플리케이션은 정해진 방식대로 구현해야한다. 어떤 애플리케이션에 어떤 URL을 보내든지, 그 전에 클라이언트 애플리케이션에서 안전하지 않거나 제한된 문자를 변환하는 것이 좋다. 안전하지 않은 모든 문자를 인코딩하기만 하면, 다른 애플리케이션으로부터 특별한 의미를 가지는 문자를 받았을 때 혼돈할 걱정 없이 애플리케이션 간에 공유할 수 있는 URL의 원형을 유지할 수 있다.

입력받는 URL에서 어떤 문자를 인코딩해야하는지 결정하는 데는 브라우저와 같이 사용자로부터 최초로 URL을 입력받은ㄴ 애플리케이션에서 하는 것이 가장 적절하다. URL을 구성하는 각 컴포넌트마다 사용할 수 있거나 없는 문자들이 있을 것이고, 또 어떤 문자는 스킴에 ㅂ따라서 가용성이 달라지기 때문에 해당 문자들을 직접입력받는 애플리케이션이야말로 어떤 문자를 인코딩해야 하는지 결정하기에 가장 좋은 위치라는 것이다.

스킴의 바다

• http: 사용자 이름이나 비밀번호가 없다는 것을 제외하고는 일반 URL 포맷을 지키는 하이퍼 텍스트 전송 프로토콜 스킴이다. 포트값이 생략되어 있으면 기본값은 80이다.
• https: https 스킴은 http 스킴과 거의 같다. 다른 점이라고는 https는 HTTP 커넥션의 양 끝단에서 암호화하기 위해 넷스케이프에서 개발한 보안 소켓 계층(Secure Sockets Layer, SSL)을 사용한다는 것 뿐이다.
• mailto: mailto URL은 이메일 주소를 가리킨다. 이메일은 다른 스킴과는 다르게 동작하기 때문에 mailto URL은 표준 URL과는 다른 포맷을 가진다.
• ftp: 파일 전송 프로토콜 (File Transfer Protocol) URL은 FTP 서버의 디렉터리에 있는 콘텐츠 목록을 가져오는데 사용할 수 있다. FTP는 웹과 URL이 출현하기 전부터 있었다. 웹 애플리케이션은 데이터에 접근하는 용도의 스킴으로 FTP를 사용한다.
• rtsp, rtspu: RTSPU(RealTime Streaming Protocol) URL은 실시간 스트리밍 프로토콜을 통해서 읽을 수 있는 오디오 및 비디오와 같은 미디어 리소스 식별자이다.
• file: file스킴은 주어진 호스트 기기 에서 바로 접근할 수 있는 파일들을 나타냄. 각 필드도 일반적인 URL 포맷을 따른다. 만약 호스트가 생략되어 있으면, URL을 사용하고 있는 기기의 로컬 호스트가 기본값.
• telnet: 스킴은 대화형 서비스에 접근하는데 사용한다. telnet URL 자체가 객체를 가리키지는 않지만, 리소스라고 할 수 있는 대화형 애플리케이션은 이 telnet 프로토콜을 통해 접근할 수 있다.

미래

URL은 강력한 도구다. URL은 세상에 존재하는 모든 객체에 이름을 지을 수 있고, 새로운 포맷을 쉽게 추가할 수 있게 설계되었다. URL은 인터넷 프로토콜 간에 공유할 수 있는 새로운 포맷을 쉽게 추가할 수 있게 설계됐다. URL은 인터넷 프로토콜 간에 공유할 수 있는 일관된 작명 규칙을 제공한다.

하지만 URL이 완벽한 것은 아니다. URL은 주소이지 실제 이름은 아니다. 이는 URL이 특정 시점에 어떤 것이 위치한 곳을 알려준다는 것을 뜻한다. URL은 리소스를 찾는데 필요한 포트와 서버 이름을 제공한다. 이런 스킴의 단점은 리소스가 옮겨지면 URL을 더는 사용할 수 없다는 것이다. 그리고 그 시점에 기존 URL이 가리키고 있던 객체를 찾을 방법이 없어진다.

이런 문제를 예방할 수 있는 이상적인 방법은 객체의 위치와 상관없이, 그 객체를 가리키는 실제 객체의 이름을 사용하는 것이다. 사람처럼 리소스의 이름과 다른 몇가지 정보만 있으면 그것의 위치가 바뀌더라도 리소스의 위치를 찾을 수 있다.

인터넷 기술 태스크 포스(IEFT)는 한동안 고심한 끝에 URN(Unifrom Resource Names)이라는 새로운 표준 작업에 착수하였다. URN은 객체가 옮겨지더라도 (웹 서버 내에서나 웹 서버 간 모두) 항상 객체를 가리킬 수 있는 이름을 제공한다.

URL은 나름 한계를 가지고 있지만 웹 개발 커뮤니티에서 이를 가장 긴급한 사안이라고 이야기하지는 않는다.
URL은 현재는 물론 가까운 미래에도 인터넷에 있는 리소스를 명명하는 방법이 될 것이다. 그것은 어디에나 쓰일 것이고 웹이 성공하는데 있어 매우 중요한 부분임이 입증될 것이다. URL은 그것을 대체할 수 있는 작명 스킴이 나오기 전까지는 계속 사용될 것이다.

다만 URL은 그 한계를 가진 상태에서 그것을 해결할 수 있는 새로운 표준 (아마도 URN) 같은 것들이 나오고 적용될 것이다.