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, , 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*.&#x5B; ''* &#x5D;

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 .

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. &#x5B; '''' &#x5D;
## Operacioni i protokollit 
djathtas|parapamje|250x250px| 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: 

### 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**):

# **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.
# **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.
# **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)
djathtas|parapamje|260x260px| Ndërprerja e lidhjes
parapamje| 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  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.   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 &#x2014; përfundimisht &#x2014; 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  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. 

### Vulat kohore TCP 
Vulat kohore të TCP, të përcaktuara në  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&nbsp;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&nbsp;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

 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". 

## 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  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ë  në vitin 1974, dhe specifikimi v4 , i botuar në shtator 1981. , 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ë  . Midis kësaj liste është , 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  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  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 &#x2014; një rast i osifikimit të protokollit &#x2014; 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;  , 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.   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;  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. &#x5B; '''' &#x5D;

## 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.

## Debugimi 
## 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*. . doi:10.17487/RFC0675.
* Postel, Jon (Shtator 1981). *Protokolli i Internetit (IP)*. . doi:10.17487/RFC0791.
* Postel, Jon (Shtator 1981). *Protokolli i Kontrollit të Transmetimit (TCP)*. . doi:10.17487/RFC0793.
* Braden, Robert (Red.) (Tetor 1989). *Kërkesat për Hostet e Internetit – Shtresat e Komunikimit*. . doi:10.17487/RFC1122.
* Jacobson, Van; Braden, Bob; Borman, Dave (Maj 1992). *Zgjerimet TCP për Performancë të Lartë*. . doi:10.17487/RFC1323.
* Bellovin, Steven M. (Maj 1996). *Mbrojtja Kundër Sulmeve me Numër Sekuencial*. . doi:10.17487/RFC1948.
* Mathis, Matt et al. (Tetor 1996). *Opsionet për Konfirmim Selektiv të TCP-së (SACK)*. . doi:10.17487/RFC2018.
* Allman, Mark et al. (Prill 1999). *Kontrolli i Mbipopullimit në TCP*. . doi:10.17487/RFC2581.
* Floyd, Sally et al. (Korrik 2000). *Një Zgjerim i Opsionit të Konfirmimit Selektiv për TCP*. . doi:10.17487/RFC2883.
* Ramakrishnan, K. K. et al. (Shtator 2001). *Shtesa e Njoftimit të Qartë të Mbipopullimit (ECN) në IP*. . doi:10.17487/RFC3168.
* Ludwig, Reiner; Meyer, Michael (Prill 2003). *Algoritmi i Zbulimit Eifel për TCP*. . doi:10.17487/RFC3522.
* Spring, Neil et al. (Qershor 2003). *Sinjalizimi Robust i ECN-së me Nonce*. . doi:10.17487/RFC3540.
* Allman, Mark et al. (Shtator 2009). *Kontrolli i Mbipopullimit në TCP*. . doi:10.17487/RFC5681.
* Simpson, William Allen (Janar 2011). *Transaksionet TCP Cookie (TCPCT)*. . doi:10.17487/RFC6013.
* Ford, Alan et al. (Mars 2011). *Udhëzime Arkitekturore për Zhvillimin e Multipath TCP-së*. . doi:10.17487/RFC6182.
* Paxson, Vern et al. (Qershor 2011). *Llogaritja e Kohës së Riprovimit të TCP-së*. . doi:10.17487/RFC6298.
* Ford, Alan et al. (Janar 2013). *Zgjerimet TCP për Operacion Multipath me Adresa të Shumta*. . doi:10.17487/RFC6824.
* Mathis, Matt et al. (Maj 2013). *Reduktimi Proporcional i Shpejtësisë për TCP*. . doi:10.17487/RFC6937.
* Borman, David et al. (Shtator 2014). *Zgjerimet TCP për Performancë të Lartë*. . doi:10.17487/RFC7323.
* Duke, Martin et al. (Shkurt 2015). *Udhërrëfyes për Dokumentet e Specifikimit të TCP-së*. . doi:10.17487/RFC7414.
* Cheng, Yuchung et al. (Dhjetor 2014). *TCP Fast Open*. . 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*. . 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*. . doi:10.17487/RFC8095.
* Cheng, Yuchung et al., red. (Shkurt 2021). *Algoritmi RACK-TLP për Zbulimin e Humbjeve në TCP*. . doi:10.17487/RFC8985.
* Deering, Stephen E.; Hinden, Robert M. (Korrik 2017). *Specifikimi i Protokollit të Internetit, Versioni 6 (IPv6)*. . doi:10.17487/RFC8200.
* Trammell, Brian; Kuehlewind, Mirja (Prill 2019). *Imazhi i Protokollit të Rrjetit në Ujërat e Kabllit (Wire Image)*. . doi:10.17487/RFC8546.
* Hardie, Ted, red. (Prill 2019). *Sinjalet e Shtigjeve të Protokollit të Transportit*. . doi:10.17487/RFC8558.
* Iyengar, Jana; Swett, Ian, red. (Maj 2021). *Zbulimi i Humbjeve dhe Kontrolli i Mbipopullimit në QUIC*. . 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*. . doi:10.17487/RFC9065.
* Thomson, Martin; Pauly, Tommy (Dhjetor 2021). *Qëndrueshmëria Afatgjatë e Mekanizmave të Zgjerimit të Protokolleve*. . doi:10.17487/RFC9170.
* Eddy, Wesley M., red. (Gusht 2022). *Protokolli i Kontrollit të Transmetimit (TCP)*. . doi:10.17487/RFC9293.
Shuma e kontrollit llogaritet mbi fushat e mëposhtme:

; 
; 
; 
; 
; 

### 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ë.

Shuma e kontrollit llogaritet mbi fushat e mëposhtme:

; 
; 
; 
; 
; 

### 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 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 

## Lexime të mëtejshme 
* 
* 
* **

## 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

## Referime