Экономим трафик и ускоряем интернет
В эпоху скоростных безлимитных подключений многие из нас перестали задумываться о том, какое количество трафика расходуют те или иные приложения и сервисы, и насколько долго загружаются страницы. В то же время, огромное количество абонентов вынуждены пользоваться лимитным тарифными планами, и подгонять свои запросы под ограничения в 10, 5, и даже 3 гигабайта трафика в месяц, да ещё и при скорости в 1-2 мегабита. Конечно же, первое, что приходит в голову в такой ситуации — меньше скачивать файлов. Понятно, что от скачивания торрентов с Blu-Ray фильмами придётся отказаться. Но, кроме этого, есть ещё ряд менее очевидных потребителей трафика. И в данном материале мы дадим ряд советов, как его расход свести к минимуму, а заодно ускорить серфинг и немного защитить себя от навязчивого рекламного ПО (т.н. «adware»).
Как известно, наиболее тяжёлыми являются медиафайлы и потоковые мультимедиа-сервисы. Увы, но онлайн-кинотеатры и Smart TV не для вас, как ни прискорбно. Ограничьте просмотр видеороликов, а если всё же необходимо взглянуть на что-то важное — выбирайте качество поменьше. Так, если на YouTube выбрать качество 360p, то 20 минут видео вам обойдётся примерно в 120 Мб; но если смотреть в FullHD — то в целый гигабайт. Онлайн-радио или музыка будут расходовать примерно в 3 раза меньше трафика, чем видео в стандартном качестве. Например, одна песня в MP3 занимает порядка 5-8 мегабайт. Единственный совет — ограничивайте аппетиты.
На втором месте по объёмам находится интернет-реклама. Всевозможные баннеры и анимированные картинки, которыми пестрят большинство популярных сайтов, мало того что «сжигают» очень много мегабайт, но также существенно замедляют загрузку страниц. А ещё зачастую несут в себе различную заразу — это бывают и вирусы, и просто нежелательные программы, устанавливающиеся на компьютер без спроса, и никак не желающие удаляться. Чтобы отключить рекламу в браузере, мы настоятельно рекомендуем использовать специальные расширения, например, хорошо зарекомендовавший себя AdBlock Plus. Даже на безлимитках скорость серфинга значительно возрастает, если убрать баннеры и прочую мишуру с веб-страниц.
Многие рекламные баннеры используют технологию Adobe Flash и иные плагины, например, Silverlight. По умолчанию, flash контент автоматически скачивается при загрузке станицы, но это исправимо. Если вы используете Chrome, зайдите в настройки, нажмите ссылку «Показать дополнительные настройки» — нажмите кнопку «Настройки контента», в открышемся окне найдите пункт «Плагины» и включите параметр «Запрашивать разрешение на запуск». Теперь для загрузки наобходимого вам flash контента по нему нужно будет щёлкнуть мышью, а нежелательные объекты сами по себе загружаться не будут (да-да, flash бывает и полезным, ряд сервисов без него работать откажутся). Похожим образом можно сделать в Opera и Firefox (кстати, для последнего есть специальное расширение Flashblock). Блокируя плагины, не забудьте добавить в исключения онлайн-банкинг, площадки электронных торгов, и прочие необходимые и проверенные сервисы (если вы их, разумеется, используете).
Если трафика осталось совсем мало, в настройках любого браузера можно отключить ещё и загрузку изображений (для Chrome, в настройках контента найдите пункт «Картинки» и включите параметр «Не показывать»). Веб-страницы будут выглядеть, мягко говоря, не очень красиво, но текстовая инофрмация на них останется, а мегабайт вы сэкономите прилично.
Совсем не лишним будет упомянуть о существовании бесплатной утилиты AdMuncher. Она в автоматическом режиме блокирует всё вышеперечисленное (не надо заниматься настройкой браузера), причём блокировки можно настраивать. Например, можно разрешить загрузку только маленьких картинок, которые не займут много трафика. К тому же, утилита обеспечивает базовые функции защиты от рекламного и шпионского ПО, умеет блокировать сбор браузером информации о пользователе, и содержит ещё ряд полезных функций. Программа довольно простая и лёгкая, в то же время с огромным функционалом, так что её однозначно рекомендуем. Даже тем, у кого подключение безлимитное.
Забудьте о том, что кеш браузера нужно чистить, и чем чаще, тем лучше. Это — не более, чем миф; само по себе удаление кеша ощутимого прироста скорости не даёт. А вот закачивать изображения и прочие элементы страниц после очистки браузеру придётся заново — и это всё лишний трафик. Поэтому, объём кеша можно даже увеличить.
Напоследок, можно сэкономить ещё, прибегнув к помощи сторонних компаний. Существует ряд сервисов, которые пропустят ваш трафик через свои сервера и сожмут его, тем самым высвободив для вас драгоценные мегабайты. Специальный клиент, установленный на вашем компьютере, получит сжатый поток, распакует его, и передаст в браузер. Из бесплатных сервисов такого рода хотелось бы отметить расширение Экономия трафика для Chrome, функцию Turbo для Opera, и универсальную программу toonel.net. Имейте в виду, что не все веб-сервисы корректно работают со сжатием трафика. Для защищённых соединений сжатие работать не будет, или будет очень слабым. Ну и конечно же, так как в передачу данных вовлекаются сторонние сервера, мы не рекомендуем при включенном сжатии передавать в открытом виде какие-либо конфиденциальные данные, пароли, номера банковских карт, и тому подобное.
Маленький совет — не все веб-сервисы одинаково полезны. 2ГИС или Вектор зачастую с успехом заменяют онлайн-карты, а почтовый клиент (например, Thunderbird) позволит сэкономить трафик на загрузке веб-интерфейса почтового сервера.
Разобравшись с серфингом, перейдём к приложениям. Первым делом, отключите функцию автоматического обновления в настройках операционной системы и используемых вами программ. Следом отключайте отправку всевозможных отчётов об ошибках, статистики использования, получение новостей и подобное. Перефразируя известную поговорку, новое — не значит лучшее, и, если работа компьютера вас устраивает — совершенно незачем тратить 300 мегабайт на обновление драйвера видеокарты. Проверяйте обновления вручную и загружайте только те из них, которые вам действительно нужны. Пожалуй, единственное исключение — антивирусная программа. На обновлениях антивируса лучше не экономить.
Также, хотелось бы упомянуть о пиринговых программах, в частности, торренте. Не забывайте, что эти программы не только скачивают, но и раздают скачанное другим пользователям. А исходящий трафик учитывается наравне со входящим. Если и используете торрент — выключайте его после завершения загрузки (да, я понимаю, что это нехорошо и вообще противоречит духу файлообменных сетей, так что выбор за вами).
Учитывайте, что некоторые программы и сервисы продолжают работать в сети даже тогда, когда вас за компьютером нет. Во избежание лишнего расхода трафика в стиле «оно само что-то скачало», включайте сетевой адаптер компьютера только тогда, когда выходите в интернет, и отключайте его после завершения сеанса связи. Для Windows 7: «Пуск» — «Панель управления» — «Сеть и интернет» — «Центр управления сетями и общим доступом» — «Изменение параметров адаптера» — правой кнопкой по значку сетевой карты — «Отключить» либо «Подключить».
И последнее. Для слежения за израсходованным трафиком, удобно установить программу вроде NetWorx. Но не забывайте заглядывать в личный кабинет абонента — учёт трафика провайдером может вестись немного иначе, и не всегда разница будет в вашу пользу. Если вы используете роутер и несколько компьютеров (смартфонов, планшетов) — личный кабинет остаётся единственным простым средством контроля.
Источник
BGP: некоторые особенности поведения трафика
В этой небольшой заметки хочу коснуться некоторых интересных моментов и особенностей управления трафиком (или попыток управления трафиком) в случае использования протокола BGP. Статья не даст ответ на вопрос о том, как сделать счастье в сети!
Изложенная информация носит познавательный характер и будет похожа на легкое чтиво для специалистов в области телекоммуникаций. Сведения будут изложены в достаточно свободной форме, без излишнего насыщения спецификой. Попробуем ответить на вопрос: «почему трафика нет там, где он должен быть, и есть там, где быть его не должно».
Мы не будем рассматривать назначение протокола BGP со всеми вытекающими последствиями, а сразу возьмем быка за рога.
Исходные данные
Начнем с того, что мы имеем собственную автономную систему, делегированный блок(-и) адресов и одного провайдера. В данном случае связь нашей AS с сетью Интернет осуществляется используя один единственный канал с провайдером. Трафик в нашу сеть (к нашим префиксам) пройдет через этот логический канал, второго мнения тут быть не может. Аналогично с входящим трафиком, весь исходящий трафик пойдет через единственный существующий канал.
Все работает хорошо, но рано или поздно приходит момент, когда возникает необходимость подключения к дополнительному провайдеру. Причин этому множество, но хотел бы немного остановиться на этом моменте. Подключая второго (третьего . ) провайдера клиент пытается обеспечить резервирование каналов, повысить связность, оптимизировать затраты на Интернет (у провайдера А дешевый «мировой» канал, провайдер В может обеспечить скоростное и дешевое включение в локальные точки обмена трафиком) и .
Ситуация с резервированием канала может иметь два основным сценария:
1) имеется основной канал емкостью 1Гбит. Резервный (только на случай резерва) покупается значительно меньшей пропускной способность — например, 100 Мбит. В этом случае стоит осознавать последствия выхода из строя основного канал — конца света не наступит, но клиенты ощутят перемены;
2) резервный канал покупается аналогичной (или близкой к тому) пропускной способность. Такой канал получается не совсем дешевый и очень не хочется что бы он простаивал. Тут администратор начинает шаманить с разными балансировками.
Природно, что сетевой администратор хочет абсолютно точно понимать как трафик входит/выходит/проходит через его сеть. А бы даже сказал — его автономную систему. Так вот, в этом можно на 100% быть уверенным только в том случае, если используется один провайдер. Если провайдеров несколько, то понимание о трафике в сети перерастает в предположения о трафике в сети. И вот почему.
В рукаве администратора несколько механизмом влияния на информационные потоки (local preference, weight, med, as-path, etc.), но на сколько они эффективны? Скажу, что они достаточно эффективны (кто-бы сомневался), но не до конца. Ниже приведу парочку интересных примеров.
1. Исходящий трафик
Предположим что от двух провайдеров мы получаем Full View. Первый провайдер у нас будет основной, второй — резервный. Определяем политику обработки анонсов от провайдера: устанавливаем на префиксы, полученные от первого провайдера, больший local preference (как вариант) чем на префиксы, полученный от второго провайдера.
Рис. 1
В итоге весь исходящий трафик должен пойти по основному каналу. Визуализируем логические каналы (например с помощью Cacti Weathermap) и наблюдаем странную картину: трафик уходит не только через основной канал, но и через резервный. Как же так?
Все дело в том, что один Full View другому — рознь. Посмотрим на то, что мы получаем от провайдеров, в частности, на количество получаемых префиксов PfxRcd (пример взят с реального маршрутизатора):
#sh ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
X.X.X.X 4 AAAAA 3582179 106997 96854566 0 0 4w6d 392986
Y.Y.Y.Y 4 BBBBB 772880 508161 96854556 0 0 6d02h 400394
Сессия с оборудованием X.X.X.X (AS-AAAAA) — основная.
Видим разницу в количестве в 8000 префиксов. Это означает, что если мы будет запрашивать ресурсы, находящиеся в этих 8000 сетях, то будет использоваться резервный канал. Почему так получается? Обратив внимание на эти префиксы (дельту) я заметил, что и от основного провайдера я их получаю, но в агрегированном виде. Имеется ввиду, что вместо 4*/24 мы получаем 1*/22. Кто делает эту сумаризацию? Тяжело сказать, наверное, кто-то из upstream’ов.
Небольшой подитог: даже исходящий трафик способен вытекать тудой, кудой мы не ожидаем.
2. Входящий трафик
В этом случае все с одной стороны проще, с другой сложнее.
Каким образом мы можем влиять на поведение входящего трафика? Классика — искуственно удлинять AS-PATH (prepend), отправлять анонсы провайдеру с некоторыми communities для занижения провайдерского local preference (сражу скажу, что такую возможность предоставляют не все провайдеры, а у некоторых, достаточно не маленьких, даже нет looking-glass. В таком случае коллеги звонят провайдеру и дежурный администратор в телефонном режиме рассказывает какие префиксы он «видит» и с какими атрибутами) и другие значительно менее эффективные методы.
Но как бы мы не старались, в большей мере все зависит от политик провайдера. И если с балансировкой/нагрузкой исходящего трафика все более менее хорошо, то входящий трафик мы будем получать в оба канал, причем в достаточно непредсказуемом соотношении.
Например. Наша AS-A имеет связи с двумя провайдерами: AS-B (основной) и AS-C (резервный). Свои сети мы анонсируем обоим провайдерам, но в сторону резервного мы специально удлиняем AS-PATH (хотим получить трафик в этот канал только при неисправностях с основным).
Рис. 2
Резервный провайдер получает анонсы о наших сетях из двух источников: непосредственно от клиента (от нас) и от своих пиринговых партнеров (пунктирная линия). Во многих случаях приходится сталкиваться с тем, что провайдер считает более приоритетным путем в клиентскую сеть тот путь, который непосредственно соединяет его с клиентом. Для этого он (резервный провайдер) увеличивает значения local preference на анонсы, полученные непосредственно от клиента (в данном случае 200), а не от пира (в данном случае 100). Всем своим соседям он расскажет именно об удлиненном пути (анонсах полученных от клиента), так как BGP маршрутизатор анонсирует дальше только лучший маршрут.
Значит, если трафик будет проходить через автономную сеть провайдера AS-B, то получать мы его будем в основной канал, если через сеть провайдера AS-C — в резервный. В итоге, хотим мы того или нет, но входящий трафик к нам будет «заходить» с обоих каналов. В добавок мы получаем ассиметрию: всячески пытаемся отправить трафик в основной канал, а получаем его и с основного, и с резервного.
Небольшой подитог: при двух и более провайдерах, трафик будет «литься» со всех сторон.
3. Иногда, даже порядок установки сессий играет роль
1. Рассмотрим пример.
Рис. 3
Наша сеть (AS-A) связана с провайдером (AS-B). AS-C, AS-D — другие провайдеры, AS-E — такой-же клиент как и мы. Зеленой стрелкой показано распостранение маршрутной информации, синей — входящий трафик.
2. И тут мы решаем установить связь с AS-E (это наш партнер, не провайдер). Суть связи не в организации дополнительного канала, а в обеспечении резервирования — страховки друг друга. По умолчанию, линк должен быть не нагружен. При возникновении аварий, одна AS подстраховывает другую.
Для этого мы устанавливаем политику на исходящие анонсы в сторону партнера, а именно удлиняем AS-PATH. Для партнерской сети этот анонс не является лучшим, поэтому дальше AS-E его не распространяется.
Рис. 4
3. Но так случилось, что наша сессия с основным провайдером порвалась (или это мы тестировали). В таком случае происходит: красные стрелки — распостранение удлиненного маршрута, синие стрелки — путь трафика в сеть.
Рис. 5
И тоже все в порядке.
Сессия с основным провайдером поднимается. Следует отметить, что провайдер AS-D — это тот случай о котором мы говорили ранее (для клиентов устанавливают повышенный local preference), остальные провайдеры такого не делают, то есть выбор пути основывается на AS-PATH.
4. AS-B принимает анонс от AS-A. Анонс без prepend, стало быть этот путь теперь лучший, и именно он анонсируется далее.
Рис. 6
Видим как далее распостраняется анонс и меняются источники трафика:
Рис. 7
5. В конце концов информация о доступности собственных префиксов AS-A доходит до AS-D. Для этой автономной системы такой путь считается менее приемлемым, так как ранее на обновления от клиента (от AS-E) были установлены более высокие local preference. Итогом этих процессов является такое установившееся состояние:
Рис. 8
Прошу обратить внимание на рис. 4 и рис. 8. Как видно, характер входящего трафика существенно меняется. В этом случае наш резервный канал стал если не основным, то далеко не резервным. Как исправить ситуацию? Для возвращения на круги своя можно положить/поднять сессию с партнером (AS-E), но метод далеко не научный.
Небольшой подитог: я хотел продемонстрировать, что иногда даже порядок установки сессий играет роль и влияет на характер трафика. Можно сказать, что случай слегка надуманный, но взят он из реальной жизни и имеет место быть.
Управления трафиком используя протокол BGP и маршрутизация между автономными системами — комплексный и интересный процесс. Количество факторов, влияющих на информационные потоки, даже больше, чем нам может показаться.
Источник