HTTP / HTTPS ve Web Socket

Bu yazıda genel hatlarıyla HTTP isteklerinin ne olduğunu, OSI katmanınında nerde yer aldığını, nasıl çalıştığını ve benzerlikleri ve farklılıklarıyla birlikte Web Socket kavramının ne olduğunu yine kafamızda canlandırabileceğimiz bir akışta anlatmayaca çalışacağız.

Bu yazı frontend geliştiricileri için “nice to have” backend geliştiricileri için “must” olmakla beraber iletişim protokollerini öğrenmeye yeni başlayan herkes için oldukça öğretici olacaktır diye ümit ediyorum.

HTTP Nedir? Nasıl Çalışır?

HTTP, web tarayıcıları ile sunucular arasında iletişim kurmaya yarayan bir protokoldür. Web’de gördüğümüz her şey — her görsel, her metin, her buton — aslında uzakta bir sunucuda barınan ve bir IP adresi üzerinden yayın yapan bir kod tabanından gelir.Bu bağlamda HTTP bu atılan isteğin formatı, şekli ve üsulunu belirleyen bir protokoldür.

En basit haliyle, HTTP bir “istek-cevap” (request-response) modeli üzerine kuruludur. İstemci (genellikle bir web tarayıcısı) sunucuya bir istek gönderir, sunucu buna bir cevap verir ve bağlantı kapanır. Buradaki “bağlantı kapanır” vurgusunun önemini yazının ilerleyen aşamalarında daha detaylıca anlayacağız.

Şimdi, bu sürecin adım adım nasıl işlediğini inceleyelim:

1. İstek Başlatma: Tarayıcıya bir site adresi girersiniz, örneğin example.com. Tarayıcı, bu domain’in hangi IP adresine karşılık geldiğini öğrenmek için DNS (Domain Name System) sunucusuna sorgu atar.
2. İstek Hazırlama: DNS’ten IP adresini aldıktan sonra, tarayıcı HTTP isteğini hazırlar. Bu istekte method (GET, POST gibi), path (örneğin /about), header’lar (kullanıcı bilgileri, kabul edilen formatlar) ve opsiyonel olarak request body (veri) bulunur. Sıklıkla HTTP yerine HTTPS görürüz. Sondaki “S”, güvenlik anlamına gelir ve TCP protokolü üzerine eklenen TLS/SSL katmanından kaynaklanır. (Bunu birazdan detaylı ele alacağız.)
3. Bağlantı Kurulumu: İstek atılmadan önce, bir “el sıkışma” (handshake) süreci yaşanır. Bu, bağlantının güvenilirliğini sağlar.

HTTP’de El Sıkışma (Handshake) Protokolü

HTTP isteklerindeki el sıkışma, tarayıcı ile sunucu arasında veri alışverişi başlamadan önceki kritik bir adımdır. Bu süreç, performans, güvenlik ve bağlantı güvenilirliği açısından web’in en temel taşlarından biridir.

HTTP, application layer’da (OSI modelinin 7. katmanı) çalışır, ancak bağlantı kurulumu transport layer’da (4. katman) gerçekleşir. Genellikle TCP (Transmission Control Protocol) kullanılır. Bu katman hiyerarşisinden şunu anlayabiliriz: HTTP protokolünün çalışması için TCP katmanına ya da handshake protokolüne ihtiyaç yoktur aslında. Bunun gerekliliğinin en büyük sebebi hem güvenlik hem de aktarılan verinin bütünlüğünün kontrol edilebilir olması Bu handshake aşaması şu şekilde çalışır :

TCP Three-Way Handshake:

• İstemci, sunucuya SYN (synchronize) paketi gönderir: “Bağlantı kurmak istiyorum.”
• Sunucu, SYN-ACK (synchronize-acknowledge) ile cevap verir: “Tamam, kabul ediyorum.”
• İstemci, ACK (acknowledge) gönderir: “Anlaşıldı, bağlantı hazır.”

Bu aşamadan sonra HTTP isteği gönderilebilir. TCP, bağlantı temelli (connection-oriented) bir protokoldür: Veri paketlerini numaralandırır, kayıpları tespit eder ve yeniden gönderir. Ayrıca akış kontrolü (alıcıyı boğmamak için hız ayarı) ve tıkanıklık kontrolü (ağ yoğunluğuna göre yavaşlama) yapar.

TCP’nin alternatifi UDP (User Datagram Protocol)’dir:

• TCP: Bağlantı temelli, güvenilir, sıralı veri iletimi. Kayıpları düzeltir, ama daha yavaş.
• UDP: Bağlantısız, hızlı ama güvenilmez. Paketler kaybolabilir veya sırası bozulabilir. Video streaming gibi gecikme hassas uygulamalarda tercih edilir. Herhangi bir güvenlik vaadi yoktur, bağlantı kurmak için bir girişimde bulunmaz, gönderilen ve alınan paketlerin takibini ya da kontrolünü yapmaz.

HTTP, TCP olmadan tam işlevsel bir şekilde çalışamaz; çünkü bağlantı kurulumu ve veri transferi için transport layer protokolüne ihtiyaç duyar.

HTTP Stateless’tır, ama Sessionless değildir

HTTP stateless bir protokoldür: Her istek-cevap çifti bağımsızdır. Atılan her istek tüm header, body, cookie ve daha nice detayıyla birlikte yepyeni, kendisinden öncekilerden tamamen bağımsız bir istektir. Sunucu, önceki istekleri hatırlamaz. Ancak bu açığı kapatmak için cookie’ler, session’lar veya token’lar kullanılır. Bunlar sayesinde, aynı kullanıcı için bir “session” oluşturup state’i koruyabilirsiniz. Yani HTTP sessionless değil; session yönetimi üst katmanlarda yapılır.

HTTPS: “S” Ne Anlama Gelir?

HTTPS, HTTP’nin güvenli versiyonudur. TCP bağlantısı kurulduktan sonra TLS (Transport Layer Security) el sıkışması başlar. TLS el sıkışması ile paylaşılan şifreleme algoritmaları tarafların gönderilen veriyi korumak için kullanmayı tercih ettiği ekstra bir katman gibidir. Direkt olarak ürünü göndermek yerine bir bulmaca ile açılan bir kutu ile gönderdiğinizi düşünün, karşı tarafla da bulmacının kılavuzunu paylaşırsınız ve araya birisi girerse paketin gizliliğinin ifşa olmasının tek yolu bulmacanın kılavuzunu ele geçirmedir. Kılavuz diye bahsettiğimiz bu sertifikaların paylaşılması ile alakalı da oldukça kapsamlı ve detaylı birçok method vardır; kendi kendine bağımsız ve titiz bir süreçtir:

• Tarayıcı, desteklediği şifreleme algoritmalarını sunucuya bildirir.
• Sunucu, sertifikasını gönderir (kimliğini kanıtlar).
• Tarayıcı sertifikayı doğrular (güvenilir otorite tarafından imzalanmış mı? Domain eşleşiyor mu?).
• İki taraf, ortak bir şifreleme anahtarı üzerinde anlaşır.

Bundan sonra tüm veri şifreli akar. TLS, HTTP ile TCP arasına girerek güvenliği sağlar. Bu, man-in-the-middle saldırılarını önler ve veriyi korur.

HTTP’nin Sınırlılıkları

HTTP yukarda bahsettiğimiz ve dahası bahsetmediğimiz birçok açıdan oldukça muhteşem bir protokole sahiptir. Oldukça kullanışlı olmasına rağmen eksik kaldığı bazı alanlar vardır.

Bu alanların ortak özelliği her paket teslimi için bir istek atma zorunluluğu olmaması talebidir.

Örneğin whatsapp’da biz karşı taraftan mesaj gelip gelmediğini eğer HTTP ile elde ediyor olsaydık ne yapmamız gerekirdi : en iyi senaryoda belli aralıklarla istek atıp yeni mesaj var mı diye kontrol etmemiz gerekirdi. Bu da network ağında oldukça gereksiz bir trafik anlamına gelir. Evde geliştirdiğimiz ve markete sunmadığımız bir uygulamada bu çok sıkıntı olmaz ama çoklu kullanıcı desteği sunması gereken uygulamalar ya da panellerde -borsa ekranları vb.- bu sıkıntıya bir çözüm üretebilmemiz gerekiyor.

İşte burada WebSocket devreye giriyor

WebSocket Nedir? Nasıl Çalışır?

WebSocket, tarayıcı ile sunucu arasında tek bir bağlantı üzerinden çift yönlü (full-duplex) ve sürekli iletişim sağlayan bir protokoldür. HTTP’de bağlantı her seferinde kapanırken, WebSocket’te bağlantı açık kalır ve her iki taraf da istediği anda veri gönderebilir.

WebSocket’in doğuş sebebi, HTTP’nin push iletişimini desteklememesidir, yani “Bir değişiklik olduğunda bunu bana ilet” yapısına sahip olmamasıdır.. Canlı sohbet, anlık bildirimler, multiplayer oyunlar veya gerçek zamanlı veri akışı gerektiren senaryolarda daha demin vurguladığımız gibi bu push communication oldukça gerekli bir yapıdır.. Mesajlar genellikle JSON gibi hafif formatlarda taşınır, bu da verimliliği artırır.

JSON’ın verimli oluşunun gerekçesi olarak da hızlıca şöyle yorumlar yapabiliriz :

1. XML gibi veri yapılarına kıyasla çok daha verimlidir, yani gereksiz container’lar kullanılmaz ve on-point bir response yapısı izlenir; bu da ağ trafiğinde daha az veri gönderilmesi ile birlikte avantajımıza olur.
2. Serialize — Deserialize senaryolarını desteklemesi, bu konuya şu anda girmeyeceğiz ama Metin olarak gelen bir içeriğin -> Nesne formatına dönüştürülmesi ya da tam tersi senaryonun destekleniyor olması yine JSON response kullanımını destekliyor

WebSocket El Sıkışması ve Çalışma Mantığı

WebSocket, HTTP üzerinden başlar ama sonra yükseltilir, yani birbirinden kopuk ve bağımsız kavramlar değillerdir:

1. İstek Gönderme: İstemci, HTTP GET isteğiyle WebSocket bağlantısı ister. Önemli header’lar:

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

2. Sunucu Cevabı: Sunucu, anahtarı işler ve kabul eder:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

3. Bağlantı Açık Kalır: Artık TCP soketi üzerinden çift yönlü iletişim başlar. Veri çerçeveleri (frames) ile mesajlar gönderilir: Metin, binary, ping/pong (bağlantı kontrolü).

Avantajlar:

• Düşük gecikme: Sürekli bağlantı, polling’e gerek yok.
• Verimlilik: Az overhead, küçük paketler.
• Gerçek zamanlı: Sunucu push yapabilir.

Dezavantajlar: Bağlantı yönetimi zor olabilir (örneğin reconnection), güvenlik için WSS (WebSocket Secure) kullanın.