Как отключить алгоритм нейгла

На этой стадии окно перегрузки открывается линейно - по одному сегменту за период кругового обращения. В стратегии отправки TCP окно перегрузки в принципе может запретить посылать данные, которые в его отсутствие можно было бы послать.

Алгоритм Нейгла - это лишь один из двух алгоритмов, позволяющих избежать синдрома безумного окна SWS - silly window syndrome. Смысл этой тактики в том, чтобы не допустить отправки небольших объемов данных. Как вы видели, алгоритм Нейгла пытается избежать синдрома SWS со стороны отправителя. Но требуются и усилия со стороны получателя, который не должен декларировать слишком маленькие окна.

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

Этот алгоритм впервые предложен в RFC [Nagle ]. Он требует, чтобы никогда не было более одного неподтвержденного маленького сегмента, то есть сегмента размером менее MSS. Цель алгоритма Нейгла - не дать TCP забить сеть последовательностью мелких сегментов. Вместо этого TCP сохраняет в своих буферах небольшие блоки данных, пока не получит подтверждение на предыдущий маленький сегмент, после чего посылает сразу все накопившиеся данные.

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

Условия, при которых такая ошибка возникает, обсуждались в совете 9 при рассмотрении краха приложения-партнера. Подводя итог этим рассуждениям, можно сказать, что применительно к TCP-соединениям операцию записи лучше представлять себе как копирование в очередь для передачи, сопровождаемое извещением TCP о появлении новых данных.

TCP на другом конце обязан удовлетворить это пожелание и не посылать сегменты большего размера. MSS вычисляется на основе MTU maximum transmission unit - максимальный размер передаваемого блока , как описано в совете 7. В то же время TCP не может переполнять буферы на принимающем конце. Как вы видели в совете 1, это определяется окном передачи. Если бы эти два условия были единственными, то стратегия отправки была бы проста: К сожалению, есть и другие факторы. Прежде всего, очень важно не допускать перегрузки сети.

Предположим, что в комнате, полной народу, кто-то закричал: Если же люди будут выходить по одному, то пробки не возникнет, и все благополучно покинут помещение. Для предотвращения перегрузки TCP применяет два алгоритма, в которых используется еще одно окно, называемое окном перегрузки. Максимальное число байтов, которое TCP может послать в любой момент, - это минимальная из двух величин: Обратите внимание, что эти окна отвечают за разные аспекты управления потоком.

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

Операция записи возвращает лишь ошибки, очевидные в момент вызова, а именно:. Причина большинства этих проблем - ошибка в программе. После завершения стадии разработки они почти не встречаются.

Представляет интерес не конкретный API и детали системных вызовов, а семантические вопросы, связанные с этими операциями. Как сказано в совете 6, между операциями записи и посылаемыми TCP сегментами нет взаимно-однозначного соответствия. Как именно соотносятся обращения к операции записи с протоколом TCP, зависит от системы, но все же спецификации протокола достаточно определенны и можно сделать некоторые выводы при знакомстве с конкретной реализацией.

В книге [Stevens ] содержится подробное объяснение этих алгоритмов и результаты трассировки в локальной сети. В настоящее время эти алгоритмы следует включать в любую реализацию, согласующуюся со стандартом RFC [Braden ]. Несмотря на впечатляющие результаты, реализация этих алгоритмов очень проста - всего две переменные состояния и несколько строчек кода. Детали можно найти в книге [Wright and Stevens ]. Еще один фактор, влияющий на стратегию отправки TCP, - алгоритм Нейгла.

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

Это означает, что после записи управление почти всегда быстро возвращается программе. Как упоминалось в совете 9, это имеет значение для надежности передачи данных. С точки зрения приложения данные записаны. Поэтому, помня о гарантиях доставки, предлагаемых TCP, можно считать, что информация дошла до другого конца.

Если отправляющее приложение завершает сеанс аварийно, то TCP все равно будет пытаться доставить данные. Еще один важный момент, который нужно иметь в виду, - это обработка ошибки записи. Если при записи на диск вызов write не вернул код ошибки, то точно известно, что запись была успешной. Строго говоря, это неверно. Обычно данные находятся в буфере в пространстве ядра до того момента, пока не произойдет сброс буферов на диск.

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

Авторитетным источником информации об алгоритмах избежания перегрузки является работа [Jacobson ], в которой они впервые были предложены. Джекобсон привел результаты нескольких экспериментов, демонстрирующие заметное повышение производительности сети после внедрения управления перегрузкой.

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

Если вы начали с одного сегмента, то последовательные размеры окна будут составлять 1, 2, 4, 8 и т. Его работа предполагает, что соединение достигло равновесного состояния, и сеть постоянно зондируется - не увеличилась ли пропускная способность.

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

Традиционная реализация подробно описана в системе BSD. Она часто рассматривается как эталонная, и ее исходные тексты доступны. Исходные тексты оригинальной реализации для системы 4. Подробные пояснения к исходному тексту вы найдете в книге [Wright and Stevens ]. Когда пользователь выполняет запись в TCP-соединение, данные сначала копируются из буфера пользователя в память ядра. Дальнейшее зависит от состояния соединения. О том, как принимается решение, будет сказано ниже. Сначала рассмотрим операцию записи с точки зрения приложения.

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

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

Одна из основных целей стратегии отправки данных в TCP - максимально эффективное использование имеющейся полосы пропускания. TCP посылает данные блоками, размер которых равен MSS maximum segment size - максимальный размер сегмента.

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

Хочется думать, что если операция записи n байт вернула значение n , то все эти n байт, действительно, переданы на другой конец и, возможно, уже подтверждены. Увы, это не так. TCP посылает столько данных, сколько возможно или ничего , и немедленно возвращает значение п.

Но суть в том, что после возврата из wri t e уже не будет никаких сообщений об ошибках. Можно признать потерю не сброшенных на диск данных неизбежной, но не более вероятной, чем отказ самого диска. При работе с TCP получение кода ошибки от операции записи - очень редкое явление.

Это называется затором congestion collapse. Чтобы избежать перегрузки, TCP не посылает по простаивающему соединению все сегменты сразу. Сначала он посылает один сегмент и постепенно увеличивает число неподтвержденных сегментов в сети, пока не будет достигнуто равновесие. Эту проблему можно наглядно проиллюстрировать таким примером.

Если TCP неожиданно пошлет в сеть большое число сегментов, может исчерпаться память маршрутизатора, что повлечет за собой отбрасывание датаграмм. А из-за этого начнутся повторные передачи, что еще больше загрузит сеть. В худшем случае сеть будет загружена настолько, что датаграммы вообще нельзя будет доставить.