Bölüm 16:Diğer Uygulama Protokolleri

İsteğimiz hâlâ yolda. Ama aynı kabloda o an akan tek şey o değil: komşu dairede bir film oynuyor, bir posta sunucusu kuyruğunu boşaltıyor, biri dosya paylaşıyor.

Şimdiye kadar ağı tek bir isteğin gözünden anlattım. Bu bölümde diğerlerine bakıyoruz; ihtiyaçları bambaşka. Aynı taşımadan ne bekliyorlar?

Bir protokolü protokol yapan nedir?

Uygulama katmanında bir protokolün tanımlaması gereken dört şey var. Birincisi hangi ileti türlerinin değişileceği: istek ve yanıt. İkincisi sözdizimi, yani hangi alanların bulunduğu ve nasıl ayrıldığı. Üçüncüsü o alanların ne anlama geldiği. Dördüncüsü süreçlerin ne zaman gönderip nasıl karşılık vereceği.

Bu dördünün tanımını herkesin okuyabildiği bir belgede bulabiliyorsan elinde bir açık protokol var demektir; o belge de çoğu zaman bir RFC oluyor. Elle yazdığın istek satırının çalışma sebebi buydu: karşı taraf aynı belgeyi okumuştu. Karşısında tescilli protokoller var; görüntülü toplantı uygulamalarının çoğunda telde ne aktığını yalnızca üreticisi bilir.

İkinci ayrımı mimaride yapıyorsun. İstemci-sunucu mimarisinde bir uçta sürekli açık duran, kalıcı adresli bir makine bulunuyor. İstemciler aralıklı bağlanıyor, adresleri değişebiliyor ve birbirleriyle hiç konuşmuyor. HTTP, IMAP ve FTP bu mimarinin örnekleri.

Eşler arası mimaride sürekli açık sunucu yok. Her uç hizmeti başka uçlardan istiyor, karşılığında kendisi de veriyor; dosya paylaşımında BitTorrent böyle çalışıyor. Kazancına kendiliğinden ölçeklenme deniyor: katılan her yeni eş sisteme yeni talep getirirken aynı anda yeni kapasite de getiriyor. Bedelini ise yönetim karmaşası olarak ödüyorsun. Burada hizmeti veren uçlar da aralıklı bağlı ve adresleri değişiyor.

Zarfın üstü mektubun içiyle aynı olmak zorunda mı?

E-postayı üç parçaya ayırabilirsin: kullanıcı ajanı, posta sunucuları ve SMTP. Yazdığın ileti senin makinende durmuyor; giden de gelen de sunucuda saklanıyor. Sunucunun içinde de iki ayrı yapı buluyorsun. Kullanıcı başına bir posta kutusu gelen iletileri tutuyor, bir de giden kuyruğu var.

Kuyruktaki iletiyi taşıyan protokole SMTP deniyor. Gönderen sunucu, alan sunucuya kendisi bağlanıyor ve arada aracı bir depo bulunmuyor. Bağlantı TCP üzerinden 25 numaralı porta açılıyor ve bağlantıyı başlatan taraf istemci rolüne giriyor. O taraf da bir posta sunucusu. Aktarımı üç evrede tamamlıyorlar: selamlaşma, iletilerin aktarımı ve kapanış.

Komutları düz ASCII metin olarak yazıyorsun; yanıtlar da üç haneli bir kod ile kısa bir ifadeden oluşuyor. Belgeleme için ayrılmış adlarla oturum şöyle görünüyor:

220 mail.example.com ESMTP hazir
HELO gonderen.example.net
250 merhaba gonderen.example.net
MAIL FROM: <deniz@example.net>
250 gonderen kabul edildi
RCPT TO: <arda@example.com>
250 alici kabul edildi
DATA
354 govdeyi bekliyorum, sonu tek nokta
From: deniz@example.net
To: arda@example.com
Subject: kablo raporu

Rapor ekte.
.
250 ileti teslim icin alindi
QUIT
221 kapaniyorum

İletinin bittiğini ayrı bir uzunluk alanından değil, tek başına nokta içeren bir satırdan anlıyorsun; yani CRLF.CRLF dizisinden. Bağlantı da kalıcı kalıyor: aynı TCP bağlantısından arka arkaya birçok ileti geçebiliyor.

İki kısıt daha var. SMTP hem başlığın hem gövdenin 7 bitlik ASCII olmasını şart koşuyor. Resim ya da PDF bu boruya olduğu gibi giremiyor, önce ASCII’ye kodlanıyor. Bunu yapan katmanın adı MIME, en bilinen kodlaması base64. Base64 her üç baytı dört karaktere açtığı için gövde yaklaşık %33 şişiyor. İkinci kısıt paketleme: HTTP her nesneyi kendi yanıtında taşırken SMTP birden çok nesneyi tek bir çok parçalı iletide taşıyor. Eklerin aynı iletinin içine girmesinin sebebi bu. Yön de ters: HTTP’de istemci çeker, SMTP’de istemci iter.

Taşıyan protokolle iletinin biçimi ayrı standartlarda duruyor. Aktarımı RFC 5321 tanımlıyor, eski numarası RFC 821’di. İletinin sözdizimi ise RFC 5322’de, eski numaraları RFC 2822 ve RFC 822’ydi. İskelet tanıdık: başlık satırları, boş bir satır, sonra gövde.

Yukarıdaki oturumda iki ayrı adres kümesi geçti. MAIL FROM ile RCPT TO zarfın üstünü yazıyor. From: ve To: satırları ise mektubun içinde duruyor. İkisinin aynı olma zorunluluğu yok ve sahte gönderen sorununun kökü tam olarak burası. SMTP iletinin içeriğiyle ilgilenmiyor; tek işi onu hedef makineye ulaştırmak.

Sahte gönderen nasıl kapatıldı?

Yukarıdaki oturumda hiçbir yerde kimlik kanıtı istenmediğine dikkat et. MAIL FROM satırına istediğini yazabilirsin; SMTP sana inanır. 1982’de bu bir kusur değildi, çünkü ağdaki herkes birbirini tanıyordu. Bugün kusur.

Protokolü değiştirmek mümkün olmadı — dünyadaki her posta sunucusunu aynı gün güncelleyemezsin. Onun yerine üç ayrı katman DNS üzerinden eklendi, ve üçü de TXT kaydını kullanıyor.

SPF en basiti: alan sahibi, “benim adıma yalnızca şu IP adresleri posta gönderebilir” diye bir liste yayımlıyor.

example.net.  TXT  "v=spf1 ip4:198.51.100.0/24 include:_spf.saglayici.com -all"

Alıcı sunucu, bağlanan makinenin adresini bu listeye karşı sınıyor. Sondaki -all “listede yoksa reddet” demek. Kusuru da var: MAIL FROM alanına, yani zarfın üstüne bakıyor — kullanıcının gördüğü From: satırına değil. Üstelik ileti bir posta listesi üzerinden yönlendirilirse gönderen adres değişir ve SPF kırılır.

DKIM başka bir yerden yakalıyor: imza. Gönderen sunucu, seçtiği başlıkları ve gövdeyi özel anahtarıyla imzalayıp iletiye bir DKIM-Signature başlığı ekliyor. Açık anahtar yine DNS’te, secici._domainkey.example.net adresinde duruyor. sayısal imzanın posta zarfındaki hâli bu. Yönlendirmeye dayanıyor, çünkü imza iletiyle birlikte seyahat ediyor. Kusuru: imzayı atan alanın, kullanıcının gördüğü From: alanıyla aynı olması gerekmiyor.

İki mekanizma da aynı boşluğu bırakıyor: kullanıcının gördüğü satır hâlâ korunmuyor.

DMARC o boşluğu kapatıyor ve üçlünün çatı katı. Alan sahibi _dmarc.example.net adresinde bir politika yayımlıyor:

_dmarc.example.net.  TXT  "v=DMARC1; p=reject; rua=mailto:rapor@example.net"

Şartı iki parçalı. Birincisi, SPF ya da DKIM’den en az biri geçmeli. İkincisi ve asıl yenilik: geçen mekanizmanın alanı, From: satırındaki alanla hizalı olmalı. Böylece imzayı saldirgan.com atıp From: satırına bankaniz.com yazmak işe yaramıyor. p= politikası ne yapılacağını söylüyor: none yalnızca raporla, quarantine spam klasörüne at, reject hiç kabul etme.

rua= adresi de az bilinen ama değerli bir parça: uyumlu alıcılar, alan adına kimin posta göndermeye çalıştığını özetleyen günlük raporlar yolluyor. Alan sahibi böylece kendi adının nerede kötüye kullanıldığını görebiliyor.

Üçünün ortak dersi şu: kimliği protokole ekleyemedikleri için adın yanına eklediler. Posta sunucusu değişmedi; değişen şey, o sunucunun DNS’e bir soru daha sorması oldu.

İleti sunucuda; onu kim alıyor?

SMTP çizgiyi burada çekiyor. İletiyi alıcının sunucusuna teslim ediyor ve orada bırakıyor; sunucudan almak ayrı bir erişim protokolünün işi. IMAP iletileri sunucuda tutuyor ve alma, silme, klasör yönetme işini üstleniyor; tanımı RFC 3501’de. IMAP ile POP3’ün numaraları 143 ile 110; ikisi de iyi bilinen port aralığının içinde kalıyor.

Tarayıcıdan girdiğin posta hizmetine webmail deniyor ve yeni bir protokol getirmiyor. HTTP arayüzünü göndermek için SMTP’nin, almak için IMAP ya da POP’un üstüne koyuyor.

Video akışı neden bir indirme sayılmıyor?

2020’de servis sağlayıcıların konut trafiğinin %80’i üç akış hizmetine gidiyordu. Aynı filmi isteyenlerin bağlantıları da birbirine benzemiyor: kimi fiberde, kimi hücresel veride.

Video, sabit hızda gösterilen bir görüntü dizisi. Saniyede 24 görüntü tipik bir gösterim hızı, kayıtta saniyede 30 kare de yaygın. Her görüntü bir piksel dizisi ve her piksel bitlerle temsil ediliyor. Ham hâlde bu sayı devasa. Kodlama onu, görüntü içindeki ve görüntüler arasındaki tekrarı kullanarak düşürüyor. Sabit bit hızında kodlama hızı sabit kalıyor, değişken bit hızında sahnedeki tekrara göre oynuyor. Somut karşılıkları var: MPEG 1 için 1,5 Mbit/s, MPEG2 için 3 ile 6 Mbit/s, MPEG4 için 64 Kbit/s ile 12 Mbit/s arası.

Bir hesap bunu yere indiriyor. 5 Mbit/s sabit hızda iki saatlik film 7.200 saniye × 5 Mbit, yani 36.000 Mbit tutuyor: kabaca 36 Gbit, yaklaşık 4,5 GB. İzlemeye başlamadan önce bunun inmesini beklemek kabul edilebilir bir şey değil.

Akışın tanımı da zaten bu: sen videonun başını izlerken sunucu hâlâ sonrasını gönderiyor. Kısıt sert. Oynatma zamanlaması kaydın özgün zamanlamasıyla aynı olmak zorunda, ağ gecikmesi ise değişken. Bu yüzden istemci tarafında bir tampon şart; ağın eklediği gecikmeyi ve gecikme oynamasını o karşılıyor. Üstüne duraklatma, sarma ve ortaya atlama da isteniyor.

İkinci sorun bant genişliği. Sunucudan sana kalan pay zamanla değişiyor; tıkanıklık evde de, erişim ağında da, çekirdekte de olabiliyor. Kayıp ve gecikme ya oynatmayı geciktiriyor ya da görüntüyü bozuyor.

DASH bu iki sorunu tek tasarımla karşılıyor. Sunucu dosyayı parçalara bölüyor ve her parçayı birden çok hızda kodlayıp ayrı dosyalarda saklıyor. Manifest dosyası bu parçaların adreslerini veriyor; istemcinin elindeki tek harita o. İstemci bant genişliğini düzenli aralıklarla ölçüyor, her seferinde tek bir parça istiyor ve o an sürdürebileceği en yüksek hızı seçiyor. Zekâ sunucuda değil, istemcide. Üç kararı da o veriyor: parçayı ne zaman isteyeceğini, hangi kodlama hızını isteyeceğini ve hangi sunucudan isteyeceğini.

Şimdi parça süresini 4 saniye olarak kabul edelim. İki saatlik film 1.800 parça eder, yani tek bir film için 1.800 ayrı HTTP isteği. Aynı hızda tek parça 20 Mbit, yani 2,5 MB. DASH’in açılımı da bunu söylüyor: HTTP üzerinden dinamik, uyarlanır akış. O parçaların hangi makinede durduğu ise kenar sunucularında çözülmüştü.

Aynı kablodan geçen sesler taşımadan ne istiyor?

Hepsi aynı taşıma katmanının üstünde duruyor ama ondan aynı şeyi istemiyor. İstekler dört eksende ayrışıyor: veri bütünlüğü, zamanlama, throughput ve güvenlik.

Dosya aktarımı ve web işlemleri %100 güvenilirlik istiyor; tek bayt eksik gelen arşiv bozuk arşivdir. Ses ise bir miktar kaybı kaldırıyor. Throughput tarafında da bantlar var: gerçek zamanlı ses 5 Kbit/s ile 1 Mbit/s arasında, akan video 10 Kbit/s ile 5 Mbit/s arasında çalışıyor. Elastik uygulamalar ne bulursa onu kullanıyor. Bu istekler protokol seçimine dönüşüyor:

Telefonun UDP tarafına düşebilmesi tesadüf sayılmaz: 6. bölümde bağlantısız gönderimi anlatırken geç gelen verinin hiç gelmemiş sayıldığını söylemiştim.

Listede bir de tarihsel kalıntı duruyor. Telnet uzaktaki makineye bağlanıp komut vermeyi sağlıyor; ama parolalar dahil her şey açık gidiyor. SSH aynı işi güçlü bir şifrelemeyle yapıyor. Bugün 23 numaralı portun yerini 22 almış durumda.

Bu adların hepsi kendi makinende tek bir dosyada duruyor:

grep -E '^(ftp|ssh|telnet|smtp|domain|http|pop3|imap2)[[:space:]]' /etc/services

Her satırda bir ad, bir numara ve taşıma protokolü göreceksin: smtp 25/tcp gibi. Windows tarafında aynı liste %SystemRoot%\System32\drivers\etc\services yolunda duruyor. Bu bölümde adı geçen protokollerin hemen hepsini o satırlarda bulabilirsin.

Özet

Peki, ne öğrendik?

• Bir protokol dört şeyi tanımlar: ileti türlerini, sözdizimini, alanların anlamını ve gönderme kurallarını. Açık olanın tanımı bir RFC’de durur.
• E-postanın zarfı ile mektubu ayrı yazılır: MAIL FROM ile RCPT TO zarfın üstündedir, From: ile To: mektubun içindedir, ve ikisinin uyuşma zorunluluğu yoktur.
• SMTP teslim eder, erişim protokolü alır: ileti alıcının sunucusunda kalır, oradan çekme işini IMAP ya da POP3 yapar.
• Video akışı yüzlerce küçük istektir: 4 saniyelik parçalarla iki saatlik bir film 1.800 ayrı HTTP isteğine dönüşür ve hızını istemci seçer.

Aynı kablodan geçen sesleri tek tek duydun; kimi güvenilirlik istiyor, kimi zamanında gelmeyi. Ama hepsi o kabloya girerken aynı işlemden geçiyor. İstek makineden çıkacak; peki çıkarken tam olarak neye dönüşüyor?