В чем причина спайков пауз в паутине?

Question

Я запускаю сервер (который использует tornado python) на одном экземпляре AWS, и я сталкиваюсь с шипами в латентности websocket.

Профилирование времени в оба конца с момента отправки клиенту сообщения веб-камеры, которое сразу же отправляет сообщение ack обратно на сервер, когда сервер получает сообщение ack, дает в среднем < .1 секунду, однако Я отмечаю, что иногда это происходит до 3 секунд. Примечание: при запуске сервера локально отсутствуют всплески.

Что может быть причиной или поправкой на это? Я посмотрел на использование ЦП и увеличился до 40%. Шипы не коррелируют с интенсивным трафиком (обычно 2 или 3 клиента), и Интернет клиента кажется прекрасным. Мне трудно поверить, что экземпляр выходит за пределы возможностей с таким низким использованием.

Answer 1

Тот факт, что шип составляет 3 секунды, на самом деле говорит вам гораздо больше, чем вы можете подозревать, о характере проблемы.

Это потеря пакетов.

TCP, как вы, вероятно, знаете, сказал, что обеспечивает «надежный» транспорт, гарантируя, что передаваемая полезная нагрузка будет отправлена ​​дальним концом в том порядке, в котором она была отправлена, поскольку TCP повторно собирает вещи в правильном порядке до доставки полезная нагрузка. Одним из существенных способов, которым это достигается, является автоматическая повторная передача пакетов, которые считаются потерянными.

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

Это 3 секунды во многих, если не большинстве, реализациях, основанных на стандартах, установленных несколько лет назад в то время, когда пропускная способность и латентность сегодняшних линий передачи были неслыханными, возможно, невообразимыми.

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

Вы увидите повторные передачи трафика, если вы наблюдаете сетевой трафик с помощью сниффера пакетов, хотя это будет служить только для подтверждения того, что это проблема.

Это может быть потеря с сервера на клиент или потеря с клиента на сервер. Последнее, как правило, более вероятно, поскольку клиенты часто имеют более низкое количество доступной полосы пропускания вверх ... но направленность потери пакетов явно не указывает на физическое местоположение, в котором оно происходит. Если ваш клиент не отслеживает местное время, так что время инициации запроса и ответа может быть скоррелировано, вы не знаете, находится ли задержка в сообщении или в подтверждении.

При относительно небольшой нагрузке маловероятно, что проблема на вашем экземпляре или в сети AWS на вашей стороне, и вы, очевидно, не можете подключить сниффера к произвольным точкам в Интернете, чтобы определить проблему.

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

Одним из методов для этого было бы создание преднамеренного объезда для трафика через другое оборудование, расположенное в другом месте, например, в другом регионе AWS или другом облачном провайдере.

Во-первых, вы, конечно, захотите узнать, как эти повторные передачи используются с помощью wirehark.

Затем настройте прокси-сервер в другом месте, используя простой прокси-сервер TCP-соединения, такой как HAProxy, или даже простой инструмент, например redir или socat.

Такая конфигурация будет прослушивать соединения с клиентами, а когда она будет установлена, создаст новое TCP-соединение с пунктом назначения (ваш сервер веб-сервера), но, что важно, они связывают только два соединения вместе с полезной нагрузкой уровень - не уровень TCP, и, конечно, ничего ниже - поэтому повторные передачи будут отображаться только на проводе между этим промежуточным сервером и концом соединения с проблемой потери пакетов. На другом конце не будет доказательств повторных передач - только данные, поступающие позже, чем ожидалось.

Для того чтобы этот тест имел смысл, прокси-сервер должен находиться вдали от сервера и клиента и без какой-либо значимой общей инфраструктуры - следовательно, предложение разместить его в другом регионе AWS. Другая зона доступности в том же регионе может иметь общую интернет-инфраструктуру на некотором уровне, поэтому для этой цели недостаточно далеко.

Если client <--> proxy <--> server показывает повторные передачи TCP на пути между прокси-сервером и сервером, а не между клиентом и прокси-сервером, проблема, вероятно, будет на вашем сервере, его оборудовании, сети или подключении к Интернету, и вам придется действуйте соответственно.

И наоборот (и, я бы предположил, более вероятно), если путь между прокси-сервером и сервером свободен от повторных передач, но путь между клиентом и прокси-сервером по-прежнему грязный, вы исключили сервер и его инфраструктуру в качестве источника проблема. Как действовать зависит от вас, но на данный момент вы знаете, в чем проблема ... нет.

Две другие возможности:

Обе стороны остаются грязными, что является наименее вероятным сценарием. Правило 1 устранения неполадок состоит в том, чтобы сначала предположить, что у вас есть только одна проблема, а не две.

Или обе стороны внезапно и незатронуты, когда трафик использует эту настройку, что предполагает, что ваша тестовая установка маршрутизируется вокруг сломанной части Интернета. Вы «решили», но понятия не имеете. Мы также надеемся, что это не результат, но, учитывая капризы глобального Интернета, не исключено, что ваш стек может включать в себя такие компоненты, как выбор промежуточной конечной точки на основе геолокации и DNS. Это похоже на свертку, но имеет свое место.

Такая тактика на самом деле является частью логики функции S3 transfer acceleration. Содержимое не ближе к конечному пользователю, но TCP-соединение из браузера прекращается на оборудовании в пограничной сети AWS в месте, которое часто приближается к браузеру, а второе TCP-соединение обратно в ведро с полезной нагрузкой, соединенной вместе ... и, да, она быстрее и стабильнее, причем значимость изменения становится более заметной по мере того, как расстояние и качество соединения различаются.