Protokolli i Kontrollit të Transmetimit

Protokolli i Kontrollit të Transmetimit (TCP) është një nga protokollet kryesore të suitës së protokolleve të internetit. Ai filloi në implementimin fillestar të rrjetit në të cilin plotësoi Protokollin e Internetit (IP). Prandaj, i gjithë grupi zakonisht quhet TCP/IP . TCP siguron shpërndarje të besueshme, të renditur dhe të kontrolluar nga gabimet të një rrjedhe oktetesh (bajtesh) midis aplikacioneve që funksionojnë në hostet që komunikojnë nëpërmjet një rrjeti IP. Aplikacionet kryesore të internetit, si World Wide Web, email-i, administrimi në distancë dhe transferimi i skedarëve, mbështeten në TCP, i cili është pjesë e shtresës së transportit në modelin TCP/IP. SSL/TLS shpesh funksionon mbi TCP

TCP është protokol i orientuar drejt lidhjes, që do të thotë se dërguesi dhe marrësi së pari duhet të krijojnë një lidhje bazuar në parametrat qe jane marre vesh: ata e bëjnë këtë përmes procedurës së shtrëngimit të dorës në tre drejtime. Serveri duhet të jetë duke dëgjuar (hapur pasivisht) për kërkesat e lidhjes nga klientët përpara se të vendoset një lidhje. Shtrëngimi i dorës në tre drejtime (hapja aktive), ritransmetimi dhe zbulimi i gabimeve shtojnë besueshmërinë, por zgjasin vonesën . Aplikacionet që nuk kërkojnë shërbim të besueshëm të rrjedhës së të dhënave mund të përdorin në vend të kësaj Protokollin e Datagramit të Përdoruesit (UDP), i cili ofron një shërbim datagrami pa lidhje që i jep përparësi kohës mbi besueshmërinë. TCP përdor shmangien e mbingarkesës së rrjetit. Megjithatë, ka dobësi në TCP, duke përfshirë mohimin e ofrimit te shërbimit, rrëmbimin e lidhjes, veton e TCP dhe sulmin e rivendosjes.

Origjina historike

Në maj të vitit 1974, Vint Cerf dhe Bob Kahn përshkruan një protokoll rrjetëzimi për ndarjen e burimeve duke përdorur ndërrimin e paketave midis nyjeve të rrjetit. Autorët kishin punuar me Gérard Le Lann për të përfshirë koncepte nga projekti francez CYCLADES në rrjetin e ri. Specifikimi i protokollit që rezultoi, RFC 675, u shkrua nga Vint Cerf, Yogen Dalal dhe Carl Sunshine dhe u botua në dhjetor 1974. Ai përmban përdorimin e parë të dëshmuar të termit internet, si shkurtes për rrjet ndermjetes.

Protokolli i Kontrollit të Transmetimit përfshinte si lidhjet e orientuara drejt lidhjes, ashtu edhe shërbimet me datagrama midis kompjuterëve pritës. Në versionin 4, protokolli monolit i Kontrollit të Transmetimit u nda në një arkitekturë modulare, e cila përfshinte Protokollin e Kontrollit të Transmetimit (TCP) dhe Protokollin e Internetit (IP). Kjo çoi në krijimin e një modeli rrjetëzimi që u bë i njohur jozyrtarisht si TCP/IP, megjithëse në mënyrë formale iu referuan me emra të ndryshëm, si modeli i arkitekturës së internetit të Departamentit të Mbrojtjes (i njohur shkurt si modeli i Departamentit të Mbrojtjes) ose modeli DARPA Më vonë, u bë pjesë dhe sinonim i Internet Protocol Suite .

Dokumentet me poshte të Shënimit të Eksperimentit të Internetit (IEN) përshkruajnë evolucionin e TCP në versionin modern:

• IEN 5 Specifikimi i Programit të Kontrollit të Transmetimit në Internet TCP Versioni 2 ( Mars 1977).
• IEN 21 Specifikimi i Programit të Kontrollit të Transmetimit të Internetwork TCP Versioni 3 ( Janar 1978).
• IEN 27
• IEN 40
• IEN 44
• IEN 55
• IEN 81
• IEN 112
• IEN 124

TCP ne fillim u standardizua në janar të vitit 1980 si RFC 761.

Në vitin 2004, Vint Cerf dhe Bob Kahn morën Çmimin Turing për punën e tyre themelore mbi protokollet TCP/IP

Funksioni i rrjetit

Në nivelet më të ulëta të pirgut të protokolleve, për shkak të mbingarkesës së rrjetit, balancimit të ngarkesës së trafikut ose sjelljes së paparashikueshme të rrjetit, paketat IP mund të humbasin, të dyfishohen ose të dorëzohen jashtë renditjes . TCP i zbulon këto probleme, kërkon ritransmetimin e të dhënave të humbura, rirreshton të dhënat që kanë mbërritur jashtë rendit dhe madje ndihmon në zvogëlimin e mbingarkesës së rrjetit për të minimizuar shfaqjen e problemeve të tjera. Nëse të dhënat nuk mund të dorëzohen, burimi njoftohet për dështimin. Pasi TCP në anën pritëse të rimontojë sekuencën origjinale të okteteve të transmetuara, ia dorëzon ato aplikacionit përkatës. Kështu, TCP abstrakton komunikimin e aplikacionit nga detajet themelore të rrjetëzimit.

Ndërsa IP merret me shpërndarjen fizike të të dhënave, TCP ndjek dhe menaxhon segmentet — njësitë individuale të transmetimit në të cilat ndahet një mesazh për të mundësuar një rrugëzim më efikas nëpër rrjet. Për shembull, kur një skedar HTML dërgohet nga një server web, shtresa e softuerit TCP e atij serveri e ndan skedarin në segmente dhe i përcjell ato individualisht në shtresën e internetit në grumbullin e rrjetit . Softueri i shtresës së internetit e kapsullon çdo segment TCP në një paketë IP duke shtuar një kokë që përfshin (ndër të dhëna të tjera) adresën IP të destinacionit. Kur programi klient në kompjuterin e destinacionit pranon segmentet, softueri TCP në shtresën e transportit i rimonton ato, sigurohet që të jenë të renditura saktë dhe pa gabime, dhe më pas ia përcjell përmbajtjen aplikacionit marrës..

Struktura e segmentit TCP

Protokolli i Kontrollit të Transmetimit (TCP) merr të dhëna nga një rrjedhë të dhënash, i ndan ato në segmente dhe u shton një kokëz TCP, duke krijuar kështu segmentet TCP.

Segmenti TCP më pas enkapsulohet në një datagram të Protokollit të Internetit (IP) dhe shkëmbehet me kolegët.

Termi 'paketë TCP' përdoret si në mënyrë joformale, ashtu edhe në kontekste formale, megjithatë në terminologjinë më të saktë i referohet njësisë së të dhënave të protokollit TCP (PDU), datagramit IP PDU dhe kornizës PDU të shtresës së lidhjes së të dhënave :

Proceset transmetojnë të dhëna duke thirrur funksionet e TCP-së dhe duke kaluar buffer-a me të dhëna si argumente. TCP paketojnë këto të dhëna në segmente dhe i dërgon ato modulit të internetit (për shembull IP), i cili ka për detyrë të transmetojë çdo segment te TCP-ja e destinacionit.

Një segment TCP përbëhet nga një kokë segmenti dhe një pjesë të dhënash. Koka e segmentit përmban 10 fusha të detyrueshme, si dhe një fushë shtesë opsionale (Opsionet, të shënuara me sfond rozë në tabelë). Seksioni i të dhënave ndodhet pas kokës dhe përmban ngarkesën e të dhënave që dërgohen për aplikacionin. Gjatësia e seksionit të të dhënave nuk specifikohet në kokën e segmentit; ajo mund të llogaritet duke zbritur gjatësinë e kombinuar të kokës së segmentit dhe kokës IP nga gjatësia totale e datagramit IP të specifikuar në kokën IP. 

Operacioni i protokollit

Një diagram i thjeshtuar i gjendjes së TCP-së.

Operacionet e protokollit TCP mund të ndahen në tre faza. Vendosja e lidhjes është një proces me shumë hapa i 'shtrëngimit të dorës' që krijon lidhjen para se të fillojë faza e transferimit të të dhënave. Pasi të përfundojë transferimi, ndërprerja e lidhjes e mbyll atë dhe liron të gjitha burimet e alokuara.

Një lidhje TCP menaxhohet nga sistemi operativ përmes një burimi që përfaqëson pikën fundore lokale të komunikimit, të quajtur soketi i internetit. Gjatë jetëgjatësisë së një lidhjeje TCP, pika fundore lokale kalon nëpër një sërë ndryshimesh të gjendjes:

Gjendjet e soketave TCP

Shteti	Pika e Fundit	Përshkrimi
DËGJO	Serveri	Duke pritur për një kërkesë lidhjeje nga çdo pikë fundore TCP e largët.
SYN-SENT	Klient	Duke pritur për një kërkesë lidhjeje që përputhet pasi të jetë dërguar një kërkesë lidhjeje.
SYN-PRITUR	Serveri	Duke pritur për një konfirmim të kërkesës për lidhje pasi të keni marrë dhe dërguar një kërkesë për lidhje.
I KRIJUAR	Serveri dhe klienti	Një lidhje e hapur, të dhënat e marra mund t'i dorëzohen përdoruesit. Gjendja normale për fazën e transferimit të të dhënave të lidhjes.
FIN-WAIT-1	Serveri dhe klienti	Duke pritur një kërkesë për ndërprerjen e lidhjes nga TCP-ja e largët, ose një konfirmim të kërkesës për ndërprerjen e lidhjes të dërguar më parë.
FIN-WAIT-2	Serveri dhe klienti	Duke pritur një kërkesë për ndërprerjen e lidhjes nga TCP-ja e largët.
MBYLL - PRIT	Serveri dhe klienti	Duke pritur një kërkesë për ndërprerjen e lidhjes nga përdoruesi lokal.
MBYLLJA	Serveri dhe klienti	Duke pritur për një konfirmim kërkese për përfundimin e lidhjes nga TCP-ja e largët.
LAST-ACK	Serveri dhe klienti	Duke pritur për një konfirmim të kërkesës për përfundimin e lidhjes të dërguar më parë në TCP-në e largët (e cila përfshin një konfirmim të kërkesës së saj për përfundimin e lidhjes).
KOHË-PRITJE	Server ose klient	Duke pritur që të kalojë kohë e mjaftueshme për t'u siguruar që të gjitha paketat e mbetura në lidhje kanë skaduar.
MBYLLUR	Serveri dhe klienti	Asnjë gjendje lidhjeje fare.

Vendosja e lidhjes

Para se një klient të përpiqet të lidhet me një server, serveri duhet të krijojë dhe të “dëgjojë” në një port specifik për të pranuar lidhje të ardhshme; kjo quhet hapje pasive. Pasi hapja pasive është vendosur, klienti mund të fillojë krijimin e lidhjes duke realizuar një hapje aktive përmes procesit të shtrëngimit të dorës me tre hapa (ose three-way handshake):

1. SYN : Hapja aktive kryhet nga klienti që dërgon një SYN në server. Klienti e vendos numrin rendor të segmentit në një vlerë të rastësishme A.
2. SYN-ACK : Si përgjigje, serveri përgjigjet me një SYN-ACK. Numri i konfirmimit është vendosur një më shumë se numri i sekuencës së marrë, dmth. A+1, dhe numri i sekuencës që serveri zgjedh për paketën është një numër tjetër i rastësishëm, B.
3. ACK : Më në fund, klienti dërgon një ACK përsëri në server. Numri rendor caktohet në vlerën e konfirmimit të marrë, p.sh. A+1, dhe numri i konfirmimit caktohet një më shumë se numri rendor i marrë, p.sh. B+1.

Hapat 1 dhe 2 përcaktojnë dhe konfirmojnë numrin rendor për një drejtim (nga klienti te serveri). Hapat 2 dhe 3 përcaktojnë dhe konfirmojnë numrin rendor për drejtimin tjetër (nga serveri te klienti). Pas përfundimit të këtyre hapave, si klienti ashtu edhe serveri kanë marrë konfirmimet përkatëse dhe është krijuar një lidhje komunikimi me dy drejtime (full duplex)

Ndërprerja e lidhjes

Diagrami i detajuar i sekuencës TCP close()

Faza e përfundimit të lidhjes përdor një shtrëngim duarsh katërpalësh, ku secila anë e lidhjes e mbyll pjesën e vet në mënyrë të pavarur. Kur një pikë fundore dëshiron të ndërpresë gjysmën e saj të lidhjes, ajo dërgon një paketë FIN, të cilën pala tjetër e pranon me një ACK. Kështu, një çmontim tipik kërkon një palë segmente FIN dhe ACK nga secila pikë fundore e TCP. Pasi pala që dërgoi FIN-in e parë të marrë përgjigjen ACK përfundimtare, ajo pret për një periudhë kohe para se të mbyllë përfundimisht lidhjen. Gjatë kësaj kohe, porta lokale nuk është e disponueshme për lidhje të reja; kjo i lejon klientit TCP të ridërgojë konfirmimin përfundimtar tek serveri në rast se ACK-u humbet gjatë transmetimit. Kohëzgjatja e kësaj periudhe ndryshon sipas implementimit, por vlera të zakonshme janë 30 sekonda, 1 minutë dhe 2 minuta. Pas skadimit të kësaj kohe, klienti hyn në gjendjen MBYLLUR dhe porta lokale bëhet sërish e disponueshme për lidhje të reja.

Gjithashtu është e mundur që lidhja të ndërpritet me një shtrëngim duarsh 3-palësh, ku hosti A dërgon një FIN, hosti B përgjigjet me një FIN & ACK (duke kombinuar dy hapa në një), dhe më pas hosti A i kthen një ACK.

Disa sisteme operative, siç është Linux zbatojnë një sekuencë mbylljeje gjysmë-dupleks. Nëse hosti mbyll në mënyrë aktive një lidhje ndërkohë që ende ka të dhëna hyrëse të palexuara, ai dërgon një sinjal RST në vend të FIN, duke humbur kështu të gjitha të dhënat e marra. Kjo siguron që aplikacioni TCP të njoftohet për humbjen e të dhënave.

Një lidhje mund të jetë në gjendje gjysmë të hapur, ku njëra anë e ka ndërprerë lidhjen, por ana tjetër ende jo. Pala që e ka përfunduar lidhjen nuk mund të dërgojë më të dhëna, ndërsa pala tjetër mundet. Ana që ka përfunduar duhet të vazhdojë të pranojë dhe të lexojë të dhënat derisa edhe pala tjetër të ndërpresë lidhjen.

Përdorimi i burimeve

Shumica e implementimeve ruajnë një hyrje në një tabelë që lidh një seancë me procesin përkatës të sistemit operativ që po funksionon. Meqenëse paketat TCP nuk përfshijnë një identifikues sesioni, të dy pikat fundore e identifikojnë sesionin duke përdorur adresën IP dhe portin e klientit. Sa herë që pranohet një paketë, implementimi i TCP-së kryen një kërkim në këtë tabelë për të gjetur procesin e destinacionit. Çdo hyrje në tabelë njihet si Bllok Kontrolli i Transmetimit (TCB). Ai përmban informacione rreth pikave fundore (adresat IP dhe portet), statusit të lidhjes, të dhënave të nevojshme për paketat që shkëmbehen, si dhe buffer-ave për dërgimin dhe marrjen e të dhënave..

Numri i seancave në anën e serverit është i kufizuar vetëm nga memoria dhe mund të rritet me mbërrijnë lidhje të reja, por klienti duhet të ndajë një port të përkohshëm përpara se të dërgojë SYN-in e parë në server. Ky port mbetet i rezervuar gjatë gjithë kohës së komunikimit dhe në mënyrë efektive kufizon numrin e lidhjeve dalëse që mund të krijohen nga secila adresë IP e klientit. Nëse një aplikacion nuk mbyll siç duhet lidhjet e panevojshme, klienti mund të konsumojë të gjitha burimet e disponueshme dhe të mos jetë në gjendje të krijojë lidhje të reja TCP, madje edhe për aplikacione të tjera

Të dy pikat fundore duhet të kenë gjithashtu hapësirë për paketat që nuk janë pranuar ende dhe për të dhënat që janë marrë, por ende nuk janë lexuar..

Transferimi i të dhënave

Protokolli i Kontrollit të Transmetimit ndryshon në disa karakteristika kryesore krahasuar me te tjeret, rrjedhimisht me Protokollin e Datagramit të Përdoruesit :

• Transferimi i të dhënave i renditur: hosti i destinacionit riorganizon segmentet sipas një numri rendor
• Ritransmetimi i paketave të humbura: çdo rrjedhë kumulative e papranuar ritransmetohet
• Transferim i të dhënave pa gabime: paketat e korruptuara trajtohen si të humbura dhe ritransmetohen
• Kontrolli i rrjedhës kufizon shpejtësinë me të cilën dërguesi transferon të dhëna për të siguruar një dorëzim të besueshëm. Marrësi vazhdimisht i jep dërguesit një sinjal për të treguar se sa të dhëna mund të pranojë. Kur memoria e hostit marrës mbushet, konfirmimi i ardhshëm ndalon përkohësisht transferimin, duke i dhënë kohë përpunimit të të dhënave në memorje
• Kontrolli i mbingarkesës: paketat e humbura (të supozuara për shkak të mbingarkesës) shkaktojnë një ulje të shkallës së shpërndarjes së të dhënave

Transmetim i besueshëm

TCP përdor një numër rendor për të identifikuar secilin bajt të të dhënave që transmetohen. Ky numër rendor tregon renditjen e bajteve që dërgohen nga secili kompjuter, duke siguruar që të dhënat të mund të rindërtohen në saktësi dhe në radhën e duhur në destinacion, pavarësisht nga ndonjë dërgesë jashtë renditjeje që mund të ndodhë. Numri rendor i bajtit të parë zgjidhet nga transmetuesi për paketën e parë, i cili shënohet me flamurin SYN. Ky numër mund të jetë i cfaredoshem dhe, në fakt, duhet të jetë i paparashikueshëm për t'u mbrojtur nga sulmet e parashikimit të sekuencës TCP .

Konfirmimet (ACK) dërgohen nga marrësi me një numër rendor për t’i treguar dërguesit se të dhënat janë pranuar deri në bajtin e specifikuar. ACK-të nuk do të thotë që të dhënat janë dorëzuar tashmë aplikacionit; ato vetëm tregojnë se përgjegjësia për dorëzimin e të dhënave është kaluar te pala marrëse

Besueshmëria në TCP arrihet përmes zbulimit të paketave të humbura nga dërguesi dhe ritransmetimit të tyre. TCP përdor dy teknika kryesore për identifikimin e humbjeve: kohëzgjatjen e ritransmetimit (RTO) dhe konfirmimet kumulative të dyfishta (DupACKs).

Kur një segment TCP ritransmetohet, ai mban të njëjtin numër rendor si përpjekja origjinale e dërgimit. Kjo mënyrë e dorëzimit dhe renditjes logjike të të dhënave bën që, kur konfirmimi pranohet pas një ritransmetimi, dërguesi të mos mund të dallojë nëse po konfirmohet transmetimi origjinal apo ritransmetimi—fenomen i njohur si 'paqartësia e ritransmetimit TCP shkakton kompleksitet për shkak të paqartësisë së ritransmetimit.

Ritransmetim i bazuar në ACK të dyfishtë

Nëse humbet një segment i vetëm (p.sh., segmenti me numrin 100) në një rrjedhë, marrësi nuk mund të pranojë paketat me numra më të mëdhenj se 100, sepse përdor konfirmime kumulative (ACK). Për pasojë, marrësi vazhdon të konfirmojë përsëri segmentin 99 me çdo paketë të re që merr. Ky konfirmim i dyfishtë përdoret si sinjal për humbjen e paketës. Kështu, nëse dërguesi merr tre konfirmime të dyfishta për segmentin 99, ai ritransmeton segmentin e fundit që nuk është konfirmuar. Përdoret pragun prej tre për të shmangur ritransmetimet e panevojshme që mund të shkaktohen nga rirenditja e segmenteve në rrjet. Ky prag është efektiv në parandalimin e ritransmetimeve të rreme për shkak të riporositjes. Disa implementime TCP përdorin njohje selektive (SACK) për të ofruar reagime të qarta në lidhje me segmentet që janë marrë. Kjo përmirëson shumë aftësinë e TCP për të ritransmetuar segmentet e duhura.

Paqartësia në ritransmetim mund të shkaktojë ritransmetime të shpejta dhe të kota, si dhe shmangie të gabuar të mbingarkesës, nëse riporositjet tejkalojnë pragun e konfirmimit të dyfishtë. Në dy dekadat e fundit, është vërejtur më shumë riorganizim i paketave në internet gjë që bëri që implementimet e TCP, të tilla si ajo në bërthamën Linux, të miratonin metoda heuristike për të shkallëzuar pragun e konfirmimit të dyfishtë. Kohët e fundit, here pas here ka pasur përpjekje për të hequr plotësisht ritransmetimet e shpejta të bazuara në ACK të dyfishta dhe për t'i zëvendësuar ato me ato të bazuara në kohëmatës. (Nuk duhet ngatërruar me RTO-në klasike të diskutuar më poshtë). Algoritmi i zbulimit të humbjeve bazuar në kohë i quajtur Konfirmimi i Fundit (RACK) është adoptuar si algoritmi parazgjedhur në Linux dhe Windows.

Ritransmetim i bazuar në skadimin e kohës

Kur një dërgues transmeton një segment, ai inicializon një kohëmatës me një vlerësim konservativ të kohës së mbërritjes së konfirmimit. Segmenti ritransmetohet nëse kohëmatësi skadon, me një prag të ri të skadimit të kohës prej dyfishi të vlerës së mëparshme, duke rezultuar në sjellje të tërheqjes eksponenciale . Zakonisht, vlera fillestare e kohëmatësit të ritransmetimit (RTO) llogaritet si RTT i lëmuar (smoothed RTT) + maksimumi i G dhe 4 herë variacioni i RTT-së, ku G përfaqëson granularitetin e orës së sistemit. Kjo mbron nga trafiku i tepërt i transmetimit për shkak të aktereve keqveres ose keqdashës, siç janë sulmuesit e mohimit të shërbimit " man-in-the-middle" .

Vlerësimet e sakta të kohës së kthimit (RTT) janë shumë të rëndësishme për rikuperimin e paketave të humbura, pasi ato i lejojnë dërguesit të supozojë se një paketë e papranuar është humbur pasi ka kaluar një periudhë e mjaftueshme kohe, për shembull gjatë përcaktimit të kohës së riprovimit (RTO). Paqartësia e ritransmetimit mund të bëjë që vlerësimi i RTT-së nga dërguesi të jetë i pasaktë. Në një mjedis me RTT të ndryshueshme, mund të ndodhin afate kohore të rreme: nëse RTT nënvlerësohet, atëherë RTO aktivizohet dhe shkakton një ritransmetim të panevojshëm dhe një nisje të ngadaltë. Pas një ritransmetimi të panevojshëm, kur mbërrijnë konfirmimet për transmetimet origjinale, dërguesi mund të besojë gabimisht se po konfirmon ritransmetimin dhe të përfundojë duke menduar se segmentet e dërguara midis transmetimit origjinal dhe ritransmetimit janë humbur. Kjo shkakton ritransmetime të mëtejshme të panevojshme, të cilat mund të çojnë në mbingarkim të lidhjes. Konfirmimi selektiv (SACK) mund të ndihmojë në zvogëlimin e këtij problemi. RFC 6298 specifikon që implementimet nuk duhet të përdorin segmente të ritransmetuara kur vlerësojnë RTT-në. Algoritmi i Karn siguron që një vlerësim i mirë RTT do të prodhohet — përfundimisht — duke pritur derisa të ketë një konfirmim të qartë përpara se të rregullojë RTO-në. Megjithatë, pas ritransmetimeve të rreme, mund të duhet kohë e konsiderueshme para se të arrijë një konfirmim kaq i qartë, duke degraduar performancën ndërkohë. Vulat kohore TCP zgjidhin gjithashtu problemin e paqartësisë së ritransmetimit në caktimin e RTO-së, megjithëse ato nuk e përmirësojnë domosdoshmërisht vlerësimin e RTT-së.

Zbulimi i gabimeve

Numrat e sekuencës i lejojnë marrësit të hedhë poshtë paketat e dyfishta dhe të rendisë në mënyrë të saktë paketat që vijnë jashtë renditjes. Konfirmimet ndihmojnë dërguesit të përcaktojnë kur duhet të ritransmetojnë paketat e humbura

Për të siguruar saktësinë, përfshihet një fushë kontrolli; shih § Checksum computation për detaje. Shuma e kontrollit TCP është një kontroll i dobët sipas standardeve moderne dhe normalisht çiftëzohet me një kontroll të integritetit CRC në shtresën 2, nën TCP dhe IP, siç përdoret në PPP ose në kornizën Ethernet . Megjithatë, futja e gabimeve në paketat që kalojnë ndërmjet hop-eve, të cilat janë të mbrojtura nga CRC, është e zakonshme. Shuma e kontrollit 16-bit e TCP-së arrin të kapë shumicën e këtyre gabimeve.

Kontroll i rrjedhës

TCP përdor një protokoll kontrolli të rrjedhës nga fillimi në fund për të shmangur që dërguesi të dërgojë të dhëna shumë shpejt që marrësi TCP t'i marrë dhe përpunojë ato në mënyrë të besueshme. Mekanizmi i kontrollit të rrjedhës është i domosdoshëm në mjedise ku pajisjet komunikojnë me shpejtësi të ndryshme në rrjet. Për shembull, nëse një kompjuter personal (PC) dërgon të dhëna te një telefon inteligjent që përpunon ngadalë të dhënat e marra, telefoni duhet të jetë në gjendje të rregullojë rrjedhën e të dhënave për të shmangur mbingarkesën.

TCP përdor një protokoll kontrolli të rrjedhës së dritares rrëshqitëse. Në secilin segment TCP, hosti marrës specifikon në fushën e dritares së marrjes sasinë e të dhënave shtesë (në bajt) që është i gatshëm të ruajë në buffer për atë lidhje. Host dërgues mund të dërgojë vetëm një sasi të caktuar të të dhënave pa pritur për një konfirmim dhe përditësimin e vlerës së dritares nga hosti marrës.

Numrat e sekuencës TCP dhe dritaret e pranimit sillen shumë si një orë. Dritarja e pranimit ndryshon çdo herë që marrësi merr dhe pranon një segment të ri të të dhënave. Pasi të mbarojnë numrat e sekuencës, numri i sekuencës kthehet përsëri në 0.

Kur një marrës njofton se madhësia e dritares është 0, dërguesi ndalon dërgimin e të dhënave dhe aktivizon kohëmatësin e persistencës. Ky kohëmatës përdoret për të parandaluar bllokimin e lidhjes që mund të ndodhë nëse humbet një përditësim i madhësisë së dritares nga marrësi, dhe dërguesi nuk mund të vazhdojë të dërgojë të dhëna pa marrë një përditësim të ri. Kur koha e kohëmatësit të persistencës skadon, dërguesi TCP përpiqet të rikuperohet duke dërguar një paketë të vogël (zakonisht me një bajt të vetëm), që marrësi ta konfirmojë dhe t’i japë një madhësi të re të dritares së pranimit.

Nëse marrësi përpunon të dhënat hyrëse në pjesë të vogla, ai mund të reklamojë vazhdimisht një dritare të vogël pranimi. Kjo njihet si sindroma e dritares qesharake, pasi është joefikase të dërgohen vetëm disa bajtë të të dhënave në një segment TCP, duke marrë parasysh ngarkesën relativisht të madhe të kokës TCP.

Kontroll i trafikut

Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHDAspekti i fundit kryesor i TCP është kontrolli i mbingarkesës . TCP përdor një numër mekanizmash për të arritur performancë të lartë dhe për të shmangur kolapsin kongjestiv, një situatë bllokimi ku performanca e rrjetit degradohet rëndë. Këto mekanizma kontrollojnë shkallën e të dhënave që hyjnë në rrjet, duke mbajtur rrjedhën e të dhënave nën një nivel që mund të shkaktonte kolaps. Ato gjithashtu japin një shpërndarje të drejtë afërsisht maksimale-minimale midis flukseve.

Konfirmimet për të dhënat e dërguara, ose mungesa e tyre, përdoren nga dërguesit për të nxjerrë përfundime mbi gjendjen e rrjetit midis dërguesit dhe marrësit TCP. Së bashku me kohëmatësit, dërguesit dhe marrësit TCP mund të përshtatin mënyrën e rrjedhjes së të dhënave. Kjo zakonisht quhet kontrolli i mbingarkesës ose shmangia e mbingarkesës.

Implementimet moderne të portokolit TCP përmbajnë katër algoritme të ndërthurura: nisje e ngadaltë, shmangie e mbingarkesës, ritransmetim i shpejtë dhe rikuperim i shpejtë .

Përveç kësaj, dërguesit përdorin një kohëzgjatje ritransmetimi (RTO) që bazohet në kohën e parashikuar të udhëtimit vajtje-ardhje (RTT) midis dërguesit dhe marrësit, si dhe ndryshimin në këtë kohë vajtje-ardhje. Ka hollësi në vlerësimin e RTT-së. Për shembull, dërguesit duhet të jenë të kujdesshëm kur llogarisin mostrat e RTT për paketat që dërgohen përsëri; zakonisht ata përdorin Algoritmin e Karn-it ose vulat kohore të TCP-së. Këto mostra individuale RTT më pas mesatarizohen me kalimin e kohës për të krijuar një kohë të zbutur vajtje-ardhje (SRTT) duke përdorur algoritmin e Jacobson-it . Kjo vlerë SRTT është ajo që përdoret si vlerësim i kohës së udhëtimit vajtje-ardhje.

Përmirësimi i TCP-së për të trajtuar në mënyrë të besueshme humbjet, për të minimizuar gabimet, për të menaxhuar mbingarkesën dhe për të optimizuar performancën në mjedise me shpejtësi shumë të lartë janë fusha të vazhdueshme kërkimi dhe zhvillimi në standardet e rrjeteve. Si rezultat, ekzistojnë një numër variacionesh të algoritmit për shmangien e mbingarkesës së TCP-së .

Madhësia maksimale e segmentit

Madhësia maksimale e segmentit (MSS) është sasia më e madhe e të dhënave, e specifikuar në bajt, që TCP është i gatshëm të marrë në një segment të vetëm. Për te pasur performancën më të mirë, MSS duhet të vendoset mjaftueshëm i vogël për të shmangur fragmentimin e IP, i cili mund të çojë në humbje të paketave dhe ritransmetime të tepërta. Për ta arritur këtë, zakonisht MSS njoftohet nga secila palë duke përdorur opsionin MSS kur vendoset lidhja TCP. Vlera e opsionit rrjedh nga madhësia maksimale e njësisë së transmetimit (MTU) të shtresës së lidhjes së të dhënave të rrjeteve në të cilat dërguesi dhe marrësi janë të lidhur drejtpërdrejt. Dërguesit TCP mund të përdorin zbulimin e MTU-së së shtegut për të nxjerrë përfundimin e MTU-së minimale përgjatë shtegut të rrjetit midis dërguesit dhe marrësit, dhe ta përdorin këtë për të rregulluar dinamikisht MSS-në për të shmangur fragmentimin e IP-së brenda rrjetit.

Njoftimi i MSS mund edhe ndryshe të quhet edhe negocim i MSS, por, në kuptimin e ngushtë të fjalës, MSS nuk negociohet . Dy vlera plotësisht të pavarura të MSS lejohen për dy drejtimet e rrjedhës së të dhënave në një lidhje TCP, kështu që nuk ka nevojë të bihet dakord për një konfigurim të përbashkët MSS për një lidhje dypalëshe.

Mirënjohje selektive

Mbështetja vetëm në skemën kumulative të konfirmimit të përdorur nga TCP origjinal mund të shpie në joefikasitet kur humbasin paketat. Për shembull, supozojmë se bajtet me numër rendor 1,000 deri në 10,999 dërgohen në 10 segmente të ndryshme TCP me madhësi të barabartë, dhe segmenti i dytë (numrat e rendor 2,000 deri në 2,999) humbet gjatë transmetimit. Në një protokoll të pastër kumulativ konfirmimi, marrësi mund të dërgojë vetëm një vlerë kumulative ACK prej 2,000 (numri rendor menjëherë pas numrit të fundit rendor të të dhënave të marra) dhe nuk mund të thotë se ka marrë me sukses bajtet nga 3,000 deri në 10,999. Kështu, dërguesi mund të duhet të ridërgojë të gjitha të dhënat duke filluar me numrin rendor 2,000.

Për të lehtësuar këtë problem, TCP përdor opsionin e konfirmimit selektiv (SACK), të përcaktuar në vitin 1996 në RFC 2018, i cili i lejon marrësit të pranojë blloqe të ndërprera paketash që janë marrë saktë, përveç numrit rendor menjëherë pas numrit të fundit rendor të bajtit të fundit të vazhdueshëm të marrë në mënyrë të njëpasnjëshme, si në konfirmimin bazë TCP. Konfirmimi mund të përfshijë një numër blloqesh SACK, ku secili bllok SACK përbëhet nga Skaji i Majtë i Bllokut (numri i parë rendor i bllokut) dhe Skaji i Djathtë i Bllokut (numri rendor menjëherë pas numrit rendor të fundit të bllokut). Një bllok është një diapazon i vazhdueshëm të dhënash që marrësi e ka marrë saktë.. Në shembullin e mësipërm, marrësi do të dërgonte një segment ACK me një vlerë kumulative ACK prej 2,000 dhe një kokë opsioni SACK me numra sekuencialë 3,000 dhe 11,000. Dërguesi do të ritransmetonte në përputhje me rrethanat vetëm segmentin e dytë me numra sekuencialë nga 2,000 deri në 2,999.

Një dërgues i protokolit TCP mund ta interpretojë një shpërndarje të segmentit jashtë rendit si një segment të humbur. Nëse vepron kështu, dërguesi TCP do të ritransmetojë segmentin përpara paketës jashtë rendit dhe do të ngadalësojë shpejtësinë e dorëzimit të të dhënave për atë lidhje. Opsioni dublikate-SACK, një zgjerim i opsionit SACK që u përcaktua në maj 2000 në RFC 2883, e zgjidh këtë problem. Pasi marrësi TCP zbulon një paketë të dytë të kopjuar, ai dërgon një D-ACK për të treguar se nuk janë humbur segmente, duke i lejuar dërguesit TCP të rivendosë shkallën më të lartë të transmetimit.

Njoftimet selektive mund të 'mos pranohen', ku marrësi hedh poshtë në mënyrë të njëanshme të dhënat e pranuara në mënyrë selektive. RFC 2018 e dekurajonte këtë sjellje, por nuk e ndalonte, duke i dhënë marrësit mundësinë e anulimit, për shembull, nëse i mbaronte hapësira e memorjes. Kjo mundësi e mosrespektimit çon në kompleksitet më të madh në implementim si për dërguesit ashtu edhe për marrësit, dhe gjithashtu imponon një kosto memorieje për dërguesin.

Shkallëzimi i dritares

Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHDPër përdorim më efikas të rrjetave me gjerësi të lartë bande, mund të përdoret një madhësi më e madhe TCP. Një fushë e madhësisë së dritares TCP prej 16-bitësh kontrollon rrjedhën e të dhënave dhe vlera e saj është e kufizuar në 65,535 bajt. Meqenëse fusha e madhësisë nuk mund të zgjerohet përtej këtij limiti, përdoret një faktor shkallëzimi. Opsioni i shkallëzimit të dritares TCP, siç përcaktohet në RFC 1323, është një opsion i përdorur për të rritur madhësinë maksimale të dritares në 1 gigabajt. Shkallëzimi në këto madhësi më të mëdha të dritareve është i nevojshëm për akordimin e TCP-së .

Opsioni i shkallës së dritares përdoret vetëm gjatë shtrëngimit të dorës 3-palëshe TCP. Vlera e shkallës së dritares përfaqëson numrin e bitëve për të zhvendosur majtas fushën e madhësisë së dritares 16-bitëshe gjatë interpretimit të saj. Vlera e shkallës së dritares mund të caktohet nga 0 (pa shkallëzim) deri në 14 për secilin drejtim në mënyrë të pavarur. Të dyja palët duhet të dërgojnë opsionin për shkallëzimin e dritares në segmentet e tyre SYN për të aktivizuar shkallëzimin në të dy drejtimet.

Disa routerë dhe firewall-e paketash rishkruajnë faktorin e shkallëzimit të dritares gjatë një transmetimi. Kjo bën që palët dërguese dhe marrëse të marrin madhësi të ndryshme të dritareve TCP. Rezultati është një trafik i paqëndrueshëm që mund të jetë shumë i ngadaltë. Problemi është i dukshëm në disa faqe interneti pas një ruteri me defekt.

Vulat kohore TCP

Vulat kohore të TCP, të përcaktuara në RFC 1323 në vitin 1992, mund të ndihmojnë TCP të përcaktojë se në cilin rend u dërguan paketat. Vulat kohore TCP normalisht nuk janë të lidhura me orën e sistemit dhe fillojnë nga një vlerë e rastësishme. Shumë sisteme operative do ta rrisin vulën kohore për çdo milisekondë të kaluar; megjithatë, RFC-ja thotë vetëm se shenjat e tik-takit duhet të jenë proporcionale.

• një vlerë kohore e dërguesit prej 4 bajtësh (vula ime kohore)
• një vlerë kohore prej 4 bajtësh për përgjigjen me jehonë (vula kohore më e fundit e marrë nga ju).

Vulat kohore TCP përdoren në një algoritëm të njohur si Mbrojtja kundër numrave të sekuencës së mbështjellë (PAWS). Ky algoritëm përdoret kur dritarja e pranimit kalon kufirin rrethues të numrit të sekuencës. Kur një paketë ritransmetohet dhe lind dyshimi nëse numri rendor i saj i përket ritransmetimit të fundit apo një të mëparshmi, vula kohore përdoret për të vendosur se cila prej tyre është më e freskët.

Gjithashtu, algoritmi i zbulimit Eifel përdor vulat kohore TCP për të përcaktuar nëse ritransmetimet ndodhin për shkak të humbjes së paketave apo thjesht për shkak të vonesave..

Vulat kohore TCP janë të aktivizuara si parazgjedhje në Linux, ndërsa janë të çaktivizuara si parazgjedhje në Windows Server 2008, 2012 dhe 2016

Statistikat e fundit tregojnë se niveli i përdorimit të vulës kohore TCP ka qëndruar rreth 40%, pasi mbështetja për këtë veçori është ndërprerë nga Windows Server që nga Windows Server 2008..

Të dhëna jashtë brezit

Është e mundur që të ndërpritet transmetimi në radhë përpara se të përfundojë ai, në vend që të pritet përfundimi i tij. Kjo bëhet duke specifikuar të dhënat si urgjente, duke i shënuar ato si të dhëna jashtë brezit (OOB). Kjo tregon programit marrës që t’i përpunojë menjëherë. Kur përpunimi përfundon, TCP njofton aplikacionin dhe rifillon transmetimin e të dhënave në rrjedhën normale. Një shembull është përdorimi i TCP-së për një seancë hyrjeje në distancë, ku përdoruesi mund të dërgojë një komandë tastiere që ndërpret ose ndalon programin që po ekzekutohet në distancë, pa pritur që programi të përfundojë transferimin aktual.

Treguesi urgjent ndryshon vetëm mënyrën e përpunimit në hostin e largët dhe nuk përshpejton asnjë përpunim brenda rrjetit. Aftësia zbatohet në mënyra të ndryshme ose dobët në sisteme të ndryshme, ose mund të mos mbështetet fare. Kur është në dispozicion, rekomandohet të supozohet se vetëm një bajt i vetëm i të dhënave jashtë brezit (OOB) trajtohet në mënyrë të besueshme. Meqenëse kjo veçori nuk përdoret shpesh, nuk është testuar mirë në disa platforma dhe është shoqëruar me dobësi, për shembull WinNuke .

Dërgimi i detyruar i të dhënave

Normalisht, TCP pret për 200 ms për një paketë të plotë të të dhënave për t'u dërguar ( Algoritmi i Nagle përpiqet të grupojë mesazhe të vogla në një paketë të vetme). Kjo pritje krijon vonesa të vogla, por potencialisht serioze, nëse përsëritet vazhdimisht gjatë një transferimi skedarësh. Për shembull, një bllok tipik dërgimi është 4 KB, ndërsa MSS (Maksimum Segment Size) tipik është 1460 bajtë, kështu që në një lidhje Ethernet 10 Mbit/s dërgohen dy paketa, secila me kohë rreth 1.2 ms, të ndjekura nga një paketë e tretë që mbart 1176 bajtë të mbetura, e cila ndalet për rreth 197 ms, sepse TCP po pret mbushjen e buffer-it. Në rastin e telnet-it, çdo shtypje tastiere nga përdoruesi jehonohet nga serveri para se përdoruesi ta shohë në ekran. Një vonesë e tillë do të ishte shumë shqetësuese.

Vendosja e opsionit të soketit TCP_NODELAY mbivendos vlerën e parazgjedhur 200 vonesë dërgimi ms. Programet e aplikacioneve përdorin këtë opsion socket për të detyruar dërgimin e të dhënave menjëherë pas shkrimit të një karakteri ose një rreshti karakteresh

RFC 793 e përcakton bitin push pershembull si "një mesazh për grumbullin TCP marrës për të dërguar këto të dhëna menjëherë deri te aplikacioni marrës". Nuk ka asnjë mënyrë për ta treguar ose kontrolluar atë në hapësirën e përdoruesit duke përdorur socket-et Berkeley ; kontrollohet vetëm nga pirgu i protokolleve .

Dobësitë

TCP mund të sulmohet në mënyra të ndryshme. Rezultatet e një vlerësimi të plotë të sigurisë së TCP-së, së bashku me zbutjet e mundshme për problemet e identifikuara, u botuan në vitin 2009, dhe u ndoqën brenda IETF-së deri në vitin 2012. Dobësitë e dukshme përfshijnë mohimin e shërbimit, rrëmbimin e lidhjes, veton TCP dhe sulmin e rivendosjes së TCP .

Mohimi i shërbimit

Duke përdorur një adresë IP të falsifikuar dhe duke dërguar në mënyrë të përsëritur paketa SYN të mbledhura qëllimisht, të ndjekura nga shumë paketa ACK, sulmuesit mund të bëjnë që serveri të marre sasi të mëdha burimesh duke mbajtur gjurmët e lidhjeve të rreme. Kjo njihet si një sulm përmbytjeje SYN . Zgjidhjet e propozuara për këtë problem përfshijnë cookie-t SYN dhe enigmat kriptografike, megjithëse cookie-t SYN vijnë me grupin e tyre të dobësive. Sockstress është një sulm i ngjashëm, i cili mund të zbutet me menaxhimin e burimeve të sistemit. Një sulm i avancuar DoS që përfshinte shfrytëzimin e kohëmatësit të vazhdueshëm TCP u analizua në Phrack Nr. 66. Përmbytjet PUSH dhe ACK janë variante të tjera.

Rrëmbimi i lidhjes

Një sulmues që arrin të përgjojë një seancë TCP dhe të ridrejtojë paketat mund të rrëmbejë lidhjen TCP. Për ta realizuar këtë, sulmuesi mëson numrin rendor nga komunikimi në vazhdim dhe krijon një segment të falsifikuar që duket si segment i vlefshëm në rrjedhën e të dhënave. Një rrëmbim i thjeshtë mund të shkaktojë pranimin e gabuar të një pakete në njërën prej palëve. Kur hosti marrës pranon segmentin e rremë, sinkronizimi ndërmjet dy palëve humbet. Rrëmbimi mund të kombinohet me mashtrim ARP ose sulme të tjera të rrugëzimit që i lejojnë një sulmuesi të marrë kontroll të përhershëm të lidhjes TCP.

Imitimi i një adrese IP të ndryshme nuk ishte i vështirë para RFC 1948 kur numri fillestar i sekuencës ishte lehtësisht i hamendësueshëm. Implementimet e mëparshme lejonin që një sulmues të dërgonte një seri paketash që marrësi do të besonte se vinin nga një adresë IP tjetër, pa pasur nevojë të ndërpriste komunikimin përmes sulmeve ARP ose rrugëzimi. Mjafton që hosti legjitim i adresës IP të imituar të jetë jashtë funksionit, ose të dëmtohet duke përdorur sulme mohimi të shërbimit . Kjo është arsyeja pse numri fillestar i renditjes tani zgjidhet rastësisht.

Vetoja e TCP-së

Një sulmues që mund të përgjojë komunikimin dhe të parashikojë madhësinë e paketës tjetër që do të dërgohet, mund të bëjë që marrësi të pranojë një ngarkesë keqdashëse pa ndërprerë lidhjen ekzistuese. Sulmuesi injekton një paketë keqdashëse me numrin rendor dhe madhësinë e ngarkesës së paketës së ardhshme të pritur. Kur paketa legjitime më pas pranohet, ajo ka të njëjtin numër rendor dhe gjatësi si një paketë që tashmë është marrë, prandaj hiqet në heshtje si një paketë e kopjuar — kështu, paketa legjitime bllokohet nga ajo keqdashëse. Ndryshe nga rrëmbimi i lidhjes, lidhja nuk desinkronizohet kurrë dhe komunikimi vazhdon normalisht pasi pranohet ngarkesa keqdashëse. Mbrojtja e TCP-së i jep sulmuesit më pak kontroll mbi komunikimin, por e bën këtë sulm veçanërisht të vështirë për t’u zbuluar. E vetmja shenjë për marrësin që diçka nuk shkon është pranimi i një pakete të dyfishtë, një dukuri normale në rrjetet IP. Dërguesi i paketës së dubluar nuk vëren asnjë shenjë të sulmit..

Portat TCP

Një lidhje me protokolin TCP identifikohet nga një katërfish i përbërë nga adresa e burimit, porta e burimit, adresa e destinacionit dhe porta e destinacionit. Numrat e portave përdoren për të identifikuar shërbime të ndryshme dhe për të lejuar lidhje të shumëfishta midis hosteve. TCP përdor numra portash 16-bitësh, duke ofruar 65,536 vlera të mundshme për secilën prej portave burimore dhe destinacionore. Varësia e identitetit të lidhjes nga adresat do të thotë që lidhjet TCP janë të lidhura me një shteg të vetëm rrjeti; TCP nuk mund të përdorë rrugë të tjera që kanë në dispozicion hostet me shumë shtëpi dhe lidhjet ndërpriten nëse adresa e një pike fundore ndryshon.

Numrat e porteve kategorizohen në tre kategori themelore: të njohura, të regjistruara dhe dinamike ose private. Portat e njohura caktohen nga Autoriteti i Numrave të Caktuar në Internet (IANA) dhe zakonisht përdoren nga proceset në nivel sistemi. Aplikacionet e njohura që funksionojnë si serverë dhe që dëgjojnë pasivisht për lidhje zakonisht përdorin këto porta. Disa shembuj përfshijnë: FTP (20 dhe 21), SSH (22), TELNET (23), SMTP (25), HTTP mbi SSL/TLS (443) dhe HTTP (80). Portat e regjistruara përdoren zakonisht nga aplikacionet e përdoruesve fundorë si porta burimore të përkohshme kur lidhen me serverë, por ato gjithashtu mund të përdoren për të identifikuar shërbime të emërtuara që janë regjistruar nga palë të treta. Portat dinamike ose private mund të përdoren edhe nga aplikacionet e përdoruesve fundorë. Megjithatë, këto porta zakonisht nuk kanë ndonjë kuptim të veçantë jashtë një lidhjeje specifike TCP.

Përkthimi i Adresës së Rrjetit (NAT) zakonisht përdor numra dinamikë portash në anën publike për të drejtuar trafikun midis një rrjeti publik dhe një nënrrjeti privat, duke mundësuar që shumë adresa IP private (së bashku me portet përkatëse) të ndajnë një adresë të vetme publike

Zhvillimi

TCP si protokol eshte n kompleks. Megjithatë, ndërsa janë bërë dhe propozuar përmirësime të rëndësishme gjatë viteve, funksionimi i tij më themelor nuk ka ndryshuar ndjeshëm që nga specifikimi i tij i parë RFC 675 në vitin 1974, dhe specifikimi v4 RFC 793, i botuar në shtator 1981. RFC 1122, i botuar në tetor 1989, sqaroi një numër kërkesash për zbatimin e protokollit TCP. Një listë me 8 specifikimet e kërkuara dhe mbi 20 përmirësime që inkurajohen fuqimisht është e disponueshme në RFC 7414 . Midis kësaj liste është RFC 2581, TCP Congestion Control, një nga RFC-të më të rëndësishme të lidhura me TCP në vitet e fundit, i cili përshkruan algoritme të përditësuara që shmangin mbingarkesën e panevojshme. Në vitin 2001, u shkrua RFC 3168 për të përshkruar Njoftimin Eksplicit të Kongjestionit (ECN), një mekanizëm sinjalizimi për shmangien e bllokimit.

Algoritmi origjinal i shmangies së mbingarkesës së TCP njihej si TCP Tahoe, por që atëherë janë propozuar shumë algoritme alternative (duke përfshirë TCP Reno, TCP Vegas, FAST TCP, TCP New Reno dhe TCP Hybla ).

TCP me shumë shtigje (MPTCP) është një përpjekje e vazhdueshme brenda IETF që synon të lejojë një lidhje TCP të përdorë shtigje të shumëfishta për të maksimizuar përdorimin e burimeve dhe për të rritur redundancën. Redundanca e ofruar nga Multipath TCP në kontekstin e rrjeteve pa tel mundëson përdorimin e njëkohshëm të rrjeteve të ndryshme, duke rritur rendimentin dhe përmirësuar aftësitë e kalimit (handover). Multipath TCP ofron gjithashtu përfitime të ndjeshme të performancës në mjediset e qendrave të të dhënave. Implementimi referues i Multipath TCP u zhvillua në kernelin Linux. Multipath TCP përdoret për të mbështetur aplikacionin e njohjes së zërit Siri në iPhone, iPad dhe Mac.

tcpcrypt është një zgjerim i propozuar në korrik 2010 për të ofruar enkriptim në nivel transporti direkt në vetë TCP-në. Është projektuar të funksionojë në mënyrë transparente dhe nuk kërkon ndonjë konfigurim. Ndryshe nga TLS (SSL), vetë tcpcrypt nuk ofron autentifikim, por ofron primitivë të thjeshtë që mund të përdoren nga aplikacionet për të realizuar autentifikimin. RFC-ja për tcpcrypt u publikua nga IETF në maj të vitit 2019.

TCP Fast Open është një zgjidhje për të pershpejtuar hapjen e lidhjeve TCP të njëpasnjëshme midis dy pikave fundore. Funksionon kryesore duke anashkaluar shtrëngimin e dorës në tre drejtime duke përdorur një cookie kriptografike. Është i ngjashëm me një propozim të mëparshëm të quajtur T/TCP, i cili nuk u miratua gjerësisht për shkak të problemeve të sigurisë. TCP Fast Open u publikua si RFC 7413 në vitin 2014.

Ai eshte i propozuar në maj 2013, Reduktimi Proporcional i Shkallës (PRR) është një zgjerim TCP i zhvilluar nga inxhinierët e Google. PRR siguron që madhësia e dritares TCP pas rikuperimit të jetë sa më afër pragut të nisjes së ngadaltë të jetë e mundur. Algoritmi është projektuar për të përmirësuar shpejtësinë e rikuperimit dhe është algoritmi i parazgjedhur i kontrollit të mbingarkesës në bërthamat Linux 3.2+.

Propozime të vjetruara

Transaksionet e Cookie-ve TCP (TCPCT) janë një zgjidhje e propozuar në dhjetor 2009 për të siguruar serverat kundër sulmeve të mohimit të shërbimit. Ndryshe nga cookie-t SYN, TCPCT nuk bie ndesh me zgjerime të tjera TCP, siç është shkallëzimi i dritares . TCPCT u krijua për shkak të nevojave të DNSSEC, ku serverët duhet të trajtojnë një numër të madh lidhjesh TCP jetëshkurtra. Në vitin 2016, TCPCT u anulua në favor të TCP Fast Open. Statusi i RFC-së origjinale u ndryshua në historik .

Implementimet e harduerit

Një mënyrë për të kapërcyer kërkesat e fuqisë përpunuese të protokolit TCP është ndërtimi i implementimeve harduerike të tij, të njohura gjerësisht si motorë shkarkimi TCP (TOE). Problemi kryesor i TOE-ve është se ato janë të vështira për t'u integruar në sistemet kompjuterike, duke kërkuar ndryshime të gjera në sistemin operativ të kompjuterit ose pajisjes kompjuterike.

Imazhi i telit dhe osifikimi

Të dhënat me tela të TCP ofrojnë mundësi të konsiderueshme për mbledhjen dhe modifikimin e informacionit për vëzhguesit në rrugë, pasi meta të dhënat e protokollit transmetohen në tekst të qartë . Ndërsa kjo transparencë është e dobishme për operatorët e rrjetit dhe studiuesit, informacioni i mbledhur nga meta të dhënat e protokollit mund të zvogëlojë privatësinë e përdoruesit fundor. Kjo dukshmëri dhe lakueshmëri e meta të dhënave ka bërë që TCP të jetë i vështirë për t'u zgjeruar — një rast i osifikimit të protokollit — pasi çdo nyje e ndërmjetme (një ' kuti e mesme ') mund të marrë vendime bazuar në ato meta të dhëna ose edhe t'i modifikojë ato, duke thyer parimin nga fillimi në fund . Një studim zbuloi se një e treta e shtigjeve në internet hasin të paktën një ndërmjetës që modifikon metat të dhënat e TCP-së, ndërsa 6.5% e shtigjeve preken nga efekte të dëmshme apo shteruese të shkaktuara nga ndërmjetësit. Shmangia e rreziqeve të zhvillimit nga ndërmjetësit vendosi kufizime të konsiderueshme në projektimin e MPTCP, dhe vështirësitë e shkaktuara nga ndërmjetësit kanë penguar vendosjen e TCP te shpjet në shfletuesit e internetit . Një burim tjetër i osifikimit është vështirësia e modifikimit të funksioneve TCP në pikat fundore, zakonisht në bërthamën e sistemit operativ ose në harduer me një motor shkarkimi TCP .

Performanca

Meqenëse TCP u ofron aplikacioneve abstraksionin e një rrjedhe bajtesh të besueshme, ai mund të vuajë nga bllokimi i kokës së linjës: nëse paketat rirregullohen ose humbasin dhe duhet të ritransmetohen (dhe për pasojë rirregullohen), të dhënat nga pjesët e mëvonshme të rrjedhës mund të mbërrijnë përpara pjesëve të mëparshme në rend sekuencial. Megjithatë, këto të dhëna zakonisht nuk mund të përdoren derisa të jenë pranuar edhe të dhënat paraprake, duke shkaktuar vonesë në rrjet . Nëse shumë mesazhe të pavarura të nivelit më të lartë enkapsulohen dhe multipleksohen në një lidhje të vetme TCP, atëherë bllokimi i kokës së linjës mund të shkaktojë përpunimin e një mesazhi të marrë plotësisht që është dërguar më vonë për të pritur dorëzimin e një mesazhi që është dërguar më parë. Shfletuesit e uebit përpiqen të zbusin bllokimin e kokës së linjës duke hapur lidhje të shumta paralele. Kjo sjell koston e vendosjes së lidhjes në mënyrë të përsëritur, si dhe shumëfishimin e burimeve të nevojshme për të ndjekur këto lidhje në pikat fundore. Lidhjet paralele gjithashtu kanë kontroll të mbingarkesës që vepron në mënyrë të pavarur nga njëra-tjetra, në vend që të jenë në gjendje të bashkojnë informacionin së bashku dhe t'i përgjigjen më shpejt kushteve të vëzhguara të rrjetit; Modelet agresive fillestare të dërgimit të TCP mund të shkaktojnë mbingarkesë nëse hapen lidhje të shumta paralele; dhe modeli i drejtësisë për lidhje çon në një monopolizim të burimeve nga aplikacionet që ndjekin këtë qasje.

Vendosja e lidhjes është një kontribues i madh në vonesën siç përjetohet nga përdoruesit e internetit. Shtrëngimi i dorës trepalësh i TCP-së prezanton një RTT të latencës gjatë vendosjes së lidhjes përpara se të dhënat të mund të dërgohen. Për rrjedhat e shkurtra, këto vonesa janë shumë të rëndësishme. Siguria e Shtresës së Transportit (TLS) kërkon një shtrëngim duarsh më vete për shkëmbimin e çelësave gjatë vendosjes së lidhjes. Për shkak të dizajnit të shtresuar, shtrëngimi i duarve TCP dhe shtrëngimi i duarve TLS vazhdojnë në seri; shtrëngimi i duarve TLS nuk mund të fillojë derisa shtrëngimi i duarve TCP të ketë përfunduar. Dy RTT janë të nevojshme për krijimin e lidhjes me TLS 1.2 mbi TCP. TLS 1.3 lejon rifillimin e lidhjes zero RTT në disa rrethana, por, kur vendoset mbi TCP, një RTT është ende i nevojshëm për lidhjen TCP handshake, dhe kjo nuk mund të ndihmojë lidhjen fillestare; lidhjet zero RTT gjithashtu paraqesin sfida kriptografike, pasi shkëmbimi efikas, i sigurt për riprodhim dhe i sigurt për përpara i çelësave jo-interaktiv është një temë e hapur kërkimore. Me TCP Fast Open, të dhënat mund të përfshihen që në paketat fillestare të komunikimit (SYN dhe SYN-ACK), gjë që redukton vonesën duke shmangur një RTT gjatë fazës së krijimit të lidhjes. Megjithatë, TCP Fast Open ka qenë e vështirë për t'u vendosur për shkak të osifikimit të protokollit; Që prej 2020 , asnjë shfletues interneti nuk e përdori atë si parazgjedhje.

Prodhueshmëria e TCP-së ndikohet nga riorganizimi i paketave. Paketat e riorganizuara mund të shkaktojnë dërgimin e konfirmimeve të dyfishta, të cilat, nëse tejkalojnë një prag të caktuar, mund të çojnë në ritransmetim të rremë dhe në aktivizimin e mekanizmave të kontrollit të mbingarkesës. Sjellja e transmetimit mund të jetë gjithashtu e karakterizuar nga shpërthime të trafikut, pasi diapazonet e mëdha të të dhënave pranohen menjëherë kur arrin një paketë e riorganizuar në fillim të diapazonit, një situatë që ngjason me ndikimin e bllokimit të kokës së linjës në aplikacione. Blanton & Allman (2002) zbuluan se rendimenti ishte në përpjesëtim të zhdrejtë me sasinë e riporositjes, deri në një prag ku çdo riporositje shkakton ritransmetim të rremë. Zbutja e riorganizimit varet nga aftësia e dërguesit për të përcaktuar se ka dërguar një ritransmetim të rremë, dhe për këtë arsye nga zgjidhja e paqartësisë së ritransmetimit. Zvogëlimi i ritransmetimeve të rreme të shkaktuara nga riorganizimi mund të ngadalësojë rikuperimin nga humbja e vërtetë.

Njohja selektive mund të ofrojë përfitim të konsiderueshëm për rendimentin; Bruyeron, Hemon & Zhang (1998) matën fitime deri në 45%. Një faktor i rëndësishëm në përmirësim është se njohja selektive mund të shmangë më shpesh fillimin e ngadaltë pas një humbjeje dhe për këtë arsye mund të përdorë më mirë bandwidth-in e disponueshëm. Megjithatë, TCP mund të pranojë në mënyrë selektive vetëm deri në tre blloqe numrash sekuencialë në të njëjtën kohë. Kjo kufizon shkallën e ritransmetimit dhe mund të ndikojë në mënyrën e rikuperimit të humbjeve, duke shkaktuar edhe ritransmetime të panevojshme, sidomos në mjedise me humbje të larta..

TCP u projektua fillimisht për rrjetet me tela ku humbja e paketave konsiderohet si rezultat i mbingarkesës së rrjetit dhe madhësia e dritares së mbingarkesës zvogëlohet ndjeshëm si një masë paraprake. Megjithatë, lidhjet pa tel dihet se përjetojnë humbje sporadike dhe zakonisht të përkohshme për shkak të zbehjes, hijezimit, ndërprerjes së transmetimit, ndërhyrjes dhe efekteve të tjera radio, të cilat nuk janë rreptësisht mbingarkesë. Pas uljes (së gabuar) të madhësisë së dritares së mbingarkesës, për shkak të humbjes së paketave pa tel, mund të ketë fazë të shmangies së mbingarkesës me një rënie konservative të madhësisë së dritares. Kjo bën që lidhja radio të mos përdoret sa duhet. Janë kryer kërkime të gjera për të luftuar këto efekte të dëmshme. Zgjidhjet e sugjeruara mund të kategorizohen si zgjidhje nga fillimi në fund, të cilat kërkojnë modifikime në klient ose server, zgjidhje të shtresës së lidhjes, siç është Protokolli i Lidhjes Radio në rrjetet celulare, ose zgjidhje të bazuara në proxy të cilat kërkojnë disa ndryshime në rrjet pa modifikuar nyjet fundore. Një numër algoritmash alternative të kontrollit të mbingarkesës, të tilla si Vegas, Westwood, Veno dhe Santa Cruz, janë propozuar për të ndihmuar në zgjidhjen e problemit të rrjetit pa tel. 

Përshpejtimi

Ideja e një përshpejtuesi TCP është që të ndërpresë lidhjet TCP brenda procesorit të rrjetit dhe më pas të transmetojë të dhënat përmes një lidhjeje të dytë drejt sistemit fundor. Paketat e të dhënave që vijnë nga dërguesi ruhen në një tampon në nyjen përshpejtuese, e cila është përgjegjëse për ritransmetimet lokale në rast humbjeje paketash. Kështu, në rast të humbjeve, cikli i reagimit midis dërguesit dhe marrësit zvogëlohet në atë midis nyjes së përshpejtimit dhe marrësit, duke garantuar një dërgesë më të shpejtë të të dhënave te marrësi.

Duke qenë se TCP është një protokoll adaptiv i shpejtësisë, shpejtësia me të cilën dërguesi injekton paketat në rrjet varet drejtpërdrejt nga kushtet e ngarkesës në rrjet dhe nga kapaciteti i përpunimit të marrësit. Kushtet në rrjet vlerësohen nga dërguesi në bazë të konfirmimeve që ai pranon. Qendrat e përshpejtimit ndajnë rrugën e kthimit midis dërguesit dhe marrësit, duke siguruar kështu një kohë më të shkurtër të udhëtimit të kthimit (RTT) për paketat. Një RTT më i shkurtër është i dobishëm pasi mundëson një reagim më të shpejtë ndaj ndryshimeve në rrjet dhe një përshtatje më efektive të dërguesit për t'u përballur me këto ndryshime.

Disavantazhet e metodës përfshijnë faktin se seanca TCP duhet të kalojë përmes përshpejtuesit; kjo do të thotë se nëse rrugëzimi ndryshon dhe përshpejtuesi nuk është më në shteg, lidhja do të ndërpritet. Gjithashtu, kjo metodë shkatërron vetinë end-to-end të mekanizmit TCP ACK, pasi kur dërguesi pranon ACK-un, paketa është ruajtur vetëm në përshpejtues dhe nuk është dorëzuar drejtpërdrejt te marrësi.

Alternativat

Për shumë aplikacione, TCP nuk është i përshtatshëm, pasi aplikacioni zakonisht nuk mund të përpunojë paketat që mbërrijnë pas një pakete të humbur deri sa të marrë kopjen e ritransmetuar të asaj pakete. Kjo shkakton probleme për aplikacionet në kohë reale, të tilla si mediat streaming, lojërat shumëlojtarësh në kohë reale dhe zëri mbi IP (VoIP), ku në përgjithësi është më e dobishme të merren shumica e të dhënave në kohën e duhur sesa të renditen të gjitha të dhënat në rregull.

Për arsye historike dhe të performancës se rrjeteve, shumica e rrjeteve të zonave të ruajtjes (SAN) përdorin Protokollin e Kanalit me Fibra (FCP) mbi lidhjet e Kanalit me Fibra . Për sistemet e ngulitura, nisjen në rrjet dhe serverat që shërbejnë kërkesa të thjeshta nga një numër i madh klientësh (p.sh. serverat DNS ), kompleksiteti i TCP mund të jetë problem. Truke të tilla si transmetimi i të dhënave midis dy hosteve që janë të dy pas NAT (duke përdorur STUN ose sisteme të ngjashme) janë shumë më të thjeshta pa një protokoll relativisht kompleks si TCP në mes.

Në përgjithësi, aty ku protokoli TCP nuk është i përshtatshëm, përdoret Protokolli i të Dhënave të Përdoruesit (UDP). Kjo siguron të njëjtin multipleksim të aplikacionit dhe shuma kontrolli që ofron TCP, por nuk trajton rrjedha ose ritransmetim, duke i dhënë zhvilluesit të aplikacionit mundësinë për t'i koduar ato në një mënyrë të përshtatshme për situatën, ose për t'i zëvendësuar ato me metoda të tjera siç është korrigjimi i gabimit përpara ose fshehja e gabimeve .

Protokolli i Transmetimit të Kontrollit të Rrjedhës (SCTP) është një protokoll tjetër që ofron shërbime të besueshme të orientuara drejt lidhjes, të ngjashme me TCP. Është më i ri dhe dukshëm më kompleks se TCP, dhe ende nuk është përhapur gjerësisht. Megjithatë, është projektuar posaçërisht për t'u përdorur në situata ku besueshmëria dhe konsideratat në kohë pothuajse reale janë të rëndësishme.

Protokolli i Transportit Venturi (VTP) është një protokoll i patentuar pronësor që është dizajnuar për të zëvendësuar TCP në mënyrë transparente për të kapërcyer joefikasitetet e perceptuara që lidhen me transportin e të dhënave pa tel.

Algoritmi i shmangies së mbingarkesës TCP funksionon shumë mirë për mjedise ad-hoc ku dërguesi i të dhënave nuk dihet paraprakisht. Nëse mjedisi është i parashikueshëm, një protokoll i bazuar në kohë, siç është Modaliteti i Transferimit Asinkron (ATM), mund të shmangë mbingarkesën e ritransmetimit të protokolit te TCP-së.

Protokolli i Transferimit të të Dhënave (UDT) i bazuar në UDP ka efikasitet më të mirë se protokoli TCP në rrjetet që kanë vonesë të lartë të brezit të gjerë .

Protokolli i Transaksioneve Shumëqëllimëshe (MTP/IP) është një softuer i patentuar pronësor që është dizanjuar për të arritur në mënyrë adaptive rendiment të lartë dhe performancë të lartë transaksionesh në një gamë të gjerë kushtesh rrjeti, veçanërisht ato ku TCP perceptohet si joefikas.

Llogaritja e shumës së kontrollit

Shuma e kontrollit TCP për IPv4

Kur protokoli TCP funksionon mbi IPv4, metoda e përdorur për të llogaritur shumën e kontrollit përcaktohet si më poshtë:

Fusha e kontrollit është komplementi 16-bitësh i njëshave të shumës së komplementit të njëshave të të gjitha fjalëve 16-bitëshe në kokë dhe tekst. Llogaritja e shumës së kontrollit duhet të sigurojë rreshtimin 16-bit të të dhënave që përmblidhen. Nëse një segment përmban një numër tek oktetesh të kokës dhe tekstit, rreshtimi mund të arrihet duke e mbushur oktetin e fundit me zero në të djathtë të tij për të formuar një fjalë 16-bitëshe për qëllime kontrolli. Padi nuk transmetohet si pjesë e segmentit. Gjatë llogaritjes së shumës së kontrollit, vetë fusha e shumës së kontrollit zëvendësohet me zero.

Me fjalë të tjera, pas mbushjes së duhur, të gjitha fjalët 16-bitëshe mblidhen duke përdorur aritmetikën e plotësuesit të njësheve . Shuma më pas plotësohet në mënyrë bitore dhe futet si fusha e kontrollit. Një pseudo-header që imiton header-in e paketës IPv4 të përdorur në llogaritjen e checksum është si më poshtë:

• Cerf, Vint; Dalal, Yogen; Sunshine, Carl (Dhjetor 1974). Specifikimi i Programit të Kontrollit të Transmetimit në Internet, Versioni Dhjetor 1974. RFC 675. doi:10.17487/RFC0675.
• Postel, Jon (Shtator 1981). Protokolli i Internetit (IP). RFC 791. doi:10.17487/RFC0791.
• Postel, Jon (Shtator 1981). Protokolli i Kontrollit të Transmetimit (TCP). RFC 793. doi:10.17487/RFC0793.
• Braden, Robert (Red.) (Tetor 1989). Kërkesat për Hostet e Internetit – Shtresat e Komunikimit. RFC 1122. doi:10.17487/RFC1122.
• Jacobson, Van; Braden, Bob; Borman, Dave (Maj 1992). Zgjerimet TCP për Performancë të Lartë. RFC 1323. doi:10.17487/RFC1323.
• Bellovin, Steven M. (Maj 1996). Mbrojtja Kundër Sulmeve me Numër Sekuencial. RFC 1948. doi:10.17487/RFC1948.
• Mathis, Matt et al. (Tetor 1996). Opsionet për Konfirmim Selektiv të TCP-së (SACK). RFC 2018. doi:10.17487/RFC2018.
• Allman, Mark et al. (Prill 1999). Kontrolli i Mbipopullimit në TCP. RFC 2581. doi:10.17487/RFC2581.
• Floyd, Sally et al. (Korrik 2000). Një Zgjerim i Opsionit të Konfirmimit Selektiv për TCP. RFC 2883. doi:10.17487/RFC2883.
• Ramakrishnan, K. K. et al. (Shtator 2001). Shtesa e Njoftimit të Qartë të Mbipopullimit (ECN) në IP. RFC 3168. doi:10.17487/RFC3168.
• Ludwig, Reiner; Meyer, Michael (Prill 2003). Algoritmi i Zbulimit Eifel për TCP. RFC 3522. doi:10.17487/RFC3522.
• Spring, Neil et al. (Qershor 2003). Sinjalizimi Robust i ECN-së me Nonce. RFC 3540. doi:10.17487/RFC3540.
• Allman, Mark et al. (Shtator 2009). Kontrolli i Mbipopullimit në TCP. RFC 5681. doi:10.17487/RFC5681.
• Simpson, William Allen (Janar 2011). Transaksionet TCP Cookie (TCPCT). RFC 6013. doi:10.17487/RFC6013.
• Ford, Alan et al. (Mars 2011). Udhëzime Arkitekturore për Zhvillimin e Multipath TCP-së. RFC 6182. doi:10.17487/RFC6182.
• Paxson, Vern et al. (Qershor 2011). Llogaritja e Kohës së Riprovimit të TCP-së. RFC 6298. doi:10.17487/RFC6298.
• Ford, Alan et al. (Janar 2013). Zgjerimet TCP për Operacion Multipath me Adresa të Shumta. RFC 6824. doi:10.17487/RFC6824.
• Mathis, Matt et al. (Maj 2013). Reduktimi Proporcional i Shpejtësisë për TCP. RFC 6937. doi:10.17487/RFC6937.
• Borman, David et al. (Shtator 2014). Zgjerimet TCP për Performancë të Lartë. RFC 7323. doi:10.17487/RFC7323.
• Duke, Martin et al. (Shkurt 2015). Udhërrëfyes për Dokumentet e Specifikimit të TCP-së. RFC 7414. doi:10.17487/RFC7414.
• Cheng, Yuchung et al. (Dhjetor 2014). TCP Fast Open. RFC 7413. doi:10.17487/RFC7413.
• Zimmermann, Alexander et al. (Prill 2016). Lëvizja e Zgjerimeve të Vjetra TCP dhe Dokumenteve TCP në Status Historik ose Informativ. RFC 7805. doi:10.17487/RFC7805.
• Fairhurst, Gorry et al., red. (Mars 2017). Shërbimet e Protokolleve të Transportit të IETF dhe Mekanizmat e Kontrollit të Mbipopullimit. RFC 8095. doi:10.17487/RFC8095.
• Cheng, Yuchung et al., red. (Shkurt 2021). Algoritmi RACK-TLP për Zbulimin e Humbjeve në TCP. RFC 8985. doi:10.17487/RFC8985.
• Deering, Stephen E.; Hinden, Robert M. (Korrik 2017). Specifikimi i Protokollit të Internetit, Versioni 6 (IPv6). RFC 8200. doi:10.17487/RFC8200.
• Trammell, Brian; Kuehlewind, Mirja (Prill 2019). Imazhi i Protokollit të Rrjetit në Ujërat e Kabllit (Wire Image). RFC 8546. doi:10.17487/RFC8546.
• Hardie, Ted, red. (Prill 2019). Sinjalet e Shtigjeve të Protokollit të Transportit. RFC 8558. doi:10.17487/RFC8558.
• Iyengar, Jana; Swett, Ian, red. (Maj 2021). Zbulimi i Humbjeve dhe Kontrolli i Mbipopullimit në QUIC. RFC 9002. doi:10.17487/RFC9002.
• Fairhurst, Gorry; Perkins, Colin (Korrik 2021). Mendime mbi Konfidencialitetin e Kokës së Transportit, Operacionet e Rrjetit dhe Evoluimin e Protokolleve të Transportit në Internet. RFC 9065. doi:10.17487/RFC9065.
• Thomson, Martin; Pauly, Tommy (Dhjetor 2021). Qëndrueshmëria Afatgjatë e Mekanizmave të Zgjerimit të Protokolleve. RFC 9170. doi:10.17487/RFC9170.
• Eddy, Wesley M., red. (Gusht 2022). Protokolli i Kontrollit të Transmetimit (TCP). RFC 9293. doi:10.17487/RFC9293.

Shuma e kontrollit llogaritet mbi fushat e mëposhtme:

Source address: 32 bits:The source address in the IPv4 header

Destination address: 32 bits:The destination address in the IPv4 header

Zeroes: 8 bits:All zeroes

Protocol: 8 bits:The protocol value for TCP: 6

TCP length: 16 bits:The length of the TCP header and data (measured in octets). For example, let's say we have IPv4 packet with Total Length of 200 bytes and IHL value of 5, which indicates a length of 5 bits × 32 bits = 160 bits = 20 bytes. We can compute the TCP length as (Total Length) − (IPv4 Header Length) i.e. 200 − 20, which results in 180 bytes.

Shuma e kontrollit TCP për IPv6

Kur TCP funksionon mbi IPv6, metoda e përdorur për të llogaritur shumën e kontrollit ndryshohet:

Çdo protokoll transporti ose protokoll tjetër i shtresës së sipërme që përfshin adresat nga koka IP në llogaritjen e tij të kontrollit duhet të modifikohet për përdorim mbi IPv6, për të përfshirë adresat IPv6 128-bit në vend të adresave IPv4 32-bit.

Një pseudo-header që imiton header-in IPv6 për llogaritjen e checksum-it është treguar më poshtë.Stampa:APHD

Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHDStampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHD Stampa:APHDShuma e kontrollit llogaritet mbi fushat e mëposhtme:

Source address: 128 bits:The address in the IPv6 header.

Destination address: 128 bits:The final destination; if the IPv6 packet doesn't contain a Routing header, TCP uses the destination address in the IPv6 header, otherwise, at the originating node, it uses the address in the last element of the Routing header, and, at the receiving node, it uses the destination address in the IPv6 header.

TCP length: 32 bits:The length of the TCP header and data (measured in octets).

Zeroes: 24 bits; Zeroes == 0:All zeroes.

Next header: 8 bits:The protocol value for TCP: 6.

Shkarkimi i shumës së kontrollit

Shumë implementime të programeve TCP/IP ofrojnë mundësi për të përdorur ndihmën e harduerit për të llogaritur automatikisht shumën e kontrollit në përshtatësin e rrjetit para transmetimit në rrjet ose pas marrjes nga rrjeti për validim. Kjo mund të zvogëlojë ngarkesën e CPU-së që lidhet me llogaritjen e shumës së kontrollit, duke rritur potencialisht performancën e përgjithshme të rrjetit.

Kjo veçori mund të shkaktojë që analizuesit e paketave që nuk janë të vetëdijshëm ose të pasigurt në lidhje me përdorimin e shkarkimit të kontrollit të raportojnë kontrolle të pavlefshme në paketat dalëse që nuk kanë arritur ende në përshtatësin e rrjetit. Kjo do të ndodhë vetëm për paketat që kapen përpara se të transmetohen nga përshtatësi i rrjetit; të gjitha paketat e transmetuara nga përshtatësi i rrjetit në tel do të kenë shuma kontrolli të vlefshme. Ky problem mund të ndodhë edhe kur monitorohen paketat që transmetohen midis makinave virtuale në të njëjtin host, ku një drajver i pajisjes virtuale mund të mos e bëjë llogaritjen e shumës së kontrollit (si një optimizim), duke ditur se shuma e kontrollit do të llogaritet më vonë nga bërthama e hostit VM ose nga hardueri i tij fizik.

Shënime

• Allman, Mark; Paxson, Vern (tetor 1999). "On estimating end-to-end network path properties". ACM SIGCOMM Computer Communication Review. 29 (4): 263–274. doi:10.1145/316194.316230. {{cite journal}}: |hdl-access= ka nevojë për |hdl= (Ndihmë!); Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
• Bhat, Divyashri; Rizk, Amr; Zink, Michael (qershor 2017). "Not so QUIC: A Performance Study of DASH over QUIC". NOSSDAV'17: Proceedings of the 27th Workshop on Network and Operating Systems Support for Digital Audio and Video. fq. 13–18. doi:10.1145/3083165.3083175. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
• Blanton, Ethan; Allman, Mark (janar 2002). "On making TCP more robust to packet reordering" (PDF). ACM SIGCOMM Computer Communication Review. 32: 20–30. doi:10.1145/510726.510728. {{cite journal}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
• Briscoe, Bob; Brunstrom, Anna; Petlund, Andreas; Hayes, David; Ros, David; Tsang, Ing-Jyh; Gjessing, Stein; Fairhurst, Gorry; Griwodz, Carsten; Welzl, Michael (2016). "Reducing Internet Latency: A Survey of Techniques and Their Merits". IEEE Communications Surveys & Tutorials. 18 (3): 2149–2196. doi:10.1109/COMST.2014.2375213. {{cite journal}}: |hdl-access= ka nevojë për |hdl= (Ndihmë!); Mungon ose është bosh parametri |language= (Ndihmë!)
• Bruyeron, Renaud; Hemon, Bruno; Zhang, Lixa (prill 1998). "Experimentations with TCP selective acknowledgment". ACM SIGCOMM Computer Communication Review. 28 (2): 54–77. doi:10.1145/279345.279350. {{cite journal}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
• Chen, Shan; Jero, Samuel; Jagielski, Matthew; Boldyreva, Alexandra; Nita-Rotaru, Cristina (2021). "Secure Communication Channel Establishment: TLS 1.3 (Over TCP Fast Open) versus QUIC". Journal of Cryptology. 34 (3). doi:10.1007/s00145-021-09389-w. {{cite journal}}: Mungon ose është bosh parametri |language= (Ndihmë!)
• Corbet, Jonathan (8 dhjetor 2015). "Checksum offloads and protocol ossification". LWN.net. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
• Corbet, Jonathan (29 janar 2018). "QUIC as a solution to protocol ossification". LWN.net. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
• Ghedini, Alessandro (26 korrik 2018). "The Road to QUIC". The Cloudflare Blog. Cloudflare. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
• IETF HTTP Working Group. "HTTP/2 Frequently Asked Questions". {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)
• Karn, Phil; Partridge, Craig (nëntor 1991). "Improving round-trip time estimates in reliable transport protocols". ACM Transactions on Computer Systems. 9 (4): 364–373. doi:10.1145/118544.118549. {{cite journal}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
• Ludwig, Reiner; Katz, Randy Howard (janar 2000). "The Eifel algorithm: making TCP robust against spurious retransmissions". ACM SIGCOMM Computer Communication Review. doi:10.1145/505688.505692. {{cite journal}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
• Marx, Robin (3 dhjetor 2020). "Head-of-Line Blocking in QUIC and HTTP/3: The Details". {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
• Paasch, Christoph; Bonaventure, Olivier (1 prill 2014). "Multipath TCP". Communications of the ACM. 57 (4): 51–57. doi:10.1145/2578901. {{cite journal}}: |hdl-access= ka nevojë për |hdl= (Ndihmë!); Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
• Papastergiou, Giorgos; Fairhurst, Gorry; Ros, David; Brunstrom, Anna; Grinnemo, Karl-Johan; Hurtig, Per; Khademi, Naeem; Tüxen, Michael; Welzl, Michael; Damjanovic, Dragana; Mangiante, Simone (2017). "De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives". IEEE Communications Surveys & Tutorials. 19: 619–639. doi:10.1109/COMST.2016.2626780. {{cite journal}}: |hdl-access= ka nevojë për |hdl= (Ndihmë!); Mungon ose është bosh parametri |language= (Ndihmë!)
• Rybczyńska, Marta (13 mars 2020). "A QUIC look at HTTP/3". LWN.net. {{cite web}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
• Sy, Erik; Mueller, Tobias; Burkert, Christian; Federrath, Hannes; Fischer, Mathias (2020). "Enhanced Performance and Privacy for TLS over TCP Fast Open". Proceedings on Privacy Enhancing Technologies. 2020 (2): 271–287. arXiv:1905.03518. doi:10.2478/popets-2020-0027. {{cite journal}}: Mungon ose është bosh parametri |language= (Ndihmë!)
• Zhang, Lixia (5 gusht 1986). "Why TCP timers don't work well". ACM SIGCOMM Computer Communication Review. 16 (3): 397–405. doi:10.1145/1013812.18216. {{cite journal}}: Mungon ose është bosh parametri |language= (Ndihmë!)Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)

Lexime të mëtejshme

• Stevens, W. Richard (1994-01-10). TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley Pub. Co. ISBN 978-0-201-63346-7. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)
• Stevens, W. Richard; Wright, Gary R (1994). TCP/IP Illustrated, Volume 2: The Implementation. Addison-Wesley. ISBN 978-0-201-63354-2. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)
• Stevens, W. Richard (1996). TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols. Addison-Wesley. ISBN 978-0-201-63495-2. {{cite book}}: Mungon ose është bosh parametri |language= (Ndihmë!)**

Lidhje të jashtme

• Intervistë për historinë gojore me Robert E. Kahn
• Caktimet e Portit IANA
• Parametrat TCP të IANA-s
• Përmbledhje e TCP nga John Kristoff (Konceptet themelore pas TCP dhe si përdoret për të transportuar të dhëna midis dy pikave fundore)
• Shembull i shumës së kontrollit

Shiko edhe

• Paketa e protokolleve të internetit