Почему серфинг / загрузка происходит так медленно при загрузке / синхронизации на Google Drive через Ethernet?

Узким местом является, как вы и предполагали, восходящий поток: если он насыщен загрузкой, это приведет к высокой задержке в TCP ack пакеты (что касается больших загрузок) и DNS-запросов и HTTP-запросов (в отличие от их ответов) - это приведет к очень ощутимой медлительности.

Поскольку большая часть этой задержки возникает из-за очередей и буферизации, решение состоит в том, чтобы уменьшить ваши загрузки примерно до 95% доступной пропускной способности загрузки - это будет держать очереди и буферы близкими к пустым, но не будет существенно препятствовать вашим загрузкам.

Насыщение вашего апстрима НЕ ДОЛЖНО вызывать большие задержки. Вы хотите, чтобы загрузки насыщали ваш апстрим, в противном случае вы бы тратили впустую трафик и имели бы ненужные длительные загрузки. Тем не менее, во многих домашних сетях насыщение вашего восходящего потока приводит к большим задержкам, но это не просто факт жизни, с которым вам приходится мириться и с которым нужно жить, это ошибка, которую можно исправить, а не просто обойти, замедляя ваши загрузки,

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

Если Google Drive использует TCP для загрузки, это не должно усугублять перегрузку или увеличивать задержку, поскольку в TCP есть встроенные механизмы предотвращения перегрузок и контроля перегрузок.

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

Посмотрите на bufferbloat и посмотрите, как на вашем маршрутизаторе устанавливается встроенное ПО, поддерживающее инновации в области защиты от буферов, которые были впервые использованы в проекте CeroWrt, такие как интеллектуальная организация очереди FQ_CoDel (или обычный CoDel) и уведомление о явном перегружении (ECN).

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

То есть, допустим, у вас есть такая ситуация:

• Порт WAN вашего маршрутизатора - Gigabit Ethernet
• Он подключен к модему ADSL2+, установленному для Приложения A, и вы платите за "до 25 Мбит / с вниз, до 6 Мбит / с вверх"
• Вы измерили свою загрузку с помощью http://www.dslreports.com/speedtest (инструмент тестирования скорости DSLReports измеряет буферную загрузку, делая его намного лучше, чем Speedtest.net), и вы получаете только загрузку 400 Кбит / с.

В этом сценарии, поскольку вы знаете, что ваш широкополосный восходящий канал на самом деле измеряет только 400 кбит / с, настройте порт WAN вашего маршрутизатора так, чтобы он передавал только 400 кбит / с к модему. Это, вероятно, будет препятствовать созданию раздутых буферных очередей.

Я столкнулся с этой проблемой, а затем запустил оптимизатор TCP с http://www.speedguide.net/downloads.php и использовал его, чтобы установить для моего соединения оптимальные настройки. Теперь синхронизация с Google Диском больше не убивает мою сеть. Хорошие времена.