Ellenőrző kérdések a Szállítási szintű átvitel témaköréből

Ez az oldal a korábbi SCH wikiről lett áthozva.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor, kérlek, javíts rajta egy rövid szerkesztéssel!

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót.

Előző: SzgHaloVizsgaHalozAtv Következő: SzgHaloVizsgaViszony

1. Mi a szállítási réteg célja és szerepe a távoli felhasználók kommunikációjában?

Feladata a megbízható, gazdaságos adatszállítás garantálása a hoszttól a célhosztig. Mindezt két hoszt közötti hálózat teljes elrejtésével teszi.

2. Miért tekinthető a szállítási réteg a legfontosabb rétegnek?

Fő határvonalát alkotja a szállítási-szolgáltató (1-4.réteg ) (transport service prvider) rétegek és a megbízható adatátvitel szolgálat felhasználója között.

3. Milyen szállítási szolgálatokat ismer? Milyen feladat-csoportokat kell a szállítási protokollnak támogatnia?

kapcsolódásra váró állapot, összeköttetésre irányuló kérés, adatküldés, adat érkezésére vár állapot, kapcsolat bontása.

• normál mód: a küldő hoszttól érkező adat egy várakozó sorba kerül, innen később továbbításra kerül.
• sürgősségi: a sor következő tovább küldésre kerülő adata helyére kerül és a lehető leghamarabb továbbküldik.

4. Mi a szolgálat minősége, és a kezdeti opció-egyeztetés?

Quality of Service (QoS) - a felhasználótól kapott paraméterek közt szerepel, a rendelkezésre álló eszközök (hálózati szolgáltatások) alapján eldönti, hogy képes-e teljesíteni a felhasználó kérését. A kapcsolat kizárólag akkor jön lére, ha a felhasználó megelégszik a felkínált minőséggel.

5. Milyen szolgálati primitívek használatosak az OSI-környezetben, és milyen a TCP/IP környezetben?

• OSI:
  • request
  • indication
  • response
  • confirm
• TCP/IP
  • LISTEN
  • CONNECT
  • SEND
  • RECEIVE
  • CLOSE

7. Címzéssel kapcsolatban milyen eljárásokat ismer a szállítási cím megszerzésére? A távoli TSAP megszerzése érdekében hogyan működik egy process szerver? Hogyan egy név szerver?

A folyamatok összekötésére külön szállítási címeket definiálnak a portok(Internet) vagy AAL-SAP(ATM). Általánosságban TSAP-nek nevezzük őket (Transport SAP). Hasonlóan a hálózati réteg NSAP-jeihez az IP-címekhez.

A TSAP-k eléréséhez vagy a

• jól ismert (well-known) portokon keresztül, így pl. a webszerver 80 portján
• kezdeti összekötés-protokoll segítségével: a folyamatszoftver (process server) várja a kéréseket és létrehozza a szükséges szolgáltató folyamatokat és hozzájuk irányítja a kérést, közben ő csak a kérések figyeléséért felel.
• névszolgáltató (katalógus szolgáltató) felel a bejelentkezett igények kiszolgálásáért (gyakran egy ASCII karakterfűzért kap), továbbítja a cél folyamat felé.

8. Két távoli hoszt közötti kapcsolatfelvétel milyen nehézségekkel jár? Hogyan lehet a gondokat kivédeni a háromutú HS segítségével?

késleltetett kettőzés problémája: CR TPDU küldése, válasz CA TPDU, késve érkezhetnek meg, tárolja az alhálózat, és felbukkan wtf?! :). Megoldás a háromutas kézfogásos (three way handshake) algoritmus. Minden üzenet sorszámozva és nyugtázva elfogadható. ÁBRA.

9. A szállítási összeköttetés bontása milyen gondokkal jár? Hogyan lehet kivédeni háromutú HS segítségével?

H1 üzenetben tudatja a kérdést, hogy le akar bontani. H2 válaszol, hogy rendben van, készen áll. Viszont nem tudja, hogy H' megkapta-e az engedélyt ->végtelen ciklus (két hadsereg problémája). Feloldása egy időzítő beállításával. Az időzítő lejárta után nem érkezik válasz a DR TPDU-ra akkor megszakítja a kapcsolatot, ha ugyanis H2 érdekelt lett volna a fenntartásban azt valamiképpen biztos tudtára adta volna.

10. Milyen forgalomszabályozási módszereket ismer a szállítási szintű működés támogatására? Mi az a változó adási ablakméretű csúszó/forgó ablakos mechanizmus?

Cél, hogy az adó ne töltse túl a vevő pufferét. Az adatkapcsolati rétegben is volt ilyen szabályzás. Ott az adási ablak mérete mindig maximális, a vevőoldali pufferbe be nem férő keretek a következő sorozatban ismétlésre kerülnek. A szállítási rétegben az adategységek nagyobbak, ezért ilyen pazarlás és hálózati terhelés nem engedhető meg. Ennek elkerülésére a vevő által küldött üzenetek fejrészébe az Nr (köv. várt üzenet száma) mellett egy CR (credit) érték is bekerül. Ennek jelentése az,hogy a vevőnek ennyi szabad puffere van, ez legyen a lehetséges maximális adási ablakméret. Az adó ezen üzenet vételekor Nr sorszámtól kezd adni, és a maximum Cr darab üzenetet ad. thx to NA

A pufferkezelés lehetőségei:

• azonos méretű pufferek használata javasolt, ha a TPDU-k is azonos méretűek, egy pufferbe egy TPDU-t lehet elhelyezni.
• változó méretű puffer használata akkor célszerű, ha a TPDU-k mérete széles határok között mozoghat. Előnye a jobb kihasználtság, viszont cserébe többletmunkával jár. Lehetőség van dinamikus puffer igénylésére, főleg kis sávszélességű löketszerű forgalom céljára. Nagy sávszélességet igénylő átvitel esetén a vevő teljes ablaknyi puffert rendelhet a bejövő forgalomhoz.

-- adamo - 2005.12.30.

11. Milyen nyalábolási módokat ismer a szállítási rétegben?

Lényege: A gazdaságos működés érdekében a felhsználói igényeket nyalábólva kell magvalósítani

• Felfelé irányuló multiplexelés: Több felhasználó igényét egyetlen összeköttetés elégíti ki.(Egy NSAP elégít ki a túloldalon lévő egy NSAP-ot)
• Lefelé irányuló multiplexelés: Egy nagy felhasználói igény kielégítéséhez több virtuális áramkört létesítünk. (Több NSAP elégít ki a túloldalon névő NSAP-ot)

thx to NA

• Egy hoszt csak egyetlen hálózati címmel rendelkezik, a feltöltési multiplexelés feladata eldönteni, hogy a beérkező TPDU-k melyik folyamathoz kell továbbítani.
• A letöltési multiplexelés során az alhálózaton belül virtuálisan vagy fizikálisan több kapcsolatot (virtuális áramkör) létesíthetünk és ezek körforgás alapú használatával nagyobb sávszélesség érhető el, mint egyetlen útvonal használatával. Például az ISDN két különálló, egyenként 64kbps os vonalát megosztva használunk adattovábbításra, ezáltal elérhető a 128kbps sebesség is.

-- adamo - 2005.12.30.

12. Ismertesse a TCP szegmens formátumát, a mezők szerepét!

Rögzített 20 bájtos fejrész ( és egy opcionális rész) után 0 vagy több adatbájtot tartalmaz. Korlátait a 64 kbájtos IP adatmező adja illetve egyes hálózatok meghatározhatnak egy legnagyobb átvihető adategységet (MTU - maximal transfer unit), mely általában 1500 bájt (az Ethernet adatmező mérete)

*1*	*2*	*3*	*4*	*5*	*6*	*7*	*8*	*9*	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31	32
forrásport(16)																célport(16)
sorszám(32)
nyugtaszám(32)
TCP fejrész hossza				.						URG	ACK	PSH	RST	SYN	FIN	ablakméret(16)
ellenőrző összeg(16)																sürgősségi mutató(16)
opciók(32*x)
DATA

A fejrész 5 db 32 bites szót tartalmaz:

• Saját port és a Címzett port: ÖK. két végpontját azonosítja
• Sorszám (Ns) és Nyugta (Nr): Megszokott a szerepük. A nyugta a

következő várt bájt sorszámát tartalmazza. Mind a 2ét mező 32 bites.

• TCP fejrész: Megmutatja,hogy hány 32 bites szóból áll a TCP fejrész.

A fejrész hossz az opciók tetszőleges mérete miatt érdekes.

• 6db a gyakorlatban használaton kívüli bit helye.
• Ezeket egybites változók követik:
  • URG: sürgősségi mutataó használatát engedélyezi
  • ACK: a nyugta érvényességét jelzi, 0 esetén a szegmens nem tartalmaz nyugtát, figyelmen kívül hagyható a mezeje.
  • PSH: késedelem nélküli továbbítás kérése- pufferelés nélkül
  • RST: hoszt összeomlását vagy az összekötés helyreállításának igényét jelzi.
  • SYN: összekötés létesítésére irányul
    • kérés (CR): SYN=1 & ACK=0
    • elfogadás (CA): SYN=1 & ACK=1
  • FIN: összeköttetés bontását jelzi - a küldőknek nincs több továbbítani való adata.
• Ablakméret: hány bájtot lehet elküldeni a nyugtázott bájttal

kezdődően. 0 ablakméret is érvényes: jelentése: "Köszi, az eddigi adatokat megkaptam őket, de most pihenésre van szükségem, most többet nem kérek!"

• Az ellenőrző összeg a fejrész és az adatmezőn kívül egy pszeudófejrészt is kódol: tartalmazza a forrás és a cél 32bites IP címét! (protokoll hierarchia súlyos megsértése!)

thx to NA &
-- adamo - 2005.12.30.
táblázat helyrepofozása -- Zoz - 2006.01.17.

13. Hogyan valósít meg a TCP megbízható átvitelt? Ismertesse a sorszámozási rendszer sajátosságait!

Mind az összekötés létesítésénél, mind a bontásnál háromutas HS segítségével biztosítja a megbízhatóságát.
Kapcsolat felvétel esetén a TPDU üzenetek sorszámokat tartalmaznak, minden válaszüzenet tartalmazza a megérkezett üzenet sorszámát, ezáltal elkerülhető a késve beérkezett ismétlő üzenet okozta galibák.
A kapcsolat bontása során a (keep alive timer) életbentartó időzítő védi ki az udvariatlan kapcsolatbontást (értesítés nélküli távozás) veszélyeit. Ha az időzítő lejártáig nem érkezik üzenet automatikusan lebontják a kapcsolatot.

14. Hogyan támogatja a TCP a változó adási ablakméretű csúszó-ablakot? Ismertesse az eljárást!

Minden megérkezett üzenet nyugtájában közli (a fennmaradó pufferméret függvényében) a következő üzenethez használt ablakméretet. Ha eléri a 0byte-os puffert megáll a küldés. Két kivételes esetben mégis joga van a küldésre:

• sürgős adat megszakíthatja a vevő gépén futó folyamatokat és elsőbbséget kaphat.
• a holtpont kialakulását előzi meg a második lehetőség: 1 byte-os szegmens segítségével lekérdezi az ablakméretet frissítheti-e már vagy marad a 0 érték.

15. Ismertesse a beágyazódási folyamatot a TCP, az IP, a PPP protokollok használata esetén! Hogyan ágyazódik be a felhasználói adat a TCP szegmensbe, az az IP datagramba, stb.?

állandó IP-fej
változó IP-fej
állandó TCP-fej	IP-adat
állandó TCP-fej	IP-adat
TCP adat	IP-adat

16. Hogyan definiálható a socket? Mi célt szolgál? Lehet-e több socket egy hosztban? Kapcsolódhat-e egy socket több más hoszthoz? Mutassa meg a socket és a port közötti különbséget!

A TCP szolgálat alapja egy csatlakozó (socket) definiálása, ezekehez csatlakozik az alkalmazási folyamat. Socketek között megbízható csatorna kialakítása: Socket:= hálózat címe+ hoszt azonosítója + port. Az első kettő az IP csomag fejrészében található 32 bites cím(megfelel az OSI modell NSAP címének. a 32 bit csak IpV4 esetén igaz) Ahány portunk van annyi socketet tudunk nyitni. Az alkalmazási és szállítási réteg közötti TSAP-t az interneten portnak nevezzük.

thx to NA

17. Milyen hibavédelmi eljárást használ a TCP?

Hibakezelés folytonos ARQ-val történik, alapértelmezett a GO-Back-N eljárás szelektív visszalépés opcionális. Forgalomszabályozás csúszóablakos változó adási ablakmérettel...

thx to NA

18. Milyen kapcsolat-menedzselési eljárásokat alkalmaz a TCP?

3 utas HS lebontás esetén időzítővel, kapcsolatlétesítés esetén sorszámozással kiegészítve.

19. Milyen időzítőket alkalmaz a TCP?

• ismétléses: szegmens újraküldése nyugta hiányában.
• folytatandó: 0 ablakméret esetén a "van-e szabad puffer kéremszépen" kérdés ütemezése - holtpont elkerülés céljából
• életbentartó (KeepAlive): lejár, ha régóta nincs forgalom. Ekkor a hoszt ellenőrzi, él-e még a másik, ha nem, bontja a kapcsolatot.
• bontási (Timed Wait): Miután teljesen megszűnt a kapcsolat, még 120 mp várakozás. Ezzel azt lehet elkerülni, hogy egy gyors bontás - újracsatlakozás esetén az előző kapcsolathoz tartozó szegmenst kapjunk.

20. Ismertesse az UDP szegmens szerkezetét!

Összeköttetés nélküli protokoll. Szegmense 8 bájtos fejrész után a felhasználói adat.

forrásport	célport
szegmenshossz	ellenőrző összeg

szegmenshossz a fej és az adat hosszát fedi. Az ellenőrző összeg használata nem kötelező (ez esetben ki van nullázva) ha nem érzik fontosnak (pl.: digitalizált beszéd). Az UDP nem támogatja a forgalomszabályozást, a hibakezelést és az újraküldést. Egyedül a portok használatával folyamat demultiplexelésre kiváló.

21. Milyen hibavédelmi eljárást használ az UDP?

Semmilyet. Mindent az alkalmazásnak kell megvalósítania, ha szeretne (nyugtázást, sorrendezést, ..) (Volt, de szerintem hibás: "hibás elveszett csomag esetén időzítő hatására újraküldés.")

22. Milyen alkalmazásokhoz előnyösebb a TCP és milyenekhez az UDP?

• AZ UDP használat kliens szerver interakciók és multimédiás összeköttetés kiépítésére. Összeköttetés kiépítése nélküli szolgálat: fontos a csomagforgalom, a hibakezelés vagy az időzítés.
• *TCP*: megbízható bájtfolyam forgalom irányítás hibakezelés újraküldés

-- adamo - 2005.12.27.