Linux: медленное квитирование SSL из-за отложенного приветствия клиента

Изучая проблему, затрагивающую кластер прокси-серверов, которые затрагиваются одновременно, я обнаружил странное поведение при установлении соединений SSL.

Симптомом является то, что исходящие HTTPS-запросы выполняются медленнее, чем обычно, когда происходит воздействие, я привязал это к медлительности при завершении подтверждения SSL. HTTP-запросы / соединения не затрагиваются таким же образом.

Проблема, по-видимому, вызвана исходящими соединениями из-за задержки между окончанием трехстороннего подтверждения TCP и отправкой Client Hello по доверенности. После этого рукопожатие завершается нормально, без задержек.

Вот несколько примеров из захватов трафика:

Чтобы api.twitter.com (Задержка 2,4 секунды):

Чтобы graph.facebook.com (Задержка 28,4 секунды):

Даже с повторными передачами во втором примере Client Hello Пакет не должен был так долго выходить.

Некоторые факты / соображения:

• Проблема возникает временно в определенное время дня (около 10:00 и 17:00), затрагивает все хосты и исчезает примерно через 30 минут. позже, одновременно
• это может указывать на внешнюю причину (возможно, сеть), но вывод tcpdump, кажется, возлагает вину на локальный сервер
• ЦП, нагрузка, память и все другие отслеживаемые показатели производительности в это время являются нормальными
• влияет на все удаленные хосты SSL
• влияет на соединения случайным образом, некоторые работают нормально, но многие работают очень медленно
• на пропускную способность (после рукопожатия) похоже не влияет
• как только проблема исчезнет, ​​SSL-соединения с одними и теми же удаленными хостами будут стабильно быстрыми
• тесты проводились с curl и openssl s_client connect, с теми же результатами

Что требует уточнения:

1. Что могло вызвать такую ​​задержку на местной стороне?
2. Может, wirehark меня обманывает?
3. какие еще индикаторы производительности / статистика / команды я мог бы изучить для дальнейшего устранения причин задержки?
4. есть ли сетевой фактор (MTU, буферы приема, фрагментация), который мог бы оправдать такое поведение?
5. как я могу найти доказательства, чтобы прояснить, является ли это сетевой проблемой вне моих серверов?

Версии программного обеспечения:

• Red Hat Enterprise Linux Server, выпуск 5.11 (Tikanga)
• OpenSSL 0.9.8e-fips-rhel5 01 июля 2008 г.
• ядро 2.6.18-416.el5 # 1 SMP среда 26 октября 12:04:18 EDT 2016 x86_64 x86_64 x86_64 GNU / Linux

Изменить: информация о strace

Сделал несколько строк, как рекомендовано в ответе ниже, поймал эти медленные вызовы:

strace -T -o output.strace openssl s_client -connect 104.244.42.66:443 </dev/null

connect(3, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("104.244.42.66")}, 16) = 0 <2.266597>
poll([{fd=4, events=POLLIN}], 1, 5000)  = 1 ([{fd=4, revents=POLLIN}]) <2.387366>
write(3, "\26\3\1\0S\1\0\0O\3\1X\342\24\3556c\354\270T\302\225[\236\317\327\305\205r\177\t/"..., 88) = 88 <0.000034>
read(3, "\26\3\1\0001\2\0", 7)          = 7 <2.556229>
read(3, "\0-\3\1\332\37\254+\240\320\236qA\375\275L\23l\340\355\205x\264\274\273\213\377\323&\345\307O"..., 47) = 47 <0.000011>
read(3, "\26\3\1\v\273", 5)             = 5 <0.000007>
(...)
read(3, "\24\3\1\0\1", 5)               = 5 <2.223115>

В poll() call - это обратный поиск DNS, он выполняет:

sendto(4, "\3623\1\0\0\1\0\0\0\0\0\0\00266\00242\003244\003104\7in-ad"..., 44, MSG_NOSIGNAL, NULL, 0) = 44 <0.000157>

Другие такие poll() звонки в той же трассе быстрые.