Случайные задержки ресурсов сайта: потеря пакетов из-за ограничения пропускной способности?

Мой веб-сайт загружается медленнее, чем мне кажется, из-за того, что некоторым ресурсам требуется нелепо долгая загрузка с сервера. Я пытался найти причину этого. Я на 95% уверен, что это проблема с сетью, а не проблема с Apache, из-за проведенных тестов (см. Ниже).

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

Гипотеза и вопрос

Моя текущая теория заключается в том, что ограничение пропускной способности нашего colo вызывает потерю пакетов, когда браузер загружает ресурсы параллельно, возможно, на мгновение выше предела пропускной способности. Это разумная теория? Есть ли что-то, что мы можем изменить, кроме запроса большей полосы пропускания, даже если большую часть полосы пропускания мы не используем большую часть времени?

Или есть какой-то другой путь, который мне нужно исследовать?

конфигурация

• Apache 2.4.3 на Fedora 18, процессор и память с большим количеством доступной емкости.
• Гигабитный Ethernet для переключения на восходящую линию 4 или 5 Мбит / с через средство колокейшн.
• Это не очень высокий трафик сайта. Редко больше, чем пара посетителей одновременно.

Тесты, которые я сделал

1. traceroute к серверу нормально. traceroute с сервера, скажем, наш офис останавливается после 8 или около того прыжков. Я предполагаю, что это связано с traceroute трафик где-то блокируется (так как такие вещи, как wget - смотрите ниже - и ssh кажется, в основном работает нормально), но я могу предоставить более подробную информацию, если это уместно.
2. strace на Apache указано, что сервер сразу же обслуживает весь образ без задержки.
3. tcpdump / wireshark показал, что данные изображения были отправлены немедленно, но затем, некоторые пакеты были переданы повторно. Одна трассировка, в частности, показала, что окончательный пакет ресурса был немедленно передан сервером, несколько раз передан повторно, но исходный пакет был тем, который в итоге получил браузер.
4. Хотя иногда я мог воспроизвести проблему при загрузке страницы через wget, это происходило не так регулярно, как в браузере. Моя гипотеза состоит в том, что это потому, что wget не распараллеливает загрузки.
5. Тестирование с iperf было интересно. С помощью iperf В режиме UDP я обнаружил, что у меня практически нет потерь пакетов на скоростях до 4 Мбит / с. Кроме того, я начал видеть ~10% потерь пакетов. Точно так же в режиме TCP небольшое количество параллельных соединений разумно разделяет полосу пропускания между ними. С другой стороны, 6 или более параллельных соединений начали получать шаблон пропускной способности "пилообразная", где соединение иногда могло бы иметь пропускную способность, а не другие времена.

Я был бы рад предоставить более подробную информацию по любому из них, но я не хотел переполнять этот пост подробностями, не относящимися к делу. Я не достаточно разбираюсь в сетях, чтобы знать, какая информация полезна, а какая нет.:-D Любые указатели на другие хорошие инструменты для устранения неполадок в сети будут отличными.

РЕДАКТИРОВАТЬ 1: Уточнил мою почти уверенность, что Apache не виноват, а скорее что-то сетевое или что-то другое.

РЕДАКТИРОВАТЬ 2: я пытался iperf между этим сервером и другим нашим на том же гигабитном коммутаторе, и получил довольно стабильные 940+ Мбит / с. Я думаю, что это исключает большинство аппаратных проблем или дуплексных несоответствий с нашей стороны, за исключением, возможно, восходящей линии связи.

РЕДАКТИРОВАТЬ 3: Несмотря на то, что особенности очень разные, этот пост о проблеме TCP-incast звучит очень похоже, с точки зрения того, что трафик с высокой пропускной способностью перетасовывается по узкому каналу небольшими пакетами и теряет пакеты. Мне нужно прочитать его более подробно, чтобы увидеть, применимы ли какие-либо особенности к нашей ситуации.