В последнее время все большее количество российских интернет-пользователей сталкивается с проблемой затрудненного отображения онлайн-видео на сервисе YouTube.
Огромное количество форумов, включая форумы интернет-провайдеров, заполнено вопросами “Почему у меня тормозит YouTube?” или им подобными.
Хочу прояснить основную причину данных проблем.
Как известно, YouTube принадлежит интернет-гиганту Google.
Текущей осенью Google столкнулся с проблемой загруженности собственного оборудования и каналов на MSK-IX. Имеющихся 20G (в виде двух каналов 10G + 10G) на московской точке обмена трафиком уже давно перестало хватать (при текущих нагрузках требуется увеличение емкостей минимум в два раза), в результате чего более низкая приоретизация трафика потокового видео c YouTube перед поисковым трафиком Google сказалась более отчетливо в виде затруднения просмотра в режиме реального времени роликов с YouTube. Очевидно, что чем выше разрешение выбирает пользователь, тем хуже загружается видеоматериал.
О загруженности каналов Google очень наглядно говорят трассировки через MSK-IX со стороны различных магистральных провайдеров:
ae0-5.RT.M9.MSK.RU.retn.net
(87.245.233.30) 7.210 ms 7.232 ms 7.197 ms
74.125.51.241 (74.125.51.241) [AS 15169]
864.368 ms 899.170 ms 919.116 ms
209.85.248.91 (209.85.248.91) [AS 15169]
8.052 ms 26.194 ms 19.573 ms
173.194.35.203 (173.194.35.203) [AS 15169]
7.740 ms 7.752 ms 7.797 ms
или
m9-gw2-te3-5.msk.anders.ru (87.251.152.197) 2 ms 2 ms 4 ms
msk-ix-gw2.google.com (193.232.246.232) 69 ms * 71 ms
209.85.252.161 (209.85.252.161) 48 ms 47 ms 48 ms
173.194.35.238 (173.194.35.238) 51 ms 51 ms 48 ms
В принципе, представленные данные говорят сами за себя.
Я уже писал ранее, что YouTube представляет собой распределенную сеть дата-центов, хранящих видеоматериалы (т.е. сеть организовна по принципу СDN), поэтому конечный, скажем, московский, пользователь может просматривать ролик, который хранится в дата-центе, расположенном в США; очевидно, что видеоматериал в таком случае доставляется через собственные каналы Google до ближайшенй точки обмена или пиринга с провайдером конечного пользователя (в случае большинства российских пользователей такой точкой является MSK-IX), и если каналы Google оказываются перегруженными, то просмотр онлайн-видео значительно затрудняется.
Также нельзя исключать и фактор дополнительных ограничений, которые может накладывать Google в текущей непростой ситуации на снижение приоретизации видеотрафика.
Прежде чем продолжить свое повествование далее, хочу еще раз акцентироваться на вопросах распределенности хранения данных сервисом YouTube.
Каждый ролик на сервисе может быть доступен в следующих форматах и разрешениях — страндартных 240p, 360p, 480p и форматах высокой четкости (HD) 720p и 1080p.
Если рассмотреть вариант идеальный вариант загруженного видео, т.е. когда ролик доступен во всех вышеперечисленных форматах, то на серверах Google будут храниться сразу пять файлов с соответствующим заявленному в настройках качеству экранным разрешением, поэтому маршрутизация к каждому из таких файлов будет разной, равно как и скорость загрузки (иногда складывается парадоксальная ситуация, когда ролик в формате 360p загружается на несколько порядков медленнее, нежели 720p).
При этом Google использует не только систему распределенного хранения данных, но и геотаргетинг для оптимизации нагрузки на собственные каналы — в зависимости от текущей загрузки каналов клиент перенаправляется на менее загруженные сервера.
Также стоит отметить, что Google (AS 15169) поддерживает и сохраняет видео в разных форматах кодеков: традиционного Flash [FLV], популярного MPEG-4 Part 10 — H.264 (AVC) [MP4] и формате собственной разработки WebM [WebM], основанного на видеокодеке V8 и аудиокодеке Vorbis, который ориентирован для использования на страницах HTML5.
Иными словами, видеоматериал представляется на серверах роликами следующих форматов:
FLV 240p, FLV 360p, FLV 480p,
MP4 360p, MP4 720p, MP4 1080p,
WebM 360p, WebM 480p, WebM 720p.
Привожу пример для одного случайно выбранного ролика, дабы посмотреть маршруты прохождения трафика из Москвы до серверов Google, на которых упомянутый ролик хранится.
Итак, для формата 240p FLV
(сервер o-o.preferred.svo01s01.v14.lscache6.c.youtube.com [74.125.168.177]) имеем:
m9-gw2-te3-5.msk.anders.ru (87.251.152.197) 2 ms 2 ms 4 ms
msk-ix-gw2.google.com (193.232.246.232) 60 ms 80 ms 60 ms
209.85.243.235 [AS 15169] 4 ms 4 ms 4 ms
74.125.168.177 [AS 15169] 4 ms 4 ms 4 ms
для формата 360p FLV
(сервер o-o.preferred.svo01s01.v6.lscache8.c.youtube.com [74.125.168.181]):
msk-ix-gw1.google.com (193.232.244.232) 56 ms 70 ms 121 ms
209.85.243.235 [AS 15169] 4 ms 2 ms 4 ms
74.125.168.181 [AS 15169] 2 ms 2 ms 2 ms
для формата 480p FLV
(сервер o-o.preferred.ams03g05.v8.lscache7.c.youtube.com [208.65.155.207]):
msk-dsr5-tg7-2.rt-comm.ru [195.161.2.69] 3 ms 3 ms 3 ms
Port-channel2.463.ar1.ARN3.gblx.net
(64.213.54.49) [AS 3549] 61 ms 22 ms 22 ms
64.211.193.226 [AS 3549] 48 ms 50 ms 48 ms
208.117.247.179 [AS 15169] 48 ms 48 ms 48 ms
208.117.247.187 [AS 15169] 48 ms 48 ms 48 ms
208.65.155.207 [AS 15169] 47 ms 47 ms 47 ms
для формата 720р MP4
(сервер o-o.preferred.ams03g05.v6.lscache8.c.youtube.com [208.117.245.95]):
msk-dsr5-tg7-2.rt-comm.ru (195.161.2.69) 7 ms 3 ms 3 ms
tge1-4.fr3.lon.llnw.net
(195.66.224.133) [AS 22822] 66 ms 55 ms 55 ms
google.tge5-1.fr3.lon.llnw.net
(87.248.208.170) [AS 22822] 55 ms 55 ms 55 ms
208.117.247.179 [AS 15169] 52 ms 53 ms 53 ms
208.117.245.95 [AS 15169] 52 ms 52 ms 52 ms
для формата 480p WebM
(сервер o-o.preferred.ams03g05.v14.lscache8.c.youtube.com [208.117.226.224]):
ae6-4.RT.ACT.FKT.DE.retn.net (87.245.233.73) 44 ms 46 ms 46 ms
dialup-212.162.19.29.frankfurt1.mik.net
(212.162.19.29) [AS 3356] 43 ms 94 ms 44 ms
* * *
ft-level3-ge.frankfurt1.Level3.net
(4.68.62.158) [AS 3356] 72 ms 59 ms 45 ms
81.52.179.142 [AS 5511] 45 ms 46 ms 45 ms
208.117.247.187 [AS 15169] 46 ms 48 ms 62 ms
208.117.226.224 [AS 15169] 48 ms 52 ms 48 ms
Также не стоит забывать и про вторую группу серверов, всегда соответствующим первым, отвечающих за кеширование видеоматериала и его “транспортировку” (передачу) в потоке:
трассировка к серверу tc.v14.cache8.c.youtube.com [208.65.155.212]:
b57-gw2-te3-1.spb.anders.ru (81.91.177.78) 16 ms 12 ms 16 ms
tc-gw2-te3-3.sto.anders.ru (81.91.177.66) 76 ms 28 ms 24 ms
tc2-gw1-te1-3.ams.anders.ru (81.91.187.146) 44 ms 44 ms 48 ms
ge-9-5-451.r00.amstnl02.nl.bb.gin.ntt.net (81.20.64.13) [AS 2914]
44 ms 44 ms 40 ms
ae-2.r22.amstnl02.nl.bb.gin.ntt.net (129.250.2.112) [AS 2914]
40 ms 44 ms 44 ms
ae-5.r23.londen03.uk.bb.gin.ntt.net (129.250.5.197) [AS 2914]
52 ms 100 ms 60 ms
ae-2.r02.londen03.uk.bb.gin.ntt.net (129.250.5.41) [AS 2914]
52 ms 48 ms 52 ms
xe-0.francetelecom.londen03.uk.bb.gin.ntt.net
(129.250.8.198) [AS 2914] 72 ms 72 ms 60 ms
tengige0-9-0-5.ffttr3.Frankfurt.opentransit.net
(193.251.131.137) [AS 5511] 64 ms 56 ms 60 ms
* * *
208.65.155.212 [AS 15169] 64 ms 66 ms 66 ms
трассировка к серверу tc.v9.cache2.c.youtube.com [208.117.226.17]:
m9-gw4-po21.msk.anders.ru (81.91.177.122) 1 ms 1 ms 1 ms
km114-gw1-te3-1.vrn.anders.ru (81.91.187.170) 8 ms 8 ms 8 ms
anc-gw2-te4-3.fra.anders.ru (81.91.177.222) 52 ms 56 ms 56 ms
ge-0-1-0-16-zar1.fri.cw.net (166.63.204.189) [AS 1273]
96 ms 56 ms 52 ms
xe-10-1-0-xcr1.fra.cw.net (195.2.21.117) [AS 1273]
64 ms 56 ms 56 ms
xe-9-1-0-xcr1.prp.cw.net (195.2.9.53) [AS 1273] 64 ms 64 ms 64 ms
google-gw3.prp.cw.net (195.10.62.38) [AS 1273] 64 ms 66 ms 66 ms
* * *
208.117.226.17 [AS 15169] 68 ms 66 ms 70 ms
Как можно видеть, маршрутизация, казалось бы, к одному и тому же ролику проходит сразу несколькими различными путями, нередко даже минуя стык Google на MSK-IX и петляя через европейских операторов.
И это вполне нормально, ибо подобная диверсификация маршрутов вполне оправдана: несложно посчитать, что объемы трафика, генерируемые Google, огромны — это не только работа поисковой системы (включая большие потоки данных от поисковых роботов-ботов) и сервиса YouTube, но и целого ряда коммерческих сервисов, приносящих Google прибыль, включая сервис AdWords, социальной сети Google+, почты GMAIL, сервиса Maps и т.д., — а пропустить такие объемы запросов со всей России и Ближнего зарубежья только через каналы в рамках MSK-IX и SPB-IX просто невозможно — это приведет к полному коллапсу, поэтому в приоритете остается обеспечение нормального функционирования всех поисковых сервисов, более “тяжелый” же видеотрафик с точки зрения приоритета и маршрутизации отходит на второй план.
Однако нельзя не отметить при этом грамотную структуру построения сетей и дата-центров Google, которая позволяет даже при критичных нагрузках и даже перегрузках, которые мы наблюдаем в данный момент, сохранять свою работоспособность, избегая парализации.
При просмотре этого же ролика на YouTube через другого московского провайдера Google предложил иные варианты серверов хранения (порядка десяти пар, приведу лишь некоторые):
o-o.preferred.svo01s01.v6.lscache6.c.youtube.com
tc.v6.cache6.c.youtube.com
o-o.preferred.svo01s01.v1.lscache5.c.youtube.com
tc.v1.cache5.c.youtube.com
o-o.preferred.svo01s01.v4.lscache6.c.youtube.com
tc.v4.cache6.c.youtube.com
Поэтому в вечернее время имеющиеся проблемы с загрузкой каналов Google активно усиливаются проблемами загрузок (и перегрузок) каналов российских провайдеров в сторону Европы (а проблема внешних каналов в сторону Европы, т.н. “европейских каналов” или “западных апстримов”, является довольно болезненной проблемой всего российского интернета с его спецификой развития и непрекращающихся “политических разборок” крупных игроков рынка).
Описанное выше является также и ответом на контраргументы пользователей, знакомых со схемой тестирования скорости загрузки видео, предоставляемой сервисом YouTube: видео, предназначенное для тестов, в большинстве случаев располагается на ближайших к пользователю серверах и никак не ограничивается по скорости загрузки со стороны YouTube.
На данный момент достоверной информации о планах расширения каналов со стороны Google на MSK-IX не имеется.
Слухи, догадки и инсайдерскую информацию в данный момент я приводить не готов, ибо это будет некорректно.
Проблема ухудшения качества доступа к ресурсам YouTube затронула всех провайдеров, как московских, так и региональных, схема маршрутизации которых в сторону YouTube проходит через MSK-IX: из столичных провайдеров сюда стоит отнести и 2KOM (2КОМ), и QWERTY, и ЦИФРА ОДИН, и ряд более мелких сетей районного масштаба.
Также ситуация с загруженностью каналов Google на MSK-IX в ряде случаев усугубляется еще и загруженностью оборудования и каналов самих интернет-провайдеров в сторону упомянутой точки обмена.
Так, например, выглядит маршурут со стороны московского провайдера QWERTY в сторону YouTube в вечернее время:
213.85.208.161 (213.85.208.161) 8 ms 4 ms 42 ms
213.85.208.250 (213.85.208.250) 105 ms 358 ms 223 ms
msk-ix-gw2.google.com (193.232.246.232) 104 ms 104 ms 105 ms
209.85.252.161 (173.194.35.224) 46 ms 47 ms 46 ms
173.194.35.224 (173.194.35.224) 50 ms 51 ms 50 ms
Видно, что определенные проблемы с загруженностью узлов наблюдаются и на стороне QWERTY, поэтому при подобной ситуации на одну проблему с загруженностью каналов и оборудования накладывается другая, что в итоге еще больше усугубляет ситуацию с просмотром видеоматериалов с YouTube для клиентов.
После возникновения описанных проблем с загруженностью каналов Google на MSK-IX со стороны участников ОПГ (Отдельной Пиринговой Группы) посыпались злорадные заявления в стилистике “мол, у нас прямой пиринг с Google, поэтому у нас проблем нет”. Однако реальная ситуация у основных игроков ОПГ, оказывающих услуги физическим лицам, куда можно отнести БИЛАЙН (КОРБИНА + ГОЛДЕН-ТЕЛЕКОМ), МТС (СТРИМ), АКАДО (КОМКОР) и МЕГАФОН (NETBYNET), совсем иная: пользователи испытывают аналогичные (а иногда даже более сильные) затруднения с просмотром онлайн-видео на YouTube.
И причины тут две:
- некоторые участники ОПГ (к примеру, ТРАНСТЕЛЕКОМ или МТС/КОМСТАР/СТРИМ) действительно имеют прямые стыки с каналами Google вне MSK-IX, однако эти стыки все-таки расположены в рамках технологической базы точек обмена трафиком (либо российских, либо немецких, либо швецких), поэтому в случае прямых стыков в рамках Москвы (ТРАНСТЕЛЕКОМ, КОМКОР/АКАДО, МТС/СТРИМ/КОМСТАР) часть трафика направляется в те же российские каналы Google, которые достаточно загружены (загруженными в ряде случаев оказываются и упомянутые выше собственные приватные пиры данных провайдеров с Google в рамках Москвы), а остальная часть трафика утекает через европейские аплинки, а в случае же расположения всех стыков в Европе (БИЛАЙН/КОРБИНА&ГОЛДЕН-ТЕЛЕКОМ, NETBYNET) — только через каналы в сторону Европы, что создает немалую дополнительную нагрузку на европейские аплинки у данных провайдеров с учетом рассмотренной выше схемы переменной маршрутизации к различным серверам YouTube, поэтому, во-первых, качество доступа также напрямую зависит от загрузки каналов Google на данных европейских точках, а во-вторых, проблема сильной загрузки европейских аплинков у провайдеров, входящих в ОПГ, в часы-пик до сих пор не решена и является крайне актуальной;
- приоритет потокового видео (да и вообще всего трафика в целом) для клиентов т.н. “Домашнего Интернета” (физических лиц) у данных провайдеров довольно низок (в отличие от пользователей — юридических лиц), что также оказывает отрицательный эффект на просмотр потокового видео (особенно в форматах высокой четкости) в часы наибольших нагрузок (вечернее время, выходные и праздничные дни).
Не могу не отметить, что БИЛАЙН (КОРБИНА), несмотря на громкие заявления и заверения представителей его технической поддержки о наличии “прямого стыка с каналами Google”, осуществляет маршрутизацию через промежуточного магистрала LEVEL3:
hq-bb-giga2-23.msk.corbina.net (85.21.224.242)
1 msec 0 msec 0 msec
mo-crs-be2.msk.corbina.net (195.14.54.252)
28 msec 22 msec 24 msec
tc-bb-po2.sto.corbina.net (195.14.54.103)
18 msec 18 msec 18 msec
213.242.110.105 45 msec 18 msec 18 msec
* * *
ae-7-7.ebr1.Dusseldorf1.Level3.net
(4.69.142.170) [AS 3356] 40 msec 40 msec 39 msec
ae-46-46.ebr2.Frankfurt1.Level3.net
(4.69.143.170) [AS 3356] 44 msec 43 msec 44 msec
ae-72-72.csw2.Frankfurt1.Level3.net
(4.69.140.22) [AS 3356] 43 msec 44 msec 46 msec
ae-1-60.edge3.Frankfurt1.Level3.net
(4.69.154.7) [AS 3356] 45 msec 46 msec 45 msec
212.162.24.14 [AS 3356] 46 msec 44 msec 46 msec
62.67.33.114 [AS 3356] 43 msec 41 msec
209.85.248.12 [AS 15169] 49 msec 41 msec 40 msec
72.14.239.60 [AS 15169] 46 msec 70 msec 44 msec
72.14.234.10 [AS 15169] 59 msec 60 msec 56 msec
209.85.241.45 [AS 15169] 118 msec 94 msec 96 msec
209.85.252.161 [AS 15169] 95 msec 106 msec 102 msec
173.194.35.224 [AS 15169] 96 msec 95 msec 96 msec
Трасса же до внутренних серверов YouTube (до уже упоминавшегося выше tc.v9.cache2.c.youtube.com [208.117.245.17]) является на удивление длинной и запутанной, с немалым количеством потерь:
mo-crs-be2.msk.corbina.net (195.14.54.252) 20 msec 24 msec 24 msec
tc-bb-po2.sto.corbina.net (195.14.54.103) 18 msec 18 msec 18 msec
213.242.110.89 18 msec 18 msec 18 msec
* * *
ae-0-10.bar1.Copenhagen1.Level3.net
(4.69.137.153) [AS 3356] 29 msec 32 msec 27 msec
ae-7-7.ebr1.Dusseldorf1.Level3.net
(4.69.142.170) [AS 3356] 40 msec 43 msec 40 msec
ae-45-45.ebr2.Frankfurt1.Level3.net
(4.69.143.166) [AS 3356] * 43 msec *
ae-62-62.csw1.Frankfurt1.Level3.net
(4.69.140.18) [AS 3356] 45 msec 45 msec *
* * *
ix-2-3-0-0.tcore1.FR0-Frankfurt.as6453.net
(195.219.180.97) [AS 6453] 45 msec * *
if-7-2.tcore1.FNM-Frankfurt.as6453.net
(195.219.50.2) [AS 6453] 57 msec 57 msec 56 msec
if-5-2.tcore1.AV2-Amsterdam.as6453.net
(195.219.194.13) [AS 6453] 57 msec 58 msec 77 msec
if-2-2.tcore2.AV2-Amsterdam.as6453.net
(195.219.194.6) [AS 6453] 57 msec 56 msec 64 msec
if-5-2.tcore2.L78-London.as6453.net
(80.231.131.13) [AS 6453] 59 msec 60 msec 60 msec
if-2-2.tcore1.L78-London.as6453.net
(80.231.131.2) [AS 6453] 58 msec 56 msec 57 msec
Vlan704.icore1.LDN-London.as6453.net
(80.231.130.10) [AS 6453] 57 msec 57 msec *
ix-8-2.icore1.LDN-London.as6453.net
(195.219.83.6) [AS 6453] 62 msec * 60 msec
* * *
* * *
208.117.226.17 [AS 15169] 68 msec 66 msec 70 msec
Очевидно, что такая цепочка не может обеспечить полноценного функционинирования всех сервисов YouTube, т.е. нормального качества просмотра потокового видео, в “часы-пик”.
Аналогичная проблема наблюдается и на каналах МТС (СТРИМ/КОМСТАР):
a197-crs-1-be1-53.msk.stream-internet.net [212.188.1.113]
15 ms 19 ms 19 ms
m9-crs-1-be4.msk.stream-internet.net [195.34.59.49]
62 ms 64 ms 64 ms
bor-crs-1-be1.spb.stream-internet.net [195.34.53.126]
58 ms 59 ms 58 ms
anc-cr01-po3.ff.stream-internet.net [195.34.53.102]
142 ms 107 ms 122 ms
74.125.50.57 63 ms 64 ms 64 ms
209.85.255.176 66 ms 64 ms 64 ms
Загрузка европейских каналов МТС также на лицо.
Но если для членов ОПГ загруженность каналов в сторону зарубежного сегмента и проблемы с отображением потокового видео существуют давно, решаются не очень эффективно и довольно медленно и уже приобрели статус “перманентного состояния”, то для пользователей провайдеров, использующих более логичные пиринговые схемы, неожиданно возникшие проблемы с YouTube стали действительно неприятной неожиданностью_.
В принципе, решение данной проблемы сейчас лежит большей своей частью в зоне ответственности компании Google (за исключением ситуации у провайдеров, входящих в Отдельную Пиринговую Группу, — “Билайна”, “Транстелекома”, “NetByNet”, “Акадо” и “МТС”) и зависит от нее, от расторопности в расширении российских каналов на MSK-IX, при этом часть ответственности все-таки ложится и на плечи интернет-провайдеров, ибо нехватка емкостей внешних аплинков в сторону Европы наблюдается у подавляющего большинства.
Однако некоторые провайдеры и магистралы все-таки частично решили проблему загрузки, перенаправив трафик в сторону каналов Google в рамках SPB-IX, что, конечно, полностью не решило проблему, но несколько сняло ее остроту.
Вот пример, как поступил РАСКОМ:
spb-dc-sr1-v220-hsrp.rascom.ru (80.64.99.129) 5.702 ms 0.689 ms 0.565 ms
spb-ivc-cr2-vl-3.rascom.ru (80.64.98.6) 0.383 ms 0.474 ms 0.547 ms
gw1.spb-ix.google.com (194.226.100.138) 0.718 ms 0.717 ms 0.605 ms
72.14.236.221 (72.14.236.221) 63.527 ms 69.504 ms 73.262 ms
72.14.236.248 (72.14.236.248) 32.182 ms 32.091 ms 32.098 ms
209.85.254.153 (209.85.254.153) 54.962 ms 54.34 ms 54.312 ms
66.249.95.175 (66.249.95.175) 48.772 ms
64.233.174.55 (64.233.174.55) 49.643 ms 52.713 ms 49.532 ms
* * *
bw-in-f93.1e100.net (74.125.43.93) 49.684 ms 49.572 ms 49.526 ms
Конечно, подобное решение не является выходом из положения и больше похоже на временную “заплатку”, поскольку нужно понимать, что емкость каналов Google на SPB-IX в десять раз меньше, т.е. составляет всего 2G, поэтому выходом из положения это также не является, ибо стык такого малого объема “забьется” в течение крайне короткого времени, и в итоге все очень быстро придет к тому, что уже жители Северной Столицы начнут испытывать точно такие же (а если еще не более худшие) проблемы с доступом не только к YouTube, но и к другим сервисам Google, включая поисковые.
Значительно меньшие проблемы испытывают клиенты провайдеров, имеющих прямой пиринг с Google и/или соответствующим образом анонсированы (подразумевается статус registered). Сюда можно отнести РОСТЕЛЕКОМ, ФИОРД (FIORD) и ONLIME. Однако это видимое благополучие на фоне общей печальной картины также очень шатко, ибо напрямую зависит от загруженности стыков данных провайдеров с Google. На данный момент известно, что стык РОСТЕЛЕКОМ-GOOGLE, несмотря на недавнее расширение до 30G, уже “забит”.
Варианты нормализации ситуации даже при текущей конфигурации каналов и стыков более чем возможно: на MSK-IX у Google есть еще 20G (10+10) для IPv6. Очевидно, что через использование IPv6-маршрутизации вполне реально запустить новые пути прохождения трафика в сторону AS Google.
Однако на этом пути возникает несколько препятствий:
во-первых, захочет ли сам Google использовать новые маршруты в рамках IPv6,Ю дабы не нанести ущерба работе своих поисковых систем (хотя если следовать здравой логике, то должен захотеть, ибо выгода очевидна);
во-вторых, отечественные провайдеры очень вяло поддерживают IPv6: причем в одном случае оборудование некоторых крупных магистралов поддерживает IPv6, но сама маршрутизация в рамках этого протокола еще не отлажена до необходимого уровня качественной работоспособности, а в другом случае более мелкие провайдеры IPv6 вообще не поддерживают;
и в-третьих, кто-то должен первым начать диалог в этом направлении, однако известная проблема “гордости” отечественных провайдеров вряд ли позволит оперативно сесть за стол переговоров.
Остается надеяться, что в ближайшее время Google все же поправит ситуацию. Про необходимость осуществления определенных действий со российских игроков рынка провайдинга даже не упоминаю, ибо, глядя на их подходы и на текущую ситуацию с межпровайдерским взаимодействием в отечественном Интернете, понимаю, что говорить о чем либо тут просто бесполезно.
В принципе, сложившаяся ситуация есть яркое проявление и прямое следствие отвратной пиринговой политики со стороны всех игроков российского рынка, которая привела к возникновению фактически “удельных княжеств” в РУнете;
при желании решить данную проблему можно быстро, эффективно и просто, однако этого желания, увы, нет, что подтверждают факты реального положения дел на сегодняшний день.
Подытоживая вышесказанное, еще раз хочу напомнить, что качество доступа к сервисам и ресурсам YouTube зависит не только от самого YouTube, но также и от качества каналов самих интернет-провайдеров.
Надеюсь, что материалы этой статьи достаточно четко и надежно проиллюстрировали сей факт.
ПОСЛЕСЛОВИЕ:
Конечным интернет-клиентам/пользователям менять DNS-сервера провайдера на DNS Google в данной ситуации не нужно, ибо такие манипуляции не помогут делу никак и ситуацию не изменят; не стоит поддаваться и недавно распространившемуся в РУнете мнению, что скорость работы YouTube зависит от типа браузера, — эти заявления абсолютно безосновательны.
Также рекомендую ознакомиться с другими актуальными материалами по тематике YouTube:
публикацией
«Проблема некорректного отображения страниц YouTube»
и статьей
«Об особенностях ресурсов потокового видео».
