Здравствуйте, chaotic-kotik, Вы писали:
CK>Вот так прогресс делает некоторые специализации менее нужными. Вот раньше как было, ходил HTTP трафик по TCP, люди писали TCP сервера поверх стека ОС, преодолевали проблемы оного стека ОС (проблема 10К), использовали epoll и windows completion ports. Но QUIC работает поверх UDP, большая часть протокола в userspace, сейчас у UDP нет таких проблем как у TCP,
И каким же образом этот вывод получается из сказанного ранее?
Переход на UDP магически отменяет необходимость делать ожидание на сокетах?
CK> ОС умеет через recvmsg обрабатывать миллионы UDP пакетов в секунду,
А для TCP, значит, не умела? О какой ОС речь-то?
CK> поэтому нет проблемы 10К.
Здравствуйте, netch80, Вы писали:
N>И каким же образом этот вывод получается из сказанного ранее? N>Переход на UDP магически отменяет необходимость делать ожидание на сокетах?
я имел ввиду recvmmsg/sendmmsg + SO_REUSEPORT, на них можно построить свой QUIC стек на уровне приложения, который не будет нуждаться в ОС для мультеплексирования соединений и context switches и будет многопоточным
Здравствуйте, chaotic-kotik, Вы писали:
CK>это решается https, иначе ты можешь просто не знать, что это товой оператор так сделал, скажем на мегафоне тебе могут огромный поупап баннер на сайте показать, который на самом деле не владелец сайта туда поставил, а мегафон CK>ну и не скажешь же ты своим пользователям менять симкарты?
Да, это проблема пользователей. Без навязанного https этот баннер у них будет на большинстве сайтов, и они сами разберутся с провайдером.
Ну а твой пример с мегафоном некорректен: это у него было давно, и у малой части пользователей, сейчас про такое уже не слышно. Сейчас если кто-то где-то и балуется подобным, то это мизерная часть аудитории.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, chaotic-kotik, Вы писали:
N>>И каким же образом этот вывод получается из сказанного ранее? N>>Переход на UDP магически отменяет необходимость делать ожидание на сокетах? CK>я имел ввиду recvmmsg/sendmmsg + SO_REUSEPORT,
Ага, тут вторая 'm' принципиальна.
CK> на них можно построить свой QUIC стек на уровне приложения, который не будет нуждаться в ОС для мультеплексирования соединений и context switches и будет многопоточным
Для сервера, да, в тему. Только для клиента это не очень полезно. Использовать один и тот же сокет для нескольких соединений с одним сервером — очевидный конфликт с правилами идентификации соединений, не сработает. Использовать его с разными серверами — значит, что слой IO дальше будет разбрасывать эти данные между разными сущностями (как вкладки в браузере) — тоже странное решение, мягко говоря.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Вот так прогресс делает некоторые специализации менее нужными. Вот раньше как было, ходил HTTP трафик по TCP, люди писали TCP сервера поверх стека ОС, преодолевали проблемы оного стека ОС (проблема 10К), использовали epoll и windows completion ports. Но QUIC работает поверх UDP, большая часть протокола в userspace, сейчас у UDP нет таких проблем как у TCP, ОС умеет через recvmsg обрабатывать миллионы UDP пакетов в секунду, поэтому нет проблемы 10К.
Проблема 10K не решается сама собой от переноса соединений в user space.
Pzz>Проблема 10K не решается сама собой от переноса соединений в user space.
Ну как же. Ведь тцп стек операционки писали криворукие старперы, а модные девелоперы быстро эти пакетики разрулят на питончике, в 100500 раз быстрее. А если будет тормозить на питончике — напишут на го, вот тогда уж точно все залетает. А если у кого все еще не залетает, то те могут эээ.. заташить этот клубок макарон* в kernel-space.
*
Новый паттерн архитектуры от гугла:
Как много веселых ребят, и все делают велосипед...
CK>>это решается https, иначе ты можешь просто не знать, что это товой оператор так сделал, скажем на мегафоне тебе могут огромный поупап баннер на сайте показать, который на самом деле не владелец сайта туда поставил, а мегафон CK>>ну и не скажешь же ты своим пользователям менять симкарты?
Ops>Да, это проблема пользователей. Без навязанного https этот баннер у них будет на большинстве сайтов, и они сами разберутся с провайдером. Ops>Ну а твой пример с мегафоном некорректен: это у него было давно, и у малой части пользователей, сейчас про такое уже не слышно. Сейчас если кто-то где-то и балуется подобным, то это мизерная часть аудитории.
Все уже давно поняли, что ты не можешь и не хочешь решать проблему подмены трафика пользователя провайдером (для этого надо всего лишь настроить https на своих сайтах и сделать автоматическое обновление сертификатов LetsEncrypt). И поэтому рассказываешь, что она не актуальна (касается мизерной части и вообще давно такого не было), перекладываешь ее решение на своих пользователей (пусть поменяют сим карты и перейдут на другого провайдера), а ответственность на Гугл (теперь всем известно, откуда твой геморрой).
Здравствуйте, ononim, Вы писали:
Pzz>>Проблема 10K не решается сама собой от переноса соединений в user space. O>Ну как же. Ведь тцп стек операционки писали криворукие старперы, а модные девелоперы быстро эти пакетики разрулят на питончике, в 100500 раз быстрее. А если будет тормозить на питончике — напишут на го, вот тогда уж точно все залетает. https://www.dpdk.org/
O>>Ну как же. Ведь тцп стек операционки писали криворукие старперы, а модные девелоперы быстро эти пакетики разрулят на питончике, в 100500 раз быстрее. А если будет тормозить на питончике — напишут на го, вот тогда уж точно все залетает. C>https://www.dpdk.org/ C>Ась?
Набор кастомных драйверов сетевых адаптеров со своими либами, заточенные под конкретное железо, начатая по инициативе интеля vs наколенная реализация транспортного протокола поверх UDP методом "а давайте запилим, и пофиг че получится по бенчмаркам, у нас бабок много"?
Очень популистское сравнение. Но на стадных девелоперов подействует.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Cyberax, Вы писали:
C>>Конкретно QUIC делается с простой целью — чтобы он не сосал, как TCP через middlebox'ы.
CC>Что то мне кажется что в реале он как раз будет сосать что тот пылесос. CC>Потому что шторм UDP запросов говномиддлбоксы переваривают плохо.
Здравствуйте, ononim, Вы писали:
O>Набор кастомных драйверов сетевых адаптеров со своими либами, заточенные под конкретное железо, начатая по инициативе интеля vs наколенная реализация транспортного протокола поверх UDP методом "а давайте запилим, и пофиг че получится по бенчмаркам, у нас бабок много"?
Только вот по бенчмаркам получается лучше TCP. А так да, ерунда.
Здравствуйте, Cyberax, Вы писали:
C>Но не тут-то было! Так как банк — большой и очень умный, то исходящий трафик фильтруется через middlebox, который считает ICMP изобретением дьявола и блокирует его. Тем более, что трафик ещё и на сервера в Калифорнии идёт. Нельзя такого допускать, никак нельзя. C>Сразу начинают придумываться идеи типа: "А что если одновременно послать один большой пакет, пока мы в фоне посылаем маленькие?". Но от этого middlebox'ам плохеет так, что они вообще соединение разрывают. C>>>Если есть идеи как это исправить в рамках существующего TCP — добро пожаловать в Гугл на семизначную зарплату.
У меня есть идея, но не техническая, а скорее организационная. Организовать работу так, чтобы пока middlebox'ы не настроят нормально — вообще ничего не работало бы. Благо, у гугла почти что монополия на браузеры. Чтобы с одной стороны безопасников с их middlebox'ами пинали топменеджеры: "какого хрена у меня айпад не показывает видео?", а с другой — какой-нибудь ITU их пинал в духе "неправильно настроенное сетевое оборудование — это уголовное преступление, это раньше мы в сети только котиков смотрели, а теперь от интернета зависит всё. Давайте-давайте, на работу, правила чистить! Вилкой — раз-раз-раз!". Чтобы эти любители всё позапрещать забегали, как при пожаре.
Здравствуйте, ononim, Вы писали:
C>>https://www.dpdk.org/ C>>Ась? O>Набор кастомных драйверов сетевых адаптеров со своими либами, заточенные под конкретное железо, начатая по инициативе интеля vs наколенная реализация транспортного протокола поверх UDP методом "а давайте запилим, и пофиг че получится по бенчмаркам, у нас бабок много"? O>Очень популистское сравнение. Но на стадных девелоперов подействует.
Это очень хорошая вещь. По сути, она даёт приложению монопольный доступ к сетевой карте. Можете рассматривать DPDK как некий новый стандарт, вроде berkley sockets. Ничто не мешает реализовать его поддержку в уже существующих драйверах.
нет, -17 не будет финализироваться, много багрепортов выползло. До июля тестируем интероп, в июле смотрим. Плюс у меня есть планы всерьёз набросить на вентилятор, так что, если получится, то и в июле не будет финала. Но шансы 50/50.
Здравствуйте, Cyberax, Вы писали:
C>OSI сдохла уже давно.
Хммм… А мужики-то не знают! Как же она сдохла, неужели фейсбуки с контактами прямо в Ethernet-кадры данные оборачивают?
P.S. Тот факт что 99% девелоперов разрабатывают application-level протоколы, вовсе не значит, что остальных 6 уровней уже более нет в природе.
CK>я имел ввиду recvmmsg/sendmmsg + SO_REUSEPORT, на них можно построить свой QUIC стек на уровне приложения, который не будет нуждаться в ОС для мультеплексирования соединений и context switches и будет многопоточным
А что даст SO_REUSEPORT для UDP на уровне приложения?
