C>>И всё, пользователь видит застывшую полосу загрузки. Через некоторый таймаут Гугл поймёт, что переборщил с размером пакетов и уменьшит его. Но тайамаут — это тормоза. O>Это однократный таймаут, потом все пакеты такому клиенту надо слать с определенным MTU, периодически в фоне проверяя нельзя ли его подрастить. Причем оптимальный MTU должен запоминать не только гугл, но и сам клиент.
Кстати, MTU нужно периодически пересчитывать, потому что у промежуточного провайдера может поменяться роутинг (упал линк, данные пошли по резервному маршруту), да и пользователь через QUIC может подключиться по другому (пришел с мобилкой домой, подключился к WiFi, QUIC сессия осталась прежней). Причем, MTU клиент->сервер может отличаться от MTU сервер->клиент.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Somescout, Вы писали:
S>>ШИ ТО. Ютуб второй после твитча случай, когда программистам можно пересадить руки макаки и это не ухудшит результат. Гугль гонится за миллисекундами скорости, игнорируя что один из их основных сайтов тормозное ****.
vsb>Почему тормозное? У меня очень быстро открывается и работает.
Посмотрел — сейчас да, вроде поправили. Но до этого несколько месяцев открытие страницы занимало порядка 7-8 секунд и сопровождалось несколькими relayout, что неслабо раздражало (а в частности выкидывало из полноэкранного режима, если врубал его до полной загрузки страницы).
O>>Это однократный таймаут, потом все пакеты такому клиенту надо слать с определенным MTU, периодически в фоне проверяя нельзя ли его подрастить. Причем оптимальный MTU должен запоминать не только гугл, но и сам клиент. M>Причем, MTU клиент->сервер может отличаться от MTU сервер->клиент.
Это само собой. Кстати тут можно дополнить, что скорее всего скорость клиент->сервер большого значения не имеет, и гораздо важней сервер->клиент. Тогда можно сделать так: если клиент не умеет в TCP_MAXSEG то для клиент->сервер ставим MTU=1380, которое fits for all. А на сервере юзаем TCP_MAXSEG или ваще делаем кастомный TCP стек, который на таймаутах подбирает оптимальный MTU для server->client. Гугл же может пропатчить KDE под FreeBSD TCP стек на своих серверах?
А если скорость клиент->сервер все же важна, и браузер под линуксом окажется быстрее чем под виндой, то микрософт быренько реализует TCP_MAXSEG в winsock'е.
Но миром правит hype-driven-development. На тюнингованном протоколе хайпа не вырастишь, то ли дело навелосипедить новый.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Pzz, Вы писали:
Pzz>Хочу еще добавить, что wifi — это не единственный радиотранспорт. И в более других с безопасностью, я подозреваю, еще хуже.
В более других — лучше. WiMAX тому пример. Ну и сотовые сети последних поколений. При использовании такого транспорта всё будет шифроваться минимум дважды.
Здравствуйте, andyp, Вы писали:
A>В более других — лучше. WiMAX тому пример. Ну и сотовые сети последних поколений. При использовании такого транспорта всё будет шифроваться минимум дважды.
А ещё есть ZigBee (и построенный на той же технологии Thread), где всё хуже.
Здравствуйте, ononim, Вы писали:
O>Ненене. Не нужно никаких ICMP. Они считать что ICMP проходит — то вообще ничего не нужно, PMTU discovery придуман давно, но он не работает когда ICMP блочится. Что является корнем проблемы с PMTU. Т.о. нужно определять PMTU без использования ICMP.
Ок, пытаемся.
C>>И всё, пользователь видит застывшую полосу загрузки. Через некоторый таймаут Гугл поймёт, что переборщил с размером пакетов и уменьшит его. Но тайамаут — это тормоза. O>Это однократный таймаут, потом все пакеты такому клиенту надо слать с определенным MTU, периодически в фоне проверяя нельзя ли его подрастить. Причем оптимальный MTU должен запоминать не только гугл, но и сам клиент.
ОК, сделали (кстати, оно реально тестировалось Гуглом). Но всё равно не работает. У части клиентов странички периодически затормаживаются на несколько секунд.
Проблема в том, что IPv4 пакеты могут сами по себе фрагментироваться и пересобираться. Но вот пересборка часто глючит (см. "middlebox") или вообще запрещена, как сатанистский ритуал, порочащий доброе имя IPv4. Если установить DF, то можно потерять ответы о невозможности доставки.
И в TCP для контроля за этим есть только настройка MSS, которая согласуется только один раз в SYN-пакетах в начале. Так что вот и получается, что оно как-то всё вместе не работает.
O>Встречный вопрос: а как тогда решается данная проблема QUIC'ом? Ведь явно на тех же таймаутах. Потому что больше надежных путем нету. Потому все еще в упор не вижу преимуществ QUIC'а над тюнингом TCP.
В QUIC периодически посылаются тестовые пакеты параллельно основному соединению. Для них замеряется время в пути и при удачности измерения — размер окна переключается на них.
C>>Сразу начинают придумываться идеи типа: "А что если одновременно послать один большой пакет, пока мы в фоне посылаем маленькие?". Но от этого middlebox'ам плохеет так, что они вообще соединение разрывают. O>О да, а от QUIC'а мидлбоксы будут расслабленно плевать в потолок
Да, так как они НИЧЕГО не смогут сделать без полноценной MITM-атаки. В QUIC нет никаких зацепок для middlebox'ов, кроме одного бита (который с трудом протащили в стандарт).
Здравствуйте, Sharov, Вы писали:
N>>Иначе малейший затор создаст пакет большего размера, который уже не пройдёт. S>Почему, пакеты объединятся что ли? Или о чем речь?
Да. Формально, не пакеты, а собственно порции данных, в один пакет, который будет больше практического предела прохождения.
Здравствуйте, Cyberax, Вы писали:
C>А ещё есть ZigBee (и построенный на той же технологии Thread), где всё хуже.
У ZigBee только крючки для шифрования на MAC уровне. PAN же. Защищенные сети мутят на проприетарных девайсах с уже зашитой внутрь криптой. В открытую защищенную сеть на ZigBee не получится
C>В QUIC периодически посылаются тестовые пакеты параллельно основному соединению. Для них замеряется время в пути и при удачности измерения — размер окна переключается на них.
В UDP нету понятия соединения. Пакеты посылаются просто параллельно, и нет никаких гарантий что они все ходят по такому же маршруту.
С такой т.з. можно запустить ответчик на UDP "параллельный" TCP соединению и подстраивать TCP_MAXSEG согласно результатом от UDP.
Этот протокол вполне можно пропихнуть как стандартный UDP-хелпер для PMTU discovery, все спасибо скажут. А не вот так.
O>>О да, а от QUIC'а мидлбоксы будут расслабленно плевать в потолок C>Да, так как они НИЧЕГО не смогут сделать без полноценной MITM-атаки. В QUIC нет никаких зацепок для middlebox'ов, кроме одного бита (который с трудом протащили в стандарт).
Хватит того что там есть номер UDP порта.
Надо было копать глубже — и туннелтроваться через ICMP.
Вот тогда бы все подофигели Но это невозможно без админских прав.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, andyp, Вы писали:
A>В более других — лучше. WiMAX тому пример. Ну и сотовые сети последних поколений. При использовании такого транспорта всё будет шифроваться минимум дважды.
А разве государство не ограничивает качество шифрования в сотовых сетях на уровне "сделали вид, что все зашифровано"?
Если мы все еще говорим об утюге, то там скорее будет Bluetooth или ZigBee какой-нибудь.
Здравствуйте, Pzz, Вы писали:
Pzz>А разве государство не ограничивает качество шифрования в сотовых сетях на уровне "сделали вид, что все зашифровано"?
Государству сейчас это просто не нужно. Проще стойку рядом с оборудованием провайдера поставить и снимать уже нешифрованный трафик, что собственно и делается.
Pzz>Если мы все еще говорим об утюге, то там скорее будет Bluetooth или ZigBee какой-нибудь.
ZigBee в теории предусматривает возможность шифрования на уровне MAC. На практике оказывается, что либо имеем дело с закрытой сетью, где все устройства выдаются провайдером (и тут шифрование вполне себе может присутствовать), либо с открытой сетью, где устройства могут быть любыми, но шифрования нет.
Здравствуйте, ononim, Вы писали:
C>>В QUIC периодически посылаются тестовые пакеты параллельно основному соединению. Для них замеряется время в пути и при удачности измерения — размер окна переключается на них. O>В UDP нету понятия соединения.
Оно есть в QUIC.
O>Пакеты посылаются просто параллельно, и нет никаких гарантий что они все ходят по такому же маршруту.
Более того, в QUIC напрямую поддерживается multipath — можно передавать данные параллельно через WiFi и LTE, например.
O>С такой т.з. можно запустить ответчик на UDP "параллельный" TCP соединению и подстраивать TCP_MAXSEG согласно результатом от UDP.
А может проще тогда свой протокол сделать?
O>Этот протокол вполне можно пропихнуть как стандартный UDP-хелпер для PMTU discovery, все спасибо скажут. А не вот так.
Ещё потом добавить multipath, шифрование, назвать всё это QUIC — и будет просто супер!
C>>Да, так как они НИЧЕГО не смогут сделать без полноценной MITM-атаки. В QUIC нет никаких зацепок для middlebox'ов, кроме одного бита (который с трудом протащили в стандарт). O>Хватит того что там есть номер UDP порта.
То есть?
Здравствуйте, Ops, Вы писали:
Ops>Может быть. Решается голосованием ногами — этот провайдер может и в другом нагадить, нафиг он нужен?
это решается https, иначе ты можешь просто не знать, что это товой оператор так сделал, скажем на мегафоне тебе могут огромный поупап баннер на сайте показать, который на самом деле не владелец сайта туда поставил, а мегафон
ну и не скажешь же ты своим пользователям менять симкарты?
Здравствуйте, CreatorCray, Вы писали:
CC>Что то мне кажется что в реале он как раз будет сосать что тот пылесос. CC>Потому что шторм UDP запросов говномиддлбоксы переваривают плохо.
там свой congestion control есть, при этом он как раз снизит нагрузку на сетевое оборудование, т.к. CC в TCP работает хреново, т.к. он работает на уровне TCP подключения, а по факту, браузер открывает множество соединений с хостом и весь CC вылетает в трубу (ну почти)
S>Соответственно, в будущей версии HTTP транспорт TCP заменят на QUIC.
Вот так прогресс делает некоторые специализации менее нужными. Вот раньше как было, ходил HTTP трафик по TCP, люди писали TCP сервера поверх стека ОС, преодолевали проблемы оного стека ОС (проблема 10К), использовали epoll и windows completion ports. Но QUIC работает поверх UDP, большая часть протокола в userspace, сейчас у UDP нет таких проблем как у TCP, ОС умеет через recvmsg обрабатывать миллионы UDP пакетов в секунду, поэтому нет проблемы 10К.
CK>Но QUIC работает поверх UDP, большая часть протокола в userspace, сейчас у UDP нет таких проблем как у TCP, ОС умеет через recvmsg обрабатывать миллионы UDP пакетов в секунду, поэтому нет проблемы 10К.
Тащемто если хотябы _немножечко_ изучить тему то обнаружится что QUIC грузит CPU сильно сильнее чем TCP.
Как много веселых ребят, и все делают велосипед...
Но это невозможно без админских прав.
