I filed a bug for this improvement.
https://bugs.openjdk.java.net/browse/JDK-8209840
We may fix it in a near release.
Thanks,
Xuelei
On 8/22/2018 3:29 AM, Simone Bordet wrote:
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!
