우리가 지금까지 말해왔던 HTTP는 정확히 무엇인가? HTTP에 대해서 정확한 정의를 내려보자.
모든것이 HTTP
모든것이 HTTP -> 현대의 네트워크 통신에서는 거의 모든것을 HTTP 프로토콜을 통해서 전송하게 된다.
HTTP 1과 2는 TCP프로토콜을 기반으로 만들어진 프로토콜이고, HTTP3는 UDP를 기반으로 만들어진 프로토콜이다. HTTP1과 2에서 성능을 향상시킨것이 HTTP3이다.
HTTP 특징
클라이언트 서버구조
무상태 프로토콜 (스테이스리스), 비연결성
HTTP 메세지
단순함, 확장 가능
HTTP는 다음과 같은 특징을 가진다. 차근차근 HTTP의 특성들을 파악해나가보자.
클라이언트 서버구조
가장 단순한 이야기이다. 우리가 잘 알고있는 클라이언트(요청) 서버(응답)으로 분리되어서 작동하는 클라이언트-서버 구조를 기반으로 작동하는 HTTP 프로토콜이다.
지금의 현대 개발자와 인터넷 사용자들에게는 이러한 개념이 너무나도 당연하지만, 과거에는 클라이언트 - 서버의 분할 개념이 명확하지 않았고 이로 인한 다양한 문제점들이 있었다. 클라이언트-서버 역할 분할의 철학은 각자의 역할과 책임을 명확하게 만든다.
서버 - 모든 데이터, 비즈니스 로직(기능) -> 효율적으로 요청에 응답하기 위해서 최적화
클라이언트 - UI(사용자 인터페이스) , 응답 -> 사용자의 편의성을 극대화
그리고 이러한 구조는 , 클라이언트와 서버의 독립적인 성장을 가능하게한다 . 서로의 역할과 책임이 명확하게 구분되어 있으니, 클라이언트 관련 기술(프론트엔드)은 어떻게 하면 사용자의 편의성을 극대화시킬지에만 집중한다. 서버 관련 기술(백엔드)은 어떻게 하면 효율적으로 데이터를 저장하고 , 처리할지에만 집중한다. 이는 각 두가지의 기술파트가 독립적으로 성장할 수 있는 환경을 제공한다.
HTTP는 Stateless(무상태) 프로토콜이다.
Stateful vs Stateless ( 상태유지 VS 무상태 )
두가지의 차이점은 다음의 두 예시를 통해서 명확하고 빠르게 이해할 수 있다. 
위의 예시만으로 판단을 하면은 상태를 유지하는 것이 고객에게 더욱 유리한 서비스를 제공할것이라고 판단할 수 있다. 그러면은 왜 HTTP는 무상태 프로토콜을 지향할까? 그건 무상태 프로토콜이 가지는 이점이 네트워크 환경상에서 서버가 클라이언트에게 서비스를 제공할때 더 크기 때문이다. 그 이유는 다음과 같다 .
왜 stateless인가.
상태유지 프로토콜은 '상태를 기본적으로 유지'해준다. 이 말은 고객이 정보를 단편적으로 보낸다라는 것을 의미한다. 고객은 점원이 변경되지 않고 자신이 데이터를 유지해준다는 사실을 알기에, 정보를 단편적으로 보낸다. 예를 들어 위의 예시에서는 ( 노트북, 2개, 신용카드) 라는 3개의 정보를 단편적으로 순서적으로 보내게 된다. 이 경우에 발생하는 문제는 바로 점원이 중간에 바뀌는 경우에 대처할 수 없다는 것이다. 위의 예시에서 고객은 클라이언트이고 , 점원은 서버이다. 만약 (노트북 , 2개) 까지 값을 저장한 서버가 갑자기 다운되버려서 다른 서버로 서비스를 시작해야한다면, 그런데 이 사실을 클라이언트가 모른다면 ? 지금까지 저장된 정보가 날라가버렸으므로 다시 단편적으로 변경된 서버하고 통신을 시도해야만한다. 이것이 상태프로토콜의 단점이다.
반대로, 무상태 프로토콜은 프로토콜의 특성상 언제나 정보를 묶어서 보낸다. (노트북, 2개, 신용카드)라는 정보를 언제나 하나로 묶어서 보내야하는것이다. 이러한 특성때문에 어떤 서버가 해당 정보를 받든지간에 똑같은 업무를 처리할 수 있다는 명확한 장점이 있다. 
stateless의 한계
물론, Stateless 역시 실무한계가 있다. 대표적인 예시가 로그인이다. 로그인한 사용자는 로그인했다는 사실을 계속 서버에 유지한채로 서비스를 제공해야하므로 상태유지로 설계해야한다. HTTP는 기본적으로 무상태이므로 상태유지를 위해서는 쿠키와 서버 세션이라는 특수한 기술을 사용하여서 상태를 유지시킨다. 상태 유지가 가지는 단점과 한계때문에 상태유지는 필요한 최소한만의 기능을 구현하는데에만 사용하는 것이 좋다.
HTTP는 비연결성 모델이다.
장점
HTTP는 기본이 연결을 유지하는 모델이다. 비연결성 모델인 이유는 연결을 유지하지 않으므로 필요한 자원이 최소화되기 때문이다. 예를 들어서 1시간동안 수천명이 서버를 이용해도 비연결성 모델은 연결이 유지하지 않은채 요청을 처리하므로 실제로 처리하는 요청은 수십개 이하로 매우 작은 경우도 있다. 이는 서버자원을 매우 효율적으로 사용하는 장점을 가지고 있다.
한계와 극복
비연결성 모델의 단점은 당연히 연결이 유지되지 않으므로, 요청이 들어올때마다 TCP/IP 연결을 새로 맺어야한다는 단점이 존재한다. 이는 3way handshake 시간이 지속적으로 추가됨을 의미한다. 웹 브라우저 상에서 사이트를 요청하면 정말로 다양한 자원(HTML, CSS, 자바스크립트, 추가 이미지)등이 함께 다운로드되게 된다. 비연결성 모델은 해당 사이트를 이용할때 매순간 다시 연결을 맺어야 하므로 자원의 다운로드에서 매우 비효율적으로 작동하게 된다. 이러한 문제점은 HTTP 지속연결 이라는 기술을 사용하여서 해결한다.
HTTP 메세지
"정말로 모든것을 HTTP로 주고 받을 수 있다."
이러한 HTTP는 요청메시지와 응답메세지의 구조가 서로 다르다.
요청과 응답의 구조
- startline :
- startline에는 요청이나 응답의 상태를 나타낸다.
- 항상 첫번째 줄에 위치한다.
- 응답에서는 status line이라고 부른다.
- HTTP headers
- 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합이다.
- body
- 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함한다.
- 요청과 응답의 유형에 따라 선택적으로 사용한다.
startline과 httpheader를 묶어서 요청이나 응답의 헤드(head)라고 이야기한다. payloda는 body라고 이야기한다.
HTTP는 Head와 Body로 구성되어있다.
요청 (Requsets)
head
- start line
- http method를 나타낸다.
- 요청 대상이나 프로토콜, 포트 , 도메인의 절대 경로는 요청 컨텍스트에 작성된다.
body
- 요청의 본문 메세지 구조의 마지막에 위치한다.
- 모든 요청에 body가 필요한것은 아니다.
- GET, HEAD, DELETE , OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않다.
응답
head
- 응답의 첫줄은 status line 이라고 부른다. staustline은 다음과 같은 내용들을 포함한다.
- 현재 프로토콜의 버전.
- 상태 코드 - 요청의 결과를 나타낸다
- 상태 텍스트 - 상태코드에 대한 설명
body
- 요청메세지에 요청한 내용들을 담고있는 본문 부분이다.
