https://blog.cloudflare.com/encrypt-that-sni-firefox-edition/

С одной стороны — дело хорошее, а с другой — как же эти костыли надоели. Как и централизованный DNS.

А чем централизация тебе вредит, если что они нынче её только повышают, загоняя всех на "истино безопасные" ресолверы

А чем централизация тебе вредит, если что они нынче её только повышают, загоняя всех на "истино безопасные" ресолверы

Вот я именно эту централизацию и имею ввиду. Google тоже начинал как Don't be Evil. В скатлися в Майкрософт-95 в квадрате.

Теперь мы верим cloudfare? Ага-ага.

Один Сайт (фейсбук) Один Ресолвер (Клаудфаре) Один ээээ…

Если ты не платишь за услугу, то ты — товар

тут возникает неприятный момент, вот со всей этой "безопасностью" просто необходимо кому то верить

если будет подпись то верить можно всем

С одной стороны — дело хорошее, а с другой — как же эти костыли надоели. Как и централизованный DNS.

костыли? ты про DoH?

костыли? ты про DoH?

И про DoH и про очередное расширение монструозного TLS

И про связь ключей для ESNI с DNS'ом

Где это костыли с обеих сторон

есть куда более забавная перспектива, когда quic стандартизируют и можно будет DoH гонять поверх quic

А уж это будет вообще гуглопиздец, как HTTP/2

если будет подпись то верить можно всем

https://www.youtube.com/watch?v=TrxPifYjaSY

есть куда более забавная перспектива, когда quic стандартизируют и можно будет DoH гонять поверх quic

https://66.media.tumblr.com/eef2bc408f5da913eee54d30a29f7904/tumblr_pgng27mgDw1s9iq8zo1_500.jpg

Я понимаю, что без ядерной войны с этим ничего не сделать — я достаточно старый что бы понимать важность обратной совместимости, я сам на x86 сижу, чо уж там. Но смотреть на это грустно с инженерной точки зрения. Потому что если подойти с умом — ну, можно сделать стек протоколов, который будет решать все накопившиеся с 1992 года (а с учётом DNS с 1987), при этом будет верефицирован с криптографической точки зрения и его исходный код будет занимать раз в 100 (если не в 1000) меньше кода, чем сейчас . Но, увы, увы.

Wureguard держит кто в проде?

вчерась же страдали тут

Я понимаю, что без ядерной войны с этим ничего не сделать — я достаточно старый что бы понимать важность обратной совместимости, я сам на x86 сижу, чо уж там. Но смотреть на это грустно с инженерной точки зрения. Потому что если подойти с умом — ну, можно сделать стек протоколов, который будет решать все накопившиеся с 1992 года (а с учётом DNS с 1987), при этом будет верефицирован с криптографической точки зрения и его исходный код будет занимать раз в 100 (если не в 1000) меньше кода, чем сейчас . Но, увы, увы.

звучит как фантастика :)

звучит как фантастика :)

Я надеюсь, что как фантастика (не хочу ядерной войны), но помечтать-то можно!

Wureguard держит кто в проде?

С его реализацией на go без релиза? На проде? У меня он запускается 1 раз из 5.

помечтать, это да, это за всегда приятно

Особенно в пятницу

У меня все работает на луниксе с первого раза.

На BSD не проверял пока

С его реализацией на go без релиза? На проде? У меня он запускается 1 раз из 5.

Ты так говоришь, будто на го сейчас мало чего в проде)

Ты так говоришь, будто на го сейчас мало чего в проде)

ну, не важно даже что на го, а то, что в юзерленде.

Я надеюсь, что как фантастика (не хочу ядерной войны), но помечтать-то можно!

ну мечтаний у меня тоже много. например, хочу что-то вроде network channels, когда приложение сообщает ядру набор фильтров(udp/53 например), а весь стек уже в приложении живет.

Ты так говоришь, будто на го сейчас мало чего в проде)

и то, что релиза нет, и даже ядерная линуксовая версия — бета максимум, а эта на го — вообще преальфа

У меня все работает на луниксе с первого раза.

а толку? на андроиде гошный вариант, например.

потому проще взять старый добрый ipsec

там хотя бы аппаратное шифрование

У меня все работает на луниксе с первого раза.

на линуксе эталонная реализация, это понятно. Хотя по моим замерам айписек с аесом на железе с аесом всё равно быстрее чем его чача с поли.

Т.е. рассказы про то, какие они быстрые — ну може. на микроконтроллерах и быстрые, а сейчас аппаратный аес на любом телефоне есть

Т.е. рассказы про то, какие они быстрые — ну може. на микроконтроллерах и быстрые, а сейчас аппаратный аес на любом телефоне есть

не только aes, но и sha

на линуксе эталонная реализация, это понятно. Хотя по моим замерам айписек с аесом на железе с аесом всё равно быстрее чем его чача с поли.

У них на сайте бенч обратное говорит )

не только aes, но и sha

aes-gcm не требует sha

У них на сайте бенч обратное говорит )

ну, понимаешь, совсем честное сравнение мне не провести, потому что ядерной реализации у нас пока нет. Но я сравнивал на одном железе aes-256-gcm и chacha20-poly1305 в openssl и там всё было совершенно однозначно.

Понял, спасибо!

Может на трёхгигагерцовом зионе с avx2 будет по другому, а когда железка послабее — аппаратное ускорение заруливает

померять на своём железе - дело 5 минут

Но, да, повозившись с айписеком, я понимаю привлекательность вайргарда

Ггг, я об этом же

но, увы, пока он эффективен только на линуксе. В юзерленде он точно не лучше опенвпна

все скоростные приемущества съест граница ядро-юзерленд

все скоростные приемущества съест граница ядро-юзерленд

потому что tun/tap - страшное уёбище

да простите меня за лексику

потому что tun/tap - страшное уёбище

как тут уже обсуждалось, на современных скоростях и pps'ах все старые api такие

хм, как бы мне померять pps, кстати...

А что за фигня с top -SH? CPU: 0.0% user, 0.0% nice, 50.0% system, 0.0% interrupt, 50.0% idle PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 10 root 155 ki31 0 256K RUN 1 750:33 99.63% idle{idle: cpu1} 3179 lev 20 0 13M 3724K CPU1 1 0:00 0.17% top 0 root -76 - 0 2816K - 1 0:27 0.08% kernel{if_config_tqg_0} 11 root -60 - 0 1664K WAIT 1 0:22 0.07% intr{swi4: clock (0)} 3169 lev 20 0 17M 7740K select 1 0:00 0.02% sshd Где тот системнй процесс или тред, что жрёт одно ядро (там их всего 2)?!

Это когда роутится UDP. Когда TCP Всё хорошо — видны заняты делом треды сетевой карты

Пойду в current@ писать

И вообще при роутинге UDP, даже если 100500 потоков, НЕИЗВЕСТНО ЧТО жрёт одно ядро. А при TCP — видно, что жрёт, и жрутся оба ядра.

роутингу в общем случае пофиг что он роутит, TCP или UDP. Это важно только сетевой карте, т.к. она может на разные очереди положить пакет в зависимости от того как хеш посчитает

роутингу в общем случае пофиг что он роутит, TCP или UDP. Это важно только сетевой карте, т.к. она может на разные очереди положить пакет в зависимости от того как хеш посчитает

Вот я и удивляюсь — я же понимаю, что всё равно. Если UDP пакетами по 8 килобайт (там везде Jumbo, фрагментации нет) то видны 2 потока сетевой карты (каждый меньше одного ядра) и всё красиво и понятно. Если UDP пакетами по килобайту, то что-то, непонятно что, жрёт ровно одно ядро и упирается в него

Загадка

Особенно мне нравится как вообще не в списке потоков ни одного который бы жрал процссор, но процессор сожран

И когда пакеты больше кушают оба ядра, а когда маленькие — одно, даже если используется много портов

top -HSIzts1

у меня вот такой alias

я только -HS

Ща этот попробую

там видно какой irq будет жрать

там видно какой irq будет жрать

а нифига CPU: 0.4% user, 0.0% nice, 50.0% system, 0.0% interrupt, 49.6% idle Mem: 4164K Active, 15M Inact, 198M Wired, 20M Buf, 3716M Free Swap: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 0 root -76 - 0 2816K - 1 0:08 0.29% kernel{if_io_tqg_1} 0 root -76 - 0 2816K - 1 0:28 0.08% kernel{if_config_tqg_0} 11 root -60 - 0 1664K WAIT 1 0:22 0.08% intr{swi4: clock (0)} 3169 lev 20 0 17M 7740K select 1 0:00 0.02% sshd 698 root 20 0 18M 18M select 1 0:03 0.01% ntpd{ntpd} 6 root -16 - 0 128K - 1 0:02 0.01% rand_harvestq 1629 mailnull 20 0 15M 6056K nanslp 1 0:00 0.01% dma 16 root -16 - 0 384K psleep 1 0:02 0.00% pagedaemon{dom0} 18 root -16 - 0 384K qsleep 1 0:01 0.00% bufdaemon{bufdaemon} 14 root -68 - 0 3200K - 1 0:00 0.00% usb{usbus0} 19 root 16 - 0 128K syncer 1 0:01 0.00% syncer 14 root -68 - 0 3200K - 1 0:00 0.00% usb{usbus1} 795 root -16 - 0 128K nfscl 1 0:00 0.00% nfscl 14 root -68 - 0 3200K - 1 0:00 0.00% usb{usbus3} 14 root -68 - 0 3200K - 1 0:00 0.00% usb{usbus2} 754 root 52 0 10M 2696K rpcsvc 1 0:00 0.00% nfscbd{nfscbd: master} 20 root -16 - 0 128K vlruwt 1 0:00 0.00% vnlru 16 root -16 - 0 384K umarcl 1 0:00 0.00% pagedaemon{uma} 18 root -16 - 0 384K - 1 0:00 0.00% bufdaemon{bufspacedaemon-1} 18 root -16 - 0 384K - 1 0:00 0.00% bufdaemon{bufspacedaemon-0}

А вот толсыте пакеты и вытягивается wire speed: CPU: 0.0% user, 0.0% nice, 28.3% system, 0.0% interrupt, 71.7% idle Mem: 4136K Active, 15M Inact, 198M Wired, 20M Buf, 3716M Free Swap: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 0 root -76 - 0 2816K CPU0 0 4:44 47.99% kernel{if_io_tqg_0} 11 root -60 - 0 1664K WAIT 1 0:22 0.10% intr{swi4: clock (0)} 0 root -76 - 0 2816K - 1 0:28 0.09% kernel{if_config_tqg_0} 3169 lev 20 0 17M 7740K select 1 0:00 0.02% sshd 6 root -16 - 0 128K - 0 0:02 0.01% rand_harvestq

Всё видно, куда ушло

http://paste.org.ru/?gnr16x

Может в карренте сломали?

Там же переделывали top

На 11.2 У менять есть intr

а тут — нет

кстати при своих тестах не пробовал крутить kern.random.harvest? )

оно может заметно влиять

не, не пробовал!

Точнеее тут есть intr, но только clock...

Так. А сейчас показывает 0 root -76 - 0 2816K CPU0 0 5:59 69.33% kernel{if_io_tqg_0} Бред какой-то. А. Понял. А если хоть чуть-чуть не полностью ядро занято, то это видно

кстати при своих тестах не пробовал крутить kern.random.harvest? )

советуешь вынести оттуда всё, что про сеть?

ну вон Оливер 351 использует

убрать INTERRUP, NET_NG и NET_ETHER...

попробую

Не, пофиг на PPS

А от чего у интела зависит раскладка по потокам? От маков только, от айпишников и портов нет?

обычно как раз от адресов и портов зависит

поэтому и придумали GRE over UDP, чтобы можно было раскладывать удобнее трафик

вне зависимости от того какая карта

тогда странно что 32 потока udp на 32 порта разных (но пара хостов одна) грузит одно ядро

может у тебя одна очередь :)

может у тебя одна очередь :)

обижаешь! Хотя... Хм, ща, доеду до работы и посмотрю

Не, ну очередей — как ядер, 2 dev.em.0.queue_rx_1.rx_irq: 0 dev.em.0.queue_rx_0.rx_irq: 0 dev.em.0.queue_tx_1.tx_irq: 0 dev.em.0.queue_tx_0.tx_irq: 0

Я понимаю, что без ядерной войны с этим ничего не сделать — я достаточно старый что бы понимать важность обратной совместимости, я сам на x86 сижу, чо уж там. Но смотреть на это грустно с инженерной точки зрения. Потому что если подойти с умом — ну, можно сделать стек протоколов, который будет решать все накопившиеся с 1992 года (а с учётом DNS с 1987), при этом будет верефицирован с криптографической точки зрения и его исходный код будет занимать раз в 100 (если не в 1000) меньше кода, чем сейчас . Но, увы, увы.

не переживай, это более реально ) хотя, конечно, угасать веб будет еще десятилетия после перелома

не переживай, это более реально ) хотя, конечно, угасать веб будет еще десятилетия после перелома

Ну посмотри на x86. ВСЕ знают, что он — говно. Intel тоже знает, они не идиоты. Они делают ИДЕАЛЬНЫЕ RISC-ядра, а потом сверху бахают x86 декодер, трансалятор и прочую ересь, которая есть и транзисторы и производительность. Думаешь, они, с инженерной точки зрения, рады это сделать?

Сомневаюсь

Но делают. Потому что иначе никто не купит даже у Intel

Вот так и тут.

ничо-ничо, вот свалим капитализм

и эта проблема станет решаема

но, впрочем, с этим лучше в другой канальчик пойти :)

ничо-ничо, вот свалим капитализм

ХАХАХАХАХА. Не при нашей жизни. Ну или, опять же, после ядерной войны