У меня есть оригинал. Книжка является художественной переработкой манов и занимает место на полке скорее как сувенир. Если вы надеетесь найти в ней больше информации, какие-то нюансы, то вас постигнет разочарование. То, о чем умалчивают manpages, умалчивает и эта книга.
Плюс из-за того, что можно отправить запросы сразу ко всем ресурсам и нет такого жесткого ограничения на кол-во параллельных потоков, устраняется проблема HOL-блокировки. Это не влияет на общее время загрузки, но в некоторых случаях позволяет браузерам получать минимально необходимые ресурсы для отрисовки страницы в первую очередь и страница отображается быстрее. Загружаться она может при этом дольше, но визуально пользователю кажется, что сайт работает шустрее.
TCP-хэндшейк достаточно дешевый чтобы в большинстве случаев на типичных задержках его не замечать. Основная экономия там достигается на TCP+TLS хэндшейках вместе взятых. HTTP/2 в браузерах работает только поверх TLS.
Только ситуация как раз обратная, 6 TCP соединений имеют большее суммарное окно, как в начале, сразу после открытия, так и в конце, после передачи данных.
Для nginx достаточно оставить включенными только протоколы TLS:
В nginx SSLv2 по-умолчанию был отключен ещё в 0.8.19 (т.е. больше 6 лет назад). И ничего делать не нужно, если только вы сами явно не включили его зачем-то.
И если уж вы решили цитировать статистику и что-то этим пытаетесь доказать или утверждать на тему, то замечу, раз статья на русском, то наверное статистика по русскоязычным сайтам более актуальна для целевой аудитории: http://w3techs.com/technologies/segmentation/cl-ru-/web_server
Для справки, сайт w3techs.com специализируется на статистике интернет-ресурсов и обновляет данные раз в сутки. Разница между вашей и моей ссылкой лишь в разбивке данных. По моей ссылке она чуть более подробная и содержит выборку для топ 1000, 10 000, 100 000 и 1 млн. самых посещаемых сайтов, а также процент "Overall" (т.е. в целом по всем отслеживаемым хостам). По вашей ссылке точь в точь та же самая статистика по "Overall", но для чуть более расширенного списка серверов.
Я нигде не отрицал, что в целом по интернету IIS вероятно имеет свои "чуть больше 10 процентов" и продолжает их стремительно терять. Но все верно, статья не об IIS, так что непонятно, зачем его было приплетать, а уж переходить на личности точно не стоило.
Для тех, кто в танке и не умеет пользоваться поиском
С невалидным поведение такое же как и раньше: браузер предупредит пользователя и тому нужно будет нажать кнопку. И скорее всего такое соединение не будет использоваться для запросов к другим хостам, даже если принятый таким способом самоподписной сертификат валиден и для них.
Вот чего-чего, а совместимости и разным деталям в стандарте уделено внимания не очень много, он вообще создает впечатление довольно сырого и написанного на скорую руку. Т.н. connection reuse, о котором я рассказал, описан в этой части: https://tools.ietf.org/html/rfc7540#section-9.1.1
Кстати, есть еще одна не решенная задача с nginx: сквозная авторизация ntlm. Хотя-бы потому, что он не умеет сопоставлять соединения входящие и к backend один-к-одному.
Зависит от сертификата. Если сертификат валиден для всех трех доменов, то будет одно соединение. Если валиден для двух из трех, скажем, то к этим двум будет одно соединение и еще одно к третьему.
SPDY для nginx около года существовал в виде отдельного патча и с июня 2012 его активно уже использовал cloudflare: blog.cloudflare.com/introducing-spdy
Это не со мной спорить нужно. ;-) Всем известный персонаж глубоко уверен, что контеншн там не грозит почти никогда и с точки зрения производительности абсолютно некритично, а вот с точки зрения сложности кода любая оптимизация — усложнение.
У меня изначально там были безлоковые очереди с семафорами, но благодаря стараниям всем известного персонажа их пришлось выкинуть, дескать слишком сложно. А с condition variables у нас там все равно уже лок есть.
Очень адекватный взгляд на ситуацию. Можете дополнить статью примером NGINX, для которого в итоге единственно работающим путем развития стало создание платного продукта.
работают — слышали историю Frenzy, ну и не только. Это просто первое, что в голову пришло
Например в случае nginx не работали вообще. Их хватало только на хостинг сайта. О том чтобы прокормить даже одного программиста, не говоря уже о целой команде, и речи не шло.
configureскормить такой же набор опций. Формат выводаnginx -Vкак раз позволяет это сделать.Я нигде не отрицал, что в целом по интернету IIS вероятно имеет свои "чуть больше 10 процентов" и продолжает их стремительно терять. Но все верно, статья не об IIS, так что непонятно, зачем его было приплетать, а уж переходить на личности точно не стоило.
;-)
Вот чего-чего, а совместимости и разным деталям в стандарте уделено внимания не очень много, он вообще создает впечатление довольно сырого и написанного на скорую руку. Т.н. connection reuse, о котором я рассказал, описан в этой части: https://tools.ietf.org/html/rfc7540#section-9.1.1
http://w3techs.com/technologies/cross/web_server/ranking
И, кстати, одно дело, когда кто-то на бумаге заявляет «production-ready» и другое дело реальный production: w3techs.com/technologies/segmentation/ce-spdy/web_server
Так что не рекомендую даже пытаться — зарежет.