HTTP protokol

Pa pazi, ako su ti ciljne grupe korisnici koji koriste HTTP proxy server, onda ti opet ne odgovara ni da portujes taj live streaming na TCP, jer opet proxy ce da razume samo HTTP1.0 ili HTTP1.1 protokol. Jedino da se proxy prosiri sa nekim dodatnim extenzijama za proksiranje udp saobracaja, ili nesto slicno, ali to je samo subjektivno resenje.

Zaista je zalosno sto neki ljudi jos uvek Internet vide samo kroz rupicu proxy servera l;(

---

Niko nije rekao da se koristi proxy. Mozda je samo masq sa firewall-om koji dozvoljava prolaz kroz tcp:80. Ili mozda klasicno rutiranje sa istim firewall-om.
Sve u svemu to je ona druga solucija sto je alex naveo tako da slobodno portuj aplikaciju na tcp i na port 80 i radice ali samo ako ne idete na net preko proxy-ja. Pitaj admina dal idete preko proxy-ja ili direktno.

PS: firewall-a ne zanima dal je to http ftp smtp pop3 pop2 imap4 imap3 ili neki tamo peti sunrpc protokol. njega samo zanima tip prenosa podataka udp tcp icmp port preko koga se odvija komunikacija i ip adrese izmedju kojih se odvija konverzacija.
Tako da sto se firewall-a tice ako tebi program cilja na port 80 preko tcp-a.

Ajde da vidimo ko koliko zna oko protokola prvo, pa da onda unapredjujemo pricu na firewall. Koliko ja znam, HTTP je protokol aplikativnog nivoa TCP/IP stacka, a TCP i UDP su protokoli transportnog nivoa (iliti layer-a) Tj, HTTP je protokol koji "radi" po TCP portu 80. koliko ja znam ne postoji UDP port za HTTP. Drugo, firewall pusta, kao sto je neko vec rekao, ono sto mu ti kazes da pusta. Takodje, "HTTP streaming" ne postoji. Trece, postoji nesto sto se zove OSI referencni model, sto ljudi koji su odgovarali na celu ovu temu ocigledno znaju, te, sergio, potrudi se da ga i ti pregledas.

Protokol koji omogucava prenos A/V zapisa, a koji egzistira u okviru HTTP-a je RTSP (Real Time Streaming Protocol ). Vise informacija na web adresi www.rtsp.org

za sergio-a

Kada neki racunar hoce da ostvari komunikaciju sa drugim racunarom desava se sledece ( ovde pod komunikacijom ne podrazumevam pingovanje ili neke slicne svari vec konekciju na aplikativnom nivou ) :

Aplikacija sa racunara1 poziva aplikaciju na racunaru2. Da bi taj poziv otisao sa racunara1 na racunar2 mora do tamo nesto da ga nosi. To rade protokoli i to ne bilo koji . Tacno se zna njihov redosled. Aplikaciju ne moze da nosi neki protokol iz transportnog sloja kao sto je npr. TCP ili UDP ili sa internet sloja kao sto je ICMP ili ARP nego samo protokol koji radi na aplikativnom nivou. I cak ni ovde na aplikativnom nivou ne moze bilo koji aplikativni protokol da nosi bilo koju aplikaciju.

Znaci odredjena aplikacija sa racunara1 krece da se da se obraca odredjenom racunaru2 tj. odredjenoj aplikaciji na tom racunaru.Nju do drugog racunara nosi tacno odredjeni protokol na aplikativnom nivou koji je predodredjen za tu aplikaciju.
Dalje, nije ni to dovoljno, jer ne moze protokol na aplikativnom novou sa racunara1 da komunicira sa istim tim protokolom na racunaru2 sam od sebe. Nego i njega neko mora da nosi. Tako da sada aplikaciju koju nosi aplikacioni protokol sada sve njih zajedno nosi novi protokol na nizem nivou tj. na transportnom layer-u.

I tek tada se ostvaruje komunikacija. Odlazi se do drugog racunara i dolazi kod njega na transportni layer-u. I sada idemo obrnutim redosledom. Kako smo se tamo od aplikacije pa preko protokola na aplikativnom nivou spustali nadole tako ovde na racunaru2 mi se od najnizeg penjemo na gore i dolazimo do aplikacije.

Racunari1 i 2 su ostvarili komunikaciju.

Naravno ova prica vazi za i za tvoj slucaj. Ako imas neku aplikaciju koja radi na nekom racunaru i koja kontaktira neki Server radi razmene real-time videa, voice stream-a, data stream-a ili kombinacije ovih elemenata mora da postoji protokol preko koga ce sve to da funkcionise. Ali to je protokol na aplikativnom nivou a ne protokol na transportnom layer-u. Znaci tvoje podatke sigurno ne nosi UDP nego opet ponavljam neki aplikativni protokol koji sluzi tacno za tu aplikaciju i koga ona poziva kada krece konekcija a taj protokol nosi UDP na transpornom sloju.

Znaci nije tebi bitan UDP. Tebi je bitan aplikativni protokol. A UDP i TCP su low-level protokoli koji ce u svakom slucaju raditi ispod na Internetu. Jer ta dva protokola nose skoro sve aplikativne protokole na Internetu ( osim naprimer kada pravimo VPN pa koristimo PPTP protokol da ostvarimo tunnel konekciju-on ne koristi ni UDP ni TCP ).

Iz ovoga sledi da nemozes da menjas UDP sa HTTP-om jer je HTTP je aplikacioni protokol, oni su sa dva totalno razlicita layer-a.

Dalje nemozes ni da menjas ni da su ti protokli na istim layer-ima, naprimer da su oba na aplikativnom nivou. Jer tvoja aplikacija koristi tacno odredjeni protokol i da bi koristio drugi protokol na aplikativnom nivou aplikacija mora da ga prepozna a ne da ti odlucis da menjas tek tako.

Dalje ako mozes da koristis HTTP protokol ti znaci koristis neki browser, znaci tvoja aplikacija je browser i ona moze da gadja samo Web Server to jest IIS service na njemu koji je po defaultu ostavio port 80 koji ceka da se uspostavi konekcija.


Protokoli koji se koriste za to sto ti trazis su npr. PNM-RealNetwork protocol, RTSP, MMS-Windows media protocol ....

Ali opet ti kazem odredjena aplikacija vuce odredjeni protokol.

Sto se tice Firewall-a, svaki Firewall propusta samo ono sto onaj koji ga odrzava odredi ( kao sto je neko vec ranije rekao ). Tako da on uopste nemora da propusta HTTP ako nije tako setovan. Radi se o tome da su skoro svi Firewall-i u namesteni da pustaju HTTP da bi moglo da se ide na Web site-ove.

Posto si napisao da treba da prodjes kroz Firewall da bi otisao na taj server na Internetu treba da znas tacno koji protokol koristi ta aplikacija i da znas na kom portu radi ta apikacija. Kada imas te informacije pravis rule
koji propusta kroz Firewall bas ono sto ti hoces i ti odlazis na zeljeni Server.
U celoj ovoj prici najbitniji je port.
Jer sa tim portom tvoja aplikacija gadja Server na Internetu. A taj Server bas na tom istom portu ceka.

Znaci ono sto si napisao da Firewall propusta samo HTTP preko porta 80, nepropusta on to tako. Tvoj Web browser gadja Server i to Web server
na Internetu. Zahtev sa tvog racunara ili bilo kog klijentskog racunara koji se nalazi iza Firewall-a dolazi do tog Firewall-a. I sada on propusta HTTP zahtev ali ne na portu 80. On otvara bilo koji port na kartici i to svaki put drugacije iz nekog opsega portova npr. 3012 ( dinamicki portovi ).
Ali zato kada dodje na odredisni Server on gadja PORT 80 , a ovaj ga upravo na tom portu ceka.

Mirko