이번 글은 imagekit 공식 사이트에서 HTTP/2 vs HTTP/1 – Performance Comparison 문서와
HTTP/1.1 vs HTTP/2: What’s the Difference 문서를 번역/편집하여 작성 하였습니다.”
참고자료 :
1. HTTP1.1, HTTP2
1.1 소개
하이퍼텍스트 전송 프로토콜(HTTP)은 1989년 발명된 이후로 월드와이드웹(World Wide Web)에서 사실상의 통신 표준이 된 응용 프로토콜입니다.
1997년 HTTP/1.1 릴리스부터 최근까지 사용된 프로토콜 입니다.
그러나 2015년에는 특히 모바일 플랫폼과 서버 집약적인 그래픽 및 비디오를 처리할 때 대기 시간을 줄이는 여러 방법을 제공하는 HTTP/2라는 새로운 버전이 사용되었습니다.
HTTP/2는 그 이후로 점점 대중화되어 전 세계 웹사이트의 약 1/3이 HTTP/2를 지원하는 것으로 추정됩니다.
1.2 배경
HTTP/2가 HTTP/1.1에 대해 수행한 특정 변경 사항을 컨텍스트화하기 위해 먼저 각각의 역사적 개발 및 기본 작동을 개략적으로 살펴보겠습니다.
HTTP/1.1
- 1989년 Timothy Berners-Lee가 World Wide Web의 통신 표준으로 개발한 HTTP는 클라이언트 컴퓨터와 로컬 또는 원격 웹 서버 간에 정보를 교환하는 최상위 응용 프로그램 프로토콜.
- 이 과정에서 클라이언트는 또는 와 같은 메서드 를 호출하여 서버에 텍스트 기반 요청을 보냄 .
- 이에 대한 응답으로 서버는 HTML 페이지와 같은 리소스를 클라이언트에 다시 보냄.
- 요청 및 응답 교환을 인터넷 프로토콜 스택의 단일 응용 프로그램 계층 으로 생각할 수 있음.
- 이 계층은 전송 계층 (일반적으로 전송 제어 프로토콜 또는 TCP 사용)과 네트워킹 계층 (인터넷 프로토콜 또는 IP 사용 ) 위에 있음.
HTTP/2
- HTTP/2는 압축, 다중화 및 우선 순위 지정과 같은 기술을 사용하여 웹 페이지 로드 대기 시간을 줄이기 위해 주로 Google에서 개발한 SPDY 프로토콜로 시작되었음.
- 이 프로토콜은 IETF(Internet Engineering Task Force) 의 하이퍼텍스트 전송 프로토콜 작업 그룹 httpbis가 표준을 구성할 때 HTTP/2의 템플릿으로 사용되어 2015년 5월 HTTP/2의 출판으로 절정에 달했음.
- 처음부터 Chrome, Opera, Internet Explorer 및 Safari를 포함한 많은 브라우저가 표준화 작업을 지원.
- 부분적으로는 이 브라우저 지원으로 인해 2015년부터 프로토콜의 상당한 채택률이 있었으며 특히 새로운 사이트의 채택률이 높음.
- 기술적인 관점에서 HTTP/1.1과 HTTP/2를 구별하는 가장 중요한 기능 중 하나는 인터넷 프로토콜 스택의 응용 프로그램 계층의 일부로 생각할 수 있는 바이너리 프레이밍 계층.
- 모든 요청과 응답을 일반 텍스트 형식으로 유지하는 HTTP/1.1과 달리 HTTP/2는 바이너리 프레이밍 계층을 사용하여 모든 메시지를 바이너리 형식으로 캡슐화하는 동시에 동사, 메서드 및 헤더와 같은 HTTP 의미 체계를 유지.
- 애플리케이션 수준 API는 여전히 기존 HTTP 형식으로 메시지를 생성하지만 기본 계층은 이러한 메시지를 바이너리로 변환.
- HTTP/2 이전에 생성된 웹 응용 프로그램이 새 프로토콜과 상호 작용할 때 정상적으로 계속 작동.
- 메시지를 바이너리로 변환하면 HTTP/2가 HTTP/1.1에서 사용할 수 없는 데이터 전달에 대한 새로운 접근 방식을 시도할 수 있음.
- 이는 두 프로토콜 간의 실질적인 차이점의 근원이 되는 대조임.
1.3 전달 모델
- HTTP/1.1과 HTTP/2는 의미 체계를 공유하여 두 프로토콜의 서버와 클라이언트 사이를 이동하는 요청과 응답이 및 와 같은 친숙한 방법을 사용하여 헤더와 본문이 있는 전통적인 형식의 메시지로 목적지에 도달.
- 그러나 HTTP/1.1이 이를 일반 텍스트 메시지로 전송하는 동안 HTTP/2는 이를 바이너리로 인코딩하여 상당히 다른 전달 모델 가능성을 허용.
HTTP/1.1 — 파이프라인 및 헤드 오브 라인 차단
- 클라이언트가 HTTP 요청에 대해 받는 첫 번째 응답은 종종 완전히 렌더링된 페이지가 아닙니다. 대신 요청된 페이지에 필요한 추가 리소스에 대한 링크가 포함되어 있음.
- 클라이언트는 페이지를 다운로드한 후에만 페이지의 전체 렌더링에 서버에서 이러한 추가 리소스가 필요하다는 것을 발견.
- 이 때문에 클라이언트는 이러한 리소스를 검색하기 위해 추가 요청을 해야 함.
- HTTP/1.0에서 클라이언트는 새로운 요청이 있을 때마다 TCP 연결을 끊고 다시 만들어야 했으며, 이는 시간과 리소스 측면에서 많은 비용이 드는 일.
- HTTP/1.1은 지속적인 연결과 파이프라이닝을 도입하여 이 문제를 처리.
- 지속적인 연결을 사용하면 HTTP/1.1은 TCP 연결을 닫으라고 직접 지시하지 않는 한 계속 열려 있어야 한다고 가정.
- 이를 통해 클라이언트는 각각에 대한 응답을 기다리지 않고 동일한 연결을 따라 여러 요청을 보낼 수 있으므로 HTTP/1.0보다 HTTP/1.1의 성능이 크게 향상.
- 불행히도 이 최적화 전략에는 자연스러운 병목 현상이 있음.
- 여러 데이터 패킷이 동일한 대상으로 이동할 때 서로 전달할 수 없기 때문에 필요한 리소스를 검색할 수 없는 대기열의 선두에 있는 요청이 뒤에 있는 모든 요청을 차단하는 상황이 있음.
- 이것을 HOL(head-of-line) 차단 이라고 하며 HTTP/1.1에서 연결 효율성을 최적화하는 데 중요한 문제.
- 별도의 병렬 TCP 연결을 추가하면 이 문제를 완화할 수 있지만 클라이언트와 서버 간에 가능한 동시 TCP 연결 수에는 제한이 있으며 각각의 새 연결에는 상당한 리소스가 필요.
- 이러한 문제를 해결하기 위해 앞서 언급한 바이너리 프레이밍 계층을 사용하도록 제안한 HTTP/2 가 개발.
HTTP/2 — 바이너리 프레이밍 레이어의 장점
- HTTP/2에서 이진 프레이밍 계층은 요청/응답을 인코딩하고 더 작은 정보 패킷으로 잘라 데이터 전송의 유연성을 크게 높임.
- HOL 차단의 영향을 줄이기 위해 여러 TCP 연결을 사용해야 하는 HTTP/1.1과 달리 HTTP/2는 두 시스템 간에 단일 연결 개체를 설정.
- 이 연결에는 여러 데이터 스트림 이 있음.
- 각 스트림은 친숙한 요청/응답 형식의 여러 메시지로 구성.
- 마지막으로 이러한 각 메시지는 프레임 이라는 더 작은 단위로 나뉨.
- 가장 세분화된 수준에서 통신 채널은 이진 인코딩된 프레임 묶음으로 구성되며 각각 특정 스트림에 태그가 지정.
- 식별 태그를 사용하면 연결이 전송 중에 이러한 프레임을 인터리브하고 다른 쪽 끝에서 재조립할 수 있음.
- 인터리브 처리된 요청과 응답은 그 뒤에 있는 메시지를 차단하지 않고 병렬로 실행할 수 있음.
- 이 프로세스를 멀티플렉싱 이라고 함 .
- 멀티플렉싱은 메시지가 다른 메시지가 완료될 때까지 기다릴 필요가 없도록 하여 HTTP/1.1의 헤드라인 차단 문제를 해결.
- 이것은 서버와 클라이언트가 동시 요청과 응답을 보낼 수 있음을 의미하므로 더 큰 제어와 더 효율적인 연결 관리가 가능.
- 멀티플렉싱을 통해 클라이언트는 여러 스트림을 병렬로 구성할 수 있으므로 이러한 스트림은 단일 TCP 연결만 사용.
- 오리진당 단일 영구 연결을 갖는 것은 네트워크 전체에서 메모리 및 처리 공간을 줄여 HTTP/1.1을 향상시키고, 그 결과 네트워크 및 대역폭 활용도가 향상되어 전체 운영 비용이 절감.
- 단일 TCP 연결은 또한 클라이언트와 서버가 여러 요청/응답에 대해 동일한 보안 세션을 재사용할 수 있으므로 HTTPS 프로토콜의 성능을 향상.
- HTTPS에서 TLS 또는 SSL 핸드셰이크 동안 양 당사자는 세션 전체에서 단일 키 사용에 동의.
- 연결이 끊어지면 새 세션이 시작되며 추가 통신을 위해 새로 생성된 키가 필요.
- 따라서 단일 연결을 유지 관리하면 HTTPS 성능에 필요한 리소스를 크게 줄일 수 있음.
- HTTP/2 사양에서 TLS 계층을 반드시 사용해야 하는 것은 아니지만 많은 주요 브라우저에서 HTTPS가 있는 HTTP/2만 지원.
- 바이너리 프레이밍 계층에 내재된 멀티플렉싱이 HTTP/1.1의 특정 문제를 해결하지만 동일한 리소스를 기다리는 여러 스트림은 여전히 성능 문제를 일으킬 수 있음.
HTTP/2 — 스트림 우선 순위 지정
- 스트림 우선 순위 지정은 동일한 리소스에 대해 경쟁하는 요청의 가능한 문제를 해결할 뿐만 아니라 개발자가 요청의 상대적 가중치를 사용자 지정하여 애플리케이션 성능을 더 잘 최적화할 수 있도록 함.
- 아시다시피 이진 프레이밍 계층은 메시지를 병렬 데이터 스트림으로 구성.
- 클라이언트가 서버에 동시 요청을 보낼 때 각 스트림에 1에서 256 사이의 가중치를 할당하여 요청하는 응답의 우선 순위를 지정할 수 있음.
- 숫자가 높을수록 우선 순위가 높음.
- 이 외에도 클라이언트는 종속된 스트림의 ID를 지정하여 다른 스트림에 대한 각 스트림의 종속성을 명시.
- 부모 식별자가 생략되면 스트림은 루트 스트림에 종속된 것으로 간주.
- 그림에서 채널에는 각각 고유한 ID가 있고 특정 가중치와 연결된 6개의 스트림.
- 스트림 1에는 연결된 상위 ID가 없으며 기본적으로 루트 노드와 연결.
- 다른 모든 스트림에는 일부 상위 ID가 표시.
- 각 스트림에 대한 리소스 할당은 보유하는 가중치와 필요한 종속성을 기반으로 함.
- 예를 들어 그림에서 동일한 가중치와 동일한 상위 스트림이 할당된 스트림 5 및 6은 리소스 할당에 대해 동일한 우선순위를 갖음.
- 서버는 이 정보를 사용하여 서버가 요청이 데이터를 검색하는 순서를 결정할 수 있도록 하는 종속성 트리를 만듬.
이전 그림의 스트림을 기반으로 종속성 트리
- 이 종속성 트리에서 스트림 1은 루트 스트림에 종속되고 루트에서 파생된 다른 스트림이 없으므로 사용 가능한 모든 리소스가 다른 스트림보다 먼저 스트림 1에 할당.
- 트리는 스트림 2가 스트림 1의 완료에 의존함을 나타내므로 스트림 2는 스트림 1 작업이 완료될 때까지 진행되지 않음.
- 스트림 3과 4를 살펴보면 이 두 스트림은 모두 스트림 2에 의존.
- 스트림 1의 경우와 같이 스트림 2는 스트림 3과 4보다 먼저 사용 가능한 모든 리소스를 얻음.
- 스트림 2가 작업을 완료한 후 스트림 3과 4는 자원을 얻음.
- 이들은 가중치로 표시된 대로 2:4의 비율로 분할되어 스트림 4에 대한 리소스 청크가 더 높아짐.
- 마지막으로 스트림 3이 완료되면 스트림 5와 6은 사용 가능한 리소스를 동일한 부분으로 가져옴.
- 이는 스트림 4가 더 많은 리소스를 수신하더라도 스트림 4가 작업을 완료하기 전에 발생할 수 있음.
- 하위 수준의 스트림은 상위 수준의 종속 스트림이 완료되자마자 시작할 수 있음.
- 애플리케이션 개발자는 필요에 따라 요청에 가중치를 설정할 수 있음.
- 예를 들어, 웹 페이지에 썸네일 이미지를 제공한 후 고해상도 이미지를 로드하는 데 더 낮은 우선 순위를 지정할 수 있음.
- 이 가중치 할당 기능을 제공함으로써 HTTP/2는 개발자가 웹 페이지 렌더링을 더 잘 제어할 수 있도록 함.
- 이 프로토콜을 사용하면 클라이언트가 사용자 상호 작용에 대한 응답으로 런타임에 종속성을 변경하고 가중치를 재할당할 수 있음.
- 그러나 특정 스트림이 특정 리소스에 액세스하지 못하도록 차단되는 경우 서버가 할당된 우선 순위를 자체적으로 변경할 수 있다는 점에 유의하는 것이 중요.
1.4 버퍼 오버 플로우
- 두 시스템 간의 모든 TCP 연결에서 클라이언트와 서버 모두 아직 처리되지 않은 들어오는 요청을 보유하는 데 사용할 수 있는 특정 양의 버퍼 공간이 있음.
- 이러한 버퍼는 다운스트림 및 업스트림 연결의 불균일한 속도 외에도 수많은 또는 특히 큰 요청을 처리할 수 있는 유연성을 제공.
- 그러나 버퍼가 충분하지 않은 상황이 있음.
- 예를 들어, 서버는 제한된 버퍼 크기 또는 낮은 대역폭으로 인해 클라이언트 애플리케이션이 처리할 수 없는 속도로 많은 양의 데이터를 푸시할 수 있음.
- 마찬가지로 클라이언트가 서버에 거대한 이미지나 동영상을 업로드할 때 서버 버퍼가 오버플로되어 일부 추가 패킷이 손실될 수 있음.
- 버퍼 오버플로를 피하기 위해 흐름 제어 메커니즘은 발신자가 데이터로 수신자를 압도하는 것을 방지해야 함.
HTTP/1.1
- HTTP/1.1에서 흐름 제어는 기본 TCP 연결에 의존.
- 이 연결이 시작되면 클라이언트와 서버 모두 시스템 기본 설정을 사용하여 버퍼 크기를 설정.
- 수신기의 버퍼가 부분적으로 데이터로 채워지면 보낸 사람에게 수신 창 , 즉 버퍼에 남아 있는 사용 가능한 공간의 양을 알려줌.
- 이 수신 창은 ACK 패킷 으로 알려진 신호로 광고됨.
- 이는 수신기가 개방 신호를 수신했음을 확인하기 위해 보내는 데이터 패킷.
- 이 보급된 수신 창 크기가 0이면 클라이언트가 내부 버퍼를 지운 다음 데이터 전송 재개를 요청할 때까지 발신자는 더 이상 데이터를 보내지 않음.
- 기본 TCP 연결을 기반으로 하는 수신 창을 사용하면 연결의 양쪽 끝에서만 흐름 제어를 구현할 수 있다는 점에 유의하는 것이 중요.
HTTP/2
- HTTP/2는 단일 TCP 연결 내에서 데이터 스트림을 다중화.
- 결과적으로 TCP 연결 수준의 수신 창은 개별 스트림의 전달을 규제하기에 충분하지 않음.
- HTTP/2는 클라이언트와 서버가 전송 계층에 의존하지 않고 자체 흐름 제어를 구현할 수 있도록 하여 이 문제를 해결함.
- 응용 프로그램 계층은 사용 가능한 버퍼 공간을 통신하여 클라이언트와 서버가 다중화된 스트림 수준에서 수신 창을 설정할 수 있도록 함.
- 이 미세한 흐름 제어는 WINDOW_UPDATE프레임을 통한 초기 연결 후에 수정하거나 유지 관리.
- 이 방법은 애플리케이션 계층 수준에서 데이터 흐름을 제어하기 때문에 흐름 제어 메커니즘은 수신 창을 조정하기 전에 신호가 최종 목적지에 도달할 때까지 기다릴 필요가 없음.
- 중간 노드는 흐름 제어 설정 정보를 사용하여 자체 리소스 할당을 결정하고 그에 따라 수정.
- 이러한 방식으로 각 중간 서버는 고유한 사용자 지정 리소스 전략을 구현하여 연결 효율성을 높일 수 있음.
- 흐름 제어의 이러한 유연성은 적절한 리소스 전략을 생성할 때 유리.
- 흐름 제어 구현을 클라이언트와 서버로 연기하면 웹 응용 프로그램의 인지된 성능을 향상시킬 수 있음
HTTP/1.1은 버퍼 오버플로를 피하기 위해 전송 계층에 의존하기 때문에 각각의 새로운 TCP 연결에는 별도의 흐름 제어 메커니즘이 필요함.
그러나 HTTP/2는 단일 TCP 연결 내에서 스트림을 다중화하며 다른 방식으로 흐름 제어를 구현해야 함.
1.5 리소스 요청 예측
- 일반적인 웹 응용 프로그램에서 클라이언트는 GET요청을 보내고 HTML 페이지를 받음.
- 인덱스 페이지 콘텐츠를 검사하는 동안 클라이언트는 페이지를 완전히 렌더링하기 위해 CSS 및 JavaScript 파일과 같은 추가 리소스를 가져와야 함을 발견할 수 있음.
- 클라이언트는 초기 요청에서 응답을 받은 후에만 이러한 추가 리소스가 필요하다고 결정 하므로 이러한 리소스를 가져오고 페이지 통합을 완료하기 위해 추가 요청을 해야 함.
- 이러한 추가 요청은 궁극적으로 연결 로드 시간을 증가시킴.
- 서버는 클라이언트에 추가 파일이 필요하다는 것을 미리 알고 있기 때문에 서버는 요청하기 전에 이러한 리소스를 클라이언트에 보내 클라이언트 시간을 절약할 수 있음.
HTTP/1.1과 HTTP/2는 이를 달성하기 위한 다른 전략을 가지고 있음.
HTTP/1.1 — 리소스 인라인
- HTTP/1.1에서 개발자는 클라이언트 시스템이 페이지를 렌더링하는 데 필요한 추가 리소스를 미리 알고 있으면 리소스 인라인 이라는 기술을 사용 하여 서버가 응답으로 보내는 HTML 문서 내에 필요한 리소스를 직접 포함할 수 있음.
- 클라이언트가 페이지를 렌더링하기 위해 특정 CSS 파일이 필요한 경우 해당 CSS 파일을 인라인하면 요청하기 전에 클라이언트에 필요한 리소스를 제공하여 클라이언트가 보내야 하는 총 요청 수를 줄임.
- 그러나 리소스 인라인에는 몇 가지 문제가 있음.
- HTML 문서에 리소스를 포함하는 것은 더 작은 텍스트 기반 리소스에 대한 실행 가능한 솔루션이지만 텍스트가 아닌 형식의 더 큰 파일은 HTML 문서의 크기를 크게 증가시킬 수 있으며, 이는 궁극적으로 연결 속도를 감소시키고 원래의 이점을 무효화할 수 있음.
- 이 기술을 사용하여. 또한 인라인된 리소스는 더 이상 HTML 문서와 분리되지 않기 때문에 클라이언트가 이미 가지고 있는 리소스를 거부하거나 리소스를 캐시에 배치하는 메커니즘이 없음.
- 여러 페이지에 리소스가 필요한 경우 각각의 새 HTML 문서에는 코드에 동일한 리소스가 인라인되어 있어 리소스가 처음에 단순히 캐시된 경우보다 HTML 문서가 더 커지고 로드 시간이 길어짐.
리소스 인라인의 주요 단점은 클라이언트가 리소스와 문서를 분리할 수 없다는 것.
연결을 최적화하려면 더 세밀한 수준의 제어가 필요하며, HTTP/2는 서버 푸시를 충족해야 합니다.
HTTP/2 — 서버 푸시
- HTTP/2는 클라이언트의 초기 요청에 대한 다중 동시 응답을 가능하게 하기 때문에 GET서버는 요청된 HTML 페이지와 함께 클라이언트에 리소스를 보내 클라이언트가 요청하기 전에 리소스를 제공할 수 있음.
- 이 프로세스를 서버 푸시 라고 함.
- 이러한 방식으로 HTTP/2 연결은 푸시된 리소스와 문서 간의 분리를 유지하면서 리소스 인라인이라는 동일한 목표를 달성할 수 있음.
- 이는 클라이언트가 기본 HTML 문서와 별도로 푸시된 리소스를 캐시하거나 거부하여 리소스 인라인의 주요 단점을 수정할 수 있음을 의미.
- HTTP/2에서 이 프로세스는 서버 PUSH_PROMISE가 리소스를 푸시할 것임을 클라이언트에 알리는 프레임을 보낼 때 시작됨.
- 이 프레임에는 메시지의 헤더만 포함되며 클라이언트가 서버가 푸시할 리소스를 미리 알 수 있음.
- 리소스가 이미 캐시된 경우 클라이언트는 RST_STREAM응답으로 프레임을 보내 푸시를 거부할 수 있음.
- 프레임은 또한 PUSH_PROMISE서버가 푸시할 리소스를 알고 있기 때문에 클라이언트가 서버에 중복 요청을 보내는 것을 방지.
여기서 서버 푸시의 강조점은 클라이언트 제어라는 점에 유의하는 것이 중요.
클라이언트가 서버 푸시의 우선 순위를 조정하거나 비활성화해야 하는 경우 언제든지 SETTINGS이 HTTP/2 기능을 수정하기 위해 프레임을 보낼 수 있음.
1.6 압축
- 웹 애플리케이션을 최적화하는 일반적인 방법은 압축 알고리즘을 사용하여 클라이언트와 서버 간에 이동하는 HTTP 메시지의 크기를 줄이는 것.
- HTTP/1.1 및 HTTP/2 모두 이 전략을 사용하지만 전자에는 전체 메시지 압축을 금지하는 구현 문제가 있음.
HTTP/1.1
- gzip 과 같은 프로그램은 특히 CSS 및 JavaScript 파일의 크기를 줄이기 위해 HTTP 메시지로 전송된 데이터를 압축하는 데 오랫동안 사용.
- 그러나 메시지의 헤더 구성 요소는 항상 일반 텍스트로 전송.
- 각 헤더는 매우 작지만 이러한 압축되지 않은 데이터의 부담은 요청이 많을수록 연결에 점점 더 무거워지며, 다양한 리소스와 다양한 리소스 요청을 필요로 하는 복잡하고 API가 많은 웹 애플리케이션에 불이익을 줌.
- 또한 쿠키를 사용하면 헤더가 훨씬 더 커질 수 있으므로 일종의 압축이 필요.
- 이 병목 현상을 해결하기 위해 HTTP/2는 HPACK 압축을 사용하여 헤더 크기를 줄임.
HTTP/2
- HTTP/2에서 계속해서 등장한 주제 중 하나는 바이너리 프레이밍 레이어를 사용하여 세부 사항을 더 잘 제어할 수 있음.
- 헤더 압축의 경우에도 마찬가지로, HTTP/2는 데이터에서 헤더를 분할하여 헤더 프레임과 데이터 프레임을 생성할 수 있음.
- HTTP/2 전용 압축 프로그램 HPACK 은 이 헤더 프레임을 압축할 수 있음.
- 이 알고리즘은 Huffman 코딩을 사용하여 헤더 메타데이터를 인코딩할 수 있으므로 크기를 크게 줄일 수 있음.
- 또한 HPACK은 이전에 전달된 메타데이터 필드를 추적하고 클라이언트와 서버 간에 공유되는 동적으로 변경된 인덱스에 따라 추가로 압축할 수 있음.
- HTTP/2는 HPACK 및 기타 압축 방법을 사용하여 클라이언트-서버 대기 시간을 줄일 수 있는 기능을 하나 더 제공.
1.7 HTTP/1, HTTP/2 성능 비교
- 데모 페이지 는 100개의 작은 이미지로 분할된 이미지로 구성 됨.
- 이미지는 HTTP/1.1과 HTTP/2를 통해 나란히 로드되어 HTTP/2의 다중화 및 헤더 압축으로 인한 로드 성능의 차이를 보여 줌.
- HTTP/1.1과 HTTP/2를 통한 자산 로드의 차이점은 다음과 같음.
- HTTP/2가 확실한 승자입니다.
- 처음 몇 개의 자산이 HTTP/2를 통해 로드되기 시작하면 다음 자산이 매우 빠르게 로드됩니다.
- HTTP/1.1의 경우는 그렇지 않습니다.
- 이미지 자산은 전체 이미지를 완성하기 위해 (HTTP/1.1의 파이프라이닝에 일반적으로) 더 오랜 시간 동안 차례로 로드됩니다.
HTTP/2 METHOD 확인
- Chrome의 개발자 도구를 열고 네트워크 탭으로 이동.
- “이름” 또는 항목 목록의 다른 제목을 마우스 오른쪽 버튼으로 클릭하고 목록에서 “프로토콜”을 선택.
- 페이지를 다시 로드하고 페이지에 로드되는 항목에 대한 프로토콜 값을 확인.
- HTTP/2가 특정 요청에 대해 작동하는 경우 Protocol의 값은 “h2” 그렇지 않은 경우 “http/1.1”.
성능 차이
- Chrome에서 디버거를 열고 데모 페이지를 다시 로드 .
- “폭포”를 기준으로 “네트워크” 탭의 이미지를 정렬.
HTTP/1
HTTP/2
- 이미지는 6개의 배치로 로드(브라우저에서 설정한 병렬 연결).
- 따라서 HTTP/1은 전체 100개 이미지 세트는 로드를 완료하는 데 더 많은 시간이 걸림.
HTTP/2 지원브라우저
- 거의 모든 브라우저는 HTTP/2를 지원.
- Chrome, Firefox, Opera, Safari(특정 OS 버전용), IE 등.
- HTTP/2는 TLS를 통해서만 구현.
- 따라서 아직 리소스를 HTTPS로 이동하지 않은 경우 리소스를 HTTPS로 이동하는 것이 훨씬 더 중요.
- HTTPS는 전체 페이지나 웹사이트가 아니라 특정 리소스에 필요.
결론
이 지점별 분석에서 볼 수 있듯이 HTTP/2는 여러 면에서 HTTP/1.1과 다릅니다.
일부 기능은 웹 애플리케이션 성능을 더 잘 최적화하는 데 사용할 수 있는 더 높은 수준의 제어를 제공하고 다른 기능은 단순히 이전 프로토콜.
두 프로토콜 간의 변형에 대한 높은 수준의 관점을 얻었으므로 HTTP/2의 다중화, 스트림 우선 순위 지정, 흐름 제어, 서버 푸시 및 압축과 같은 요소가 웹 개발 환경의 변화에 어떻게 영향을 미칠지 고려할 수 있습니다.