HTTP

HyperText Transfer Protocol
텍스트 기반의 프로토콜
- HTTP 요청과 응답의 헤더 부분은 여전히 텍스트
- HTTP 바디 부분은 다양한 형식의 데이터를 포함할 수 있음
- HTML, TEXT, 이미지, 음성, 영상 파일, JSON, XML 등등
- **거의 모든 형태의 데이터 전송 가능**
- 클라이언터의 요청과 서버의 응답으로 구성된 방식
- 서버 간에 데이터를 주고 받을 때도 대부분 HTTP 사용

TCP - HTTP/1.1, HTTP/2
UDP - HTTP/3

HTTP 특징

1. 클라이언트 서버 구조
2. 무상태 프로토콜
3. 비연결성
4. 확장 가능 (커스텀 헤더)

클라이언트 서버 구조

- Request, Response 구조
- 클라이언트가 요청을 보내고 서버가 응답을 보내는 구조 
  서버는 비즈니스 로직, 데이터에 집중
  클라이언트는 UI, 사용성에 집중 

** 
HTTP는 **클라이언트-서버 구조(Client-Server Architecture)**를 따르는 프로토콜입니다.
클라이언트는 요청(Request)만 보내고, 서버는 요청을 처리한 뒤 응답(Response)을 반환하는 역할만 
수행합니다.이처럼 역할을 명확히 분리함으로써, 클라이언트와 서버를 독립적으로 개발하거나 
확장할 수 있는 유연성을 제공합니다.

무상태 프로토콜

- 서버가 클라이언트 상태를 보존하지 않음 
- 장점 : 서버 확장성이 높음 ( 스케일아웃 )
  상태를 유지하면 서버를 바꿀 때 모든 정보를 해당 서버에 전달해야 함
  상태를 유지하지 않으면 응답 서버를 쉽게 바꿀 수 있다. (요청마다 모든 정보를 전송하기 때문)
  무한한 서버 증설 가능
  -> 상태를 유지하지 않으면 요청이 몰리거나 서버가 문제가 생겼을 때 다른 서버로 대응할 수 있게 됨 
  -> 여러 서버로 대응하여 트래픽 분산 가능 
  
- 단점 : 클라이언트가 추가 데이터 전송 
  
**
HTTP는 무상태(Stateless) 프로토콜입니다.
즉, 이전 요청의 상태를 기억하거나 저장하지 않습니다.
이로 인해 서버는 모든 요청을 독립적으로 처리할 수 있으므로, 서버를 수평적으로 확장(Load Balancing)
하기에 유리합니다. 단점으로는, 클라이언트가 매 요청마다 필요한 상태 정보를 함께 전송해야 하므로, 
네트워크 부하가 증가할 수 있습니다.

** 웹 애플리케이션을 설계할 때는 최대한 무상태로 설계해야 함 

** 한계 ** 
요청을 보낼 때마다 쿠키나 토큰 정보를 보내야 함
전송되는 데이터가 많아진다.
상태 유지는 최소한만 사용해야 함 // 세션으로 서버에서 상태 정보를 유지할 경우 서버 부담이 커짐 

비연결성

TCP/IP는 기본적으로 연결을 유지한다. 
- 클라이언트가 수가 늘어나면 서버 부하가 커짐 

HTTP는 TCP/IP를 연결하고 응답과 요청 사이클이 끝나면 연결을 끊어버린다.
- 서버 자원을 매우 효율적으로 사용 가능 

단점 
요청을 보낼 때마다 TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가 (비효율)
이를 해결하고자 현재는 HTTP 지속 연결로 문제 해결 (Persistent Connections)

**
HTTP는 기본적으로 비연결성(Connectionless) 프로토콜입니다.
클라이언트가 HTTP 요청을 보내기 위해 먼저 TCP 3-way handshake를 통해 연결을 수립하고,
서버가 응답을 완료하면 TCP 연결을 바로 종료하는 방식입니다.
이로 인해 **소켓 자원을 효율적으로 관리할 수 있는 장점**이 있습니다.

하지만, 매 요청마다 새로운 TCP 연결을 수립(3-way handshake)해야 하기 때문에, 
지연(latency)과 오버헤드가 발생하는 단점이 있습니다.

** 현재는 HTTP 지속 연결을 사용하여 필요한 데이터를 전부 전송한 후 연결을 해제한다. 

** 최대한 스테이트리스하게 설계해야 한다.

특정 시간에 딱 맞추어 발생하는 대용량 트래픽
- 수강신청, 명절 KTX 예매, 티켓팅 등등 

최대한 스테이트리스하게 설계해야 한다. 
그래야 서버를 확 늘려서 대응할 수 있게 됨

HTTP 메시지