По мне очередная попытка КТ съэкономить на внешке. Поглядим чем это закончится.
Закончится, думаю, не в пользу клиентов. Я пока ограничился баном подсети 212.154.140.64/27. Почему? Читаем далее...
А вообще, кэшировать P2P трафик плохая идея.
HTTP-трафик тоже кешируется, только хитро и незаметно. Это вдвойне плохая идея, потому что не всегда есть зеркало.
Road_Runner, а где Вы эти ссылки видели? Ни разу мне не попадались.
Допустим, качаем файл браузером. Если заглянуть в процесс клиент-серверного общения, то увидим цепочку редиректов:
1) http://download.mozilla.org/?product=firefox-6.0&os=win&lang=ru
2) http://pv-mirror01.mozilla.org/pub/mozilla.org/firefox/releases/6.0/win32/ru/Firefox%20Setup%206.0.exe
3) http://212.154.140.71:9205/.../pv-mirror01.mozilla.org/pub/mozilla.org/firefox/releases/6.0/win32/ru/Firefox%20Setup%206.0.exeНа 2-м шаге мы должны были начать получать данные, но Huawei iCache
подменяет ответ от сервера и отсылает нас на 3-й шаг. Для пользователя это выглядит абсолютно прозрачно, он видит только первую ссылку в своем браузере. Заметить подмену можно по косвенным признакам: если замерить скорость скачивания файла, то она вдвое выше, чем на внешку (с зарубежного сайта качает как с казнета).
Увы, но кеширование работает отвратно, зачастую с Huawei iCache скачиваются устаревшие данные. Например, на сайте лежит одна версия файла, а скачивается совершенно другая (проверено). Представьте теперь, что произойдет с софтом, который рискнет обновиться через Интернет. Но и это еще не все. Дополнительное звено, анализирующее HTTP-трафик, резко ухудшает пинг/время отклика от серверов!
Сообщение отредактировал Wio: 14.08.2011, 04:03:26