Мне просто интересно, что произойдет, если коммутатор теряет слишком много пакетов. Я спрашиваю, потому что у меня есть переключатель, который постоянно перегружен. Это вызвано тем, что люди загружают в сеть тяжелые файлы. У меня есть резервный переключатель на случай, если этот не удастся.
Короткий ответ: "не много". С точки зрения того, что фактически происходит на коммутаторе, пакеты потеряны - и это все. Переключатель не заботится, кроме регистрации факта, что они были потеряны.
Ниже вы узнаете, что именно приводит к потере пакетов, и как сеть в целом справляется с этим.
Опять же, вкратце, реагирование на потерю пакетов осуществляется клиентами, а не коммутатором. Это их ответственность, и единственный контроль, который имеет коммутатор над ним, заключается в настройке его очередей и с такими функциями, как QoS, которые просто определяют приоритет трафика (они не останавливают потерю пакетов).
Коммутаторы используют очереди, чтобы позволить небольшой объем буфера между пакетами, которые входят и выходят из них. Они вроде как кеш и имеют много похожих функций. Как правило, вы хотите, чтобы пакет входил в коммутатор и выходил прямо. Это самый быстрый способ, но это не всегда возможно.
Если у вас есть несколько клиентов, соединяющихся в соединении, которому не хватает пропускной способности, или вы подключаетесь через узкую полосу пропускания к месту назначения, пакеты не могут быть отправлены так быстро, как они поступают в устройство.
Дополнительные пакеты будут накапливаться в очередях, используемых в коммутаторе, в надежде, что это был пакетный пакет, и что до полного заполнения кэша будет меньше пакетов, и он сможет «догнать» себя.
Если кэш заполнен, то это означает, что любые другие входящие пакеты не имеют места для хранения, и именно здесь пакеты отбрасываются - они просто отбрасываются до тех пор, пока в очереди не будет достаточно места.
Реальным примером этого может быть файловый сервер в офисе. Скажем, у вас было 48x100 Мбит / с подключений и 2x 1 Гбит / с подключений (где 48 для клиентов, а 2 гигабита связаны с сервером). Если бы никто больше не пытался связаться с сервером, тогда клиент мог бы счастливо использовать свое полное соединение со скоростью 100 Мбит / с (конечно, с дополнительными издержками). Но как только более 20 человек захотят получить доступ к файловому серверу, уже имеющему 2 Гбит, и 21-й человек не сможет это сделать.
Пакеты начнут добавляться в очередь по принципу «первым пришел - первым обслужен» и выпущены с использованием установки приоритетов, настроенной на коммутаторе - как правило, «первым пришел - первым обслужен» (FIFO), когда не настроена такая конфигурация, как QoS. Когда этот буфер становится заполненным (слишком много пакетов), тогда пакеты полностью отбрасываются, и клиенты должны понять и что-то с этим сделать.
Типичный результат будет иметь в качестве средней пропускной способности available_bandwidth / (number_of_clients * bandwidth_of_clients) . Где скорость каждого клиента пропорциональна скорости их соединения с коммутатором. Это не столько детерминированное проектное решение, сколько результат вероятности того, что пакет поступит из одного из портов, как только освободится место в очереди.
Программное / аппаратное взаимодействие должно идентифицировать, что пакеты отбрасываются, и реализовать ограничение скорости, чтобы уменьшить объем данных, пытающихся быть отправленными. Тем не менее, если, конечно, данные являются UDP (обычно в приложениях реального времени), то никаких ACK-сообщений нет, поэтому он не будет знать о каком-либо ограничении скорости.
Как правило, ограничение скорости - это то, как весь трафик определяет самую высокую скорость, с которой он может отправлять. Например, у вас может быть соединение в 1 Гбит / с с маршрутизатором в простой сети, но тогда будет загружена только скорость загрузки 20 Мбит, и когда вы попытаетесь отправить больше, чем ваши пакеты, будут отброшены, ПК не получит ACK, и ограничение скорости наложено так, что соответствует максимальной скорости, которую он может достичь по всей сети (включая интернет) до места назначения.
В TCP алгоритм Nagle используется для наложения этого ограничения скорости, но в UDP-соединении результатом, вероятно, будет снижение качества (для таких вещей, как видеопоток) или просто сбой, но невозможность получения достаточного количества данных должна явным образом исходить из пункт назначения, а не из-за отсутствия подтверждения.
