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

Question

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

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

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

Звучит ли это правильно? Можете ли вы пролить свет на эту проблему? Кто-нибудь закодировал этот сценарий?

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

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

Answer 1

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

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

Answer 2

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

Традиционно, веб-браузеры ограничивают себя двумя одновременными подключениями к веб-серверу. IE8 увеличил это до шести, разозлив множество администраторов веб-сервера. Подробнее об этой проблеме см. Здесь .

Обратите внимание, что в TCP уже есть алгоритмы управления перегрузкой, которые пытаются насыщать канал даже для одного (1) соединения. Если загружаемые документы не являются крошечными (10 с или более килобайт), вы, вероятно, обнаружите, что открытие тонн подключений к одному и тому же серверу не ускорит процесс и может замедлить их.

Единственный способ, которым может помочь множество соединений с одним и тем же сервером, - это если (а) он сильно загружен и ваша цель состоит в том, чтобы просто поглотить больше, чем ваша «справедливая доля» пропускной способности сервера; или (b) вы загружаете множество крошечных файлов по разным HTTP-соединениям, поэтому у алгоритма TCP недостаточно времени для адаптации к доступной пропускной способности канала.

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