Zeta-TCP
Zeta-TCP hänvisar till en uppsättning proprietära Transmission Control Protocol (TCP)-algoritmer som syftar till att förbättra TCP-prestandan från slut till ände, oavsett om peeren är Zeta-TCP eller någon annan TCP-protokollstack, med andra ord, vara kompatibel med befintliga TCP-algoritmer. Det designades och implementerades av AppEx Networks Corporation.
Zeta-TCP erbjuder i första hand följande förbättringar:
- Undvikande av trängsel baserat på både latens- och förlustmått.
- Förbättrad förlustdetekteringsalgoritm.
- Omvänd kontroll.
Undvikande av trängsel
De flesta av TCP-stackimplementeringarna idag använder TCP New Reno eller dess varianter (som TCP SACK RFC3517 ) som algoritm för att undvika överbelastning. De nya Reno-baserade algoritmerna är förlustbaserade. Förlustbaserade algoritmer behandlar paketförlusterna som den enda indikationen på trängseln i nätverket. Eftersom Internet sedan dess har utvecklats är detta antagande ofta ett överdrivet antagande idag. Trängselförlusten sjunker ständigt i takt med att teknologierna utvecklas, medan relativt sett slumpmässiga förluster beror på medias egenskaper (t.ex. trådlösa/ fading-kanaler ), trådljud/överhörning, anslutningsbrister, programvarubuggar, etc. , ökar. När en "stockning" upptäcks (eller falsklarmd), krymper New Reno Congestion Window (CWND) kraftigt, vilket orsakar en nedgång i sändningshastigheten. Detta är en av huvudorsakerna till att de TCP-baserade applikationerna ofta knappt kan utnyttja en bråkdel av den abonnerade bandbredden idag, speciellt när RTT är stor.
TCP Vegas och dess varianter, framför allt FAST TCP , baserar sina prognoser för överbelastning endast på RTT-mätningen. Sådana latensbaserade algoritmer övervinner problemen med de förlustbaserade, och är vanligtvis en mer realistisk återspegling av trängseln i nätverket. Men de latensbaserade algoritmerna har också sina egna begränsningar .
Zeta-TCP försöker ta itu med problemet genom att kombinera styrkan hos både latensbaserade och förlustbaserade algoritmer. Den mäter ständigt RTT-variationen och förlusthastighetsvariationen och beräknar sannolikheten för överbelastningar. Olika CWND-backoff-scheman tillämpas baserat på sannolikhetsnivån. Med den högsta nivån tillämpar den backoff-schemat från New Reno, som redan har visat sig vara effektivt och stabilt med många år av massiv utbyggnad.
Förlustdetektering
Paketförlusterna i den verkliga nätverksmiljön sprids sällan jämnt ut. Snarare tenderar de att hända nära varandra. De TCP-relaterade RFC:erna (New Reno och SACK, etc.) definierade uttryckligen hur den första förlusten kan upptäckas med hög tillförsikt. Detekteringen av förlusterna efter att TCP går in i Fast Recovery-läget med SACK tillåten är dock inte särskilt effektiv i RFC3517 . Och några populära operativsystem har sina egna implementeringar som är lika suboptimala.
Zeta-TCP har introducerat en enkel men effektiv algoritm för att beräkna förlustsannolikheten på varje unACK'd/unSACK'd-paket. Ett paket återsänds endast när dess förlustsannolikhet har överskridit en viss tröskel. Samma regel gäller för beslutet om vidaresändning av varje paket. Därför kan Zeta-TCP minimera antalet återsända paket, vilket ytterligare förbättrar bandbreddsutnyttjandet. Laboratorietester bekräftade också att Zeta-TCP återsände mycket färre paket än de andra TCP-implementeringarna med samma förlusthastighet.
Zeta-TCP har också utvecklat en mekanism för att noggrant upptäcka paketförlusten vid tidigast möjliga tidpunkt när man misstänker att en förlust sannolikt kommer att inträffa. Tidig upptäckt kan vanligtvis spara en RTT eller två vid återsändning.
Omvänd kontroll
Medan de andra algoritmerna fokuserar på att accelerera den utgående trafiken, försöker Reverse Control lösa de inkommande problemen. Omvänd kontroll övervakar kvaliteten på anslutningarna med inkommande data, och exekverar algoritmen för att antyda peern att sända så snabbt som möjligt när anslutningskvaliteten är bra. Algoritmen gör också stora ansträngningar för att mer exakt identifiera de verkliga paketförlusterna från andra onormala situationer för att undvika att utlösa onödiga snabba återställningar.
Den omvända styrda inkommande accelerationen är heuristisk genom att den inkommande hastigheten verkligen kontrolleras av avsändaren, dvs. peeren. Det kan bara antyda peer att skicka snabbare. Vissa TCP-stackar tar tipset och andra inte. Dessutom har avsändarsidan (till exempel innehållsservern) ofta en hastighetsbegränsande mekanism så att accelerationseffekten begränsas.
Förutom acceleration kan Reverse Control också begränsa inkommande hastighet. Till skillnad från acceleration är det mycket effektivt och exakt att bromsa den inkommande trafiken med TCP-flödeskontrollmekanismen. Begränsningen av inkommande hastighet för Zeta-TCP lägger grunden för kontrollen av inkommande flöde av AppEx IPEQ.
Genomförande
I skrivande stund har Zeta-TCP implementerats som mjukvarumoduler för Linux ( Netfilter Kernel Module), Microsoft Windows 10 ner till XP och relaterade Windows Server-versioner ( NDIS IM Filter/NDIS LWF) och WinCE. AppEx valde att inte modifiera protokollstacken, utan avlyssna TCP-flödena och tillämpa dess algoritmer i farten. Detta är det icke-påträngande sättet att implementera de algoritmer som är avsedda för bredare acceptans. Nackdelen är den extra kostnaden för bearbetningen. Men i verkligheten är omkostnaden försumbar i jämförelse med prestandavinsterna.