http2.0은 여러 파일을 한번에 병렬로 전송가능하다.
고로 http2.0은 http1.1에 비해 속도가 매우 빠르다.
http2.0 요청과 응답은 Message,Frame, Stream 3가지 단위가 사용됨
HTTP 요청을 여러개의 Frame으로 나누고, 이 Frame이 모여 요청과 응답을 하는 Message가 된다. Message는 특정 Stream에 속하고 여러개의 Stream은 하나의 Connection에 속하게 된다.
응답 프레임들은 요청 순서에 상관없이 먼저 완료된 순서대로 클라이언트에 전달 가능
HTTP2.0은 클라이언트의 요청에 대해 미래에 필요한 리소스를 미리 보낼 수 있다.
예를 들어 클라이언트로부터 HTML 문서를 요청하는 하나의 HTTP 메세지를 받은 서버는 그 HTML문서가 링크해 사용하는 이미지, css, js 파일 등의 리소스를 스스로 파악해 클라이언트에 미리 push해 브라우저의 캐시에 가져다놓음
그래서 서버는 요청하지도 않은 리소스를 미리 보내어 가까운 미래에 특정 개체가 필요할 때 바로 사용되도록 성능 향상을 이끌어 낸다. 클라이언트가 HTML 문서를 파싱해 필요한 리소스를 다시 요청하여 발생되는 트래픽과 회전지연을 줄여줌
데이터 전송 효율 높임
TCP를 이용하기 떄문에 Handshake의 Round Trip Time으로 인한 지연 시간 발생
즉 TCP 통신의 문제
TCP는 패킷이 유실되거나 오류가 있을 때 재전송한다. 재전송 과정에서 패킷의 지연 발생시 HOLB 문제가 발생. TCP/IP 4계층을 보면, 어플리케이션 계층에서 HTTP HOLB를 해결하였다 해도 전송계층에서의 TCP HOLB를 해결한건 아님
HTTP 2.0 이 헤더 필드로 어떤 문자열이든 사용할 수 있게 해준다.
그래서 이를 악용하면 HTTP 2.0 메시지를 중간의 Proxy 서버가 HTTP 1.1 메시지로 변환할 때 메시지를 불법 위조할수 있다는 위험성이 있다. 다행히 거꾸로 HTTP/1.1 메시지를 HTTP/2.0 메시지로 번역하는 과정에서는 이런 문제가 발생하지 않는다.
HTTP 2.0은 기본적으로 성능을 위해 클라이언트와 서버 사이의 커넥션을 오래 유지하는 것을 염두에 두고 있다.
하지만 이것은 개인 정보의 유출에 악용될 가능성이 있다. 이는 HTTP/1.1에서의 Keep-Alive도 가지고 있는 문제이기도 하다.
TCP를 버리고 UDP를 채택-> UDP를 개조한 QUIC 프로토콜 만듦
QUIC는 보안 세션을 설정하기 위해 한 번의 핸드셰이크만 필요함