HTTP 완벽 가이드 - 1. HTTP : 웹의 기초 2

HyeBin, Park·2021년 12월 26일
0

HTTP 완벽 가이드

목록 보기
2/3
post-thumbnail

HTTP 완벽 가이드


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) 알고리즘을 이용하여 변환해보기

책의 변환 예제
  1. 경로는 ./hammers.html. 기저 URL은 http://www.joes-hardware.com/tools.html

  2. 스킴은 비어있다. 따라서 기저 URL의 스킴을 상속 받는다.
    => 스킴 : http

  3. 적어도 한개의 컴포넌트는 비어 있지 않아 호스트와 포트 컴포넌트를 상속받는다.
    => 호스트 : www.joes-hardware.com, 포트:80

  4. 상대 URL컴포넌트와 상속받은 컴포넌트를 합치면 새로운 절대 URL을 얻을 수 있다.

2.4 URL 확장

  • 어떤 브라우저들은 URL을 입력한 다음이나 입력하는 동안 자동으로 URL을 확장한다.(자동완성느낌?)

1) 호스트 명 확장

  • 이 기능을 지원하는 브라우저는 단순한 휴리스틱만을 사용해서 입력한 호스트명을 전체 호스트명으로 확장할 수 있다.

휴리스틱 : 불충분한 시간이나 정보로 인하여 합리적인 판단을 할 수 없거나, 체계적이면서 합리적인 판단이 굳이 필요하지 않은 상황에서 사람들이 빠르게 사용할 수 있게 보다 용이하게 구성된 간편추론의 방법

  • 예를 들어 주소 입력란에 'yahoo'를 입력하면 브라우저는 자동으로 'www.' 과 '.com'을 붙여준다.
  • 'yahoo' 란 단어를 포함한 사이트를 찾지 못한 브라우저는 확장을 포기하기 전 몇가지 URL을 추가로 제시한다.
  • 사용자의 시간을 절약하고 혼란을 막아준다. 하지만 이는 HTTP 애플리케이션에 문제를 발생시킬 수도 있다.

2) 히스토리 확장

  • 과거에 사용자가 방문했던 URL의 기록을 저장해 둔다.
  • URL을 입력하면 완결된 형태의 URL들을 선택하게 해준다.
  • 예를들어 http://www.joes- 처럼 이전에 방문했던 URL의 시작 부분을 입력하면
  • 브라우저는 http://www.joes-hardware.com 을 보여주고 사용자는 이를 선택만 하면 된다.

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 스킴의 바다

0개의 댓글