HTTP

• (OSI 7 Layer / TCP/IP 4 Layer) Application Layer에서 사용하는 프로토콜.
• 클라이언트와 서버가 통신하는 일종의 통신 패러다임.
• 응용 계층에서 만든 데이터를 어떤 형태로 서버에 전송할지 명시하는 역할.(request-response)
• 현재는 주로 HTTP2.0 버전이 사용됨.

HTTP 0.9 (GET)

버전을 구분하다보니 태초의 http를 이렇게 0.9 버전으로 분류하는 것 같은데, 이 때는 통신에 성공했는지 실패했는지를 파악할 수 있는 상태 코드도 없고 서버에서 클라이언트로 던져줄 수 있는 데이터의 형태는 오직 html 문서만 허락됐다… 이후 버전에 등장하는 http header가 없기 때문에 제약이 많지만 심플한 형태의 HTTP라고 할 수 있다.

HTTP 1.0 (GET)

이제 http 응답 전송 시 상태 코드를 포함해서 response 할 수 있게 되었다. 그리고 요청 헤더에 Content-Type을 명시할 수 있어 html 문서 뿐만 아니라 여러 타입의 데이터를 주고 받을 수 있게 되었다.

HTTP 1.1 (GET, POST, PUT, DELETE)

이전에는 get method만 사용해 서버에 데이터를 요청할 수 있었지만 1.1 버전부터는 서버에 요청하는 메소드가 다양해짐으로써 crud의 형태를 갖췄다고 볼 수 있을 것 같다.

1.1에서 눈여겨 볼 점은 ‘파이프라이닝(pipelining)’이라는 것인데, 기존 http 통신의 경우 여러 개의 요청이 있을 때 그 요청이 순차적으로 처리되도록 앞 순서의 요청이 처리될 때까지 뒤의 요청들은 기다린다.(network latency 증가)

이를 해결하기 위해 앞 순서의 request가 다 종료되지 않아도 뒷 순서의 request를 요청해서 지연 정도를 줄이는 방법이 http 파이프라이닝이다.

기본적으로 http는 tcp 전송 방식을 택하기 때문에 기존 방식의 경우 클라이언트와 서버가 커넥션을 맺고 끝는 것까지 다 기다렸다가 다음 요청을 하는 방식에서 각각의 request를 tcp/ip packet으로 쪼개 응답을 기다리지 않고 먼저 요청한 다음 순서대로 응답을 받는 방식으로 tcp 통신의 장점인 순서 보장을 유지한다.

즉 하나의 커넥션으로 여러 개의 request와 response를 처리한다는 점에서 지연 정도를 어느 정도 줄일 수 있는 것이다.

그러나 여전히 앞 순서의 request의 응답 속도가 늦을 경우 뒷 순서의 요청 응답을 받지 못하고 기다려야 하는 병목 현상은 해결되지 않았다고 볼 수 있다. (Head of Line Blocking)

HTTP 2.0 (Multiplexing)

HTTP 2.0이 1.1보다 속도가 빠르다는 건 알고 있었지만 왜인지 정확한 이유를 알 지 못했는데

1. HTTP Header를 압축 : 이전 헤더 정보를 해시 테이블에 저장한 뒤 이후 request에 동일한 헤더 내용이 있는 경우 색인 번호만 적어 header 크기를 상당히 줄임.
2. Server Push 기능 : 클라이언트 측에서 이미지,css와 같이 html 파싱 후에 필요하다고 알 수 있는 리소스를 클라이언트가 파악에서 재요청하기 전에 서버에서 알아서 먼저 html과 같이 전송

앞서 1.1에서 발생한 tcp의 장점이자 병목현상을 유발할 수 밖에 없는 “순서 보장” 부분을 과감하게(?) 버리고 멀티플렉싱 기법을 도입했다고 할 수 있다. 이제 하나의 connection 내의 request들은 앞 순서의 request의 response를 기다리지 않고 응답이 빨리 오는 것을 먼저 받는다. connection 내에 여러 개의 스트림을 만들어 각각의 요청을 독립적으로 처리할 수 있게 된 것이다. 또한 스트림의 경우 우선 순위를 매개 중요한 리소스 전달이 지연되지 않도록 할 수 있다.