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