Bob Kahn’ın TCP/IP’yi nasıl şekillendirdiğini, paket ağlarının neden güvenilirliğin anahtarı olduğunu ve bu tasarımın uygulamalar, API’ler ve bulut servislerini nasıl desteklemeye devam ettiğini öğrenin.
Ç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ü.
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.
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.
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.
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.
İ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ı:
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, İ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.
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:
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.
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’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 (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 (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.
Ayrımı şöyle düşünebilirsiniz:
Adres sormayla paketin geleceğini garanti edemezsiniz; bu güveni üstte inşa edersiniz.
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, 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.
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:
İş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.
Paket kaybı nadir değildir ve her zaman birilerinin suçu değildir. Yaygın nedenler:
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.
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ı.
İnsanlar TCP’ye "güvenilir" dediklerinde genellikle şunları kastediyorlar:
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.
Benzer görünseler de farklı sorunları çözerler:
Birlikte TCP’nin hızlı ama makul kalmasına yardımcı olurlar.
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.
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.
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.
Ç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.
Uçlarda genellikle şunlar ele alınır:
Ağda ise daha çok:
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 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 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.
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.
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.
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.
TCP kaybolan paketleri yeniden dener, ama kullanıcı deneyimi için "çok uzun"un ne olduğunu bilemez. Bu yüzden uygulamalar ekler:
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.
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.
Sanal makineler ve konteynerler nerede yazılımın çalıştığını ve nasıl paketlendiğini değiştirir:
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.
Ortak bulut mimarileri tanıdık ağ yapı taşlarından kurulur:
IP adresini hiç görmeseniz bile platform adres atar, paketleri yönlendirir ve arka planda bağlantıları takip eder.
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:
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.
“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, 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, 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.
Karar verin:
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.
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.
Net bir “ağ hatası” yerine genellikle görürsünüz:
Bu semptomların kaynağı her zaman kod değildir; çoğu zaman TCP işi yaparken uygulamanızın zamanlayıcısı tükeniyordur.
Önce temel sınıflandırmayla başlayın: sorun çoğunlukla kayıp, gecikme mi yoksa yol değişiklikleri mi?
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.
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.
TCP/IP, farklı ağların birbirine bağlanmasına ve veriyi öngörülebilir şekilde iletmesine izin veren ortak bir dizi ağ kuralıdır.
Önemi şuradan gelir: Wi‑Fi, LTE, fiber ve uydu gibi güvenilmez, heterojen bağlantıları yazılım için kullanılabilir hale getirir—yani uygulamalar, fiziksel ağ detaylarını bilmeden bayt gönderip yanıt alabileceğini varsayabilir.
Bob Kahn, “internetworking” fikrini ileri taşıyarak farklı ağların aynı dahili tasarımı veya donanımı paylaşmak zorunda kalmadan birbirine bağlanmasını sağladı.
Vint Cerf gibi iş birlikçileriyle birlikte, bu çalışma IP'nin ağlar arasında adresleme/iletimle ilgilenmesini ve TCP'nin üstünde uygulamalar için güvenilir teslimat sağlamasını öngören ayrımı şekillendirdi.
Paket anahtarlama, bir mesajı küçük paketlere bölmektir; her paket bağımsız yolculuk edebilir.
Yararları:
IP tek bir işe odaklanır: paketleri hedef adrese doğru iletmeye çalışmak. Teslimat, sıra veya zamanlama garantisi vermez.
Bu “elinden geleni yapma” modeli, yönlendiricilerin basit ve hızlı kalmasını sağlar; ağlar başarısız olduğunda veya yeni ağlar katıldığında bile küresel ölçekte büyümeyi mümkün kılar.
TCP, IP’nin en iyi çabasıyla ilettiği paketleri uygulama dostu bir sıralı bayt akışı haline getirir.
Bunu şu mekanizmalarla yapar:
Farklı sorunları çözerler:
İyi performans için her ikisi de gereklidir: hızlı bir gönderici hem alıcıya hem de ağın durumuna saygı göstermelidir.
Katmanlama (layering), her katmanın tek bir işi iyi yapmasını sağlar; böylece her parça bağımsız olarak gelişebilir.
Geliştiriciler için sonucu: her ağ tipi için uygulamanızı yeniden tasarlamak zorunda kalmadan API’ler inşa edebilirsiniz.
Uçtan uca prensibi, ağın çekirdeğini (yönlendiriciler) nispeten basit tutup “zeka”yı uçlara koymayı söyler.
Uygulamalar ve işletim sistemleri, güvenilirlik, zaman aşımı, yeniden denemeler ve şifreleme (genellikle TLS ile) gibi bağlama duyarlı işleri halleder; ağ çekirdeği her uygulamaya özel davranamaz.
Gecikme (latency) tek bir isteğin gidiş-dönüş süresidir; çok konuşkan desenleri (birbiri ardına küçük istekler) zayıflatır.
Bant genişliği (throughput) saniyede iletilen bayt miktarıdır; büyük transferleri etkiler.
Pratik ipuçları:
Seçiminiz ihtiyaçlarınıza dayanmalı:
Kural: istek/yanıt ve doğruluk öncelikli uygulamalar genellikle TCP (veya HTTP/3 için QUIC) ile başlar.
