Nagles algoritme , opkaldt efter John Nagle, er et TCP/IP -netværkseffektivitetsværktøj, der reducerer antallet af pakker, der skal sendes over netværket.
Nagles papir, Controlling IP/TCP Network Congestion ( RFC 896 ) beskriver, hvad han kaldte "small packet problem", hvor en applikation gentagne gange sender data i små bidder, ofte så små som 1 byte. Da TCP -pakker har en 40 byte header ( TCP 20 byte, IPv4 20 byte ), resulterer dette i, at en 41 byte pakke bliver transmitteret med 1 byte nyttelast, hvilket er en enorm overhead. Denne situation opstår ofte i en Telnet- session., hvor de fleste tastetryk genererer én byte med data, der straks transmitteres. Derudover kan mange af disse pakker over langsomme links være i transit på samme tid, hvilket kan føre til overbelastning af netværket.
Nagles algoritme fungerer ved at sammenkæde flere små udgående beskeder og derefter sende dem alle på én gang. Især så længe der er en sendt pakke, som afsenderen endnu ikke har modtaget bekræftelse på, skal afsenderen buffer de næste data, der skal sendes, indtil der er nok data til en komplet pakke, der kan sendes én gang.
hvor MSS er den maksimale datablokstørrelse for en TCP-pakke. MSS afhænger af MTU .
Denne algoritme interagerer ikke godt med TCP's delayed acknowledgement-teknologi, som blev introduceret til TCP omkring samme tid, i begyndelsen af 1980'erne. Hvis en applikation, der bruger begge algoritmer, etablerer to på hinanden følgende TCP - skriveforbindelser og derefter læser , vil sidstnævnte ikke blive udført, før dataene fra den anden skrivning når sin destination. Resultatet er en konstant forsinkelse på op til 500ms, " ACK delay ". Af denne grund giver TCP-implementeringen normalt en grænseflade til applikationer til at deaktivere Nagle-algoritmen (TCP_NODELAY-mulighed).
"På brugerniveau bør skrive-skrive-læse-sekvenser på stikkontakter undgås. "Skriv-læs-skriv-læs" vil fungere godt. "Record-Record-Record" også. Men "skriv-skriv-læs" vil gøre tingene værre. Så hvis du kan, buffer dine små TCP-pakker med data til at skrive, og send dem alle på én gang. Hvis du bruger standard UNIX I/O-pakken og "flush" de data, der skal skrives før hver læsning, fungerer læsningen normalt fint."
Tinygram-problemet og Silly window-syndromet er ofte forvirrede. Problemet med at videregive små data opstår, når vinduet er næsten tomt. Narrow flow syndrom opstår, når det er næsten fuldt.
Algoritmen kan anvendes til data af enhver størrelse. Hvis dataene, der skal skrives, strækker sig over 2n pakker, vil den sidste pakke blive tilbageholdt i afventning af ACK fra den forrige pakke. I enhver anmodnings-svar-applikationsprotokol, hvor anmodningsdataene kan være større end pakken, kan dette kunstigt pålægge flere hundrede millisekunders forsinkelse mellem anmodning og svar, selv hvis anmoderen bufre anmodningsdataene, før de sendes. I dette tilfælde skal anmoderen deaktivere Nagle-algoritmen. Hvis svardataene kan være større end pakken, skal responderen også deaktivere Nagle-algoritmen, så rekvirenten modtager hele svaret med det samme.
Således kan Nagles algoritme beskytte mod en sjusket skrevet applikation, men det hjælper ikke en omhyggeligt skrevet en, der er opmærksom på buffering; for en sådan applikation vil algoritmen enten ikke have nogen effekt, eller vil have en negativ effekt fra applikationen.
Programmer, der værdsætter opdateret responstid, fungerer muligvis ikke godt med Nagles algoritme. Applikationer såsom online multiplayer-spil antager, at enhver handling i spillet sendes med det samme, mens algoritmen bevidst forsinker transmissionen, hvilket øger netværkets båndbreddeeffektivitet på bekostning af forsinkelse. Af denne grund bruger applikationer med lav burstbåndbredde typisk TCP_NODELAY til at omgå Nagles forsinkelser.
En anden mulighed i dette tilfælde er at bruge UDP .