Re[16]: TCP все...
От: Masterspline  
Дата: 18.11.18 16:11
Оценка:
C>>И всё, пользователь видит застывшую полосу загрузки. Через некоторый таймаут Гугл поймёт, что переборщил с размером пакетов и уменьшит его. Но тайамаут — это тормоза.
O>Это однократный таймаут, потом все пакеты такому клиенту надо слать с определенным MTU, периодически в фоне проверяя нельзя ли его подрастить. Причем оптимальный MTU должен запоминать не только гугл, но и сам клиент.

Кстати, MTU нужно периодически пересчитывать, потому что у промежуточного провайдера может поменяться роутинг (упал линк, данные пошли по резервному маршруту), да и пользователь через QUIC может подключиться по другому (пришел с мобилкой домой, подключился к WiFi, QUIC сессия осталась прежней). Причем, MTU клиент->сервер может отличаться от MTU сервер->клиент.
Re[15]: TCP все...
От: Somescout  
Дата: 18.11.18 17:17
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, Somescout, Вы писали:


S>>ШИ ТО. Ютуб второй после твитча случай, когда программистам можно пересадить руки макаки и это не ухудшит результат. Гугль гонится за миллисекундами скорости, игнорируя что один из их основных сайтов тормозное ****.


vsb>Почему тормозное? У меня очень быстро открывается и работает.


Посмотрел — сейчас да, вроде поправили. Но до этого несколько месяцев открытие страницы занимало порядка 7-8 секунд и сопровождалось несколькими relayout, что неслабо раздражало (а в частности выкидывало из полноэкранного режима, если врубал его до полной загрузки страницы).
ARI ARI ARI... Arrivederci!
Re[17]: TCP все...
От: ononim  
Дата: 18.11.18 17:22
Оценка:
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. На тюнингованном протоколе хайпа не вырастишь, то ли дело навелосипедить новый.
Как много веселых ребят, и все делают велосипед...
Отредактировано 18.11.2018 17:23 ononim . Предыдущая версия .
Re[17]: TCP все...
От: CreatorCray  
Дата: 18.11.18 21:24
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Ага. Думаешь sleep-ы мне не скармливают?

Думаю что хром просто может стандарт не соблюдать в свою пользу.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[16]: TCP все...
От: andyp  
Дата: 18.11.18 21:45
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Хочу еще добавить, что wifi — это не единственный радиотранспорт. И в более других с безопасностью, я подозреваю, еще хуже.


В более других — лучше. WiMAX тому пример. Ну и сотовые сети последних поколений. При использовании такого транспорта всё будет шифроваться минимум дважды.
Re[15]: TCP все...
От: Sharov Россия  
Дата: 18.11.18 22:21
Оценка:
Здравствуйте, netch80, Вы писали:

N>Иначе малейший затор создаст пакет большего размера, который уже не пройдёт.


Почему, пакеты объединятся что ли? Или о чем речь?
Кодом людям нужно помогать!
Re[17]: TCP все...
От: Cyberax Марс  
Дата: 19.11.18 02:24
Оценка:
Здравствуйте, andyp, Вы писали:

A>В более других — лучше. WiMAX тому пример. Ну и сотовые сети последних поколений. При использовании такого транспорта всё будет шифроваться минимум дважды.

А ещё есть ZigBee (и построенный на той же технологии Thread), где всё хуже.
Sapienti sat!
Re[16]: TCP все...
От: Cyberax Марс  
Дата: 19.11.18 02:37
Оценка: 1 (1)
Здравствуйте, 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'ов, кроме одного бита (который с трудом протащили в стандарт).
Sapienti sat!
Re[16]: TCP все...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 19.11.18 09:40
Оценка: 2 (1)
Здравствуйте, Sharov, Вы писали:

N>>Иначе малейший затор создаст пакет большего размера, который уже не пройдёт.

S>Почему, пакеты объединятся что ли? Или о чем речь?

Да. Формально, не пакеты, а собственно порции данных, в один пакет, который будет больше практического предела прохождения.
The God is real, unless declared integer.
Re[18]: TCP все...
От: andyp  
Дата: 19.11.18 09:52
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>А ещё есть ZigBee (и построенный на той же технологии Thread), где всё хуже.


У ZigBee только крючки для шифрования на MAC уровне. PAN же. Защищенные сети мутят на проприетарных девайсах с уже зашитой внутрь криптой. В открытую защищенную сеть на ZigBee не получится
Re[17]: TCP все...
От: ononim  
Дата: 19.11.18 10:21
Оценка:
C>В QUIC периодически посылаются тестовые пакеты параллельно основному соединению. Для них замеряется время в пути и при удачности измерения — размер окна переключается на них.
В UDP нету понятия соединения. Пакеты посылаются просто параллельно, и нет никаких гарантий что они все ходят по такому же маршруту.
С такой т.з. можно запустить ответчик на UDP "параллельный" TCP соединению и подстраивать TCP_MAXSEG согласно результатом от UDP.
Этот протокол вполне можно пропихнуть как стандартный UDP-хелпер для PMTU discovery, все спасибо скажут. А не вот так.

O>>О да, а от QUIC'а мидлбоксы будут расслабленно плевать в потолок

C>Да, так как они НИЧЕГО не смогут сделать без полноценной MITM-атаки. В QUIC нет никаких зацепок для middlebox'ов, кроме одного бита (который с трудом протащили в стандарт).
Хватит того что там есть номер UDP порта.
Надо было копать глубже — и туннелтроваться через ICMP.
Вот тогда бы все подофигели Но это невозможно без админских прав.
Как много веселых ребят, и все делают велосипед...
Отредактировано 19.11.2018 10:27 ononim . Предыдущая версия . Еще …
Отредактировано 19.11.2018 10:25 ononim . Предыдущая версия .
Re[17]: TCP все...
От: Pzz Россия https://github.com/alexpevzner
Дата: 19.11.18 12:20
Оценка:
Здравствуйте, andyp, Вы писали:

A>В более других — лучше. WiMAX тому пример. Ну и сотовые сети последних поколений. При использовании такого транспорта всё будет шифроваться минимум дважды.


А разве государство не ограничивает качество шифрования в сотовых сетях на уровне "сделали вид, что все зашифровано"?

Если мы все еще говорим об утюге, то там скорее будет Bluetooth или ZigBee какой-нибудь.
Re[18]: TCP все...
От: andyp  
Дата: 19.11.18 13:15
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>А разве государство не ограничивает качество шифрования в сотовых сетях на уровне "сделали вид, что все зашифровано"?


Государству сейчас это просто не нужно. Проще стойку рядом с оборудованием провайдера поставить и снимать уже нешифрованный трафик, что собственно и делается.

Pzz>Если мы все еще говорим об утюге, то там скорее будет Bluetooth или ZigBee какой-нибудь.


ZigBee в теории предусматривает возможность шифрования на уровне MAC. На практике оказывается, что либо имеем дело с закрытой сетью, где все устройства выдаются провайдером (и тут шифрование вполне себе может присутствовать), либо с открытой сетью, где устройства могут быть любыми, но шифрования нет.
Re[18]: TCP все...
От: Cyberax Марс  
Дата: 19.11.18 19:03
Оценка:
Здравствуйте, 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 порта.
То есть?
Sapienti sat!
Re[20]: TCP все...
От: chaotic-kotik  
Дата: 20.11.18 06:46
Оценка:
Здравствуйте, Ops, Вы писали:

Ops>Может быть. Решается голосованием ногами — этот провайдер может и в другом нагадить, нафиг он нужен?


это решается https, иначе ты можешь просто не знать, что это товой оператор так сделал, скажем на мегафоне тебе могут огромный поупап баннер на сайте показать, который на самом деле не владелец сайта туда поставил, а мегафон
ну и не скажешь же ты своим пользователям менять симкарты?
Re[8]: TCP все...
От: chaotic-kotik  
Дата: 20.11.18 06:57
Оценка: 1 (1)
Здравствуйте, CreatorCray, Вы писали:

CC>Что то мне кажется что в реале он как раз будет сосать что тот пылесос.

CC>Потому что шторм UDP запросов говномиддлбоксы переваривают плохо.

там свой congestion control есть, при этом он как раз снизит нагрузку на сетевое оборудование, т.к. CC в TCP работает хреново, т.к. он работает на уровне TCP подключения, а по факту, браузер открывает множество соединений с хостом и весь CC вылетает в трубу (ну почти)
Re[14]: TCP все...
От: chaotic-kotik  
Дата: 20.11.18 06:59
Оценка:
Здравствуйте, Somescout, Вы писали:


S>Разница минимальна, более того со всеми подобными проблемами куда лучше справляется IPv6. Но гугля не хочет его ждать у гугли чешется NIH.


Re[16]: TCP все...
От: chaotic-kotik  
Дата: 20.11.18 07:03
Оценка: -1
Здравствуйте, ononim, Вы писали:

O>Согласен, надо подумать. К сожалению в винде отсутствует какой либо контроль над размером пакета.


Re: TCP все...
От: chaotic-kotik  
Дата: 20.11.18 07:21
Оценка: 1 (1) -1
Здравствуйте, Shmj, Вы писали:

S>

S>Соответственно, в будущей версии HTTP транспорт TCP заменят на QUIC.


Вот так прогресс делает некоторые специализации менее нужными. Вот раньше как было, ходил HTTP трафик по TCP, люди писали TCP сервера поверх стека ОС, преодолевали проблемы оного стека ОС (проблема 10К), использовали epoll и windows completion ports. Но QUIC работает поверх UDP, большая часть протокола в userspace, сейчас у UDP нет таких проблем как у TCP, ОС умеет через recvmsg обрабатывать миллионы UDP пакетов в секунду, поэтому нет проблемы 10К.
Re[2]: TCP все...
От: ononim  
Дата: 20.11.18 08:28
Оценка: +1
CK>Но QUIC работает поверх UDP, большая часть протокола в userspace, сейчас у UDP нет таких проблем как у TCP, ОС умеет через recvmsg обрабатывать миллионы UDP пакетов в секунду, поэтому нет проблемы 10К.
Тащемто если хотябы _немножечко_ изучить тему то обнаружится что QUIC грузит CPU сильно сильнее чем TCP.
Как много веселых ребят, и все делают велосипед...
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.