Početna › Mrežni modeli i protokoli › Praktični primeri
💾

Praktični primeri – Modul 2 – Mrežni modeli i protokoli

Primer 1 – Praćenje puta veb zahteva kroz OSI slojeve

Scenario: Korisnik u pregledaču ukuca https://www.primer-firma.rs i pritisne Enter.

Korak po korak (pojednostavljeno, sa fokusom na slojeve):

  1. Aplikacioni sloj (7): Pregledač formira HTTPS zahtev (GET zahtev za početnu stranicu sajta).
  2. Prezentacioni sloj (6): Podaci se pripremaju za TLS šifrovanje (deo HTTPS mehanizma).
  3. Sesijski sloj (5): Uspostavlja se sesija komunikacije sa serverom sajta.
  4. Transportni sloj (4): Prvo se uspostavlja TCP konekcija (three-way handshake) ka portu 443 servera; zahtev se enkapsulira u TCP segment.
  5. Mrežni sloj (3): Segment se enkapsulira u IP paket, sa izvornom IP adresom korisnika i odredišnom IP adresom servera (dobijenom prethodno putem DNS upita).
  6. Sloj veze podataka (2): Paket se enkapsulira u Ethernet okvir, sa MAC adresom korisnikovog uređaja i MAC adresom prvog "skoka" — obično default gateway-a (rutera), jer je server na internetu, van lokalne mreže.
  7. Fizički sloj (1): Okvir se pretvara u niz bitova i fizički šalje kroz mrežni kabl ili Wi-Fi signal.

Objašnjenje rezultata: Ovaj proces ilustruje kompletnu enkapsulaciju opisanu u Temi 11, primenjenu na stvaran, svakodnevni scenario. Server na drugom kraju prolazi kroz obrnut proces (dekapsulaciju) da bi pročitao stvarni HTTP zahtev, i zatim vraća odgovor koji prolazi kroz isti proces enkapsulacije/dekapsulacije u suprotnom smeru.

Primer 2 – Prepoznavanje protokola na osnovu broja porta

Scenario: Mrežni administrator gleda firewall log i vidi sledeće pokušaje konekcije ka serveru firme, svaki naveden sa brojem odredišnog porta: 443, 22, 25, 53, 3389 (dodatni primer van obrađenih protokola, koristi se za RDP — Remote Desktop Protocol, samo za ilustraciju metode zaključivanja), 80.

Korak po korak:

  1. Za svaki broj porta, administrator prvo proverava da li je to jedan od "well-known" portova (0–1023).
  2. Port 443 → HTTPS (šifrovan veb saobraćaj).
  3. Port 22 → SSH (udaljen, bezbedan pristup komandnoj liniji).
  4. Port 25 → SMTP (slanje elektronske pošte).
  5. Port 53 → DNS (upiti za razrešavanje imena).
  6. Port 3389 → nije obrađen u ovom modulu, ali administrator zna da nije u opsegu well-known portova vezanih za protokole iz ovog modula, pa bi po potrebi proverio dodatnu referencu/dokumentaciju.
  7. Port 80 → HTTP (nešifrovan veb saobraćaj).

Objašnjenje rezultata: Poznavanje standardnih brojeva portova omogućava administratoru da brzo proceni prirodu saobraćaja i donese odluku o tome da li je neki pokušaj konekcije očekivan (npr. HTTPS ka veb serveru) ili sumnjiv (npr. neočekivan pokušaj na portu koji se ne koristi ni za jedan legitiman servis firme), čime se ubrzava dijagnostika i bezbednosna analiza.

Primer 3 – TCP naspram UDP: izbor protokola za konkretnu aplikaciju

Scenario: IT tim firme razvija dve nove funkcionalnosti internog sistema: (a) sistem za deljenje i sinhronizaciju važnih poslovnih dokumenata između zaposlenih, i (b) sistem za video pozive unutar firme.

Analiza za (a) — deljenje dokumenata:

  • Zahtev: dokumenti moraju stići kompletni i neoštećeni, redosled podataka mora biti tačan, brzina je manje kritična od tačnosti.
  • Zaključak: koristi se TCP, jer njegova pouzdanost (potvrde prijema, retransmisija) direktno odgovara zahtevu da nijedan deo dokumenta ne sme nedostajati ili biti oštećen.

Analiza za (b) — video pozivi:

  • Zahtev: komunikacija mora biti u realnom vremenu sa minimalnim kašnjenjem; kratak gubitak par frejmova videa je prihvatljiv i manje primetan korisniku od kašnjenja izazvanog čekanjem na retransmisiju.
  • Zaključak: koristi se UDP, jer njegova brzina i nizak nivo kašnjenja direktno odgovaraju zahtevu za komunikacijom uživo, dok povremeni, kratak gubitak kvaliteta ne narušava suštinski upotrebljivost sistema.

Objašnjenje rezultata: Ovaj primer pokazuje kako se teorijsko znanje o razlici TCP/UDP (Teme 12–13) direktno primenjuje na stvarne inženjerske odluke prilikom biranja tehnologije za konkretnu poslovnu potrebu.

Realni poslovni scenario – Dijagnostika "sajt ne radi" korišćenjem slojevitog pristupa

Ivana, Help Desk tehničarka, prima prijavu: "Ne mogu da otvorim naš interni portal, piše mi greška." Umesto nasumičnog isprobavanja rešenja, Ivana sistematski prolazi kroz slojeve, kombinujući znanje iz ovog modula:

  1. Fizički/Sloj 2: Proverava da li korisnik uopšte ima aktivnu mrežnu vezu (kabl/Wi-Fi) — potvrđeno, veza je aktivna.
  2. Sloj 3 (IP): Traži od korisnika da pokrene ping ka IP adresi servera portala — ping je uspešan, što znači da postoji osnovna IP dostupnost.
  3. Sloj 3/Aplikacioni (DNS): Pita korisnika da li greška pominje da "stranica ne postoji" ili nešto slično problemu sa imenom — utvrđuje da korisnik uopšte ne može da otvori portal ni preko imena.
  4. Ivana sama testira nslookup portal.firma.rs sa svog računara — dobija ispravnu IP adresu, što znači da DNS server firme radi ispravno za nju.
  5. Ivana traži od korisnika da pokuša nslookup portal.firma.rs na svom računaru — otkriva da korisnikov računar koristi pogrešan (zastareo ili nedostupan) DNS server, verovatno zbog nedavne izmene mrežnih podešavanja.
  6. Zaključak i rešenje: Problem nije bio na samom serveru portala (Sloj 7 — aplikacija je bila potpuno ispravna), već u DNS rezoluciji na strani korisnika (deo aplikacionog sloja, Tema 20) — Ivana ispravlja DNS podešavanja na korisnikovom računaru i portal odmah počinje da radi.

Ovaj scenario pokazuje zašto slojevit pristup dijagnostici (obrađen detaljnije u Modulu 20) štedi vreme i sprečava nasumično "pokušaj-pa-vidi" rešavanje problema.