Bölüm 20: Encapsulation ve Başlıklar

Katmanların birbirine ne sözü verdiğini kurduk. Söylemediğim şey, komşuya neyin uzatıldığıydı.

Uzatılan şey çıplak veri değil. Her katman kendisine geleni bir zarfa koyup uzatıyor ve o zarfın adı başlık. Peki zarfın içinde kaç zarf var?

Dört basamak, tek yük

Application layer elindeki mesajı taşımaya veriyor ve taşıma onu hiç açmıyor. İçindeki baytların ne anlama geldiğine bakmadan başına kendi başlığını ekliyor; ortaya bir segment çıkıyor.

Network layer aynı işi bir basamak aşağıda tekrarlıyor. Aldığı segmentin tamamını, taşımanın az önce yazdığı başlık dahil, tek parça yük sayıyor. Kendi başlığını onun da önüne ekliyor: datagram. Son basamak data link layer; o da datagramı olduğu gibi alıp sarıyor ve ortaya frame (çerçeve) çıkıyor.

application  [ mesaj ]
transport    [ TCP | mesaj ]                       ->  segment
network      [ IP  | TCP | mesaj ]                 ->  datagram
data link    [ ETH | IP  | TCP | mesaj | FCS ]     ->  frame

Kargo şirketine dönersek, her basamak yalnızca kendi etiketini yazar. Bir öncekinin etiketi artık paketin parçasıdır.

Aynı merdiveni baytlarla izlemek istersen:

Son satırdaki FCS dikkatini çekmiş olmalı. Frame hem başlıkla hem kuyrukla sarılıyor; sondan yazan tek katman data link layer.

Her başlık, onu ekleyen katmanın kendi hizmetini kurmak için ihtiyaç duyduğu alanları taşıyor. Üstteki katman o alanları hiç görmüyor. Alttaki katman görüyor ama anlamlarını bilmiyor. Encapsulation dediğimiz şey bu.

Başlıkta ne var?

Seçenek taşımayan bir TCP başlığı 20 bayt. Başlık sabit değil; içinde başlık uzunluğu (data offset) adında bir alan var ve başlığın kendi uzunluğunu bildiriyor, çünkü seçeneklerle uzayabiliyor. Yük kısmı da değişken uzunlukta; uygulamanın sokete yazdığı kadar.

Seçeneksiz IPv4 başlığı da 20 bayt. İkisi birlikte her yükün üstüne 40 baytlık sabit bir zarf bindiriyor.

IPv4 başlığını tahmin etmeye gerek yok; RFC 791 alanları bit bit sayıyor. Başlık 32 bitlik satırlar hâlinde okunur ve seçeneksiz hâli tam beş satırdır:

Birkaç alan ilk okumada kolayca kayıyor, oysa hepsi kitabın başka bölümlerinde karşına çıkacak.

IHL başlığın uzunluğunu bayt değil, 32 bitlik kelime cinsinden verir. Seçeneksiz başlıkta değeri 5’tir: 5 × 4 = 20 bayt. Alan 4 bit olduğu için en büyük değeri 15, yani başlığın tavanı 60 bayt. Seçeneklere ayrılabilecek yer bu yüzden 40 baytla sınırlı; bu bir tasarım tercihi değil, dört bitin matematiği.

DSCP ve ECN aslında tek bir 8 bitlik alandan bölündü. Eski adı Hizmet Türü’ydü; RFC 2474 üstteki altı biti hizmet sınıfına, RFC 3168 alttaki iki biti tıkanıklık bildirimine ayırdı. İlki paket zamanlamada, ikincisi tıkanıklık denetiminde işe yarıyor. İkisi de aynı bayttan çıkıyor.

Bayraklardaki DF biti “bu paketi bölme” demek. Bölmesi gereken bir router DF bitini görürse paketi düşürüp gönderene bir ICMP mesajıyla haber verir ve o mesajın içinde bir sonraki atlamanın MTU’sunu yazar. Gönderen böylece yol boyunca sığacak en büyük boyu adım adım öğrenir; yöntemin adı yol MTU keşfi. O ICMP mesajları bir firewall tarafından susturulursa yöntem sessizce çöker; sahadaki hâlini 48. bölümde tünelleri kurarken adım adım izleyeceğiz.

Başlık sağlaması yalnızca başlığı korur, yükü değil. Sebep basit: TTL her atlamada değiştiği için sağlamanın da her router’da yeniden hesaplanması gerekiyor; yükü de kapsasaydı bu hesap her atlamada bütün paket üstünde yapılacaktı. IPv6 alanı tamamen kaldırarak aynı sorunu kökünden çözdü.

Protokol alanı küçük ama işi büyük: yükün hangi üst katman protokolüne ait olduğunu söylüyor, TCP mi UDP mi.

Frame’in alanları da sırayla belli; boyları toplandığında zarfın maliyeti çıkıyor:

Bu iki adresin nasıl kurulduğunu burada boş bırakıyorum. Alanların genişliğini biliyorsun; içlerindeki değerin ne anlama geldiğini 23. bölümde dolduracağız.

Adresler, tür alanı ve FCS birlikte 18 bayt tutuyor. Önsöz (preamble) hariç azami sade frame bu yüzden 1.518 bayt. Araya 4 baytlık bir 802.1Q etiketi girerse tavan 1.522 bayta çıkıyor; etiketin ilk iki baytı 0x8100 tür tanımlayıcısını taşır ve o tanımlayıcıyı bilmeyen bir istasyon frame’i bilinmeyen tür sanıp atar.

Tür alanı (EtherType) 0x0800 ise içeride IP var, 0x0806 ise ARP. FCS’nin içine yazılan değer ise bir CRC-32 sağlaması; hesabın kendisi 24. bölümün işi.

Her zarf bir sonrakini nasıl gösteriyor?

Encapsulation’ın asıl inceliği zarfları sarmakta değil, açarken hangi sırayla açılacağını bilmekte. Alıcıya gelen şey bir bayt dizisi. Nerede bittiğini, içinde ne olduğunu ve sonraki başlığın hangi protokole ait olduğunu ona kimse söylemiyor; bunların hepsi zarfın kendi içinde yazılı.

Her başlığın içinde, bir sonraki başlığın kim olduğunu söyleyen bir alan var. Bu alanlar bir zincir kuruyor ve zincir, bayt dizisini adım adım çözüyor:

Zincirin bu kadar sıradan görünmesi aldatıcı. Bu üç alan, yığının tamamının değiştirilebilir olmasını sağlayan şey. Ethernet, içinde IP taşıdığını bilmiyor; yalnızca 0x0800 diye bir sayı taşıyor ve o sayının anlamını bir tabloya bırakıyor. IPv6 ortaya çıktığında Ethernet’in tek bir satırı bile değişmedi; tabloya yeni bir sayı eklendi. Katmanları gerçekten ayıran şey, başlıkta bir isim değil bir numara taşımaktır.

Zarfları açmanın adı encapsulation çözme (decapsulation) ve sarmanın tam tersi sırayla yürüyor. Alıcı kartı frame’i alıyor, FCS’yi yeniden hesaplayıp yazandan farklı çıkarsa frame’i sessizce atıyor. Sağlamsa 14 baytlık başlığı çıkarıp kalanı IP’ye uzatıyor. IP kendi başlığını doğruluyor, hedef adres kendisiyse başlığı çıkarıp protokol alanının gösterdiği yere, diyelim TCP’ye, uzatıyor. TCP checksum’ı denetliyor, hedef porta bakıp doğru sokete bırakıyor. Her kat kendi zarfını açıyor, kendi denetimini yapıyor ve bir üstteki katmanın zarfına hiç dokunmuyor.

Encapsulation’ın özeti: her katman, bir üstündekinin verdiği her şeyi anlamsız bir yük sayar; ne olduğunu yalnızca bir sayıyla not eder ve o sayıyı okumayı karşı taraftaki eşine bırakır.

Yük hatta sığmazsa?

Bir bağlantı üzerinden gidebilecek en büyük frame’in veri alanına MTU deniyor. Ethernet’te 1.500 bayt. Bu bir network layer kararı değil, data link layer kararı: değeri ikinci katmanda hangi protokolün çalıştığına göre değişiyor. Yol boyunca tek bir sabit değer yok.

Sayı yükseltilebilir de. Switch’lerin çoğu bugün 9.000 bayt veri taşıyan jumbo frame’leri kabul ediyor; aynı veriyi altı kat daha az frame’le göndermek, frame başına düşen 18 baytlık zarfı altı kat fazla verinin üstüne yaymak demek. Yine de bu yetenek standart dışı ve yerelde kalıyor. Sebebi yolun kendisinde. Bir yol, üstündeki en dar bağlantı kadar geniştir; yol üstündeki tek bir port jumbo frame’i tanımıyorsa onu sessizce düşürüyor. Uçların birlikte büyütmeyi pazarlık edeceği bir mekanizma da yok; MTU her bağlantının kendi kararı. Büyük MTU bu yüzden ancak kapalı alanlarda işe yarıyor: veri merkezinin içi, depolama ağı, iki router arasındaki tek bir hat. Oralarda iki uç da aynı yönetimin elinde.

Geriye kalanı hesaplamak kolay. 1.500 baytlık veri alanından IP başlığının 20 baytını ve TCP başlığının 20 baytını düşünce elde 1.460 bayt kalıyor. SYN paketiyle pazarlığa açılan en büyük segment boyunun tipik değeri de bu.

Peki yük bu sınırı aşarsa? IPv4 datagramı bölüyor; işlemin adı parçalama. Her parça kendi başına tam bir IP datagramı ve kendi başlığını taşıyor.

Somut bir örnek kuralım. 2.048 baytlık bir datagramın yükü 2.028 bayt. MTU’su 1.500 olan bir bağlantıya girdiğinde ikiye ayrılıyor:

parça 1:  veri 1.480 bayt · ofset 0    · MF=1 · toplam uzunluk 1.500
parça 2:  veri   548 bayt · ofset 185  · MF=0 · toplam uzunluk   568

Parçaları birbirine bağlayan üç alan var ve üçü de IP başlığında duruyor. Kimlik, iki parçanın aynı datagramdan doğduğunu söylüyor. Bayrak alanındaki MF biti arkadan başka parça gelip gelmediğini bildiriyor. Ofset ise parçanın özgün veri alanındaki yerini veriyor, o da bayt cinsinden değil, 64 bitin yani 8 baytın katları cinsinden. 1.480’i sekize bölünce 185 çıkıyor. Son parça hariç her parçanın verisi bu yüzden sekizin katı olmak zorunda.

Bir ayrıntı daha: TCP başlığı yalnızca ilk parçada duruyor. IP bölerken yükün içine bakmıyor; ikinci parça onun için sıradan bir bayt dizisi.

Parçaları birleştiren tek yer hedef uç sistem. Bedeli şu: bir parça yol boyunca yalnızca küçülebiliyor. IPv6 bu işi sabit başlıktan çıkardı; 40 baytlık başlıkta ne parçalama var ne checksum, amaç router’da işlemeyi hızlandırmak. Gerekirse parçalama ayrı bir uzatma başlığına iniyor.

Bir terim notu da düşeyim. OSI belgelerinde bu işleme segmentation, TCP/IP belgelerinde fragmentation deniyor. İkisi aynı şeyi anlatıyor.

Zarfın bedeli ne kadar?

Tel üstünde bir yükün taşıdığı toplam zarf 58 bayt: 20 TCP, 20 IP, 18 Ethernet.

1.460 baytlık dolu bir yükle frame 1.518 bayta çıkıyor ve zarfın payı %3,8 oluyor. Şimdi yükü küçült. İstek satırı ve başlıklarla kurulan sade bir HTTP isteği 480 bayt tutsun. Aynı 58 bayt ekleniyor, toplam 538 bayt, zarfın payı %10,8. Zarf hiç değişmedi. Yük küçüldükçe oransal olarak şişti.

Uç vakayı da görelim. Yüksüz bir ACK, 20 baytlık TCP başlığı ile 20 baytlık IP başlığından ibaret: 40 baytlık bir datagram. Ethernet veri alanının alt sınırı 46 bayt olduğu için aradaki fark dolgu ile kapatılıyor ve frame 64 bayta çıkıyor. Telden geçen her şey zarf.

O dolgu baytları network layer’ına kadar çıkıyor. Onları ayıklayan şey IP başlığındaki uzunluk alanı.

Kanalın ödediği fatura frame boyuyla değil toplamla ölçülüyor. 1.500 baytlık veri taşıyan bir frame’in kanal maliyeti, önsöz ve frame’ler arası boşluk dahil, 1.538 bayt. Yükün payı %97,5. 10 Mbit/s’lik bir hatta bu saniyede 812 frame demek. Aynı hatta asgari boy frame’ler saniyede 14.880 adet geçiyor ve yalnızca 5.475.840 bit veri taşıyor: kanalın %54,8’i.

Ek yükün bit karşılığı da sabit: 64 bit önsöz, 96 bit iki adres, 16 bit tür alanı, 32 bit FCS. 10 Mbit/s’te frame’ler arası boşluk 9,6 µs, yani 96 bit süresi. Toplamı 304 bit süresi.

Küçük frame’in bir yararı da var. Bozulan bir frame’de yeniden gönderilecek bit sayısı daha az. Multiplexing ile tek bağlantıya sığdırılan istekler de aynı hesabın içinde; zarf yok olmuyor, yalnızca daha çok yükün üstüne yayılıyor.

Bütün bunları kendi makinende görebilirsin:

ip link show
sudo tcpdump -n -e -c 5 'tcp port 443'

İlk komut her interface’in yanına mtu 1500 yazacak. İkincisi her satırın başında frame’in kaynak ve hedef adresini, ethertype IPv4 (0x0800) etiketini ve frame’in bayt cinsinden boyunu dökecek. Windows tarafında aynı değeri netsh interface ipv4 show subinterfaces komutu veriyor.

Özet

• Encapsulation dört basamaklı bir merdiven: mesaj segmente, segment datagrama, datagram frame’e giriyor ve her basamak bir öncekinin tamamını yük sayıyor.
• Her başlık kendi katmanının işi için var: üstteki alanları görmüyor, alttaki anlamlarını bilmiyor; sondan kuyruk ekleyen tek katman da data link layer.
• IPv4 başlığı beş satır, on üç alandır: IHL başlığın tavanını 60 bayta kilitler, DSCP ile ECN aynı bayttan bölünmüştür, DF biti yol MTU keşfini başlatır ve checksum yalnızca başlığı korur.
• Bağlayıcı alanlar zinciri kuruyor: frame’deki tür alanı, IP’deki Protokol ve taşımadaki port numarası yükü doğru üst katmana yönlendiriyor.
• MTU aşılırsa datagram bölünüyor: Kimlik, Bayrak ve Ofset parçaları birbirine bağlıyor, birleştirmeyi ise yalnızca hedef uç yapıyor.

Zarfları saydık, alanlarını adlandırdık, bedelini hesapladık. Ama buraya kadar hepsi anlatı olarak kaldı. Zarflar gerçekten orada mı, bunu kendi gözünle görebilir misin?