> For the complete documentation index, see [llms.txt](https://real-dev.gitbook.io/real-library/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://real-dev.gitbook.io/real-library/backend-mastre-courese-udemy/9.-http.md).
# 9. HTTP
### HTTP Request, Response는 어떻게 생겼는가?
### HTTP 1.0과 1.1의 차이는 무엇인가?
* TCP 프로토콜 위에서 구현되었기 때문에 Hand shake 과정이 수반된다.
* 1.0 버전에선 모든 요청마다 매번 TCP 연결을 맺고, 닫았기 때문에 이로 인한 지연 시간이 많이 발생했다. 물론 HTTP/1.0 버전이 사용되던 당시가 90년대로 메모리 용량을 절약하는게 주요한 과제여서 그랬다지만, 하드웨어 성능은 지수 그래프 형태로 증가했으므로 점점 비효율적으로 변했다.
* 1.1 버전에선 Keep-alive 옵션을 통해 한번의 연결을 재사용할 수 있도록 변경되었다. 따라서 지연시간이 줄고, CPU 사용량을 절약할 수 있었다.
* 1.1에선 스트리밍과 청크 기반 전송이 가능하도록 변경되었고, 파이프라인을 구성할 수도 있게되었다. 단 파이프라인 기능은 기본적으로 비활성화되어있는데, 이유는 하나의 파이프라인으로 엮인 N개의 요청들의 응답이 순서를 보장하지 않기 때문에 HTML보다 이미지가 먼저 로드되고, 그래서 웹사이트가 정상적으로 렌더링 되지 않는 등의 문제가 발생했기 때문이다.
*
### HTTP 이전의 프로토콜은 어떤 것이 사용되었는가?
\
### HTTP/1.1은 왜 사장되었고 HTTP/2가 출시되었는가?
\
### HTTP/1.1은 여전히 사용되는가? 그렇다면 왜 아직 사용되는가?
* 여전히 사용되며, 주된 이유는 HTTP/1.1 버전을 사용하던 사이트에서 딱히 업그레이드할 필요를 못 느낀다는게… 가장 큰 이유
### HTTP2
* 당연하게도 1.1의 개선판
* HTTP1.1는 여러개의 정적 자원을 받기 위해 N개의 파이프라인을 병렬로 열고 전송 받도록 설계됨
* 2버전은 TCP 를 사용해 하나의 TCP연결을 통해 한번에 전달받고, 이 과정에서 별도의 정적 요청은 각자의 Stream으로 구분되어 처리된다. 때문에 한번의 연결을 통해 N개의 스트림을 처리할 수 있다. 스트림 간 명확한 순서는 없다.
* 때문에 거의 모든 경우에 HTTP1.1보다 빠르게 동작한다. 다만 CPU 사용량은 상대적으로 높다. 트레이드 오프인 셈
* 가장 큰 단점으로 Head line blocking이 있는데, 간단히 얘기해서 TCP 전송이라 스트림 간의 순서가 존재하는데, 이 때 선행 스트림에 문제가 발생하면 후행 스트림은 처리되지 않는 부분이다. HTTP3에선 이 부분이 개선되었다.
### HTTP3
* QUIC이라는 UDP 기반 프로토콜 위에서 만들어졌다. 때문에 Protocol 자체가 가벼워짐
* 스트림 순서 간의 연관이 없고, 결론적으로 Head line block이 발생하지 않는다.