Мега пупер быстрый кешированный интернет

[Ism]

Дело в том, что squid гораздо эффективнее работает с кешем, в отличие от браузера.
Покопал настройки и оказалось что толку refresh_pattern не особо много, все получается ценой некорректности работы страниц

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

[drBatty]

другие пути ограничения именно потока входящих пакетов, теоретически, существуют, но я, увы, о них не знаю·

почему нельзя DROP'ать лишние входящие пакеты, когда их слишком много?

Дело в том, что squid гораздо эффективнее работает с кешем, в отличие от браузера.

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

[Ism]

Дело в том, что squid гораздо эффективнее работает с кешем, в отличие от браузера.

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

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

[drBatty]

Ну если плохой ДНС , то никакой толстый канал не поможет.

кеширующий прокси тоже. А вот свой BIND - вполне.

С другой стороны если SSD винт, то с проксей на десктопе будет лучше даже на толстом канале.

по тестам - возможно. Мне и так хорошо.

Также у squid есть еще возможность выделить оперативную память для кеша, если оперативы много , то можно дат 2 гига, тогда вообще самолет.
Браузеры тоже это умеют, но гораздо хуже

ну хозяин - барин.

[Ism]

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

[drBatty]

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

нет. Качки как качали 100500 гигов прона, так и будут качать. Веб это капля в море.

[Ism]

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

нет. Качки как качали 100500 гигов прона, так и будут качать. Веб это капля в море.

Может быть, скорее проблема в видеохостингах , их не закешируешь

Интересную ссылку нашел , объясняется как настраивать конфиг http://diesel.elcat.kg/lofiversion/index.php?t553040.html

[drBatty]

Может быть, скорее проблема в видеохостингах , их не закешируешь

а... дык вот почему тытрубу закрывают! а всё "невинность мусульман" якобы... Но мы-то знаем.

[sash-kan]

другие пути ограничения именно потока входящих пакетов, теоретически, существуют, но я, увы, о них не знаю·

почему нельзя DROP'ать лишние входящие пакеты, когда их слишком много?

вы у меня спрашиваете?
тогда — да, разрешаю: делайте с уже пришедшими к вам пакетами что угодно·
можете даже называть этот процесс «ограничением входящего канала»·
или любым другим удобным вам термином·
я не против·

[pelmen]

Или вы собираетесь задерживать P2P пакеты, пропуская без задержек пакеты на 22й и 80й порт? Не думаю, что это даст значительный выигрыш.

Вот здесь кроется корень разногласия. Вы не думаете, а мы знаем, что это даст значительный выигрыш. Попробуйте на забитом торрентом канале открыть сессии по 22 или 80 портам. И вы поймете, что работать так просто невозможно. И вы захотите выставить преоритеты таким образом, чтобы "задерживать P2P пакеты, пропуская без задержек пакеты на 22й и 80й порт" (выражаясь вашими же словами). А для того, чтобы задерживать P2P пакеты необходимо взаимодействовать с отсылающей стороной, как верно вам сказал sash-kan. А взаимодействие это видится возможным только так: отбрасывать входящие от этой стороны пакеты, таким образом клиент наш, ожидающий эти пакеты и, в итоге, не получивший их, не посылает подтверждения о приёме этих пакетов. Посылающая сторона не получив подтверждения о приёме пошлет пакет повторно, но уже подождав некоторое время (типа "вдруг временно разрыв связи был. Подожду несколько сот милисекунд"). Получается, что некоторые пакеты будут посланы повторно, что увеличит объем передаваемой информации. НО! этот объем информации растянется на значительно бОльшее время, непропорционально бОльшее. (например, объем информации увеличится на 1%, но при этом время, за которое эти 101% передадутся увеличится на 10%). Таким образом, уменьшая количество информации, передаваемое за единицу времени, мы разгружаем канал. Высвободившуюся полосу любезно предоставляем более преоритетному трафику (22 или 80 порт, например). И в итоге действительно, как вы и сказали, фильм будет скачан не за 55 минут, а за 60, что, как, опять же, вы сказали, для вас не принципиально.
А разобраться я не могу в синтаксисе tc
Уж больно мудрёно там всё...
И таки да, man tc мне в помощь, но видимо не настолько оно мне нужно.

[liaonau]

Да, так удобнее намного. По результатам личного опыта могу посоветовать дисциплину hfsc, а не hfb как советуют в большинстве howto, для страниц в браузере (небольшого размера), самое оно.
Man tc очень короткий как будто бы написан для сверхразумных инопланетян, лучше все же прочитайте LARTC.
Кстати, для htb дисциплины есть htbinit, там с синтаксисом вроде бы попроще. Мне лично не нравится, но может быть кому-нибудь подойдет.

[Ism]

Я лоханулся, в dnsmasq надо так

interface=lo
bind-interfaces
cache-size=3000
local-ttl=3600

Может первый вариант и работал, но так правильней

Правда не совсем понял как работает bind-interfaces, но везде рекомендуют это включать