TCP se prirodno integrira u okruženje klijent/poslužitelj (vidi sliku 10.1). Aplikacija poslužitelja sluša(slušati) dolazne zahtjeve za povezivanje. Na primjer, usluge WWW, Prijenos datoteka ili Terminal Access slušaju zahtjeve klijenata. Komunikaciju u TCP-u pokreću odgovarajući potprogrami, koji pokreću vezu s poslužiteljem (vidi poglavlje 21 o sučelju za programiranje utičnice).
Riža. 10.1. Klijent poziva poslužitelj.
U stvarnosti, klijent može biti drugi poslužitelj. Na primjer, poslužitelji e-pošte mogu se povezati s drugim poslužiteljima e-pošte kako bi prosljeđivali poruke e-pošte između računala.
10.2 TCP koncepti
U kojem obliku bi aplikacije trebale slati podatke preko TCP-a? Kako TCP prenosi podatke na IP? Kako TCP protokoli za slanje i primanje identificiraju vezu između aplikacija i podataka potrebnih za implementaciju? Na sva ova pitanja odgovoreno je u sljedećim odjeljcima koji opisuju osnovne TCP koncepte.
10.2.1 Ulazni i izlazni tokovi podataka
Konceptualni model povezivanja pretpostavlja da aplikacija šalje tok podataka ravnopravnoj aplikaciji. Istodobno, može primati tok podataka od svog partnera za povezivanje. TCP pruža puni dupleks(full duplex) način rada u kojem se istovremeno dva toka podataka (vidi sliku 10.2).
Riža. 10.2. Aplikacije razmjenjuju tokove podataka.
10.2.2 Segmenti
TCP može transformirati tok podataka koji napušta aplikaciju u oblik prikladan za postavljanje u datagrame. Kako?
Aplikacija prenosi podatke u TCP-u, a ovaj ih protokol stavlja izlazni međuspremnik(spremnik 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 međuspremnik TCP je pakiran u segmente. TCP prenosi segment na IP za isporuku kao poseban datagram. Pakiranje podataka u komade ispravne duljine osigurava da se podaci šalju učinkovito, tako da će TCP pričekati dok se odgovarajuća količina podataka ne pojavi u izlaznom međuspremniku prije kreiranja segmenta.
Riža. 10.3 Izrada TCP segmenta
10.2.3 Izbacivanje
Međutim, velike količine podataka često je nemoguće primijeniti na aplikacije u stvarnom svijetu. Na primjer, kada klijentski program krajnjeg korisnika pokrene interaktivnu sesiju s udaljenim poslužiteljem, tada korisnik samo unosi naredbe (slijeđeno pritiskom na Povratak).
Korisnički klijentski program treba TCP da zna o slanju podataka udaljenom hostu i da to odmah učini. U ovom slučaju koristite izbacivanje(gurnuti).
Ako pogledate operacije u interaktivnoj sesiji, možete pronaći mnogo segmenata s malo podataka, a štoviše, neravnine se mogu naći u gotovo svakom segmentu podataka. Međutim, push se ne bi trebao primjenjivati tijekom prijenosa datoteka (osim za posljednji segment), a TCP će moći najučinkovitije pakirati podatke u segmente.
10.2.4 Hitni podaci
Model prosljeđivanja aplikacije pretpostavlja primjenu uređenog toka bajtova koji putuje do odredišta. Pozivajući se ponovno na primjer interaktivne sesije, pretpostavimo da je korisnik pritisnuo tipku pažnja(pažnja) ili pauza(prekinuti). Udaljena aplikacija mora moći preskočiti bajtove koji ometaju i odgovoriti na pritisak tipke što je prije moguće.
Mehanizam hitni podaci(hitni podaci) označava posebne informacije u segmentu kao hitno. Na taj način TCP obavještava svog partnera da segment sadrži hitne podatke i može naznačiti gdje se nalazi. Partner bi trebao proslijediti ove podatke odredišnoj aplikaciji što je prije moguće.
10.2.5 Priključci aplikacije
Klijent mora identificirati uslugu kojoj želi pristupiti. To se postiže specifikacijom IP adrese usluge hosta i broja TCP porta. Kao i kod UDP-a, brojevi TCP portova kreću se od 0 do 65535. Portovi u rasponu od 0 do 1023 nazivaju se dobro poznatim i koriste se za pristup standardnim uslugama.
Nekoliko primjera dobro poznatih portova i njihovih odgovarajućih aplikacija prikazano je u tablici 10.1. Usluge Odbaciti(luka 9) i chargen(port 19) su TCP verzije usluga koje već poznajemo iz UDP-a. Zapamtite da je promet TCP porta 9 potpuno izoliran od prometa UDP porta 9.
Tablica 10.1 Općepoznati TCP portovi i njihove odgovarajuće aplikacije
| Luka | dodatak | Opis |
|---|---|---|
| 9 | Odbaciti | Otkazivanje svih dolaznih podataka |
| 19 | Chargen | Generator simbola. Razmjena toka znakova |
| 20 | FTP-podaci | FTP port za prosljeđivanje podataka |
| 21 | FTP | Port za FTP razgovor |
| 23 | TELNET | Port za udaljenu Telnet registraciju |
| 25 | SMTP | SMTP port |
| 110 | POP3 | Dohvaćanje usluge pošte za osobna računala |
| 119 | NNTP | Pristup online vijestima |
Što je s portovima koje koriste klijenti? U rijetkim slučajevima, klijent ne radi preko dobro poznatog porta. Ali u takvim situacijama, želeći otvoriti vezu, često traži od operativnog sustava da mu dodijeli neiskorišteni i nerezervirani port. Po završetku veze, klijent je dužan vratiti ovaj port natrag, nakon čega port može ponovno koristiti drugi klijent. Budući da postoji više od 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 utičnica. TCP veza je u potpunosti identificirana adresom utičnice na svakom kraju te veze. Na sl. 10.4 prikazuje vezu između klijenta na utičnici (128.36.1.24, port = 3358) i poslužitelja na utičnici (130.42.88.22, port = 21).
Riža. 10.4. Adrese utičnica
Svako zaglavlje datagrama sadrži izvornu i odredišnu IP adresu. Kasnije će se vidjeti da su brojevi izvornog i odredišnog porta naznačeni u zaglavlju TCP segmenta.
Poslužitelj je obično sposoban upravljati više klijenata u isto vrijeme. Jedinstvene adrese utičnice poslužitelja dodijeljene su istovremeno svim njegovim klijentima (vidi sliku 10.5).
Riža. 10.5. Više klijenata povezanih na adrese utičnice poslužitelja
Budući da datagram sadrži segment TCP veze identificiran IP adresama i portovima, poslužitelju je vrlo lako pratiti višestruke klijentske veze.
10.3 TCP mehanizam pouzdanosti
U ovom ćemo odjeljku pogledati TCP mehanizam koji se koristi za pouzdanu isporuku podataka uz održavanje redoslijeda prosljeđivanja i izbjegavanje gubitka ili dupliciranja.
10.3.1 Numeriranje i potvrda
TCP koristi numeriranje i potvrdu (ACK) kako bi osigurao pouzdan prijenos podataka. Shema TCP numeriranja je pomalo neobična: svaki veza proslijeđena oktet smatra se da ima redni broj. Zaglavlje TCP segmenta sadrži redni broj prvi oktet podataka ovog segmenta.
Primatelj je dužan potvrditi primitak podataka. Ako ACK ne stigne unutar vremenskog intervala, podaci se ponovno šalju. Ova metoda se zove pozitivna potvrda s relejem(pozitivna potvrda s ponovnim prijenosom).
TCP primatelja pomno prati dolazne sekvencijske brojeve kako bi osigurao da se podaci primaju na dosljedan način i da nema dijelova koji nedostaju. Budući da se ACK-ovi mogu nasumično izgubiti ili odgoditi, duplicirani segmenti mogu stići do primatelja. Brojevi u slijedu omogućuju vam da identificirate duplicirane podatke koji se zatim odbacuju.
Na sl. 10.6 prikazuje pojednostavljeni pogled na TCP timeout i ponovni prijenos.
Riža. 10.6. Istek i ponovni prijenos u TCP-u
10.3.2 Polja porta, slijeda i ACK u TCP zaglavlju
Kao što je prikazano na sl. 10.7, prvih nekoliko polja TCP zaglavlja pruža prostor za izvorne i odredišne portove, 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 vršnjaka, ovo će polje imati vrijednost 31, što označava segment za prosljeđivanje.
Riža. 10.7. Početne vrijednosti u poljima TCP zaglavlja
Treba napomenuti jedan mali detalj. Pretpostavimo da je TCP poslao bajtove od 1 do 50 ili više, nema podataka za slanje. Ako podatke primi od partnera, TCP je dužan potvrditi njihov primitak, za što će poslati zaglavlje bez podataka povezanih s njim. Naravno, ovo zaglavlje sadrži ACK vrijednost. Polje sekvence sadrži vrijednost 51, tj. broj sljedećeg bajta koji namjerava poslati TCP. Kada TCP pošalje sljedeće podatke, novo TCP zaglavlje će također imati vrijednost 51 u polju slijeda.
10.4 Uspostavljanje veze
Kako se dvije aplikacije povezuju jedna s drugom? Prije komunikacije, svaki od njih poziva potprogram za formiranje memorijskog bloka koji će se koristiti za pohranjivanje TCP i IP parametara ove veze, na primjer, adrese utičnice, trenutni redni broj, početnu vrijednost životnog vijeka itd.
Poslužiteljska aplikacija čeka da se pojavi klijent, koji, želeći pristupiti poslužitelju, izdaje zahtjev spoj(povezivanje) identificiranje IP adrese i porta poslužitelja.
Postoji jedna tehnička posebnost. Svaka strana počinje numeriranje svakog bajta ne s jednim, već s slučajni redni broj(u nastavku ćemo saznati zašto se to radi). Izvorna specifikacija savjetuje: generirajte početni broj sekvence na temelju 32-bitnog vanjskog mjerača vremena koji se povećava otprilike svaka 4 μs.
10.4.1 Skripta za povezivanje
Postupak povezivanja se često naziva trosmjernim rukovanjem jer se za uspostavljanje veze razmjenjuju tri poruke — SYN, SYN i ACK.
Tijekom postavljanja veze, partneri razmjenjuju tri važne informacije:
1. Količina međuspremnika za primanje 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 primjenjuje operacije 1 i 2 za označavanje granice unutar kojih će druga strana djelovati. Osobno računalo može imati mali međuspremnik za primanje, a superračunalo može imati veliki međuspremnik. Memorijska struktura osobnog računala može ograničiti dolazne dijelove podataka na 1 KB, a superračunalo se kontrolira velikim segmentima.
Mogućnost kontrole načina na koji druga strana šalje podatke važno je svojstvo za TCP/IP skalabilnost.
Na sl. 10.8 prikazuje primjer skripte za povezivanje. Prikazani su vrlo jednostavni početni sekvencijalni brojevi kako ne bi preopteretili crtež. Imajte na umu da na ovoj slici klijent može primiti veće segmente od poslužitelja.
Riža. 10.8. Uspostavljanje veze
Izvode se sljedeće operacije:
1. Poslužitelj se inicijalizira i postaje spreman za povezivanje s klijentima (ovo stanje se naziva pasivno otvoreno).
2. Klijent traži od TCP-a da otvori vezu s poslužiteljem na navedenoj IP adresi i portu (ovo stanje se naziva aktivno otvoreno).
3. TCP klijenta prima početni redni broj (u ovom primjeru - 1000) i šalje sinkronizirani segment(sinkroniziraj segment - SYN). Ovaj segment nosi redni broj, veličinu prozora za primanje (4K) i najveći segment koji klijent može prihvatiti (1460 bajtova).
4. Kada stigne SYN, poslužitelj TCP prima rudnik početni redni broj (3000). Šalje SYN segment koji sadrži početni broj sekvence (3000), ACK 1001 (što znači da je prvi bajt poslan od strane klijenta označen brojem 1001), veličinu prozora za primanje (4K) i najveći segment koji poslužitelj može primiti (1024 bajta ).
5. Klijentski TCP, nakon što je primio SYN / ACK poruku od poslužitelja, šalje natrag ACK 3001 (prvi bajt podataka koje šalje poslužitelj treba biti označen brojem 3001).
6. Klijent TCP daje upute svojoj aplikaciji da otvori vezu.
7. Poslužiteljski TCP, nakon što je primio ACK poruku od klijentskog TCP-a, obavještava svoju aplikaciju o otvaranju veze.
Klijent i poslužitelj objavljuju svoja pravila za primljene podatke, sinkroniziraju svoje redovne brojeve i postaju spremni za razmjenu podataka. TCP specifikacija također dopušta drugi (ne baš uspješan) scenarij u kojem se ravnopravne aplikacije istovremeno aktivno otvaraju jedna drugu.
10.4.2 Postavljanje vrijednosti IP parametara
Zahtjev za povezivanje aplikacije također može specificirati parametre za IP datagrame koji će nositi podatke za tu vezu. Ako nije navedena specifična vrijednost parametra, koristi se zadana vrijednost.
Na primjer, aplikacija može odabrati željenu vrijednost za IP prioritet ili vrstu usluge. Budući da svaka od povezanih strana samostalno postavlja svoj prioritet i vrstu usluge, teoretski se te vrijednosti mogu razlikovati za različite smjerove protoka podataka. U pravilu se u praksi koriste iste vrijednosti za svaki smjer razmjene.
Kada aplikacija koristi sigurnosne opcije za vladine ili vojne agencije, svaka od krajnjih točaka veze mora koristiti iste razine sigurnosti ili se veza neće uspostaviti.
10.5 Prijenos podataka
Prijenos podataka počinje nakon dovršetka potvrde stvaranja veze u tri koraka (vidi sliku 10.9). TCP standard omogućuje uključivanje normalnih podataka u segmente potvrde, ali neće biti isporučeni aplikaciji dok se veza ne dovrši. Radi lakšeg numeriranja koriste se 1000-bajtne poruke. Svaki segment TCP zaglavlja ima ACK polje koje identificira redni broj bajta za koji se očekuje da će biti primljen od ravnopravnog partnera na vezi..
Riža. 10.9. Jednostavan protok podataka i ACK
Prvi segment koji šalje klijent sadrži bajtove od 1001 do 2000. Njegovo ACK polje treba sadržavati vrijednost 3001, što označava redni broj bajta koji bi trebao biti primljen od poslužitelja.
Poslužitelj odgovara klijentu segmentom koji sadrži 1000 bajtova podataka (počevši od 3001). Njegovo polje ACK TCP zaglavlja će naznačiti da su bajtovi od 1001 do 2000 već uspješno primljeni, tako da bi sljedeći očekivani redni broj segmenta trebao biti 2001.
Klijent tada šalje segmente počevši od bajtova 2001, 3001 i 4001 tim redoslijedom. Imajte na umu da klijent ne očekuje ACK nakon svakog poslanog segmenta. Podaci se šalju partneru dok se njegov međuspremnik ne napuni (u nastavku ćemo vidjeti da primatelj može vrlo precizno naznačiti količinu podataka koja mu se šalje).
Poslužitelj čuva širinu pojasa korištenjem jednog ACK-a za označavanje uspješnog prosljeđivanja svih segmenata.
Na sl. 10.10 prikazuje prijenos podataka kada se izgubi prvi segment. Kada istekne vremensko ograničenje, segment se ponovno prenosi. Imajte na umu da nakon primitka izgubljenog segmenta, primatelj šalje jedan ACK koji potvrđuje da su oba segmenta poslana.
Riža. 10.10. Gubitak podataka i ponovni prijenos
10.6 Zatvaranje veze
Normalni prekid veze postiže se istim postupkom trostrukog rukovanja kao i prilikom otvaranja veze. Svaka od 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 scenarij je također prihvatljiv (iako se rijetko koristi):
O:"Gotov sam. Nemam više podataka za slanje."
V:"Dobro. Međutim, postoje neki podaci..."
V:– I ja sam završio posao.
O:"Dobro".
U primjeru u nastavku, veza zatvara poslužitelj, kao što je često slučaj za komunikaciju klijent/poslužitelj. U ovom slučaju, nakon što korisnik uđe u sesiju telnet naredbe za odjavu poslužitelj pokreće zahtjev za zatvaranje veze. U situaciji prikazanoj na sl. 10.11 izvode se sljedeće radnje:
1. Aplikacija na poslužitelju govori TCP-u da zatvori vezu.
2. TCP poslužitelj šalje završni segment (FIN) obavještavajući svog partnera da više nema podataka za slanje.
3. Klijentov TCP šalje ACK na FIN segment.
4. TCP klijenta govori svojoj aplikaciji da poslužitelj želi zatvoriti vezu.
5. Klijentska aplikacija govori svom TCP-u da zatvori vezu.
6. TCP klijenta šalje FIN poruku.
7. TCP poslužitelj prima FIN od klijenta i odgovara ACK porukom.
8. TCP poslužitelj daje upute svojoj aplikaciji da zatvori vezu.
Riža. 10.11. Zatvaranje veze
Obje strane mogu početi zatvarati u isto vrijeme. U ovom slučaju, normalno zatvaranje veze je završeno nakon što svaki partner pošalje ACK poruku.
10.6.1 Nagli prekid
Svaka od strana može zatražiti naglo prekid veze. To je prihvatljivo kada aplikacija želi prekinuti vezu ili kada TCP naiđe na ozbiljan komunikacijski problem koji ne može riješiti sama. Iznenadni prekid se zahtijeva slanjem jedne ili više poruka za resetiranje ravnopravnom uređaju, kao što je naznačeno posebnom zastavicom u TCP zaglavlju.
10.7 Kontrola protoka
TCP prijamnik se učitava s dolaznim protokom podataka i određuje koliko informacija može primiti. Ovo ograničenje utječe na TCP pošiljatelja. Objašnjenje u nastavku za ovaj mehanizam je konceptualno, a programeri ga mogu implementirati na različite načine u svoje proizvode.
Tijekom postavljanja veze, svaki partner dodjeljuje prostor za ulazni međuspremnik veze i o tome obavještava drugu stranu. Obično se veličina međuspremnika izražava kao cijeli broj maksimalnih veličina segmenta.
Tok podataka ulazi u ulazni međuspremnik i tamo se pohranjuje prije nego što se pošalje aplikaciji (određuje TCP port). Na sl. 10.12 prikazuje ulazni međuspremnik koji može prihvatiti 4KB.
Riža. 10.12. Prozor za primanje ulaznog međuspremnika
Prostor međuspremnika se puni kako podaci pristižu. Kada aplikacija primateljica dohvati podatke iz međuspremnika, oslobođeni prostor postaje dostupan za nove dolazne podatke.
10.7.1 Prozor za primanje
Prozor za primanje(prozor za primanje) - bilo koji prostor u ulaznom međuspremniku koji još nije zauzet podacima. Podaci ostaju u ulaznom međuspremniku dok ih ciljna aplikacija ne potroši. Zašto aplikacija ne preuzima podatke odmah?
Jednostavan scenarij pomoći će odgovoriti na ovo pitanje. Pretpostavimo da je klijent prenio datoteku na FTP poslužitelj koji radi na vrlo zauzetom višekorisničkom računalu. FTP program tada mora pročitati podatke iz međuspremnika i zapisati ih na disk. Kada poslužitelj izvodi disk I/O operacije, program čeka da se te operacije dovrše. U tom trenutku može se pokrenuti drugi program (na primjer, prema rasporedu) i dok se FTP program ponovno pokrene, sljedeći podaci će već stizati u međuspremnik.
Prozor za primanje proširuje se od posljednjeg potvrđenog bajta do kraja međuspremnika. Na sl. 10.12 prvo, cijeli međuspremnik je dostupan i stoga je dostupan prozor za primanje od 4 KB. Kada stigne prvi KB, prozor primanja će se smanjiti na 3 KB (radi jednostavnosti, pretpostavit ćemo da je svaki segment 1 KB, iako u praksi ta vrijednost varira ovisno o potrebama aplikacije). Dolazak sljedeća dva segmenta od 1 KB smanjit će prozor za primanje na 1 KB.
Svaki ACK koji šalje primatelj sadrži informaciju o trenutnom stanju prozora za primanje, ovisno o tome koji je protok podataka iz izvora reguliran.
Većinom se veličina ulaznog međuspremnika postavlja u vrijeme pokretanja veze, iako TCP standard ne navodi kako se postupa s tim međuspremnikom. Ulazni međuspremnik može rasti ili se smanjiti kako bi pošiljaocu pružio povratnu informaciju.
Što se događa ako se dolazni segment može postaviti u prozor za primanje, ali nije stigao u redu? Općenito se pretpostavlja da sve implementacije spremaju dolazne podatke u prozor za primanje i šalju potvrdu (ACK) samo za cijeli susjedni blok od nekoliko segmenata. Ovo je ispravna metoda, jer će u suprotnom odbacivanje podataka koji nisu u redu značajno pogoršati performanse.
10.7.2 Prozor za slanje
Sustav koji prenosi podatke mora pratiti dvije karakteristike: koliko je podataka već poslano i potvrđeno te trenutnu veličinu primateljevog prozora za primanje. Aktivan otpremni prostor(razmak za slanje) proširuje se od prvog nepriznatog okteta lijevo od trenutnog prozora za primanje. Dio prozor korišten od poslati, označava koliko se dodatnih podataka može poslati partneru.
Početni redni broj i početna veličina prozora za primanje postavljaju se tijekom postavljanja veze. Riža. 10.13 ilustrira neke od značajki mehanizma prijenosa podataka.
1. Pošiljatelj počinje s prozorom za slanje od 4 KB.
2. Pošiljatelj šalje 1 KB. Kopija ovih podataka čuva se dok se ne primi potvrda (ACK), jer će se možda morati ponovno prenijeti.
3. Stiže ACK poruka 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, stiže ACK za sve poslane podatke (tj. sve primljene od strane primatelja). ACK vraća veličinu prozora za slanje na 4K.
Riža. 10.13. Pošalji prozor
Treba istaknuti nekoliko zanimljivih značajki:
S Pošiljatelj ne čeka ACK za svaki segment podataka koji šalje. Jedino ograničenje prijenosa je veličina prozora za primanje (na primjer, pošiljatelj bi trebao poslati samo 4K jednobajtne segmente).
S Pretpostavimo da pošiljatelj šalje podatke u nekoliko vrlo kratkih segmenata (na primjer, 80 bajtova). U tom slučaju, podaci se mogu preoblikovati za učinkovitiji prijenos (na primjer, u jedan segment).
10.8 TCP zaglavlje
Na sl. 10.14 prikazuje format segmenta (TCP zaglavlje i podaci). Zaglavlje počinje ID-ovima izvornog i odredišnog porta. Sljedeće 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 će se pojaviti u toku ulaznih podataka.
Riža. 10.14. TCP segment
Postoji šest zastava:
Polje pristranost podataka(Odmak 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 za maksimalnu veličinu segmenta
Parametar "maksimalna veličina segmenta"(maksimalna veličina segmenta - MSS) se koristi za oglašavanje najvećeg dijela podataka koji sustav može primiti i obraditi. Međutim, naslov je pomalo netočan. Obično u TCP-u segment tretira kao zaglavlje plus podaci. ali maksimalna veličina segmenta definirano kao:
Najveći datagram koji možete prihvatiti je 40
Drugim riječima, MSS odražava najveće nosivost u prijemniku s duljinom TCP i IP zaglavlja od 20 bajtova. Ako postoje dodatni parametri, njihovu duljinu treba oduzeti od ukupne veličine. Stoga je količina podataka koja se može poslati u segmentu definirana kao:
MSS deklarirana vrijednost + 40 - (zbroj duljina TCP i IP zaglavlja)
Peers obično razmjenjuju MSS vrijednosti u početnim SYN porukama kada je veza otvorena. Ako sustav ne oglašava maksimalnu veličinu segmenta, koristi se zadana vrijednost od 536 bajtova.
Veličina maksimalnog segmenta je kodirana s 2-bajtnom preambulom nakon koje slijedi 2-bajtna vrijednost, tj. najveća vrijednost će biti 2 16 -1 (65 535 bajtova).
MSS nameće tvrdo ograničenje na podatke poslane na TCP: prijemnik neće moći obraditi velike vrijednosti. Međutim, pošiljatelj koristi segmente manji, jer je za vezu određen i MTU duž puta.
10.8.2 Korištenje polja zaglavlja u zahtjevu za povezivanje
Prvi segment poslan za otvaranje veze ima SYN oznaku 1 i ACK oznaku 0. Početni SYN je jedini segment koji ima ACK polje 0. Imajte na umu da sigurnost koristi ovu značajku 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 primanje. Jedini trenutno definirani TCP parametar je maksimalna veličina segmenta (kada nije navedena, zadana vrijednost je 536 bajtova) koju TCP očekuje da primi. Ova vrijednost je duga 32 bita i obično je prisutna u zahtjevu za povezivanje u polju opcije(Opcija). TCP zaglavlje koje sadrži MSS vrijednost ima 24 bajta.
10.8.3 Korištenje polja zaglavlja u odgovoru na vezu
U odgovoru za omogućavanje na zahtjev za povezivanje, obje zastavice (SYN i ACK) jednake su 1. Sustav koji odgovara označava početni broj sekvence u odgovarajućem polju i veličinu prozora za primanje u polju Prozor... Maksimalna veličina segmenta koju primatelj želi koristiti obično se nalazi u odgovoru na zahtjev za povezivanje (u opcije). Ova vrijednost može biti različita od vrijednosti strane koja je zatražila povezivanje, tj. mogu se koristiti dvije različite vrijednosti.
Zahtjev za povezivanje može se odbiti navođenjem zastavice za resetiranje (RST) s vrijednošću 1 u odgovoru.
10.8.4 Odabir početnog rednog broja
TCP specifikacija pretpostavlja da tijekom uspostavljanja veze svaka strana bira početni redni broj(na trenutnoj vrijednosti 32-bitnog internog mjerača vremena). Kako se to radi?
Zamislite što se događa kada se sustav sruši. Recimo da je korisnik otvorio vezu neposredno prije pada i poslao malu količinu podataka. Nakon oporavka, sustav više ne pamti ništa što je učinjeno prije pada, uključujući već pokrenute veze i dodijeljene brojeve portova. Korisnik ponovno uspostavlja vezu. Brojevi portova ne odgovaraju izvornim zadacima, a neke od njih možda već koriste druge veze uspostavljene nekoliko sekundi prije pada.
Stoga druga strana na samom kraju veze možda i ne zna da je njezin partner doživio kolaps i da mu je tada rad obnovljen. Sve će to dovesti do ozbiljnih poremećaja, pogotovo kada je potrebno dugo vremena da stari podaci putuju mrežom i pomiješaju se s podacima iz novostvorene veze. Odabir timera za novi početak eliminira takve probleme. Stari podaci imat će različitu numeraciju od raspona slijednih brojeva nove veze. Hakeri, kada krivotvore izvornu IP adresu za pouzdani host, pokušavaju dobiti pristup računalima navodeći predvidljivi početni broj sekvence u poruci. Kriptografska hash funkcija koja se temelji na internim ključevima najbolji je način odabira sigurnih početnih brojeva.
10.8.5 Uobičajena uporaba polja
Prilikom pripreme TCP zaglavlja za prijenos, u polju se navodi redni broj prvog okteta prenesenih podataka redni broj(Redni broj).
U polje se upisuje sljedeći broj okteta koji se očekuje od poveznog partnera potvrda(Broj potvrde) kada je ACK bit postavljen na 1. Polje prozor(Prozor) je za trenutnu veličinu prozora za primanje. Ovo polje sadrži broj bajtova iz broja potvrde koji se može prihvatiti... Imajte na umu da ova vrijednost omogućuje preciznu kontrolu protoka podataka. Koristeći ovu vrijednost, partner pokazuje stvarno stanje prozora za primanje tijekom sesije razmjene.
Ako aplikacija ukazuje na TCP push operaciju, tada je zastavica PUSH postavljena na 1. TCP primatelj MORA odgovoriti na ovu zastavicu brzom isporukom podataka aplikaciji čim ih pošiljatelj želi poslati.
Oznaka HITNO, ako je postavljena na 1, podrazumijeva hitan prijenos podataka, a odgovarajući pokazivač MORA se odnositi na zadnji oktet hitnih podataka. Tipična upotreba hitnih podataka je slanje signala otkazivanja ili prekida s terminala.
Često se nazivaju hitni podaci informacije izvan opsega(izvan benda). Međutim, ovaj izraz je netočan. Ubrzani podaci šalju se u redovnom TCP streamu, iako neke implementacije mogu imati posebne mehanizme da kažu aplikaciji da primi hitne podatke, a aplikacija mora provjeriti sadržaj hitnih podataka prije nego stignu svi bajtovi poruke.
Oznaka RESET postavljena je na 1 za prekid veze. Ista se zastavica postavlja u odgovoru kada stigne segment koji nije povezan ni s jednom od trenutnih TCP veza.
FIN je postavljen na 1 za poruke o zatvaranju veze.
10.8.6 Kontrolni zbroj
IP kontrolni zbroj je samo za IP zaglavlje, a TCP kontrolni zbroj se izračunava za cijeli segment kao i pseudo-zaglavlje generirano iz IP zaglavlja. Prilikom izračunavanja TCP kontrolnog zbroja, odgovarajuće polje je postavljeno na 0. Na sl. 10.15 prikazuje pseudo-zaglavlje vrlo slično onom korištenom u UDP kontrolnom zbroju.
Riža. 10.15. Polje pseudo-zaglavlja uključeno je u TCP kontrolni zbroj
Duljina TCP-a izračunava se dodavanjem duljine TCP zaglavlja s duljinom podataka. TCP kontrolni zbroj je obveznim, ne kao UDP. Primatelj prvo izračunava kontrolni zbroj primljenog segmenta, a zatim ga uspoređuje sa sadržajem polja kontrolnog zbroja TCP zaglavlja. Ako se vrijednosti ne podudaraju, segment se odbacuje.
10.9 Primjer TCP segmenta
Riža. 10.16, protokol analizatora Njuškalo od Network General, slijed je TCP segmenata. Prva tri segmenta uspostavljaju vezu između klijenta i poslužitelja Telnet... Posljednji segment nosi 12 bajtova podataka.
Riža. 10.16. Prikaz TCP zaglavlja pomoću Sniffer Analyzer
analizator Njuškalo prevodi većinu vrijednosti u decimalni. Međutim, vrijednosti zastavice izlaze kao heksadecimalne. Zastava s vrijednošću 12 je 010010. Kontrolni zbroj se također prikazuje u heksadecimalnom obliku.
10.10 Podrška sesiji
10.10.1 Ispitivanje prozora
Brzi pošiljatelj i spori primatelj mogu formirati prozor za primanje od 0 bajta. Ovaj rezultat se zove zatvorivši prozor(zatvori prozor). Kada ima slobodnog prostora za ažuriranje veličine prozora za primanje, koristi se ACK. Međutim, ako se takva poruka izgubi, obje strane će morati čekati u nedogled.
Kako bi izbjegao ovu situaciju, pošiljatelj postavlja pohranjeni mjerač vremena(persist timer) kada je prozor zatvoren. Vrijednost timera je vremensko ograničenje ponovnog prijenosa. Na kraju mjerača vremena, segment se šalje partneru zvučni prozor(sonda prozora; neke implementacije uključuju i podatke). Ispitivanje uzrokuje da peer pošalje natrag ACK koji izvješćuje o trenutnom statusu prozora.
Ako je veličina prozora još uvijek nula, vrijednost pohranjenog mjerača vremena se udvostručuje. Ovaj postupak se ponavlja sve dok mjerač vremena ne dosegne maksimalno 60 sekundi. TCP će nastaviti slati probne poruke svakih 60 sekundi – dok se prozor ne otvori, dok korisnik ne prekine proces ili dok aplikacija ne istekne.
10.11 Odjava
10.11.1 Istek
Partner za vezu može se srušiti ili biti potpuno prekinut zbog kvara pristupnika ili komunikacije. Postoji nekoliko mehanizama koji sprječavaju TCP od ponovnog slanja podataka.
Po dolasku do prvog praga za ponovni prijenos (prenos), TCP daje upute IP-u da provjeri neispravan usmjerivač i istovremeno obavještava aplikaciju o problemu. TCP nastavlja slati podatke dok se ne dosegne druga granična vrijednost i tek tada prekida vezu.
Naravno, prije nego što se to dogodi, može stići ICMP poruka u kojoj se navodi da je odredište iz nekog razloga nedostupno. U nekim implementacijama, čak i tada, TCP će nastaviti pokušavati doći do odredišta sve dok ne istekne vremenski interval (nakon čega se problem može riješiti). Zatim se aplikacija obavještava da je odredište nedostupno.
Aplikacija može postaviti vlastito vremensko ograničenje isporuke podataka i izvesti vlastite operacije na kraju ovog intervala. Veza je obično prekinuta.
10.11.2 Održavanje veze
Kada nepotpuna veza ima podatke za prijenos dulje vrijeme, dobiva status neaktivne. Tijekom razdoblja neaktivnosti može doći do rušenja mreže ili prekida veze fizičkih veza. Čim mreža ponovno postane operativna, partneri će nastaviti razmjenjivati podatke bez prekida komunikacijske sesije. Ova strategija bila je u skladu sa zahtjevima Ministarstva obrane.
Međutim, svaka veza - aktivna ili neaktivna - zauzima puno memorije računala. Neki administratori moraju vratiti neiskorištene resurse sustavima. Stoga mnoge TCP implementacije mogu poslati poruku o tome zadržavanje veze(održavanje u životu) testiranje neaktivnih veza. Takve se poruke povremeno šalju partneru kako bi provjerili njegovo postojanje na mreži. ACK poruke trebale bi biti primljene kao odgovor. Korištenje poruka o održavanju aktivnosti nije obvezno. Ako sustav ima tu mogućnost, aplikacija je može otkazati vlastitim sredstvima. Predviđeno razdoblje zadano timeout za održavanje veze je puna dva sata!
Podsjetimo, aplikacija može postaviti vlastiti mjerač vremena prema kojem će na vlastitoj razini odlučiti prekinuti vezu.
10.12 Izvođenje
Koliko je TCP učinkovit? Mnogi čimbenici utječu na performanse resursa, od kojih su memorija i širina pojasa glavni (vidi sliku 10.17).
Riža. 10.17. TCP faktori izvedbe
Širina pojasa i latencija u fizičkoj mreži koja se koristi ozbiljno će ograničiti propusnost. Loša kvaliteta prijenosa podataka rezultira velikom količinom ispuštenih datagrama, što uzrokuje ponovni prijenos i, kao rezultat, smanjuje učinkovitost propusnosti.
Strana primateljica mora osigurati dovoljno prostora za međuspremnik da omogući pošiljatelju slanje podataka bez prekida. To je osobito važno za mreže s velikom latencijom, gdje postoji dug vremenski interval između slanja podataka i primanja ACK-a (a također i prilikom pregovaranja o veličini prozora). Za održavanje stabilnog protoka podataka iz izvora, strana primateljica mora imati prozor od najmanje umnoška propusnosti i kašnjenja.
Na primjer, ako izvor može slati podatke brzinom od 10.000 bajtova/s, a potrebno je 2 sekunde da vrati ACK, onda s druge strane morate osigurati prozor za primanje od najmanje 20.000 bajtova, inače protok podataka neće biti kontinuirano. Međuspremnik za primanje od 10.000 bajtova prepolovit će propusnost.
Drugi važan čimbenik za izvedbu je sposobnost domaćina da odgovori na događaje visokog prioriteta i brzo se izvrši prebacivanje konteksta, tj. dovršiti neke operacije i prebaciti se na druge. Domaćin može interaktivno podržati mnoge lokalne korisnike, skupne pozadinske procese i desetke istodobnih komunikacijskih veza. Prebacivanje konteksta omogućuje servisiranje svih ovih operacija uz skrivanje opterećenja sustava. Implementacije koje integriraju TCP/IP s jezgrom operacijskog sustava mogu značajno smanjiti troškove korištenja prebacivanja konteksta.
Računalni CPU resursi su potrebni za obradu TCP zaglavlja. Ako procesor nije u mogućnosti brzo izračunati kontrolne zbrojeve, usporit će brzinu prijenosa podataka preko mreže.
Osim toga, programeri bi trebali razmotriti olakšavanje konfiguriranja TCP parametara tako da ih administrator mreže može prilagoditi svojim lokalnim zahtjevima. Na primjer, mogućnost podešavanja veličine međuspremnika za propusnost i kašnjenje mreže dramatično će poboljšati performanse. Nažalost, mnoge implementacije ne posvećuju dovoljno pažnje ovom problemu 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 svoje revolvere. Hoćete li postići izvrsne performanse?
Ne uvijek. Kvaliteta razvoja TCP softvera također je važna. Mnogi problemi u izvedbi dijagnosticirani su i riješeni tijekom godina u različitim TCP implementacijama. Najbolji softver je RFC 1122, koji definira zahtjeve komunikacijskog sloja za internetske hostove.
Jednako je važna iznimka i primjena algoritama Jacobson, Kern i Partridge (ovi zanimljivi algoritmi bit će razmotreni u nastavku).
Programeri softvera mogu ostvariti značajne prednosti stvaranjem programa koji eliminiraju nepotrebne prijenose malih količina podataka i imaju ugrađene mjerače vremena za oslobađanje mrežnih resursa koji se trenutno ne koriste.
10.13 Algoritmi za poboljšanje izvedbe
Prelazeći na prilično složeni dio TCP-a, pogledat ćemo mehanizme za poboljšanje performansi i rješavanje uskih grla u propusnosti. Ovaj odjeljak razmatra sljedeća pitanja:
■ Sporo početak(spori početak) sprječava korištenje velikog udjela mrežnog prometa za novu sesiju, što može dovesti do dodatnih troškova.
■ Oporavak od sindrom glupog prozora(sindrom glupog prozora) sprječava loše dizajnirane aplikacije da preopterećuju mrežu porukama.
■ Odgođen ACK(odgođeni ACK) smanjuje zagušenje smanjenjem broja nezavisnih poruka s potvrdom prosljeđivanja.
■ Izračunato vremensko ograničenje ponovnog prijenosa(računanje vremenskog ograničenja ponovnog prijenosa) temelji se na pregovaranju o vremenu sesije u stvarnom vremenu, smanjujući nepotrebne ponovne prijenose, ali ne uzrokujući velika kašnjenja za stvarno potrebne razmjene podataka.
■ Usporite TCP prosljeđivanje kada preopterećenja na mreži omogućuje usmjerivačima da se vrate u izvorni način rada i dijele mrežne resurse za sve sesije.
■ Slanje duplicirani ACK-ovi(duplikat ACK) pri primanju segmenta izvan slijeda, omogućuje ravnopravnim korisnicima ponovno slanje prije isteka vremena.
10.13.1 Sporo pokretanje
Ako su svi kućanski električni aparati uključeni u isto vrijeme kod kuće, doći će do preopterećenja električne mreže. U računalnim mrežama spor start sprječava pregorijevanje mrežnih osigurača.
Nova veza koja trenutno pokreće prijenos velikih količina podataka na već učitanoj mreži može dovesti do problema. Ideja iza sporog pokretanja je osigurati da nova veza ima uspješan početak uz polagano povećanje brzine prijenosa podataka prema stvarnom opterećenju mreže. Pošiljatelj je ograničen veličinom prozora za učitavanje, a ne velikim prozorom za primanje.
Prozor za učitavanje(prozor zagušenja) počinje od 1 veličine segmenta. Za svaki segment s uspješno primljenim ACK, prozor učitavanja se povećava za 1 segment sve dok ostaje manji od prozora za primanje. Ako mreža nije preopterećena, prozor za učitavanje će postupno dostići veličinu prozora za primanje. U normalnim uvjetima prosljeđivanja, ti prozori će biti iste veličine.
Imajte na umu da spori početak nije tako spor. Nakon prvog ACK, veličina prozora učitavanja je jednaka 2 segmenta, a nakon uspješnog primanja ACK za dva segmenta, veličina se može povećati na 8 segmenata. Drugim riječima, veličina prozora raste eksponencijalno.
Pretpostavimo da je umjesto primanja ACK-a došlo do isteka vremena. U nastavku se raspravlja o ponašanju prozora za učitavanje u ovom slučaju.
10.13.2 Sindrom bezumnog prozora
U prvim implementacijama TCP/IP-a, programeri su se suočili s tim fenomenom sindrom glupog prozora(Silly Window Syndrome - SWS), koji se često pojavljivao. Da biste razumjeli događaje koji se događaju, razmotrite sljedeći scenarij, koji dovodi do neželjenih posljedica, ali je sasvim moguće:
1. Aplikacija za slanje brzo šalje podatke.
2. Aplikacija primateljica čita 1 bajt podataka iz ulaznog međuspremnika (tj. polako).
3. Ulazni međuspremnik se brzo puni nakon čitanja.
4. Aplikacija primateljica čita 1 bajt i TCP šalje ACK što znači "Imam slobodan prostor za 1 bajt podataka."
5. Aplikacija za slanje šalje 1-bajtni TCP paket preko mreže.
6. TCP primatelj šalje ACK što znači "Hvala. Primio sam paket i nemam više slobodnog prostora."
7. Aplikacija primateljica ponovno čita 1 bajt i šalje ACK, a cijeli se proces ponavlja.
Aplikacija koja sporo prima dugo čeka da podaci stignu i neprestano gura primljene informacije na lijevi rub prozora, izvodeći potpuno beskorisnu operaciju koja stvara dodatni promet na mreži.
Stvarne životne situacije, naravno, nisu tako ekstremne. Brzi pošiljatelj i spori primatelj razmjenjivat će male (u odnosu na maksimalnu veličinu segmenta) komade podataka i prebacivati se na gotovo puni prozor primanja. Na sl. 10.18 prikazani su uvjeti za pojavu sindroma "glupavog prozora".
Riža. 10.18. Primanje prozorskog međuspremnika s vrlo malim slobodnim prostorom
Ovaj problem nije teško riješiti. Čim se prozor primanja smanji manje od zadane ciljne veličine, TCP počinje prevariti pošiljatelja. U ovoj situaciji, TCP ne bi trebao upućivati na pošiljatelja dodatni prostor u prozoru kada aplikacija primateljica čita podatke iz međuspremnika u malim dijelovima. Umjesto toga, pušteni resursi trebaju biti tajni od pošiljatelja dok ih ne bude dovoljno. Preporučena veličina je jedan segment, osim ako cijeli ulazni međuspremnik ne sadrži jedan segment (u potonjem slučaju koristi se veličina jednaka polovici međuspremnika). Ciljna veličina koju TCP treba izvijestiti može se izraziti kao:
minimalno (1/2 ulaznog međuspremnika, maksimalna veličina segmenta)
TCP počinje varati kada veličina prozora postane manja od ove veličine, a reći će istinu kada veličina prozora nije manja od vrijednosti dobivene formulom. Imajte na umu da nema štete za pošiljatelja jer aplikacija primateljica i dalje ne bi mogla obraditi većinu podataka koje očekuje.
Predloženo rješenje može se lako provjeriti u gornjem slučaju s ACK izlazom za svaki primljeni bajt. Ista metoda prikladna je i za slučaj kada ulazni međuspremnik može pohraniti nekoliko segmenata (kao što je često slučaj u praksi). Brzi pošiljatelj će ispuniti ulazni međuspremnik, ali primatelj će pokazati da nema slobodnog prostora za smještaj informacija i neće otvoriti ovaj resurs dok njegova veličina ne dosegne cijeli segment.
10.13.3 Nagleov algoritam
Pošiljatelj bi, bez obzira na primatelja, trebao isključiti prijenos vrlo kratkih segmenata, akumulirajući podatke prije slanja. Nagle algoritam implementira vrlo jednostavnu ideju za smanjenje broja kratkih datagrama koji se šalju preko mreže.
Algoritam preporučuje odgađanje prijenosa podataka (i guranje) čekanjem na ACK od prethodno poslanih podataka. Akumulirani podaci šalju se nakon primanja ACK-a na prethodno poslanu informaciju, ili nakon primanja podataka u veličini cijelog segmenta za slanje, ili nakon isteka vremenskog ograničenja. Ovaj se algoritam ne smije koristiti za aplikacije u stvarnom vremenu koje trebaju slati podatke što je brže moguće.
10.13.4 Odgođen ACK
Drugi mehanizam za poboljšanje performansi je ACK metoda odgode. Smanjenje broja ACK-ova smanjuje količinu propusnosti koja se može koristiti za prosljeđivanje drugog prometa. Ako TCP peer malo odgodi slanje ACK, tada:
■ Možete potvrditi prijem više segmenata s jednim ACK.
■ Aplikacija primateljica može primiti određenu količinu podataka unutar vremenskog intervala; izlazno zaglavlje može biti uključeno u ACK i ne mora generirati zasebnu poruku.
Kako bi se izbjegla kašnjenja pri slanju toka segmenata pune veličine (na primjer, prilikom razmjene datoteka), ACK bi trebao biti poslan barem za svaki drugi puni segment.
Mnoge implementacije koriste vremensko ograničenje od 200 ms. Ali odgođeni ACK ne usporava tečaj. Kada stigne kratki segment, još uvijek ima dovoljno slobodnog prostora u ulaznom međuspremniku za primanje novih podataka, a pošiljatelj može nastaviti slati (uz to, ponovni prijenos je obično puno sporiji). Ako stigne cijeli segment, morate na njega odgovoriti ACK porukom u istoj sekundi.
10.13.5 Istek ponovnog prijenosa
Nakon slanja segmenta, TCP postavlja mjerač vremena i prati dolazak ACK-a. Ako se ACK ne primi unutar vremenskog razdoblja, TCP ponovno prenosi segment (relej). Međutim, koji bi trebao biti vremenski period?
Ako je prekratak, pošiljatelj će ispuniti mrežu prosljeđivanjem nepotrebnih segmenata koji dupliciraju već poslane informacije. Predugo vrijeme čekanja spriječit će vas da brzo popravite segmente koji su stvarno loši tijekom prijenosa, što će smanjiti propusnost.
Kako mogu odabrati pravu količinu vremena za timeout? Vrijednost koja je dobra za LAN velike brzine nije dobra za udaljenu vezu s više pogodaka. To znači da je načelo "jedna vrijednost za sve uvjete" očito neprikladno. Štoviše, čak i za postojeću specifičnu vezu, mrežni uvjeti mogu se promijeniti i kašnjenja se mogu povećati ili smanjiti.
Jacobson, Kern i Partridge algoritmi (opisani u člancima , Van Jacobson i Poboljšanje procjene vremena povratnog putovanja u pouzdanim transportnim protokolima, Karn i Partridge) omogućuju TCP-u da se prilagodi promjenjivim mrežnim uvjetima. Ovi se algoritmi preporučuju za korištenje u novim implementacijama. U nastavku ćemo ih ukratko pokriti.
Zdrav razum nalaže da bi najbolja osnova za procjenu ispravnog vremena čekanja za određenu vezu mogla biti vrijeme ciklusa(round-trip time) kao interval između slanja podataka i primanja potvrde o njihovom primitku.
Dobre odluke za sljedeće količine mogu se dobiti iz osnovne statistike (vidi sliku 10.19) koja vam može pomoći da izračunate vrijeme čekanja. Međutim, nemojte se oslanjati na prosjeke, jer će više od polovice procjena biti veće od prosjeka. Gledajući nekoliko odstupanja, možete dobiti točnije procjene, uzimajući u obzir normalnu distribuciju i smanjujući predugo vrijeme čekanja na ponovni prijenos.
Riža. 10.19. Distribucija vremena ciklusa
Nema potrebe za velikom količinom proračuna za dobivanje formalnih matematičkih procjena odstupanja. Grube procjene mogu se koristiti na temelju apsolutne vrijednosti razlike između posljednje vrijednosti i prosječne procjene:
Posljednje odstupanje = | Zadnji ciklus - Prosjek |
Drugi čimbenik koji treba uzeti u obzir pri izračunavanju ispravnog timeouta je promjena vremena ciklusa zbog trenutnih mrežnih uvjeta. Ono što se dogodilo na webu u zadnji čas važnije je od onoga što se dogodilo prije sat vremena.
Pretpostavimo da izračunavate prosjek ciklusa za vrlo dugu sesiju. Iako je mreža u početku bila slabo opterećena, a odredili smo 1000 malih vrijednosti, onda je došlo do povećanja prometa uz značajno povećanje latencije.
Na primjer, ako je 1000 vrijednosti dalo prosjek od 170 jedinica, ali je tada izmjereno 50 vrijednosti s prosjekom od 282, tada će trenutni prosjek biti:
170 × 1000/1050 + 282 × 50/1050 = 175
Vrijednost bi bila razumnija izglađeno vrijeme ciklusa(Smoothed Round-Trip Time - SRTT), koji uzima u obzir prioritet kasnijih vrijednosti:
Novi SRTT = (1 - α) × (stari SRTT) + α × Vrijednost zadnjeg ciklusa
Vrijednost α je između 0 i 1. Povećati a rezultira većim utjecajem trenutnog vremena ciklusa na izglađeni prosjek. Budući da računala mogu brzo podijeliti po stepenu 2 pomicanjem binarnih brojeva udesno, α se uvijek bira da bude (1/2) n (obično 1/8), pa:
Novi SRTT = 7/8 × stari SRTT + 1/8 × Vrijeme posljednjeg ciklusa
Tablica 10.2 pokazuje kako se formula za SRTT prilagođava trenutnoj vrijednosti SRTT od 230 kada promjena stanja mreže rezultira progresivnim povećanjem vremena ciklusa (pod pretpostavkom da ne dođe do isteka). Vrijednosti u stupcu 3 koriste se kao vrijednosti u stupcu 1 za sljedeći red u tablici (to jest, kao stari SRTT).
Tablica 10.2 Izračunavanje izglađenog vremena 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 dolazi pitanje odabira vrijednosti za timeout ponovnog prijenosa. Analiza vremena ciklusa otkriva značajno odstupanje ovih vrijednosti od trenutnog prosjeka. Ima smisla postaviti granicu za veličinu odstupanja (odstupanja). Dobre vrijednosti za vremensko ograničenje ponovnog prijenosa (nazvane Retransmission TimeOut - RTO u RFC standardima) dane su sljedećom formulom s ograničenjem izglađenog odstupanja (SDEV):
T = Istek ponovnog prijenosa = SRTT + 2 × SDEV
T = SRTT + 4 × SDEV
Da biste izračunali SDEV, prvo odredite apsolutnu vrijednost trenutnog odstupanja:
DEV = | Vrijeme posljednjeg ciklusa - Stari SRTT |
Formula za izravnavanje se tada koristi za obračun posljednje vrijednosti:
Novi SDEV = 3/4 × stari SDEV + 1/4 × DEV
Ostaje jedno pitanje – koje su početne vrijednosti? Preporučeno:
Početni timeout = 3 s
Početni SRTT = 0
Početni SDEV = 1,5 s
Van Jacobson je definirao brzi algoritam koji vrlo učinkovito izračunava timeout ponovnog prijenosa.
10.13.6 Primjer statistike
Koliko će dobro funkcionirati gore izračunato vremensko ograničenje? Uočeno je značajno povećanje performansi kada je ostvarena rezultirajuća vrijednost. Primjer bi bila statistika tima netstat primljeno na sustav tigar- Internet poslužitelj kojemu pristupaju mnogi domaćini iz cijelog svijeta.
1510769 paketa (314955304 bajta) primljeno u nizu
Sustav tigar manje od 2,5% TCP segmenata podataka ponovno je poslano. Za milijun i pol dolaznih segmenata podataka (ostale su čiste ACK poruke) samo 0,6% je duplicirano. Treba imati na umu da razina gubitka u ulaznim podacima približno odgovara razini za izlazne segmente. Dakle, beskorisni promet retransmisije čini oko 0,6% ukupnog prometa.
10.13.7 Izračuni nakon ponovnog podnošenja
Gornje formule koriste vrijednost vremena ciklusa kao interval između slanja segmenta i primanja potvrde. Međutim, pretpostavimo da nije primljena nikakva potvrda tijekom razdoblja čekanja i da se podaci moraju ponovno poslati.
Kernov algoritam pretpostavlja da se vrijeme ciklusa u ovom slučaju ne smije mijenjati. Trenutna izglađena vrijednost vremena ciklusa i izglađeno odstupanje zadržati svoje vrijednosti sve dok se ne primi potvrda za slanje određenog segmenta bez ponovnog slanja. U ovom trenutku, izračuni se nastavljaju na temelju spremljenih vrijednosti i novih mjerenja.
10.13.8 Radnje nakon ponovnog prijenosa
Ali što se događa prije nego što se primi potvrda? Nakon ponovnog prijenosa, ponašanje TCP-a se radikalno mijenja, uglavnom zbog gubitka podataka zbog zagušenja mreže. Stoga će reakcija na ponovno slanje podataka biti:
■ Smanjenje brzine ponovne otpreme
■ Smanjite zagušenje mreže smanjenjem ukupnog prometa
10.13.9 Eksponencijalno kočenje
Nakon ponovnog prijenosa, interval timeouta se udvostručuje. Međutim, što se događa ako se timer ponovno prekorači? Podaci će se ponovno poslati, a razdoblje ponovnog prijenosa ponovno će se udvostručiti. Ovaj proces se zove eksponencijalno usporavanje(eksponencijalno povlačenje).
Ako se kvar na mreži nastavi, razdoblje čekanja će se udvostručiti dok se ne postigne unaprijed postavljena maksimalna vrijednost (obično 1 minuta). Nakon isteka vremena može se poslati samo jedan segment. Timeout također nastaje kada se prekorači unaprijed određena vrijednost za broj prijenosa podataka bez primanja ACK.
10.13.10 Smanjenje zagušenja smanjenjem količine podataka koji se šalju preko mreže
Smanjenje količine prenesenih podataka nešto je složenije od gore navedenih mehanizama. Počinje djelovati, kao i već spomenuti spori start. No, budući da je postavljena granica za razinu prometa, što u početku može dovesti do problema, tečaj će se zapravo usporiti zbog povećanja veličine okvira opterećenja za jedan segment. Morate postaviti vrijednosti granica kako biste stvarno smanjili brzinu učitavanja. Prvo se izračunava prag opasnosti:
Granica - minimalno 1/2 (trenutačni prozor za učitavanje, prozor za primanje partnera)
Ako je dobivena vrijednost više od dva segmenta, koristi se kao granica. Inače, granica je postavljena na dva segmenta. Potpuni algoritam oporavka zahtijeva:
■ Postavite veličinu prozora za učitavanje na jedan segment.
S Za svaki primljeni ACK, povećajte prozor opterećenja za jedan segment dok se ne dostigne granica (vrlo slično mehanizmu sporog pokretanja).
■ Zatim, sa svakim primljenim ACK, dodajte manju vrijednost prozoru opterećenja, koji se odabire na temelju stope povećanja u jednom segmentu za vrijeme ciklusa (povećanje se izračunava kao MSS / N, gdje je N veličina prozor opterećenja u segmentima).
Idealan scenarij mogao bi pojednostaviti rad mehanizma za oporavak. Pretpostavimo da je partnerov prozor za primanje (i trenutni prozor za učitavanje) bio 8 segmenata prije nego što je otkriveno vremensko ograničenje, a granica je definirana kao 4 segmenta. Ako primateljska aplikacija trenutno čita podatke iz međuspremnika, prozor za primanje ostaje na 8 segmenata.
■ 1 segment je poslan (prozor učitavanja = 1 segment).
■ ACK primljen — 2 segmenta su poslana.
■ ACK za 2 primljena segmenta — 4 segmenta su poslana (dostignuta granica).
■ ACK primljen za 4 segmenta. Poslano je 5 segmenata.
■ ACK primljen za 5 segmenata. Šalje se 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 primanje).
Budući da je potvrda svih poslanih podataka potrebna za vrijeme ponovnog prijenosa, proces se nastavlja sve dok prozor učitavanja ne dosegne veličinu prozora za primanje. Događaji koji se odvijaju prikazani su na sl. 10.20. Veličina prozora raste eksponencijalno, udvostručujući se tijekom razdoblja sporog početka, a po dolasku do granice linearno se povećava.
Riža. 10.20. Ograničavanje brzine prijenosa tijekom zagušenja
10.13.11 Duplicirani ACK-ovi
U nekim implementacijama koristi se opcijska značajka - tzv brza ponovna otprema(brzi retransmit) - kako bi se pod određenim uvjetima ubrzao ponovni prijenos podataka. Njegova glavna ideja odnosi se na slanje dodatnih ACK-ova od strane primatelja, što ukazuje na prazninu u primljenim podacima.
Pri primanju segmenta izvan reda, primatelj šalje natrag ACK koji pokazuje na prvi bajt. izgubljeno podataka (vidi sliku 10.21).
Riža. 21.10. Duplicirani ACK-ovi
Pošiljatelj ne šalje odmah ponovno podatke jer IP može normalno dostaviti podatke primatelju bez slijeda slanja. Ali kada se primi nekoliko dodatnih ACK-ova za duplicirane podatke (na primjer, tri), segment koji nedostaje bit će poslan bez čekanja da istekne vremensko ograničenje.
Imajte na umu da svaki duplikat ACK označava primitak segmenta podataka. Nekoliko duplikata ACK vam daje do znanja da je mreža sposobna isporučiti dovoljno podataka i stoga nije preopterećena. Kao dio cjelokupnog algoritma, izvodi se malo smanjenje veličine prozora opterećenja uz stvarno povećanje mrežnog prometa. U ovom slučaju, postupak radikalne promjene veličine prilikom obnavljanja rada se ne primjenjuje.
Prema standardu Zahtjevi domaćina(zahtjevi hosta) TCP bi trebao napraviti isti spori početak kao što je gore opisano prilikom gašenja izvora (prigušenje izvora). Međutim, izvješćivanje o tome nije ciljano niti učinkovito jer veza koja prima ovu poruku možda neće generirati previše prometa. Trenutna specifikacija Zahtjevi za usmjerivač(zahtjevi usmjerivača) označava da usmjerivači ne bi trebao slati poruke o suzbijanju izvora.
10.13.13 TCP statistika
Na kraju, pogledajmo statističke poruke naredbe netstat, vidjeti kako rade mnogi od gore opisanih mehanizama.
Segmenti su imenovani paketi.879137 paketa podataka (226966295 bajtova)
Ponovno je poslano 21815 paketa podataka (8100927 bajtova).Ponovno otpremanje.
132957 paketa samo za potvrdu (104216 odgođeno)Primjećujemo veliki broj
odgođen ACK.
Otvor prozora za sondiranjenula veličina.
Ovo su SYN i FIN poruke.762469 acks (za 226904227 bajtova)Upozorenje o pristizanju paketa
izvan slijeda.
1510769 paketa (314955304 bajta)
9006 potpuno dupliranih paketa (867042 bajta)Rezultat timeouta kada je real
dostavu podataka.
74 paketa s nešto duplo. podaci (12193 bajta prevareno)Za veću učinkovitost
neki od podataka su prepakirani kako bi uključili dodatne bajtove kada su ponovno poslani.
13452 paketa izvan reda (2515087 bajtova)
530 paketa (8551 bajt) podataka nakon prozoraMožda je ovaj podatak bio
uključene u senzorske poruke.
402 paketa primljena nakon zatvaranjaOvo su naknadne reprize
slanje.
108 odbačeno zbog loših kontrolnih zbrojaNevaž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 prihvaćanje)
18929 veza zatvoreno (uključujući 643 kapi)
Otpalo je 4100 embrionalnih veza
572187 segmenata ažuriranih rtt (od 587397 pokušaja)Neuspjeli pokušaji promjene
vrijeme ciklusa, jer ACK nije imao vremena stići prije isteka vremenskog ograničenja,
26 veza prekinuto zbog isteka rexmitNaknadni neuspješni pokušaji
ponovno slanje, što ukazuje na izgubljenu vezu.
Istek vremena za ispitivanjenulti prozor.
Istek vremena naplateprekinuta veza.
472 veze prekinute zbog održavanja
10.14 Usklađenost sa zahtjevima programera
Trenutni TCP standard zahtijeva od implementacija da se pridržavaju postupka sporog pokretanja prilikom inicijalizacije veze i koriste Kern i Jacobson algoritme za procjenu vremenskog ograničenja ponovnog prijenosa i upravljanje opterećenjem. Testovi su pokazali da ovi mehanizmi dovode do značajnih poboljšanja performansi.
Što se događa ako instalirate sustav koji se ne pridržava ovih standarda? Neće moći pružiti adekvatne performanse za svoje vlastite korisnike, a bit će loš susjed za druge sustave na mreži, sprječavajući vraćanje normalnog rada nakon privremene zagušenja i generirajući prekomjeran promet koji rezultira ispuštenim datagramima.
10.15 Prepreke u izvedbi
TCP je dokazao svoju fleksibilnost, radeći na mrežama s tečajevima od stotina ili milijuna bitova u sekundi. Ovaj protokol omogućio je postizanje dobrih rezultata u modernim lokalnim mrežama s Ethernetom, Token-Ringom i Fiber Distributed Data Interface (FDDI) topologijama, kao i za komunikacijske linije male brzine ili veze na daljinu (poput satelitskih veza) .
TCP je dizajniran da odgovori na ekstremne uvjete kao što je zagušenje mreže. Međutim, trenutna verzija protokola ima značajke koje ograničavaju performanse obećavajućih tehnologija koje nude propusnost u stotinama i tisućama megabajta. Da biste razumjeli probleme koji se pojavljuju, razmotrite jednostavan (iako nerealan) primjer.
Pretpostavimo da kada premještate datoteku između dva sustava, želite razmjenjivati kontinuirani tok što je učinkovitije moguće. Pretpostavimo da:
■ Maksimalna veličina ciljnog segmenta je 1 KB.
■ Prozor za primanje - 4 kbajta.
■ Širina pojasa omogućuje slanje dva segmenta u 1 sekundi.
■ Aplikacija primateljica troši podatke kako stignu.
S ACK poruke stižu za 2 sekunde.
Pošiljatelj je sposoban kontinuirano slati podatke. Uostalom, kada je volumen dodijeljen za prozor pun, stiže ACK, dopuštajući slanje drugog segmenta:
Nakon 2 s:
PRIMI POTVRDU SEGMENTA 1, MOŽE POSLATI SEGMENT 5.
PRIMITE POTVRDU SEGMENTA 2, MOŽETE POSLATI SEGMENT 6.
PRIMITE POTVRDU SEGMENTA 3, MOŽETE POSLATI SEGMENT 7.
PRIMI POTVRDU SEGMENTA 4, MOŽE POSLATI SEGMENT 8.
Nakon još 2 s:
PRIMI POTVRDU SEGMENTA 5, MOŽE POSLATI SEGMENT 9.
Ako je prozor za primanje bio samo 2 KB, pošiljatelj 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 (kako bi se pružili jednostavniji brojevi), mali prozor može dovesti do problema sa satelitskim vezama velike latencije.
Pogledajmo sada što se događa s vezama velike brzine. Na primjer, ako se propusnost i brzina prijenosa mjere na 10 milijuna bita u sekundi, ali je vrijeme ciklusa 100 ms (1/10. sekunde), tada za kontinuirani tok prozor za primanje mora pohraniti najmanje 1.000.000 bita, 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, budući da će brojevi sekvence vrlo brzo ponestati. Ako veza može prenositi podatke brzinom od 4 GB / s, tada bi se brojevi sekvenci trebali ažurirati svake sekunde. Neće biti moguće razlikovati stare duplikate datagrama koji su odgođeni više od sekunde tijekom surfanja internetom od svježih novih podataka.
Novo istraživanje je u tijeku kako bi se poboljšao TCP/IP i uklonile gore navedene barijere.
10.16 TCP funkcije
Ovo poglavlje usredotočuje se na mnoge značajke TCP-a. Glavni su navedeni u nastavku:
■ Povezivanje portova s vezama
■ Inicijalizacija veza potvrdom u 3 koraka
■ Izvodi polagano pokretanje kako bi se izbjeglo zagušenje mreže
■ Segmentacija podataka u tranzitu
■ Numeriranje podataka
■ Rukovanje dolaznim dupliranim segmentima
■ Izračunavanje kontrolnih zbroja
■ Regulacija protoka podataka kroz prozor za primanje i prozor za slanje
■ Prekid veze na utvrđeni način
■ Prekid veze
■ Prosljeđivanje hitnih podataka
■ Pozitivna potvrda o ponovnoj otpremi
■ Izračunavanje vremenskog ograničenja ponovnog prijenosa
■ Smanjen povratni promet tijekom zagušenja mreže
■ Alarm za dolazak segmenta izvan reda
■ Osjećaj 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 neprestano prati trenutno stanje druge strane veze.
U nastavku ćemo ukratko pogledati tipičan prijelaz stanja poslužitelja i klijenta koji se nalaze na različitim krajevima veze. Ne namjeravamo davati iscrpan opis svih mogućih stanja prilikom prijenosa podataka. Nalazi se u RFC 793 i u Zahtjevi domaćina.
Tijekom uspostavljanja veza, poslužitelj i klijent prolaze kroz slične nizove stanja. Stanja poslužitelja prikazana su u tablici 10.3, a stanja klijenta prikazana su u tablici 10.4.
Tablica 10.3 Slijed stanja poslužitelja
| Stanje poslužitelja | Događaj | Opis |
|---|---|---|
| ZATVORENO (zatvoreno) | Fiktivno stanje prije početka veze. | |
| Pasivno otvaranje poslužiteljskom aplikacijom. | ||
| SLUŠAJ (praćenje) | Poslužitelj čeka na klijentsku vezu. | |
| TCP poslužitelj prima SYN i šalje SYN / ACK. | Poslužitelj je primio SYN i poslao SYN / ACK. Ide čekati ACK. | |
| SYN-PRIMLJENO | TCP poslužitelj prima ACK. | |
| OSNOVAN (instaliran) | ACK primljen, veza otvorena. |
Tablica 10.4 Redoslijed stanja klijenta
Ako bi partneri istovremeno pokušali uspostaviti vezu jedan s drugim (što se događa vrlo rijetko), svaki bi prošao kroz stanja ZATVORENO, SYN-SENT, SYN-RECEIVED i ESTABLISHED.
Krajnje strane veze ostaju u UTVRĐENOM stanju sve dok se jedna od strana ne pokrene zatvaranje veze slanjem FIN segmenta. Tijekom normalnog zatvaranja, strana koja pokreće to zatvaranje prolazi kroz stanja prikazana u tablici 10.5. Njezin partner prolazi kroz stanja prikazana u tablici 10.6.
Tablica 10.5 Redoslijed stanja stranke koja zatvara vezu
| Zatvarajuća bočna stanja | Događaj | Opis |
|---|---|---|
| USTANOVLJENA | Lokalna aplikacija zahtijeva zatvaranje veze. | |
| TCP šalje FIN / ACK. | ||
| FIN-ČEKAJ-1 | Pokrivatelj čeka odgovor partnera. Podsjetimo da novi podaci možda još uvijek pristižu od partnera. | |
| TCP prima ACK. | ||
| FIN-ČEKAJ-2 | Završna strana je primila ACK od partnera, ali FIN još nije stigao. Završna strana čeka FIN, prihvaćajući dolazne podatke. | |
| TCP prima FIN / ACK. | ||
| Šalje ACK. | ||
| VRIJEME-ČEKANJE | Veza se održava u neodređenom stanju kako bi se omogućilo da duplirani podaci ili duplicirani FIN-ovi koji još postoje na mreži stignu ili ispadnu. Razdoblje čekanja je dvostruko veće od procjene maksimalnog životnog vijeka segmenta. | |
| ZATVORENO |
Tablica 10.6 Slijed partnerskih stanja za zatvaranje veze
| Status partnera | Događaj | Opis |
|---|---|---|
| USTANOVLJENA | TCP prima FIN / ACK. | |
| ZATVORI-ČEKAJ | 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. | ||
| ZADNJI POTVRDI | 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ćuje provjeru trenutnog stanja veze. Veze u državama prikazane su u nastavku slušati, pokretanje, uspostavljeno, zatvaranje i vrijeme-čekati.
Imajte na umu da je broj priključka naveden na kraju svake lokalne i vanjske adrese. Možete vidjeti da postoji TCP promet za ulazne i 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 UTVRĐEN
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 UTVRĐEN
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 UTVRĐEN
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 UTVRĐEN
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 UTVRĐEN
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 UTVRĐEN
10.18 Bilješke o provedbi
Od samog početka, TCP je dizajniran za međuoperaciju mrežne opreme različitih proizvođača. TCP specifikacija ne navodi točno kako bi unutarnje implementacijske strukture trebale funkcionirati. Ova su pitanja prepuštena programerima kako bi pronašli najbolje mehanizme za svaku specifičnu implementaciju.
Čak i RFC 1122 (dokument Zahtjevi domaćina - zahtjevi domaćina) ostavlja dovoljno prostora za varijacije. Svaka od implementiranih funkcija označena je određenom razinom kompatibilnosti:
■ SVIBANJ (Dopušteno)
■ NE SMIJE
Nažalost, ponekad postoje proizvodi koji ne ispunjavaju MUST zahtjeve. Kao rezultat toga, korisnici doživljavaju neugodnosti degradacije performansi.
Neke dobre prakse implementacije nisu uzete u obzir u standardima. Na primjer, poboljšanje sigurnosti moguće je ograničavanjem korištenja dobro poznatih portova od strane privilegiranih procesa sustava ako je ova metoda podržana na lokalnom operativnom sustavu. Kako bi se maksimizirala izvedba, implementacije bi trebale imati što manje kopiranja i premještanja poslanih ili dohvaćenih podataka.
Standardni API nedefinirano(kao i sigurnosna politika) tako da postoji slobodno polje aktivnosti za eksperimentiranje s različitim skupovima softverskih alata. Međutim, to može rezultirati korištenjem različitih API-ja na svakoj platformi i spriječit će se premještanje aplikacijskog softvera s jedne platforme na drugu.
Zapravo, programeri temelje svoje alate na Socket API-ju iz Berkeleya. Važnost programskog sučelja porasla je pojavom WINSocka (Windows Socket), što je dovelo do proliferacije novih desktop aplikacija koje su se mogle izvoditi na vrhu bilo kojeg WINSock sučelja kompatibilnog s TCP/IP stogom.
10.19 Daljnje čitanje
Izvorni TCP standard definiran je u RFC 793. Ažuriranja, popravci i zahtjevi interoperabilnosti obrađeni 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 u Proceedings of the ACM SIGCOMM Workshop 1988. Jacobson je također izdao nekoliko RFC-ova u kojima se revidiraju algoritmi za poboljšanje performansi.
Poslužitelji koji implementiraju ove protokole na korporativnoj mreži daju klijentu IP adresu, pristupnik, mrežnu masku, poslužitelje imena, pa čak i pisač. Korisnici ne moraju ručno konfigurirati svoje hostove kako bi mogli koristiti mrežu.
Operativni sustav QNX Neutrino implementira još jedan plug-and-play protokol nazvan AutoIP, koji je projekt odbora za automatsku konfiguraciju IETF-a. Ovaj protokol se koristi na malim mrežama za dodjelu IP adresa hostovima koji su lokalni na poveznici. Protokol AutoIP neovisno određuje lokalnu IP adresu kanala, koristeći pregovaračku shemu s drugim domaćinima i bez kontaktiranja središnjeg poslužitelja.
Korištenje PPPoE protokola
PPPoE je skraćenica od Point-to-Point Protocol over Ethernet. Ovaj protokol enkapsulira podatke za prijenos preko premoštene Ethernet mreže.
PPPoE je specifikacija za povezivanje korisnika Etherneta na Internet putem širokopojasne veze kao što je iznajmljena linija, bežični uređaj ili kabelski modem. Korištenje PPPoE i širokopojasnog modema omogućuje korisnicima lokalne računalne mreže individualni autentificirani pristup brzim podatkovnim mrežama.
PPPoE kombinira Ethernet s PPP-om za učinkovito stvaranje zasebne veze s udaljenim poslužiteljem za svakog korisnika. Kontrola pristupa, obračun povezivanja i odabir davatelja usluga su specifični za korisnika, a ne za host. Prednost ovog pristupa je u tome što ni telefonska tvrtka ni davatelj internetskih usluga nisu dužni pružati nikakvu posebnu podršku za to.
Za razliku od dial-up veza, DSL i kabelski modem veze su uvijek aktivne. Budući da fizičku vezu s udaljenim davateljem usluga dijeli više korisnika, potrebna je obračunska metoda koja registrira pošiljatelje i odredišta prometa i naplaćuje korisnicima. PPPoE omogućuje korisniku i udaljenom domaćinu koji sudjeluju u komunikaciji da saznaju međusobne mrežne adrese tijekom početne razmjene tzv. otkrivanje(otkriće). Nakon što je uspostavljena sesija između pojedinačnog korisnika i udaljene stranice (kao što je davatelj internetskih usluga), sesija se može nadzirati za obračunavanje. U mnogim domovima, hotelima i korporacijama pristup internetu se dijeli preko digitalnih pretplatničkih linija koristeći Ethernet i PPPoE tehnologiju.
PPPoE veza se sastoji od klijenta i poslužitelja. Klijent i poslužitelj rade koristeći bilo koje sučelje koje je blisko Ethernet specifikacijama. Ovo se sučelje koristi za izdavanje IP adresa klijentima, povezujući te IP adrese s korisnicima i opcijski s radnim stanicama, umjesto provjere autentičnosti samo na radnoj stanici. PPPoE poslužitelj stvara vezu od točke do točke za svakog klijenta.
Uspostavljanje PPPoE sesije
Da biste stvorili PPPoE sesiju, trebali biste koristiti uslugupppoed... Modulio-pkt- * nPruža usluge PPPoE protokola. Prvo morate trčatiio-pkt- *Sodgovarajući vozač... Primjer:
Putovanje preko mrežnih protokola.
TCP i UDP su oba protokola transportnog sloja. UDP je protokol bez povezivanja s nezaštićenom dostavom paketa. TCP (Transmission Control Protocol) je protokol orijentiran na vezu s zajamčenom dostavom paketa. Najprije slijedi stisak ruke (Halo. | Halo. | Hajdemo razgovarati? | Hajde.), nakon čega se smatra da je veza uspostavljena. Nadalje, paketi se šalju naprijed-natrag preko ove veze (postoji razgovor), a uz provjeru je li paket stigao do primatelja. Ako je paket izgubljen, ili je stigao, ali s malom kontrolnom zbrojem, onda se ponovo šalje ("ponoviti, nisam čuo"). Dakle, TCP je pouzdaniji, ali je kompliciraniji sa stajališta implementacije i stoga zahtijeva više takta/memorije, što nije najmanje važno 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 putem kojeg poslužitelj šalje stranice našem pregledniku. HTTP je sada sveprisutan na World Wide Webu za dohvaćanje informacija s web stranica. Na slici je prikazano svjetlo na mikrokontroleru s ugrađenim OS-om u kojem se boje postavljaju putem preglednika.
HTTP protokol je tekstualan i prilično jednostavan. Zapravo, ovako izgleda metoda GET koju uslužni program netcat šalje na lokalnu IPv6 adresu poslužitelja sa svjetlima:
~ $ nc fe80 :: 200: e2ff: fe58: b66b% mazko 80< HTTP metoda je obično kratka engleska riječ s velikim slovima, osjetljiva na velika i mala slova. Svaki poslužitelj mora podržavati barem metode GET i HEAD. Osim metoda GET i HEAD, često se koriste metode POST, PUT i DELETE. Metoda GET koristi se za traženje sadržaja navedenog resursa, u našem slučaju ovdje je GET / b HTTP / 1.0 gdje je put / b odgovoran za boju (plava). Odgovor poslužitelja: HTTP / 1.0 200 OK Server: Contiki / 2.4 http://www.sics.se/contiki/ Veza: zatvori Cache-Control: bez predmemorije, bez pohrane, mora se ponovno potvrditi Pragma: bez predmemorije Istječe: 0 Content- vrsta: tekst / html Crvena je ISKLJUČENA Zelena je ISKLJUČENA Plava je UKLJUČENA
Statusni kod (imamo 200) dio je prvog retka odgovora poslužitelja. To je troznamenkasti cijeli broj. Prva znamenka označava klasu uvjeta. Kod odgovora obično slijedi izraz objašnjenja na engleskom jeziku, odvojen razmakom, koji osobi objašnjava razlog ovog konkretnog odgovora. U našem slučaju poslužitelj je radio bez grešaka, sve na hrpu (OK).
I zahtjev i odgovor sadrže zaglavlja (svaki redak je zasebno polje zaglavlja, par naziv-vrijednost odvojen je dvotočkom). Zaglavlja završavaju praznim redom, nakon čega podaci mogu ići.
Moj preglednik odbija otvoriti lokalnu IPv6 adresu, pa je dodatna adresa upisana u firmware mikrokontrolera, a isti prefiks također mora biti dodijeljen virtualnom mrežnom sučelju simulatora:
~ $ sudo ip addr add abcd :: 1/64 dev mazko # linux ~ $ netsh sučelje ipv6 postavi adresu mazko abcd :: 1 # windows ~ $ curl http: //
Aplikacija klijent-poslužitelj na TCP streaming utičnici
U sljedećem primjeru koristimo TCP za pružanje uređenih, pouzdanih dvosmjernih tokova bajtova. Izgradimo kompletnu aplikaciju koja uključuje klijenta i poslužitelja. Prvo ćemo pokazati kako konstruirati poslužitelj na TCP streaming utičnicama, a zatim klijentsku aplikaciju za testiranje našeg poslužitelja.
Sljedeći program stvara poslužitelj koji prima zahtjeve za povezivanje od klijenata. Poslužitelj je izgrađen sinkrono, stoga je izvođenje niti blokirano sve dok poslužitelj ne pristane na povezivanje s klijentom. Ova aplikacija pokazuje jednostavan poslužitelj koji odgovara klijentu. Klijent prekida vezu slanjem poruke poslužitelju
TCP poslužitelj
Kreiranje strukture poslužitelja prikazano je u sljedećem funkcionalnom dijagramu:
Ovdje je kompletan kod za program SocketServer.cs:
// SocketServer.cs koristeći System; koristeći System.Text; koristeći System.Net; korištenjem System.Net.Sockets; imenski prostor SocketServer (klasa Program (statički void Main (string args)) (// Postavite lokalnu krajnju točku za utičnicu IPHostEntry ipHost = Dns.GetHostEntry ("localhost"); IPAdresa ipAddr = ipHost.AddressList; IPEndPoint = novi ipEndPoint, ipEndPoint 11 ); // Stvorite Tcp / Ip utičnicu sListener = new Socket (ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp); // Dodijelite utičnicu lokalnoj krajnjoj točki i poslušajte dolazne utičnice pokušajte (sListener.Bind (ipEndPoint ); sListener. Slušaj (10); // Počni osluškivati veze dok (true) (Console.WriteLine ("Čekanje veze na portu (0)", ipEndPoint); // Program pauzira, čeka dolaznu vezu Rukovalac utičnice = sListener.Accept (); string data = null; // Čekali smo da se klijent pokuša povezati s nama bajt bajt = novi bajt; int bytesRec = handler.Receive (bajtovi); podaci + = Encoding.UTF8.GetString (bytes, 0, bytesRec); // Prikaži podatke na konzoli Console.Write ("Primljeno tekst: "+ podaci +" \ n \ n "); // Pošaljite odgovor klijentu \ string reply = "Hvala na zahtjevu u" + data.Length.ToString () + "znakovi"; byte msg = Encoding.UTF8.GetBytes (odgovor); rukovalac.Pošalji (poruka); ako (podaci.IndexOf ("
Pogledajmo strukturu ovog programa.
Prvi korak je uspostavljanje lokalne krajnje točke za utičnicu. Prije otvaranja utičnice za slušanje veza, morate pripremiti lokalnu adresu krajnje točke za nju. Jedinstvena adresa za TCP/IP uslugu određena je kombinacijom IP adrese domaćina s brojem porta usluge koji stvara krajnju točku za uslugu.
Klasa Dns 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 prikladnu adresu iz niza za posluživanje.
Napravite IPEndPoint za poslužitelj kombiniranjem prve IP adrese domaćina iz metode Dns.Resolve () s 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 stvorite stream socket s novom instancom klase Socket. S lokalnom krajnjom točkom postavljenom za slušanje veza, utičnica se može stvoriti:
Socket sListener = nova utičnica (ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
Nabrajanje Adresa Obitelj specificira sheme adresiranja koje instanca klase Socket može koristiti za rješavanje adrese.
U parametru SocketType postoje TCP i UDP utičnice. U njemu možete definirati, između ostalog, sljedeće vrijednosti:
DgramPodržava datagrame. Vrijednost Dgram zahtijeva da navedete Udp za tip protokola i InterNetwork u parametru obitelji adresa.
SirovaPodržava pristup temeljnom transportnom protokolu.
StreamPodržava streaming utičnice. Vrijednost Stream zahtijeva da se Tcp navede za tip protokola.
Treći i posljednji parametar definira vrstu protokola potrebnog za utičnicu. U parametru ProtocolType možete odrediti sljedeće najvažnije vrijednosti - Tcp, Udp, Ip, Raw.
Sljedeći korak trebao bi biti dodjela utičnice pomoću metode Vezati ()... Kada konstruktor otvori utičnicu, ne dodjeljuje mu se ime, rezerviran je samo deskriptor. Metoda Bind () se poziva da dodijeli ime utičnici poslužitelja. Da bi klijentska utičnica mogla identificirati TCP streaming utičnicu, poslužiteljski 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 što ste stvorili utičnicu i povezali ime s njom, možete slušati dolazne poruke pomoću metode slušaj ()... U stanju slušanja, utičnica će čekati na pokušaje dolaznog povezivanja:
SListener.Slušaj (10);
Parametar definira zaostatak koji određuje maksimalni broj veza na čekanju u redu čekanja. U danom kodu, vrijednost parametra dopušta akumuliranje do deset veza u redu čekanja.
U stanju slušanja mora se biti spreman pristati na vezu s klijentom, za koji se metoda koristi prihvatiti ()... Ova metoda dobiva klijentsku vezu i dovršava povezivanje imena klijent/poslužitelj. Metoda Accept () blokira nit pozivatelja dok se ne uspostavi veza.
Metoda Accept () dohvaća prvi zahtjev za povezivanjem iz reda zahtjeva na čekanju i stvara novu utičnicu za rukovanje. Iako je nova utičnica stvorena, izvorna utičnica nastavlja slušati i može biti višenitna za primanje višestrukih zahtjeva za povezivanje od klijenata. Nijedna poslužiteljska aplikacija ne smije zatvoriti utičnicu za slušanje. Trebao bi nastaviti raditi zajedno s utičnicama stvorenim metodom Accept za obradu dolaznih zahtjeva klijenata.
Dok (true) (Console.WriteLine ("Čekanje veze na portu (0)", ipEndPoint); // Program pauzira, čeka dolaznu vezu Socket handler = sListener.Accept ();
Nakon što klijent i poslužitelj uspostave vezu između sebe, možete slati i primati poruke korištenjem metoda poslati () i primi () Klasa utičnice.
Metoda Send () zapisuje odlazne podatke u utičnicu na koju se uspostavlja veza. Metoda Receive () čita dolazne podatke u stream socket. Na sustavu temeljenom na TCP-u mora se uspostaviti veza između utičnica prije izvršavanja metoda slanja () i primanja (). Točan protokol između dva entiteta u interakciji mora se unaprijed odrediti kako klijentske i poslužiteljske aplikacije ne bi blokirale jedna drugu, ne znajući tko bi trebao prvi poslati svoje podatke.
Kada je razmjena podataka između poslužitelja i klijenta završena, morate zatvoriti vezu pomoću metoda Ugasiti () i Zatvoriti ():
Handler.Shutdown (SocketShutdown.Both); rukovalac.Zatvori ();
SocketShutdown je nabrajanje koje sadrži tri vrijednosti koje treba zaustaviti: Oba- prestaje slati i primati podatke preko utičnice, Primiti- prestaje primati podatke o utičnici, i Poslati- prestaje slati podatke preko utičnice.
Utičnica se zatvara kada se pozove metoda Close (), koja također postavlja svojstvo Connected utičnice na false.
Klijent na TCP-u
Funkcije koje se koriste za stvaranje klijentske aplikacije manje-više nalikuju poslužiteljskoj aplikaciji. Kao i kod poslužitelja, iste metode se koriste za određivanje krajnje točke, instanciranje utičnice, slanje i primanje podataka i zatvaranje utičnice.
