HTTP와 HTTP 메서드

서버와 클라이언트  사이에 데이터를 주고받을 때 HTTP 메서드를 활용하는데, HTTP가 무엇이고, 어디서 파생되었는지, 구성 요소는 무엇이 있고, 어떤 규약을 가지고 통신하는지 알아보고자 한다

---

HTTP란?

HTTP(Hyper Text Transfer Protocol)

• 하이퍼텍스트 링크를 사용하여 웹 페이지를 로드하는 데 사용되는 프로토콜
• HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜

HTTP는 HTML 문서를 주고 받기 위해 설계된 프로토콜이었다 하지만 HTTP 버전이 올라가면서 이미지나, JSON도 주고받을 수 있는데

 

최초에 HTTP가 고안된 배경은 단순한 텍스트를 일일이 찾아보는 것이 번거로워 문서를 링크로 연결할 수 있는 HTML이 개발되었고, 네트워크를 통해 이 HTML을 주고 받을 수 있도록 고안한 것이 HTTP이다

---

HTTP 특징

• Stateless한 프로토콜이다
  • 상태를 저장하지 않으므로 같은 클라이언트가 보낸 요청일지라도 이전에 보낸 요청/응답에 대해 알지 못함
  • 상태를 저장하지 않으므로 응답과 요청이 독립적이며 확장에 유연하다
• Connectionless(비연결성)
  • 요청과 응답이 독립적이며 상태를 저장하지 않기 때문에 요청이 들어오고 응답을 내주면 연결을 끊는다
  • HTTP는 데이터 통신의 신뢰성과 안정성을 보장하는 TCP 연결을 사용한다
    • TCP/IP는 연결을 유지하는 프로토콜로 TCP/IP 연결 비용이 존재한다
    • 같은 클라이언트에서 연속해서 요청을 보내면 다시 연결하는 비용의 문제가 발생하여 HTTP/1.1부터는 지속 연결을 지원하여 성능을 최적화하였다.
• 요청/응답(Request/Response) 구조로 되어있다

기본 정의만 보고는 이해하기 어렵기 때문에 좀 더 자세하게 알아보고 어떤 의미를 가지고 있는지 정리한다

---

Stateless 한 프로토콜?

HTTP는 간단한 목적으로 설계되었었다.

각 요청과 응답은 독립적으로 처리되며 웹 서버와 클라이언트 간에 최소한의 상태 정보를 유지하거나 추적할 필요가 없었다

도입부에서 언급했듯이 HTTP 버전이 올라가면서 일반 HTML 파일을 주고받기 위한 목적에서 다른 문서들을 전송할 수 있으며 성공과 ㅅ실패를 의미하는 여러 상태코드, 헤더 개념 도입 등 다양한 기능을 제공하게 되었다

뿐만 아니라 웹 서비스의 진화에 따라 다양한 요구 사항이 발생하면서 상태 유지가 필요한 경우도 생겼다

• 인증 및 세션 관리
  • 로그인, 세션 정보 추적을 위해 서버나 클라이언트에 상태를 저장해야 하는 경우
• 상태 관리
  • 클라이언트의 작업 상태를 추적하고 관리해야하는 경우
    • 온라인 쇼핑 카트의 내용을 유지
• 캐싱
  • 데이터 캐싱 및 최적화를 위해 상태 정보를 사용하는 경우
• 보안
  • 사용자 인증을 처리하기 위해 상태 정보가 필요한 경우
    • OAuth 토큰을 사용하여 인증 및 권한 부여를 관리

최신 버전의 HTTP 버전은 요구사항을 만족하는 서비스를 제공하기 위해 상태를 유지하는 메커니즘이 도입되기도 한다

하지만 무상태성은 HTTP의 핵심 원칙 중 하나이며 상태를 저장한다는 것은 보안적 취약점이 발생할 수 있기 때문에

항상 최소한의 정보만 저장하고 관리하는 방식에 대한 이슈는 오랜 이슈 중 하나이다

---

 

Connectionless?

커넥션 관리는 HTTP의 주요 주제이다

 

HTTP 통신은 요청과 응답이 이루어지면 연결을 끊는 매커니즘이었다

 

웹 서비스의 진화에 따라 HTTP 통신에서 제공하는 서비스가 많아지고, 데이터의 신뢰성과 안정성이 보장되는 TCP를 사용해야 했으며, 대규모 커넥션이 많아지는 상황에 놓였다

 

이전의 방식대로 매 요청마다 새로운 커넥션을 생성하는 비용이 웹 애플리케이션의 성능에 많은 영향을 주었다

 

HTTP/1.1에서 연결을 지속할 수 있는 두 가지 모델이 추가됨 (HTTP2에서 모델이 더 추가됨)

1. 영속적인 커넥션 모델
   • 연속적인 요청 사이에 커넥션을 유지하여 새 커넥션을 여는데 필요한 시간을 줄인다
2. HTTP 파이프라이닝
   • HTTP의 순차적 요청, 응답은 네트워크 latency로 인해 지연이 발생-> 이러한 단점을 극복하기 위해 요청의 응답을 기다리지 않고 여러 요청을 보낸 후 요청한 순서대로 응답을 받는 방식
   • 구현이 어려워 모던 브라우저에선 사용하지 않음
   • HTTP/1.1에서는 예상하기 어렵거나 분석하기 힘든 이상한 오류를 야기할 수 있음 -> HTTP/2에서 멀티플렉싱으로 대체됨
     • 멀티플렉싱에 대한 자세한 설명은 블로그 참고

---

요청/응답 구조

 

HTTP Request 구조

HTTP Request Message

• Start line
  • HTTP Request Message의 시작라인이며, 세 가지 부분으로 구성되어 있음
    • HTTP Method - GET
    • Request target - /test.html
    • HTTP Version - HTTP/1.1
• Headers
  • HTTP 헤더에는 키, 값 쌍에 저장된 텍스트 정보가 포함
  • 헤더는 모든 HTTP 요청에 포함된다
  • headers도 세 가지로 나뉠 수 있다
    • 1. 일반 헤더(General Headers):
         • 이 헤더는 요청 메시지와 응답 메시지 양쪽에 모두 적용되는 일반적인 메타 정보를 포함합니다.
         • 예시: Cache-Control, Connection, Date, Upgrade, Via 등
      2. 요청 헤더(Request Headers):
         • 이 헤더는 클라이언트가 서버에게 요청을 보낼 때 요청과 관련된 정보를 포함합니다. 요청 메시지의 목적이나 데이터 전달과 관련된 정보를 담습니다.
         • 예시: Host, User-Agent, Accept, Content-Type, Content-Length 등
      3. 본문(Entity) 헤더(Entity Headers):
         • 이 헤더는 요청 또는 응답 메시지의 실제 데이터(본문 또는 엔터티)와 관련된 정보를 제공합니다. 이 정보는 엔터티 본문의 특성을 설명하고 데이터의 길이 등을 나타냅니다.
         • 예시: Content-Type, Content-Length, Content-Encoding, Last-Modified 등
• Body
  • HTTP Request에서 전송하는 데이터를 담고 있는 부분
  • Body가 없는 request는 데이터가 없는 것
  • 주로 POST 요청에서 HTML 폼 데이터, JSON, XML 또는 다른 형식의 데이터를 전송하는 데 사용

 

Response 구조

• Status line
  • HTTP Response의 상태를 나타내는 부분
  • 세가지 부분으로 구성됨
    • HTTP version - HTTP/1.1
    • Status Code - 200
    • Status Text - OK
• Headers
  • HTTP Response의 헤더 부분은 요청의 헤더와 비슷하게 구성되어 있으며, 요청과 다른 헤더 값들도 있다
  • 예를 들어, User-Agent 대신 Server 헤더는 서버 소프트웨어 정보를 나타냄
• Body
  • HTTP Response의 본문은 요청과 마찬가지로 데이터를 포함하는 부분
  • HTML, JSON, XML, 이미지 또는 기타 형식의 리소스로 이루어짐
  • Response body가 비어있는 경우도 존재

---

HTTP 메서드

HTTP가 무엇이고, 특징과 구성요소를 알아보았다

그렇다면 그냥 HTTP Request 메시지에 데이터를 담아 보내면 서버 측에서 원하는 행동을 하고 결과를 반환해 주는 것인가?

 

Request 메시지에 'GET'과 같은 내용이 담겨 있는데 이를 HTTP Method라고 부르며

서버가 수행해야 하는 동작을 지정하여 Request를 보내는 것이다.

즉, HTTP는 요청 메서드를 정의하여, 주어진 리소스에 수행하길 원하는 행동을 나타낸다

 

HTTP 메서드에는 어떤 동작들을 지정하며 각각의 차이나 목적이 무엇인지 정리한다

 

HTTP 메서드가 가지는 주요 속성

• 안전(Safe)
  • 메서드를 호출하는 것이 서버의 상태나 데이터를 변경하지 않음을 의미
  • 서버 리소스를 읽는 작업에 해당하며 서버의 상태가 변경되지 않음
• 멱등성(Idempotent)
  • 메서드가 멱등하다는 것은 같은 요청을 여러 번 전송해도 결과가 변하지 않음을 의미
  • 리소스의 상태가 동일하게 유지됨
• 캐시 가능(Cacheable)
  • 서버 응답을 클라이언트 또는 중간 프록시(캐시)에 저장하고 재사용할 수 있음
  • 캐시 가능한 메서드의 응답은 캐시에 저장되어 동일한 요청이 있을 때 서버에 대한 추가 요청을 줄여준다

HTTP 메서드 종류

• GET
  • 특정 리소스의 표시를 요청하며 오직 데이터를 받기만 한다
  • Safe 한 메서드로 서버의 상태를 변경하지 않고 리소스를 읽는 작업
  • 동일한 GET 요청을 여러 번 보내더라도 서버의 상태나 리소스가 변경되지 않는 멱등한 메서드
  • 동일한 GET 요청에 대한 응답은 캐시에서 반환될 수 있음
• HEAD
  • GET 메서드의 요청과 동일한 응답을 요구
  • 응답 본문을 포함하지 않음 (Body)
• POST
  • 특정 리소스에 엔티티를 제출할 때 사용
    • 메시지 바디에 데이터를 담아 서버로 요청하면 서버에서 처리/생성
  • 데이터 조회 시 JSON으로 데이터를 보내야 할 때 사용하기도 함
  • 서버의 상태를 변경하고 새로운 리소스를 생성하는 데 사용되므로 Safe 하지 못하다
  • 여러 번 POST 요청을 보내면 각각 다른 결과가 나타날 수 있으므로 멱등하지 못하다
  • POST 요청은 보통 서버의 상태를 변경하므로 캐시 가능하지 못하다 
• PUT
  • 리소스를 현재 요청 payload로 대체할 때 사용
  • 리소스가 있으면 덮어쓰고 없다면 새로 생성
  • 서버에 새로운 데이터를 업데이트하거나 리소스를 생성하는 데 사용되므로 Safe 하지 못하다
  • PUT 요청은 항상 동일한 결과를 반환하므로 멱등하다
  • 리소스의 상태를 변경하므로 캐시 가능하지 못함
• PATCH
  • 리소스의 일부분만 수정하는 데 사용
  • PATCH를 지원하지 않는 경우 POST를 사용할 수 있음
  • 리소스의 일부를 수정하므로 Safe 하지 못하다
  • 여러 번 요청에 적용된 결과가 다른 결과가 나타날 수 있으므로 멱등하지 못하다
• DELETE
  • 특정 리소스를 삭제하는 데 사용
  • 서버에서 리소스를 제거하는 데 사용하므로 Safe 하지 못하다
  • 동일한 DELETE를 여러 번 요청해도 리소스가 이미 삭제되었거나 없는 상태인 경우에도 동일한 결과를 나타내 멱등하다
  • 리소스를 삭제하는 작업이므로 캐시 가능한 것이 아니다
• CONNECT
  • 목적 리소스로 식별되는 서버로의 터널을 맺는 데 사용
• OPTIONS
  • 목적 리소스의 통신을 설정
  • Preflight 요청을 통해 통신하기에 안전한 상태인지를 확인 (CORS 정책 검사 용도)
• TRACE
  • 목적 리소스의 경로를 따라 메시지 loop-back 테스트할 때 사용
  • 서버에 도달했을 때의 최종 패킷의 요청 패키 내용을 응답받을 수 있음

---

References

 

https://mangkyu.tistory.com/251

[HTTP] HTTP 메소드의 멱등성(Idempotence)과 Delete 메소드가 멱등한 이유

https://developer.mozilla.org/ko/docs/Web/HTTP/Methods

HTTP 요청 메서드 - HTTP | MDN

 

 

 

https://jaehyeon48.github.io/network/history-of-http/#http10

HTTP의 역사

https://velog.io/@wlwl99/HTTP%EC%9D%98-%ED%8A%B9%EC%A7%95

HTTP의 특징