Should x/net/http2 combine the header and body packets into one?

veezhang · February 22, 2023, 9:46am

When sending a large number of small requests, there will be a performance loss here.
So should combine the header and body packets, and do not flush immediately after write headers?

github.com

golang/net/blob/master/http2/transport.go#L1617


      
          				StreamID:      streamID,
          				BlockFragment: chunk,
          				EndStream:     endStream,
          				EndHeaders:    endHeaders,
          			})
          			first = false
          		} else {
          			cc.fr.WriteContinuation(streamID, endHeaders, chunk)
          		}
          	}
          	cc.bw.Flush()
          	return cc.werr
          }
          
          
// internal error values; they don't escape to callers
          var (
          	// abort request body write; don't send cancel
          	errStopReqBodyWrite = errors.New("http2: aborting request body write")
          
          
	// abort request body write, but send stream reset of cancel.
          	errStopReqBodyWriteAndCancel = errors.New("http2: canceling request")

christophberger · February 22, 2023, 6:41pm

I am completely unenlightened when it comes to HTTP2 internals, but from skimming the Web, I get the impression that HTTP2 always separates HEADERS frames from DATA frames, probably for better multiplexing capabilities.

RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2):

The basic protocol unit in HTTP/2 is a frame (Section 4.1). Each frame type serves a different purpose. For example, HEADERS and DATA frames form the basis of HTTP requests and responses (Section 8.1)

HTTP/2 and How it Works. TLS helps improve security. Now it is… | by Carson | Medium

Introduction to HTTP/2

veezhang · February 23, 2023, 2:54am

@christophberger Thanks!
I think it might not be for multiplexing.

Here it is said that multiplexing is implemented through stream. Each HTTP request/response is associated with its own stream, independent of each other.

https://httpwg.org/specs/rfc7540.html#Overview

The original text is as follows:

Multiplexing of requests is achieved by having each HTTP request/response exchange associated with its own stream (Section 5). Streams are largely independent of each other, so a blocked or stalled request or response does not prevent progress on other streams.

christophberger · February 23, 2023, 8:02am

Ok, maybe it is not for multiuplexing. As said, I know next to nothing about the HTTP2 specification.

But my (admittedly guesswork-based) point still holds. HTTP2 strictly keeps different frame types separated, and this is probably why the http2 package does not combine header and body.

veezhang · February 24, 2023, 1:56am

Yes. The Header and Body have different frame types separated, and I don’t want to merge frames. I want to not flush immediately after write headers, in this way, the Linux network protocol will not send in two tcp packets separated.

christophberger · February 24, 2023, 8:52am

in this way, the Linux network protocol will not send in two tcp packets separated.

Curious: Did you test this?
And if so, do you see significant performance gains?

From my basic understanding, HTTP2 frames get multiplexed onto TCP connections, but there is no direct influence on how the network stack manages TCP packets.

I base my assumptions on this SO answer, especially the first bullet point and the second comment:

The main point is that a single TCP connection may contain frames from many different HTTP/2 streams, interleaved. The relationship to TCP packets is not important here - TCP packets are reassembled into TCP streams by your TCP stack, and should have no bearing on your understanding of HTTP/2.

@laike9m: Each TCP “packet” contain just some part of the TCP stream. These packets have no relation to any kind of message - because TCP is a single stream and not a sequence of messages. Thus an application layer frame may be packet in multiple TCP packets, a single packet may contain multiple application layer frames etc. There simply is no defined mapping from application layer frames to TCP packets.

Again, I am not a network specialist, but these answers are in line with my understanding of the OSI model and its separation of concerns between the layers of a network stack.

So maybe you do not need to worry too much about a performance loss from flushing the header.

veezhang · February 27, 2023, 7:05am

Hi thanks a lot!
And I make a test for it.
I open an issue for it.

system · May 28, 2023, 7:06am

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.