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

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

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

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

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

    По итогам предварительного тестирования на канале максимальной толщины, выигрыш в скорости загрузки для 25 крупнейших сайтов интернета составлял до 55%.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

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

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

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

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

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

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

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

                                            Другое дело, что не всегда оправданна разработка своего собственного протокола, если default (TCP) приемлем.
                                              –1
                                              Вообще спор был о том, что TCP с его handshake и свойством останавливать весь поток из-за потери или повреждения одного-единственного кадра уже не адекватен для большинства современных приложений. Раньше приложения были простыми и применение TCP позволяло не заморачиваясь быстро писать программы. Теперь имплементация пересылки байтов по сети составляет 1% от времени разработки приложения в целом. Поэтому пользы от той автоматизации, которую дает TCP, уже ОТНОСИТЕЛЬНО мало. А вот вносимое им принципиальное ограничение на задержку всего потока из-за единственного потерянного кадра — реально мешает быстрой загрузке страниц (например). Как и начальный handshake. Да и алгоритмы окна, алгоритм неселективных подтверждений в TCP, отсутствие ECN — все это уже устарело. Что-то улучшают совместимыми патчами, а что-то нельзя улучшить без нарушения совместимости. Поэтому было бы логичным вообще отказаться уже от массового использования TCP.
                                        +4
                                        Недостатки HTTP известны сразу с его появления, ничего революционного в этом нет. То, что исходит оно от гугла, хорошо тем, что гугл имеет несколько превышающие нулевую отметку шансы это дело протолкнуть, во-вторых, типичный «админ», не читавший в жизни ни rfc 2616, ни вообще ничего, таки поведется на шум =)
                                          +3
                                          55% — это не вдвое :-)
                                            –2
                                            Если брать время отправки по протоколу HTTP за 100%, SPDY уменьшает время загрузки в 2 раза, то скорость SPDY 50% быстрее или составляет 50% от скорости HTTP.
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                            +2
                                            В плане внедрения основная проблема даже не в обновлении браузеров, а в обновлении серверного ПО. Пока нет поддержки со стороны Апача и других серверов — протокол останется игрушкой Гугла.
                                              +3
                                              я думаю, при необходимости апач быстро подкрутят. А вот в ISS поддержка может появится не скоро
                                                –3
                                                фи, не мучайте покойника, он живет только за счет роста популярности вендосервером, которая растет из-за обилия эникейщиков и непонимания индивидов из 1С и тому подобных, что SaaS это хорошо, а дрежать продукты только под Windows это не православно, это даже не сотонически это по fagot'ски.
                                                  0
                                                  ой, как толсто, советую покурить доки по 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
                                                    –3
                                                    нафига? у меня винды нет. Он ставится на *nix like? им можно рулит из консоли и хранить конфиг в sql? apache не панацея. Или чтобы поднять вэь сервер мне надо обязательно графическую оболочку в систему ставить и держать ее запущеной? А еще круто расход ресусрсов во время простоя. Вот когда винда (серверная) научится держать idle на 99% во время простоя со всеми запущеными сервисами тогда посмотрю в эту сторону. А когда можно будет все делать из консоли полноценно, а не через костыли — может даже поставлю потестить.
                                                    P.S.
                                                    не ожидал встреить фаната IIS тут, собстно я не троллю :)
                                                      +2
                                                      >Он ставится на *nix like?
                                                      а зачем?
                                                      >им можно рулит из консоли
                                                      да
                                                      > и хранить конфиг в sql?
                                                      0_0
                                                      >Или чтобы поднять вэь сервер мне надо обязательно графическую оболочку в систему ставить и держать ее запущеной?
                                                      не обязательно, Windows Core Install
                                                      >А когда можно будет все делать из консоли полноценно, а не через костыли — может даже поставлю потестить.
                                                      PowerShell

                                                      PS я не фанат, просто я знаю, что ИИС хорош, т.к. работаю как с апач/нжинкс+пхп, так и с ИИС+.нет
                                                        0
                                                        да я IIS не крутил из-за осадака 6 версии. не разу встречал чтобы винду настраивали через консоль (через консоль, а не MMC).
                                                        >> и хранить конфиг в sql?
                                                        >0_0
                                                        очень удобно для vhost'ов :)
                                                        >PS я не фанат, просто я знаю, что ИИС хорош, т.к. работаю как с апач/нжинкс+пхп, так и с ИИС+.нет
                                                        меня платформа .NET не привлекает.
                                                        >>Он ставится на *nix like?
                                                        >а зачем?
                                                        зачем мне плодить сервера если у меня уже есть сервера на freebsd,dragonflybsd?
                                                        >Win 2008 Web раздаётся майкрософтом на каждом углу (выставки, конференции, тренинги, даже когда банально пива попить приглашают)
                                                        в моем городе ниразу не было такого, мне в дефолтсити ехать за бесплатной виндой?
                                                        И насколько я понимаю на десктоп мне тоже придется ставить винду.
                                                        +1
                                                        у вас 0 знаний в вопросе IIS7.X
                                                          +1
                                                          Я бы добавил, что 0 не только в IIS7, но и в IIS вообще, а так же серверной архитектуре винды. :)
                                                          +5
                                                          Он ставится на 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: Следующим шагом своей эволюции считаю избавление от «реляционной зависимости» :)
                                                            +1
                                                            PS2: И если Вы сейчас начнёте рассказывать про то, что всё это Win-счастье стоит немалых денег, то сразу отвечаю, что Win 2008 Web раздаётся майкрософтом на каждом углу (выставки, конференции, тренинги, даже когда банально пива попить приглашают) бесплатно с правом коммерческого использования. ASP.NET бесплатен и идёт с .NET Framework. IIS7/7.5 бесплатен и идёт с сервером. SQL Server существует в бесплатной Express-редакции, в которой для web-разрабочика практически нет ограничений. Visual Studio тоже существует в бесплатной Express-редакции, в которой хоть не так комфортно, как хотелось бы, но всё же вполне юзабельно.

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

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

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

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

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

                                                                    А сжатие HTTP-заголовков приведет к апгрейду межсетевых экранов, что куда дороже, чем удобство быстрого просмотра вКонтакте для сотрудников.
                                                                      0
                                                                      Рекомендую в конце статьи дать ссылку на 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
                                                                      Успехов.
                                                                        0
                                                                        Идея неплохая.
                                                                        А надо понимать, что до 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 охотно к Гуглу прислушиваются.
                                                                          0
                                                                          Google в последнее время живчик. По всем фронтам.

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

                                                                          Самое читаемое