История изменений

давай ссылку

Предположу, что речь вот об этом:

https://pastebin.com/RVHfBkuc — код сервера.

https://pastebin.com/xk37uhcS — код клиента.

По поводу кода сервера я задавал Царю вопросы по деталям реализации (Царю про 10к в надежде перевести дискуссию в конструктив (комментарий)), но Царь порвался и внятного ничего не ответил.

Между тем, там есть важный момент: откуда следует, что 10k нитей работают параллельно и одновременно? Я, например, не в курсе, что происходит, если accept для одного и того же серверного сокета параллельно вызывается на нескольких нитях. Возможно, этот accept будет работать как mutex: т.е. когда N нитей одновременно вызовут accept, то все они «заснут», а проснется лишь одна из них при подключении клиента.

Эта единственная проснувшаяся нить быстро вычитает 8 байт, отошлет клиенту 10KiB мусора в ответ (без какого-либо контроля за тем, сколько реально ушло), закроет клиентский сокет и уснет на 10 секунд.

Поскольку вот эти операции чтения и бесконтрольной записи будут происходить очень быстро, то можно предположить, что как только к серверу подключается очередной клиент, то он сразу же обслуживается и отключается. И в реальности активных подключений к серверу может быть не 10k, а всего пара-тройка дестяков (ну сотен). При этом из 10k рабочих нитей в конкретный момент времени лишь малая часть занимается работой, некоторая (большая часть) заблокирована на вызове accept-а и оставшаяся часть (растущая со временем), висит на sleep(10). По сути, при беглом взгляде на царский код, не видно, чтобы 10k нитей действительно бы работали параллельно и действительно бы обслуживали 10k параллельных подключений.

Царская реализация сервера не дает никакой диагностики на этот счет. Ну и царь не представил никаких результатов прогонов своего бенчмарка, так что судить не о чем.

PS. Поскольку часть нитей висит на sleep(10) и эта часть постоянно увеличивается, то кажется, что есть возможность устроить небольшой DDoS царскому серверу: создать больше 10k параллельных подключений (пусть даже с отсылкой этих несчастных 8 байт на сервер) за короткое время (за пару секунд, скажем). По идее, на 10001-ом подключении ответа от царского сервера придется ждать 7-8 секунд, пока первая из нитей выйдет из sleep(10).

давай ссылку

Предположу, что речь вот об этом:

https://pastebin.com/RVHfBkuc — код сервера.

https://pastebin.com/xk37uhcS — код клиента.

По поводу кода сервера я задавал Царю вопросы по деталям реализации (Царю про 10к в надежде перевести дискуссию в конструктив (комментарий)), но Царь порвался и внятного ничего не ответил.

Между тем, там есть важный момент: откуда следует, что 10k нитей работают параллельно и одновременно? Я, например, не в курсе, что происходит, если accept для одного и того же серверного сокета параллельно вызывается на нескольких нитях. Возможно, этот accept будет работать как mutex: т.е. когда N нитей одновременно вызовут accept, то все они «заснут», а проснется лишь одна из них при подключении клиента.

Эта единственная проснувшаяся нить быстро вычитает 8 байт, отошлет клиенту 10KiB мусора в ответ (без какого-либо контроля за тем, сколько реально ушло), закроет клиентский сокет и уснет на 10 секунд.

Поскольку вот операции чтения и бесконтрольной записи будут происходить очень быстро, то можно предположить, что как только к серверу подключается очередной клиент, то он сразу же обслуживается и отключается. И в реальности активных подключений к серверу может быть не 10k, а всего пара-тройка дестяков (ну сотен). При этом из 10k рабочих нитей в конкретный момент времени лишь малая часть занимается работой, некоторая (большая часть) заблокирована на вызове accept-а и оставшаяся часть (растущая со временем), висит на sleep(10). По сути, при беглом взгляде на царский код, не видно, чтобы 10k нитей действительно бы работали параллельно и действительно бы обслуживали 10k параллельных подключений.

Царская реализация сервера не дает никакой диагностики на этот счет. Ну и царь не представил никаких результатов прогонов своего бенчмарка, так что судить не о чем.

PS. Поскольку часть нитей висит на sleep(10) и эта часть постоянно увеличивается, то кажется, что есть возможность устроить небольшой DDoS царскому серверу: создать больше 10k параллельных подключений (пусть даже с отсылкой этих несчастных 8 байт на сервер) за короткое время (за пару секунд, скажем). По идее, на 10001-ом подключении ответа от царского сервера придется ждать 7-8 секунд, пока первая из нитей выйдет из sleep(10).