Протокол Railgun для сжатия трафика



    CDN-провайдер CloudFlare в прошлом году разработал протокол Railgun для сжатия сетевого трафика. Бинарный протокол, написанный на языке программирования Google Go, передаёт хэши веб-страниц и diff’ы между ними, с поддержкой версионности. После внедрения этой технологии степень сжатия в некоторых случаях достигает 99.6%, что недостижимо с помощью gzip. Сайты 4Chan и Imgur после внедрения Railgun сократили некэшируемый трафик примерно на 50%.

    Сейчас компания CloudFlare объявила, что поддержка протокола реализована также у Amazon Web Services и около 30 крупнейших хостинговых компаний. Поставить Railgun теперь как никогда просто: есть плагины для WordPress, Joomla, Drupal и прочих CMS, выпущены пакеты для большинства популярных дистрибутивов Linux и BSD.

    Любой CDN-провайдер старается кэшировать максимальное количество контента. Но в реальности закэшировать можно только около 66% объектов, а остальные 34% приходится заново запрашивать с сервера в случае обновления. Для сжатия этого трафика и был создан Railgun.



    В Railgun используются примерно такие же алгоритмы, как при обработке последовательности кадров в видео высокой чёткости. Высокая степень сжатия в видеокодеках достигается за счёт сжатия не отдельных кадров, а отличий между соседними кадрами. Это позволяет сжать кадр размеров миллионы пикселов в несколько килобайт. Теоретически можно его сжать вообще в один байт, если он ничем не отличается от предыдущего кадра. То же самое с веб-страницами. При изменении веб-страницы в реальности меняется только небольшая часть, и достаточно передать изменение между актуальной версией и той, которую клиент получил в предыдущий раз.

    Технически, Railgun состоит из двух компонентов: отправителя (sender) и получателя (listener). Отправители установлены в каждом дата-центре CDN-сети CloudFlare по всему миру. Получатель — программный компонент, который предоставляется коммерческим партнёрам CloudFlare. Между отправителем и получателем устанавливается TCP-соединение, защищённое TLS, по которому бинарный протокол Railgun осуществляет асинхронную передачу HTTP-запросов. Для веб-клиента система Railgun выглядит как прокси-сервер, хотя на самом деле это специализированная система со специфическими функциями. Одна из них — сжатие контента, который невозможно кэшировать, за счёт синхронизации версий страниц. При обновлении версии страницы по сети передаётся только изменение между предыдущей и новой версией.



    Тестирование показали, что максимальное сжатие достигается на новостных сайтах с большой посещаемостью. Например, бинарное сравнение главной страницы сайта reddit.com показывает изменение в среднем 2,15% в течение 5 минут и 3,16% в течение часа. Главная страница The New York Times бинарно изменяется на 0,6% за пять минут и на 3% в течение часа. Для главной страницы BBC News эти показатели составляют 0,4% и 2%, соответственно. Вообще, для самых популярных сайтов при повторном запросе diff иногда настолько мал, что помещается в одном пакете TCP.
    Поддержать автора
    Поделиться публикацией

    Комментарии 42

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

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


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

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

                          client -(http)> server

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

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

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

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

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

                                      А по теме, интересно насколько вообще рентабелен такой метод экономии при усложнении системы в целом.
                                        +1
                                        художник хоть на секунду задумывался, как держать такую штуку в руках?
                                        Рукоятка и правда странная. В остальном не вижу сильных отличий от других bullpup винтовок типа СВУ.
                                        image
                                          0
                                          Булл-пап всегда перезаряжается дольше, а для лучшего баланса обычно (если это возможно) ставят переднюю рукоядку.
                                          +1
                                          Какая-то неправильная рельса на первой картинке :(
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                            0
                                            > Бинарный протокол, написанный на языке программирования Google Go

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

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

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

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.