войти зарегистрироваться

Высокая производительность whois

индекс
125,97

Протокол SPDY ускорит Сеть вдвое

Разработчики из компании Google только что объявили, что работают над новым сетевым протоколом SPDY (читается как SPeeDY, то есть «быстрый»), который должен проапгрейдить протокол HTTP и значительно повысить скорость работы всех типов соединений.

SPDY позволяет вдвое уменьшить задержку (latency) при работе через HTTP. Делается это за счёт трёх методов:

1) мультиплексирование запросов;
2) расстановка приоритетов для запросов;
3) сжатие заголовков HTTP.

Чтобы продемонстрировать все возможности SPDY, инженеры Google подняли тестовый веб-сервер и выпустили специальную версию браузера Chrome.

По итогам предварительного тестирования на канале максимальной толщины, выигрыш в скорости загрузки для 25 крупнейших сайтов интернета составлял до 55%.
+65
13 ноября 2009, 01:40
12
alizar

комментарии (86)

  • Хром в исходниках?
    а как скачать уже собранный?
    • Спасибо.
      а то я никак не мог проснутся с утра )))
  • Давно пора было с HTTP что-то делать.
    • Мицгол уже давно придумал гипертекстовый FIDONet. осталось только реализовать и он обгонит всё остальное.
  • Ждем на неделе заявление от Yahoo, что они также начали разработку нового протокола, который ускорит интернет.
    • =)
      А вообще это совсем не та область, в которой Гугл и Яху конкуренты. Ускорение выгодно обоим как разработчикам веб-приложений, и затягивать это дело конкуренцией было бы невыгодно.
      Уж скорее стоит ожидать альтернативы от Майкрософт — протокол, который ускорит веб на 56 %… но лет через десять.
    • следом яндекс.хттп
    • да, даёшь гонку интернетов!
  • Еще лет через 5 догадаются, что если выкинуть внизу TCP и заменить его на UDP, то можно ускорить еще вдвое :)
    Кстати, телефонисты с VoIP signaling протоколами уже давным-давно прошли по аналогичным «граблям».
    • UDP не гарантирует доставку. В VoIP не страшно потерять пару пакетов, а скажем для исполняемого файла это беда.
      • котроль целостности можно поверх организовать. Вообщем порка уже активнее менять интернет…
        • А точно лучше получится?
          • я гарантирую это!
            P.S.
            ясно дело мы все уткнулись в чисто физические ограничения каналов => надо решать эту проблему, но в тоже время оптимизировать все остальное, самый дельный способ: смотрим дату последнего мажорого изменения в элементе, давно? крутим этот элемент. например от IPv4 уже давно пора отказываться.
            • Тут крайне опасно высказывать мнение о том, что современная структура web ужасна. Сразу куча одминов начинает минусовать за неуважение к их любимым http-серверам, или, упаси Бог, к PHP или JS. :)
            • Думаю, проблема не в самом TCP, а в том количестве порно, которое приходится прокачивать интернету.
              А вообще, переход на новый протокол технически сложен и обходится очень дорого. Так что лучше тратить силы не на аналоги неплохо отлаженных и всеми поддерживаемых протоколов, а на что-нибудь действительно новое. Вот, например, есть интересный проект CCNX (content-centric networking).
        • то есть вы хотите убрать целостность, а потом добавить ее еще раз? о_О
          если я вас правильно понял, то это равносильно увеличению размера фрейма
          • добавить только там где надо. И поменять смысл целостности, например проверят целостность частей файла, а не каждого пакета как пример. Да и не одной проверкой целостностью tcp беден.
            • Класно, скачал 700 меговый файл, частями по 1 мегабайту. В итоге все части оказались битыми. Лучше уж и там и там проверять, и в пакетах и в p2p клиенте.
              • вы вас какието проблемы со связью :) я качал исошки по tftp, ничего нормально скачалось. у меня тонкие клиенты по udp качают ядро системы, это конечно не услувия через интернет, но все же. p2p вообщето на udp переходит. И да: чем ситуация с 700 битами частями отличается 700 битый частей в tcp? тут проверка каждого пакета (в tcp), а в udp пусть будет части, размером ну наример с 512килобайт. часть не сошлась шлет поновой.
                • Сделайте прототип и попробуйте передать файл. именно через интернет.
                  • ZOMG!
                    MD5 (kernel) = 0e81c7786ae6a7dab47cd09b900f8856 -приемник
                    MD5 (kernel) = 0e81c7786ae6a7dab47cd09b900f8856 -источник
                    du -h kernel
                    3,3M kernel
                    пришлось таймауты крутить, из-за того, что я нахожусь в США, а сервер в Сибири.
                    P.S.
                    bash.org.ru/quote/394858
                    • Передавлось 3,3М? Тогда для чистоты эксперимента передать 700 метровый файл. Все замерить. Потом передать с помощью TCP (многопоточно). Все замерить. И если udp вырулит — то статью на хабр с цифрами ;)
        • Зря человека минусуете, у нас SCADA система на UDP написана, обрабатывает десятки тысяч сигналов. UDP работает в несколько раз быстрее TCP за счет того, что не надо осуществлять коннект и разрыв соединения.
          А контроль целостности реализуется поверх протокола.
          • вот об этом я и говорю, не контроль целостности основная проблема TCP. Забавно плюсуют тех чьи коментарии или шутка или человек не в теме — #comment_2174857 #comment_2175082
            • а что вы с аутентификацией делать собираетесь?
              • ооо а в TCP уже устроенный алгоритм аутенфикации появился? Ну лично я буду использовать authpf, залогинился на сервер и попал в гудлист :)
                • ну да, он там всегда имелся — это числа syn и ack.
                  Очевидно, что использовать TCP лучше, чем UDP с кучей накрученных костылей.
                  • это создание сессии. аутенфикация на уровке: это я! а это я! точно ты? точно, а ты? да!
                    от спуфинга она почему-то не спасает.
                    • это спасает вас от спуфинга, когда нет человека посередине, т.е. в 99 процентах случаев
          • Если вам надо отправлять изредка сигналы, то на каждый сигнал устанавливать соединение, а потом его закрывать — это фигня в большинстве случаев

            Если вам надо отправлять сигналы довольно часто, то установить соединение и отправлять сигналы по заранее установленному соединению — вполне приемлемо в большинстве случаев.

            Если у вас данные идут сплошным потоком, то использовать UDP — это фигня в большинстве случаев.

            Ествественно всё зависит от конкретной задачи. Если у вас производительность не требуется, то можно и на каждое сообщение TCP-соединение устанавливать. UDP (фактически user-level IP) оставили не просто так.
        • UDP + контроль целостности = TCP
      • Я не зря сказал про сигнальные протоколы. Поверх UDP делается какой-нибудь reliable datagram protocol. В идеале — даже вместо UDP, но это было бы хуже с точки зрения проникновения через современные firewalls. Использование UDP и прочих над ним навернутых протоколов без установления соединения позволяет сэкономить на паре обменов сообщениями.
      • TCP/IP — «глупый» протокол. Он ничего не знает о специфике данных внутри пакетов, а для той самой «гарантированной доставки» просто шлет данные повторно, не учитывая что реально нужно переслать, а что — нет. Как образец умного протокола — uTP: он в состоянии четко определить, что именно прошло/непрошло и что нужно отправить повторно.
    • UDP — это совсем не решение. Собственно, в нише HTTP, TCP замечательно работает и замечательно такому применению подходит.

      Ну и собственно, кроме TCP/UDP, для любителей экзотики, есть еще SCTP и DCCT. У SCTP есть реализация для винды.
      • > есть еще SCTP и DCCT.

        Вот именно, только что хотел об этом напомнить. :-)
      • Как раз хотел про SCTP сказать. Как замена TCP вполне себе подойдет. И реализация есть, конечно, далеко не только для винды. =)
        В телефонии им пользуются и не жалуются. (http://en.wikipedia.org/wiki/SIGTRAN)
    • В VoIP TCP не подходит по той причине, что он будет до посинения стараться передать пакет, которые уже как 20 ms нафиг никому не нужен, а тот что нужен стоит в очереди.
      • Аналогично и для web — посмотрите сколько картинок и баннеров на типичной странице — на каком-нибудь новостном сайте, например. Либо одна из них «застрянет» и все остальные не будут грузиться из-за нее, либо нужно устанавливать отдельное соединение на каждую картинку — а отдельное соединение это 1.5 rount-trip обмена в TCP handshake (SYN, SYN-ACK и ACK) плюс оно «отъедает» порт на сервере, кроме того, если нужно одну из картинок загрузить с другого сервера (заранее не известного для балансирования нагрузки), то нужно либо делать редирект, либо динамически генерировать все содержимое страницы, либо заниматься всякой фильтрацией и вмешательством в протоколы более высокого уровня.
        • > посмотрите сколько картинок и баннеров на типичной странице

          Банеры, как правило, с других серверов идут, вообще-то.
    • TCP при передачи потоковых данных работает быстрее, чем UDP за счет масштабирования окна данных.
      • Алгоритмы масштабирования окна в стандартном TCP (понимаемом всеми операционными системами и роутерами) был придуман очень давно и морально устарел. Кое-что исправили новыми совместимыми патчами, но нельзя ведь выйти за пределы принципиальных ограничений, наложенных форматом пакета и его интерпретацией уже существующим оборудованием. А вот новые протоколы, которые реализуются поверх UDP, по определению свободны от таких ограничений, которые идут от необходимости поддерживать совместимость со всем старым железом и ОС.
        В принципе для альтернативных протоколов (типа SCTP) не нужен даже UDP, они могут прекрасно работать и поверх чистого IP. Но на практике очень многие firewalls, провайдеры и т.п. убивают пакеты неизвестных им протоколов или сильно дискриминируют этот трафик. Поэтому в открытом Интернете использовать UDP надежней. В закрытых же сетях можно работать прямо поверх IP.
        Если TCP работает быстрее, чем продвинутые дейтаграмм-ориентированные протоколы, то либо это плохие протоколы, либо проблема в шейпинге траффика недобросовестными провайдерами или оборудованием, которое специально отдает предпочтение TCP и дискриминирует UDP.
        Если нет никакой дискриминации, то UDP в сочетании с умным протоколом работает быстрее, чем обычный TCP. Естественно речь идет о ситуации, когда часть пакетов теряется или повреждается. На идеальном канале без потерь, вариаций в задержке и искажений, «кондовый» TCP может быть быстрее — за счет поддержки на уровне ядра ОС и железа.
        • Ну по-моему это почти очевидно, что TCP является частным случаем протокола поверх IP, так что под конкретную задачу свой протокол может быть оптимальнее. С UDP то же самое, разве что с поправкой на дополнительный оверхед на UDP. О чём здесь спорить то?

          Другое дело, что не всегда оправданна разработка своего собственного протокола, если default (TCP) приемлем.
          • Вообще спор был о том, что TCP с его handshake и свойством останавливать весь поток из-за потери или повреждения одного-единственного кадра уже не адекватен для большинства современных приложений. Раньше приложения были простыми и применение TCP позволяло не заморачиваясь быстро писать программы. Теперь имплементация пересылки байтов по сети составляет 1% от времени разработки приложения в целом. Поэтому пользы от той автоматизации, которую дает TCP, уже ОТНОСИТЕЛЬНО мало. А вот вносимое им принципиальное ограничение на задержку всего потока из-за единственного потерянного кадра — реально мешает быстрой загрузке страниц (например). Как и начальный handshake. Да и алгоритмы окна, алгоритм неселективных подтверждений в TCP, отсутствие ECN — все это уже устарело. Что-то улучшают совместимыми патчами, а что-то нельзя улучшить без нарушения совместимости. Поэтому было бы логичным вообще отказаться уже от массового использования TCP.
  • Недостатки HTTP известны сразу с его появления, ничего революционного в этом нет. То, что исходит оно от гугла, хорошо тем, что гугл имеет несколько превышающие нулевую отметку шансы это дело протолкнуть, во-вторых, типичный «админ», не читавший в жизни ни rfc 2616, ни вообще ничего, таки поведется на шум =)
  • 55% — это не вдвое :-)
    • Если брать время отправки по протоколу HTTP за 100%, SPDY уменьшает время загрузки в 2 раза, то скорость SPDY 50% быстрее или составляет 50% от скорости HTTP.
      • … то скорость быстре в два раза, а не на 50%, и составляет она не 50% скорости а 200% скорости более медленного протокола.

        А вот время, затраченное на передачу, может быть на 50% меньше изходя из ситации описанной вами.

        P.S.
        Почитал оригинал, там действительно имеется ввиду время загрузки, а не скорость.

        Вывод 1: статья криво переведена и ввела в заблуждение Brybndin и меня тоже :)
        Вывод 2: всегда нужна ссылка на оригинал.
  • В плане внедрения основная проблема даже не в обновлении браузеров, а в обновлении серверного ПО. Пока нет поддержки со стороны Апача и других серверов — протокол останется игрушкой Гугла.
    • я думаю, при необходимости апач быстро подкрутят. А вот в ISS поддержка может появится не скоро
      • фи, не мучайте покойника, он живет только за счет роста популярности вендосервером, которая растет из-за обилия эникейщиков и непонимания индивидов из 1С и тому подобных, что SaaS это хорошо, а дрежать продукты только под Windows это не православно, это даже не сотонически это по fagot'ски.
        • ой, как толсто, советую покурить доки по IIS, особенно по 7.x
          просветлиться, так сказать
          blogs.iis.net/bills/archive/2007/5/7/1696624.aspx
          digg.com/software/Apache_vs_IIS6_Which_handles_the_digg_effect_better
          • нафига? у меня винды нет. Он ставится на *nix like? им можно рулит из консоли и хранить конфиг в sql? apache не панацея. Или чтобы поднять вэь сервер мне надо обязательно графическую оболочку в систему ставить и держать ее запущеной? А еще круто расход ресусрсов во время простоя. Вот когда винда (серверная) научится держать idle на 99% во время простоя со всеми запущеными сервисами тогда посмотрю в эту сторону. А когда можно будет все делать из консоли полноценно, а не через костыли — может даже поставлю потестить.
            P.S.
            не ожидал встреить фаната IIS тут, собстно я не троллю :)
            • >Он ставится на *nix like?
              а зачем?
              >им можно рулит из консоли
              да
              > и хранить конфиг в sql?
              0_0
              >Или чтобы поднять вэь сервер мне надо обязательно графическую оболочку в систему ставить и держать ее запущеной?
              не обязательно, Windows Core Install
              >А когда можно будет все делать из консоли полноценно, а не через костыли — может даже поставлю потестить.
              PowerShell

              PS я не фанат, просто я знаю, что ИИС хорош, т.к. работаю как с апач/нжинкс+пхп, так и с ИИС+.нет
              • да я IIS не крутил из-за осадака 6 версии. не разу встречал чтобы винду настраивали через консоль (через консоль, а не MMC).
                >> и хранить конфиг в sql?
                >0_0
                очень удобно для vhost'ов :)
                >PS я не фанат, просто я знаю, что ИИС хорош, т.к. работаю как с апач/нжинкс+пхп, так и с ИИС+.нет
                меня платформа .NET не привлекает.
                >>Он ставится на *nix like?
                >а зачем?
                зачем мне плодить сервера если у меня уже есть сервера на freebsd,dragonflybsd?
                >Win 2008 Web раздаётся майкрософтом на каждом углу (выставки, конференции, тренинги, даже когда банально пива попить приглашают)
                в моем городе ниразу не было такого, мне в дефолтсити ехать за бесплатной виндой?
                И насколько я понимаю на десктоп мне тоже придется ставить винду.
            • у вас 0 знаний в вопросе IIS7.X
              • Я бы добавил, что 0 не только в IIS7, но и в IIS вообще, а так же серверной архитектуре винды. :)
            • Он ставится на Win. Точнее интегрирован в неё.

              Им можно рулить из консоли. Более того, всей виндой можно рулить из консоли. Курим Win 2008 Server Core.

              Конфиг штатно нельзя хранить в sql (хотя сторонние расширения вроде позволяют, не интересовался детально), но конфиг ииса — это обычный xml-файл, которым куда как удобней программно рулить, нежели реляционной sql-базой.

              А вообще, IIS7+ вполне себе нормальный сервер, конфигурится от «мегашутстро отдаём статику, что аж nginx отдыхает» и до полноценного сервера приложений ASP.NET. Кстати, ASP.NET при грамотном подходе побыстрее PHP. В частности за счёт jit и возможности контроля запроса на почти всех стадиях его прохождения в сервере (т.е. на стадии принятия, распаковки, авторизации и т.д.).

              И да, я сейчас работаю исключительно с ASP.NET и Win-платформой. Пришёл с nix'ов и просто счастлив тому факту, что не надо самому городить зоопарк из nginx+apache+php+memcached+eAccelerator+fastcgi и т.д. Теперь у меня всё в одном процессе и очень быстро.

              PS: Следующим шагом своей эволюции считаю избавление от «реляционной зависимости» :)
            • PS2: И если Вы сейчас начнёте рассказывать про то, что всё это Win-счастье стоит немалых денег, то сразу отвечаю, что Win 2008 Web раздаётся майкрософтом на каждом углу (выставки, конференции, тренинги, даже когда банально пива попить приглашают) бесплатно с правом коммерческого использования. ASP.NET бесплатен и идёт с .NET Framework. IIS7/7.5 бесплатен и идёт с сервером. SQL Server существует в бесплатной Express-редакции, в которой для web-разрабочика практически нет ограничений. Visual Studio тоже существует в бесплатной Express-редакции, в которой хоть не так комфортно, как хотелось бы, но всё же вполне юзабельно.

              PS3: Win-хостинг на том же паркинге от 99руб/мес :)
              • скачал, сейчас посмотрю. За полследнии пол-года MS ушли дальше чем я думал. Но все равно винда в фоне жрет ресурсов больше…
                P.S.
                скольже тут любитейлей MS. это пугает, надо срочно с этим, что-то делать.
                • Сейчас как раз разворачиваю Win 2008 Web Server на неттопе Acer Revo R3610… :) Посмотрим :) если удовлетворит мои запросы — пойдёт в агаву на колокейшн :)
                  • нет ну это уже не нормально. я покидаю этот спор.
      • Если вы имели ввиду IIS (а вы его имели ввиду, правда?), то исходя из архитектуры IIS 6 ( https://msdb.ru/Downloads/Docs/Events/Materials/281102/SEC10.ppt ) сам IIS переписывать и не придется, достаточно переписать или заменить драйвер http.sys. Кстати, во время работы IIS не имеет сетевых подключений и не слушает никаких портов. По поводу IIS 7 не скажу — пока плотно с ним не занимался, но сетевое взаимодействие там должно быть как у IIS 6.
        • нда, опечатался конечно ISS.

          Сенкс за ссылку. Интересно, почитаю.
  • Зачем такие революции, можно же эволюционировать, сделав протокол HTTP 1.2 с обратной совместимостью. Так же как сейчас с протоколом HTTP 1.1 по сравнению с HTTP 1.0.
    • то что создает гугл — это протокол более низкого уровня. его на уровень http не выведешь.
      • Вообще-то SPDY это протокол такого же прикладного уровня (по отношению к Интернету), как и HTTP. Вы, возможно, с SCTP путаете, тот — протокол уровня TCP/UDP.
  • Я вот помню лет 6 назад мужики меняли в TCP алгоритм прохождения и подтверждения пакетов, получая большой прирост скорости и качества сигнала. Где оно теперь? Если SPDY будет поддерживать только хром, который надо собрать из исходников и сервер гугла, который вообще отсутствует в открытом доступе — кому он нужен? А если и нет… Ну будет в Apache прописано «да, мы поддерживаем SPDY», ну и что? К тому же у большинства народу в интернете ширина канала такая, что никаких приростов они не увидят. Какой прирост на 512кбит может быть, когда браузер просто чтобы получить информацию тратит в десятки раз больше времени, чем занимает задержка…
    • ROX
    • ROX
    • 13 ноября 2009, 08:37
    • #
      • 0
    Информационное присутствие. Считаные единицы выведенных на производственный уровень проектов, зато бренд постоянно на слуху.
    Молодцы.
  • извиняюсь, если спрашиваю что-то не то, но как его собрать из исходников?
  • Странно, что они в работе ни разу не упомянули SCTP, ни в аспекте сравнения с HTTP over SCTP, ни в аспекте перевода сообщений SPDY на SCTP.
    • Да вроде упомянули.
      • Действительно, ваша ссылка намного более актуальна для первоначального ознакомления, чем приведённые в оригинальном посте.
  • Не читая предварительно комментов, готов поспорить, что чуть выше уже кто-нибудь ляпнул про «новый интернет с блекджеком...» и т.п. ;)
    • как ни странно… :)
      • Блин, проспорил… Не тот нонче хабраюзер пошел, то ли дело былые времена :)
  • >По итогам предварительного тестирования на канале максимальной толщины, выигрыш в скорости загрузки для 25 крупнейших сайтов интернета составлял до 55%.

    что-то я вот эту фразу не понял. Это как они тестировали этот протокол для крупнейших сайтов, если для тестирования необходимо также установить какую-то штуку, которая будет поддерживать этот протокол на серверах этих сайтов?
    • скачали заглавные страницы на диск и отдали своим сервером?
  • Походу Google в процессе проектирования Chrome OS замерил производительность всего начиная с момента включения питания.
    Особо узкие места выделили и сформировали команды по изучению проблемы.
    Так что это не последняя статья про то, что гугл изобретает что-то по новой.

    С другой стороны, они тут подкрутят, там подопрут и глядишь сделают незаметной глазу простого пользователя разницу между хранением документов на сервере и в локали.
    То есть в рамках Chrome OS данный протокол найдёт своё применение, даже, если никто кроме серверов Гугла не будет его поддерживать.

    PROFIT…
  • По-моему, это очередной клон opera-turbo-подобных сервисов. Достаточно на выходе в интернет http жать в gzip, и на выходе сайтов жать в gzip — получится прирост не меньший в скорости, но за счет процессоров.

    А сжатие HTTP-заголовков приведет к апгрейду межсетевых экранов, что куда дороже, чем удобство быстрого просмотра вКонтакте для сотрудников.
  • Рекомендую в конце статьи дать ссылку на ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%82%D0%B5%D0%B2%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_OSI
    Успехов.
  • Идея неплохая.
    А надо понимать, что до adoption ее не такой уж большой путь.
    Мест «где нужно поменять» глобально не так уж много.
    Web-серверы
    Vendor Product Web Sites Hosted Percent
    Apache Apache 108,078,535 46.90%
    Microsoft IIS 49,723,999 21.58%
    Tencent qq.com 30,069,136 13.05%
    Google GWS 13,819,947 6.0%
    nginx nginx 13,813,997 5.99%

    Т.е. если удатся убедить Apache включить в очередной билд поддержку SPDY (а поскольку это Open Source, можно предложить патч), то со стороны Web Server победа будет достигнута.

    На стороне браузеров — ну вот Chrome явно получит поддержку SPDY. Firefox можно предложить патч или профинансировать разработку, в Firefox охотно к Гуглу прислушиваются.
  • Google в последнее время живчик. По всем фронтам.
Только авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.