İnternet Protokolleri: TCP/IP’den HTTP/3’e Derinlemesine Bakış

Bir bağlantı sorununun kaynağı çoğu zaman uygulama değildir. DNS yanıtı, IP rotası, TCP veya QUIC portu, TLS el sıkışması ve HTTP yanıtı ayrı ayrı ölçülmelidir. HTTP/3, TCP'nin yerine QUIC'i koyar; fakat UDP/443 erişimi, TLS 1.3 ve istemci desteği olmadan tek başına hız garantisi vermez.

İnternet Protokolleri: Dijital Dünyanın Görünmez İskeleti

Bir web sayfası açılırken yalnızca tarayıcı ile sunucu konuşmaz. DNS adı IP adresine çevirir, yönlendiriciler paketleri taşır, TCP veya QUIC akışı yönetir, TLS veriyi şifreler ve HTTP uygulama isteğini tanımlar. Bu katmanları ayırabilmek, VPS üzerinde yaşanan bağlantı, gecikme ve güvenlik sorunlarını doğru yerde aramayı sağlar.

İnternet protokollerini bilmek, her paketin içeriğini ezberlemek anlamına gelmez. Hangi katmanın hangi sorumluluğu taşıdığını ve bir arıza sırasında hangi ölçümün yapılacağını bilmek çoğu durumda yeterlidir.

Ağ Mimarisi ve TCP/IP Modelinin Temelleri

İnternet protokolleri, verilerin adreslenmesini, taşınmasını ve işlenmesini tanımlayan standartlardır. Bu standartlar katmanlı bir modelle birlikte çalışır. OSI modeli yedi katmanlı bir referans çerçevesidir; pratikte kullanılan TCP/IP modeli ise çoğunlukla dört katmanla anlatılır. Bazı kaynaklar fiziksel ve veri bağlantısı katmanlarını ayırarak beş katmanlı gösterim kullanır.

TCP/IP Modelinin Katmanları ve Görevleri

• Uygulama Katmanı: HTTP, DNS, SMTP, SSH ve benzeri protokoller uygulamaların ağ hizmetlerini kullanmasını sağlar. Veri biçimi ve uygulama mesajlarının anlamı bu katmanda belirlenir.
• Taşıma Katmanı: Uygulamalar arasındaki akışı yönetir. TCP sıralı ve güvenilir aktarım sunarken UDP, QUIC gibi protokollerin temelini oluşturan daha yalın datagram aktarımı sağlar.
• İnternet Katmanı: IP paketlerinin kaynak ve hedef adreslerini kullanarak ağlar arasında yönlendirme yapılır. IPv4 ve IPv6 bu katmanın başlıca protokolleridir.
• Ağ Erişim Katmanı: Ethernet ve Wi-Fi gibi teknolojiler üzerinden çerçevelerin iletilmesini, MAC adreslerini ve fiziksel bağlantıyı kapsar.

Katmanlar birbirinden tamamen bağımsız değildir; fakat sorumlulukların ayrılması teşhisi kolaylaştırır. Örneğin bir DNS sorgusunun yanıt vermemesi, uygulama sorunu gibi görünse de UDP/53 erişimi, yönlendirme veya güvenlik duvarı kuralı kaynaklı olabilir.

Ne yapılmalı – Bir bağlantı sorununda uygulama loguna geçmeden önce DNS çözümlemesini, IP erişimini, ilgili portu ve TLS el sıkışmasını ayrı ayrı test edin.

TCP ve IP: İnternet’in Kalbi Atıyor

TCP ve IP aynı işi yapmaz. IP, paketlerin ağlar arasında adreslenmesini ve yönlendirilmesini sağlar; TCP ise iki uçtaki uygulamalar arasında güvenilir bir bayt akışı kurar. Bu ayrım, sorunun ağ yolunda mı yoksa uygulamanın dinlediği portta mı olduğunu anlamak için kritiktir.

IP (Internet Protocol): Adresleme ve Yönlendirme

IP paketleri kaynak ve hedef adreslerini taşır. Router’lar hedef adresi yönlendirme tablolarıyla karşılaştırır ve paketi bir sonraki ağa iletir. IP, teslimat garantisi vermez; paket kaybı, sıra değişikliği veya yinelenen paketler için güvenilirlik mekanizması taşıma katmanına ya da uygulamaya bırakılır.

• IPv4: 32 bit adres kullanır. 192.168.1.1 gibi adresler toplam 232 teorik adres alanına sahiptir; özel ağlarda RFC 1918 kapsamındaki 10.0.0.0/8, 172.16.0.0/12 ve 192.168.0.0/16 blokları kullanılır.
• IPv6: 128 bit adres kullanır. Örnek bir dokümantasyon adresi 2001:db8::1 biçimindedir; 2001:db8::/32 gerçek yönlendirme için değil, örnekler için ayrılmıştır.

Bir sunucunun IP adresi tek başına hizmetin çalıştığını göstermez. DNS kaydı doğru olabilir, fakat güvenlik duvarı ilgili portu engelliyor veya servis yalnızca 127.0.0.1 üzerinde dinliyor olabilir.

TCP (Transmission Control Protocol): Güvenilir Bağlantı ve Akış Kontrolü

TCP, bağlantı odaklı, sıralı ve güvenilir bir aktarım sağlar. Web’in HTTP/1.1 ve HTTP/2 sürümleri, SSH ve çoğu veritabanı bağlantısı TCP kullanır. Modern Linux sistemlerinde TCP soketlerini incelemek için eski netstat yerine genellikle ss tercih edilir.

TCP’nin başlıca mekanizmaları şunlardır:

• Üç yönlü el sıkışma: Bağlantı genellikle SYN, SYN-ACK ve ACK paketleriyle kurulur. Bu aşama tamamlanmadan uygulama verisi normal akışa girmez.
• Sıralı teslimat: Segmentler sıra numaralarıyla takip edilir; kayıp segmentler yeniden gönderilir.
• Akış kontrolü: Alıcının ilan ettiği pencere, göndericinin alıcı tamponunu aşmasını önler.
• Tıkanıklık kontrolü: TCP, ağın kapasitesini gözlemleyerek gönderim hızını ayarlar. Bu, alıcı tamponundan farklı bir mekanizmadır.
• Hata kontrolü: Sağlama toplamı ve onay mekanizmaları bozuk veya kayıp verinin fark edilmesine yardımcı olur.

TCP’nin güvenilirliği gecikme maliyeti doğurur. Tek bir TCP bağlantısında kayıp segmentin yeniden iletilmesi, aynı bağlantı üzerindeki diğer veri akışlarını da bekletebilir; HTTP/2’nin uygulama katmanındaki çoklaması bu taşıma katmanı etkisini ortadan kaldırmaz.

UDP (User Datagram Protocol): Hız ve Basitlik

UDP bağlantı kurma, sıralama ve yeniden iletim garantisi sunmayan bir taşıma protokolüdür. DNS’in çoğu sorgusu UDP/53 kullanır; büyük yanıtlar veya aktarım koşulları gerektiğinde TCP/53’e geçiş görülebilir. Gerçek zamanlı ses, oyun ve bazı tünel protokolleri de UDP’nin düşük protokol yükünden yararlanır.

UDP’nin hızlı olması otomatik değildir. Uygulamanın paket kaybını, tekrarları ve hız kontrolünü nasıl ele aldığı belirleyicidir. QUIC de UDP üzerinde çalışır, fakat güvenilir akışlar, şifreleme ve tıkanıklık kontrolünü kendi protokol katmanında sağlar.

Ne yapılmalı – Bir portu test ederken yalnızca ping sonucuna güvenmeyin; TCP için ss ve nc, UDP için servis logları ve tcpdump ile gerçek trafiği doğrulayın.

Uygulama Katmanı Protokolleri ve Web’in Evrimi: HTTP/1.x’ten HTTP/3’e

Uygulama katmanı, taşınan verinin ne anlama geldiğini belirler. HTTP bir web isteğinin yöntemini, başlıklarını ve gövdesini tanımlar; DNS isim çözümlemesini, SMTP e-posta aktarımını, SSH ise uzak kabuk ve tünel erişimini düzenler.

HTTP/1.x: Web’in İlk Adımları

HTTP/1.0 ve HTTP/1.1 metin tabanlı bir mesaj biçimi kullanır. HTTP/1.1 kalıcı bağlantılar ve parça parça aktarım gibi özellikler getirdi; ancak tek bağlantı üzerindeki isteklerin sıralı işlenmesi pratikte gecikme oluşturabiliyordu.

• Head-of-Line Blocking: Bir istek geciktiğinde aynı bağlantıdaki sonraki istekler bekleyebilirdi.
• Çok sayıda TCP bağlantısı: Tarayıcılar gecikmeyi azaltmak için aynı sunucuya birden fazla bağlantı açabiliyordu.
• Başlık tekrarı: Çerezler ve diğer başlıklar her istekte yeniden taşınabiliyor, gereksiz veri oluşturabiliyordu.

HTTP/2: Performans Devrimi

HTTP/2, RFC 9113 ile standartlaştırılmış ikili çerçeveleme ve çoklama yaklaşımını kullanır. Genellikle TLS üzerinden h2 ALPN kimliğiyle sunulur. Tarayıcı desteği pratikte HTTPS ile birlikte değerlendirilmelidir.

• Çoklama: Tek TCP bağlantısı içinde birden fazla istek ve yanıt bağımsız akışlar olarak taşınır.
• Başlık sıkıştırma: HPACK, tekrar eden başlık alanlarının daha verimli taşınmasını sağlar.
• İkili çerçeveleme: Mesajlar metin satırları yerine çerçevelere ayrılır.
• Sunucu itmesi: HTTP/2 standardında bulunur; ancak tarayıcı ve sunucu ekosisteminde sınırlı destek gördüğü için güncel kurulumlarda temel performans stratejisi olarak kullanılmamalıdır.

HTTP/2, uygulama katmanındaki beklemeyi azaltır; TCP’nin kayıp segment sonrası tüm bağlantıyı etkileyen davranışını değiştirmez. Bu ayrım, yüksek paket kaybı görülen mobil veya uzak bağlantılarda önem kazanır.

HTTP/3: Geleceğin Web Protokolü ve QUIC

HTTP/3, RFC 9114 ile standartlaştırılmıştır ve QUIC üzerinde çalışır. QUIC’in temel tanımı RFC 9000, TLS ile bağlantısı ise RFC 9001 kapsamındadır. HTTP/3 için istemci ve sunucu arasında çoğunlukla UDP/443 erişimi gerekir; TCP/443 açık olsa bile UDP engelleniyorsa bağlantı HTTP/2 veya HTTP/1.1’e düşebilir.

• UDP üzerinde QUIC: QUIC, UDP’yi yalnızca taşıma kabı olarak kullanır; güvenilir akış, yeniden iletim ve tıkanıklık kontrolünü kendi içinde sağlar.
• Akış bazlı HOLB azaltımı: Bir akıştaki kayıp paket, aynı bağlantıdaki diğer QUIC akışlarını TCP’deki gibi zorunlu olarak durdurmaz.
• Entegre TLS 1.3: QUIC bağlantıları TLS 1.3 kullanır; TLS el sıkışması QUIC bağlantı kurulumu ile birlikte ilerler.
• 0-RTT: Daha önce kurulmuş bağlantılarda erken veri gönderilebilir. Bu veri yeniden oynatma riskine açık olabileceğinden, sunucu 0-RTT isteklerini yalnızca idempotent işlemlerde kabul etmelidir.
• Bağlantı geçişi: Connection ID sayesinde istemcinin ağ adresi değiştiğinde bağlantı bazı durumlarda korunabilir; bu garanti her ağ cihazı ve NAT davranışı için mutlak değildir.

HTTP/3’ü etkinleştirmek yalnızca bir web sunucusu direktifi eklemekten ibaret değildir. UDP/443 güvenlik duvarında açık olmalı, sertifika ve ALPN doğru sunulmalı, istemci desteği izlenmeli ve TCP tabanlı geri dönüş yolu korunmalıdır.

Ne yapılmalı – HTTP/3’ü açmadan önce curl --http3 veya tarayıcı geliştirici araçlarıyla doğrulama yapın; UDP/443 trafiğini güvenlik duvarı ve paket yakalama kayıtlarında ayrıca kontrol edin.

Güvenlik ve Protokoller: Bir Sistem Yöneticisinin Önceliği

Bir protokolün çalışması, güvenli çalıştığı anlamına gelmez. Port erişimi, kimlik doğrulama, şifreleme, sertifika doğrulaması ve loglama birlikte değerlendirilmelidir.

TLS/SSL ve HTTPS: Verilerin Şifreli Yolculuğu

HTTPS, HTTP’nin TLS ile korunmuş halidir. Güncel kurulumlarda TLS 1.2 ve özellikle TLS 1.3 tercih edilir; TLS 1.0 ve TLS 1.1, RFC 8996 ile kullanımdan kaldırılmıştır. SSL adı günlük dilde kalsa da SSLv2 ve SSLv3 güvenli seçenekler değildir.

TLS sertifikası sunucu kimliğini doğrular, şifreleme anahtarlarının kurulmasını sağlar ve aktarımın değiştirilmesini zorlaştırır. Sertifika süresi, hostname eşleşmesi, ara sertifikalar, SNI ve ALPN birlikte kontrol edilmelidir. VPS veya Dedicated Sunucu yönetirken bu ayarların sorumluluğu altyapı yöneticisine aittir.

Diğer Güvenlik Odaklı Protokoller

• SSH: Uzak kabuk, port yönlendirme ve kimlik doğrulama için kullanılır. Parola yerine anahtar tabanlı erişim ve sınırlı kullanıcı yetkileri tercih edilmelidir.
• SFTP: SSH üzerinden çalışan dosya aktarım protokolüdür; FTP’nin TLS’li biçimiyle karıştırılmamalıdır.
• VPN protokolleri: IPsec, OpenVPN ve WireGuard farklı kimlik doğrulama, anahtar yönetimi ve tünel tasarımlarına sahiptir. WireGuard genellikle UDP kullanır; varsayılan portu 51820/UDP’dir, fakat kurulum bunu değiştirebilir.

SSH portunu değiştirmek tek başına güvenlik sağlamaz. Daha etkili bir temel; güncel paketler, anahtar tabanlı erişim, root girişinin sınırlandırılması, MFA’nın uygun yerde kullanılması, fail2ban ve nftables kurallarının loglarla doğrulanmasıdır.

Ne yapılmalı – TLS sürümlerini, sertifika zincirini, SSH kimlik doğrulamasını ve açık portları düzenli aralıklarla tarayın; yaptığınız her değişikliği geri alma adımıyla birlikte kaydedin.

Protokol Sorunlarını Giderme ve İzleme: Pratik Yaklaşımlar

Ağ teşhisinde tek bir araç bütün resmi göstermez. Önce isim çözümlemeyi, ardından rota ve port erişimini, sonra TLS ve uygulama yanıtını ayrı katmanlarda ölçmek daha az varsayım üretir.

• ping: ICMP erişimi ve yaklaşık gecikmeyi ölçer. ICMP engellenmişse başarısız olması, TCP veya HTTP’nin de başarısız olduğu anlamına gelmez.
• mtr: Traceroute yaklaşımını canlı kayıplar ve gecikme ölçümüyle birleştirir. Son hopta kayıp görünmeden önce ara hoplardaki ICMP rate limit’lerini yorumlayın.
• dig: DNS kayıtlarını, sorgu türünü ve yanıt sunucusunu inceler. Hızlı kontrol için dig +short A example.com ve dig +short AAAA example.com kullanılabilir.
• ss: Dinleyen soketleri ve bağlantı durumlarını gösterir. Örneğin ss -lntup, TCP ve UDP dinleyicilerini süreç bilgisiyle listeler.
• tcpdump: Paketlerin gerçekten arayüze ulaşıp ulaşmadığını gösterir. Üretimde kapsamı daraltın; örneğin tcpdump -ni eth0 port 443 çıktısını süre ve dosya boyutuyla sınırlayın.
• curl: HTTP durum kodu, yönlendirme, TLS ve protokol pazarlığını kontrol eder. curl -I --http2 https://example.com veya desteklenen ortamda curl --http3 -I https://example.com kullanılabilir.
• Güvenlik duvarı logları: nftables kurallarının beklenen trafiği engelleyip engellemediğini gösterir. Kuralı değiştirmeden önce sayaçları ve mevcut konfigürasyonu kaydedin.

Bir servis yanıt vermediğinde önce süreci yeniden başlatmak cazip gelir. Daha güvenli sıra; systemctl status, servis logları, ss ile dinleme durumu, yerel bağlantı testi ve dış ağ testi şeklindedir. Log okumadan yeniden başlatmak, kanıtı ortadan kaldırabilir.

Ne yapılmalı – Her ağ arızasında zaman damgası, istemci IP’si, hedef port, DNS yanıtı ve ölçülen gecikmeyi kaydedin; teşhis sırasında aynı testi farklı ağlardan tekrarlayın.

Geleceğin Protokolleri ve Ağlar: Yenilikler Yolda

HTTP/3 artık yalnızca deneysel bir seçenek değildir; fakat her site için otomatik olarak daha hızlı olacağı da söylenemez. Paket kaybı, istemci desteği, CDN davranışı, UDP erişimi ve sunucu yükü ölçülmeden yapılan geçişler beklenen kazanımı vermeyebilir.

• IPv6’nın yaygınlaşması: Çift yığın kurulumlarında A ve AAAA kayıtları, yönlendirme, firewall ve uygulama dinleme adresleri birlikte doğrulanmalıdır.
• Şifreleme ve kuantum sonrası hazırlık: Yeni algoritmaların üretim sistemlerine eklenmesi standartlar, kütüphane desteği ve anahtar yaşam döngüsüyle birlikte ele alınmalıdır. TLS 1.3’ü kapatıp deneysel bir çözüm eklemek güvenlik planı değildir.
• Ağ sanallaştırma ve programlanabilir ağlar: SDN, eBPF ve servis ağı yaklaşımları gözlemlenebilirliği artırabilir; karmaşıklık da aynı ölçüde büyür. Değişikliklerin kapsamı, geri dönüşü ve ölçümü önceden tanımlanmalıdır.

Sistem yöneticileri için en değerli beceri yeni protokol adlarını bilmekten çok, protokolü ölçülebilir bir varsayımla devreye almaktır. HTTP/3’ü açarken önce bir alan adında etkinleştirmek, gerçek istemci trafiğini izlemek ve sorun halinde HTTP/2’ye geri dönmek kontrollü bir yaklaşımdır.

Son Söz: Dijital Dünyanın Kılcal Damarları

TCP/IP modeli, IP’nin yönlendirme görevini, TCP ve UDP’nin taşıma tercihlerini, TLS’in güvenlik katmanını ve HTTP’nin uygulama mesajını birbirinden ayırır. HTTP/3 ve QUIC bu yapıyı ortadan kaldırmaz; taşıma katmanındaki bazı sınırlamaları farklı bir tasarımla ele alır.

Bir bağlantı sorununda önce katmanı bulun, sonra ölçün. dig, mtr, ss, tcpdump ve curl çoğu VPS arızasında yeterli başlangıç setidir. Kendi altyapınızı kurarken bulut sunucu veya VDS sanal sunucu seçiminin yanında UDP erişimi, IPv6 desteği, firewall yönetimi ve ölçüm imkanlarını da değerlendirin.

Uygulama Kontrol Listesi

• DNS için A ve AAAA kayıtlarını ayrı ayrı doğrulayın.
• Sunucunun ilgili TCP veya UDP portunda dinlediğini kontrol edin.
• Firewall sayaçlarını ve loglarını değişiklikten önce kaydedin.
• TLS sertifikasının süresini, hostname'ini ve zincirini doğrulayın.
• HTTP/3 için UDP/443 erişimini dış ağdan test edin.
• 0-RTT isteklerini yalnızca güvenli ve idempotent işlemlerle sınırlayın.
• Ağ değişikliklerini önce staging veya düşük riskli bir alan adında deneyin.

Sık Sorulan Sorular