Комментарии 87
Хром в исходниках?
а как скачать уже собранный?
а как скачать уже собранный?
Давно пора было с HTTP что-то делать.
Мицгол уже давно придумал гипертекстовый FIDONet. осталось только реализовать и он обгонит всё остальное.
C HTTP как раз все относительно в порядке, у него узкие места начинают выплывать в его применениях для вполне определенных целей. Например, он ОЧЕНЬ ФИГОВО заточен на работу поверх SSL (HTTPS).
По ряду причин: Начиная с того, что для HTTPS приходиться держать persistent connection (поскольку установление ssl-соединения, это достаточно ресурсоемкий процесс, в отличии от TCPшного обмена 3мя пакетами). Однако этот самый персист ssl-соединения делает «смерти подобным» попытку сделать более-менее что-то highload использующее https. Большинство же стандартных методов оптимизации производительности сервера направленного на обработку десятков тысяч одновременных соединений, оказывается, опять-таки практически нифига не работают ввиду того что http, предполагающий «поток байт», сидит на ssl криптоструктура которого по сути является «блочной».
Список недостатков текущей реализации https могу продолжить…
По ряду причин: Начиная с того, что для HTTPS приходиться держать persistent connection (поскольку установление ssl-соединения, это достаточно ресурсоемкий процесс, в отличии от TCPшного обмена 3мя пакетами). Однако этот самый персист ssl-соединения делает «смерти подобным» попытку сделать более-менее что-то highload использующее https. Большинство же стандартных методов оптимизации производительности сервера направленного на обработку десятков тысяч одновременных соединений, оказывается, опять-таки практически нифига не работают ввиду того что http, предполагающий «поток байт», сидит на ssl криптоструктура которого по сути является «блочной».
Список недостатков текущей реализации https могу продолжить…
НЛО прилетело и опубликовало эту надпись здесь
=)
А вообще это совсем не та область, в которой Гугл и Яху конкуренты. Ускорение выгодно обоим как разработчикам веб-приложений, и затягивать это дело конкуренцией было бы невыгодно.
Уж скорее стоит ожидать альтернативы от Майкрософт — протокол, который ускорит веб на 56 %… но лет через десять.
А вообще это совсем не та область, в которой Гугл и Яху конкуренты. Ускорение выгодно обоим как разработчикам веб-приложений, и затягивать это дело конкуренцией было бы невыгодно.
Уж скорее стоит ожидать альтернативы от Майкрософт — протокол, который ускорит веб на 56 %… но лет через десять.
НЛО прилетело и опубликовало эту надпись здесь
да, даёшь гонку интернетов!
Еще лет через 5 догадаются, что если выкинуть внизу TCP и заменить его на UDP, то можно ускорить еще вдвое :)
Кстати, телефонисты с VoIP signaling протоколами уже давным-давно прошли по аналогичным «граблям».
Кстати, телефонисты с VoIP signaling протоколами уже давным-давно прошли по аналогичным «граблям».
UDP не гарантирует доставку. В VoIP не страшно потерять пару пакетов, а скажем для исполняемого файла это беда.
котроль целостности можно поверх организовать. Вообщем порка уже активнее менять интернет…
А точно лучше получится?
я гарантирую это!
P.S.
ясно дело мы все уткнулись в чисто физические ограничения каналов => надо решать эту проблему, но в тоже время оптимизировать все остальное, самый дельный способ: смотрим дату последнего мажорого изменения в элементе, давно? крутим этот элемент. например от IPv4 уже давно пора отказываться.
P.S.
ясно дело мы все уткнулись в чисто физические ограничения каналов => надо решать эту проблему, но в тоже время оптимизировать все остальное, самый дельный способ: смотрим дату последнего мажорого изменения в элементе, давно? крутим этот элемент. например от IPv4 уже давно пора отказываться.
Тут крайне опасно высказывать мнение о том, что современная структура web ужасна. Сразу куча одминов начинает минусовать за неуважение к их любимым http-серверам, или, упаси Бог, к PHP или JS. :)
Думаю, проблема не в самом TCP, а в том количестве порно, которое приходится прокачивать интернету.
А вообще, переход на новый протокол технически сложен и обходится очень дорого. Так что лучше тратить силы не на аналоги неплохо отлаженных и всеми поддерживаемых протоколов, а на что-нибудь действительно новое. Вот, например, есть интересный проект CCNX (content-centric networking).
А вообще, переход на новый протокол технически сложен и обходится очень дорого. Так что лучше тратить силы не на аналоги неплохо отлаженных и всеми поддерживаемых протоколов, а на что-нибудь действительно новое. Вот, например, есть интересный проект CCNX (content-centric networking).
Черт, теперь уже и ссылку не вставишь.
www.ccnx.org/
www.ccnx.org/
то есть вы хотите убрать целостность, а потом добавить ее еще раз? о_О
если я вас правильно понял, то это равносильно увеличению размера фрейма
если я вас правильно понял, то это равносильно увеличению размера фрейма
добавить только там где надо. И поменять смысл целостности, например проверят целостность частей файла, а не каждого пакета как пример. Да и не одной проверкой целостностью 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
MD5 (kernel) = 0e81c7786ae6a7dab47cd09b900f8856 -приемник
MD5 (kernel) = 0e81c7786ae6a7dab47cd09b900f8856 -источник
du -h kernel
3,3M kernel
пришлось таймауты крутить, из-за того, что я нахожусь в США, а сервер в Сибири.
P.S.
bash.org.ru/quote/394858
Передавлось 3,3М? Тогда для чистоты эксперимента передать 700 метровый файл. Все замерить. Потом передать с помощью TCP (многопоточно). Все замерить. И если udp вырулит — то статью на хабр с цифрами ;)
боюсь, что tftp с этим по инету не справится :) он все же совсем не для этого создан. И в нем не релизована проверка целостности частей о которой я говорю.
То, что 700 фаил передастся с ошибками — 100%, ну и tcp тоже с этими же ошибками и передаст, только завдублит все много раз. и я уже говорил — я нахожусь в тысячах милях от своего сервера.
Вот инфа по uTP (micro TP)
bittorrent.org/beps/bep_0029.html -1
arstechnica.com/old/content/2008/12/utorrents-switch-to-udp-and-why-the-sky-isnt-falling.ars -2
www.thinkbroadband.com/news/3807-utorrent-shifts-towards-udp-to-make-it-work-better.html -3
То, что 700 фаил передастся с ошибками — 100%, ну и tcp тоже с этими же ошибками и передаст, только завдублит все много раз. и я уже говорил — я нахожусь в тысячах милях от своего сервера.
Вот инфа по uTP (micro TP)
bittorrent.org/beps/bep_0029.html -1
arstechnica.com/old/content/2008/12/utorrents-switch-to-udp-and-why-the-sky-isnt-falling.ars -2
www.thinkbroadband.com/news/3807-utorrent-shifts-towards-udp-to-make-it-work-better.html -3
Зря человека минусуете, у нас SCADA система на UDP написана, обрабатывает десятки тысяч сигналов. UDP работает в несколько раз быстрее TCP за счет того, что не надо осуществлять коннект и разрыв соединения.
А контроль целостности реализуется поверх протокола.
А контроль целостности реализуется поверх протокола.
вот об этом я и говорю, не контроль целостности основная проблема TCP. Забавно плюсуют тех чьи коментарии или шутка или человек не в теме — #comment_2174857 #comment_2175082
а что вы с аутентификацией делать собираетесь?
Если вам надо отправлять изредка сигналы, то на каждый сигнал устанавливать соединение, а потом его закрывать — это фигня в большинстве случаев
Если вам надо отправлять сигналы довольно часто, то установить соединение и отправлять сигналы по заранее установленному соединению — вполне приемлемо в большинстве случаев.
Если у вас данные идут сплошным потоком, то использовать UDP — это фигня в большинстве случаев.
Ествественно всё зависит от конкретной задачи. Если у вас производительность не требуется, то можно и на каждое сообщение TCP-соединение устанавливать. UDP (фактически user-level IP) оставили не просто так.
Если вам надо отправлять сигналы довольно часто, то установить соединение и отправлять сигналы по заранее установленному соединению — вполне приемлемо в большинстве случаев.
Если у вас данные идут сплошным потоком, то использовать UDP — это фигня в большинстве случаев.
Ествественно всё зависит от конкретной задачи. Если у вас производительность не требуется, то можно и на каждое сообщение TCP-соединение устанавливать. UDP (фактически user-level IP) оставили не просто так.
UDP + контроль целостности = TCP
Я не зря сказал про сигнальные протоколы. Поверх UDP делается какой-нибудь reliable datagram protocol. В идеале — даже вместо UDP, но это было бы хуже с точки зрения проникновения через современные firewalls. Использование UDP и прочих над ним навернутых протоколов без установления соединения позволяет сэкономить на паре обменов сообщениями.
TCP/IP — «глупый» протокол. Он ничего не знает о специфике данных внутри пакетов, а для той самой «гарантированной доставки» просто шлет данные повторно, не учитывая что реально нужно переслать, а что — нет. Как образец умного протокола — uTP: он в состоянии четко определить, что именно прошло/непрошло и что нужно отправить повторно.
В 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 может быть быстрее — за счет поддержки на уровне ядра ОС и железа.
В принципе для альтернативных протоколов (типа SCTP) не нужен даже UDP, они могут прекрасно работать и поверх чистого IP. Но на практике очень многие firewalls, провайдеры и т.п. убивают пакеты неизвестных им протоколов или сильно дискриминируют этот трафик. Поэтому в открытом Интернете использовать UDP надежней. В закрытых же сетях можно работать прямо поверх IP.
Если TCP работает быстрее, чем продвинутые дейтаграмм-ориентированные протоколы, то либо это плохие протоколы, либо проблема в шейпинге траффика недобросовестными провайдерами или оборудованием, которое специально отдает предпочтение TCP и дискриминирует UDP.
Если нет никакой дискриминации, то UDP в сочетании с умным протоколом работает быстрее, чем обычный TCP. Естественно речь идет о ситуации, когда часть пакетов теряется или повреждается. На идеальном канале без потерь, вариаций в задержке и искажений, «кондовый» TCP может быть быстрее — за счет поддержки на уровне ядра ОС и железа.
Ну по-моему это почти очевидно, что TCP является частным случаем протокола поверх IP, так что под конкретную задачу свой протокол может быть оптимальнее. С UDP то же самое, разве что с поправкой на дополнительный оверхед на UDP. О чём здесь спорить то?
Другое дело, что не всегда оправданна разработка своего собственного протокола, если default (TCP) приемлем.
Другое дело, что не всегда оправданна разработка своего собственного протокола, если default (TCP) приемлем.
Вообще спор был о том, что TCP с его handshake и свойством останавливать весь поток из-за потери или повреждения одного-единственного кадра уже не адекватен для большинства современных приложений. Раньше приложения были простыми и применение TCP позволяло не заморачиваясь быстро писать программы. Теперь имплементация пересылки байтов по сети составляет 1% от времени разработки приложения в целом. Поэтому пользы от той автоматизации, которую дает TCP, уже ОТНОСИТЕЛЬНО мало. А вот вносимое им принципиальное ограничение на задержку всего потока из-за единственного потерянного кадра — реально мешает быстрой загрузке страниц (например). Как и начальный handshake. Да и алгоритмы окна, алгоритм неселективных подтверждений в TCP, отсутствие ECN — все это уже устарело. Что-то улучшают совместимыми патчами, а что-то нельзя улучшить без нарушения совместимости. Поэтому было бы логичным вообще отказаться уже от массового использования TCP.
Недостатки HTTP известны сразу с его появления, ничего революционного в этом нет. То, что исходит оно от гугла, хорошо тем, что гугл имеет несколько превышающие нулевую отметку шансы это дело протолкнуть, во-вторых, типичный «админ», не читавший в жизни ни rfc 2616, ни вообще ничего, таки поведется на шум =)
55% — это не вдвое :-)
В плане внедрения основная проблема даже не в обновлении браузеров, а в обновлении серверного ПО. Пока нет поддержки со стороны Апача и других серверов — протокол останется игрушкой Гугла.
я думаю, при необходимости апач быстро подкрутят. А вот в 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
просветлиться, так сказать
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 тут, собстно я не троллю :)
P.S.
не ожидал встреить фаната IIS тут, собстно я не троллю :)
>Он ставится на *nix like?
а зачем?
>им можно рулит из консоли
да
> и хранить конфиг в sql?
0_0
>Или чтобы поднять вэь сервер мне надо обязательно графическую оболочку в систему ставить и держать ее запущеной?
не обязательно, Windows Core Install
>А когда можно будет все делать из консоли полноценно, а не через костыли — может даже поставлю потестить.
PowerShell
PS я не фанат, просто я знаю, что ИИС хорош, т.к. работаю как с апач/нжинкс+пхп, так и с ИИС+.нет
а зачем?
>им можно рулит из консоли
да
> и хранить конфиг в sql?
0_0
>Или чтобы поднять вэь сервер мне надо обязательно графическую оболочку в систему ставить и держать ее запущеной?
не обязательно, Windows Core Install
>А когда можно будет все делать из консоли полноценно, а не через костыли — может даже поставлю потестить.
PowerShell
PS я не фанат, просто я знаю, что ИИС хорош, т.к. работаю как с апач/нжинкс+пхп, так и с ИИС+.нет
да я IIS не крутил из-за осадака 6 версии. не разу встречал чтобы винду настраивали через консоль (через консоль, а не MMC).
>> и хранить конфиг в sql?
>0_0
очень удобно для vhost'ов :)
>PS я не фанат, просто я знаю, что ИИС хорош, т.к. работаю как с апач/нжинкс+пхп, так и с ИИС+.нет
меня платформа .NET не привлекает.
>>Он ставится на *nix like?
>а зачем?
зачем мне плодить сервера если у меня уже есть сервера на freebsd,dragonflybsd?
>Win 2008 Web раздаётся майкрософтом на каждом углу (выставки, конференции, тренинги, даже когда банально пива попить приглашают)
в моем городе ниразу не было такого, мне в дефолтсити ехать за бесплатной виндой?
И насколько я понимаю на десктоп мне тоже придется ставить винду.
>> и хранить конфиг в sql?
>0_0
очень удобно для vhost'ов :)
>PS я не фанат, просто я знаю, что ИИС хорош, т.к. работаю как с апач/нжинкс+пхп, так и с ИИС+.нет
меня платформа .NET не привлекает.
>>Он ставится на *nix like?
>а зачем?
зачем мне плодить сервера если у меня уже есть сервера на freebsd,dragonflybsd?
>Win 2008 Web раздаётся майкрософтом на каждом углу (выставки, конференции, тренинги, даже когда банально пива попить приглашают)
в моем городе ниразу не было такого, мне в дефолтсити ехать за бесплатной виндой?
И насколько я понимаю на десктоп мне тоже придется ставить винду.
НЛО прилетело и опубликовало эту надпись здесь
Он ставится на 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: Следующим шагом своей эволюции считаю избавление от «реляционной зависимости» :)
Им можно рулить из консоли. Более того, всей виндой можно рулить из консоли. Курим 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руб/мес :)
PS3: Win-хостинг на том же паркинге от 99руб/мес :)
Если вы имели ввиду IIS (а вы его имели ввиду, правда?), то исходя из архитектуры IIS 6 ( https://msdb.ru/Downloads/Docs/Events/Materials/281102/SEC10.ppt ) сам IIS переписывать и не придется, достаточно переписать или заменить драйвер http.sys. Кстати, во время работы IIS не имеет сетевых подключений и не слушает никаких портов. По поводу IIS 7 не скажу — пока плотно с ним не занимался, но сетевое взаимодействие там должно быть как у IIS 6.
Зачем такие революции, можно же эволюционировать, сделав протокол HTTP 1.2 с обратной совместимостью. Так же как сейчас с протоколом HTTP 1.1 по сравнению с HTTP 1.0.
Я вот помню лет 6 назад мужики меняли в TCP алгоритм прохождения и подтверждения пакетов, получая большой прирост скорости и качества сигнала. Где оно теперь? Если SPDY будет поддерживать только хром, который надо собрать из исходников и сервер гугла, который вообще отсутствует в открытом доступе — кому он нужен? А если и нет… Ну будет в Apache прописано «да, мы поддерживаем SPDY», ну и что? К тому же у большинства народу в интернете ширина канала такая, что никаких приростов они не увидят. Какой прирост на 512кбит может быть, когда браузер просто чтобы получить информацию тратит в десятки раз больше времени, чем занимает задержка…
НЛО прилетело и опубликовало эту надпись здесь
извиняюсь, если спрашиваю что-то не то, но как его собрать из исходников?
Странно, что они в работе ни разу не упомянули SCTP, ни в аспекте сравнения с HTTP over SCTP, ни в аспекте перевода сообщений SPDY на SCTP.
Да вроде упомянули.
Не читая предварительно комментов, готов поспорить, что чуть выше уже кто-нибудь ляпнул про «новый интернет с блекджеком...» и т.п. ;)
>По итогам предварительного тестирования на канале максимальной толщины, выигрыш в скорости загрузки для 25 крупнейших сайтов интернета составлял до 55%.
что-то я вот эту фразу не понял. Это как они тестировали этот протокол для крупнейших сайтов, если для тестирования необходимо также установить какую-то штуку, которая будет поддерживать этот протокол на серверах этих сайтов?
что-то я вот эту фразу не понял. Это как они тестировали этот протокол для крупнейших сайтов, если для тестирования необходимо также установить какую-то штуку, которая будет поддерживать этот протокол на серверах этих сайтов?
Походу Google в процессе проектирования Chrome OS замерил производительность всего начиная с момента включения питания.
Особо узкие места выделили и сформировали команды по изучению проблемы.
Так что это не последняя статья про то, что гугл изобретает что-то по новой.
С другой стороны, они тут подкрутят, там подопрут и глядишь сделают незаметной глазу простого пользователя разницу между хранением документов на сервере и в локали.
То есть в рамках Chrome OS данный протокол найдёт своё применение, даже, если никто кроме серверов Гугла не будет его поддерживать.
PROFIT…
Особо узкие места выделили и сформировали команды по изучению проблемы.
Так что это не последняя статья про то, что гугл изобретает что-то по новой.
С другой стороны, они тут подкрутят, там подопрут и глядишь сделают незаметной глазу простого пользователя разницу между хранением документов на сервере и в локали.
То есть в рамках Chrome OS данный протокол найдёт своё применение, даже, если никто кроме серверов Гугла не будет его поддерживать.
PROFIT…
По-моему, это очередной клон opera-turbo-подобных сервисов. Достаточно на выходе в интернет http жать в gzip, и на выходе сайтов жать в gzip — получится прирост не меньший в скорости, но за счет процессоров.
А сжатие HTTP-заголовков приведет к апгрейду межсетевых экранов, что куда дороже, чем удобство быстрого просмотра вКонтакте для сотрудников.
А сжатие 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 охотно к Гуглу прислушиваются.
А надо понимать, что до 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 в последнее время живчик. По всем фронтам.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Протокол SPDY ускорит Сеть вдвое