Ağ temelleri: TCP, DNS, HTTP, TLS

Backend mülakatlarında ağ soruları genelde iki amaçla sorulur: "tarayıcıya adres yazınca ne olur" gibi bir soruyla adayın uçtan uca resmi görüp görmediğini anlamak, ve production'da karşılaşılan sorunları (timeout, bağlantı tükenmesi, yavaş DNS, TLS hatası) ağ katmanında düşünebiliyor mu diye bakmak. Ağ mühendisi kadar derin bilmen beklenmez; ama bir isteğin hangi katmanlardan geçtiğini ve her katmanda neyin bozulabileceğini anlatabilmen beklenir.

Katmanlar

Pratikte TCP/IP modeli kullanılır; OSI'nin yedi katmanı daha çok terminoloji için anılır ("L4 load balancer", "L7 proxy").

TLS tam olarak bir katmana oturmaz: TCP'nin üstünde, HTTP'nin altında çalışır. Bu yüzden bir L4 load balancer şifreli trafiği açmadan iletebilir; L7 load balancer ise HTTP başlığını, path'i ya da cookie'yi okuyacaksa TLS'i sonlandırmak zorundadır.

TCP ve UDP

TCP bağlantı yönelimlidir: üçlü el sıkışma (SYN, SYN-ACK, ACK) ile bağlantı kurulur; veri sıralı, kayıpsız ve tekrarsız teslim edilir. Kayıp paket yeniden gönderilir, akış kontrolü (alıcının penceresi) ve tıkanıklık kontrolü (ağın kapasitesi) gönderim hızını ayarlar. Bunun bedeli gecikmedir: bağlantı kurmak en az bir tur (RTT) sürer, kayıp bir paket arkasındaki tüm verinin uygulamaya teslimini bekletir (head-of-line blocking).

UDP bağlantısızdır: paket gönderilir, teslim, sıra ya da tekrar garantisi yoktur. Bu yüzden hafif ve hızlıdır; DNS sorguları, video/ses akışı ve oyunlar UDP kullanır. Güvenilirlik gerekiyorsa uygulama kendisi sağlar. QUIC tam olarak budur: UDP üstünde güvenilirlik, akış başına sıralama ve dahili TLS 1.3; HTTP/3 QUIC üzerinde çalışır.

Bağlantı kapanırken önce kapatan taraf TIME_WAIT durumunda bir süre bekler (Linux'ta 60 saniye). Saniyede binlerce kısa ömürlü bağlantı açıp kapatan bir servis, istemci tarafında ephemeral port'larını (Linux'ta varsayılan 32768-60999) tüketebilir. Çözüm genelde kernel ayarı değil, bağlantıyı yeniden kullanmaktır: HTTP keep-alive ve bağlantı havuzu.

DNS

DNS, api.example.com gibi bir adı IP adresine çevirir. Akış: uygulama işletim sisteminin resolver'ına sorar; o önce kendi cache'ine ve /etc/hosts'a bakar, sonra recursive resolver'a (şirket DNS'i, ISP ya da 8.8.8.8) gider. Recursive resolver cache'inde yoksa sırayla root sunucusuna, .com TLD sunucusuna ve alan adının authoritative sunucusuna sorar ve cevabı TTL süresince cache'ler.

TTL bir ödünleşimdir: uzun TTL daha az sorgu ve daha hızlı çözümleme demektir ama IP değişikliği (failover, taşıma) geç yayılır. Planlı bir taşımadan önce TTL düşürülür. Java tarafında bir tuzak var: JVM DNS cevaplarını kendi içinde de cache'ler (networkaddress.cache.ttl). Load balancer IP'leri değişen bir ortamda bu değerin makul olması gerekir.

HTTP sürümleri

gRPC HTTP/2 üzerinde çalışır; uzun ömürlü tek bağlantı kullandığı için L4 load balancer'da yükü dengesiz dağıtabilir (bkz. İleri seviye soru).

TLS ve HTTPS

TLS üç şey sağlar: gizlilik (şifreleme), bütünlük (veri yolda değişmedi) ve kimlik doğrulama (karşı taraf gerçekten o sunucu). TLS 1.3 el sıkışması bir turda (1-RTT) biter: istemci desteklediği şifre takımlarını ve anahtar paylaşımını gönderir; sunucu kendi anahtar paylaşımını ve sertifikasını gönderir. İstemci sertifika zincirini güvendiği kök otoritelere (CA) kadar doğrular ve sertifikadaki adın bağlandığı adla eşleştiğini kontrol eder. Oturum anahtarı Diffie-Hellman ile türetilir; bu sayede sunucunun özel anahtarı ileride çalınsa bile geçmiş trafik çözülemez (forward secrecy).

mTLS'te sunucu da istemciden sertifika ister. Servisler arası iletişimde ve bankacılıkta kurum-kurum entegrasyonlarında sık görülür; service mesh'ler (Istio, Linkerd) bunu otomatikleştirir. Sertifikaların süresi dolar: production kesintilerinin klasik sebeplerinden biri yenilenmeyen sertifikadır, bu yüzden bitiş tarihi izlenir ve yenileme otomatikleştirilir.

Load balancer, proxy ve CDN

• Forward proxy istemcinin önünde durur, istemci adına dışarı çıkar (kurumsal çıkış proxy'si).
• Reverse proxy sunucuların önünde durur: TLS sonlandırma, yönlendirme, sıkıştırma, cache, rate limiting (Nginx, Envoy).
• L4 load balancer IP ve port'a bakar, TCP bağlantısını bir hedefe iletir; hızlıdır, içeriği görmez (AWS NLB).
• L7 load balancer HTTP'yi anlar: path ya da host'a göre yönlendirme, başlık ekleme, istek bazında dağıtım (AWS ALB, Nginx).
• CDN statik içeriği (ve bazen API cevaplarını) kullanıcıya yakın uç sunuculardan servis eder; gecikmeyi ve origin yükünü azaltır.

Load balancer arkasındaki uygulama istemcinin gerçek IP'sini X-Forwarded-For başlığından öğrenir. Bu başlık istemci tarafından da gönderilebildiği için yalnızca güvenilen proxy'lerin eklediği değer okunmalıdır (Spring Boot'ta server.forward-headers-strategy).

IP adresleme, CIDR ve NAT

10.0.0.0/16 gösteriminde /16, ilk 16 bitin ağı tanımladığını söyler; geriye 16 bit, yani 65.536 adres kalır. /24 256 adres demektir. Özel (internette yönlendirilmeyen) aralıklar RFC 1918'de tanımlıdır: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Özel ağdaki makineler internete NAT üzerinden çıkar: NAT kaynak adresi kendi genel adresiyle değiştirir ve dönen cevabı doğru makineye geri iletir. İçeriden dışarı bağlantı açılabilir, dışarıdan içeri açılamaz.

Timeout'lar ve bağlantı havuzları

Bir HTTP çağrısında en az üç ayrı süre vardır: connect timeout (TCP ve TLS bağlantısı kurulamıyor), read/response timeout (bağlantı var ama cevap gelmiyor) ve havuzdan bağlantı alma timeout'u (havuz dolu, sıra bekleniyor). Hiçbirinin sonsuz bırakılmaması gerekir: yavaş bir bağımlılık thread'leri tutar, thread'ler tükenir ve hata zincirleme yayılır (bkz. Kitap Bölüm 14). Bağlantı havuzu (HikariCP, Apache HttpClient, Reactor Netty) el sıkışma maliyetini bir kez öder; havuz boyutu ve bekleme süresi, yük altında davranışı doğrudan belirler.