TCP integrohet natyrshëm në një mjedis klient/server (shih Figurën 10.1). Aplikimi i serverit mete(dëgjoni) kërkesat hyrëse për lidhje. Për shembull, shërbimet WWW, transferimi i skedarëve ose aksesi në terminal dëgjojnë kërkesat që vijnë nga klientët. Komunikimet në TCP inicohen nga rutinat e duhura, të cilat iniciojnë një lidhje me serverin (shih Kapitullin 21 për ndërfaqen e programimit të foleve).

Oriz. 10.1. Klienti thërret serverin.

Në realitet, klienti mund të jetë një server tjetër. Për shembull, serverët e postës mund të lidhen me serverë të tjerë të postës për të dërguar mesazhe email midis kompjuterëve.

10.2 Konceptet TCP

Në çfarë forme duhet të dërgojnë aplikacionet të dhëna në TCP? Në çfarë forme TCP i transmeton të dhënat në IP? Si e identifikojnë protokollet TCP dërguese dhe marrëse lidhjen midis aplikacioneve dhe elementëve të të dhënave të kërkuara për ta zbatuar atë? Të gjitha këto pyetje janë përgjigjur në seksionet e mëposhtme, të cilat përshkruajnë konceptet bazë të TCP.

10.2.1 Rrjedhat e të dhënave hyrëse dhe dalëse

Konceptuale Modeli i lidhjes përfshin një aplikacion që përcjell një rrjedhë të dhënash tek një aplikacion homolog. Në të njëjtën kohë, ai është në gjendje të marrë një rrjedhë të dhënash nga partneri i tij i lidhjes. TCP ofron dupleks i plotë modaliteti i funksionimit (dupleks i plotë) në të cilin servisohet njëkohësisht dy rryma të dhëna (shih Fig. 10.2).

Oriz. 10.2. Aplikacionet shkëmbejnë të dhëna.

10.2.2 Segmentet

TCP mund të konvertojë rrjedhën e të dhënave duke lënë një aplikacion në një formë të përshtatshme për t'u ruajtur në datagrame. Si?

Aplikacioni dërgon të dhëna në TCP dhe ky protokoll i vendos ato buferi i daljes(dërgo tampon). Më pas, TCP shkurton pjesë të të dhënave nga buferi dhe i dërgon ato, duke shtuar një kokë (kjo gjeneron segmente- segment). Në Fig. 10.3 tregon se si të dhënat nga buferi i daljes TCP paketohet në segmente. TCP ia kalon segmentin IP-së për dorëzim si një datagram i veçantë. Paketimi i të dhënave në copa të gjatësisë së saktë siguron përcjellje efikase, kështu që TCP do të presë derisa sasia e duhur e të dhënave të disponohet në buferin e daljes përpara se të krijojë një segment.

Oriz. 10.3 Krijimi i një segmenti TCP

10.2.3 Shtytja

Megjithatë, sasi të mëdha të dhënash shpesh janë të pamundura për t'u aplikuar në aplikacionet e botës reale. Për shembull, kur një program klienti i përdoruesit fundor nis një sesion ndërveprues me një server të largët, përdoruesi më pas fut vetëm komanda (të ndjekura duke shtypur tastin Kthimi).

Programi klient i përdoruesit ka nevojë për TCP që të dijë se të dhënat po dërgohen në hostin në distancë dhe ta kryejë këtë veprim menjëherë. Në këtë rast përdoret duke shtyrë jashtë(shtyj).

Nëse shikoni operacionet në një seancë interaktive, do të gjeni shumë segmente me pak të dhëna, dhe për më tepër, popping mund të gjendet pothuajse në çdo segment të të dhënave. Megjithatë, shtytja nuk duhet të përdoret gjatë transferimit të skedarëve (përveç segmentit të fundit), dhe TCP do të jetë në gjendje t'i paketojë të dhënat në segmente në mënyrë më efikase.

10.2.4 Të dhëna urgjente

Modeli i përcjelljes së të dhënave të aplikacionit përfshin një rrjedhë të porositur bajtësh që udhëtojnë drejt destinacionit. Duke iu referuar përsëri shembullit të sesionit interaktiv, supozoni se përdoruesi ka shtypur një tast vëmendje(vëmendje) ose thyej(ndërpres). Aplikacioni në distancë duhet të jetë në gjendje të kapërcejë bajtët ndërhyrës dhe t'i përgjigjet goditjes së tastit sa më shpejt të jetë e mundur.

Mekanizmi të dhëna urgjente(të dhëna urgjente) shënon informacion të veçantë në një segment si urgjente. Duke bërë këtë, TCP i thotë kolegut të tij se segmenti përmban të dhëna urgjente dhe mund të tregojë se ku ndodhet. Partneri duhet t'ia përcjellë këtë informacion aplikacionit të destinacionit sa më shpejt të jetë e mundur.

10.2.5 Portat e aplikimit

Klienti duhet të identifikojë shërbimin që dëshiron të aksesojë. Kjo bëhet përmes specifikimit të adresës IP të shërbimit pritës dhe numrit të portit të tij TCP. Ashtu si UDP, numrat e portave TCP variojnë nga 0 në 65535. Portat në rangun 0 deri në 1023 quhen të njohura dhe përdoren për të hyrë në shërbimet standarde.

Disa shembuj të porteve të njohura dhe aplikimet e tyre përkatëse janë paraqitur në Tabelën 10.1. Shërbimet Hidhni(porti 9) dhe i ngarkuar(porti 19) janë versione TCP të shërbimeve të njohura tashmë për ne nëpërmjet UDP. Duhet mbajtur mend se trafiku në portin 9 të protokollit TCP është plotësisht i izoluar nga trafiku në portin 9 të protokollit UDP.

Tabela 10.1 Portet e njohura TCP dhe aplikacionet përkatëse të tyre

Port	Aplikacion	Përshkrim
9	Hidhni	Anulo të gjitha të dhënat hyrëse
19	Ngarkues	Gjenerator i karaktereve. Shkëmbimi i rrjedhës së karaktereve
20	Të dhënat FTP	Porta e përcjelljes së të dhënave FTP
21	FTP	Porta për dialog FTP
23	TELNET	Porta për regjistrim në distancë nëpërmjet Telnet
25	SMTP	Porta e protokollit SMTP
110	POP3	Shërbimi i mostrës së postës për kompjuterë personalë
119	NNTP	Qasje në lajmet në internet

Po në lidhje me portet e përdorura nga klientët? Në raste të rralla, klienti nuk punon përmes një porti të njohur. Por në situata të tilla, duke dashur të hapë një lidhje, shpesh i kërkon sistemit operativ t'i caktojë një port të papërdorur dhe të parezervuar. Në fund të lidhjes, klienti duhet ta kthejë këtë port, pas së cilës porti mund të ripërdoret nga një klient tjetër. Meqenëse ka më shumë se 63,000 porte TCP në grupin e numrave të parezervuar, kufizimet e portit të klientit mund të shpërfillen.

10.2.6 Adresat e prizës

Siç e dimë tashmë, quhet kombinimi i adresës IP dhe portit për komunikim priza e adresës. Një lidhje TCP identifikohet plotësisht nga adresa e folesë në çdo skaj të lidhjes. Në Fig. Figura 10.4 tregon lidhjen midis një klienti me adresë socket (128.36.1.24, port = 3358) dhe një server me adresë socket (130.42.88.22, port = 21).

Oriz. 10.4. Adresat e foleve

Kreu i çdo datagrami përmban adresat IP të burimit dhe të destinacionit. Më vonë do të shihni që numrat e portit të burimit dhe të destinacionit janë specifikuar në titullin e segmentit TCP.

Në mënyrë tipike, një server është i aftë të menaxhojë klientë të shumtë në të njëjtën kohë. Adresat unike të prizës së serverit u caktohen njëkohësisht të gjithë klientëve të tij (shih Fig. 10.5).

Oriz. 10.5. Klientë të shumtë të lidhur me adresat e prizës së serverit

Për shkak se një datagram përmban një segment lidhjeje TCP të identifikuar nga adresat IP dhe portat, është shumë e lehtë për një server të mbajë gjurmët e lidhjeve të shumta me klientët.

10.3 Mekanizmi i besueshmërisë së TCP

Në këtë seksion, ne do të shikojmë mekanizmin TCP të përdorur për të dhënë në mënyrë të besueshme të dhëna duke ruajtur rendin e transmetimit dhe duke shmangur humbjen ose dyfishimin.

10.3.1 Numërimi dhe konfirmimi

TCP përdor numërimin dhe njohjen (ACK) për të siguruar transferim të besueshëm të të dhënave. Skema e numërimit TCP është disi e pazakontë: çdo përcillet mbi lidhjen oktet konsiderohet se ka numër serial. Kreu i segmentit TCP përmban një numër sekuence okteti i parë i të dhënave në këtë segment.

Marrësit i kërkohet të konfirmojë që të dhënat janë marrë. Nëse ACK nuk arrin brenda intervalit të skadimit, të dhënat ritransmetohen. Kjo metodë quhet konfirmim pozitiv me stafetë(mirënjohje pozitive me ritransmetim).

Marrësi i të dhënave TCP kontrollon rreptësisht numrat e sekuencës hyrëse për të verifikuar që të dhënat janë marrë në sekuencë dhe se nuk ka pjesë që mungojnë. Meqenëse ACK mund të humbasë ose vonohet rastësisht, segmentet e kopjuara mund të arrijnë te marrësi. Numrat e sekuencës ju lejojnë të identifikoni të dhëna të dyfishta, të cilat më pas hidhen.

Në Fig. Figura 10.6 tregon një pamje të thjeshtuar të skadimit dhe ritransmetimit në TCP.

Oriz. 10.6. Kohëzgjatja dhe ritransmetimi në TCP

10.3.2 Fushat porta, sekuenca dhe ACK në kokën TCP

Siç tregohet në Fig. 10.7, disa fusha të para të kokës TCP ofrojnë hapësirë ​​për vlerat e portit të burimit dhe destinacionit, numrin e sekuencës së bajtit të parë të të dhënave të mbyllura dhe një ACK të barabartë me numrin e sekuencës tjetër bajt i pritur në skajin tjetër. Me fjalë të tjera, nëse TCP merr të gjitha bajtet deri në 30 nga homologu i tij, kjo fushë do të ketë vlerën 31, duke treguar segmentin që do të përcillet më pas.

Oriz. 10.7. Vlerat fillestare në fushat e titullit TCP

Një detaj i vogël nuk mund të anashkalohet. Le të supozojmë se TCP ka dërguar bajt 1 deri në 50 dhe nuk ka më të dhëna për të dërguar. Nëse të dhënat merren nga një koleg, TCP duhet të konfirmojë marrjen e tyre duke dërguar një titull pa të dhënat e bashkangjitura. Natyrisht, ky titull përmban vlerën ACK. Në fushën e sekuencës - vlera është 51, d.m.th. numri i bajtit të ardhshëm, i cili synon dërgoni TCP. Kur TCP dërgon të dhënat e radhës, titulli i ri TCP do të ketë gjithashtu një fushë sekuence prej 51.

10.4 Krijimi i një lidhjeje

Si lidhen dy aplikacione me njëri-tjetrin? Përpara komunikimit, secila prej tyre thërret një nënprogram për të formuar një bllok memorie që do të përdoret për të ruajtur parametrat TCP dhe IP të një lidhjeje të caktuar, për shembull, adresat e foleve, numrin e sekuencës aktuale, vlerën fillestare të jetëgjatësisë, etj.

Aplikacioni i serverit pret që të shfaqet një klient, i cili, duke dashur të ketë akses në server, lëshon një kërkesë për të kompleks(lidheni), duke identifikuar adresën IP dhe portin e serverit.

Ekziston një veçori teknike. Secila anë fillon të numërojë çdo bajt jo me një, por me numër serial i rastësishëm(do të zbulojmë më vonë pse është bërë kjo). Specifikimi origjinal këshillon që numri i sekuencës fillestare të gjenerohet bazuar në një kohëmatës të jashtëm 32-bit që rritet afërsisht çdo 4 µs.

10.4.1 Skenari i lidhjes

Procedura e lidhjes shpesh quhet shtrëngim duarsh me tre drejtime sepse shkëmbehen tre mesazhe për të krijuar një lidhje - SYN, SYN dhe ACK.

Gjatë vendosjes së lidhjes, partnerët shkëmbejnë tre informacione të rëndësishme:

1. Hapësirë ​​buferi për marrjen e të dhënave

2. Sasia maksimale e të dhënave të bartura në një segment hyrës

3. Numri i sekuencës fillestare i përdorur për të dhënat dalëse

Vini re se secila palë përdor operacionet 1 dhe 2 për të treguar kufijtë brenda të cilëve do të veprojë pala tjetër. Një kompjuter personal mund të ketë një buffer të vogël pranimi, por një superkompjuter mund të ketë një buffer të madh. Struktura e memories së një kompjuteri personal mund të kufizojë pjesët e të dhënave hyrëse në 1 KB, por një superkompjuter menaxhon segmente më të mëdha.

Aftësia për të kontrolluar se si pala tjetër dërgon të dhëna është një veçori e rëndësishme që e bën TCP/IP të shkallëzueshme.

Në Fig. Figura 10.8 tregon një shembull skripti lidhjeje. Numrat shumë të thjeshtë të sekuencës fillestare janë paraqitur në mënyrë që të mos mbingarkohet vizatimi. Vini re se në këtë figurë, klienti është në gjendje të marrë segmente më të mëdha se serveri.

Oriz. 10.8. Krijimi i një lidhjeje

Operacionet e mëposhtme kryhen:

1. Serveri inicializohet dhe bëhet gati për t'u lidhur me klientët (kjo gjendje quhet pasive e hapur).

2. Klienti kërkon TCP të hapë një lidhje me serverin në adresën IP dhe portin e specifikuar (kjo gjendje quhet aktive e hapur).

3. Klienti TCP merr numrin e sekuencës fillestare (1000 në këtë shembull) dhe dërgon sinkronizimi i segmentit(Sinkronizimi i segmentit - SYN). Ky segment mbart numrin e sekuencës, madhësinë e dritares së marrjes (4K) dhe madhësinë e segmentit më të madh që klienti mund të marrë (1460 byte).

4. Kur vjen një SYN, serveri TCP merr e imja numri i sekuencës fillestare (3000). Ai dërgon një segment SYN që përmban numrin e sekuencës fillestare (3000), ACK 1001 (që do të thotë se bajt-i i parë i dërguar nga klienti numërohet si 1001), madhësinë e dritares së marrjes (4K) dhe madhësinë e segmentit më të madh që serveri mund të marrë (1024 bytes).

5. Klienti TCP, pasi ka marrë një mesazh SYN/ACK nga serveri, dërgon mbrapsht ACK 3001 (bajt i parë i të dhënave të dërguara nga serveri duhet të numërohet 3001).

6. Klienti TCP udhëzon aplikacionin e tij për të hapur lidhjen.

7. Serveri TCP, pasi ka marrë një mesazh ACK nga klienti TCP, informon aplikacionin e tij për hapjen e lidhjes.

Klienti dhe serveri shpallin rregullat e tyre për të dhënat e marra, sinkronizojnë numrat e tyre të sekuencës dhe bëhen gati për të shkëmbyer të dhëna. Specifikimi TCP lejon gjithashtu një skenar tjetër (jo shumë të suksesshëm), kur aplikacionet homologe hapin në mënyrë aktive njëra-tjetrën njëkohësisht.

10.4.2 Vendosja e vlerave të parametrave IP

Një kërkesë aplikacioni për të krijuar një lidhje mund të specifikojë gjithashtu parametra për datagramet IP që do të mbajnë të dhënat e lidhjes. Nëse nuk specifikohet një vlerë specifike e parametrit, përdoret vlera e paracaktuar.

Për shembull, një aplikacion mund të zgjedhë një vlerë të dëshiruar për prioritetin IP ose llojin e shërbimit. Meqenëse secila nga palët e lidhura vendos në mënyrë të pavarur përparësinë dhe llojin e saj të shërbimit, teorikisht këto vlera mund të ndryshojnë për drejtime të ndryshme të rrjedhave të të dhënave. Si rregull, në praktikë përdoren të njëjtat vlera për çdo drejtim shkëmbimi.

Kur një aplikacion përfshin opsione sigurie qeveritare ose ushtarake, çdo pikë fundore e lidhjes duhet të përdorë të njëjtat nivele sigurie ose lidhja nuk do të vendoset.

10.5 Transferimi i të dhënave

Transferimi i të dhënave fillon pas përfundimit të konfirmimit me tre hapa të krijimit të lidhjes (shih Figurën 10.9). Standardi TCP lejon që të dhënat normale të përfshihen në segmentet e njohjes, por ato nuk do të dorëzohen në aplikacion derisa të përfundojë lidhja. Për të thjeshtuar numërimin, përdoren mesazhe 1000 byte. Çdo segment i titullit TCP ka një fushë ACK që identifikon numrin e sekuencës së bajtit që pritet të merret nga partneri i lidhjes.

Oriz. 10.9. Shkëmbim i thjeshtë i të dhënave dhe rrjedhë ACK

Segmenti i parë i dërguar nga klienti përmban bajt 1001 deri në 2000. Fusha e tij ACK duhet të përmbajë vlerën 3001, e cila tregon numrin e sekuencës së bajtit që pritet të merret nga serveri.

Serveri i përgjigjet klientit me një segment që përmban 1000 bajt të dhëna (duke filluar me numrin 3001). Fusha ACK e titullit TCP të saj do të tregojë se bajtet 1001 deri në 2000 janë marrë tashmë me sukses, kështu që numri i sekuencës së segmentit tjetër që pritet nga klienti duhet të jetë 2001.

Më pas klienti dërgon segmente duke filluar me bajt 2001, 3001 dhe 4001 në sekuencën e specifikuar. Vini re se klienti nuk pret për një ACK pas secilit prej segmenteve të dërguar. Të dhënat i dërgohen kolegut derisa hapësira e tij e buferit të mbushet (do të shohim më poshtë se marrësi mund të specifikojë shumë saktë sasinë e të dhënave që i dërgohen).

Serveri kursen gjerësinë e brezit të lidhjes duke përdorur një ACK të vetme për të treguar suksesin në përcjelljen e të gjithë segmenteve.

Në Fig. Figura 10.10 tregon transferimin e të dhënave kur segmenti i parë humbet. Kur skadon afati, segmenti ritransmetohet. Vini re se me marrjen e një segmenti të humbur, marrësi dërgon një ACK të vetme që konfirmon përcjelljen e të dy segmenteve.

Oriz. 10.10. Humbja dhe ritransmetimi i të dhënave

10.6 Mbyllja e një lidhjeje

Ndërprerja normale e një lidhjeje kryhet duke përdorur të njëjtën procedurë të shtrëngimit të trefishtë të duarve si kur hapni një lidhje. Secila palë mund të fillojë të mbyllë lidhjen duke përdorur skenarin e mëposhtëm:

A:

B:"Mirë".

NË:"Edhe unë e mbarova punën."

A:"Mirë".

Le të supozojmë skenarin e mëposhtëm (megjithëse përdoret jashtëzakonisht rrallë):

A:"Mbarova. Nuk ka më të dhëna për të dërguar."

NË:"Mirë. Megjithatë, ka disa të dhëna..."

NË:"Edhe unë e mbarova punën."

A:"Mirë".

Në shembullin e mëposhtëm, lidhja mbyllet nga serveri, siç ndodh shpesh për lidhjet klient/server. Në këtë rast, pasi përdoruesi të hyjë në seancë telnet Komanda e daljes bën që serveri të fillojë një kërkesë për të mbyllur lidhjen. Në situatën e treguar në Fig. 10.11, kryhen veprimet e mëposhtme:

1. Aplikacioni në server i thotë TCP të mbyllë lidhjen.

2. Serveri TCP dërgon një segment përfundimtar (Segmenti përfundimtar - FIN), duke informuar kolegun e tij se nuk ka më të dhëna për të dërguar.

3. TCP-ja e klientit dërgon një ACK në segmentin FIN.

4. TCP e klientit i tregon aplikacionit të tij që serveri dëshiron të mbyllë lidhjen.

5. Aplikacioni klient i thotë TCP-së së tij të mbyllë lidhjen.

6. Klienti TCP dërgon një mesazh FIN.

7. Serveri TCP merr FIN nga klienti dhe përgjigjet me një mesazh ACK.

8. TCP e serverit i thotë aplikacionit të tij që të mbyllë lidhjen.

Oriz. 10.11. Mbyllja e një lidhjeje

Të dyja palët mund të fillojnë të mbyllen në të njëjtën kohë. Në këtë rast, mbyllja normale e lidhjes përfundon pasi secili peer dërgon një mesazh ACK.

10.6.1 Ndërprerja e papritur

Secila palë mund të kërkojë një ndërprerje të papritur (mbyllje të papritur) të lidhjes. Kjo është e pranueshme kur një aplikacion dëshiron të ndërpresë një lidhje ose kur TCP zbulon një problem serioz komunikimi që nuk mund ta zgjidhë me mjetet e veta. Ndërprerja e menjëhershme kërkohet duke dërguar një ose më shumë mesazhe të rivendosur te peer, të treguar nga një flamur specifik në kokën TCP.

10.7 Kontrolli i rrjedhës

Marrësi TCP ngarkohet me rrjedhën e të dhënave hyrëse dhe përcakton se sa informacion mund të pranojë. Ky kufizim prek dërguesin TCP. Shpjegimi i mëposhtëm i këtij mekanizmi është konceptual dhe zhvilluesit mund ta zbatojnë atë në mënyra të ndryshme në produktet e tyre.

Gjatë konfigurimit të lidhjes, çdo koleg cakton hapësirë ​​për buferin e hyrjes së lidhjes dhe njofton palën tjetër për këtë. Në mënyrë tipike, madhësia e tamponit shprehet si një numër i plotë i madhësive maksimale të segmentit.

Rrjedha e të dhënave hyn në buferin e hyrjes dhe ruhet atje përpara se të përcillet në aplikacion (përcaktuar nga porta TCP). Në Fig. Figura 10.12 tregon një bufer hyrës që mund të pranojë 4 KB.

Oriz. 10.12. Dritarja e marrjes së tamponit të hyrjes

Hapësira e tamponit mbushet kur të dhënat vijnë. Kur aplikacioni marrës merr të dhëna nga buferi, hapësira e liruar bëhet e disponueshme për të dhëna të reja hyrëse.

10.7.1 Dritarja e marrjes

Dritarja e marrjes(dritarja e marrjes) - çdo hapësirë ​​në buferin e hyrjes që nuk është zënë tashmë nga të dhënat. Të dhënat mbeten në buferin e hyrjes derisa të përdoren nga aplikacioni i synuar. Pse aplikacioni nuk mbledh të dhëna menjëherë?

Një skenar i thjeshtë do t'ju ndihmojë t'i përgjigjeni kësaj pyetjeje. Le të supozojmë se një klient ka dërguar një skedar në një server FTP që funksionon në një kompjuter shumë të ngarkuar me shumë përdorues. Më pas programi FTP duhet të lexojë të dhënat nga buferi dhe t'i shkruajë ato në disk. Kur serveri kryen operacionet e hyrjes/daljes së diskut, programi pret që këto operacione të përfundojnë. Në këtë kohë, një program tjetër mund të fillojë (për shembull, sipas një plani) dhe, ndërsa programi FTP fillon përsëri, të dhënat e ardhshme do të mbërrijnë tashmë në tampon.

Dritarja e marrjes shtrihet nga bajti i fundit i pranuar deri në fund të buferit. Në Fig. 10.12, fillimisht i gjithë buferi është i disponueshëm dhe, për rrjedhojë, disponohet një dritare marrëse 4 KB. Kur të mbërrijë KB-ja e parë, dritarja e marrjes do të reduktohet në 3 KB (për thjeshtësi, do të supozojmë se çdo segment është me madhësi 1 KB, megjithëse në praktikë kjo vlerë ndryshon në varësi të nevojave të aplikacionit). Ardhja e dy segmenteve të ardhshme 1 KB do të reduktojë dritaren e pranimit në 1 KB.

Çdo ACK i dërguar nga marrësi përmban informacion për gjendjen aktuale të dritares marrëse, në varësi të së cilës rregullohet rrjedha e të dhënave nga burimi.

Në pjesën më të madhe, madhësia e buferit të hyrjes vendoset kur lidhja fillon, megjithëse standardi TCP nuk specifikon se si të menaxhohet ky bufer. Buferi i hyrjes mund të rritet ose zvogëlohet duke i dhënë reagime dërguesit.

Çfarë ndodh nëse segmenti i mbërritur mund të vendoset në dritaren marrëse, por ai arrin jashtë funksionit? Në përgjithësi supozohet se të gjitha implementimet ruajnë të dhënat hyrëse në një dritare marrëse dhe dërgojnë një konfirmim (ACK) vetëm për të gjithë bllokun e afërt të segmenteve të shumëfishta. Kjo është mënyra e duhur, sepse në të kundërt, hedhja e të dhënave që vijnë jashtë funksionit do të ulë ndjeshëm performancën.

10.7.2 Dritarja e paraqitjes

Sistemi që transmeton të dhënat duhet të mbajë gjurmët e dy karakteristikave: sa të dhëna janë dërguar dhe pranuar tashmë, dhe madhësia aktuale e dritares së pranimit të marrësit. Aktiv duke dërguar hapësirë(hapësira e dërgimit) shtrihet nga okteti i parë i papranuar në skajin e majtë të dritares aktuale të marrjes. Pjesë dritare, te perdorura për të dërguar, tregon se sa të dhëna shtesë mund t'i dërgohen partnerit.

Numri fillestar i sekuencës dhe madhësia fillestare e dritares së marrjes specifikohen gjatë konfigurimit të lidhjes. Oriz. Figura 10.13 ilustron disa nga veçoritë e mekanizmit të transferimit të të dhënave.

1. Dërguesi fillon me një dritare dërgimi 4 KB.

2. Dërguesi dërgon 1 KB. Një kopje e këtyre të dhënave ruhet derisa të merret një konfirmim (ACK), pasi mund të ketë nevojë të ritransmetohet.

3. Mbërrin mesazhi ACK për KB-në e parë dhe dërgohen të dhënat e ardhshme 2 KB. Rezultati është paraqitur në pjesën e tretë nga maja e Fig. 10.13. Hapësira ruajtëse 2 KB vazhdon.

4. Së fundi, një ACK arrin për të gjitha të dhënat e transmetuara (d.m.th., të gjitha ato merren nga marrësi). ACK rikthen madhësinë e dritares së dërgimit në 4 KB.

Oriz. 10.13. Dërgo dritaren

Ka disa veçori interesante që ia vlen të përmenden:

■ Dërguesi nuk pret një ACK për çdo segment të të dhënave që dërgon. I vetmi kufizim në përcjelljen është madhësia e dritares së marrjes (për shembull, dërguesi duhet të përcjellë vetëm segmente 4K me një bajt).

■ Supozoni se dërguesi dërgon të dhëna në disa segmente shumë të shkurtra (për shembull, 80 byte). Në këtë rast, të dhënat mund të riformatohen për transmetim më efikas (për shembull, në një segment të vetëm).

10.8 TCP header

Në Fig. Figura 10.14 tregon formatin e segmentit (titulli TCP dhe të dhënat). Kreu fillon me ID-të e portit të burimit dhe të destinacionit. Fusha tjetër tjetër numër serik(numri i sekuencës) tregon pozicionin në rrjedhën e të dhënave dalëse që zë ky segment. Fusha ACK(konfirmimi) përmban informacion në lidhje me segmentin e ardhshëm të pritshëm që duhet të shfaqet në rrjedhën e të dhënave hyrëse.

Oriz. 10.14. Segmenti TCP

Ka gjashtë flamuj:

Fusha kompensimet e të dhënave(Data Offset) përmban madhësinë e titullit TCP në fjalë 32-bit. Kreu TCP duhet të përfundojë në një kufi 32-bit.

10.8.1 Opsioni i madhësisë maksimale të segmentit

Parametri "madhësia maksimale e segmentit"(madhësia maksimale e segmentit - MSS) përdoret për të deklaruar pjesën më të madhe të të dhënave që mund të pranohet dhe përpunohet nga sistemi. Sidoqoftë, emri është disi i pasaktë. Zakonisht në TCP segment trajtohen si të dhëna kokë plus. Megjithatë madhësia maksimale e segmentit përcaktuar si:

Madhësia e datagramit më të madh që mund të merret është 40

Me fjalë të tjera, MSS pasqyron më të madhin ngarkesë në marrës kur titujt TCP dhe IP janë 20 bajt të gjatë. Nëse ka parametra shtesë, gjatësia e tyre duhet të zbritet nga madhësia totale. Prandaj, sasia e të dhënave që mund të dërgohen në një segment përcaktohet si:

Vlera e deklaruar MSS + 40 – (shuma e gjatësive të kokës TCP dhe IP)

Kolegët zakonisht shkëmbejnë vlerat MSS në mesazhet fillestare SYN kur hapni një lidhje. Nëse sistemi nuk reklamon një vlerë maksimale të madhësisë së segmentit, përdoret vlera e paracaktuar prej 536 bajt.

Madhësia maksimale e segmentit është e koduar si një hyrje prej 2 bajtësh e ndjekur nga një vlerë prej 2 bajtësh, d.m.th. vlera më e madhe do të jetë 2 16 -1 (65,535 bytes).

MSS vendos një kufizim të rëndë në të dhënat e dërguara në TCP: marrësi nuk do të jetë në gjendje të përpunojë vlera të mëdha. Megjithatë, dërguesi përdor segmente madhësi më të vogël, meqënëse për lidhjen përcaktohet edhe madhësia e MTU përgjatë trasesë.

10.8.2 Përdorimi i fushave të kokës në një kërkesë për lidhje

Segmenti i parë i dërguar për të hapur një lidhje ka një flamur SYN prej 1 dhe një flamur ACK prej 0. SYN fillestar është i vetmi një segment që ka një fushë ACK me vlerë 0. Vini re se veglat e sigurisë përdorin këtë veçori për të identifikuar kërkesat hyrëse për një sesion TCP.

Fusha numër serik përmban numri i sekuencës fillestare(numri i sekuencës fillestare), fushë dritare - madhësia fillestare dritarja e pranimit. I vetmi parametër TCP i përcaktuar aktualisht është madhësia maksimale e segmentit (kur nuk specifikohet, përdoret vlera e paracaktuar prej 536 bajt) që TCP pret të marrë. Kjo vlerë zë 32 bit dhe zakonisht është e pranishme në kërkesën për lidhje në fushë opsione(Opsion). Kreu TCP që përmban vlerën MSS është 24 bajt i gjatë.

10.8.3 Përdorimi i fushave të kokës në një përgjigje të kërkesës për lidhje

Në një përgjigje granti ndaj një kërkese lidhjeje, të dy flamujt (SYN dhe ACK) janë të barabartë me 1. Sistemi që përgjigjet tregon numrin e sekuencës fillestare në fushën përkatëse dhe madhësinë e dritares së marrjes në fushë Dritare. Madhësia maksimale e segmentit që marrësi dëshiron të përdorë zakonisht gjendet në përgjigjen ndaj kërkesës për lidhje (në opsione). Kjo vlerë mund të ndryshojë nga vlera e palës që kërkon lidhjen, d.m.th. mund të përdoren dy vlera të ndryshme.

Një kërkesë për lidhje mund të refuzohet duke specifikuar një flamur rivendosjeje (RST) me një vlerë prej 1 në përgjigje.

10.8.4 Zgjedhja e numrit të sekuencës fillestare

Specifikimi TCP supozon se gjatë konfigurimit të lidhjes secila palë zgjedh numri i sekuencës fillestare(bazuar në vlerën aktuale të kohëmatësit të brendshëm 32-bit). Si bëhet kjo?

Le të imagjinojmë se çfarë do të ndodhë nëse sistemi shembet. Le të supozojmë se përdoruesi hapi një lidhje pak para përplasjes dhe dërgoi një sasi të vogël të dhënash. Pas rikuperimit, sistemi nuk kujton më asgjë që është bërë përpara përplasjes, duke përfshirë lidhjet e nisura tashmë dhe numrat e porteve të caktuara. Përdoruesi rivendos lidhjen. Numrat e portit nuk përputhen me caktimet origjinale dhe disa prej tyre mund të jenë tashmë në përdorim nga lidhje të tjera të krijuara disa sekonda përpara përplasjes.

Prandaj, pala tjetër në fund të lidhjes mund të mos e dijë se partneri i saj u rrëzua dhe më pas u rikthye. E gjithë kjo do të çojë në ndërprerje serioze, veçanërisht kur duhet një kohë e gjatë që të dhënat e vjetra të kalojnë nëpër rrjet dhe të përzihen me të dhënat nga lidhja e krijuar rishtazi. Zgjedhja e një kohëmatësi të fillimit me një përditësim (fillimi i ri) eliminon probleme të tilla. Të dhënat e vjetra do të kenë një numërim të ndryshëm nga diapazoni i numrave të sekuencës së lidhjes së re. Hakerët, kur mashtrojnë adresën IP të burimit për një host të besuar, përpiqen të fitojnë akses në kompjuterë duke specifikuar një numër të sekuencës fillestare të parashikueshme në mesazh. Një funksion hash kriptografik i bazuar në çelësat e brendshëm ofron metodën më të mirë për zgjedhjen e farave të sigurta.

10.8.5 Përdorimet e zakonshme të fushave

Kur përgatitni titullin TCP për transmetim, numri i sekuencës së oktetit të parë të të dhënave të transmetuara tregohet në fushë numër serik(Numri i sekuencës).

Numri i oktetit të ardhshëm që pritet nga partneri i lidhjes futet në fushë konfirmim(Numri i konfirmimit) kur biti ACK vendoset në 1. Fusha dritare(Dritarja) është menduar për madhësinë aktuale të dritares marrëse. Kjo fushë përmban numri i bajteve nga numri i konfirmimit që mund të merret. Vini re se kjo vlerë lejon kontrollin e saktë të rrjedhës së të dhënave. Duke përdorur këtë vlerë, peer tregon gjendjen aktuale të dritares së marrjes gjatë seancës së shkëmbimit.

Nëse një aplikacion specifikon një operacion shtytjeje në TCP, atëherë flamuri PUSH vendoset në 1. TCP marrës DUHET t'i përgjigjet këtij flamuri duke i dorëzuar shpejt të dhënat në aplikacion sapo dërguesi dëshiron t'i përcjellë ato.

Flamuri URGENT, kur vendoset në 1, nënkupton transferimin urgjent të të dhënave dhe treguesi përkatës duhet t'i referohet oktetit të fundit të të dhënave urgjente. Një përdorim tipik i të dhënave urgjente është dërgimi i sinjaleve të ndërprerjes ose ndërprerjes nga terminali.

Shpesh thirren të dhënat urgjente informacione jashtë brezit(jashtë brezit). Megjithatë, ky term është i pasaktë. Të dhënat urgjente dërgohen në një rrjedhë normale TCP, megjithëse zbatimet individuale mund të kenë mekanizma të veçantë për t'i treguar aplikacionit që të dhënat urgjente kanë mbërritur dhe aplikacioni duhet të kontrollojë përmbajtjen e të dhënave urgjente përpara se të mbërrijnë të gjitha bajtet e mesazhit.

Flamuri RESET vendoset në 1 kur lidhja duhet të ndërpritet në mënyrë jonormale. I njëjti flamur vendoset në përgjigje kur arrin një segment që nuk është i lidhur me asnjë nga lidhjet aktuale TCP.

Flamuri FIN është vendosur në 1 për mesazhet e mbylljes së lidhjes.

10.8.6 Shuma e kontrollit

Shuma e kontrollit IP është vetëm për kokën e IP-së, ndërsa shuma e kontrollit TCP llogaritet për të gjithë segmentin si dhe pseudo-header-in e krijuar nga kreu i IP-së. Gjatë llogaritjes së TCP checksum, fusha përkatëse ka vlerën 0. Në Fig. Figura 10.15 tregon një pseudo-header që ngjan shumë me atë të përdorur në një shumë kontrolli UDP.

Oriz. 10.15. Fusha pseudo-header përfshihet në kontrollin TCP

Gjatësia TCP llogaritet duke shtuar gjatësinë e kokës TCP në gjatësinë e të dhënave. Shuma e kontrollit TCP është të detyrueshme, jo si UDP. Shuma e kontrollit të një segmenti të mbërritur fillimisht llogaritet nga marrësi dhe më pas krahasohet me përmbajtjen e fushës së kontrollit të titullit TCP. Nëse vlerat nuk përputhen, segmenti hidhet poshtë.

10.9 Shembull i segmentit TCP

Oriz. 10.16, protokolli i funksionimit të analizatorit Njehësues nga Network General, është një sekuencë e segmenteve TCP. Tre segmentet e para vendosin lidhjen midis klientit dhe serverit Telnet. Segmenti i fundit mbart 12 bajt të dhëna.

Oriz. 10.16. Shfaqja e kokës TCP nga analizuesi Sniffer

Analizator Njehësues konverton shumicën e vlerave në formë dhjetore. Sidoqoftë, vlerat e flamurit dalin si heksadecimal. Një flamur me një vlerë prej 12 përfaqëson 010010. Shuma e kontrollit del gjithashtu në heksadecimal.

10.10 Mbështetja e sesionit

10.10.1 Sondimi i dritares

Një dërgues i shpejtë dhe një marrës i ngadalshëm mund të formojnë një dritare marrëse me madhësi 0 bajt. Ky rezultat quhet duke mbyllur dritaren(mbyll dritaren). Kur hapësira e lirë bëhet e disponueshme për të përditësuar madhësinë e dritares së marrjes, përdoret ACK. Megjithatë, nëse një mesazh i tillë humbet, të dyja palët do të duhet të presin pafundësisht.

Për të shmangur këtë situatë, dërguesi vendos kohëmatës i kursyer(kohëmatësi i vazhdueshëm) kur mbyllet dritarja e përkohshme. Vlera e kohëmatësit është koha e ritransmetimit. Pas përfundimit të kohëmatësit, një segment i dërgohet partnerit sensori i dritares(sondimi i dritares; disa implementime përfshijnë gjithashtu të dhëna). Hetimi bën që kolegu të dërgojë një ACK që raporton statusin aktual të dritares.

Nëse dritarja mbetet ende në madhësi zero, vlera e kohëmatësit që ruhet dyfishohet. Ky proces përsëritet derisa kohëmatësi të arrijë një maksimum prej 60 sekondash. TCP do të vazhdojë të dërgojë mesazhe hetimi çdo 60 sekonda derisa të hapet dritarja, përdoruesi të përfundojë procesin ose të përfundojë koha e aplikimit.

10.11 Përfundimi i një seance

10.11.1 Time-out

Partneri i lidhjes mund të prishet ose të ndërpritet plotësisht për shkak të një porte ose lidhjeje të gabuar. Për të parandaluar ritransmetimin e të dhënave në TCP, ekzistojnë disa mekanizma.

Kur TCP arrin pragun e parë të ritransmetimit, i thotë IP-së të kontrollojë ruterin e dështuar dhe njëkohësisht informon aplikacionin se ka një problem. TCP vazhdon të përcjellë të dhënat derisa të arrihet pragu i dytë përpara se të lëshojë lidhjen.

Sigurisht, përpara se të ndodhë kjo, një mesazh ICMP mund të arrijë që tregon se destinacioni është i paarritshëm për ndonjë arsye. Në disa implementime, edhe pas kësaj, TCP do të vazhdojë të përpiqet të aksesojë destinacionin derisa të skadojë intervali i skadimit (në të cilën pikë problemi mund të zgjidhet). Më pas, aplikacioni informohet se pika e destinacionit është e paarritshme.

Një aplikacion mund të caktojë kohëzgjatjen e vet për dërgimin e të dhënave dhe të kryejë veprimet e veta kur ky interval përfundon. Zakonisht lidhja ndërpritet.

10.11.2 Ruajtja e një lidhjeje

Kur një lidhje jo e plotë ka të dhëna për t'u përcjellë për një kohë të gjatë, ajo bëhet joaktive. Gjatë një periudhe pasiviteti, rrjeti mund të prishet ose linjat e komunikimit fizik mund të ndërpriten. Sapo rrjeti të bëhet sërish funksional, partnerët do të vazhdojnë të shkëmbejnë të dhëna pa ndërprerë seancën e komunikimit. Kjo strategji përputhej me kërkesat e Ministrisë së Mbrojtjes.

Megjithatë, çdo lidhje - aktive ose joaktive - merr shumë memorie kompjuteri. Disa administratorë duhet të kthejnë burimet e papërdorura në sisteme. Prandaj, shumë implementime TCP janë të afta të dërgojnë një mesazh rreth ruajtjen e lidhjes(keep-live), i cili teston lidhjet joaktive. Mesazhe të tilla i dërgohen periodikisht partnerit për të kontrolluar ekzistencën e tij në rrjet. Përgjigja duhet të jetë mesazhe ACK. Përdorimi i mesazheve të mbajë gjallë është opsional. Nëse sistemi e ka këtë aftësi, aplikacioni mund ta anashkalojë atë duke përdorur mjetet e veta. Periudha e parashikuar default Koha e mirëmbajtjes së lidhjes është plot dy orë!

Kujtojmë se një aplikacion mund të vendosë kohëmatësin e vet, sipas të cilit do të vendosë në nivelin e tij nëse do të ndërpresë lidhjen.

10.12 Performanca

Sa efikas është TCP? Performanca e burimit ndikohet nga shumë faktorë, më kryesorët janë memoria dhe gjerësia e brezit (shih Figurën 10.17).

Oriz. 10.17. Faktorët e Performancës TCP

Gjerësia e brezit dhe vonesa e rrjetit fizik të përdorur kufizon ndjeshëm xhiron. Cilësia e dobët e përcjelljes së të dhënave rezulton në një vëllim të madh të datagrameve të hedhura, gjë që shkakton ritransmetime dhe për pasojë zvogëlon efikasitetin e gjerësisë së brezit.

Fundi marrës duhet të sigurojë hapësirë ​​të mjaftueshme buferi për të lejuar dërguesin të dërgojë të dhëna pa ndërprerje. Kjo është veçanërisht e rëndësishme për rrjetet me vonesë të lartë, ku ka një interval të gjatë kohor midis dërgimit të të dhënave dhe marrjes së një ACK (dhe kur negociohet madhësia e dritares). Për të mbajtur një rrjedhë të qëndrueshme të të dhënave nga burimi, fundi marrës duhet të ketë një dritare me të paktën madhësinë e produktit të gjerësisë së brezit dhe vonesës.

Për shembull, nëse burimi mund të dërgojë të dhëna me një shpejtësi prej 10,000 bajt/s, dhe ACK-së i duhen 2 sekonda për t'u kthyer, atëherë pala tjetër duhet të sigurojë një dritare marrëse me madhësi të paktën 20,000 bajt, përndryshe rrjedha e të dhënave nuk do të të jetë i vazhdueshëm. Një tampon pranimi prej 10,000 bajte do të përgjysmojë xhiron.

Një faktor tjetër i rëndësishëm për performancën është aftësia e hostit për t'iu përgjigjur ngjarjeve me prioritet të lartë dhe për të ekzekutuar shpejt ndërrimi i kontekstit, d.m.th. plotësoni disa operacione dhe kaloni në të tjera. Pritësi mund të mbështesë në mënyrë interaktive përdorues të shumtë lokalë, procese të sfondit grupor dhe dhjetëra lidhje të njëkohshme komunikimi. Ndërrimi i kontekstit ju lejon të trajtoni të gjitha këto operacione duke fshehur ngarkesën në sistem. Implementimet që integrojnë TCP/IP me kernelin e sistemit operativ mund të reduktojnë ndjeshëm barrën e përdorimit të ndërrimit të kontekstit.

Burimet e CPU-së së kompjuterit kërkohen për operacionet e përpunimit të kokës TCP. Nëse procesori nuk mund të llogarisë shpejt shumat e kontrollit, kjo çon në një ulje të shpejtësisë së transferimit të të dhënave përmes rrjetit.

Përveç kësaj, zhvilluesit duhet të kërkojnë të thjeshtojnë konfigurimin e cilësimeve të TCP në mënyrë që administratori i rrjetit t'i konfigurojë ato për t'iu përshtatur kërkesave të tyre lokale. Për shembull, aftësia për të rregulluar madhësinë e tamponit me gjerësinë e brezit të rrjetit dhe vonesën do të përmirësojë ndjeshëm performancën. Fatkeqësisht, shumë zbatime nuk i kushtojnë vëmendje të mjaftueshme kësaj çështjeje dhe programojnë në mënyrë të ngurtë parametrat e komunikimit.

Le të supozojmë se mjedisi i rrjetit është i përsosur: ka burime të mjaftueshme dhe ndërrimi i kontekstit kryhet më shpejt se kaubojët që nxjerrin revolverët e tyre. A do të arrihet një performancë e shkëlqyer?

Jo gjithmone. Cilësia e zhvillimit të softuerit TCP gjithashtu ka rëndësi. Me kalimin e viteve, shumë probleme të performancës janë diagnostikuar dhe zgjidhur në zbatime të ndryshme TCP. Mund të konsiderohet se softueri më i mirë do të jetë ai që përputhet me RFC 1122, i cili përcakton kërkesat për shtresën e komunikimit të hosteve të Internetit.

Po aq i rëndësishëm është përjashtimi dhe përdorimin e algoritmeve Jacobson, Kern dhe Partridge (këto algoritme interesante do të diskutohen më poshtë).

Zhvilluesit e softuerit mund të përfitojnë përfitime të konsiderueshme duke krijuar programe që eliminojnë transferimet e panevojshme të sasive të vogla të të dhënave dhe kanë kohëmatës të integruar në burimet e rrjetit të lirë që nuk janë aktualisht në përdorim.

10.13 Algoritme për përmirësimin e performancës

Duke ecur përpara për të njohur pjesën mjaft komplekse të TCP, ne do të shikojmë mekanizmat për rritjen e performancës dhe zgjidhjen e problemeve me kapacitet të reduktuar. Ky seksion diskuton çështjet e mëposhtme:

■ Fillimi i ngadaltë(fillimi i ngadalshëm) parandalon që një pjesë e madhe e trafikut të rrjetit të përdoret për një seancë të re, gjë që mund të rezultojë në humbje.

■ Shërimi nga sindromi i "dritares së paditur".(sindroma e dritares budallaqe) parandalon aplikacionet e dizajnuara keq që të mbingarkojnë rrjetin me mesazhe.

■ ACK me vonesë(ACK i vonuar) redukton mbingarkesën duke reduktuar numrin e mesazheve të konfirmimit të të dhënave të pavarura.

■ Koha e llogaritur e ritransmetimit(llogaritja e kohës së ritransmetimit) bazohet në negocimin e kohës reale të seancës, duke reduktuar sasinë e ritransmetimeve të panevojshme, por nuk shkakton vonesa të mëdha për shkëmbimet vërtet të nevojshme të të dhënave.

■ Ndalimi i përcjelljes së TCP kur mbingarkesat në një rrjet i lejon ruterat të kthehen në modalitetin e tyre origjinal dhe të ndajnë burimet e rrjetit në të gjitha seancat.

■ Dërgimi dublikatë ACK(ACK dublikatë) kur marrja e një segmenti jashtë sekuencës lejon kolegët të ritransmetojnë përpara se të ndodhë një afat kohor.

10.13.1 Nisje e ngadaltë

Nëse ndizni të gjitha pajisjet elektrike shtëpiake në shtëpi në të njëjtën kohë, rrjeti elektrik do të mbingarkohet. Në rrjetet kompjuterike nisje e ngadaltë parandalon fryrjen e siguresave të rrjetit.

Një lidhje e re që fillon menjëherë të dërgojë një sasi të madhe të dhënash në një rrjet tashmë të zënë mund të çojë në probleme. Ideja e një fillimi të ngadaltë është të sigurohet që një lidhje e re të nisë me sukses, ndërsa ngadalë rrit shpejtësinë e transferimit të të dhënave sipas ngarkesës aktuale të rrjetit. Dërguesi kufizohet nga madhësia e dritares së ngarkesës, jo nga dritarja më e madhe e marrjes.

Dritarja e ngarkimit(dritarja e mbingarkesës) fillon me një madhësi prej 1 segmenti. Për çdo segment me një ACK të marrë me sukses, madhësia e dritares së ngarkesës rritet me 1 segment derisa të mbetet më e vogël se dritarja e marrjes. Nëse rrjeti nuk është i mbingarkuar, dritarja e ngarkesës gradualisht do të arrijë madhësinë e dritares marrëse. Në kushte normale të përcjelljes, madhësitë e këtyre dritareve do të jenë të njëjta.

Vini re se një fillim i ngadaltë nuk është aq i ngadaltë. Pas ACK-së së parë, madhësia e dritares së ngarkesës është 2 segmente, dhe pas marrjes me sukses të ACK-së për dy segmente, madhësia mund të rritet në 8 segmente. Me fjalë të tjera, madhësia e dritares rritet në mënyrë eksponenciale.

Le të supozojmë se në vend të marrjes së një ACK, ndodh një situatë timeout. Sjellja e dritares së ngarkesës në këtë rast diskutohet më poshtë.

10.13.2 Sindroma e dritares pa të dhëna

Në implementimet e para TCP/IP, zhvilluesit u ndeshën me fenomenin sindromi i "dritares së paditur".(Silly Window Syndrome - SWS), e cila u shfaq mjaft shpesh. Për të kuptuar ngjarjet që po ndodhin, merrni parasysh skenarin e mëposhtëm, i cili çon në pasoja të padëshirueshme, por është mjaft i mundshëm:

1. Aplikacioni dërgues dërgon të dhëna shpejt.

2. Aplikacioni marrës lexon 1 bajt të dhëna nga buferi i hyrjes (d.m.th. ngadalë).

3. Buferi i hyrjes mbushet shpejt pas leximit.

4. Aplikacioni marrës lexon 1 bajt dhe TCP dërgon një ACK që do të thotë "Kam hapësirë ​​të lirë për 1 bajt të dhënash".

5. Aplikacioni dërgues dërgon një paketë TCP 1-byte përmes rrjetit.

6. TCP marrëse dërgon një ACK që do të thotë "Faleminderit. E mora paketën dhe nuk kam më hapësirë ​​të lirë."

7. Aplikacioni marrës përsëri lexon 1 bajt dhe dërgon një ACK dhe i gjithë procesi përsëritet.

Një aplikacion me marrje të ngadaltë pret një kohë të gjatë që të mbërrijnë të dhënat dhe vazhdimisht e shtyn informacionin e marrë në skajin e majtë të dritares, duke kryer një operacion krejtësisht të padobishëm që gjeneron trafik shtesë në rrjet.

Situatat reale, natyrisht, nuk janë aq ekstreme. Një dërgues i shpejtë dhe një marrës i ngadalshëm do të shkëmbejnë pjesë të vogla (në raport me madhësinë maksimale të segmentit) të të dhënave dhe do të kalojnë në një dritare pothuajse të plotë të marrjes. Në Fig. Figura 10.18 tregon kushtet për shfaqjen e sindromës "dritare budallaqe".

Oriz. 10.18. Dritarja marrëse e tamponit me hapësirë ​​shumë të vogël të lirë

Zgjidhja e këtij problemi nuk është e vështirë. Sapo dritarja e marrjes zvogëlohet në një gjatësi më të vogël se kjo madhësi e synuar, TCP fillon të mashtrojë dërguesin. Në këtë situatë, TCP nuk duhet t'i tregojë dërguesit shtesë hapësira e dritares kur aplikacioni marrës lexon të dhënat nga buferi në copa të vogla. Në vend të kësaj, ju duhet t'i mbani sekret burimet e lëshuara nga dërguesi derisa të ketë mjaft prej tyre. Rekomandohet një madhësi e vetme segmenti, përveç nëse i gjithë buferi i hyrjes ruan një segment të vetëm (në rastin e fundit, përdoret një madhësi gjysmë-bufer). Madhësia e synuar që TCP duhet të raportojë mund të shprehet si:

minimale (1/2 bufer hyrëse, madhësia maksimale e segmentit)

TCP fillon të gënjejë kur madhësia e dritares bëhet më e vogël se kjo madhësi dhe do të tregojë të vërtetën kur madhësia e dritares nuk është më e vogël se vlera e marrë nga formula. Vini re se nuk ka asnjë dëm për dërguesin, pasi aplikacioni marrës nuk do të jetë në gjendje të përpunojë shumë nga të dhënat që pret gjithsesi.

Zgjidhja e propozuar mund të verifikohet lehtësisht në rastin e diskutuar më sipër me një dalje ACK për secilin nga bajtët e marrë. E njëjta metodë është gjithashtu e përshtatshme për rastin kur buferi i hyrjes mund të ruajë disa segmente (siç ndodh shpesh në praktikë). Dërguesi i shpejtë do të mbushë buferin e hyrjes, por marrësi do të tregojë se nuk ka hapësirë ​​të lirë për të akomoduar informacionin dhe nuk do ta hapë këtë burim derisa madhësia e tij të arrijë të gjithë segmentin.

10.13.3 Algoritmi i Nagle

Dërguesi duhet, pavarësisht nga marrësi, të shmangë dërgimin e segmenteve shumë të shkurtra duke grumbulluar të dhëna përpara se të dërgojë. Algoritmi i Nagle zbaton një ide shumë të thjeshtë që ju lejon të zvogëloni numrin e të dhënave të shkurtra të dërguara në rrjet.

Algoritmi rekomandon vonimin e përcjelljes (dhe shtyrjes) të të dhënave gjatë pritjes për një ACK nga të dhënat e transmetuara më parë. Të dhënat e grumbulluara dërgohen pas marrjes së një ACK për një informacion të dërguar më parë, ose pas marrjes së të dhënave për t'i dërguar në sasinë e një segmenti të plotë, ose pas përfundimit të një afati kohor. Ky algoritëm nuk duhet të përdoret për aplikacione në kohë reale që duhet të dërgojnë të dhëna sa më shpejt të jetë e mundur.

10.13.4 ACK e vonuar

Një mekanizëm tjetër për të përmirësuar performancën është metoda e vonesës ACK. Zvogëlimi i numrit të ACK-ve zvogëlon gjerësinë e brezit që mund të përdoret për të përcjellë trafikun tjetër. Nëse peer TCP vonon pak dërgimin e ACK, atëherë:

■ Segmente të shumta mund të pranohen me një ACK të vetme.

■ Aplikacioni marrës është në gjendje të marrë një sasi të caktuar të të dhënave brenda intervalit të skadimit, d.m.th. ACK mund të përmbajë kokën e daljes dhe nuk kërkon gjenerimin e një mesazhi të veçantë.

Për të shmangur vonesat gjatë dërgimit të një rryme segmentesh me gjatësi të plotë (për shembull, kur shkëmbeni skedarë), duhet të dërgohet një ACK për të paktën çdo segment tjetër të plotë.

Shumë zbatime përdorin një afat kohor prej 200 ms. Por një ACK e vonuar nuk e ul kursin e këmbimit. Kur arrin një segment i shkurtër, ka ende hapësirë ​​të mjaftueshme të lirë në buferin e hyrjes për të marrë të dhëna të reja dhe dërguesi mund të vazhdojë të dërgojë (përveç kësaj, ridërgimi zakonisht është shumë më i ngadalshëm). Nëse arrin një segment i tërë, duhet t'i përgjigjeni atij në të njëjtin sekondë me një mesazh ACK.

10.13.5 Koha e ritransmetimit

Pas dërgimit të segmentit, TCP vendos një kohëmatës dhe monitoron mbërritjen e ACK. Nëse një ACK nuk merret brenda periudhës së skadimit, TCP ritransmeton segmentin (rele). Megjithatë, cila duhet të jetë periudha e pushimit?

Nëse është shumë i shkurtër, dërguesi do të vërshojë rrjetin duke përcjellë segmente të panevojshme që kopjojnë informacionin që tashmë është dërguar. Kohëzgjatja shumë e madhe do të parandalojë riparimin e shpejtë të segmenteve që në fakt janë shkatërruar gjatë përcjelljes, gjë që do të reduktojë xhiron.

Si të zgjidhni periudhën e duhur të skadimit? Një vlerë që është e përshtatshme për një rrjet lokal me shpejtësi të lartë nuk do të jetë e përshtatshme për një lidhje në distancë me shumë goditje. Kjo do të thotë se parimi i "një vlerë për çdo kusht" është qartësisht i papërshtatshëm. Për më tepër, edhe për një lidhje specifike ekzistuese, kushtet e rrjetit mund të ndryshojnë dhe vonesat mund të rriten ose ulen.

Algoritmet Jacobson, Kern dhe Partridge (të përshkruara në artikuj , Van Jacobson, dhe Përmirësimi i vlerësimeve të kohës së udhëtimit vajtje-ardhje në protokollet e besueshme të transportit, Karn dhe Partridge) lejojnë TCP të përshtatet me ndryshimin e kushteve të rrjetit. Këto algoritme rekomandohen për përdorim në implementime të reja. Më poshtë do t'i shikojmë shkurtimisht.

Arsyeja e shëndoshë dikton që baza më e mirë për të vlerësuar kohën e saktë të skadimit për një lidhje të caktuar do të ishte monitorimi koha e ciklit(koha vajtje-ardhje) si intervali ndërmjet dërgimit të të dhënave dhe marrjes së konfirmimit të marrjes së tyre.

Zgjidhje të mira për sasitë e mëposhtme mund të merren nga statistikat bazë (shih Figurën 10.19) për të ndihmuar në llogaritjen e kohës së skadimit. Sidoqoftë, nuk duhet të mbështeteni në mesataret, pasi më shumë se gjysma e vlerësimeve do të jenë më të mëdha se mesatarja statistikore. Duke marrë në konsideratë disa pika të jashtme, mund të marrim vlerësime më të mira që marrin parasysh shpërndarjen normale dhe zvogëlojnë kohën tepër të gjatë të pritjes së ritransmetimit.

Oriz. 10.19. Shpërndarja e kohërave të ciklit

Nuk ka nevojë për një sasi të madhe llogaritjesh për të marrë vlerësime formale matematikore të devijimeve. Ju mund të përdorni vlerësime mjaft të përafërta bazuar në vlerën absolute të diferencës midis vlerës së fundit dhe vlerësimit mesatar:

Devijimi i fundit = | Cikli i fundit - Mesatar |

Për të llogaritur vlerën e saktë të skadimit, një faktor tjetër që duhet marrë parasysh është ndryshimi në kohën e ciklit për shkak të kushteve aktuale të rrjetit. Ajo që ndodh në internet në minutën e fundit është më e rëndësishme se ajo që ndodhi një orë më parë.

Le të supozojmë se po llogarisim mesataren e ciklit për një seancë shumë të gjatë. Le të ngarkohet lehtë rrjeti në fillim dhe ne identifikuam 1000 vlera të vogla, por më pas pati një rritje të trafikut me një rritje të konsiderueshme të vonesës.

Për shembull, nëse 1000 vlera jepnin një mesatare statistikore prej 170 njësi, por më pas maten 50 vlera me një mesatare prej 282, atëherë mesatarja aktuale do të ishte:

170×1000/1050 + 282×50/1050 = 175

Një vlerë më e arsyeshme do të ishte koha e ciklit të zbutur(Koha e zbutur Round-Trip - SRTT), e cila merr parasysh përparësinë e vlerave të mëvonshme:

SRTT e re = (1 – α)×(SRTT e vjetër) + α×Vlera e ciklit të fundit

Vlera e α është midis 0 dhe 1. Rrit a rezulton në një ndikim më të madh të kohës së ciklit aktual në mesataren e zbutur. Meqenëse kompjuterët mund të kryejnë shpejt pjesëtimin me fuqitë e 2 duke zhvendosur numrat binarë djathtas, α zgjidhet gjithmonë të jetë (1/2)n (zakonisht 1/8), kështu që:

SRTT e re = 7/8×SRTT e vjetër + 1/8×Koha e ciklit të fundit

Tabela 10.2 tregon se si formula për SRTT përshtatet me vlerën aktuale të SRTT prej 230 njësive kur një ndryshim në kushtet e rrjetit shkakton që koha e ciklit të rritet në mënyrë progresive (duke supozuar se nuk ndodh skadimi). Vlerat në kolonën 3 përdoren si vlera në kolonën 1 për rreshtin tjetër të tabelës (d.m.th., si SRTT e vjetër).

Tabela 10.2 Llogaritja e kohës së ciklit të zbutur

SRTT e vjetër	RTT e fundit	(7/8)×(SRTT e vjetër) + (1/8)×(RTT)
230.00	294	238.00
238.00	264	241.25
241.25	340	253.59
253.59	246	252.64
252.64	201	246.19
246.19	340	257.92
257.92	272	259.68
259.68	311	266.10
266.10	282	268.09
268.09	246	265.33
265.33	304	270.16
270.16	308	274.89
274.89	230	269.28
269.28	328	276.62
276.62	266	275.29
275.29	257	273.00
273.00	305	277.00

Tani vjen çështja e zgjedhjes së një vlere për afatin e ritransmetimit. Analiza e vlerave të kohës së ciklit tregon një devijim të konsiderueshëm të këtyre vlerave nga vlera mesatare aktuale. Ka kuptim të vendoset një kufi për madhësinë e devijimeve. Një vlerë e mirë për kohëzgjatjen e ritransmetimit (në standardet RFC kjo vlerë quhet Koha e Ritransmetimit - RTO) jepet nga formula e mëposhtme me një kufizim të devijimit të zbutur (SDEV):

T = Koha e ritransmetimit = SRTT + 2×SDEV

T = SRTT + 4×SDEV

Për të llogaritur SDEV, së pari përcaktoni vlerën absolute të devijimit aktual:

DEV = | Koha e ciklit të fundit - SRTT e vjetër |

Formula e zbutjes përdoret më pas për të marrë parasysh vlerën e fundit:

SDEV i ri = 3/4×SDEV i vjetër + 1/4×DEV

Mbetet një pyetje - cilat vlera fillestare duhet të merren? Rekomanduar:

Koha fillestare = 3 sekonda

SRTT fillestar = 0

SDEV fillestar = 1,5 s

Van Jacobson përcaktoi një algoritëm të shpejtë që llogarit në mënyrë shumë efikase kohën e ritransmetimit të të dhënave.

10.13.6 Shembull i statistikave

Sa i suksesshëm do të jetë koha e llogaritur më sipër? Kur kjo vlerë u zbatua, u vunë re përmirësime të rëndësishme të performancës. Një shembull do të ishte statistikat e ekipit netstat, të marra në sistem tigër- një server interneti i aksesuar nga shumë host nga e gjithë bota.

1510769 pako (314955304 byte) të marra në sekuencë

Sistemi tigër Më pak se 2.5% e segmenteve të të dhënave TCP u ritransmetuan. Për një milion e gjysmë segmente të të dhënave hyrëse (pjesa tjetër janë mesazhe të pastra ACK), vetëm 0.6% u dyfishuan. Duhet të merret parasysh se niveli i humbjeve në të dhënat hyrëse përafërsisht korrespondon me nivelin për segmentet e prodhimit. Kështu, trafiku i kotë i ritransmetimit përbën rreth 0.6% të trafikut total.

10.13.7 Llogaritjet pas ridërgimit

Formulat e paraqitura më sipër përdorin kohën e ciklit si interval midis dërgimit të një segmenti dhe marrjes së një konfirmimi të marrjes së tij. Megjithatë, supozoni se nuk është marrë asnjë konfirmim brenda periudhës së skadimit dhe të dhënat duhet të dërgohen përsëri.

Algoritmi i Kernit supozon se koha e ciklit nuk duhet të ndryshohet në këtë rast. Vlera kohore e ciklit aktual të zbutur dhe devijimi i zbutur ruajnë vlerat e tyre derisa të merret konfirmimi për të përcjellë një segment të caktuar pa e ridërguar atë. Nga kjo pikë e tutje, llogaritjet rifillojnë në bazë të vlerave të ruajtura dhe matjeve të reja.

10.13.8 Veprimet pas ritransmetimit

Por çfarë ndodh përpara se të merret konfirmimi? Pas ritransmetimit, sjellja e TCP ndryshon rrënjësisht, kryesisht për shkak të humbjes së të dhënave për shkak të mbingarkesës së rrjetit. Prandaj, përgjigja ndaj ridërgimit të të dhënave do të jetë:

■ Shkalla e reduktuar e ritransmetimit

■ Luftoni mbingarkesën e rrjetit duke reduktuar trafikun e përgjithshëm

10.13.9 Frenimi eksponencial

Pas ritransmetimit, intervali i skadimit dyfishohet. Megjithatë, çfarë ndodh nëse kohëmatësi tejmbush përsëri? Të dhënat do të dërgohen përsëri dhe periudha e ritransmetimit do të dyfishohet përsëri. Ky proces quhet frenim eksponencial(mbrapa eksponenciale).

Nëse defekti i rrjetit vazhdon të ndodhë, periudha e skadimit do të dyfishohet derisa të arrihet vlera maksimale e paracaktuar (zakonisht 1 minutë). Pas një kohe, vetëm një segment mund të dërgohet. Një kohëzgjatje ndodh gjithashtu kur tejkalohet vlera e paracaktuar për numrin e transferimeve të të dhënave pa marrë një ACK.

10.13.10 Reduktimi i mbingarkesës duke reduktuar të dhënat e dërguara përmes rrjetit

Reduktimi i sasisë së të dhënave të dërguara është disi më kompleks se mekanizmat e diskutuar më sipër. Fillon të funksionojë, ashtu si fillimi i ngadaltë i përmendur tashmë. Por, meqenëse është vendosur një kufi në nivelin e trafikut që fillimisht mund të çojë në probleme, shpejtësia e shkëmbimit në të vërtetë do të ngadalësohet për shkak të një rritje në madhësinë e dritares së ngarkesës për një segment. Ju duhet të vendosni vlerat kufitare për të zvogëluar shpejtësinë e dërgimit. Së pari, llogaritet pragu i rrezikut:

Kufiri – minimumi 1/2 (dritarja aktuale e ngarkesës, dritarja e marrjes së partnerit)

Nëse vlera që rezulton është më shumë se dy segmente, ajo përdoret si kufi. Përndryshe, madhësia e kufirit vendoset në dy segmente. Algoritmi i rikuperimit të plotë kërkon:

■ Vendosni madhësinë e dritares së ngarkesës në një segment.

■ Për çdo ACK të marrë, rrisni madhësinë e dritares së ngarkesës me një segment derisa të arrihet kufiri (ashtu si mekanizmi i ngadaltë i fillimit).

■ Më pas, me çdo ACK të marrë, shtoni një vlerë më të vogël në dritaren e ngarkesës, e cila zgjidhet bazuar në shkallën e rritjes për segment për kohën e ciklit (rritja llogaritet si MSS/N, ku N është madhësia e dritares së ngarkesës në segmente).

Skenari ideal mund të sigurojë një paraqitje të thjeshtuar se si funksionon mekanizmi i rikuperimit. Le të supozojmë se dritarja e marrjes së partnerit (dhe dritarja aktuale e ngarkesës) kishte një madhësi prej 8 segmentesh përpara se të zbulohej afati, dhe kufiri ishte përcaktuar si 4 segmente. Nëse aplikacioni marrës lexon menjëherë të dhënat nga buferi, madhësia e dritares së pranimit do të mbetet 8 segmente.

■ Dërgohet 1 segment (dritarja e ngarkesës = 1 segment).

■ ACK është marrë - 2 segmente janë dërguar.

■ ACK është marrë për 2 segmente - 4 segmente janë dërguar (kufiri është arritur).

■ ACK është marrë për 4 segmente. Janë dërguar 5 segmente.

■ ACK është marrë për 5 segmente. Janë dërguar 6 segmente.

■ ACK është marrë për 6 segmente. Janë dërguar 7 segmente.

■ ACK marrë për 7 segmente. Dërgohen 8 segmente (dritarja e ngarkimit është përsëri e barabartë në madhësi me dritaren marrëse).

Meqenëse ritransmetimi i skadimit kërkon konfirmimin e marrjes së të gjitha të dhënave të dërguara, procesi vazhdon derisa dritarja e ngarkimit të arrijë madhësinë e dritares së pranimit. Ngjarjet që ndodhin janë paraqitur në Fig. 10.20. Madhësia e dritares rritet në mënyrë eksponenciale, duke u dyfishuar gjatë periudhës së fillimit të ngadaltë dhe rritet në mënyrë lineare sapo të arrihet kufiri.

Oriz. 10.20. Kufizimi i shpejtësisë së përcjelljes gjatë mbingarkesës

10.13.11 ACK-të e dyfishta

Disa zbatime përdorin një veçori opsionale të quajtur ridërgoni shpejt(ritransmetim i shpejtë) - për të shpejtuar ridërgimin e të dhënave në kushte të caktuara. Ideja e tij themelore përfshin dërgimin e marrësit të ACK-ve shtesë që tregojnë një boshllëk në të dhënat e marra.

Kur merr një segment jashtë rendit, marrësi dërgon një ACK që tregon bajtin e parë humbur të dhëna (shih Figurën 10.21).

Oriz. 10.21. ACK-të e kopjuara

Dërguesi nuk i ritransmeton menjëherë të dhënat sepse IP normalisht mund t'i japë të dhëna marrësit pa një sekuencë dërgimi. Por kur merren disa ACK shtesë të dyfishta të të dhënave (për shembull, tre), segmenti që mungon do të dërgohet pa pritur përfundimin e afatit.

Vini re se çdo ACK dublikatë tregon marrjen e një segmenti të të dhënave. Disa ACK dublikatë tregojnë se rrjeti është i aftë të japë një sasi të mjaftueshme të dhënash dhe për këtë arsye nuk është tepër i ngarkuar. Si pjesë e algoritmit të përgjithshëm, një reduktim i vogël i madhësisë së dritares së ngarkesës kryhet kur ka një rritje reale të trafikut të rrjetit. Në këtë rast, procesi i ndryshimit të përmasave radikale gjatë restaurimit të punës nuk zbatohet.

Sipas standardit Kërkesat e hostit(kërkesat e hostit) TCP duhet të kryejë të njëjtin fillim të ngadaltë siç përshkruhet më sipër kur shuan burimin. Megjithatë, ky mesazh nuk është i synuar ose efektiv sepse lidhja që merr mesazhin mund të mos gjenerojë shumë trafik. Specifikimi aktual Kërkesat e ruterit(kërkesat e ruterit) tregon se ruterat nuk duhet dërgoni mesazhe në lidhje me shtypjen e burimit.

13/10/13 Statistikat e TCP

Së fundi, le të shohim mesazhet statistikore të ekipit netstat, për të parë në punë shumë nga mekanizmat e përshkruar më sipër.

Segmentet quhen paketa.

879137 paketa të dhënash (226966295 byte)

21815 paketa të dhënash (8100927 byte) të ritransmetuara

Ri-dërgesë.

132957 pako vetëm për pranim (104216 me vonesë)

Le të vërejmë një numër të madh

ACK e vonuar.

Sonda e hapjes së dritares

madhësi zero.

Këto janë mesazhe SYN dhe FIN.

762469 akse (për 226904227 bajt)

Sinjali për mbërritjen e paketave

jashtë sekuencës.

1510769 pako (314955304 byte)

9006 paketa plotësisht të kopjuara (867042 byte)

Rezultati i afatit me real

shpërndarjen e të dhënave.

74 pako me disa dup. të dhëna (12193 bajt të mashtruar)

Për efikasitet më të madh

disa të dhëna u ripaketuan për të përfshirë bajt shtesë kur dërgoheshin përsëri.

13452 pako jashtë rendit (2515087 byte)

530 pako (8551 bajt) të dhënash pas dritares

Ndoshta këto të dhëna ishin

përfshirë në mesazhet tingëlluese.

402 pako të marra pas mbylljes

Këto janë përsëritje të mëvonshme

duke dërguar.

108 u hodhën për kontrolle të këqija

Shuma e kontrollit TCP e pavlefshme.

0 është hedhur poshtë për fushat e zhvendosjes së gabuar të kokës

7 u hodh për shkak se paketa është shumë e shkurtër

14677 lidhje të vendosura (përfshirë pranimet)

18929 lidhje të mbyllura (përfshirë 643 pika)

4100 lidhje embrionale ranë

572187 segmente të përditësuara rtt (nga 587397 përpjekje)

Përpjekjet për ndryshim të dështuara

koha e ciklit, pasi ACK nuk ka mbërritur përpara skadimit të afatit,

26 lidhje u ndërprenë nga koha e kthimit

Përpjekjet e mëvonshme të pasuksesshme

ridërgo, duke treguar një lidhje të humbur.

Afatet e provës

dritare zero.

Afatet e verifikimit

lidhje e prishur.

472 lidhje të rënë nga keepalive

10.14 Pajtueshmëria me kërkesat e zhvilluesit

Standardi aktual TCP kërkon që implementimet t'i përmbahen rreptësisht procedurës së fillimit të ngadaltë kur inicializojnë një lidhje dhe të përdorin algoritmet Kern dhe Jacobson për të vlerësuar kohën e ridërgimit të të dhënave dhe kontrollin e ngarkesës. Testet kanë treguar se këto mekanizma çojnë në përmirësime të rëndësishme të performancës.

Çfarë ndodh kur instaloni një sistem që nuk i përmbahet rreptësisht këtyre standardeve? Ai nuk do të ofrojë performancë adekuate për përdoruesit e vet dhe do të jetë një fqinj i dobët për sistemet e tjera në rrjet, duke e penguar atë të rikuperohet nga një mbingarkesë e përkohshme dhe të gjenerojë trafik të tepërt që shkakton rënien e të dhënave.

10.15 Barrierat ndaj produktivitetit

TCP ka vërtetuar fleksibilitetin e tij duke operuar mbi rrjete me shpejtësi transferimi prej qindra ose miliona bit në sekondë. Ky protokoll ka arritur rezultate të mira në rrjetet moderne lokale me topologji Ethernet, Token-Ring dhe Fiber Distributed Data Interface (FDDI), si dhe për lidhjet e komunikimit me shpejtësi të ulët ose lidhjet në distanca të gjata (të ngjashme me lidhjet satelitore).

TCP është krijuar për t'iu përgjigjur kushteve ekstreme të tilla si bllokimi i rrjetit. Sidoqoftë, versioni aktual i protokollit ka veçori që kufizojnë performancën në teknologjitë premtuese që ofrojnë gjerësi bande prej qindra ose mijëra megabajt. Për të kuptuar problemet e përfshira, merrni parasysh një shembull të thjeshtë (ndonëse jorealist).

Supozoni se kur zhvendosni një skedar midis dy sistemeve, dëshironi të kryeni një rrjedhë të vazhdueshme shkëmbimi sa më efikas të jetë e mundur. Le të supozojmë se:

■ Madhësia maksimale e segmentit të marrësit është 1 KB.

■ Dritarja e marrjes - 4 KB.

■ Gjerësia e brezit ju lejon të dërgoni dy segmente në 1 s.

■ Aplikacioni marrës i konsumon të dhënat kur mbërrijnë.

■ Mesazhet ACK mbërrijnë pas 2 s.

Dërguesi është në gjendje të dërgojë të dhëna vazhdimisht. Në fund të fundit, kur vëllimi i caktuar për dritaren është i plotë, vjen një ACK, duke lejuar dërgimin e një segmenti tjetër:

Pas 2 s:

MERRNI KËRKIM TË SEGMENTIT 1, MUND TË DËRGONI SEGMENTIN 5.

MERRNI KËRKIM TË SEGMENTIT 2, MUND TË DËRGONI SEGMENTIN 6.

MERRNI KËRKIM TË SEGMENTIT 3, MUND TË DËRGONI SEGMENTIN 7.

MERRNI KËRKIM TË SEGMENTIT 4, MUND TË DËRGONI SEGMENTIN 8.

Pas 2 sekondash të tjera:

MERRNI KËRKESËN E SEGMENTIT 5, MUND TË DËRGONI SEGMENTIN 9.

Nëse dritarja e marrjes ishte vetëm 2 KB, dërguesi do të detyrohej të priste një sekondë në çdo dy përpara se të dërgonte të dhënat e radhës. Në fakt, për të mbajtur një rrjedhë të vazhdueshme të të dhënave, dritarja marrëse duhet të jetë së paku:

Dritarja = Gjerësia e brezit×Koha e ciklit

Megjithëse shembulli është disi i ekzagjeruar (për të siguruar numra më të thjeshtë), një dritare e vogël mund të shkaktojë probleme në lidhjet satelitore me vonesë të lartë.

Tani le të shohim se çfarë ndodh me lidhjet me shpejtësi të lartë. Për shembull, nëse gjerësia e brezit dhe shpejtësia e përcjelljes maten me 10 milion bit për sekondë, por koha e ciklit është 100 ms (1/10 e sekondës), atëherë për një rrymë të vazhdueshme dritarja marrëse duhet të ruajë të paktën 1.000.000 bit, d.m.th. . 125,000 byte. Por numri më i madh që mund të shkruhet në fushën e kokës për një dritare të pranimit të TCP është 65,536.

Një problem tjetër lind me shpejtësi të lartë baud sepse numrat e sekuencës do të mbarojnë shumë shpejt. Nëse lidhja mund të transferojë të dhëna me një shpejtësi prej 4 GB/s, atëherë numrat e sekuencës duhet të përditësohen brenda çdo sekonde. Nuk do të ketë asnjë mënyrë për të bërë dallimin midis datagrameve të vjetra të kopjuara që u vonuan për më shumë se një sekondë ndërsa lëviznin nëpër internet nga të dhënat e reja të reja.

Hulumtimi i ri po kryhet në mënyrë aktive për të përmirësuar TCP/IP dhe për të eliminuar pengesat e përmendura më sipër.

10.16 Funksionet TCP

Ky kapitull mbulon shumë funksione të TCP. Ato kryesore janë renditur më poshtë:

■Lidhja e porteve me lidhjet

■ Inicializoni lidhjet duke përdorur konfirmimin me tre hapa

■ Kryerja e një fillimi të ngadaltë për të shmangur mbingarkimin e rrjetit

■ Segmentimi i të dhënave gjatë transmetimit

■ Numërimi i të dhënave

■ Përpunimi i segmenteve të dyfishta në hyrje

■ Llogaritja e shumave kontrolluese

■ Kontrolli i rrjedhës së të dhënave përmes dritares marrëse dhe asaj dërguese

■ Ndërprisni lidhjen në mënyrën e përcaktuar

■ Ndërprerja e lidhjes

■ Përcjellja e të dhënave urgjente

■ Konfirmim pozitiv i ridërgimit

■ Llogaritni kohën e ritransmetimit

■ Trafiku i reduktuar i kthimit gjatë mbingarkesës së rrjetit

■ Sinjalizimi që segmentet vijnë jashtë rendit

■ Ndjenja e mbylljes së dritares marrëse

10.17 shtetet e TCP

Një lidhje TCP kalon nëpër disa faza: lidhja krijohet duke shkëmbyer mesazhe, më pas dërgohen të dhënat dhe më pas lidhja mbyllet duke shkëmbyer mesazhe të veçanta. Çdo hap në operacionin e lidhjes korrespondon me një specifikë gjendje kjo lidhje. Softueri TCP në çdo skaj të lidhjes monitoron vazhdimisht gjendjen aktuale të anës tjetër të lidhjes.

Më poshtë do të shohim shkurtimisht tranzicionin tipik të gjendjes midis një serveri dhe një klienti të vendosur në skajet e kundërta të një lidhjeje. Ne nuk synojmë të ofrojmë një përshkrim shterues të të gjitha gjendjeve të mundshme gjatë dërgimit të të dhënave. Është dhënë në RFC 793 dhe dokument Kërkesat e hostit.

Gjatë vendosjes së lidhjes, serveri dhe klienti kalojnë nëpër sekuenca të ngjashme gjendjesh. Gjendjet e serverit janë paraqitur në tabelën 10.3 dhe gjendjet e klientit janë paraqitur në tabelën 10.4.

Tabela 10.3 Sekuenca e gjendjes së serverit

Statusi i serverit	Ngjarja	Përshkrim
MBYLLUR		Gjendja dummy para fillimit të vendosjes së lidhjes.
	Hapja pasive nga një aplikacion serveri.
DËGJO (përcjellje)		Serveri është duke pritur për një lidhje nga klienti.
	Serveri TCP merr SYN dhe dërgon një SYN/ACK.	Serveri mori SYN dhe dërgoi SYN/ACK. Shkon në pritje për ACK.
SYN-MARRË	Serveri TCP merr një ACK.
I KRIJUAR (i instaluar)		ACK u mor, lidhja e hapur.

Tabela 10.4 Sekuenca e shtetit të klientit

Nëse partnerët do të përpiqeshin njëkohësisht të krijonin një lidhje me njëri-tjetrin (gjë që është jashtëzakonisht e rrallë), secili do të kalonte në gjendjet e MBYLLUR, SYN-DËRGUAR, SYN-RECEIVED dhe ESTABLISHED.

Palët fundore të lidhjes mbeten në gjendjen e KRIJUAR derisa të fillojë njëra nga palët mbyllje lidhjet duke dërguar segmentin FIN. Gjatë një mbylljeje normale, pala që nis mbylljen kalon nëpër gjendjet e paraqitura në tabelën 10.5. Partneri i saj kalon nëpër gjendjet e paraqitura në tabelën 10.6.

Tabela 10.5 Sekuenca e gjendjeve të anës që mbyll lidhjen

Mbyllja e shteteve anësore	Ngjarja	Përshkrim
I THEMELUAR	Një aplikacion lokal kërkon që lidhja të mbyllet.
	TCP dërgon FIN/ACK.
FIN-PRIT-1		Pala mbyllëse pret përgjigjen e partnerit. Ju kujtojmë se të dhëna të reja mund të vijnë ende nga partneri.
	TCP merr një ACK.
FIN-PRIT-2		Pala mbyllëse ka marrë një ACK nga kolegu, por nuk ka marrë ende një FIN. Pala mbyllëse pret për FIN kur pranon të dhënat hyrëse.
	TCP merr FIN/ACK.
	Dërgon ACK.
KOHA-PRIT		Lidhja mbahet në një gjendje të papërcaktuar për të lejuar që të dhënat e kopjuara ose FIN-të e kopjuara ende ekzistuese në rrjet të arrijnë ose të hidhen. Periudha e pritjes është dyfishi i vlerësimit maksimal të jetëgjatësisë së segmentit.
MBYLLUR

Tabela 10.6 Sekuenca e shteteve partnere pas mbylljes së një lidhjeje

Statusi i partnerit	Ngjarja	Përshkrim
I THEMELUAR	TCP merr FIN/ACK.
MBYLL-PRIT		FIN ka ardhur.
	TCP dërgon një ACK.
		TCP pret që aplikacioni i tij të mbyllë lidhjen. Në këtë pikë, aplikacioni mund të jetë duke dërguar një sasi mjaft të madhe të dhënash.
	Aplikacioni lokal fillon mbylljen e lidhjes.
	TCP dërgon FIN/ACK.
KËRKESA E FUNDIT		TCP pret për ACK-në përfundimtare.
	TCP merr një ACK.
MBYLLUR		Të gjitha informacionet e lidhjes janë fshirë.

10.17.1 Analizimi i gjendjeve të lidhjes TCP

Ekipi netstat -an ju lejon të kontrolloni statusin aktual të lidhjes. Lidhjet në shtete janë paraqitur më poshtë dëgjo, nisje, themeluar, mbyllje Dhe kohë-prit.

Vini re se numri i portës së lidhjes është renditur në fund të çdo adrese lokale dhe të jashtme. Mund të shihni që ka trafik TCP si për radhët hyrëse ashtu edhe për ato dalëse.

Pro Recv-Q Send-Q Adresa Lokale Adresa e Jashtme (shteti)

Tcp 0 0 128.121.50.145.25 128.252.223.5.1526 SYN_RCVD

Tcp 0 0 128.121.50.145.25 148.79.160.65.3368 I THEMELUAR

Tcp 0 0 127.0.0.1.1339 127.0.0.1.111 TIME_PRIT

Tcp 0 438 128.121.50.145.23 130.132.57.246.2219 E THEMELUAR

Tcp 0 0 128.121.50.145.25 192.5.5.1.4022 KOHA_PRIT

Tcp 0 0 128.121.50.145.25 141.218.1.100.3968 KOHA_PRIT

Tcp 0 848 128.121.50.145.23 192.67.236.10.1050 E THEMELUAR

Tcp 0 0 128.121.50.145.1082 128.121.50.141.6000 E THEMELUAR

Tcp 0 0 128.121.50.145.1022 128.121.50.141.1017 E THEMELUAR

Tcp 0 0 128.121.50.145.514 128.121.50.141.1020 CLOSE_PRIT

Tcp 0 1152 128.121.50.145.119 192.67.239.23.3572 I THEMELUAR

Tcp 0 0 128.121.50.145.1070 192.41.171.5.119 KOHA_PRIT

Tcp 579 4096 128.121.50.145.119 204.143.19.30.1884 I THEMELUAR

Tcp 0 0 128.121.50.145.119 192.67.243.13.3704 E THEMELUAR

Tcp 0 53 128.121.50.145.119 192.67.236.218.2018 FIN_WAIT_1

Tcp 0 0 128.121.50.145.119 192.67.239.14.1545 I THEMELUAR

10.18 Shënime mbi implementimet

Që në fillim, protokolli TCP u krijua për të ndërvepruar pajisjet e rrjetit nga prodhues të ndryshëm. Specifikimi i TCP nuk specifikon saktësisht se si duhet të funksionojnë strukturat e brendshme të zbatimit. Këto pyetje u janë lënë zhvilluesve, të cilët kanë për detyrë të gjejnë mekanizmat më të mirë për çdo zbatim specifik.

Edhe RFC 1122 (dokument Kërkesat e hostit - kërkesat për hostet) lë liri të mjaftueshme për variacione. Secili prej funksioneve të zbatuara është shënuar me një nivel të caktuar përputhshmërie:

■ MAJ (Lejohet)

■ NUK DUHET

Fatkeqësisht, ndonjëherë ka produkte që nuk zbatojnë kërkesat MUST. Si rezultat, përdoruesit përjetojnë shqetësimin e performancës së reduktuar.

Disa praktika të mira të zbatimit nuk mbulohen në standarde. Për shembull, siguria mund të përmirësohet duke kufizuar përdorimin e porteve të njohura nga procese të privilegjuara në sistem, nëse sistemi operativ lokal e mbështet këtë metodë. Për të përmirësuar performancën, zbatimet duhet të kopjojnë dhe zhvendosin të dhënat e dërguara ose të marra sa më pak të jetë e mundur.

Ndërfaqja standarde e programimit të aplikacionit të papërcaktuara(si dhe politika e sigurisë), në mënyrë që të ketë hapësirë ​​të lirë për të eksperimentuar me grupe të ndryshme mjetesh softuerike. Megjithatë, kjo mund të rezultojë në ndërfaqe të ndryshme programimi që përdoren në secilën platformë dhe nuk do të lejojë që softueri i aplikacionit të zhvendoset ndërmjet platformave.

Në fakt, zhvilluesit i bazojnë mjetet e tyre në ndërfaqen e programimit Socket, të huazuar nga Berkeley. Rëndësia e ndërfaqes së softuerit u rrit me ardhjen e WINSock (Windows Socket), i cili çoi në një përhapje të aplikacioneve të reja desktop që mund të funksiononin në krye të çdo ndërfaqeje WINSock të pajtueshme me pirgun TCP/IP.

10.19 Leximi i mëtejshëm

Standardi origjinal TCP është përcaktuar në RFC 793. Përmirësimet, rishikimet dhe kërkesat e përputhshmërisë trajtohen në RFC 1122. Kern dhe Partridge publikuan artikullin Përmirësimi i vlerësimeve të udhëtimit vajtje-ardhje në protokollet e besueshme të transportit Në revistë Procedurat e ACM SIGCOMM 1987. Artikulli i Jacobson Shmangia dhe Kontrolli i Kongjestionit u shfaq në Procedurat e Punëtorisë ACM SIGCOMM 1988. Jacobson lëshoi ​​gjithashtu disa RFC duke rishikuar algoritmet e performancës.

Serverët që zbatojnë këto protokolle në një rrjet të korporatës i ofrojnë klientit një adresë IP, portë, maskë rrjeti, serverë emrash dhe madje edhe një printer. Përdoruesit nuk duhet të konfigurojnë manualisht hostet e tyre në mënyrë që të përdorin rrjetin.

Sistemi operativ QNX Neutrino zbaton një tjetër protokoll konfigurimi automatik të quajtur AutoIP, i cili është një projekt i Komitetit të Auto-konfigurimit të IETF. Ky protokoll përdoret në rrjete të vogla për të caktuar adresat IP lokale të lidhjeve për hostet. Protokolli AutoIP përcakton në mënyrë të pavarur adresën IP lokale të lidhjes, duke përdorur një skemë negocimi me hostet e tjerë dhe pa kontaktuar një server qendror.

Duke përdorur protokollin PPPoE

Shkurtesa PPPoE qëndron për Protokollin Point-to-Point mbi Ethernet. Ky protokoll përmbledh të dhënat për transmetim përmes një rrjeti Ethernet me një topologji të lidhur.

PPPoE është një specifikim për lidhjen e përdoruesve të Ethernet-it me internetin përmes një lidhjeje me brez të gjerë, si p.sh. një linjë abonenti dixhital me qira, një pajisje me valë ose një modem kabllor. Përdorimi i protokollit PPPoE dhe një modemi me brez të gjerë u siguron përdoruesve të rrjetit kompjuterik lokal akses individual dhe të vërtetuar në rrjetet e të dhënave me shpejtësi të lartë.

Protokolli PPPoE kombinon teknologjinë Ethernet me protokollin PPP, duke krijuar në mënyrë efektive një lidhje të veçantë me një server në distancë për çdo përdorues. Kontrolli i aksesit, llogaritja e lidhjes dhe zgjedhja e ofruesit të shërbimit përcaktohen për përdoruesit, jo për hostet. Avantazhi i kësaj qasjeje është se as kompania telefonike dhe as ofruesi i shërbimit të internetit nuk duhet të ofrojnë ndonjë mbështetje të veçantë për këtë.

Ndryshe nga lidhjet dial-up, lidhjet DSL dhe modem kabllor janë gjithmonë aktive. Për shkak se lidhja fizike me një ofrues shërbimi në distancë ndahet midis përdoruesve të shumtë, nevojitet një metodë kontabiliteti që regjistron dërguesit dhe destinacionet e trafikut dhe tarifon përdoruesit. Protokolli PPPoE lejon përdoruesin dhe hostin në distancë që po marrin pjesë në një seancë komunikimi të mësojnë adresat e rrjetit të njëri-tjetrit gjatë një shkëmbimi fillestar të quajtur zbulim(zbulim). Pasi të jetë krijuar një sesion ndërmjet një përdoruesi individual dhe një hosti të largët (p.sh., një ofrues shërbimi interneti), sesioni mund të monitorohet për qëllime akruale. Shumë shtëpi, hotele dhe korporata ofrojnë akses publik në internet përmes linjave dixhitale të pajtimtarëve duke përdorur teknologjinë Ethernet dhe protokollin PPPoE.

Një lidhje nëpërmjet protokollit PPPoE përbëhet nga një klient dhe një server. Klienti dhe serveri funksionojnë duke përdorur çdo ndërfaqe që është afër specifikimeve të Ethernet. Kjo ndërfaqe përdoret për të lëshuar adresa IP për klientët dhe për të lidhur ato adresa IP me përdoruesit dhe opsionalisht me stacionet e punës, në vend të vërtetimit vetëm të bazuar në stacionet e punës. Serveri PPPoE krijon një lidhje pikë-për-pikë për çdo klient.

Vendosja e një sesioni PPPoE

Për të krijuar një seancë PPPoE, duhet të përdorni shërbiminpppoed. Moduliio-pkt-*nOfron shërbime të protokollit PPPoE. Së pari ju duhet të vraponiio-pkt-*Meshofer i përshtatshëm. Shembull:

Udhëtimi përmes protokolleve të rrjetit.

TCP dhe UDP janë të dy protokolle të shtresës së transportit. UDP është një protokoll pa lidhje me shpërndarje të paketave jo të garantuara. TCP (Transmission Control Protocol) është një protokoll i orientuar drejt lidhjes me shpërndarje të garantuar të paketave. Së pari ka një shtrëngim duarsh (Përshëndetje. | Përshëndetje. | Le të bisedojmë? | Le të shkojmë.), pas së cilës lidhja konsiderohet e vendosur. Pastaj paketat dërgohen mbrapa dhe mbrapa mbi këtë lidhje (një bisedë është në zhvillim e sipër), dhe kontrollohet nëse paketa ka arritur te marrësi. Nëse paketa humbet, ose ka mbërritur, por me një kontroll të prishur, atëherë ajo dërgohet përsëri ("përsëris, nuk dëgjova"). Kështu, TCP është më i besueshëm, por është më kompleks nga pikëpamja e zbatimit dhe, në përputhje me rrethanat, kërkon më shumë cikle orësh / memorie, gjë që nuk është më pak e rëndësishme për mikrokontrolluesit. Shembuj të protokolleve të aplikacionit që përdorin TCP përfshijnë FTP, HTTP, SMTP dhe shumë të tjerë.

TL; DR

HTTP (Hypertext Transfer Protocol) është një protokoll aplikacioni me të cilin serveri dërgon faqe në shfletuesin tonë. HTTP tani përdoret gjerësisht në World Wide Web për të marrë informacion nga faqet e internetit. Fotografia tregon një llambë në një mikrokontrollues me një OS në bord, në të cilën ngjyrat vendosen përmes një shfletuesi.

Protokolli HTTP është i bazuar në tekst dhe mjaft i thjeshtë. Në fakt, kjo është se si duket metoda GET, e dërguar nga programi netcat në adresën lokale IPv6 të serverit me dritat:

~$ nc fe80::200:e2ff:fe58:b66b%mazko 80<

Metoda HTTP është zakonisht një fjalë e shkurtër angleze e shkruar me shkronja të mëdha dhe është e ndjeshme. Çdo server duhet të mbështesë të paktën metodat GET dhe HEAD. Përveç metodave GET dhe HEAD, shpesh përdoren metodat POST, PUT dhe DELETE. Metoda GET përdoret për të kërkuar përmbajtjen e një burimi të caktuar, në rastin tonë këtu GET /b HTTP/1.0 ku shtegu /b është përgjegjës për ngjyrën (blu). Përgjigja e serverit:

HTTP/1.0 200 OK Serveri: Contiki/2.4 http://www.sics.se/contiki/ Lidhja: mbyll Cache-Control: pa memorie, pa dyqan, duhet të rivlerësohet Pragma: pa memorie Skadon: 0 Përmbajtja- lloji: tekst/html

E kuqja është FAKTUAR

E gjelbërta është FAKT

Blu është AKTIV

Kodi i statusit (ne kemi 200) është pjesë e rreshtit të parë të përgjigjes së serverit. Është një numër i plotë treshifror. Shifra e parë tregon klasën e gjendjes. Kodi i përgjigjes zakonisht pasohet nga një frazë shpjeguese në anglisht e ndarë me një hapësirë, e cila i shpjegon personit arsyen e kësaj përgjigjeje të veçantë. Në rastin tonë, serveri funksionoi pa gabime, gjithçka ishte në rregull (OK).

Si kërkesa ashtu edhe përgjigja përmbajnë tituj (çdo rresht është një fushë e veçantë e kokës, çifti emër-vlerë ndahet me dy pika). Titujt përfundojnë me një vijë të zbrazët, pas së cilës të dhënat mund të pasojnë.

Shfletuesi im refuzon të hapë adresën lokale IPv6, kështu që një adresë shtesë shkruhet në firmware-in e mikrokontrolluesit dhe e njëjta prefiks gjithashtu duhet të caktohet në ndërfaqen e rrjetit virtual të simulatorit:

~$ sudo ip addr shtoni abcd::1/64 dev mazko # linux ~$ netsh ndërfaqe ipv6 vendos adresën mazko abcd::1 # windows ~$ curl http://

Aplikim klient-server në një prizë transmetimi TCP

Shembulli i mëposhtëm përdor TCP për të siguruar transmetime të rregullta dhe të besueshme të bajteve me dy drejtime. Le të ndërtojmë një aplikacion të plotë që përfshin një klient dhe një server. Së pari, ne demonstrojmë se si të ndërtojmë një server duke përdorur bazat e transmetimit TCP, dhe më pas një aplikacion klienti për të testuar serverin tonë.

Programi i mëposhtëm krijon një server që merr kërkesa për lidhje nga klientët. Serveri është ndërtuar në mënyrë sinkrone, prandaj, ekzekutimi i thread-it bllokohet derisa serveri të pranojë të lidhet me klientin. Ky aplikacion demonstron një server të thjeshtë që i përgjigjet një klienti. Klienti përfundon lidhjen duke dërguar një mesazh te serveri .

Serveri TCP

Krijimi i strukturës së serverit tregohet në diagramin funksional të mëposhtëm:

Këtu është kodi i plotë për programin SocketServer.cs:

// SocketServer.cs duke përdorur Sistemin; duke përdorur System.Text; duke përdorur System.Net; duke përdorur System.Net.Sockets; Hapësira e emrave SocketServer ( Programi i klasës ( i pavlefshëm statik Main (vargu args) ( // Cakto pikën fundore lokale për folenë IPHostEntry ipHost = Dns.GetHostEntry("localhost"); IPadresa ipAddr = ipHost.AddressList, IPEndipdr = newipEndipint 11000); // Krijo një prizë Tcp/IP Socket sListener = fole e re (ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp); // Cakto folenë në pikën përfundimtare lokale dhe dëgjo për prizat hyrëse (Bind). ipEndPoint); sListener. Listen(10); // Filloni të dëgjoni për lidhje ndërsa (vërtetë) (Console.WriteLine("Duke pritur për një lidhje në portin (0)", ipEndPoint); // Programi ndalon, duke pritur për një lidhje hyrëse Trajtuesi i folesë = sListener.Accept(); të dhënat e vargut = null; // Ne pritëm që klienti të përpiqet të lidhet me ne bajt bajt = bajt i ri; int bytesRec = mbajtës.Marrë (bajtë); të dhëna += kodim. UTF8.GetString(bytes, 0, bytesRec); // Shfaq të dhënat në tastierë Console.Write("Teksti i marrë: " + të dhëna + "\n\n"); // Dërgo një përgjigje klientit\ string reply = "Faleminderit për kërkesën në " + data.Length.ToString() + " karaktere"; byte msg = Encoding.UTF8.GetBytes(përgjigje); mbajtës.Dërgo(msg); nëse (të dhënat.IndexOf(" ") > -1) ( Console.WriteLine ("Serveri ka përfunduar lidhjen me klientin."); break; ) handler.Shutdown(SocketShutdown.Both); handler.Close(); ) ) catch (Exception ex) ( Console.WriteLine (p.sh.ToString()); ) në fund ( Console.ReadLine (); ) ) )

Le të shohim strukturën e këtij programi.

Hapi i parë është vendosja e prizës në një pikë fundore lokale. Përpara se të hapni një prizë për të dëgjuar lidhjet, duhet të përgatisni një adresë të pikës fundore lokale për të. Një adresë unike e shërbimit TCP/IP përcaktohet nga kombinimi i adresës IP të hostit me numrin e portit të shërbimit, i cili krijon pikën përfundimtare të shërbimit.

Klasa Dns ofron metoda që kthejnë informacion në lidhje me adresat e rrjetit të mbështetur nga një pajisje në rrjetin lokal. Nëse një pajisje LAN ka më shumë se një adresë rrjeti, klasa Dns kthen informacion për të gjitha adresat e rrjetit dhe aplikacioni duhet të zgjedhë adresën e duhur për të shërbyer nga grupi.

Le të krijojmë një IPendPoint për serverin duke kombinuar adresën e parë IP të kompjuterit pritës të marrë nga metoda Dns.Resolve() me numrin e portit:

IPHostEntry ipHost = Dns.GetHostEntry("localhost"); IPadresa ipAddr = ipHost.Lista e Adresave; IPEndPoint ipEndPoint = IPEndPoint i ri(ipAddr, 11000);

Këtu klasa IPEndPoint përfaqëson localhost në portin 11000. Më pas, ne krijojmë një prizë transmetimi me një shembull të ri të klasës Socket. Pasi të kemi vendosur një pikë përfundimtare lokale për të dëgjuar lidhjet, ne mund të krijojmë një prizë:

Socket sListener = Socket i ri (ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp);

Transferimi Adresa e Familjes specifikon skemat e adresimit që një shembull i klasës Socket mund të përdorë për të zgjidhur një adresë.

Në parametrin SocketType Prizat TCP dhe UDP janë të ndryshme. Në të mund të përcaktoni, ndër të tjera, vlerat e mëposhtme:

Dgram

Mbështet datagramet. Vlera Dgram kërkon që Udp të specifikohet për llojin e protokollit dhe InterNetwork në parametrin e familjes së adresave.

Të papërpunuara

Mbështet aksesin në protokollin themelor të transportit.

Transmeto

Mbështet prizat e transmetimit. Vlera Stream kërkon që Tcp të specifikohet për llojin e protokollit.

Parametri i tretë dhe i fundit specifikon llojin e protokollit të kërkuar për folenë. Në parametrin Lloji i Protokollit Ju mund të specifikoni vlerat e mëposhtme më të rëndësishme - Tcp, Udp, Ip, Raw.

Hapi tjetër duhet të jetë caktimi i prizës duke përdorur metodën Lidh (). Kur një fole hapet nga një konstruktor, nuk i caktohet një emër, rezervohet vetëm një dorezë. Metoda Bind() thirret për të caktuar një emër në prizën e serverit. Në mënyrë që një prizë klienti të identifikojë një prizë të transmetimit TCP, programi i serverit duhet t'i japë prizës së tij një emër:

SListener.Bind(ipEndPoint);

Metoda Bind() lidh një fole me një pikë fundore lokale. Metoda Bind() duhet të thirret përpara çdo përpjekjeje për të thirrur metodat Listen() dhe Accept().

Tani, pasi të keni krijuar një prizë dhe të keni lidhur një emër me të, mund të dëgjoni mesazhet hyrëse duke përdorur metodën Dëgjo (). Në gjendjen e dëgjimit, priza do të dëgjojë për përpjekjet hyrëse të lidhjes:

SListener.Listen(10);

Parametri përcakton të prapambetura, duke treguar numrin maksimal të lidhjeve që presin në radhë. Në kodin e mësipërm, vlera e parametrit lejon deri në dhjetë lidhje të grumbullohen në radhë.

Në gjendjen e dëgjimit, duhet të jeni gati të pranoni të lidheni me klientin, për të cilin përdoret metoda Prano (). Kjo metodë siguron një lidhje klienti dhe plotëson lidhjen e emrit të klientit dhe serverit. Metoda Accept() bllokon thread-in e programit thirrës derisa të arrijë një lidhje.

Metoda Accept() heq kërkesën e parë të lidhjes nga radha e kërkesave në pritje dhe krijon një fole të re për ta përpunuar atë. Megjithëse krijohet një prizë e re, priza origjinale vazhdon të dëgjojë dhe mund të përdoret me multi-threading për të pranuar kërkesa të shumta lidhjeje nga klientët. Asnjë aplikacion serveri nuk duhet të mbyllë një prizë dëgjimi. Duhet të vazhdojë të punojë së bashku me bazat e krijuara nga metoda Prano për të përpunuar kërkesat hyrëse të klientit.

Ndërsa (e vërtetë) (Console.WriteLine ("Pritja e një lidhjeje në portin (0)", ipEndPoint); // Programi ndalon ndërsa pret për një lidhje hyrëse Mbajtës i socket = sListener.Accept();

Pasi klienti dhe serveri të kenë krijuar një lidhje me njëri-tjetrin, mesazhet mund të dërgohen dhe merren duke përdorur metodat Dërgo () Dhe Merre () Socket e klasës.

Metoda Send() shkruan të dhënat dalëse në prizën e lidhur. Metoda Receive() lexon të dhënat hyrëse në prizën e transmetimit. Kur përdorni një sistem të bazuar në TCP, duhet të krijohet një lidhje midis prizave përpara se të ekzekutoni metodat Send() dhe Receive(). Protokolli i saktë midis dy entiteteve komunikuese duhet të përcaktohet paraprakisht në mënyrë që aplikacionet e klientit dhe serverit të mos bllokojnë njëri-tjetrin duke mos ditur se kush duhet t'i dërgojë më parë të dhënat e tyre.

Kur të përfundojë shkëmbimi i të dhënave midis serverit dhe klientit, duhet të mbyllni lidhjen duke përdorur metodat Fike() Dhe Mbylle ():

Handler.Shutdown(SocketShutdown.Both); mbajtës.Close();

SocketShutdown është një numër që përmban tre vlera për të ndaluar: te dyja- ndalon dërgimin dhe marrjen e të dhënave nga priza, Merrni- ndalon prizën të marrë të dhëna dhe Dërgo- ndalon dërgimin e të dhënave nga priza.

Socket mbyllet duke thirrur metodën Close(), e cila gjithashtu vendos vetinë Connected të folesë në false.

Klienti TCP

Funksionet që përdoren për të krijuar një aplikacion klienti janë pak a shumë të ngjashëm me një aplikacion serveri. Ashtu si me serverin, të njëjtat metoda përdoren për të përcaktuar pikën përfundimtare, për të instancuar prizën, për të dërguar dhe marrë të dhëna dhe për të mbyllur folenë.