Ai avut vreodată un fișier încărcat și viteza încet, dar cu siguranță crește, apoi, la un moment dat, scade brusc, apoi crește din nou? Încărcarea unui fișier într-un flux nu oferă o viteză completă a canalului? Rulați clientul torrent și ping în joc sărind puternic? Utilizați un modem 3G (sau o altă linie cu pierderi relativ mari de pachete) și nu îl puteți tolera?
Sigur că ți-ai dat vina pe routerul tău pentru orice, sau ai acuzat-o pe furnizorul tău de un model de curbare? Ea afectează, dar nu sunt de vină.
Deci, întâlniți:
TCP Congestion Control sau algoritmul de evitare a congestiei TCP.
Ce este?
Pe scurt, algoritmi care încearcă să facă tot posibilul pentru a furniza cea mai rapidă viteză de transfer de date între două noduri care transmit date prin TCP. Ele controlează dimensiunea ferestrei TCP și pot viza RTT (ora rotundă a turului - timpul de la trimiterea cererii la primirea răspunsului), pierderea pachetelor, timpul de așteptare pentru trimiterea pachetului din coada de așteptare etc. Fiecare algoritm se comportă diferit în această sau în situația respectivă și nu există nici unul universal.
Ce sunt algoritmii?
Sunt mulți. În kernelul Linux 3.7 există:
- BIC TCP
- CUBIC TCP
- TCP de mare viteză
- H-TCP
- TCP Hybla
- TCP-Illinois
- TCP Low Priority
- TCP Vegas
- TCP NewReno
- TCP Veno
- TCP Westwood +
- YEAH-TCP
BIC cubica, de mare viteză, H-TCP, NewReno, Illinois - acești algoritmi sunt concepute pentru așa-numitele rețele lungi de grăsime - lung (și, prin urmare, cu RTT ridicat) și rețele rapide. TCP Hybla mare comportă pe link-ul prin satelit, mai degrabă veno este proiectat pentru rețele wireless cu pierderi mari de pachete. TCP Low Priority poate fi numit greu algoritm de congestie. El nu face mult, ci doar încercarea de a trimite o coadă de pachete, TCP Vegas este uneori folosit pe servere cu un număr mare de conexiuni, deoarece oferă o viteză aproape constantă, deși nu este ideală. Westwood + - algoritm combinat, YEAH-TCP este cel mai tânăr dintre ei, dar cel mai interesant, pentru că se comportă mai mult sau mai puțin în toate cazurile.
Mai multe informații despre algoritmi pot fi găsite în post casperrr
După cum vedeți, CUBIC rămâne în urmă. El a mărit în mod semnificativ RTT cu privire la utilizarea completă a canalului 3G, în timp ce Westwood + și NewReno se descurcă mai mult sau mai puțin cu această problemă.
Să aruncăm o privire asupra numărului de retransmisii:
După cum se poate observa din grafic, CUBIC are un număr relativ mare de retransmisii
În același timp, este în plumb în rata de transmisie de date pe unitate de timp.
Ce înseamnă asta? Aceasta înseamnă că, folosind Westwood + sau NewReno, puteți naviga confortabil pe Internet în timp ce descărcați un fișier mare.
Test de canal de mare viteză
În transmiterea eficientă a datelor, în funcție de RTT, YeAH
Dependența de transmiterea efectivă a datelor și pierderea pachetelor, din nou, YeAH ocupă locul întâi
Din păcate, cu YeAH pe nucleul 3.7 unele probleme, după un timp se cântărește interrupt'ami software-ul sistemului. Acest comportament nu este respectat la 3.6.
Cum se schimba?
Este ușor să modificați algoritmul de congestie, doar o singură linie:
sysctl -w net.ipv4.tcp_congestion_control = westwood
Dacă în loc de westwood, puteți introduce nume din /lib/modules/.../kernel/net/ipv4/tcp_....ko fără prefixul tcp_.
În loc să încheiem
Pe canalele de acasă wifi, recomand să folosesc Westwood sau Veno. Pentru canalele cu fir, YeAH (dacă nu aveți probleme cu el), H-TCP sau Illinois poate fi o alegere bună.
Câteva sfaturi. Dacă aveți deja un kernel 3.6+, asigurați-vă că ați activat net.ipv4.tcp_fastopen. Nu vor exista probleme cu serverele incompatibile, iar strângerea de mâini pentru serverele acceptate se va accelera.
De asemenea, vă recomandăm să setați net.ipv4.tcp_slow_start_after_idle la 0, aceasta va adăuga viteză pentru SPDY și alte conexiuni de tip keep-alive.
Articole similare
Trimiteți-le prietenilor: