I can't count.

Serializing HTTP/2 preface, optional initial SETTINGS, and optional initial WINDOW_UPDATE happens in one go within SpdySession, so combining them is straightforward.

Slapping on the SETTINGS ACK is tricky: this is only send after a SETTINGS frame is received from the server.  Shall we wait for that?  What if initial request could be sent out earlier?  What if both peers wait for to receive the other's SETTINGS frame before they send out their own so that they can combine it with the SETTINGS ACK, resulting in a lock?

As for the HEADERS, that would make sense, but would be fairly complicated: HttpStreamFactoryImpl::Job calls into SpdySessionPool which instantiates SpdySession and initializes the connection, but then it notifies JobController which in turn notifies HttpNetworkTransacion which then initiates the stream with the request.  I am not even sure this happens synchronously.  Maybe one could withhold enqueueing any data in SpdySession until the first set of HEADERS is ready to be sent out.

Of course I misspoke (miswrote?): initial SETTINGS frame is not optional (though it may be empty).

Well, two or three packets is still better than five. :-)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8abf64aff97080b772d924ebf79d4c74d14eea0d

commit 8abf64aff97080b772d924ebf79d4c74d14eea0d
Author: bnc <bnc@chromium.org>
Date: Wed Jun 07 20:18:54 2017

SpdySession: Combine three frames into a single packet.

Combine HTTP/2 connection preface, initial SETTINGS frame, and optional
initial WINDOW_UPDATE frame into a single SpdySerializedFrame so that it
can be send on the wire in a single packet.

Also combine said frames in tests.  (Because of the way expected and
actual write data are compared, tests expecting individual packets
(before this change) pass with the packets sent separately or combined,
but tests expecting combined packets (after this change) only pass
when packets are actually combined.)

BUG=705551

Review-Url: https://codereview.chromium.org/2909653002
Cr-Commit-Position: refs/heads/master@{#477745}

[modify] https://crrev.com/8abf64aff97080b772d924ebf79d4c74d14eea0d/net/spdy/chromium/spdy_network_transaction_unittest.cc
[modify] https://crrev.com/8abf64aff97080b772d924ebf79d4c74d14eea0d/net/spdy/chromium/spdy_session.cc
[modify] https://crrev.com/8abf64aff97080b772d924ebf79d4c74d14eea0d/net/spdy/chromium/spdy_session.h
[modify] https://crrev.com/8abf64aff97080b772d924ebf79d4c74d14eea0d/net/spdy/chromium/spdy_session_unittest.cc

I decreased the number of packets from five to three by combining the first three of them into one.  This is already an improvement as stated in comment #4.  The acknowledgement SETTINGS frame should not be combined for reasons laid out in comment #2.  Combining the HEADERS frame is theoretically possible, but currently not high on my list, so I am making this issue Available if someone wants to grab it.

Thanks, Bence!

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

It's a low priority optimization. Leaving it at Available seems reasonable.