Bob Kahn ve TCP/IP: Uygulamaları Güçlendiren Görünmez Katman

TCP/IP Neden Modern Yazılımın Gizli Temelidir

Çoğu uygulama “anında” gibi hissedilir: bir düğmeye dokunursunuz, besleme yenilenir, ödeme tamamlanır, video başlar. Ancak görmediğiniz şey, küçük veri parçalarını Wi‑Fi, hücresel ağlar, ev yönlendiricileri ve veri merkezleri arasında—çoğu zaman birkaç ülkeyi aşarak—taşımak için yapılan işlerdir; aradaki karmaşayı düşünmenize gerek kalmaz.

Bu görünmezliği TCP/IP sağlar. Tek bir ürün veya bulut özelliği değildir. Cihazların ve sunucuların, ağ gürültülü, tıkalı veya kısmen arızalı olsa bile genellikle sorunsuz ve güvenilir hissedecek şekilde konuşmasına izin veren paylaşılan kurallar bütünüdür.

Bob Kahn, bunun mümkün olmasında kilit isimlerden biriydi. Vint Cerf gibi iş birlikçileriyle birlikte, TCP/IP haline gelen temel fikirleri şekillendirmeye yardımcı oldu: ağlar için ortak bir “dil” ve uygulamaların güvenebileceği şekilde veriyi teslim etme yöntemi. Abartıya gerek yok—bu iş önem taşıdı çünkü güvenilmez bağlantıları yazılımın üzerine güvenle inşa edebileceği bir şeye dönüştürdü.

Paket ağları, meşgul olduğunuzu düşünerek açıklama

Tek bir mesajı sürekli bir akış halinde göndermek yerine paket ağı, onu paket adı verilen küçük parçalara böler. Her paket varış yerine kendi yolunu izleyebilir; farklı postanelerden geçen ayrı zarflar gibi düşünebilirsiniz.

Bu yazıda neleri öğreneceksiniz

TCP’nin güven duygusunu nasıl yarattığını, IP’nin neden kasıtlı olarak kusursuz vaat etmediğini ve katmanlamanın sistemi neden anlaşılır kıldığını açacağız. Yazının sonunda bir uygulama bir API çağırdığında olup biteni ve bu onlarca yıllık fikirlerin modern bulut servislerini neden hâlâ güçlendirdiğini hayal edebileceksiniz.

TCP/IP’nin Çözmesi Gereken Problem

Erken bilgisayar ağları “İnternet” olarak doğmadı. Belirli gruplar için, belirli amaçlarla kuruldular: bir üniversite ağı burada, bir askeri ağ orada, bir araştırma laboratuvarı ağı başka yerde. Her biri dahili olarak iyi çalışabilirdi, ama genellikle farklı donanım, mesaj formatları ve veri yolculuğunun kuralları vardı.

Bu, sinir bozucu bir gerçeklik yarattı: iki bilgisayar “ağa bağlı” olsa bile bilgi alışverişi yapamayabiliyorlardı. Farklı ray genişlikleri ve farklı sinyal anlamları olan birçok demiryolu sistemi olan bir ülke düşünün. Bir sistem içinde trenleri hareket ettirebilirsiniz, ama başka bir sisteme geçiş zor, pahalı ya da imkansız olabilir.

İnternetworking: sadece bilgisayarları değil ağları bağlamak

Bob Kahn’ın ana meydan okuması sadece “bilgisayar A’yı bilgisayar B’ye bağlamak” değildi. Sorun şuydu: Ağları birbirine nasıl bağlarsınız ki trafik, birden çok bağımsız sistemden geçse bile daha büyük, tek bir sistemmiş gibi ilerlesin?

İşte “internetworking” bunun anlamı—farklı tasarlanmış ve farklı kuruluşlar tarafından yönetilen ağların üzerinden verinin ağdan ağa atlayabilmesini sağlayan bir yöntem inşa etmek.

Neden paylaşılan kurallar (protokoller) önemliydi

İnternetworking büyük ölçekte çalışsın istiyorsanız, herkesin tek bir ağın iç tasarımına bağlı olmayan ortak bir dizi kurala—protokole—ihtiyacı vardı. Bu kurallar ayrıca gerçek kısıtları da yansıtmalıydı:

• Ağlar çökecek, veri düşürecek veya sırasız teslimat yapacaktı.
• Hiçbir merkezi işletmeci her bağlantıyı mikro yönlendiremeyecekti.
• Zaman içinde yeni ağlar eklenmeye devam edecekti.

TCP/IP pratik bir cevap oldu: bağımsız ağların birbirine bağlanmasına izin veren ve yine de gerçek uygulamalar için yeterince güvenilir veri taşıyabilen ortak bir “anlaşma”.

Bob Kahn’ın Katkısı Basitçe

Bob Kahn, İnternet’in “yol kuralları”nı oluşturan kilit mimarlardan biri olarak bilinir. 1970’lerde DARPA’da çalışırken, ağcılığı zekice bir araştırma deneyinden, farklı türdeki birçok ağı birbirine bağlayabilecek bir şeye taşımaya yardımcı oldu—tüm ağların aynı donanımı, kablolamayı veya iç tasarımı kullanmasını zorunlu kılmadan.

Temel fikir: ağları konuşur hale getirmek

ARPANET paket anahtarlı bağlantılar üzerinden bilgisayarların iletişim kurabileceğini gösterdi. Ama radyo tabanlı sistemler, uydu bağlantıları ve diğer deneysel ağlar da ortaya çıkıyordu—her birinin kendine özgü tuhaflıkları vardı. Kahn’in odak noktası birlikte çalışabilirlikti: bir mesajın birden çok ağ üzerinden tek bir ağmış gibi yol alabilmesini sağlamak.

Bir “mükemmel” ağ inşa etmek yerine şu yaklaşımı savundu:

• Her yerel ağ kendi tasarımını koruyabilir.
• Üstte ortak bir protokol, ağ sınırları boyunca veriyi taşır.
• Bu “tutkal” gelecekte kimsenin henüz icat etmediği ağlar üzerinde de çalışacak kadar geneldir.

Vint Cerf ile birlikte çalışarak TCP/IP haline geleni ortaklaşa tasarladılar. Kalıcı sonuçlardan biri sorumlulukların net ayrımıydı: IP adresleme ve yönlendirmeyi, TCP ise uygulamalar için güvenilir teslimatı yönetir.

Geliştiriciler bugün neden hâlâ fayda görüyor

Bir API çağırdıysanız, bir web sayfası yüklediyseniz veya bir konteynerdan bir izleme servisine log gönderdinizse, Kahn’in savunduğu internetworking modeline güveniyorsunuz. Paketlerin Wi‑Fi, fiber, LTE veya bulut omurgası üzerinden geçtiğini umursamak zorunda değilsiniz. TCP/IP bunların hepsini tek bir sürekli sistem gibi gösterir—yazılım böylece özelliklere, kablolamaya değil odaklanabilir.

TCP/IP Katmanlama Fikri: Basit ama Güçlü

TCP/IP’nin arkasındaki en akıllı fikirlerden biri katmanlamadır: her şeyi yapan tek bir devasa ağ sistemi inşa etmek yerine her katman bir işi iyi yapsın diye küçük parçaları üst üste koyarsınız.

Bu önemlidir çünkü ağlar birbirinin aynı değildir. Farklı kablolar, radyolar, yönlendiriciler ve sağlayıcılar birkaç temiz sorumlulukta anlaştıklarında yine birlikte çalışabilirler.

IP: ağlar arasında adresleme ve yönlendirme

IP (Internet Protocol) şu soruyu yanıtlar: Bu veri nereye gidiyor ve onu o yere nasıl yaklaştırırız?

IP, makinelerin tanımlanması için adresler sağlar ve paketlerin ağdan ağa atlayabilmesi için temel yönlendirme sunar. Önemli olarak, IP mükemmel olmaya çalışmaz. Paketleri bir adım öteye taşımaya odaklanır; yol değişse bile ilerlemeyi sürdürür.

TCP: IP üstünde güvenilir teslimat

TCP (Transmission Control Protocol) daha sonra IP’nin üstünde yer alır ve şöyle yanıt verir: Bunu nasıl güvenilir bir bağlantı gibi hissettiririz?

TCP uygulamaların genellikle istediği “güvenilirlik” işlerini yapar: veriyi doğru sırada teslim etme, eksik parçaları fark etme, gerektiğinde yeniden deneme ve göndericinin alıcıyı veya ağı aşırı yüklemesini önleyecek bir hızlama uygulama.

Basit bir posta benzetmesi

Ayrımı şöyle düşünebilirsiniz:

• IP, zarfı şehirler ve postaneler arasında taşıyan adresleme ve yönlendirme ağı gibidir.
• TCP, çok parçalı bir gönderinin eksiksiz ve doğru sırada ulaştığını garanti eden takip ve onay sistemine benzer.

Adres sormayla paketin geleceğini garanti edemezsiniz; bu güveni üstte inşa edersiniz.

Bu “basit yığın” neden güçlü kaldı

Sorumluluklar ayrıldığı için bir katmanı yeniden tasarlamak tüm sistemi baştan yapmayı gerektirmez. Yeni fiziksel ağlar IP taşıyabilir ve uygulamalar TCP’nin davranışına güvenebilir; yönlendirmenin nasıl çalıştığını anlamak zorunda kalmazlar. Bu temiz ayrım, TCP/IP’nin hemen her uygulama ve API’nin altında görünmez, paylaşılan temel haline gelmesinin büyük bir nedenidir.

Paket Anahtarlama: Hız, Esneklik ve Karmaşa

Paket anahtarlama, büyük ağları pratik kılan fikirdir: mesajınızı tüm yolu için ayrılmış bir hat rezervasyonu yerine küçük parçalara böler ve her parçayı bağımsız gönderirsiniz.

Bir “paket” nedir (ve neden parçalar kazanır)

Paket, bir başlık (kimden, kime ve diğer yönlendirme bilgileri) ile içerikten bir dilim içeren küçük bir veri paketidir.

Veriyi parçalara ayırmak şunları sağlar:

• Hatları birçok kullanıcı arasında paylaşma (kablonun sahibi yoktur).
• Ağın yavaş veya kırık kısımlarının etrafından yönlendirme.
• Tüm dosyayı değil sadece kayıp parçaları yeniden göndererek kurtarma.

Farklı yollar, karışık sıra

İşte “karmaşa” burada başlar. Aynı indirme veya API çağrısına ait paketler o an meşgul veya uygun olan duruma göre farklı yollar izleyebilir. Bu da paketlerin sırasız gelmesine neden olabilir—örneğin #12 numaralı paket #5’ten önce ulaşabilir.

Paket anahtarlama bunu engellemeye çalışmaz. Paketleri hızlı geçirmek, varış sırasının dağınık olması pahasına tercih edilir.

Paketler neden kaybolur

Paket kaybı nadir değildir ve her zaman birilerinin suçu değildir. Yaygın nedenler:

• Tıkanıklık: yönlendiriciler tampon alanı biter ve paket düşürür.
• Gürültü/enterferans: özellikle kablosuz bağlantılarda.
• Kesintiler ve yeniden yönlendirmeler: bir bağlantı ortasında bozulur ve bazı paketler ulaşamaz.

Kusur bir hata değil, bir özellik

Ana tasarım tercihi ağın kusurlu olmasına izin vermektir. IP paketleri iletmeye odaklanır; teslimat veya sıralama sözü vermez. Bu serbestlik ağların ölçeklenmesini sağlar—ve üst katmanların (ör. TCP) karmaşayı temizlemesi için gerekçe sunar.

TCP Güvenilmez Ağları Nasıl Güvenilir Hissettirir

IP paketleri "elinden geleni yapar" düzeyinde iletir: bazıları geç gelebilir, sıradan çıkabilir, çoğaltılabilir veya hiç gelmeyebilir. TCP bunun üstünde uygulamaların güvenebileceği bir şey yaratır: tek, sıralı, eksiksiz bir bayt akışı—dosya yüklerken, bir web sayfası yüklerken veya bir API çağırırken beklediğiniz türden bir bağlantı.

Güvenilirlik, basitçe

İnsanlar TCP’ye "güvenilir" dediklerinde genellikle şunları kastediyorlar:

• Sıralı: veri uygulamaya gönderildiği sırayla teslim edilir.
• Eksiksiz: eksik parçalar tespit edilir ve yeniden gönderilir.
• Boşluk yok: uygulama dağıtılmış paketler yerine sürekli bir akış okur.

Ana mekanizmalar (ve neden işe yarıyorlar)

TCP verinizi parçalara böler ve her parçaya sıra numaraları verir. Alıcı, ne aldığını onaylamak için ACK gönderir.

Eğer gönderici zamanında bir ACK görmezse, bir şeyin kaybolduğunu varsayar ve yeniden iletim yapar. Bu temel “illüzyon”dur: ağ paketleri düşse bile TCP karşı taraf onaylayana dek denemeye devam eder.

Akış kontrolü vs tıkanıklık kontrolü

Benzer görünseler de farklı sorunları çözerler:

• Akış kontrolü alıcıyı korur. "Meşgulüm—daha yavaş gönder." der.
• Tıkanıklık kontrolü ağı korur. "Yol tıkalı—geri çekil." der.

Birlikte TCP’nin hızlı ama makul kalmasına yardımcı olurlar.

Uyarlamalı zaman aşımı

Sabit bir zaman aşımı hem yavaş hem hızlı ağlarda başarısız olurdu. TCP, ölçülen gidiş-dönüş zamanına göre sürekli olarak zaman aşımını ayarlar. Koşullar kötüleşirse yeniden gönderim için daha uzun bekler; hızlanırsa daha duyarlı olur. Bu uyum, TCP’nin Wi‑Fi, mobil ağlar ve uzun mesafe bağlantılarında çalışmaya devam etmesinin nedenidir.

Ölçeklenen Bir Tasarım Tercihi: Uçtan Uca Düşüncesi

TCP/IP’nin en önemli fikirlerinden biri uçtan uca prensibidir: "zeka"yı ağın uçlarına koy, ağın ortasını nispeten basit tut.

Uçlarda zeka

Basitçe söylemek gerekirse, uçlar verinin gerçekten önemini taşıyan cihazlar ve programlardır: telefonunuz, dizüstünüz, bir sunucu ve üzerlerinde çalışan işletim sistemleri ve uygulamalar. Ağın çekirdeği—ortadaki yönlendiriciler ve bağlantılar—öncelikle paketleri ilerletmeye odaklanır.

Her yönlendiriciyi "mükemmel" yapmaya çalışmak yerine, TCP/IP ortanın kusurlu olacağını kabul eder ve bağlam gerektiren işleri uçlara bırakır.

Daha basit bir çekirdek büyümeyi neden sağladı

Çekirdeği basit tutmak İnternet’in büyümesini kolaylaştırdı. Yeni ağlar katılabilirken her ara cihazın her uygulamanın ihtiyaçlarını anlaması gerekmiyordu. Yönlendiricilerin bir paketin bir video araması mı yoksa API isteği mi olduğunu bilmesi gerekmez—sadece iletirler.

Neyin nereye ait olduğuna örneklerle

Uçlarda genellikle şunlar ele alınır:

• Güvenilirlik: yeniden iletimler, sıralama, çoğaltma temizleme (TCP).
• Güvenlik: şifreleme ve kimlik (çoğunlukla uygulama/OS seviyesinde TLS).
• Uygulama davranışı: zaman aşımı, yeniden denemeler, önbellekleme, oran sınırlama.

Ağda ise daha çok:

• Adresleme ve yönlendirme (IP).
• Temel paket işleme ve tıkanıklık sinyalleri.

Takas

Uçtan uca düşünce iyi ölçeklenir, ama karmaşıklığı dışa iter. İşletim sistemleri, kütüphaneler ve uygulamalar ağın dağınık yapısı üzerinde işi yürütecek şekilde sorumlu olur. Bu esneklik iyidir ama hatalı zaman aşımı ayarları veya saldırgan yeniden denemeler gerçek kullanıcı sorunlarına yol açabilir.

IP’nin “Elinden Geleni Yapma” Modeli Neden Özellikti

IP basit bir söz verir: paketlerinizi varış noktasına doğru taşımaya çalışır. Hepsi bu. Paketin gelip gelmeyeceği, yalnızca bir kez mi geleceği, sırada mı geleceği ya da belirli bir süre içinde mi geleceği konusunda garanti vermez.

Bu bir kusur gibi görünebilir—ta ki İnternet’in ne olması gerektiğine bakana kadar: birçok küçük ağdan oluşan, farklı kuruluşların sahip olduğu ve sürekli değişen küresel bir ağ.

Yönlendiriciler ne yapar (ne yapmaz)

Yönlendiriciler IP’nin “trafik yöneticileri”dir. Temel işleri iletmektir: bir paket geldiğinde yönlendirici hedef adresine bakar ve şu an için en iyi görünen bir sonraki adımı seçer.

Yönlendiriciler bir konuşmayı telefon operatörü gibi takip etmez. Genelde size kapasite ayırmazlar ve bir paketin geçtiğini teyit etmek için beklemezler. Yönlendiricileri iletmeye odaklayarak ağın çekirdeği basit kalır—ve çok sayıda cihaz ve bağlantı için ölçeklenebilir.

“Elinden geleni yapma” küresel ölçekte neden işledi

Garantiler pahalıdır. IP her pakete teslimat, sıra ve zaman garantisi vermeye çalışsaydı, dünyadaki her ağ sıkı koordinasyon yapmak, çok fazla durum saklamak ve arızalardan aynı şekilde kurtulmak zorunda kalırdı. Bu koordinasyon yükü büyümeyi yavaşlatır ve arızaları daha şiddetli yapardı.

Bunun yerine IP dağınıklığı tolere eder. Bir bağlantı kesilirse, yönlendirici paketleri farklı bir rota üzerinden gönderebilir. Bir yol tıkandığında paketler gecikebilir veya düşebilir, ama trafik genellikle alternatif yollarla devam edebilir.

Sonuç: ağ parçaları bozulsa bile İnternet çalışmaya devam edebilir—çünkü ağın mükemmel olması gerekmiyor.

Uygulamalardan Paketlere: Gerçekte Neler Oluyor

fetch() ile bir API çağırdığınızda, "sunucuya tek bir düzgün akışta konuşuyorsunuz" gibi değildir. Uygulamanız veriyi işletim sistemine verir; işletim sistemi onu paketlere böler ve bu paketler birçok ayrı ağ üzerinden gönderilir—her atlama kendi kararlarını verir.

Basit eşleme: geliştirici eylemleri → TCP/IP davranışı

• HTTP isteği / API çağrısı: uygulamanız bayt yazar (bir HTTP isteği). TCP o bayt akışını segmentlere böler, numaralandırır ve onay bekler. IP her segmenti paket içine sarar ve yönlendirir.
• Bağlantı açma: bir TCP el sıkışması paylaşılan durumu (sıra numaraları, pencere boyutları) kurar. Bu ücretsiz değildir—ilk faydalı byte gelmeden önce zaman alır.
• Dosya yükleme: TCP yeterli verim sağlayabilir, ama gecikme yüksekse performans yine de yavaş hissedilebilir.

Gecikme vs bant genişliği (uygulamanız neden yavaş hissedilir)

• Gecikme bir mesajın gidiş-dönüş süresidir. Çok sayıda küçük istek, yeniden yönlendirme, tekrarlayan API çağrıları gibi konuşkan desenleri zayıflatır.
• Bant genişliği saniyede iletilebilen veri miktarıdır. Büyük transferleri etkiler: resimler, yedekler, video.

Sık karşılaşılan sürpriz: iyi bant genişliğiniz olabilir ama yüksek gecikme yüzünden UI yavaş hissedebilir; çünkü her istek tur süresine bağlı bekler.

Yeniden denemeler ve zaman aşımı: uygulamalar neden TCP’nin üzerine tekrar yapar

TCP kaybolan paketleri yeniden dener, ama kullanıcı deneyimi için "çok uzun"un ne olduğunu bilemez. Bu yüzden uygulamalar ekler:

• Zaman aşımı: "2 saniye içinde yanıt gelmezse hata göster."
• Yeniden denemeler: "Bir kez daha dene." Geçici kopuşlar için faydalıdır ama ödemeler gibi işlemler için idempotent değilse tehlikelidir.

"Hatalar" aslında ağ gerçekleri olabilir

Paketler gecikebilir, yeniden sıralanabilir, çoğaltılabilir veya düşebilir. Tıkanıklık gecikmeyi patlatabilir. Bir sunucu yanıt verse bile yanıt size ulaşmayabilir. Bunlar kırılgan testler, rastgele 504 hataları veya "kendi makinemde çalışıyor" gibi belirtiler olarak görünür. Çoğu zaman kodunuz düzgündür—sorun makineler arasındaki yoldadır.

TCP/IP Bulutta: Aynı Kurallar, Daha Büyük Ölçek

Bulut platformları tamamen yeni bir bilişim türü gibi gelebilir—yönetilen veritabanları, serverless fonksiyonlar, “sonsuz” ölçek. Altında ise istekleriniz hala Kahn’ın başlattığı aynı TCP/IP temelleri üzerinde gider: IP paketleri ağlar arasında taşır ve TCP (veya bazen UDP) uygulamaların ağı nasıl deneyimlediğini şekillendirir.

Bulutta ne değişir (çoğunlukla paketleme)

Sanal makineler ve konteynerler nerede yazılımın çalıştığını ve nasıl paketlendiğini değiştirir:

• Bir “sunucu” sanal makine, konteyner veya kısa ömürlü bir fonksiyon olabilir.
• Ağlar genellikle sağlayıcı tarafından yazılım tanımlı (software-defined) olarak birleştirilir.

Ama bunlar konuşlandırma ayrıntılarıdır. Paketler hâlâ IP adreslemesi ve yönlendirmesi kullanır ve birçok bağlantı sıralı, güvenilir teslimat için TCP’ye dayanır.

Aynı kalan kalıplar

Ortak bulut mimarileri tanıdık ağ yapı taşlarından kurulur:

• Load balancer’lar istemci TCP bağlantılarını (çoğunlukla HTTPS) kabul eder ve trafiği backend servislere dağıtır.
• Servisler arası çağrılar küme içinde hala ağ çağrısıdır—çoğunlukla TCP üzerinde HTTP/gRPC.
• Veritabanları ve cache’ler TCP üstünde standart protokollerle erişilir (örneğin bir veritabanı sürücüsünün TCP oturumu sürdürmesi).

IP adresini hiç görmeseniz bile platform adres atar, paketleri yönlendirir ve arka planda bağlantıları takip eder.

Güvenilirlik hâlâ ortak bir iş

TCP düşen paketleri geri getirir, sıralamayı düzeltir ve tıkanıklığa uyum sağlar—ama imkansızı vaat edemez. Bulut sistemlerinde güvenilirlik ekip işi:

• Ağ: yönlendirme, kapasite, paket kaybı, geçici arızalar.
• OS/runtime: soket tamponları, zaman aşımı ayarları, DNS önbellekleme, bağlantı yeniden kullanımı.
• Uygulama: exponential backoff ile yeniden denemeler, idempotentlik, makul zaman aşımı ve kibar düşüş davranışı.

Bu yüzden Koder.ai gibi platformlar size tam bir stack hızlıca verse bile, uygulamanız bir API, veritabanı veya mobil istemciyle konuştuğunda tekrar TCP/IP bölgesindesiniz—bağlantılar, zaman aşımı, yeniden denemeler ve hepsi.

TCP vs UDP ve Geliştiricilerin Bugün Neyi Seçtiği

“Network” dediklerinde geliştiriciler genellikle IP üstünde iki taşıyıcı arasında seçim yaparlar: TCP ve UDP. Her ikisi de IP’nin üstünde çalışır ama çok farklı ödünler verirler.

TCP: güvenilir akış (ve gizli maliyetleri)

TCP, verinin sırayla, eksiksiz gelmesi gerektiğinde idealdir ve beklemeyi tercih edersiniz. Düşünün: web sayfaları, API çağrıları, dosya transferleri, veritabanı bağlantıları.

Bu yüzden günlük internetin büyük kısmı TCP üzerindendir—HTTPS TCP üzerinde çalışır (TLS ile) ve çoğu istek/yanıt yazılımı TCP davranışına güvenerek tasarlanmıştır.

Fakat maliyeti: TCP güvenilirliği gecikme ekleyebilir. Bir paket kaçırılırsa sonraki paketler “başta bloklanabilir” (head-of-line blocking) ve bekletilebilir. Etkileşimli deneyimler için bu bekleme, ara sıra oluşan bir aksaklıktan daha rahatsız edici olabilir.

UDP: basit, hızlı ve uygulama kontrollü

UDP, mesajı gönderir ve ulaşmasını umarsınız; sıralama, yeniden iletim veya tıkanıklık kontrolü sağlamaz.

Zamanlama mükemmellikten daha önemliyse geliştiriciler UDP’yi seçerler: canlı ses/video, oyunlar veya gerçek zamanlı telemetri gibi. Bu uygulamalar genellikle kendi hafif güvenilirlik katmanlarını kurar veya hiç kurmazlar.

Modern büyük örneklerden biri: QUIC, UDP üstünde çalışarak uygulamaların daha hızlı bağlantı kurmasına ve bazı TCP darboğazlarından kaçınmasına izin verir—altyapı IP ağını değiştirmeye gerek kalmadan.

Seçim için pratik rehber

Karar verin:

• Güvenilirlik ihtiyacı: Her bayt sıralı ve eksiksiz mi gelmeli? TCP tercih edin.
• Gecikme duyarlılığı: "Şimdi" kusursuzluktan daha mı önemli? UDP düşünün.
• Kontrol: Uygulama hangi parçayı yeniden deneyeceğine, neleri atlayacağına karar vermek istiyor mu? UDP (veya QUIC) daha fazla esneklik sunar.

"Güvenilir"in Hâlâ Garantileyemediği Şeyler: Gerçek Dünya Tuzakları

TCP sıklıkla “güvenilir” olarak tanımlanır ama bu uygulamanızın her zaman güvenilir hissedeceği anlamına gelmez. TCP birçok ağ sorunundan kurtulabilir, fakat iki sistem arasındaki yol kararsızsa düşük gecikme, tutarlı bant genişliği veya iyi kullanıcı deneyimi garanti edemez.

Karşılaşacağınız yaygın ağ sorunları

Paket kaybı TCP’nin yeniden iletim yapmasını zorlar. Güvenilirlik korunur ama performans kötüleşebilir.

Yüksek gecikme (uzun round-trip time) her istek/yanıt döngüsünü yavaşlatır, paket kaybı yokken bile.

Bufferbloat yönlendirici veya işletim sistemi kuyrukları çok fazla veri tuttuğunda olur. TCP daha az kayıp görür ama kullanıcılar büyük gecikmeler ve “takılma” hissi yaşar.

Yanlış yapılandırılmış MTU parçalanmaya veya paketlerin yok olmasına neden olabilir; bu da rastgele görünen zaman aşımı hatalarına yol açar.

Uygulama içinde bunun neye benzediği

Net bir “ağ hatası” yerine genellikle görürsünüz:

• Normalde çalışan API çağrılarında zaman aşımı.
• Hızlı başlayan sonra sürünmeye düşen yüklemeler/indirmeler.
• "Kararsız" bağlantılar: tekrarlayan yeniden bağlanmalar, duraklayan akışlar veya kısmi sayfa yüklemeleri.

Bu semptomların kaynağı her zaman kod değildir; çoğu zaman TCP işi yaparken uygulamanızın zamanlayıcısı tükeniyordur.

Pratik hata ayıklama başlangıç noktaları

Önce temel sınıflandırmayla başlayın: sorun çoğunlukla kayıp, gecikme mi yoksa yol değişiklikleri mi?

• Ping tarzı kontroller gecikme ve kayıp hakkında fikir verir (ICMP bazen engellense de).
• Traceroute tarzı düşünme gecikme veya kaybın nerede başladığını bulmaya yardımcı olur.
• Kayıtlar ve metrikler ekleyin: istek süreleri, zaman aşımı sayıları, yeniden deneme sayıları ve kuyruk/geri basınç sinyalleri.

Hızlı geliştiriyorsanız (ör. Koder.ai ile bir servis prototipi oluşturup barındırıyorsanız), bu gözlemlenebilirlik temellerini planlama aşamasına almak değerlidir—çünkü ağ hataları önce zaman aşımı ve yeniden denemeler olarak ortaya çıkar, temiz istisnalar değil.

Başarısızlık ile tasarlayın

Ağların bozulacağını varsayın. Zaman aşımı, exponential backoff ile yeniden denemeler kullanın ve işlemleri idempotent yapın ki yeniden denemeler ücretlendirme, çoğaltma veya durum bozulmasına yol açmasın.