요청을 할때마다 connection 연결 (3way), 연결 해지 (4way)
연결을 지속한다. 지정된 시간동안 계속 Connection을 맺을 필요없다.
HTTP Keep-alive 속성!
Queue에 요청을 받아놓는다.
응답이 올때까지 기다리지 않고 바로 요청을 보낼 수 있다.
파이프라인에서 파생되는 문제
첫번째 처리가 오래걸리면 그 이후 처리까지 오래걸린다.
HTTP 2.0은 기존 HTTP를 대체하는 것이 아니라 확장한다.
성능 개선에 초점을 맞추었다.
프레임이 모여 메세지, 메세지가 모여 스트림
스트림 -> 멀티플렉싱(다중화)
다중화: 하나의 전송로에서 여러 데이터를 요청,응답하는 것
요청과 응답의 병렬처리가 가능하다.
하나의 Connection에서 데이터 요청과 응답이 가능하다.
대부분의 HTTP 전송은 수명이 짧고 폭주하는 반면 TCP는 수명이 긴 대량 데이터 전송에 최적화되어 있습니다. -> TCP를 잘~사용하게 되었다!
출처: 구글
TLS(SSL) handshake 반복할 필요없다.
그동안 SSL handshake를 계속하고 있었던거군아...
구글 say : HTTP 메시지를 독립된 프레임으로 세분화하고 이 프레임을 인터리빙한 다음, 다른 쪽에서 다시 조립하는 기능은 HTTP/2에서 가장 중요한 기능 향상입니다. 실제로, 이 기능은 모든 웹 기술에 걸쳐 수많은 성능 향상에 파급 효과를 주고 있으며, 다음과 같은 작업이 가능합니다.
프레임으로 나눈 것이 곧 Client 쪽에서 조립할 수 있는 이유이자 다중화할 수 있는 이유라고 하는데, 왜 그런걸까.. 그냥 head+body 같이 보낸다고 다중화가 안되는 이유가 있나?
기존 (HTTP 1, 1.1) : 중복되는 Header
HTTP 2.0 중복되는 Header 문제 해결
구글 say : 아직까지 나타나지 않은 값에 대해 정적 Huffman 코딩을 사용하고 또한 정적 테이블이나 동적 테이블에 이미 있는 값을 인덱스로 대체하여 각 요청의 크기를 줄일 수 있습니다.
indexing한 걸 인코딩한다는 말이 있는데 아니다!
기존에는 html 파일에 필요한 자원을 다시 요청했다.
HTTP 2.0에서는 html 파일에 필요한 자원을 서버가 push해준다.
HTTP 3.0은 QUIC + HTTP 2.0이라고 할 수 있다.
TLS 는 SSL과 똑같다.
그렇다면 QUIC은 HTTPS와 같은 보안을 무조건 지원한다는 건가??!
HTTP 3.0을 알기 위해 QUIC을 먼저 알아보자.
HTTP 1,2에서 사용한 TCP와 달리 비연결형 프로토콜 UDP를 사용한다.
이렇게 미리 connection을 맺지 않고
connection + data를 함께 보내버린다.
출처
대신 UDP의 특성인 신뢰성이 없다는 한계를 QUIC에서 보완하고 있다.
위에서 한번 연결이 되면 uuid 식별자로 식별한다.
wifi가 바뀌어도 다시 연결할 필요없다?
TLS가 기본적으로 적용되어서 보안성 향상
HTTPS보면 handshake하는 거 있던데 UDP에서는 어떻게 하는 걸까,, + CA 기관 설정 안한데랑은 통신이 안되나?
HTTP 2.0에서 TCP layer에서의 head of blocking 해결