Осенняя проблема значительной деградации качества доступа к сервисам YouTube со стороны российского сегмента Интернета, о которой я писал ранее, начала решаться.
В середине января Google в три раза увеличил емкости на MSK-IX: с 20G до 60G. При этом число каналов не увеличилось, их осталось два (в точках 193.232.244.232 и 193.232.246.232, как и было ранее), соответственно пропорционально увеличились емкости каждого из каналов с 10G на 30G.
Благодаря троекратному расширению канальных емкостей удалось решить проблемы с воспроизведением потокового видео в реальном времени — подавляющее большинство роликов, включая видео формата HD, для конечных пользователей, подключенных к MSK-IX, теперь стали загружаться нормально.
Изменения коснулись и принципов буферизации: Google ее явно улучшил — полоса пропускания при загрузке данных теперь сопоставима с видеопотоком, а не полосой пропускания на стороне клиента (речь идет, естественно, о полосах, превышающих 5Mbps), что позволяет одновременно обеспечить и комфортный просмотр видео любого формата в режиме реального времени, и оптимизировать нагрузку на каналы в “часы-пик”.
Однако стоит отметить, что расширение каналов затронуло только MSK-IX, на точке обмена в Санкт-Петербурге SPB-IX емкость осталось прежней — всего 2G, поэтому у конечных клиентов провайдеров северной столицы проблемы с доступом, скорее всего, самостоятельно (без “ручного” изменения схемы маршрутизации) не решатся.
Более того, появились долгожданные прямые стыки с Google и у провайдеров, входящих в ОПГ (Отдельную Пиринговую Группу), — в списке новых обладателей прямых стыков с Google оказались ГОЛДЕН-ТЕЛЕКОМ (БИЛАЙН), КОРБИНА-ТЕЛЕКОМ (БИЛАЙН) и АКАДО (КОМКОР).
Вот как теперь выглядит маршрут к youtube.com из сетей КОМКОРа:
iki-crs.comcor.ru (62.117.100.73) 4 msec 4 msec 8 msec
74.125.51.81 2 msec 1 msec 1 msec
72.14.236.220 9 msec 12 msec 8 msec
209.85.250.232 [AS 15169] 30 msec 33 msec 31 msec
209.85.248.132 [AS 15169] 89 msec 81 msec 80 msec
64.233.174.55 [AS 15169] 48 msec 48 msec 50 msec
youtube.com (173.194.69.136) [AS 15169] 52 msec 50 msec 58 msec
А вот так из сетей провайдера КОРБИНА-ТЕЛЕКОМ (БИЛАЙН):
m9-br-be1.msk.corbina.net (78.107.184.43) 3 msec 2 msec 3 msec
google-gw.msk.corbina.net (195.14.32.22) 1 msec 3 msec 3 msec
72.14.236.220 [AS 15169] 10 msec 9 msec 9 msec
209.85.250.232 [AS 15169] 33 msec 34 msec 34 msec
209.85.248.132 [AS 15169] 66 msec 49 msec 49 msec
64.233.174.55 [AS 15169] 49 msec 50 msec 52 msec
youtube.com (173.194.69.190) [AS 15169] 51 msec 48 msec 51 msec
Нельзя не отметить значительное улучшение маршрутизации, благодаря прямым стыкам.
Хотя уже даже на этих данных, несмотря на недавнее появление стыков, в ряде случаев начинает “проступать” загруженность на стыке ПРОВАЙДЕР-GOOGLE.
Однако оптимизация прохождения трафика со стороны ОПГ в сторону Google пока что оставляет желать лучшего.
Снова можно отчетливо наблюдать, что для разных серверов системы хранения YouTube трафик продолжает “ходить” разными путями, поэтому скорость загрузки видео для одного и того же ролика в разных форматах может быть различной (об особенностях системы хранения и SDN-сетях Google я уже упоминал здесь, здесь и здесь), в том числе и довольно медленной.
Рассмотрим ситуацию на примере маршрутизации из сетей провайдера КОРБИНА-ТЕЛЕКОМ (БИЛАЙН) в сторону YOUTUBE (GOOGLE) для случайно выбранного ролика, который доступен как в форматах “стандартной” четкости — 240p, 360p и 480p, так и высокой — 720p.
Вот что имеем для разных типов кодирования и разрешения одного и того же ролика:
для видео формата 240p FLV
(сервер o-o.preferred.svo01s01.v14.lscache6.c.youtube.com [74.125.168.177])
по протоколу IPv4 имеем:
m9-crs-be3.msk.corbina.net (195.14.54.141) 7 msec 7 msec 5 msec
m9-br-be1.msk.corbina.net (78.107.184.43) 2 msec 1 msec 6 msec
google-gw.msk.corbina.net (195.14.32.22) 3 msec 22 msec 1 msec
209.85.243.235 [AS 15169] 3 msec 2 msec 1 msec
74.125.168.177 [AS 15169] 2 msec 4 msec 1 msec
для того же ролика 240p FLV,
но уже по протоколу IPv6
(o-o.preferred.svo01s01.v14.lscache6.c.youtube.com [2A00:1450:400F:6::14]):
hq-bb-gi1-17.corbina.net
(2A00:18C0::1:1C:1) 2 msec 6 msec 6 msec
m9-crs-loopback6.0.c.8.1.0.0.a.2.ip6.arpa
(2A00:18C0::14) 2 msec 8 msec 8 msec
2A00:18C0:1:27::1 3 msec 2 msec 5 msec
2A00:18C0::1:3C:2 3 msec 5 msec 1 msec
2001:4860::4:0:E70 [AS 15169] 11 msec 10 msec 10 msec
2001:4860::1:0:26EC [AS 15169] 22 msec 21 msec 36 msec
2001:4860::3:0:29AB [AS 15169] 45 msec 40 msec 22 msec
2001:4860:0:1::4FB [AS 15169] 24 msec 22 msec 20 msec
o-o.preferred.svo01s01.v14.lscache6.c.youtube.com
(2A00:1450:400F:6::14) [AS 15169] 23 msec 26 msec 21 msec
В обоих случаях видим, что трафик ходит через прямой стык между каналами КОРБИНА-ТЕЛЕКОМ и GOOGLE.
для формата 480p FLV
(сервер o-o.preferred.ams03g05.v8.lscache7.c.youtube.com [208.65.155.207])
по протоколу IPv4:
mo-crs-be2.msk.corbina.net (195.14.54.252) 29 msec 24 msec 24 msec
tc-bb-po2.sto.corbina.net (195.14.54.103) 18 msec 22 msec 19 msec
TenGigabitEthernet7-2.ar3.HAM1.gblx.net@
@(208.49.135.185) 29 msec 30 msec 30 msec
64.211.193.226 [AS 3549] 54 msec 54 msec 52 msec
208.65.155.207 [AS 15169] 58 msec 60 msec 60 msec
по протоколу IPv6
(o-o.preferred.ams03g05.v8.lscache7.c.youtube.com [2A00:1450:400E:5::F]):
hq-bb-gi1-17.corbina.net
(2A00:18C0::1:1C:1) 3 msec 1 msec 2 msec
m9-crs-loopback6.0.c.8.1.0.0.a.2.ip6.arpa
(2A00:18C0::14) 6 msec 8 msec 8 msec
2A00:18C0::1:3C:10 2 msec 2 msec 1 msec
2A00:18C0::1:3C:2 1 msec 1 msec 1 msec
2001:4860::4:0:E70 [AS 15169] 8 msec 9 msec 9 msec
2001:4860::1:0:26EC [AS 15169] 19 msec 20 msec 117 msec
2001:4860::1:0:FBC [AS 15169] 40 msec 41 msec 41 msec
2001:4860::3:0:CC [AS 15169] 57 msec 50 msec 48 msec
2001:4860:0:1::308 [AS 15169] 49 msec 50 msec 49 msec
o-o.preferred.ams03g05.v8.lscache7.c.youtube.com
(2A00:1450:400E:5::F) [AS 15169] 50 msec 50 msec 51 msec
А уже в этом случае наблюдаем, что маршрутизация до серверов Google отправляется по “европейской петле”, минуя прямой стык с каналами Google в Москве, т.е. принцип маршрутизации остался аналогичным принципам прошлой осени.
Соответственно для конечного пользователя просмотр ролика в упомянутом формате 480p FLV из-за данной “петли” в “часы-пик” может оказаться проблематичным.
При этом по протоколу IPv6 маршрутизация более чем корректная — через московский пиринговый стык. Однако ввиду того, что функционал IPv6 пока что конечным клиентам недоступен, польза от этого прямого маршрута фактически равна нулю.
Аналогичная картина наблюдается и для формата 720p MP4
(сервер o-o.preferred.ams03g05.v6.lscache8.c.youtube.com [208.117.245.95]):
mo-crs-be2.msk.corbina.net
(195.14.54.252) 20 msec 29 msec 20 msec
tc-bb-po2.sto.corbina.net
(195.14.54.103) 18 msec 24 msec 23 msec
xe-8-1-0.stk30.ip4.tinet.net
(141.136.96.125) 19 msec 22 msec 20 msec
so-1-2-0.lon12.ip4.tinet.net
(213.200.82.1) [AS 3257] 50 msec 58 msec 60 msec
google-gw.ip4.tinet.net (141.136.96.106) 58 msec 62 msec 62 msec
* * *
208.117.245.95 [AS 15169]
И в этом случае наблюдаем картину маршрутизации вне прямого стыка в Москве со всеми вытекающими отсюда проблемами, связанными со стабильной загрузкой европейских аплинков у КОРБИНЫ (говорить подробно об этом уже нет желания: тема перегрузки аплинков стала за последние несколько лет перманентным состоянием для участников ОПГ). Да и в такой ситуации маршрутизацию до сервисов YouTube вообще контролировать и отлаживать невозможно, — для каждого случая она разная, поэтому работоспособность YouTube, определяемая скоростью загрузки видеоматериалов конечному пользователю, представляет собой “лоскутное одеяло” — что-то работает и загружается хорошо, что-то — похуже, а что-то — совсем плохо.
Клиенты провайдеров, подключенных к MSK-IX, “видят” описанный сервер напрямую через каналы Google, что минимизирует риски деградации загрузки контента со стороны серверов сети SDN Google:
msk-ix-gw1.google.com [193.232.244.232] 3 ms 3 ms 4 ms
72.14.236.220 11 ms 18 ms 10 ms
209.85.250.232 81 ms 30 ms 34 ms
216.239.43.250 42 ms 37 ms 58 ms
72.14.233.214 38 ms 37 ms 56 ms
209.85.240.222 77 ms 51 ms 51 ms
72.14.236.69 65 ms 49 ms 92 ms
208.117.247.179 69 ms 64 ms 78 ms
208.117.245.95 65 ms 57 ms 55 ms
Подытоживая вышесказанное:
1. На MSK-IX емкость каналов Google увеличилась в три раза, с 20G до 60G, поэтому для провайдеров, подключенных к MSK-IX, проблемы прошлой осени должны полностью уйти в прошлое.
2. На SPB-IX емкость каналов осталась прежней, следовательно для клиентов провайдеров Санкт-Петербурга и Ленинградской области, подключенных к каналам Google в данной точке, проблемы прошлой осени могут проявиться еще в большем объеме.
3. Провайдеры, входящие в ОПГ, заимели прямые пиринговые стыки с каналами Google, что в целом должно улучшить доступ к YouTube, однако ввиду специфической маршрутизации до серверов хранения видео качество доступа и скорость загрузки видео остаются непредсказуемыми и в каждом случае будут разными.
