Bölüm 19: Hizmet ve Protokol
Ağlar'a “Sen”i Katmak kitabının bir bölümü: adres çubuğuna yazdığın tek bir isteğin peşinden bakırla fiberin fiziğine inip karşı taraftan geri dönen uzun bir teknik yolculuk.
Kısım 4: Makineden Yerel Ağa (Bölüm 18-29)
Tüm bölümler
- Giriş
- Adres Çubuğundan İsteğe
- Paket Anahtarlamalı Yol
- İsimden Adrese
- DNS Kayıtları
- Önbellek, Tazelik ve Güven
- Port Numarası ve Soket
- Bağlantısız Taşıma: UDP
- Üç Adımlı El Sıkışma
- Simetrik Şifreleme
- Açık Anahtarlı Kriptografi
- TLS El Sıkışması
- Sertifika Zinciri
- HTTP Mesajının Anatomisi
- Durum, Çerez ve Oturum
- HTTP/2'den HTTP/3'e
- İçerik Dağıtım Ağları
- Diğer Uygulama Protokolleri
- Katmanlı Mimari
- Hizmet ve Protokol
- Encapsulation ve Başlıklar
- Paket Yakalama ve Çözümleme
- Ağ Interface Kartı
- Fiziksel Adresleme
- Hata Sezme ve CRC
- Adres Çözümleme: ARP
- Ortam Erişimi: CSMA/CD
- Switch'ler
- Ağ Topolojileri
- Sanal Yerel Ağlar
- Kablosuz Erişim: 802.11
- Radyo Kanalı ve Kapasite
- Kablosuz Ağ Güvenliği
- Hücresel Ağlar
- Spektrum ve Kuşaklar
- Hareketlilik ve Aktarma
- Adres Kiralama: DHCP
- Adresin Anatomisi
- Adres Tükenmesi ve IPv6
- Router Mimarisi
- Kuyruk Yönetimi
- Cihaz Yapılandırma
- Routing Protokolleri
- Kontrol Düzlemi ve SDN
- Ağ İzleme ve Yönetimi
- Alanlar Arası Routing
- Adres Çevirisi
- Ara Kutular
- Tünelleme ve IPsec
- Firewall'lar
- Ağ Saldırıları
- Operatör ve Metro Ağları
- Bitten Sinyale
- Sembol Hızı ve Kanal Kapasitesi
- Multiplexing Teknikleri
- İletim Ortamları
- Bakır Kablo Sonlandırma
- Fiber Sonlandırma
- Fiber Optik İletim
- Bakır Erişim Ağı: DSL
- DSL'de Hız ve Mesafe
- Pasif Optik Ağlar
- Kablo Erişim Ağları
- Kablo Modem ve CMTS
- Denizaltı Kabloları
- Veri Merkezi Ağları
- Encapsulation Çözme
- Güvenilir Aktarım
- Tıkanıklık Denetimi
- Trafik Çözümleme
- Gecikme Bütçesi
- Soket Programlama
- Eşten Eşe ve Protokol Tasarımı
- Uyarlanır Video Akışı
- Gerçek Zamanlı Ses ve Görüntü
- Kablosuz Sensör Ağlarının Mimarisi
- Sensör Ağlarında Ortam Erişimi
- Sensör Ağlarında Yönlendirme ve IP
- Zaman Eşitleme ve Konum Bulma
- Sensör Ağı Uygulamaları
- Mobil Kablosuz Sensör Ağları
- Son Söz
Katlar sayıldı, kutular yerine oturdu. Geriye aralarındaki anlaşma kalıyor ve o anlaşma iki ayrı yöne uzanıyor: biri aşağıya ve yukarıya, öteki karşıdaki makineye.
Peki bu iki yön neden ayrı adlar taşıyor ve ayrımı bilmek sana ne kazandırıyor?
Komşuya verilen söz nedir?
Bir katmanın üç muhatabı var: altındaki, üstündeki ve karşı makinedeki eşi. İlk ikisiyle dikey, üçüncüsüyle yatay konuşuyor. Dikey ilişkinin adı hizmet, yatay ilişkinin adı protokol.
Sözleşme çift yönlü. Bir kat aynı anda hem üstüne hizmet veriyor hem altından hizmet alıyor. Hizmetin sınırını bir liste çiziyor; katmanın dışarıya açtığı temel işlemler neyse hizmet o kadar. Protokol ise iki eşin, kimin ne zaman ne göndereceğine dair önceden verdiği söz. Bu ikisini ayrı tutmak, kitabın geri kalanında çok işine yarayacak.
Bu ayrımın kolayca kaçırılan bir sonucu var: hizmet ile protokol bağımsız değişkenlerdir. Aynı hizmeti farklı protokollerle verebilirsin: transport layer’ın “güvenilir bayt akışı” hizmetini TCP de verir, QUIC de. İkisinin içi tamamen başka, dışarıya verdikleri söz aynı. Bu yüzden HTTP’yi TCP’den QUIC’e taşımak, 15. bölümde gördüğün gibi, HTTP’nin anlamlarına hiç dokunmadı.
İki ilişkiyi ve aradaki kutuların kaç kat çıktığını tek figürde görelim:
- İki uçta beşer kat. İstemci de sunucu da yığının tamamını gerçekliyor: application, transport, network, data link ve physical. İstek en üstte doğuyor, en altta tele iniyor; karşı tarafta aynı merdiven ters yönde çıkılıyor.
- Aradaki kutular yalnızca gerektiği kadar çıkıyor. Switch frame'i okuyup iletmek için data link layer'a kadar çıkıyor, daha yukarısını hiç görmüyor. Router hedef IP adresine bakmak zorunda olduğu için bir kat daha, network layer'a çıkıyor. Kimse taşıma ve uygulama başlıklarını açmıyor.
- Yatay ilişki protokol. Aynı kattaki iki eş birbirine kendi diliyle sesleniyor: HTTP uygulamadan uygulamaya, TCP taşımadan taşımaya. IP ile Ethernet ise atlama atlama konuşuyor, çünkü o katların eşi yolun üstündeki kutularda da var.
- Dikey ilişki hizmet. Bitler yalnızca telden geçiyor; kesik çizgilerin hiçbiri gerçek bir yol değil. Her kat altındakinin hizmetine yaslanıyor, aradaki kutu da paketi okuyabildiği en derin başlığa kadar çıkarıp yeniden aşağı indiriyor.
- Katman numarası kutunun tavanını söylüyor. Switch 2. katman, router 3. katman cihazı; ikisi de altındaki her katı gerçeklemek zorunda. Uygulama ile taşıma başlıkları yol boyunca kimseye görünmüyor, bu yüzden uçtan uca güvenilirlik ancak uçlarda kurulabiliyor.
Hizmetler ikiye ayrılır ve bu ayrım kitabın üçte birini açıklıyor. Bağlantı yönelimli hizmette önce bir kurulum yapılır, sonra veri akar, sonunda bağlantı kapatılır, tıpkı telefon gibi. Bağlantısız hizmette kurulum yoktur; her birim kendi başına, kendi adresiyle yollanır, tıpkı mektup gibi. 8. bölümde üç mesajlık el sıkışmayı kuran TCP birincisi, 7. bölümde hiçbir söz vermeyen UDP ikincisidir. IP de bağlantısızdır; güvenilir bir transport layer’ının bağlantısız bir network layer üstünde durabilmesi, katmanlamanın en güçlü gösterisidir.
Bu kadar soyut bir sözleşmenin çok somut adları var. Uygulama ile taşıma arasındaki interface (arayüz) port numarasıdır; iyi bilinen iki örnek HTTP’nin 80 ve FTP’nin 21 numarasıdır. 6. bölümdeki demultiplexing bu interface’in sözleşmesi üstünde duruyor. Data link ile network layer arasındaki interface ise Ethernet frame’inin 2 baytlık tür alanı. O alan, frame’in içindekinin üstteki hangi protokole teslim edileceğini söylüyor; data link layer’ın demultiplexing’i tek bir alana sığmış durumda. Aynı işi LLC katmanında Service Access Point yapıyor.
Taşınan şeyin adının katman katman değiştiğini önceki bölümdeki tabloda gördün: segment, datagram, frame, bit. Bu birimlerin ortak adına Protocol Data Unit deniyor; network layer’ın birimine gündelik konuşmada paket de diyoruz. Adların değişmesini bir süs olarak görme: her kat bir öncekini yalnızca yük sayıyor. Başlık, o katın kendi hizmetini gerçeklemek için var. Data link layer sararken başlığın yanına bir de kuyruk ekliyor; üstündeki katlarda böyle bir şey görmeyeceksin, onlar yalnızca başlık koyuyor.
Bu cümleyi tek bir denklemde toplayabilirsin. Üstten inen veriye o katın gözünden hizmet veri birimi (SDU) denir; kat kendi denetim bilgisini, yani protokol denetim bilgisini (PCI) ekler ve ortaya kendi protokol veri birimi (PDU) çıkar:
(N)-PDU = (N)-PCI + (N)-SDU ve (N)-PDU = (N−1)-SDUİkinci eşitlik encapsulation’ın tanımını veriyor: bir katın ürettiği paket, bir alttaki katın gözünde ham veriden başka bir şey değil. Taşımanın ürettiği segment network layer’ın SDU’su, network layer’ın ürettiği datagram data link layer’ın SDU’sudur. Zarfın içinde zarf budur ve bir sonraki bölümde aynı işi bayt bayt sayacağız.
Bir yer daha var ve orada tek bir kat kendi içinde ikiye bölünmüş durumda. Data link layer IEEE 802 ailesinde iki alt katmandan oluşuyor. Alttaki MAC alt katmanı hattı kimin ne zaman kullanacağına karar veriyor ve fiziksel adresi taşıyor; Ethernet’in ve Wi-Fi’ın farklı olduğu yer burasıdır. Üstteki LLC alt katmanı (IEEE 802.2) ise üst katmana tek tip bir yüz gösteriyor. Bölünmenin sebebini ekonomide bulacaksın: network layer, altında bakır mı radyo mu olduğunu umursamak zorunda kalmıyor. Ağ kartı denetleyicisinin çipte gerçeklediği şey de MAC alt katmanıdır.
DerinleşmeBir hizmet çağrısı resmî olarak nasıl yazılır?
OSI hizmeti ne bir fonksiyon imzası ne bir API olarak tanımlar. Onun yerine dört soyut hizmet ilkeli kullanır ve bir hizmet çağrısını bu dördün dizilişiyle yazar.
| ilkel | kim çağırır | ne demek |
|---|---|---|
request | üstteki kat, gönderen uçta | “şu hizmeti başlat” |
indication | katman, alan uçtaki üstüne | “karşıdan böyle bir istek geldi” |
response | üstteki kat, alan uçta | “kabul ediyorum / şu cevabı ver” |
confirm | katman, gönderen uçtaki üstüne | “işlem sonuçlandı, sonucu bu” |
Bir bağlantı kurulumu bu dizilişle yazılır: CONNECT.request → (ağ) → CONNECT.indication → CONNECT.response → (ağ) → CONNECT.confirm. Dört ilkelin tamamı kullanılıyorsa hizmet onaylı, yalnızca ilk ikisi kullanılıyorsa onaysızdır. Veri gönderimi çoğu zaman onaysızdır: DATA.request gider, karşıda DATA.indication doğar, geriye bir şey dönmez.
Bu gösterimin bugünkü değeri iki tane. Birincisi, bir protokol belgesini okurken hizmetin tarifi ile mesajların tarifini birbirinden ayırmayı öğretiyor: ilki katmanın ne söz verdiği, ikincisi telde ne geçtiği. İkincisi, sözlüğün kendisi hâlâ dolaşımda: hücresel ağların 3GPP belgeleri bu dört ilkeli aynen kullanır; çekirdek ağın interface tanımları böyle yazılmıştır.
Somut bir karşılığını kendi makinende de görebilirsin. Bir sunucu soketinde listen() çağrısı katmanı hazır duruma sokar, karşıdan gelen SYN accept()’in dönmesiyle bir indication gibi yüzeye çıkar, accept()’in kendisi bir response gibi davranır ve istemci tarafındaki connect() çağrısının dönmesi bir confirmdir. Soket interface’i OSI’nin sözlüğünü kullanmıyor ama aynı dört anı üretiyor.
Ayrımın en somut sonucunu taşımada göreceksin. Taşımanın uygulamaya verdiği şeye mantıksal iletişim deniyor: iki makine doğrudan birbirine bağlıymış gibi görünüyor. Oysa arada router’lar var ve paket anahtarlama her atlamada yeniden işliyor. Aynı datagram yol boyunca farklı bağ protokolleriyle taşınıyor. İlk atlamada onu Wi-Fi taşıyabiliyor, sonrakinde Ethernet; ikisi farklı hizmet veriyor ama datagram aradaki farkı hiç fark etmiyor.
Sınır bazen elle tutulur. Data link layer çipte ya da ağ interface kartında gerçekleniyor, üstündeki katlar ise yazılım. Bakırdan radyoya geçtiğinde altındaki her şey değişiyor, MAC alt katmanı ise yerinde kalıyor.
Ortada neden tek bir protokol var?
Yığına yandan bakınca ortada bir daralma görüyorsun. Network layer’ında tek bir protokol var: IP. Üstünde TCP, UDP, HTTP, SMTP ve QUIC yan yana yaşıyor. Altında Ethernet, Wi-Fi, Bluetooth ve PPP var, en altta da bakır, radyo ve fiber. Darlık yalnızca ortada; şekle bu yüzden kum saati deniyor.
Belin dar olmasının bedeli ağır. IP, İnternet’e bağlı milyarlarca cihazın her birinde gerçeklenmek zorunda. Karşılığında alınan şey de o kadar büyük: yeni bir bağ teknolojisi çıktığında yalnızca IP’yi taşıması yetiyor, üstündeki hiçbir protokolün haberi olmuyor.
Bunu yazıya döken belge RFC 1958 ve mimarinin üç köşe taşını sayıyor: basit bağlanabilirlik, dar bel olarak IP ve zekânın ağın kenarında durması. Aynı belge bir itirafı da taşıyor: mimari ilk 25 yıl boyunca hiç yazıya dökülmemişti.
Bel o günden beri kalınlaştı. Ağın içinde çalışan ara kutular araya girdi: adres çeviriciler, firewall’lar, önbellekler. İstek satırını okuyan bir ara kutu, tanımı gereği katman sınırını çiğniyor.
Katmanlamanın faturası
Buraya kadar hep kazancı saydım. Bedelini de saymak gerekiyor, çünkü üç kalemi var ve üçü de ölçülebilir.
Birinci kalem başlık. Her kat kendi başlığını ekliyor ve bu başlıklar veriye değil, katmanın kendi hizmetine ait. Tek bir HTTP yanıtının tam dolu bir frame’ini say: 14 bayt Ethernet başlığı, 20 bayt IP, 20 bayt TCP, 4 bayt frame sağlaması, telde ayrıca 8 bayt önsöz ve 12 bayt frame arası boşluk. Toplam 78 bayt gider, 1.460 bayt veri taşınır. Telde harcanan 1.538 baytın %94,9’u işe yarıyor.
Şimdi aynı yığından tek bir tuş vuruşu geçir: şifresiz bir uzak oturumda, Telnet’te bastığın bir harf. Veri 1 bayt. IP datagramı 41 bayta çıkıyor, frame 59 bayt ediyor ve Ethernet’in 64 baytlık asgari frame şartı yüzünden dolgu ile 64’e tamamlanıyor; telde 84 bayt. Bu kez işe yarayan oran %1,2.
Aynı yığın, aynı katmanlar, arada seksen kat fark. Katmanlamanın faturası sabit değil; paket küçüldükçe büyüyor. Protokollerin başlık sıkıştırmaya niçin bu kadar emek verdiğini bu iki sayı açıklıyor.
İkinci kalem tekrar. Aynı işin birden çok katta yapılması. Hata denetimini say: data link layer frame’in tamamı için 4 baytlık bir CRC hesaplıyor, IPv4 kendi başlığı için ayrı bir sağlama tutuyor, TCP başlık ve veri için üçüncü bir sağlama üretiyor. Üç ayrı hesap, büyük ölçüde aynı baytların üstünde.
Gereksiz mi? Hayır; sebebi de güzel. Uçtan uca bakınca yalnızca TCP’ninki zorunlu: veri ancak alıcı süreçte doğrulanırsa doğrulanmış sayılır, çünkü arada bozulma yalnızca telde değil bir router’ın belleğinde de olabilir. Alttaki ikisi zorunlu değil, erken. Bozuk bir frame’i ilk atlamada atmak, onu kıtanın öbür ucuna taşıyıp orada attırmaktan ucuz. Buna rağmen IPv6 başlık sağlamasını tamamen kaldırdı, çünkü alttaki CRC yaygınlaştı ve o kalem artık kârını çıkarmıyordu. Bir katmanın işini gerçekten gereksiz kılan şey, ölçünün değişmesi oluyor.
Üçüncü kalem bilgi saklama ve en pahalısı bu. Bir katman altındakini bilmemeye söz verdiği için bazen yanlış karar veriyor. Klasik örneği TCP ile kablosuz: TCP paket kaybını tıkanıklık işareti sayar ve hızını keser. Oysa Wi-Fi’da bir frame girişimden bozulmuş olabilir, yani ortada tıkanıklık yoktur. Data link layer iki durumu ayırt edebilir ama TCP’ye söyleyecek bir kanalı yoktur; sözleşmede öyle bir alan yok. TCP hattı dolu sanıp yavaşlar ve boş hat boş kalır.
Bu üçüncü kalem, gerçek sistemlerin katman sınırını neden sürekli deldiğini de açıklıyor. Ağ kartının segmentleri işletim sistemi yerine kendisinin bölmesi, router’ın trafiği transport layer portlarına bakarak yollara dağıtması, tıkanıklığın kayıp yerine bir bit ile bildirilmesi: üçü de bilerek yapılmış birer katman ihlali. Katmanlamayı bir yasa olarak değil, bir varsayılan olarak düşün; mühendislik de çoğu zaman o varsayılanın nerede bırakılacağına karar vermek anlamına geliyor.
Sınır kendi makinende nerede duruyor?
Katman sınırını kavramsal bir şey sanma; kendi makinende üç satırda görebilirsin.
$ ip -o link show wlp3s0
2: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ... link/ether 00:00:5e:00:53:af
$ ip -o -4 addr show wlp3s0
2: wlp3s0 inet 192.0.2.37/24 brd 192.0.2.255 scope global wlp3s0
$ ss -tn state established
Recv-Q Send-Q Local Address:Port Peer Address:Port
0 0 192.0.2.37:41320 203.0.113.9:443Aynı kartın üç ayrı adını görüyorsun. MAC adresi 48 bit tutuyor ve bu ağın dışında hiçbir yerde anlam taşımıyor. IP adresi 32 bit ve İnternet’in tamamında anlamlı. Port numarası 16 bit ve yalnızca senin makinende geçerli. İlk satırdaki mtu alanı da bir sözleşme: data link layer üstündekine 1.500 bayttan fazlasını bir seferde taşımayacağını söylüyor. Üstteki katman buna uymak zorunda. IP’yi tanımlayan RFC 791’de başlık 20 bayt tutuyor ve o yirmi bayt bu 1.500 baytın içinden çıkıyor.
Özet
- Dikey ilişkinin adı hizmet, yatay ilişkinin adı protokoldür. İkisi bağımsız değişkendir: aynı hizmeti TCP de QUIC de verir. Sözleşmenin somut karşılıkları port numarası ve Ethernet’in tür alanıdır.
- Hizmet ya bağlantı yönelimlidir ya bağlantısız: TCP önce kurulum yapar, UDP ile IP her birimi kendi adresiyle yollar; güvenilir bir taşıma bağlantısız bir ağın üstünde durabilir.
- Encapsulation tek satırlık bir denklemdir:
(N)-PDU = (N)-PCI + (N)-SDUve bir katın ürettiği paket, bir alttakinin gözünde ham veridir.- Data link layer iki alt kattan oluşur: MAC hattı kimin ne zaman kullanacağına karar verir, LLC üst kata tek tip bir yüz gösterir.
- Katmanlamanın üç kalemlik bir faturası var: başlık yükü paket küçüldükçe %5’ten %99’a tırmanır, aynı iş birden çok katta tekrar edilir ve bilgi saklama bazen yanlış karara yol açar.
- Kum saatinin beli tek bir protokolden ibarettir. IP’nin her cihazda bulunma zorunluluğu, üstündeki ve altındaki çeşitliliğin bedelidir.
Katmanları saydık, sınırlarını çizdik ve aralarındaki sözleşmenin adını koyduk. Geriye o sözleşmenin içeriği kalıyor: bir katman diğerine ne veriyor?
20. bölüme devam et: Encapsulation ve Başlıklar