Может быть A и последний в цепочке, но в общепринятом смысле корневым здесь будет B. Сама цепочка от приложения не зависит, но какой сертификат в ней доверенный, то есть на каком приложение закончит (если закончит) проверку цепочки, зависит.
Взять конкретно: вот я с помощью OpenSSL создал себе эту цепочку сертификатов A->B->C->D, запустил сервер, использующий сертификат D, и открываю страницу на винде в ms edge. Для этого я добавил сертификат B в хранилище сертификатов "Trusted Root Certification Authorities" на винде. То есть, судя по по названию хранилища, теперь B корневой, но на нём цепочка не заканчивается.
Многие другие приложения вообще избегают слов "корневой" и "доверенный". В Firefox список сертификатов называется просто "authorities", в curl они передаются в опции "-cacert" и в документации не упоминаются слова "root" и "trusted". В nodejs проскальзывает "root", но документация его использует очень осторожно, и переопределяется список сертификатов опцией просто "ca".
Возможно надо microsoft винить за некорректное название хранилища на винде конкретно. Но, надеюсь, видите, какая с этим словом путаница
Что значит "последний"?) Допустим, цепочка сертификатов выглядит так: A->B->C->D, где A самоподписанный, а D листовой. Если сертификат A доверенный для моего браузера, тогда согласен, что он последний в цепочке, он же корневой. А если доверенным является B, но не A? Я бы всё ещё сказал, что последним в цепочке является А, тем не менее, мой браузер не считает его корневым в общепринятом смысле.
Даже если считать, что тогда последним в цепочке является B, а что если во втором браузере у меня B не доверенный, а доверенный C? Получается, нужно говорить о сертификате "корневом для данной программы". По-моему эта фраза звучит очень странно. Для меня "корневой" слышится как какое-то неотъемлемое свойство сертификата или CA, а по факту "корневость" сертификата зависит от конкретной программы. Короче, как ни крути, какие-то неоднозначности.
Или просто откроем два (или двадцать два) TCP-соединения и будем делать тоже самое.
Так и жили с http1.1, и одной из целей http2 как раз было избавиться от кучи TCP-соединений. Во вступлении RFC об этом речь
The resulting protocol [HTTP/2] is more friendly to the network because fewer TCP connections can be used in comparison to HTTP/1.x. This means less competition with other flows and longer-lived connections, which in turn lead to better utilization of available network capacity. Note, however, that TCP head-of-line blocking is not addressed by this protocol.
Вот, допустим, накидали причин, почему множество TCP-соединений это неоптимально.
Ну как, то, что есть похожие принципы работы не значит, что http2 это tcp в tcp. Всё-таки цели разные: tcp потоковый протокол, http2 основан на обмене сообщениями. Почему http2 тогда работает поверх tcp? Потому что выбирать приходится только из tcp и udp, либо изобретать свой транспортный протокол, а это головная боль. udp не подходит, потому что реализовывать надёжную доставку пакетов тоже головная боль, а tcp её предоставляет и проверен временем.
Теперь, вроде как у нас от tcp есть целый поток по которому отправляй данные не хочу, а мы только одно сообщение отправили и ждём, давайте этот поток использовать по полной. Для этого прилепим к каждому сообщению идентификатор и будем отправлять их целую кучу. Новая проблема: сообщения можно отправлять только целиком, ну так давайте разобьём их на более мелкие кадры. Вот и вышел http2, по мне так из вполне логичных и обоснованных рассуждений. Другое дело, что эти простые и очевидные решения оказались не совсем совместимы с реальностью, и что тот "целый поток" плохо справляется с грудой сообщений которые мы по нему теперь отправляем. Тут уже ничего не остаётся, кроме как придумывать новый транспортный протокол, собственно чем и занялись в http3. В общем, понятиями конечно http2 и tcp оперируют очень похожими, но в историческом контексте, я считаю, решения вполне обоснованные.
В том и дело, что http2 прикладной протокол, реализации которого тратят больше вычислительных ресурсов на то, чтобы интерпретировать содержимое кадров, а не на то, чтобы считать их из памяти. Соответственно, в моём понимании, там увеличение производительности от выравнивания было бы мизерное, если бы вообще было.
Таким образом при обработке эти поля можно прямо сразу считать готовой структурой работать с заголовком в памяти напрямую.
Не скажу, что я эксперт в низкоуровневом программировании, но как-то мне не верится, что сколько-нибудь значительного улучшения производительности можно было бы достичь с выровненным заголовком. Для tcp ещё могу понять: там содержимое заголовков — это набор чиселок, а содержимое пакета вообще не имеет значения, соответственно чиселки проще считывать, когда они выровнены. А реализации http2 интерпретируют содержимое кадров не как просто чиселки. В плане, как ни крути, реализации http2 работают на прикладном уровне, значит они читают все данные: и заголовок кадра, и содержимое, — из системного буфера tcp в условный массив. Даже если заголовок кадра был бы, допустим, 16 байтов, http-заголовки всё равно записаны чёрт знает как, у них всех разная длина, и значения могут быть произвольные. Так что чтобы от выровненного заголовка кадра был смысл, надо чтобы и http-заголовки были выровнены, а это трата места. И вообще, HTTP/2 пытается оптимизировать использование трафика и, пусть и не слишком удачно, количество необходимых tcp соединений, а не скорость обработки: мне кажется любые выигрыши производительности, которые можно было бы достигнуть выравниванием, мгновенно нивелируются, например, затратами на распаковку HPACK.
Заменить отдельные потоки TCP-соединениями, пинги на keepalive, управление окном на ... управление окном
И вы получите HTTP/1.1 с его недостатками, которые гугл попытался исправить в HTTP/2?) Не хочу сказать, что http2 хороший протокол. То, что возникли проблемы из-за попытки отправлять кучу запросов по одному TCP соединению, и так понятно, это упоминается в каждой статье с обзором http3. Собственно для этого и пришлось разрабатывать quic. Но если у вас вопрос "зачем был нужен такой протокол", то ответ — не совсем удачная попытка избавиться от проблем http1.1, которая перелилась в http3 — пока не совсем ясно, насколько удачную попытку избавиться от проблем http2.
Бенчмарки все поголовно говорят, что http2 быстрее, у кого-то в 2 раза, у кого-то в 1.001. Так что, по крайней мере, если вы играете в бенчмарки, выигрыш есть) А есть ли на самом деле ну надо смотреть на конкретном сайте и целевой аудитории.
И, кстати, запрос GET / HTTP/1.1\r\n\r\n в http2, если использовать HPACK по уму, а не как я описывал, записывается 00 00 03 01 05 00 00 00 01 12 14 17 — 12 байтов вместо 18, считайте, на треть меньше B). А оценивать более содержательные запросы и включать в оценку преамбулу не будем, чтобы не портить статистику.
Не соглашусь, всё-таки HTTP/3 и QUIC сравнительно новые, ещё не обжились инфраструктурой. Особенно QUIC: учитывая, что сейчас клиент, отправляя пакеты QUIC не может быть уверен, дойдёт ли он хоть куда-нибудь, будет ли принят сервером или отвалится где-то по пути из-за файерволов, соединение HTTP/3 всё равно приходится начинать с соединения HTTP/2. Не на всех языках даже есть реализации клиентов/серверов HTTP/3 из-за терок с openssl. Взять тот же NodeJS, там библиотека для работы с QUIC всё ещё в разработке. Плюс HTTP/3 толком от 2 версии не отличается, по большому счёту просто вся чепуха с мультиплексированием перенесена с прикладного уровня на транспортный.
Ну и я полагаю позиция комитета по HTTP такая, что все три версии протокола сосуществуют, а не заменяют друг друга. Всё-таки чем дальше в лес, тем больше дров непонятно, зачем упарываться с бинарным HTTP/2, если вы пишете hello world для портфолио, там и HTTP/1.1 прекрасно справляется. Так же с HTTP/3, всё-таки TCP не без недостатков, но проверен временем. Зачем лезть в трясину QUIC, если HTTP/2 даёт достаточный выигрыш во что вы там ни играли.
Вдохновляющее предложение, но не вижу большой ценности в том, чтобы разбирать реализации) Если у меня получилось описать протокол в целом так, чтобы был ясен смысл основных его особенностей, не должно быть трудно разобраться, как работают конкретные реализации. Практических гайдов, как настроить тот же putty вроде как уйма, а про OpenSSH тут заикался чисто ради примера, иначе бы вышло абстрактное повествование в вакууме. Так что вряд ли дождётесь, всё-таки я скорее теоретик, чем практик)
Да, именно так. Если потеряете — не конец света, только придется создать новую пару ключей, и попросить администратора перенастроить авторизацию, отправив новый открытый ключ. Главное, чтобы потерянный закрытый никто не узнал до того момента, как старый открытый не удалят с сервера.
Во-первых, то, что её ввели в старом отменённом ГОСТе, не значит, что она неверная. Возьмите, например, ГОСТ Р 34.13-2015. Издан в 2016 году, сейчас действует, и использует эту лексику.
Во-вторых статья, которую вы привели говорит о целостности в совершенно другом контексте, собственно в этом и размытость. Имитовставка, она же MAC — вполне конкретное понятие, набор байт, благодаря которому можно убедиться в целостности сообщения. Целостность — очень общее понятие, которое применимо к самым разным контекстам. Если хотите, говорите "ключ целостности". Я же считаю, что "имитовставка", как более узкий термин, здесь уместна, а раз алгоритм имитовставки, то и ключ для него предпочитаю называть ключом имитовставки.
А вообще, мне название "ключ целостности" кажется немного размытым. Всё-таки "имитовставка" подразумевает, что это дополнительная "вставка" в сообщение, а "ключ имитовставки" соответственно нужен чтобы эту "вставку" сгенерировать и проверить. А "ключ целостности" по-моему никак не описывает, что он из себя представляет и как именно используется. Но кому как, я знаком с MAC только по английским ресурсам, не возьмусь утверждать, какая терминология закрепилась в русском.
UPD: я обдумал эту тему, и понял, что действительно как-то не гоже утверждать, что соединение защищено без упоминания MAC. Написал чуть более подробно о нём.
Цель была описать части SSH, с которыми приходится иметь дело при использовании протокола будучи рядовым разработчиком. MAC вещь важная, но при использовании протокола с ним обычно иметь дело не приходится, он находится совсем под капотом в реализациях протокола (по крайней мере я ни разу не слышал/не видел в статьях про SSH упоминание MAC, полагаю часть про него вообще не знает, часть не считает нужным обсуждать, так как реализации сами разбираются с ним). Так что я позволил себе посчитать MAC одной из тех самых "продвинутых возможностей", пусть он и заложен практически в основу протокола. Возможно напишу ещё что-то про SSH и раскрою тему MAC, но здесь считаю лишним его разбор.
Дошли руки. Обещанная ссылка: https://habr.com/ru/companies/timeweb/articles/764260/
Это вторая из двух статей о TLS, где собственно разбор по байтам. Если не очень разбираетесь в протоколе, лучше начать с первой: https://habr.com/ru/companies/timeweb/articles/752270/
К сожалению, не вместилось в статью. А может и не к сожалению, не считаю эту тему особенно интересной)
Не понял, о чем вы
Может быть A и последний в цепочке, но в общепринятом смысле корневым здесь будет B. Сама цепочка от приложения не зависит, но какой сертификат в ней доверенный, то есть на каком приложение закончит (если закончит) проверку цепочки, зависит.
Взять конкретно: вот я с помощью OpenSSL создал себе эту цепочку сертификатов A->B->C->D, запустил сервер, использующий сертификат D, и открываю страницу на винде в ms edge. Для этого я добавил сертификат B в хранилище сертификатов "Trusted Root Certification Authorities" на винде. То есть, судя по по названию хранилища, теперь B корневой, но на нём цепочка не заканчивается.
Многие другие приложения вообще избегают слов "корневой" и "доверенный". В Firefox список сертификатов называется просто "authorities", в curl они передаются в опции "-cacert" и в документации не упоминаются слова "root" и "trusted". В nodejs проскальзывает "root", но документация его использует очень осторожно, и переопределяется список сертификатов опцией просто "ca".
Возможно надо microsoft винить за некорректное название хранилища на винде конкретно. Но, надеюсь, видите, какая с этим словом путаница
Что значит "последний"?) Допустим, цепочка сертификатов выглядит так: A->B->C->D, где A самоподписанный, а D листовой. Если сертификат A доверенный для моего браузера, тогда согласен, что он последний в цепочке, он же корневой. А если доверенным является B, но не A? Я бы всё ещё сказал, что последним в цепочке является А, тем не менее, мой браузер не считает его корневым в общепринятом смысле.
Даже если считать, что тогда последним в цепочке является B, а что если во втором браузере у меня B не доверенный, а доверенный C? Получается, нужно говорить о сертификате "корневом для данной программы". По-моему эта фраза звучит очень странно. Для меня "корневой" слышится как какое-то неотъемлемое свойство сертификата или CA, а по факту "корневость" сертификата зависит от конкретной программы. Короче, как ни крути, какие-то неоднозначности.
Так и жили с http1.1, и одной из целей http2 как раз было избавиться от кучи TCP-соединений. Во вступлении RFC об этом речь
Вот, допустим, накидали причин, почему множество TCP-соединений это неоптимально.
Ну как, то, что есть похожие принципы работы не значит, что http2 это tcp в tcp. Всё-таки цели разные: tcp потоковый протокол, http2 основан на обмене сообщениями. Почему http2 тогда работает поверх tcp? Потому что выбирать приходится только из tcp и udp, либо изобретать свой транспортный протокол, а это головная боль. udp не подходит, потому что реализовывать надёжную доставку пакетов тоже головная боль, а tcp её предоставляет и проверен временем.
Теперь, вроде как у нас от tcp есть целый поток по которому отправляй данные не хочу, а мы только одно сообщение отправили и ждём, давайте этот поток использовать по полной. Для этого прилепим к каждому сообщению идентификатор и будем отправлять их целую кучу. Новая проблема: сообщения можно отправлять только целиком, ну так давайте разобьём их на более мелкие кадры. Вот и вышел http2, по мне так из вполне логичных и обоснованных рассуждений. Другое дело, что эти простые и очевидные решения оказались не совсем совместимы с реальностью, и что тот "целый поток" плохо справляется с грудой сообщений которые мы по нему теперь отправляем. Тут уже ничего не остаётся, кроме как придумывать новый транспортный протокол, собственно чем и занялись в http3. В общем, понятиями конечно http2 и tcp оперируют очень похожими, но в историческом контексте, я считаю, решения вполне обоснованные.
В том и дело, что http2 прикладной протокол, реализации которого тратят больше вычислительных ресурсов на то, чтобы интерпретировать содержимое кадров, а не на то, чтобы считать их из памяти. Соответственно, в моём понимании, там увеличение производительности от выравнивания было бы мизерное, если бы вообще было.
Не скажу, что я эксперт в низкоуровневом программировании, но как-то мне не верится, что сколько-нибудь значительного улучшения производительности можно было бы достичь с выровненным заголовком. Для tcp ещё могу понять: там содержимое заголовков — это набор чиселок, а содержимое пакета вообще не имеет значения, соответственно чиселки проще считывать, когда они выровнены. А реализации http2 интерпретируют содержимое кадров не как просто чиселки. В плане, как ни крути, реализации http2 работают на прикладном уровне, значит они читают все данные: и заголовок кадра, и содержимое, — из системного буфера tcp в условный массив. Даже если заголовок кадра был бы, допустим, 16 байтов, http-заголовки всё равно записаны чёрт знает как, у них всех разная длина, и значения могут быть произвольные. Так что чтобы от выровненного заголовка кадра был смысл, надо чтобы и http-заголовки были выровнены, а это трата места. И вообще, HTTP/2 пытается оптимизировать использование трафика и, пусть и не слишком удачно, количество необходимых tcp соединений, а не скорость обработки: мне кажется любые выигрыши производительности, которые можно было бы достигнуть выравниванием, мгновенно нивелируются, например, затратами на распаковку HPACK.
И вы получите HTTP/1.1 с его недостатками, которые гугл попытался исправить в HTTP/2?) Не хочу сказать, что http2 хороший протокол. То, что возникли проблемы из-за попытки отправлять кучу запросов по одному TCP соединению, и так понятно, это упоминается в каждой статье с обзором http3. Собственно для этого и пришлось разрабатывать quic. Но если у вас вопрос "зачем был нужен такой протокол", то ответ — не совсем удачная попытка избавиться от проблем http1.1, которая перелилась в http3 — пока не совсем ясно, насколько удачную попытку избавиться от проблем http2.
Не понял, что вы имеете в виду под "кривыми отступами полей заголовков" и при чём здесь TCP. HTTP/2 не стремится заменить TCP ни в какой интерпретации
Думал об этом, возможно будет :) Если будет, оставлю тут ссылку
Не за что)
Бенчмарки все поголовно говорят, что http2 быстрее, у кого-то в 2 раза, у кого-то в 1.001. Так что, по крайней мере, если вы играете в бенчмарки, выигрыш есть) А есть ли на самом деле ну надо смотреть на конкретном сайте и целевой аудитории.
И, кстати, запрос
GET / HTTP/1.1\r\n\r\nв http2, если использовать HPACK по уму, а не как я описывал, записывается00 00 03 01 05 00 00 00 01 12 14 17— 12 байтов вместо 18, считайте, на треть меньше B). А оценивать более содержательные запросы и включать в оценку преамбулу не будем, чтобы не портить статистику.Не соглашусь, всё-таки HTTP/3 и QUIC сравнительно новые, ещё не обжились инфраструктурой. Особенно QUIC: учитывая, что сейчас клиент, отправляя пакеты QUIC не может быть уверен, дойдёт ли он хоть куда-нибудь, будет ли принят сервером или отвалится где-то по пути из-за файерволов, соединение HTTP/3 всё равно приходится начинать с соединения HTTP/2. Не на всех языках даже есть реализации клиентов/серверов HTTP/3 из-за терок с openssl. Взять тот же NodeJS, там библиотека для работы с QUIC всё ещё в разработке. Плюс HTTP/3 толком от 2 версии не отличается, по большому счёту просто вся чепуха с мультиплексированием перенесена с прикладного уровня на транспортный.
Ну и я полагаю позиция комитета по HTTP такая, что все три версии протокола сосуществуют, а не заменяют друг друга. Всё-таки чем дальше в лес, тем больше дров непонятно, зачем упарываться с бинарным HTTP/2, если вы пишете hello world для портфолио, там и HTTP/1.1 прекрасно справляется. Так же с HTTP/3, всё-таки TCP не без недостатков, но проверен временем. Зачем лезть в трясину QUIC, если HTTP/2 даёт достаточный выигрыш во что вы там ни играли.
Точно, спасибо!
Вдохновляющее предложение, но не вижу большой ценности в том, чтобы разбирать реализации) Если у меня получилось описать протокол в целом так, чтобы был ясен смысл основных его особенностей, не должно быть трудно разобраться, как работают конкретные реализации. Практических гайдов, как настроить тот же putty вроде как уйма, а про OpenSSH тут заикался чисто ради примера, иначе бы вышло абстрактное повествование в вакууме. Так что вряд ли дождётесь, всё-таки я скорее теоретик, чем практик)
Да, именно так. Если потеряете — не конец света, только придется создать новую пару ключей, и попросить администратора перенастроить авторизацию, отправив новый открытый ключ. Главное, чтобы потерянный закрытый никто не узнал до того момента, как старый открытый не удалят с сервера.
Во-первых, то, что её ввели в старом отменённом ГОСТе, не значит, что она неверная. Возьмите, например, ГОСТ Р 34.13-2015. Издан в 2016 году, сейчас действует, и использует эту лексику.
Во-вторых статья, которую вы привели говорит о целостности в совершенно другом контексте, собственно в этом и размытость. Имитовставка, она же MAC — вполне конкретное понятие, набор байт, благодаря которому можно убедиться в целостности сообщения. Целостность — очень общее понятие, которое применимо к самым разным контекстам. Если хотите, говорите "ключ целостности". Я же считаю, что "имитовставка", как более узкий термин, здесь уместна, а раз алгоритм имитовставки, то и ключ для него предпочитаю называть ключом имитовставки.
https://ru.wikipedia.org/wiki/Имитовставка
А вообще, мне название "ключ целостности" кажется немного размытым. Всё-таки "имитовставка" подразумевает, что это дополнительная "вставка" в сообщение, а "ключ имитовставки" соответственно нужен чтобы эту "вставку" сгенерировать и проверить. А "ключ целостности" по-моему никак не описывает, что он из себя представляет и как именно используется. Но кому как, я знаком с MAC только по английским ресурсам, не возьмусь утверждать, какая терминология закрепилась в русском.
UPD: я обдумал эту тему, и понял, что действительно как-то не гоже утверждать, что соединение защищено без упоминания MAC. Написал чуть более подробно о нём.
Цель была описать части SSH, с которыми приходится иметь дело при использовании протокола будучи рядовым разработчиком. MAC вещь важная, но при использовании протокола с ним обычно иметь дело не приходится, он находится совсем под капотом в реализациях протокола (по крайней мере я ни разу не слышал/не видел в статьях про SSH упоминание MAC, полагаю часть про него вообще не знает, часть не считает нужным обсуждать, так как реализации сами разбираются с ним). Так что я позволил себе посчитать MAC одной из тех самых "продвинутых возможностей", пусть он и заложен практически в основу протокола. Возможно напишу ещё что-то про SSH и раскрою тему MAC, но здесь считаю лишним его разбор.