[openssl-commits] [openssl] master update

[Matt Caswell]

The branch master has been updated
       via  0299f3f790437d124d15f60489c774407325f82b (commit)
      from  242525372c65d9c92fba970333ceb961abc24ce4 (commit)


- Log -----------------------------------------------------------------
commit 0299f3f790437d124d15f60489c774407325f82b
Author: Matt Caswell <matt at openssl.org>
Date:   Tue Jul 18 14:54:23 2017 +0100

    Add some performance notes about early data
    
    In particular add information about the effect of Nagle's algorithm on
    early data.
    
    Fixes #3906
    
    Reviewed-by: Ben Kaduk <kaduk at mit.edu>
    (Merged from https://github.com/openssl/openssl/pull/3955)

-----------------------------------------------------------------------

Summary of changes:
 doc/man3/SSL_read_early_data.pod | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/doc/man3/SSL_read_early_data.pod b/doc/man3/SSL_read_early_data.pod
index 38dffe5..f0237fa 100644
--- a/doc/man3/SSL_read_early_data.pod
+++ b/doc/man3/SSL_read_early_data.pod
@@ -168,6 +168,30 @@ In the event that the current maximum early data setting for the server is
 different to that originally specified in a session that a client is resuming
 with then the lower of the two values will apply.
 
+=head1 NOTES
+
+The whole purpose of early data is to enable a client to start sending data to
+the server before a full round trip of network traffic has occurred. Application
+developers should ensure they consider optimisation of the underlying TCP socket
+to obtain a performant solution. For example Nagle's algorithm is commonly used
+by operating systems in an attempt to avoid lots of small TCP packets. In many
+scenarios this is beneficial for performance, but it does not work well with the
+early data solution as implemented in OpenSSL. In Nagle's algorithm the OS will
+buffer outgoing TCP data if a TCP packet has already been sent which we have not
+yet received an ACK for from the peer. The buffered data will only be
+transmitted if enough data to fill an entire TCP packet is accumulated, or if
+the ACK is received from the peer. The initial ClientHello will be sent as the
+first TCP packet, causing the early application data from calls to
+SSL_write_early_data() to be buffered by the OS and not sent until an ACK is
+received for the ClientHello packet. This means the early data is not actually
+sent until a complete round trip with the server has occurred which defeats the
+objective of early data.
+
+In many operating systems the TCP_NODELAY socket option is available to disable
+Nagle's algorithm. If an application opts to disable Nagle's algorithm
+consideration should be given to turning it back on again after the handshake is
+complete if appropriate.
+
 =head1 RETURN VALUES
 
 SSL_write_early_data() returns 1 for success or 0 for failure. In the event of a