Насколько распространены пропущенные пакеты при обмене данными внутри центра обработки данных?

Допустим, у меня есть 2 машины в одном центре обработки данных, но не обязательно в одной стойке.

Насколько распространенными будут отброшенные пакеты при отправке с использованием UDP между этими двумя машинами?

Я спрашиваю , в предположении , что , поскольку существует лишь несколько переключателей на большинстве между машинами , что пакеты не будут упали вообще .

Насколько распространено поступление неупорядоченных пакетов в одном и том же центре обработки данных? Я предполагаю, что есть только один маршрут в 99,9% случаев, поэтому этого не может быть.

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

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

В конечном итоге я пытаюсь решить, использовать ли многоадресную UDP или PGM при обмене данными между различными экземплярами Linode VPS, расположенными в одном центре обработки данных. Информация должна поступить и в порядке. Конечно, UDP не звучит так здорово!

Но если можно ожидать почти идеальной или идеальной доставки в одном и том же центре обработки данных, то это нормально. Но я проверяю это предположение.

Спасибо.

Вы не можете полагаться на UDP для доставки пакетов по порядку, потому что спецификация не предоставляет эти гарантии. Даже в самой идеальной ситуации, когда один кабель Ethernet соединяет два хоста, остается проблема операционной системы, сетевого стека, драйвера NIC и реализации libc, против которой вы пишете.

На каждом шаге в этой цепочке разработчики этого кода будут выбирать НЕ приоритезировать упорядочение пакетов UDP, даже если они поступают по той простой причине, что им это не нужно.

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

В вашей ситуации виртуальная машина будет работать на общей инфраструктуре, которая будет работать на томе, а не на производительности, тогда вероятность прогнозирования порядка получения пакетов UDP будет низкой.

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

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

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

Следует учитывать, что большинство центров обработки данных блокируют дейтаграммы и многоадресную рассылку, чтобы упростить и снизить нагрузку на их сетевую инфраструктуру.

Сам протокол IP / PGM необходимо использовать только в том случае, если у вас включен PGM Router Assist и известны сетевые элементы между сервером и клиентами, в противном случае придерживайтесь PGM, инкапсулированного в UDP, и сохраняющего бремя управления разрешениями приложений.

Если вы используете уровень обмена сообщениями, такой как ØMQ, вы можете отложить выбор IP / PGM, UDP / PGM или оверлейной сети TCP до развертывания и интеграции.

Я написал простое многоадресное приложение .net, которое может измерять отброшенные пакеты под заданным давлением.

Вы можете скачать его здесь: SimpleMulticastAnalyzer .

Наслаждаться.