Пользователь
0,0
рейтинг
4 апреля 2013 в 16:41

Youtube

Приходится ждать загрузки видео >360p по несколько секунд, обрывы на середине просмотра стало уже обыденным делом и это с достаточно широким каналом.
image
Причина в занижении провайдерами скорости к серверам кеширующим видео, всё что нужно сделать это заблокировать доступ к ним.
Для того чтобы запрос шел мимо cdn серверов ютуба надо заблокировать диапазон ip адресов (в роутере или на компьютере)
173.194.55.0/24 и 206.111.0.0/16

под виндой (кроме xp) при включенном брандмауэре достаточно открыть cmd с правами администратора
netsh advfirewall firewall add rule name=«youtube» dir=in action=block remoteip=173.194.55.0/24,206.111.0.0/16 enable=yes

в маке
sudo ipfw add reject src-ip 173.194.55.0/24 in
sudo ipfw add reject src-ip 206.111.0.0/16 in

linux
iptables -I INPUT -s 206.111.0.0/16 -j DROP
iptables -I INPUT -s 173.194.55.0/24 -j DROP
@xjunkiex
карма
1,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (179)

  • +18
    Заглавная буква в начале предложения для слабаков!
    • 0
      fxd
      • +19
        вторая попытка
      • +6
        А теперь сделайте это связным текстом, а не кучкой несвязных мыслей. Я вам помогу:
        Причина в занижении провайдерами скорости к серверам кеширующим видео, всё что нужно сделать это заблокировать доступ к ним.

        Кому нужно сделать? Зачем? Догадаться легко, но на парсинг приходится прилагать усилия. Исправляем:

        Причина этой проблемы состоит в занижении провайдерами скорости к серверам, кеширующим видео. Для её решения достаточно заблокировать доступ к кеширующим серверам.
        • 0
          Какие вы скучные…
          • +13
            Не теряйте надежды, грузовик со смайлами гуманитарной помощи уже выехал!
                _______________________
               |                       |h_ __
               |  )))))))))))))))))))  ||=|##L_
               |________________.====._||_|__._]
                `(_)(_)`       `(_)(_)"""="=(_)


            Чтение ithappens поможет вам продержаться до его прибытия.
  • +2
    А какие провайдеры занижают скорость к ютубу? Может, лучше их боком обходить (разумеется, если есть альтернативы)?
    • +3
      Ростелеком (ХМАО), другие провайдеры не доступны.
      • +3
        Почему вы думаете. что Ростелеком режет скорость ютьюба?
        • +2
          потому что я не могу комфортно просматривать видео на скорости 5Мбит/с после внесения этих правил проблема исчезла, но да — можете считать это плацебо, лишь бы работало.
        • +5
          У меня onlime 80Мбит/с
          Открываем 720p размером в 1 минуту и ждем его загрузки минут 5.

          Если использовать плагины для скачивания видео с сайта, то это видео скачается на комп за 20 сек.
          • +4
            у меня 30-ка тоже онлайм, 720р даже минуту не могу посмотреть
            • 0
              Аналогичная проблема… Причём на разных видео по-разному, бывает и не тупит сильно
          • +1
            Подтверждаю, такой же канал — смотреть невозможно.
          • +2
            Так как как из этого вытекает, что это провайдер намеренно режет ютьюб? Если использовать за основу идею топикстартера, то есть некий диапазон адресов, который шейпит злобный провайдер. При этом когда вы качаете видео с сайта вы качаете его ровно с тех же адресов, как и при обычном просмотре.
            • 0
              Этот эффект — когда скачивание быстрее, чем кеширование в плеере — я тоже наблюдал.
              Я думаю, шейпер встроен гуглом во флеш-плеер, чтобы нагружать свои сервера в соответствии с битрейтом просматриваемого видео. Но иногда этот шейпер глючит
              • +3
                Я думаю, шейпер встроен гуглом во флеш-плеер

                Во-первых, не шейпер, а полисер. Такие вещи не шейпят.
                Во-вторых, по дампу пакетов четко видно, что потери односторонние, причем тех пакетов, что отправляю я в сторону ютуба (ACKи), а не тех, что он присылает мне. По последнему дампу — многократные дропы в течение 200 миллисекунд за каждые полторы секунды, сплошные ретрансмиты ACKов. Сбивает окно к чертовой матери, длительные паузы, когда ютуб раз за разом шлет мне один и тот же пакет. И ни одного пакета от ютуба потеряно не было, при этом видео тормозило страшно.

                Предвосхищая комментарии: исходящий канал у меня занят на 30-40кб/с из пары десятков мегабит.
                Онлайм (Ростелеком).
                • +3
                  Что-то я глупость написал. После пива траблшутинг не идет…

                  Да, есть дропы пакетов от ютуба. По одному раз в полторы секунды. Оно и сбивает окно.
                  Меня смутило наличие множества отправленных подряд одинаковых ACKов, что ожидаемо при таком RTT.
                  • 0
                    Глупость вы сейчас написали. Какому админу пиво мешает? :)
                    • +2
                      А кто тут админ? =)
                      • +1
                        А, тогда пардоньте
                • 0
                  Ну откуда в флеш-плеере полисер? :)
                  Проблема с гугловым cdn известна давно, гугол неоптимально раскладывает клиентов по кешам. Есть мнение что делается это специально для стимулирования операторов к установке локальных кешей. ТС просто заблокировал самые тупые кусочки cdn и все заработало.
                  • 0
                    Только вот кэш от гугла могут получить очень немногие операторы.
                    • 0
                      И какие же там сложности кроме необходимого объема трафика?
                      • 0
                        Собственно, никаких.
                  • +1
                    Ну откуда в флеш-плеере полисер?

                    Какое-то средство ограничения скорости с точки зрения здравого смысла должно быть. Допустим, человек с быстрым каналом открыл видео длиной в час, посмотрел первые пару минут и закрыл его. Стоило ли скачивать его целиком? Наоборот, загрузка должна идти со скоростью чуть выше, чем скорость просмотра.
                    Конечно, обычно такое реализуется отправкой пакета с нулевым окном для притормаживания процесса. Но мало ли…
                    • 0
                      Думается мне что скорость регулируют на стороне cdn, а не на стороне плеера.
          • +1
            подтверждаю, аналогичный тариф, вечером смотреть ютуб просто нереально (Москва)
          • 0
            А вам совет из поста помог? У меня тоже онлайм и та же проблема.
        • 0
          Подтверждаю. Проще видео зачастую с торрентов скачать в лучшем качестве, чем ждать пока загрузится на Ютубе. Да и заикания тоже бесят.
      • –4
        Ростелеком вообще забавный провайдер, у меня друг работает в томском филиале специалистом по недвижимости, так у них там органичение по траффику в месяц, что-то около 100 или 500 мегабайт
        • +1
          Cool story, bro
          • –1
            Это к тому, что если они даже сотрудникам не могут предоставить безлимитный интернет, то вполне могут и пользователям ограничивать
    • +1
      Ну, например, Электронтелеком занижает скорость ютуба. Альтернатива в доме только «ужас-ужас Северо-Западный Телеком».
      • +1
        Пользуюсь Мега Авангард более 3 лет. PON по оптике. Никаких сбоев вообще практически не было. Скорость не режет. Скорость закачки с локальных пиров выше тарифной. Поддержка правда ужасная, узнать что либо очень сложно. Подозреваю, что мы соседи, рядом с заливом.
      • 0
        СЗТ очень неплох как провайдер.
    • +2
      Starlink. Официально заявили что это проблема ютуба и они «ведут переговоры» с гуглом. Но мы то с вами знаем…
      • +28
        Официально заявили что это проблема ютуба и они «ведут переговоры» с гуглом

        image
      • +1
        Да им вообще пофигу, 4 года народ жалуется, можно ссылку на офицальное заявление?
      • +6
        Вот, держи: ,,
        • 0
          Там можно обойтись одной дополнительной запятой.: Р «Если однородные придаточные связаны одиночным соединительным или разделительным союзом (и, да в значении «и», или, либо), то запятая между придаточными предложениями не ставится». Пруф.
          • 0
            Точку еще надо подарить.
    • +3
      Эр Телеком
    • 0
      Новосибирск, академорг. Два года уже ютубом пользоваться невозможно. Люди даже к другим провайдерам из-за этого уходят.
      • –1
        И правильно делают.
  • +3
    Зачем вы даете вредные советы?
    • НЛО прилетело и опубликовало эту надпись здесь
      • +4
        автор один и тот же, если что.
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            реплика была в дополнение, а не возражение.
      • +23
        Вот зачем кидать ссылку на лепру, на которой у большинства нет аккаунтов?
        • –21
          на случай если у кого-то все-таки есть аккаунт
        • +18
          Зачем давать ссылку на лепру, которой не существует
  • +42
    Ну когда уже видео загрузится на картинке?!
  • +39
    Так и не дождался, когда видео загрузится :(
    • +24
      Я обновлял комменты. Честно!
      • +76
        А если бы не обновляли, то успели бы написать свой — первым)
        • 0
          Вывод: Сначала напиши коммент, потом обновляй.
    • 0
      Я так и не дождался! Что там на видео? (( Интересно прям…
    • 0
      Люди делятся на 2 типа: те, кто обновляют комменты, и те кто пишут первые =)
  • +22
    Еще хорошим тоном было бы привести команды для отмены блокировки…
    • 0
      Как-то так:
      windows:
      netsh advfirewall firewall delete rule name=«youtube»

      Mac:
      sudo ipfw del reject src-ip 173.194.55.0/24 in
      sudo ipfw del reject src-ip 206.111.0.0/16 in

      Linux:
      sudo iptables -D INPUT -s 173.194.55.0/24 -j DROP
      sudo iptables -D INPUT -s 206.111.0.0/16 -j DROP
  • +16
    Во-первых, сама идея «а давайте отхреначим кусок гугловой подсети и посмотрим чо будет» выглядит странно.
    Во-вторых, вся эта идея берет свое начало в блоге какого-то американского дядьки. Вы уверены, что будучи в России, ходите на те же самые сервера? Ради интереса можете поснифать трафик ;)
    В-третьих, у кучи провайдеров гугловые кеширующие сервера стоят на их же площадке. Этого никто не афиширует, потому что гугль запрещает это делать, пока Google Global Cache в бете находится, но если у вашего провайдера абонентов эдак тысяч 50, то скорее всего, кешировалки у него либо уже стоят, либо готовятся к установке.
    • +1
      если это работает — то очевидно что на теже, тут же банится вся подсеть cdn серверов.
      у кучи провайдеров может и стоит, но ни у одного человека (в Тюмени и ХМАО) я еще ни разу не видел чтобы ютуб нормально проигрывал видео
      • 0
        А с чего вы взяли, что оно работает? Ну, кроме плацебо =) Раньше что, оно ходило на какой-то из забаненных адресов?
        • –4
          с того что я постоянно смотрю подборку ютуб видео в серии постов tusinida на leprosorium.com и ежедневно встречал эти проблемы, теперь же ситуация изменилась!
          Возможно дело в том, что в посты добавляется только свежее видео с видеорегистраторов и эти видео в течении нескольких часов (после публикации на ютуб) расходятся по всевозможным ручп, автовидео и прочим ресурсам, а под большим внезапным ростом просмотра у видео гугл копируется их на cdn
          • +25
            Мы же на техническом ресурсе все-таки, хотелось бы фактов, результатов тестов, данных о том, откуда тянулись ролики до, откуда стали тянуться после, как изменилась скорость загрузки по версии ютьюба и так далее. Просто видите ли, с Хабра эти советы расползутся теперь по всему рунету, и куча людей будет слепо им следовать, потому что так на Хабре написали. Примерно так же ходят копипасты последовательностей загадочных действий, которые пинг в онлайн игрушках могут уменьшить, хотя при ближайшем рассмотрении оказывается, что эти методы в принципе, даже теоретически не могут на что-то повлиять. Здесь то же самое, польза от всего этого вашего шаманства весьма сомнительна.

            Самый главный вопрос: если вы уверены, что ваш провайдер шейпит ютьюб, то почему вы считаете, что он шейпит именно эти два диапазона? Потому что об этом написал какой-то американский дядька? =)
            У меня рандомный ролик тянулся с tc.v13.cache5.c.youtube.com [208.117.238.144], ни в один из забаненных вами диапазонов он не попадает.
            • 0
              А рандомный ролик тормозил или нормально проигрывался?
              • 0
                Нормально проигрывался.
                • –3
                  Ну так это значит он был из «хорошей» подсети, которую банить и не нужно, так?
                  • +9
                    Да с чего вы в принципе взяли, что есть «хорошая» подсеть, а есть «плохая»? Вы взяли непроверенный факт и теперь пытаетесь оперировать «от обратного». =)
              • 0
                Мой рандомный ролик шел с 208.117.250.202. Тормозил.
            • –1
              Смотрел это видео: www.youtube.com/watch?v=HEe3xfWfkG8

              Решил проверить с какого откуда грузится ролик.

              Оказалось отсюда: o-o---preferred---sn-n8v7ln7z---v19---lscache2.c.youtube.com

              Пропинговал.

              Pinging o-o.preferred.sn-n8v7ln7z.v19.lscache2.c.youtube.com [173.194.18.85] with 32 bytes of data:
              Reply from 173.194.18.85: bytes=32 time=51ms TTL=54
              Reply from 173.194.18.85: bytes=32 time=51ms TTL=54
              Reply from 173.194.18.85: bytes=32 time=52ms TTL=54
              Reply from 173.194.18.85: bytes=32 time=51ms TTL=54

              Ping statistics for 173.194.18.85:
              Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
              Approximate round trip times in milli-seconds:
              Minimum = 51ms, Maximum = 52ms, Average = 51ms

              То есть ip: 173.194.18.85.

              Очистил кэш и куки в хроме(DNS кэширование на компе и так отключено). Повторил процедуру. Выдался тот же ip.

              После чего заблокировал ранг айпишников 173.194.18.0/24.

              Снова начал скачивать это же видео. DNS тот же, т.е. o-o.preferred.sn-n8v7ln7z.v19.lscache2.c.youtube.com

              А вот ip уже поменялся.

              Pinging o-o.preferred.sn-n8v7ln7z.v19.lscache2.c.youtube.com [74.125.168.150] with 32 bytes of data:
              Reply from 74.125.168.150: bytes=32 time=2ms TTL=59
              Reply from 74.125.168.150: bytes=32 time=2ms TTL=59
              Reply from 74.125.168.150: bytes=32 time=5ms TTL=59
              Reply from 74.125.168.150: bytes=32 time=3ms TTL=59

              Ping statistics for 74.125.168.150:
              Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
              Approximate round trip times in milli-seconds:
              Minimum = 2ms, Maximum = 5ms, Average = 3ms
              • 0
                Не надо с ним спорить, этот человек постоянно защищает бредовые инициативы провайдеров, в прошлый раз, в посте про цензуру даже кичился, что у него есть некое письмо с разъяснениями по этому закону с чёрными списками, но выложить не смог. В общем, мутный персонаж, думаю, проще не тратить на него силы вообще
                • +2
                  «Этот человек» пытается рассказать, как на самом деле обстоят дела. И не не не смог, а не стал. ;)
                  • 0
                    Ну так расскажите, не стесняйтесь. А то заинтриговали же :)
                    • +3
                      По-моему, я исключительно этим и занимаюсь в этом тредике :)
              • +5
                Прежде чем я отвечу более предметно, не могли бы вы объяснить один забавный факт? 74.125.168.150 это Mountain View, United States. От Тюмени до этого города по прямой что-то около 9500 километров, судя по данным вольфрам-альфы. Если допустить, что прямо между ними лежит оптика, то на передачу данных потребуется 44 ms. У вас же пакеты долетают за 2ms. Не могли бы вы объяснить, как у вас так получается?
                • 0
                  кто сказал что я в тюмени?
                  • +3
                    Вы писали habrahabr.ru/post/175473/#comment_6095955 и habrahabr.ru/post/175473/#comment_6096109
                    Возможно, я не так понял? В профиле написано, что Вы из Москвы. Ок, между Москвой и Маунтин Вью около 9000 км. Вопрос тот же. Как вы получили цифру в 2мс?
                    • +4
                      Хорошо, будем считать, что скорость света это не предел, и при необходимости в оптике он даже может почти в 10 раз ускориться. Продолжим же разбирать ваш забавный эксперимент. Если я правильно понял написанное, вы сначала пингуете какой-то домен, получаете первый ip адрес, после этого блокируете фаерволом входящий трафик с подсети, в которую входит первый адрес. Далее вы вновь резолвите тот же домен и получаете второй адрес, не из заблокированного диапазона. Допустим, все так и было, угу. :)
                      Вопрос заключается вот в чем: почему вы считаете, что эти два события вообще связаны? DNS сервер, который в конечном итоге возвращает вам ip адрес ресурса, не имеет ни малейшего понятия о том, какие правила фильтрации входящего трафика установлены на вашем компьютере.
                      • –5
                        мне было лень отключать правила ради тролля, я просто скопировал результаты тестов
                        forum.onlime.ru/index.php?showtopic=12736&st=220
                        • +4
                          Не пытайтесь видеть троллинг или оскорбления там, где их нет. Я нисколько не хочу обидеть Вас, либо кого-то еще. Наоборот, я пытаюсь объяснить, где именно вы неправы и почему.
                          Если вам лично кажется, что некий набор действий решает вашу проблему, то окей, ради бога. В конце концов, куча людей верило, что если нарезать мышкой круги при загрузке винды, то процесс пойдет быстрее. :)
                          Просто публикация на хабре ведет за собой определенные последствия, ее неминуемо растаскивают по блогам, всяким там фишкам и прочим ресурсам, после чего она становится в глазах обычного пользователя непреложной истиной. Сейчас народные массы начнут бездумно блокировать здоровенные куски гугловых подсетей, что приведет к большим проблемам, если гугл вдруг начнет отдавать что-то с адресов из этого диапазона. Собственно, это неоднократно уже бывало ранее, правда в несколько меньших масштабах.
                • +3
                  А с чего вы взяли, что машинка с таким адресом находится в Mountain View? Можно элементарно поднять много машин с этим адресом на loopback адаптере и светить в ближайшую от каждой из машин точку пиринга (точнее, в свой бордер роутер) маршрутом через себя с низкой стоимостью. Anycast называется. Каждый волен развлекаться как угодно внутри своей автономной системы, главное — отдать маршрут через BGP.

                  Вот картинка, чтобы понятнее было:
                  image
                  • +4
                    И стоит эта машинка, судя по 2 мс пинга до нее, где-то у моего уважаемого оппонента прям рядом, ага. Такой нежданный сервер гугла ВНЕЗАПНО появляется и исчезает на просторах России. При этом пингуется, опять же, только им. Seems legit. :)
                    • +1
                      Я не защищаю автора, а рассказываю вам про технологию, как айпишник может внезапно появляться в разных точках планеты, да ещё и одновременно. Смотрите, вот я из виртуалки, да ещё и за домашним роутером, пингую ya.ru:

                      PING ya.ru (93.158.134.3) 56(84) bytes of data.
                      64 bytes from www.yandex.ru (93.158.134.3): icmp_seq=1 ttl=59 time=4.62 ms
                      64 bytes from www.yandex.ru (93.158.134.3): icmp_seq=2 ttl=59 time=4.22 ms
                      64 bytes from www.yandex.ru (93.158.134.3): icmp_seq=3 ttl=59 time=3.83 ms
                      64 bytes from www.yandex.ru (93.158.134.3): icmp_seq=4 ttl=59 time=3.95 ms


                      С таким же успехом это мог быть кеширующий сервре гугла, стоящий в Москве, пинги были бы сравнимы. Например, открыл с хост-машины (винда) ролик, хром сказал мне, что качается он с адреса r5.sn-n8v7lnez.c.youtube.com. Попинговал (из виртуалки, по непонятной мне причине, пинги туда не идут):

                      C:\>ping r5---sn-n8v7lnez.c.youtube.com
                      
                      Обмен пакетами с r5.sn-n8v7lnez.c.youtube.com [74.125.110.20] с 32 байтами данны
                      х:
                      Ответ от 74.125.110.20: число байт=32 время=4мс TTL=59
                      Ответ от 74.125.110.20: число байт=32 время=4мс TTL=59
                      Ответ от 74.125.110.20: число байт=32 время=4мс TTL=59
                      Ответ от 74.125.110.20: число байт=32 время=4мс TTL=59
                      
                      Статистика Ping для 74.125.110.20:
                          Пакетов: отправлено = 4, получено = 4, потеряно = 0
                          (0% потерь)
                      Приблизительное время приема-передачи в мс:
                          Минимальное = 4мсек, Максимальное = 4 мсек, Среднее = 4 мсек


                      Маршрут туда:

                      C:\>tracert r5.sn-n8v7lnez.c.youtube.com.
                      
                      Трассировка маршрута к r5.sn-n8v7lnez.c.youtube.com [74.125.110.20]
                      с максимальным числом прыжков 30:
                      
                        1    <1 мс    <1 мс    <1 мс  dir-320 [192.168.0.1]
                        2    10 ms     3 ms     1 ms  supernw.ultra.net.ru [10.7.3.14]
                        3     1 ms     1 ms     1 ms  gw4.ultra.net.ru [10.7.5.48]
                        4     2 ms     2 ms    21 ms  midgard.tor.asgard.digitonenet.com [81.25.61.33]
                      
                        5    26 ms    24 ms    21 ms  msk-ix-gw1.google.com [193.232.244.232]
                        6     3 ms     4 ms     4 ms  216.239.47.149
                        7     4 ms     3 ms     3 ms  74.125.110.20
                      
                      Трассировка завершена.


                      Конечно же я не могу гарантировать, что они этим айпишником ещё куда-то светят, но технически могут. Гугл много с кем пирится, можете в чьём нибудь bgp looking glass список пиров поглядеть.
                      • 0
                        Я нисколько не отрицаю сказанное вами =)
  • +6
    Только 1 вопрос: как потом убрать эти правила? Для мака, например.
    • –1
      ipfw –q delete 100 > /dev/null 2&>1
      ipfw –q delete 200 > /dev/null 2&>1
      • 0
        при условии что при добавлении правил они закрепились за номерами 000100 и 000200
        • 0
          посмотреть список правил с номерами ipfw list
  • +27
    Если дождаться загрузки ролика из топика, то покажут мультик.
    • +2
      Точно, ну погоди.
    • +1
      Мультик про змейку, гоняющуюся за своим хвостом.
  • 0
    А чего именно эти аипишники-то? У меня у прова допустим CDNы:
    95.83.191.4
    95.83.191.5
    95.83.191.6
    И с ними буфферизация видео стремится к 100мбитам))

    image
    • 0
      а зачем ограничивать в вашем случае? Если у прова стоят cdn гугла то вообще ни каких проблем не должно быть
    • 0
      А чем (откуда) это вы такую интересную картинку сделали?
      • +1
        Правой кнопкой по youtube ролику — «Показать информацию о видео», такая статистика только для flash плеера, у html5 плеера она немного другая.
  • –6
    С лепры на хабру, отличный план.
    • +18
      план и правда отличный. не все сидят на лепре.
      • +1
        В этом случае хорошим тоном было бы указать источник. А лучше на первоисточник
        • 0
          я на лепре писал, повторю и тут — инфу получил в maillist, без ссылки на источник
          • +3
            Ах, точно, извиняй.
  • 0
    Вроде помогло. До этого момента и не думал что у меня в маке запущен и работает ipfw :-)
  • –1
    Можно универсальный способ :)
    loginsin ~ # route add -net 206.111.0.0/16 gw 127.0.0.1
    loginsin ~ # route add -net 173.194.55.0/24 gw 127.0.0.1
    • +1
      Тогда уж можно было бы сразу по-человечески:

      ximaera@endeavour:22:~#545$ sudo ip route add blackhole 206.111.0.0/16 ximaera@endeavour:22:~#546$ sudo ip route add blackhole 173.194.55.0/24
      • +1
        … чьорт побьери, а на 12" мониторе проблема с переносом строк незаметна :-(
  • +3
    Только не DROP, а REJECT --with-icmp-reset, тогда уж.
    • 0
      Тогда уж на исходящие пакеты.
  • +3
    Разве ipfw в маке не умеет инлайн?
    sudo ipfw add reject src–ip 173.194.55.0/24,206.111.0.0/16 in
    Во-вторых, почему вообще in, а не out и dest-ip?
    Зачем туда запросы отправлять?
    В третьих эта CDN для US, для других зон другие ип.
  • 0
    Подскажите, каким образом можно узнать с каких серверов по факту грузиться видео?
    • +1
      wireshark
    • 0
      Ставить программный файрволл и следить за браузером. У меня вот например выскакивает какой сервер ютуба: images.vfl.ru/ii/1365089199/836cfe40/2081601.jpg IP у него — 208.117.250.209. В трассировке до него указанных в статье серверов не вижу и добавление блокировок на трассировку а сервер загрузки не влияют.
      • –1
        значит это не cdn
        • +1
          а как их вычислить?
  • 0
    Мне не помогло :( Пров: QWERTY… мучаюсь с ютубом давно.
  • +1
    Новотелеком, Новосибирск — данное действие ничего хорошего, да и плохого тоже, не сделало.
    50 Мегабит как был незагружен, так и остался.
    Напомнило: habrahabr.ru/post/164881/
    • 0
      аналогично и у меня на том же провайдере при той же скорости. Ждем решения проблемы от Google.
  • 0
    Провайдер Укртелеком — с начала 2013 года проблемы с ютубом.
    Кстати —
    # iptables –I INPUT –s 206.111.0.0/16 –j DROP
    Bad argument `–I'

    Это как понимать?
    • 0
      парсер превратил минус в дефис
      • 0
        я копипастил… видимо Хабр исправил на тире автоматом
        • 0
          правила везде в интернете гуляют с тире вместо дефисов
  • +1
    бредовая идея. бредовое решение.
    занижении провайдерами скорости к серверам кеширующим видео

    Кешируюй на то и кеширующий, чтоб бсыстрее с него получить видео.
    • +1
      если они для этого созданы, то это не значит что провайдеры хотят выдавать полный канал в эту сторону.
  • +2
    Я прошу прощение за свой узкий кругозор, но как это сделать на роутере? У меня NetGear JNR3210.
    Или подскажите, что произойдёт после выполнения этого скрипта в cmd Win7? Куда вносятся изменения и как потом отменить их?
    • +1
      Такой же вопрос к обладателям Asus (конкретно rt-n56u, но думаю, это не важно).
      • 0
        включить LAN to WAN Filter
        а в него два правила:
        Source IP *
        Ports *
        Destination IP 206.111.*.* и 173.194.55.*
        Prots *
        Protocol TCP
  • +5
    Тоже в начале года наблюдал такую проблему, потом написал в роскомнадзор жалобу и через неделю внезапно все заработало как надо.
  • 0
    system-administrators.info/?p=1254
    тут транслейт сидра в диапозон
  • +1
    У меня эр-телеком (дом.ру). На первом попавшемся мёртвом видео хост r9---ams09x08.c.youtube.com (208.117.250.238). В диапазоны из топика оно не попадает.

    Гы. Загуглив IP, обнаружил, что у прова есть форум. %) (Не, ну серьёзно, у них на сайте нет ссылки на него.) На форуме весьма свежий срач про тытрубку… *тяжёлый вздох* А чёрт с ним, можно без тытрубки прожить.
    • +1
      Ну видимо они считают что чем меньше абонентов знают про форум тем меньше жалоб (нет массовых жалоб нет проблем).
      PS: понравился ответ админа со ссылкой на эту статью с посылом, что видите не только у нас так значит мы не причем — проблем нет…
  • –4
    хм… На OpenSUSE 12.2 ошибку дает:

    Bad argument `–I'

    Не подскажите, что делать?

    upd. Я БУДУ ВСЕГДА ЧИТАТЬ КОММЕНТАРИИ ПЕРЕД ТЕМ, КАК НАПИСАТЬ…
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Дом.РУ, в последнее время видео с ютуба тормозило при 480. После выполнения инструкций 480 идет норм, 720 подлагивает.
    Канал обещают в 50 Мбит/с.
    Тестировал с ноута через Wi-Fi.
  • 0
    Замечал такую вещь при закачке видео с ютуба: стартует на скорости в десятки мегабит и в течении нескольких секунд сваливается в единицы мегабит. Это оно?
    • 0
      Не, это фича: чтобы сильно не забивать канал сначала прокачивается начало ролика + небольшой буфер, а потом качается со скоростью потока видеоролика. Поставите на паузу — перестаёт качаться. Перемотаете сильно вперёд — опять быстро скачается кусок, а потом начнёт медленно качаться.
      • 0
        Значит я верно предполагал.
  • 0
    Абсолютно такие же симптомы у американского Verizon, попробвал — стало в разы быстрее но теперь часовые ролики грузятся полностью а не кусками как раньше но так и лучше т.к. иногда некоторые куски «забывались» грузится и приходилось курсором нажать на ± 5 секунд чтобы разбудить плеер.
    • +1
      Сутки спустя все опять начало тормозить. Наверное надо постоянно следить откуда тянется видео и блочить адреса.
  • 0
    От имени моих жены и дочи выражаю вам огромную благодарность!
  • +10
    А что прописать, чтобы redtube быстрее работал?
  • 0
    Мегафон 20/20, на просмотр 5 минут видео надо было пол-часа. Аж бесит.
    Совет помог, кажется. Буферизация опережает плейбек :) Спасибо!
  • НЛО прилетело и опубликовало эту надпись здесь
  • +2
    Команда на удаление в Win7:

    netsh advfirewall firewall delete rule name=«youtube»
    • 0
      Спасибо! xjunkiesx, добавь, пожалуйста, в статью.
  • 0
    Причина в занижении провайдерами скорости к серверам кеширующим видео

    Если не секрет. А в чём смысл?
    • 0
      затем же зачем некоторые режут торрент траффик
      • 0
        Ок. В чём смысл резать торрент трафик?
        • +3
          потому что у них в рекламе десятки и сотни мегабит за 450 рублей, а реально на всю толпу юзеров входят 2 гигабита например, и если все начнут одновременно ютубы смотреть на дикой скорости, то на всех интернета не хватит
          • +7
            Тогда что же вы наделали? Теперь точно на всех не хватит.
            • 0
              После этой статьи, Ютуб умер на обоих провайдерах)))
  • 0
    У меня на Good Line — всё ок. Никаких лишних действий не надо. Нажал смотреть и смотришь.
  • +7
    Опасная статья. Посоветовать общественности заблочить ПОДСЕТЬ cdn гугла без указания как разблочить ее обратно — как минимум опасно. Во-1, подсеть может поменяться, во-2, с заблоченной подсети когда-нибудь может начать отдаваться новый, нужный контент, ну хоть картинки в гуглопочте.

    Если пишите статью для людей, которые не могут сами заблочить эти адреса и не понимают, чем это грозит — стоит отдельно описать все проблемы, которые могут появиться после Вашего совета. Если Вы ориентируетесь на понимающую аудиторию, то стоит убрать часть «Как сделать» из статьи и добавить больше исследования проблемы.
  • +1
    В дополнение к моему предыдущему комменту. Блочить стоит избирательно по отдельным ипешникам, обязательно понимая, как разблочить ипешники обратно. Посмотреть непосредственный домент, откуда проигрывается видео — можно (точно проще wireshark'a или tcpdump'a :-D ) через плагин к firefox netvideohunter (пункт «Копировать ссылку на видео»).
  • +11
    Да прям всемирный заговор среди провайдеров, срыв покровов =)
    Я сам работаю в провайдере, много коллег работают так же в других провайдерах, но никто из нас ютуб не режет. Более того мы все коллективно занимались разбирательством, в чем же дело. Даже переписка была в ноябре 2012 в мэилинге MSK-IX.
    А все очень просто — не справляются сами гугл кэш серверы(или иначе cdn). Стоит убрать маршруты на одни серверы и перевести трафик на менее загруженные, как и им становится плохо.
    К чему приведет блокировка cdn? к большей нагрузке на основные серверы, в итоге совсем все ляжет. Успех.
    • 0
      Парни к успеху идут, чо. ;)
    • 0
      Ок, если никто не режет скорость, то почему у некоторых провайдеров тормозит а у некоторых нет? Если проблемы на стороне гугла, то тогда наверное (если рассуждать логически) тормозило бы у всех. Сейчас я имею ситуацию, что на работе ютуб проигрывается нормально — дома у меня тормозит иногда 480 (провайдер скромно обещает 100 Мбит/с).
      • 0
        Да у всех тормозит, у всех. Просто не во всех случаях, у кого-то чаще эти случаи, у кого-то нет(неравномерно нагрузка на cdn ложится). Чем ближе время ЧНН, тем больше эта вероятность. Вот у вас ролики в 11 утра в будний день тормозят ?) Если нет, то получается что и трафик никто не режет.
    • 0
      Вы молодцы, но, действительно, не все провайдеры такие хорошие, многие и ютуб режут, и торрент, и много чего ещё
  • 0
    тоже всегда удивлялся, почему с американских IP все грузится мгновенно, или с youporn например.

    Не сочтите тему холиварной, но все же — как удобно в OS X / Linux скопипастить команды в консоль, и как долго на винде искать нужное окенце.
    • 0
      Да с чего вы взяли, что американский айпи физически назначен на сервере, который находится в штатах? Почитайте выше мой коммент про anycast, ну и вообще про bgp, автономные системы и пиринг. Если пинг до машины меньше 100мс — то крайне маловероятно, что она физически в штатах.
      • 0
        Извиняюсь, если что-то неграмотно написал — я не разбираюсь в сетях и маршрутизации. Я только имел в виду, что с remote desktop американских машин ютуб открывается мгновенно, и на моей машине домашней (Минск) youporn грузится нормально.
    • 0
      [win]+R
  • 0
    А разве в маке не pf?
  • 0
    спасибо, помогло
    провайдер ToT (Тайланд)
    скачивание роликов до 500кб/сек
    но при просмотре в онлайне (через udacity.com например) грузились со скоростью 30-50кб/сек и по частям (приходилось иногда ставить на паузу и ждать)
    после этих комманд скорость стала около 200кб/сек и грузиться стали до конца
  • 0
    Божественно, 4К видео с ютуба играет без тормозов. Спасибо!
  • 0
    Ну да…

    id 1
  • 0
    Все работает, спасибо)
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Извиняюсь за такую неосведомленность, но как реализовать данное, если я не использую стандартный файервол? В ESET Smart Security, например.
  • 0
    Поэкспериментировал в выходные — все же способ помогает, но «частично».
    Часть видео теперь грузиться быстро и полностью (и судя по скорости с которой ползунок загрузки пробегал в 1080p видио я почувствовал что у меня действительно скоростной интернет). Но часть видио грузиться по прежнему с cdn (не указанных в диапазоне) причем часть грузиться с приемлемой скоростью (скачивание идет со скоростью просмотра) а часть по прежнему тормозит.
    В целом теперь тормозит где-то только каждый 7-10 ролик что все же лучше чем когда тормозит чуть ли не каждый ролик :).
    Я думаю если вычислить и «дозабанить» оставшиеся «плохие» cdn (они где то в 208.117.?.?) то ютуб можно будет смотреть совсем без тормозов) (главное чтобы не массово народ это использовал, а то думаю будет плохо уже основным серверам)
  • 0
    г. Ставрополь.
    провайдер — «Зеленая точка», разница заметна. Спасибо!
  • +1
    Есть возможность, что из-за этого может не открываться Skype на Маке?
    Ровно после этого действия перестал работать. Загружаю и вылетает.
    Или со Скайпом какая-та фигня?
  • 0
    Похоже что Гугль изменил алгоритмы кеширования, теперь если заблокирован адрес кеша, трафик не перебрасывается на родные сервера. Возможно это наша локальная проблема, но может быть так теперь у всех.

    У нас было все ровно наоборот. Всю жизнь трафик шел напрямую из США, а вчера что то переключилось и отправляет на какой то кривой польский кеш, который почему то не пингуется. В результате тупо перестало работать.

    Отключение указанных диапазонов или диапазона адресов кеша ничего не дает, так что метод не работает.
    • 0
      Польский кеш 217.96.43.14?

      У меня с него половина пакетов теряется.

      На польском форуме тоже пишут, что через американский прокси с адовым пингом видео грузится гораздо быстрее, чем напрямую с этого кеша:
      forum.neostrada.info/viewtopic.php?f=8&t=19525&start=420

      Хз, как это заблокировать.
      • 0
        Закройте фаирволлом подсеть кеша. Сейчас переключение на альтернативные сервера происходит очень быстро прямо на уровне клиента.
  • +1
    с недавних пор у Украинских провайдеров такая хрень началась. Сначала у местного провайдера Prokk, я на них гришил. Сейчас и Укртелеком стал так же тормозить. На работе все два канала оптика и сейчас такие цирки.
    Дома по проводам и сейчас сделал блокировку на микротике 173.194.55.0/24 и 206.111.0.0/16 как написано. Все работаетотлично!

    Большое спасибо за пост, а то достало!
  • –1
    Что то у меня перестало все работать. Буквально два дня и все опять глючит!? Подскажите что еще можно сделать?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.