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

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

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

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

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

К api.twitter.com (задержка 2,4 секунды): api.twitter.com

Кому graph.facebook.com (задержка 28,4 секунды): graph.facebook.com

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

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

  • Проблема возникает временно в определенное время дня (около 10:00 и 17:00), затрагивает все хосты и исчезает примерно через 30 минут. позже, одновременно
  • это будет указывать на внешнюю причину (возможно, сеть), но вывод tcpdump, кажется, возлагает вину на локальный сервер
  • ЦП, нагрузка, память и все другие отслеживаемые индикаторы производительности при этом являются нормальными время
  • влияет на все удаленные хосты SSL.
  • влияет на соединения случайным образом, некоторые из них работают нормально, но многие из них очень медленные
  • , пропускная способность (после квитирования), похоже, не изменяется
  • после устранения проблемы, 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 () является обратный поиск 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 () в той же трассировке выполняются быстро.

1
задан 3 April 2017 в 13:03
1 ответ

Вы можете попробовать выполнить команды скручивания прямым движением, чтобы увидеть, на какой системе они называются "повесить". Я обнаружил, что эти вещи иногда связаны с DNS поиском (или обратным DNS поиском)

strace curl https://[...]
2
ответ дан 3 December 2019 в 20:26

Теги

Похожие вопросы