Ha minden nap veszekszel vele Késés, akadozás és magas pingNincs egyedül. Az online játék, videohívások vagy távoli munkavégzés során tapasztalt rossz élmények mögött egyértelmű bűnös áll: az otthoni hálózatod és az eszközeiden és szervereiden lévő TCP/IP protokoll konfigurációjának kombinációja.
TCP/IP optimalizálása a következőhöz: csökkenteni a késleltetést Nem csak néhány „varázslatos” beállítás módosításáról van szó. Meg kell értened, hogyan működnek olyan fogalmak, mint a… MTU, MSS, TCP ablak, késleltetés vagy pufferfelduzzadtságEzután alkalmazzon konkrét módosításokat a számítógépén, a routerén, a Wi-Fi hálózatán, sőt még a felhőszervereken vagy a virtuális gépeken is. Nézzük meg lépésről lépésre, de gyakorlatias szemlélettel: mik is ezek a dolgok, és mit tehet annak érdekében, hogy a kapcsolat gyorsabban reagáljon.
A késleltetést befolyásoló kulcsfontosságú TCP/IP-fogalmak
Ahhoz, hogy a legtöbbet hozd ki a kapcsolatodból, hasznos megérteni néhány dolgot. alapvető TCP/IP paraméterek amelyek közvetlenül befolyásolják a pinget, a stabilitást és a teljesítményt játékokban, videohívásokban vagy távoli hozzáférésben.
MTU, fragmentáció és LSO
La MTU (maximális átviteli egység) Ez a csomag maximális mérete bájtban, amely fragmentáció nélkül elhagyhatja a hálózati interfészt. Az Ethernet-hálózatok túlnyomó többségében (és az Azure-ban vagy a Google Cloudban található virtuális gépekben) az alapértelmezett érték 1500 bájt, amely magában foglalja a hálózati fejléceket és az adatokat.
Amikor egy csomag meghaladja ezt az MTU-t, az IP réteg több kisebb töredékre bontja azt. IP-fragmentáció Ez több CPU- és memória-terhelést jelent mind az adatokat fragmentáló gépen, mind azon, amelyik érkezéskor újra összeállítja a töredékeket. Ez extra késleltetést és teljesítményveszteséget okoz, különösen nagy forgalom esetén.
Ezen kívül ott van a híres rész is „Ne töredezzen” (DF) az IP fejlécben. Ha engedélyezve van, és egy köztes útválasztó egy az MTU-nál nagyobb csomagot kap, akkor a fragmentálás helyett elveti azt, és egy ICMP „Fragmentation Needed” üzenetet küld vissza. Ezt a következőben használják: MTU útvonalészlelés (PMTUD)De ha egy tűzfal blokkolja ezeket az ICMP csomagokat, a küldő továbbra is megpróbálja küldeni a túlzottan nagy csomagokat, ami késéseket és újraküldéseket okoz.
Az olyan környezetekben, mint az Azure vagy a Google Cloud, a fragmentált csomagok hajlamosak elveszíteni a következő előnyöket: gyorsított hálózatokSR-IOV és SmartNIC-ek. Ezeket a hipervizor lassú útvonalán keresztül dolgozzák fel, több idegességrosszabb késleltetés és kevesebb csomag másodpercenként. Ezért az általános ajánlás az, hogy Kerülje a töredezettséget az MTU és az MSS megfelelő beállításával és ne növelje túl az MTU-t, ha tűzfalak vagy VPN-ek vannak a kettő között.
Másrészt a funkció Nagy küldés tehermentesítése (LSO) Ez lehetővé teszi az operációs rendszer TCP/IP veremének, hogy nagy „szupercsomagokat” generáljon, amelyeket aztán a hálózati kártya belsőleg fragmentál az MTU szerint. Ez jelentősen csökkenti a CPU terhelését, bár a forgalomrögzítésekben látszólag hatalmas keretek láthatók, amelyek nem a hálózaton belüli fragmentációra utalnak, hanem inkább arra, hogy a fragmentáció magában az adapterben történik.
MSS, PMTUD és VPN
El TCP MSS (maximális szegmensméret) Ez határozza meg, hogy az egyes TCP szegmensekbe hány bájtnyi használható adat fér el, az IP és a TCP fejlécek kivételével. A rendszerek jellemzően a következőképpen számítják ki az MSS-t:
MSS = MTU - (tamaño cabecera IP + tamaño cabecera TCP)
1500-as MTU-val és 20+20 bájtos IPv4+TCP fejlécekkel a tipikus MSS a következő: 1460 bytesEzt az értéket a TCP háromirányú kézfogása során egyeztetik, és mindkét fél a sajátját ajánlja fel. A kapcsolat a kettő közül az alacsonyabbat használja.
Azonban útközben lehetnek eszközök (tűzfalak, routerek, VPN-átjárókstb.) kisebb MTU-val, ami gyakorlatilag az MSS csökkentését kényszeríti ki. Itt történik a Útvonal MTU-felderítés (PMTUD)Amikor egy útválasztó nem tud továbbítani egy csomagot, mert az túl nagy, és a DF bit be van állítva, akkor eldobja azt, és egy ICMP „Fragmentation Needed” üzenetet küld, amely jelzi a támogatott maximális MTU-t, így a forrás csökkenti a méretét.
Ha ezeket az ICMP csomagokat blokkolja a rendszer, a kapcsolat továbbítási és adatvesztési ciklusba kerül, ami a következőt eredményezi: Késleltetés, újraküldések és végtelen betöltési időkEzért nem mindig jó ötlet könnyedséggel növelni az MTU-t a számítógépeken vagy virtuális gépeken anélkül, hogy ellenőriznénk a teljes elérési utat vagy a tűzfalszabályzatot.
A közösségi médiában a IPsec VPN vagy más alagutakban a további fejlécek csökkentik az adatok számára rendelkezésre álló helyet, ezért kisebb MTU és MSS ajánlott (pl. MTU 1400 és MSS ~1350 tipikus alagutakban) az alagút-fragmentáció és a kapcsolódó késedelmek elkerülése érdekében.
Késleltetés, RTT és TCP ablak
A híres „ping” nem más, mint a oda-vissza késleltetés (RTT) két pont között. Fizikai szinten ezt a fény terjedési sebessége a szálban (körülbelül 200 km milliszekundumként) és az adatok tényleges útvonala korlátozza. Ritkán egyenes vonalú.
A TCP-ben egyetlen kapcsolat maximális elméleti átviteli sebességét a következő alapvető képlet határozza meg:
rendimiento máximo ≈ tamaño de ventana TCP / RTT
La TCP ablak Ez az az adatmennyiség, amelyet a küldő "repülésben" tarthat anélkül, hogy még visszaigazolást (ACK) kapott volna. Egy 65 535 bájtos ablak és 1460-as MSS esetén csak körülbelül 45 csomag küldhető el, mielőtt ACK-ra várna. Ha az RTT magas (például 80-160 ms kontinensek között), a skálázatlan ablak messze elmarad a nagy kapacitású kapcsolatok előnyeinek kihasználásától.
Alapértelmezés szerint a TCP fejléc ablakmezője 16 bites, így a maximális értéke 65 535 bájtban lehet. A modern hálózatok esetében ez nevetséges, ezért évekkel ezelőtt bevezették a [hiányzó információ - valószínűleg egy adott funkció vagy módszer]. TCP ablakméretezés, amely egy 2^na szorzótényezőt alkalmaz erre az értékre, és több száz MB-os vagy akár GB-os ablakokat tesz lehetővé.
Az olyan rendszerekben, mint a Windows vagy a Linux, az ablakméretezés automatikusan, előre definiált beállításokkal történik (automatikus hangolás), és olyan parancsokkal tekinthető meg vagy módosítható, mint például Get-NetTCPSetting o sysctlAz agresszívabb szintek (pl. "kísérleti") óriási ablakokat tesznek lehetővé, és jelentősen javíthatják a teljesítményt a nagy távolságú hálózatokon, feltéve, hogy nincs túl sok csomagvesztés.
Gyorsított hálózatok, RSS és GRO/TSO
Felhőplatformokon (Azure, Google Cloud stb.) a hagyományos hálózati interfészek nagymértékben támaszkodnak a gazdagép CPU-jára az egyes csomagok feldolgozásában, a szabályok alkalmazásában, a beágyazásban és a kibontásban. Ez egy brutális terhelés a hipervizoron amikor nagy a forgalom, és az instabil késleltetést generál.
Ezért az ún. gyorsított hálózatokEzek olyan technológiákon alapulnak, mint az SR-IOV és az FPGA-kkal ellátott SmartNIC kártyák. Az ötlet az, hogy a szoftveresen definiált hálózati verem jelentős része a NIC hardveren fut, és az adatforgalom gyakorlatilag közvetlenül a virtuális gépről a kártyára mehet, megkerülve a gazdagép virtuális kapcsolóját.
Ez számos előny:
- Kevesebb késleltetés, több PPS.
- Kevesebb remegés
- Alacsonyabb CPU-fogyasztás a gazdagépen és a virtuális gépen.
Vannak azonban fontos részletek. Például sok gyorsított hálózati rendszer nem a gyors útvonalon keresztül dolgozza fel a fragmentált csomagokat; ha IP-fragmentáció van jelen, akkor a forgalom a lassú útvonalon halad, ami hatással van a teljesítményre.
A vendég operációs rendszer oldalán kulcsfontosságú, hogy engedélyezve legyenek az olyan technológiák, mint a. Fogadási oldali skálázás (RSS)amely a bejövő csomagok feldolgozását több CPU-mag között osztja el, valamint szegmentálási és aggregációs letöltéseket, például TSO (adási szegmentációs tehermentesítés) és GRO/LRO (általános vételi tehermentesítés)amelyek csökkentik a CPU által közvetlenül kezelendő csomagok számát.
TIME_WAIT és a socket újrafelhasználása
Egy másik kevésbé ismert, de fontos TCP teljesítménytényező az állapot VÁRAKOZÁSI IDŐAmikor egy TCP-kapcsolat normál módon lezárul, az utolsó ACK-ot küldő végpont TIME_WAIT állapotba kerül tíz vagy akár több száz másodpercre. Ez idő alatt a rendszer fenntartja a socketet, hogy a régi kapcsolatról érkező késleltetett csomagok ne jelenjenek meg újra, és ne keveredjenek össze egy új munkamenettel.
A sokat használt szervereken vagy gépeken könnyű felhalmozódni több ezer vagy tízezer socket a TIME_WAIT alattEz kimerítheti az efemer portok tartományát, és hibákat okozhat új kapcsolatok megnyitásakor. Ezért sok rendszer lehetővé teszi mind a TIME_WAIT időtartam, mind a porttartomány, valamint bizonyos újrafelhasználási szabályzatok beállítását.
Egy agresszívabb technika, amelyet egyes kernelek (például a Windows Server az Azure-ban) támogatnak, az úgynevezett TIME_WAIT merényletHa egy új SYN érkezik, amelynek sorszáma jelentősen nagyobb, mint a régi kapcsolaté, a rendszer kényszerítheti a socket bezárását a TIME_WAIT idő alatt, és azonnal elfogadja az új kapcsolatot. Ez növeli a skálázhatóságot, de ha rosszul van konfigurálva, problémákat okozhat. interoperabilitási problémák bizonyos konzervatívabb TCP-vermekkel.
Miért olyan fontos a ping a mindennapi életben?
Az elméleten túl a késleltetés közvetlen hatással van szinte mindenre, amit ma online csinálunk. Nem elég egyszerűen „600 Mbps sebességgel rendelkezni”; ha a válasz lassú, az a felhasználói élmény romlását okozza. Tekintsünk át néhány esetet, amikor egy Egy „tisztességes” ping mindent megváltoztat.
Online játékok és "játszható" ping szintek
Versenyjátékokban minden milliszekundum számít. ping 20 ms alatt Gyakorlatilag ideális: a műveletek szinte valós időben rögzülnek, és alig észrevehető a késleltetés. 20 és 50 ms között az élmény továbbra is nagyon jó. 50-100 ms-ra felmenve enyhe deszinkronizációt tapasztalhatsz, különösen, ha távoli szervereken játszol.
Tól 100-300 ms Komoly problémák kezdődnek: késve érkező felvételek, késéssel látható mozgások, "pattogó" autók egy versenyjátékban stb. 300 ms felett a játék kínzóbbá válik, mint bármi más, különösen a lövöldözős, autóversenyes vagy sportjátékokban.
A játék típusa is nagy hatással van. FPS és versenyjátékok Gyakorlatilag kötelező 50 ms alatt maradni a versenyzéshez; online sporteseményekben a 30-40 ms alatti idő is kívánatos. Azonban a MMO-k vagy körökre osztott stratégiai játékok150-200 ms-os pingekkel is „túlélheted” a játékmenetet anélkül, hogy az megszakadna, bár az élmény sosem lesz olyan gördülékeny. Ha Windows rendszeren játszol, érdekelhet, hogyan kell ezt csinálni. A bemeneti késleltetés csökkentése Windows 11 rendszerben a versenyjátékokban a reakcióidő javítása érdekében.
Videohívások, képernyőmegosztás és VoIP-hívások
A Zoom, Teams, Skype vagy hasonló platformokon keresztüli videohívásokban a ping is kulcsfontosságú. Ideális esetben a ... körül kellene mozognia. 20-40 msahol a beszélgetés természetesen folyik, átfedések nélkül. A legtöbb felhasználó akár 100 ms-ig is elvisel, bár beszéd közben már enyhe késések is észrevehetők.
Amikor a ping meghaladja a 100 msAkaratlanul is elkezded félbeszakítani a másikat. A válaszok átmeneti „visszhanggal” érkeznek, és gyakoriak a kínos csendek. Ha ráadásul a kapcsolat sávszélessége korlátozott, vagy a Wi-Fi gyenge, akkor a kép- és hangkimaradások is hozzáadódnak.
Con képernyőmegosztás vagy távirányító A hatás hasonló. Minden kattintásnak és minden egérmozdulatnak időbe telik, mire a távoli képernyőn regisztrálódik. Magas pingek esetén úgy tűnik, mintha a számítógép lassú lenne. Ez hihetetlenül frusztráló bárki számára, aki produktívan próbál dolgozni.
Dolgok internete, otthonautomatizálás és távmunka
Az ökoszisztémában IoT és okoseszközök (hangszórók, izzók, kamerák, konnektorok, robotok, állatetetők stb.) esetén a késleltetés is kulcsszerepet játszik. Bár egy lámpa 500 ms-os késleltetéssel történő felkapcsolása nem drámai, ha sok műveletet láncolunk össze, vagy hanggal interakcióba lépünk (Alexa, Google Assistant), ez nagyon észrevehetővé válik.
Távoli munkavégzés esetén a távoli asztalokhoz, szerverekhez vagy felhőalkalmazásokhoz való folyamatos késleltetés miatt bármilyen feladat unalmassá válik. Sokan azt hiszik, hogy ez a „sebesség hiánya”, pedig valójában csak egy… magas és/vagy erősen változó késleltetés (jitter) telített WiFi, összeomlott routerek vagy a szerverhez vezető rossz útvonalak okozzák.
Késleltetés és biztonság: közvetett hatás
A magas késleltetés önmagában nem jelenti azt, hogy közvetlen biztonsági kockázatEnnek azonban lehetnek mellékhatásai. Ha a megfigyelőrendszerek, az azonosításmegelőző rendszerek vagy a tűzfalak túl későn kapják meg az információt, akkor túl későn reagálhatnak egy támadásra, vagy akár kritikus eseményeket is elszalaszthatnak.
Továbbá, amikor a felhasználók kétségbeesetten aggódnak a lag miatt, hajlamosak „megkerülni” a biztonsági ellenőrzéseket: Letiltják a tűzfalat, eltávolítják a víruskeresőt, vagy véletlenszerűen nyitnak meg portokat. a routeren, hogy megpróbálja „gyorsabbá” tenni. Itt a rossz hálózati élmény szükségtelen kapukat nyithat meg a valódi fenyegetések előtt.
A magas késleltetés fő okai az otthoni hálózatokban
A játékban vagy sebességteszten látható ping sok tényező összege: szolgáltató, internet útvonal, célkiszolgáló... de otthon is számos tipikus probléma adódhat, amit te magad is kezelhetsz.
Gyenge WiFi lefedettség és interferencia
Legtöbben ma már szinte kizárólag Wi-Fi-n keresztül csatlakozunk, és itt kezdődnek a problémák. Az egyik gyenge vagy interferenciával teli jel Ez nemcsak a sebességet csökkenti, hanem a késleltetést és a jittert is növeli, mivel az eszközöknek újra kell küldeniük a csomagokat, csökkenteniük kell a modulációt, várniuk kell, amíg a csatorna felszabadul stb.
Ha messze vagy a routertől, több fal mögött vagy, vagy szomszédos hálózatok vesznek körül, amelyek ugyanazon a csatornán vannak, a ping-ed romlani fog. Továbbá, minél több kliens csatlakozik egy hozzáférési ponthoz, annál hosszabb a várakozási idő, amíg mindegyik „sorra kerül” a kommunikációhoz. A lassú kliensek pedig negatívan befolyásolják a többit. Tudja meg, hány eszköz van a WiFi hálózatán problémás ügyfelek azonosítására.
Az ilyen funkciók itt nagyon hasznosak Műsoridő méltányosságaamelyek elosztják a műsoridőt az eszközök között, hogy a lassabbak ne monopolizálják a rádiót. Ennek ellenére, amikor csak lehetséges, játékhoz és vezetékes telefonról való munkavégzéshez használd [az alternatívát]. Ethernet kábel és hagyd meg a WiFi-t mindenki másnak.
Elavult vagy túlterhelt router
Egy régi router elavult firmware-rel vagy nagyon alapvető hardverrel jelentős szűk keresztmetszetet jelenthet. Amikor a router processzora túlterhelt a NAT, a tűzfal, a QoS és a P2P forgalom kezelése miatt, a... sorban állási késés és pufferfelduzzanatA csomagok egy óriási pufferben gyűlnek össze, és jelentős késéssel kerülnek kiküldésre, tönkretéve a pingelést.
Frissítse a firmware-t, tiltsa le a felesleges funkciókat, és ha szükséges, kérjen csereeszközt a szolgáltatójától, vagy vásároljon újat. legerősebb semleges router Gyakran fordulópontot jelent. Érdemes időnként újraindítani a memóriaállapotok és az esetleges szivárgások törléséhez.
Letöltések és egyéb sávszélességet fogyasztó eszközök
Ha a hálózatodon több eszközről is nagy mennyiségű letöltés történik (P2P, frissítések, 4K streaming, felhőalapú biztonsági mentések), akkor ez normális. a ping-csúcsokA probléma nem annyira az, hogy "elfogynak a megabájtok", hanem az, hogy a router hogyan kezeli a kimenő sorokat.
A megoldás két utat foglal magában:
- Egyrészt jobban szabályozható, hogy mi töltődik le a háttérben (PC, mobilok, konzolok, NAS…).
- Másrészt aktiválja és állítsa be megfelelően a QoS és pufferfelduzzadtság elleni védelem a routerről, hogy az interaktív forgalom (játékok, VoIP, videohívások) elsőbbséget élvezzen a tömeges letöltésekkel szemben.
VPN, proxy, tűzfal és háttérprogramok
az VPN Nagyon hasznosak a forgalom titkosításához vagy a földrajzi korlátozások megkerüléséhez, de szinte mindig késleltetést okoznak, mivel a kapcsolat egy közvetítő szerveren keresztül történik. Ha a VPN ingyenes vagy rossz minőségű, akkor egyenesen végzetes lehet a ping szempontjából. Ugyanez vonatkozik bizonyos... proxy.
A tűzfalak, mind a PC-n, mind az útválasztón, szintén némi késleltetést okoznak az egyes csomagok vizsgálatával, és ha rosszul vannak konfigurálva, jelentősen lelassíthatják a kapcsolatot. Ehhez jön még hozzá... háttérfolyamatok (Windows frissítések, felhőkliensek, játékokhoz letölthető javítások stb.), amelyek észrevétlenül fogyasztják a sávszélességet.
Kártevők és feltört eszközök
Egy kártevővel fertőzött számítógép rejtett forgalmat generálhat (spam, DDoS-támadások, adatbányászat, adatletöltések), vagy sok CPU- és lemezerőforrást fogyaszthat, ami hatással van a kapcsolat minőségére. Ha ezt észleli Minden lassú, és a ping minden látható ok nélkül megugrik.Célszerű minden eszközön alapos vizsgálatot futtatni egy megbízható víruskereső programmal. Ezenkívül ajánlott követni a legjobb gyakorlatokat a következőkre vonatkozóan: egészséges hálózati infrastruktúra fenntartása és kerülje a veszélyeztetett berendezéseket.
Eszközök a késleltetés mérésére és a problémák észlelésére
Mielőtt bármit is megváltoztatnál, elengedhetetlen a pontos mérések elvégzése. Ne hagyatkozz kizárólag a böngésződ sebességtesztjére: vannak speciális eszközök, amelyek segíthetnek meghatározni, hogy hol ugrott meg az egekbe a ping, és hogy a probléma a helyi hálózatoddal, az internetszolgáltatóddal vagy a célkiszolgálóval van-e.
Alap ping és traceroute
Hasznosság fütyülésEz a kiindulópont, ami minden operációs rendszerben jelen van. Egy egyszerű ping 8.8.8.8 (Például) megtekintheted egy adott célállomás átlagos, minimális és maximális késleltetését, valamint azt, hogy van-e csomagvesztés. Ha pingeled a router átjáróját, megkapod a helyi hálózatod késleltetését.
Ha hozzáadsz egy -t Windowson (ping 8.8.8.8 -tHagyhatod futni, hogy lásd, vannak-e jelkimaradások, jelkimaradások vagy remegés. És a traceroute/tracert Ellenőrized, hogy a csomagok mely ugrásokon mennek keresztül, és melyik ponton kezd gyanúsan növekedni a késleltetés.
Speciális eszközök: WinMTR, PingPlotter és mások
Olyan programok, mint WinMTR Kombinálják a traceroute és a folyamatos ping módszert, megjelenítve a jelveszteség százalékos arányát, valamint az egyes ugrások minimális, átlagos és maximális válaszidejét. Nagyon hasznosak annak azonosításában, hogy a probléma az internetszolgáltató első ugrásában, egy közbenső gerinchálózatban vagy magában a játékszerverben rejlik-e.
Egyéb közművek, mint például Hálózati késleltetés nézet (NirSoft) méri a számítógép által megnyitott TCP-kapcsolatok tényleges késleltetését. Vannak olyan csomagok is, mint a NetScan eszközök Grafikus pinget, portszkennert, traceroute-ot és DNS-t tartalmaz. Minden egyben.
Ping mérése mobilon: alkalmazások Androidra és iOS-re
Okostelefonokon és táblagépeken a késleltetést olyan alkalmazásokkal is mérheti, mint például Fing, He.net hálózati eszközök, NetX vagy iOS-en speciális ping eszközökkel. Ezek tökéletesek annak ellenőrzésére, hogy a probléma egy adott szoba Wi-Fi-jével, a mobilhálózattal, vagy magával a vezetékes telefonnal van-e rossz minőségben.
Speciális TCP/IP optimalizálás szervereken és felhőben
Ha szervereket, felhőalapú virtuális gépeket vagy igényes webes projekteket kezel, számos további TCP/IP és kernel paramétert állíthat be. alacsonyabb késleltetés és nagyobb teljesítmény. Különösen a nagy sebességű hálózatokon.
Kernel és TCP verem beállítások Linuxban
Linuxon, a következő használatával: sysctl és olyan eszközöket, mint tc o ethtool Speciális optimalizálásokat alkalmazhat, például:
- Csökkentse a minimális RTO-t (
net.ipv4.tcp_rto_min_us) biztonságos értékekre, például 5000 µs-ra (5 ms) alacsony késleltetésű belső hálózatokon. A csomagvesztés utáni gyorsabb helyreállítás érdekében. - Aktiválása Fair Queuing (FQ) a
tc qdisc replace dev <iface> root fq.A sávszélesség jobb elosztása a folyamatok között, és a túlzott löketek elkerülése egyetlen kapcsolatról. - Kapcsolja ki a lassú indulás inaktivitás után (
net.ipv4.tcp_slow_start_after_idle=0) olyan szervereken, amelyek állandó kapcsolatokat használnak. Így nem nevetségesen alacsony sávszélességről indulnak újra minden alkalommal, amikor alvó módból felébrednek. - Tiltsa le a problémás részt HyStart (ACK vonatészlelés) a Cubic TCP-ben. Annak megakadályozására, hogy a torlódás okozta téves riasztások lelassítsák az ablak növekedését.
- Növelje a TCP pufferek (
tcp_rmem, tcp_wmem, rmem_max, wmem_max). hogy nagy átviteli sebességet tudjon fenntartani a magas RTT-vel rendelkező kapcsolatokon, megakadályozva, hogy a socketek memóriahiányban fogyjanak el. - Határ
tcp_notsent_lowatEz megakadályozza, hogy túl sok elküldetlen adat halmozódjon fel a kernelben, így védve a rendszert a túlzott memóriafogyasztástól. - engedélyezéséhez GRO/LRO hardver kompatibilis hálózati kártyákon (
ethtool -K <iface> rx-gro-hw onA csomagok csoportosítása és a megszakításonkénti CPU-terhelés csökkentése érdekében.
nagy MTU-k és nagy teljesítményű hálózatok
Belső felhőalapú hálózatokban (pl. Google Cloud VPC-k), ahol támogatást nyújtanak jumbo MTU akár ~8900 bájtigErősen ajánlott az MTU növelése (például körülbelül 4082 bájtra, ami kompatibilis a 4 KB memórialapokkal) a másodpercenként feldolgozott csomagok számának csökkentése és a CPU hatékonyságának javítása érdekében.
Azonban óvatosnak kell lenni az internetre kimenő vagy VPN-eken áthaladó forgalommal: ebben az esetben a legjobb, ha vagy a standard MTU-t 1500-on tartjuk, vagy útvonalanként módosítjuk (ip route change a mtu y advmss), hogy a külső kommunikáció ne töredezettedjen vagy vesszen el a túlzottan nagy csomagok miatt.
Webszerverek, HTTP/2/3 és gyorsítótárazás
Webszervereken (Nginx, Apache stb.) a TCP finomhangolása mellett az érzékelt késleltetés jelentősen csökkenthető a következő engedélyezésével: HTTP/2 és HTTP/3 (QUIC)amelyek lehetővé teszik több kérés multiplexálását egyetlen kapcsolaton keresztül, és csökkentik a kézfogások költségét.
Engedélyezés GZIP tömörítés vagy Brotli, használja memórián belüli gyorsítótár (Redis, Memcached), minimalizálja a CSS/JS-t és szolgáltasson statikus tartalmat egy CDN közeli jelenléti pontokkal a felhasználónak. Minden milliszekundum, amit a TTFB-ben (Time To First Byte) és a hálózati RTT-ben megtakarítasz, azt jelenti, hogy a webhely „gyorsabban” reagál a látogató szemében.
Folyamatos monitorozás és késleltetési mutatók
Végül, ha komolyan gondolod a teljesítményt, akkor folyamatosan mérned kell azt. Eszközök, mint például ApacheBench, wrk, JMeter vagy megfigyelhetőségi csomagok (Prometheus + Grafana, New Relic, Datadog…) lehetővé teszik a monitorozást RTT, TTFB, késleltetési percentilisek, átviteli sebesség és hibaarány bajo carga
Ha riasztásokat állít be, amikor a TTFB meghalad bizonyos küszöbértékeket, amikor a szolgáltatások közötti belső ping megugrik, vagy amikor a csomagvesztés megnő, akkor a rendszer proaktívan észleli a hálózati problémákat, a CPU-telítettséget, az útvonalváltozásokat vagy a szűk keresztmetszeteket, mielőtt a késleltetés elérné a végfelhasználót.
Mindezen koncepciók és beállítások ismeretében, az MTU-tól és az MSS-től kezdve a router QoS-on át a gyorsított felhőhálózatokig és a webszerver konfigurációjáig, egyértelmű, hogy a késleltetés nem egyetlen varázslatos tényező eredménye. Számos hálózati komponens és maga a TCP/IP összessége, amely megfelelő hangolás esetén lehetővé teszi a játékok, videohívások, távmunka és webhelyek számára, hogy ilyen gyorsasággal reagáljanak. azonnali érzés amire mindannyian törekszünk, és amit gyakran inkább a hálózat módosításával és megértésével érünk el, mint egyszerűen „több megabájt” lekötésével.
