HTTP1.1의 문제점
HTTP/1.1는 기본적으로 Connection당 하나의 요청을 처리하도록 설계되어있음
- HOL(Head of Line) Blocking
- HTTP1.1에서 Connection당 1개의 Request를 처리할 수 있는 비효율적인 통신 기법을 Pipelining기법으로 개선-> 서버에서 이전 Response가 완료되기 전 까지 나머지 작업들의 Latency발생
- RTT(Round Trip Time) 증가
- RTT: 클라이언트에서 서버로 Reqeust를 보내고 서버에서 처리 후 다시 돌아오기 까지의 시간(패킷 왕복 시간)
- 일반적으로 하나의 Connection에 하나의 요청을 처리하므로 3 Way Handshake가 반복적으로 일어나므로 불필요한 RTT증가와 네트워크 지연 초래
- Header 구조
- Header에 많은 Meta정보가 저장되어 있는데, 사용자가 중복된 Header값을 갖는 Request를 여러번 전송하게 될 경우 전송 데이터보다 헤더 크기가 큰 경우가 발생
HTTP2.0의 핵심
HTTP프로토콜의 성능 향상에 초점을 둔 버전
- Frame&stream
- HTTP1.0-1.1에서 전송 메시지를 Plain Text로 표현하고 헤더와 메시지를 개행으로 구별했지만, HTTP2.0에서는 바이너리 포맷으로 인코딩된 Message가 프레임에 담겨 전송됨.
- message: Request/Response 메시지에 매핑되는 프레임의 전체 시퀀스
- stream: 구성된 연결 내에서 전달되는 바이트의 양방향 흐름, 쌍방 통신이 가능
- Freame: HTTP2.0에서 통신의 최소단위. Headers Frame, Data Frame으로 매핑.
- 프레임에 담긴 요청/응답은 스트림을 통해 이동하며 하나의 커넥션위에 여러 개의 스트림이 동시에 만들어 질 수 있어 Multiple Request/Response가능
- Multiplexed Streams
- HTTP/1.1을 개선하여 하나의 커넥션에 여러 개의 스트림이 동시에 생성되어 다수의 요청/응답 처리 가능.
- 하나의 Connection으로 동시에 여러 개의 메시지를 주고받을 수 있으며 Response는 순서에 상관없이 stream으로 주고받음
- Stream Prioritization
- Client의 Request대해 리소스의 우선순위를 설정해서 필요한 리소스부터 Response하여 렌더링 속도를 개선
- Server Push
- 클라이언트가 필요로 하는 리소스에 대해 서버에서 단일 HTTP 요청 응답으로 구성 파일들을 함께 packing 하여 전송하여 전송 속도를 개선→ 트랜잭션, RTT감소, 응답속도 개선
- Header Compression
- 별도의 압축이나 인코딩 과정없이 전송되는 헤더의 사이즈를 줄이기 위해 Header table과 Huffman 인코딩 기법(HPAC압축방식)을 이용함.
피드백 사항 정리
- RTT증가 이슈가 http1.0이 아닌 http1.1의 문제점인지?
- http1.1은 keep-alive와 pipelining을 지원하는 버전인데, 지속적인 TCP세션이 유지된다고 해도 이전 response의 처리가 이루어지지 않으면 http1.0과 동일한 문제를 가짐. 네트워크 지연 발생률이 개선되지 못하기 때문에 RTT증가는 HTTP1.0과 1.1의 공통 문제점이라고 할 수 있음
- 웹 개발/ 디버깅 툴
- js를 기준으로 ide인 webstorm과 editor인 vscode가 많이 쓰임. vscode가 확장 플러그인이 다양하고 가볍기 때문에 많이 쓰이고 두 sw모두 웹 개발 시 주로 chrome으로 디버깅 함. 크롬 개발자 도구로 http2.0 패킷을 모니터링 할 수 있고 server push에 관한 내용도 명시가 되어있음. 최근 웹 디버깅 도구인 Fiddler가 http2.0을 지원함
- get method에서 body를 갖는 경우? 보낼 수 있는지?
- http1.1 프로토콜에 관해 정리 된 rfc 7231문서에서 request get method의 body는 정의 되지 않았고, body에 내용이 있을 시 요청이 거부될 수 있다고 표현됨. get메소드 uri에 명시한 자원정보가 길 때 json/xml 포맷으로 body에 표현할 수 있으나 어떤 웹 엔진이냐에 따라 요청 에러가 나거나 무시되거나, 아무런 response를 받지 못할 수도 있음
- http상위 버전과 하위 버전의 호환성&내용협상
- 서버가 클라이언트의 버전 보다 낮을 때 내용 협상에 의해 클라이언트의 버전으로 맞춤. 캐시정책 및 서버 주도 협상에서 말했듯 accept헤더필드와 vary의 인자로 클라이언트에 맞는 버전으로 협상되어 response.