TCP se prirodno integriše u okruženje klijent/server (pogledajte sliku 10.1). Serverska aplikacija bubice(slušati) dolazne zahtjeve za povezivanje. Na primjer, usluge WWW, prijenosa datoteka ili pristupa terminalu slušaju zahtjeve klijenata. Komunikaciju u TCP-u pokreću odgovarajući potprogrami koji pokreću vezu sa serverom (pogledajte Poglavlje 21 o API-ju utičnice).

Rice. 10.1. Klijent poziva server.

U stvarnosti, klijent može biti drugi server. Na primjer, mail serveri se mogu povezati sa drugim serverima e-pošte za slanje e-poruka između računara.

10.2 TCP koncepti

U kom obliku aplikacije trebaju slati podatke u TCP-u? Kako TCP prenosi podatke na IP? Kako prenosni i prijemni TCP protokoli identifikuju vezu između aplikacije i elemente podataka koji su potrebni za njenu implementaciju? Na sva ova pitanja odgovoreno je u sljedećim odjeljcima, koji opisuju osnovne koncepte TCP-a.

10.2.1 Ulazni i izlazni tokovi podataka

Konceptualno model povezivanja pretpostavlja da aplikacija šalje tok podataka ravnopravnoj aplikaciji. U isto vrijeme, sposoban je primati tok podataka od svog partnera za vezu. TCP pruža full duplex(full duplex) način rada u kojem oba dva toka podataka (vidi sliku 10.2).

Rice. 10.2. Aplikacije razmjenjuju tokove podataka.

10.2.2 Segmenti

TCP može pretvoriti odlazni tok podataka iz aplikacije u oblik pogodan za postavljanje u datagrame. Kako?

Aplikacija šalje podatke na TCP, a ovaj protokol ih stavlja izlazni bafer(bafer za slanje). Zatim TCP izrezuje dijelove podataka iz međuspremnika i šalje ih, dodajući zaglavlje (u ovom slučaju, segmentima segment). Na sl. 10.3 pokazuje kako podaci iz izlazni bafer TCP-ovi su pakirani u segmente. TCP prosljeđuje segment na IP za isporuku kao jedan datagram. Pakovanje podataka u komade ispravne dužine osigurava efikasno prosljeđivanje, tako da će TCP čekati dok se odgovarajuća količina podataka ne nađe u izlaznom baferu prije kreiranja segmenta.

Rice. 10.3 Kreiranje TCP segmenta

10.2.3 Guranje

Međutim, velike količine podataka često nisu primjenjive na aplikacije u stvarnom svijetu. Na primjer, kada klijentski program krajnjeg korisnika započne interaktivnu sesiju s udaljenim serverom, korisnik tada samo unosi naredbe (slijeđeno pritiskom na povratak).

Korisnikovom klijentskom programu je potreban TCP da zna da se podaci šalju udaljenom hostu i da odmah izvrši ovu operaciju. U ovom slučaju se koristi ekstruzija(gurnuti).

Ako pogledate operacije u interaktivnoj sesiji, možete pronaći mnogo segmenata sa malo podataka, a štaviše, iskakanje se može naći u gotovo svakom segmentu podataka. Međutim, iskakanje ne bi trebalo da se koristi tokom prenosa datoteka (osim za poslednji segment), a TCP će moći najefikasnije da spakuje podatke u segmente.

10.2.4 Hitni podaci

Model prosljeđivanja podataka aplikacije pretpostavlja uređeni tok bajtova na svom putu do odredišta. Ponovo se pozivajući na primjer interaktivne sesije, pretpostavimo da je korisnik pritisnuo tipku pažnju(pažnja) ili break(prekid). Udaljena aplikacija mora biti u mogućnosti da preskoči bajtove koji ometaju i odgovori na pritisak na tipku što je prije moguće.

Mehanizam hitni podaci(hitni podaci) označava posebne informacije u segmentu kao hitno. Ovim TCP govori svom ravnopravnom uređaju da segment sadrži hitne podatke i može naznačiti gdje se nalazi. Partner bi trebao proslijediti ovu informaciju odredišnoj aplikaciji što je prije moguće.

10.2.5 Portovi aplikacije

Klijent mora identificirati uslugu kojoj želi pristupiti. Ovo se radi kroz specifikaciju IP adrese host servisa i broja njegovog TCP porta. Kao i kod UDP-a, brojevi TCP portova se kreću od 0 do 65535. Portovi od 0 do 1023 poznati su kao dobro poznati portovi i koriste se za pristup standardnim uslugama.

Nekoliko primjera dobro poznatih portova i njihovih odgovarajućih aplikacija prikazano je u Tabeli 10.1. Usluge Odbaci(luka 9) i naplaćeno(port 19) su TCP verzije usluga koje već poznajemo iz UDP-a. Imajte na umu da je promet na TCP portu 9 potpuno izoliran od prometa na UDP portu 9.

Tabela 10.1 Dobro poznati TCP portovi i njihove odgovarajuće aplikacije

Luka	Dodatak	Opis
9	Odbaci	Otkažite sve dolazne podatke
19	naplaćeno	Generator znakova. Razmjena tokova karaktera
20	FTP podaci	FTP port za prosljeđivanje
21	FTP	Port za FTP dijalog
23	TELNET	Port za udaljenu prijavu preko Telneta
25	SMTP	Port SMTP protokola
110	POP3	Usluga uzorkovanja pošte za personalni računar
119	NNTP	Pristup online vijestima

Šta je sa portovima koje koriste klijenti? U rijetkim slučajevima, klijent ne radi na dobro poznatom portu. Ali u takvim situacijama, želeći da otvori vezu, često traži od operativnog sistema da mu dodijeli neiskorišteni i nerezervisani port. Na kraju veze, klijent mora vratiti ovaj port nazad, nakon čega drugi klijent može ponovo koristiti port. Budući da postoji preko 63.000 TCP portova u nerezerviranom skupu brojeva, ograničenja portova klijenta mogu se zanemariti.

10.2.6 adrese utičnica

Kao što već znamo, kombinacija IP adrese i porta za komunikaciju se zove adresa utičnice. TCP veza je u potpunosti identificirana adresom utičnice na svakom kraju te veze. Na sl. Slika 10.4 prikazuje vezu između klijenta sa adresom utičnice (128.36.1.24, port = 3358) i servera sa adresom utičnice (130.42.88.22, port = 21).

Rice. 10.4. adrese utičnice

Zaglavlje svakog datagrama sadrži izvornu i odredišnu IP adresu. U nastavku ćete vidjeti da su brojevi izvornog i odredišnog porta navedeni u zaglavlju TCP segmenta.

Obično je server sposoban upravljati više klijenata u isto vrijeme. Jedinstvene adrese utičnice servera se dodeljuju istovremeno svim njegovim klijentima (pogledajte sliku 10.5).

Rice. 10.5. Više klijenata povezanih na adrese serverskih utičnica

Pošto datagram sadrži segment TCP veze identifikovan IP adresama i portovima, serveru je vrlo lako da prati višestruke veze sa klijentima.

10.3 TCP mehanizam pouzdanosti

U ovom odeljku ćemo pogledati TCP mehanizam koji se koristi za pouzdanu isporuku podataka uz očuvanje naloga za prosleđivanje i izbegavanje gubitka ili dupliranja.

10.3.1 Numeracija i potvrda

TCP koristi numeriranje i potvrdu (ACK) kako bi osigurao pouzdan prijenos podataka. Šema TCP numeriranja je pomalo neobična: svaki proslijeđen preko veze oktet smatra se da ima serijski broj. Zaglavlje TCP segmenta sadrži redni broj prvi oktet podataka ovog segmenta.

Od primaoca se traži da potvrdi prijem podataka. Ako ACK ne stigne unutar vremenskog intervala, podaci se ponovo prenose. Ova metoda se zove pozitivna potvrda sa relejem(pozitivna potvrda sa retransmicijom).

Prijemnik TCP podataka vrši strogu provjeru dolaznih brojeva sekvence kako bi provjerio sekvencu u kojoj su podaci primljeni i da nema izgubljenih dijelova. Pošto ACK može biti nasumično izgubljen ili odložen, dupli segmenti mogu stići do prijemnika. Brojevi sekvence vam omogućavaju da odredite dupliciranje podataka, koji se zatim odbacuju.

Na sl. Slika 10.6 prikazuje pojednostavljeni prikaz vremenskog ograničenja i ponovnog prijenosa u TCP-u.

Rice. 10.6. Vremensko ograničenje i ponovni prijenos u TCP-u

10.3.2 Port, sekvenca i ACK polja u TCP zaglavlju

Kao što je prikazano na sl. 10.7, prvih nekoliko polja TCP zaglavlja pruža prostor za vrijednosti izvornog i odredišnog porta, redni broj prvog bajta ugrađenih podataka i ACK jednak broju sekvence sljedeći bajt koji se očekuje na drugom kraju. Drugim riječima, ako TCP primi sve bajtove do 30 od svog ravnopravnog partnera, ovo polje će imati vrijednost 31, što ukazuje na segment koji treba proslijediti sljedeći.

Rice. 10.7. Početne vrijednosti u poljima TCP zaglavlja

Treba napomenuti jedan mali detalj. Pretpostavimo da je TCP poslao bajtove od 1 do 50 i da nema više podataka za slanje. Ako su podaci primljeni od ravnopravnog partnera, TCP mora potvrditi prijem slanjem zaglavlja bez priloženih podataka. Naravno, ACK vrijednost je prisutna u ovom zaglavlju. U polju sekvence - vrijednost 51, tj. sljedeći broj bajta namjerava poslati TCP. Kada TCP pošalje sljedeće podatke, novo TCP zaglavlje će također imati vrijednost 51 u polju sekvence.

10.4 Uspostavljanje veze

Kako su dvije aplikacije povezane? Prije komunikacije, svaki od njih poziva potprogram kako bi formirao blok memorije koji će se koristiti za pohranjivanje TCP i IP parametara ove veze, kao što su adrese utičnice, trenutni redni broj, početna vrijednost životnog vijeka itd.

Serverska aplikacija čeka da se pojavi klijent, koji, želeći pristupiti serveru, izdaje zahtjev spoj(povezivanje) identificiranje IP adrese i porta servera.

Postoji jedna tehnička karakteristika. Svaka strana počinje numerisati svaki bajt ne od jednog, već od nasumični serijski broj(Kasnije ćemo vidjeti zašto se to radi.) Originalna specifikacija savjetuje da se generira početni broj sekvence na osnovu 32-bitnog vanjskog tajmera koji se povećava otprilike svakih 4 µs.

10.4.1 Skripta za povezivanje

Postupak povezivanja se često naziva trosmjernim rukovanjem, budući da se za uspostavljanje veze razmjenjuju tri poruke - SYN, SYN i ACK.

Tokom uspostavljanja veze, partneri razmenjuju tri važne informacije:

1. Količina međuspremnika za prijem podataka

2. Maksimalna količina podataka koja se prenosi u dolaznom segmentu

3. Početni redni broj koji se koristi za odlazne podatke

Imajte na umu da svaka strana koristi operacije 1 i 2 za označavanje granice do kojih će druga strana djelovati. Lični računar može imati mali bafer za prijem, dok superračunar može imati ogroman bafer. Memorijska struktura personalnog računara može ograničiti dolazne delove podataka na 1 KB, a superkompjuter se kontroliše velikim segmentima.

Mogućnost kontrole načina na koji druga strana šalje podatke je važna karakteristika koja čini TCP/IP skalabilnim.

Na sl. Slika 10.8 prikazuje primjer skripte za povezivanje. Dati su vrlo jednostavni početni redni brojevi kako ne bi preopteretili figuru. Imajte na umu da na ovoj slici klijent može primiti veće segmente od servera.

Rice. 10.8. Uspostavljanje veze

Izvode se sljedeće operacije:

1. Server se inicijalizira i postaje spreman za povezivanje s klijentima (ovo stanje se naziva pasivno otvoreno - pasivno otvoreno).

2. Klijent traži od TCP-a da otvori vezu sa serverom na navedenoj IP adresi i portu (ovo stanje se naziva aktivno otvoreno).

3. TCP klijenta prima početni redni broj (1000 u ovom primjeru) i šalje vremenski segment(sinhroniziraj segment - SYN). U ovom segmentu se šalje redni broj, veličina prozora za prijem (4K) i veličina najvećeg segmenta koji klijent može primiti (1460 bajtova).

4. Kada stigne SYN, server TCP prima moj početni redni broj (3000). Šalje SYN segment koji sadrži početni broj sekvence (3000), ACK 1001 (što znači numerisanje prvog bajta koji je klijent poslao kao 1001), veličinu prozora za prijem (4K) i veličinu najvećeg segmenta koji server može primiti (1024 bajtova).

5. Klijentski TCP, nakon što je primio SYN/ACK poruku od servera, šalje nazad ACK 3001 (prvi bajt podataka koje šalje server treba da bude numerisan kao 3001).

6. Klijent TCP govori svojoj aplikaciji da otvori vezu.

7. Server TCP, nakon što je primio ACK poruku od klijentskog TCP-a, obavještava svoju aplikaciju da je veza otvorena.

Klijent i server objavljuju svoja pravila za primljene podatke, sinhronizuju svoje redne brojeve i postaju spremni za razmenu podataka. TCP specifikacija također dozvoljava drugi scenario (ne baš dobar) gdje se ravnopravne aplikacije aktivno otvaraju jedna drugu u isto vrijeme.

10.4.2 Postavljanje vrijednosti IP parametara

Zahtjev aplikacije za uspostavljanje veze također može specificirati parametre za IP datagrame koji će nositi podatke veze. Ako nije navedena specifična vrijednost parametra, koristi se zadana vrijednost.

Na primjer, aplikacija može odabrati željenu vrijednost za IP prioritet ili tip usluge. Budući da svaka od povezanih strana samostalno postavlja svoj prioritet i vrstu usluge, teoretski se ove vrijednosti mogu razlikovati za različite smjerove tokova podataka. U pravilu, u praksi se primjenjuju iste vrijednosti za svaki smjer razmjene.

Kada aplikacija koristi vladine ili vojne sigurnosne opcije, svaka krajnja tačka veze mora koristiti iste nivoe sigurnosti ili veza neće uspjeti.

10.5 Prosljeđivanje podataka

Prijenos podataka počinje nakon završetka potvrde stvaranja veze u tri koraka (vidi sliku 10.9). TCP standard omogućava da se normalni podaci uključe u segmente potvrde, ali neće biti isporučeni aplikaciji dok se veza ne završi. Da bi se pojednostavilo numerisanje, koriste se poruke od 1000 bajta. Svaki segment TCP zaglavlja ima ACK polje koje identifikuje redni broj bajta za koji se očekuje da će biti primljen od partnera u vezi..

Rice. 10.9. Jednostavan protok podataka i ACK

Prvi segment koji šalje klijent sadrži bajtove od 1001 do 2000. Njegovo ACK polje mora sadržavati vrijednost 3001, što označava redni broj bajta koji bi trebao biti primljen od servera.

Server odgovara klijentu segmentom koji sadrži 1000 bajtova podataka (počevši od broja 3001). Njegovo ACK polje u TCP zaglavlju će pokazati da su bajtovi od 1001 do 2000 već uspješno primljeni, tako da bi sljedeći očekivani redni broj segmenta od klijenta trebao biti 2001.

Klijent tada šalje segmente koji počinju sa bajtovima 2001, 3001 i 4001 tim redosledom. Imajte na umu da klijent ne očekuje ACK nakon svakog poslanog segmenta. Podaci se šalju ravnopravnom uređaju sve dok se njegov međuspremnik ne napuni (u nastavku ćemo vidjeti da prijemnik može vrlo precizno odrediti količinu podataka koji će mu se poslati).

Server čuva propusni opseg veze korištenjem jednog ACK-a da naznači da su svi segmenti uspješno proslijeđeni.

Na sl. Slika 10.10 prikazuje prosljeđivanje podataka kada se izgubi prvi segment. Kada istekne vremensko ograničenje, segment se ponovo šalje. Imajte na umu da po prijemu izgubljenog segmenta, primalac šalje jedan ACK koji potvrđuje prosljeđivanje oba segmenta.

Rice. 10.10. Gubitak podataka i ponovni prijenos

10.6 Zatvaranje veze

Normalno prekidanje veze se izvodi pomoću iste procedure trostrukog rukovanja kao prilikom otvaranja veze. Svaka strana može započeti zatvaranje veze u sljedećem scenariju:

O:

B:"Dobro".

V:"I ja sam završio posao."

O:"Dobro".

Sljedeći scenario je također prihvatljiv (iako se koristi izuzetno rijetko):

O:"Završio sam posao. Nemam više podataka za slanje."

V:“Dobro. Međutim, postoje podaci…”

V:"I ja sam završio posao."

O:"Dobro".

U primjeru ispod, veza zatvara server, kao što je često slučaj za komunikaciju klijent/server. U ovom slučaju, nakon što korisnik uđe u sesiju telnet naredba za odjavu (odjava sa sistema) server pokreće zahtjev za zatvaranje veze. U situaciji prikazanoj na sl. 10.11, izvode se sljedeće radnje:

1. Aplikacija na serveru govori TCP-u da zatvori vezu.

2. Server TCP šalje završni segment (FIN), obavještavajući svog partnera da nema više podataka za slanje.

3. TCP klijenta šalje ACK na FIN segment.

4. TCP klijenta govori svojoj aplikaciji da server želi da zatvori vezu.

5. Klijentska aplikacija obavještava svoj TCP da je veza zatvorena.

6. TCP klijenta šalje FIN poruku.

7. Server TCP prima FIN od klijenta i odgovara ACK porukom.

8. TCP servera govori svojoj aplikaciji da zatvori vezu.

Rice. 10.11. Zatvaranje veze

Obje strane mogu započeti zatvaranje u isto vrijeme. U ovom slučaju, normalno zatvaranje veze je završeno nakon što svaki od vršnjaka pošalje ACK poruku.

10.6.1 Nagli prekid

Svaka strana može zatražiti nagli prekid veze. Ovo je prihvatljivo kada aplikacija želi prekinuti vezu ili kada TCP otkrije ozbiljan problem u komunikaciji koji ne može riješiti sama. Nagli prekid se zahteva slanjem jedne ili više poruka za resetovanje ravnopravnom uređaju, kao što je naznačeno specifičnom zastavicom u TCP zaglavlju.

10.7 Kontrola protoka

TCP prijemnik se učitava sa dolaznim tokom podataka i određuje koliko informacija može prihvatiti. Ovo ograničenje utiče na TCP pošiljaoca. Sljedeće objašnjenje ovog mehanizma je konceptualno, a programeri ga mogu drugačije implementirati u svoje proizvode.

Tokom postavljanja veze, svaki ravnopravni partner dodjeljuje prostor za ulazni bafer veze i obavještava drugu stranu o tome. Tipično, veličina bafera se izražava kao cijeli broj maksimalnih veličina segmenta.

Tok podataka ulazi u ulazni bafer i tamo se pohranjuje do prosljeđivanja aplikaciji (određuje TCP port). Na sl. Slika 10-12 prikazuje ulazni bafer koji može zauzeti 4 KB.

Rice. 10.12. Prozor za primanje ulaznog bafera

Prostor bafera se popunjava kako podaci pristižu. Kada aplikacija primateljica povuče podatke iz bafera, oslobođeni prostor postaje dostupan za nove dolazne podatke.

10.7.1 Prozor za prijem

prozor za prijem(prozor za prijem) - bilo koji prostor u ulaznom baferu koji već nije zauzet podacima. Podaci ostaju u ulaznom međuspremniku sve dok ih ciljna aplikacija ne iskoristi. Zašto aplikacija ne prikuplja podatke odmah?

Jednostavan scenario će vam pomoći da odgovorite na ovo pitanje. Pretpostavimo da je klijent uploadovao datoteku na FTP server koji radi na veoma zauzetom računaru sa više korisnika. FTP program tada mora pročitati podatke iz bafera i zapisati ih na disk. Kada server izvodi I/O operacije diska, program čeka da se te operacije završe. U ovom trenutku može se pokrenuti drugi program (na primjer, prema rasporedu) i do trenutka kada se FTP program ponovo pokrene, sljedeći podaci će već biti u međuspremniku.

Prozor prijema se proširuje od posljednjeg potvrđenog bajta do kraja bafera. Na sl. 10.12, cijeli bafer je prvo dostupan, pa je stoga dostupan 4K prozor za prijem. Kada stigne prvi KB, prozor za prijem će se smanjiti na 3 KB (radi jednostavnosti, pretpostavićemo da je svaki segment veličine 1 KB, iako u praksi ova vrijednost varira ovisno o potrebama aplikacije). Dolazak sljedeća dva 1K segmenta će smanjiti prozor prijema na 1K.

Svaki ACK koji šalje prijemnik sadrži informaciju o trenutnom stanju prijemnog prozora, u zavisnosti od toga koji je protok podataka iz izvora regulisan.

Većinom se veličina ulaznog bafera postavlja u vrijeme pokretanja veze, iako TCP standard ne specificira kako se upravlja ovim baferom. Ulazni bafer se može povećati ili smanjiti kako bi pošiljaocu pružio povratnu informaciju.

Šta se dešava ako se dolazni segment može postaviti u prozor za prijem, ali ne stigne? Općenito se pretpostavlja da sve implementacije pohranjuju dolazne podatke u prozor za primanje i šalju potvrdu (ACK) samo za cijeli uzastopni blok od nekoliko segmenata. Ovo je ispravan način, jer će u suprotnom odbacivanje podataka koji nisu u redu značajno smanjiti performanse.

10.7.2 Pošalji prozor

Sistem koji prenosi podatke mora pratiti dvije karakteristike: koliko podataka je već poslano i potvrđeno, i trenutnu veličinu prijemnog prozora prijemnika. Aktivan slanje prostora(razmak za slanje) Proširuje se od prvog neprijavljenog okteta lijevo od trenutnog prozora primanja. dio prozor korišteno poslati, označava koliko dodatnih podataka može biti poslano partneru.

Početni redni broj i početna veličina prozora za prijem se postavljaju tokom podešavanja veze. Rice. 10.13 ilustruje neke od karakteristika mehanizma za prenos podataka.

1. Pošiljalac počinje sa prozorom za slanje od 4 KB.

2. Pošiljalac šalje 1 KB. Kopija ovih podataka se čuva sve dok se ne primi potvrda (ACK), jer će možda biti potrebno ponovno prenijeti.

3. Stiže ACK za prvi KB, a sljedeća 2 KB podataka se šalju. Rezultat je prikazan u trećem dijelu od vrha Sl. 10.13. Pohrana od 2 KB se nastavlja.

4. Konačno, ACK stiže za sve prenesene podatke (tj. sve primljene od strane primaoca). ACK vraća veličinu prozora za slanje na 4 KB.

Rice. 10.13. Pošalji prozor

Treba istaći nekoliko zanimljivih karakteristika:

■ Pošiljalac ne čeka ACK za svaki segment podataka koji šalje. Jedino ograničenje prijenosa je veličina prozora za primanje (na primjer, pošiljalac mora prenijeti samo 4K jednobajtne segmente).

■ Pretpostavimo da pošiljalac šalje podatke u nekoliko vrlo kratkih segmenata (na primjer, 80 bajtova). U ovom slučaju, podaci se mogu preformatirati za efikasniji prijenos (npr. u jedan segment).

10.8 TCP zaglavlje

Na sl. Slika 10.14 prikazuje format segmenta (TCP zaglavlje i podaci). Zaglavlje počinje ID-ovima izvornog i odredišnog porta. Sljedeće polje serijski broj(redni broj) označava poziciju u odlaznom toku podataka koju ovaj segment zauzima. Polje ACK(potvrda) sadrži informacije o očekivanom sljedećem segmentu koji bi se trebao pojaviti u toku ulaznih podataka.

Rice. 10.14. TCP segment

Postoji šest zastava:

Polje pomaci podataka(Odstupanje podataka) sadrži veličinu TCP zaglavlja u 32-bitnim riječima. TCP zaglavlje mora završavati na 32-bitnoj granici.

10.8.1 Opcija maksimalne veličine segmenta

Parametar "maksimalna veličina segmenta"(maksimalna veličina segmenta - MSS) se koristi za deklarisanje najvećeg podatka koji sistem može primiti i obraditi. Međutim, naslov je pomalo netačan. Obično u TCP-u segment tretira se kao zaglavlje plus podaci. ali maksimalna veličina segmenta definirano kao:

Veličina najvećeg datagrama koji se može primiti je 40

Drugim riječima, MSS odražava najveće nosivost na prijemniku kada su TCP i IP zaglavlja dugačka 20 bajtova. Ako postoje dodatni parametri, njihovu dužinu treba oduzeti od ukupne veličine. Stoga je količina podataka koja se može poslati u segmentu definirana kao:

Deklarisana MSS vrijednost + 40 - (zbir dužina TCP i IP zaglavlja)

Tipično, ravnopravni korisnici razmjenjuju MSS vrijednosti u početnim SYN porukama kada je veza otvorena. Ako sistem ne oglašava maksimalnu veličinu segmenta, koristi se zadana vrijednost od 536 bajtova.

Maksimalna veličina segmenta je kodirana sa 2-bajtnom preambulom praćenom vrijednošću od 2 bajta, tj. najveća vrijednost bi bila 2 16 -1 (65.535 bajtova).

MSS nameće tvrdo ograničenje na podatke koji se šalju na TCP: prijemnik neće moći obraditi velike vrijednosti. Međutim, pošiljalac koristi segmente manja veličina budući da je veličina MTU duž rute također određena za vezu.

10.8.2 Upotreba polja zaglavlja u zahtjevu za povezivanje

Prvi segment poslan za otvaranje veze ima SYN zastavicu 1 i ACK zastavicu 0. Početni SYN je jedini segment koji ima ACK polje 0. Imajte na umu da sigurnost koristi ovu funkciju za otkrivanje dolaznih zahtjeva za TCP sesiju.

Polje serijski broj sadrži početni redni broj(početni redni broj), polje prozor - početna veličina prozor za prijem. Jedina trenutno definisana TCP postavka je maksimalna veličina segmenta (kada nije navedena, koristi se zadana vrijednost od 536 bajtova) koju TCP treba da primi. Ova vrijednost je duga 32 bita i obično je prisutna u zahtjevu za povezivanje u polju opcije(Opcija). Dužina TCP zaglavlja koje sadrži MSS vrijednost je 24 bajta.

10.8.3 Korištenje polja zaglavlja u odgovoru na vezu

U odobrenju odgovora na zahtjev za povezivanje, obje zastavice (SYN i ACK) su postavljene na 1. Sistem koji odgovara pokazuje početni broj sekvence u odgovarajućem polju i veličinu prozora za prijem u polju Prozor. Maksimalna veličina segmenta koju primalac želi da koristi obično se nalazi u odgovoru na vezu (u opcije). Ova vrijednost može se razlikovati od vrijednosti strane koja traži vezu, tj. mogu se koristiti dvije različite vrijednosti.

Zahtjev za povezivanje može se odbiti specificiranjem zastavice za resetiranje (RST) sa vrijednošću 1 u odgovoru.

10.8.4 Odabir početnog rednog broja

TCP specifikacija pretpostavlja da tokom uspostavljanja veze svaka strana bira početni redni broj(zasnovano na trenutnoj vrijednosti 32-bitnog internog tajmera). Kako se to radi?

Zamislite šta se dešava kada se sistem sruši. Pretpostavimo da je korisnik otvorio vezu neposredno prije pada i poslao malu količinu podataka. Nakon oporavka, sistem više ne pamti ništa što je urađeno prije pada, uključujući veze koje su već pokrenute i dodijeljene brojeve portova. Korisnik ponovo uspostavlja vezu. Brojevi portova se ne podudaraju s originalnim dodjelama, a neki od njih možda već koriste druge veze uspostavljene nekoliko sekundi prije pada.

Dakle, druga strana na samom kraju veze možda neće biti svjesna da je njen partner prošao kroz pad i da je potom obnovljen. Sve će to dovesti do ozbiljnih poremećaja, posebno kada prođe dosta vremena dok stari podaci ne prođu kroz mrežu i pomiješaju se s podacima iz novostvorene veze. Odabir tajmera za početak s ažuriranjem (novi početak) eliminira takve probleme. Stari podaci će imati različitu numeraciju od raspona brojeva sekvence nove veze. Hakeri, kada lažiraju izvornu IP adresu za pouzdanog hosta, pokušavaju da dobiju pristup računarima navodeći predvidljivi početni broj sekvence u poruci. Kriptografska hash funkcija zasnovana na internim ključevima je najbolji način za odabir sigurnih početnih brojeva.

10.8.5 Uobičajena upotreba polja

Prilikom pripreme TCP zaglavlja za prijenos, u polju se navodi redni broj prvog okteta prenesenih podataka serijski broj(redni broj).

U polje se upisuje broj sljedećeg okteta koji se očekuje od partnera za povezivanje potvrda(Broj potvrde) kada je ACK bit postavljen na 1. Polje prozor(Prozor) je za trenutnu veličinu prozora za prijem. Ovo polje sadrži broj bajtova iz broja potvrde koji se može prihvatiti. Imajte na umu da ova vrijednost omogućava preciznu kontrolu toka podataka. Sa ovom vrijednošću, ravnopravni uređaj pokazuje stvarno stanje prijemnog prozora tokom sesije razmjene.

Ako aplikacija ukazuje na TCP push operaciju, tada je PUSH zastavica postavljena na 1. TCP koji prima MORA odgovoriti na ovu zastavicu brzom isporukom podataka aplikaciji čim ih pošiljatelj želi proslijediti.

Oznaka URGENT, ako je postavljena na 1, podrazumijeva hitan prijenos podataka, a odgovarajući pokazivač mora pokazivati ​​na posljednji oktet hitnih podataka. Tipična upotreba hitnih podataka je slanje signala sa terminala za otkazivanje ili prekid.

Često se nazivaju hitni podaci informacije izvan opsega(van opsega). Međutim, ovaj izraz je netačan. Hitni podaci se šalju u normalnom TCP toku, iako pojedinačne implementacije mogu imati posebne mehanizme da ukažu aplikaciji da su hitni podaci stigli, a aplikacija mora ispitati sadržaj hitnih podataka prije nego što stignu svi bajtovi poruke.

Oznaka RESET je postavljena na 1 kada bi se veza trebala prekinuti. Ista zastavica se postavlja u odgovoru kada se primi segment koji nije pridružen nijednoj od trenutnih TCP veza.

FIN zastavica je postavljena na 1 za poruke o zatvaranju veze.

10.8.6 Kontrolna suma

IP kontrolna suma je samo za IP zaglavlje, dok se TCP kontrolna suma izračunava za cijeli segment kao i pseudo zaglavlje generirano iz IP zaglavlja. Tokom izračunavanja TCP kontrolne sume, odgovarajuće polje je postavljeno na 0. Na sl. Slika 10-15 prikazuje pseudo zaglavlje vrlo slično onom koji se koristi u UDP kontrolnoj sumi.

Rice. 10.15. Pseudo polje zaglavlja uključeno u TCP kontrolni zbir

TCP dužina se izračunava dodavanjem dužine TCP zaglavlja dužini podataka. TCP kontrolni zbroj je obavezno, a ne kao u UDP-u. Kontrolnu sumu dolaznog segmenta prvo izračunava primalac, a zatim upoređuje sa sadržajem polja kontrolne sume TCP zaglavlja. Ako se vrijednosti ne podudaraju, segment se odbacuje.

10.9 Primjer TCP segmenta

Rice. 10.16, protokol analizatora Njuškalo od Network General, je niz TCP segmenata. Prva tri segmenta uspostavljaju vezu između klijenta i servera telnet. Poslednji segment nosi 12 bajtova podataka.

Rice. 10.16. Prikaz TCP zaglavlja pomoću Sniffer Parser

Analyzer Njuškalo prevodi većinu vrijednosti u decimalni. Međutim, vrijednosti zastavice se izlaze kao heksadecimalne. Oznaka sa vrijednošću 12 je 010010. Kontrolna suma se također ispisuje u heksadecimalnom obliku.

10.10 Podrška za rad sesije

10.10.1 Ispitivanje prozora

Brzi pošiljalac i spori primalac mogu formirati prozor za primanje od 0 bajta. Ovaj rezultat se zove zatvaranje prozora(zatvori prozor). Kada ima slobodnog prostora za ažuriranje veličine prozora za prijem, koristi se ACK. Međutim, ako se takva poruka izgubi, obje strane će morati čekati neograničeno.

Da bi se izbjegla ova situacija, pošiljatelj postavlja sačuvaj tajmer(persist timer) prilikom zatvaranja premium prozora. Vrijednost tajmera je vremensko ograničenje ponovnog prijenosa. Na kraju tajmera, segment se šalje partneru sensing window(sonda prozora; neke implementacije uključuju podatke). Sonda uzrokuje da peer pošalje natrag ACK koji prijavljuje trenutni status prozora.

Ako je prozor i dalje veličine nula, vrijednost trajnog tajmera se udvostručuje. Ovaj proces se ponavlja sve dok vrijednost tajmera ne dostigne maksimum od 60 s. TCP će nastaviti slati probne poruke svakih 60 sekundi dok se ne otvori prozor, dok korisnik ne prekine proces ili dok aplikacija ne istekne.

10.11 Završetak sesije

10.11.1 Istek

Partner u vezi se može srušiti ili biti potpuno prekinut zbog kvara pristupnika ili veze. Da bi se spriječio ponovni prijenos podataka u TCP-u, postoji nekoliko mehanizama.

Po dolasku do prvog praga retransmisije (releja), TCP govori IP-u da provjeri ima li neuspjelog rutera i istovremeno obavještava aplikaciju o problemu. TCP nastavlja slati podatke sve dok se ne dostigne druga granična vrijednost i tek tada zatvara vezu.

Naravno, prije nego što se to dogodi, može postojati ICMP poruka koja ukazuje da je odredište nedostupno iz nekog razloga. U nekim implementacijama, čak i nakon ovoga, TCP će nastaviti pokušavati da pristupi odredištu sve dok ne istekne vremenski interval (u tom trenutku problem može biti riješen). Zatim se aplikacija obavještava da je odredište nedostupno.

Aplikacija može postaviti svoje vlastito vremensko ograničenje isporuke podataka i izvršiti vlastite operacije kada ovaj interval istekne. Obično je veza prekinuta.

10.11.2 Održavanje veze

Kada nedovršena veza ima podatke za slanje duže vrijeme, dobija status mirovanja. Tokom perioda neaktivnosti može doći do pada mreže ili kvara fizičke veze. Čim mreža ponovo postane operativna, partneri će nastaviti s razmjenom podataka bez prekida komunikacijske sesije. Ova strategija je ispunila zahtjeve Ministarstva odbrane.

Međutim, svaka veza - aktivna ili neaktivna - zauzima puno memorije računara. Neki administratori moraju vratiti neiskorištene resurse u sistem. Stoga su mnoge TCP implementacije sposobne slati poruku o tome održavanje veze(keep-alive) koji testira neaktivne veze. Takve poruke se periodično šalju partneru da provjeri njegovo postojanje u mreži. Odgovor moraju biti ACK poruke. Upotreba poruka o održavanju života nije obavezna. Ako sistem ima ovu mogućnost, aplikacija je može nadjačati svojim vlastitim sredstvima. Predviđeni period default jer je vremensko ograničenje održavanja veze puna dva sata!

Podsjetimo, aplikacija može postaviti svoj tajmer, prema kojem će na svom nivou odlučivati ​​o prekidu veze.

10.12 Performanse

Koliko je efikasan TCP? Na performanse resursa utiču mnogi faktori, a glavni su memorija i propusni opseg (vidi sliku 10.17).

Rice. 10.17. TCP faktori performansi

Širina pojasa i kašnjenja u fizičkoj mreži u upotrebi ozbiljno ograničavaju propusnost. Loš kvalitet prijenosa podataka rezultira velikom količinom odbačenih datagrama, što uzrokuje ponovne prijenose i posljedično smanjuje efikasnost propusnog opsega.

Strana koja prima podatke mora obezbijediti dovoljno prostora za međuspremnik da omogući pošiljaocu da prenosi podatke bez pauza u radu. Ovo je posebno važno za mreže sa velikim kašnjenjem, gde postoji dugo vreme između slanja podataka i primanja ACK-ova (a takođe i kada se pregovara o veličini prozora). Da bi se održao stalan tok podataka iz izvora, kraj koji prima podatke mora imati prozor koji nije manji od proizvoda širine pojasa i kašnjenja.

Na primjer, ako izvor može poslati podatke brzinom od 10.000 bajtova/s, a potrebno je 2 sekunde da vrati ACK, tada prozor za primanje na drugoj strani mora biti veličine najmanje 20.000 bajtova, inače će protok podataka ne bude kontinuirano. Prijemni bafer od 10.000 bajtova će prepoloviti propusnost.

Još jedan važan faktor performansi je sposobnost hosta da odgovori na događaje visokog prioriteta i da se brzo izvrši prebacivanje konteksta, tj. završiti jednu operaciju i prebaciti se na drugu. Host može interaktivno podržati više lokalnih korisnika, grupne pozadinske procese i desetke istovremenih komunikacijskih veza. Prebacivanje konteksta vam omogućava da opslužujete sve ove operacije, skrivajući opterećenje na sistemu. Implementacije koje integrišu TCP/IP sa kernelom operativnog sistema mogu značajno smanjiti opterećenje korišćenjem promene konteksta.

Računalni CPU resursi su potrebni za operacije obrade TCP zaglavlja. Ako procesor ne može brzo izračunati kontrolne sume, to dovodi do smanjenja brzine prijenosa podataka preko mreže.

Osim toga, programeri bi trebali nastojati da pojednostave konfiguraciju TCP postavki tako da ih administrator mreže može prilagoditi svojim lokalnim zahtjevima. Na primjer, mogućnost prilagođavanja veličine bafera za propusni opseg i kašnjenje mreže uvelike će poboljšati performanse. Nažalost, mnoge implementacije ne obraćaju dovoljno pažnje na ovo pitanje i tvrdo kodiraju komunikacijske parametre.

Pretpostavimo da je mrežno okruženje savršeno: ima dovoljno resursa i prebacivanje konteksta je brže nego što kauboji izvlače oružje. Hoće li se postići odlične performanse?

Nije uvijek. Kvalitet razvoja TCP softvera je također važan. Tokom godina, mnogi problemi performansi su dijagnosticirani i riješeni u različitim TCP implementacijama. Može se smatrati da će najbolji softver biti onaj koji je usklađen sa RFC 1122, koji definiše zahtjeve za komunikacioni sloj internet hostova.

Jednako važan izuzetak i primjena Jacobson, Kern i Partridge algoritama (ovi zanimljivi algoritmi će biti razmotreni u nastavku).

Programeri softvera mogu dobiti značajne prednosti kreiranjem programa koji eliminišu nepotrebne male prenose podataka i imaju ugrađene tajmere za oslobađanje mrežnih resursa koji se trenutno ne koriste.

10.13 Algoritmi za poboljšanje performansi

Prelazeći na uvod u prilično složeni dio TCP-a, pogledat ćemo mehanizme za poboljšanje performansi i rješavanje problema pada propusnosti. Ovaj odjeljak razmatra sljedeća pitanja:

■ spor start(spori početak) sprječava korištenje velike količine mrežnog prometa za novu sesiju, što može dovesti do dodatnih troškova.

■ Liječenje od Sindrom bezumnog prozora(sindrom glupog prozora) sprečava loše dizajnirane aplikacije da preplave mrežu porukama.

■ Odgođen ACK(odloženi ACK) smanjuje zagušenje smanjenjem broja nezavisnih poruka potvrde prijenosa podataka.

■ Izračunato vremensko ograničenje ponovnog prijenosa(računanje vremenskog ograničenja ponovnog prijenosa) se oslanja na pregovaranje sesije u realnom vremenu, smanjujući nepotrebne ponovne prijenose, a ne uzrokujući velika kašnjenja za stvarno potrebne razmjene podataka.

■ TCP prosljeđivanje zastoj kada preopterećenja na mreži omogućava ruterima da se vrate u prvobitni način rada i dijele mrežne resurse za sve sesije.

■ Dostava dupli ACK-ovi(duplikat ACK) po prijemu segmenta izvan sekvence, omogućava ravnopravnim korisnicima ponovni prijenos prije isteka vremena.

10.13.1 Sporo pokretanje

Ako su svi kućni električni aparati uključeni u isto vrijeme kod kuće, električna mreža će biti preopterećena. U kompjuterskim mrežama spor start sprečava pregorevanje mrežnih osigurača.

Nova veza koja trenutno počinje slati veliku količinu podataka na već zauzetoj mreži može dovesti do problema. Ideja sporog pokretanja je osigurati da se nova veza uspješno pokrene sa sporim povećanjem brzine prijenosa podataka u skladu sa stvarnim opterećenjem mreže. Pošiljalac je ograničen veličinom prozora za učitavanje, a ne većim prozorom za primanje.

prozor za učitavanje(prozor zagušenja) počinje veličinom od 1 segmenta. Za svaki segment sa uspješno primljenim ACK, veličina prozora za učitavanje se povećava za 1 segment, sve dok ostaje manji od prozora za prijem. Ako mreža nije zagušena, prozor za učitavanje će postepeno dostići veličinu prozora za prijem. U normalnom stanju prosljeđivanja, ovi prozori će biti iste veličine.

Imajte na umu da spor početak nije tako spor. Nakon prvog ACK-a, veličina prozora za učitavanje je 2 segmenta, a nakon uspješnog ACK-a za dva segmenta, veličina se može povećati na 8 segmenata. Drugim riječima, veličina prozora se eksponencijalno povećava.

Pretpostavimo da je umjesto primanja ACK-a došlo do isteka vremena. Ponašanje prozora za učitavanje u ovom slučaju je objašnjeno u nastavku.

10.13.2 Sindrom bezumnog prozora

U ranim implementacijama TCP/IP-a, programeri su se susreli sa ovim fenomenom Sindrom bezumnog prozora(Silly Window Syndrome - SWS), koji se dosta često manifestirao. Da biste razumjeli šta se događa, razmislite o sljedećem scenariju, koji dovodi do neželjenih posljedica, ali je sasvim moguće:

1. Aplikacija koja šalje podatke brzo šalje podatke.

2. Aplikacija koja prima podatke čita 1 bajt podataka iz ulaznog bafera (tj. polako).

3. Ulazni bafer se brzo puni nakon čitanja.

4. Aplikacija koja prima čita 1 bajt i TCP šalje ACK što znači "Imam slobodan prostor za 1 bajt podataka".

5. Aplikacija za prijenos šalje TCP paket od 1 bajta preko mreže.

6. TCP koji prima šalje ACK što znači "Hvala. Primio sam paket i nemam više slobodnog prostora."

7. Aplikacija koja prima ponovo čita 1 bajt i šalje ACK, a cijeli proces se ponavlja.

Aplikacija koja sporo prima dugo čeka da podaci stignu i stalno gura primljene informacije na lijevu ivicu prozora, izvodeći potpuno beskorisnu operaciju koja stvara dodatni promet na mreži.

Stvarne situacije, naravno, nisu tako ekstremne. Brzi pošiljalac i spori primalac će razmijeniti male (u odnosu na maksimalnu veličinu segmenta) komade podataka i prebaciti se na skoro pun prozor za prijem. Na sl. 10.18 prikazuje uslove za pojavu sindroma "glupog prozora".

Rice. 10.18. Primanje prozorskog bafera sa vrlo malim slobodnim prostorom

Rješavanje ovog problema je jednostavno. Čim se prozor primanja smanji za dužinu manju od date ciljne veličine, TCP počinje da obmanjuje pošiljaoca. U ovoj situaciji, TCP ne smije upućivati ​​na pošiljaoca dodatno prostor u prozoru kada aplikacija koja prima podatke čita podatke iz bafera u malim komadima. Umjesto toga, oslobođeni resursi trebaju biti tajni od pošiljatelja dok ih ne bude dovoljno. Preporučuje se veličina jednog segmenta, osim ako cijeli ulazni bafer ne pohranjuje jedan segment (u posljednjem slučaju koristi se veličina jednaka polovini bafera). Ciljna veličina koju TCP treba da prijavi može se izraziti kao:

minimum (1/2 ulaznog bafera, maksimalna veličina segmenta)

TCP počinje da vara kada je veličina prozora manja od ove veličine, a reći će istinu kada veličina prozora nije manja od vrijednosti date formulom. Imajte na umu da nema štete za pošiljaoca, jer aplikacija koja prima i dalje ne bi mogla obraditi veliki dio podataka koje očekuje.

Predloženo rješenje je lako provjeriti u slučaju koji je gore razmotren sa izlazom ACK za svaki primljeni bajt. Ista metoda je pogodna i za slučaj kada ulazni bafer može pohraniti nekoliko segmenata (kao što se često dešava u praksi). Brzi pošiljalac će ispuniti ulazni bafer, ali primalac će pokazati da nema slobodnog prostora za pohranjivanje informacija i neće otvoriti ovaj resurs dok njegova veličina ne dostigne cijeli segment.

10.13.3 Nagleov algoritam

Pošiljalac mora, bez obzira na primatelja, izbjegavati slanje vrlo kratkih segmenata gomilanjem podataka prije slanja. Nagleov algoritam implementira vrlo jednostavnu ideju za smanjenje broja kratkih datagrama koji se šalju preko mreže.

Algoritam preporučuje odlaganje prijenosa podataka (i iskakanje) dok se čeka ACK od prethodno prenesenih podataka. Akumulirani podaci se šalju nakon prijema ACK-a na prethodno poslanu informaciju, ili nakon prijema za slanje podataka u veličini cijelog segmenta, ili po završetku isteka vremena. Ovaj algoritam se ne bi trebao koristiti za aplikacije u realnom vremenu koje trebaju slati podatke što je brže moguće.

10.13.4 Odgođen ACK

Drugi mehanizam za poboljšanje performansi je način na koji se ACK odlaže. Smanjenje broja ACK-ova smanjuje količinu propusnog opsega koja se može koristiti za slanje drugog saobraćaja. Ako TCP partner malo odgodi slanje ACK-a, tada:

■ Više segmenata može biti potvrđeno jednim ACK.

■ Prijemna aplikacija može primiti određenu količinu podataka unutar vremenskog intervala, tj. izlazno zaglavlje može biti uključeno u ACK i nije potrebno generirati posebnu poruku.

Kako bi se izbjegla kašnjenja prilikom prosljeđivanja toka segmenata pune dužine (na primjer, prilikom razmjene datoteka), ACK treba poslati za najmanje svaki drugi segment pune dužine.

Mnoge implementacije koriste vremensko ograničenje od 200 ms. Ali odloženi ACK ne smanjuje kurs. Kada stigne kratak segment, još uvijek ima dovoljno slobodnog prostora u ulaznom baferu za primanje novih podataka, a pošiljalac može nastaviti prijenos (uz to, ponovni prijenos je obično mnogo sporiji). Ako stigne cijeli segment, morate na njega odgovoriti ACK porukom u istoj sekundi.

10.13.5 Vremensko ograničenje ponovnog prijenosa

Nakon slanja segmenta, TCP postavlja tajmer i prati dolazak ACK. Ako ACK nije primljen u vremenskom periodu, TCP ponovo šalje segment (relej). Međutim, koji bi trebao biti vremenski period?

Ako je prekratak, pošiljalac će preplaviti mrežu nepotrebnim segmentima koji dupliraju već poslane informacije. Predugo vremensko ograničenje će spriječiti da se segmenti koji su stvarno oštećeni tokom prijenosa brzo poprave, što će smanjiti propusnost.

Kako odabrati ispravan interval za timeout? Vrijednost koja je prikladna za LAN velike brzine neće biti prikladna za udaljenu vezu s mnogo pogodaka. Stoga je princip "jedna vrijednost za bilo koje uvjete" očigledno neprikladan. Štoviše, čak i za postojeću specifičnu vezu, mrežni uvjeti se mogu promijeniti, a kašnjenja se mogu povećati ili smanjiti.

Algoritmi Jacobsona, Kerna i Partridgea (opisani u člancima , Van Jacobson i Poboljšanje procjene vremena povratnog putovanja u pouzdanim transportnim protokolima, Karn i Partridge) omogućavaju TCP-u da se prilagodi promjenjivim mrežnim uvjetima. Ovi algoritmi se preporučuju za upotrebu u novim implementacijama. U nastavku ćemo ih ukratko pregledati.

Zdrav razum nalaže da bi najbolja osnova za procjenu tačnog vremena čekanja za određenu vezu mogla biti praćenje vrijeme ciklusa(povratno vrijeme) kao interval između slanja podataka i prijema potvrde o njihovom prijemu.

Dobra rješenja za sljedeće veličine mogu se dobiti na osnovu elementarne statistike (vidi sliku 10.19) koja će pomoći u izračunavanju vremena čekanja. Međutim, nemojte se oslanjati na prosjek, jer će više od polovine rezultata biti veće od statističkog prosjeka. Uzimajući u obzir par varijansi, mogu se dobiti bolje procjene koje uzimaju u obzir normalnu distribuciju i smanjuju predugo kašnjenje retransmisije.

Rice. 10.19. Distribucija vremena ciklusa

Nema potrebe za velikom količinom proračuna da bi se dobile formalne matematičke procjene odstupanja. Možete koristiti prilično grube procjene na osnovu apsolutne vrijednosti razlike između posljednje vrijednosti i prosječne procjene:

Posljednje odstupanje = | Zadnji ciklus - Prosjek |

Da biste izračunali ispravnu vrijednost vremenskog ograničenja, još jedan faktor koji treba uzeti u obzir je promjena vremena ciklusa zbog trenutnih mrežnih uslova. Ono što se dogodilo na mreži u posljednjem trenutku važnije je od onoga što se dogodilo prije sat vremena.

Pretpostavimo da izračunavate prosek ciklusa za veoma dugu sesiju. Pretpostavimo da je na početku mreža bila slabo opterećena, a odredili smo 1000 malih vrijednosti, ali je tada došlo do povećanja prometa uz značajno povećanje vremena kašnjenja.

Na primjer, ako je 1000 vrijednosti dalo prosječnu vrijednost od 170 jedinica, ali je tada izmjereno 50 vrijednosti sa prosjekom od 282, tada bi trenutni prosjek bio:

170x1000/1050 + 282x50/1050 = 175

Bilo bi razumnije izglađeno vrijeme ciklusa(Smoothed Round-Trip Time - SRTT), koji uzima u obzir prioritet kasnijih vrijednosti:

Novi SRTT = (1 – α)×(stari SRTT) + α×Vrijednost posljednjeg ciklusa

Vrijednost α je između 0 i 1. Povećanje a rezultira većim uticajem trenutnog vremena ciklusa na izglađeni prosjek. Budući da računari mogu brzo podijeliti po stepenu 2 pomicanjem binarnih brojeva udesno, vrijednost za α je uvijek (1/2) n (obično 1/8), tako da:

Novi SRTT = 7/8×stari SRTT + 1/8×Vrijeme posljednjeg ciklusa

Tabela 10.2 pokazuje kako se formula za SRTT prilagođava trenutnoj vrijednosti SRTT od 230 jedinica kada promjena uslova mreže rezultira uzastopnim povećanjem vremena ciklusa (pod pretpostavkom da ne dođe do vremenskog ograničenja). Vrijednosti u koloni 3 koriste se kao vrijednosti u koloni 1 za sljedeći red u tabeli (tj. stari SRTT).

Tabela 10.2 Izračunavanje vremena izglađenog ciklusa

Stari SRTT	Najnoviji RTT	(7/8)×(stari SRTT) + (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

Sada se postavlja pitanje odabira vrijednosti za vremensko ograničenje ponovnog prijenosa. Analiza vremena ciklusa pokazuje značajno odstupanje ovih vrijednosti od trenutnog prosjeka. Ima smisla postaviti granicu za veličinu odstupanja (odstupanja). Dobre vrijednosti za vremensko ograničenje retransmisije (nazvane Retransmission TimeOut - RTO u RFC standardima) su date sljedećom formulom sa ograničenom izglađenom varijansom (SDEV):

T = Retransmission Timeout = SRTT + 2×SDEV

T = SRTT + 4×SDEV

Da biste izračunali SDEV, prvo odredite apsolutnu vrijednost trenutnog odstupanja:

DEV = | Vrijeme posljednjeg ciklusa - Stari SRTT |

Zatim se formula za izglađivanje koristi za obračun posljednje vrijednosti:

Novi SDEV = 3/4×stari SDEV + 1/4×DEV

Ostaje jedno pitanje - koje početne vrijednosti uzeti? Preporučeno:

Početno vremensko ograničenje = 3 s

Početni SRTT = 0

Početni SDEV = 1,5 s

Van Jacobson je definisao brzi algoritam koji veoma efikasno izračunava vremensko ograničenje retransmisije.

10.13.6 Primjer statistike

Koliko će dobro funkcionisati gore izračunato vremensko ograničenje? Prilikom implementacije dobijene vrijednosti uočena su značajna poboljšanja performansi. Primjer bi bila statistika komandi netstat primljeno na sistem tiger- Internet server kojem pristupaju mnogi domaćini iz cijelog svijeta.

1510769 paketa (314955304 bajtova) primljeno u nizu

sistem tiger manje od 2,5% TCP segmenata podataka je ponovo poslano. Za milion i po dolaznih segmenata podataka (ostalo su čisti ACK-ovi), samo 0,6% je duplirano. U ovom slučaju treba uzeti u obzir da nivo gubitaka u ulaznim podacima približno odgovara nivou za izlazne segmente. Dakle, beskorisni promet retransmisije čini oko 0,6% ukupnog saobraćaja.

10.13.7 Obračuni nakon ponovnog podnošenja

Gore navedene formule koriste vrijednost vremena ciklusa kao interval između slanja segmenta i prijema potvrde o njegovom prijemu. Međutim, pretpostavimo da nije primljena potvrda tokom perioda čekanja i da se podaci moraju ponovo poslati.

Kernov algoritam pretpostavlja da u ovom slučaju vrijeme ciklusa ne treba mijenjati. Trenutna izglađena vrijednost vremena ciklusa i izglađeno odstupanje zadržavaju svoje vrijednosti sve dok se ne primi potvrda za slanje nekog segmenta bez ponovnog slanja. Od ovog trenutka, proračuni se nastavljaju na osnovu pohranjenih vrijednosti i novih mjerenja.

10.13.8 Radnje nakon retransmisije

Ali šta se dešava prije nego što se dobije potvrda? Nakon ponovnog prijenosa, ponašanje TCP-a se drastično mijenja, uglavnom zbog gubitka podataka zbog zagušenja mreže. Stoga će odgovor na ponovno slanje podataka biti:

■ Smanjena stopa retransmisije

■ Borite se protiv zagušenja mreže smanjenjem ukupnog saobraćaja

10.13.9 Eksponencijalno kočenje

Nakon ponovnog prijenosa, vremenski interval se udvostručuje. Međutim, šta se dešava kada se tajmer ponovo prekorači? Podaci će biti ponovo poslani i period retransmisije će se ponovo udvostručiti. Ovaj proces se zove eksponencijalno kočenje(eksponencijalno povlačenje).

Ako se mrežni kvar nastavi javljati, vremenski period će se udvostručiti dok ne dostigne unaprijed postavljenu maksimalnu vrijednost (obično 1 minut). Nakon isteka vremena, samo jedan segment se može poslati. Vremensko ograničenje se također događa kada se prekorači unaprijed postavljena vrijednost za broj prijenosa podataka bez prijema ACK-a.

10.13.10 Smanjenje zagušenja smanjenjem podataka koji se šalju preko mreže

Smanjenje količine poslanih podataka je nešto složenije od mehanizama o kojima smo gore govorili. Počinje da radi, kao i već pomenuti spori start. Ali, pošto je postavljeno ograničenje za nivo saobraćaja, što u početku može dovesti do problema, kurs će se zapravo usporiti zbog povećanja veličine prozora opterećenja za jedan segment. Morate postaviti granične vrijednosti ​​za stvarno smanjenje brzine slanja. Prvo se izračunava prag opasnosti:

Granica - minimalno 1/2 (trenutni prozor za učitavanje, prozor za primanje partnera)

Ako je rezultirajuća vrijednost više od dva segmenta, koristi se kao granica. Inače, veličina granice je postavljena na dva segmenta. Kompletan algoritam oporavka zahtijeva:

■ Postavite veličinu prozora za učitavanje na jedan segment.

■ Za svaki primljeni ACK, povećajte veličinu prozora za učitavanje za jedan segment dok se ne dostigne granica (slično kao mehanizam sporog pokretanja).

■ Nakon toga, sa svakim primljenim ACK, dodajte manju vrijednost prozoru opterećenja, koji se bira na osnovu stope povećanja po segmentu za vrijeme ciklusa (povećanje se izračunava kao MSS/N, gdje je N veličina opterećenja prozor u segmentima).

Scenario za idealan slučaj može biti pojednostavljen prikaz kako mehanizam oporavka funkcionira. Pretpostavimo da je prozor primanja ravnopravnog partnera (i prozor trenutnog opterećenja) bio 8 segmenata prije nego što je vremensko ograničenje otkriveno, a granica je definirana kao 4 segmenta. Ako primateljska aplikacija trenutno čita podatke iz bafera, veličina prozora za primanje će ostati na 8 segmenata.

■ 1 segment se šalje (prozor učitavanja = 1 segment).

■ ACK primljen - 2 segmenta su poslana.

■ ACK primljen za 2 segmenta - 4 segmenta su poslana, (granica je dostignuta).

■ Primljeno ACK za 4 segmenta. Poslano je 5 segmenata.

■ Primljeno ACK za 5 segmenata. Poslano je 6 segmenata.

■ ACK primljen za 6 segmenata. Poslano je 7 segmenata.

■ ACK primljen za 7 segmenata. Šalje se 8 segmenata (prozor za učitavanje je opet jednak po veličini prozoru za prijem).

Budući da svi poslani podaci moraju biti potvrđeni tokom vremenskog ograničenja ponovnog prijenosa, proces se nastavlja sve dok prozor učitavanja ne dostigne veličinu prozora za prijem. Događaji koji se dešavaju prikazani su na sl. 10.20. Veličina prozora raste eksponencijalno, udvostručujući se tokom perioda sporog početka, a kada se dostigne granica, povećanje je linearno.

Rice. 10.20. Ograničenje brzine naprijed tokom zagušenja

10.13.11 Duplicirani ACK-ovi

U nekim implementacijama koristi se opciona karakteristika - tzv brza dostava(brzi retransmit) - kako bi se ubrzao ponovni prijenos podataka pod određenim uvjetima. Njegova glavna ideja se odnosi na to da primalac šalje dodatne ACK-ove koji ukazuju na prazninu u primljenim podacima.

Po prijemu segmenta koji nije u redu, primalac šalje natrag ACK koji pokazuje na prvi bajt. izgubljen podatke (vidi sliku 10.21).

Rice. 10.21. Duplicirani ACK-ovi

Pošiljalac ne vrši trenutni ponovni prijenos podataka jer IP može normalno dostaviti podatke primaocu bez sekvence slanja. Ali kada se primi nekoliko dodatnih ACK-ova za dupliciranje podataka (na primjer, tri), tada će segment koji nedostaje biti poslan bez čekanja da se završi vrijeme.

Imajte na umu da svaki duplikat ACK označava prijem segmenta podataka. Nekoliko dupliranih ACK-ova jasno daje do znanja da je mreža sposobna da isporuči dovoljno podataka i da stoga nije previše opterećena. Kao dio ukupnog algoritma, vrši se malo smanjenje veličine prozora opterećenja uz stvarno povećanje mrežnog prometa. U ovom slučaju se ne primjenjuje postupak drastične promjene veličine prilikom restauracije rada.

Po standardu Host Requirements(zahtjevi hosta) TCP mora izvesti isti spori start kao što je gore opisano kada se izvor gasi. Međutim, prijavljivanje ovoga nije ciljano niti efikasno, jer veza koja je primila poruku možda neće generirati previše prometa. Trenutna specifikacija Zahtjevi za ruter(zahtjevi rutera) specificira da ruteri ne treba slati poruke o suzbijanju izvora.

10.13.13 TCP statistika

Na kraju, pogledajmo statističke poruke naredbe netstat, da vidite mnoge od gore opisanih mehanizama u akciji.

Segmenti se nazivaju paketi.

879137 paketa podataka (226966295 bajtova)

21815 paketa podataka (8100927 bajtova) je ponovo poslano

Ponovna otprema.

132957 paketa samo za potvrdu (104216 odgođeno)

Obratite pažnju na veliki broj

odloženi ACK-ovi.

Zvuk otvaranja prozora

veličina nula.

Ovo su SYN i FIN poruke.

762469 acks (za 226904227 bajtova)

Signal dolaska paketa

van redosleda.

1510769 paketa (314955304 bajtova)

9006 potpuno dupliranih paketa (867042 bajtova)

Rezultat timeout-a sa real

dostava podataka.

74 paketa sa nešto duplo. podaci (12193 bajtova prevarenih)

Da bi bili efikasniji

neki podaci su prepakovani da bi uključili dodatne bajtove kada su ponovo poslati.

13452 paketa van reda (2515087 bajtova)

530 paketa (8551 bajtova) podataka nakon prozora

Možda je ovaj podatak bio

uključene u zvučne poruke.

402 paketa primljena nakon zatvaranja

Ovo su naknadna ponavljanja

slanje.

108 je odbačeno zbog loših kontrolnih suma

Nevažeći TCP kontrolni zbroj.

0 je odbačeno zbog loših polja pomaka zaglavlja

7 je odbačeno jer je paket prekratak

Uspostavljeno 14677 veza (uključujući prihvatanje)

18929 veza zatvoreno (uključujući 643 kapi)

4100 embrionalnih veza je otpalo

572187 segmenata ažuriranih rtt (od 587397 pokušaja)

Neuspješni pokušaji promjene

vrijeme ciklusa, jer ACK nije stigao prije isteka vremenskog ograničenja,

26 veza prekinuto zbog isteka rexmit-a

Naknadni neuspješni pokušaji

ponovo poslati, što ukazuje na izgubljenu vezu.

Istek vremena za ispitivanje

nulti prozor.

Provjerite istekne

veza u stanju mirovanja.

472 veze su prekinute zbog održavanja

10.14 Usklađenost sa zahtjevima programera

Trenutni TCP standard zahtijeva da se implementacije striktno pridržavaju procedure sporog pokretanja prilikom inicijalizacije veze i da koriste Kern i Jacobson algoritme za procjenu vremenskog ograničenja ponovnog slanja i kontrolnog opterećenja. Testovi su pokazali da ovi mehanizmi dovode do značajnih poboljšanja performansi.

Šta se dešava kada instalirate sistem koji se striktno ne pridržava ovih standarda? Neće obezbediti adekvatne performanse za sopstvene korisnike, i biće loš komšija za druge sisteme na mreži, sprečavajući oporavak od privremenog preopterećenja i generisanje prekomernog saobraćaja što rezultira ispuštenim datagramima.

10.15 Prepreke performansama

TCP je dokazao svoju fleksibilnost radeći na mrežama sa brzinama prijenosa od stotina ili miliona bitova u sekundi. Ovaj protokol je postigao dobre rezultate u modernim lokalnim mrežama sa Ethernet, Token-Ring i Fiber Distributed Data Interface (FDDI) topologijama, kao i za niske brzine komunikacionih linija ili veza na velike udaljenosti (poput satelitskih komunikacija).

TCP je dizajniran da odgovori na ekstremne uslove, kao što je zagušenje mreže. Međutim, trenutna verzija protokola ima karakteristike koje ograničavaju performanse u novim tehnologijama koje nude stotine i hiljade megabajta propusnog opsega. Da biste razumjeli probleme koji se pojavljuju, razmotrite jednostavan (iako nerealan) primjer.

Pretpostavimo da kada premještate datoteku između dva sistema, želite što efikasnije razmjenjivati ​​kontinuirani tok. Pretpostavimo da:

■ Maksimalna veličina odredišnog segmenta je 1 KB.

■ Prozor za prijem - 4 KB.

■ Širina pojasa vam omogućava da pošaljete dva segmenta u 1 s.

■ Aplikacija koja prima podatke troši podatke kako stignu.

■ ACK poruke stižu nakon 2 sekunde.

Pošiljalac može kontinuirano slati podatke. Na kraju krajeva, kada je volumen dodijeljen za prozor pun, stiže ACK, omogućavajući slanje drugog segmenta:

Nakon 2 s:

PRIMITE POTVRDU SEGMENTA 1, MOŽETE POSLATI SEGMENT 5.

PRIMITE POTVRDU SEGMENTA 2, MOŽETE POSLATI SEGMENT 6.

PRIMITE POTVRDU SEGMENTA 3, MOŽETE POSLATI SEGMENT 7.

PRIMITE POTVRDU SEGMENTA 4, MOŽETE POSLATI SEGMENT 8.

Nakon još 2 s:

PRIMITE POTVRDU SEGMENTA 5, MOŽETE POSLATI SEGMENT 9.

Ako je prozor za prijem bio samo 2K, pošiljalac bi morao čekati jednu sekundu od svake dvije prije nego što pošalje sljedeće podatke. Zapravo, da bi se održao kontinuirani tok podataka, prozor za primanje mora biti najmanje:

Prozor = širina pojasa×vrijeme ciklusa

Iako je primjer pomalo pretjeran (da bi se pružili jednostavniji brojevi), mali prozor može dovesti do problema sa satelitskim vezama velike latencije.

Pogledajmo sada šta se dešava sa vezama velike brzine. Na primjer, ako se propusni opseg i brzina prijenosa mjere na 10 Mbps, ali je vrijeme ciklusa 100 ms (1/10 sekunde), tada za kontinuirani stream prozor za prijem mora pohraniti najmanje 1.000.000 bitova, tj. 125.000 bajtova. Ali najveći broj koji se može upisati u polje zaglavlja za TCP prijemni prozor je 65,536.

Drugi problem se javlja pri visokim brzinama prijenosa, jer brojevi sekvence ponestaju vrlo brzo. Ako veza može slati podatke brzinom od 4 GB / s, tada bi se brojevi sekvence trebali ažurirati svake sekunde. Neće biti načina da se napravi razlika između starih dupliranih datagrama koji su kasnili više od sekunde dok su putovali internetom i svježih novih podataka.

Novo istraživanje se aktivno provodi kako bi se poboljšao TCP/IP i uklonile gore navedene prepreke.

10.16 TCP funkcije

Ovo poglavlje pokriva mnoge karakteristike TCP-a. Glavni su navedeni u nastavku:

■ Povezivanje portova sa vezama

■ Inicijalizacija veza putem potvrde u tri koraka

■ Izvođenje sporog pokretanja kako bi se izbjeglo zagušenje mreže

■ Segmentacija podataka u tranzitu

■ Numerisanje podataka

■ Rukovanje dolaznim dupliranim segmentima

■ Izračun kontrolne sume

■ Regulacija protoka podataka kroz prozor za prijem i prozor za slanje

■ Prekidanje veze na propisan način

■ Prekidanje veze

■ Prosljeđivanje hitnih podataka

■ Pozitivna potvrda ponovnog slanja

■ Proračun vremenskog ograničenja ponovnog prijenosa

■ Smanjenje obrnutog saobraćaja tokom zagušenja mreže

■ Signalizacija neispravnih segmenata

■ Ispitivanje zatvaranja prijemnog prozora

10.17 TCP stanja

TCP veza prolazi kroz nekoliko faza: veza se uspostavlja razmjenom poruka, zatim se šalju podaci, a zatim se veza zatvara razmjenom posebnih poruka. Svaki korak u radu veze odgovara određenom stanje ovu vezu. TCP softver na svakom kraju veze stalno prati trenutno stanje druge strane veze.

U nastavku ćemo ukratko razmotriti tipičnu promjenu stanja servera i klijenta koji se nalaze na različitim krajevima veze. Nemamo za cilj da damo iscrpan opis svih mogućih stanja prilikom prenosa podataka. Dat je u RFC 793 i dokumentu Host Requirements.

Tokom uspostavljanja veze, server i klijent prolaze kroz slične nizove stanja. Stanja servera su prikazana u tabeli 10.3, a stanja klijenta su prikazana u tabeli 10.4.

Tabela 10.3 Slijed stanja servera

Status servera	Događaj	Opis
ZATVORENO		Lažno stanje prije početka postavljanja veze.
	Pasivno otvaranje serverskom aplikacijom.
SLUŠAJ (praćenje)		Server čeka konekciju od klijenta.
	TCP server prima SYN i šalje SYN/ACK.	Server je primio SYN i poslao SYN/ACK. Prelazi na čekanje ACK.
SYN RECEIVED	TCP server prima ACK.
OSNOVAN (instaliran)		ACK primljen, veza otvorena.

Tabela 10.4 Slijed stanja klijenta

Ako bi vršnjaci pokušavali da uspostave vezu jedni s drugima u isto vrijeme (što je izuzetno rijetko), svaki bi prošao kroz stanja ZATVORENO, SYN-SENT, SYN-RECEIVED i ESTABLISHED.

Krajnje strane veze ostaju u ESTABLISHED stanju sve dok jedna od strana ne nastavi zatvaranje vezu slanjem FIN segmenta. Tokom normalnog zatvaranja, strana koja inicira to zatvaranje prolazi kroz stanja prikazana u tabeli 10.5. Njen partner prolazi kroz stanja prikazana u tabeli 10.6.

Tabela 10.5 Redoslijed stanja strane koja zatvara vezu

Bočna stanja zatvaranja	Događaj	Opis
ESTABLISHED	Lokalna aplikacija zahtijeva da se veza zatvori.
	TCP šalje FIN/ACK.
FIN-WAIT-1		Završna strana čeka odgovor partnera. Podsjetimo, novi podaci mogu ipak stići od partnera.
	TCP prima ACK.
FIN-WAIT-2		Završna strana je primila ACK od istog partnera, ali još nije primila FIN. Završna strana čeka FIN dok prihvata dolazne podatke.
	TCP prima FIN/ACK.
	Šalje ACK.
VRIJEME-ČEKAJ		Veza se održava u neodređenom stanju kako bi se omogućio dolazak ili odbacivanje dupliciranih podataka ili dupliciranog FIN-a koji još uvijek postoji u mreži. Period čekanja je dvostruko veći od procjene maksimalnog vijeka trajanja segmenta.
ZATVORENO

Tabela 10.6 Redoslijed stanja bliskog partnera

Status partnera	Događaj	Opis
ESTABLISHED	TCP prima FIN/ACK.
CLOSE-WAIT		FIN je stigao.
	TCP šalje ACK.
		TCP čeka da njegova aplikacija zatvori vezu. U ovom trenutku, aplikacija može poslati prilično veliku količinu podataka.
	Lokalna aplikacija pokreće zatvaranje veze.
	TCP šalje FIN/ACK.
LAST-ACK		TCP čeka konačni ACK.
	TCP prima ACK.
ZATVORENO		Uklonjene su sve informacije o vezi.

10.17.1 Analiza stanja TCP veze

Tim netstat -an omogućava vam da provjerite trenutno stanje veze. U nastavku su prikazane veze u stanjima slušanje, pokretanje, uspostavljeno, zatvaranje i vrijeme-cekaj.

Imajte na umu da je broj priključka naveden na kraju svake lokalne i eksterne adrese. Možete vidjeti da postoji TCP promet i za ulazne i za izlazne redove.

Pro Recv-Q Send-Q Lokalna adresa Strana adresa (država)

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 OSNOVAN

Tcp 0 0 127.0.0.1.1339 127.0.0.1.111 TIME_WAIT

Tcp 0 438 128.121.50.145.23 130.132.57.246.2219 USPOSTAVLJENO

Tcp 0 0 128.121.50.145.25 192.5.5.1.4022 TIME_WAIT

Tcp 0 0 128.121.50.145.25 141.218.1.100.3968 TIME_WAIT

Tcp 0 848 128.121.50.145.23 192.67.236.10.1050 OSNOVAN

Tcp 0 0 128.121.50.145.1082 128.121.50.141.6000 OSNOVAN

TCP 0 0 128.121.50.145.1022 128.121.50.141.1017 OSNOVAN

Tcp 0 0 128.121.50.145.514 128.121.50.141.1020 CLOSE_WAIT

Tcp 0 1152 128.121.50.145.119 192.67.239.23.3572 OSNOVAN

Tcp 0 0 128.121.50.145.1070 192.41.171.5.119 TIME_WAIT

Tcp 579 4096 128.121.50.145.119 204.143.19.30.1884 OSNOVAN

Tcp 0 0 128.121.50.145.119 192.67.243.13.3704 OSNOVAN

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 OSNOVAN

10.18 Bilješke o implementaciji

Od samog početka, TCP protokol je dizajniran za interoperabilnost mrežne opreme različitih proizvođača. TCP specifikacija ne precizira tačno kako treba da rade interne strukture implementacije. Ova pitanja su prepuštena programerima, koji su pozvani da pronađu najbolje mehanizme za svaku pojedinačnu implementaciju.

Čak i RFC 1122 (dokument Zahtjevi domaćina- zahtjevi domaćina) ostavlja dosta prostora za varijacije. Svaka od implementiranih funkcija je označena određenim nivoom kompatibilnosti:

■ MAY (Dozvoljeno)

■ NE SME

Nažalost, ponekad postoje proizvodi koji ne ispunjavaju MUST zahtjeve. Kao rezultat toga, korisnici doživljavaju neugodnost smanjenih performansi.

Neke dobre prakse implementacije nisu obuhvaćene standardima. Na primjer, sigurnost se može poboljšati ograničavanjem upotrebe dobro poznatih portova na privilegovane procese u sistemu, ako je ovaj metod podržan na lokalnom operativnom sistemu. Da bi se poboljšale performanse, implementacije bi trebale učiniti što je moguće manje kopiranja i premještanja poslanih ili preuzetih podataka.

Standardni programski interfejs aplikacije nedefinisano(kao i sigurnosna politika), tako da postoji slobodno polje aktivnosti za eksperimentisanje sa različitim skupovima softverskih alata. Međutim, to može rezultirati različitim API-jima na svakoj platformi i spriječiti premještanje aplikacijskog softvera između platformi.

U stvari, programeri baziraju svoje alate na Socket API-ju, pozajmljenom od Berkeleyja. Važnost programskog interfejsa je porasla sa pojavom WINSocka (Windows Socket), što je dovelo do proliferacije novih desktop aplikacija koje su mogle da rade na vrhu bilo kog WINSock interfejsa kompatibilnog sa TCP/IP stekom.

10.19 Dodatna literatura

Originalni TCP standard je definiran u RFC 793. Nadogradnje, popravci i zahtjevi kompatibilnosti pokriveni su u RFC 1122. Kern (Kash) i Partridge (Partridge) objavili su članak Poboljšanje procjena povratnog putovanja u pouzdanim transportnim protokolima U časopisu Zbornik radova ACM SIGCOMM 1987. Jacobsonov članak Izbjegavanje i kontrola zagušenja pojavio se u Proceedings of the ACM SIGCOMM Workshop 1988. Jacobson je također objavio nekoliko RFC-ova koji revidiraju algoritme za poboljšanje performansi.

Serveri koji implementiraju ove protokole na korporativnoj mreži daju klijentu IP adresu, gateway, mrežnu masku, servere imena, pa čak i štampač. Korisnici ne moraju ručno da konfigurišu svoje hostove da bi koristili mrežu.

Operativni sistem QNX Neutrino implementira drugi protokol za automatsku konfiguraciju pod nazivom AutoIP, koji je projekat IETF komiteta za automatsku konfiguraciju. Ovaj protokol se koristi u malim mrežama za dodjelu IP adresa za lokalnu vezu (link-local) hostovima. Protokol AutoIP određuje lokalnu IP adresu veze samostalno koristeći šemu pregovaranja sa drugim domaćinima i bez pristupa centralnom serveru.

Korištenje PPPoE protokola

Skraćenica PPPoE je skraćenica za "Point-to-Point Protocol over Ethernet". Ovaj protokol inkapsulira podatke za prijenos preko Ethernet mreže s premoštenom topologijom.

PPPoE je specifikacija za povezivanje Ethernet korisnika na Internet preko širokopojasne veze, kao što je iznajmljena digitalna pretplatnička linija, bežični uređaj ili kablovski modem. Korišćenje PPPoE protokola i širokopojasnog modema omogućava korisnicima lokalne računarske mreže individualni autentifikovan pristup mrežama za prenos podataka velike brzine.

PPPoE protokol kombinuje Ethernet tehnologiju sa PPP protokolom, što vam omogućava da efikasno kreirate zasebnu vezu sa udaljenim serverom za svakog korisnika. Kontrola pristupa, obračun konekcije i izbor provajdera usluga definisani su za korisnike, a ne za domaćine. Prednost ovog pristupa je u tome što ni telefonska kompanija ni ISP ne moraju pružiti nikakvu posebnu podršku za ovo.

Za razliku od dial-up veza, DSL i kablovski modem veze su uvijek aktivne. Budući da fizičku vezu sa udaljenim provajderom usluga dijeli više korisnika, potrebna je računovodstvena metoda koja evidentira pošiljaoce saobraćaja i odredišta i naplaćuje korisnicima. PPPoE protokol omogućava korisniku i udaljenom domaćinu koji učestvuju u komunikacijskoj sesiji da nauče međusobne mrežne adrese tokom početne razmjene tzv. otkriće(otkriće). Jednom kada se uspostavi sesija između pojedinačnog korisnika i udaljenog hosta (npr. Internet provajdera), ta sesija se može nadgledati kako bi se izvršila obračunavanja. Mnogi domovi, hoteli i korporacije dijele Internet putem digitalnih pretplatničkih linija koristeći Ethernet tehnologiju i PPPoE protokol.

PPPoE veza se sastoji od klijenta i servera. Klijent i server rade koristeći bilo koji interfejs koji je blizak Ethernet specifikacijama. Ovo sučelje se koristi za izdavanje IP adresa klijentima i povezivanje tih IP adresa za korisnike i, opciono, za radne stanice, umjesto autentifikacije zasnovane samo na radnoj stanici. PPPoE server kreira vezu od tačke do tačke za svakog klijenta.

Postavljanje PPPoE sesije

Da biste kreirali PPPoE sesiju, trebali biste koristiti uslugupppoed. Modulio-pkt-*pPruža usluge PPPoE protokola. Prvo treba da trčišio-pkt-*Withodgovarajući vozač. Primjer:

Putovanje kroz mrežne protokole.

TCP i UDP su oba protokola transportnog sloja. UDP je protokol bez veze sa negarantovanom dostavom paketa. TCP (Transmission Control Protocol) je protokol orijentisan na vezu sa garantovanom isporukom paketa. Prvo dolazi do rukovanja (Zdravo | Zdravo | Hajde da razgovaramo? | Hajde.), Nakon čega se smatra da je veza uspostavljena. Nadalje, paketi se šalju naprijed-nazad preko ove veze (postoji razgovor), uz provjeru da li je paket stigao do primaoca. Ako je paket izgubljen, ili je stigao, ali sa malom kontrolnom sumom, onda se ponovo šalje ("ponovi, nisam čuo"). Dakle, TCP je pouzdaniji, ali je teži u smislu implementacije i, shodno tome, zahtijeva više ciklusa/memorije, što nije zadnja stvar za mikrokontrolere. Primjeri aplikacijskih protokola koji koriste TCP uključuju FTP, HTTP, SMTP i mnoge druge.

TL;DR

HTTP (Hypertext Transfer Protocol) je aplikacijski protokol pomoću kojeg server šalje stranice našem pretraživaču. HTTP je sada sveprisutan na World Wide Webu za preuzimanje informacija sa web stranica. Na slici je lampa na mikrokontroleru sa ugrađenim operativnim sistemom u kojem se boje podešavaju preko pretraživača.

HTTP protokol je baziran na tekstu i prilično je jednostavan. Zapravo, ovako izgleda GET metoda koju uslužni program netcat šalje na lokalnu IPv6 adresu servera sa svjetlima:

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

HTTP metoda je obično kratka engleska riječ napisana velikim slovima, osjetljiva na velika i mala slova. Svaki server mora podržavati barem metode GET i HEAD. Pored metoda GET i HEAD, često se koriste metode POST, PUT i DELETE. Metoda GET se koristi za traženje sadržaja navedenog resursa, u našem slučaju ovdje GET /b HTTP/1.0 gdje je /b putanja odgovorna za boju (plava). Odgovor servera:

HTTP/1.0 200 OK Server: Contiki/2.4 http://www.sics.se/contiki/ Veza: zatvori Cache-Control: bez predmemorije, bez skladištenja, mora se ponovo potvrditi Pragma: bez keširanja Ističe: 0 Sadržaj- tip: text/html

Crvena je ISKLJUČENA

Zelena je ISKLJUČENA

Plava je UKLJUČENA

Statusni kod (imamo 200) je dio prvog reda odgovora servera. To je trocifreni cijeli broj. Prva cifra označava statusnu klasu. Šifra odgovora obično je praćena razmakom razdvojenom frazom objašnjenja na engleskom, koja osobi objašnjava razlog takvog odgovora. U našem slučaju server je radio bez grešaka, sve je bilo na gomili (OK).

I zahtjev i odgovor sadrže zaglavlja (svaki red je zasebno polje zaglavlja, par ime-vrijednost je odvojen dvotočkom). Zaglavlja završavaju praznim redom, nakon čega mogu slijediti podaci.

Moj pretraživač odbija da otvori lokalnu IPv6 adresu, tako da je dodatna adresa registrovana u firmveru mikrokontrolera i isti prefiks mora biti dodeljen i virtuelnom mrežnom interfejsu simulatora:

~$ sudo ip addr add abcd::1/64 dev mazko # linux ~$ netsh interfejs ipv6 postavi adresu mazko abcd::1 # windows ~$ curl http://

Klijent-server aplikacija na TCP stream socketu

Sljedeći primjer koristi TCP za pružanje uređenih, pouzdanih dvosmjernih tokova bajtova. Hajde da napravimo kompletnu aplikaciju koja uključuje klijenta i servera. Prvo, demonstriramo kako konstruirati server na TCP stream utičnicama, a zatim i klijentsku aplikaciju za testiranje našeg servera.

Sljedeći program kreira server koji prima zahtjeve za povezivanje od klijenata. Server se gradi sinhrono, stoga je izvršenje niti blokirano sve dok server ne pristane da se poveže sa klijentom. Ova aplikacija pokazuje jednostavan server koji odgovara klijentu. Klijent prekida vezu slanjem poruke serveru .

TCP server

Kreiranje strukture servera prikazano je na sljedećem funkcionalnom dijagramu:

Evo kompletnog koda za program SocketServer.cs:

// SocketServer.cs koristeći System; koristeći System.Text; koristeći System.Net; koristeći System.Net.Sockets; imenski prostor SocketServer ( klasa Program ( static void Main(string args) ( // Postavite lokalnu krajnju tačku za utičnicu IPHostEntry ipHost = Dns.GetHostEntry("localhost"); IPAddress ipAddr = ipHost.AddressList; IPEndPoint ipPEndPoint, new IpEndPoint, new 11000 ); // Kreirajte Tcp/Ip utičnicu Socket sListener = new Socket(ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp); // Dodijelite utičnicu lokalnoj krajnjoj točki i osluškujte dolazne utičnice pokušajte ( sListener.Point)(ipEnd ; sListener. Listen(10); // Počni osluškivati ​​veze dok (true) ( ​​Console.WriteLine("Čeka se konekcija na portu (0)", ipEndPoint); // Program se pauzira, čekajući dolazni konekcija Rukovalac utičnice = sListener.Accept(); string data = null; // Čekali smo da se klijent pokuša povezati s nama byte bytes = new byte; int bytesRec = handler.Receive(bytes); data += Encoding.UTF8. GetString(bytes, 0, bytesRec); // Prikaži podatke na konzoli Console.Write("Primljeno tekst: " + podaci + "\n\n"); // Slanje odgovora klijentu\ string reply = "Hvala na zahtjevu u " + data.Length.ToString() + " znakovima"; byte msg = Encoding.UTF8.GetBytes(reply); handler.Send(msg); ako (data.IndexOf(" ") > -1) ( Console.WriteLine("Server je prekinuo vezu sa klijentom."); prekid; ) handler.Shutdown(SocketShutdown.Both); handler.Close(); ) ) catch (Exception ex) ( Console.WriteLine (ex.ToString()); ) konačno ( Console.ReadLine(); ) ) ) )

Pogledajmo strukturu ovog programa.

Prvi korak je postavljanje lokalne krajnje točke za utičnicu. Prije otvaranja utičnice za slušanje veza, morate pripremiti adresu lokalne krajnje točke za nju. Jedinstvena TCP/IP adresa usluge određena je kombinacijom IP adrese domaćina sa brojem servisnog porta koji kreira krajnju tačku usluge.

Dns klasa pruža metode koje vraćaju informacije o mrežnim adresama koje podržava uređaj na lokalnoj mreži. Ako LAN uređaj ima više od jedne mrežne adrese, Dns klasa vraća informacije o svim mrežnim adresama, a aplikacija mora odabrati odgovarajuću adresu za posluživanje iz niza.

Kreirajte IPEndPoint za server kombinovanjem prve IP adrese domaćina dobijene metodom Dns.Resolve() sa brojem porta:

IPHostEntry ipHost = Dns.GetHostEntry("localhost"); IPAddress ipAddr = ipHost.AddressList; IPEndPoint ipEndPoint = nova IPEndPoint(ipAddr, 11000);

Ovdje klasa IPEndPoint predstavlja localhost na portu 11000. Zatim kreiramo stream socket sa novom instancom klase Socket. Postavljanjem lokalne krajnje točke za slušanje veza, možete kreirati utičnicu:

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

Nabrajanje AdresaPorodica specificira šeme adresiranja koje instanca klase Socket može koristiti za rješavanje adrese.

U parametru SocketType TCP i UDP utičnice se razlikuju. Može uključivati ​​sljedeće vrijednosti:

dgram

Podržava datagrame. Vrijednost Dgram zahtijeva da navedete Udp za tip protokola i InterNetwork u parametru porodice adresa.

Sirova

Podržava pristup osnovnom transportnom protokolu.

Potok

Podržava stream utičnice. Vrijednost Stream zahtijeva da se Tcp navede za tip protokola.

Treći i posljednji parametar specificira tip protokola potrebnog za utičnicu. U parametru ProtocolType možete odrediti sljedeće najvažnije vrijednosti - Tcp, Udp, Ip, Raw.

Sljedeći korak bi trebao biti dodjeljivanje utičnice metodom Bind(). Kada konstruktor otvori soket, njemu se ne dodeljuje ime, već je rezervisan samo rukohvat. Bind() metoda se poziva da dodijeli ime serverskoj utičnici. Da bi klijentska utičnica mogla identificirati utičnicu TCP toka, serverski program mora imenovati svoju utičnicu:

SListener.Bind(ipEndPoint);

Metoda Bind() povezuje utičnicu s lokalnom krajnjom točkom. Morate pozvati metodu Bind() prije bilo kakvog pokušaja pozivanja metoda Listen() i Accept().

Sada, nakon kreiranja utičnice i povezivanja imena s njim, možete slušati dolazne poruke koristeći metodu slušaj(). U stanju slušanja, utičnica će čekati na dolazne pokušaje povezivanja:

SListener.Listen(10);

Parametar definira zaostatak (zaostatak) A koji specificira maksimalan broj veza koje čekaju da budu obrađene u redu čekanja. U gornjem kodu, vrijednost parametra omogućava da se do deset veza akumulira u redu čekanja.

U stanju slušanja, morate biti spremni da pristanete na povezivanje s klijentom, za koji se metoda koristi prihvati(). Ova metoda dobiva klijentsku vezu i dovršava asocijaciju između imena klijenta i poslužitelja. Metoda Accept() blokira nit pozivajućeg programa sve dok se ne primi veza.

Metoda Accept() preuzima prvi zahtjev za povezivanje iz reda zahtjeva na čekanju i kreira novu utičnicu za rukovanje. Dok je nova utičnica kreirana, originalna utičnica nastavlja da sluša i može se koristiti sa višenitnošću za prihvatanje višestrukih zahtjeva za povezivanje od klijenata. Nijedna serverska aplikacija ne bi trebala zatvoriti utičnicu za slušanje. Mora nastaviti da funkcionira zajedno sa utičnicama kreiranim metodom Accept za obradu dolaznih zahtjeva klijenata.

Dok (true) ( ​​Console.WriteLine("Čeka se konekcija na portu (0)", ipEndPoint); // Program pauzira, čeka dolaznu vezu Socket handler = sListener.Accept();

Kada klijent i server uspostave vezu između sebe, možete slati i primati poruke koristeći ove metode Pošalji() i primiti() Socket class.

Metoda Send() zapisuje odlazne podatke u soket na koji je povezan. Metoda Receive() čita dolazne podatke na stream socketu. Kada koristite sistem baziran na TCP-u, mora se uspostaviti veza između utičnica prije nego što se izvrše metode Send() i Receive(). Tačan protokol između dva entiteta u interakciji mora biti određen unaprijed tako da klijentska i serverska aplikacija ne blokiraju jedna drugu, ne znajući ko bi trebao prvi poslati svoje podatke.

Kada je razmjena podataka između servera i klijenta završena, morate zatvoriti vezu koristeći metode ugasiti() i Zatvori():

Handler.Shutdown(SocketShutdown.Both); handler.Close();

SocketShutdown je enum koji sadrži tri vrijednosti koje treba zaustaviti: Oba- zaustavlja slanje i primanje podataka na utičnici, primiti- prestaje primati podatke na utičnicu i poslati- zaustavlja slanje podataka utičnicom.

Utičnica se zatvara kada se pozove metoda Close(), koja takođe postavlja svojstvo Connected utičnice na false.

Klijent na TCP-u

Funkcije koje se koriste za kreiranje klijentske aplikacije su manje-više slične serverskoj aplikaciji. Što se tiče servera, iste metode se koriste za određivanje krajnje tačke, instanciranje utičnice, slanje i primanje podataka i zatvaranje utičnice.