[컴퓨터 네트워크] 11. Application Layer (4) : HTTP/2

HTTP/2

지난 글에서 HTTP/1 과 HTTP/1.1 에 대해서 정리했었다.

간단히 말해서 HTTP/1 은 base HTML 에 대해서도 TCP Connection을 만들고, 이 HTML 을 구성하는데 필요한 referenced object 들에 대해서도 매번 TCP connection 을 만들어서 데이터를 가져오는 방식이었다.

각 오브젝트 하나를 가져오는데 2RTT 의 시간이 필요했다.

 

HTTP/1.1 은 이를 약간 개선해서, 한번 TCP Connection 을 만들면 이 연결로 base HTML 과 referenced object 까지 한번에 가져와서 오브젝트를 가져오는 시간을 거의 반으로 줄이는 개선된 프로토콜이었다.

 

HTTP/2 는 여기에서 한 단계 더 발전한 프로토콜이다.

HTTP/2 의 목표는 multi-object HTTP 요청에 대한 응답 delay 를 1.1보다 줄이는 것이다.

 

HTTP/1.1 에서 하나의 Single TCP Connection 내에서 multiple, pipelined GET 이 가능했다.

서버는 각각의 GET 요청에 대해 FCFS (First Come First Service) 방식을 사용하여 순서대로 GET 요청에 응답을 보낸다.

 

그런데 FCFS 방식을 사용하면 중간에 사이즈가 큰 오브젝트 하나에 대한 요청이 먼저 왔을 때, 이 요청 하나를 처리하는데 시간이 오래 걸려서 뒤에 있는 작은 오브젝트들의 처리가 늦어지는 문제가 발생할 수 있다.

만약 클라이언트 A가 큰 오브젝트를 먼저 요청하고, B가 작은 오브젝트를 다음에 요청했다면, B는 자신이 요청하지 않은 큰 오브젝트 하나 때문에 자신의 response delay 가 증가하는 문제가 생긴다.

 

이런 현상을 HOL (head of line) Blocking 이라고 한다.

HOL Blocking 현상은 TCP 에서 나오는 loss recovery 도 지연시킨다.

(훼손된 패킷의 재전송, 재전송이 후순위에 밀려있으니 HOL Blocking 현상이 발생하면 훼손 패킷에 대한 재전송이 늦어진다. 또 TCP는 데이터의 순서를 지켜서 보내야 하는데 10개 패킷중 가운데 5번 패킷이 HOL 문제를 만나면 나머지 6~10 패킷도 늦게 보내지는 문제가 생긴다.)

 

 

HOL Blocking 의 예시사진이다.

O1 의 크기가 너무 커서 이 데이터 하나를 보내는데 많은 시간이 소요되었다.

이때문에 상대적으로 크기가 작은 O2 ~ O4 까지 오브젝트의 전송 시간이 모두 밀린다.

---

 

HOL Blocking 문제를 해소하고자하는 HTTP/2의 아이디어는, 바로 모든 데이터를 공평하게 1분씩 처리하는 것이다.

따라서 FCFS 를 지키기보다, 서버의 판단에 따라 필요하다면 요청을 처리하는 순서를 바꿔서 처리하거나, 클라이언트가 아직 요청을 보내지 않았지만 곧 요청할 거라고 예상되는 오브젝트를 미리 push 할 수 있도록 하는 기법을 이용한다.

 

예를 들면 클라이언트가 base HTML 을 요구했을 때, 당연히 후에 그 base HTML에 연결된 referenced object 들도 요청을 할 것이다. 따라서 이 오브젝트들을 서버가 미리 알아서 push 해줄 수 있다.

 

모든 데이터를 공평하게 1분씩 처리한다는 말은 오브젝트 크기를 '프레임' 이라는 고정된 크기로 나눠서 프레임 단위로 보내주는 아이디어로 구현한다.

이 프레임 단위로 스케줄링을 하면 HOL Blocking 을 완화할 수 있다.

 

하나의 큰 Object 1 을 프레임단위로 쪼개서 보낸다.

 

(그런데 이러면 한 가지 의문이 생긴다. 만약 O1 뒤에 아주 작은 요청이 1000개 있다고 해보자. 그러면 O1 오브젝트를 요청한 클라이언트는 원래는 10개 프레임을 보내는 정도의 딜레이를 예상했는데, 1000개 프레임을 보내는 딜레이를 감내해야 1개 오브젝트를 받게 될 수도 있을 것이다. 이런 문제는 어떻게 해결할까?)

 

---

단일 TCP 연결에 대한 HTTP/2 는 여전히 패킷 loss 복구에 대해 지연이 발생한다는 문제점을 갖고 있다.

(중간 데이터 하나가 없으면 그 뒷 데이터를 보낼 수 없다.)

그래서 이를 해결하려고 브라우저는 HTTP/2를 사용할 때도 병렬 연결을 만들게 된다.

 

하지만 이는 성능상에 문제도 있고, 기존 TCP 연결에는 보안이 취약하다는 문제도 있었다.

따라서 이를 개선하기 위해 HTTP/3 이 제시되었고, 현재는 HTTP/3 이 주로 사용된다.

(이 내용은 transport layer 에서 자세히 다룬다.)