[http 완벽 가이드] 2장 URL과 리소스

 

이 내용은 http 완변 가이드란 책을 읽고 정리한 내용입니다.

 

더 자세한 내용이 궁금하시면 책을 직접 읽어보시는 걸 추천합니다.

 

 

2장 URL과 리소스

학습목표

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

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

리소스를 찾기위해

• 사용자가 리소스를 가지기 위해 리소스의 위치를 알아야한다.
• URL이 리소스의 위치를 나타낸다.
• URL을 통해 리소스를 찾기위해 HTTP와 다른 프로토콜을 이용한다.
• 사용자 URL 입력 → 브라우저 적절한 프로토콜로 URL 서버에 메서드를 보냄

URL이란

• 통합 자원 지시자로( Unuform Resource Locaters)라는 이름을 가진다.
• URI의 부분 집합으로써 다음으로 나뉘어 진다.
  • URL - 리소스의 위치를 나타내고 위치로 리소스를 가져온다.
  • URN - 리소스의 특정 이름을 통해 리소스를 지정한다.
• URL의 형태

http://www.naver.com/index.html

→ 스킴 // 호스트(어디에)/ 경로 (무엇을 의 형태로 나타난다.

 

• URL은 모든 사람이 같은 방식으로 이름을 써서 리소스를 찾을 수 있도록, 단일 방식의 작명 규칙을 가진다.

2. URL 문법

• URL로 인터넷상의 모든 리소스를 찾을 수 있지만, 그 리소스들은 다른 스킴(HTTP,FTP,SMTP)을 통해 접근할 수 있으며,URL 문법은 스킴에 따라서 달라진다.
• 그렇다면 스킴이 다르다면 완전 다른 URL 문법일까? → 그건 아니다.
• 기본적인 형태는 URL 문법을 따른다.
• 대부분의 URL 스킴의 문법은 일반적으로 9개 부분으로 나뉜다.

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

컴포넌트	설명	기본값
스킴	리소스를 가져오려면 어떤 프로토콜을 사용하여 서버에 접근해야 하는지 가리킨다.	없음
사용자이름	몇몇 스킴은 리소스에 접근을 하기 위해 사용자 이름을 필요로 한다.	anonymous
비밀번호	사용자의 비밀번호를 가리키며, 사용자 이름에 콜론으로 이어서 기술한다.	<이메일 주소>
호스트	리소스를 호스팅하는 서버의 호스트 명이나 IP주소.	없음
포트	리소스를 호스팅하는 서버가 열어놓는 포트번호. 많은 스킴이 기본 포트를 사지고 있다(HTTP의 기본 포트는 80이다)	스킴에 따라 다름
경로	이전 컴포넌트와 빗금(/)으로 구분되어 있으며, 서버 내 리소스가 서버 어디에 있는지를 가리킨다. 경로 컴포넌트의 문법은 서버와 스킴에 따라 다르다.	없음
파라미터	특정 스킴들에서 입력 파라미터를 기술하는 용도로 사용한다. 파라미터는 이름/값을 쌍으로 가진다. 파라미터는, 다른 파라미터나 경로의 일부와 세미콜론(;)으로 구분하여 기술하며, 여러 개를 가질 수 있다.	없음
질의	스킴에서 애플리케이션(데이터 베이스, 게시판, 검색 엔진, 기타 인터넷 게이트웨이)에 파라미터를 전달하는데 쓰인다. 질의 컴포넌트를 작성하는데 쓰이는 공통 포맷은 없다. 이는 URL 의 끝에 ? 로 구분한다.	없음
프래그먼트	리소스의 조각이나 일부분을 가리키는 이름이다. URL이 특정 객체를 가리킬 경유에 프래그먼트 필드는 서버에 전달되지 않는다. 이는 클라이언트에서만 사용한다. URL 의 끝에서 #문자로 구분하다.	없음

2.1 스킴 : 사용할 프로토콜

• 리소스에 접근할 때 어떻게 접근하는지 알려준는 중요한 정보다.
• 스킴 컴포넌트는 알파벳으로 시작해야 하고 URL의 나머지 부분들과 첫 번째 “:”로 구분한다.
• 스킴명은 대소문자를 가리지 않는다.

HTTP://www.naver.com/index.html == http://www.naver.com/index.html

2.2 호스트와 포트

• 애플리캐이션이 인터넷에 있는 리소스를 찾으려면, 리소스를 호스팅하고 있는 장비와 그 장비 내에서 리소스에 접근할 수 있는 서버가 어디에 있는지 알아야 한다.
• URL의 호스트와 포트가 그 정보를 제공한다.
• 호스트 컴포넌트는 접근하려고 하는 리소스를 가지고 있는 인터넷상의 호스트 장비를 가리킨다.
  • DNS로 호스팅 서버의 IP주소를 가시성 있게 바꿔준다
  • www.naver.com == 102.34.21.3.1 이랑 같음
• 포트 컴포넌트는 서버가 열어놓은 네트워크 포트를 가리킨다. 내부적으로 TCP 프로토콜을 사용하는 HTTP는 기본 포트로 80을 사용한다.

2.3 사용자 이름과 비밀번호

 

→ FTP는 URL 입력시 사용자의 이름과 비밀번호를 요구하기에 여기에 적합한 예시이다.

• FTP처럼 사용자의 이름과 비밀번호를 요구하는 스킴을 사용할 시 사용자의 이름과 비밀번호를 입력안할시 기본값이 입력된다.
• 사용자의 이름은 anonymous이고
• 비밀번호는 브라우저마다 다르다.

2.4 경로

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

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

• HTTP URL 에서 경로 컴포넌트는 / 문자를 기준으로 경로 조각으로 나뉜다.
• 각 경로조각은 자체만의 파라미터 컴포넌트를 가질 수 있다.

2.5 파라미터

• 많은 스킴이 객체에 대한 호스트 및 경로 정보만으로는 리소스를 찾지 못한다.
• 포트, 이름과 비번 명시 외에도 많은 프로토콜이 더 많은 정보를 요구한다.
• 파라미터는 URL을 통해 서버에 리소스 정보를 요청할때 더 명확한 요청을 하게 해준다
  • 예를 들어 이미지 파일을 요청한다고 가정해보자.
  • 이미지 파일을 텍스트로 받을 시 깨짐 위험이 있기에 바이너리로 받고 싶다.
  • 이때 파라미터를 입력을 안할시 서버에서 어떻게 줄지 위험 부담이 크다.
• 이 컴포넌트는 이름/값 쌍의 리스트로 URL의 나머지 부분들과 ‘;’문자로 구분하여 URL에 기술한다.

httpL://www.joes-hardware.com/hammers;sale=false/index.html;graphics=true

• HTTP는 URL에서의 경로 컴포넌트는 경로조각으로 나눌 수 있다
• 위 URL에는 hammers와 index.html이란 두 개의 경로 조각이 있다. hammers 경로조각은 false 인 sale이라는 파라미터를 가진다. index.html 경로조각은 값이 True인 graphics란 파라미터를 가진다.

2.6 질의 문자열

• 데이터베이스 같은 서비스들은 요청받을 리소스 형식의 범위를 좁히기 위해서 질문이나 질의를 받을 수 있다.
• 다음 URL은 아이템 번호 12731의 재고가 있느니 확인하기 위해서 웹 데이터베이스 게이트웨이에 질의하는데 사용한다.

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

• ? 뒤에 있는 값들을 질의 컴포넌트라 부른다.
• 게이트웨이를 가리키는 URL의 경로 컴포넌트와 함께 전달하고 있다.
  • 게이트웨이는 다른 애플리케이션에 접근할 때 거치는 통로이다.
• 특정 문자들을 제외하고는 질의 컴포넌트 포맷에 제약사항은 없다.
• 많은 게이트웨이가 &로 나뉜 이름=값 인 쌍을 이룬다.

2.7 프래그먼트

• 본래의 리소스 형식에서 더 작게 리소스를 지칭하는 것
• #을 이용한다.

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

위 문법은 tools.html의 일부인 drills를 지칭한다.

• 하지만 프래그먼트를 사용하면 drills만 서버에 요청할까?
  • 아니다
• 서버에는 tools.html을 요청하고 브라우저는 tools.html안에 drills를 찾아 화면에 띄운다.

 

3. 단축 URL

• 웹 클라이언트는 몇몇 단축 URL을 인식하고 사용한다.
• 상대 URL은 리소스 안에 있는 리소스를 간결하게 기술한다.
• 많은 브라우저가 URL 일부분을 입력하면 나머지 부분을 자동으로 입력해주는 URL 자동 확장을 지원한다.

3.1 상대 URL

• URL 의 종류
  1. 절대 URL: 리소스의 모든 정보가 다 있다.
  2. 상대 URL : 리소스의 정보가 일부만 있다.
• 상대 URL로 리소스 접근 시 필요한 모든 정보는 기저(base)라고 하는 다른 URL을 사용한다.

http://www.joes-hardware.com/tools.html

 

• 이 html을 보면 상대 url인 ./hammers가 있다.
• 이 상대 경로를 기준으로 브라우저는 기저URL을 http://www.joes-hardware.com/tools.html
• 을 사용해서 호스트나 스킴같은 정보들을 얻는다.
• 상대 URL을 사용하면 리소스의 위치를 쉽게 변경 가능하다.
  • 변경하더라도 새로운 기저 URL에 의해 해석 되기 때문

+브라우저가 상대URL을 절대 URL로 변경하는 과정

1. 우선 기저 URL을 찾는다.
   • 리소스에 명시적으로 제공 - 예 ) HTML문서 중 태그로 명시되어있다.
   • 리소스를 포함하고있는 기저 URL - 바로 위 그림 예제와 같이 기저 URL을 포함하지 않는 리소스에 포함된 경우 해당 리소스의 URL을 기저URL로 쓸 수 있다면 쓴다.
   • 기저 URL이 없는 경우 - 없는 경우는 보통 절대 URL만으로 이루어져 있다는 뜻이다.
   • 하지만 불안전하게 깨진 URL일 수 도 있다.
2. 상대 참조 해석하기
   • 이제 브라우저는 기저 URL과 상대 URL을 컴포넌트 단위로 분해한다.
   • → 이를 URL 분해라고 한다.
   • 분해하고 나면 변환을 위해 다음 알고리즘을 사용한다.

 

3.2 URL 확장

• 우리가 URL을 입력할때 브라우저가 우리가 입력하던 주소를 자동으로 확장하는 경험이 있을 것이다. 그것을 URL 확장이라 한다.
• URL 확장의 종류
  1. 호스트 명 확장
  2. 히스토리 확장

1. 호스트명 확장
   • 호스트명 확장을 지원하는 브라우저는 단순한 휴리스틱 만을 사용해서 입력한 호스트 명을 전체 호스트명으로 확장할 수 있다.
   • 예) 주소입력란 yahoo를 입력하면 www.과 .com을 붙인다.
   • 어떤 브라우저는 yahoo라는 단어를 포함한 사이트를 찾지 못하면 확장을 포기하기전 몇 가지의 URL을 추가로 제시하는 방식을 사용한다.
   • 하지만 호스트명 확장 기능은 프락시 같은 다른 HTTP 애플리캐이션에 문제를 발생 시킬 수 있다. 이는 6장에서 해결방법이 있다.
2. 히스토리 확장
   • 브라우저가 유저가 과거에 방문했던 URL을 저장해놓는 것
   • URL의 앞글자만 입력해도 전체 URL을 보여준다

• 프락시를 사용할 경우 URL 자동확장 기능은 다르게 동작할 수 있다는 걸 유념하자 → 6장에서 다룬다.

4. 안전하지 않은 문자

• 모든 프로토콜이 데이터를 전송하기 위해서 서로 다른 장치를 가지고 있기 때문에 어떤 인터넷 프로토콜이든 안전하게 전송될 수 있도록 URL을 설계하는 것은 중요했다.
• 안전한 전송이란 정보가 유실될 위헙 없이 URL을 전송할 수 있다는 것을 의미한다.
• URL은 상대적으로 작고 일반적으로 안전한 알파벳 문자만 포함하도록 허락한다.
• 모든 프로토콜이 사용 가능하고 가독성도 있기를 바랬다.
• → 출력이 되지 않거나 보이지 않는 문자를 URL에서 사용하는 것을 금지 했다.
• 만약 이진 데이터나 일반적으로 안전한 알파벳 외의 문자도 포함하려고 할 때가 있다
• → 이스케이프 기능을 추가하여 안전하지 않은 문자를 인코딩할 수 있게 함

4.1 URL 문자 집합

• URL 문자들은 US-ASCII 문자를 사용한다.
• 하지만 US-ASCII는 아주 적은 수의 문자만을 포함한다.
• URL 설계자들은 이스케이프 문자열을 쓸 수 있게 설계해서 US-ASCII에서 금지하는 문자를 표현할 수 있게 하였다.

4.2 인코딩 쳬계

• URL에서 안전하지 않은 문자는 16진수로 변환후 % 이스케이프 문을 사용하여 %16진수 이렇게 표현한다.

4.3 문자 제한

• 다음은 안전한 문자 안에 속해있지만 예악어라 반드시 인코딩이 필요한 문자들이다.

4.4 좀 더 알아보기

• 근데 어떤 경우는 안전하지 않은 문자를 포함해도 URL 접속이 가능한 경우가 있다.
• 이는 몇몇 프로토콜은 별 문제가 되지 않기 때문이다.
  • 하지만 이는 명백한 개발자의 실수이고
  • 안전하니 않은 문자를 사용하는건 하지말아야한다.
• 이를 해결하기 가장 좋은건 모든 문자를 인코딩하는 건데 그건 비추천한다.

5. 스킴의 바다

• 유명한 스킴의 예들과 형식

6. 미래

• URL은 강력한 도구이나 가장 큰 단점이 존재한다.
• URL은 리소스의 주소를 나타낼뿐 리소스의 실제 이름은 아니다.
• 이는 리소스의 위치가 달라지면 기존 URL로는 찾을 방법이 없다는 것을 의미한다.
• 이에 인터넷 기술 테스크 포스(IEFT)는 URN이란 새로운 표준 작업에 착수하였다.
• URN은 항상 객체를 가리킬 수 있는 이름을 제공한다.
• 또 지속 통합 자원 지시자 (Persistent uniform resource locators, PURL)을 사용하면 URL에서 URN 기능을 제공할 수 있다.
• PURL은 리소스의 실제 주소를 관리하고 추적하는 리소스 위치 중개 서버를 두고, 해당 리소스를 우회적으로 제공한다.
• 클라이언트는 영구적인 URL을 요청하면 PURL은 그 URL에 맞는 리소스의 실제 URL로 연결해준다.

하지만

• URN이 좋은 방식이라곤 하나 아직 URL에서 URN로 바뀌기에는 많은 시간이 필요할 것이다.
• 실제로 web 시장은 URL 단점을 그렇게 중요하지 않게 보기 때문에 바뀌는데 오래걸릴 것이고
• URL을 대체할 것이 생기기 전까지 널리 쓰일것이다.