Her Yazılım Geliştiricinin Bilmesi Gereken Ağ Temelleri

Distributed sistemlerdeki gizemli timeout’lar, yavaş API’lar ve TLS hataları neredeyse her zaman uygulama sorunu gibi görünen ağ sorunlarıdır. Geliştiriciler TCP, DNS ve HTTP’nin çalışma modelinden yoksun olduğunda teşhis yanlış katmanda takılır, düzeltmeler ise tahmine dayalı kalır.

Aşağıdaki kavramlar backend geliştirmede ve production troubleshooting’inde en sık karşılaşılanlar: protokoller, bağlantı yaşam döngüsü, debugging araçları ve güvenlik temelleri. Her başlık kavramın ne olduğunu, ne zaman önem kazandığını ve hangi komutun cevabı verdiğini anlatıyor.

Ağ Bilgisi Nerede İşe Yarar#

Mükemmel uygulama kodu bile, verinin client ile server arasında nasıl hareket ettiği anlaşılmadığında yetersiz kalır. Geliştiriciler şu konularda zorlanır:

• Gizemli timeout’ları debug etme - DNS mi? TCP handshake mi? SSL negotiation mı? Uygulama logiği mi?
• Performans optimizasyonu - API’n neden yavaş? Latency mi, bandwidth mi, yoksa connection overhead mı?
• Güvenlik kararları - TLS, sertifikalar ve network güvenliğini anlamak bilinçli seçimler yapmana yardımcı olur
• Altyapı tasarımı - Load balancing, CDN konfigürasyonu ve servis iletişim patternleri
• Production olayları - Network sorunları genellikle uygulama sorunları gibi görünür

Ağ Katmanları ve Modeller#

OSI Modeli#

OSI (Open Systems Interconnection) modeli networking’i yedi katmana ayırır. Tüm katmanları ezberlemene gerek yok, ama konsepti anlamak troubleshooting’e yardımcı olur:

Katman 7: Application  (HTTP, FTP, SMTP)
Katman 6: Presentation (SSL/TLS, encryption)
Katman 5: Session  (connection management)
Katman 4: Transport  (TCP, UDP)
Katman 3: Network  (IP, routing)
Katman 2: Data Link  (Ethernet, MAC adresleri)
Katman 1: Physical  (kablolar, sinyaller)

Debug ederken bir sorunun hangi katmanda olduğunu bilmek zaman kazandırır: DNS sorunları Katman 7, routing problemleri Katman 3, fiziksel bağlantı ise Katman 1’dir.

TCP/IP Modeli#

Pratikte kullandığımız model OSI’yi dört katmana indirger:

Application Layer  (HTTP, DNS, SSH)
Transport Layer  (TCP, UDP)
Internet Layer  (IP, ICMP)
Link Layer  (Ethernet, Wi-Fi)

Geliştirici troubleshooting’i çoğunlukla Application ve Transport katmanlarında olur. IP’yi anlamak routing sorunlarında yardımcı olur, Link layer sorunları genellikle network admin müdahalesi gerektirir.

Temel Protokoller#

HTTP/HTTPS#

HTTP (Hypertext Transfer Protocol) web iletişiminin temelidir. Client’ların request gönderip server’ların response döndüğü bir request-response protokolü.

Temel özellikler:

• Stateless (her request bağımsız)
• Text tabanlı protokol
• Metodlar: GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD
• Status kodları: 2xx (başarı), 3xx (redirect), 4xx (client hatası), 5xx (server hatası)

HTTPS, HTTP üzerine SSL/TLS şifreleme ekler. ‘S’, verinin transit sırasında şifrelendiği anlamına gelir.

HTTPS aslında aynı anda üç garanti sağlar: şifreleme veriyi gizli tutar, authentication doğru server’la konuştuğunu kanıtlar, integrity ise verinin transit sırasında değiştirilmediğini gösterir.

Temel bir HTTP request şöyle görünür:

# Basit GET request
curl -v https://api.example.com/users

# JSON body ile POST
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Ahmet", "email": "ahmet@example.com"}'

# Response header'ları gör
curl -I https://api.example.com/health

API’ler, web uygulamaları ve RESTful servisler asıl kullanım alanı; internet üzerinden her şey için HTTPS default olmalı.

HTTP/2 ve HTTP/3#

HTTP/2, HTTP/1.1’i şu özelliklerle geliştirir:

• Multiplexing (tek connection üzerinden çoklu request’ler)
• Header compression
• Server push
• Binary protokol (text tabanlı değil)

HTTP/3, TCP yerine QUIC kullanır:

• Daha hızlı connection kurulumu
• Packet loss’u daha iyi handle eder
• UDP üzerine kurulu, reliability eklenmiş

HTTP/2, birçok resource’u olan websiteler için latency’yi önemli ölçüde azaltır, HTTP/3 ise packet loss olan mobil networklerde parlıyor. HTTP/2 ayrıca HTTPS gerektirir; browser’lar plain HTTP üzerinden onu negotiate etmez.

TCP vs UDP#

TCP (Transmission Control Protocol):

• Connection-oriented (veri transferinden önce handshake)
• Reliable (delivery ve order garanti eder)
• Flow control ve congestion control

UDP (User Datagram Protocol):

• Connectionless (fire and forget)
• Unreliable (delivery garantisi yok)
• Ordering garantisi yok

HTTP/HTTPS trafiği, database bağlantıları ve dosya transferleri delivery’nin garanti edilmesi gerektiği için TCP’ye ihtiyaç duyar. UDP ise kayıp bir packet’in onu garanti etmenin overhead’inden daha ucuz olduğu her yerde devreye girer: video streaming (kayıp bir frame fark edilmez), gaming (mükemmel doğruluk yerine hız), DNS sorguları (client sadece retry yapabilir), real-time metrikler (bir data point kaybetmek önemli değildir).

Üç yönlü handshake, ağ üzerinde şöyle görünür:

TCP retransmission’lar mı görüyorsun? Network congestion, packet loss veya firewall sorunlarını kontrol et.

WebSocket#

WebSocket, tek bir TCP connection üzerinden full-duplex iletişim sağlar. HTTP’nin request-response modelinin aksine, bir HTTP upgrade request olarak başlar ve ardından real-time, iki yönlü mesajlar için kalıcı, düşük overhead’li bir kanal açık tutar; chat uygulamaları, canlı bildirimler, real-time dashboard’lar, işbirlikçi düzenleme ve gaming bu yüzden ona yönelir. Her iki taraf da bir request beklemeden veri gönderebilir.

Node.js’te server ve client:

import WebSocket from 'ws';

// Server
const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws) => {
  console.log('Client bağlandı');

  ws.on('message', (message) => {
    console.log('Alındı:', message);
    // Tüm client'lara broadcast
    wss.clients.forEach((client) => {
      if (client.readyState === WebSocket.OPEN) {
        client.send(message);
      }
    });
  });

  ws.on('close', () => {
    console.log('Client bağlantısı kesildi');
  });
});

// Client
const ws = new WebSocket('ws://localhost:8080');

ws.on('open', () => {
  ws.send('Merhaba Server!');
});

ws.on('message', (data) => {
  console.log('Alındı:', data);
});

Proxy’ler ve load balancer’lar WebSocket bağlantılarını genellikle idle timeout sonrası kapatır, bu yüzden bağlantıyı canlı tutan şey bir heartbeat/ping-pong değişimidir.

gRPC#

gRPC, HTTP/2 ve Protocol Buffers kullanan modern bir RPC framework’ü; özellikle microservice iletişimi için popüler. Verimli bir binary protokol, Protocol Buffers sayesinde strongly typed, üç yönde de streaming’i destekler (client, server, bi-directional), .proto dosyalarından kod üretir ve load balancing ile retry’ları hazır sunar; bu da onu yüksek performanslı API’ler, çok dil desteği olan polyglot ortamlar ve streaming data için de uygun kılar.

Minimal bir .proto tanımı:

syntax = "proto3";

service UserService {
  rpc GetUser (GetUserRequest) returns (User);
  rpc ListUsers (ListUsersRequest) returns (stream User);
}

message GetUserRequest {
  string user_id = 1;
}

message User {
  string id = 1;
  string name = 2;
  string email = 3;
}

gRPC’nin zorlandığı yerler: browser client’lar (sınırlı destek), public-facing API’ler (REST daha evrensel), Protocol Buffers’a aşina olmayan takımlar.

DNS ve Ad Çözümleme#

DNS Nasıl Çalışır#

DNS (Domain Name System), insan tarafından okunabilir domain isimlerini IP adreslerine çevirir. Distributed, hiyerarşik bir sistem.

DNS sorgu akışı:

DNS kayıt tipleri:

• A: Domain’i IPv4 adresine map eder
• AAAA: Domain’i IPv6 adresine map eder
• CNAME: Başka bir domain’e alias
• MX: Mail server kayıtları
• TXT: Text kayıtları (genellikle doğrulama, SPF, DKIM için)
• NS: Nameserver kayıtları
• SOA: Start of Authority (zone bilgisi)

Troubleshooting için yaygın dig komutları:

# Temel DNS lookup
dig example.com

# Belirli kayıt tipini sorgula
dig example.com AAAA

# Belirli DNS server kullan
dig @8.8.8.8 example.com

# DNS resolution path'ini trace et
dig +trace example.com

# Reverse DNS lookup (IP'den domain'e)
dig -x 192.0.2.1

# Sadece kısa cevap
dig +short example.com

DNS nerede ters gider:

• DNS caching: DNS değiştirildi ama hala eski IP resolve ediliyor? TTL’i (Time To Live) kontrol et
• DNS propagation: Değişikliklerin globally yayılması 24-48 saat alabilir
• Local cache: Uygulama DNS sonuçlarını cache edebilir (DNS client ayarlarını kontrol et)
• Split-horizon DNS: İç ve dış DNS farklı sonuçlar dönüyor

DNS hataları genellikle sessizdir: uygulama DNS bozukken stale cache değerini kullanmaya devam edebilir ve cache expire olana kadar sorunu maskeler.

DNS TTL#

TTL (Time To Live), resolver’lara bir DNS kaydını ne kadar süre cache edeceklerini söyler. Saniye cinsinden ölçülür.

Strateji:

• Uzun TTL (saat/gün): Stabil altyapı, DNS yükünü azalt
• Kısa TTL (dakika): Planlı değişikliklerden önce daha hızlı cutover için
• Denge: 300-3600 saniye (5 dakika - 1 saat) çoğu durum için işe yarar

Pre-migration pattern:

# Migration'dan 1 hafta önce: TTL'i 300 saniyeye düşür
# Migration günü: DNS kayıtlarını değiştir
# Migration'dan 1 hafta sonra: TTL'i tekrar 3600+ saniyeye yükselt

IP Adresleme ve Routing#

IPv4 Adresleme#

IPv4 adresi: Noktalarla ayrılmış dört oktet (0-255) olarak yazılan 32-bit sayı.

Örnek: 192.168.1.100

Özel aralıklar:

• Private adresler (internet’te routable değil):
  • 10.0.0.0/8 (10.0.0.0 - 10.255.255.255)
  • 172.16.0.0/12 (172.16.0.0 - 172.31.255.255)
  • 192.168.0.0/16 (192.168.0.0 - 192.168.255.255)
• Loopback: 127.0.0.0/8 (localhost)
• Link-local: 169.254.0.0/16 (DHCP fail olduğunda auto-configuration)

CIDR notasyonu: 192.168.1.0/24, ilk 24 bit’in network, son 8 bit’in host olduğu anlamına gelir.

• /24 = 256 adres (254 kullanılabilir, 2 rezerve)
• /16 = 65,536 adres
• /8 = 16,777,216 adres

Kendi IP adresini kontrol etmek:

# Public IP
curl ifconfig.me

# Local IP (Linux/Mac)
ifconfig | grep "inet " | grep -v 127.0.0.1

# Local IP (Linux)
ip addr show

IPv6 Adresleme#

IPv6 adresi: Dört hexadecimal digit’ten oluşan sekiz grup olarak yazılan 128-bit sayı.

Örnek: 2001:0db8:85a3:0000:0000:8a2e:0370:7334

Kısaltılmış: 2001:db8:85a3::8a2e:370:7334 (ardışık sıfırlar :: ile değiştirilebilir)

IPv4 adresleri tükendiği için cloud provider’lar giderek daha fazla IPv6 kullanıyor; modern uygulamalar ikisini de desteklemeli.

Birçok araç default olarak IPv4 kullanır, bu yüzden IPv6 bağlantısını açıkça test etmek gerekir.

NAT (Network Address Translation)#

NAT, private network’teki birden fazla cihazın tek bir public IP adresini paylaşmasına izin verir. Ev router’ın yaptığı bu.

Nerede karşına çıkar:

• Private vs public IP’leri anlamak
• Bağlantı sorunlarını debug etme (NAT traversal)
• Güvenlik etkileri (NAT temel firewalling sağlar)
• Cloud ortamlar (VPC networking, NAT gateway’ler)

AWS örneği: Private subnet instance’ları, internet’ten erişilemezken internet’e erişmek için NAT Gateway kullanır.

Port’lar ve Yaygın Servisler#

Port Numaraları#

Port’lar, bir host üzerindeki belirli servisleri tanımlar. Aralık: 0-65535

Port aralıkları:

• Well-known port’lar (0-1023): Yaygın servisler için rezerve, root/admin gerektirir
• Registered port’lar (1024-49151): Uygulamalar tarafından kullanılır
• Dynamic/Private port’lar (49152-65535): Client bağlantıları için geçici port’lar

Bilmekte fayda olan port’lar:

Port	Protokol	Servis
20/21	FTP	File Transfer (data/control)
22	SSH	Secure Shell
25	SMTP	Email gönderme
53	DNS	Domain Name System
80	HTTP	Web trafiği
443	HTTPS	Güvenli web trafiği
465/587	SMTP	Güvenli email (SSL/TLS)
3000	-	Yaygın dev server (Node.js)
3306	MySQL	Database
5432	PostgreSQL	Database
6379	Redis	Cache/database
8080	HTTP	Alternatif HTTP (dev/proxy)
8443	HTTPS	Alternatif HTTPS
27017	MongoDB	Database

Bir port’u neyin kullandığını kontrol eden komutlar:

# Port dinliyor mu kontrol et (Linux)
netstat -tuln | grep :443

# Port'u ne kullanıyor görüntüle
lsof -i :3000

# Port açık mı test et
nc -zv example.com 443

# Timeout ile bağlantı test et
timeout 5 bash -c 'cat < /dev/null > /dev/tcp/example.com/443' && echo "Açık" || echo "Kapalı"

Port zaten kullanımda: process’i bul ve kill et:

# Port 3000 kullanan process'i bul
lsof -ti:3000

# Port 3000 kullanan process'i kill et
kill $(lsof -ti:3000)

# Gerekirse zorla kill et
kill -9 $(lsof -ti:3000)

Firewall’lar ve Port Güvenliği#

Firewall’lar, hangi port’ların erişilebilir olduğunu kontrol eder. AWS/Azure’daki security group’lar esasen firewall’lardır.

Best practice’ler:

• Sadece gerekli port’ları aç
• Mümkün olduğunda specific source IP’ler kullan (0.0.0.0/0 değil)
• İç vs dış trafik için farklı kurallar
• Her port’un neden açık olduğunu dokümante et

Bir API aniden erişilemez hale geldiğinde, uygulama koduna dalmadan önce firewall kurallarını kontrol et; sadece bir security group kuralının trafiği bloklaması “bozuk” kodu debug ederken saatleri götürebilir.

Load Balancing ve Trafik Dağıtımı#

Load Balancer Tipleri#

Load balancer’lar, reliability ve scalability için trafiği birden fazla server’a dağıtır.

Layer 4 (Transport Layer) Load Balancing:

• IP adresi ve port’a göre route eder
• Hızlı (application layer inspection yok)
• Protocol-agnostic (herhangi bir TCP/UDP trafiği ile çalışır)
• Yüksek throughput gereksinimleri, HTTP olmayan protokoller, basit round-robin dağıtımı ve sticky session’ların başka yerde handle edildiği WebSocket trafiği için uygun
• Örnekler: AWS Network Load Balancer, TCP modunda HAProxy

Layer 7 (Application Layer) Load Balancing:

• HTTP header’ları, URL path, cookie’lere göre route eder
• Content tabanlı routing
• SSL termination
• Path tabanlı routing (/api/* bir servise, /admin/* diğerine), tek load balancer üzerinde birden fazla domain’i kapsayan host tabanlı routing ve request/header modifikasyonu için uygun
• Örnekler: AWS Application Load Balancer, NGINX, HTTP modunda HAProxy

Load Balancing Algoritmaları#

Round Robin: Request’leri sırayla eşit dağıt. Basit ama server yükünü hesaba katmaz.

Least Connections: En az aktif bağlantılı server’a gönder. Uzun ömürlü bağlantılar için iyi.

IP Hash: Client IP’sine göre route et. Aynı client her zaman aynı server’a gider (sticky session olmadan session affinity).

Weighted: Server’lara ağırlık ata (farklı kapasite için). Migration’lar veya canary deployment’lar için kullanışlı.

Blue/Green deployment:

Load Balancer Konfigürasyonu:
- Blue environment: weight 100
- Green environment: weight 0

Green'e deploy et, test et, sonra:
- Blue: 90, Green: 10 (canary)
- Blue: 50, Green: 50 (kademeli geçiş)
- Blue: 0, Green: 100 (tam cutover)

Health Check’ler#

Health check’ler, server kullanılabilirliğini doğrular. Load balancer, unhealthy server’ları rotation’dan çıkarır.

Health check stratejileri:

• TCP check: Port’a bağlanabiliyor mu? (minimal check)
• HTTP check: 200 OK dönüyor mu? (application-aware)
• Deep health check: Database’i sorgula, dependency’leri kontrol et

Implementation örneği:

// Basit health check endpoint
app.get('/health', (req, res) => {
  res.status(200).json({ status: 'ok' });
});

// Deep health check
app.get('/health/deep', async (req, res) => {
  try {
    // Database kontrol et
    await db.query('SELECT 1');

    // Redis kontrol et
    await redis.ping();

    // Kritik dependency'leri kontrol et
    const apiReachable = await checkExternalAPI();

    if (apiReachable) {
      res.status(200).json({
        status: 'healthy',
        dependencies: {
          database: 'ok',
          cache: 'ok',
          externalAPI: 'ok'
        }
      });
    } else {
      throw new Error('Harici API erişilemiyor');
    }
  } catch (error) {
    res.status(503).json({
      status: 'unhealthy',
      error: error.message
    });
  }
});

Health check başarısızlıkları cascading sorunlara neden olur: çok agresif bir check healthy server’ları unhealthy işaretler, çok lenient bir check ise unhealthy server’ları rotation’da bırakır.

Content Delivery Network’ler (CDN)#

CDN Temelleri#

CDN, içeriği coğrafi olarak dağıtılmış edge server’lar arasında dağıtır. Client’lar daha hızlı delivery için en yakın edge location’a bağlanır.

Temel kavramlar:

• Origin: Kendi orijinal server’ın
• Edge location: CDN’in dağıtılmış server’ları
• Cache: Edge location’larda saklanan içerik
• TTL: İçeriğin ne kadar süre cache’de kalacağı
• Cache invalidation: Stale içeriği kaldırma

Neyi cache’le:

• Statik asset’ler (resimler, CSS, JavaScript)
• Nadir değişen içerik
• Public erişilebilir resource’lar

Neyi cache’leme:

• Dinamik, kullanıcıya özel içerik
• Authenticated API response’ları
• Real-time data

Cache Control Header’ları#

HTTP header’larıyla caching davranışını kontrol et:

// 1 yıl cache (fingerprint'li immutable asset'ler)
res.setHeader('Cache-Control', 'public, max-age=31536000, immutable');

// 1 saat cache
res.setHeader('Cache-Control', 'public, max-age=3600');

// Hiç cache'leme
res.setHeader('Cache-Control', 'no-store, no-cache, must-revalidate');

// Cache et ama revalidate et
res.setHeader('Cache-Control', 'public, max-age=0, must-revalidate');

Cache-Control direktifleri:

• public: Herhangi bir cache tarafından cache’lenebilir
• private: Sadece client browser cache’leyebilir (CDN değil)
• no-cache: Cache’lenmiş versiyon kullanmadan önce origin ile revalidate et
• no-store: Hiç cache’leme
• max-age: Saniye cinsinden cache ömrü
• immutable: İçerik asla değişmeyecek (agresif caching)

Asset fingerprinting:

app-abc123.js  # Filename'de hash, sonsuza kadar cache
app.js  # Hash yok, kısa cache veya no-cache

CDN Tuzakları#

Sorun: Yeni versiyon deploy edildi ama kullanıcılar eski cache’lenmiş içeriği görüyor.

Çözümler:

• Versioned filename’ler kullan (app.v2.js veya app.abc123.js)
• CDN cache’ini invalidate et (para tutabilir, zaman alır)
• Deployment öncesi TTL’i düşür

Sorun: CDN authenticated içeriği cache’liyor.

Çözüm: Kullanıcıya özel içerik için Cache-Control: private kullan veya Vary: Authorization header ekle.

SSL/TLS ve Sertifikalar#

SSL/TLS Nasıl Çalışır#

SSL/TLS, network iletişimi için encryption, authentication ve integrity sağlar.

TLS handshake süreci (basitleştirilmiş):

1. Client desteklediği cipher suite’leri ve TLS versiyonunu gönderir
2. Server seçilen cipher’ı ve sertifikasını döner
3. Client sertifikayı doğrular (güvenilir CA tarafından imzalanmış)
4. Client ve server key alışverişi yapar ve şifreli bağlantı kurar
5. Uygulama verisi şifreli kanal üzerinden akar

Sertifika bileşenleri:

• Public key: Server’a gönderilen veriyi şifrelemek için kullanılır
• Private key: Server tarafından veriyi çözmek için kullanılır (gizli tutulur)
• Certificate Authority (CA): Sertifikaları imzalayan güvenilir kuruluş
• Certificate chain: Senin sertifikan → Intermediate CA → Root CA

Sertifika Tipleri#

Domain Validation (DV): Domain’i kontrol ettiğini kanıtlar. Otomatik, hızlı, ücretsiz (Let’s Encrypt).

Organization Validation (OV): Organizasyon doğrulamasını içerir. Daha fazla güven, daha pahalı.

Extended Validation (EV): En yüksek doğrulama seviyesi. Browser’da organizasyon adını gösterir. En pahalı.

Wildcard: Tüm subdomain’leri kapsar (*.example.com). Kullanışlı ama ele geçirilirse daha yüksek güvenlik riski.

Multi-domain (SAN): Tek sertifikada birden fazla spesifik domain’i kapsar.

Pratik Sertifika Yönetimi#

Let’s Encrypt örneği - Ücretsiz otomatik sertifikalar:

# Certbot kur
sudo apt-get install certbot

# Sertifika al (otomatik)
sudo certbot certonly --standalone -d example.com -d www.example.com

# Otomatik yenileme (cron'a ekle)
0 0 * * * certbot renew --quiet

Sertifikada çıkabilecek sorunlar:

Süresi dolmuş sertifika:

# Sertifika süresini kontrol et
echo | openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -dates

Sertifika zinciri sorunları:

# Sertifika zincirini doğrula
openssl s_client -connect example.com:443 -showcerts

# Belirli CA bundle ile test et
curl --cacert /path/to/ca-bundle.crt https://example.com

Sertifikada yanlış domain:

# Sertifika subject'ini kontrol et
echo | openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -subject -ext subjectAltName

Self-signed sertifikalar: Development için iyi, production için asla. Browser’lar uyarı gösterir.

TLS Best Practice’leri#

• TLS 1.2 veya 1.3 kullan (TLS 1.0/1.1 deprecated)
• Güçlü cipher suite’ler (RC4, DES gibi zayıf cipher’lardan kaçın)
• Certificate pinning mobil uygulamalar için (opsiyonel, güvenlik ekler)
• Otomatik yenileme (sertifikalar expire olur, Let’s Encrypt için genellikle 90 gün)
• HSTS header browser’lara sadece HTTPS kullanmalarını söyler

// HSTS'i etkinleştir
res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');

Ağ Güvenliğinin Temelleri#

Firewall’lar#

Firewall, kurallara göre network trafiğini filtreler. Farklı katmanlarda çalışabilir.

Tipler:

• Packet filtering: Katman 3/4 (IP, port, protokol)
• Stateful inspection: Bağlantı durumunu takip eder
• Application firewall: Katman 7 (HTTP vb. inspect eder)
• WAF (Web Application Firewall): Web saldırılarına karşı korur (SQL injection, XSS)

Cloud firewall eşdeğerleri:

• AWS: Security Groups, Network ACL’ler, AWS WAF
• Azure: Network Security Groups, Application Gateway WAF
• GCP: VPC Firewall Rules, Cloud Armor

Best practice: Defense in depth. Çoklu güvenlik katmanları.

VPN (Virtual Private Network)#

VPN, public network üzerinden şifreli tünel oluşturarak, private network’teymişsin gibi görünmeni sağlar.

Kullanım durumları:

• Kurumsal network’e güvenli uzaktan erişim
• Coğrafi olarak kısıtlanmış servislere erişim
• Güvenilmeyen networklerde trafiği şifreleme (kafe Wi-Fi’ı)

Tipler:

• Site-to-Site VPN: İki network’ü bağlar (örn. ofis ile AWS VPC)
• Remote Access VPN: Bireysel kullanıcılar network’e bağlanır
• SSL VPN: Browser tabanlı, client gerekmez
• IPsec VPN: Geleneksel, client yazılımı gerektirir

Geliştirici perspektifi: Production sistemlere uzaktan erişiyorsan muhtemelen VPN kullanıyorsun. Bağlantı gereksinimlerini ve troubleshooting’i anla.

Yaygın Saldırı Vektörleri#

DDoS (Distributed Denial of Service): Server’ı trafik ile bunaltma; CDN, rate limiting ve auto-scaling bunu absorbe eder.

Man-in-the-Middle: İletişimi kesme; TLS/SSL ve sertifika doğrulaması bu açığı kapatır.

DNS Hijacking: DNS’i kötü niyetli server’lara yönlendirme. Önlem: DNSSEC, güvenilir DNS provider’lar.

Port Scanning: Açık port’ları keşfetme. Önlem: Gereksiz port’ları kapat, firewall kullan.

SQL Injection: Input’larda kötü niyetli SQL; parameterized query’ler ve input validasyonu bunu durdurur.

XSS (Cross-Site Scripting): Kötü niyetli script enjekte etme. Önlem: Output encoding, CSP header’ları.

Temel Ağ Araçları#

ping#

Amaç: Bağlantıyı test et ve latency’yi ölç.

# Temel ping
ping example.com

# 5 packet ile sınırla
ping -c 5 example.com

# Flood ping (test için, root gerektirir)
sudo ping -f example.com

Ne söyler:

• Host’a ulaşabiliyor musun?
• Latency ne?
• Packet loss var mı?

Örnek output:

64 bytes from example.com (93.184.216.34): icmp_seq=1 ttl=56 time=15.2 ms

• time=15.2 ms: Round-trip latency
• ttl=56: Time to live (kalan hop sayısı)

Tuzak: Bazı server’lar ICMP’yi (ping) bloklar. Response olmayışı her zaman server’ın down olduğu anlamına gelmez.

traceroute / tracepath#

Amaç: Packet’lerin destination’a giderken aldığı yolu göster.

# Destination'a route'u trace et
traceroute example.com

# Alternatif (root gerektirmez)
tracepath example.com

# UDP yerine ICMP ile trace et
traceroute -I example.com

Ne söyler:

• Destination’a network yolu
• Latency nerede ekleniyor
• Packet’ler nerede drop ediliyor

Sonuçları yorumlama:

 1  192.168.1.1 (192.168.1.1)  1.234 ms
 2  10.0.0.1 (10.0.0.1)  5.678 ms
 3  * * *
 4  example.com (93.184.216.34)  15.2 ms

• Her satır bir hop (router)
• * * *, hop response vermedi (genellikle firewall’lanmış)
• Latency’de büyük sıçrama bottleneck gösterir

curl#

curl, çeşitli protokoller kullanarak veri transfer eder ve API testi için olmazsa olmazdır.

# GET request
curl https://api.example.com/users

# JSON ile POST
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Ahmet"}'

# Redirect'leri takip et
curl -L https://example.com

# Response header'larını göster
curl -i https://example.com

# Request/response header'larını göster
curl -v https://example.com

# Response'u dosyaya kaydet
curl -o output.html https://example.com

# Progress bar ile indir
curl -# -O https://example.com/dosya.zip

# Belirli IP ile test et (DNS'i bypass et)
curl --resolve example.com:443:93.184.216.34 https://example.com

# Custom header'lar
curl -H "Authorization: Bearer token123" https://api.example.com

# Zaman breakdown'unu ölç
curl -w "@curl-format.txt" -o /dev/null -s https://example.com

curl timing format dosyası (curl-format.txt):

time_namelookup:  %{time_namelookup}s\n
time_connect:  %{time_connect}s\n
time_appconnect:  %{time_appconnect}s\n
time_pretransfer: %{time_pretransfer}s\n
time_redirect:  %{time_redirect}s\n
time_starttransfer: %{time_starttransfer}s\n
time_total:  %{time_total}s\n

netstat / ss#

Amaç: Network istatistikleri - aktif bağlantılar, dinleyen port’lar, routing table’ları.

# Tüm dinleyen TCP port'ları göster
netstat -tuln

# Process bilgisiyle tüm bağlantıları göster
sudo netstat -tulnp

# Routing table'ı göster
netstat -r

# Modern alternatif (daha hızlı)
ss -tuln

# Belirli portu göster
ss -tuln | grep :443

# State'e göre bağlantıları göster
ss -t state established

Göreceğin state’ler:

• LISTEN: Bağlantıları bekliyor
• ESTABLISHED: Aktif bağlantı
• TIME_WAIT: Bağlantı kapatıldı, closure’ı garantilemek için bekliyor
• CLOSE_WAIT: Uzak taraf kapattı, lokal taraf henüz kapatmadı

Debugging senaryosu: Çok fazla TIME_WAIT bağlantısı mı? TCP ayarlarını veya connection pooling’i ayarlamak gerekebilir.

nslookup / dig#

Amaç: DNS sorguları ve troubleshooting.

# Temel lookup
nslookup example.com

# Belirli DNS server'ı sorgula
nslookup example.com 8.8.8.8

# Dig (daha detaylı)
dig example.com

# Belirli kayıt tipini sorgula
dig example.com AAAA

# Kısa cevap
dig +short example.com

# DNS resolution'ı trace et
dig +trace example.com

# Reverse lookup
dig -x 93.184.216.34

tcpdump / wireshark#

Amaç: Packet capture ve analiz. Network sorunları için ultimate debugging aracı.

# Interface'de capture (root gerektirir)
sudo tcpdump -i eth0

# Belirli port capture et
sudo tcpdump -i eth0 port 443

# Dosyaya kaydet
sudo tcpdump -i eth0 -w capture.pcap

# Dosyadan oku
tcpdump -r capture.pcap

# Belirli host capture et
sudo tcpdump -i eth0 host example.com

# Sadece HTTP trafiği
sudo tcpdump -i eth0 -A port 80

tcpdump, başka hiçbir şey yardımcı olmadığında başvurulacak son çaredir. Her packet’i göreceksin, bu bunaltıcı ama bazen gerekli.

Wireshark: tcpdump’ın GUI versiyonu, güçlü filtreleme ve analizle. Kaydedilmiş packet capture’ların deep inspection’ı için kullan.

nc (netcat)#

nc, TCP/UDP bağlantıları için İsviçre çakısıdır.

# Port açık mı test et
nc -zv example.com 443

# Port'ta dinle (basit server)
nc -l 8080

# Bağlan ve veri gönder
echo "Merhaba" | nc example.com 80

# İki makine arasında chat
# Makine 1: nc -l 8080
# Makine 2: nc makine1-ip 8080

# Basit HTTP request
printf "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n" | nc example.com 80

telnet#

telnet, TCP bağlantılarını şifrelemeden test eder; protokolleri doğrudan debug etmek için kullanışlıdır.

# SMTP test et
telnet mail.example.com 25

# HTTP test et
telnet example.com 80
# Sonra yaz: GET / HTTP/1.1 [Enter]
#  Host: example.com [Enter]
#  [Enter]

# Port açık mı test et
telnet example.com 443

Not: Çoğu sistem artık default olarak telnet içermiyor. Bunun yerine nc kullan.

Pratik Debugging Senaryoları#

Senaryo 1: API Timeout#

Sorun: API call’ları rastgele timeout oluyor.

Debugging yaklaşımı:

# 1. Server erişilebilir mi kontrol et
ping api.example.com

# 2. DNS resolution süresini kontrol et
time dig api.example.com

# 3. Bağlantıyı test et
curl -w "@curl-format.txt" -o /dev/null https://api.example.com

# 4. Farklı lokasyondan kontrol et
# Network path sorunu mu yoksa server sorunu mu?

# 5. Aktif bağlantıları monitor et
watch -n 1 'ss -s'

# 6. Packet loss kontrol et
ping -c 100 api.example.com | tail -n 3

Temel çıkarım: 3. adımdaki zaman dökümü, sırada hangi katmana bakman gerektiğini söyler. Yavaş time_namelookup DNS’i, yavaş time_appconnect TLS’i, yavaş time_starttransfer ise tekrar uygulamayı işaret eder.

Senaryo 2: SSL Sertifika Hatası#

Sorun: HTTPS bağlantısı sertifika hatasıyla başarısız oluyor.

Debugging yaklaşımı:

# 1. Sertifika detaylarını kontrol et
echo | openssl s_client -connect example.com:443 -servername example.com

# 2. Süreyi kontrol et
echo | openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -dates

# 3. Sertifika zincirini doğrula
curl -v https://example.com

# 4. Sertifika domain ile eşleşiyor mu kontrol et
echo | openssl s_client -connect example.com:443 2>/dev/null | \
  openssl x509 -noout -text | grep DNS:

# 5. Custom CA bundle ile test et (private CA kullanıyorsan)
curl --cacert /path/to/ca.crt https://example.com

Senaryo 3: DNS Resolution Sorunları#

Sorun: Domain yanlış IP’ye resolve ediliyor veya hiç edilmiyor.

Debugging yaklaşımı:

# 1. Sisteminin ne resolve ettiğini kontrol et
dig example.com

# 2. Farklı DNS server'larla kontrol et
dig @8.8.8.8 example.com  # Google DNS
dig @1.1.1.1 example.com  # Cloudflare DNS
dig @8.8.4.4 example.com  # Google DNS backup

# 3. Local DNS cache'i temizle (Mac)
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# 4. Local DNS cache'i temizle (Linux)
sudo systemd-resolve --flush-caches

# 5. DNS propagation sorunu mu kontrol et
# Online araçlar kullan: whatsmydns.net

# 6. Authoritative server'da DNS kayıtlarını doğrula
dig +trace example.com

DNS sorunları genellikle ara sıra hatalar olarak görünür, çünkü birden fazla seviyede caching var: uygulama, OS, resolver, TTL.

Senaryo 4: Port Zaten Kullanımda#

Sorun: Server başlatılamıyor - port zaten kullanımda.

Debugging yaklaşımı:

# 1. Port'u ne kullanıyor bul
lsof -i :3000

# 2. Process'i kill et
kill $(lsof -ti:3000)

# 3. Kill işe yaramazsa
kill -9 $(lsof -ti:3000)

# 4. Port gerçekten boş mu kontrol et
netstat -tuln | grep :3000

# 5. Alternatif - farklı port kullan veya port reuse konfigüre et
# Node.js'te:
# server.listen(3000, { reuseAddr: true })

Senaryo 5: Yüksek Latency#

Sorun: Uygulama yavaş hissettiriyor, latency nereden geliyor debug et.

curl ile ölçme:

# curl timing formatı oluştur
cat > curl-format.txt << 'EOF'
\n
    time_namelookup:  %{time_namelookup}s\n
       time_connect:  %{time_connect}s\n
    time_appconnect:  %{time_appconnect}s\n
   time_pretransfer:  %{time_pretransfer}s\n
      time_redirect:  %{time_redirect}s\n
 time_starttransfer:  %{time_starttransfer}s\n
                    ----------\n
         time_total:  %{time_total}s\n
\n
EOF

# Request timing'ini ölç
curl -w "@curl-format.txt" -o /dev/null -s https://api.example.com

Sonuçları yorumlama:

• Yüksek time_namelookup: DNS yavaş
• Yüksek time_connect: Network latency veya server response vermiyor
• Yüksek time_appconnect: SSL handshake yavaş
• Yüksek time_starttransfer: Server işleme yavaş
• Diğer süreler düşük ama time_total yüksek: Büyük response body

Varsayılan Debugging Sırası#

Yukarıdan aşağıya ilerle: host’a ulaş, ismi çözümle, TCP handshake’i tamamla, TLS handshake’i tamamla, sonra HTTP response’unu ve süresini oku. curl -w, dig ve ss bu beş kontrolü root yetkisi ya da capture dosyası olmadan saniyeler içinde yapar. Önce bunları elemek önemli, çünkü hangi katmanda olursa olsun bir hata servisin içinden hep aynı biçimde görünür: timeout olarak.

tcpdump’a atlamayı iki durum haklı çıkarır. Birincisi, hızlı araçlar temiz dönmesine rağmen belirtinin sürmesi; bu genellikle uçlar arasında bir yerin trafiği yeniden yazdığı veya düşürdüğü anlamına gelir. İkincisi, hatanın ara sıra oluşması ve tekrarladığı anda capture’ın zaten çalışıyor olması gerekmesi. Packet capture okumak isteyeceğinden çok daha fazla veri üretir.

Olay anının dışında karşılığını veren alışkanlık şu: hangi port’ların açık olduğunu, neden açık olduklarını ve hangi firewall kuralının buna izin verdiğini yazmak.

Kaynaklar#

• HTTP’ye Genel Bakış - MDN Web Docs (yeni sekmede açılır) - HTTP’yi uygulama katmanı protokolü olarak ele alan, istemci-sunucu iletişimi, bağlantılar ve protokol evrimini kapsayan Mozilla’nın kapsamlı rehberi.
• RFC 9110 - HTTP Anlambilimi (yeni sekmede açılır) - İstek yöntemleri, durum kodları, başlık alanları ve içerik müzakeresi dahil HTTP anlambilimini tanımlayan IETF standardı.
• RFC 9293 - İletim Denetim Protokolü (TCP) (yeni sekmede açılır) - RFC 793’ü ve güvenilir, bağlantı yönelimli aktarım protokolüne ilişkin sonraki güncellemeleri birleştiren mevcut IETF TCP standardı.
• DNS Nedir? (yeni sekmede açılır) - Cloudflare Öğrenme Merkezi’nin DNS, etki alanı çözümlemesinin nasıl çalıştığı ve özyinelemeli çözücülerin rolü hakkındaki açıklaması.
• İnternet Protokolü Nedir? (yeni sekmede açılır) - IP adresleme, paket yönlendirme ve IP ile aktarım protokolleri arasındaki ilişkiyi kapsayan Cloudflare’in İnternet Protokolü rehberi.