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

Abstract#

Ağ temellerini anlamak sadece network mühendisleri için değil - her yazılım geliştiricisi için gerekli bir bilgi. Production'da bir sorunu debug ederken, API performansını optimize ederken veya distributed bir sistem tasarlarken, network kavramları sürekli karşına çıkıyor. Bu rehber, backend sistemler geliştirirken ve production sorunlarını çözerken karşılaştığım gerçek dünya senaryoları, yaygın tuzaklar ve debugging durumlarıyla birlikte networking temellerinin pratik bir sözlüğünü sunuyor.

Geliştiriciler Neden Network Bilgisi İhtiyaç Duyar#

Öğrendiğim şey şu: Mükemmel uygulama kodu yazabilirsin, ama verinin client ile server arasında nasıl hareket ettiğini anlamazsan, şu konularda zorlanırsın:

• 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

Distributed sistemlerle çalışmak bana network sorunlarının aslında uygulama sorunları olduğunu öğretti. İkisini birbirinden ayıramazsın.

Network Katmanları & 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)

Neden önemli: Debug ederken, bir sorunun hangi katmanda olduğunu bilmek zaman kazandırır. DNS sorunları Katman 7, routing problemleri Katman 3, ve fiziksel bağlantı 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)

Gerçek dünya bağlamı: 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.

Yaygın tuzak: HTTPS sadece şifreleme değil - aynı zamanda authentication (doğru server'la konuştuğunu kanıtlama) ve integrity (verinin transit sırasında değiştirilmediği) sağlar.

Pratik örnek - HTTP request yapma:

# Basit GET requestcurl -v https://api.example.com/users
# JSON body ile POSTcurl -X POST https://api.example.com/users \  -H "Content-Type: application/json" \  -d '{"name": "Ahmet", "email": "[email protected]"}'
# Response header'ları görcurl -I https://api.example.com/health

Ne zaman kullanılır: API'ler, web uygulamaları, RESTful servisler. 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ş

Gerçek dünya etkisi: HTTP/2, birçok resource'u olan websiteler için latency'yi önemli ölçüde azaltır. HTTP/3, packet loss olan mobil networklerde parlıyor.

Yaygın tuzak: HTTP/2, HTTPS gerektirir. Browser'larda plain HTTP üzerinden kullanamazsın.

TCP vs UDP#

TCP (Transmission Control Protocol):

• Connection-oriented (veri transferinden önce handshake)
• Reliable (delivery ve order garanti eder)
• Flow control ve congestion control
• Yavaş ama güvenilir

UDP (User Datagram Protocol):

• Connectionless (fire and forget)
• Unreliable (delivery garantisi yok)
• Ordering garantisi yok
• Hızlı ama riskli

TCP ne zaman kullanılır:

• HTTP/HTTPS trafiği
• Database bağlantıları
• Dosya transferleri
• Reliability gerektiği her durum

UDP ne zaman kullanılır:

• Video streaming (ara sıra kayıp frame OK)
• Gaming (mükemmel doğruluk yerine hız)
• DNS sorguları (kaybolursa retry yapılabilir)
• Real-time metrikler (bir data point kaybetmek kabul edilebilir)

Pratik örnek - TCP handshake görselleştirmesi:

Yaygın debugging senaryosu: 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'unun aksine, WebSocket bi-directional streaming'e izin verir.

Temel özellikler:

• HTTP upgrade request olarak başlar
• Kalıcı bağlantı
• Message framing için düşük overhead
• Real-time, iki yönlü iletişim

Ne zaman kullanılır:

• Chat uygulamaları
• Canlı bildirimler
• Real-time dashboard'lar
• İşbirlikçi düzenleme
• Gaming

Pratik örnek - Node.js'te WebSocket:

import WebSocket from 'ws';
// Serverconst 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');  });});
// Clientconst ws = new WebSocket('ws://localhost:8080');
ws.on('open', () => {  ws.send('Merhaba Server!');});
ws.on('message', (data) => {  console.log('Alındı:', data);});

Yaygın tuzak: WebSocket bağlantıları, idle timeout'lu proxy'ler veya load balancer'lar tarafından kesilebilir. Bağlantıları canlı tutmak için heartbeat/ping-pong implement et.

gRPC#

gRPC, HTTP/2 ve Protocol Buffers kullanan modern bir RPC framework'ü. Özellikle microservice iletişimi için popüler.

Temel özellikler:

• Binary protokol (verimli)
• Strongly typed (Protocol Buffers)
• Streaming'i destekler (client, server, bi-directional)
• .proto dosyalarından kod üretimi
• Built-in load balancing ve retry'ler

Ne zaman kullanılır:

• Microservice iletişimi
• Yüksek performanslı API'ler
• Polyglot ortamlar (çok dil desteği)
• Streaming data

Pratik örnek - Basit gRPC 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;}

Ne zaman kullanılmaz: Browser client'lar (sınırlı destek), public-facing API'ler (REST daha evrensel), Protocol Buffers'a aşina olmayan takımlar.

DNS & Name Resolution#

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)

Pratik debugging - DNS lookup araçları:

# Temel DNS lookupdig example.com
# Belirli kayıt tipini sorguladig example.com AAAA
# Belirli DNS server kullandig @8.8.8.8 example.com
# DNS resolution path'ini trace etdig +trace example.com
# Reverse DNS lookup (IP'den domain'e)dig -x 192.0.2.1
# Sadece kısa cevapdig +short example.com

Debug ettiğim yaygın sorunlar:

• DNS caching: DNS'i değiştirdim 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

Gerçek dünya tuzağı: DNS hataları genellikle sessiz. Uygulamanda DNS bozukken stale cache değeri kullanılabilir 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 & 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

Pratik örnek - IP'ni kontrol etme:

# Public IPcurl 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)

IPv6 neden önemli: IPv4 adresleri tükendi. Cloud provider'lar giderek daha fazla IPv6 kullanıyor ve modern uygulamalar ikisini de desteklemeli.

Yaygın tuzak: Birçok araç default olarak IPv4 kullanır. IPv6 bağlantısını açıkça test et.

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.

Geliştiriciler neden önemser:

• 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 & 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

Bilmen gereken yaygın port'lar:

Pratik debugging - Port kullanımını kontrol et:

# Port dinliyor mu kontrol et (Linux)netstat -tuln | grep :443
# Port'u ne kullanıyor görüntülelsof -i :3000
# Port açık mı test etnc -zv example.com 443
# Timeout ile bağlantı test ettimeout 5 bash -c 'cat < /dev/null > /dev/tcp/example.com/443' && echo "Açık" || echo "Kapalı"

Yaygın sorun: Port zaten kullanımda. Process'i bul ve kill et:

# Port 3000 kullanan process'i bullsof -ti:3000
# Port 3000 kullanan process'i kill etkill $(lsof -ti:3000)
# Gerekirse zorla kill etkill -9 $(lsof -ti:3000)

Firewall'lar & 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

Gerçek dünya senaryosu: API aniden erişilemiyor. Uygulama koduna dalmadan önce firewall kurallarını kontrol et. "Bozuk" kodu debug etmek için saatler harcadım, oysa sadece bir security group kuralı trafiği blokluyordu.

Load Balancing & Distribution#

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)
• Ö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
• Örnekler: AWS Application Load Balancer, NGINX, HTTP modunda HAProxy

Layer 4 ne zaman kullanılır:

• Yüksek throughput gereksinimleri
• HTTP olmayan protokoller
• Basit round-robin dağıtımı
• Başka yerde handle edilen sticky session'lu WebSocket

Layer 7 ne zaman kullanılır:

• Path tabanlı routing (/api/* bir servise, /admin/* diğerine)
• Host tabanlı routing (tek load balancer'da birden fazla domain)
• SSL offloading
• Request modification/header'lar

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ı.

Gerçek dünya pattern'i - 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 endpointapp.get('/health', (req, res) => {  res.status(200).json({ status: 'ok' });});
// Deep health checkapp.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    });  }});

Yaygın tuzak: Health check başarısızlıkları cascading sorunlara neden olur. Check çok agresifse, healthy server'lar unhealthy işaretlenir. Çok lenient ise, unhealthy server'lar rotation'da kalı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: 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 cacheres.setHeader('Cache-Control', 'public, max-age=3600');
// Cache'lemeres.setHeader('Cache-Control', 'no-store, no-cache, must-revalidate');
// Cache et ama revalidate etres.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)

Gerçek dünya pattern'i - Asset fingerprinting:

app-abc123.js  # Filename'de hash, sonsuza kadar cacheapp.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 & 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 kursudo 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

Yaygın sertifika sorunları:

Süresi dolmuş sertifika:

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

Sertifika zinciri sorunları:

# Sertifika zincirini doğrulaopenssl s_client -connect example.com:443 -showcerts
# Belirli CA bundle ile test etcurl --cacert /path/to/ca-bundle.crt https://example.com

Sertifikada yanlış domain:

# Sertifika subject'ini kontrol etecho | 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ştirres.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');

Network Güvenlik 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. Önlem: CDN, rate limiting, auto-scaling.

Man-in-the-Middle: İletişimi kesme. Önlem: TLS/SSL, sertifika doğrulaması.

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. Önlem: Parameterized query'ler, input validasyonu.

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

Temel Networking Araçları#

ping#

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

# Temel pingping example.com
# 5 packet ile sınırlaping -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ı?

Yaygın 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 ettraceroute example.com
# Alternatif (root gerektirmez)tracepath example.com
# UDP yerine ICMP ile trace ettraceroute -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#

Amaç: Çeşitli protokoller kullanarak veri transferi. API testi için olmazsa olmaz.

# GET requestcurl https://api.example.com/users
# JSON ile POSTcurl -X POST https://api.example.com/users \  -H "Content-Type: application/json" \  -d '{"name": "Ahmet"}'
# Redirect'leri takip etcurl -L https://example.com
# Response header'larını göstercurl -i https://example.com
# Request/response header'larını göstercurl -v https://example.com
# Response'u dosyaya kaydetcurl -o output.html https://example.com
# Progress bar ile indircurl -# -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'larcurl -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\ntime_connect:     %{time_connect}s\ntime_appconnect:  %{time_appconnect}s\ntime_pretransfer: %{time_pretransfer}s\ntime_redirect:    %{time_redirect}s\ntime_starttransfer: %{time_starttransfer}s\ntime_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östernetstat -tuln
# Process bilgisiyle tüm bağlantıları göstersudo netstat -tulnp
# Routing table'ı gösternetstat -r
# Modern alternatif (daha hızlı)ss -tuln
# Belirli portu gösterss -tuln | grep :443
# State'e göre bağlantıları gösterss -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 lookupnslookup example.com
# Belirli DNS server'ı sorgulanslookup example.com 8.8.8.8
# Dig (daha detaylı)dig example.com
# Belirli kayıt tipini sorguladig example.com AAAA
# Kısa cevapdig +short example.com
# DNS resolution'ı trace etdig +trace example.com
# Reverse lookupdig -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 etsudo tcpdump -i eth0 port 443
# Dosyaya kaydetsudo tcpdump -i eth0 -w capture.pcap
# Dosyadan okutcpdump -r capture.pcap
# Belirli host capture etsudo tcpdump -i eth0 host example.com
# Sadece HTTP trafiğisudo tcpdump -i eth0 -A port 80

Ne zaman kullanılır: Başka hiçbir şey yardımcı olmadığında son çare. 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)#

Amaç: TCP/UDP bağlantıları için İsviçre çakısı.

# Port açık mı test etnc -zv example.com 443
# Port'ta dinle (basit server)nc -l 8080
# Bağlan ve veri gönderecho "Merhaba" | nc example.com 80
# İki makine arasında chat# Makine 1: nc -l 8080# Makine 2: nc makine1-ip 8080
# Basit HTTP requestprintf "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n" | nc example.com 80

telnet#

Amaç: TCP bağlantılarını test et (şifrelenmemiş). Protokolleri debug etmek için kullanışlı.

# SMTP test ettelnet mail.example.com 25
# HTTP test ettelnet example.com 80# Sonra yaz: GET / HTTP/1.1 [Enter]#           Host: example.com [Enter]#           [Enter]
# Port açık mı test ettelnet 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 etping api.example.com
# 2. DNS resolution süresini kontrol ettime dig api.example.com
# 3. Bağlantıyı test etcurl -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 etwatch -n 1 'ss -s'
# 6. Packet loss kontrol etping -c 100 api.example.com | tail -n 3

Öğrendiğim şey: Timeout'lar genellikle network ile ilgili, uygulama bug'ı değil. Koda dalmadan önce network sağlığını kontrol et.

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 etecho | openssl s_client -connect example.com:443 -servername example.com
# 2. Süreyi kontrol etecho | openssl s_client -connect example.com:443 2>/dev/null | \  openssl x509 -noout -dates
# 3. Sertifika zincirini doğrulacurl -v https://example.com
# 4. Sertifika domain ile eşleşiyor mu kontrol etecho | 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 etdig example.com
# 2. Farklı DNS server'larla kontrol etdig @8.8.8.8 example.com    # Google DNSdig @1.1.1.1 example.com    # Cloudflare DNSdig @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ğruladig +trace example.com

Gerçek dünya ipucu: 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 bullsof -i :3000
# 2. Process'i kill etkill $(lsof -ti:3000)
# 3. Kill işe yaramazsakill -9 $(lsof -ti:3000)
# 4. Port gerçekten boş mu kontrol etnetstat -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şturcat > 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\nEOF
# 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

Temel Çıkarımlar#

Network'lerle çalışmak bana birkaç ders öğretti:

1. Network sorunları uygulama sorunları gibi görünür. Koda dalmadan önce network sorunlarını ele. Bağlantıyı, DNS'i, sertifikaları ve firewall kurallarını kontrol et.

2. Debugging'i katmanla. Üst seviyeden başla (host'a ulaşabiliyor muyum?) ve aşağı in (TCP handshake, SSL negotiation, HTTP response).

3. Temel araçlarda uzmanlaş. curl, dig, netstat/ss ve tcpdump network debugging'in %90'ını çözer. Bunları iyi öğren.

4. DNS her zaman suçludur. Bir şey bozulduğunda önce DNS'i kontrol et. DNS caching, propagation ve TTL ince sorunlara neden olur.

5. Ölç, tahmin etme. Latency'nin nereden geldiğini belirlemek için timing araçları kullan. Uygulama kodu mu? Network mü? SSL mi? Database mi?

6. Güvenlik networking'in bir parçasıdır. SSL/TLS, firewall'lar ve VPN'ler opsiyonel eklentiler değil. Bunları mimariye baştan oluştur.

7. Dokümantasyon önemlidir. Network mimarisini, firewall kurallarını ve port kullanımını dokümante et. Gelecekteki sen (veya takımın) incident'lar sırasında teşekkür edecek.

8. Stack boyunca test et. Lokal'de, staging'de ve farklı coğrafi lokasyonlardan test et. Network davranışı ortama göre değişir.

Bu temelleri anlamak seni network mühendisi yapmaz ama daha iyi bir geliştirici yapar. Sorunları daha hızlı debug edersin, bilinçli mimari kararlar alırsın ve daha güvenilir sistemler kurarsın. Network, stack'in sadece bir başka katmanı - uygulama kodun kadar ciddiye al.