Марк Брукер (Marc Brooker), инженер от компанията Amazon Web Services (AWS), разясни заблужденията, свързани с повишаването на ефективността при предаване на малки съобщения, при използване на алгоритъма на Нейгъл, който е по подразбиране в TCP/IP стека. Препоръките се свеждат до деактивиране на алгоритъма на Нейгъл по подразбиране, което в контекста на отделни приложения може да се направи чрез задаване на опцията TCP_NODELAY за мрежови сокети с помощта на извикването на setsockopt, каквото вече се практикува в проекти като Node.js и curl.
Алгоритъмът на Нейгъл позволява агрегация на малки съобщения за намаляване на трафика – задържа изпращането на нови TCP сегменти до получаване на потвърждение за прием на предходно изпратените данни. Например, без прилагане на агрегация при изпращане на 1 байт, допълнително се изпращат 40 байта с TCP и IP заглавки на пакета. В съвременни условия използването на алгоритъма на Нейгъл води до значително увеличение на забавянията, които са неприемливи за интерактивни и разпределени приложения.
Изложени са три основни довода в полза на използването по подразбиране на опцията TCP_NODELAY, която деактивира алгоритъма на Нейгъл:
- Несъвместимостта на алгоритъма на Нейгъл с оптимизацията „delayed ACK“, при която ACK отговорът не се изпраща веднага, а след получаване на отговорни данни. Проблемът е, че в алгоритъма на Нейгъл получаването на ACK пакет е сигнал за изпращане на агрегирани данни, а ако ACK пакетът не е получен, изпращането се извършва при настъпване на таймаут. По този начин се образува затворен кръг и ACK пакетът като сигнал не работи, тъй като другата страна не получава данни заради тяхното натрупване от страна на изпращача, а изпращачът не ги изпраща до таймаута, тъй като не получава ACK пакет.
- RFC за алгоритъма на Нейгъл е приет през 1984 година и не е създаден с параметрите на съвременни високоскоростни мрежи и сървъри в дата центровете, което води до проблеми с отзивчивостта. Закъснението между изпращането на запитването и получаването на отговора (RTT) в съвременните мрежи е 0.5 ms + няколко милисекунди при обмен на данни между дата центрове в един регион + до стотици милисекунди при изпращане по целия свят. През тези милисекунди, съвременният сървър е способен да извърши огромен обем работа.
- Съвременните разпределени приложения отдавна не изпращат единични байтове данни, а агрегиране на малки данни обикновено се реализира на ниво приложение. Дори ако размерът на полезните данни е броени байтове, размерът на изпращаната информация обикновено нараства значително след прилагане на сериализация, използване на API обвивки в JSON и изпращане с TLS шифроване. Спестяването на 40 байта не е толкова актуално.
Източник: opennet.ru
