Hi, > > 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....@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? Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz