There are (at least) two subtle ways that our current SSL code is slightly inefficient:
-
Sometimes, it may happen the side the finishes the handshake is also the first to speak, and in this case it's slightly less overhead if the first data frame goes out in the same packet as the end of the handshake. (When this actually happens is complicated; it depends on which side speaks first, whether we're starting a new session or resuming and old one, and which version of TLS is in use.) What we could do is to have a kind of "cork" option, where if send_all triggers the handshake then it tells _retry to leave the last set of bytes-to-send in the buffer (if any), where they'll immediately get flushed out by the next call to _retry. (Note: this doesn't help if calling do_handshake explicitly; not sure there's much we can do about that.)
-
Currently, the user hands SSLStream.send_all chunks of data of whatever size, and then we let openssl break them into records. I believe that by default it will use the largest possible records (16 KiB). This is not necessarily the best approach. Even though ssl doesn't expose any specific knobs for this, I think each call to SSLObject.write has to generate a complete record, so we could do it by tracking the optimal record size and manually breaking data into pieces of that size before passing them to write. (Maybe with a bit of trickiness if we want to rejoin it all before calling send_all on the transport. Or maybe this doesn't really matter.)
Also I guess if we're piggybacking on the end of a handshake, that should be taken into account when calculating the optimal size for the first record.
There are (at least) two subtle ways that our current SSL code is slightly inefficient:
Sometimes, it may happen the side the finishes the handshake is also the first to speak, and in this case it's slightly less overhead if the first data frame goes out in the same packet as the end of the handshake. (When this actually happens is complicated; it depends on which side speaks first, whether we're starting a new session or resuming and old one, and which version of TLS is in use.) What we could do is to have a kind of "cork" option, where if
send_alltriggers the handshake then it tells_retryto leave the last set of bytes-to-send in the buffer (if any), where they'll immediately get flushed out by the next call to_retry. (Note: this doesn't help if callingdo_handshakeexplicitly; not sure there's much we can do about that.)Currently, the user hands
SSLStream.send_allchunks of data of whatever size, and then we let openssl break them into records. I believe that by default it will use the largest possible records (16 KiB). This is not necessarily the best approach. Even thoughssldoesn't expose any specific knobs for this, I think each call toSSLObject.writehas to generate a complete record, so we could do it by tracking the optimal record size and manually breaking data into pieces of that size before passing them towrite. (Maybe with a bit of trickiness if we want to rejoin it all before callingsend_allon the transport. Or maybe this doesn't really matter.)Also I guess if we're piggybacking on the end of a handshake, that should be taken into account when calculating the optimal size for the first record.