On Wed, Nov 9, 2016 at 11:42 AM, Martin Rex <m...@sap.com> wrote: > in reality, the Google servers perform pathological fragmentation > of the AppData and use a whooping 36 TLS records for the response > (curiously no TLS AppData record split between header and body). >
At the beginning of a connection we aim to size TLS records so that they don't span packets. Since none of a TLS record can be processed until the whole record is received, spanning packets can mean spanning TCP windows or loss events and thus add significant latency. Web browsers will shallow-parse data as it arrives in order to start subresource fetches as soon as possible, so delays can have a cascading effect. See also https://hpbn.co/transport-layer-security-tls/#optimize-tls-record-size. If you download a lot of data on a connection (i.e. some MBs) then you should find the the record sizes adjust to optimise for throughput. Cheers AGL
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
