Комментарии 78
Я заметил, что работа YouTube на самом деле ухудшилась. Часто натыкаюсь на буферизацию. Возможно это эффект самовнушения, потмоу что не думаю что провайдеры так быстро оттреагировали
Посмотрите, каким именно GGC вы обслуживаетесь. redirector.c.youtube.com/report_mapping
Правда, придется подбирать браузер, потому что хром, например, ссылку не откроет. Раздолбаи в гугле не знают, как работают SAN-сертификаты.
Потом посмотрите трейс до этого GGC — станет понятнее.
Правда, придется подбирать браузер, потому что хром, например, ссылку не откроет. Раздолбаи в гугле не знают, как работают SAN-сертификаты.
Потом посмотрите трейс до этого GGC — станет понятнее.
curl -D/dev/stdout -L --insecure вполне заменяет браузер, всё равно там plaintext:
HTTP/1.1 200 OK
Date: Sun, 29 Oct 2017 10:56:38 GMT
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Cache-Control: no-cache, must-revalidate
Content-Type: text/plain; charset=UTF-8
Server: ClientMapServer
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Alt-Svc: quic=":443"; ma=2592000; v="41,39,38,37,35"
Accept-Ranges: none
Vary: Accept-Encoding
Transfer-Encoding: chunked
77.37.230.77 => rostelecom-bka3 (77.37.128.0/17)
Debug Info:
o-AAAuOQuco4GD4LDIN5IyPVuYRKGalWlWOBkkkR8_UfOhJj81eTi0Ji4QtHWJZ1romLjxg4Nvm49NGB
IKufnfqu7Cl1fFKtAKHIn5U-RdRFQUwn7Mn7Te3Wo5KIDYx983C5j4K4KKQi4Lu21IKndP7qYNoG8PnP
(и ещё практически три тысячи таких же непонятных строк, которые не base64,
потому что имеют в своём составе подчёркивания и дефисоминусы и не ascii85,
потому что есть только буквы, цифры, подчёркивания и дефисоминусы)(Оператор: onlime.)
В данном случае дебаг не важен, главное — имя GGC, содержащее название оператора и код аэропорта. bka — Быково.
Если скорость ютьюба меняется существенно, а GGC при этом не меняется — проблема в загрузке конкретной ноды GGC или канала до нее. Если меняется GGC — значит, гугл или оператор перекидывает обслуживание вашего префикса между серверами с разной для вас доступностью.
Нюанс в том, что, не будучи оператором, повлиять на это вы всё равно не можете, так что эта информация носит исключительно познавательный характер.
Если скорость ютьюба меняется существенно, а GGC при этом не меняется — проблема в загрузке конкретной ноды GGC или канала до нее. Если меняется GGC — значит, гугл или оператор перекидывает обслуживание вашего префикса между серверами с разной для вас доступностью.
Нюанс в том, что, не будучи оператором, повлиять на это вы всё равно не можете, так что эта информация носит исключительно познавательный характер.
У меня выдает GGC в моем городе. Город не крупный, получается провайдеры такие кеш серверы ставят во всех городах?
Условие для установки GGC у гугла было — не менее определенного объема трафика из автономной системы провайдера. Поэтому когда провайдер местный — он должен быть достаточно крупным, чтобы этот трафик порождать. С федералами, вероятно, гугл работал совместно, выбирая точки размещения (но это исключительно догадки, как федералы работают с гуглом лучше спрашивать у сотрудников федералов).
Т.е. если ваш провайдер локальный — его клиенты создают необходимый объем, а если федеральный — то, может быть, у вас стоит кэш уровня региона.
Т.е. если ваш провайдер локальный — его клиенты создают необходимый объем, а если федеральный — то, может быть, у вас стоит кэш уровня региона.
Это base64url, https://tools.ietf.org/html/rfc7515#appendix-C, правда легче от этого не становится — внутри все равно шифрованная белиберда.
badidea просто напишите на этой страничке в хром(иуме).
А что означает собственный IP-адрес на этой странице?
Такой эффект наблюдаю на СМАРТ ТВ. На компьютерах воспроизводится нормально, только Firefox не использую — Safari или Opera.
А по теме — можно на карте увидеть расположение Google's Global Cache access points
А по теме — можно на карте увидеть расположение Google's Global Cache access points
Да нет, не самовнушение. С недавнего времени стало проще(и быстрей) скачать видео в нужном качестве, ибо время ожидания в браузере порой просто неразумное.
Мегафон-Сибирь.
Мегафон-Сибирь.
Попробуйте для начала выключить DASH playback. Правда, качество выше 720р исчезнет, но 720 хватит всем! У меня раньше с 200 мбит\с видео регулярно зависало. С отключенным DASH стало загружаться мгновенно.
Включен «по умолчанию»(media.mediasource.enabled). Браузер PaleMoon.
Думаете стоит отключить?
Я тут нечаянно, в ходе экспериментов, включил media.gmp.decoder.enabled и youtube/rutube начали показывать ошибку.
Думаете стоит отключить?
Я тут нечаянно, в ходе экспериментов, включил media.gmp.decoder.enabled и youtube/rutube начали показывать ошибку.
Попытка не пытка! Для лисы есть расширения, которые его выключают. Проверить, что сработало, легко: исчезнут 1080, 2к и 4к.
По моим подпискам таких и нет :)
Вот здесь. Хотя, говорят, с новым апдейтом не работает… Но ради науки можно поставить 54 из архива.
Выключил. Максимум 36Кб. Загрузка нормальная. Спасибо.
360
Ого. Значит и остальное они на свой DASH перевели — это печально. Но теперь вы знаете в чем причина! Я бы на вашем месте рассмотрел что-нибудь типа svptube чтобы смотреть не в браузере видео. Должно решить проблему.
А смысл? Я редко смотрю. Что то большое(типа полные игры КВН) я банально закачиваю, а из-за чего то 5-10 минут… Ну не знаю, сейчас, после изменения(media.mediasource.enabled=false) работает нормально.
На «свистке» от Мегафон больших скоростей и не видел никогда, максимум 720. Теперь 360, но загружается нормально.
На «свистке» от Мегафон больших скоростей и не видел никогда, максимум 720. Теперь 360, но загружается нормально.
Такая беда стала наблюдаться с марта месяца гдето. И только в Хроме. От провайдера не зависит.
В целом вся эта фигня с «якобы запретом GGC» идет от некомпетентности контролирующих органов (ну и дальнейшей истеричности СМИ). Операторы связи не используют в сети (несертифицированное) оборудование гугл — в таком случае еще можно было бы как-то на них давить. Но поскольку операторы связи всего лишь предоставляют гуглу (Райдену) услуги хостинга, не приобретая это оборудование и не устанавливая его в свою сеть — запретить GGC через давление на оператора не так и просто.
Как ни грустно, конец статьи тупо скатывается на рекламу.
В то же время совершенно игнорируются вопросы безопасности. Никакой нормальный поставщик «обновления для браузеров, Windows, антивирусов и другого ПО» не будет передавать данные по нешифрованному каналу в связи с возможностью атаки man-in-the-middle, которой, по сути, и является DPI.
К счастью сейчас всё больше соединений проходит по https, содержимое которого по DPI недоступно.
В то же время совершенно игнорируются вопросы безопасности. Никакой нормальный поставщик «обновления для браузеров, Windows, антивирусов и другого ПО» не будет передавать данные по нешифрованному каналу в связи с возможностью атаки man-in-the-middle, которой, по сути, и является DPI.
К счастью сейчас всё больше соединений проходит по https, содержимое которого по DPI недоступно.
Всю жизнь обновлял, обновляю и буду обновлять свою систему по «нешифрованному каналу». ЧЯДНТ?
Заголовок спойлера
После загрузки, естественно, проверяется подпись.
В случае обновлений больше вопрос не к шифрованию содержимого, а в его достоверности. В случае проверки подписи также стоит вопрос, а достоверна ли она. Если она получена по тому же http, то в этом нет никакой гарантии.
Как связаны проверка подписи и канал, по которому она получена?
В случае незащищённого канала подпись (MD5, SHA-XXX) тоже можно подменить.
Здесь я в первую очередь имею в виду, что подлинность контента гарантируется идентификацией подлинности сервера средствами сертификатов SSL.
Здесь я в первую очередь имею в виду, что подлинность контента гарантируется идентификацией подлинности сервера средствами сертификатов SSL.
https://ru.wikipedia.org/wiki/Электронная_подпись
Если вам лень вникать в математику, достаточно поразмышлять над тем, зачем вообще кому-то понадобилось придумывать такое количество формул, если для передачи подписи требуется обязательно защищенный канал? Правильный ответ: потому что вы можете использовать цифровую подпись при передаче по незащищенным каналам (например: электронная почта, HTTP, FTP и т. д.)
Если вам лень вникать в математику, достаточно поразмышлять над тем, зачем вообще кому-то понадобилось придумывать такое количество формул, если для передачи подписи требуется обязательно защищенный канал? Правильный ответ: потому что вы можете использовать цифровую подпись при передаче по незащищенным каналам (например: электронная почта, HTTP, FTP и т. д.)
Спасибо, я полностью в курсе технологий цифровой подписи. Наверное, Вы невнимательно прочли предыдущее сообщение — я говорил именно об идентификации подлинности отдающего сервера и отсутствии подмены данных от него, а не о шифровании содержимого.
Вопрос в том, что для проверки цифровой подписи скаченного ПО необходимо знать корневой сертификат их издающего центра.
Аналогично для проверки контрольной суммы MD5/SHA-XXX её значение должно быть сравнено с полученным из авторитетного источника.
А вот в качестве авторитетного источника сейчас практически всегда выступает получение корневого сертификата издателя ПО или контрольной суммы по https, где достоверность сайта (и вот здесь уже обязательно его содержимого) проверяема теми интернет-центрами сертификации, чьи координаты уже зашиты в браузер.
PS. Да, я знаю, что сертификаты можно распространять и на токенах, и на бумажках, но на практике это редкость.
Вопрос в том, что для проверки цифровой подписи скаченного ПО необходимо знать корневой сертификат их издающего центра.
Аналогично для проверки контрольной суммы MD5/SHA-XXX её значение должно быть сравнено с полученным из авторитетного источника.
А вот в качестве авторитетного источника сейчас практически всегда выступает получение корневого сертификата издателя ПО или контрольной суммы по https, где достоверность сайта (и вот здесь уже обязательно его содержимого) проверяема теми интернет-центрами сертификации, чьи координаты уже зашиты в браузер.
PS. Да, я знаю, что сертификаты можно распространять и на токенах, и на бумажках, но на практике это редкость.
я говорил именно об идентификации подлинности отдающего сервера и отсутствии подмены данных от него, а не о шифровании содержимого.И зачем нам это нужно? Вместо того, чтобы скачивать обновление с любого ближайшего сервера, который любезно согласится нам его отдать, мы будем ходить за тридевять земель. Кто выиграет от этого? Никто: провайдеру гонять туда-сюда ненужный трафик, владельцам программы испытывать повешенную нагрузку на сервера в день релиза, пользователю ждать по нескольку часов, пока все загрузится.
Вопрос в том, что для проверки цифровой подписи скаченного ПО необходимо знать корневой сертификат их издающего центра.Наличие CA для этой решения этой задачи не обязательно. Но можно сделать и так, да. Не вижу проблем.
Аналогично для проверки контрольной суммы MD5/SHA-XXX её значение должно быть сравнено с полученным из авторитетного источника.А вот тут неверно, аналогии никакой нет. Во-первых, я бы не рассматривал хеш-функции как надежную подпись вообще, это скорее контрольная цифра чтобы убедиться, что файл не был случайно (неумышленно) поврежден. Во-вторых, при использовании нормальных алгоритмов, нам не нужно «сравнение с эталоном». И подпись вместе с файлом мы могли получить хоть с серверов АНБ / ФСБ — что с ней сделается-то?
А вот в качестве авторитетного источника сейчас практически всегда выступает получение корневого сертификата издателя ПО или контрольной суммы по https, где достоверность сайта (и вот здесь уже обязательно его содержимого) проверяема теми интернет-центрами сертификации, чьи координаты уже зашиты в браузер.Если вы один раз получили программу из «надежного источника» (диск в запечатанной упаковке, сверили хеш-сумму через тот же HTTPS, в случае с WIndows проверили подпись инсталятора), то зачем ей использовать какие-то левые CA, если разработчик сразу может зашить в нее публичные ключи своих собственных серверов? Или даже публичный ключ своего CA, чтобы иметь возможность в будущем расширять свою инфраструктуру. В первый раз — да, нужно быть внимательнее. Но ведь и во всемогущество HTTPS вы верите только исходя из того, что вам не подсунули кукую-то левую сборку браузера или ОС. Тем более, что мы тут обсуждаем обновления.
PS. Да, я знаю, что сертификаты можно распространять и на токенах, и на бумажках, но на практике это редкость.Не такая уж и редкость, но чтобы вы не подумали, что я придираюсь, допустим, что это так (правда, сам ключ на бумаге, конечно, не печатают — печатают его отпечаток для проверки человеком).
Если я правильно понял, то вы:
- Скачиваете с сайта Майкрософт (Эппл, убунта) обновление винды
- Скачиваете с сайта Майкрософт значение электронной подписи
- Проверяете подпись.
Если канал не защищён то что мешает человеку который подменил файл обновления подменить значение электронной подписи? (Опять же если речь идёт о простой md5/sha).
Настоящую безопасность дают более сложные алгоритмы подписи в которых фигурируют открытые и закрытые ключи, но что-то я редко встречаю обновления подписанные таким образом. Расскажите более конкретно про свой кейс, если можно воздержавшись от оскорблений и сомнений в способностях собеседников.
Если канал не защищён то что мешает человеку который подменил файл обновления подменить значение электронной подписи?Вероятно то, что измененная подпись не пройдет проверку?
Опять же если речь идёт о простой md5/shaНет, речь о них не идет.
Расскажите более конкретно про свой кейсУ меня их много. Взять ту же упомянутую вами «Убунту» — все обновления идут с ближайшего к вам зеркала, никак не подконтрольных создателям этой ОС (например,
mirror.yandex.ru — откуда нам знать, что это зеркало не оприходовали ФСБшники?). После загрузки, но перед установкой, проверяется PGP-подпись с помощью публичного ключа, изначально зашитого в дистрибутив.Нет, речь о них не идет.
После загрузки, но перед установкой, проверяется PGP-подпись с помощью публичного ключа, изначально зашитого в дистрибутив.
Спасибо за пояснение.
перед установкой, проверяется PGP-подпись с помощью публичного ключа, изначально зашитого в дистрибутив
Откуда вам известна подлинность "изначально зашитого" ключа, если дистрибутив убунты вы тоже скачали с сервера кгб?
- Речь идет про обновление системы, читайте внимательнее.
- То же самое верно про HTTPS.
- именно об обновлении. Ну, скачаете вы обновление подписанное ключём кгб и подтвердите его подлинность своей частью ключа, который зашит в ваш дистрибутив, скачанный до этого с серверов кгб же. Или какого другого злобного хацкера. Можете спать спокойно? Вы же проверили обновление! Ну, не работает только одна часть системы безопасности, только всё полностью. Думайте внимательно. А если строить полную систему, то удобнее с https. Распределение публичных pgp-ключей — та ещё боль.
- Не совсем так. Вернее, совсем не так. Стандартная практика в нормальных компаниях — ручная установка собственных сертификатов и последующее обновление софта только с серверов компании, через, сюрприз, https и его разновидности, используя эти сертификаты. А для большинства других менее параноидальных случаев работает "просто" https с сертификатами, удостоверенными доверенными публичными центрами сертификации. Да, там атаки тоже возможны, но, если всё делать правильно, маловероятны. Для паранойи остаются "свои" сертификаты. Преимущество данного способа — всё работает автоматически.
который зашит в ваш дистрибутив, скачанный до этого с серверов кгб жеЕще раз, речь идет об обновлении. Вопрос того, откуда у вас взялся изначальный дистрибутив, выходит за рамки данного обсуждения.
Стандартная практика в нормальных компаниях — ручная установка собственных сертификатовЧто вам это даст, если ваш дистрибутив, как вы говорите, «скачан с серверов КГБ»? Вас там уже будет ждать «обновленный» OpenSSL, докачивать ничего не придется.
но что-то я редко встречаю обновления подписанные таким образом
Обновления Винды подписаны сертификатом MS и просто не запустятся при повреждении или модификации файла.
А каким образом, защищенность (или незащищенность) канала передачи, влияет на аутентичность цифровой подписи?
Проверять полученную цифровую подпись нужно по достоверному сертификату, который тоже нужно получить. Аналогично для хеш-сумм.
Лишний раз скажу, что здесь я имею в виду не шифрование содержимого в канале связи, а его соответствие содержимого оригиналу у автора. То есть именно web-сайт с подтверждённым в удостоверяющем центре сертификатом.
Лишний раз скажу, что здесь я имею в виду не шифрование содержимого в канале связи, а его соответствие содержимого оригиналу у автора. То есть именно web-сайт с подтверждённым в удостоверяющем центре сертификатом.
Похоже фраза «мы создадим свой интернет» уже в альфе…
А не проще разместить тоже самое но у не провайдера? Делаем дочку, лицензии на услуги связи у нее нет, закон о связи на нее не распространяется как и куча нормативных требований, дочка заключает договор в google, все запросы на youtube уходят на сервера дочки. Их по большому счету можно даже из стоек не вынимать.
На сколько я понял из статьи, оно сейчас так и есть. Вы просто предлагаете добавить еще одно звено, которое, по сути, излишне.
Сейчас: Google арендует стойку в помещении провайдера.
Будет: Google арендует стойку у фирмы, которая арендует стойку в помещении провайдера.
Сейчас: Google арендует стойку в помещении провайдера.
Будет: Google арендует стойку у фирмы, которая арендует стойку в помещении провайдера.
Так в статье же упомянуто, что сами сервера не подлежат сертификации. Что помешает сертифицировать не подлежащие сертификации дочки? Особенно когда органам вторит политика.
Чисто гипотетически, если вместо железяки будет запущена виртуалка, это как-то повлияет на решение РКМ?
Я работал в телекоме, и знаю как гугл сервера снижали нагрузку на аплинк. Что не инициатива, то сервис хуже — заплати больше. Прям грустно.
По статистике 3-терабайтное кеш-хранилище под Youtube-контент для 100 тыс. абонентов снижает внешнюю Youtube-полосу на 30%.
Когда собиралась эта статистика, до 2015 или позже? ("As of March 2015, all Youtube videos are served through HTTPS by default." — https://superuser.com/questions/685851/how-to-redirect-youtubes-videos-url-googlevideo-com-from-https-to-https-autom; HSTS preload list " { "name": "googlevideo.com", "include_subdomains": true, "pins": "google" },": https://productforums.google.com/forum/#!topic/youtube/hf7SDRTmwdg )
Как вы можете кэшировать https сайты?
Требуется ли пользователям устанавливать дополнительный корневой сертификат в ОС или браузер, или у вас есть подписанный сертификат с правом выпуска https-сертификатов для любого домена (basicConstraints.cA = true; vasexperts.ru/blog/filtraciya-url-v-ramkax-zakona/)?
https://forum.nag.ru/index.php?/topic/110449-sistema-keshirovaniya/
DimaM Опубликовано 16 ноября, 2015 "https не кэшируется. youtube временно не кэшируется ( google борется с кэшированием и поломал используемую у нас схему, сейчас готовим решение на замену )"
Опубликовано 10 марта, 2016 Затеяли более глобальные работы: вместо поддержки отдельных видеосайтов делаем универсальное решение (с учетом контрольных сумм
для динамических ссылок). Выход версии планируется во 2 квартале.
Хм, была странная статья: https://vasexperts.ru/blog/ves-mir-shifruet-rossiya-deshifruet-p/
Дешифровать нельзя, но можно перехватить. Именно такой способ и обсуждается в министерствах. Операторы связи должны будут поставить на своих сетях оборудование, способное выполнять MITM-атаку (Man in the Middle). Это оборудование притворяется запрошенным сайтом для пользователя и пользователем – для сайта.… Чтобы браузер пользователя не выдал ошибки сертификата, российский УЦ должен быть добавлен в доверенные корневые центры сертификации на компьютере пользователя. Этот вопрос планируется к решению соглашением с производителями таких популярных обозревателей, как Google Chrome, Mozilla Firefox, Opera.
«Система DPI дает возможность менять приоритет проходящих пакетов»
«Маршрутизаторы и шейперы используют эту информацию для обеспечения нужного качества»
Как ни оптимизируй и не меняй приоритет, если трафика слишком много — это вообще не поможет. Вдобавок видеотрафик в приоритет никто ставить не будет.
Игроманы точно пострадают, ибо с увеличением внешнего трафика пинг во всяких cs:go, lol, SC, дота и др. вырастет. А ведь там и 10 мс заметны.
«Маршрутизаторы и шейперы используют эту информацию для обеспечения нужного качества»
Как ни оптимизируй и не меняй приоритет, если трафика слишком много — это вообще не поможет. Вдобавок видеотрафик в приоритет никто ставить не будет.
Игроманы точно пострадают, ибо с увеличением внешнего трафика пинг во всяких cs:go, lol, SC, дота и др. вырастет. А ведь там и 10 мс заметны.
Использую сторонний опенсорсный плеер PotPlayer ru.wikipedia.org/wiki/Daum_PotPlayer для просмотра видео/плей-листов с Тытруба (в буфере ссылка > Ctrl+U > Enter).
Что характерно, в Хроме тормоза, буферизация, про 1080@60fps вообще можно забыть, плюс битва ADBlock'а с рекламной. В плеере же выставляю максимальное качество + в самом плеере можно дополнительно конвертировать 30 в 60 fps.
Екатеринбург @ Билайн [канал 100 Мбит/с]
Интересно услышать мнение других участников топика. Пользуетесь ли Вы альтернативными средствами просмотра?
Что характерно, в Хроме тормоза, буферизация, про 1080@60fps вообще можно забыть, плюс битва ADBlock'а с рекламной. В плеере же выставляю максимальное качество + в самом плеере можно дополнительно конвертировать 30 в 60 fps.
Екатеринбург @ Билайн [канал 100 Мбит/с]
Интересно услышать мнение других участников топика. Пользуетесь ли Вы альтернативными средствами просмотра?
А что мешает гуглу перейти на обычный CDN? (для ютуба)
При заходе на ютуб гугл знает твой IP и какой у тебя провайдер. Соответственно, можно разместить в этой сети свой CDN-сервер и просто обратиться к нему для подгрузки видео. От провайдера никаких действий не требуется, да и решение проще.
Разве что стоит отметить, что нужно открывать как минимум 2 соединения — для сайта и CDN, но это на всех CDN так (да и сейчас Google итак же открывает 2 соединения).
При заходе на ютуб гугл знает твой IP и какой у тебя провайдер. Соответственно, можно разместить в этой сети свой CDN-сервер и просто обратиться к нему для подгрузки видео. От провайдера никаких действий не требуется, да и решение проще.
Разве что стоит отметить, что нужно открывать как минимум 2 соединения — для сайта и CDN, но это на всех CDN так (да и сейчас Google итак же открывает 2 соединения).
Именно так оно и работает. Не путайте Google Global Cache и рекламу DPI в этой статье.
Только забыли упомянуть, что Ваш кеш сервер не кеширует Ютубчик
Сам работаю в провайдинге небольшого городка вечерами действительно Ютубик тормозит, долго грузит а то и сбрасывает на качесвто 144р хотя общий арендуемы нами канал у магистрала прогружен где-то на 60% всего, и те-же торренты качают на нормальной скорости, speedtest.net показывает скорость по тарифу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Жизнь после запрета Google Global Cache: Последствия для провайдеров и клиентов