[CS] HTTP

Hyper Text Transfer Protocol
서버와 클라이언트가 서로 데이터를 주고 받기 위해 사용되는 통신 규약

HTTP의 역사

HTTP/0.9

• 1991년
• GET 메서드만 지원
• HTTP 헤더 없음

HTTP/1.0

• 1996년
• HTTP 헤더 추가
  • 요청 헤더 : HTTP 버전이 생김
  • 응답 헤더 : 상태 코드와 content-type이 생겨 html 파일 외 다른 타입의 파일도 전송 가능
• HEAD, POST 메서드 추가
• HTTP 상태 코드 추가
• 하나의 연결당 하나의 요청을 처리하도록 설계, 성능 저하 및 서버 부하 비용이 증가하는 단점 존재

HTTP/1.1

• 1997년
• 지속 연결 기능 추가
• 파이프라이닝 기능 추가
  • 하나의 커넥션에서 응답을 기다리지 않고 연속적으로 여러 요청을 순차적으로 전송하고 그 순서에 맞춰 응답을 받아 지연 시간을 줄이는 방식
  • Head Of Line Blocking 단점 존재
    • 우선 순위로 들어온 요청의 응답 시간이 길어지면 후 순위에 있는 요청의 응답 시간도 길어짐
• PUT, OPTIONS, DELETE 등의 메서드 추가
• HTTP 쿠키 추가
• 그 외 지금까지 쓰이는 대부분의 기능이 이때 추가됨

HTTP/2.0

• 2015년
• HTTP 1.1 성능 개선 및 확장
• 메시지 전송 방식 변화 : 바이너리 프레이밍 계층 사용
• 파싱, 전송 속도 증가
• 오류 발생 가능성 저하
• 멀티플렉싱
  • 여러 개의 스트림을 사용하여 송수신하는 것
  • 특정 스트림의 패킷이 손실되어도 해당 스트림에만 영향을 미치고 나머지 다른 스트림은 정상 동작
• 헤더 압축
  • 크기가 큰 헤더를 압축하는 것
  • 허프만 코딩 압축 알고리즘을 사용하는 HPACK 압축 형식을 가짐
  • 헤더 중복값을 개선하는 효과도 있음
• 서버 푸시
  • 클라이언트의 요청 없이 서버가 바로 리소스 푸시 가능
  • html을 읽으면서 그 안에 들어 있던 css파일을 서버에서 푸시하여 클라이언트에 먼저 전송

HTTP/3.0

• 2019년 ~ ing
• UDP 기반 QUIC 프로토콜 사용
• 기존 TCP의 고질적인 지연 시간(RTT) 해결

RTT
패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간 (패킷 왕복 시간)

---

HTTP 메세지 구조

HTTP 메시지는 위에서부터 차례대로 시작 라인(Start Line), 헤더(Header), 공백 라인(Empty Line), 바디(Message Body)로 구성되어 있다.

Start Line
-------------
Header
-------------
Empty Line (Blank Line)
-------------
Message Body

공백 라인은 HTTP 메세지 값 구분을 하기 위한 라인으로, 필수 요소이며, HTTP 요청 종류에 따라 Message Body가 없을 수도 있는데 이땐 공백만 넣고 끝내면 된다.

HTTP 요청 메세지 (Request)

시작 라인 Start Line

• HTTP Method : GET, POST, PUT, DELETE 등
• URL : 요청 대상 경로 표시
• Version : 사용된 HTTP 버전

헤더 Header

• Headers : HTTP 전송에 필요한 모든 부가 정보 포함
• Host 요청하려는 서버 호스트 이름과 포트번호
• User-agent 클라이언트 프로그램 정보. 이 정보를 통해 서버는 클라이언트 프로그램(브라우저)에 맞는 최적의 데이터를 전송
• Referer 바로 직전에 머물렀던 웹 링크 주소 
• Accept 클라이언트가 처리 가능한 미디어 타입 종류 나열
• If-Modified-Since 여기에 쓰여진 시간 이후로 변경된 리소스 취득, 페이지 수정시 최신 페이지로 교체
• Authorization 인증 토큰을 서버로 보낼 때 쓰이는 Header
• Origin 서버로 Post 요청을 보낼 때 요청이 어느 주소에 시작되었는지 나타내는 값으로 요청을 보낸 주소와 받는 주소가 다르면 CORS(Cross-Origin Resource Sharing) 에러 발생
• Cookie 쿠키 값이 key-value로 표현

바디 Messgae Body

• Message Body : 실제 전송할(요청할) 데이터 (HTML 문서, 이미지, 영상, JSON 등)
• 요청 데이터가 없다면 비어있음

POST /test HTTP/1.1

Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 83
Content-Type: application/json
Host: google.com
User-Agent: HTTPie/0.9.3

{
    "test_id": "tmp_1234567",
    "order_id": "8237352"
}

HTTP 응답 메세지 (Response)

시작 라인 Start Line

• Version : 사용된 HTTP 버전
• Status Code : 클라이언트가 보낸 요청이 성공적으로 처리 되었는지 or 실패했는지 숫자 코드로 응답 (200, 404, 500 등)
• Status Message : Status Code에 대한 결과를 사람이 이해할 수 있는 글로 표현

헤더 Header

• Headers : Request와 동일, 다만 User-agent 대신 Server 헤더 사용

바디 Messgae Body

• Message Body : 전송받은 데이터

---

HTTP 메서드

클라이언트와 서버 사이에서 데이터를 전송하는 방식

종류

주로 쓰이는 메서드 5가지

• GET : 리소스(데이터) 조회
• POST : 요청 데이터 처리, 주로 데이터 생성에 사용
• PUT : 리소스를 대체(전체 변경), 해당 리소스가 없다면 생성
• PATCH : 리소스의 일부만 변경
• DELETE : 리소스 삭제

그 외 메서드 4가지

• HEAD : GET과 동일하나 메시지 부분을 제외한 상태 줄과 헤더만 조회
• OPTIONS : 대상 리소스에 대한 통신 가능 옵션을 설명(주로 CORS에서 사용)
• CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE : 대상 리소스에 대한 경로를 따라 메세지 루프백 테스트 수행

특성

안전성 (Safe)

• 호출해도 리소스 변경이 일어나지 않는 속성
• 안전의 기준은 오직 리소스 변경 가능성이며, 외적인 요소는 포함하지 않음
• GET, HEAD를 안전한 메서드라 볼 수 있음 (단순 조회만 하므로 리소스 변경X)

멱등성 (Idempotent)

• 동일한 요청을 여러번 반복해도 결과가 같음을 의미
• 멱등성은 요청의 결과를 보고 판단함
• GET, PUT, DELETE 메서드 들을 멱등성을 가지도록 구현해야함

캐시 가능 (Cacheable)

• 응답 결과를 캐시 처리하여 사용할 수 있는 속성
• GET, HEAD, POST, PATCH 메서드들이 캐시 가능 하나, Message Body의 캐시 키 복잡성 문제로 실제로는 GET, HEAD에만 사용함

---

참고:
HTTP는 무엇일까요? - 기본 핵심 요약 총정리 - Inpa Dev
[간단정리] HTTP Request/Response 구조
HTTP의 역사