The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Предложение по включению режима TCP_NODELAY по умолчанию"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от opennews (??), 10-Май-24, 09:18 
Марк Брукер (Marc Brooker), инженер из компании Amazon Web Services (AWS), разобрал заблуждения, связанные с повышением эффективности передачи мелких сообщений при  использовании...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61145

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Предложение по включению режима TCP_NODELAY по умолчанию"  +20 +/
Сообщение от Аноним (1), 10-Май-24, 09:18 
Наконец-то хоть кто-то не поленился поднять эту тему
Ответить | Правка | Наверх | Cообщить модератору

2. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (2), 10-Май-24, 09:24 
Что мешает вставить в ядро одну строчку кода?
Ответить | Правка | Наверх | Cообщить модератору

3. "Предложение по включению режима TCP_NODELAY по умолчанию"  +8 +/
Сообщение от An (??), 10-Май-24, 09:32 
Торвальдс
Ответить | Правка | Наверх | Cообщить модератору

6. "Предложение по включению режима TCP_NODELAY по умолчанию"  +7 +/
Сообщение от Аноним (6), 10-Май-24, 10:27 
Лол благодаря ему эта строчка вообще существует. А отключать опцию или нет это дело пользователя.
Ответить | Правка | Наверх | Cообщить модератору

4. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от хрю (?), 10-Май-24, 09:49 
Зачем? Если кому это действительно надо отключают сей алгоритм и давно - "что уже давно делается в таких проектах, как Node.js и curl." Гражданин вещает с позиций AWS, а позиция обычных смертных может быть немного отличаться.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

5. "Предложение по включению режима TCP_NODELAY по умолчанию"  +7 +/
Сообщение от Аноним (6), 10-Май-24, 10:25 
Просто aws хочет ценник за трафик больше получить.  
Ответить | Правка | Наверх | Cообщить модератору

104. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Abra (?), 11-Май-24, 22:02 
Простите, а за счёт чего? Данные просто будут переданы быстрее, и только. Но объем должен быть тот же
Ответить | Правка | Наверх | Cообщить модератору

8. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от Аноним (2), 10-Май-24, 10:32 
Если вдруг обычному пользователю захочется форсировать данный флаг глобально. Чтобы в игрушках были минимальные задержки, например...
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

25. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Banned (?), 10-Май-24, 12:40 
Типичный кээсер. Реальная выгода хоть есть?
Ответить | Правка | Наверх | Cообщить модератору

34. "Предложение по включению режима TCP_NODELAY по умолчанию"  +5 +/
Сообщение от Аноним (34), 10-Май-24, 13:49 
А разве игрушки не UDP пользуются для минимализации латентности?
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

45. "Предложение по включению режима TCP_NODELAY по умолчанию"  –4 +/
Сообщение от Аноним (2), 10-Май-24, 15:17 
К сожалению, нет.
Ответить | Правка | Наверх | Cообщить модератору

56. "Предложение по включению режима TCP_NODELAY по умолчанию"  +4 +/
Сообщение от Аноним (56), 10-Май-24, 17:29 
Правильнее было бы сказать: "Не все".
Unreal Engine - UDP.
Unity - UDP.
Godot - HTTPS поверх TCP (пздц) по дефолту для ленивых. TCP или UDP для всех остальных.
Но нужно учесть тот факт что на Godot игор нет.
Ответить | Правка | Наверх | Cообщить модератору

83. "Предложение по включению режима TCP_NODELAY по умолчанию"  –3 +/
Сообщение от Аноним (2), 11-Май-24, 04:56 
Фактически, сказал тоже самое, но в более краткой форме. Разумеется, есть игры которые используют UDP, но встречаются они крайне редко.
Ответить | Правка | Наверх | Cообщить модератору

99. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (99), 11-Май-24, 15:26 
Чушь несёшь. Игры в основном используют TCP для согласования и прочей мелочи. И UDP для RT трафика в игре. Если, конечно, речь о играх где важен FPS и задержки. Так было ещё со времён CS
Ответить | Правка | Наверх | Cообщить модератору

102. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (2), 11-Май-24, 16:50 
Найдите мне MMORPG с UDP протоколом.
Ответить | Правка | Наверх | Cообщить модератору

125. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от rshadow (ok), 13-Май-24, 19:36 
Очень забавное наблюдение. Погуглил. В среднем так: если игра без автотаргета, по факту ближе к шутеру, то UDP. Если просто клацать мышкой (Линейка, вовка, ева и т.д.) то TCP. Ну и плюс всякая медийка (внутриигровые войс чаты) тоже UDP.

Например https://valheim.fandom.com/wiki/Dedicated_servers#Networking

Ответить | Правка | Наверх | Cообщить модератору

7. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от Аноним (7), 10-Май-24, 10:31 
любой дистрибутив может сделать это по своему желанию.
если нет то сами себе сделайте.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

10. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (2), 10-Май-24, 11:28 
Уже давно...
Ответить | Правка | Наверх | Cообщить модератору

39. "Предложение по включению режима TCP_NODELAY по умолчанию"  +8 +/
Сообщение от timur.davletshin (ok), 10-Май-24, 14:27 
Погодите, панове, а что мешает использовать TCP_NODELAY при открытии сокета? Разве не так задумано было? Нужен интерактив? - Тогда используй соотв. опцию при открытии соединения.

Для сомневающихся, советую поиграться с SSH и попробовать заоверрайдить умолчальные TCP_NODELAY. Консолька интересной становится.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

75. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ivan_83 (ok), 11-Май-24, 03:20 
Консольке от флага приятно не не более того.
В качестве аргумента скажу что консолька часто нормально себя ощущает при RTT 50-150мс, подозреваю что ОС без TCP_NODELAY на столько пакет не задерживает.
Ответить | Правка | Наверх | Cообщить модератору

97. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от timur.davletshin (ok), 11-Май-24, 13:49 
> Консольке от флага приятно не не более того.
> В качестве аргумента скажу что консолька часто нормально себя ощущает при RTT
> 50-150мс, подозреваю что ОС без TCP_NODELAY на столько пакет не задерживает.

Патчить кривой софт надо, а не менять то, что потенциально может много проблем создать.

Ответить | Правка | Наверх | Cообщить модератору

89. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (89), 11-Май-24, 09:38 
>а что мешает использовать TCP_NODELAY при открытии сокета?

Тем что не все это знают, а те кто знают те забывают. Признаюсь честно, я делал что то типа прокси-туннеля и запускал VNC через нее и думал что задержки курсора это комп или сеть тормозит. А потом вспомнил про TCP_NODELAY.
Лучше бы имхо было наоборот, флаг TCP_DELAY_LEGACY_FOR_TELNET.

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

94. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ivan_83 (ok), 11-Май-24, 12:44 
Так оно нужно только для отдельных применений.
У меня вот есть msd - оно стримит IPTV, там свой огромный буффер из которого рассылает клиентам, и от TCP_NODELAY ничего не изменится совсем, потому что у клиента тоже буфера.

Ответить | Правка | Наверх | Cообщить модератору

112. "Предложение по включению режима TCP_NODELAY по умолчанию"  –1 +/
Сообщение от pda (ok), 12-Май-24, 20:45 
Наверное то, что приложению по хорошему неоткуда знать нужно ему использовать этот флаг или нет. Так понимаю, он был актуален во времена медленных каналов, вроде модемных. На них экономия могла иметь смысл, на широкополосных нет. По этому его и выносили в конфиг.
Но теперь модемных каналов не осталось и по идее нет нужды требовать от приложений устанавливать его явно.

Вообще это решение выглядит таким себе. По идее механизм управления потоком стоило привязывать к интерфейсу.

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

115. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от timur.davletshin (ok), 13-Май-24, 07:43 
> Наверное то, что приложению по хорошему неоткуда знать нужно ему использовать этот
> флаг или нет.

А кто об этом должен знать, как не приложение? Вы бредите или это такой юмор?

> Вообще это решение выглядит таким себе. По идее механизм управления потоком стоило
> привязывать к интерфейсу.

А... это после воскресенья такое. Бывает.


Ответить | Правка | Наверх | Cообщить модератору

118. "Предложение по включению режима TCP_NODELAY по умолчанию"  –2 +/
Сообщение от pda (ok), 13-Май-24, 12:55 
> А кто об этом должен знать, как не приложение? Вы бредите или
> это такой юмор?

Откуда приложению знать (да ещё и на этапе компиляции) в каких условиях его будут использовать? Модемный канал или нет?

> А... это после воскресенья такое. Бывает.

Вы про себя что ли? Ну, просыхайте. Может перечитаете и поймёте.

Ответить | Правка | Наверх | Cообщить модератору

119. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от timur.davletshin (ok), 13-Май-24, 13:33 
> Откуда приложению знать (да ещё и на этапе компиляции) в каких условиях
> его будут использовать? Модемный канал или нет?

Вы просто не поняли, для чего TCP_NODELAY делался. К ширине канала это имеет очень небольшое отношение. А вот приложение прекрасно знает, что ему нужно больше - интерактив или пропускная способность. Но ты сильно не расстраивайся, не плакай там. Не ты один такой, вон Mozilla (да и Chrome) до сих пор не умеет помечать ToS в пакетах канала данных WebRTC. Багрепортам уже не помню сколько лет.

> какая-то тухлая эскапада на предмет моей некомпетентности

Воспользуйся моим советом выше и поиграйся с SSH. Если они смогли, то что мешает другим?

Ответить | Правка | Наверх | Cообщить модератору

121. "Предложение по включению режима TCP_NODELAY по умолчанию"  –1 +/
Сообщение от pda (ok), 13-Май-24, 14:40 
> А вот приложение прекрасно знает, что ему нужно больше - интерактив или пропускная способность.

Вы текст-то новости прочли? "RFC для алгоритма Нейгла принят в 1984 году и он не рассчитан на параметры современных высокоскоростных сетей и серверов в датацентрах, что приводит к возникновению проблем с отзывчивостью." Так откуда приложению знать в современной оно сети работает или нет?

>> какая-то тухлая эскапада на предмет моей некомпетентности
> Воспользуйся моим советом выше и поиграйся с SSH. Если они смогли, то
> что мешает другим?

Простите, вы там кого от моего имени процитировали? У меня в посте таких слов нет. Вы ChatGPT, у вас галлюцинации? Если нет и отвечаете кому-то другому - вот идите к нему в ветку и отвечайте.

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

Ответить | Правка | Наверх | Cообщить модератору

122. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от timur.davletshin (ok), 13-Май-24, 14:55 
> Понимания, что неправильный алгоритм управления может ухудшить работу? Спасибо за гениальное наставление, сам бы я точно до этого не догадался.

Наоборот, ты наконец поймёшь, что СТОИТ читать не новости, а RFC... и экспериментировать. Если человек из новости не пишет о том, что ядро предоставляет интерфейс для управления поведением сетевого стека, то он а) некомпетентен или б) ангажирован. Я ставлю на второе. В твоём же случае очевидна первая причина.

Прежде чем продолжить тухлую пикировку, давай определимся с твоим тезисом о том, что приложение "не знает о ширине канала". Имеются ли давно внедрённые алгоритмы, которые позволяют определить эту самую полосу? Имеются ли минимальные требования к работе приложения (я, надеюсь, мы не будем разговаривать о запуске VoIP через 1200 baud packet radio?)?

Потом вернёмся к тому, насколько ты понимаешь, чем и зачем TCP_NODELAY используется сейчас.

А потом мы по пунктикам разберём, где выступивший с инициативой пан слукавил (или соврал). Я очень люблю, когда ссылаются на "старость" RFC без учёта реализаций.

Ответить | Правка | Наверх | Cообщить модератору

132. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (132), 16-Май-24, 02:35 
Nagle занимается тем, что буферизует данные, записываемые в TCP-сокет, вместо нерадивых приложений которые делают write(2) по паре байт, чтобы без Nagle-а приводило бы к куче мелких пакетов с пейлоадом в эти самые пары байт.

Потому кроме приложений, которые и дергают write(2)-ы, никто и не может знать, нужен Nagle им, потому что написаны они левой пяткой без нормальной буферизации данных, или нет, потому что у программиста есть мозг, и он им подумал о том, что будет происходить с отправляемыми данными на уровне TCP/IP стека.

Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

57. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от timur.davletshin (ok), 10-Май-24, 17:54 
Хороший такой детектор получился из плюсующих данный комментарий.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

63. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от violation (?), 10-Май-24, 20:49 
Можно вопрос к знатоку 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 строчек  с ошибкой все время бегут друг за другом без остановки в терминале и чтобы остановить закрываю эмулятор терминала.
Может быть можно решить по-нормальному?

Ответить | Правка | Наверх | Cообщить модератору

64. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (64), 10-Май-24, 21:38 
Нашел такой вариант без export,но ошибки сыпятся все равно.
about:config
security.sandbox.content.level to 0
Ответить | Правка | Наверх | Cообщить модератору

98. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от timur.davletshin (ok), 11-Май-24, 13:50 
> Можно вопрос к знатоку 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. Без шуток, туда лучше сразу иди.

Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

11. "Предложение по включению режима TCP_NODELAY по умолчанию"  +15 +/
Сообщение от Аноним (11), 10-Май-24, 11:41 
> Даже если размер полезных данных составляет считанные байты, то, как правило, фактически размер отправляемой информации существенно возрастает после применения сериализации, использования API-обвязок в JSON и отправки с использованием TLS-шифрования. Экономия 40 байтов становится не столь актуальной.

всё, что нужно знать о современном программизде. адын байт не могут отослать без JSON и TLS.

Ответить | Правка | Наверх | Cообщить модератору

27. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (34), 10-Май-24, 13:07 
Без Шизон. Вообще непонятна это стремления в ASCII-сериализацию, есть же и двоичные форматы.
Ответить | Правка | Наверх | Cообщить модератору

77. "Предложение по включению режима TCP_NODELAY по умолчанию"  +3 +/
Сообщение от Ivan_83 (ok), 11-Май-24, 03:26 
Потому что для отладки текстовых протоколов достаточно обычного отладчика и текстового редактора, а для бинарных нужны парсеры особые.
Для написания текстового кодера достаточно snprintf() а декодера sscanf().
Итого текстовый протокол делается за пол часа и работает сразу, отлаживать можно любой прогой отправляющей текст.
А всякие питонисты у них этот xml/json/yaml чуть не нативно везде напихан, им даже кодить сильно не надо чтобы оно начало по сети бегать.

Я не говорю что бинарные протоколы плохие (не все, ИМХО, как и текстовые), просто показал процесс со стороны разработчика.

Ответить | Правка | Наверх | Cообщить модератору

66. "Предложение по включению режима TCP_NODELAY по умолчанию"  +5 +/
Сообщение от Аноним (99), 10-Май-24, 22:59 
Скажи спасибо, что уже не XML, а пока всего лишь JSON. Правда, теперь идёт YAML и конца этого идиотизма не проглядывается
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

68. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (99), 10-Май-24, 23:21 
Хотя не, ещё не уже, как раз этот долбанутый aws использует у себя в протоколах XML
Ответить | Правка | Наверх | Cообщить модератору

70. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (70), 11-Май-24, 00:35 
У XML хотя бы схемы есть. А в джсон все как попало срут.
Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

85. "Предложение по включению режима TCP_NODELAY по умолчанию"  +2 +/
Сообщение от Аноним (85), 11-Май-24, 08:10 
У жсона тоже можно схему прописать. Да и в xml никто не мешает насрать чем угодно.
Ответить | Правка | Наверх | Cообщить модератору

78. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ivan_83 (ok), 11-Май-24, 03:27 
Да пофиг же, пожал сверху zlib если не нравится оверхэд и всё.
Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

127. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Sem (??), 14-Май-24, 13:02 
Какой в этом смысл? Лучше сразу protobuf использовать бинарный.
Ответить | Правка | Наверх | Cообщить модератору

76. "Предложение по включению режима TCP_NODELAY по умолчанию"  –1 +/
Сообщение от Ivan_83 (ok), 11-Май-24, 03:22 
Щас набегут контуженные безхопасностью и расскажут что без TLS жизни угрожает опасность, и что сериализацию надо делать средствами руста, не важно сколько оверхэда оно накидывает :)
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

123. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от fuggy (ok), 13-Май-24, 16:31 
Как два байта переслать, оказывать могут не все.
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

12. "Предложение по включению режима TCP_NODELAY по умолчанию"  –2 +/
Сообщение от Шарп (ok), 10-Май-24, 11:44 
>Современные распределённые приложения давно не отправляют единичные байты данных, а агрегирование мелких данных обычно реализуется на уровне приложения.

Если такие пакеты не отправляются, то и алгоритм Нейгла не гадит. Тогда почему он ноет?

Ответить | Правка | Наверх | Cообщить модератору

17. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от кр3рр (?), 10-Май-24, 11:52 
Ответ самого автора, Джона Негла: https://news.ycombinator.com/item?id=10608356


Ответить | Правка | Наверх | Cообщить модератору

19. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от кр3рр (?), 10-Май-24, 11:54 
И второй: https://news.ycombinator.com/item?id=34180239
Ответить | Правка | Наверх | Cообщить модератору

20. "Предложение по включению режима TCP_NODELAY по умолчанию"  –1 +/
Сообщение от Аноним (2), 10-Май-24, 11:54 
Вы плохой усвоили материал.
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

14. "Предложение по включению режима TCP_NODELAY по умолчанию"  +3 +/
Сообщение от Аноним (14), 10-Май-24, 11:48 
Хочешь сам рулить отправкой, используй udp, что собственно и сделал гугл с quic.
Ответить | Правка | Наверх | Cообщить модератору

47. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от laindono (ok), 10-Май-24, 15:19 
В quic пакеты ACK вообще по другому сделаны кстати. Можно сразу на много-много запросов ACK в один пакет запихнуть.
Ответить | Правка | Наверх | Cообщить модератору

67. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (99), 10-Май-24, 23:14 
Посмотри, что ли, что такое TCP SACK
Ответить | Правка | Наверх | Cообщить модератору

79. "Предложение по включению режима TCP_NODELAY по умолчанию"  –2 +/
Сообщение от Ivan_83 (ok), 11-Май-24, 03:28 
Да, и теперь гугол может списать за показ рекламы и сказав: "я тут ваш баннер по юдп послал, услуга оказана".
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

90. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (89), 11-Май-24, 09:40 
>используй udp

И огреби кучу проблем в реальном мире например с проксями и файрволлами

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

15. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от 12yoexpert (ok), 10-Май-24, 11:49 
> что уже давно делается в таких проектах, как Node.js

так вот, почему на node.js всё так летает

Ответить | Правка | Наверх | Cообщить модератору

18. "Предложение по включению режима TCP_NODELAY по умолчанию"  –3 +/
Сообщение от 12yoexpert (ok), 10-Май-24, 11:53 
Последний довод это какой-то вынос мозга, нет слов. Как будто кроме перекладывателей json-ов на свете больше никого нет
Ответить | Правка | Наверх | Cообщить модератору

22. "Предложение по включению режима TCP_NODELAY по умолчанию"  –1 +/
Сообщение от Аноним (6), 10-Май-24, 11:58 
Что ещё есть? Давай перечисляй.
Ответить | Правка | Наверх | Cообщить модератору

103. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от MaleDog (?), 11-Май-24, 21:40 
Любой алгоритм, где на надежность и гарантия доставки важнее скорости. Но нет, давайте сделаем, как удобнее "прикладникам", а не "сетевикам" и "системщикам". Это как с монгой по умолчанию выставим "0.0.0.0", а кому надо безопасно поставит "127.0.0.1". Напомнить к чему привело?
Ответить | Правка | Наверх | Cообщить модератору

23. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (23), 10-Май-24, 12:05 
Тут не идёт речь о "на свете". Речь об AWS.
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

29. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от 12yoexpert (ok), 10-Май-24, 13:16 
нет, тут речь о дефолтном конфиге ядра
Ответить | Правка | Наверх | Cообщить модератору

42. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (-), 10-Май-24, 14:51 
Он касается всех, не только перекладывателей json'а:

> Современные распределённые приложения давно не отправляют единичные байты данных, а агрегирование мелких данных обычно реализуется на уровне приложения.

Если ты дёргаешь ядро на каждый отправляемый байт, то либо ты никогда не слышал про буферизацию, либо тебе действительно _надо_ отправлять по байту, и ты готов терпеть накладные расходы на лишние сисколлы.

В первом случае, тебе следует заняться повышением образованности, и проложить между своим кодом и сисколлами прослойку буферизирующего стрима (в качестве грязного и дешёвого способа можешь использовать fdopen).

Во втором случае, ты сознательно отказываешься от буферизации, и ты будешь выставлять TCP_NODELAY, чтобы ядро не впихивало бы тебе её принудительно, чтобы жертвы производительности, принесённые тобою на алтарь сисколлов, не прошли бы даром.

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

50. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (50), 10-Май-24, 16:55 
Это воннаби дед, у него от слов современный, api, json начинается кружится голова и мутнеет перед глазами.
Ответить | Правка | Наверх | Cообщить модератору

80. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ivan_83 (ok), 11-Май-24, 03:35 
Подход "сделаем всё сами правильно" это отказ от кооперации, когда в ядре за вас уже всё сделали давным давно.
Да, сисколы дорогие относительно буферизации в приложении, но не факт что в приложении получится сделать лучше и что этим вообще стоит заниматся.

Идеальная замена алгоритма буферизации, сопоставимая с тем что в ядре, это не просто добавить буфер в приложение, это ещё и таймер, чтобы данные там не залёживались.
А таймер это ещё один сискол...

В общем есть случаи когда лучше дать ОС буферизировать и просто задрачивать send() в приложении.

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

107. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (-), 12-Май-24, 09:07 
> Идеальная замена алгоритма буферизации, сопоставимая с тем что в ядре, это не просто добавить буфер в приложение, это ещё и таймер, чтобы данные там не залёживались.

Идеальная замена алгоритма буферизации, не потребует ничего этого. В ядре генерализованный алгоритм, который ничего не знает о характере генерации данных, и поэтому ориентируется на таймер. Юзерспейс, же, генерирующий данные, может поступать интереснее. Например, если тебе надо отправить http запрос, ты можешь создать буфер в десяток килобайт, и писать запрос туда, чтобы потом одним сисколлом отправить. Если буфер маловат для запроса, скидываешь содержимое в ядро и продолжаешь писать в него. Нет никакой нужды в таймерах. Юзерспейс часто знает, когда важно отправлять данные немедленно по мере появления, когда нет смысла отправлять раньше времени (половину http запроса бессмысленно отправлять пораньше, прежде чем ты вторую дописал), а когда требуется более сложная и менее эффективная схема как в ядре.

Если тебе нужен таймер для буферизации, то тебе уже не повезло с задачей, и имеет смысл остановиться и подумать, а нельзя ли как-нибудь без него.

> А таймер это ещё один сискол...

Попробуй посчитать. Вот представь, что приложение генерирует данные по байту, что временя до следующего байта распределяется по Пуассону. Приложение хотело бы байты отправлять по мере появления, чтобы не терять латенси, но готово отчасти пожертвовать латенси ради срупута. Зная задержку на буферизацию в ядре, попробуй прикинуть при каких лямбдах буферизация в ядре будет выгоднее периодической (10 раз в сек?) обработки SIGALRM, а потом попробуй нафантазировать случай, который реализует такую лямбду, при этом хотя бы отдалённо выглядя реалистично. В этом случае, ведь, надо чтобы требования к задержкам со стороны задачи примерно бы совпадали с тем, что ядро использует. На осмысленность экономии трёх байт трафика, давай забьём, примем её как данность, чтобы не сравнивать яблоки с апельсинами, экономию трафика и латенси.

> В общем есть случаи когда лучше дать ОС буферизировать и просто задрачивать send() в приложении.

Было бы убедительнее, если бы ты привёл пример.

Ответить | Правка | Наверх | Cообщить модератору

108. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ivan_83 (ok), 12-Май-24, 10:47 
Как минимум при прототипировании не имеет смысла возится вообще с буферизацией у себя.
В остальном для любой задачи где частота вызова не сильно высокая и не будет расти количество таких писаталей.
Какой нить датчик или сериал порт.


SIGALRM - это какое то жуткое легаси, create_timer_fd(), kqueue() - вот современные методы.

Ответить | Правка | Наверх | Cообщить модератору

24. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от кр3рр (?), 10-Май-24, 12:05 
И к слову, отключение TCP_NODELAY не отменяет агрегирования. Десять вызовов send() подряд не приведут к отправке 10 TCP-пакетов. Их, разумеется, будет в среднем больше, чем без NODELAY, но не 10.
Ответить | Правка | Наверх | Cообщить модератору

28. "Предложение по включению режима TCP_NODELAY по умолчанию"  +2 +/
Сообщение от Аноним (28), 10-Май-24, 13:08 
Я далек от глубокого понимания сетей и возможно не понял что ты имеешь ввиду, но ты же выше сам скинул ссылку на пост того самого Джона Нейгла (имени которого алгоритм) и он там утверждает что таки на каждый 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."

чего я не догнал, что упустил?

Ответить | Правка | Наверх | Cообщить модератору

40. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (28), 10-Май-24, 14:28 
А, сорри. Невнимательно прочитал.

после прочтения строчки:
> Десять вызовов send() подряд не приведут к отправке 10 TCP-пакетов

подумал что имеется ввиду "их будет меньше" и уже глазами мельком проскочил и неверно прочитал следующую строку:
> Их, разумеется, будет в среднем больше
>> БОЛЬШЕ

Ответить | Правка | Наверх | Cообщить модератору

46. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от кр3рр (?), 10-Май-24, 15:18 
При 10 вызовах send/write с малым количеством данных без NODELAY в идеале отправится 1 TCP-пакет, но с NODELAY не факт, что отправится 10 — это зависит от заполненности буфера или других факторов.

Подробно не исследовал, у меня была как раз задача отправлять по отдельному пакету на каждый вызов send/write в Linux для TCP-сокета, и я не смог ее решить стандартными средствами юзерспейса.

Ответить | Правка | Наверх | Cообщить модератору

92. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (2), 11-Май-24, 11:19 
Агрегацией занимается драйвер сетевого устройства.
Ответить | Правка | Наверх | Cообщить модератору

95. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ivan_83 (ok), 11-Май-24, 12:46 
Вы большей частью не правы.

Вот как во фре:
# 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 */


те только один драйвер сетевух умеет в агрегацию.

Ответить | Правка | Наверх | Cообщить модератору

26. "Предложение по включению режима TCP_NODELAY по умолчанию"  +5 +/
Сообщение от Аноним (26), 10-Май-24, 13:02 
очередной один "умный" чувак пытается решить за всех
почему он не рассказал что вырастет нагрузка на сетевые устройства из-за возросшего pps?
Ответить | Правка | Наверх | Cообщить модератору

30. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от 12yoexpert (ok), 10-Май-24, 13:20 
потому что на таких сюрпризах амазон веб сервисес зарабатывает бабки. дурить клиентов - основной источник их дохода
Ответить | Правка | Наверх | Cообщить модератору

51. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от Аноним (50), 10-Май-24, 16:57 
Так он отвечает на комбинаторе, зайди поспорь с ним) А общими словами кидать всякий горазд. Ты ведь даже не понял о чем речь в статье, судя по комментам)
Ответить | Правка | Наверх | Cообщить модератору

37. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от Аноним (37), 10-Май-24, 13:54 
В их датацентре pps сетка потянет, а за его пределами - хоть трава не расти.
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

53. "Предложение по включению режима TCP_NODELAY по умолчанию"  –1 +/
Сообщение от Аноним (50), 10-Май-24, 16:59 
На чем должна быть сетка, чтобы не потянуть возросшие pps от no_delay?! На dlink des-3526 или распбери пи?
Ответить | Правка | Наверх | Cообщить модератору

48. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (48), 10-Май-24, 15:55 
> вырастет нагрузка на сетевые устройства из-за возросшего pps

Устройства младше 15 лет не развалятся, а старше в такие места не ставят. Максимум какому-то помойному оператору с оборудованием с ебея придётся проапгрейдиться, но разве ж это вред?

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

54. "Предложение по включению режима TCP_NODELAY по умолчанию"  –1 +/
Сообщение от Аноним (50), 10-Май-24, 17:00 
Да челы видимо цоды видали токмо на картинках.
Ответить | Правка | Наверх | Cообщить модератору

31. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от anonymous (??), 10-Май-24, 13:30 
хорошая новость. Я раньше следил за проектом bufferbloat, так как раз с этими странностями TCP/IP пытались бороться (codel, cake они придумали и протолкнули в ядро). Там очень сложно все, и я через слово все понимал на форуме но было безумно интересно. Основной толчок проекту был тогда когда на какую то конференцию сетевиков приперлась куча народу с вайфаем и никто не мог понять вроде по параметрам все должно было работать надежно и с большим запасом а по факту жуткое лагалово особенно в лайвстримах. Это начали раскручивать, и оказалось что там совсем неочевидные вещи происходят, в том числе и то с чем должен был бороться этот алгоритм Nagle но там настолько сложно все - прямо детективная история с аппаратными очередями пакетов, их разбивка, невозможность контролировать это программно из драйверов, аномальное поведение которое при попытке исправить делает еще хуже (вроде до сих пор не побороли сложности с ECM). Короче, очень здорово что снова пытаются разобраться с этим и не только команда с buffetbloat.
Ответить | Правка | Наверх | Cообщить модератору

33. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от Аноним (37), 10-Май-24, 13:34 
>детективная история с аппаратными очередями пакетов

Проприетарные истории с сетевыми карточками - конечно же проблема ядра и его разработчиков.  

Ответить | Правка | Наверх | Cообщить модератору

55. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от Аноним (55), 10-Май-24, 17:14 
Это вообще-то очевидно, так как именно им придётся с этим разбираться.
Ну или пусть вешают табличку "ваше оборудование не поддерживается" и идут разрабатывать свободное железо вместо траты сил на кривой вяланд и сустемды.
Ответить | Правка | Наверх | Cообщить модератору

81. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от Ivan_83 (ok), 11-Май-24, 03:37 
bufferbloat это примерно как борьба с изменением климата: никто не понимает но всем весело.
Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

135. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от КТОТОТАМ (ok), 17-Май-24, 17:03 
Прочитал ваше сообщение и заинтересовался) А вы для каких целей занимаетесь изучением темы с Bufferbloat ? Просто у меня тоже в этой теме кое какие наблюдения есть...
Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

32. "Предложение по включению режима TCP_NODELAY по умолчанию"  –1 +/
Сообщение от Аноним (37), 10-Май-24, 13:33 
Если это внушение для разработчиков сетевых приложений, не отправляющих по 1 байту, то в принципе нормальный посыл. setsockopt в руки.
Если же хотят в сетевом стеке по умолчанию включенный nodelay, то пусть идут лесом. Если ценой задержек в сети гуляет меньше пакетов, весь мир экономит электричество. Где-то получается обходиться менее производительным оборудованием. Топовые датацентры корпораций - это не весь мир. Даже если в них большая часть передаваемых данных сосредоточена.
Ответить | Правка | Наверх | Cообщить модератору

35. "Предложение по включению режима TCP_NODELAY по умолчанию"  –2 +/
Сообщение от Ананимус (?), 10-Май-24, 13:49 
> Если ценой задержек в сети гуляет меньше пакетов, весь мир экономит электричество.

Расчеты экономии в студию, что ли. Звучит как экономия на спичках.

Ответить | Правка | Наверх | Cообщить модератору

36. "Предложение по включению режима TCP_NODELAY по умолчанию"  +2 +/
Сообщение от Аноним (37), 10-Май-24, 13:53 
Звучит как корпоративный буллшит, за который в случае факапа никто отвечать не будет. Присвоить прибыль, обобществить убытки - ваше всё!
Ответить | Правка | Наверх | Cообщить модератору

38. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ананимус (?), 10-Май-24, 13:57 
>  Звучит как корпоративный буллшит, за который в случае факапа никто отвечать не будет. Присвоить прибыль, обобществить убытки - ваше всё!

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

Ответить | Правка | Наверх | Cообщить модератору

59. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от ss (??), 10-Май-24, 19:14 
"отморожу себе уши что бабушке было больно"
Ответить | Правка | Наверх | Cообщить модератору

61. "Предложение по включению режима TCP_NODELAY по умолчанию"  –1 +/
Сообщение от Ананимус (?), 10-Май-24, 20:34 
> "отморожу себе уши что бабушке было больно"

Нет, отморожу ему уши. Я не вижу никаких внятных обоснований заметного увеличения трафика от NODELAY.

Ответить | Правка | Наверх | Cообщить модератору

44. "Предложение по включению режима TCP_NODELAY по умолчанию"  +2 +/
Сообщение от Аноним (-), 10-Май-24, 15:15 
Если по-хорошему, то Брукер тоже не привёл никаких расчётов. Прежде чем такое изменение выкатывать в качестве нового дефолта, неплохо было бы оценить последствия.

Я лично, думаю, что так будет правильно -- буферизировать надо в юзерспейсе, там где известен характер данных и требования к задержкам, там где буферизацию можно заточить под юзкейс. И предлагаемая стратегия взять и поменять всем дефолты, неплохой способ заставить юзерспейс думать об этом, а не лепить как придётся. Но я к тому, что если требовать расчётов экономии, то требовать их надо от тех, кто агитирует за изменение дефолтов.

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

49. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ананимус (?), 10-Май-24, 16:00 
>  Если по-хорошему, то Брукер тоже не привёл никаких расчётов. Прежде чем такое изменение выкатывать в качестве нового дефолта, неплохо было бы оценить последствия.

Latency можно померять, но если ты посмотришь в любые latency-critical приложение, ты увидешь там NODELAY. Чтобы далеко не ходить -- это даже в NGINX дефолт. То есть большая часть HTTP трафика в мире ходит с NODELAY и всем нормально.

Ответить | Правка | Наверх | Cообщить модератору

52. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (-), 10-Май-24, 16:57 
> если ты посмотришь в любые latency-critical приложение, ты увидешь там NODELAY.

Вот я об этом и говорю. Умозрительные рассуждения на базе голословных утверждений. Но мало того, ты ещё смотришь на ситуацию однобоко и не с того бока. Если изменить дефолты, то проблемой могут стать не столько латенси-критикл приложения, сколько срупут-критикл, которые не используют ноделей. И поэтому интереснее взгляд именно с этой стороны, исследование которое бы оценило как много таких приложений в дикой природе, и как в абсолютных числах может измениться объём мирового трафика.

Ответить | Правка | Наверх | Cообщить модератору

62. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ананимус (?), 10-Май-24, 20:36 
>> если ты посмотришь в любые latency-critical приложение, ты увидешь там NODELAY.
> Если изменить дефолты, то проблемой могут стать не
> столько латенси-критикл приложения, сколько срупут-критикл, которые не используют ноделей.
> И поэтому интереснее взгляд именно с этой стороны, исследование которое бы
> оценило как много таких приложений в дикой природе, и как в
> абсолютных числах может измениться объём мирового трафика.

Оло, NGINX использует NODELAY. Это, считай, 70% мирового трафика. CDN, стриминг и прочее объемное человеческое творчество.

Ответить | Правка | Наверх | Cообщить модератору

84. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (99), 11-Май-24, 06:32 
Это только фронты, внутри ДЦ идёт гораздо больший трафик и никакого HTTP там нет. Ну и, конечно, замечательные у тебя рассужедния уровня ~ на 30 % можно забить. Собственно по положительному ответу на вопрос топика можно легко определять проф непригодных
Ответить | Правка | Наверх | Cообщить модератору

86. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ананимус (?), 11-Май-24, 09:01 
> Это только фронты, внутри ДЦ идёт гораздо больший трафик и никакого HTTP
> там нет.

Статья про отключение NODELAY внутри ДЦ и профиты, которые от этого видят люди, работающие в этом ДЦ. Ну и да, в postgres тоже NODELAY.

> Ну и, конечно, замечательные у тебя рассужедния уровня ~
> на 30 % можно забить. Собственно по положительному ответу на вопрос
> топика можно легко определять проф непригодных

Если БОЛЬШАЯ часть трафика не вызывает проблем, значит МЕНЬШАЯ часть трафика тоже не вызовет. Это очевидно, хватит отрицать реальность.

Ответить | Правка | Наверх | Cообщить модератору

96. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ivan_83 (ok), 11-Май-24, 12:50 
Вы упрощаете, сильно упрощаете, реальный мир сложнее.

На практике приложение должно на лету уметь делать автотюнинг и менять не только NODELAY но и CC, в зависимости от RTT.
Но приложений таких я не видел, самые лучшие уже умеют NODELAY для listen, но не умеют СС.

Ответить | Правка | Наверх | Cообщить модератору

100. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ананимус (?), 11-Май-24, 15:35 
> Вы упрощаете, сильно упрощаете, реальный мир сложнее. На практике приложение должно на лету уметь делать автотюнинг и менять не только NODELAY но и CC, в зависимости от RTT.
>Но приложений таких я не видел.

Реальный мир и опеннетчики, лол.


Ответить | Правка | Наверх | Cообщить модератору

105. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (99), 11-Май-24, 23:22 
Эти люди делают для своего ДЦ свои версии ядер. Вот и пусть там делают что хоят и не лезут с идиотскими предложениями на весь мир.
Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

110. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ананимус (?), 12-Май-24, 12:45 
> Эти люди делают для своего ДЦ свои версии ядер. Вот и пусть
> там делают что хоят и не лезут с идиотскими предложениями на
> весь мир.

Это предложение отражает реальность, в которой почти все сетевые приложения, где важно соблюдать задержки, используют NODELAY. То есть это де-факто дефолт, лол. Всем остальным приложениям положить на это все болт, потому что там такой трафик, что хоть побайтово пиши. Останутся два древних приложения, которые нужно будет починить. Все просто, но опеннет как всегда.

Ответить | Правка | Наверх | Cообщить модератору

129. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Sem (??), 14-Май-24, 13:16 
Есть некое количество приложений, которые опираются на текущий дефолт. И сколько такого, никто оценивать не собирается. Ну да, лучше поменять поведение по-умолчанию, а потом собирать грабли.
Ответить | Правка | Наверх | Cообщить модератору

130. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ананимус (?), 14-Май-24, 17:46 
>  Есть некое количество приложений, которые опираются на текущий дефолт. И сколько такого, никто оценивать не собирается. Ну да, лучше поменять поведение по-умолчанию, а потом собирать грабли.

Вместо этого все новые приложения должны делать костыли, да? :D

Ответить | Правка | Наверх | Cообщить модератору

117. Скрыто модератором  +/
Сообщение от Аноним (-), 13-Май-24, 10:58 
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

82. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ivan_83 (ok), 11-Май-24, 03:42 
Тут надо понимать что и почему, а не просто подражать кому то.

С одной стороны у nginx почти всегда отправляеся большая пачка данных (и я не думаю что DELAY сработал бы).
С другой надо конкурировать с другими, а конкурируют они по всяким дроческим метрикам, среди которых и задержка.

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

58. "Предложение по включению режима TCP_NODELAY по умолчанию"  +1 +/
Сообщение от Аноним (58), 10-Май-24, 19:13 
Экономия должна достигаться не таким способом. Буквально почти все мобильные приложения построены на базе веба, тянут с собой вебдвижок, и весят сотни мегабайт, при функционале максимум на десятки. Только один запуск такого приложения прожигает, наверное, месяцы потерь на эти 40 байт. Веб - вот где сверх избыточность. Веб и мобильные приложения нужно жестко ограничивать, как по памяти, так и по ресурсам CPU и GPU.
Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

65. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (48), 10-Май-24, 22:38 
Ну раз нужно, то можешь начинать прямо сегодня, прямо сейчас. Засовываешь свой браузер в cgroup с любыми лимитами и дело в шляпе.
Ответить | Правка | Наверх | Cообщить модератору

69. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (69), 10-Май-24, 23:21 
> Даже если размер полезных данных составляет считанные байты, то, как правило, фактически размер отправляемой информации существенно возрастает после применения сериализации, использования API-обвязок в JSON и отправки с использованием TLS-шифрования. Экономия 40 байтов становится не столь актуальной.

Информации мало, а данных много. Вот на это действительно нужно обратить внимание. А опцию каждый разработчик сам решит - включать её в своём приложении или нет.

Ответить | Правка | Наверх | Cообщить модератору

71. "Предложение по включению режима TCP_NODELAY по умолчанию"  +3 +/
Сообщение от Ivan_83 (ok), 11-Май-24, 02:16 
1. Кому надо давно сами ставят TCP_NODELAY.

2. Есть разные реализации TCP и я сильно сомневаюсь что TCP_NODELAY и "delayed ACK" работает везде именно как описал Марк.

3. Оптимизации зависят от сценария использования, натягиывать всех на TCP_NODELAY не означает сделать всем лучше, кому то определённо поплохеет.

Ответить | Правка | Наверх | Cообщить модератору

72. "Предложение по включению режима TCP_NODELAY по умолчанию"  –1 +/
Сообщение от Аноним (72), 11-Май-24, 02:37 
> 1. Кому надо давно сами ставят TCP_NODELAY.

А у Вас в велобаджо все еще ставят TCP_NODELAY, а
в веларибо уже давно все могло бы работть и так.

> 2. Есть разные реализации TCP и я сильно сомневаюсь что TCP_NODELAY и "delayed ACK" работает везде именно как описал Марк.

А по конкретнее?

> 3. Оптимизации зависят от сценария использования, натягиывать всех на TCP_NODELAY не означает сделать всем лучше, кому то определённо поплохеет.

Кому-то в 1984 году? Непонятно зачем вообще эту фичу надо по умолчанию включать?

Ответить | Правка | Наверх | Cообщить модератору

73. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ivan_83 (ok), 11-Май-24, 03:02 
Есть как минимум один стёк в венде, два во FreeBSD, вероятно в других BSD и огрызке ещё минимум полтора наберётся, есть юзерспейсные реализации для всяких DPDK/netmap, и есть линуксовый.

И вместо мнений анонимов: "ололо, давайте выкиним старьё, мы это не понимаем" я бы лучше послушал мнение разработчиков которые пилят сейчас TCP, как минимум из нетфликса и гугла, они должны быть глубоко в теме и иметь адекватную экспертизу.

Кто такой Марк и насколько он больше в теме по сравнению с местными коментаторами и мной - я не знаю.
Своей экспертизы у меня нет, есть только понимание что современный TCP стёк очень сложный и учитывает очень много всего.
У того же RACK крутилок наверное более 150, а там ещё рядом крутилки СС, и крутилки от самой ОС, и это всё вместе очень не тривиально взаимодействует.

И даже если мнение нетфликса и гугла совпадёт с мнением Марка это будет означать что рекомендация годная для серверов/раздачи, но не факт что клиенту оно надо.

Ответить | Правка | Наверх | Cообщить модератору

87. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ананимус (?), 11-Май-24, 09:02 
> И вместо мнений анонимов: "ололо, давайте выкиним старьё, мы это не понимаем"
> я бы лучше послушал мнение разработчиков которые пилят сейчас TCP, как
> минимум из нетфликса и гугла, они должны быть глубоко в теме
> и иметь адекватную экспертизу.

Это ведет к помойным интерфейсам, которыми нельзя пользоваться без книжек и best practices.

Ответить | Правка | Наверх | Cообщить модератору

88. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от крок (?), 11-Май-24, 09:18 
Иногда нет простых и хороших решений для сложных комплексных проблем.
Книжки нужны тем кто считает что в его ситуации дефолты не оптимальны.
Ответить | Правка | Наверх | Cообщить модератору

91. "Предложение по включению режима TCP_NODELAY по умолчанию"  –1 +/
Сообщение от Ананимус (?), 11-Май-24, 09:48 
> Иногда нет простых и хороших решений для сложных комплексных проблем.
> Книжки нужны тем кто считает что в его ситуации дефолты не оптимальны.

Как мы тут выяснили, дефолты неадекватны почти всем современным применениям.

Ответить | Правка | Наверх | Cообщить модератору

93. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ivan_83 (ok), 11-Май-24, 12:40 
Это вы где то для себя выяснили, но лучше дефолтов от вас как то ничего не видно.
Сысоев хотя бы в 2007 описывал как, что и для чего тюнить.
Ответить | Правка | Наверх | Cообщить модератору

101. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ананимус (?), 11-Май-24, 15:36 
> Это вы где то для себя выяснили, но лучше дефолтов от вас
> как то ничего не видно.
> Сысоев хотя бы в 2007 описывал как, что и для чего тюнить.

У нас есть всратые дефолты, люди предлагают сделать их нормальными. Все, отставить истерику, идите защищайте скрепы в другом месте.


Ответить | Правка | Наверх | Cообщить модератору

106. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ivan_83 (ok), 12-Май-24, 00:26 
Аноним Марк, все достижения которого это работа на амазон и ведение бложика написал у себя в бложике что есть какая то старая опция которая работает с другой опцией непонятно как для него и давайте её выключим.
Никаких замеров он не произвёл, даже в домашней локалке, даже с виртуалками на локалхосте.

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

Ответить | Правка | Наверх | Cообщить модератору

109. "Предложение по включению режима TCP_NODELAY по умолчанию"  –1 +/
Сообщение от Ананимус (?), 12-Май-24, 12:40 
> Я не знаю что там у вас за дефолты, меня большая часть
> дефолтов вполне устраивает, часть от того что я крутил была по
> рекомендациям Сысоева, человека с большим практическим опытом в этом вопросе и
> с обоснованиями каждого параметра.

Кого волнует что тебя устраивает? Кто ты такой-то вообще? Весь полезный софт использует NODELAY по умолчанию, поэтому этот дефолт можно менять.

Ответить | Правка | Наверх | Cообщить модератору

111. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ivan_83 (ok), 12-Май-24, 15:16 
Офигенный уровень аргументации, идите, меняйте :)
А зачем вам менять если у вас весь софт и так это включает?
Ответить | Правка | Наверх | Cообщить модератору

114. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ананимус (?), 12-Май-24, 23:15 
> А зачем вам менять если у вас весь софт и так это включает?

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

Ответить | Правка | Наверх | Cообщить модератору

120. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (120), 13-Май-24, 14:32 
>помойным интерфейсам, которыми нельзя пользоваться без книжек и best practices

Книжки читать и best practices разбирать - это-ж какая нагрузка на мозги.

Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

126. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ананимус (?), 14-Май-24, 01:08 
> Книжки читать и best practices разбирать - это-ж какая нагрузка на мозги.

Конечно. Приходишь ты в гости, зашел в туалет. Нажимаешь кнопку слива и тут внезапно унитаз начинает квартиру говном заливать. Ты выбегаешь в панике, а хозяева говорят: ну ты чо надо было инструкцию читать это кнопка фонтанирования говном, чтобы слив работал надо переключить унитаз в правильный режим специальной педалью за бачком.

Вот примерно так это выглядит, если переносить на реальность. Good defaults matter, очевидные вещи должны делаться очевидным способом. Если в большинстве случаев Нагль это неочевидная история, которая только все портит, ему не место в дефолтах.

Ответить | Правка | Наверх | Cообщить модератору

124. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (-), 13-Май-24, 18:04 
> И вместо мнений анонимов: "ололо, давайте выкиним старьё, мы это не понимаем" я бы лучше послушал мнение разработчиков

Мнение анонимов имеет право на существование. Характер задач выполняемых tcp меняется, и исторические наслоения легаси становятся иррелевантными. Keep It Simple, Stupid, выкидывай всё, что не выглядит строго необходимым, потому что иначе все эти протоколы под своим весом обвалятся.

Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

74. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Ivan_83 (ok), 11-Май-24, 03:14 
Во фре вообще нет крутилки глобально включающей TCP_NODELAY для всех сокетов.
Видимо оно нафиг не надо.
Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

113. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (113), 12-Май-24, 21:03 
> ... использования API-обвязок в JSON и отправки ...

Всё так: сколько там переизбыток на передаче описания структуры данных через обвязку. Но зато проще войти в IT. Но - недостатки потом всюду.

Ответить | Правка | Наверх | Cообщить модератору

116. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (116), 13-Май-24, 08:20 
А в венде можно активировать TCP_NODELAY по умолчанию для всех соединений через реестр. А в линуксе как это сделоть, а?
Ответить | Правка | Наверх | Cообщить модератору

131. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Электрон (?), 15-Май-24, 23:01 
Его текст заслуживает отдельно потраченного против него времени. Там если пройтись с CTRL+C по тексту, много раз будет "проблема во всех вокруг, но не из-за меня".

Есть: периодический дебаг отклика приложений.
Хочет: давайте перевернем все наоброт!

Но почему-то он не идет к авторам программ (своих же амазоновских микросервисов? Кто же еще будет 0.5мс отклик иметь) и не просит их включить издавна рабочий флаг.

Да, программы чаще всего отправляют большие пакеты, а не по байту. А ещё программы ничего не знают о фактическом MTU, поэтому (и только с TCP, не UDP!) единственный способ не терять в оверхеде -- дать системе самой разбивать поток данных на TCP пакеты. Особенно с pMTUd в IPv6 это должно работать на 100%.

Почему сразу NODELAY? Может стоит изменить значения таймера, из-за которого задерживается? Либо эвристика в этом месте, либо эвристика в плане автоматического включения NODELAY.

В конце он пишет, мол, "когда я write(), то оно должно [отсылаться]". Нет, мой дорогой, по семантике надо flush!

Ненаучный подход, подискутировать можно и нужно, но не с его статьи в качестве вводной. Кроме себя ничего не видит.

Ответить | Правка | Наверх | Cообщить модератору

133. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от невежда (?), 16-Май-24, 06:59 
в чём заключается nodelay если оно приостонавливает отправку?)
Ответить | Правка | Наверх | Cообщить модератору

134. "Предложение по включению режима TCP_NODELAY по умолчанию"  +/
Сообщение от Аноним (134), 16-Май-24, 09:42 
> в чём заключается nodelay если оно приостонавливает отправку?)

Наоборот, TCP_NODELAY отключает приостановку отправки. Приостановка нужна, чтобы вместо 1000 пакетов с 1 байтом данных в каждом и 40 байтов заголовков отправить один пакет и сэкономить 40К на сетевых заголовках.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру