Инженерный комитет IETF (Internet Engineering Task Force), занимающегося развитием протоколов и архитектуры сети Интернет, опубликовал (http://www.spinics.net/lists/ietf-ann/msg73989.html) первый черновой вариант спецификации HTTP 2.00 (http://tools.ietf.org/html/draft-ietf-httpbis-http2-00). Примечательно, что в качестве основы HTTP 2.00 выступает разработанный компанией Google протокол SPDY (http://dev.chromium.org/spdy). Более того, спецификация описывает текущую реализацию SPDY, уже поддерживаемую в браузерах Chrome, Opera и Firefox. До окончательного формирования RFC спецификации ещё предстоит пройти долгий путь доработки и обсуждения, например процесс стандартизации аудиокодека Opus потребовал трёх лет, во время которых было выпущено 16 предварительных вариантов спецификации.Протокол SPDY разработан (https://www.opennet.ru/opennews/art.shtml?num=33638) для минимизации задержек при соединении и обмене данными между клиентом и сервером. По данным Google ускорение работы реальных сайтов при использовании SPDY составляет от 15% до 50%. SPDY добавляет сеансовый уровень поверх SSL, что даёт возможность обеспечить передачу нескольких одновременных потоков в рамках одного TCP-соединения. SPDY позволяет мультиплексировать запросы ресурсов, обрабатывать их параллельно и отправлять запросы с учетом динамически рассчитываемых приоритетов, увеличивая текущую пропускную способность. Использование SSL одновременно позволяет решить проблему с прохождением запросов через прокси серверы и позволяет организовать доставку данных по инициативе сервера, без специального запроса клиента (технология Server push). Дополнительное ускорение достигается за счёт сжатия HTTP-заголовков запроса и ответа.
URL: http://www.spinics.net/lists/ietf-ann/msg73989.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=35540
>ускорение достигается за счёт сжатияУгу...
Т.е. к тому времени когда HTTP2.0 станет повсеместным я уже не смогу отослать запрос с помощью telnet?
Обратную совместимость никто не отменяет.
> Т.е. к тому времени когда HTTP2.0 станет повсеместным я уже не смогу отослать запрос с помощью telnet?Уже сейчас ты не можешь отправить почту на smtp.gmail.ru через telnet, например.
> Уже сейчас ты не можешь отправить почту на smtp.gmail.ru через telnet, например.*.gmail.com конечно.
>> Уже сейчас ты не можешь отправить почту на smtp.gmail.ru через telnet, например.
> *.gmail.com конечно.Гугл запретил пользоваться телнетом поверх ssl?
$ openssl s_client -quiet -connect smtp.gmail.com:465
depth=1 C = US, O = Google Inc, CN = Google Internet Authority
verify error:num=20:unable to get local issuer certificate
verify return:0
220 mx.google.com ESMTP ee6sm6608409lcc.8
HELO
250 mx.google.com at your service
>> Уже сейчас ты не можешь отправить почту на smtp.gmail.ru через telnet, например.это *ты* не можешь, потому что безграмотный. остальные в курсе, как работать telnet'ом поверх ssl.
> Т.е. к тому времени когда HTTP2.0 станет повсеместным я уже не смогу отослать запрос с помощью telnet?Да, придется в бонус к нему еще stunel юзать или дописать несоколько вызовов SSL-либы.
> Дополнительное ускорение достигается за счёт сжатия HTTP-заголовков запроса и ответа.они открыли для себя mod_gzip ?
может быть mod_deflate? Нет, они изобрели сжатие заголовков, контент вы по-прежнему будете сжимать mod_deflate/nginx-gzip
Для скорости неплохо бы с TCP на UDP перебраться, а не в SSL лезть. Впрочем, думаю Google знает что делает.
> Для скорости неплохо бы с TCP на UDP перебратьсяа потом опять написать на UDP механизмы контроля доставки. действительно, зачем пользоваться готовыми — да здравствуют велосипеды!
ACK
> ACKFIN
> а потом опять написать на UDP механизмы контроля доставки.В uTP кстати велосипедисты так и сделали. И congestion control там как-то более реалистичный для фонового протокола вышел. Правда в отместку за это у протокола вылез ряд иных дурацких свойств. "И выигрывая в силе, проигрываем в расстоянии".
в ENet, например, тоже. только вот они не потоковые, например. допиливать ко всему софту, который использует http, «потоковый» слой поверх навелосипеденого на UDP протокола? так TCP уже сделан же.
> всему софту, который использует http, «потоковый» слой поверх навелосипеденого
> на UDP протокола? так TCP уже сделан же.У TCP довольно много грабель. Например, congestion control у него - ни два ни полтора. Он отстой и для предотвращения забития канала bulk-download'ами, и интерактивность не может обеспечить толком, даже когда это надо (время ретрансмиссии и затыка в данных почти не лимитировано кроме совсем уж диких полных таймаутов). За что TCP и не жалуют местами, собственно.
Проблема есть. Но то что ты описал - проблема только для совсем уж нубов. гугле куос.
однако же для передачи страниц — вполне нормально работает. QoS тоже не просто так придумали. и не надо сваливать все задачи в одну кучу, например. те же большие даунлоады можно отдавать торрентами, а не гнать тупо по http-каналу.
>> всему софту, который использует http, «потоковый» слой поверх навелосипеденого
>> на UDP протокола? так TCP уже сделан же.
> У TCP довольно много грабель. Например, congestion control у него - ни
> два ни полтора.У UDP грабель ещё больше.
И congestion control там, если делают, то свой, велосипедный.
В uTorrent рекомендуют не включать uTP.
В NFS, тоже сначала сделали все на UDP, а в версии 3 добавили поддержку TCP.
И сейчас все современные статьи рекомендуют настраивать NFS по TCP.
>В uTP кстати велосипедисты так и сделали. И congestion control там как-то более реалистичный для фонового протокола вышел.Это не те ли клоуны котороые забили буфера на ISP рутерах миллиардами меееееленьких пакетов ??
Как же, как же - помним, помним. Самый популярный вопрос на форумах был как забокировать &@$*расов?!!!! И таки нашли как - и правила эти я думаю до сих пор никто с фаеров не убрал :)
Для начала их никто из вменяемых и не ставил. Мелочевка только.
> Для начала их никто из вменяемых и не ставил. Мелочевка только.Ога.
Крупночевка делает проще - при обнаружении торрент трафика тупо режет канал.
Так делают, например beeline, qwerty.
> Ога.
> Крупночевка делает проще - при обнаружении торрент трафика тупо режет канал.
> Так делают, например beeline, qwerty.Ростелеком так не делает, ТТК тоже. Если брать по СПб - SkyNet точно не режет, Interzet режет - но это редкостные ***, Дом.Ру не режет, MNS тоже не режет.
Пчелайномегафономтсы не рассматриваем в принципе - после скупки ими нескольких домосеток народ оттуда повалил к конкурентам, как ошпаренный. А режут наверняка там, где купили уже с обрезкой.
> Ростелеком так не делает, ТТК тоже.В случае магистральных каналов, или последней мили до клиента?
> Пчелайномегафономтсы не рассматриваем в принципе - после скупки ими нескольких домосеток
> народ оттуда повалил к конкурентам, как ошпаренный. А режут наверняка там,
> где купили уже с обрезкой.В москве корбина не резала, билайн стал резать через некоторое время.
"они не правы, но думаю они знают что делают". Шедеврально.
Не пищи больше сюда.
>"они не правы, но думаю они знают что делают"Не вижу противоречия
> Не пищи больше сюда.А можно и я не буду пищать?
> Для скорости неплохо бы с TCP на UDP перебраться, а не в
> SSL лезть. Впрочем, думаю Google знает что делает.TCP действительно следует заменить, но не на UDP, который даже установление соединения не умеет, а на SCTP, который умеет в многопоточность и четырехэтапное квитирование, избавляющее от SYN-флуд атак.
Но тут приблизительно такая же проблема, как и с ipv6, так что приходится лезть уровнем выше.
опять пытаются «заменить» streaming на message. ну что ж такое-то?
В чем проблема? SCTP как раз выполняет функции TCP плюс основную функцию SPDY.
Впрочем, http всё равно следует адаптировать к поддержке SCTP.
> В чем проблема?ты таки не различаешь даже слова stream и message? O_O
>> В чем проблема?
> ты таки не различаешь даже слова stream и message? O_OЯ различаю stream и message, но не понимаю что именно ты хочешь этим сказать.
> Я различаю stream и message, но не понимаю что именно ты хочешь
> этим сказать.ясно. сказал бы сразу — я бы на тебя время вообще не тратил.
Можно по существу, не используя слова stream и message как магические?
нет.
чую что это повсеместно и в ходу будет только под мою старость )))
Не боись!
Я тоже не думал в институте что через 20 лет мой телефон будет играючи рвать весь республиканский ВЦ АН ***СССР :)
> Не боись!
> Я тоже не думал в институте что через 20 лет мой телефон
> будет играючи рвать весь республиканский ВЦ АН ***СССР :)рвать-то рвет, но все равно тормозит.
> чую что это повсеместно и в ходу будет только под мою старость
> )))старость уже наступила