Марк Брукер (Marc Brooker), инженер из компании Amazon Web Services (AWS), разобрал заблуждения, связанные с повышением эффективности передачи мелких сообщений при использовании...Подробнее: https://www.opennet.me/opennews/art.shtml?num=61145
Наконец-то хоть кто-то не поленился поднять эту тему
Что мешает вставить в ядро одну строчку кода?
Торвальдс
Лол благодаря ему эта строчка вообще существует. А отключать опцию или нет это дело пользователя.
Зачем? Если кому это действительно надо отключают сей алгоритм и давно - "что уже давно делается в таких проектах, как Node.js и curl." Гражданин вещает с позиций AWS, а позиция обычных смертных может быть немного отличаться.
Просто aws хочет ценник за трафик больше получить.
Простите, а за счёт чего? Данные просто будут переданы быстрее, и только. Но объем должен быть тот же
Если вдруг обычному пользователю захочется форсировать данный флаг глобально. Чтобы в игрушках были минимальные задержки, например...
Типичный кээсер. Реальная выгода хоть есть?
А разве игрушки не UDP пользуются для минимализации латентности?
К сожалению, нет.
Правильнее было бы сказать: "Не все".
Unreal Engine - UDP.
Unity - UDP.
Godot - HTTPS поверх TCP (пздц) по дефолту для ленивых. TCP или UDP для всех остальных.
Но нужно учесть тот факт что на Godot игор нет.
Фактически, сказал тоже самое, но в более краткой форме. Разумеется, есть игры которые используют UDP, но встречаются они крайне редко.
Чушь несёшь. Игры в основном используют TCP для согласования и прочей мелочи. И UDP для RT трафика в игре. Если, конечно, речь о играх где важен FPS и задержки. Так было ещё со времён CS
Найдите мне MMORPG с UDP протоколом.
Очень забавное наблюдение. Погуглил. В среднем так: если игра без автотаргета, по факту ближе к шутеру, то UDP. Если просто клацать мышкой (Линейка, вовка, ева и т.д.) то TCP. Ну и плюс всякая медийка (внутриигровые войс чаты) тоже UDP.Например https://valheim.fandom.com/wiki/Dedicated_servers#Networking
любой дистрибутив может сделать это по своему желанию.
если нет то сами себе сделайте.
Уже давно...
Погодите, панове, а что мешает использовать TCP_NODELAY при открытии сокета? Разве не так задумано было? Нужен интерактив? - Тогда используй соотв. опцию при открытии соединения.Для сомневающихся, советую поиграться с SSH и попробовать заоверрайдить умолчальные TCP_NODELAY. Консолька интересной становится.
Консольке от флага приятно не не более того.
В качестве аргумента скажу что консолька часто нормально себя ощущает при RTT 50-150мс, подозреваю что ОС без TCP_NODELAY на столько пакет не задерживает.
> Консольке от флага приятно не не более того.
> В качестве аргумента скажу что консолька часто нормально себя ощущает при RTT
> 50-150мс, подозреваю что ОС без TCP_NODELAY на столько пакет не задерживает.Патчить кривой софт надо, а не менять то, что потенциально может много проблем создать.
>а что мешает использовать TCP_NODELAY при открытии сокета?Тем что не все это знают, а те кто знают те забывают. Признаюсь честно, я делал что то типа прокси-туннеля и запускал VNC через нее и думал что задержки курсора это комп или сеть тормозит. А потом вспомнил про TCP_NODELAY.
Лучше бы имхо было наоборот, флаг TCP_DELAY_LEGACY_FOR_TELNET.
Так оно нужно только для отдельных применений.
У меня вот есть msd - оно стримит IPTV, там свой огромный буффер из которого рассылает клиентам, и от TCP_NODELAY ничего не изменится совсем, потому что у клиента тоже буфера.
Наверное то, что приложению по хорошему неоткуда знать нужно ему использовать этот флаг или нет. Так понимаю, он был актуален во времена медленных каналов, вроде модемных. На них экономия могла иметь смысл, на широкополосных нет. По этому его и выносили в конфиг.
Но теперь модемных каналов не осталось и по идее нет нужды требовать от приложений устанавливать его явно.Вообще это решение выглядит таким себе. По идее механизм управления потоком стоило привязывать к интерфейсу.
> Наверное то, что приложению по хорошему неоткуда знать нужно ему использовать этот
> флаг или нет.А кто об этом должен знать, как не приложение? Вы бредите или это такой юмор?
> Вообще это решение выглядит таким себе. По идее механизм управления потоком стоило
> привязывать к интерфейсу.А... это после воскресенья такое. Бывает.
> А кто об этом должен знать, как не приложение? Вы бредите или
> это такой юмор?Откуда приложению знать (да ещё и на этапе компиляции) в каких условиях его будут использовать? Модемный канал или нет?
> А... это после воскресенья такое. Бывает.
Вы про себя что ли? Ну, просыхайте. Может перечитаете и поймёте.
> Откуда приложению знать (да ещё и на этапе компиляции) в каких условиях
> его будут использовать? Модемный канал или нет?Вы просто не поняли, для чего TCP_NODELAY делался. К ширине канала это имеет очень небольшое отношение. А вот приложение прекрасно знает, что ему нужно больше - интерактив или пропускная способность. Но ты сильно не расстраивайся, не плакай там. Не ты один такой, вон Mozilla (да и Chrome) до сих пор не умеет помечать ToS в пакетах канала данных WebRTC. Багрепортам уже не помню сколько лет.
> какая-то тухлая эскапада на предмет моей некомпетентности
Воспользуйся моим советом выше и поиграйся с SSH. Если они смогли, то что мешает другим?
> А вот приложение прекрасно знает, что ему нужно больше - интерактив или пропускная способность.Вы текст-то новости прочли? "RFC для алгоритма Нейгла принят в 1984 году и он не рассчитан на параметры современных высокоскоростных сетей и серверов в датацентрах, что приводит к возникновению проблем с отзывчивостью." Так откуда приложению знать в современной оно сети работает или нет?
>> какая-то тухлая эскапада на предмет моей некомпетентности
> Воспользуйся моим советом выше и поиграйся с SSH. Если они смогли, то
> что мешает другим?Простите, вы там кого от моего имени процитировали? У меня в посте таких слов нет. Вы ChatGPT, у вас галлюцинации? Если нет и отвечаете кому-то другому - вот идите к нему в ветку и отвечайте.
И что по вашему я должен был добиться "игранием с SSH"? Понимания, что неправильный алгоритм управления может ухудшить работу? Спасибо за гениальное наставление, сам бы я точно до этого не догадался.
> Понимания, что неправильный алгоритм управления может ухудшить работу? Спасибо за гениальное наставление, сам бы я точно до этого не догадался.Наоборот, ты наконец поймёшь, что СТОИТ читать не новости, а RFC... и экспериментировать. Если человек из новости не пишет о том, что ядро предоставляет интерфейс для управления поведением сетевого стека, то он а) некомпетентен или б) ангажирован. Я ставлю на второе. В твоём же случае очевидна первая причина.
Прежде чем продолжить тухлую пикировку, давай определимся с твоим тезисом о том, что приложение "не знает о ширине канала". Имеются ли давно внедрённые алгоритмы, которые позволяют определить эту самую полосу? Имеются ли минимальные требования к работе приложения (я, надеюсь, мы не будем разговаривать о запуске VoIP через 1200 baud packet radio?)?
Потом вернёмся к тому, насколько ты понимаешь, чем и зачем TCP_NODELAY используется сейчас.
А потом мы по пунктикам разберём, где выступивший с инициативой пан слукавил (или соврал). Я очень люблю, когда ссылаются на "старость" RFC без учёта реализаций.
Nagle занимается тем, что буферизует данные, записываемые в TCP-сокет, вместо нерадивых приложений которые делают write(2) по паре байт, чтобы без Nagle-а приводило бы к куче мелких пакетов с пейлоадом в эти самые пары байт.Потому кроме приложений, которые и дергают write(2)-ы, никто и не может знать, нужен Nagle им, потому что написаны они левой пяткой без нормальной буферизации данных, или нет, потому что у программиста есть мозг, и он им подумал о том, что будет происходить с отправляемыми данными на уровне TCP/IP стека.
Хороший такой детектор получился из плюсующих данный комментарий.
Можно вопрос к знатоку Firefox?
Sandbox: seccomp sandbox violation: pid 2247, tid 2250, syscall 441, args 13 140541341901696 32 0 0 8.
[warn] epoll_wait: Function not implemented
Firefox 115.10 esr Gentoo
Решается через
export MOZ_DISABLE_CONTENT_SANDBOX=1
Работает,но 100500 строчек с ошибкой все время бегут друг за другом без остановки в терминале и чтобы остановить закрываю эмулятор терминала.
Может быть можно решить по-нормальному?
Нашел такой вариант без export,но ошибки сыпятся все равно.
about:config
security.sandbox.content.level to 0
> Можно вопрос к знатоку Firefox?
> Sandbox: seccomp sandbox violation: pid 2247, tid 2250, syscall 441, args 13
> 140541341901696 32 0 0 8.
> [warn] epoll_wait: Function not implemented
> Firefox 115.10 esr Gentoo
> Решается через
> export MOZ_DISABLE_CONTENT_SANDBOX=1
> Работает,но 100500 строчек с ошибкой все время бегут друг за другом
> без остановки в терминале и чтобы остановить закрываю эмулятор терминала.
> Может быть можно решить по-нормальному?Знатоки Firefox в Bugzilla. Без шуток, туда лучше сразу иди.
> Даже если размер полезных данных составляет считанные байты, то, как правило, фактически размер отправляемой информации существенно возрастает после применения сериализации, использования API-обвязок в JSON и отправки с использованием TLS-шифрования. Экономия 40 байтов становится не столь актуальной.всё, что нужно знать о современном программизде. адын байт не могут отослать без JSON и TLS.
Без Шизон. Вообще непонятна это стремления в ASCII-сериализацию, есть же и двоичные форматы.
Потому что для отладки текстовых протоколов достаточно обычного отладчика и текстового редактора, а для бинарных нужны парсеры особые.
Для написания текстового кодера достаточно snprintf() а декодера sscanf().
Итого текстовый протокол делается за пол часа и работает сразу, отлаживать можно любой прогой отправляющей текст.
А всякие питонисты у них этот xml/json/yaml чуть не нативно везде напихан, им даже кодить сильно не надо чтобы оно начало по сети бегать.Я не говорю что бинарные протоколы плохие (не все, ИМХО, как и текстовые), просто показал процесс со стороны разработчика.
Скажи спасибо, что уже не XML, а пока всего лишь JSON. Правда, теперь идёт YAML и конца этого идиотизма не проглядывается
Хотя не, ещё не уже, как раз этот долбанутый aws использует у себя в протоколах XML
У XML хотя бы схемы есть. А в джсон все как попало срут.
У жсона тоже можно схему прописать. Да и в xml никто не мешает насрать чем угодно.
Да пофиг же, пожал сверху zlib если не нравится оверхэд и всё.
Какой в этом смысл? Лучше сразу protobuf использовать бинарный.
Щас набегут контуженные безхопасностью и расскажут что без TLS жизни угрожает опасность, и что сериализацию надо делать средствами руста, не важно сколько оверхэда оно накидывает :)
Как два байта переслать, оказывать могут не все.
>Современные распределённые приложения давно не отправляют единичные байты данных, а агрегирование мелких данных обычно реализуется на уровне приложения.Если такие пакеты не отправляются, то и алгоритм Нейгла не гадит. Тогда почему он ноет?
Ответ самого автора, Джона Негла: https://news.ycombinator.com/item?id=10608356
И второй: https://news.ycombinator.com/item?id=34180239
Вы плохой усвоили материал.
Хочешь сам рулить отправкой, используй udp, что собственно и сделал гугл с quic.
В quic пакеты ACK вообще по другому сделаны кстати. Можно сразу на много-много запросов ACK в один пакет запихнуть.
Посмотри, что ли, что такое TCP SACK
Да, и теперь гугол может списать за показ рекламы и сказав: "я тут ваш баннер по юдп послал, услуга оказана".
>используй udpИ огреби кучу проблем в реальном мире например с проксями и файрволлами
> что уже давно делается в таких проектах, как Node.jsтак вот, почему на node.js всё так летает
Последний довод это какой-то вынос мозга, нет слов. Как будто кроме перекладывателей json-ов на свете больше никого нет
Что ещё есть? Давай перечисляй.
Любой алгоритм, где на надежность и гарантия доставки важнее скорости. Но нет, давайте сделаем, как удобнее "прикладникам", а не "сетевикам" и "системщикам". Это как с монгой по умолчанию выставим "0.0.0.0", а кому надо безопасно поставит "127.0.0.1". Напомнить к чему привело?
Тут не идёт речь о "на свете". Речь об AWS.
нет, тут речь о дефолтном конфиге ядра
Он касается всех, не только перекладывателей json'а:> Современные распределённые приложения давно не отправляют единичные байты данных, а агрегирование мелких данных обычно реализуется на уровне приложения.
Если ты дёргаешь ядро на каждый отправляемый байт, то либо ты никогда не слышал про буферизацию, либо тебе действительно _надо_ отправлять по байту, и ты готов терпеть накладные расходы на лишние сисколлы.
В первом случае, тебе следует заняться повышением образованности, и проложить между своим кодом и сисколлами прослойку буферизирующего стрима (в качестве грязного и дешёвого способа можешь использовать fdopen).
Во втором случае, ты сознательно отказываешься от буферизации, и ты будешь выставлять TCP_NODELAY, чтобы ядро не впихивало бы тебе её принудительно, чтобы жертвы производительности, принесённые тобою на алтарь сисколлов, не прошли бы даром.
Это воннаби дед, у него от слов современный, api, json начинается кружится голова и мутнеет перед глазами.
Подход "сделаем всё сами правильно" это отказ от кооперации, когда в ядре за вас уже всё сделали давным давно.
Да, сисколы дорогие относительно буферизации в приложении, но не факт что в приложении получится сделать лучше и что этим вообще стоит заниматся.Идеальная замена алгоритма буферизации, сопоставимая с тем что в ядре, это не просто добавить буфер в приложение, это ещё и таймер, чтобы данные там не залёживались.
А таймер это ещё один сискол...В общем есть случаи когда лучше дать ОС буферизировать и просто задрачивать send() в приложении.
> Идеальная замена алгоритма буферизации, сопоставимая с тем что в ядре, это не просто добавить буфер в приложение, это ещё и таймер, чтобы данные там не залёживались.Идеальная замена алгоритма буферизации, не потребует ничего этого. В ядре генерализованный алгоритм, который ничего не знает о характере генерации данных, и поэтому ориентируется на таймер. Юзерспейс, же, генерирующий данные, может поступать интереснее. Например, если тебе надо отправить http запрос, ты можешь создать буфер в десяток килобайт, и писать запрос туда, чтобы потом одним сисколлом отправить. Если буфер маловат для запроса, скидываешь содержимое в ядро и продолжаешь писать в него. Нет никакой нужды в таймерах. Юзерспейс часто знает, когда важно отправлять данные немедленно по мере появления, когда нет смысла отправлять раньше времени (половину http запроса бессмысленно отправлять пораньше, прежде чем ты вторую дописал), а когда требуется более сложная и менее эффективная схема как в ядре.
Если тебе нужен таймер для буферизации, то тебе уже не повезло с задачей, и имеет смысл остановиться и подумать, а нельзя ли как-нибудь без него.
> А таймер это ещё один сискол...
Попробуй посчитать. Вот представь, что приложение генерирует данные по байту, что временя до следующего байта распределяется по Пуассону. Приложение хотело бы байты отправлять по мере появления, чтобы не терять латенси, но готово отчасти пожертвовать латенси ради срупута. Зная задержку на буферизацию в ядре, попробуй прикинуть при каких лямбдах буферизация в ядре будет выгоднее периодической (10 раз в сек?) обработки SIGALRM, а потом попробуй нафантазировать случай, который реализует такую лямбду, при этом хотя бы отдалённо выглядя реалистично. В этом случае, ведь, надо чтобы требования к задержкам со стороны задачи примерно бы совпадали с тем, что ядро использует. На осмысленность экономии трёх байт трафика, давай забьём, примем её как данность, чтобы не сравнивать яблоки с апельсинами, экономию трафика и латенси.
> В общем есть случаи когда лучше дать ОС буферизировать и просто задрачивать send() в приложении.
Было бы убедительнее, если бы ты привёл пример.
Как минимум при прототипировании не имеет смысла возится вообще с буферизацией у себя.
В остальном для любой задачи где частота вызова не сильно высокая и не будет расти количество таких писаталей.
Какой нить датчик или сериал порт.
SIGALRM - это какое то жуткое легаси, create_timer_fd(), kqueue() - вот современные методы.
И к слову, отключение TCP_NODELAY не отменяет агрегирования. Десять вызовов send() подряд не приведут к отправке 10 TCP-пакетов. Их, разумеется, будет в среднем больше, чем без NODELAY, но не 10.
Я далек от глубокого понимания сетей и возможно не понял что ты имеешь ввиду, но ты же выше сам скинул ссылку на пост того самого Джона Нейгла (имени которого алгоритм) и он там утверждает что таки на каждый write() в сеть даже одного байта будет таки слаться отдельный IP-пакет с +40 байтами служебной информации:"Turning on TCP_NODELAY has similar effects, but can make throughput worse for small writes. If you write a loop which sends just a few bytes (worst case, one byte) to a socket with "write()", and the Nagle algorithm is disabled with TCP_NODELAY, each write becomes one IP packet. This increases traffic by a factor of 40, with IP and TCP headers for each payload."
чего я не догнал, что упустил?
А, сорри. Невнимательно прочитал.после прочтения строчки:
> Десять вызовов send() подряд не приведут к отправке 10 TCP-пакетовподумал что имеется ввиду "их будет меньше" и уже глазами мельком проскочил и неверно прочитал следующую строку:
> Их, разумеется, будет в среднем больше
>> БОЛЬШЕ
При 10 вызовах send/write с малым количеством данных без NODELAY в идеале отправится 1 TCP-пакет, но с NODELAY не факт, что отправится 10 — это зависит от заполненности буфера или других факторов.Подробно не исследовал, у меня была как раз задача отправлять по отдельному пакету на каждый вызов send/write в Linux для TCP-сокета, и я не смог ее решить стандартными средствами юзерспейса.
Агрегацией занимается драйвер сетевого устройства.
Вы большей частью не правы.Вот как во фре:
# grep -rsp "TF_NODELAY" /usr/src/
/usr/src/sys/dev/cxgbe/tom/t4_tom.c: toep->params.nagle = tp->t_flags & TF_NODELAY ? 0 : 1;
/usr/src/sys/dev/cxgbe/tom/t4_tom.c: cp->nagle = tp->t_flags & TF_NODELAY ? 0 : 1;
/usr/src/sys/netinet/tcp_stacks/bbr.c: } else if ((amm < maxseg) && ((tp->t_flags & TF_NODELAY) == 0)) {
/usr/src/sys/netinet/tcp_stacks/bbr.c: ((tp->t_flags & TF_NODELAY) ||
/usr/src/sys/netinet/tcp_stacks/rack.c: (idle || (tp->t_flags & TF_NODELAY)) &&
/usr/src/sys/netinet/tcp_stacks/rack.c: ((tp->t_flags & TF_NODELAY) == 0) &&
/usr/src/sys/netinet/tcp_output.c: (idle || (tp->t_flags & TF_NODELAY)) &&
/usr/src/sys/netinet/tcp_syncache.c: (TF_LRD|TF_NOPUSH|TF_NODELAY);
/usr/src/sys/netinet/tcp_usrreq.c: opt = TF_NODELAY;
/usr/src/sys/netinet/tcp_usrreq.c: optval = tp->t_flags & TF_NODELAY;
/usr/src/sys/netinet/tcp_usrreq.c: if (t_flags & TF_NODELAY) {
/usr/src/sys/netinet/tcp_usrreq.c: db_printf("%sTF_NODELAY", comma ? ", " : "");
/usr/src/sys/netinet/tcp_var.h:#define TF_NODELAY 0x00000004 /* don't delay packets to coalesce */
те только один драйвер сетевух умеет в агрегацию.
очередной один "умный" чувак пытается решить за всех
почему он не рассказал что вырастет нагрузка на сетевые устройства из-за возросшего pps?
потому что на таких сюрпризах амазон веб сервисес зарабатывает бабки. дурить клиентов - основной источник их дохода
Так он отвечает на комбинаторе, зайди поспорь с ним) А общими словами кидать всякий горазд. Ты ведь даже не понял о чем речь в статье, судя по комментам)
В их датацентре pps сетка потянет, а за его пределами - хоть трава не расти.
На чем должна быть сетка, чтобы не потянуть возросшие pps от no_delay?! На dlink des-3526 или распбери пи?
> вырастет нагрузка на сетевые устройства из-за возросшего ppsУстройства младше 15 лет не развалятся, а старше в такие места не ставят. Максимум какому-то помойному оператору с оборудованием с ебея придётся проапгрейдиться, но разве ж это вред?
Да челы видимо цоды видали токмо на картинках.
хорошая новость. Я раньше следил за проектом bufferbloat, так как раз с этими странностями TCP/IP пытались бороться (codel, cake они придумали и протолкнули в ядро). Там очень сложно все, и я через слово все понимал на форуме но было безумно интересно. Основной толчок проекту был тогда когда на какую то конференцию сетевиков приперлась куча народу с вайфаем и никто не мог понять вроде по параметрам все должно было работать надежно и с большим запасом а по факту жуткое лагалово особенно в лайвстримах. Это начали раскручивать, и оказалось что там совсем неочевидные вещи происходят, в том числе и то с чем должен был бороться этот алгоритм Nagle но там настолько сложно все - прямо детективная история с аппаратными очередями пакетов, их разбивка, невозможность контролировать это программно из драйверов, аномальное поведение которое при попытке исправить делает еще хуже (вроде до сих пор не побороли сложности с ECM). Короче, очень здорово что снова пытаются разобраться с этим и не только команда с buffetbloat.
>детективная история с аппаратными очередями пакетовПроприетарные истории с сетевыми карточками - конечно же проблема ядра и его разработчиков.
Это вообще-то очевидно, так как именно им придётся с этим разбираться.
Ну или пусть вешают табличку "ваше оборудование не поддерживается" и идут разрабатывать свободное железо вместо траты сил на кривой вяланд и сустемды.
bufferbloat это примерно как борьба с изменением климата: никто не понимает но всем весело.
Прочитал ваше сообщение и заинтересовался) А вы для каких целей занимаетесь изучением темы с Bufferbloat ? Просто у меня тоже в этой теме кое какие наблюдения есть...
Если это внушение для разработчиков сетевых приложений, не отправляющих по 1 байту, то в принципе нормальный посыл. setsockopt в руки.
Если же хотят в сетевом стеке по умолчанию включенный nodelay, то пусть идут лесом. Если ценой задержек в сети гуляет меньше пакетов, весь мир экономит электричество. Где-то получается обходиться менее производительным оборудованием. Топовые датацентры корпораций - это не весь мир. Даже если в них большая часть передаваемых данных сосредоточена.
> Если ценой задержек в сети гуляет меньше пакетов, весь мир экономит электричество.Расчеты экономии в студию, что ли. Звучит как экономия на спичках.
Звучит как корпоративный буллшит, за который в случае факапа никто отвечать не будет. Присвоить прибыль, обобществить убытки - ваше всё!
> Звучит как корпоративный буллшит, за который в случае факапа никто отвечать не будет. Присвоить прибыль, обобществить убытки - ваше всё!Если это единственная техническая аргументация, на которую ты способен, то я за то чтобы поменять дефолту просто чтобы тебе и дальше жопу рвало.
"отморожу себе уши что бабушке было больно"
> "отморожу себе уши что бабушке было больно"Нет, отморожу ему уши. Я не вижу никаких внятных обоснований заметного увеличения трафика от NODELAY.
Если по-хорошему, то Брукер тоже не привёл никаких расчётов. Прежде чем такое изменение выкатывать в качестве нового дефолта, неплохо было бы оценить последствия.Я лично, думаю, что так будет правильно -- буферизировать надо в юзерспейсе, там где известен характер данных и требования к задержкам, там где буферизацию можно заточить под юзкейс. И предлагаемая стратегия взять и поменять всем дефолты, неплохой способ заставить юзерспейс думать об этом, а не лепить как придётся. Но я к тому, что если требовать расчётов экономии, то требовать их надо от тех, кто агитирует за изменение дефолтов.
> Если по-хорошему, то Брукер тоже не привёл никаких расчётов. Прежде чем такое изменение выкатывать в качестве нового дефолта, неплохо было бы оценить последствия.Latency можно померять, но если ты посмотришь в любые latency-critical приложение, ты увидешь там NODELAY. Чтобы далеко не ходить -- это даже в NGINX дефолт. То есть большая часть HTTP трафика в мире ходит с NODELAY и всем нормально.
> если ты посмотришь в любые latency-critical приложение, ты увидешь там NODELAY.Вот я об этом и говорю. Умозрительные рассуждения на базе голословных утверждений. Но мало того, ты ещё смотришь на ситуацию однобоко и не с того бока. Если изменить дефолты, то проблемой могут стать не столько латенси-критикл приложения, сколько срупут-критикл, которые не используют ноделей. И поэтому интереснее взгляд именно с этой стороны, исследование которое бы оценило как много таких приложений в дикой природе, и как в абсолютных числах может измениться объём мирового трафика.
>> если ты посмотришь в любые latency-critical приложение, ты увидешь там NODELAY.
> Если изменить дефолты, то проблемой могут стать не
> столько латенси-критикл приложения, сколько срупут-критикл, которые не используют ноделей.
> И поэтому интереснее взгляд именно с этой стороны, исследование которое бы
> оценило как много таких приложений в дикой природе, и как в
> абсолютных числах может измениться объём мирового трафика.Оло, NGINX использует NODELAY. Это, считай, 70% мирового трафика. CDN, стриминг и прочее объемное человеческое творчество.
Это только фронты, внутри ДЦ идёт гораздо больший трафик и никакого HTTP там нет. Ну и, конечно, замечательные у тебя рассужедния уровня ~ на 30 % можно забить. Собственно по положительному ответу на вопрос топика можно легко определять проф непригодных
> Это только фронты, внутри ДЦ идёт гораздо больший трафик и никакого HTTP
> там нет.Статья про отключение NODELAY внутри ДЦ и профиты, которые от этого видят люди, работающие в этом ДЦ. Ну и да, в postgres тоже NODELAY.
> Ну и, конечно, замечательные у тебя рассужедния уровня ~
> на 30 % можно забить. Собственно по положительному ответу на вопрос
> топика можно легко определять проф непригодныхЕсли БОЛЬШАЯ часть трафика не вызывает проблем, значит МЕНЬШАЯ часть трафика тоже не вызовет. Это очевидно, хватит отрицать реальность.
Вы упрощаете, сильно упрощаете, реальный мир сложнее.На практике приложение должно на лету уметь делать автотюнинг и менять не только NODELAY но и CC, в зависимости от RTT.
Но приложений таких я не видел, самые лучшие уже умеют NODELAY для listen, но не умеют СС.
> Вы упрощаете, сильно упрощаете, реальный мир сложнее. На практике приложение должно на лету уметь делать автотюнинг и менять не только NODELAY но и CC, в зависимости от RTT.
>Но приложений таких я не видел.Реальный мир и опеннетчики, лол.
Эти люди делают для своего ДЦ свои версии ядер. Вот и пусть там делают что хоят и не лезут с идиотскими предложениями на весь мир.
> Эти люди делают для своего ДЦ свои версии ядер. Вот и пусть
> там делают что хоят и не лезут с идиотскими предложениями на
> весь мир.Это предложение отражает реальность, в которой почти все сетевые приложения, где важно соблюдать задержки, используют NODELAY. То есть это де-факто дефолт, лол. Всем остальным приложениям положить на это все болт, потому что там такой трафик, что хоть побайтово пиши. Останутся два древних приложения, которые нужно будет починить. Все просто, но опеннет как всегда.
Есть некое количество приложений, которые опираются на текущий дефолт. И сколько такого, никто оценивать не собирается. Ну да, лучше поменять поведение по-умолчанию, а потом собирать грабли.
> Есть некое количество приложений, которые опираются на текущий дефолт. И сколько такого, никто оценивать не собирается. Ну да, лучше поменять поведение по-умолчанию, а потом собирать грабли.Вместо этого все новые приложения должны делать костыли, да? :D
> NGINX использует NODELAY. Это, считай, 70% мирового трафика.То есть ты настаиваешь на своём однобоком взгляде? Ну ок, продолжай стоять на своём, я с интересом наблюдаю за этим цирковым трюком.
Тут надо понимать что и почему, а не просто подражать кому то.С одной стороны у nginx почти всегда отправляеся большая пачка данных (и я не думаю что DELAY сработал бы).
С другой надо конкурировать с другими, а конкурируют они по всяким дроческим метрикам, среди которых и задержка.
Экономия должна достигаться не таким способом. Буквально почти все мобильные приложения построены на базе веба, тянут с собой вебдвижок, и весят сотни мегабайт, при функционале максимум на десятки. Только один запуск такого приложения прожигает, наверное, месяцы потерь на эти 40 байт. Веб - вот где сверх избыточность. Веб и мобильные приложения нужно жестко ограничивать, как по памяти, так и по ресурсам CPU и GPU.
Ну раз нужно, то можешь начинать прямо сегодня, прямо сейчас. Засовываешь свой браузер в cgroup с любыми лимитами и дело в шляпе.
> Даже если размер полезных данных составляет считанные байты, то, как правило, фактически размер отправляемой информации существенно возрастает после применения сериализации, использования API-обвязок в JSON и отправки с использованием TLS-шифрования. Экономия 40 байтов становится не столь актуальной.Информации мало, а данных много. Вот на это действительно нужно обратить внимание. А опцию каждый разработчик сам решит - включать её в своём приложении или нет.
1. Кому надо давно сами ставят TCP_NODELAY.2. Есть разные реализации TCP и я сильно сомневаюсь что TCP_NODELAY и "delayed ACK" работает везде именно как описал Марк.
3. Оптимизации зависят от сценария использования, натягиывать всех на TCP_NODELAY не означает сделать всем лучше, кому то определённо поплохеет.
> 1. Кому надо давно сами ставят TCP_NODELAY.А у Вас в велобаджо все еще ставят TCP_NODELAY, а
в веларибо уже давно все могло бы работть и так.> 2. Есть разные реализации TCP и я сильно сомневаюсь что TCP_NODELAY и "delayed ACK" работает везде именно как описал Марк.
А по конкретнее?
> 3. Оптимизации зависят от сценария использования, натягиывать всех на TCP_NODELAY не означает сделать всем лучше, кому то определённо поплохеет.
Кому-то в 1984 году? Непонятно зачем вообще эту фичу надо по умолчанию включать?
Есть как минимум один стёк в венде, два во FreeBSD, вероятно в других BSD и огрызке ещё минимум полтора наберётся, есть юзерспейсные реализации для всяких DPDK/netmap, и есть линуксовый.И вместо мнений анонимов: "ололо, давайте выкиним старьё, мы это не понимаем" я бы лучше послушал мнение разработчиков которые пилят сейчас TCP, как минимум из нетфликса и гугла, они должны быть глубоко в теме и иметь адекватную экспертизу.
Кто такой Марк и насколько он больше в теме по сравнению с местными коментаторами и мной - я не знаю.
Своей экспертизы у меня нет, есть только понимание что современный TCP стёк очень сложный и учитывает очень много всего.
У того же RACK крутилок наверное более 150, а там ещё рядом крутилки СС, и крутилки от самой ОС, и это всё вместе очень не тривиально взаимодействует.И даже если мнение нетфликса и гугла совпадёт с мнением Марка это будет означать что рекомендация годная для серверов/раздачи, но не факт что клиенту оно надо.
> И вместо мнений анонимов: "ололо, давайте выкиним старьё, мы это не понимаем"
> я бы лучше послушал мнение разработчиков которые пилят сейчас TCP, как
> минимум из нетфликса и гугла, они должны быть глубоко в теме
> и иметь адекватную экспертизу.Это ведет к помойным интерфейсам, которыми нельзя пользоваться без книжек и best practices.
Иногда нет простых и хороших решений для сложных комплексных проблем.
Книжки нужны тем кто считает что в его ситуации дефолты не оптимальны.
> Иногда нет простых и хороших решений для сложных комплексных проблем.
> Книжки нужны тем кто считает что в его ситуации дефолты не оптимальны.Как мы тут выяснили, дефолты неадекватны почти всем современным применениям.
Это вы где то для себя выяснили, но лучше дефолтов от вас как то ничего не видно.
Сысоев хотя бы в 2007 описывал как, что и для чего тюнить.
> Это вы где то для себя выяснили, но лучше дефолтов от вас
> как то ничего не видно.
> Сысоев хотя бы в 2007 описывал как, что и для чего тюнить.У нас есть всратые дефолты, люди предлагают сделать их нормальными. Все, отставить истерику, идите защищайте скрепы в другом месте.
Аноним Марк, все достижения которого это работа на амазон и ведение бложика написал у себя в бложике что есть какая то старая опция которая работает с другой опцией непонятно как для него и давайте её выключим.
Никаких замеров он не произвёл, даже в домашней локалке, даже с виртуалками на локалхосте.Я не знаю что там у вас за дефолты, меня большая часть дефолтов вполне устраивает, часть от того что я крутил была по рекомендациям Сысоева, человека с большим практическим опытом в этом вопросе и с обоснованиями каждого параметра.
> Я не знаю что там у вас за дефолты, меня большая часть
> дефолтов вполне устраивает, часть от того что я крутил была по
> рекомендациям Сысоева, человека с большим практическим опытом в этом вопросе и
> с обоснованиями каждого параметра.Кого волнует что тебя устраивает? Кто ты такой-то вообще? Весь полезный софт использует NODELAY по умолчанию, поэтому этот дефолт можно менять.
Офигенный уровень аргументации, идите, меняйте :)
А зачем вам менять если у вас весь софт и так это включает?
> А зачем вам менять если у вас весь софт и так это включает?Чтобы новый софт перестал заниматься кручением ручек. Чем меньше нужно крутить, тем лучше. Это тебе тоже объяснять придется?
>помойным интерфейсам, которыми нельзя пользоваться без книжек и best practicesКнижки читать и best practices разбирать - это-ж какая нагрузка на мозги.
> Книжки читать и best practices разбирать - это-ж какая нагрузка на мозги.Конечно. Приходишь ты в гости, зашел в туалет. Нажимаешь кнопку слива и тут внезапно унитаз начинает квартиру говном заливать. Ты выбегаешь в панике, а хозяева говорят: ну ты чо надо было инструкцию читать это кнопка фонтанирования говном, чтобы слив работал надо переключить унитаз в правильный режим специальной педалью за бачком.
Вот примерно так это выглядит, если переносить на реальность. Good defaults matter, очевидные вещи должны делаться очевидным способом. Если в большинстве случаев Нагль это неочевидная история, которая только все портит, ему не место в дефолтах.
> И вместо мнений анонимов: "ололо, давайте выкиним старьё, мы это не понимаем" я бы лучше послушал мнение разработчиковМнение анонимов имеет право на существование. Характер задач выполняемых tcp меняется, и исторические наслоения легаси становятся иррелевантными. Keep It Simple, Stupid, выкидывай всё, что не выглядит строго необходимым, потому что иначе все эти протоколы под своим весом обвалятся.
Во фре вообще нет крутилки глобально включающей TCP_NODELAY для всех сокетов.
Видимо оно нафиг не надо.
> ... использования API-обвязок в JSON и отправки ...Всё так: сколько там переизбыток на передаче описания структуры данных через обвязку. Но зато проще войти в IT. Но - недостатки потом всюду.
А в венде можно активировать TCP_NODELAY по умолчанию для всех соединений через реестр. А в линуксе как это сделоть, а?
Его текст заслуживает отдельно потраченного против него времени. Там если пройтись с CTRL+C по тексту, много раз будет "проблема во всех вокруг, но не из-за меня".Есть: периодический дебаг отклика приложений.
Хочет: давайте перевернем все наоброт!Но почему-то он не идет к авторам программ (своих же амазоновских микросервисов? Кто же еще будет 0.5мс отклик иметь) и не просит их включить издавна рабочий флаг.
Да, программы чаще всего отправляют большие пакеты, а не по байту. А ещё программы ничего не знают о фактическом MTU, поэтому (и только с TCP, не UDP!) единственный способ не терять в оверхеде -- дать системе самой разбивать поток данных на TCP пакеты. Особенно с pMTUd в IPv6 это должно работать на 100%.
Почему сразу NODELAY? Может стоит изменить значения таймера, из-за которого задерживается? Либо эвристика в этом месте, либо эвристика в плане автоматического включения NODELAY.
В конце он пишет, мол, "когда я write(), то оно должно [отсылаться]". Нет, мой дорогой, по семантике надо flush!
Ненаучный подход, подискутировать можно и нужно, но не с его статьи в качестве вводной. Кроме себя ничего не видит.
в чём заключается nodelay если оно приостонавливает отправку?)
> в чём заключается nodelay если оно приостонавливает отправку?)Наоборот, TCP_NODELAY отключает приостановку отправки. Приостановка нужна, чтобы вместо 1000 пакетов с 1 байтом данных в каждом и 40 байтов заголовков отправить один пакет и сэкономить 40К на сетевых заголовках.