Reported in OpenJDK:

> > On 7/12/2018 1:17 PM, Simone Bordet wrote:
> > Currently:
> > - Server wraps 160, 6 and 907 in 3 wraps.
> > - Server *sends* the 1073 bytes in 1 TCP write
> > - Client unwraps 160, then goes into NEED_WRAP
> > - Client wraps 6, then goes again into NEED_UNWRAP to finish with the
> > 6 and 907 received by the server.
> >
> > What I'm suggesting:
> > - Server wraps 160, 6 and 907 in 3 wraps.
> > - Server *sends* the 1073 (160+6+907) bytes in 1 TCP write
> > - Client unwraps 160, stays in NEED_UNWRAP, unwraps the 6, unwraps the
> > 907, then goes into NEED_WRAP
> > - Client wraps 6 and 58
> > - Client *sends* the 64 (6+58) bytes in 1 TCP write.
> >
> > The 6 bytes of the dummy change_cipher_spec are *sent* just after
> > receiving the ServerHello in both cases, they are just *generated* at
> > different times.
> >
> > By having all the unwraps() consecutive and all the wraps()
> > consecutive you can enable a number of optimizations I described
> > earlier.
> >
> > Imagine a client that would perform a TCP *send* every time the state
> > moves away from NEED_WRAP.
> > Currently it would:
> > 1. TCP send for ClientHello
> > 2. Reads 1073 from server
> > 3. Unwrap 160, then NEED_WRAP
> > 4. Generate 6, then NEED_UNWRAP
> > 5. TCP send the 6 bytes
> > 6. Unwrap 6 and 907, then NEED_WRAP
> > 7. Generate 58 then FINISHED
> > 8 TCP send the 58 bytes.
> >
> > You can see that the client issues 3 TCP sends.
> >
> > With what I am suggesting, the client would only issue 2 TCP sends,
> > which seems more in line with the efforts in TLS 1.3 to be more
> > efficient.
> >
> > It would just be a matter of *generating* those 6 bytes a bit later,
> > *after* having fully unwrapped the ServerHello.
> >
> On Fri, Jul 13, 2018 at 3:45 PM Xuelei Fan <xuelei.fan at oracle.com> wrote:
> It's a good idea!

I just built:

$ hg id -i
76072a077ee1

and I can still see the (very) inefficient behavior above.
Are there plans to fix it?