| 1.1, 82500 (?), 13:21, 13/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Надстройка обычно = костыль, но тут, судя по анонсу, как-то язык не поворачивается так назвать. Маркетинг :)
| | |
| |
| |
| 3.43, Аноним (-), 23:02, 13/11/2009 [^] [^^] [^^^] [ответить]
| –2 +/– |
Не фига не хорошее, какой-то костыль, решающий частную проблему. Пусть сделают свою куйню в виде прокси, чтобы локально на компьютер можно было поставить и на сервер. На компьютере пользователя HTTP будет преобразовываться в этот SPDY, отправляться через тырнет на SPDY-сервер, который будет конвертировать его обратно в HTTP и обслуживать. Получится по сути свободная реализация модных у вантузятников веб-ускорителей.
| | |
| |
| 4.53, spunky (ok), 20:32, 14/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
прокси-сервер? Не проблема. Особенно при открытом протоколе. Вот модуль для веб-сервера уже посложнее задачка.
| | |
| 4.55, ТТТ (?), 13:18, 15/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
Глупость какая!!!
почему просто не стандартизировать эти улучшения как HTTP 2.0 и не мучится с настройками если это стандарт да еще и открытый всерано или поздно поддержат.
| | |
|
|
|
| |
| 2.3, vadiml (?), 13:51, 13/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> доступ к данным изменится с последовательного на параллельный
из-за последовательного доступа обрезка рекламы и счётчиков даёт заметную прибавку в скорости отображения страниц -- броузерам слишком часто приходится подолгу ждать пока загрузятся все баннеры.
Как только отключу дома проксю -- впечатление что инет начинает жутко тормозить.
| | |
| |
| 3.9, barmaglot (??), 14:28, 13/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Это не из за последовательного доступа, а из за закачки фигни со всех сторон. Обрезка происходит после закачки именно из за того что протокол последовательный. А твой случай это имменно подтверждает :) Прокси заранее режет все-то что тебе ненужно, и т.д.
| | |
| 3.11, barmaglot (??), 14:32, 13/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Цитатко из меня любимого:
(1)
>Все мы пользуемся NoScript и AdBlock, при параллельном доступе вместо последовательного (стримового), ненужные данные не будут закачиваться.
(2)
>Если сейчас не закачиваются лишь игнорируемые внешние линки, то с подобным изменением можно будет блокировать ненужный контент сервера к которому подсоединён.
(3)
>Причём не просто блокировать при рендеринге, а именно не загружать этот контент. Гибкость филтеринга контента возрастает неимоверно. | | |
| |
| 4.19, anonymous (??), 15:30, 13/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>Все мы пользуемся NoScript и AdBlock, при параллельном доступе вместо последовательного (стримового), ненужные данные не будут закачиваться.
Вот на этой самой странице, отнюдь не перегруженной JavaScript'ом тупое удаление этого JavaScript'а дало уменьшение размера страницы на ~12%. А на каком-нибудь mail.ru эта "оптимизация" даст более 40%. ;)
| | |
| 4.23, pavlinux (ok), 15:47, 13/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> а именно не загружать этот контент.
Как ты себе представляешь игнорировать то, чего ещё не знаешь?
Можно указать то, чего не хочешь видеть, но это не значит,
что на другой стороне примут во внимание пожелания населения.
| | |
| 4.34, xxx (??), 18:04, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Причём не просто блокировать при рендеринге, а именно не загружать этот контент. Гибкость филтеринга контента возрастает неимоверно.
Вот на этом-то внедрение нового протокола и загнётся. Нафиг гуглам и прочим, зарабатывающим на рекламе, такая фича =)
| | |
| 4.41, Аноним (-), 22:18, 13/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
в опере так и работает игнор список для блокирования контента, ничего лишнего не грузится, выкиньте ваш слоуфокс
| | |
| |
| 5.49, Michael (??), 00:26, 14/11/2009 [^] [^^] [^^^] [ответить]
| +2 +/– |
Их персональный слоуфокс они не отдадут. Он им дорог. У остальных AdBlock Plus тоже режет по-человечески.
| | |
|
|
|
| 2.10, Вова (?), 14:28, 13/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Новый протокол это конечно замечательно, особенно со сжатыми заголовками.
были какие-то сервисы в том тысячелетии, зиповали веп на лету, вроде как "ускоряли" браузинг, ничто не ново. Вот на наге человек предложил в "панели мейл.ру" и другие порнографические надстройки браузера добавить что-то вроде торрент-клиента, вот это действительно даст эффект в скорости доступа, но она ни к чему, на мой взгляд, проблема уже давно на стороне клиента, браузеры тормозят.
>ОДНАКО !!!!! Веб сайты грузятся не быстрее а медленнее. И компьютеры то
>у меня все быстрее и быстрее, и HTML парсинг шустрый, и
>JS движки все круче и быстрее
Проблема чаще не в отдаче серверов, а в насыщенности яваскриптом/итп. Я часто использую для браузинга 'links -g', когда нужно просто "посмотреть/почитать", без дописок и тп. Странички часто отображаются коряво - но моментально, часто буквально в момент ввода урл, нажатия 'enter', дома сижу на корбиновской 10тке метров/сек, на работе хз какая скорость. Тормозит яваскрипт и тп, вовсе не канал. Если бы отдача сервера была причиной задержек - не было бы разницы между браузингом в links -g и файрфоксе.
| | |
| |
| 3.14, barmaglot (??), 14:39, 13/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> насыщенности яваскриптом/итп
Так ведь не парсинг скрипта тормозит и скрипты небольшие. Все задержки приходятся на резолвинг имён и подключение к 3-м серверам. А тормоза из за того, что все действия происходят последовательно. Считал тег отпарсил,[ есть реф ] -> пошел по рефу, вытянул, .... тегу конец -> РЕНДЕРИНГ. Весь процесс синхронный и последовательный. Спасает только многопоточность которая рефы в фоне качает.Но рендерить ведь не начнёшь, до тех пор пока не получишь контент.
| | |
| |
| 4.21, abbadon (?), 15:39, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Ставим фаербаг в идём на вкладку net и смотрим как и что грузится и чего мы собственно ждём.
Удивитесь и паралельности запросов и ожидания загрузки ява скриптов. Можно у гугла по теме оптимизации сайта и особенностей работы с ним браузеров почитать.
| | |
|
|
| 2.15, Konstantin (??), 14:39, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Эта штука не для Web, а для программ использующих HTTP в качестве транспортного протокола. Так как сжатие заголовков напрочь убивает возможность согласования параметров. Пользоваться такой штукой можно только если заранее известно что и клиент и сервер ее поддерживают.
| | |
| 2.24, B.O.B.A.H. (??), 15:51, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
> Они медленно отдают тебе твой контент, постепенно и не спеша. Побайтово ...
> HTML стар. Пора менять.
как-то не вяжется :)
| | |
| 2.36, Iv945n (ok), 18:43, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> ОДНАКО !!!!! Веб сайты грузятся не быстрее а медленнее. И компьютеры то у меня все быстрее и быстрее, и HTML парсинг шустрый, и JS движки все круче и быстрее, нo иногда очень задалбывает загруженость самих серверов и их отказы от обслуживания. Они медленно отдают тебе твой контент, постепенно и не спеша. Побайтово ...
Наверно не последнюю роль в этом играет то, что кол-во клиентов и их запросы всё растут.
> HTML стар. Пора менять.
Насчёт HTML не уверен, а вот HTTP И FTP это уж скорее таки да.
| | |
| |
| 3.38, Pilat (ok), 18:47, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
 >> ОДНАКО !!!!! Веб сайты грузятся не быстрее а медленнее. И компьютеры то у меня все быстрее и быстрее, и HTML парсинг шустрый, и JS движки все круче и быстрее, нo иногда очень задалбывает загруженость самих серверов и их отказы от обслуживания. Они медленно отдают тебе твой контент, постепенно и не спеша. Побайтово ...
не в том проблема что медленно отдают, а в том, что хозяева серверов вешают всё большую функциональность. Одна страничка обвешивается модулями как ёлка, повесить модуль сейчас легко, поэтому о том что он кушает ресурсы никто и не думает.
| | |
|
| 2.12, Ak (?), 14:32, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
В отличии от некоторых "альтернативных производителей ПО" навязывающих необходимость проапгрейдить железо дабы удовлетворить потребности прожорливых никомуненужностей, Гуглеры более адекватно оценивают возможности потребителей. Людям с толстым каналом этот прирост в общем-то до лампочки. А вот тем кто пользует "медленный DSL"(Dial-UP, а иногда и GPRS на старых трубках) это да. Так что зря вы это про "год".
| | |
| |
| 3.16, barmaglot (??), 14:42, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Людям с толстым каналом тоже влом больше 3-х секунд ждать появления странички. Это психология. Всё что дольше 3-х сикунд длится - медленно и долго, и бесит. Частичное появление контента, до конца закачки, конечно спасает. Но регулярный перерендер из за появления запоздавших элементов - бесит.
| | |
| 3.60, Pilat (ok), 19:59, 16/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>В отличии от некоторых "альтернативных производителей ПО" навязывающих необходимость проапгрейдить железо дабы
>удовлетворить потребности прожорливых никомуненужностей, Гуглеры более адекватно оценивают возможности потребителей. Людям
>с толстым каналом этот прирост в общем-то до лампочки. А вот
>тем кто пользует "медленный DSL"(Dial-UP, а иногда и GPRS на старых
>трубках) это да. Так что зря вы это про "год".
Я сижу на EDGE на новой трубе, и то отказ от лишних соединений должен раз в 10 повысить скорость загрузки страничек.
| | |
|
| 2.48, waf (ok), 00:21, 14/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Гибкость филтеринга контента возрастает неимоверно.
Никто из рулящих "крупняков" на такое не пойдёт, и в первую очередь Google.
| | |
| 2.58, Gambler (ok), 19:38, 16/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> а) не изменить стримовый характер самого HTTP на пакетный ?
В TCP/IP вообще не хватает надежного протокола для пересылки пакетов данных. Не UDP, а чтобы гарантированно доходили, но при этом не надо было ждать открытия/закрытия соединения.
У Oracle в разработке есть RDS (Reliable Datagram Socket, http://oss.oracle.com/projects/rds/), но это пока только дизайн, который ничем не поддерживается.
Вообще, я согласен, интернет-технологии очень сильно устарели, потому что сама суть интернета сильно изменилась. Однако людям свойственно цепляться за существующие решения мертвой хваткой, и добавлять один за другим новые костыли, одновременно треплясь про "новшества".
| | |
|
| |
| 2.8, stan (??), 14:24, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
 >А чем их SCTP не устраивает? Стандарт, и вполне параллельный.
Это ж баблгам....транспортный уровень, вот!
А речь про прикладной.
SCTP тоже надо, но слишком много переписывать придётся.
Он висит как IPv6.
| | |
| |
| 3.42, Финиш (?), 22:29, 13/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
>Это ж баблгам....транспортный уровень, вот!
>А речь про прикладной.
>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 протокол все-таки висит на транспортпом уровне.
Отображение страниц в браузере больше зависит от сеансового уровня и уровня представления
А то, что уровень приложений не может это адекватно обработать, зависит от кодеров
ИМХО
| | |
| |
| 4.45, аноним (?), 23:28, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Марш курить доки по модели OSI. HTTP - прикладной, надо же такой бред сморозить.
| | |
| |
| 5.46, Финиш (?), 23:33, 13/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ради троллинга :-)
Демон http отвечает на запросы на....
Браузер отправляет запросы по...
| | |
|
|
|
|
| 1.17, Аноним (-), 14:54, 13/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ясное дело, что текстовый протокол расходует больше трафика чем бинарный.
Так же понятно, что человек иногда заходит на сайт узнать не вышел ли новый релиз, и его бы устроил ответ 0 или 1.
Но это всё жутко мешает распространению и популяризации.
Самый лучший по всем показателям язык программирования ассемблер не используется повсеместно именно по этому.
Вердикт: не взлетит.
| | |
| |
| 2.20, Cobold (??), 15:37, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Ясное дело, что текстовый протокол расходует больше трафика чем бинарный.
компрессия сейчас практически везде включена, даже если 99% пользователей о ней не знают
> Так же понятно, что человек иногда заходит на сайт узнать не вышел ли новый релиз, и его бы устроил ответ 0 или 1
и это за вас полностью прозрачно браузер делает.
Вердикт: перед тем как писать не мешало бы ознакомиться с сабжем
| | |
| |
| 3.26, pavlinux (ok), 15:59, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>> Ясное дело, что текстовый протокол расходует больше трафика чем бинарный.
>компрессия сейчас практически везде включена, даже если 99% пользователей о ней не
>знают
>> Так же понятно, что человек иногда заходит на сайт узнать не вышел ли новый релиз, и его бы устроил ответ 0 или 1
>и это за вас полностью прозрачно браузер делает.
>Вердикт: перед тем как писать не мешало бы ознакомиться с сабжем
Content-Encoding: gzip
Оно?
| | |
| |
| |
| 5.30, Pilat (ok), 17:14, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>А разве оно хедеры и куки жмет?
Естественно не жмёт, оттого-то гугль и зашевилился.
| | |
| 5.52, Dvorkin (??), 13:31, 14/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
 а 90% передачи - это контент. сжать его в 5-10 раз - эффективнее, чем париться про 20% импрува при сжатии заголовков
к сожалению, почему-то про эти простые вещи забывают/не знают кул-админы
к слову, хеадер зачастую умещается в типичный mtu, и, соответственно, может быть передан неделимо, что автоматически означает максимальную скорость передачи при большом количестве хопов.
стоит ли игра по разработке нового формата заголовков свеч, или таки лучше для начала в принудительном порядке отправлять детей в школу читать маны перед тем, как садиться что-то админить?
на месте гугля (если конечно его намерения действительно так благи) я бы просто организовал курсы повышения квалификации
| | |
| |
| 6.56, Cobold (??), 12:05, 16/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
если честно, новость интересная но написанна в стиле PR кампании - будто бы они 'ускоритель интернета' изобрели. Этот протокол должен быть действительно не плох для ajax, но только в строго конкретных случаях - на уровне приложения и организации сервера нужно делать тесты и смотреть будет ли выигрыш. В любом случае хорошо если браузеры его будут поддерживать.
| | |
| |
| 7.66, Dvorkin (ok), 20:00, 17/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> быть действительно не плох для ajax, но только в строго конкретных случаях
в израиле, например. где пакетики бьются на 512 на каком-то большом роутере :)
P.S. сочтут за разжигание :P
| | |
|
| 6.61, Pilat (ok), 20:09, 16/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>а 90% передачи - это контент. сжать его в 5-10 раз -
да не всегда контент. Часто 90% - это установление соединения. Крайний случай - спутниковые каналы, где скорости большие, а задержки ещё больше. 100 килобайт там пролетают за долю секунды, а ответ на запрос - за десятки секунд может быть получен. В хороших сетях ответ быстрее приходит, но если померять - при пинге 250ms (USA-RUS) только на установку соединения уйдёт четверть секунды, а 100К данных при мегабитной линии придёт за то же время. 50/50 , это ещё если повезёт.
| | |
| |
| 7.65, Dvorkin (ok), 19:58, 17/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> 100 килобайт там пролетают за долю секунды, а ответ на запрос - за десятки секунд может быть получен
в этом случае приплюха тоже ничего не меняет. только усложняет. кто ж с ЖПРезом на output сидит сейчас?
| | |
| |
| 8.68, Pilat (ok), 22:48, 17/11/2009 [^] [^^] [^^^] [ответить] | +/– | при чём тут GPRS, спутниковые линии имеют особенность - огромные задержки именн... текст свёрнут, показать | | |
| |
| |
| 10.70, Pilat (ok), 13:34, 18/11/2009 [^] [^^] [^^^] [ответить] | +/– | мы сами понимаем, что если в этот пакет положить несколько запросов - вся страни... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
| 1.22, pavlinux (ok), 15:42, 13/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> Сжатие заголовков, что, по словам разработчиков, на ~88%
> уменьшает размер заголовков запроса, и на ~85% -- размер заголовков ответа.
Теперь эффективность DDoS атаки увеличится на 85% :)
| | |
| |
| 2.39, Iv945n (ok), 18:50, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>> Сжатие заголовков, что, по словам разработчиков, на ~88%
>> уменьшает размер заголовков запроса, и на ~85% -- размер заголовков ответа.
>
>Теперь эффективность DDoS атаки увеличится на 85% :)
Помню во времена UUCP и FTN почты была такая штука как мэйл-бомба, когда фабриковался маленький почтовый пакетик, который распаковывался в огромный файл из одинаковых байтов и забиывл проц и винч на ноде. Защищались от такого проверкой и ограничением процента сжатия (ratio) пакета.
| | |
| |
| 3.40, pavlinux (ok), 20:07, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>> Сжатие заголовков, что, по словам разработчиков, на ~88%
>>> уменьшает размер заголовков запроса, и на ~85% -- размер заголовков ответа.
>>
>>Теперь эффективность DDoS атаки увеличится на 85% :)
>
>Помню во времена UUCP и FTN почты была такая штука как мэйл-бомба,
>когда фабриковался маленький почтовый пакетик, который распаковывался в огромный файл из
>одинаковых байтов и забиывл проц и винч на ноде. Защищались от
>такого проверкой и ограничением процента сжатия (ratio) пакета.
Ну а толку тогда от прироста скорости, вся идея Гугли в этом и состоит - сплющить, дабы в TCP влезло больше HTTP
| | |
|
| 2.54, User294 (ok), 08:46, 15/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>Теперь эффективность DDoS атаки увеличится на 85% :)
Что, теперь полтора землекопа^W адслщика смогут завалить апача даже без ботов? За кадром слышно восторженное ликование хаксоров льющих вагоны сплюснутых хидеров которые сервант потом медленно и печально будет разгребать.
| | |
|
| 1.27, Pilat (ok), 16:24, 13/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Всё это делается, скорее всего, для удешевления AJAX запросов, в которых на заголовок приходится большая доля трафика.
| | |
| |
| 2.35, Cobold (??), 18:35, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Хотя, на сколлько я с AJAX сталкивался запросы вместе с хедерами редко больше чем полтора Kb требуют - в один пакет укладываются. Не понятно почему у них бинарные заголовки такой выигрыш дают, а вот использовать вместо отдельных TCP сессий собственный мультиплексор поверх одного TCP соединения действительно разумно. Опять же, видимо становится возможным в размер одного TCP пакета несколько параллельных мелких HTTP запросов укладывать, тогда и компрессия имеет смысл. Вроде смысл доходит помаленьку :)
| | |
| 2.62, Gambler (ok), 20:12, 16/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
Сейчас вообще среднестатистический "web 2.0" сайт требует сгрузить сотню-другую файлов. Естественно, заголовки создают лишнюю загрузку.
Но это предложение - глупейшие костыли. Вместо узколобого сжатия заголовков, намного логичней было бы сделать протокол для настоящего асинхронного общения с веб сервером, чтобы оно шло через один поток и безо всяких извратов. А заголовки (нужные) посылать только один раз - при открытии потока.
| | |
| |
| 3.63, Pilat (ok), 20:26, 16/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Сейчас вообще среднестатистический "web 2.0" сайт требует сгрузить сотню-другую файлов. Естественно, заголовки
>создают лишнюю загрузку.
>
>Но это предложение - глупейшие костыли. Вместо узколобого сжатия заголовков, намного логичней
>было бы сделать протокол для настоящего асинхронного общения с веб сервером,
>чтобы оно шло через один поток и безо всяких извратов. А
>заголовки (нужные) посылать только один раз - при открытии потока.
это тоже неправильно. Наверно, все сталкивались с reget'оподобными программами, ускоряющими загрузку за счёт нескольких потоков. Несколько параллельных запросов могут выполниться быстрее, чем один последовательный. Это естественно на реальных линиях, не в локальной сети.
| | |
| |
| 4.64, Gambler (ok), 21:01, 16/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>это тоже неправильно. Наверно, все сталкивались с reget'оподобными программами, ускоряющими загрузку за счёт нескольких потоков. Несколько параллельных запросов могут выполниться быстрее, чем один последовательный. Это естественно на реальных линиях, не в локальной сети.
Открытие потока занимает какое-то время. Отсылка заголовков занимает какое-то время. Загрузка еще одной копии сервера в память занимает какое-то время и жрет память. Когда файлы маленькие, многопоточность мешает. Не зря в HTTP 1.1 сделали Keep-Alive, который по одному потоку отправляет несколько страниц. Однако эта штука сделана для документов. А AJAX-запросы это, по сути, никакие не документы, а просто сообщения. Потому HTTP для их пересылки работает плохо. (Скажем, сильно не хватает возможности сделать запрос со стороны сервера. Естественно после того, как клиент открыл какую-то страницу. Приходится со стороны клиента постоянно что-то запрашивать.)
| | |
|
|
|
| |
| 2.33, Pilat (ok), 17:46, 13/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>ИМХО, отличная идея использовать P2P для трансфера HTML страниц =)
Дурацкая идея. Датентность P2P просто гигантская даже по сравнению с HTTP, а гуглу именно латентность не даёт покоя.
| | |
| 2.50, Вова (?), 08:52, 14/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>ИМХО, отличная идея использовать P2P для трансфера HTML страниц =)
конечно отличная, особенно в плане вконтактов: если Маша Вислодуденко уже посмотрела новый клип Сосо Павлиашвили, то Тане Ничай-Васько гораздо быстрее отдастся этот клип из локальной сетки провайдера (100м этернет) чем прямо с сервера вконтакта (512 кб/сек тариф "розовые бантики"), это очевидно
| | |
|
| 1.51, Чь то имя (?), 12:53, 14/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Трудно понимаемо такое стремление к пожатию. Ведь если заголовок размером меньше mtu большой прибавки к скорости пожатием не добиться. Другое дело что некоторые серваки и броузеры, пихают всякую чушь в заголовок. Но это вовсе не проблема протокола.
Можно в следующей спецификации договорится что, например, Content-Type и CT одно и тоже. Думаю два байта на имя поля более чем достаточно...
| | |
| |
| 2.57, Cobold (??), 12:18, 16/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Трудно понимаемо такое стремление к пожатию. Ведь если заголовок размером меньше mtu
>большой прибавки к скорости пожатием не добиться. Другое дело что некоторые
>серваки и броузеры, пихают всякую чушь в заголовок. Но это вовсе
>не проблема протокола.
>Можно в следующей спецификации договорится что, например, Content-Type и CT одно и
>тоже. Думаю два байта на имя поля более чем достаточно...
там было такое ключевое слово "мультиплексор" - если браузеру нужно сделать одновременно несколько взаимно независимых коротких запросов, к примеру HEAD для разных ресурсов, и получить на них короткие ответы, то довольно накладно для каждого запроса открывать и закрывать новое tcp сеодинение (сколько это, 4 дополнительных пакета?), а потом гнать полупустые пакеты только по тому что для отдельного HEAD весь mtu не нужен. Короче, получается транспортный протокол аппликационного уровня.
| | |
|
| 1.59, Gambler (ok), 19:52, 16/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А вообще, надоело. Сначала делают сайты, где требуется для открытия одной страницы грузить 100-200 файлов (Откройте Gmail со включенным Firebug), а потом учтиво предлагают под эти их сайты дополнять базовые протоколы - которые, по-хорошему, надо давно выкинуть к чертовой матери и заменить на что-то более адекватное.
| | |
| |
| 2.67, szh (ok), 22:07, 17/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> которые, по-хорошему, надо давно выкинуть к чертовой матери и заменить на что-то более адекватное.
Это невозможно сделать. Legacy, legacy, legacy - это реальность.
> Сначала делают сайты, где требуется для открытия одной страницы грузить 100-200 файлов
> (Откройте Gmail со включенным Firebug)
Gmail это не сайт а прежде всего веб программа, имеет принципиальное преймущество над "сайтами". За эти преймущества логично платить ресурсами.
Так что все правильно делают.
| | |
|
|
