HTTP/2

프론트엔드 개발시 http2에 대해서 기본적으로 알아야할 부분들을 정리한 글입니다. rfc 7540과 http2 in action, google dev 에서 필요한 부분들을 참고하여 작성하였습니다. 
글 후반부에는 프론트엔드 개발시 http2 환경에서 최적화에 대한 내용도 포함하였습니다. 

terms by rfc7540 (https://datatracker.ietf.org/doc/html/rfc7540#section-2.2)
- client: The endpoint that initiates an HTTP/2 connection. Clients send HTTP requests and receive HTTP responses.
- connection: A transport-layer connection between two endpoints.
- connection error: An error that affects the entire HTTP/2 connection.
- endpoint: Either the client or server of the connection.
- frame: The smallest unit of communication within an HTTP/2 connection, consisting of a header and a variable-length sequence of octets structured according to the frame type.
- peer: An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint that is remote to the primary subject of discussion.
- receiver: An endpoint that is receiving frames.
- sender: An endpoint that is transmitting frames.
- server: The endpoint that accepts an HTTP/2 connection. Servers receive HTTP requests and send HTTP responses. - stream: A bidirectional flow of frames within the HTTP/2 connection.
- stream error: An error on the individual HTTP/2 stream.

1.Introduction

Flow animation with http1.1, h2, h2 with push 
https://freecontent.manning.com/animation-http-1-1-vs-http-2-vs-http-2-with-push/

HTTP 1.1 vs HTTP.2 vs HTTP/2 with Push - Manning

 

 

summary
- HTTP/1.1 has some fundamental performance problems, particularly with fetching multiple resources.
- Workarounds exist for these performance problems (multiple connections, sharding, spriting, and so on), but they have their own downsides. 
- Performance issues are easy to see in waterfall diagrams that can be generated by tools such as WebPagetest. 
- SDPY was designed to address these performance issues.
- HTTP/2 is the standardized version of SPDY.
- Not all performance problems can be solved by HTTP/2

1.1 SPDY
- Multiplexed streams: Requests and responses used a single TCP connection and were broken into interleaved packets grouped into separate streams.
- Request prioritization: To avoid introducing new performance problems by sending all requests at the same time, the concept of prioritization of the requests was introduced.
- HTTP header compression: HTTP bodies had long been compressed, but now headers could be compressed too.

1.2 HTTP/2
1.2.1 Usage

web server	Web server added http/2
Apache HTTPD	2.4.17 (though marked as experimental until 2.4.26)
IIS	10.0
Jetty	9.3
Netty	4.1
nginx	1.9.5
Node.JS	8.4.0(though not enabled by default until 9.0 and still marked as experimental until 10.10)
Tomcat	8.5

 

1.2.2 Performance
show the performance improvements of HTTP/2.0
https://www.tunetheweb.com/performance-test-360/

HTTP versus HTTPS versus HTTP2 Test

This page is available over HTTP 1.1, HTTP 1.1 over HTTPS, and HTTP/2 over HTTPS

 

2. HTTP/2 protocol 

2.1 HTTP/2 protocol basics
- full binary protocol
- Multiplexed rather than synchronous
- Flow control
- Stream prioritization
- Header compression
- Server push

2.1.1 full binary protocol

HTTP/2의 모든 성능 향상 중 핵심은 새 바이너리 프레이밍 계층입니다. 이 계층은 HTTP 메시지가 캡슐화되어 클라이언트와 서버 사이에 전송되는 방식을 규정합니다.

계층'이란 애플리케이션에 노출되는 소켓 인터페이스와 더 상위 HTTP API 간에 최적의 새 인코딩 메커니즘을 도입하기 위해 선택된 디자인을 의미합니다. HTTP 의미 체계(예: 동사, 메서드 및 헤더)는 영향을 받지 않지만 전송 중에 이 의미 체계가 인코딩되는 방식은 다릅니다. 줄바꿈으로 구분되는 일반 텍스트 HTTP/1.x 프로토콜과 달리, 모든 HTTP/2 통신은 더 작은 메시지와 프레임으로 분할되며, 각각은 바이너리 형식으로 인코딩됩니다.

따라서 클라이언트와 서버는 서로를 이해하기 위해 새 바이너리 인코딩 메커니즘을 사용해야 합니다. HTTP/1.x 클라이언트는 HTTP/2 전용 서버를 이해하지 못하며 그 반대도 마찬가지입니다. 다행히, 필요한 모든 프레이밍 작업을 클라이언트와 서버가 대신 수행해주기 때문에 애플리케이션은 이 모든 변경을 인식하지 않아도 됩니다.

 HTTP/2 moves to a full binary protocol, in which HTTP messages are split and sent in clearly defined frames. All HTTP/2 messages effectively use chunked encoding as standard, and this doesn’t need to be set explicitly. In fact, the HTTP/2 specification states
       The chunked transfer encoding defined in Section 4.1 of RFC7230 MUST NOT be used in HTTP/2.
These frames are similar to the TCP packets that underlie most HTTP connections. When all the frames are received, the full HTTP message can be reconstructed.

2.1.2 스트림, 메시지 및 프레임

새 바이너리 프레이밍 메커니즘이 도입됨에 따라 클라이언트와 서버 간에 데이터 교환 방식이 바뀌었습니다. 이 과정을 설명하기 위해 HTTP/2 용어를 먼저 익혀보겠습니다.

• 스트림: 구성된 연결 내에서 전달되는 바이트의 양방향 흐름이며, 하나 이상의 메시지가 전달될 수 있습니다.
• 메시지: 논리적 요청 또는 응답 메시지에 매핑되는 프레임의 전체 시퀀스입니다.
• 프레임: HTTP/2에서 통신의 최소 단위이며 각 최소 단위에는 하나의 프레임 헤더가 포함됩니다. 이 프레임 헤더는 최소한으로 프레임이 속하는 스트림을 식별합니다.

이러한 용어의 관계는 다음과 같이 요약됩니다.

• 모든 통신은 단일 TCP 연결을 통해 수행되며 전달될 수 있는 양방향 스트림의 수는 제한이 없습니다.
• 각 스트림에는 양방향 메시지 전달에 사용되는 고유 식별자와 우선순위 정보(선택 사항)가 있습니다.
• 각 메시지는 하나의 논리적 HTTP 메시지(예: 요청 또는 응답)이며 하나 이상의 프레임으로 구성됩니다.
• 프레임은 통신의 최소 단위이며 특정 유형의 데이터(예: HTTP 헤더, 메시지 페이로드 등)를 전달합니다. 다른 스트림들의 프레임을 인터리빙한 다음, 각 프레임의 헤더에 삽입된 스트림 식별자를 통해 이 프레임을 다시 조립할 수 있습니다.
  

  

간단히 말해, HTTP/2는 HTTP 프로토콜 통신을 바이너리 인코딩된 프레임의 교환으로 세분화합니다. 그런 다음 이 프레임은 특정 스트림에 속하는 메시지에 매핑되며, 모든 프레임은 단일 TCP 연결 내에서 다중화됩니다. HTTP/2 프로토콜이 제공하는 다른 모든 기능과 성능 최적화는 이러한 기반을 통해 지원됩니다.

Frame(https://datatracker.ietf.org/doc/html/rfc7540#section-4)
Once the HTTP/2 connection is established, endpoints can begin exchanging frames.

frame format
All frames begin with a fixed 9-octet header followed by a variable- length payload.

Stream(https://datatracker.ietf.org/doc/html/rfc7540#section-5)
A "stream" is an independent, bidirectional sequence of frames exchanged between the client and server within an HTTP/2 connection. Streams have several important characteristics:

- A single HTTP/2 connection can contain multiple concurrently open streams, with either endpoint interleaving frames from multiple streams.
- Streams can be established and used unilaterally or shared by either the client or server. o Streams can be closed by either endpoint.
- The order in which frames are sent on a stream is significant. Recipients process frames in the order they are received. In particular, the order of HEADERS and DATA frames is semantically significant.
- Streams are identified by an integer. Stream identifiers are assigned to streams by the endpoint initiating the stream.

2.1.2 Multiplexed rather than synchronous
HTTP/2의 새 바이너리 프레이밍 계층은 이러한 제한을 없애주고 전체 요청 및 응답 다중화를 지원합니다. 이를 위해 클라이언트와 서버가 HTTP 메시지를 독립된 프레임으로 세분화하고, 이 프레임을 인터리빙한 다음, 다른 쪽에서 다시 조립하도록 허용합니다.

이 스냅샷은 동일한 연결 내의 여러 스트림을 캡처한 것입니다. 클라이언트는 DATA 프레임(스트림 5)을 서버로 전송 중인 반면, 서버는 스트림 1과 스트림 3의 인터리빙된 프레임 시퀀스를 클라이언트로 전송 중입니다. 따라서 3개의 병렬 스트림이 존재합니다.

HTTP 메시지를 독립된 프레임으로 세분화하고 이 프레임을 인터리빙한 다음, 다른 쪽에서 다시 조립하는 기능은 HTTP/2에서 가장 중요한 기능 향상입니다. 실제로, 이 기능은 모든 웹 기술에 걸쳐 수많은 성능 향상에 파급 효과를 주고 있으며, 다음과 같은 작업이 가능합니다.

• 여러 요청을 하나도 차단하지 않고 병렬로 인터리빙할 수 있습니다.
• 여러 응답을 하나도 차단하지 않고 병렬로 인터리빙할 수 있습니다.
• 단일 연결을 사용하여 여러 요청과 응답을 병렬로 전달할 수 있습니다.
• 연결된 파일, 이미지 스프라이트(image sprites), 도메인 분할과 같은 불필요한 HTTP/1.x 임시 방편을 제거합니다(HTTP/1.x에 맞게 최적화 참조).
• 불필요한 지연 시간을 제거하고 가용 네트워크 용량의 활용도를 개선하여 페이지 로드 시간을 줄입니다.
• 기타 등등…

HTTP/2 allows multiple requests to be in progress at the same time, on a single connection, using different streams for each HTTP request or response. This concept of multiple independent requests happening at the same time was made possible by moving to the binary framing layer, where each frame has a stream identifier. The receiving party can reconstruct the full message when all frames for that stream have been received. Frames are the key to allowing multiple messages to be sent at the same time. Each frame is labeled to indicate which message it belongs to (the stream), which allows two, three, or a hundred messages to be sent or received at the same time on the same multiplexed connection, as opposed to the six parallel HTTP/1 connections that most browsers allow.

The main point is that the HTTP/2 connection isn’t blocked after sending a request until the response is received, as it is in HTTP/1.1
The order in which the server sends back responses is entirely up to the server, though the client can indicate priorities. If multiple responses can be sent, the server can prioritize the important resources (such as CSS and JavaScript) over less important resources (such as images).

- HTTP/2 uses multiple binary frames to send HTTP requests and responses across a single TCP connection, using a multiplexed stream.
- HTTP/2 is mostly different at the message-sending level, and at even a slightly higher level, the core concepts of HTTP remain the same. Requests have a method (such as GET), a resource you want to get (such as /styles.css), headers, body, status codes (such as 200, 404), caching, cookies, and so on, which stay the same.

 

2.1.3 Stream prioritization and flow control
Before HTTP/2, HTTP was a single request-and-response protocol, so there was no need for prioritization within the protocol. The client (typically, the web browser) decided the priority outside of HTTP by deciding what order to send the messages in, using the limited number of HTTP/1 connections (typically, six). This prioritization usually required requesting critical resources (HTML, render blocking CSS, and critical JavaScript) first and requesting non-blocking items (such as images and asynchronous JavaScript) later. Requests were queued, awaiting a free HTTP/1 connection, and the queuing, managed by the browser, decided the priority.
HTTP/2 now has a much higher limit on the number of requests in flight at any time (typically, 100 active streams by default in many implementations), so many requests no longer need to be queued by the browser and can be sent immediately. This fact could lead to bandwidth being wasted on lower-priority resources (such as images) and therefore cause the page to appear to load slower over HTTP/2. Stream prioritization is needed so that the most critical resources can be sent with higher priority. Stream prioritization is implemented by the server sending more frames for higher-priority requests than for lower-priority requests when a queue of frames is waiting to be sent.
If you have five critical resources and a sixth noncritical one, under HTTP/1, all the resources can be sent with the same priority on the six separate connections, or the first five can be sent while the sixth is held back. Under HTTP/2, all six requests can be sent with the appropriate priority, and this priority is used to decide how much resource to allocate to sending each response.
These processes usually are controlled by the browser and server, so users and web developers have little control of them at this writing,

2.1.4 server push
Another important difference between HTTP/1 and HTTP/2 is that HTTP/2 adds the concept of server push, which allows the server to respond to a request with more than one response. Under HTTP/1, when the home page is returned, the browser must read it and then request the other resources (such as CSS and JavaScript) before it starts rendering the page. With HTTP/2 server push, those resources can be sent with the initial response and should be available when the browser looks to use them.

summary
- HTTP/2 push is a new concept in HTTP/2 that allows multiple responses to be sent back to a single HTTP request.
- HTTP/2 push was proposed as an alternative to inlining critical resources. 
- Many servers and CDNs implement HTTP/2 push by using HTTP link headers.
- HTTP/2 push is implemented in the browser in ways that may not be obvious.
- Overpushing resources is easy and can have a detrimental effect on website performance.
- The performance benefit of HTTP/2 push may not be great, and the risks are high. 
- It may be better to use preload hints, perhaps with 103 Early Hints, rather than push. 
- HTTP/2 push may have other use cases, though some would require changes in the protocol.


without server push

 

H2 with server push

Push vs preload
Preload isn’t as fast as HTTP/2 push in pushing a resource before being asked for it, but it’s a browser-initiated request, which has several advantages:
- The browser is aware of what is in its cache(s) and uses that knowledge appropriately to decide whether to make the request. Unlike HTTP/2 push, a preload hint won’t cause new downloads of resources that the client already has. If the browser already has the resource, it ignores the preload hint. Because many HTTP/2 servers use HTTP link headers to push resources, however, you should add a nopush attribute if you don’t want to push a resource. 
- You have fewer push-cache worries and complications when you use preload hints, which should be downloaded and pulled into the HTTP cache. If a preloaded resource isn’t used, you’re still wasting time downloading it, but that rule applies whether you’re using preload or HTTP/2 push. 
- You can also use preload to load resources from other domains, whereas you can use HTTP/2 push only for resources on your own domain. 
- Chrome developer tools shows all preloaded requests whether they’re used or not, but it shows only used pushed requests (although a workaround is sending a preload HTTP link header for each pushed resource).

new status code: 103 Early Hints
 main concept is that server push preload link header
https://datatracker.ietf.org/doc/html/draft-kazuho-early-hints-status-code

3. Optimizatizing for h2

3.1 h2 requests still have a cost

3.2 h2 isn't limitless

3.3 bundling 

• Even in HTTP/2 environment, any level of concatenation showed a significant improvement compared to non-concatenation.
• The improvement was most significant (3x faster) when the distance between browser and server is shortest (i.e. over a connection with least latency).
• Differences among concatenation levels below 1000 (50, 6 or 1) were negligible.
• As distance between browser and server is getting farther (more latency), fluctuations of loading speed between samplings became bigger. This means comparing two numbers measured long interval between them can be irrelevant.

https://medium.com/@asyncmax/the-right-way-to-bundle-your-assets-for-faster-sites-over-http-2-437c37efe3ff

The Right Way to Bundle Your Assets for Faster Sites over HTTP/2

3.4 image sprite

sprite set optimisation is still relevant, even when upgrading to HTTP/2 protocol.

 

https://blog.octo.com/en/http2-arrives-but-sprite-sets-aint-no-dead/

HTTP/2 arrives but sprite sets ain’t no dead | OCTO Talks !

참고자료
http2 in action by Barry Pollard 
https://developers.google.com/web/fundamentals/performance/http2?hl=ko

HTTP/2 소개  |  Web Fundamentals  |  Google Developers

https://blog.octo.com/en/http2-arrives-but-sprite-sets-aint-no-dead/

HTTP/2 arrives but sprite sets ain’t no dead | OCTO Talks !

https://medium.com/@asyncmax/the-right-way-to-bundle-your-assets-for-faster-sites-over-http-2-437c37efe3ff

The Right Way to Bundle Your Assets for Faster Sites over HTTP/2

 

https://caniuse.com/?search=http2 

"http2" | Can I use... Support tables for HTML5, CSS3, etc

https://datatracker.ietf.org/doc/html/draft-kazuho-early-hints-status-code

https://freecontent.manning.com/animation-http-1-1-vs-http-2-vs-http-2-with-push/

HTTP 1.1 vs HTTP.2 vs HTTP/2 with Push - Manning

 

rfc7540