Комментарии 179
А теперь сделайте это связным текстом, а не кучкой несвязных мыслей. Я вам помогу:
Причина в занижении провайдерами скорости к серверам кеширующим видео, всё что нужно сделать это заблокировать доступ к ним.

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

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


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

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

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

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

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

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

image
Да им вообще пофигу, 4 года народ жалуется, можно ссылку на офицальное заявление?
Там можно обойтись одной дополнительной запятой.: Р «Если однородные придаточные связаны одиночным соединительным или разделительным союзом (и, да в значении «и», или, либо), то запятая между придаточными предложениями не ставится». Пруф.
Новосибирск, академорг. Два года уже ютубом пользоваться невозможно. Люди даже к другим провайдерам из-за этого уходят.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Вот зачем кидать ссылку на лепру, на которой у большинства нет аккаунтов?
А если бы не обновляли, то успели бы написать свой — первым)
Я так и не дождался! Что там на видео? (( Интересно прям…
Люди делятся на 2 типа: те, кто обновляют комменты, и те кто пишут первые =)
Еще хорошим тоном было бы привести команды для отмены блокировки…
Как-то так:
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
Во-первых, сама идея «а давайте отхреначим кусок гугловой подсети и посмотрим чо будет» выглядит странно.
Во-вторых, вся эта идея берет свое начало в блоге какого-то американского дядьки. Вы уверены, что будучи в России, ходите на те же самые сервера? Ради интереса можете поснифать трафик ;)
В-третьих, у кучи провайдеров гугловые кеширующие сервера стоят на их же площадке. Этого никто не афиширует, потому что гугль запрещает это делать, пока Google Global Cache в бете находится, но если у вашего провайдера абонентов эдак тысяч 50, то скорее всего, кешировалки у него либо уже стоят, либо готовятся к установке.
если это работает — то очевидно что на теже, тут же банится вся подсеть cdn серверов.
у кучи провайдеров может и стоит, но ни у одного человека (в Тюмени и ХМАО) я еще ни разу не видел чтобы ютуб нормально проигрывал видео
А с чего вы взяли, что оно работает? Ну, кроме плацебо =) Раньше что, оно ходило на какой-то из забаненных адресов?
с того что я постоянно смотрю подборку ютуб видео в серии постов tusinida на leprosorium.com и ежедневно встречал эти проблемы, теперь же ситуация изменилась!
Возможно дело в том, что в посты добавляется только свежее видео с видеорегистраторов и эти видео в течении нескольких часов (после публикации на ютуб) расходятся по всевозможным ручп, автовидео и прочим ресурсам, а под большим внезапным ростом просмотра у видео гугл копируется их на cdn
Мы же на техническом ресурсе все-таки, хотелось бы фактов, результатов тестов, данных о том, откуда тянулись ролики до, откуда стали тянуться после, как изменилась скорость загрузки по версии ютьюба и так далее. Просто видите ли, с Хабра эти советы расползутся теперь по всему рунету, и куча людей будет слепо им следовать, потому что так на Хабре написали. Примерно так же ходят копипасты последовательностей загадочных действий, которые пинг в онлайн игрушках могут уменьшить, хотя при ближайшем рассмотрении оказывается, что эти методы в принципе, даже теоретически не могут на что-то повлиять. Здесь то же самое, польза от всего этого вашего шаманства весьма сомнительна.

Самый главный вопрос: если вы уверены, что ваш провайдер шейпит ютьюб, то почему вы считаете, что он шейпит именно эти два диапазона? Потому что об этом написал какой-то американский дядька? =)
У меня рандомный ролик тянулся с tc.v13.cache5.c.youtube.com [208.117.238.144], ни в один из забаненных вами диапазонов он не попадает.
А рандомный ролик тормозил или нормально проигрывался?
Ну так это значит он был из «хорошей» подсети, которую банить и не нужно, так?
Да с чего вы в принципе взяли, что есть «хорошая» подсеть, а есть «плохая»? Вы взяли непроверенный факт и теперь пытаетесь оперировать «от обратного». =)
Смотрел это видео: 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
Не надо с ним спорить, этот человек постоянно защищает бредовые инициативы провайдеров, в прошлый раз, в посте про цензуру даже кичился, что у него есть некое письмо с разъяснениями по этому закону с чёрными списками, но выложить не смог. В общем, мутный персонаж, думаю, проще не тратить на него силы вообще
«Этот человек» пытается рассказать, как на самом деле обстоят дела. И не не не смог, а не стал. ;)
Ну так расскажите, не стесняйтесь. А то заинтриговали же :)
По-моему, я исключительно этим и занимаюсь в этом тредике :)
Прежде чем я отвечу более предметно, не могли бы вы объяснить один забавный факт? 74.125.168.150 это Mountain View, United States. От Тюмени до этого города по прямой что-то около 9500 километров, судя по данным вольфрам-альфы. Если допустить, что прямо между ними лежит оптика, то на передачу данных потребуется 44 ms. У вас же пакеты долетают за 2ms. Не могли бы вы объяснить, как у вас так получается?
Хорошо, будем считать, что скорость света это не предел, и при необходимости в оптике он даже может почти в 10 раз ускориться. Продолжим же разбирать ваш забавный эксперимент. Если я правильно понял написанное, вы сначала пингуете какой-то домен, получаете первый ip адрес, после этого блокируете фаерволом входящий трафик с подсети, в которую входит первый адрес. Далее вы вновь резолвите тот же домен и получаете второй адрес, не из заблокированного диапазона. Допустим, все так и было, угу. :)
Вопрос заключается вот в чем: почему вы считаете, что эти два события вообще связаны? DNS сервер, который в конечном итоге возвращает вам ip адрес ресурса, не имеет ни малейшего понятия о том, какие правила фильтрации входящего трафика установлены на вашем компьютере.
Не пытайтесь видеть троллинг или оскорбления там, где их нет. Я нисколько не хочу обидеть Вас, либо кого-то еще. Наоборот, я пытаюсь объяснить, где именно вы неправы и почему.
Если вам лично кажется, что некий набор действий решает вашу проблему, то окей, ради бога. В конце концов, куча людей верило, что если нарезать мышкой круги при загрузке винды, то процесс пойдет быстрее. :)
Просто публикация на хабре ведет за собой определенные последствия, ее неминуемо растаскивают по блогам, всяким там фишкам и прочим ресурсам, после чего она становится в глазах обычного пользователя непреложной истиной. Сейчас народные массы начнут бездумно блокировать здоровенные куски гугловых подсетей, что приведет к большим проблемам, если гугл вдруг начнет отдавать что-то с адресов из этого диапазона. Собственно, это неоднократно уже бывало ранее, правда в несколько меньших масштабах.
А с чего вы взяли, что машинка с таким адресом находится в Mountain View? Можно элементарно поднять много машин с этим адресом на loopback адаптере и светить в ближайшую от каждой из машин точку пиринга (точнее, в свой бордер роутер) маршрутом через себя с низкой стоимостью. Anycast называется. Каждый волен развлекаться как угодно внутри своей автономной системы, главное — отдать маршрут через BGP.

Вот картинка, чтобы понятнее было:
image
И стоит эта машинка, судя по 2 мс пинга до нее, где-то у моего уважаемого оппонента прям рядом, ага. Такой нежданный сервер гугла ВНЕЗАПНО появляется и исчезает на просторах России. При этом пингуется, опять же, только им. Seems legit. :)
Я не защищаю автора, а рассказываю вам про технологию, как айпишник может внезапно появляться в разных точках планеты, да ещё и одновременно. Смотрите, вот я из виртуалки, да ещё и за домашним роутером, пингую 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 список пиров поглядеть.
Только 1 вопрос: как потом убрать эти правила? Для мака, например.
при условии что при добавлении правил они закрепились за номерами 000100 и 000200
Если дождаться загрузки ролика из топика, то покажут мультик.
НЛО прилетело и опубликовало эту надпись здесь
А чего именно эти аипишники-то? У меня у прова допустим CDNы:
95.83.191.4
95.83.191.5
95.83.191.6
И с ними буфферизация видео стремится к 100мбитам))

image
а зачем ограничивать в вашем случае? Если у прова стоят cdn гугла то вообще ни каких проблем не должно быть
А чем (откуда) это вы такую интересную картинку сделали?
Правой кнопкой по youtube ролику — «Показать информацию о видео», такая статистика только для flash плеера, у html5 плеера она немного другая.
я на лепре писал, повторю и тут — инфу получил в maillist, без ссылки на источник
Вроде помогло. До этого момента и не думал что у меня в маке запущен и работает ipfw :-)
Можно универсальный способ :)
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
Тогда уж можно было бы сразу по-человечески:

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
… чьорт побьери, а на 12" мониторе проблема с переносом строк незаметна :-(
Разве ipfw в маке не умеет инлайн?
sudo ipfw add reject src–ip 173.194.55.0/24,206.111.0.0/16 in
Во-вторых, почему вообще in, а не out и dest-ip?
Зачем туда запросы отправлять?
В третьих эта CDN для US, для других зон другие ип.
Подскажите, каким образом можно узнать с каких серверов по факту грузиться видео?
Ставить программный файрволл и следить за браузером. У меня вот например выскакивает какой сервер ютуба: images.vfl.ru/ii/1365089199/836cfe40/2081601.jpg IP у него — 208.117.250.209. В трассировке до него указанных в статье серверов не вижу и добавление блокировок на трассировку а сервер загрузки не влияют.
Новотелеком, Новосибирск — данное действие ничего хорошего, да и плохого тоже, не сделало.
50 Мегабит как был незагружен, так и остался.
Напомнило: habrahabr.ru/post/164881/
аналогично и у меня на том же провайдере при той же скорости. Ждем решения проблемы от Google.
Провайдер Укртелеком — с начала 2013 года проблемы с ютубом.
Кстати —
# iptables –I INPUT –s 206.111.0.0/16 –j DROP
Bad argument `–I'

Это как понимать?
бредовая идея. бредовое решение.
занижении провайдерами скорости к серверам кеширующим видео

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

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

Bad argument `–I'

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

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

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

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

Не сочтите тему холиварной, но все же — как удобно в OS X / Linux скопипастить команды в консоль, и как долго на винде искать нужное окенце.
Да с чего вы взяли, что американский айпи физически назначен на сервере, который находится в штатах? Почитайте выше мой коммент про anycast, ну и вообще про bgp, автономные системы и пиринг. Если пинг до машины меньше 100мс — то крайне маловероятно, что она физически в штатах.
Извиняюсь, если что-то неграмотно написал — я не разбираюсь в сетях и маршрутизации. Я только имел в виду, что с remote desktop американских машин ютуб открывается мгновенно, и на моей машине домашней (Минск) youporn грузится нормально.
спасибо, помогло
провайдер ToT (Тайланд)
скачивание роликов до 500кб/сек
но при просмотре в онлайне (через udacity.com например) грузились со скоростью 30-50кб/сек и по частям (приходилось иногда ставить на паузу и ждать)
после этих комманд скорость стала около 200кб/сек и грузиться стали до конца
Божественно, 4К видео с ютуба играет без тормозов. Спасибо!
НЛО прилетело и опубликовало эту надпись здесь
Извиняюсь за такую неосведомленность, но как реализовать данное, если я не использую стандартный файервол? В ESET Smart Security, например.
Поэкспериментировал в выходные — все же способ помогает, но «частично».
Часть видео теперь грузиться быстро и полностью (и судя по скорости с которой ползунок загрузки пробегал в 1080p видио я почувствовал что у меня действительно скоростной интернет). Но часть видио грузиться по прежнему с cdn (не указанных в диапазоне) причем часть грузиться с приемлемой скоростью (скачивание идет со скоростью просмотра) а часть по прежнему тормозит.
В целом теперь тормозит где-то только каждый 7-10 ролик что все же лучше чем когда тормозит чуть ли не каждый ролик :).
Я думаю если вычислить и «дозабанить» оставшиеся «плохие» cdn (они где то в 208.117.?.?) то ютуб можно будет смотреть совсем без тормозов) (главное чтобы не массово народ это использовал, а то думаю будет плохо уже основным серверам)
г. Ставрополь.
провайдер — «Зеленая точка», разница заметна. Спасибо!
Есть возможность, что из-за этого может не открываться Skype на Маке?
Ровно после этого действия перестал работать. Загружаю и вылетает.
Или со Скайпом какая-та фигня?
Похоже что Гугль изменил алгоритмы кеширования, теперь если заблокирован адрес кеша, трафик не перебрасывается на родные сервера. Возможно это наша локальная проблема, но может быть так теперь у всех.

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

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

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

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

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

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