2장 간단한 프로토콜 HTTP

nudge411·2021년 7월 21일
0
해당 내용은 그림으로 배우는 Http&Network Basic 책내용을 정리한것 입니다.

1. HTTP는 클라이언트와 서버 간에 통신을 한다.

  • HTTP 프로토콜 에서는 반드시 한쪽은 클라이언트, 다른쪽은 서버의 역할을 한다.
  • 리소스를 요구하는 쪽이 클라이언트가 되고 제공하는 쪽이 서버가 된다.

2. 리퀘스트와 리스폰스를 교환하여 성립

  • HTTP 는 클라이언트가 리퀘스트(요청, Request)가 송신되며, 그 결과가 서버로부터 리스폰트(응답, Response)로 되돌아옵니다.
  • 반드시 클라이언트측 으로부터 통신이 시작됩니다.
  • 서버는 Request 받지 않고서는, Response 를 송신하는 일은 없다.
- Resquest
GET /index.html HTTP/1.1
Host: www.google.com
  • 위에서 GET 은 서버에 요구하는 종류를 나타내며 메소드 라고 한다.
  • /index.html 는 요구대상인 리소스를 나타내는데 리퀘스트 URI 라고 한다.
  • HTTP/1.1 은 클라이언트의 기능을 식별하기 위한 HTTP 버전 이다.
  • 즉 HTTP 서버 상에 있는 /index.html 라는 리소스가 필요하다는 Request 이다.
  • Request 메세지는 메소드, URI, 프로토콜 버전, 옵션 Request 헤더필드, 엔티티 로 구성된다.
- Response
HTTP/1.1 200 OK
Date: Tue, 10 Jul 2012 06:50:15 GMT
Content-Lenght: 362
Content-Type: text/html

<html>
  • 첫줄의 HTTP/1.1 은 서버의 HTTP 버전을 나타낸다.
  • 200 OK 는 request의 처리결과를 나타내는데, 상태코드와 설명이다.
  • 다음 줄은 response 가 발생한 일시를 나타내는데 헤더필드의 일부이다.
  • 그리고 빈줄로 구분하고 그 아래를 body 라고 불리는 리소스 본체이다.
  • 기본적으로 response 는 프로토콜 버전, 상태코드, 상태코드의 설명, 옵션의 response 헤더필드, body 로 구성되어 있다.

3. HTTP는 상태를 유지하지 않는 프로토콜

  • HTTP 는 상태를 계속하여 유지하지 않는 스테이트리스(stateless) 프로토콜 이다.
  • HTTP 는 새로운 요청이 보내질때 마다 새로운 응답이 생성된다.
  • 과거의 요청이나 응답에 관련한 정보를 전혀 가지고있지 않다.
  • 이는 많은 데이터를 매우 빠르고 확실하게 처리하는 범위성(scalability) 을 확보하기 위한 설계이다.
  • 하지만 웹이 진화하면서 상태유지를 할수있는 기능이 요구 되었다.
  • 상태를 계속 유지 하고싶은 요구에 부응하기 위해서 쿠키(Cookie) 라는 기술이 도입 되었다.

4. Request URI로 리소스를 식별

  • HTTP 는 URI 를 사용하여 인터넷 상의 리소스를 지정합니다.
  • URI 덕분에 인터넷상의 어떤 장소에 있는 리소스도 호출할수 있습니다.
  • 클라이언트는 리소스를 호출할 때 마다 요청할 때 요청안에 Request URI라고 불리는 형식으로 포함해야한다.
- 모든 URI를 Request URI 에 포함
GET http://hackr.kr/index.html HTTP/1.1

- Host 헤더필드에 네트워크 로케이션 포함
GET /index.html HTTP/1.1
Host: hackr.kr
  • 서버 자신에게 요청을 송신하는 경우에는 URI에 [*]를 지정할수 있다.
OPTIONS * HTTP/1.1

5. 서버에 임무를 부여하는 HTTP 메소드

HTTP/1.1 에서 사용할수 있는 메소드에 대해 살펴보자.

  1. GET: 리소스 획득
    • 리퀘스트 URI로 식별된 리소스를 가져올수 있도록 요구
    • 리소스 내용은 지정된 리소스를 서버가 해석한 결과

  2. POST: 엔티티 전송
    • 엔티티를 전송하기 위해서 사용
    • GET 또한 엔티티를 전송할수 있지만, 일반적으로 POST 를 사용

  3. PUT: 파일 전송
    • 파일을 전송하기 위해서 사용
    • 요청에 포함된 엔티티를 리퀘스트 URI로 지정한 곳에 보존하도록 요구
    • HTTP/1.1 PUT은 인증기능이 없어 누구든지 파일업로드가 가능한 보안이슈가 있다.
    • 일반적인 웹보다는 인증 기능과 짝을 이루거나 REST 와 같이 연계하는 양식에서 사용된다.

  4. HEAD: 메세지 헤더 취득
    • GET과 같은 기능이지만 메세지 바디를 돌려주지 않는다.
    • URI 유효성과 리소스 갱신시간을 확인하는 목적 등으로 사용
    • 리스폰스 헤더만 되돌려준다.

  5. DELETE: 파일 삭제
    • 파일 삭제를위해 사용된다.
    • PUT 과 반대로 동작하며 지정된 리소스를 삭제한다.
    • 인증기능이 없어 일반적인 웹사이트 에서는 사용되지 않는다.
    • 인증기능이 포함된 웹앱 또는 REST를 사용하는 경우 사용된다.

  6. OPTIONS: 제공하고 있는 메소드의 문의
    • 지정된 리소스가 제공하고 있는 메소드를 조사하기 위해 사용

  7. TRACE: 경로 조사
    • 웹서버에 접속하여 자신에게 통신을 되돌려 받는 루프백을 발생
    • Max-forwards 헤더에 수치를 포함, 수치를 디스카운트 하여 0이 된지점의 response 를 되돌려받음
    • 해당 메소드는 보안상의 이유로 거의사용되지 않는다.

  8. CONNECT: 프록시에 터널링 요구
    • 프록시에 터널 접속확립을 요함으로, TCP 통신을 터널링 시키기위해 사용
    • 주로 SSL, TLS 등의 프로토콜로 암호화된 것을 터널링 시키기위해 사용

6. 메소드를 사용해서 지시

  • 메소드는 리소스에 어떠한 행동을 하기 원하는지를 지시하기 위해 존재
  • HTTP/1.0 과 HTTP/1.1 에서 제공하는 메소드는 상이하다.
  • 대문자와 소문자를 구변하기때문에 주로 대문자로 기재한다.
메소드설명제공하고 있는 HTTP 버전
GET리소스 취득1.0 1.1
POST엔티티 바디 전송1.0 1.1
PUT파일 전송1.0 1.1
HEAD메세지 헤더 취득1.0 1.1
DELETE파일 삭제1.0 1.1
OPTIONS서포트하고 있는 메소드 문의1.1
TRACE경로 조사1.1
CONNECT프록시에의 터널링 요구1.1
LINK리소스 간에 링크 관계를 확립1.0
UNLINK링크 관계 삭제1.0

7. 지속 연결로 접속량을 절약

  • HTTP 초기에는 통신을 할때마다 TCP에 의해 연결과 종료를 해야했다
  • 하지만 HTTP가 널리 보급되면서 이미지의 경우 여러번의 리퀘스트를 송신했는데, 매번 TCP 연결과 종료를 하게되는 불필요한 연결이 발생되어 통신량이 늘어났다.
  • 특히나 서버측에 과도한 클라이언트의 요청이 들어오면서 서버 부하가 증감했다.
  1. 지속연결
    • HTTP/1.1 과 HTTP/1.0 일부에서 TCP연결 문제를 해결하기 위해 고안되었다.
    • 지속연결의 특징은 어느 한쪽이 명시적으로 연결종료 하지않는다면 연결을 계속하여 유지한다.
    • 장점으로는 TCP 커넥션의 반복되는 연결과 종료로 인한 오버헤드를 줄여주기 때문에 서버에 대한 부하가 줄어든다.
    • 또한 오버헤드를 줄인만큼 HTTP의 요청과 응답이 빠르게 완료되기 때문에 웹페이지를 띄우는 속도가 향상되었다.
  2. 파이프라인화
    • 지속연결은 여러 요청을 보낼수 있도록 파이프라인화를 가능하게 한다.
    • 파이프라인화 이전에는 요청후에 응답을 수신 할때까지 기다려야했다.
    • 파이프라인화 이후에는 응답을 기다리지 않고 바로 다음 요청을 보낼수 있다.
    • 이로인해 여러 요청을 병렬적으로 전송하는것이 가능해졌고, 일일이 응답을 기다릴 필요가 없게되었다.

8. 쿠키를 사용한 상태관리

  • HTTP 는 stateless 프로토콜 이기 때문에 과거 요청이나 응답을 관리하지않는다.
  • 인증이 필요한 웹페이지의 경우 페이지를 이동할때마다 지속적으로 로그인 정보를 보내거나 요청마다 매개변수 또는 추가정보를 붙여 로그인 상태를 관리해야하는 문제점이 발생한다.
  • 물론 statelsee는 CPU나 메모리 같은 리소스의 소비를 억제하고, 다양한 곳에서 이용될수 있는 장점이 있다.
  • 클라이언트의 상태를 서버가 전부 관리하는것은 현실적으로 매우 힘들다.
  • 때문에 쿠키(Cookie) 시스템이 도입되었다.
  • 쿠키는 요청과 응답에 쿠키 정보를 추가하여 클라이언트의 상태를 파악하기위한 시스템이다.
  • 쿠키는 서버에서 응답으로 보내지는 Set-Cookie 라는 헤더필드에 의해 쿠키를 클라이언트에 보존하게 된다.
  • 다음번에 클라이언트가 같은 서버로 요청을 보낼 때, 자동으로 쿠키 값을 넣어 송신한다.
  • 서버는 클라이언트가 보내온 쿠키를 확인하고 어떤 클라이언트가 접속했는지 체크하고 서버상의 기록을 확인하여 이전상태를 확인할수 있다.
profile
이직을 위해 다시한번 기초부터 공부해보는 블로그

0개의 댓글