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, 사용성에 집중 

** 
클라이언트와 서버가 독립적으로 진화할 수 있음 

무상태 프로토콜

- 서버가 클라이언트 상태를 보존하지 않음 
- 장점 : 서버 확장성이 높음 ( 스케일아웃 )
  상태를 유지하면 서버를 바꿀 때 모든 정보를 해당 서버에 전달해야 함
  상태를 유지하지 않으면 응답 서버를 쉽게 바꿀 수 있다. (요청마다 모든 정보를 전송하기 때문)
  무한한 서버 증설 가능
  -> 상태를 유지하지 않으면 요청이 몰리거나 서버가 문제가 생겼을 때 다른 서버로 대응할 수 있게 됨 
  -> 여러 서버로 대응하여 트래픽 분산 가능 
  
- 단점 : 클라이언트가 추가 데이터 전송 
  요청을 보낼 때마다 쿠키나 토큰 정보를 보내야 함
  상태 유지는 최소한만 사용해야 함 // 세션으로 서버에서 상태 정보를 유지할 경우 서버 부담이 커짐 
  
  ** 웹 애플리케이션을 설계할 때는 최대한 무상태로 설계해야 함 

비연결성

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

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

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

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

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

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

HTTP 메시지