kvp#4
Az ftp olyan mint a telnet. Titkositatlan es meg az ellen sem ved, hogy valaki a elvegye elolunk az eppen letolteni szandekozott file-t. (ehhez eleg egy jokor kiadott netcat parancs egy masik geprol) Nem biztonsagos es nehezen hasznalhato tuzfalakon at. A firefox is joreszt csak az anonim (publikus) passziv letoltest tudta uzembiztosan kezelni. Persze nem a https az alternativaja, hanem az scp vagy az sftp. Ezeket siman belerakhatnak a bongeszobe, de mivel egy bongeszo alapvetoen nem telnet, ssh vagy ftp kilens, hanem http/https, ezert nem meglepo, ha nem akarnak ezzel szivni. A https egyebkent akkor alternativaja az ftp-nek, amikor publikus file-okat akarunk letolteni egy weboldalrol. Regebben a weboldalak ftp-s letoltesi linkeket tartalmaztak, ma mar jellemzoen ezek a letoltheto file-ok is a webszerveren vannak fent.
Vannak rendes rlogin/telnet/ssh/ftp/sftp/scp kliensek, amik viszont ezeket a protokollokat kezelik viszonylag jol.
ps: IPv6-tal kapcsolatban annyi info, hogy a legtobb mobilnetes kapcsolat mar itthon is azt hasznal, mert a szolgaltatok reges regen kifogytak a v4-es cimekbol, meg a nat-oltakbol is. NAT jellemzoen mar csak akkor kell amikor egy ipv6-os keszulek csak ipv4-es cimmel rendelkezo szervert akar elerni. Az ipv6 egyebkent semmit nem valtoztatott a folotte futo protokollokon, ugyanugy a regi tcp megy felette mint eddig.
Media stream-elesre https-t csak akkor hasznalnak, ha elore buffer-elt tartalomrol van szo, tehat a gep letolti a stream-et. Ilyen pl. a youtube. Rendes stream-ek eseten (pl. video vagy audio hivasok) udp-n megy minden adat. (az UDP-s youtube stream olyan lenne, amibe nem tud valaki azonnal beletekerni vagy megallitani, tovabba halozati ingadozasok eseten kimaradnana a kep meg a hang, igy inkabb bufferelnek https-en es all meg a video amig helyre nem all a forgalom, minthogy percenkent kimaradjon 1-1 masodperc a videobol, aztan 10 masodperc legyen amig helyreall a kep integritasa, a youtuble egy elore felvett video szoltaltatas, nem realtime video chat)