1. HTTP : 웹의 기초
🚩 2장 URL과 리소스
# 들어가기전 : 인터넷을 도시라고 생각해보자
- 도시의 리소스에는 무엇이 있으며 이를 분류하기위한 표준화된 이름은 무엇일까?
- 예를 들어보자
=> 박물관, 레스토랑, 사람들의 집 ... 주소
=> 소방서, 경찰서 .... 전화번호
=> 책, 버스, 은행 계좌 ... ISBN 번호, 노선번호, 계좌번호
- 표준화된 이름에 모두가 동의하기 때문에 도시의 리소스를 모두 쉽게 공유 할 수 있다.
- 이처럼 인터넷에도 리소스의 위치를 가리키는 표준 이름이 있는데 그것이 URL 이다.
2.1 인터넷의 리소스 탐색하기
📍 URL
- 리소스의 위치를 가리키며, 이를 이용해 인터넷 상의 수십억 개의 리소스를 찾고 사용하고 공유 할 수 있다.
URL 예시
📍 URL 구조
대부분의 URL 구조
- 스킴 : http , 웹 클라이언트가 리소스에 어떻게 접근하는 지 알려줌(프로토콜)
=> 프로토콜의 종류 : mailto(메일), ftp(FTP 서버의 파일), ...
- 서버의 위치 : www.hyeb.com , 리소스가 호스팅 되어있는 위치
- 리소스의 경로 : /velog/index.html , 서버에 존재하는 로컬 리소스 중 요청 받은 리소스 위치
2.2 URL 문법
대부분의 URL 문법
- URL의 문법은 스킴에 따라서 달라진다. ※ 제일 아래의 2.7 스킴의 바다 참조
- 위 문법의 모든 컴포넌트를 가지는 URL은 거의 없다
- 가장 중요한 세가지 컴포넌트는 스킴, 호스트, 경로
1) 스킴 : 사용할 프로토콜
- 주어진 리소스에 어떻게 접근하는지 알려주는 중요한 정보
- 해석하는 애플리케이션이 어떤 프로토콜을 사용하여 리소스를 요청해야하는지 알려줌
- 알파벳으로 시작해야하며 대소문자 구분을 하지 않는다.
- ':' 문자로 구분한다.
2) 호스트와 포트
책의 호스트와 포트 예제
=> 애플리케이션이 인터넷에 있는 리소스를 찾으려면,
=> 리소스를 호스팅 하고 있는 장비와 그 장비 내에서 리소스에 접근할 수 있는 서버가 어디에 있는지 알아야 한다.
- 호스트 컴포넌트는 접근하려고하는 리소스를 가지고 있는 인터넷상의 호스트 장비를 가리킨다.
=> 호스트 컴포넌트는 호스트 명이나 IP 주소로 제공
- 포트 컴포넌트는 서버가 열어놓은 네트워크 포트를 가리킨다.
=> ex) HTTP의 기본포트는 80
3) 사용자 이름과 비밀번호
- 많은 서버가 자신이 가지고 있는 데이터에 접근을 허용하기 전에 사용자 이름과 비밀번호를 요구함
- 값이 삽입되어있지 않을 경우 기본 사용자 이름(anonymous)과 비밀 번호(브라우저마다 다름) 값을 넣어 놓음
- '@'나 ':' 로 사용자 이름과 비밀번호 컴포넌트를 분리한다.
4) 경로 : 리소스가 서버의 어디에 있는지
책의 경로 예제
- 계층적 파일 시스템 경로와 유사한 구조를 가진다.
- '/' 문자를 기준으로 경로조각을 나뉜다.
- 경로조각은 자체만의 파라미터 컴포넌트를 가질 수 있다.
5) 파라미터 : 리소스에 접근할 때 필요하다.
책의 파라미터 예제
- 애플리케이션이 서버에 정확한 요청을 하기 위해 필요한 입력 파라미터를 받는데 사용
- 이름/값 쌍의 리스트로 URL 나머지 부분들로부터 ';' 문자로 구분한다.
- 위의 예제에서 hammers 경로조각에 값이 false인 sale 이라는 파라미터를 가짐
- index.html 경로조각은 값이 graphics 란 파라미터를 가짐
6) 질의 문자열
책의 질의 문자열 예제
- 질의 컴포넌트는 게이트웨이를 가리키는 URL의 경로 컴포넌트와 함께 전달된다.
- '?' 우측에 있는 값이고 두개 이상의 경우 '&'로 나뉜다.
- 위의 예시는 item의 값이 12731 이고 color의 값이 blue인 값이 있는지 check
7) 프래그먼트 : 리소스의 특정 부분을 가리킬 수 있다.
책의 질의 프래그먼트 예제
- HTML 같은 리소스 형식들은 본래의 수준보다 더 작게 나뉠 수 있다.
- 예를 들어 한 개의 텍스트 문서의 경우, 그 리소스에 대한 URL은 텍스트 문서 전체를 가리키겠지만, 이상적으로는 리소스 안에 있는 특정 텍스트를 가리킬 수 있어야한다.
- '#' 문자 뒤에 온다.
- 위의 예에서 drills라는 프래그먼트는 www.joes-hardware.com 에 위치한 /tools.html 웹 페이지의 일부를 가리킨다.
- 일반적으로 HTTP 서버는 객체 일부가 아닌 전체만 다루기 때문에 클라이언트는 서버에 프래그먼트를 전달하지 않음
- 브라우저가 서버로부터 전체 리소스를 내려받은 후, 프래그먼트를 사용하여 리소스의 일부를 보여줌
2.3 단축 URL : 긴 URL을 짧게 만들어 주는 기술
1) 절대 URL : 리소스에 접근하는데 필요한 모든 정보를 가지고 있다.
2) 상대 URL : URL을 짧게 표기하는 방식으로 모든 정보를 담고 있지는 않다.
- 프래그먼트이거나 URL 일부이다.
- 리소스 집합(HTML페이지 같은)을 쉽게 변경할 수 있다.
- 상대 URL로 리소스에 접근하는데 필요한 모든 정보를 얻기 위해서는 기저를 사용해야한다.
- 문서 집합의 위치를 변경해도 새로운 기저 URL에 의해서 해석되어 위치를 변경해도 잘 동작한다.
# 기저 URL : 상대 URL의 기준
3) 상대 URL을 새로운 절대 URL로 변환하기
1. 기저 URL 찾기
- 리소스에서 명시적으로 제공 : 어떤 리소스들은 기저 URL을 명확하게 기술한다.
- 리소스를 포함하고 있는 기저 URL : 해당 리소스의 URL을 기저 URL로 사용한다.
- 기저 URL이 없는 경우 : 절대 URL만으로 이루어져 있다는 뜻
2. 상대 참조 해석하기
- 상대 URL과 기저 URL을 각각의 컴포넌트 조각으로 나눈다.
3. 변환을 끝내기 위해 알고리즘 사용
책의 알고리즘
- 이 알고리즘은 상대 URL을 리소스를 참조하는데 사용할 수 있는 절대 경로 형태로 변환한다.
4) 알고리즘을 이용하여 변환해보기
책의 변환 예제
-
경로는 ./hammers.html. 기저 URL은 http://www.joes-hardware.com/tools.html
-
스킴은 비어있다. 따라서 기저 URL의 스킴을 상속 받는다.
=> 스킴 : http
-
적어도 한개의 컴포넌트는 비어 있지 않아 호스트와 포트 컴포넌트를 상속받는다.
=> 호스트 : www.joes-hardware.com, 포트:80
-
상대 URL컴포넌트와 상속받은 컴포넌트를 합치면 새로운 절대 URL을 얻을 수 있다.
2.4 URL 확장
- 어떤 브라우저들은 URL을 입력한 다음이나 입력하는 동안 자동으로 URL을 확장한다.(자동완성느낌?)
1) 호스트 명 확장
- 이 기능을 지원하는 브라우저는 단순한 휴리스틱만을 사용해서 입력한 호스트명을 전체 호스트명으로 확장할 수 있다.
※ 휴리스틱 : 불충분한 시간이나 정보로 인하여 합리적인 판단을 할 수 없거나, 체계적이면서 합리적인 판단이 굳이 필요하지 않은 상황에서 사람들이 빠르게 사용할 수 있게 보다 용이하게 구성된 간편추론의 방법
- 예를 들어 주소 입력란에 'yahoo'를 입력하면 브라우저는 자동으로 'www.' 과 '.com'을 붙여준다.
- 'yahoo' 란 단어를 포함한 사이트를 찾지 못한 브라우저는 확장을 포기하기 전 몇가지 URL을 추가로 제시한다.
- 사용자의 시간을 절약하고 혼란을 막아준다. 하지만 이는 HTTP 애플리케이션에 문제를 발생시킬 수도 있다.
2) 히스토리 확장
2.5 안전하지 않은 문자
- url은 상대적으로 작고 일반적으로 안전한 알파벳 문자만 포함하도록 허락한다.
- 하지만, 안전한 알파벳 외의 문자도 포함하려 할 때가 있어 이스케이프라는 기능을 추가하였다.
- 이스케이프는 안전하지 않은 문자를 안전한 문자로 인코딩 할 수 있게 하였다.
1) URL의 문자 집합
- 역사적으로 많은 컴퓨터 애플리케이션이 US-ASCII 를 사용해왔음.
- 시간이 지나고 전세계 사람들이 사용하게 되었고, 모든 문자들을 US-ASCII가 지원하지 않는 문제점이 생김
- 이스케이프 문자열 : US-ASCII에서 사용이 금지된 문자들로, 특정 문자나 데이터를 인코딩 할 수 있게 한다.
2) 인코딩 체계
- 인코딩 : 안전하지 않은 문자를 이스케이프 문자로 바꾼다.
- 이스케이프 문자 : '%' 기호로 시작해 ASCII 코드로 표현되는 두 개의 16진수 숫자로 이루어져있다.
3) 문자 제한
- 몇몇 문자는 URL 내에서 특별한 의미로 예약 되어 있다.
- URL에서 예약된 문자들을 다른 용도로 사용하려면 그 전에 반드시 인코딩 해야한다.
2.6 좀 더 알아보기
- 애플리케이션은 정해진 방식대로 구현해야한다.
- 어떤 애플리케이션에 어떤 URL을 보내기전에 클라이언트 애플리케이션에서 안전하지 않거나 제한된 문자를 변환 하는 것이 좋다. => 인코딩하기만하면 혼동할 걱정 없이 URL의 원형을 유지 할 수 있다.
- 입력받은 URL에서 인코딩할 문자를 결정하는건 사용자로부터 최초로 URL을 입력받는 애플리케이션에서 하는 것이 적절하다.
=> 각 컴포넌트마다 사용가능여부가 다를 것이고 어떤 문자는 스킴에 따라 가용성이 달라지기 때문에
- 극단적인 방법으로는 모든 문자를 인코딩 하는 것이다. BUT, 오동작을 일으킬 수 있음
- URL을 해석하는 애플리케이션은 처리하기전에 URL을 디코드 해야한다.
2.7 스킴의 바다