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

O>Тащемто если хотябы _немножечко_ изучить тему то обнаружится что QUIC грузит CPU сильно сильнее чем TCP.


что именно ты имеешь ввиду и почему по твоему это опровергает мои слова?
Re[2]: TCP все...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.11.18 09:01
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

CK>Вот так прогресс делает некоторые специализации менее нужными. Вот раньше как было, ходил HTTP трафик по TCP, люди писали TCP сервера поверх стека ОС, преодолевали проблемы оного стека ОС (проблема 10К), использовали epoll и windows completion ports. Но QUIC работает поверх UDP, большая часть протокола в userspace, сейчас у UDP нет таких проблем как у TCP,


И каким же образом этот вывод получается из сказанного ранее?
Переход на UDP магически отменяет необходимость делать ожидание на сокетах?

CK> ОС умеет через recvmsg обрабатывать миллионы UDP пакетов в секунду,


А для TCP, значит, не умела? О какой ОС речь-то?

CK> поэтому нет проблемы 10К.


The God is real, unless declared integer.
Re[3]: TCP все...
От: chaotic-kotik  
Дата: 20.11.18 09:21
Оценка: 1 (1) -1
Здравствуйте, netch80, Вы писали:

N>И каким же образом этот вывод получается из сказанного ранее?

N>Переход на UDP магически отменяет необходимость делать ожидание на сокетах?

я имел ввиду recvmmsg/sendmmsg + SO_REUSEPORT, на них можно построить свой QUIC стек на уровне приложения, который не будет нуждаться в ОС для мультеплексирования соединений и context switches и будет многопоточным
Re[21]: TCP все...
От: Ops Россия  
Дата: 20.11.18 10:11
Оценка: -1
Здравствуйте, chaotic-kotik, Вы писали:

CK>это решается https, иначе ты можешь просто не знать, что это товой оператор так сделал, скажем на мегафоне тебе могут огромный поупап баннер на сайте показать, который на самом деле не владелец сайта туда поставил, а мегафон

CK>ну и не скажешь же ты своим пользователям менять симкарты?

Да, это проблема пользователей. Без навязанного https этот баннер у них будет на большинстве сайтов, и они сами разберутся с провайдером.
Ну а твой пример с мегафоном некорректен: это у него было давно, и у малой части пользователей, сейчас про такое уже не слышно. Сейчас если кто-то где-то и балуется подобным, то это мизерная часть аудитории.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[4]: TCP все...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.11.18 10:47
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:

N>>И каким же образом этот вывод получается из сказанного ранее?

N>>Переход на UDP магически отменяет необходимость делать ожидание на сокетах?
CK>я имел ввиду recvmmsg/sendmmsg + SO_REUSEPORT,

Ага, тут вторая 'm' принципиальна.

CK> на них можно построить свой QUIC стек на уровне приложения, который не будет нуждаться в ОС для мультеплексирования соединений и context switches и будет многопоточным


Для сервера, да, в тему. Только для клиента это не очень полезно. Использовать один и тот же сокет для нескольких соединений с одним сервером — очевидный конфликт с правилами идентификации соединений, не сработает. Использовать его с разными серверами — значит, что слой IO дальше будет разбрасывать эти данные между разными сущностями (как вкладки в браузере) — тоже странное решение, мягко говоря.
The God is real, unless declared integer.
Re[2]: TCP все...
От: Pzz Россия https://github.com/alexpevzner
Дата: 20.11.18 11:04
Оценка: +3
Здравствуйте, chaotic-kotik, Вы писали:

CK>Вот так прогресс делает некоторые специализации менее нужными. Вот раньше как было, ходил HTTP трафик по TCP, люди писали TCP сервера поверх стека ОС, преодолевали проблемы оного стека ОС (проблема 10К), использовали epoll и windows completion ports. Но QUIC работает поверх UDP, большая часть протокола в userspace, сейчас у UDP нет таких проблем как у TCP, ОС умеет через recvmsg обрабатывать миллионы UDP пакетов в секунду, поэтому нет проблемы 10К.


Проблема 10K не решается сама собой от переноса соединений в user space.
Re[3]: TCP все...
От: ononim  
Дата: 20.11.18 11:08
Оценка: :)
Pzz>Проблема 10K не решается сама собой от переноса соединений в user space.
Ну как же. Ведь тцп стек операционки писали криворукие старперы, а модные девелоперы быстро эти пакетики разрулят на питончике, в 100500 раз быстрее. А если будет тормозить на питончике — напишут на го, вот тогда уж точно все залетает. А если у кого все еще не залетает, то те могут эээ.. заташить этот клубок макарон* в kernel-space.

  *
Новый паттерн архитектуры от гугла:
Как много веселых ребят, и все делают велосипед...
Отредактировано 20.11.2018 11:14 ononim . Предыдущая версия .
Re[3]: TCP все...
От: chaotic-kotik  
Дата: 20.11.18 11:31
Оценка: -1 :)
Здравствуйте, Pzz, Вы писали:

Pzz>Проблема 10K не решается сама собой от переноса соединений в user space.


ты про kernel bypass что-нибудь слышал?
вот например разработчики scylladb слышали — https://www.scylladb.com/product/technology/networking/
Re[22]: TCP все...
От: Masterspline  
Дата: 20.11.18 17:51
Оценка: +1
CK>>это решается https, иначе ты можешь просто не знать, что это товой оператор так сделал, скажем на мегафоне тебе могут огромный поупап баннер на сайте показать, который на самом деле не владелец сайта туда поставил, а мегафон
CK>>ну и не скажешь же ты своим пользователям менять симкарты?

Ops>Да, это проблема пользователей. Без навязанного https этот баннер у них будет на большинстве сайтов, и они сами разберутся с провайдером.

Ops>Ну а твой пример с мегафоном некорректен: это у него было давно, и у малой части пользователей, сейчас про такое уже не слышно. Сейчас если кто-то где-то и балуется подобным, то это мизерная часть аудитории.

Все уже давно поняли, что ты не можешь и не хочешь решать проблему подмены трафика пользователя провайдером (для этого надо всего лишь настроить https на своих сайтах и сделать автоматическое обновление сертификатов LetsEncrypt). И поэтому рассказываешь, что она не актуальна (касается мизерной части и вообще давно такого не было), перекладываешь ее решение на своих пользователей (пусть поменяют сим карты и перейдут на другого провайдера), а ответственность на Гугл (теперь всем известно, откуда твой геморрой).
Re[4]: TCP все...
От: Cyberax Марс  
Дата: 20.11.18 20:40
Оценка: 1 (1) +1
Здравствуйте, ononim, Вы писали:

Pzz>>Проблема 10K не решается сама собой от переноса соединений в user space.

O>Ну как же. Ведь тцп стек операционки писали криворукие старперы, а модные девелоперы быстро эти пакетики разрулят на питончике, в 100500 раз быстрее. А если будет тормозить на питончике — напишут на го, вот тогда уж точно все залетает.
https://www.dpdk.org/

Ась?
Sapienti sat!
Re[5]: TCP все...
От: ononim  
Дата: 20.11.18 21:12
Оценка:
O>>Ну как же. Ведь тцп стек операционки писали криворукие старперы, а модные девелоперы быстро эти пакетики разрулят на питончике, в 100500 раз быстрее. А если будет тормозить на питончике — напишут на го, вот тогда уж точно все залетает.
C>https://www.dpdk.org/
C>Ась?
Набор кастомных драйверов сетевых адаптеров со своими либами, заточенные под конкретное железо, начатая по инициативе интеля vs наколенная реализация транспортного протокола поверх UDP методом "а давайте запилим, и пофиг че получится по бенчмаркам, у нас бабок много"?
Очень популистское сравнение. Но на стадных девелоперов подействует.
Как много веселых ребят, и все делают велосипед...
Отредактировано 20.11.2018 21:13 ononim . Предыдущая версия .
Re[8]: TCP все...
От: reversecode google
Дата: 20.11.18 21:22
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


C>>Конкретно QUIC делается с простой целью — чтобы он не сосал, как TCP через middlebox'ы.


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

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

там bbr насколько я помню
который ой как хорош
Re[6]: TCP все...
От: Cyberax Марс  
Дата: 20.11.18 22:51
Оценка:
Здравствуйте, ononim, Вы писали:

O>Набор кастомных драйверов сетевых адаптеров со своими либами, заточенные под конкретное железо, начатая по инициативе интеля vs наколенная реализация транспортного протокола поверх UDP методом "а давайте запилим, и пофиг че получится по бенчмаркам, у нас бабок много"?

Только вот по бенчмаркам получается лучше TCP. А так да, ерунда.
Sapienti sat!
Re[6]: TCP все...
От: chaotic-kotik  
Дата: 21.11.18 06:46
Оценка:
Здравствуйте, ononim, Вы писали:

O>Очень популистское сравнение. Но на стадных девелоперов подействует.


приятно почувствовать себя особенным? :D
Re[15]: TCP все...
От: Ночной Смотрящий Россия  
Дата: 05.12.18 21:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>В WPA3 это исправили, но его пока ещё никто не поддерживает.


Что то мне подсказывает, что его поддержат быстрее, чем QUIC
Re[15]: TCP все...
От: Слава  
Дата: 05.12.18 23:07
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Но не тут-то было! Так как банк — большой и очень умный, то исходящий трафик фильтруется через middlebox, который считает ICMP изобретением дьявола и блокирует его. Тем более, что трафик ещё и на сервера в Калифорнии идёт. Нельзя такого допускать, никак нельзя.

C>Сразу начинают придумываться идеи типа: "А что если одновременно послать один большой пакет, пока мы в фоне посылаем маленькие?". Но от этого middlebox'ам плохеет так, что они вообще соединение разрывают.
C>>>Если есть идеи как это исправить в рамках существующего TCP — добро пожаловать в Гугл на семизначную зарплату.

У меня есть идея, но не техническая, а скорее организационная. Организовать работу так, чтобы пока middlebox'ы не настроят нормально — вообще ничего не работало бы. Благо, у гугла почти что монополия на браузеры. Чтобы с одной стороны безопасников с их middlebox'ами пинали топменеджеры: "какого хрена у меня айпад не показывает видео?", а с другой — какой-нибудь ITU их пинал в духе "неправильно настроенное сетевое оборудование — это уголовное преступление, это раньше мы в сети только котиков смотрели, а теперь от интернета зависит всё. Давайте-давайте, на работу, правила чистить! Вилкой — раз-раз-раз!". Чтобы эти любители всё позапрещать забегали, как при пожаре.
Re[6]: TCP все...
От: Слава  
Дата: 05.12.18 23:12
Оценка:
Здравствуйте, ononim, Вы писали:

C>>https://www.dpdk.org/

C>>Ась?
O>Набор кастомных драйверов сетевых адаптеров со своими либами, заточенные под конкретное железо, начатая по инициативе интеля vs наколенная реализация транспортного протокола поверх UDP методом "а давайте запилим, и пофиг че получится по бенчмаркам, у нас бабок много"?
O>Очень популистское сравнение. Но на стадных девелоперов подействует.

Это очень хорошая вещь. По сути, она даёт приложению монопольный доступ к сетевой карте. Можете рассматривать DPDK как некий новый стандарт, вроде berkley sockets. Ничто не мешает реализовать его поддержку в уже существующих драйверах.
Re[5]: QUIC не все...
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 25.12.18 08:40
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Так уже: https://www.ietf.org/id/draft-ietf-quic-transport-16.txt — будет по плану ратифицирован в следующем году, во время июльской встречи IETF.


16, говорите? Нам пишут:

нет, -17 не будет финализироваться, много багрепортов выползло. До июля тестируем интероп, в июле смотрим. Плюс у меня есть планы всерьёз набросить на вентилятор, так что, если получится, то и в июле не будет финала. Но шансы 50/50.

The God is real, unless declared integer.
Re[3]: TCP все...
От: Mr.Delphist  
Дата: 25.12.18 11:59
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>OSI сдохла уже давно.

Хммм… А мужики-то не знают! Как же она сдохла, неужели фейсбуки с контактами прямо в Ethernet-кадры данные оборачивают?

P.S. Тот факт что 99% девелоперов разрабатывают application-level протоколы, вовсе не значит, что остальных 6 уровней уже более нет в природе.
Re[4]: TCP все...
От: Mr.Delphist  
Дата: 25.12.18 12:04
Оценка:
Здравствуйте, chaotic-kotik, Вы писали:


CK>я имел ввиду recvmmsg/sendmmsg + SO_REUSEPORT, на них можно построить свой QUIC стек на уровне приложения, который не будет нуждаться в ОС для мультеплексирования соединений и context switches и будет многопоточным


А что даст SO_REUSEPORT для UDP на уровне приложения?
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.