Re: Низкая скорость передачи данных при использовании https

[Maxim Dounin]

Hello!

On Thu, Apr 08, 2021 at 05:28:16PM +0600, raven_kg at megaline.kg wrote:

> Замечено, что по https отдача первого байта происходит на 200мс дольше.
> 
> 
> # curl -s -o /dev/null -w "Connect: %{time_connect} TTFB: 
> %{time_starttransfer} Total time: %{time_total} \n" 
> https://<domain>/robots.txt
> Connect: 0,101801 TTFB: 0,424129 Total time: 0,424269
> # curl -s -o /dev/null -w "Connect: %{time_connect} TTFB: 
> %{time_starttransfer} Total time: %{time_total} \n" 
> http://<domain>/robots.txt
> Connect: 0,099435 TTFB: 0,196609 Total time: 0,196732
> 
> 
> Для меня не новость, что SSL требует время для шифрования, но не 
> слишком-ли много? Ниже выдержки из конфига со всем, что касается SSL:

SSL - это не только затраты процессора на шифрование, но ещё и 
пара дополнительных round trip'ов на собственно SSL handshake.  С 
учётом того, что просто коннект у вас занимает 100ms - 
дополнительные 200ms на SSL handshake без кэширования сессий 
выглядят логично.

В случае TLSv1.3 в теории должно добавляться 1 RTT на handshake в 
типичном случае, но тут уже могут быть нюансы.  Во-первых, важна 
поддержка TLSv1.3 всеми сторонами, а во-вторых, важны настройки: 
можно свалиться в запрос HelloRetryRequest и соответственно 2 RTT.

Вот это вот у вас в конфиге:

>     ssl_ecdh_curve            secp384r1;

в случае curl'а гарантировано приведёт к HelloRetryRequest и двум 
RTT, то есть к 200 миллисекундам задержки в вашем случае.  
Уберите это из конфига, и проверьте с "curl --tlsv1.3" - и 200 
миллисекунд должны подужаться до где-то 100.

Не надо менять ssl_ecdh_curve с auto на что либо другое без веских 
причин.  Остальные параметры SSL, впрочем, тоже не стоит крутить 
без нужды и понимания того, к чему это ведёт - даже если где-то в 
интернете рекомендуют.

-- 
Maxim Dounin
http://mdounin.ru/