# Single, Persistent Connection
+ 좁은 골목을 차로 지나는 것처럼 HTTP/1.1에서는 한번에 파일1개만 전달할수 있다.
+ HTTP/2 연결은 다른 요청들과 응답들을 같은 연결에서 공유하는 것을 허락하는 multiplex방식이다.
+ 멀티플랙싱 방식은 한 번에 많은 HTTP 요청을 보내고 응답을 받을수 있다.
+ HTTP/2 연결은 3가지 요소로 구성된다.
- Message - 요청이나 응답.
- Streams - 요청, 응답 채널, 동시에 양방향으로 메시지를 전달한다. 이연결은 필요한만큼 많이 가질수 있다.
- Frames - 전송을위해 메시지는 프레임으로 쪼개진다. 각각의 프레임은 메시지와 스트림을 구분하는 헤더를 가지고 있다. 그래서 다른 메시지의 프레임은 요청, 응답 스트림 내에서 서로다른 메시지 프레임과 섞일 수 있다.
+ HTTP/2 연결의 흐름도를 보면, 2개의 스트림은 각각 요청/응답 채널이 있고, 요청 응답을 병렬로 전달한다.
+ 요청과 응답은 각각 독립적이다.
+ 기존 HTTP/1.1 에서는 하나의 Connection에 여러개의 Request를 보낼 수 있었다(keep-alive)
+ 그러나 여러 개의 request를 하는 경우 이에 대해 request 에 차례에 따라 순서대로 response를 보내야하는 단점이 있다.
+ 하나의 response의 사이즈가 길거나 처리속도가 오래걸린다면, 다음 response는 순서에 의해 응답속도가 지연될 수밖에 없다.
+ 전체적인 처리속도의 저하를 일으키는 문제를 Head Of line blocking (한 라인에서 앞 대가리가 멈춤문제….?) 라고 한다.
+ 이를 위해서 HTTP/2에서는 Stream 이라는 단위로 Request, Response를 주고 받는 단위를 자르고 이를 다시 Frame 이란 단위로 잘게 잘랐다, Frame은 오고가는 데이터의 묶음이다.
# Multiplexing
+ Stream 단위의 Request, Response를 Frame 이란 단위로 잘게 자르는 방식
+ 동작방식은 아래와 같다
1) Client가 Stream을 연다. 열때는 HTTP Header정보가 들어가 있는 HEADERS frame을 날려서 헤더를 다 보냈으면 END_HEADER라는 flag를 설정해서 보낸다.
2) 그리고 POST 형식으로 Entity를 보낼 내용이 있다면 DATA frame으로 추가적으로 날리고 END_STREAM flag를 체크하여 Request 를 종료한다. 만약 보낼 데이터가 없었다면 마지막 HEADERS frame에 END_HEADERS와 END_STREAM을 둘 다 설정해서 보냈을 것이다.
3) END_STREAM으로 인해서 half-closed상태가 되고 이제는 client는 더 이상 이 스트림에 데이터를 보낼 수 없다. Server가 응답할 차례이기 때문에..
4) Server는 HEADERS frame을 통해서 response header를 보내게된다. 그리고 response stream을 다 보냈다면 client와 마찬가지로 END_HEADER를 설정해서 보낼것이다.
5) Server는 DATA frame을 통해서 요청에 대한 응답 내용을(html이나 json이나 뭐던간에) 보낼 것이다. 그리고 client와 마찬가지로 끝나면 END_STREAM을 설정할테고 만약 보낼 데이터가 없었다면 END_STREAM을 마지막 HEADERS frame 에 설정해서 보냈을 것이다.
6) 이렇게 stream이 하나가 닫힌다
+ send를 할 때는 위의 내용을 frame 단위로 보낸 그러면 한번에 client 는 서로 다른 request를 나타내는 stream의 frame 이 섞여서 보낼것이고, 받는쪽인 server에서는 이를 stream 별로 정리하여 해석하고 다시 그에 대한 응답은 먼저 준비되는 순서대로 보낼 수 있는 것이다.
+ 이로 인해 하나의 request가 처리가 오래걸려도 다른 request에는 문제가 없이 처리되어 response 를 받을 수 있게 되는 것이다.
