11. ANA UYGULAMA KATMANI PROTOKOLLERİ
Bu bölümde birçok internet tesisinde kullanılan uygulama katmanı
protokollerini inceleyeceğiz. Buradaki amacımız son kullanıcıya sağlanan ana servisleri
genel olarak tanıtmaktır. Bu bölüm dahilinde incelenen protokoller şunlardır:
TELNET: terminal servisleri içindir Çoğu üründe, bu protokollerin çalıştırılması basittir; genelde bu bir veya
birkaç terminal komutu girmekten veya bilgisayar ekranındaki bir ikona
tıklamaktan daha karışık değildir. Tanımlamanın bu kısmını satıcı-özel
kullanım kılavuzlarına bırakmak en iyisidir. Bu bölümde bu protokollerin
çalıştırılmasından ziyade mimarileri üzerinde odaklanılmıştır. 11.1 TELNET Protokolü Bilgi işlem merkezinden sorumlu bir yönetici düşünelim. İşlem merkezindeki
bir host bilgisayar birçok terminal arasındaki haberleşme işlemlerini
desteklemekle görevlidir. Bu terminaller birbirlerinden farklı
karakteristiktedirler. Örneğin, bir DEC terminalindeki kullanıcı
Hewlett-Packard terminalindeki kullanıcı ile haberleşmek ihtiyacındadır.
Haberleşmek kolay sayılmaz. Her iki cihaz da farklı ekran ve tuş takımı
kontrol karakterleri kullanırlar, ve her ikisi de haberleşme linkindeki
trafiği yönetmek için farklı hat protokolleri kullanırlar. Eğer host cihazın geniş bir terminal yelpazesini desteklemesi gerekiyorsa,
değerli kaynaklar protokol farklılıklarını çözmek için cihazın CPU
çevrimlerinde harcanır, ve çevirmeyi gerçekleştirecek destek yazılımının
tasarımı ve kodlaması pahalı bir girişimdir. Bilgi işlem merkezinin
yöneticisi, bu farklı cihazlar arasında çeviri yapabilmek için, sistemleri
geliştirmek veya elde etmek üzere büyük bir zaman ve epeyce bir kaynak
harcamalıdır. TELNET bu sorunlara çözüm sağlar. Örneğin, TELNET’le host bilgisayarın,
haberleşeceği diğer host’lara bağlı terminallerin karakteristiklerini
öğrenmesi sağlanır. Eşit ölçüde önemli olarak, TELNET iki makine arasındaki
terminal-tabanlı oturum için gerekli olan fonksiyonların ve servislerin
müzakere edilmesini sağlar. Bu yaklaşım protokol dönüştürme sorununu daha hoş
yapar çünkü müzakere eden cihazlar iki cihaz tarafından desteklenmeyen
servisleri kullanmama seçeneğine sahiptirler. TELNET farklı makineler
arasında protokol dönüşümü sağlamaz. Bunun yerine, makinelerin
karakteristiğine karar veren bir mekanizma ve de veri alışverişi için,
makinelerin internetworking’lerini müzakere edebilecekleri araçlar sağlar. TELNET protokolü bir host cihazı üzerindeki bir programın (TELNET
istekçisi denir) başka bir cihazın (TELNET sunucusu denir) kaynaklarını
kullanmasını sağlar. Tek gereken, istekçinin sunucuya yerel olarak bağlı
olmasıdır (Şekil 11-1’e bakınız). TELNET çeşitli özellikler sağlamasına
rağmen, bazı insanlar bu standarda remote login protokolü derler çünkü TELNET
bir host cihazı ile bir uzak cihaza login yapılmasını destekler. Dikkat
edelim ki, diğer ‘remote login’ protokolleri TELNET’in yanında yer alırlar.
Örneğin, SUN iş istasyonları bir remote login (R login) prosedürüne sahiptir.
Şekil 11-1 TELNET
Modeli 11.1.1 Ağ hayali terminali TELNET standardı bir ağ hayali terminali (NVT) fikri temeline dayanır.
Hayali teriminin kullanılması bir NVT’nin gerçekten var olmamasındandır. NVT
aslında bir terminalin karakteristiklerini göstermek için standart araçlar
sağlayan hayali bir cihazdır. Bu fikirle haberleşilen her bir terminalle
ilgili karakteristiklerin sağlanması görevi host bilgisayarına ait olur.
TELNET standardı ile, hem kullanıcı hem de sunucu cihazlarının kendi terminal
karakteristiklerini hayali terminal tanımlamasına göre haritalamaları
gerekmektedir. Sonuçta cihazlar NVT ile haberleşiyorlarmış görüntüsü verirler
çünkü iki taraf da tamamlayıcı bir haritalama sağlar. 11.1.1.1 Müzakereler TELNET protokolü, diğer hayali terminal protokollerine benzer olarak,
haberleşen makinelerin oturum sırasında kullanılacak çeşitli opsiyonları
müzakere edebilmelerini sağlar. Sunucu ve istekçinin bu opsiyonları
kurabilmek için standart bir prosedürler kümesi kullanmaları gerekir. Bu
opsiyonlar TELNET protokolünün analizi süresince incelenecektir. Müzakereli opsiyonların kullanımı, host makinelerinin hayali terminalin
sağladığının ötesinde servisler sağlayabileceği olasılığını ortaya çıkarır.
Bundan başka, TELNET modeli, protokollerce şart koşulanlar dışında, müzakere
edilmiş opsiyonları sınırlamaz. Bunun yerine, TELNET tanımladıklarının
ötesinde farklı anlaşmaların müzakere edilebilmesini sağlar. 11.1.2 TELNET RFC’leri Internet standartları, müzakere edilebilecek TELNET opsiyonlarını
tanımlamak üzere, çeşitli RFC’ler içerir. Tablo 11-1’de TELNET opsiyon
kodlarının bir listesi vardır (numaraları ve eğer varsa ilgili RFC’leri ile
birlikte). Bu opsiyonların tümünün her bir satıcı ürününde olduğu kanısına
varmayın çünkü çoğu TELNET ürünü tüm olası opsiyonları desteklemez. Şekil 11-2’de iki taraf arasında opsiyonların nasıl müzakere edilebileceği
gösterilmiştir. Taraflardan biri belli bir opsiyonla (Şekilde x fonksiyonu)
ilgili olarak diğer tarafı sorgulayarak müzakereyi başlatabilir.
Şekil 11-2 TELNET
Müzakereleri Şekilde, cevaplayan taraf opsiyonu destekleyebileceğini belirtmektedir.
Bundan sonra, başlatan taraf cevaplayan tarafa opsiyonunun karakteristiğini
sorar. Cevaplayan taraf opsiyonla ilgili bilgisini gönderir. Bu bilgi cevaplayan
tarafın terminalinin karakteristiklerini veya diğer işletim gereksinimlerini
tanımlar. İki taraf arasında akan mesajlar TELNET mesaj formatına (komut yapısı
denen) sadık olmalıdırlar. Örneğin, başlangıç işareti "destekler
misin" veya "destekleyecek misin" özel TELNET kodları do veya
will ile sağlanır. Dönüşte, cevaplayan taraf bir TELNET kodu göndermelidir
(bu örnekte, cevaplayan taraf bir will kodu göndermektedir). Tablo 11-2’de kodların isimleri, TELNET mesajlarındaki değerleri ve kısaca
anlamları listelenmiştir. Tablo, altı TELNET fonksiyonunu tanımlamak üzere
altı satır girişi içerir. Bu fonksiyonlar hemen hemen tüm terminal-tabanlı
uygulamalarda ortaktır; böylece, TELNET standardı bunları göstermek üzere
araçlar tanımlar. Interrupt prosesi fonksiyonu, sisteme bir kullanıcı prosesini erteleme,
kesme, iptal etme veya sonlandırma imkanı sağlar. Örneğin, kullanıcıya sonsuz
döngüden kurtulabilmesi için bir işlemi sonlandırma imkanı sağlanır. Abort çıkışı (AO) fonksiyonu bir uygulamanın tamamlanmak üzere çalışmasına
izin verir ancak çıkışın kullanıcı iş istasyonuna gönderilmesini engeller. Bu
fonksiyon aynı zamanda kaydedilmiş ancak hala gösterilmemiş (displayed)
çıkışları siler. Orda mısın (AYT) fonksiyonu bir kullanıcının uygulamanın icra edilip edilmediğini
bilmek istediği zaman kullanılan faydalı bir işlemdir. Tipik olarak bir
kullanıcı, belli bir zaman süresince mesajlarını alamamışsa AYT fonksiyonunu
çağırır. Karakter sil (EC) fonksiyonu kullanıcının veri nehrindeki bir
karakteri silmesini sağlar. En basit şekli ile, giriş hatası
yapıldığında ekran üzerinde veriyi düzeltmekte kullanılır. Satır sil (EL) fonksiyonu kullanıcının düzeltme sürecinde bir giriş
satırını silebilmesini sağlar. Tablo 11-2’de tanımlanan kodlara ek olarak, TELNET yazıcı çıktılarının
değiştirilmesini sağlayan kodlara da sahiptir. Kodlar hayali terminal
protokollerindeki kodlara oldukça benzerdir. Bu kodlar; horizontal tab (HT),
vertical tab (VT), form feed (FD), back space (BS), Bell (BEL), line feed
(LF), carriage return (CR), vs. gibi işlemleri gerçekleştirirler. Tablo 11-1 TELNET
Opsiyon Kodları
11.1.3 TELNET komutları TELNET veri birimlerine komut denir, ve formatları Şekil 9-3’te
gösterilmiştir. Eğer üç bayt kullanılacaksa, ilk bayt komut olarak yorumla
(interpret as command (IAC)) baytıdır ki bu TELNET’in rezerve edilmiş bir
kodudur. Aynı zamanda bir escape karakteridir çünkü alıcı tarafından gelen
trafiğin bir veri veya bir TELNET komutu olduğunu algılamada kullanılır. Bunu
takip eden komut kodu baytıdır, IAC baytı ile birlikte kullanılır. Üçüncü
bayta opsiyon müzakeresi kodu denir. Oturum süresince kullanılacak
opsiyonları tanımlamada kullanılır. Tablo 11-2
Telnet Komut Kodları
Şekil 11-3 TELNET
Komut Formatı 11.2 Trivial File Transfer Protokolü TFTP basit bir dosya transfer protokolüdür. FTP kadar karmaşık değildir ve
onun kadar fonksiyona sahip değildir. Fazla kod içermez ve hafızada fazla
yer tutmaz; sonuç olarak, küçük cihazlarda kullanılabilir. TFTP hiçbir güvenlik veya kullanıcı yetkisi sağlamaz. Aslında, çok
az bir uçtan-uca güvenilirliği vardır çünkü UDP ile çalışır, TCP’yi
kullanmaz. TFTP toplamsal hata-kontrolü, zamanlayıcı desteği, ve
yeniden-iletim yeteneklerine sahiptir. Tipik olarak, iletici sabit bir veri bloğu (512 bayt) gönderir ve sıradaki
bloğu göndermeden önce alıcıdan bir acknowledgment (onay) bekler. Bu tip bir
işlem, flip-flop protokolü olarak anılır çünkü iletici sıradaki veri bloğunu
göndermeden önce alıcıdan bir onay beklemelidir. Her bir blok sırayla numaralanmıştır. Acknowledgment alanı onaylayan
blokların sayısını içerir. Mesajın sonu 512 bayttan daha az veri içeren
fragmantasyonlu bir bloğun gönderilmesi ile anlaşılır. Bu protokol sağlam olmak üzere tasarlanmamıştır. Herhangi bir sorun
bağlantının sonlandırılmasına sebep verebilir. TFTP, yalnızca bazı hata
mesajları sağlar ve aynı zamanda mesajlar kaybolduğunda da anlayabilmek için
timeout’ları destekler. Genelde, aşağıdaki durumlarda hatalar oluşur: · taraflardan biri gerekli isteği yapamaz (örneğin, istek formatı
bozuktur, bir dosya yerleştirilmemiştir, vs.) TFTP bugün yaygın olarak kullanılmamaktadır, ancak bazı satıcılar,
uyumluluk sorunlarını rahatlatmak için, TFTP’yi ürünlerine dahil etmişlerdir.
Örneğin, IBM’in kendi kişisel bilgisayarları için ürettiği TCP/IP
ürünlerinde, AIX ve PC DOS makineleri arasında etkileşime izin vermek
amacıyla, TFTP kuruludur. 11.3 File Transfer Protokolü Internet standartları daha güçlü olan ve daha yaygın kullanılan bir dosya
transfer protokolü olan FTP’yi (file transfer protocol) içerir. FTP iki
makine arasında dosya transferi yapılabilmesi için prosedürler tanımlar. FTP, oldukça alışılmadık bir biçimde, makineler arasında iki mantıksal
bağlantı sağlar. Bağlantılardan biri, makineler arasında login için
kullanılır. Bu bağlantı TELNET protokolünü kullanır. Şekil 11-4’de bu kavram
gösterilmiştir. Son kullanıcı bir protokol çeviricisi (PI) ile haberleşir. Bu
PI kontrol bağlantısını yönetir. PI, kullanıcı ve PI’ın dosya sistemi
arasında bilgiyi transfer etmelidir. Komutlar ve cevaplar kullanıcı-PI ve
sunucu-PI arasında iletilir. Şekilde gösterildiği gibi, diğer makinenin
(sunucunun) PI’sı, yönetim bağlantıları için de TELNET protokolünü cevaplar. Şekil 11-4 FTP
Modeli Dosya transferi sırasında, veri yönetimi, ‘data transfer process (DTP)’
denilen diğer mantıksal bağlantı ile sağlanır. Bir kere DTP fonksiyonlarını
gerçekleştirince ve kullanıcının isteği sağlanınca, PI bağlantıyı kapatır. FTP aynı zamanda üçüncü-taraf transferi olarak bilinen bir işleme izin
verir. Şekil 11-5’de görüldüğü gibi bir istekçi, ikisi de sunucu olarak
davranan iki uzak makineyle bağlantı kurar. Böyle bir bağlantının amacı
istekçinin, iki sunucunun dosya sistemi arasında dosya transfer izni almak
için, istek yapmasıdır. Eğer istek onaylanırsa, bir sunucu diğer sunucuyla
bir TCP bağlantısı oluşturur ve gönderici FTP modülü, veriyi TCP modülleri
boyunca ilerleterek alıcı FTP modülüne transfer eder. 11.3.1 Veri tipleri FTP’nin farklı tiplerdeki veri gösterilişlerini ve makineler arası bu
tiplerin nasıl kullanılacağına dair müzakere yapılmasını destekleme yeteneği
sınırlıdır. FTP kullanıcısı transferde kullanılacak bir tip tanımlayabilir
(örneğin, ASCII, EBCDIC, vs.). ASCII default tiptir, ve FTP kurulduğu
sistemde ASCII kodunun desteklenmesini gerektirir. EBCDIC de aynı zamanda
desteklenir ve mainframe host bilgisayarları arasında veri transferlerinde
biraz daha yaygın olarak kullanılır. ASCII ve EBCDIC bir ikinci parametre kullanarak karakterlerin format
kontrol amaçları için kullanılacağını veya kullanılamayacağını belirtirler.
Örneğin carriage return (CR), line feed (LF), dikey tab (VT), ve form feed
(FF) FTP oturumu boyunca kontrol karakterleri temsil etmek üzere
tanımlanabilirler. Şekil 11-5 FTP ile
üçüncü-taraf transferi FTP, bit nehirlerinin transferini de destekler. Bu bit nehirlerine imaj
tipleri denir. Bu işlemle, veri sürekli bit nehirleri içinde gönderilir.
Gerçek transfer için veriler, 8-bit baytlara paketlenir. Çoğu işlem ikilik
imajlar iletmek için imaj tiplerini kullanır. Böylece çoğu FTP uygulamaları
imaj tipini destekler. FTP yerel bir tipi de destekler. Bu tip baytlar içerisinde iletilir ve
burada bayt büyüklüğüne byte size denilen bir parametre ile karar verilir.
FTP’de byte size değeri ondalık bir tamsayı olarak gösterilir. 11.3.2 FTP komutları ve cevapları FTP, ön tanımlama, password yetkisi, ve dosya transfer işlemleri için bazı
komutlar kullanılır. Tablo 11-3’de bu komutların kısaltmalarını ve
fonksiyonlarının kısa bir tanımlamasını bulabilirsiniz. Tablo 11-3 FTP
Komutları
FTP aynı zamanda iki proses arasında doğru dosya transferi yapmak için
belli sayıda cevaplar tanımlar. Adından da anlaşılabileceği gibi, bu cevaplar
FTP komutlarının bir sonucu olarak istenir. Cevaplar üç-basamaklı bir sayıyı
takip eden tanımlayıcı metinlerden oluşurlar. Cevapların ilk basamağı 1-5
arası bir değer alabilir. Bu değer cevapların beş ana tipini belirtmek için
kullanılır. Tablo 11-4’de cevapların ana tiplerini ve fonksiyonlarının kısa
açıklamalarını bulabilirsiniz. Tablo 11-4 FTP
Cevap Kodları
Cevap kodlarının y değeri, cevabın doğası ile ilgili ek
bilgi içermek üzere, kodlanabilir. Bu koddaki cevap tipleri, 0-5 arası altı
değeri alarak; statü komutları, yazım hataları, yetki komutları, kontrol,
veri bağlantı komutları, vs. gibi ilgili cevapları tanıtırlar. Tablo 11-5’de
bu kodlar listelenmiştir ve tanımlanmıştır. Tablo 11-5 FTP
Cevap Kodları
Üçüncü basamak cevabın anlamı ile ilgili daha detaylı bir seviye tanımlar.
Bu kodlar çeşitlidir ve bu bitirme tezinin bakışının ötesindedir ancak
bunların kullanımı ile ilgili bir örnek kısaca sunulmuştur. FTP cevap
kodlarının bu detay seviyesi üzerinde daha fazla bilgi edinmek için RFC 959’a
başvurunuz. 11.3.3 Bir FTP oturumunda işlemlerin sırası FTP iki kullanıcı arasında veri transferini sağlamak için belirli
iyi-sıralanmış adımlar takip eder. Bu bölümde adımlar oluş sırasına göre
anlatılacaktır. 11.3.3.1 Uzak host’a login İki kullanıcı arasında veri transferi oluşmadan önce, login işlemi tamamlanmalıdır.
Bu login’in fonksiyonlarından biri password’ların, yetki kodlarının, ve diğer
güvenlik özelliklerinin yeterli olduğunu garantilemektir. Minimum olarak, bir
kullanıcı; diğer host cihazının kabul edebileceği bir kullanıcı ismine ve
password’a sahip olmalıdır. Login işlemi süresince,veri transferini kontrolde kullanılacak bazı
tabloların değiştirilmesi olasıdır. Eğer bir kullanıcı farklı bağlantılar
için farlı destek servisleri istiyorsa, bu fonksiyon çok kullanışlı olur. 11.3.3.2 Dizin tanımı (directory definition) Bu özellik gerekli olabilir veya gerekli olmayabilir. Dizin tanımı ile,
bir kez kontrol bağlantısı sağlanınca, verinin yerleşeceği boşluğu yönetmek
için dizin değiştirilebilir. 11.3.3.3 Dosya transfer tanımı Bu üçüncü işlem, dizini kullanarak, bir alt-komutlar listesi aracılığıyla
transfer edilecek dosyayı tanımlar. FTP çok geniş bir alt-komutlar
repertuarını destekler. En yaygınları GET ve PUT’tur. Bunlar bir dosyanın
uzak host’tan bir yerel dosya sistemine, veya yerel dosya sisteminden uzak
host’a kopyalanmasına olanak sağlarlar. 11.3.3.4 Mod transfer tanımı FTP dosya transfer prosesinin sıradaki adımı, transfer boyunca
kullanılacak mod tipinin tanımlanmasını içerir. Basitçe, bu adım verinin
nasıl gösterileceğinin ve bitlerin nasıl transfer edileceğinin tanımlanmasını
sağlar. FTP bu işlemleri destekleyecek belirli alt-komutlar içerir: Blok: Bu parametre mantıksal kaydı dosya içerisinde saklar. Bu parametre
ile, iletici modüldeki girişin eş formatında dosya transfer edilir. Nehir: Bu mod, transfer için default bir moddur. Hiç bir blok kontrol
bilgisi gönderilmemesini sağlamakta oldukça etkilidir. Nehir modu ne tip bir
verinin iletildiği ile ilgilenmez, yani kod ve blok transparandır. TYPE: Bu mod IMAGE, ASCII veya EBCDIC parametreleri ile birlikte
kullanılır. ASCII: Bu mod TYPE için default transfer modudur. EBCDIC: EBCDIC, EBCDIC karakterlerini kullanan host’lar (IBM tipi cihazlar
gibi) arasında sıklıkla kullanılır. IMAGE: Bu mod 8-bit baytlık ikilik bit paketlerinin peş peşe transferini
destekler. Bu, düz ikilik verinin transferinde en çok kullanılan yöntemdir. Bu adım, FTP komutlarının birçoğu ile başlatılabilir. Örneğin, retrieve
komutu kullanılarak işlemler başlatılabilir veya append komutu kullanılarak
var olan bir dosyaya kayıtlar eklenebilir. 11.3.3.6 Veri transferinin durdurulması Veri transferinin durdurulması oldukça basittir. Durdurma FTP QUIT
alt-komutunun kullanılması ile başarılabilir. Bu alt-komut FTP işlemlerini
yürüten host’un bağlantısını keser. Bazen bağlantı kesimine sebep vermeyen,
CLOSE alt-komutu kullanılır. Eğer CLOSE kullanırsanız, FTP aktif kalır
ve başka bir kullanıcı OPEN alt-komutu ile yeni bir oturum başlatabilir. 11.3.4 FTP işlemlerine örnekler Bu bölümde, işlemlerin özetlenmesi ve şimdiye kadar sunulan FTP bilgi
parçacıklarının toparlanması amacıyla örnekler sunulmuştur. FTP konum-sürümlü olması açısından, diğer belirli internet protokollerine
benzerdir. Bu nedenle, belirli konum diyagramlarını göstererek, konuyu
örneklerle açıklamak faydalı olacaktır. Tüm örneklerde aşağıdaki
tanımlamaları kullanacağız: B: işlemler başlar. W: protokol cihazı bir cevap bekliyor. E: işlem bir hata yarattı. S: İşlem başarılıdır. F: İşlem başarısızdır. Şekillerde her bir işlemi, fonksiyon kutularından çıkan cevap kodları ile
gösterdik. Cevap kodları 1yz, 2yz, 3yz, 4yz, ve 5yz gibi
kodlanmışlardır (Bunları daha önce tartışmıştık). Hatırlayalım ki, yz
değerleri cevaplarla ilgili daha özel bilgi verirler. Bu şekillerin genel notasyonu Şekil 11-6’dan görülebilir. Şekilde CMD
etiketli bir kod gösterilmiştir. Bu komut işlemi başlatarak bir bekleme
konumu (wait state) yaratır. Buna karşılık verecek cevap kodları işlemin
başarısını veya hatasını belirtir. Bunu aklımızda tutarak, FTP’nin belirli
işlemlerinin bir tartışmasını yapalım. Tekrar Şekil 11-6’ya bakalım. Bu şekilde, FTP işlemlerinin birçoğu için
model olan bir konum diyagramı (state diagram) gösterilmiştir. Şekil
11-6’daki model şu komutları desteklemektedir: ABOR, DELE, CWD, CDUP, SMNT,
HELP, MODE, NOOP, PASV, QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, ve
TYPE (Bu komutların kısa açıklamaları için Tablo 11-3’e bakabilirsiniz.).
Şekilde ‘CMD’ komutu yerine bu komutlardan birini yerleştirebilir ve akış
şemasının kalanını takip ederek olası çıkışlara karar verebilirsiniz.
Şekil 11-6
Elemanter İşlemlerde kullanılan FTP Konum Diyagramı Şekil 11-7, cevap kodu 1’in protokol cihazını tekrar bir bekleme konumuna
getirmesi dışında, önceki şekildekine benzer bir diyagramdır. Bu diyagram şu
komutları destekler: APPE, LIST, NLST, REIN, RETR, STOR ve STOU.
Şekil 11-7 Diğer
Opsiyonlar için FTP Konum Diyagramı Şekil 11-8’de login prosedürü için konum geçiş işlemleri gösterilmiştir.
Şekilde gösterildiği gibi, işlem bir kullanıcı (USER) mesajının yayınlanması
ile başlar. Bunu takiben, password (PASS) ve accounting (ACCT) mesajları
yayınlanarak login işlemlerinin başarılı, başarısız veya hatalı yapıldığına
karar verilir. 11.3.5 Bir dosya gönderme örneği Şekil 11-8’de bir doya gönderme örneği verilmiştir. Şeklin üst tarafında
bir retrive (RETR) komutuna verilebilecek cevaplar gösterilmiştir. Şeklin alt
tarafında cevapların sırası gösterilmiştir: Öncelikli cevaplar ilkin, takip
eden cevaplar sonra, pozitif ve negatif tamamlama cevapları en son olarak
gösterilmiştir. Analizi yapabilmek için Tablo 11-6’daki, RETR’ın cevap
kodlarının numaralarını şekil 11-8’deki numaralar ile eşleştirin.
Hatırlayalım ki, FTP standardında başka pek çok cevap kodu tanımlanmıştır. Şekil 11-8 Gönderme
İşlemlerine Örnek Tablo 11-6 Şekil
11-8 ile İlgili Kodlar
11.3.6 FTP’nin minimum kurulumu Tüm FTP kurulumları en azından kutu 11-7’de gösterilen servisleri ve
komutları desteklemelidirler. Tablo 11-7 FTP’nin
minimum kurulumu
11.4 Simple Mail Transfer Protocol (Basit Posta Transfer Protokolü) SMTP, Internet Protokol yığınında bulunan üst-katman protokollerinin en
yaygın kullanıma sahip olan standartlarından biridir. Adının da çağrıştırdığı
gibi, iki kullanıcı arasında nasıl mesaj (mail) iletileceğini tanımlar SMTP makaralama (spooling) kavramını kullanır. Makaralama fikri, mail’in
yerel bir uygulamadan SMTP uygulamasına gönderilebilmesini sağlar. Burada
SMTP uygulaması mail’i bir cihaza veya hafızaya kaydeder. Tipik olarak, mail
makaraya varınca, sorgulanır. Bir sunucu, mesaj var mı diye kontrol eder ve
eğer varsa bunları postalamaya kalkışır. Eğer mail’in postalanacağı kullanıcı
bulunamıyorsa, sunucu daha sonra tekrar deneyebilir. Neticede, eğer mail
gönderilemezse, yok edilir veya göndericiye geri yollanır. Bu kavram
uçtan-uca postalama sistemi olarak bilinir çünkü sunucu mail’i göndereceği
varışla kontak kurmaya kalkışır, ve mail’i postalamadan önce belli bir süre
hafızada tutar. SMTP iki RFC’de bulunur. RFC 822 mesajın yapısını anlatır (bu anlatım
tabii ki zarfı da içerir). RFC 821 iki makine arasında yapılacak mail
alışverişini kontrol eden protokolü belirtir. 11.4.1 SMTP modeli Şekil 11-9’da SMTP’nin genel bir modelini gösterilmiştir. İşlemler
gönderici-SMTP’nin alıcı-SMTP ile haberleşme kurması ile başlar. Mail’in
iletilmesinden önce, iki SMTP varlığı password’larını veya diğer yetki
işaretlerini birbirlerine ulaştırmalıdırlar. Bundan sonra, gönderici,
kimliğini ve mail alışverişi için gerekli diğer bilgileri içeren ve, MAIL
denilen özel bir komut iletir. Alıcı bundan sonra MAIL komutuna bir acknowledgment
geri döndürmelidir. SMTP’de, bu acknowledgment 250, veya bazı dokümanlarda
250 OK olarak yazılır. Formata bakılmaksızın, acknowledgment istenilen mail
aksiyonunun tamamlandığı anlamındadır. Şekil 11-9 SMTP
Modeli Prosedürün sıradaki adımı bir RCPT komutunun iletilmesidir. Amacı mesajın
hedeflerini belirtmektir. Burada da, her potansiyel alıcıdan bir
acknowledgment beklenmektedir. Prosesin üçüncü adımı DATA komutu yayınlamaktır. Bu komut gönderici
tarafından yayınlanarak, alıcıya/alıcılara mesajın gelmeye hazır olduğu
uyarısının yapılması sağlanır. Veri bundan sonra; gönderici, mesajın sonunu
belirten özel bir kontrol karakterleri katarı gönderene kadar, hattan hata
iletilir. Özel katar gelince, sunucu bir QUIT komutu ile prosesi bitirmeyi
tercih edebilir. 11.4.2 Adres alanı formatı Gönderici-SMTP kendi gönderici adres ve alıcı adres alanı için standart
bir format kullanır. Bu format aşağıdaki gibidir. local-part@domain-name Bir SMTP ismi böylece domain name system (DNS) kavramını takip eder, ve
bazı sistemler aynı sunucu özelliğini kullanarak bu isimden bir IP adresi
türetirler. Uygulamada, bu format şeması şöyle görünmelidir: Jones@beta.aus.edu Burada yerel kişinin ismi Jones’tur. beta.aus.edu ise kişinin domain
tanımlayıcısıdır. local-part@domain-name aşağıdakileri belirtmek üzere başka
formlarda olabilir: · bir doğrudan bağlantı: kullanıcı@host 11.4.3 SMTP işlemlerine örnekler Şekil 11-10’da iki SMPT kullanıcısının basit bir mail alışverişi işlemi
gösterilmiştir. Şeklin sol tarafında göndericinin bağlantı kurması
gösterilmiştir. Alıcı 220 OK ile cevap verir. HELLO komutu iki makine
arasında bir tanımlayıcı alışverişi olarak kullanılmıştır. MAIL FROM komutu
Smith@beta.com’a yeni bir mail geçişinin başlıyor olduğunu söyler.
Alıcı bu komutu tamponlarını temizlemek, konum tablolarını reset’lemek,
ve mesaja hazırlanmak için kullanır. Bundan sonra, RCPT komutu alıcının ileri
yol adresini verir. Örneğimizde, bu Smith@beta.com’dur, ki 250 OK ile cevap
vermiştir. DATA komutu alıcıya, kendisini mesaj içeriğinin takip edeceğini
bildirir. Cevap 354’tür. 354, mail girişini başlat ve bunu CRLF CRLF ile
sonlandır anlamındadır. Şekil 11-10 SMTP
Mail Transferi Veri iletilir, ve iletimin sonu CRLF CRLF ile işaretlenir. Alıcı 250 OK
ile cevaplar, ve bağlantı QUIT ve 221 cevabı ile kesilir. Bu da sunucunun
bağlantıyı kapattığı anlamına gelir. Şekil 11-11 Diğer
SMTP Özellikleri Şekil 11-11’de başka tiplerdeki SMTP mail alışveriş örnekleri
gösterilmiştir. Şeklin üst kısmında verification komutunun (VRFY) kullanımı
gösterilmiştir. Amacı alıcının ismini doğrulamaktır. Bu örnekte Jsmith, tam
ismini ve tam tanımlı mailbox’ını cevap olarak geri göndermelidir. Şekil 11-11’deki
ikinci işlem; SMTP’nin, mail listesindeki bir kimliği doğrulamakta nasıl
kullanılabileceğini göstermektedir. Cevaplayıcılar tam isimlerini ve tam
tanımlı mailbox’larını geri döndürmelidirler. Bu şekiller SMTP’nin birçok özelliğinden yalnızca birkaç örnek
sunmaktadırlar. Daha önce söylediğimiz gibi, daha detaylı bilgi için ilgili
RFC’lere başvurabilirsiniz. 11.4.4 SMTP ve Domain Name System Eğer bir uygulamada SMTP ve DNS çalışıyorsa, isim sunucusu mail alışverişi
(MX) rezerv kayıtlarını (RRs) tutmalıdır. RFC 974’de belirtildiği
üzere; bir gönderici SMTP, alıcı host’un SMTP’yi destekleyen bir well-known
(WKS) girişi var mı diye karar vermek için, host’u sorgulamalıdır. Bir SMTP mailbox’ını destekleyen RR’lere aşağıdaki örnek verilebilir: RD.ACME.COM. IN MX 1
0 RD.ACME.COM. Bu örnekte, RD.ACME.COM. için olan mail host’a postalanır. Eğer
RD.ACME.COM.’a ulaşılamıyorsa, mail MKT.ACME.COM.’a postalanır. 11.5 Internet Servislerine Ulaşmak SMTP’ye ek olarak, Internet başka mesaj yollama sistemlerini de destekler.
Post office protocol (POP) bir mail-box’a uzaktan ulaşım sağlar. POP, bir POP
acentası trafiğin postalanmasını isteyene kadar mesajları saklı tutar. İki
POP acentası (bir kullanıcı acentası ve mesaj-transfer acentası)
birbirlerinden uzak olarak yerleştirilebilirler. POP portu 109’dur. POP
servisleri, belirli Internet servis sağlayıcılarından, çevirmeli veya kiralık
hat bağlantıları ile sağlanabilir. Network news transfer protocol (NNTP) başka bir sakla-ve-ilerlet tipi
mesaj yollama servisidir. NNTP basın grupları tanımlar ve basın grupları
arasında haber makalelerini transfer eder. NNTP portu 119’dur. Tablo 11-8 Kaynak
Arama Servisleri
|
