From: Deger Cenk Erdil (erdil@cs.binghamton.edu)
Date: Sun 20 Apr 2003 - 00:38:36 EEST
Gurkan bey yazdiklariniza bir dipnot dusmek istiyorum:
bildigim kadariyla TCP/IP ne yazik ki OSI referans modeline gore kurulmus
degildir. bir kac kaynak bunu soyle anlatiyor: o siralarda bir referans
modeline cok ihtiyac vardi, ayni zamanda bir "protocol suite"ine de
ihtiyac vardi. ISO'nun OSI standardini belirlemedeki yavasligi ve
hantalligi sebebiyle OSI bir referans olarak ortaya cikana kadar TCP/IP
uygulamaya gecmis kullanilmaya baslanmistir.
TCP/IP ile ilgili butun RFC'lere bakin, OSI'ye bir referans
goremezsiniz. cunku TCP/IP gelistirilirken OSI ortada yoktur. yani aslinda
vardir ama gelistirilme asamasindadir.. bu konuda TCP/IP'nin ilk
surumleri/tanimlamalari Cerf ve Kahn tarafinda 1974 yilinda yapilmisken,
OSI'nin bir "standard" olarak ortaya cikmasi 1980 yilini bulmustur.. daha
sonra bir cok kaynak bu iki ayri dali birbiriyle birlestirmeye, en azindan
ortusturmeye calismis ama basarili olamamistir.
sizin anlattiginiz gibi OSI ve TCP/IP birbirleriyle tam olarak
ortusmezler. katmanlarinin tanim kumeleri hakkinda degisik gorusler
vardir. Ne "presentation" ve "session" katmanlari ne de onlarla ilgili
kavramlar TCP/IP'de mevcut degildir. "Transport" katmani vardir, ve buyuk
olcude iki tarafta birbirleriyle ortusurler.. OSI'nin "network" katmani
ise biraz daha genis/bulanik bir tanimla TCP/IP'de "internet" katmani
olarak adlandirilmistir.. bazi kaynaklar TCP/IP'yi 4 katman (Tanenbaum,
Stallings, vs.), bazilari 5 katman olarak gosterirler.. oteki katmanlari
da kimin kimden referans aldigi belli degildir :-) hatta bir cok yerde
TCP/IP "suite"i kendi basina bir referans modeli olarak kabul
edilmektedir.
yani kisaca OSI bir sablon modeldir, ama ne yazik ki Internet icin cok gec
kalinmis bir tanimlamadir. TCP/IP ise kendi basina bir modeldir.. OSI yeni
tasarlanacak bir sistem icin guzel bir baslangic noktasidir, ama
uygulamadaki ayrintilara girmez.
ya da OSI bir dusunurdur, filozoftur, TCP/IP ise bir muhendis :-)
sevgiler,
-dce.
On Sat, 19 Apr 2003, [iso-8859-9] G=FCrkan KARABATAK wrote:
> Selamlar
>=20
>=20
>=20
> >> gorur paketin icerigi onemli degildir ama datayi elde etmeye calisir=
=3D20
> >> ve =3D3D tekrar olusturmak icin elde etmek zorunda. Ornegin bir=3D20
> >> encriyption veya =3D3D sikistirma varsa bunu cozmek zorunda veya bir =
=3D
> ascii=3D20
> >> binary donusup =3D3D gerekiyorsa yapmak zorunda cunku datanin 2. bir=
=3D20
> >> yazilim tarafindan =3D3D
>=20
> >Burasi kabul edilemeyecek, tartisilmayacak kadar yanlis olmus. Datapipe =
=3D
> >hicbir encryption'u, sikistirmayi, vs. cozmek ve bilmek zorunda degil. =
=3D
> >Yalnizca paket icerigini okur (icerik her ne ise) ve gonderir. Bir =3D
> >decriyption,vs. yapilmasi gerekiyor ise bunu alici yapar/yapmali zaten.
>=20
> Sanirim ya yine siz yanlis anladiniz ya ben yanlis anlattim.
>=20
> Bahsettigim sey gayet dogru. Yanlis olan sizin bunu datapipe in =3D
> kendisinin yaptigini anlamaniz. Bunu datapipe degil kernel yapar. Soyle =
=3D
> aciklayayim
>=20
> TCP/IP, OSI Referans modeli baz alinarak gelistirilmis bir protokoldur. =
=3D
> OSI Referans modeline gore bir data ag uzerinden alinip islenebilmek =3D
> icin 7 katmanda islem gorur. Bu katmanlari tahminimce bilirsiniz. Bu =3D
> katmanlar data elde edilirken alttan uste dogru calisir. Ve sirasiyla su =
=3D
> islemler yapilir.
> Bilmeyen olursa diye islemlerin konumuzla ilgili olanlarini yaziyorum.
>=20
> 1. katmanda paket fiziksel ortamdan alinir
> 2. katmanda Mac headerlara bakilir paketin sahibi paketi alir.
> 3. katmanda Ip headerlari atilarak paket segmente donusturulur.
> 4. katmanda data hatalara karsi kontrol edilir
> 5 6 ve 7. katmanlar TCP Ip de Application adinda birlestirilmistir. Ve =
=3D
> 6. katman dedigimiz Presentation (Sunum) katmaninda Paket uzerinde =3D
> uygulanmis olan Encryption lar Sikistirma islemleri Bir takim donusumler =
=3D
> (ASCII-EBCDIC) gibi bazi donusumler yapilir ve 7. katmanda veri tum =3D
> headerlardan arindirilmis olarak User applicationa verilir.=3D20
>=20
> Iste datapipe dedigimiz olay bu tur bir application dir. Ve paket Tum bu =
=3D
> adimlardan gecer. Ve data tekrar gonderilecegi zaman tum bu adimlar =3D
> tersine isler. Yani agdan bir paket geldiyse datayi alip isleyecekseniz =
=3D
> 6. katmanda olan bu donusum islemleri ister istemez yapilmak zorundadir =
=3D
> (Kernel duzeyinde calismiyorsaniz).
>=20
> Netfilterde Olay boyle gerceklesmez. Bahsettigimiz kuralda Paket daha 3. =
=3D
> katmana ciktigi zaman headerlar degistirilir daha yukariya cikmadan =3D
> tekrar 2. katmana oradan 1. katman yoluyla fiziksel ortama birakilir. =3D
> Data elde edilsin diye ust katmanlara cikmaz. Bahsettigim data elde edme =
=3D
> olayi burasi.(Yazdiginiz kurallara gore degisebilir string islemi gibi). =
=3D
> Cunku netfilter Kernelle butunlesik calisir bir paketin illa 7. =3D
> katmandan gecip datanin elde edilmesi gerekmez.=3D20
>=20
> Olayin sirri burada iste. Datapipe application olarak isledigi icin her =
=3D
> gelen paket bu 7 islemden (TCP/IP modelinde 4) gececektir. Ancak =3D
> Netfilter de bu islem nerdeyse yari yariya daha hizli yapilacaktir. =3D
> Yoksa firewall olarak bu kadar hizli paket anahtarlama yapmasi =3D
> imkansizdir ve tikanmalara sebep olur.
>=20
>=20
>=20
> Diger konuya gelince http redirect olayinda sanirim bir sorun yok. =3D
> Calisma mantigini ikimizde biliyoruz. Ben sadece Iptables la daha =3D
> avantajli olur demistim bunun nedeni iste yukaridaki sebeple ayni.
>=20
> Yukaridaki yazdiklarim ezbere yazdigim kendi bilgilerim. Bazi kisimlarda =
=3D
> ufak hatalar yapmis olabilirim.
> Saygilar.
>=20
>=20
>=20
>=20