On Tue, 08 Dec 2015 11:11:52 +0100, Peter Gutmann
<pgut...@cs.auckland.ac.nz> wrote:
Dave Garrett <davemgarr...@gmail.com> writes:
A TLS extension to negotiate max length might be viable.
I think a better starting point would be to look at the implementation
that's
causing the problem. There's nothing magical about a 16K max segment
size
that causes poor performance, TCP typically has an MSS of 1400-1500
bytes, one
tenth of the TLS segment size, without there being a 187% loss in
throughput
so it looks like the problem is in the implementation, not the
protocol. I
don't see any reason why you couldn't get close to wire speeds, or at
least
min( crypto speed, wire speed ) for TLS for a properly-done
implementation.
Based on my past experience, a possible reason is that the code does the
following:
read_event_handler:
read data from socket
decrypt data
handle application data
return
rather than:
read event handler:
read data from socket
queue data for decryption
signal decryption handler
return
decryption handler:
decrypt data
handle application data
Another factor I have seen influencing speed is the size of the buffer
reading from the socket, bigger buffer gives better speed. Within reason,
of course; IIRC the benefit of increasing the buffer stops at around 5-10%
of the connection speed. A good rule of thumb is that the buffer should be
larger than the largest block that you will ever receive over the
computer's local connection, provided you read the arriving data when you
are notified about the data.
I recently saw 10x+ speed increase by changing an application's handling
of these two aspects (on Windows). In that case 300KB buffer was
sufficient, but I prefer a 1 MB buffer.
--
Sincerely,
Yngve N. Pettersen
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
