Pull to refresh

Comments 42

А юзверям надо как-то поддержку этого дела включать или все всё умеют уже?
Юзверям приходит уже обычный «жирный» контент от ближайшего узла с софтом CloudFlare
То есть по сути это протокол, который отвечает за передачу данных внутри CDN — от источника и раздатчику
А чтобы юзверям пришёл контент, они ж должны полезть не на главный сервер сайта, а на ближайший к ним кэширующий.
Как это реализовывается?
Как его незаметно отправить не на reddit.com а на cdn'овский сервак?
Или главная страница идёт с сервера основного, а там уже ссылки на всякую статику и прочее на ближайший cdn вставляются, исходя из ip запрашивающего?
DNS сервер клиенту скажет, что реддит хостится на IP ближайшего сервера CDN.
А что почитать, как DNS так заставляют работать?
Я от деталей внутренностей таких технологий далёк, но любопытно как CDN «обманывает» пользователей :)
Судя по схеме клиент о существовании некого научного рейлгана не подозревает, трафик жмется между сервером с логикой (генерирующий странички веб + база) и пачкой серверов-раздачи разбросанных по ДЦ.
В описанном выше примером экономия показана на линке между CDN и origin. CDN отправляет клиенту контент «как-есть», но забирает с origin используя railgun — экономит кучу траффика, не перевыкачивая тысячи раз запрошенные страницы.
* опоздал дважды, обновляй комментарии после прочтения статьи!
мне кажется, или создатель этого алгоритма Бабушкин? :)

А так, интересно посмотреть на него в действии, а то вдруг получится, что мой девайс будет тратить время на восстановление данных из некоторого снимка и разницы
Нет. У бабушкина все еще круче — телепортация траффика!
Черт я из-за вас проспорил своему товарищу 50 деревянных, я думал вы напишите первым вторым. Он думал 3-5-м.
Неплохо было бы клиента протокола RailGun дать и Visitor-у. Т. е. встроить протокол в браузер, который запускает пользователь.
Разве что для сайтов, которые работают на ajax/hijax и то с кучей оговорок. В браузер такую штуку было бы замечательно встроить, но этого придется достаточно долго ждать. Надо чтобы Гугл аналогичную технологию придумал или купил. И желательно, открыл исходники, чтобы не только серверы Гугла могли в нужном формате контент отдавать.
По большому счету, экономить трафик заинтересованы только компании в пределах своих собственных сетей. Внешний трафик никто экономить не будет, так как он обычно продается — чем больше трафика, тем лучше, больше денег. Поэтому вряд ли стоит ожидать быстрого встраивания подобных технологий в браузеры.
Во-первых, броизводители браузеров, как правило, на внешнем трафике не зарабатывают (включая Гугл), даже МС со своим Ажуров вряд ли так уж заинтересована в большом исходящем трафике, им интереснее продавать процессорное время.
Во-вторых, какой процент от общего трафика составляет HTML? я думаю, не очень большой, даже если брать только http.
С другой стороны, как минимум, Гугл и МС делают немалые деньги на рекламе и если сайты будут грузиться быстрее, они от этого только выиграют (потому, Гугл и продвигает свои speedy).
какой процент от общего трафика составляет HTML?


Как ни странно, не такой уж и маленький. Графика и прочая статика давно уже кешируется подобным образом, для чего предусмотрен статус «304» — «контент не изменился».
Это наблюдение из опыта или догадка? Я вот вижу по крупному проекту, что картинки, скрипты и прочая статика генерирует до 500Мбит в пиках, не смотря на достаточно агрессивное кэширование. html при этом генерирует до 25Мбит. Про медиа-контент даже говорить не хочу, цифры могут вызвать недоумение у неподготовленного человека;) В этоге, доля html это 0,015% от общего трафика.
Соглашусь, что проект проекту рознь — в последнем проекте у меня тоже сотня картинок на несколько килобайт текста. А есть проекты, подобные Википедии, где графики мало, а текста весьма прилично. Так что, разумеется, «аршином общим не измерить»
Даже на вики, небольшая картинка на странице запросто может весить больше текста. А в реальном http трафике пользователя, обычно, еще всякие флешки, некэшированные скрипты и прочее съедает большую часть трафика. Нет такой насущной надобности жать именно html
Пробывал CloudFlare пол года тому. Что могу сказать теоретически это все можно использовать только начиная от $200 в месяц, когда в ход идут другие cdn площадки. Иначе весь трафик раздается с одного хоста (хостов) в San Francisco.
Платить деньги чтобы добавить ещё 1+ звено в цепочку потенциальных MITM и фильтровщиков контента? Гениально.

Also, статья лукавит, подумайте, они говорят об оптимизации некешируемого траффика на 50%, процент некешируемого от реального траффика = 34% (согласно этой же статье), то есть максимальная достижимая оптимизация — 17% от вашего реального http траффика. Если вам в месяц обычно капает 1000 Mb траффика, то с railgun будет 970.
Как я понял, эта вещь удобна для случаев, если вы заходите на одну и ту же страницу в поисках обновлений (например, появилась ли ещё одна новость на странице, или дописали ли комментарии). Ведь в этом случае вам сыпется вся страница целиком, а так просто дифференс.
Эта штука облегчает жизнь CDN и их клиентам. Им меньше трафика между собой гонять. Ну а пользователю плюс в том, что до CDN контент быстрее долетать должен, в теории.
Хохма в том, что даже если хостер и сэкономит 17% траффика (в данной ситуации только хостер экономит траффик), то пользователю это выйдет в лучшем случае никак, а в худшем боком, см коммент bobrik'a ниже.
Весь динамический контент обычно ходит по схеме:

client -(http)> server

С рейлганом будет ходить:

client -(http)> cloudflare -(railgun)> server

При этом у клиента будут заметные тормоза, потому как cloudflare не за нулевое время проксирует каждый запрос. Если сайт в Питере, клиент в Питере, то схема с Питер -> Питер меняется на Питер -> Лондон -> Питер.

Как бы выгода не так уж очевидна :)

Ну и да, «Бинарный протокол, написанный на языке программирования Google Go» — не думал, что протоколы к языкам прибивают гвоздями.
railgun нужен только для CDN, у которых узлы находятся как можно ближе к посетителю. У посетителя при использовании CDN разницы в скорости от railgun не будет, польза в уменьшении трафика только у CDN и у клиента CDN.
Имелось ввиду реализация протокола на Go.
если CDN-сервер стоит в Лондоне, а клиент и origin в Питере, то выгоды, действительно, немного. Вообще толку от CDN, который стоит далеко от клиента (речь о http-статике, для видео всё несколько иначе) нет, один вред. А вот представьте, что сайт в Питере, клиент в Екатеринбурге, и CDN-edge тоже в Екатеринбурге. Схема меняется с Екатеринбург -> Питер на Екатеринбург -> Екатеринбург (CDN) -> Питер (origin). Но во второй схеме есть один нюанс — между CDN-сервером и origin tcp-соединение уже установлено и tcp-окно уже раздуто (я про slow start). Поэтому клиент экономит на tcp-handshake минимум RTT между Питером и Екатеринбургом и tcp-окно расширяется между ним и сервером CDN несколько бестрее из-за малого RTT. Т.е. выгода есть даже без сжатия на длинном учатске (CDN-origin == Екатеринбург-Питер). Если на длинном участке трафик будет ещё и эфективно сжиматься, то всё станет ещё чуть лучше.
Еще бы про алгоритм что-нибудь сказали, а то я давно лениво ищу про это что-нибудь: qa.
Думаю, не лишним будет указать в начале статьи, что протокол предназначен для CDN и пригодится тем, кто уже и так использует CDN.
Хм, художник хоть на секунду задумывался, как держать такую штуку в руках? Рожок возле приклада, задняя часть рукоятки закрыта, даже ухватиться толком не получится.

А по теме, интересно насколько вообще рентабелен такой метод экономии при усложнении системы в целом.
художник хоть на секунду задумывался, как держать такую штуку в руках?
Рукоятка и правда странная. В остальном не вижу сильных отличий от других bullpup винтовок типа СВУ.
image
Булл-пап всегда перезаряжается дольше, а для лучшего баланса обычно (если это возможно) ставят переднюю рукоядку.
Какая-то неправильная рельса на первой картинке :(
UFO just landed and posted this here
> Бинарный протокол, написанный на языке программирования Google Go

Что значит «Бинарный протокол, написанный на языке программирования»? Протокол — это документ. Кстати, в статье нет ссылки на главное — сам протокол.

UPD: Язык называется не Google Go, а просто Go.
UFO just landed and posted this here
Спасибо. Теперь ответьте на вопросы, которые я задавал, а не который вам пришёл из libastral.so.

1. Где сам набор соглашений интерфейса логического уровня?
2. Что значит «написанный на языке програмирования»? Соглашения для интерфейсов принято писать на английском. Вот отличный пример: tools.ietf.org/html/rfc2812
Sign up to leave a comment.

Articles