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

"Предложение по включению режима TCP_NODELAY по умолчанию"	+/–
Сообщение от opennews (??), 10-Май-24, 09:18
Марк Брукер (Marc Brooker), инженер из компании Amazon Web Services (AWS), разобрал заблуждения, связанные с повышением эффективности передачи мелких сообщений при  использовании... Подробнее: https://www.opennet.me/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
	> NGINX использует NODELAY. Это, считай, 70% мирового трафика. То есть ты настаиваешь на своём однобоком взгляде? Ну ок, продолжай стоять на своём, я с интересом наблюдаю за этим цирковым трюком.
	Ответить | Правка | К родителю #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 | Индекс форумов | Темы | Пред. тема | След. тема