Преди няколко дни, Марк Брукър, AWS инженер, критикуваха и адресираха проблемите с които винаги сте се сблъсквали с въпроса за ефективността при прехвърлянето на малки съобщения когато използвате алгоритъма на Nagle.
И споменава, че днес в разпределените системи латентността е критичен фактор което може значително да повлияе на производителността и потребителското изживяване и едно от ключовите решения е настройването на параметри като TCP_NODELAY.
Марк споменава, че въпреки че «проблеми със закъснението, които бяха коригирани бързо да активирайте тази проста опция за сокет » TCP_NODELAY, Това не е активирано, тъй като опцията по подразбиране в TCP/IP стека е алгоритъмът на Nagle.
Алгоритъмът на Nagle, формулиран в RFC896 от Джон Нагъл през 1984 г., насочени към справяне с ефективността при предаване на данни в TCP мрежи. Това позволява да се добавят малки съобщения за намаляване на трафика, спирайки изпращането на нови TCP сегменти, докато не бъде получено потвърждение за получаване на предварително изпратените данни. Например, без прилагане на агрегиране, изпращането на 1 байт изпраща допълнителни 40 байта с TCP и IP заглавки на пакети. В съвременните условия използването на алгоритъма на Nagle води до забележимо увеличаване на забавянията, което е неприемливо за интерактивни и разпределени приложения.
Една от възникналите сложности с прилагането на алгоритъма на Nagle беше негов взаимодействие със забавени ACK. Докато Nagle се опитваше да оптимизира размера на изпратените пакети, забавените ACK забавиха изпращането на потвърждения на получените пакети. Тази комбинация може да генерира проблеми със закъснението в приложения, чувствителни към този фактор.
Освен, че, Марк цитира три основни причини за използването на TCP_NODELAY по подразбиране, вместо Nagle, което предполага да бъде деактивирано:
- Несъвместимост с оптимизацията „Delayed ACK“: Алгоритъмът на Nagle е в конфликт със стратегията "отложено ACK", при която ACK отговорът не се изпраща веднага, а след получаване на данните за отговора. Проблемът е, че в алгоритъма на Nagle пристигането на ACK пакет е сигнал за изпращане на агрегирани данни. Ако пакетът ACK не бъде получен, изпращането се извършва, когато изтече времето за изчакване. Това създава цикъл на пакета ACK, тъй като сигналът не работи, защото другата страна не получава данните поради натрупването им от страната на подателя, а подателят не ги изпраща преди изтичането на времето за изчакване поради неполучаване на пакета ACK.
- RFC възраст на алгоритъма на Nagle: RFC за алгоритъма на Nagle е приет през 1984 г. и не е предназначен за съвременни високоскоростни мрежи и сървъри в центрове за данни, което създава проблеми с отзивчивостта. В съвременните мрежи забавянето между изпращане на заявка и получаване на отговор (RTT) е много кратко, което позволява на съвременните сървъри да извършват огромно количество работа през тези кратки интервали от време.
- Промени в модела за изпращане на данни: Съвременните разпределени приложения вече не изпращат отделни байтове данни и агрегирането на малки данни обикновено се прилага на ниво приложение. Дори ако размерът на полезния товар е минимален, действителният размер на изпратената информация се увеличава значително след прилагане на сериализация, използване на JSON API и изпращане с помощта на TLS криптиране. Следователно спестяването на 40 байта става по-малко уместно в сравнение с подобрената производителност и отзивчивост чрез деактивиране на алгоритъма на Nagle.
Ето защо Brooker призова за деактивиране на алгоритъма Nagle по подразбиране. Това може да се постигне чрез задаване на опцията TCP_NODELAY за мрежови сокети с помощта на извикването setockopt, както отдавна се прави в проекти като Node.js и curl.
И накрая, ако се интересувате да научите повече за него, можете да се консултирате с подробностите в следваща връзка.