Пользователь
30,2
рейтинг
13 ноября 2009 в 01:40

Разработка → Протокол SPDY ускорит Сеть вдвое

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

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

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

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

По итогам предварительного тестирования на канале максимальной толщины, выигрыш в скорости загрузки для 25 крупнейших сайтов интернета составлял до 55%.
Анатолий Ализар @alizar
карма
749,5
рейтинг 30,2
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

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

Самое читаемое Разработка

Комментарии (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.
      • +1
        … то скорость быстре в два раза, а не на 50%, и составляет она не 50% скорости а 200% скорости более медленного протокола.

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

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

        Вывод 1: статья криво переведена и ввела в заблуждение Brybndin и меня тоже :)
        Вывод 2: всегда нужна ссылка на оригинал.
  • +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
      > Где оно теперь?

      Где-где…
      en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm
  • НЛО прилетело и опубликовало эту надпись здесь
  • 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 в последнее время живчик. По всем фронтам.

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