Ооок

я не про tcp, с ним-то все в моем понимании неплохо. я скорее про легаси типа ipv4, stp, ethernet, которое было собрано в условиях ограниченных ресурсов и так вышло, что повсеместно используется до сих пор

> Some of these can be solved, by either moving QUIC into the kernel, or by using a DPDK-like userspace networking solution. However, the lack of TSO/LRO even by itself is a killer for performance.

Ну и там все описано почему.

tcp без tso/lro тоже трмоз

https://github.com/nebula-chat коллеги подсказали сервер для телеграма

Главное телеграм сли не юзать

Убожество какое-то

это из серии почему сервак с 256 ГБ памяти не может нагрузить 40 Гбит/с интерфейс

https://github.com/nebula-chat/telegramd
read only и документация на китайском

т.е. quic не жрет больше cpu потому что он в юзерленде и неоптимальный?

Having written the FreeBSD kernel TLS, I can assure you that there is no copy. Data is brought into the kernel via DMA from storage into a page in the VM page cache. When the IO is done, it is then encrypted into an connection-private page. That page is then sent and DMA'ed on the network adapter. So we have in the kernel tls case:

 - memory DMA to kernel mem from storage.
 - memory READ from kernel mem to read plaintext for crypto
 - memory write to another chunk of kernel mem to write encrypted data
 - memory DMA from kernel mem to NIC

In the case where the NIC supports inline TLS offload, the middle 2 steps are skipped, and it devolves to essentially the unencrypted case.

For QUIC you have:

 - memory DMA to kernel mem from storage
 - memory read from kernel mem via mmap
 - memory write to userspace mem to write encrypted data
 - memory read from userspace mem to copy to kernel
 - memory write to kernel mem
 - memory DMA from kernel mem to NIC

So you go from 3 "copies" to 4 "copies", which increases memory bandwidth demands by 33%.

Right now, we can just barely serve 100g from a Xeon-D because Intel limited the memory bandwidth to DDR4-2400. At an effective bandwidth limit of 60GB/sec, that's on the edge of being able to handle the kernel TLS data path. So even if everything else about QUIC was free, this extra memory copy from userspace would cut bandwidth by a third.

ну и tso/lro да

Там речь про неэластичный трафик. И, опять же, ничего про надёжную доставку. Там про дроп неактуального трафика вместо попытки доставить потерянные пакеты до последнего (и ясен пень последнее окажется медленнее).

и архивирован, https://github.com/nebula-chat/chatengine

Не глупо. Во-первых есть суды, во-вторых "мой любимый сайт не работает, пойду в другой браузер"

Если тот же фейсбук упрется рогом, вряд ли они прям протокол отключат. Или те же банки

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

Но, они могут выпилить только то, что большинство пользователей не особо заметит. Тот же http/1 вряд ли

банки или скажут клиентам использовать ie6 или будут только хром поддерживать