TCP/IP Protokol Ailesi: Katmanlı Ağ Mimarisi Rehberi
TCP/IP nedir, internet hangi katmanlarda çalışır? ARPANET'ten RFC 791/793'e tarihçe, OSI 7 katman vs TCP/IP 5 katman karşılaştırması, fiziksel/veri bağlantı/ağ/taşıma/uygulama protokolleri, TCP 3-way handshake, UDP, IPv4/IPv6, NAT, ICMP, ARP, QUIC, TLS, port numaraları ve VDS troubleshooting örnekleriyle kapsamlı kavramsal mimari rehberi.
TCP/IP Protokol Ailesi: Katmanlı Ağ Mimarisi Rehberi
İnternet, dünyanın dört bir yanındaki on milyarlarca cihazı tek bir mantıksal ağda buluşturan bir mucize gibi gelir; fakat bu mucizenin altında 1970'lerden beri rafine edilmiş, katmanlı ve modüler bir protokol mimarisi vardır: TCP/IP protokol ailesi (Transmission Control Protocol / Internet Protocol suite). Bir paket Bursa'daki bir sunucudan Tokyo'daki bir oyuncuya 130 milisaniyede ulaşabiliyorsa, bu yolculuğun her milisaniyesinde fiziksel katmandan uygulama katmanına kadar 5 ayrı protokol katmanının uyum içinde çalışması, RFC 791 (IP) ve RFC 793 (TCP) ile 1981 yılında yazıya dökülen tasarım kararlarının doğru çalıştığı anlamına gelir.
Bu rehber TCP/IP'yi yüzeysel bir "TCP güvenilir, UDP güvenilir değil" tanımının çok ötesinde, bir hosting/VDS yöneticisinin sahada karşılaştığı kararlar ve sorunlar bağlamında ele alır: ARPANET'ten RFC'lere uzanan tarihsel bağlam, OSI 7 katman ile TCP/IP 5 katman modelinin karşılaştırması, her katmanın işlevi ve hâkim protokolleri, TCP 3-way handshake ile 4-way teardown, sequence/acknowledgement mantığı, sliding window flow control, congestion control algoritmaları (Reno → CUBIC → BBR), UDP'nin connectionless tasarımı ve QUIC ile yeniden doğuşu, IPv4 adresleme + CIDR + private range + NAT, IPv6'nın 128-bit alanı, ICMP'nin ping/traceroute rolü, ARP'nin MAC ↔ IP eşlemesi, HTTP/2-HTTP/3, TLS handshake, well-known port numaraları, ve son olarak Buyukweb Tier 3 VDS bağlamında pratik troubleshooting senaryoları.
Buyukweb perspektifi: Bursa Tier 3 veri merkezimizdeki VDS sunucular KVM hypervisor üzerinde virtio-net sanal NIC ile çalışır; bu mimari TCP/IP stack'inin tüm katmanlarına root erişim sağlar. Yani
iptables/nftablesile L3-L4 firewall kuralları yazabilir,tcpdumpile paket düzeyinde analiz yapabilir,ssile TCP socket durumlarını inceleyebilir, kendi WireGuard / IPSec tüneli kurabilirsiniz. Veri merkezimiz çoklu taşıyıcı (multi-homed) BGP altyapısıyla beslenir; trafik karayoluyla redundant fiber üzerinden gelir ve L3/L4 DDoS koruma üzerinden sunucularınıza ulaşır. cPanel paylaşımlı paketlerimizde de aynı altyapı kullanılır; fark, paylaşımlı ortamda root yerine cPanel UI üzerinden yönetim olmasıdır. Faturalama TL + KDV. Network troubleshooting veya protokol seviyesinde mimari tasarımı için 0850 302 60 70 destek hattımızdan ekibimizle planlama yapabilirsiniz.
Tarihsel Bağlam: ARPANET'ten TCP/IP'ye
TCP/IP'nin doğuşu rastlantı değil; soğuk savaş döneminde dağıtık askeri iletişim ihtiyacı ve akademik bilgisayar paylaşımı ekonomisinin kesişiminde 30 yıllık bir mimari evrimin ürünüdür.
ARPANET ve NCP (1969-1982)
1969'da ARPA (Advanced Research Projects Agency) tarafından finanse edilen ARPANET, dört üniversite (UCLA, SRI, UCSB, Utah) arasında ilk paket anahtarlamalı (packet-switched) ağ olarak doğdu. İlk transport protokolü NCP (Network Control Program)'di — günümüze göre primitif, host adresleri ile sıkı bağlı bir tasarım.
NCP'nin temel kısıtı şuydu: farklı ağ teknolojilerini bir araya getiremiyordu. Ethernet, X.25, uydu linkleri ve telsiz ağları farklı paket formatlarına ve farklı güvenilirlik karakteristiklerine sahipti. ARPANET dışındaki bir ağdan ARPANET'e geçmek için her seferinde ayrı bir adaptasyon yazılması gerekiyordu.
Cerf ve Kahn'ın Tasarımı (1973-1974)
Vint Cerf ve Bob Kahn, 1974'te "A Protocol for Packet Network Intercommunication" makalesinde ağlar arası bir protokol önerdiler. Bu öneri iki temel prensibi getirdi:
- End-to-end principle — Güvenilirlik, sıralama, hata düzeltme gibi karmaşık fonksiyonlar uç noktalardadır; ağ ortası "best effort" çalışır.
- Network of networks — Farklı altyapıların (Ethernet, uydu, X.25) üstüne soyutlama katmanı koyularak hepsi tek bir mantıksal ağmış gibi çalışır.
Bu makale, bugün bildiğimiz internet (inter-network) kavramının tohumudur.
RFC 791 ve RFC 793 (1981)
Önerinin protokol şartnamesi 1981'de iki belgeye dökildi:
- RFC 791 — Internet Protocol (IP) — Paketin başlık formatı, adresleme (32-bit IPv4), fragmentation/reassembly, TTL.
- RFC 793 — Transmission Control Protocol (TCP) — Connection-oriented, sequence/acknowledgement, sliding window, retransmission, 3-way handshake.
İkisi birlikte TCP/IP olarak anıldı.
Flag Day: 1 Ocak 1983
DARPA, ARPANET'in tüm sunucularına 1 Ocak 1983'te NCP'yi kapatma ve TCP/IP'ye geçme zorunluluğu getirdi. Bu tarih internet tarihinde "Flag Day" olarak bilinir. O tarihten sonra dünya, BSD UNIX 4.2'de TCP/IP referans uygulamasının açık kaynak yayılmasıyla hızla TCP/IP'ye döndü.
TCP/IP'nin OSI'yi Yenmesi (1980-1995)
1980'lerin sonu ve 1990'ların başında OSI (Open Systems Interconnection) modeli ISO/ITU tarafından alternatif standart olarak öne sürüldü. Avrupa hükümetleri ve telekom operatörleri OSI'yi tercih etti; "GOSIP (Government OSI Profile)" bile yayınlandı. Ama OSI implementasyonları:
- Karmaşık — 7 katman, her katman katı tanım, ağır spesifikasyon
- Geç — TCP/IP zaten yaygın kullanımdayken OSI dökümentasyonu hâlâ taslaktı
- Komite üreten — Pragmatik mühendislikten uzak, "komite tasarımı" estetiği
TCP/IP, açık kaynak BSD UNIX implementasyonu, basit "rough consensus and running code" felsefesi ve internet'in patlaması ile OSI'yi 1990'larda kesin olarak yendi. OSI modeli pratikte ölü; ama OSI 7-katman referans modeli öğretim ve protokol tartışmalarında bugün hâlâ değerli bir kavramsal araçtır.
OSI 7 Katman vs TCP/IP 4-5 Katman Modeli
Ağ protokol mimarisi tartışılırken iki referans model kullanılır: OSI ve TCP/IP. Aşağıdaki tablo katmanları yan yana koyar.
| Katman # | OSI Modeli | TCP/IP 4-Katman Modeli | TCP/IP 5-Katman Pratik | Tipik Protokoller |
|---|---|---|---|---|
| 7 | Application | Application | Application | HTTP, HTTPS, DNS, SMTP, IMAP, FTP, SSH, RDP |
| 6 | Presentation | (Application içinde) | (Application içinde) | TLS/SSL, MIME, ASCII/UTF-8 |
| 5 | Session | (Application içinde) | (Application içinde) | SIP, NetBIOS, RPC |
| 4 | Transport | Transport | Transport | TCP, UDP, SCTP, QUIC |
| 3 | Network | Internet | Network | IPv4, IPv6, ICMP, IGMP, IPsec |
| 2 | Data Link | Link (Network Access) | Data Link | Ethernet, Wi-Fi, ARP, PPP, VLAN |
| 1 | Physical | Link (Network Access) | Physical | RJ45, Fiber, 5G, radio, voltage levels |
Neden Pratik Modelde 5 Katman Tercih Edilir?
Original RFC 1122'de TCP/IP 4 katmanlı olarak tarif edilir: Link, Internet, Transport, Application. Bu modelde Link katmanı hem fiziksel katmanı (kablo, sinyal) hem de veri bağlantı katmanını (MAC, frame) kapsar.
Öğretimde ve sahada 5-katman pratik model daha kullanışlıdır çünkü:
- L1 (Fiziksel) — Donanım kablo/optik/radyo seviyesinde
- L2 (Veri Bağlantı) — Aynı broadcast domain içinde MAC adresi ile çerçeve iletimi
Ayrım önemli; bir Ethernet kartı ile bir Wi-Fi kartı L1'de farklı ama L2'de aynı standart kullanır (IEEE 802 ailesi). Fiber'den geçen bir Ethernet frame'i ile bakırdan geçen aynı frame, L2 seviyesinde özdeştir.
OSI Layer 5/6/7 Neden TCP/IP'de Tek "Application" Oldu?
TCP/IP felsefesi pragmatik: end-to-end principle'ı kabul eder ve sunum (Presentation) ile oturum (Session) yönetimini uygulama kendisi yapar. TLS aslında Presentation katmanına denk gelir ama TCP/IP modelinde "Application katmanının yan eki" gibi konuşulur. SSH, HTTP, SMTP gibi protokoller kendi Presentation ve Session işleri hallederler.
OSI modeli "her şey ayrı katman" yaklaşımıyla teorik temizdir; ama pratikte bir TLS bağlantısı kuran HTTP sunucusu için Layer 5 ve Layer 6 ayrımı operasyonel değer üretmez. Bu yüzden TCP/IP pratik modeli sunum + oturum + uygulama'yı tek "Application Layer" altında birleştirir.
L1 — Fiziksel Katman
Fiziksel katman, bilgisayar ağlarının "0 ve 1" bitlerinin gerçek dünyada nasıl temsil edildiği seviyesidir: bakır kablodaki gerilim seviyeleri, fiber optik ışık darbeleri, kablosuz radyo modülasyonu, sinyal kodlaması, fiziksel konnektörler.
Ethernet (IEEE 802.3)
Kablolu ağların hâkim standardı Ethernet'tir. Tarihsel evrim:
- 10BASE-T (1990) — Cat3 bakır, 10 Mbps, RJ45
- 100BASE-TX (Fast Ethernet, 1995) — Cat5, 100 Mbps
- 1000BASE-T (Gigabit Ethernet, 1999) — Cat5e/Cat6, 1 Gbps
- 10GBASE-T (10 Gigabit Ethernet, 2006) — Cat6a/Cat7, 10 Gbps
- 25/40/100/400 Gbps — Veri merkezi omurga ve hyperscale internet exchange
Optik fiber versiyonları (1000BASE-LX, 10GBASE-LR, vb.) uzun mesafelerde ve veri merkezi içi yüksek hızda kullanılır. Tek mod (SMF) ve çok mod (MMF) fiber farklı dalga boylarında çalışır.
Wi-Fi (IEEE 802.11)
Kablosuz LAN standartları:
- 802.11n (Wi-Fi 4) — 2009, 2.4/5 GHz, 600 Mbps tepe
- 802.11ac (Wi-Fi 5) — 2013, 5 GHz, 6,9 Gbps tepe (MU-MIMO)
- 802.11ax (Wi-Fi 6/6E) — 2019, 2.4/5/6 GHz, 9,6 Gbps tepe (OFDMA, BSS Coloring)
- 802.11be (Wi-Fi 7) — 2024, multi-link operation, 320 MHz kanal, 46 Gbps tepe
Veri merkezi sunucu trafiği fiziksel kabloyla (Ethernet/fiber) taşınır; Wi-Fi son kullanıcı (laptop, telefon) tarafında baskındır.
Diğer L1 Standartları
- 5G NR / 4G LTE — Mobil hücresel ağlar
- DOCSIS — Kablo modem (kablo TV altyapısı üstünde internet)
- xDSL — Bakır telefon hattı (ADSL, VDSL, G.fast)
- GPON / XGS-PON — Fiber FTTH (eve fiber)
- 5G Fixed Wireless Access — Sabit kablosuz erişim
- LoRaWAN, NB-IoT, Sigfox — IoT uzun menzilli düşük güç kablosuz
L2 — Veri Bağlantı Katmanı
Veri bağlantı katmanı, aynı broadcast domain içindeki cihazlar arasında çerçeve (frame) iletimini sağlar. Bu katmanın temel kimliği MAC adresi (Media Access Control)'dir.
MAC Adresi
MAC adresi 48-bit (6 byte) bir donanım kimliğidir. Her ağ kartının üretici tarafından atanan benzersiz bir MAC adresi vardır. Örnek:
00:1A:2B:3C:4D:5E
└──┬───┘ └──┬───┘
OUI Üretici tarafından atanan kısım
(vendor)
İlk 24 bit OUI (Organizationally Unique Identifier)'dır ve IEEE tarafından üreticilere tahsis edilir. Geri kalan 24 bit üretici içi sıra numarasıdır.
Ethernet Frame Yapısı
Bir Ethernet II frame'i:
+--------+--------+----------+--------+---------+-----+
| Dest | Source | EtherType| Payload | FCS |
| MAC | MAC | (2 byte) | (46-1500 byte) | 4B |
| 6 byte | 6 byte | | | |
+--------+--------+----------+--------+---------+-----+
- Dest/Source MAC — Hedef ve kaynak donanım adresi
- EtherType — Üstteki protokol (0x0800 = IPv4, 0x86DD = IPv6, 0x0806 = ARP, 0x8100 = VLAN tag)
- Payload — L3 paket (IP datagram)
- FCS (Frame Check Sequence) — CRC32 hata kontrolü
MTU (Maximum Transmission Unit) — Standart Ethernet MTU 1500 byte'tır. Jumbo frame desteği ile 9000 byte'a kadar çıkabilir (veri merkezi içi optimizasyon).
ARP — MAC ↔ IP Eşlemesi
Bir cihaz, hedef IP'sini bilir ama Ethernet frame yazabilmek için hedef MAC'i bilmesi gerekir. ARP (Address Resolution Protocol, RFC 826) bu eşlemeyi yapar:
1. Cihaz A "192.168.1.10 kimde?" diye broadcast ARP request gönderir
(FF:FF:FF:FF:FF:FF MAC adresine)
2. 192.168.1.10 IP'sini sahip olan cihaz B "Ben, MAC adresim 00:1A:..."
diye unicast ARP reply döner
3. Cihaz A bu eşlemeyi ARP table'da cache'ler (Linux \`ip neigh show\`)
ARP cache süresi tipik 30-60 saniye (OS'a bağlı). arp -n veya modern ip neigh ile görüntülenir.
ARP Poisoning Saldırısı
Bir saldırgan ağda gratuitous ARP mesajları göndererek "192.168.1.1 (gateway) MAC adresi benim!" diyerek tüm trafiği kendi üzerinden geçirebilir (MITM). Karşı önlemler:
- Dynamic ARP Inspection (DAI) — switch seviyesi koruma
- Static ARP entries — kritik hostlar için manuel ARP kaydı
- Arpwatch — ARP table değişikliklerini izleyen ve uyaran araç
Switch ve VLAN
Bir L2 switch MAC adres tablosuna göre frame'leri sadece doğru porta iletir (hub'ın aksine her porta broadcast yapmaz). MAC öğrenme dinamik gerçekleşir: switch her gelen frame'in kaynak MAC + giriş portunu kaydeder.
VLAN (Virtual LAN, IEEE 802.1Q) aynı fiziksel switch üzerinde mantıksal olarak ayrı broadcast domain'leri oluşturur. VLAN tag 4 byte'lık bir ek alandır:
+----+--------+----------+
|TPID| TCI | | TPID = 0x8100, TCI içinde VLAN ID (12 bit, 1-4094)
+----+--------+----------+
Kurumsal ağlarda trunk port birden fazla VLAN'ı tek kablodan taşır (genelde switch'ler ve hypervisor host'ları arası); access port tek VLAN'a aittir (kullanıcı bilgisayarı).
PPP, MPLS, Diğer L2 Protokolleri
- PPP (Point-to-Point Protocol) — İki nokta arası serial bağlantı (xDSL, dial-up legacy)
- MPLS (Multiprotocol Label Switching) — Operatör WAN ağlarında etiket bazlı yönlendirme (L2.5 olarak da anılır)
- Spanning Tree Protocol (STP, IEEE 802.1D) — Switch ağlarında loop önleme
L3 — Ağ (Internet) Katmanı
L3, paketleri farklı broadcast domain'leri arasında, yani router'lar üzerinden iletmenin yeridir. Bu katmanın hâkim protokolü IP (Internet Protocol)'dir.
IPv4 — RFC 791
IPv4 paket başlığı 20 byte (opsiyonlarsız):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Version — 4
- IHL — Header uzunluğu (32-bit kelime)
- TTL — Her router'da 1 azaltılır, 0'a inerse paket düşer (loop koruması + traceroute)
- Protocol — Üstteki protokol (1 = ICMP, 6 = TCP, 17 = UDP, 47 = GRE, 50 = ESP)
- Source/Destination — 32-bit IPv4 adresleri
Adresleme: 32-bit, ~4,3 Milyar Adres
IPv4 adresi 4 oktet (32 bit) ile ifade edilir: 192.168.1.10. Teorik toplam: 2³² ≈ 4,3 milyar adres. 1981'de yeterli görünüyordu; 2011'de IANA en üst seviye havuz tükendi.
Sınıflar (Eski) → CIDR (Yeni)
Tarihsel olarak IPv4 adresleri sınıflara (A, B, C, D, E) ayrılıyordu:
- Class A: 1.0.0.0 - 126.255.255.255, /8 default, 16M host
- Class B: 128.0.0.0 - 191.255.255.255, /16 default, 65K host
- Class C: 192.0.0.0 - 223.255.255.255, /24 default, 254 host
- Class D: 224.0.0.0 - 239.255.255.255, multicast
- Class E: 240.0.0.0 - 255.255.255.255, deneysel
Bu model 1993'te CIDR (Classless Inter-Domain Routing, RFC 4632) ile değiştirildi. CIDR'de prefix uzunluğu serbest: /8, /9, /10, ..., /32. Bu sayede:
- IP tahsisi daha verimli (her şirkete /16 vermek yerine /22 verilebilir)
- Routing table'larda prefix aggregation mümkün
- VLSM (Variable Length Subnet Masking) — bir kurum içinde farklı boyut subnet'ler
Private Range (RFC 1918)
İnternette routable olmayan, sadece iç ağlarda kullanılan adresler:
- 10.0.0.0/8 — 10.0.0.0 - 10.255.255.255 (16,7M adres)
- 172.16.0.0/12 — 172.16.0.0 - 172.31.255.255 (1M adres)
- 192.168.0.0/16 — 192.168.0.0 - 192.168.255.255 (65K adres)
Ek olarak 169.254.0.0/16 APIPA (link-local, DHCP başarısız ise OS otomatik atar), 127.0.0.0/8 loopback (localhost).
Network Address Translation (NAT) — RFC 3022
NAT, private IP'leri public IP'ye çevirerek IPv4 adres tükenmesini geciktiren mekanizma. Farklı türleri:
- SNAT (Source NAT) — Outbound trafik için kaynak IP değişir (tipik ev/ofis gateway davranışı: 192.168.1.10 → 95.85.100.5)
- DNAT (Destination NAT) — Inbound trafik için hedef IP değişir (port forwarding: 95.85.100.5:80 → 192.168.1.20:80)
- Masquerade — Dinamik SNAT, gateway'in mevcut public IP'sini kullanır (
iptables -t nat -A POSTROUTING -j MASQUERADE) - PAT (Port Address Translation) / NAPT — Birden çok iç host tek public IP üzerinden port multiplexing ile çıkar
- CGNAT (Carrier-Grade NAT) — Operatör seviyesinde NAT, bir kullanıcının paylaşımlı IP'si olur
NAT'ın Kısıtları
NAT pratik bir ara çözüm; ama:
- End-to-end principle bozulur — her cihaz public erişilebilir değil
- Peer-to-peer uygulamalar zor (oyun, P2P, WebRTC) — STUN/TURN gerekir
- IPSec ile uyumsuzluk (header değiştiği için authentication bozulur)
- Hairpin NAT ihtiyacı (iç host kendi domain'inden kendi sunucusuna erişmek istediğinde)
IPv6'nın bir hedefi NAT'ı tarih sayfasına havale etmektir; her cihazın public erişilebilir adresi olur.
IPv6 — RFC 8200
IPv6 paket başlığı 40 byte sabit (IPv4'teki gibi opsiyon yok, ek başlıklar zincirleme):
- Adres uzunluğu — 128 bit, 2¹²⁸ ≈ 3,4 × 10³⁸ adres
- Format —
2001:0db8:85a3:0000:0000:8a2e:0370:7334veya kısaltılmış2001:db8:85a3::8a2e:370:7334 - Otomatik konfigürasyon (SLAAC) — Router Advertisement ile cihaz kendi adresini üretir
- NAT yok — Her cihaz global routable adres alır
- Fragmentation sadece kaynakta — Router'lar paketi parçalamaz, Path MTU Discovery kullanılır
IPv6 ile dual-stack ve geçiş detayları için ayrı rehberimiz var: IPv6 dual-stack rehberi.
ICMP — Internet Control Message Protocol
ICMP, IP üzerinde kontrol mesajları taşıyan yardımcı protokol. RFC 792 (IPv4 için), RFC 4443 (IPv6 için, ICMPv6).
Tipik ICMP mesajları:
- Echo Request / Echo Reply —
pingkomutu bu mesajları kullanır - Destination Unreachable — Hedef erişilemez (network, host, port, protokol)
- TTL Exceeded — TTL 0'a inmiş, paket düştü (traceroute bu mesajları kullanır)
- Redirect — "Bu hedef için başka gateway daha verimli"
- Fragmentation Needed (DF set) — Path MTU Discovery için kritik
- Source Quench — (Tarihsel, artık kullanılmaz)
Firewall'larda ICMP'yi tamamen kapatmak kötü bir fikir; özellikle "Fragmentation Needed" mesajlarını engellemek Path MTU Discovery'yi bozar ve büyük paketlerin kaybolmasına yol açar (PMTU black hole). En azından ICMP Type 3 Code 4 mesajlarına izin verin.
Routing Katmanı
Bir paket router'a geldiğinde, router routing table'a bakar ve "longest prefix match" ile en uygun next-hop'u seçer. Routing protokolleri (BGP, OSPF, IS-IS, EIGRP, RIP) bu tabloları dinamik olarak doldurur. Detaylar için ayrı rehberlerimiz:
L4 — Taşıma Katmanı
L4, uç noktalar arasında mantıksal kanal ve port multiplexing sağlar. Tek bir host üzerinde aynı anda 80 portunda web sunucu, 22'sinde SSH, 25'sinde mail çalışabilmesi L4'ün port kavramından gelir.
İki ana protokol vardır: TCP ve UDP. Modern alternatifler: SCTP, QUIC.
TCP — Transmission Control Protocol (RFC 793)
TCP connection-oriented ve reliable bir transport protokolüdür. Karakteristikleri:
- Bağlantı kurma (handshake)
- Sequence number ile sıralama
- Acknowledgement ile garanti
- Sliding window ile akış kontrolü
- Congestion control ile ağ tıkanma yönetimi
- Retransmission ile kayıp paket telafisi
3-Way Handshake — Bağlantı Kurma
Client Server
| |
|-----[SYN, seq=x]-------->|
| |
|<---[SYN-ACK, seq=y, ack=x+1]---|
| |
|-----[ACK, ack=y+1]------>|
| |
| <===== Connection ESTABLISHED ===> |
- SYN — Client "ben başlamak istiyorum, sequence numaram x" der
- SYN-ACK — Server "tamam, sen x'den başla, ben de y'den başlıyorum"
- ACK — Client "anlaşıldı, başlayalım"
Üç paket sonra bağlantı kurulmuş; iki taraf da sequence numara aralığını anladı.
Sequence ve Acknowledgement Numarası
TCP her byte'a bir sequence numarası verir (32-bit, başlangıç random — ISN). Karşı taraf "şu byte'a kadar aldım" diye ack=next_expected_byte döner.
Client gönderir: seq=1000, len=100 (byte 1000-1099)
Server alır ve onaylar: ack=1100 (sıradaki beklenen byte)
Bu mekanizma kayıp paket tespiti ve sıralama garantisinin temelidir.
Sliding Window — Flow Control
TCP, alıcının buffer dolmasını engellemek için bir "window" yayınlar:
Sender Receiver
| |
|-- "send window: 64KB"|
| |
|--byte 1-65536------->|
| | buffer doluyor, app okuyor
|<-- "ack 32768, win=32KB" --| yarısı okundu, buffer'da 32KB yer var
| |
|-- byte 65537-98304-->|
Modern Linux'ta varsayılan window 64 KB; TCP Window Scaling (RFC 7323) opsiyonu ile gigabit hızlarda 1 MB ve üstüne çıkar.
Congestion Control — Reno, CUBIC, BBR
TCP, alıcı buffer'ı dışında ağ tıkanmasını da yönetir. Bir paket kaybolursa congestion var demektir; sender hızını düşürür.
Algoritmik evrim:
- Reno (1990) — Slow start, congestion avoidance, fast retransmit, fast recovery. Klasik AIMD (Additive Increase Multiplicative Decrease).
- CUBIC (2008) — Linux varsayılan (2007+). Pencere büyüklüğünü kübik fonksiyonla artırır; yüksek bandwidth-delay product (BDP) ağlarda Reno'dan daha iyi.
- BBR (Bottleneck Bandwidth and RTT, 2016) — Google geliştirdi. Paket kaybı yerine bandwidth + RTT ölçümüne dayanır; kayıp olmadan da hız ayarlar. YouTube ve Google trafiğinde yaygın.
Linux'ta congestion algoritması:
```bash
Mevcut algoritmayı görüntüle
sysctl net.ipv4.tcp_congestion_control
Mevcut yüklü algoritmaları görüntüle
sysctl net.ipv4.tcp_available_congestion_control
BBR'a geç (kernel destekliyorsa)
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p
```
VDS müşterilerimiz BBR'a manuel geçebilir; Buyukweb varsayılan kernel'i (Ubuntu 22.04 / Debian 12 / AlmaLinux 9) zaten BBR destekler.
Retransmission ve RTO
TCP, ACK gelmezse paketi yeniden gönderir. Bekleme süresi RTO (Retransmission Timeout)'dır ve RTT'ye dayalı hesaplanır:
SRTT = (1 - alpha) * SRTT_eski + alpha * RTT_ölçüm
RTO = SRTT + 4 * RTTVAR
Hızlı tekrarlı paket kaybında RTO katlanır (binary exponential backoff). Bu, ağa daha fazla yük bindirmemek için.
Selective ACK (SACK) — RFC 2018
Klasik TCP "şu byte'a kadar aldım" der; ortada kayıp varsa sender ortadaki tüm paketleri tekrar gönderir. SACK opsiyonu "bu aralıkları aldım, şu aralıkları almadım" diyerek sadece kayıp olanların tekrarını sağlar. Modern TCP stack'lerde varsayılan açık.
4-Way Teardown — Bağlantı Sonlandırma
Client Server
| |
|-----[FIN]--------------->|
|<------[ACK]--------------|
| | Server yarı-kapalı, daha gönderebilir
|<------[FIN]--------------|
|-----[ACK]--------------->|
| |
| TIME_WAIT (2*MSL ~ 60s) |
Her iki taraf da bağımsız olarak "ben bitti" der. TIME_WAIT state 2*MSL süresi (RFC 793'te 2 dakika, modern OS'larda 60 saniye) boyunca tutulur — geç gelen paketlerin yeni bağlantıyla karışmaması için.
Nagle Algoritması ve TCP_NODELAY
Nagle algoritması (RFC 896) küçük TCP segmentlerinin birikmesini sağlar; verim için. Ama interaktif uygulamalar (SSH, oyun, telnet) için gecikme sorunu oluşturur.
```c
// TCP_NODELAY ile Nagle kapatma
int flag = 1;
setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(int));
```
HTTP/2, gRPC, Redis gibi düşük gecikme isteyen protokoller TCP_NODELAY kullanır.
TCP Keepalive
Uzun süre idle kalan bağlantılarda, taraflardan biri kapanırsa öbürü durumu fark etmeyebilir. Keepalive periyodik probe gönderir:
```bash
sysctl net.ipv4.tcp_keepalive_time # default 7200s = 2 saat
sysctl net.ipv4.tcp_keepalive_intvl # probe arası 75s
sysctl net.ipv4.tcp_keepalive_probes # 9 probe sonra ölü kabul
```
NAT/firewall arkasındaki bağlantılar için keepalive süresini düşürmek (300-600 saniye) yararlıdır; aksi halde NAT tablosu connection'ı düşürür ve sonraki paketler RST alır.
SYN Cookies — DDoS Koruması
SYN flood saldırısında saldırgan binlerce yarım açık (SYN gönderdi, ACK gelmedi) bağlantı bırakır; sunucunun bağlantı tablosu dolar. SYN Cookies mekanizması bu durumu çözer: server SYN-ACK gönderirken state tutmaz, tüm bilgiyi sequence number'a kriptografik olarak gömüp ACK gelince geri açar.
```bash
sysctl net.ipv4.tcp_syncookies # 1 = açık (Linux varsayılan)
```
UDP — User Datagram Protocol (RFC 768)
UDP TCP'nin antitezi: connectionless, unreliable, stateless.
UDP başlığı sadece 8 byte:
+-------------------+-------------------+
| Source Port (16b) | Dest Port (16b) |
+-------------------+-------------------+
| Length (16b) | Checksum (16b) |
+-------------------+-------------------+
| Payload |
+---------------------------------------+
Avantajlar:
- Hızlı — handshake yok
- Düşük overhead — başlık 8 byte
- Stateless — sunucu her paketi bağımsız işler
- Multicast / broadcast destekler
Dezavantajlar:
- Sıralama yok — paketler farklı sırayla varabilir
- Kaybolan paket retransmit edilmez — uygulama halletmek zorunda
- Akış kontrolü yok — sender alıcıyı boğabilir
UDP'nin tipik kullanım alanları:
- DNS sorgu/yanıt — Tek paketlik istek/cevap, TCP overhead'i gereksiz
- NTP (Network Time Protocol) — Saat senkronizasyonu
- DHCP — Adres atama (broadcast gerekir, UDP idealdir)
- VoIP (SIP/RTP) — Düşük gecikme, az paket kaybı kabul edilebilir
- Video streaming (RTP) — Tek bir kayıp kareyi yeniden istemek anlamsız
- Online oyun — Tutarlı düşük gecikme
- DNS over UDP 53 — Geleneksel; DoH/DoT modern alternatifler
QUIC — Modern UDP Tabanlı Transport (RFC 9000)
QUIC (Quick UDP Internet Connections), Google'da 2012'de başlatılan ve 2021'de IETF standartlaşmış (RFC 9000) bir transport protokolüdür. Adı "QUIC", "Quick" anlamında.
QUIC'in temel özellikleri:
- UDP üzerine kurulu — middlebox uyumluluğu (firewall/NAT QUIC'i UDP olarak görür)
- TLS 1.3 entegre — TLS handshake'i transport handshake ile birleşik
- 0-RTT — Önceki bağlantı bilgisi varsa sıfır RTT ile veri gönderme (yeniden bağlanma hızı)
- Connection migration — Cihaz IP değiştirse (Wi-Fi'dan 5G'ye geçiş) bağlantı kopmaz; Connection ID üzerinden devam eder
- Stream multiplexing — Tek bağlantıda paralel stream'ler, head-of-line blocking yok
- Kullanıcı alanında implementasyon — Kernel TCP stack yerine app içinde QUIC; iterasyon hızı
HTTP/3 QUIC üzerine kurulu (RFC 9114). 2026 itibariyle YouTube, Google, Cloudflare, Meta, ByteDance trafiğinin önemli kısmı HTTP/3 üzerinden geçiyor.
SCTP — Stream Control Transmission Protocol (RFC 9260)
Telekom dünyasında VoIP signalling için kullanılan bir transport. Multi-streaming ve multi-homing destekler. Genel internette yaygın değil; ama Diameter, SS7 over IP gibi 4G/5G protokollerinde temel.
L5-L7 — Uygulama Katmanı
Uygulama katmanı TCP/IP pratik modelinde tek katman; OSI'de Session + Presentation + Application olarak üçe bölünür. Bu katmanda her uygulamanın kendi protokolü olur.
HTTP/HTTPS
HTTP (HyperText Transfer Protocol) web'in temel protokolü.
Versiyon evrimi:
- HTTP/0.9 (1991) — Tek GET, sadece HTML
- HTTP/1.0 (RFC 1945, 1996) — Header'lar, response codes, MIME types
- HTTP/1.1 (RFC 7230-7235, 1997/2014) — Persistent connections, chunked transfer, pipelining
- HTTP/2 (RFC 7540, 2015) — Binary framing, stream multiplexing, header compression (HPACK), server push
- HTTP/3 (RFC 9114, 2022) — QUIC üzerinde, UDP tabanlı, 0-RTT
HTTP/2 hâlâ TCP üstüne çalışır ve "head-of-line blocking" sorunu yaşar: bir paketin kayıbı tüm stream'leri bekletir. HTTP/3 QUIC ile bu sorunu çözer çünkü her stream UDP seviyesinde bağımsız.
HTTPS = HTTP + TLS. TLS handshake TCP'den sonra (HTTP/2'de) veya transport içinde entegre (HTTP/3'te) gerçekleşir.
DNS — Domain Name System
DNS, alan adlarını IP'lere çeviren dağıtık veritabanı. Detaylı işleyiş için ayrı rehberlerimiz:
Kısaca DNS, UDP port 53 üzerinde çalışır (TCP 53 büyük cevaplar veya zone transfer için). Recursive resolver kullanıcıdan gelen sorguyu kök sunuculardan başlayarak yetkili sunucuya kadar takip eder.
SMTP, IMAP, POP3 — Mail Protokolleri
- SMTP (Simple Mail Transfer Protocol, RFC 5321) — Mail gönderme. Sunucudan sunucuya port 25, client'tan sunucuya submission port 587 (STARTTLS) veya 465 (SSL).
- IMAP (Internet Message Access Protocol, RFC 9051) — Mail okuma, sunucuda kalır, çoklu cihaz sync. Port 143 (STARTTLS) veya 993 (SSL).
- POP3 (Post Office Protocol v3, RFC 1939) — Mail indir + sil, tek cihaz. Port 110 (STARTTLS) veya 995 (SSL).
Kurumsal mail mimarisi detayı için kurumsal e-posta hosting rehberi.
FTP, SFTP, FTPS
- FTP (File Transfer Protocol, RFC 959) — Eski, plain-text, port 21 control + dinamik data port. Modern web'de yok denecek kadar az.
- SFTP — SSH üzerinde dosya transferi, port 22. Modern standart.
- FTPS — FTP + TLS, port 21 (explicit) veya 990 (implicit).
SSH — Secure Shell (RFC 4253)
Uzak sunucuya şifreli komut satırı erişimi. TCP port 22. Public-key auth, port forwarding, tunneling, SFTP, SCP destekler. Modern sunucu yönetiminin temeli.
RDP — Remote Desktop Protocol
Microsoft'un Windows uzak masaüstü protokolü. TCP/UDP port 3389. Windows Server VDS müşterilerimizin ana yönetim arayüzü.
Diğer Uygulama Protokolleri
- SIP (Session Initiation Protocol) — VoIP signalling, port 5060
- MQTT — IoT pub/sub messaging, port 1883 (8883 TLS)
- NTP — Saat senkronizasyonu, UDP port 123
- SNMP — Ağ cihazı yönetimi, UDP port 161 (162 trap)
- LDAP — Dizin servisi (Active Directory dahil), port 389 (636 LDAPS)
TLS — Transport Layer Security
TLS (Transport Layer Security), transport katmanının üstünde şifreli kanal sağlar. Tarihsel olarak SSL → TLS 1.0 → 1.1 → 1.2 → 1.3.
- TLS 1.2 (RFC 5246, 2008) — Yaygın, 4 paketlik handshake
- TLS 1.3 (RFC 8446, 2018) — Modern, 1 RTT handshake (0-RTT mümkün), eski cipher'lar (RC4, MD5, SHA1) kaldırıldı
TLS 1.3 handshake:
Client Server
| |
|--- ClientHello + KeyShare->|
| |
|<-- ServerHello + KeyShare |
| + Cert + Finished |
| |
|--- Finished -------------->|
| |
|<== Şifreli veri başlar ===>|
Tek RTT'de hem anahtar değişimi hem sertifika doğrulaması yapılır. Önceki bağlantıdan PSK varsa 0-RTT mümkün (ama replay riski olduğu için non-idempotent istekler için önerilmez).
Port Numaraları
TCP/UDP port 16-bit (0-65535). IANA üç bölgeye ayırır:
Well-Known Ports (0-1023)
İşletim sistemi privileged port'lar; bind etmek için root yetkisi gerekir.
| Port | Protokol | Hizmet |
|---|---|---|
| 20, 21 | TCP | FTP (data, control) |
| 22 | TCP | SSH, SFTP |
| 23 | TCP | Telnet (legacy) |
| 25 | TCP | SMTP (server-to-server) |
| 53 | UDP/TCP | DNS |
| 67, 68 | UDP | DHCP (server, client) |
| 80 | TCP | HTTP |
| 110 | TCP | POP3 |
| 123 | UDP | NTP |
| 143 | TCP | IMAP |
| 161, 162 | UDP | SNMP, SNMP trap |
| 389 | TCP | LDAP |
| 443 | TCP/UDP | HTTPS, HTTP/3 (QUIC) |
| 465 | TCP | SMTPS |
| 514 | UDP | Syslog |
| 587 | TCP | SMTP Submission (STARTTLS) |
| 636 | TCP | LDAPS |
| 993 | TCP | IMAPS |
| 995 | TCP | POP3S |
Registered Ports (1024-49151)
IANA tarafından kaydı yapılmış uygulama portları. Root yetkisi gerekmez.
| Port | Hizmet |
|---|---|
| 1194 | OpenVPN |
| 1433, 1434 | MSSQL |
| 1521 | Oracle DB |
| 3306 | MySQL/MariaDB |
| 3389 | RDP |
| 5060, 5061 | SIP, SIPS |
| 5432 | PostgreSQL |
| 5900 | VNC |
| 6379 | Redis |
| 8080, 8443 | Alternatif HTTP/HTTPS |
| 9000 | PHP-FPM |
| 27017 | MongoDB |
Ephemeral Ports (49152-65535)
İstemci tarafının "geçici" port'ları. Linux'ta varsayılan range:
```bash
sysctl net.ipv4.ip_local_port_range # 32768-60999 (Linux default)
```
Yüksek trafikli outbound bağlantı kuran sunucularda (proxy, load balancer) ephemeral port havuzu tükenebilir; range'i genişletmek gerekir.
Network Troubleshooting Toolbox
VDS sunucusunda ağ problemi olduğunda ilk başvurulacak araç seti. Detaylı rehberler için Linux performans izleme ve ağ tanılama rehberlerimize bakın; bu bölümde kavramsal özet veriyoruz.
ping — ICMP Echo
En temel ağ testi. Hedef erişilebilir mi, kaç ms gecikme, paket kaybı var mı?
```bash
ping -c 5 8.8.8.8 # 5 paket gönder
ping -c 5 -i 0.2 buyukweb.com # 200ms aralıkla
ping6 -c 5 2001:4860:4860::8888 # IPv6
```
traceroute / tracert / mtr
Hedefe giden yol üzerindeki her router'ı listeler. TTL'i 1, 2, 3, ... ile artırarak her hop'un ICMP TTL Exceeded mesajını alır.
```bash
traceroute -n buyukweb.com # Linux/macOS
tracert buyukweb.com # Windows
mtr -n buyukweb.com # Sürekli traceroute (paket kaybı + RTT canlı)
```
mtr özellikle ara hop'taki problemleri tespit etmek için çok değerli — örneğin hop 6'da %5 paket kaybı varsa orada bir sorun var demektir.
dig / nslookup
DNS sorgu ve yanıtını inceler.
```bash
dig buyukweb.com # A kaydı
dig buyukweb.com MX # MX kayıtları
dig @8.8.8.8 buyukweb.com # Belirli resolver kullan
dig +trace buyukweb.com # Root'tan başla recursive izleme
dig -x 8.8.8.8 # Reverse DNS (PTR)
```
tcpdump / Wireshark — Packet Capture
Paketleri kablodan yakalar.
```bash
tcpdump -i eth0 -nn port 80 # 80 portu trafiği
tcpdump -i eth0 -nn host 8.8.8.8 # 8.8.8.8'e/den gelen
tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-syn != 0' # Sadece SYN paketler
tcpdump -i eth0 -nn -w capture.pcap # Dosyaya kaydet (Wireshark ile incele)
```
Wireshark capture dosyasını grafik UI'da derinlemesine inceler; her paket başlığı, TCP stream takip, TLS handshake analizi mümkün.
netstat / ss — Socket Listing
Hangi portlar dinleniyor, hangi bağlantılar aktif?
```bash
ss -tlnp # TCP, listening, port + program
ss -tunap # TCP/UDP, all, namespace + program
ss -s # İstatistik özet
ss -ti # TCP internal (window, RTT)
```
netstat legacy; modern ss (iproute2) daha hızlı ve detaylı.
nmap — Port Scan
Bir host'ta hangi portlar açık?
```bash
nmap -sS -p 1-1024 target.com # SYN scan, ilk 1024 port
nmap -sV target.com # Servis versiyon detection
nmap -O target.com # OS fingerprinting
```
nmap'i sadece kendi sunucunuza veya yazılı izin aldığınız hedeflere karşı kullanın; izinsiz port scan birçok ülkede yasal sorun yaratabilir.
VDS Troubleshooting Senaryoları
Buyukweb VDS müşterilerinin pratik karşılaştığı 3 senaryo ve TCP/IP perspektifinden çözüm akışı.
Senaryo 1: "Site Açılmıyor"
Bir kullanıcı "site.com.tr açılmıyor" dediğinde adım adım hangi katmanı kontrol edeceksiniz?
1. DNS çalışıyor mu? (L7)
dig site.com.tr
→ IP geldi mi? Doğru IP mi?
2. IP'ye ping atılabiliyor mu? (L3)
ping <IP>
→ Yanıt geliyor mu? Paket kaybı var mı?
3. Web portu açık mı? (L4)
telnet <IP> 80
nc -zv <IP> 443
→ "Connected" mı, yoksa "Connection refused / timeout" mı?
4. TLS handshake çalışıyor mu? (L6/7)
openssl s_client -connect <IP>:443 -servername site.com.tr
→ Sertifika geçerli mi, expired mi?
5. HTTP cevap dönüyor mu? (L7)
curl -v https://site.com.tr
→ 200, 502, timeout, hangi durum kodu?
6. Yerelde sunucu çalışıyor mu? (Process)
ss -tlnp | grep ':80\|:443'
systemctl status nginx
Bu sıralı kontrol, problemin hangi katmanda olduğunu netleştirir. DNS'tense Nginx'i tekrar başlatmaktan başlamak zaman kaybıdır.
Senaryo 2: "Yavaş Sayfa Yükleme"
Sayfa açılıyor ama yavaş. Olası nedenler ve tanılama:
1. TCP retransmission var mı?
ss -ti veya tcpdump'la SYN+RST takibi
→ "retrans:5/100" gibi değer ya da çok RST varsa ağ kalitesi sorunu
2. RTT yüksek mi?
ping -c 100 <client_IP>
→ 200ms üstüne CDN/PoP gerek
3. Path MTU sorunu var mı?
ping -M do -s 1472 <hedef>
→ "Frag needed" hata, MTU düşür (1400 dene)
4. Path üzerinde paket kaybı var mı?
mtr -n -c 100 <hedef>
→ %1 üstüne hop'larda kayıp = ara router/peering sorunu
5. Application seviye yavaşlık mı?
Application log, slow query log, profiler kullan
Senaryo 3: "Bağlantı Reset (ECONNRESET)"
İstemciden "connection reset by peer" hatası geliyorsa olası nedenler:
1. Server uygulamanız RST gönderiyor (ör. timeout iç hata)
→ Application log kontrol
2. Firewall middlebox bağlantıyı kopardı
→ NAT/firewall timeout'larını incele
→ TCP keepalive ayarlarını sıkılaştır
3. Load balancer health check sırasında RST atıyor
→ LB ve backend timeout uyumu kontrol
4. SYN flood koruma kerteriz alıyor
→ syncookies, conntrack limit kontrol
tcpdump'ta tcp[tcpflags] & tcp-rst != 0 filtresi ile RST gönderen tarafı tespit edebilirsiniz.
Buyukweb VDS Network Stack Özelliği
Buyukweb VDS'leri KVM hypervisor üzerinde virtio-net sanal NIC sürücüsüyle çalışır. Bu mimari:
- Düşük overhead — paravirtualized NIC, native hıza yakın throughput
- Multi-queue support — yüksek RPS yüklerinde CPU dağılımı
- TSO / GSO / GRO — büyük paketleri kernel toplama/parçalama (offload)
- Vhost-net — paket gönderim iş parçacığı kernel modunda, latency düşük
Veri merkezi tarafında çoklu taşıyıcı BGP ile bağlantı; trafiğiniz redundant fiber üzerinden ve DDoS scrubbing katmanı üzerinden sunucuya ulaşır. Tier 3 yedeklilik:
- Çift güç beslemesi (UPS + jeneratör)
- Çoklu fiber giriş yolu
- N+1 chiller soğutma
- 7/24 fiziksel güvenlik
VDS root erişiminizle:
- WireGuard tüneli kurabilirsiniz (UDP 51820 default)
- IPSec site-to-site VPN
- nftables / iptables ile L3-L4 firewall
- HAProxy / Nginx ile L7 yük dengeleme
- BIRD / FRRouting ile dynamic routing (eğer kendi IP bloğunuz varsa)
- tcpdump ile kapsamlı packet analizi
cPanel paylaşımlı paketlerimizde root yok ama panel üzerinden DNS yönetimi, e-posta SPF/DKIM/DMARC, SSH erişim (sınırlı), .htaccess ile L7 yönetim mümkün.
Modern Trendler ve Yenilikler (2026)
TCP/IP ailesi yıllar içinde sabit değil; aktif gelişiyor.
IPv6 Hızlanması
2026 itibariyle Google trafiğinin %45 üstünde IPv6 geliyor (Google IPv6 statistic). Türkiye'de mobil operatörler IPv6'yı zorunlu, sabit hatta CGNAT hâlâ baskın. Hosting tarafında AAAA kaydı modern operasyon standardı.
HTTP/3 Yaygınlaşması
Cloudflare verilerine göre 2026'da global HTTP trafiğinin %30 üstü HTTP/3 üzerinden. YouTube, Facebook, TikTok, Cloudflare-fronted siteler hemen hemen tamamen QUIC üzerinde.
BBR ve Modern Congestion Control
Linux 5.0+ kernel'de BBR v2 yaygınlaşıyor. YouTube, Spotify, ChatGPT gibi büyük hizmetlerin tercihi.
TLS 1.3 Hâkimiyeti
2026 itibariyle modern siteler için TLS 1.3 zorunlu kabul ediliyor; TLS 1.2 sadece legacy uyumluluk için.
DNS over HTTPS (DoH) / DNS over TLS (DoT)
DNS sorgusu da artık HTTPS üzerinden gidiyor. Cloudflare 1.1.1.1, Google 8.8.8.8 DoH desteği veriyor; mobil OS'ler ve modern tarayıcılar varsayılan açıyor.
eBPF — Paket İşleme Devrimi
eBPF (extended Berkeley Packet Filter) Linux kernel'de programlanabilir paket işleme. Cilium, Calico, Katran gibi modern ağ projeleri eBPF ile L3-L7 hızlı paket işleme yapıyor.
Sık Sorulan Sorular (SSS)
"TCP mi UDP mi kullanmalıyım?"
Kullanım senaryosuna bağlı. Veri kaybı kabul edilemez ve sıralama önemliyse → TCP (web, mail, dosya transfer, veritabanı). Düşük gecikme kritik, bazı paket kaybı tolere edilebilir → UDP (oyun, VoIP, video streaming, DNS). Modern uygulamalar artık QUIC kullanarak ikisinin avantajlarını birleştirebiliyor.
"QUIC neyin yerini alır?"
QUIC, TCP + TLS kombinasyonunun yerini alıyor. UDP üzerine kurulu ama TCP'nin sağladığı tüm garantileri (sıralama, retransmission, congestion control) kendi uygulayıp + TLS 1.3'ü entegre ederek tek katmanda sağlıyor. Connection migration ve 0-RTT bonusu da gelir. HTTP/3 zorunlu olarak QUIC üstüne kurulu.
"IPv6 zorunlu mu? IPv4'le devam edebilir miyim?"
Şu an için IPv6 zorunlu değil ama önerilir. Dual-stack (IPv4 + IPv6) yaklaşımı en pragmatik: hem eski hem yeni istemcilere ulaşırsınız. Mobil operatörlerde IPv6 zaten standart; web hosting tarafında 2026'da modern bir tercih AAAA kaydı yayımlamaktır. Buyukweb VDS paketlerimizde IPv6 desteği mevcut; talebinizi destek hattına iletebilirsiniz.
"Port 80'i değiştirebilir miyim?"
Teknik olarak evet — Nginx/Apache konfigürasyonunda listen 8080; yazabilirsiniz. Ama kullanıcı tarayıcıdan port numarası yazmak zorunda kalır (örn. https://site.com.tr:8443/); UX kötüleşir. Önerilen uygulama: standart 80/443'ü açık tut, arkada non-standard port'larda admin paneli/farklı uygulamalar dinlesin. Standart portları kapatmanız meşru kullanıcıları engeller.
"TCP retransmission oranı ne kadar olmalı?"
Sağlıklı bir TCP bağlantısında retransmission %0,5 altında olmalı. %1-2 sınır seviyesi — ağda hafif paket kaybı var demektir. %3+ ciddi sorun — fiber/peering bağlantısında hata, conntrack tablosu dolu, WAN cihazı arızalı olabilir. ss -ti ile retrans ratio'yu görebilirsiniz.
"NAT arkasındayım, mail sunucu kurabilir miyim?"
Hayır, NAT arkasındaki bir host outbound port 25 mail göndermesi çoğu operatör tarafından engellenir; inbound port 25 ise zaten ev/ofis IP'sinde DNSBL'de kara listede çıkacaktır. Mail sunucu için public IP + clean reputation gerekir. Buyukweb VDS dedicated public IP ile gelir; mail sunucusu kurmaya uygun. cPanel paylaşımlı pakette de mail servisi standart.
"Path MTU Discovery nedir?"
Bir paketin uçtan uca yolculukta geçtiği tüm linkler arasındaki en küçük MTU'yu bulma süreci. Sender büyük paket gönderir DF (Don't Fragment) bayrak ile; ara router yetersiz MTU varsa ICMP "Fragmentation Needed" döner; sender paketi küçültür. Eğer ICMP filtrelenmişse PMTUD bozulur ve büyük paketler sessizce kaybolur — "PMTU black hole". Bu yüzden ICMP Type 3 Code 4 mesajlarına firewall'da izin verin.
"Kendi kernel TCP parametrelerimi ayarlayabilir miyim?"
VDS root erişimiyle evet. Sık ayarlanan parametreler:
```bash
/etc/sysctl.conf
net.core.somaxconn = 4096 # Listen backlog
net.ipv4.tcp_max_syn_backlog = 4096 # SYN queue
net.ipv4.tcp_tw_reuse = 1 # TIME_WAIT reuse
net.ipv4.tcp_fin_timeout = 30 # FIN timeout
net.ipv4.tcp_keepalive_time = 600 # Keepalive 10dk
net.ipv4.tcp_congestion_control = bbr # BBR
net.core.default_qdisc = fq # Fair queueing
```
Yüksek RPS Nginx, busy DB sunucuları için kritik tuning'ler. Yanlış değer performans düşürebilir; benchmark öncesi/sonrası karşılaştırın.
Sonuç ve Sonraki Adımlar
TCP/IP protokol ailesi, 1981'deki RFC 791 ve 793'ten beri internet omurgasının temel mimarisi. Bu rehber kapsamında işlenenler:
- Tarihsel bağlam — ARPANET, NCP, Cerf-Kahn tasarımı, RFC 791/793, 1 Ocak 1983 Flag Day
- OSI vs TCP/IP — 7-katman teorik referans, 5-katman pratik model
- L1-L7 katman katman — Fiziksel, veri bağlantı, ağ, taşıma, uygulama protokolleri
- TCP detayları — 3-way handshake, sliding window, congestion control, retransmission, SACK
- UDP ve QUIC — Connectionless, hız, modern transport evrimi
- IPv4 + IPv6 — Adresleme, CIDR, NAT, ICMP, ARP
- HTTP/2 ve HTTP/3 — Modern web protokol evrimi
- TLS 1.2/1.3 — Şifreli transport, handshake mimarisi
- Port numaraları — Well-known, registered, ephemeral
- Troubleshooting toolbox — ping, traceroute, mtr, dig, tcpdump, ss, nmap
- VDS pratik senaryolar — Site açılmama, yavaşlık, ECONNRESET
Modern hosting yöneticileri için kavramsal mimari bilgisi olmadan saha kararları vermek zor. Bu rehber, Buyukweb VDS / cPanel müşterilerinin protokol seviyesinde "neden ne olur" sorusuna yanıt bulmasını sağlar.
İlgili Büyükweb Hizmetleri
- VDS Sunucu — KVM virtio-net, root erişim, TCP tuning özgürlüğü
- Dedicated Sunucu — Fiziksel kontrol, yüksek throughput
- cPanel Web Hosting — Yönetilen ortam, SPF/DKIM/DMARC otomatik
- Paket Karşılaştırma — İhtiyaca göre paket seçimi
İlgili Ağ Rehberleri
- BGP ve Routing Protokolleri
- OSPF Link-State Routing
- DHCP Sunucu ve DORA
- DNS Nasıl Çalışır
- DNS Kayıt Türleri
- IPv6 Geçişi ve Dual-Stack
- Ağ Güvenliği IDS/IPS
- Linux Performans İzleme
TCP/IP protokol seviyesinde mimari planlama, VDS tuning veya network troubleshooting desteği için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz. Bursa Tier 3 veri merkezimizden KVM virtio-net VDS altyapısı ve çoklu taşıyıcı BGP omurga ile hizmet veriyoruz.
Ağ & Network İlgili Hizmetlerimiz
Bu yazıda anlatılan teknik konuyu profesyonel altyapıyla deneyimleyin
Etiketler:
