Bölüm 6:Bağlantısız Taşıma: UDP

6 dakikalık okumaGüncelleme: 21 Ağustos 2026

Ağlar'a “Sen”i Katmak yazısının parçası: adres çubuğuna yazdığın tek bir isteğin peşinden bakırla fiberin fiziğine kadar inen uzun bir teknik yolculuk.

Tüm bölümler

Aynı kapıdan geçen her taşıma aynı sözü vermiyor. En kolayı hiçbir vaatte bulunmayan: isim sorgusunun 53 numaralı kapıya “bağlantısız taşımayla” gittiğini söyleyip geçmiştim.

O taşımanın adı UDP ve tanımı 1980 tarihli RFC 768’de duruyor — dört sayfa. Hiçbir şey vaat etmeyen bir taşıma neye yarıyor?

Sekiz bayt, dört alan

Başlığın tamamı bu:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|          kaynak port          |          hedef port           |
+-------------------------------+-------------------------------+
|            uzunluk            |        checksum        |
+-------------------------------+-------------------------------+
|                          yük (payload)                        |

Dört alan, her biri 16 bit, toplam sekiz bayt. Karşılaştırma için: bir sonraki bölümde göreceğimiz bağlantı kuran taşımanın başlığı en az yirmi bayt ve on bir alan taşıyor.

Alanları soldan sağa okuyalım. Kaynak ve hedef port, four-tuple’ın iki ayağı; makine gelen parçayı doğru sokete bunlarla bırakıyor. Kaynak port zorunlu bile değil, cevap beklemiyorsan sıfır bırakabiliyorsun.

Uzunluk alanı başlık dahil parçanın bayt sayısını taşıyor. On altı bit olduğu için üst sınır 65.535 bayt, yükte kalan da 65.527. Pratikte bu sınıra hiç yaklaşılmıyor: yol üstündeki en küçük çerçeveye sığmayan bir parça yolda bölünüyor ve bölünen parçalardan biri kaybolursa tamamı çöpe gidiyor.

Dördüncü alan checksum ve ilginç olan o.

Hesaba giren şey yalnızca yukarıdaki sekiz bayt ile yük değil. Gönderen, hesabı yapmadan önce var olmayan bir başlık uyduruyor: içinde IP kaynak adresi, IP hedef adresi, protokol numarası ve UDP uzunluğu var. Adı sözde başlık ve telde hiç gitmiyor; yalnızca iki uçta da aynı biçimde kurulup hesaba katılıyor.

Neden? Çünkü UDP’nin tek başına cevaplayamadığı bir soru var: bu datagram gerçekten bana mı geldi? Bir yönlendiricinin belleğinde hedef adres bozulursa paket yanlış makineye düşer; o makinenin UDP katmanı, kendi adresini sözde başlığa koyup hesapladığında sağlama tutmaz ve paketi atar. Adresi taşımayan bir sağlama bu hatayı hiç göremezdi.

Bunun bir bedeli var ve adını koymak gerekiyor: taşıma katmanı, altındaki katmanın alanlarını okuyor. Katman sınırının kasten delindiği yerlerden biri burası. Ve delinmesinin somut bir bedeli daha var: adres çevirisi, IP başlığındaki adresi değiştirdiği için taşıma katmanının sağlamasını da yeniden hesaplamak zorunda kalıyor.

Checksum ne yakalar, ne kaçırır?

Hesap sandığından basit. Gönderen taraf parçanın içeriğini 16 bitlik sayılar dizisi sayıyor, hepsini topluyor, en anlamlı bitten taşan eldeyi sonuca geri ekliyor ve çıkan sayının tersini alana yazıyor. Adreslerin de hesaba katılması, parçanın yanlış makineye teslim edildiğini yakalamayı sağlıyor.

Adreslerin hesaba girmesi bir katman ihlali. Taşıma katmanı, kendi altındaki katmanın alanlarını okuyor; bunun için geçici olarak kurulan yapıya sözde başlık deniyor ve telde hiç gönderilmiyor, yalnızca iki tarafta hesaplanıyor.

Alıcı aynı hesabı tekrarlıyor. Sonuç tutmuyorsa parça bozulmuş demektir ve sessizce atılıyor — kimse haber vermiyor.

Şimdi bu korumanın sınırı. İki ayrı 16 bitlik sayıda birbirini götüren iki bit dönerse toplam değişmiyor:

1110 0110 0110 0110      ->   1110 0110 0110 0111   (son bit 0 -> 1)
1101 0101 0101 0101      ->   1101 0101 0101 0100   (son bit 1 -> 0)
-----------------------       -----------------------
toplam aynı                   toplam aynı

Bitler değişti, toplam değişmedi, alıcı hiçbir şey fark etmedi. Bu yüzden checksum’a hata saptama deniyor, hata düzeltme değil — üstelik saptaması da eksiksiz değil.

Bir tuhaflık daha: alan isteğe bağlı. Sıfır yazılırsa “ben hiç hesaplamadım” anlamına geliyor ve alıcı denetlemiyor. Bu esneklik protokolün ilk tasarımından kalma; bugünün adres ailesinde ise checksum zorunlu.

DerinleşmeBu kadar zayıf bir koruma neden hâlâ kullanılıyor?

Checksum’ın zayıflığı 1980’de de biliniyordu. Yerine daha güçlü bir yöntem koymamanın üç sebebi var ve üçü de hâlâ geçerli.

Birincisi maliyet. Birler tümleyeni toplaması, dönemin donanımında birkaç talimatla yapılabilen en ucuz işlemdi ve bugün de öyle: toplama, ekleme, tersini alma. Daha güçlü yöntemler bit düzeyinde bölme ya da çarpma istiyor. Her paket için, saniyede milyonlarca kez.

İkincisi katmanlı savunma sağlıyor, çünkü bu yolun tek denetimi olmuyor. Kablo düzeyinde her çerçevenin kendi ve çok daha güçlü bir denetimi var; bozulmuş bir çerçevenin taşıma katmanına kadar gelmesi zaten beklenmiyor. Taşımadaki hesap, o denetimin kapsamadığı yeri kolluyor: yönlendiricinin belleğinde ya da kartın tamponunda dönen bir bit, kablo denetiminden sonra oluştuğu için orada yakalanamaz.

Üçüncüsü end-to-end argument (uçtan uca savı). Aradaki her cihaza güvenmek yerine, denetimi yolun iki ucuna koymak. Zayıf bir uçtan uca denetim, güçlü ama parça parça denetimlerin yakalayamadığı bir sınıf hatayı yakalıyor.

Peki yetiyor mu? Yetmiyor. Ölçümler, saptanmadan geçen bozulmaların düşünülenden sık olduğunu gösterdi ve bu yüzden veri bütünlüğüne gerçekten ihtiyaç duyan katmanlar kendi denetimlerini kuruyor. Dosya aktarım protokolleri özet alıyor, şifreli taşımalar bütünlük etiketi taşıyor, depolama sistemleri kendi sağlamalarını yazıyor.

Bir denetimin gücü, onu kimin ve nerede yaptığından ayrı düşünülemez. Aynı zayıf hesap, tek başına dayanılırsa yetersiz; katmanlı bir savunmanın parçasıysa yerinde.

Hiçbir söz vermemek neden işe yarıyor?

Bu taşıma teslim sözü vermiyor, sıra sözü vermiyor, yineleme koruması vermiyor. Kaybolan paketi yeniden göndermiyor, sıralamayı düzeltmiyor, hızını ağa göre kısmıyor. Standart bunu gizlemiyor bile; teslimin garanti edilmediği metnin kendisinde yazılı.

Karşılığında iki şey kazanıyorsun.

Birincisi zaman kazandırıyor: bağlantı kurulmadığı için baştan bir gidiş-dönüş ödemiyorsun. İlk paket doğrudan veriyi taşıyor. Bir isim sorgusu tek paket gidip tek paket dönüyor ve milisaniyeler içinde bitiyor. El sıkışan bir taşımada aynı sorgu, daha soru sorulmadan bir tur harcardı.

İkincisi mesaj sınırı. Gönderdiğin her mesaj alıcıya ayrı bir mesaj olarak çıkıyor; iki mesaj birleşmiyor, bir mesaj ikiye bölünmüş gibi okunmuyor. Akış taşıyan bir protokolde nerede bittiğini kendin işaretlemek zorundasın. Burada sınır zaten korunuyor.

Bir ayrıntı da soket tarafında. Bağlantısız bir sokete de “bağlan” diyebiliyorsun; bu gerçek bir bağlantı kurmuyor, yalnızca karşı ucu sabitliyor. Kazancı şu: çekirdek artık o sokete hangi hataların ait olduğunu bilebiliyor ve “böyle bir kapı yok” cevabını sana iletebiliyor. Sabitlemezsen o cevap sessizce düşüyor.

Bu yüzden bu taşımayı seçen uygulamalar birbirine benziyor: isim çözümlemesi, ağ yönetimi, sesli ve görüntülü görüşme, oyunlar. Ortak noktaları, geç gelen verinin hiç gelmemiş sayılması. Kaybolan bir ses paketini yeniden istemek anlamsız; o an çoktan geçti.

Şaşırtıcı olan, en yeni web protokolünün de bunun üstüne kurulmuş olması. HTTP/3 garantileri bırakmıyor, onları taşımadan alıp uygulamanın içine taşıyor: yeniden gönderim de tıkanıklık denetimi de var, ama artık çekirdekte değil uygulamada. Sebebini 14. bölümde açacağız.

El sıkışma olmamasının bir de karanlık tarafı var. Kaynak adresi doğrulayan hiçbir adım olmadığı için gönderen, paketin üstüne başkasının adresini yazabiliyor. Cevap o adrese gidiyor.

Sorun, cevabın sorudan büyük olmasıyla ciddileşiyor. Kısa bir isim sorgusuna çok daha uzun bir cevap dönebiliyor; saldıran taraf küçük paketler gönderip kurbanın üstüne katlanmış bir trafik yığıyor. Buna yükseltme saldırısı deniyor ve bağlantısız taşımanın en bilinen kötüye kullanımı. Savunması da protokolde değil, işletmede: açık resolver’ı herkese kapatmak, cevap hızını sınırlamak, kaynak adresi kendi ağının çıkışında doğrulamak.

Kendi makinende görmek istersen bunlar soyut kalmasın. Wireshark’ta udp.port == 53 süzgeci, ya da komut satırında tcpdump -n udp port 53, bir sayfa açtığın anda giden isim sorgularını dökecek. Her satırda göreceğin şey tek bir paket: soru gitti, cevap geldi, arada başka hiçbir şey yok.

Özet

Peki, ne öğrendik?
Başlık sekiz bayt ve dört alan: kaynak port, hedef port, uzunluk, checksum. Bağlantı kuran taşımanın başlığı bunun en az iki buçuk katı.
Checksum hata saptar, düzeltmez ve saptaması da eksiksiz değil: birbirini götüren iki bit dönmesi toplamı hiç değiştirmiyor.
Hiçbir söz vermemenin karşılığı zaman ve sınır. El sıkışma olmadığı için ilk paket doğrudan veri taşıyor, ve mesaj sınırları alıcıda korunuyor.
Bu taşımayı seçen uygulamaların ortak noktası, geç gelen verinin işe yaramaması.

İsim sorgusu bu yüzden tek pakette bitti. Ama sayfanın kendisi tek pakete sığmıyor ve kaybolan bir parçayı kimsenin fark etmemesi kabul edilebilir değil. Garanti istemeyen taşımayı gördün; peki karşı taraf senin geldiğini nereden bilecek?

7. bölüme devam et: Üç Adımlı El Sıkışma