Algoritmul lui Nagle , numit după John Nagle, este un instrument de eficiență a rețelei TCP/IP care reduce numărul de pachete care trebuie trimise prin rețea.
Lucrarea lui Nagle, Controlling IP/TCP Network Congestion ( RFC 896 ) descrie ceea ce el a numit „problema pachetelor mici”, în care o aplicație trimite în mod repetat date în bucăți mici, adesea chiar de 1 octet. Deoarece pachetele TCP au un antet de 40 de octeți ( TCP 20 de octeți, IPv4 de 20 de octeți ), acest lucru are ca rezultat transmiterea unui pachet de 41 de octeți care transportă 1 octet de sarcină utilă, ceea ce reprezintă o suprasarcină uriașă. Această situație este obișnuită într-o sesiune Telnet , unde majoritatea apăsărilor de taste generează un singur octet de date care este transmis imediat. În plus, prin legături lente, multe dintre aceste pachete pot fi în tranzit în același timp, ceea ce poate duce la congestionarea rețelei.
Algoritmul lui Nagle funcționează prin concatenarea mai multor mesaje mici de ieșire și apoi prin trimiterea lor pe toate simultan. În special, atâta timp cât există un pachet trimis pentru care expeditorul nu a primit încă nicio confirmare de livrare, expeditorul trebuie să tamponeze următoarele date de trimis până când există suficiente date pentru un pachet complet care poate fi trimis o singură dată.
unde MSS este dimensiunea maximă a blocului de date pentru un pachet TCP. MSS depinde de MTU .
Acest algoritm nu interacționează bine cu tehnologia de confirmare întârziată a TCP, care a fost introdusă în TCP cam în același timp, la începutul anilor 1980. Dacă o aplicație care utilizează ambii algoritmi stabilește două conexiuni de scriere TCP consecutive și apoi citește , aceasta din urmă nu va fi executată până când datele de la a doua scriere vor ajunge la destinație. Rezultatul este o întârziere constantă de până la 500 ms, „ întârziere ACK ”. Din acest motiv, implementarea TCP oferă de obicei o interfață pentru aplicații pentru a dezactiva algoritmul Nagle (opțiunea TCP_NODELAY).
„La nivel de utilizator, secvențele de scriere-scriere-citire pe socluri ar trebui evitate. „Scrie-citește-scrie-citește” va funcționa bine. „Înregistrare-înregistrare-înregistrare” de asemenea. Dar „scrie-scrie-citește” va înrăutăți lucrurile. Deci, dacă puteți, puneți în tampon micile pachete TCP cu date de scris și apoi trimiteți-le pe toate odată. Dacă utilizați pachetul standard UNIX I/O și „spăiți” datele care trebuie scrise înainte de fiecare citire, citirea funcționează de obicei bine.”
Problema tinygramului și sindromul ferestrei Silly sunt adesea confundate. Problema transmiterii datelor mici apare atunci când fereastra este aproape goală. Sindromul fluxului îngust apare atunci când este aproape plin.
Algoritmul este aplicabil datelor de orice dimensiune. Dacă datele care urmează să fie scrise se întind pe 2n pachete, atunci ultimul pachet va fi reținut în așteptarea ACK -ului pachetului anterior. În orice protocol de aplicație cerere-răspuns, în care datele de solicitare pot fi mai mari decât pachetul, acest lucru poate impune artificial câteva sute de milisecunde de întârziere între cerere și răspuns, chiar dacă solicitantul tamponează datele cererii înainte de a le trimite. În acest caz, solicitantul trebuie să dezactiveze algoritmul Nagle. Dacă datele de răspuns pot fi mai mari decât pachetul, respondentul trebuie, de asemenea, să dezactiveze algoritmul Nagle, astfel încât solicitantul să primească întregul răspuns prompt.
Astfel, algoritmul lui Nagle poate proteja împotriva unei aplicații scrise neglijent, dar nu va ajuta una scrisă cu atenție, care acordă o atenție adecvată tamponării; pentru o astfel de aplicație, algoritmul fie nu va avea efect, fie va avea un efect negativ din aplicație.
Aplicațiile care apreciază timpul de răspuns actualizat pot să nu funcționeze bine cu algoritmul lui Nagle. Aplicații precum jocurile online multiplayer presupun că orice acțiune din joc este trimisă imediat, în timp ce algoritmul întârzie în mod deliberat transmisia, crescând eficiența lățimii de bandă a rețelei în detrimentul întârzierii. Din acest motiv, aplicațiile cu lățime de bandă de rafală redusă folosesc de obicei TCP_NODELAY pentru a ocoli întârzierile lui Nagle.
O altă opțiune în acest caz este utilizarea UDP .