Optimizing NGINX TLS Time To First Byte (TTTFB)
Alex
alex at zeitgeist.se
Wed Dec 18 03:59:42 UTC 2013
> Looking at the tcpdump after applying the patch does show ~1400 byte records:
> http://cloudshark.org/captures/714cf2e0ca10?filter=tcp.stream%3D%3D2 [2]
>
> Although now on closer inspection there seems to be another gotcha in there that I overlooked: it's emitting two packets, one is 1389 bytes, and second is ~31 extra bytes, which means the actual record is 1429 bytes. Obviously, this should be a single packet... and 1400 bytes.
I did some empirical testing and with my configuration (given cipher
size, padding, and all), I came to 1370 bytes as being the optimal size
for avoid fragmenting of TLS record fragmentation.
> If you only distinguish pre and post TLS handshake then you'll still (likely) incur the extra RTT on first app-data record -- that's what we're trying to avoid by reducing the default record size. For HTTP traffic, I think you want 1400 bytes records. Once we're out of slow-start, you can switch back to larger record size.
Maybe I am wrong but I was of the belief that you should always try to
fit TLS records into individual TCP segments. Hence you should always
try to keep TLS record ~1400 bytes (or 1370 in my case), no matter the
TCP Window.
More information about the nginx
mailing list