Введение
Продолжая предыдущую статью Блог-CSDN-блог о потере TCP-пакетов , проверка потери пакетов подтверждается на уровне среды и сетевого канала.Чтобы блоггеры, занимающиеся последующими расследованиями и решениями, могли отслеживать весь процесс, поделитесь им здесь.
2. Причины потери пакетов — уровень операционной системы
В предыдущей статье были обнаружены случайные потери пакетов при рукопожатии tcp. O&M связалась с персоналом Alibaba Cloud, чтобы проверить, связана ли потеря пакетов с облачной платформой. Alibaba Cloud провела мониторинг системы и обнаружила, что действительно было много явлений потери пакетов.
Alibaba Cloud объясняет, что в kernel-4.19.91-25.1.al7 и более ранних версиях ядра, когда приложение инициирует несколько запросов TCP-подключения одновременно, большое количество TCP-пакетов проходит через таблицу NAT и может получить дублирующиеся порты. Модуль Conntrack обнаруживает дублирование портов на этапе подтверждения и отбрасывает соответствующие TCP-пакеты.
Брандмауэр iptables можно использовать для создания правил фильтрации (filter) и NAT, все дистрибутивы Linux могут использовать iptables. Следовательно, это определяется механизмом Linux, который получает дубликат порта NAT.
У некоторых студентов могут возникнуть сомнения, не изолирован ли k8s, как может быть повторное использование порта? На самом деле, если на физической машине есть контейнер k8s, он действительно изолирован, но при этом также теряется смысл k8s: изолировать ресурсы, которые легко мешают друг другу на физических машинах, таких как диски памяти, и просто использовать один физический машина как услуга.
В производственной среде в основном используется более дюжины сервисов в одной физической возможности, а основной процессор и сетевые порты фактически совместно используются сервисами в контейнере k8s.
Подытожим процесс отправки запроса в текущей среде микросервиса:
IP + Port① Служба x отправляет запрос и преобразует сетевой адрес (пакета данных) через таблицу NAT iptables для получения порта.
②Порт отправляет пакет рукопожатия tcp, а модуль Linux Conntrack выполняет самопроверку и подтверждение ( пакет проходит через nf_conntrack_in(), nf_conntrack_confirm() для создания (нового) и подтверждения (подтверждения) в два этапа )
③Запрос достигает сервисной сетки 1
IP + Port④ Сервисная сетка преобразует сетевой адрес (пакета данных) через таблицу NAT iptables , получает порт и устанавливает TCP-связь.
⑤ Сеть отправляет пакет рукопожатия tcp, а модуль Linux Conntrack выполняет самопроверку и подтверждает ( пакет проходит через nf_conntrack_in(), nf_conntrack_confirm() для создания (нового) и подтверждения (подтверждения) в два этапа )
⑥Операционная система сервера получает пакет запроса подтверждения, получает порт через таблицу NAT iptables и использует этот порт для установления TCP-соединения с клиентской сеткой.
⑦Grid 1 передает данные в Grid 2
⑧ Сервисная сетка 2 получает данные запроса и передает их сервису y для обработки.
Здесь видно, что проблема на этот раз во втором и пятом порте, порт захвата повторяется, и пакет будет отброшен сразу, когда самотестирование linux подтвердит, время ожидания рукопожатия истекло, и tcp снова инициирует рукопожатие.
3. Решение проблемы потери пакетов — уровень операционной системы
Согласно описанию Alibaba Cloud, 4.19 получается последовательно, поэтому это относительно часто.Используйте yum для обновления до 5.x или выше.Ядро 5.X получается случайным образом, а частота дублирования портов относительно низкая.
Это решение является вероятностным. Риск повторной потери пакетов порта все еще существует, но частота будет уменьшаться. Однако Alibaba Cloud провела другие оптимизации. Когда порт неоднократно теряет пакеты, он немедленно уведомляет TCP о повторной передаче, так что задержка быть уменьшена до уровня ms.
4. Решение проблемы с потерей пакетов — уровень обслуживания
Хотя потеря пакетов является проблемой на уровне операционной системы и сети, на уровне сервиса нет решения по оптимизации.Это нельзя назвать решением.Это то же самое, что обновление операционной системы, но частота потери пакетов максимально сокращается.
Согласно позиционированию в предыдущей статье, потеря пакетов — это, по сути, первое рукопожатие, поэтому можем ли мы попытаться избежать создания новых tcp-соединений и использовать их повторно?
Есть еще такой способ. Сериализация json, используемая службой, — это EAGER_DESERIALIZER_FETCH по умолчанию для fastxml.jackson. Когда эта сериализация считывает ответ json, последний \r\n может быть не прочитан, поэтому будет использоваться следующее мультиплексное соединение. Иногда вы обнаружите грязные данные,\r\nзакройте соединение и создайте новое соединение TCP.
Переход на использование FAIL_ON_TRAILING_TOKENS может уменьшить новый TCP в описанной выше ситуации. Воздействие на самого Джексона заключается в том, что если это строка типа "{json}xxxxx" до того, как ее можно будет десериализовать, произойдет сбой после ее добавления, но в обычном бизнесе Такого ненормального json в сцене не будет.
Конечно, это изменение не направлено напрямую на потерю пакетов, а в основном на повторное использование tcp, поэтому эффект вероятен.Новые ссылки неизбежны, и ссылки не будут использоваться постоянно.Это зависит от потери пакетов по сетевым причинам. Когда это просто повторное использование ссылки или создание новой ссылки.
V. Резюме
Наконец, было установлено, что потеря пакета рукопожатия tcp произошла из-за того, что ядро Alibaba Cloud легко извлекло дубликаты портов для установления соединения tcp.Самопроверка Linux подтвердила, что пакет рукопожатия был отброшен, если было обнаружено, что он используется повторно.
Решение состоит в том, чтобы обновить ядро таким же образом (произвольное получение вместо последовательного получения и немедленное уведомление tcp о повторной передаче, когда порт неоднократно теряет пакеты), и служба использует json для настройки FAIL_ON_TRAILING_TOKENS (уменьшает количество новых tcp-ссылок)