Жизнь после запрета Google Global Cache: Последствия для провайдеров и клиентов / forpes.ru

Главная
Жизнь после запрета Google Global Cache: Последствия для провайдеров и клиентов

Жизнь после запрета Google Global Cache: Последствия для провайдеров и клиентов +3

29.10.2017 08:46

VASExperts 51 27300 Источник

В сентябре этого года Роскомнадзор разослал провайдерам письма. В них было сказано, что серверы Google Global Cache, увеличивающие скорость доступа к ресурсам Google, не сертифицированы. Регулятор отметил, что наличие этого оборудования в сети провайдера повлечет наложение штрафа до 300 тыс. рублей.

В нашем сегодняшнем материале мы посмотрим, чем грозит отказ от GGC интернет-провайдерам и клиентам.

/ Flickr / freestocks.org / PD

Что такое Google Global Cache

Google стремится обеспечить высокую надежность и производительность своих сервисов, сохранив низкой латентность. С этой целью компания инвестировала в разработку сетевой инфраструктуры. Она состоит из трёх «слоев»: дата-центров, точек присутствия (Points of Presence, или PoP) и кеширующих узлов (Google Global Cache, или GGC).

Дата-центры являются сердцем контента и сервисов ИТ-гиганта. PoP — это узлы, которые соединяют сеть Google с остальным интернетом. Серверы GGC представляют собой часть инфраструктуры, которая находится к пользователям ближе всего и располагается в сети локальных операторов.

На этих серверах временно хранится популярный контент, который часто запрашивают пользователи. Это ускоряет доступ к Google-сервисам: YouTube, Google Maps, Google Play и др. Такое решение экономит полосу пропускания и компании Google, и операторам связи.

Подобные сети доставки контента (CDN) используют и другие компании. Например, «Яндекс». CDN российской компании служит для улучшения качества работы Яндекс.Почты.

Как работает GGC

Без GGC контент, запрашиваемый пользователями (например, видео), поступает напрямую с серверов Google. С кеширующими серверами всю цепочку проходит только первая копия видео. Запросы последующих пользователей обслуживает кеш-узел. Алгоритм работы, согласно презентации сотрудника Google Майка Аксельрода (Mike Axelrod), выглядит так:

Пользователь кликает на ссылку с видео.
DNS провайдера запрашивает у DNS Google IP-адрес контента, если тот ему неизвестен.
DNS-сервер Google знает, что у провайдера есть GGC-узел, способный предоставить запрашиваемый контент.
В ответе он передает IP-адрес этого узла, который пересылается пользователю.
Далее, пользователь получает нужную ему информацию с узла GGC, а не из сети Google.
Если запрашиваемого контента нет на GGC-узле, он запрашивает его у Google от имени пользователя и кеширует для будущих обращений.

Подробнее о том, как устроена система и какое оборудование поставляет корпорация Google провайдерам, вы можете узнать по ссылке.

Последствия запрета GGC

Количество кеширующих серверов Google у крупного федерального оператора довольно велико. Если от них отказаться, то нагрузка на сервера Google и магистрали провайдера увеличится. Выключение серверов GGC скажется на качестве предоставляемых сервисов Google.

Однако основной «удар» примет на себя видеохостинг. По данным аналитического сайта Statista, Россия занимает третье место в мире по количеству активных пользователей YouTube в месяц. Без Google Global Cache видеозаписи на YouTube будут грузиться медленнее, время загрузки самого сайта увеличится.

Также пользователи могут лишиться возможности просматривать видео в высоком разрешении из-за ограничений пропускной способности (у многих провайдеров трафик YouTube считается локальным).

Директор некоммерческой организации «Общество защиты интернета» Михаил Климарев говорит, что отказ от GGC ощутят на себе и интернет-провайдеры. По данным МГТС, стриминговые сервисы (YouTube, Google Видео и др.) потребляют 30% полосы пропускания. В случае отказа от серверов, операторы будут вынуждены расширить каналы передачи данных как минимум на эти 30%.

Если по сети передается видеопоток, 90% которого — YouTube, то с GGC оператор оплачивает лишь часть трафика до сервисов Google. Остальной трафик обрабатывается в дата-центре провайдера и не покидает внутреннюю сеть. Если у провайдера есть филиалы по стране, GGC позволяет экономить на магистралях, потому что трафик не будет покидать пределы одного города.

С уходом GGC этот трафик станет платным. Все это приведет к повышению цен на тарифы интернета. Или даже отказу от безлимитных тарифов. О других прогнозах можно почитать здесь.

Как быть провайдерам

По мнению представителей телекоммуникационных компаний, сервер GGS — это не средство связи, потому не должен сертифицироваться. И запрещать пользоваться системой нельзя. Роскомнадзор, правда, такое определение отвергает.

Также в Рунете можно встретить мнение, что Роскомнадзор требует сертификацию оборудования, чтобы исключить повторение ситуации с Японией. 25 августа сотрудники Google допустили ошибку в протоколе динамической маршрутизации, в результате которой клиенты крупных японских провайдеров не могли выйти в интернет на протяжении нескольких часов. У другой части населения скорость соединения значительно упала.

Еще один вариант — действия регулятора, направленные на запрет GGC, являются формой давления на ИТ-гиганта. Роскомнадзор ждет ответных действий со стороны компании и есть вероятность, что «оппонентам» удастся договориться.

Если этого не произойдет, интернет-провайдерам придется искать выход из ситуации. Одним из вариантов, как было отмечено выше, является увеличение стоимости тарифов или отказ от безлимитного интернета, но в этом случае операторы рискуют потерять клиентов. Увеличивать ширину канала также может быть невыгодно.

Другой вариант — искать способы снижения издержек. Решить проблему запрета Google Global Cache без финансовых потерь нельзя, но можно эти потери минимизировать. Классификация и приоритезация трафика для экономии полосы пропускания способна снизить издержки, сохранив качество обслуживания (QoS) высоким.

Реализуют этот функционал системы глубокого анализа трафика — DPI. Сегодня на рынке такие решения предлагают как иностранные поставщики, так и отечественные — в том числе компания VAS Experts. Количество установок нашей системы СКАТ по России перевалило за 500, при этом 166 лицензий выданы в 2017 году. К слову, в 2015 их было всего 60.

Система DPI дает возможность менять приоритет проходящих пакетов в зависимости от протокола (DSCP/TOS в заголовке IP-пакетов, приоритет в заголовке VLAN- и QinQ-пакетов, класс трафика в заголовке MPLS-пакетов). Маршрутизаторы и шейперы используют эту информацию для обеспечения нужного качества обслуживания. Также системы DPI следят за сетью на уровнях 2–7 модели OSI и защищают её от перегрузок.

При увеличении качества видео (720p, 1080p, 4K) растет нагрузка на канал оператора. Например, в марте 2015 в Австралии трафик сервиса Netflix составил 25% от общего трафика провайдера iiNet. Активное управление трафиком и гибкая настройка приоритетов обеспечивают достойную работу видеосервисов, слегка «подрезая» трафик других приложений в критические моменты.

Еще одним вариантом может стать установка собственного кеш-сервера. Такая возможность есть у нашего решения СКАТ DPI. По статистике 3-терабайтное кеш-хранилище под Youtube-контент для 100 тыс. абонентов снижает внешнюю Youtube-полосу на 30%.

/ Схема подключения кеш-сервера

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

P.S. Другие материалы из корпоративного блога VAS Experts:

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

mediaman
29.10.2017 12:03
#10496610
Я заметил, что работа YouTube на самом деле ухудшилась. Часто натыкаюсь на буферизацию. Возможно это эффект самовнушения, потмоу что не думаю что провайдеры так быстро оттреагировали
1. rub_ak
  29.10.2017 12:28
  #10496642
  вполне возможно, что просто CDN перегружен.
1. Furriest
  29.10.2017 12:33
  #10496654
  Посмотрите, каким именно GGC вы обслуживаетесь. redirector.c.youtube.com/report_mapping
  Правда, придется подбирать браузер, потому что хром, например, ссылку не откроет. Раздолбаи в гугле не знают, как работают SAN-сертификаты.
  
  Потом посмотрите трейс до этого GGC — станет понятнее.
  1. ZyXI
    29.10.2017 14:09
    #10496800
    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.)
    
    Furriest
    29.10.2017 14:33
    #10496840
    В данном случае дебаг не важен, главное — имя GGC, содержащее название оператора и код аэропорта. bka — Быково.
    
    Если скорость ютьюба меняется существенно, а GGC при этом не меняется — проблема в загрузке конкретной ноды GGC или канала до нее. Если меняется GGC — значит, гугл или оператор перекидывает обслуживание вашего префикса между серверами с разной для вас доступностью.
    
    Нюанс в том, что, не будучи оператором, повлиять на это вы всё равно не можете, так что эта информация носит исключительно познавательный характер.
    
    MasMaX
    01.11.2017 11:50
    #10501438
    У меня выдает GGC в моем городе. Город не крупный, получается провайдеры такие кеш серверы ставят во всех городах?
    
    Furriest
    01.11.2017 13:14
    #10501626
    Условие для установки GGC у гугла было — не менее определенного объема трафика из автономной системы провайдера. Поэтому когда провайдер местный — он должен быть достаточно крупным, чтобы этот трафик порождать. С федералами, вероятно, гугл работал совместно, выбирая точки размещения (но это исключительно догадки, как федералы работают с гуглом лучше спрашивать у сотрудников федералов).
    Т.е. если ваш провайдер локальный — его клиенты создают необходимый объем, а если федеральный — то, может быть, у вас стоит кэш уровня региона.
    
    mwizard
    02.11.2017 06:23
    #10502764
    Это base64url, https://tools.ietf.org/html/rfc7515#appendix-C, правда легче от этого не становится — внутри все равно шифрованная белиберда.
  1. inkvizitor68sl
    29.10.2017 16:17
    #10497032
    badidea просто напишите на этой страничке в хром(иуме).
    
    Furriest
    29.10.2017 16:20
    #10497042
    Век живи… Спасибо :)
    
    inkvizitor68sl
    29.10.2017 16:20
    #10497046
    Да не за что)
  1. navion
    01.11.2017 22:38
    #10502522
    А что означает собственный IP-адрес на этой странице?
    
    Furriest
    02.11.2017 03:28
    #10502732
    Ничего особенного. «Я знаю, что вы приходите с этого адреса, это адрес попадает под вот этот префикс, который будет обслуживаться таким вот GGC node».
    Поскольку чтобы вы могли пользоваться GGC, ваш оператор должен проанонсировать префиксы в сторону GGC node по BGP.
    
    navion
    02.11.2017 11:44
    #10503052
    Не, там адреса самой ноды не оказалось (2КОМ). На Билайне адрес есть и до него всего пара хопов с 1 ms, но Ютуб работает намного медленнее.
1. Fagot63
  29.10.2017 14:00
  #10496788
  Та же проблема. Хром часто в последнее время не может проигрывать видео с ютуба в высоком качестве(сьезжает на 240/360р). С Лисы при этом всё нормально воспроизводится в 1080р. Могу разве что предположить что хром плохо работает с медленным интернетом(ростелеком, скорость 7-9мб/с). Порой и Лис не тянет видео в высоком качестве, но если перезагрузить страницу скорость восстанавливается.
  1. Aingis
    29.10.2017 18:12
    #10497242
    Возможно, проблема в формате WebM, который форсируется Гуглом и, соответственно, используется по умолчанию в Хроме.
    
    Fagot63
    29.10.2017 21:21
    #10497426
    Мозилла: Codecs vp9 (303) / opus (251)
    Хром: Codecs avc1.64002a (299) / mp4a.40.2 (140)
    Одно и то же видео принудительно в одинаковом качестве.
    Все станьше и страньше.
    
    Aingis
    30.10.2017 12:35
    #10498266
    Ну, WebM/vp9 вроде как лучше жмёт (конечно, зависит от обработки ютюбом), может, и в сочетании с плохим интернетом и правда стабильнее работает.
    
    Fagot63
    31.10.2017 03:00
    #10499588
    Странно то что webm не хром использует, а лис. Может где галочку в настройках поставить, но где её искать.
1. delvin-fil
  29.10.2017 15:28
  #10496958
  Да нет, не самовнушение. С недавнего времени стало проще(и быстрей) скачать видео в нужном качестве, ибо время ожидания в браузере порой просто неразумное.
  Мегафон-Сибирь.
  1. nidalee
    02.11.2017 09:11
    #10502854
    Попробуйте для начала выключить DASH playback. Правда, качество выше 720р исчезнет, но 720 хватит всем! У меня раньше с 200 мбит\с видео регулярно зависало. С отключенным DASH стало загружаться мгновенно.
    
    delvin-fil
    02.11.2017 09:19
    #10502864
    Включен «по умолчанию»(media.mediasource.enabled). Браузер PaleMoon.
    Думаете стоит отключить?
    Я тут нечаянно, в ходе экспериментов, включил media.gmp.decoder.enabled и youtube/rutube начали показывать ошибку.
1. bertmsk
  29.10.2017 18:09
  #10497238
  Такая беда стала наблюдаться с марта месяца гдето. И только в Хроме. От провайдера не зависит.

Furriest
29.10.2017 12:38
#10496658
+2
В целом вся эта фигня с «якобы запретом GGC» идет от некомпетентности контролирующих органов (ну и дальнейшей истеричности СМИ). Операторы связи не используют в сети (несертифицированное) оборудование гугл — в таком случае еще можно было бы как-то на них давить. Но поскольку операторы связи всего лишь предоставляют гуглу (Райдену) услуги хостинга, не приобретая это оборудование и не устанавливая его в свою сеть — запретить GGC через давление на оператора не так и просто.

rub_ak
29.10.2017 12:46
#10496670
-1
Если учесть, что гугл бесплатно раздавал свои сервера (за точность данного утверждения не ручаюсь), то все встает на свои места.
1. Furriest
  29.10.2017 12:47
  #10496672
  +2
  Не совсем раздавал. Сервера продолжают принадлежать гуглу. И мало того, они еще и платят операторам за хостинг.
  1. rub_ak
    30.10.2017 09:58
    #10497896
    Я имел в виду, что провайдеру они доставались бесплатно, в отличии от рекламируемого решения.

Rend
29.10.2017 13:59
#10496780
Как ни грустно, конец статьи тупо скатывается на рекламу.

В то же время совершенно игнорируются вопросы безопасности. Никакой нормальный поставщик «обновления для браузеров, Windows, антивирусов и другого ПО» не будет передавать данные по нешифрованному каналу в связи с возможностью атаки man-in-the-middle, которой, по сути, и является DPI.

К счастью сейчас всё больше соединений проходит по https, содержимое которого по DPI недоступно.
1. kafeman
  29.10.2017 16:15
  #10497030
  +1
  Всю жизнь обновлял, обновляю и буду обновлять свою систему по «нешифрованному каналу». ЧЯДНТ?
  
  Заголовок спойлера
  После загрузки, естественно, проверяется подпись.
  
  Rend
  29.10.2017 17:00
  #10497124
  В случае обновлений больше вопрос не к шифрованию содержимого, а в его достоверности. В случае проверки подписи также стоит вопрос, а достоверна ли она. Если она получена по тому же http, то в этом нет никакой гарантии.
  
  kafeman
  29.10.2017 18:29
  #10497256
  Как связаны проверка подписи и канал, по которому она получена?
  
  Rend
  29.10.2017 18:42
  #10497268
  В случае незащищённого канала подпись (MD5, SHA-XXX) тоже можно подменить.
  
  kafeman
  29.10.2017 18:49
  #10497278
  https://ru.wikipedia.org/wiki/Электронная_подпись
  
  Если вам лень вникать в математику, достаточно поразмышлять над тем, зачем вообще кому-то понадобилось придумывать такое количество формул, если для передачи подписи требуется обязательно защищенный канал? Правильный ответ: потому что вы можете использовать цифровую подпись при передаче по незащищенным каналам (например: электронная почта, HTTP, FTP и т. д.)
  
  Rend
  29.10.2017 22:16
  #10497486
  Спасибо, я полностью в курсе технологий цифровой подписи. Наверное, Вы невнимательно прочли предыдущее сообщение — я говорил именно об идентификации подлинности отдающего сервера и отсутствии подмены данных от него, а не о шифровании содержимого.
  
  Вопрос в том, что для проверки цифровой подписи скаченного ПО необходимо знать корневой сертификат их издающего центра.
  Аналогично для проверки контрольной суммы MD5/SHA-XXX её значение должно быть сравнено с полученным из авторитетного источника.
  
  А вот в качестве авторитетного источника сейчас практически всегда выступает получение корневого сертификата издателя ПО или контрольной суммы по https, где достоверность сайта (и вот здесь уже обязательно его содержимого) проверяема теми интернет-центрами сертификации, чьи координаты уже зашиты в браузер.
  
  PS. Да, я знаю, что сертификаты можно распространять и на токенах, и на бумажках, но на практике это редкость.
  
  kafeman
  30.10.2017 00:09
  #10497578
  я говорил именно об идентификации подлинности отдающего сервера и отсутствии подмены данных от него, а не о шифровании содержимого.
  И зачем нам это нужно? Вместо того, чтобы скачивать обновление с любого ближайшего сервера, который любезно согласится нам его отдать, мы будем ходить за тридевять земель. Кто выиграет от этого? Никто: провайдеру гонять туда-сюда ненужный трафик, владельцам программы испытывать повешенную нагрузку на сервера в день релиза, пользователю ждать по нескольку часов, пока все загрузится.
  
  Вопрос в том, что для проверки цифровой подписи скаченного ПО необходимо знать корневой сертификат их издающего центра.
  Наличие CA для этой решения этой задачи не обязательно. Но можно сделать и так, да. Не вижу проблем.
  
  Аналогично для проверки контрольной суммы MD5/SHA-XXX её значение должно быть сравнено с полученным из авторитетного источника.
  А вот тут неверно, аналогии никакой нет. Во-первых, я бы не рассматривал хеш-функции как надежную подпись вообще, это скорее контрольная цифра чтобы убедиться, что файл не был случайно (неумышленно) поврежден. Во-вторых, при использовании нормальных алгоритмов, нам не нужно «сравнение с эталоном». И подпись вместе с файлом мы могли получить хоть с серверов АНБ / ФСБ — что с ней сделается-то?
  
  А вот в качестве авторитетного источника сейчас практически всегда выступает получение корневого сертификата издателя ПО или контрольной суммы по https, где достоверность сайта (и вот здесь уже обязательно его содержимого) проверяема теми интернет-центрами сертификации, чьи координаты уже зашиты в браузер.
  Если вы один раз получили программу из «надежного источника» (диск в запечатанной упаковке, сверили хеш-сумму через тот же HTTPS, в случае с WIndows проверили подпись инсталятора), то зачем ей использовать какие-то левые CA, если разработчик сразу может зашить в нее публичные ключи своих собственных серверов? Или даже публичный ключ своего CA, чтобы иметь возможность в будущем расширять свою инфраструктуру. В первый раз — да, нужно быть внимательнее. Но ведь и во всемогущество HTTPS вы верите только исходя из того, что вам не подсунули кукую-то левую сборку браузера или ОС. Тем более, что мы тут обсуждаем обновления.
  
  PS. Да, я знаю, что сертификаты можно распространять и на токенах, и на бумажках, но на практике это редкость.
  Не такая уж и редкость, но чтобы вы не подумали, что я придираюсь, допустим, что это так (правда, сам ключ на бумаге, конечно, не печатают — печатают его отпечаток для проверки человеком).
  
  Yavanosta
  29.10.2017 22:40
  #10497520
  Если я правильно понял, то вы:
  
  Скачиваете с сайта Майкрософт (Эппл, убунта) обновление винды
  
  Скачиваете с сайта Майкрософт значение электронной подписи
  
  Проверяете подпись.
  
  Если канал не защищён то что мешает человеку который подменил файл обновления подменить значение электронной подписи? (Опять же если речь идёт о простой md5/sha).
  
  Настоящую безопасность дают более сложные алгоритмы подписи в которых фигурируют открытые и закрытые ключи, но что-то я редко встречаю обновления подписанные таким образом. Расскажите более конкретно про свой кейс, если можно воздержавшись от оскорблений и сомнений в способностях собеседников.
  
  kafeman
  30.10.2017 00:18
  #10497592
  Если канал не защищён то что мешает человеку который подменил файл обновления подменить значение электронной подписи?
  Вероятно то, что измененная подпись не пройдет проверку?
  
  Опять же если речь идёт о простой md5/sha
  Нет, речь о них не идет.
  
  Расскажите более конкретно про свой кейс
  У меня их много. Взять ту же упомянутую вами «Убунту» — все обновления идут с ближайшего к вам зеркала, никак не подконтрольных создателям этой ОС (например, mirror.yandex.ru — откуда нам знать, что это зеркало не оприходовали ФСБшники?). После загрузки, но перед установкой, проверяется PGP-подпись с помощью публичного ключа, изначально зашитого в дистрибутив.
  
  Yavanosta
  30.10.2017 11:14
  #10498064
  Нет, речь о них не идет.
  
  После загрузки, но перед установкой, проверяется PGP-подпись с помощью публичного ключа, изначально зашитого в дистрибутив.
  
  Спасибо за пояснение.
  
  avost
  01.11.2017 12:34
  #10501528
  перед установкой, проверяется PGP-подпись с помощью публичного ключа, изначально зашитого в дистрибутив
  Откуда вам известна подлинность "изначально зашитого" ключа, если дистрибутив убунты вы тоже скачали с сервера кгб?
  
  kafeman
  01.11.2017 12:58
  #10501592
  
  Речь идет про обновление системы, читайте внимательнее.
  
  То же самое верно про HTTPS.
  
  navion
  30.10.2017 11:20
  #10498070
  но что-то я редко встречаю обновления подписанные таким образом
  
  Обновления Винды подписаны сертификатом MS и просто не запустятся при повреждении или модификации файла.
  
  iChaos
  29.10.2017 19:04
  #10497308
  А каким образом, защищенность (или незащищенность) канала передачи, влияет на аутентичность цифровой подписи?
  
  Rend
  29.10.2017 22:22
  #10497500
  Проверять полученную цифровую подпись нужно по достоверному сертификату, который тоже нужно получить. Аналогично для хеш-сумм.
  
  Лишний раз скажу, что здесь я имею в виду не шифрование содержимого в канале связи, а его соответствие содержимого оригиналу у автора. То есть именно web-сайт с подтверждённым в удостоверяющем центре сертификатом.
  
  kafeman
  30.10.2017 00:20
  #10497596
  Верно, но я никак не могу понять, зачем вам на каждое обновление нужен новый ключ?
  
  Revertis
  31.10.2017 13:53
  #10500082
  Просто народ не может отличить хэширование от электронной подписи, не парьтесь :)

Sultansoy
29.10.2017 17:24
#10497172
Похоже фраза «мы создадим свой интернет» уже в альфе…

nApoBo3
29.10.2017 17:52
#10497218
А не проще разместить тоже самое но у не провайдера? Делаем дочку, лицензии на услуги связи у нее нет, закон о связи на нее не распространяется как и куча нормативных требований, дочка заключает договор в google, все запросы на youtube уходят на сервера дочки. Их по большому счету можно даже из стоек не вынимать.
1. kafeman
  29.10.2017 18:43
  #10497270
  На сколько я понял из статьи, оно сейчас так и есть. Вы просто предлагаете добавить еще одно звено, которое, по сути, излишне.
  
  Сейчас: Google арендует стойку в помещении провайдера.
  Будет: Google арендует стойку у фирмы, которая арендует стойку в помещении провайдера.

igoriok
31.10.2017 13:11
#10499970
Чисто гипотетически, если вместо железяки будет запущена виртуалка, это как-то повлияет на решение РКМ?

vatezlo
01.11.2017 21:48
#10502466
Я работал в телекоме, и знаю как гугл сервера снижали нагрузку на аплинк. Что не инициатива, то сервис хуже — заплати больше. Прям грустно.

a5b
01.11.2017 22:17
#10502500
По статистике 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.