Optimeeri TCP/IP-d, et vähendada mängudes viivitust

Kui sa temaga iga päev tülitsed Lag, kokutamine ja kõrge pingSa pole üksi. Selle halva kogemuse taga veebis mängides, videokõnesid tehes või kaugtööl on väga selge süüdlane: sinu koduvõrgu ja TCP/IP protokolli konfiguratsiooni kombinatsioon sinu seadmetes ja serverites.

Optimeeri TCP/IP-d vähendada viivitust See ei ole lihtsalt paari "maagilise" seadistuse timmimine. Sa pead aru saama, kuidas sellised mõisted nagu ... toimivad. MTU, MSS, TCP aken, latentsus või puhverpaisumineJa seejärel rakendage oma arvutis, ruuteris, WiFi-võrgus ja isegi pilveserverites või virtuaalmasinates konkreetseid muudatusi. Vaatame seda samm-sammult, aga praktilise mõtteviisiga: mis iga asi on ja mida saate teha, et teie ühendus kiiremini reageeriks.

Peamised TCP/IP kontseptsioonid, mis mõjutavad viivitust

Oma ühendusest maksimumi võtmiseks on kasulik mõista mõnda asja. TCP/IP põhiparameetrid mis otseselt mõjutavad pingimist, stabiilsust ja jõudlust mängudes, videokõnedes või kaugjuurdepääsus.

MTU, fragmentatsioon ja LSO

La MTU (maksimaalne ülekandeüksus) See on võrguliidesest fragmenteerimata lahkuva paketi maksimaalne suurus baitides. Enamikus Etherneti võrkudes (ja Azure'i või Google Cloudi virtuaalmasinates) on vaikeväärtus 1500 baiti, mis hõlmab võrgu päiseid ja andmeid.

Kui pakett ületab selle MTU, jagab IP-kiht selle mitmeks väiksemaks fragmendiks. IP-fragmentatsioon See hõlmab rohkem protsessori ja mälu tööd nii masinas, mis andmeid fragmenteerib, kui ka selles, mis fragmendid saabumisel uuesti kokku paneb. See toob kaasa täiendava latentsusaja ja jõudluse languse, eriti suure liikluse korral.

Lisaks on seal kuulus bitt „Ära fragmenteeri” (DF) IP-päises. Kui see on lubatud ja vahepealne ruuter saab paketi, mis on suurem kui selle MTU, siis fragmenteerimise asemel visatakse see minema ja saadetakse tagasi ICMP-sõnumiga "Fragmenteerimine vajalik". Seda kasutatakse MTU marsruudi tuvastamine (PMTUD)Aga kui tulemüür need ICMP-paketid blokeerib, jätkab saatja liiga suurte pakettide saatmist, põhjustades viivitusi ja korduvedusid.

Sellistes keskkondades nagu Azure või Google Cloud kipuvad fragmenteeritud paketid kaotama ka eeliseid, mis tulenevad kiirendatud võrgudSR-IOV ja SmartNIC-id. Neid töödeldakse hüperviisori aeglase marsruudi kaudu, kasutades rohkem värinhalvem latentsus ja vähem pakette sekundis. Seetõttu on üldine soovitus Vältige killustumist, reguleerides MTU-d ja MSS-i õigesti ja mitte MTU-d liiga palju paisutada, kui nende vahel on tulemüüre või VPN-e.

Teisest küljest funktsioon Suur saatmiskoormus (LSO) See võimaldab operatsioonisüsteemi TCP/IP-pinul genereerida suuri "superpakette", mis seejärel võrgukaardi poolt sisemiselt MTU järgi fragmenteeritakse. See vähendab oluliselt protsessori koormust, kuigi liikluse jäädvustuses võib näha pealtnäha tohutuid kaadreid, mis ei viita võrgu fragmenteerimisele, vaid pigem sellele, et fragmenteerimine toimub adapteris endas.

MSS, PMTUD ja VPN

El TCP MSS (maksimaalne segmendi suurus) See määrab, mitu baiti kasutatavat andmemahtu mahub igasse TCP segmenti, välja arvatud IP ja TCP päised. Tavaliselt arvutavad süsteemid MSS-i järgmiselt:

MSS = MTU - (tamaño cabecera IP + tamaño cabecera TCP)

MTU-ga 1500 ja IPv4+TCP päistega 20+20 baiti on tüüpiline MSS 1460 baitiSee väärtus lepitakse kokku TCP kolmepoolse käepigistuse ajal ja kumbki pool pakub oma. Ühendus kasutab kahest väärtusest madalamat.

Siiski võib teel olla seadmeid (tulemüürid, ruuterid, VPN-lüüsidjne) väiksema MTU-ga, mis sisuliselt sunnib vähendama MSS-i. Siin ongi koht, kus MTU avastamise tee (PMTUD)Kui ruuter ei saa paketti edastada, kuna see on liiga suur ja DF-bitt on seatud, siis see kustutab selle ja saadab ICMP-teate "Fragmentation Needed", mis näitab toetatud maksimaalset MTU-d, et allikas vähendaks selle suurust.

Kui need ICMP-paketid blokeeritakse, siseneb ühendus edasisaatmise ja kadumise tsüklisse, mille tulemuseks on Lag, korduseksdastamine ja lõputud laadimisajadSeetõttu pole alati hea mõte arvutites või virtuaalmasinates MTU-d kergekäeliselt suurendada ilma kogu teed või tulemüüripoliitikat kontrollimata.

Sotsiaalmeedias koos IPsec VPN Või muude tunnelite puhul vähendavad täiendavad päised andmete jaoks saadaolevat ruumi, seega on tunneli killustumise ja sellega seotud viivituste vältimiseks soovitatav kasutada väiksemaid MTU-sid ja MSS-e (nt MTU 1400 ja MSS ~1350 tüüpilistes tunnelites).

Latentsus, RTT ja TCP aken

Kuulus "ping" pole midagi muud kui edasi-tagasi latentsus (RTT) kahe punkti vahel. Füüsilisel tasandil piirab seda valguse levimiskiirus kius (umbes 200 km millisekundis) ja andmete tegelik liikumistee. See on harva sirgjoon.

TCP-s määratakse ühe ühenduse maksimaalne teoreetiline läbilaskevõime selle põhivalemi abil:

rendimiento máximo ≈ tamaño de ventana TCP / RTT

La TCP aken See on andmemaht, mis saatjal võib olla "lennul" ilma kinnitust (ACK) saamata. 65 535-baidise akna ja 1460 MSS-i korral saab enne ACK ootamist saata ainult umbes 45 paketti. Kui RTT on kõrge (näiteks 80–160 ms mandrite vahel), jääb skaleerimata aken suure läbilaskevõimega ühenduste ärakasutamiseks kaugeltki ebapiisavaks.

Vaikimisi on TCP päise aknaväli 16 bitti, mis piirab selle maksimaalset väärtust 65 535 baitini. Tänapäeva võrkude jaoks on see naeruväärne, seega aastaid tagasi võeti kasutusele [puuduv teave - tõenäoliselt konkreetne funktsioon või meetod]. TCP akna skaleerimine, mis rakendab sellele väärtusele korrutustegurit 2^na ja lubab sadade MB või isegi GB suuruseid aknaid.

Sellistes süsteemides nagu Windows või Linux hallatakse akna skaleerimist automaatselt eelmääratletud sätetega (automaatne häälestamine) ning seda saab vaadata või muuta selliste käskude abil nagu Get-NetTCPSetting o sysctlAgressiivsemad tasemed (nt "eksperimentaalne") võimaldavad hiiglaslikke aknaid ja võivad oluliselt parandada jõudlust pikamaavõrkudes, eeldusel, et pakettide kadu ei ole liiga suur.

Kiirendatud võrgud, RSS ja GRO/TSO

Pilveplatvormidel (Azure, Google Cloud jne) tuginevad traditsioonilised võrguliidesed iga paketi töötlemisel, reeglite rakendamisel, kapseldamisel ja dekapseldamisel suuresti hostprotsessorile. Selle tulemuseks on hüperviisori jõhker koormus kui liiklust on palju ja see tekitab ebastabiilse latentsuse.

Sellepärast nn. kiirendatud võrgudNeed põhinevad sellistel tehnoloogiatel nagu SR-IOV ja FPGA-dega SmartNIC-kaardid. Idee seisneb selles, et tarkvaraliselt määratletud võrgupinu oluline osa töötab NIC-riistvaral ja andmeliiklus saab virtuaalmasinast kaardile minna praktiliselt otse, möödudes hosti virtuaalsest lülitist.

See pakub mitut eelis:

• Vähem latentsust, rohkem PPS-i.
• Vähem värinat
• Väiksem protsessori tarbimine nii hostis kui ka virtuaalmasinas.

Siiski on olulisi üksikasju. Näiteks paljud kiirendatud võrgusüsteemid ei töötle fragmenteeritud pakette kiire marsruudi kaudu; kui IP-fragmentatsioon esineb, suunatakse see liiklus aeglase marsruudi kaudu, millel on sellest tulenev mõju jõudlusele.

Külalisoperatsioonisüsteemi poolel on oluline, et sellised tehnoloogiad nagu lubatud oleksid. Vastuvõtupoolse skaleerimise (RSS)mis jaotab sissetulevate pakettide töötlemise mitme protsessori südamiku vahel ning segmenteerimise ja agregeerimise allalaadimised, näiteks TSO (edastussegmenteerimise mahalaadimine) ja GRO/LRO (üldine vastuvõtu mahalaadimine)mis vähendab pakettide arvu, mida protsessor peab otse töötlema.

TIME_WAIT ja sokli taaskasutamine

Teine vähemtuntud, kuid oluline TCP jõudlustegur on olek OOTAMISTIMEKui TCP-ühendus suletakse tavapäraselt, siis viimase ACK-i saatva lõpp-punkti oodatakse kümnete või isegi sadade sekundite jooksul TIME_WAIT. Selle aja jooksul hoiab süsteem sokli reserveerituna, et vanast ühendusest pärit hilinenud paketid uuesti ei ilmuks ega läheks segi uue seansiga.

Tihedalt kasutatavatel serveritel või masinatel on lihtne koguneda tuhandeid või kümneid tuhandeid sokleid ajas TIME_WAITSee võib ammendada ajutiste portide vahemiku ja põhjustada vigu uute ühenduste avamisel. Seetõttu võimaldavad paljud süsteemid muuta nii TIME_WAIT kestust kui ka portide vahemikku, aga ka teatud korduvkasutuspoliitikaid.

Agressiivsemat tehnikat, mida toetavad mõned kernelid (näiteks Windows Server Azure'is), nimetatakse TIME_WAIT mõrvKui saabub uus SYN, mille järjekorranumber on oluliselt suurem kui vanal ühendusel, saab süsteem sundida sokli TIME_WAIT ajal sulguma ja uue ühenduse kohe vastu võtma. See suurendab skaleeritavust, kuid valesti konfigureerituna võib see põhjustada koostalitlusvõime probleemid teatud konservatiivsemate TCP-pinudega.

Miks ping teie igapäevaelus nii oluline on?

Lisaks teooriale mõjutab latentsus otseselt peaaegu kõike, mida me tänapäeval internetis teeme. Lihtsalt "600 Mbps" kiirusest ei piisa; kui vastus on aeglane, kannatab kogemus. Vaatame mõningaid juhtumeid, kus a "Korralik" ping teeb kõik vahet.

Veebimängud ja "mängitavad" pingitasemed

Võistlusmängudes on iga millisekund arvel. ping alla 20 ms See on praktiliselt ideaalne: toiminguid registreeritakse peaaegu reaalajas ja viivitust on vaevu märgata. 20–50 ms vahel on kogemus väga hea. Kui minna 50–100 ms-ni, võib märgata kerget desünkroniseerumist, eriti kui mängid kaugserverites.

Alates 100-300 ms Algavad tõsised probleemid: hilinevad kaadrid, viivitusega nähtavad liikumised, võidusõidumängus "põrkavad" autod jne. Üle 300 ms muutub mäng pigem piinamiseks kui millekski muuks, eriti tulistamis-, võidusõidu- või spordimängudes.

Suurt mõju avaldab ka mängu tüüp. FPS- ja võidusõidumängud Võistlemiseks on praktiliselt kohustuslik, et see oleks alla 50 ms; veebipõhistes spordimängudes on samuti soovitav jääda alla 30–40 ms. Siiski MMO-d või käigupõhised strateegiamängud150–200 ms pingidega saab „ellu jääda“ ilma mängu katkestamata, kuigi kogemus pole kunagi nii sujuv. Kui mängid Windowsis, võid olla huvitatud õppimisest, kuidas seda teha. Sisendviivituse vähendamine Windows 11-s võistlusmängudes reageerimisvõime parandamiseks.

Videokõned, ekraani jagamine ja VoIP-kõned

Videokõnedes Zoomi, Teamsi, Skype'i või sarnaste platvormidega on ping samuti ülioluline. Ideaalis peaks see olema umbes... 20-40 mskus vestlus kulgeb loomulikult, ilma kattumisteta. Enamik kasutajaid talub kuni umbes 100 ms, kuigi rääkimisel on juba märgata väikeseid viivitusi.

Kui ping ületab 100 msSa hakkad tahtmatult teist inimest segama. Vastused saabuvad ajutise kajaga ja ebamugavad vaikused muutuvad sagedaseks. Lisaks, kui ühenduse ribalaius on piiratud või WiFi on halb, lisanduvad video- ja helikatkestused.

koos ekraani jagamine või kaugjuhtimine Mõju on sarnane. Iga klõpsu ja hiireliigutuse registreerimine kaugekraanil võtab aega. Kõrgete pingete korral tundub arvuti aeglane. See on uskumatult frustreeriv kõigile, kes püüavad produktiivselt töötada.

Asjade internet, kodune automatiseerimine ja kaugtöö

aasta ökosüsteemis Asjade internet ja nutiseadmed (kõlarid, lambipirnid, kaamerad, pistikud, robotid, lemmikloomade söögimajad jne) mängib latentsus samuti olulist rolli. Kuigi tule sisselülitamine 500 ms viivitusega ei ole dramaatiline, muutub see väga märgatavaks, kui ühendate mitu toimingut või suhtlete häälega (Alexa, Google Assistant).

Kaugtööl olles muudab pideva viivitusega kaugtöölaudadele, serveritele või pilverakendustele juurdepääs iga ülesande tüütuks. Paljud inimesed arvavad, et see on "kiiruse puudumine", kuigi tegelikult on see lihtsalt... kõrge ja/või väga varieeruv latentsus (värin) põhjustatud küllastunud WiFi-st, kokkujooksnud ruuteritest või halbadest marsruutidest serverisse.

Latentsus ja turvalisus: kaudne mõju

Suur latentsus iseenesest ei tähenda veel otsene turvariskSellel võib aga olla kõrvalmõjusid. Kui jälgimissüsteemid, sissetungi avamise süsteemid või tulemüürid saavad teavet liiga hilja, võivad nad rünnakule liiga hilja reageerida või isegi kriitilisi sündmusi märkamata jätta.

Samuti, kui kasutajad viivituse pärast meeleheitlikult muretsema hakkavad, kipuvad nad turvakontrollidest "mööda minema": Nad keelavad tulemüüri, desinstallivad viirusetõrje või avavad juhuslikult porte. ruuteril, et proovida seda "kiiremaks" muuta. Just seal võib halb võrgukogemus avada tarbetuid uksi reaalsetele ohtudele.

Koduvõrkude kõrge latentsuse peamised põhjused

Mängus või kiirustestis nähtav ping on paljude tegurite summa: operaator, interneti marsruut, sihtserver... aga kodus on päris palju tüüpilisi probleeme, mida saad ise kontrollida.

Halb WiFi leviala ja häired

Enamik meist ühendub nüüd peaaegu eranditult WiFi kaudu ja just sealt probleemid algavadki. Üks nõrk või häiretega täidetud signaal See mitte ainult ei vähenda kiirust, vaid suurendab ka latentsust ja värinat, kuna seadmed peavad pakette uuesti edastama, modulatsiooni vähendama, ootama kanali vabanemist jne.

Kui asute ruuterist kaugel, mitme seina taga või olete ümbritsetud samal kanalil asuvatest naabervõrkudest, kannatab teie ping. Lisaks, mida rohkem kliente on pääsupunktiga ühendatud, seda pikem on ooteaeg, enne kui igaüks neist suhtlema hakkab. Ja aeglased kliendid mõjutavad teisi negatiivselt. Uurige välja, mitu seadet on teie WiFi-võrgus probleemsete klientide tuvastamiseks.

Sellised funktsioonid on siin üsna kasulikud Eetriaja õiglusmis jaotavad eetriaega seadmete vahel nii, et aeglasemad ei monopoliseeriks raadiot. Sellegipoolest, mängimiseks ja lauatelefonilt töötamiseks kasutage võimaluse korral [alternatiivi]. Etherneti kaabel ja jäta WiFi kõigile teistele.

Aegunud või ülekoormatud ruuter

Vana ruuter aegunud püsivara või väga lihtsa riistvaraga võib saada oluliseks pudelikaelaks. Kui ruuteri protsessor on NAT-i, tulemüüri, QoS-i ja P2P-liikluse haldamisel ülekoormatud, siis... järjekorra viivitus ja puhverpaisuminePaketid kogunevad hiiglaslikku puhvrisse ja saadetakse välja märkimisväärse viivitusega, rikkudes pingi.

Värskenda püsivara, keela mittevajalikud funktsioonid ja vajadusel küsi oma operaatorilt asendusseadet või osta uus. Kõige võimsam neutraalne ruuter See tähistab sageli pöördepunkti. Samuti on hea mõte see aeg-ajalt taaskäivitada, et mäluolekud ja võimalikud lekked kustutada.

Allalaadimised ja muud ribalaiust tarbivad seadmed

Kui teie võrgus on mitu seadet, mis laadivad intensiivselt alla (P2P, värskendused, 4K voogesitus, pilvevarundused), on normaalne, et teie pingi hüppedProbleem pole niivõrd selles, et "megabaidid saavad otsa", vaid selles, kuidas ruuter väljaminevaid järjekordi haldab.

Lahendus hõlmab kahte teed:

• Ühelt poolt parem kontroll taustal allalaaditava sisu üle (arvuti, mobiiltelefonid, konsoolid, NAS...).
• Teisest küljest aktiveerige ja reguleerige õigesti QoS ja puhverpaisumise vastane kaitse ruuterist, nii et interaktiivsel liiklusel (mängud, VoIP, videokõned) on prioriteet massiivsete allalaadimiste ees.

VPN, puhverserver, tulemüür ja taustaprogrammid

The VPN Need on väga kasulikud liikluse krüpteerimiseks või geopiirangute möödahiilimiseks, kuid lisavad peaaegu alati latentsust, kuna teie ühendus läheb läbi vahendajaserveri. Kui VPN on tasuta või halva kvaliteediga, võib see pingi jaoks lausa surmav olla. Sama kehtib teatud... volikirju.

Tulemüürid, nii arvutis kui ka ruuteris, lisavad samuti latentsust, kontrollides iga paketti, ja kui need on valesti konfigureeritud, võivad need ühendust ülemäära aeglustada. Lisaks sellele... taustaprotsessid (Windowsi värskendused, pilvekliendid, mängude paranduste allalaadimine jne), mis röövivad ribalaiust ilma, et te seda isegi märkaksite.

Pahavara ja ohustatud seadmed

Pahavaraga nakatunud arvuti võib genereerida varjatud liiklust (rämpspost, DDoS-rünnakud, kaevandamine, andmete allalaadimine) või tarbida palju protsessori ja ketta ressursse, mõjutades ühenduse kvaliteeti. Kui märkate, et Kõik on aeglane ja ping tõuseb ilma nähtava põhjuseta.Soovitatav on kõigis seadmetes teha põhjalik skannimine usaldusväärse viirusetõrjeprogrammiga. Lisaks on soovitatav järgida parimaid tavasid säilitada terve võrguinfrastruktuur ja vältige kahjustatud seadmeid.

Latentsuse mõõtmise ja probleemide tuvastamise tööriistad

Enne millegi muutmist on oluline teha täpsed mõõtmised. Ära toetu ainult oma brauseri kiirustestile: on olemas spetsiaalsed tööriistad, mis aitavad sul täpselt kindlaks teha, kus sinu ping hüppeliselt tõuseb ja kas probleem on sinu kohalikus võrgus, internetiteenuse pakkujas või sihtserveris.

Põhiline ping ja traceroute

Utiliit pingSee on lähtepunkt, mis esineb kõigis operatsioonisüsteemides. Lihtsa ping 8.8.8.8 (Näiteks) näete konkreetse sihtkoha keskmist, minimaalset ja maksimaalset latentsusaega ning seda, kas esineb pakettakaod. Kui pingite oma ruuteri lüüsi, saate oma kohaliku võrgu latentsusaja.

Kui lisate -t Windowsis (ping 8.8.8.8 -tVõid lasta sel töötada, et näha, kas esineb pingetõuse, katkestusi või värinat. Ja koos traceroute/tracert Sa kontrollid, milliseid hüppeid su paketid läbivad ja millisel hetkel hakkab latentsus kahtlaselt suurenema.

Täiustatud tööriistad: WinMTR, PingPlotter ja teised

Programmid meeldivad WinMTR Need ühendavad traceroute'i ja pideva pingi, näidates signaali kadu protsenti ning iga hüppe minimaalset, keskmist ja maksimaalset reageerimisaega. Need on väga kasulikud selle tuvastamiseks, kas probleem on teie internetiteenuse pakkuja esimeses hüppes, vahepealses tugivõrgus või mänguserveris endas.

Muud kommunaalteenused, näiteks Võrgu latentsusvaade (NirSoft) mõõdab teie arvuti avatud TCP-ühenduste tegelikku latentsust. Saadaval on ka tarkvarapakette nagu NetScani tööriistad Sisaldab graafilist pingi, portide skannerit, traceroute'i ja DNS-i. Kõik ühes.

Mõõda pingi mobiilis: rakendused Androidile ja iOS-ile

Nutitelefonides ja tahvelarvutites saate latentsust mõõta ka selliste rakenduste abil nagu Fing, He.net võrgutööriistad, NetX või iOS-i spetsiifilised ping-tööriistad. Need sobivad ideaalselt selle kontrollimiseks, kas probleem on konkreetse toa WiFi-ühenduses, mobiilsidevõrgus või lauatelefoni enda halva kvaliteediga.

Täiustatud TCP/IP optimeerimine serverites ja pilves

Kui haldate servereid, pilvepõhiseid virtuaalmasinaid või nõudlikke veebiprojekte, on palju rohkem TCP/IP ja kerneli parameetreid, mida saate kohandada. madalam latentsus ja suurem jõudlus. Eriti kiirete võrkude puhul.

Kerneli ja TCP pinu sätted Linuxis

Linuxis, kasutades sysctl ja tööriistad nagu tc o ethtool Saate rakendada täiustatud optimeerimisi, näiteks:

• Vähendage minimaalset RTO-d (net.ipv4.tcp_rto_min_us) ohututele väärtustele, näiteks 5000 µs (5 ms) madala latentsusega sisevõrkudes. Kiiremaks taastumiseks pakettide kadumise korral.
• Aktiveerima Õiglane järjekord (FQ) koos tc qdisc replace dev <iface> root fq. Ribalaiuse paremaks jaotamiseks voogude vahel ja liigsete pursete vältimiseks ühest ühendusest.
• Keela aeglane käivitus pärast tegevusetust (net.ipv4.tcp_slow_start_after_idle=0) serverites, mis kasutavad püsiühendusi. Et nad ei alustaks iga kord unerežiimist ärgates uuesti naeruväärselt madala ribalaiusega.
• Keelake probleemne osa HyStart (ACK-rongi tuvastamine) Cubic TCP-s. Ummikute valepositiivsete tulemuste vältimiseks, mis aeglustavad akna kasvu.
• Suurenda TCP puhvrid (tcp_rmem, tcp_wmem, rmem_max, wmem_max). et oleks võimalik säilitada suurt läbilaskevõimet kõrge RTT-ga linkidel, vältides seeläbi soklite mälu puudust.
• Piir tcp_notsent_lowat See hoiab ära liiga suure hulga saatmata andmete kogunemise kernelisse, kaitstes seega süsteemi liigse mälukasutuse eest.
• Luba riistvara GRO/LRO ühilduvatel võrgukaartidel (ethtool -K <iface> rx-gro-hw onPakettide grupeerimiseks ja protsessori koormuse vähendamiseks katkestuse kohta.

suured MTU-d ja suure jõudlusega võrgud

Sisemistes pilvevõrkudes (nt Google Cloud VPC-d), kus tuge pakutakse jumbo MTU kuni ~8900 baitiSekundi kohta töödeldavate pakettide arvu vähendamiseks ja protsessori efektiivsuse parandamiseks on tungivalt soovitatav suurendada MTU-d (näiteks umbes 4082 baitini, mis on ühilduv 4 KB mälulehekülgedega).

Siiski tuleb olla ettevaatlik internetti suunduva või VPN-e läbiva liikluse puhul: sellisel juhul on kõige parem säilitada standardne MTU 1500 või kohandada seda iga marsruudi kohta (ip route change koos mtu y advmss), et väliskommunikatsioon ei killustuks ega kaoks liiga suurte pakettide tõttu.

Veebiserverid, HTTP/2/3 ja vahemällu salvestamine

Veebiserverites (Nginx, Apache jne) saate lisaks TCP häälestamisele tajutavat latentsust oluliselt vähendada, lubades HTTP/2 ja HTTP/3 (QUIC)mis võimaldavad mitme päringu multipleksimist ühe ühenduse kaudu ja vähendavad käepigistuste kulusid.

Lubamine GZIP-tihendus või Brotli, kasutage mälusisene vahemälu (Redis, Memcached), minimeerige CSS/JS ja serveerige staatilist sisu CDN lähedalasuvate kohalolekupunktidega kasutajale. Iga millisekund, mille säästate TTFB-s (aeg esimese baidini) ja võrgu RTT-s, tähendab külastaja silmis saidi kiiremat reageerimist.

Pidev jälgimine ja latentsusaja näitajad

Lõpuks, kui suhtute tulemuslikkusse tõsiselt, peate seda pidevalt mõõtma. Tööriistad nagu ApacheBench, wrk, JMeter või jälgitavuse paketid (Prometheus + Grafana, New Relic, Datadog…) võimaldavad teil jälgida RTT, TTFB, latentsusaja protsentiilid, läbilaskevõime ja veamäär koormuse all.

Teavituste seadistamine, kui TTFB ületab teatud lävendeid, kui teenustevaheline sisemine ping suureneb või kui pakettide kadu suureneb, aitab ennetavalt tuvastada võrguprobleeme, protsessori küllastumist, marsruudi muutusi või kitsaskohti enne, kui viivitus lõppkasutajani jõuab.

Arvestades kõiki neid kontseptsioone ja seadeid, alates MTU-st ja MSS-ist kuni ruuteri QoS-i, kiirendatud pilvevõrkude ja veebiserveri konfiguratsioonini, on selge, et viivitus ei ole ühe maagilise teguri tulemus. See on paljude võrgukomponentide ja TCP/IP enda summa, mis õigesti häälestatuna võimaldab mängudel, videokõnedel, kaugtööl ja veebisaitidel sellise reageerimisvõimega reageerida. vahetuse tunne mida me kõik otsime ja mis saavutatakse sageli pigem võrgu kohandamise ja mõistmise kui lihtsalt "megabaitide" hankimise teel.