Nagles algoritm , uppkallad efter John Nagle, är ett TCP/IP -nätverkseffektivitetsverktyg som minskar antalet paket som måste skickas över nätverket.
Nagles artikel, Controlling IP/TCP Network Congestion ( RFC 896 ) beskriver vad han kallade "small packet problem", där en applikation upprepade gånger skickar data i små bitar, ofta så små som 1 byte. Eftersom TCP -paket har en 40 byte header ( TCP 20 byte, IPv4 20 byte ), resulterar detta i att ett 41 byte paket sänds med 1 byte nyttolast, vilket är en enorm overhead. Denna situation är vanlig i en Telnet- session , där de flesta tangenttryckningar genererar en enda byte med data som omedelbart överförs. Dessutom, över långsamma länkar, kan många av dessa paket vara på väg samtidigt, vilket kan leda till överbelastning i nätverket.
Nagles algoritm fungerar genom att sammanfoga flera små utgående meddelanden och sedan skicka alla på en gång. I synnerhet, så länge det finns ett skickat paket för vilket avsändaren ännu inte har fått någon bekräftelse på leverans, måste avsändaren buffra nästa data som ska skickas tills det finns tillräckligt med data för ett komplett paket som kan skickas en gång.
där MSS är den maximala datablockstorleken för ett TCP-paket. MSS beror på MTU .
Denna algoritm interagerar inte bra med TCP:s fördröjda bekräftelseteknologi, som introducerades till TCP ungefär samtidigt, i början av 1980-talet. Om en applikation som använder båda algoritmerna upprättar två på varandra följande TCP -skrivanslutningar och sedan läser , kommer den senare inte att exekveras förrän data från den andra skrivningen når sin destination. Resultatet är en konstant fördröjning på upp till 500ms, " ACK delay ". Av denna anledning tillhandahåller TCP-implementeringen vanligtvis ett gränssnitt för applikationer för att inaktivera Nagle-algoritmen (TCP_NODELAY-alternativet).
”På användarnivå bör skriv-skriv-lässekvenser på uttag undvikas. "Skriv-läs-skriv-läs" kommer att fungera bra. "Rekord-rekord-rekord" också. Men "skriv-skriv-läs" kommer att göra saken värre. Så, om du kan, buffra dina små TCP-paket med data att skriva, och skicka sedan alla på en gång. Om du använder standard UNIX I/O-paketet och "spolar" data som ska skrivas före varje läsning, fungerar läsningen vanligtvis bra."
Tinygramproblemet och Silly window-syndromet är ofta förvirrade. Problemet med att skicka små data uppstår när fönstret nästan är tomt. Narrow flow syndrom uppstår när det är nästan fullt.
Algoritmen är tillämplig på data av alla storlekar. Om data som ska skrivas sträcker sig över 2n paket, kommer det sista paketet att hållas i avvaktan på ACK för det föregående paketet. I alla begäran-svar-applikationsprotokoll, där förfrågningsdata kan vara större än paketet, kan detta på konstgjord väg lägga på flera hundra millisekunders fördröjning mellan begäran och svar, även om begäranden buffrar förfrågningsdatan innan den skickas. I det här fallet måste begäranden inaktivera Nagle-algoritmen. Om svarsdata kan vara större än paketet, måste svarsmottagaren också inaktivera Nagle-algoritmen så att förfrågaren får hela svaret omgående.
Således kan Nagles algoritm skydda mot en slarvigt skriven applikation, men det hjälper inte en noggrant skriven som ägnar ordentlig uppmärksamhet åt buffring; för en sådan applikation kommer algoritmen antingen inte att ha någon effekt, eller kommer att ha en negativ effekt från applikationen.
Applikationer som värdesätter uppdaterad svarstid kanske inte fungerar bra med Nagles algoritm. Applikationer som online multiplayer-spel förutsätter att alla åtgärder i spelet skickas omedelbart, medan algoritmen medvetet fördröjer överföringen, vilket ökar effektiviteten i nätverkets bandbredd på bekostnad av förseningar. Av denna anledning använder applikationer med låg skurbandbredd vanligtvis TCP_NODELAY för att kringgå Nagles fördröjningar.
Ett annat alternativ i det här fallet är att använda UDP .