2장. 간단한 프로토콜 HTTP

• 목차

2.1 HTTP는 클라이언트와 서버간에 통신을 한다
2.2 리퀘스트와 리스폰스를 교환하여 성립
2.3 HTTP는 상태를 유지하지 않는 프로토콜
2.4 리퀘스트 URI로 리소스를 식별
2.5 서버에 임무를 부여하는 HTTP 메소드
2.6 메소드를 사용해서 지시를 내리다
2.7 지속 연결로 접속량을 절약
2.7.1 지속 연결
2.7.2 파이프라인화
2.8 쿠키를 사용한 상태 관리

HTTP의 특징

: HTTP도 인터넷 프로토콜이라 생기는 특징

• 서버-클라이언트 모델로 통신한다
  • 클라이언트 : 리소스가 필요하다고 요청하는 쪽
  • 서버 : 리소스를 제공하는쪽
    : 리소스는 텍스트, 이미지 등등 각종 데이터들
• 리퀘스트, 리스폰스 교환
  • HTTP프로토콜의 핵심은 아래와 같은데
    1. 클라->서버 : Request
    2. 서버->클라 : Response
  • 반드시 리퀘스트를 받아야 응답도 있다
  • 그럼 이 HTTP를 배운다는건 리퀘스트와 리스폰스에 어떤내용이 어떻게 포함되어있는지를 중점적으로 공부하면 Http를 쉽게 정복할 수 있다.

Message

Request(REQ, 리퀘스트)와 Response(RES, 리스폰스)메시지의 내용

• 리퀘스트와 리스폰스 메시지를 학습함으로써 HTTP 프로토콜을 이해합니다

Request(REQ)

• 대락 사진과 설명

• Request 메시지를 이루는 내용들
  • 메소드
  • 리소스 URI
  • 프로토콜 버전
  • 옵션 리퀘스트 헤더 필드
  • 엔티티

Response(RES)

대략 사진

• Response 메시지를 이루는 내용들
  • 상태코드
  • 설명
  • Date(시간정보,timestamp)
  • 헤더 필드
  • 빈 줄(CR+LF) : 바디와 헤더의 경계선
  • 엔티디
  • 이외
    • 프로토콜 버전
    • 프레이즈 : 상태 코드를 설명한
    • 헤더 필드
    • 바디 필드
  • 실제 확인해보는게 중요합니다

Stateless

HTTP는 상태를 유지하지 않는 프로토콜이라는게 어떤 의미인지 알아봅니다

• 리퀘스트와 리스폰스를 교환하는 동안에 상태를 관리하지 않습니다.
• HTTP 프로토콜 레벨에서는 이전에 보냈던 리퀘스트나, 이미 돌려준 리스폰스에 대해서 기억하지 않습니다.
• 매 새로운 리퀘스트마다 새로운 리스폰스가 있을 뿐
• 확장성(Scalability)을 위해서 , 대량의 데이터를 확실하고 빠르게 처리하기 위함.
  : 비유하자면 FP의 순수함수와 비슷한 느낌이다

Stateless 단점

• Stateless 인 HTTP만으로는 처리하기 어려운 업무가 있음
  • 세션유지 : 쇼핑몰이나 인터넷뱅킹처럼 특정 사용자마다 로그인상태를 유지할 필요가 있는 경우
  • 로그인 상태 유지를 위해 Cookie라는 기술이 도입됨(뒤에서 다룰 예정)으로써 상태관리가 가능

URI (정보 특정하기)

: 클라이언트가 >>> 서버에게 리소스를 요청할때, 정확하게 어떤 정보를 요청하는지 명시해야 하는 경우

• 클라이언트가 필요한 정보를 구체적으로 지정하는 URI를 보내는 방법은 두가지가 있는데요
  • 모든 리퀘스트를 URI에 포함하는 방법
  • HTTP메시지 헤더필드에 네트워크 로케이션을 포함하는 방법

  모든 리퀘스트를 URI에 포함하는 방법

  GET http:sdf.kr/index.html HTTP/1.1

  HTTP메시지 헤더필드에 네트워크 로케이션을 포함하는 방법

  GET /index.html HTTP/1.1
  Host : Haxkr.kr

Method (클라의 서버요청메소드)

: HTTP 요청(REQ)메시지에 임무를 부여하는 HTTP 메소드 종류에 대해 알아보겠습니다

• 메소드는 대략 아래와 같은데
  • GET
  • POST
  • PUT
  • HEAD
  • DELETE

Persistent (지속연결)

: 서버 부하를 줄이기 위한 기술 : Persistent

• 문제를 해결하기 위한 기술
  • 하나의 크고 거대한 HTML문서(사진이 많이 포함되어 있다던지)에서 F5(새로고침) 을 누르면, 매번 거대한 HTML 문서를 통째로 다운받기때문에, 클라이언트에서도 컴퓨팅 자원소모도 심하고, 서버측에도 과부하가 심하게 걸리는 문제가 있었습니다.
• 지속연결(Persistent)기술을 이용하면 아래의 특징과 장점이 있습니다
  • TCP커넥션의 연결과 종료를 반복적으로 하지 않습니다
    : 오버헤드가 줄어듭니다, (시간지연) 이는 곳 서버의 부하 경감에 도움이됩니다.
  • 줄어든 오버헤드와 서버부담만큼 클라이언트의 응답성도 개선됩니다
• 단점은 아래와 같습니다
  • HTTP/1.0 정식 사양이 아니므로 일부 페이지에서는 호환되지 않음

Pipelining (파이프라인화)

: 서버 응답속도, 효율성 개선을위한 기술

• HTTP원칙때문에, 여러번에 걸처 나눠서 리퀘스트REQ 를 보내야하는 경우
  • 보낸 클라이언트 측에서는 서버의 응답 RES가 올때까지 기다렸다가 보내고 기다렸다가 보내고 하는 시간을 줄일수 있습니다.
• 파이프라이닝(Pipelining)기술은 리퀘스드를 연속적으로 보내는 기술입니다
  • 앞에서 배운 지속연결(Persistent)에 의존성이 있습니다.
  • 여러 리스폰스RES를 서버 응답이 없어도 병행해서 보내는것이 가능해집니다.
  • 여러 리퀘스트를 병행해서 보낼수 있어 리스폰스 RES를 기다릴 필요가 없습니다
• 예를들어

HTML  한 페이지에 10개의 이미지를 포함한 웹 페이지를 리퀘스트 한 경우(내가 글 업로드를 위해 서버에 전송하는경우)
  1. 개별연결(Non-Persistent,비지속) 
  2. 지속(Persistance)연결
  3. 파이프라이닝(Pipelining) 
위 셋중에서 파이프라인이 빠릅니다. 리퀘스트 숫자에 비례해서 효과는 커집니다.  

Cookie (쿠키)

: 무상태(Stateless) 인 HTTP는 리퀘스트와 리스폰스의 상태를 기억하거나 관리하지 않습니다. 저장기능은 불가능합니다

• 쿠키는 HTTP 메시지에 추가로 "덧붙여서" state한 기능을 구현합니다.
• 쿠키가 필요한 이유 = HTTP의 특징인 Stateless
  • 장점은 서버와 클라 모두의 컴퓨팅자원과 네트워크 리소스를 아낄수 있고 HTTP를 최대한 간결하게 유지할수 있었습니다.
  • 단점은 인증이나 로그인세션등 state가 필요한 경우에 곤란한데요, 이때 쿠키가 등장합니다
• 쿠키의 특징
  • 쿠키는 서버에서 응답RES로 보내진 Set-Cookie라는 헤더필드에 의해 클라이언트측에서 보전하게 됩니다.
  • 다음 번 클라이언트가 같은 서버로 리퀘스트를 보낼 때 자동으로 쿠키값을 넣어 송수신합니다.
  • 서버는 클라이언트가 보내온 쿠키를 확인해 클라이언트를 식별하고, 서버상의 기록을 확인해서 이전상태를 알아낼수 있습니다

엔티티란?

• 아직 나도 잘 모르지만.. 내가 아는선에서 정리를 해보자면
• 개채, 실체라는 의미인데, HTTP에서는 의미있는 대상의 단위개념으로 쓰인다.
  • 그러니까 이게 100kb짜리 사진이 있는데, 이게 하나의 엔티티가 되는거고, 100kb에서 한비트를 빼면 엔티티가 아닌게 되는.. 그런거..?