„Amazon Web Services“ (AWS) inžinierius Marcas Brookeris aptarė klaidingas nuomones apie tai, kaip „Nagle“ algoritmas, numatytasis „Amazon Web Services“ (AWS) algoritmas, pagerina mažų pranešimų efektyvumą. TCP/IP Rekomendacijos susiveda į Nagle'o algoritmo išjungimą pagal numatytuosius nustatymus, o atskirų programų kontekste tai galima padaryti nustatant TCP_NODELAY parinktį tinklo lizdams naudojant „setsockopt“ iškvietimą, kuris jau seniai daromas tokiuose projektuose kaip „Node.js“ ir „curl“.
Nagle algoritmas leidžia agreguoti nedidelius pranešimus, siekiant sumažinti srautą – sustabdo naujų TCP segmentų siuntimą, kol bus gautas patvirtinimas apie anksčiau išsiųstų duomenų gavimą. Pavyzdžiui, netaikant agregavimo, siunčiant 1 baitą papildomai siunčiama 40 baitų su TCP ir IP paketų antraštėmis. Šiuolaikinėmis sąlygomis naudojant Nagle algoritmą pastebimai padidėja vėlavimai, kurie yra nepriimtini interaktyvioms ir paskirstytoms programoms.
Yra trys pagrindinės priežastys, kodėl reikia naudoti numatytąją TCP_NODELAY parinktį, kuri išjungia Nagle algoritmą:
- Nagle algoritmo nesuderinamumas su „delayed ACK“ optimizavimu, kai ACK atsakymas siunčiamas ne iš karto, o gavus atsakymo duomenis. Problema ta, kad pagal Nagle algoritmą ACK paketo atėjimas yra signalas siųsti suvestinius duomenis, o jei ACK paketas negaunamas, siuntimas atliekamas, kai įvyksta laikas. Taigi susidaro užburtas ratas ir ACK paketas kaip signalas neveikia, nes kita pusė negauna duomenų dėl jų kaupimosi siuntėjo pusėje, o siuntėjas jų neišsiunčia prieš pasibaigiant skirtajam laikui, nes nesiunčia gauti ACK paketą.
- Nagle'o algoritmo RFC buvo priimtas 1984 m. ir nėra skirtas šiuolaikinių didelės spartos tinklų parametrams. serveriai duomenų centruose, o tai sukelia reagavimo problemų. Šiuolaikiniuose tinkluose užklausos išsiuntimo ir atsakymo gavimo (RTT) vėlavimas yra 0.5 ms plius kelios milisekundės, kai duomenys keičiasi tarp to paties regiono duomenų centrų, ir iki šimtų milisekundžių, kai duomenys siunčiami visame pasaulyje. Per šias milisekundes šiuolaikinis serveris gali atlikti didžiulį darbo kiekį.
- Šiuolaikinės paskirstytos programos nebesiunčia pavienių duomenų baitų, o mažų duomenų kaupimas dažniausiai įgyvendinamas programų lygmeniu. Net jei naudingosios apkrovos dydis yra tik baitų klausimas, tikrasis siunčiamos informacijos dydis žymiai padidėja pritaikius serializavimą, naudojant JSON API apvyniojimą ir siuntimą naudojant TLS šifravimą. 40 baitų išsaugojimas tampa mažiau aktualus.
Šaltinis: opennet.ru
