[HTTP 완벽 가이드] URL과 리소스

은승균·2022년 7월 5일
0

HTTP 완벽 가이드 2장의 내용을 다루고 있습니다.

본 책에서는 리소스텍스트, 이미지, 동영상 같이 웹에서 사용되는 식별을 할 수 있는 모든 자원을 가리킨다.

URL과 리소스

URL(Uniform Resource Locator)은 인터넷의 리소스를 가리키는 표준이름이다. 즉, 전자정보가 어디에 있고, 어떻게 접근할 수 있는지 알려준다.
이번 2장에서는 다음의 내용을 다룬다.

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

인터넷의 리소스 탐색하기

URL은 브라우저가 정보를 찾는데 필요한 리소스의 위치를 가리킨다. 이 URL을 통해 HTTP 및 다른 프로토콜을 이용해 접근할 수 있다.
우리가 URI라고 부르는 것이 있는데, URI는 Uniform Resource Identifier의 약자로, URL은 이 URI의 부분집합이다. 다른 부분으로 URN이 존재한다.
URI는 더 일반화 된 개념의 리소스 식별자로 사용하는데, HTTP 애플리케이션은 URL을 URI의 한 부분으로 취급한다.

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

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

위의 URL이 있다고 할 때, 각 부분의 의미는 아래와 같다.

- http : URL의 스킴이다. 어떻게

스킴 : 웹 클라이언트가 리소스에 어떻게 접근하는지 알려준다.

  • www.joes-hardware.com : 서버의 위치이다. 웹 클라이언트가 리소스가 어디에 호스팅 되어있는지 알려준다. 어디에
  • /seasonal/index-fall.html: 리소스의 위치이다. 서버의 존재하는 로컬 리소스들 중에서 요청받은 리소스가 무엇인지 알려준다. 무엇을

이와 같이 URL은 애플리케이션이 리소스에 접근할 수 있는 방법을 제공해준다. 정보를 찾는데에 필요한 모든 것을 제공하며, 원하는 리소스가 어디에 위치하고 어떻게 가져오는지 정의한다.

URL 문법

URL로 인터넷 상의 모든 리소스를 찾을 수 있지만, 리소스들은 서로 다른 스킴을 통해서 접근해야 할 수도 있다. 대부분의 URL 스킴의 문법은 일반저긍로 9개의 부분으로 나뉜다.

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

사실 이 모든 부분을 가지는 URL은 거의 없다. 가장 중요한 것들 3가지는 스킴, 호스트, 경로이다.

컴포넌트설명
스킴사용 할 프로토콜, 대소문자 구문하지 않음
호스트와 포트리소스를 호스팅하고있는 장비와 장비 내에서 리소스에 접근할 수 있는 서버가 어디인지
사용자 이름과 비밀번호많은 서버가 데이터 접근 전에 사용자 이름과 비밀번호를 요구한다. ftp서버가 대표적
경로리소스가 서버 어디에 있는지 알려준다. 계층적 파일 시스템 경로와 유사
파라미터/로 나뉘어진 경로 조각은 각각 파라미터 컴포넌트를 가질 수 있다.
http://www.joes.com/hammers;sale-false/index.html;graphics=true
위와 같이 hammers와 index.html 경로조각에 각각 false값을 가진 sale과 true를 가진 graphics 파라미터를 가지고 있다.
질의 문자열
(Query String)
데이터베이스와 같은 서비스들은 요청 받을 리소스 형식의 범위를 좁히기 위해서 질문, 질의를 받을 수 있다.
http://www.joes-hardware.com/inventory-check.cgi?item=12731
물음표(?) 우측에 있는 값들이 질의 컴포넌트이다.
프래그먼트HTML과 같은 리소스 형식들은 본래의 수준보다 더 작게 나뉠 수 있다. URL은 텍스트 문서의 문장 전체를 가리키겠지만, 일부분의 문장을 가리켜 주는게 이상적이라고 할 수 있다. 프래그 먼트는 URL의 오른쪽에 # 문자에 이어서 온다.
http://www.joes-hardware.com/tools.html#drills
drills가 tools.html 문서의 특정 부분을 가리킨다.

단축 URL

상대 URL

지금까지 봐왔던 URL은 절대 URL이었다. 상대 URL은 모든 정보를 담고 있지는 않다. 상대 URL로 리소스에 접근하기 위해서는 base(기저) URL을 사용해야한다.

상대 URL 문법에 따르면, HTML 작성자는 URL에 스킴, 호스트, 다른 컴포넌트들을 모두 입력하지 않아도 된다. 상대경로를 이용하여 리소스의 위치는 알 수 있지만, 스킴이나 호스트는 모른다. 그 정보는 컴포넌트가 포함된 리소스의 base URL에서 알아낼 수 있다.

장점

리소스 집합의 위치를 바꾸어도 바뀐 base URL에 기반하여 잘 동작할 것이다. 리소스 집합 전체를 옮기면 현재 리소스로부터 다른 리소스의 위치는 상대경로를 이용하여 똑같이 알아낼 수 있기 때문이다.

URL확장

브라우저에서 URL을 입력하다보면 자동으로 URL을 확장하여 빠르게 입력하도록 도와준다. 이러한 기능이 확장이다.

호스트 명 확장

호스트명 확장을 지원하는 브라우저에서는 단순한 휴리스틱만을 사용해 확장할 수 있다. 'yahoo'를 입력하면 자동으로 'www.'과 '.com'을 붙여서 'www.yahoo.com'을 만든다. 하지만 이러한 호스트 명 확장 기능은 프락시와 같은 다른 HTTP 애플리케이션에 문제를 발생시킬 수 있다.

6장에서 계속

히스토리 확장

이름에서 알 수 있듯이 브라우저에서 과거 사용자 방문 URL 기록을 기반으로 완결된 URL 형태를 제시해준다. 프락시를 사용할 경우 URL 자동확장 기능은 다르게 동작할 수 있다고 한다.

6장에서 자세히

안전하지 않은 문자

모든 프로토콜이 URL을 사용하여 데이터를 전달될 수 있도록 설계하는 것이 매우 중요했다. 안전한 전송이란 정보가 유실될 위험 없이 URL을 전송할 수 있다는 것을 의미한다. URL은 읽기 쉽고 모든 인터넷 프로토콜로 URL이 전송될 수 있고, 출력이 되지 않거나 보이지 않는 문자로 변환하지 않도록 사용하도록 설계되어야 했다.

추후 알파벳이 아닌 다른 문자가 포함되었을 때 문제가 발생한다는 것을 알게되어 이스케이프 라는 기능을 추가하여 인코딩을 하여 전달될 수 있게 하였다.

URL 문자 집합, 인코딩

미국에서 컴퓨터가 발전했기 때문에 컴퓨터에서 사용되는 문자 집합 또한 영어 중심으로 이루어진 US-ASCII를 사용했었다. 당연히 다른 나라의 문자는 지원하지 않았고, 이진 데이터를 포함해야 하는 경우에서도 한계가 있었다.
이런 것들을 지원하기 위해 이스케이프 문자열을 쓸 수 있게 하여 특정 문자나 데이터를 인코딩할 수 있게 하였다.

이스케이프 인코딩

안전하지 않은 문자를 인코딩하여 표현되는 방식은 아래와 같다

% + ASCII 코드 16진수 숫자

문자 제한

URL 내에서 특별한 의미로 사용되는 몇몇 문자는 본래 목적이 아닌 다른 목적으로 사용될 때 인코딩해야 한다.

문자선점 및 제한
%
/
.
..
#
?
;
:
$,+
@,&,=
괄호, \, ` 등
<,>,"
0x00 ~ 0x1F, 0x7F
> 0x7F

스킴의 바다

URL에서 http, https와 같은 부분을 스킴 이라고 한다. 스킴은 리로스에 어떻게 접근하는지, 즉 어떤 프로토콜을 사용하는지 알려준다. 해당 부분에 상당히 다양한 스킴이 올 수 있다.

스킴설명
http일반적인 http 프로토콜 스킴이다. 기본적으로 80번 포트를 사용한다.
httpshttp 스킴과 거의 같지만, 커넥션 양 끝단에서 암호화하기 위한 SSL을 사용한다. 기본 포트는 443번 포트이다.
mailtomailto URL은 이메일 주소를 가리킨다. 표준 URL과는 다른 포맷을 가진다.
ftp파일 전송 프로토콜은 데이터에 접근하는 용도의 스킴으로 사용된다.
rtsp,rtspu실시간 스트리밍 프로토콜을 통해서 읽을 수 있는 오디오, 비디오와 같은 미디어 리소스 식별자이다.
file호스트 기기의 파일들을 나타낸다.
news리소스의 위치정보를 충분히 포함하지 않는 특성이 있는 스킴이다. 리소스가 어디에 있는지는 애플리케이션이 알아낸다.
telnet대화형 서비스에 접근하는데 사용되는 스킴이다.

미래

URL을 사용하면 리소스의 위치를 알 수 있어 간편하게 리소스에 접근할 수 있다. 현재 많이 사용되고 있지만 완벽한 것은 아니다. 리소스의 위치가 이동하게 되면 기존의 URL을 더이상 사용할 수 없게 된다. 이러한 점을 해결하기 위해서는 위치에 따른 식별이 아닌, 해당 리소스를 가리키는 실제 객체의 이름을 사용하는 방법이다.

그러한 방법이 URN(Uniform Resource Names) 표준을 만드는데에 착수하였다. URN을 이용하면 객체가 옮겨지더라도 항상 객체를 가리킬 수 있는 이름을 제공한다.

PURL(Persistant URL, 지시 통합 자원 지시자)를 사용하면 URL로 URN의 기능을 제공할 수 있다. 리소스 위치 중개서버를 두고 해당 리소스를 우회적으로 제공한다.

PURL -> 중개서버 -> URL

언제?

한동안 URN 방식이 사용되었었던 적이 있다고 한다. 하지만 URL을 모두 URN으로 전환하기 위해서는 상당히 많은 시간과 비용, 그리고 여러 벤더들과의 합도 필요하다. 그래서 URL이 없어지는 것이 아니라 URL을 사용하며 URL의 한계를 해결할 수 있는 새로운 표준들이 추가로 적용될 것이다.

profile
3대 500을 향해서

0개의 댓글