форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"Компания Google предложила надстройку для улучшения протокол..."		+/–
Сообщение от opennews on 13-Ноя-09, 13:21
Компания Google представила (http://blog.chromium.org/2009/11/2x-faster-web.html) протокол SPDY (произносится "спиди", "Speedy"), реализуемый на уровне приложений и являющийся частью программы (http://code.google.com/speed) по разработке решений по увеличению скорости работы web.  В частности, в SPDY осуществлена попытка решения проблемы HTTP с задержкой соединения между клиентом и сервером. Исходные тексты (http://src.chromium.org/viewvc/chrome/trunk/src/net/flip/) с реализацией SPDY распространяются под BSD-подобной лицензией. Среди характеристик: -  Сжатие заголовков, что, по словам разработчиков, на ~88% уменьшает размер заголовков запроса, и на ~85% -- размер заголовков ответа. На медленном DSL-линке, в частности, сжатие заголовка запроса привело к значительной прибавке скорости при загрузке страницы для некоторых сайтов (например тех, которые породили значительное количество запросов ресурсов). -  SPDY добавляет сеансовый уровень поверх SSL, что даёт возможность создава... URL: http://blog.chromium.org/2009/11/2x-faster-web.html Новость: https://www.opennet.ru/opennews/art.shtml?num=24247
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Компания Google предложила надстройку для улучшения протокол..."		–1 +/–
Сообщение от 82500 on 13-Ноя-09, 13:21
Надстройка обычно = костыль, но тут, судя по анонсу, как-то язык не поворачивается так назвать. Маркетинг :)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Компания Google предложила надстройку для улучшения протокол..."		–3 +/–
	Сообщение от Андрей (??) on 13-Ноя-09, 14:34
	ИМО хорошее начинание.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	43. "Компания Google предложила надстройку для улучшения протокол..."		–2 +/–
	Сообщение от Аноним (??) on 13-Ноя-09, 23:02
	Не фига не хорошее, какой-то костыль, решающий частную проблему. Пусть сделают свою куйню в виде прокси, чтобы локально на компьютер можно было поставить и на сервер. На компьютере пользователя HTTP будет преобразовываться в этот SPDY, отправляться через тырнет на SPDY-сервер, который будет конвертировать его обратно в HTTP и обслуживать. Получится по сути свободная реализация модных у вантузятников веб-ускорителей.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	53. "Компания Google предложила надстройку для улучшения протокол..."		–1 +/–
	Сообщение от spunky (ok) on 14-Ноя-09, 20:32
	прокси-сервер? Не проблема. Особенно при открытом протоколе. Вот модуль для веб-сервера уже посложнее задачка.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	55. "Компания Google предложила надстройку для улучшения протокол..."		–1 +/–
	Сообщение от ТТТ on 15-Ноя-09, 13:18
	Глупость какая!!! почему просто не стандартизировать эти улучшения как HTTP 2.0 и не мучится с настройками если это стандарт да еще и открытый всерано или поздно поддержат.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Компания Google предложила надстройку для улучшения протокол..."		+4 +/–
Сообщение от barmaglot (??) on 13-Ноя-09, 13:41
Аха ... вместо того, что-бы излечить саму болезнь, будем как обычно заплатки делать. Новый протокол это конечно замечательно, особенно со сжатыми заголовками. Но я так понимаю, всего-лишь вводится новый уровень инкапсуляции HTTP протокола. Но почему: а) не изменить стримовый характер самого HTTP на пакетный ? б) не заменить HTML на EBML к примеру ? Маркап останется, доступ к данным изменится с последовательного на параллельный и скорость обработки увеличится. Ещё один момент. Все мы пользуемся NoScript и AdBlock, при параллельном доступе вместо последовательного (стримового), ненужные данные не будут закачиваться. Если сейчас не закачиваются лишь игнорируемые внешние линки, то с подобным изменением можно будет блокировать ненужный контент сервера к которому подсоединён. Причём не просто блокировать при рендеринге, а именно не загружать этот контент. Гибкость филтеринга контента возрастает неимоверно. А HTTP это болезнь. Когда-то давным давно, когда Интернет был маленький, и Мозаик был чудом, HTTP был идеален для своих задач. Все придерживались простого правила, использовать гифы и простенький дизайн страниц. И даже на dialup-е HTTP был вполне приемленм. Через 2 года Интернет настолько вырос, и такое кол-во манагеров разнюхало о его существовании, что появились Веб-Дизайнеры, ну и они конечно стали впихивать в простые и ясные странички, "красоту неимоверную". Чтоб манагерам было хорошо... Но интернету тут-же поплохело, но прошло 2 года и пришёла широкополоска, многим сразу полегчало (в основном в ЮСА, Западной Европпе, Средней Азии и Юговосточно Азии). Еще через 5 лет DSL был почти везде. И кое-где даже DSL2. Сейчас у меня 16/1 Мбит канал но я подумываю о переходе на 32/2 Мбит так как цена та-же а скорость выше. Флеш я не люблю, но пользуюсь. От ютуба не убежишь.  Торрент рулит и вообще есть куда девать пропускную способность. ОДНАКО !!!!! Веб сайты грузятся не быстрее а медленнее. И компьютеры то у меня все быстрее и быстрее, и HTML парсинг шустрый, и JS движки все круче и быстрее, нo иногда очень задалбывает загруженость самих серверов и их отказы от обслуживания. Они медленно отдают тебе твой контент, постепенно и не спеша. Побайтово ... HTML стар. Пора менять.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Компания Google предложила надстройку для улучшения протокол..."		–1 +/–
	Сообщение от vadiml on 13-Ноя-09, 13:51
	> доступ к данным изменится с последовательного на параллельный из-за последовательного доступа обрезка рекламы и счётчиков даёт заметную прибавку в скорости отображения страниц -- броузерам слишком часто приходится подолгу ждать пока загрузятся все баннеры. Как только отключу дома проксю -- впечатление что инет начинает жутко тормозить.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Компания Google предложила надстройку для улучшения протокол..."		–1 +/–
	Сообщение от barmaglot (??) on 13-Ноя-09, 14:28
	Это не из за последовательного доступа, а из за закачки фигни со всех сторон. Обрезка происходит после закачки именно из  за того что протокол последовательный. А твой случай это имменно подтверждает :) Прокси заранее режет все-то что тебе ненужно, и т.д.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Компания Google предложила надстройку для улучшения протокол..."		–1 +/–
	Сообщение от barmaglot (??) on 13-Ноя-09, 14:32
	Цитатко из меня любимого: (1) >Все мы пользуемся NoScript и AdBlock, при параллельном доступе вместо последовательного (стримового), ненужные данные не будут закачиваться. (2) >Если сейчас не закачиваются лишь игнорируемые внешние линки, то с подобным изменением можно будет блокировать ненужный контент сервера к которому подсоединён. (3) >Причём не просто блокировать при рендеринге, а именно не загружать этот контент. Гибкость филтеринга контента возрастает неимоверно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Компания Google предложила надстройку для улучшения протокол..."		+1 +/–
	Сообщение от anonymous (??) on 13-Ноя-09, 15:30
	>Все мы пользуемся NoScript и AdBlock, при параллельном доступе вместо последовательного (стримового), ненужные данные не будут закачиваться. Вот на этой самой странице, отнюдь не перегруженной JavaScript'ом тупое удаление этого JavaScript'а дало уменьшение размера страницы на ~12%. А на каком-нибудь mail.ru эта "оптимизация" даст более 40%. ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "Компания Google предложила надстройку для улучшения протокол..."		–1 +/–
	Сообщение от pavlinux (ok) on 13-Ноя-09, 15:47
	> а именно не загружать этот контент. Как ты себе представляешь игнорировать то, чего ещё не знаешь? Можно указать то, чего не хочешь видеть, но это не значит, что на другой стороне примут во внимание пожелания населения.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	34. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от xxx (??) on 13-Ноя-09, 18:04
	>Причём не просто блокировать при рендеринге, а именно не загружать этот контент. Гибкость филтеринга контента возрастает неимоверно. Вот на этом-то внедрение нового протокола и загнётся. Нафиг гуглам и прочим, зарабатывающим на рекламе, такая фича =)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	41. "Компания Google предложила надстройку для улучшения протокол..."		–1 +/–
	Сообщение от Аноним (??) on 13-Ноя-09, 22:18
	в опере так и работает игнор список для блокирования контента, ничего лишнего не грузится, выкиньте ваш слоуфокс
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	49. "Компания Google предложила надстройку для улучшения протокол..."		+2 +/–
	Сообщение от Michael (??) on 14-Ноя-09, 00:26
	Их персональный слоуфокс они не отдадут. Он им дорог. У остальных AdBlock Plus тоже режет по-человечески.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "по поводу новых идей"		–1 +/–
	Сообщение от Вова on 13-Ноя-09, 14:28
	>Новый протокол это конечно замечательно, особенно со сжатыми заголовками. были какие-то сервисы в том тысячелетии, зиповали веп на лету, вроде как "ускоряли" браузинг, ничто не ново.  Вот на наге человек предложил в "панели мейл.ру" и другие порнографические надстройки браузера добавить что-то вроде торрент-клиента, вот это действительно даст эффект в скорости доступа, но она ни к чему, на мой взгляд, проблема уже давно на стороне клиента, браузеры тормозят. >ОДНАКО !!!!! Веб сайты грузятся не быстрее а медленнее. И компьютеры то >у меня все быстрее и быстрее, и HTML парсинг шустрый, и >JS движки все круче и быстрее Проблема чаще не в отдаче серверов, а в насыщенности яваскриптом/итп. Я часто использую для браузинга 'links -g', когда нужно просто "посмотреть/почитать", без дописок и тп. Странички часто отображаются коряво - но моментально, часто буквально в момент ввода урл, нажатия 'enter', дома сижу на корбиновской 10тке метров/сек, на работе хз какая скорость. Тормозит яваскрипт и тп, вовсе не канал. Если бы отдача сервера была причиной задержек - не было бы разницы между браузингом в links -g и файрфоксе.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "по поводу новых идей"		–1 +/–
	Сообщение от barmaglot (??) on 13-Ноя-09, 14:39
	> насыщенности яваскриптом/итп Так ведь не парсинг скрипта тормозит и скрипты небольшие. Все задержки приходятся на резолвинг имён и подключение к 3-м серверам. А тормоза из за того, что все действия происходят последовательно. Считал тег отпарсил,[ есть реф ] -> пошел по рефу, вытянул, .... тегу конец -> РЕНДЕРИНГ. Весь процесс синхронный и последовательный. Спасает только многопоточность которая рефы в фоне качает.Но рендерить ведь не начнёшь, до тех пор пока не получишь контент.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "по поводу новых идей"		–1 +/–
	Сообщение от Ананим on 13-Ноя-09, 15:03
	Открой для себя оперу :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "по поводу новых идей"		+/–
	Сообщение от abbadon on 13-Ноя-09, 15:39
	Ставим фаербаг в идём на вкладку net и смотрим как и что грузится и чего мы собственно ждём. Удивитесь и паралельности запросов и ожидания загрузки ява скриптов. Можно у гугла по теме оптимизации сайта и особенностей работы с ним браузеров почитать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Konstantin (??) on 13-Ноя-09, 14:39
	Эта штука не для Web, а для программ использующих HTTP в качестве транспортного протокола. Так как сжатие заголовков напрочь убивает возможность согласования параметров. Пользоваться такой штукой можно только если заранее известно что и клиент и сервер ее поддерживают.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от B.O.B.A.H. (??) on 13-Ноя-09, 15:51
	> Они медленно отдают тебе твой контент, постепенно и не спеша. Побайтово ... > HTML стар. Пора менять. как-то не вяжется :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	36. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Iv945n (ok) on 13-Ноя-09, 18:43
	> ОДНАКО !!!!! Веб сайты грузятся не быстрее а медленнее. И компьютеры то у меня все быстрее и быстрее, и HTML парсинг шустрый, и JS движки все круче и быстрее, нo иногда очень задалбывает загруженость самих серверов и их отказы от обслуживания. Они медленно отдают тебе твой контент, постепенно и не спеша. Побайтово ... Наверно не последнюю роль в этом играет то, что кол-во клиентов и их запросы всё растут. > HTML стар. Пора менять. Насчёт HTML не уверен, а вот HTTP И FTP это уж скорее таки да.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Pilat (ok) on 13-Ноя-09, 18:47
	>> ОДНАКО !!!!! Веб сайты грузятся не быстрее а медленнее. И компьютеры то у меня все быстрее и быстрее, и HTML парсинг шустрый, и JS движки все круче и быстрее, нo иногда очень задалбывает загруженость самих серверов и их отказы от обслуживания. Они медленно отдают тебе твой контент, постепенно и не спеша. Побайтово ... не в том проблема что медленно отдают, а в том, что хозяева серверов вешают всё большую функциональность. Одна страничка обвешивается модулями как ёлка, повесить модуль сейчас легко, поэтому о том что он кушает ресурсы никто и не думает.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Ak on 13-Ноя-09, 14:32
	В отличии от некоторых "альтернативных производителей ПО" навязывающих необходимость проапгрейдить железо дабы удовлетворить потребности прожорливых никомуненужностей, Гуглеры более адекватно оценивают возможности потребителей. Людям с толстым каналом этот прирост в общем-то до лампочки. А вот тем кто пользует "медленный DSL"(Dial-UP, а иногда и GPRS на старых трубках) это да. Так что зря вы это про "год".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от barmaglot (??) on 13-Ноя-09, 14:42
	Людям с толстым каналом тоже влом больше 3-х секунд ждать появления странички. Это психология. Всё что дольше 3-х сикунд длится - медленно и долго, и бесит. Частичное появление контента, до конца закачки, конечно спасает. Но регулярный перерендер из за появления запоздавших элементов - бесит.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	60. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Pilat (ok) on 16-Ноя-09, 19:59
	>В отличии от некоторых "альтернативных производителей ПО" навязывающих необходимость проапгрейдить железо дабы >удовлетворить потребности прожорливых никомуненужностей, Гуглеры более адекватно оценивают возможности потребителей. Людям >с толстым каналом этот прирост в общем-то до лампочки. А вот >тем кто пользует "медленный DSL"(Dial-UP, а иногда и GPRS на старых >трубках) это да. Так что зря вы это про "год". Я сижу на EDGE на новой трубе, и то отказ от лишних соединений должен раз в 10 повысить скорость загрузки страничек.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	48. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от waf (ok) on 14-Ноя-09, 00:21
	>Гибкость филтеринга контента возрастает неимоверно. Никто из рулящих "крупняков" на такое не пойдёт, и в первую очередь Google.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	58. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Gambler (ok) on 16-Ноя-09, 19:38
	> а) не изменить стримовый характер самого HTTP на пакетный ? В TCP/IP вообще не хватает надежного протокола для пересылки пакетов данных. Не UDP, а чтобы гарантированно доходили, но при этом не надо было ждать открытия/закрытия соединения. У Oracle в разработке есть RDS  (Reliable Datagram Socket, http://oss.oracle.com/projects/rds/), но это пока только дизайн, который ничем не поддерживается. Вообще, я согласен, интернет-технологии очень сильно устарели, потому что сама суть интернета сильно изменилась. Однако людям свойственно цепляться за существующие решения мертвой хваткой, и добавлять один за другим новые костыли, одновременно треплясь про "новшества".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Компания Google предложила надстройку для улучшения протокол..."		+/–
Сообщение от nuclight (??) on 13-Ноя-09, 14:21
А чем их SCTP не устраивает? Стандарт, и вполне параллельный.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от stan (??) on 13-Ноя-09, 14:24
	>А чем их SCTP не устраивает? Стандарт, и вполне параллельный. Это ж баблгам....транспортный уровень, вот! А речь про прикладной. SCTP тоже надо, но слишком много переписывать придётся. Он висит как IPv6.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	42. "Компания Google предложила надстройку для улучшения протокол..."		–1 +/–
	Сообщение от Финиш on 13-Ноя-09, 22:29
	>Это ж баблгам....транспортный уровень, вот! >А речь про прикладной. >SCTP тоже надо, но слишком много переписывать придётся. >Он висит как IPv6. ...   1 Физический уровень (англ. Physical layer) 2 Канальный уровень (англ. Data Link layer) 3 Сетевой уровень (англ. Network layer) 4 Транспортный уровень (англ. Transport layer) 5 Сеансовый уровень (англ. Session layer) 6 Представительский (Уровень представления) (англ. Presentation layer) 7 Прикладной (Приложений) уровень (англ. Application layer) HTTP протокол все-таки висит на транспортпом уровне. Отображение страниц в браузере больше зависит от сеансового уровня и уровня представления А то, что уровень приложений не может это адекватно обработать, зависит от кодеров ИМХО
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	45. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от аноним on 13-Ноя-09, 23:28
	Марш курить доки по модели OSI. HTTP - прикладной, надо же такой бред сморозить.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	46. "Компания Google предложила надстройку для улучшения протокол..."		–1 +/–
	Сообщение от Финиш on 13-Ноя-09, 23:33
	Ради троллинга   :-) Демон http отвечает на запросы на.... Браузер отправляет запросы по...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "Компания Google предложила надстройку для улучшения протокол..."		+/–
Сообщение от Аноним (??) on 13-Ноя-09, 14:54
Ясное дело, что текстовый протокол расходует больше трафика чем бинарный. Так же понятно, что человек иногда заходит на сайт узнать не вышел ли новый релиз, и его бы устроил ответ 0 или 1. Но это всё жутко мешает распространению и популяризации. Самый лучший по всем показателям язык программирования ассемблер не используется повсеместно именно по этому. Вердикт: не взлетит.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Cobold (??) on 13-Ноя-09, 15:37
	> Ясное дело, что текстовый протокол расходует больше трафика чем бинарный. компрессия сейчас практически везде включена, даже если 99% пользователей о ней не знают > Так же понятно, что человек иногда заходит на сайт узнать не вышел ли новый релиз, и его бы устроил ответ 0 или 1 и это за вас полностью прозрачно браузер делает. Вердикт: перед тем как писать не мешало бы ознакомиться с сабжем
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от pavlinux (ok) on 13-Ноя-09, 15:59
	>> Ясное дело, что текстовый протокол расходует больше трафика чем бинарный. >компрессия сейчас практически везде включена, даже если 99% пользователей о ней не >знают >> Так же понятно, что человек иногда заходит на сайт узнать не вышел ли новый релиз, и его бы устроил ответ 0 или 1 >и это за вас полностью прозрачно браузер делает. >Вердикт: перед тем как писать не мешало бы ознакомиться с сабжем Content-Encoding: gzip Оно?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от _Vitaly_ (ok) on 13-Ноя-09, 17:12
	А разве оно хедеры и куки жмет?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Pilat (ok) on 13-Ноя-09, 17:14
	>А разве оно хедеры и куки жмет? Естественно не жмёт, оттого-то гугль и зашевилился.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	52. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Dvorkin (??) on 14-Ноя-09, 13:31
	а 90% передачи - это контент. сжать его в 5-10 раз - эффективнее, чем париться про 20% импрува при сжатии заголовков к сожалению, почему-то про эти простые вещи забывают/не знают кул-админы к слову, хеадер зачастую умещается в типичный mtu, и, соответственно, может быть передан неделимо, что автоматически означает максимальную скорость передачи при большом количестве хопов. стоит ли игра по разработке нового формата заголовков свеч, или таки лучше для начала в принудительном порядке отправлять детей в школу читать маны перед тем, как садиться что-то админить? на месте гугля (если конечно его намерения действительно так благи) я бы просто организовал курсы повышения квалификации
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	56. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Cobold (??) on 16-Ноя-09, 12:05
	если честно, новость интересная но написанна в стиле PR кампании - будто бы они 'ускоритель интернета' изобрели. Этот протокол должен быть действительно не плох для ajax, но только в строго конкретных случаях - на уровне приложения и организации сервера нужно делать тесты и смотреть будет ли выигрыш. В любом случае хорошо если браузеры его будут поддерживать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	66. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Dvorkin (ok) on 17-Ноя-09, 20:00
	> быть действительно не плох для ajax, но только в строго конкретных случаях в израиле, например. где пакетики бьются на 512 на каком-то большом роутере :) P.S. сочтут за разжигание :P
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	61. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Pilat (ok) on 16-Ноя-09, 20:09
	>а 90% передачи - это контент. сжать его в 5-10 раз - да не всегда контент. Часто 90% - это установление соединения. Крайний случай - спутниковые каналы, где скорости большие, а задержки ещё больше. 100 килобайт там пролетают за долю секунды, а ответ на запрос - за десятки секунд может быть получен. В хороших сетях ответ быстрее приходит, но если померять - при пинге 250ms (USA-RUS) только на установку соединения уйдёт четверть секунды, а 100К данных при мегабитной линии придёт за то же время. 50/50 , это ещё если повезёт.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	65. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Dvorkin (ok) on 17-Ноя-09, 19:58
	> 100 килобайт там пролетают за долю секунды, а ответ на запрос - за десятки секунд может быть получен в этом случае приплюха тоже ничего не меняет. только усложняет. кто ж с ЖПРезом на output сидит сейчас?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	68. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Pilat (ok) on 17-Ноя-09, 22:48
	>> 100 килобайт там пролетают за долю секунды, а ответ на запрос - за десятки секунд может быть получен > >в этом случае приплюха тоже ничего не меняет. только усложняет. кто ж >с ЖПРезом на output сидит сейчас? при чём тут GPRS, спутниковые линии имеют особенность - огромные задержки (именно на спутниковой линии), большой MTU (например 16 килобайт) и большую скорость передачи данных при низкой надёжности. Там tcpip работает плохо, не то что http. А на GPRS/EDGE пол-России сидит.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	69. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Dvorkin (ok) on 18-Ноя-09, 13:31
	> большой MTU (например 16 килобайт) nu i? ... vi sami ponimaete, chto eto avtomaticheski znachit, chto pripluha bessmislena? :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	70. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Pilat (ok) on 18-Ноя-09, 13:34
	>> большой MTU (например 16 килобайт) > >nu i? ... >vi sami ponimaete, chto eto avtomaticheski znachit, chto pripluha bessmislena? :) мы сами понимаем, что если в этот пакет положить несколько запросов - вся страница придёт одтним куском. Гугль предлагает два решения в одной упаковке - уменьшение заголовка и группировку запросов. В разных случаях разный положительный эффект.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	71. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Dvorkin (ok) on 18-Ноя-09, 16:56
	a, gruppirovku ya proglyadel. da. :) vse ravno somnitelno, chto uzhe potrachennie (i v budushem potratyatsya) na razrabotku etoy figni cheloveko-chasi opravdayut effekt. krayniy sever u nas malozaselen. a reklama dlya google - niche! vse obsuzhdayut! ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	72. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Pilat (ok) on 18-Ноя-09, 17:44
	>vse ravno somnitelno, chto uzhe potrachennie (i v budushem potratyatsya) na razrabotku >etoy figni cheloveko-chasi opravdayut effekt. krayniy sever u nas malozaselen. Ну да, за кольцом жизни вообще нет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	73. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Dvorkin (ok) on 25-Ноя-09, 04:22
	ya dlekoooo za kolcom zhivu :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "Компания Google предложила надстройку для улучшения протокол..."		+1 +/–
Сообщение от pavlinux (ok) on 13-Ноя-09, 15:42
> Сжатие заголовков, что, по словам разработчиков, на ~88% > уменьшает размер заголовков запроса, и на ~85% -- размер заголовков ответа. Теперь эффективность DDoS атаки увеличится на 85% :)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	39. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Iv945n (ok) on 13-Ноя-09, 18:50
	>> Сжатие заголовков, что, по словам разработчиков, на ~88% >> уменьшает размер заголовков запроса, и на ~85% -- размер заголовков ответа. > >Теперь эффективность DDoS атаки увеличится на 85% :) Помню во времена UUCP и FTN почты была такая штука как мэйл-бомба, когда фабриковался маленький почтовый пакетик, который распаковывался в огромный файл из одинаковых байтов и забиывл проц и винч на ноде. Защищались от такого проверкой и ограничением процента сжатия (ratio) пакета.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	40. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от pavlinux (ok) on 13-Ноя-09, 20:07
	>>> Сжатие заголовков, что, по словам разработчиков, на ~88% >>> уменьшает размер заголовков запроса, и на ~85% -- размер заголовков ответа. >> >>Теперь эффективность DDoS атаки увеличится на 85% :) > >Помню во времена UUCP и FTN почты была такая штука как мэйл-бомба, >когда фабриковался маленький почтовый пакетик, который распаковывался в огромный файл из >одинаковых байтов и забиывл проц и винч на ноде. Защищались от >такого проверкой и ограничением процента сжатия (ratio) пакета. Ну а толку тогда от прироста скорости, вся идея Гугли в этом и состоит - сплющить, дабы в TCP влезло больше HTTP
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	54. "Компания Google предложила надстройку для улучшения протокол..."		+1 +/–
	Сообщение от User294 (ok) on 15-Ноя-09, 08:46
	>Теперь эффективность DDoS атаки увеличится на 85% :) Что, теперь полтора землекопа^W адслщика смогут завалить апача даже без ботов? За кадром слышно восторженное ликование хаксоров льющих вагоны сплюснутых хидеров которые сервант потом медленно и печально будет разгребать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

27. "Компания Google предложила надстройку для улучшения протокол..."		+2 +/–
Сообщение от Pilat (ok) on 13-Ноя-09, 16:24
Всё это делается, скорее всего, для удешевления AJAX запросов, в которых на заголовок приходится большая доля трафика.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Cobold (??) on 13-Ноя-09, 17:22
	и правда, я как-то не подумал
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Cobold (??) on 13-Ноя-09, 18:35
	Хотя, на сколлько я с AJAX сталкивался запросы вместе с хедерами редко больше чем полтора Kb требуют - в один пакет укладываются. Не понятно почему у них бинарные заголовки такой выигрыш дают, а вот использовать вместо отдельных TCP сессий собственный мультиплексор поверх одного TCP соединения действительно разумно. Опять же, видимо становится возможным в размер одного TCP пакета несколько параллельных мелких HTTP запросов укладывать, тогда и компрессия имеет смысл. Вроде смысл доходит помаленьку :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	62. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Gambler (ok) on 16-Ноя-09, 20:12
	Сейчас вообще среднестатистический "web 2.0" сайт требует сгрузить сотню-другую файлов. Естественно, заголовки создают лишнюю загрузку. Но это предложение - глупейшие костыли. Вместо узколобого сжатия заголовков, намного логичней было бы сделать протокол для настоящего асинхронного общения с веб сервером, чтобы оно шло через один поток и безо всяких извратов. А заголовки (нужные) посылать только один раз - при открытии потока.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	63. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Pilat (ok) on 16-Ноя-09, 20:26
	>Сейчас вообще среднестатистический "web 2.0" сайт требует сгрузить сотню-другую файлов. Естественно, заголовки >создают лишнюю загрузку. > >Но это предложение - глупейшие костыли. Вместо узколобого сжатия заголовков, намного логичней >было бы сделать протокол для настоящего асинхронного общения с веб сервером, >чтобы оно шло через один поток и безо всяких извратов. А >заголовки (нужные) посылать только один раз - при открытии потока. это тоже неправильно. Наверно, все сталкивались с reget'оподобными программами, ускоряющими загрузку за счёт нескольких потоков. Несколько параллельных запросов могут выполниться быстрее, чем один последовательный. Это естественно на реальных линиях, не в локальной сети.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	64. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Gambler (ok) on 16-Ноя-09, 21:01
	>это тоже неправильно. Наверно, все сталкивались с reget'оподобными программами, ускоряющими загрузку за счёт нескольких потоков. Несколько параллельных запросов могут выполниться быстрее, чем один последовательный. Это естественно на реальных линиях, не в локальной сети. Открытие потока занимает какое-то время. Отсылка заголовков занимает какое-то время. Загрузка еще одной копии сервера в память занимает какое-то время и жрет память. Когда файлы маленькие, многопоточность мешает. Не зря в HTTP 1.1 сделали Keep-Alive, который по одному потоку отправляет несколько страниц. Однако эта штука сделана для документов. А AJAX-запросы это, по сути, никакие не документы, а просто сообщения. Потому HTTP для их пересылки работает плохо. (Скажем, сильно не хватает возможности сделать запрос со стороны сервера. Естественно после того, как клиент открыл какую-то страницу. Приходится со стороны клиента постоянно что-то запрашивать.)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

32. "Компания Google предложила надстройку для улучшения протокол..."		+/–
Сообщение от Аноним (??) on 13-Ноя-09, 17:39
ИМХО, отличная идея использовать P2P для трансфера HTML страниц =)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Pilat (ok) on 13-Ноя-09, 17:46
	>ИМХО, отличная идея использовать P2P для трансфера HTML страниц =) Дурацкая идея. Датентность P2P просто гигантская даже по сравнению с HTTP, а гуглу именно латентность не даёт покоя.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	50. "+1"		+/–
	Сообщение от Вова on 14-Ноя-09, 08:52
	>ИМХО, отличная идея использовать P2P для трансфера HTML страниц =) конечно отличная, особенно в плане вконтактов: если Маша Вислодуденко уже посмотрела новый клип Сосо Павлиашвили, то Тане Ничай-Васько гораздо быстрее отдастся этот клип из локальной сетки провайдера (100м этернет) чем прямо с сервера вконтакта (512 кб/сек тариф "розовые бантики"), это очевидно
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

51. "Компания Google предложила надстройку для улучшения протокол..."		+/–
Сообщение от Чь то имя on 14-Ноя-09, 12:53
Трудно понимаемо такое стремление к пожатию. Ведь если заголовок размером меньше mtu большой прибавки к скорости пожатием не добиться. Другое дело что некоторые серваки и броузеры, пихают всякую чушь в заголовок. Но это вовсе не проблема протокола. Можно в следующей спецификации договорится что, например, Content-Type и CT одно и тоже. Думаю два байта на имя поля более чем достаточно...
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	57. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от Cobold (??) on 16-Ноя-09, 12:18
	>Трудно понимаемо такое стремление к пожатию. Ведь если заголовок размером меньше mtu >большой прибавки к скорости пожатием не добиться. Другое дело что некоторые >серваки и броузеры, пихают всякую чушь в заголовок. Но это вовсе >не проблема протокола. >Можно в следующей спецификации договорится что, например, Content-Type и CT одно и >тоже. Думаю два байта на имя поля более чем достаточно... там было такое ключевое слово "мультиплексор" - если браузеру нужно сделать одновременно несколько взаимно независимых коротких запросов, к примеру HEAD для разных ресурсов, и получить на них короткие ответы, то довольно накладно для каждого запроса открывать и закрывать новое tcp сеодинение (сколько это, 4 дополнительных пакета?), а потом гнать полупустые пакеты только по тому что для отдельного HEAD весь mtu не нужен. Короче, получается транспортный протокол аппликационного уровня.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

59. "Компания Google предложила надстройку для улучшения протокол..."		+/–
Сообщение от Gambler (ok) on 16-Ноя-09, 19:52
А вообще, надоело. Сначала делают сайты, где требуется для открытия одной страницы грузить 100-200 файлов (Откройте Gmail со включенным Firebug), а потом учтиво предлагают под эти их сайты дополнять базовые протоколы - которые, по-хорошему, надо давно выкинуть к чертовой матери и заменить на что-то более адекватное.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	67. "Компания Google предложила надстройку для улучшения протокол..."		+/–
	Сообщение от szh (ok) on 17-Ноя-09, 22:07
	> которые, по-хорошему, надо давно выкинуть к чертовой матери и заменить на что-то более адекватное. Это невозможно сделать. Legacy, legacy, legacy - это реальность. > Сначала делают сайты, где требуется для открытия одной страницы грузить 100-200 файлов > (Откройте Gmail со включенным Firebug) Gmail это не сайт а прежде всего веб программа, имеет принципиальное преймущество над "сайтами". За эти преймущества логично платить ресурсами. Так что все правильно делают.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема