Сообщение Re[8]: #? А есть ли вещи, которые вы принципиально не понима от 24.09.2016 18:06
Изменено 24.09.2016 19:47 Васисуалий Пупкиндт
Здравствуйте, _Raz_, Вы писали:
ВП>> Ссылку на демку я дал выше. Она наглядно показывает что дает.
_R_>Во-первых, я не понял к чему ссылка на преимущество в latency в ответ на мое замечание, что и сервер и клиент дополнительно занимаюся криптографией.
Пример демонстрирует как работает переключение на HTTP/2, и как с этим протоколом увеличивается скорость загрузки страниц с большим количеством элементов. В данном случае два раза.
Влияние шифрования при этом минимальное. Производительность растет за счет более оптимального алгоритма передачи данных, учитывающего особенности TCP и типичного сайтового трафика. И на сервере если что и меняется в плане нагрузки, то в основном из-за особенностей протоколов HTTP/2 и SPDY, а не TLS. На клиенте разницу по расходу ресурсов вообще не заметно.
_R_>Во-вторых, я уже писал про уже существующие keep-alive и кэши.
keep-alive на уровне HTTP поддерживаются. А кого в 21 веке волнуют кэши в промежуточных прокси я хз.
_R_>Стоп-стоп-стоп. TLS дает только S в TL. Откуда тут еще альтернативные протоколы? Альтернативные чему? И этим альтернативным протоколам кровь из носа нужно шифрование? Как TLS может оптимизировать существующие каналы связи и ,если может, то почему сейчас не оптимизирует? И уж совсем не понятно звучит, что TLS поможет сохранить "совместимость с браузерным клиентским уровнем веб приложений".
TLS поддерживает расширения протокола. В данном случае речь об ALPN:
https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation
Это механизм для согласования переключения на протоколы альтернативные HTTP. Это удобно, закреплено в RFC и уже поддержано в основных браузерах.
Для кода браузеров связанного передачей HTTP переключение на альтернативный протокол происходит прозрачно. То есть добавляется только еще один уровень абстракции над TLS, а существующие методы HTTP клиента в браузерах при этом остаются без изменений.
Все это поддерживается и работает уже сейчас на крупных сайтах, к примеру avito.ru, google.com, youtube.com и т.д. Можно если интересно в Chrome поставить расширение, которое показывает какой протокол используется в данный момент.
_R_>И еще раз — я ЗА эти протоколы, но против навязывания https. Точнее, даже не против, а, как в сабже написано, "принципиально не понимаете".
Видимо есть смысл самостоятельно оценить разницу. Можно отключить в Chrome поддержку SPDY, HTTP/2 и QUIC, и сравнить как youtube будет открываться по-старинке, раза в два медленнее. Может в этот момент и пройдет это самое, принципиальное непонимание
ВП>> Ссылку на демку я дал выше. Она наглядно показывает что дает.
_R_>Во-первых, я не понял к чему ссылка на преимущество в latency в ответ на мое замечание, что и сервер и клиент дополнительно занимаюся криптографией.
Пример демонстрирует как работает переключение на HTTP/2, и как с этим протоколом увеличивается скорость загрузки страниц с большим количеством элементов. В данном случае два раза.
Влияние шифрования при этом минимальное. Производительность растет за счет более оптимального алгоритма передачи данных, учитывающего особенности TCP и типичного сайтового трафика. И на сервере если что и меняется в плане нагрузки, то в основном из-за особенностей протоколов HTTP/2 и SPDY, а не TLS. На клиенте разницу по расходу ресурсов вообще не заметно.
_R_>Во-вторых, я уже писал про уже существующие keep-alive и кэши.
keep-alive на уровне HTTP поддерживаются. А кого в 21 веке волнуют кэши в промежуточных прокси я хз.
_R_>Стоп-стоп-стоп. TLS дает только S в TL. Откуда тут еще альтернативные протоколы? Альтернативные чему? И этим альтернативным протоколам кровь из носа нужно шифрование? Как TLS может оптимизировать существующие каналы связи и ,если может, то почему сейчас не оптимизирует? И уж совсем не понятно звучит, что TLS поможет сохранить "совместимость с браузерным клиентским уровнем веб приложений".
TLS поддерживает расширения протокола. В данном случае речь об ALPN:
https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation
Это механизм для согласования переключения на протоколы альтернативные HTTP. Это удобно, закреплено в RFC и уже поддержано в основных браузерах.
Для кода браузеров связанного передачей HTTP переключение на альтернативный протокол происходит прозрачно. То есть добавляется только еще один уровень абстракции над TLS, а существующие методы HTTP клиента в браузерах при этом остаются без изменений.
Все это поддерживается и работает уже сейчас на крупных сайтах, к примеру avito.ru, google.com, youtube.com и т.д. Можно если интересно в Chrome поставить расширение, которое показывает какой протокол используется в данный момент.
_R_>И еще раз — я ЗА эти протоколы, но против навязывания https. Точнее, даже не против, а, как в сабже написано, "принципиально не понимаете".
Видимо есть смысл самостоятельно оценить разницу. Можно отключить в Chrome поддержку SPDY, HTTP/2 и QUIC, и сравнить как youtube будет открываться по-старинке, раза в два медленнее. Может в этот момент и пройдет это самое, принципиальное непонимание
Re[8]: #? А есть ли вещи, которые вы принципиально не понима
Здравствуйте, _Raz_, Вы писали:
ВП>> Ссылку на демку я дал выше. Она наглядно показывает что дает.
_R_>Во-первых, я не понял к чему ссылка на преимущество в latency в ответ на мое замечание, что и сервер и клиент дополнительно занимаюся криптографией.
Пример демонстрирует как работает переключение на HTTP/2, и как с этим протоколом увеличивается скорость загрузки страниц с большим количеством элементов. В данном случае два раза.
Влияние шифрования при этом минимальное. Производительность растет за счет более оптимального алгоритма передачи данных, учитывающего особенности TCP и типичного сайтового трафика. И на сервере если что и меняется в плане нагрузки, то в основном из-за особенностей протоколов HTTP/2 и SPDY, а не TLS. На клиенте разницу по расходу ресурсов вообще не заметно.
_R_>Во-вторых, я уже писал про уже существующие keep-alive и кэши.
keep-alive на уровне HTTP поддерживаются. А кого в 21 веке волнуют кэши в промежуточных прокси я хз.
_R_>Стоп-стоп-стоп. TLS дает только S в TL. Откуда тут еще альтернативные протоколы? Альтернативные чему? И этим альтернативным протоколам кровь из носа нужно шифрование? Как TLS может оптимизировать существующие каналы связи и ,если может, то почему сейчас не оптимизирует? И уж совсем не понятно звучит, что TLS поможет сохранить "совместимость с браузерным клиентским уровнем веб приложений".
TLS поддерживает расширения протокола. В данном случае речь об ALPN:
https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation
Это механизм для согласования переключения на протоколы альтернативные HTTP. Это удобно, закреплено в RFC и уже поддержано в основных браузерах.
Для кода браузеров связанного передачей HTTP переключение на альтернативный протокол происходит прозрачно. То есть добавляется только еще один уровень абстракции над TLS, а существующие методы HTTP клиента в браузерах при этом остаются без изменений.
Все это поддерживается и работает уже сейчас на крупных сайтах, к примеру avito.ru, google.com, youtube.com и т.д. Можно если интересно в Chrome поставить расширение, которое показывает какой протокол используется в данный момент.
_R_>И еще раз — я ЗА эти протоколы, но против навязывания https. Точнее, даже не против, а, как в сабже написано, "принципиально не понимаете".
Видимо есть смысл самостоятельно оценить разницу. Можно отключить в Chrome поддержку SPDY, HTTP/2 и QUIC, и сравнить как youtube будет открываться по-старинке, раза в два медленнее. Может в этот момент и пройдет это самое, принципиальное непонимание
ВП>> Ссылку на демку я дал выше. Она наглядно показывает что дает.
_R_>Во-первых, я не понял к чему ссылка на преимущество в latency в ответ на мое замечание, что и сервер и клиент дополнительно занимаюся криптографией.
Пример демонстрирует как работает переключение на HTTP/2, и как с этим протоколом увеличивается скорость загрузки страниц с большим количеством элементов. В данном случае два раза.
Влияние шифрования при этом минимальное. Производительность растет за счет более оптимального алгоритма передачи данных, учитывающего особенности TCP и типичного сайтового трафика. И на сервере если что и меняется в плане нагрузки, то в основном из-за особенностей протоколов HTTP/2 и SPDY, а не TLS. На клиенте разницу по расходу ресурсов вообще не заметно.
_R_>Во-вторых, я уже писал про уже существующие keep-alive и кэши.
keep-alive на уровне HTTP поддерживаются. А кого в 21 веке волнуют кэши в промежуточных прокси я хз.
_R_>Стоп-стоп-стоп. TLS дает только S в TL. Откуда тут еще альтернативные протоколы? Альтернативные чему? И этим альтернативным протоколам кровь из носа нужно шифрование? Как TLS может оптимизировать существующие каналы связи и ,если может, то почему сейчас не оптимизирует? И уж совсем не понятно звучит, что TLS поможет сохранить "совместимость с браузерным клиентским уровнем веб приложений".
TLS поддерживает расширения протокола. В данном случае речь об ALPN:
https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation
Это механизм для согласования переключения на протоколы альтернативные HTTP. Это удобно, закреплено в RFC и уже поддержано в основных браузерах.
Для кода браузеров связанного передачей HTTP переключение на альтернативный протокол происходит прозрачно. То есть добавляется только еще один уровень абстракции над TLS, а существующие методы HTTP клиента в браузерах при этом остаются без изменений.
Все это поддерживается и работает уже сейчас на крупных сайтах, к примеру avito.ru, google.com, youtube.com и т.д. Можно если интересно в Chrome поставить расширение, которое показывает какой протокол используется в данный момент.
_R_>И еще раз — я ЗА эти протоколы, но против навязывания https. Точнее, даже не против, а, как в сабже написано, "принципиально не понимаете".
Видимо есть смысл самостоятельно оценить разницу. Можно отключить в Chrome поддержку SPDY, HTTP/2 и QUIC, и сравнить как youtube будет открываться по-старинке, раза в два медленнее. Может в этот момент и пройдет это самое, принципиальное непонимание