Notice
Recent Posts
Recent Comments
Link
땃쥐네
[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 메시지'에 대해 학습 내역을 정리해보겠습니다.
'Study > [진행중] Http 완벽가이드' 카테고리의 다른 글
[Http 완벽 가이드] 01장: HTTP 개관 (0) | 2023.09.01 |
---|---|
[Study 002] Http 완벽가이드 (0) | 2023.09.01 |
Comments