WebSocket, her zaman açık uygulama verisinin iş atıdır: sohbet satırları, varlık (presence), fiyat tikleri, ortak imleçler, ajan olay akışları. Tek bir HTTP yükseltmesinden sonra istemci ve sunucu, her çeyrek yeni bir long-poll dansı icat etmeden küçük çerçeveler için çift yönlü kanal tutar. Bu bir medya yığını değildir. VPS’yi video SFU’su gibi boyutlandırırsanız CPU’ya fazla, RAM’e, dosya tanımlayıcılarına ve vekil zaman aşımlarına az yatırım yaparsınız.
Bu rehber WebSocket’in ne olduğunu, düz HTTP’den nasıl ayrıldığını, mimarinin ne zaman yapışkan oturumlar ve Redis istediğini, ters vekillerin boşta soketleri nasıl sessizce öldürdüğünü ve üretim hizmetini Avrupa Cloud VPS üzerinde nasıl barındıracağınızı kapsar. Kamera ve mikrofon mu lazım? WebRTC nedir okuyun. Hangi yığının hangi işi üstleneceğine hâlâ karar veriyorsanız WebRTC vs WebSocket.
WebSocket nedir
WebSocket HTTP (veya HTTPS) olarak başlar. İstemci yükseltme ister; sunucu kabul ederse bağlantı açık kalır ve her iki taraf her iki yönde çerçeveli mesaj gönderir. Çerçeveler ucuzdur. Tek bağlantıda teslimat sıralı ve güvenilirdir çünkü taşıma TCP’dir. Bu güvenilirlik, sentetik throughput bench’lerinin WebSocket’i WebRTC DataChannel’a tercih etmesinin nedenidir — kodek, jitter tamponu veya SRTP ödemezsiniz.
Tarayıcılar basit API sunar; sunucular Node, Go, Python, Java ve .NET kütüphaneleri kullanır. Operasyon hikâyesi daha az gösterişlidir: bağlantı sayıları, heartbeat’ler, backpressure ve yatay fan-out. WebSocket’i “push’lu REST” değil, HTTP el sıkışmalı uzun ömürlü bir TCP hizmeti olarak görün.
Protokolde üretimde önemsediğiniz birkaç ayrıntı vardır: ping/pong kontrol çerçeveleri, kapanış kodları, maksimum çerçeve boyutu ve kütüphanenizin yük altında mesajları birleştirip birleştirmediği. Kapanış kodlarını yok saymak her deploy’u sessiz düşüş gizemine çevirir. Maksimum çerçeve boyutunu yok saymak tek kötü niyetli istemciyi bellek olayına çevirir.
HTTP ve WebSocket
Klasik HTTP istek/yanıttır. Keep-alive olsa bile sunucu, istemci yeniden sorana kadar serbestçe push edemez (Server-Sent Events yararlı tek yönlü istisnadır). Long polling, istekleri açık tutarak push taklidi yapar; yeniden bağlanma fırtınaları ve vekil zaman aşımları herkesin sorunu olana kadar işe yarar.
WebSocket yükseltmeden sonra modeli tersine çevirir:
- İstemci ve sunucu söyleyecekleri olduğunda gönderir
- Soket ayağa kalktıktan sonra mesaj başına HTTP başlığı yoktur
- Protokolünüz konuları çoğulluyorsa tek TCP bağlantısı birçok mantıksal abonelik taşıyabilir
Kamuya açık internette hâlâ HTTPS/WSS gerekir. Çerezler, token’lar ve origin kontrolleri sizin sorumluluğunuzdadır. Yükseltme kimlik doğrulamayı kaldırmaz — yalnızca el sıkışmadan sonra baytların nasıl hareket ettiğini değiştirir. Birçok ekip yükseltme isteğinde kimlik doğrular (Authorization başlığı veya kısa ömürlü query token) ve herhangi bir uygulama çerçevesi işlenmeden önce soketi reddeder.
HTTP, idempotent CRUD, dosya yükleme ve önbelleklenebilir okumalar için hâlâ daha iyidir. WebSocket, ürünün bir odaya, akışa veya varlık kümesine sürekli üyelik istediğinde kazanır. İkisini karıştırmak normaldir: denetlenebilir komutlar için REST, canlı görünüm için soketler.
Uyan kullanım senaryoları
- Sohbet, yazıyor göstergeleri ve moderasyon olayları
- Çevrimiçi/çevrimdışı varlık ve birçok aboneye fan-out
- Ticker ve order-book tarzı güncellemeler
- Çok oyunculu oyun durumu (konumlar ve girdiler — ses değil)
- Pano ve ajan olay akışları
- Medya ayrı yoldayken WebRTC için sinyalizasyon (SDP ve ICE adayları)
- Belgeler HTTPS ile kalıcıyken ortak düzenleme farkındalığı (imleçler, seçimler)
Ürün mikrofon, kamera veya düşük gecikmeli ekran paylaşımı istiyorsa WebSocket’i ev yapımı medya protokolüne germeyin. Soketleri kontrol ve sohbet için tutun; medyayı WebRTC nedir yoluna koyun. “Opus çerçevelerini sohbet soketi üzerinden yayınlarız” uyarısı da geçerlidir — etkileşimli medya için ayarlanmış ICE veya tıkanıklık denetimi kazanmadan TCP head-of-line blocking miras alırsınız.
Mimari: yapışkan oturumlar ve Redis
Erken trafik tek ters vekil arkasında tek sürece sığar. Büyüme seçim dayatır.
- Tek düğüm — erken ürünler için uygundur; uygulama + vekil tek VPS’te
- Yapışkan yük dengeleme — soketi bir örneğe sabitleyin (çerez veya IP affinity) veya WebSocket’i yükseltmeleri ve oturum sahipliğini anlayan katmanda sonlandırın
- Redis (veya NATS) pub/sub — A düğümünde yayınlanan mesajın B’deki abonelere ulaşması için örnekler arası yayın
Paylaşımlı bus olmadan yatay ölçek ince şekillerde başarısız olur: farklı düğümlere bağlı kullanıcılar birbirlerinin olaylarını görmez. Dosya tanımlayıcıları, bağlantı başına RAM veya vekil boşta zaman aşımları varsayılanda kalınca dikey ölçek başarısız olur. Bus’ı ikinci düğümden önce planlayın, ilk kesintiden sonra değil.
Mümkün olduğunca kaygıları erken ayırın: soket kabul eden süreç ağır batch işleri de çalıştırmasın. Redis’i dikkatle birlikte konumlandırın — sohbet kutusundaki bellek baskısı, CPU grafikleri korkutucu görünmeden önce rastgele kopuşlar olarak çıkar. Redis önbellek ve kuyruklarla paylaşıksa realtime kanalına kendi örneğini veya en azından kendi bellek bütçesini ve eviction politikasını verin.
Oda üyeliği ve yetkilendirme yalnızca vekilde değil uygulama mantığınızdadır. Yanlış kiracının sürecine düşen yapışkan çerez, mesaj başına ACL kontrolünü atlıyorsanız hâlâ hatadır.
Vekil zaman aşımları ve nginx taslağı
Çoğu “WebSocket dengesiz” ticket’ı boşta zaman aşımıdır. Nginx, Caddy, bulut yük dengeleyicileri ve kurumsal vekiller ölü görünen bağlantıları kapatır. İstemcileriniz heartbeat (ping/pong) yapmalı; sunucularınız cevap vermeyi bırakan eşleri kapatmalı; vekil zaman aşımları boşta aralığın üzerinde marjla durmalıdır.
Upgrade başlıklarını geçirin. TLS’yi vekilde veya uygulamada sonlandırın — tarayıcılar kamuya açık sitelerde güvenli bağlam ister. Minimal nginx taslağı:
location /ws/ {
proxy_pass http://websocket_backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
}Zaman aşımlarını heartbeat’inize göre ayarlayın. Tek dizüstünden gelen yük testi sayısını kutlamadan önce worker_connections ve işletim sistemi dosya tanımlayıcı limitlerini yükseltin. Kopuş nedenlerini loglayın; bağlam olmadan “1006 abnormal closure” gün kaybettirir. TLS’yi kenarda sonlandırıyorsanız, hız sınırları ve abuse araçlarının gerçeği görmesi için orijinal istemci IP’sini tutarlı iletin.
Sağlık kontrolleri, bilerek yapmıyorsanız tam uygulama WebSocket’i açmamalıdır. Aynı süreçte ucuz bir HTTP health endpoint tercih edin; rolling deploy’larda fan-out ortasında worker’ları sert öldürmek yerine soketleri kısa grace ile boşaltın.
Diller ve kütüphaneler
Tarayıcı tek bir WebSocket yapıcısı sunar (MDN WebSocket). Sunucular zaten çalıştırdığınız dilde bir kütüphane seçer:
- Node.js —
wsveya çerçeve yardımcıları (oda/yedek istiyorsanız Socket.IO — ödünleri bilin). - Go — yalın gateway’ler için
gorilla/websocketveyanhooyr/websocket. - Python —
websockets, Starlette/FastAPI WebSocket rotaları, Django Channels. - Java — kurumsal yığınlar için Spring WebSocket / Jakarta endpoint’leri.
- C# / .NET —
ClientWebSocketve ASP.NET Core WebSockets.
TCP, HTTP, gRPC, GraphQL, WebSockets ve WebRTC boyunca protokol bağlamı Protocols in System Design yazısında taranır. Paydaşlar “neden tarayıcıya doğrudan gRPC değil?” diye sorduğunda bu haritayı kullanın.
Kurulum ve işletim sistemleri
İstemciler: her modern masaüstü ve mobil tarayıcı WebSocket uygular. Eklenti yok. Yerel uygulamalar platform soket yığınını veya dil SDK’sını kullanır.
Sunucular: her modern işletim sistemi çalışır. Üretim örnekleri genelde HTTP upgrade başlıklı Nginx veya Caddy arkasında Linux’tur. Windows Server (IIS/ARR veya Kestrel) WebSocket sonlandırabilir — zaten o mülkteyseniz; protokol, birçok SFU’nun yaptığı gibi Linux zorunlu kılmaz.
# Node örneği
npm install ws
# Go örneği
go get github.com/gorilla/websocketTLS’yi ters vekilde bağlayın (wss://). Tel formatının kendisi RFC 6455’te tanımlıdır.
Performans: bench’ler neden WebSocket’i kayırır
WebSocket TCP üzerinde gider: sıralı, güvenilir teslimat. Bu yüzden sohbet satırları yer değiştirmez ve sentetik throughput testleri sıkça WebSocket’i hâlâ ICE ve DTLS ödeyen bir WebRTC DataChannel’a tercih eder. Kazanım uygulama verisi için gerçektir — etkileşimli video için ilgisizdir. Bir slayt “WebSocket WebRTC’den daha hızlı” diyorsa dosya kopyalama testinden ve mikrofonun hiç açılıp açılmadığını sorun. Hibrit üretim sohbet sistemleri mesajlar için WebSocket, odaya ses/görüntü girince WebRTC kullanır (Codex: production-ready real-time web chat).
WebSocket yanlış araç olduğunda
Yanlış araç sinyalleri:
- Etkileşimli ses/görüntü lazım — sohbet soketi üzerinden ikili çerçeveler değil, WebRTC (SFU + TURN)
- Seyrek olayların tek yönlü sunucu push’u — Server-Sent Events daha basit olabilir
- Büyük dosya aktarımı — sıradan HTTPS yükleme ve nesne depolama; soketler zayıf CDN’dir
- Yalnızca ara sıra güncellemeli istek/yanıt — operasyon sadeliği için düz HTTP hâlâ kazanabilir
- Medya yolunda sunucu olmadan tarayıcılar arası gerçek P2P — bu WebRTC sahasıdır
Sohbet ve çağrıyı birleştiren ürünler için sektör varsayılanı hibrittir: sinyal ve mesajlaşma için WebSocket (veya HTTPS), medya için WebRTC. Bu ayrım uçtan uca WebRTC vs WebSocket içinde anlatılır. “Ekip zaten Node biliyor diye” her şeyi WebSocket yapmak, lansman haftasını başka ad altında UDP ve TURN projesine çevirir.
Avrupa’da WebSocket hizmeti barındırma
Metin çerçeveleri küçüktür; eşzamanlı bağlantılar ve RAM baskındır. Avrupa’da barındırmak, her soketi başka kıtadan geçirmeden AB kullanıcılarını varlık ve sohbet için kısa RTT’de tutar. Ham CPU saatlerinden çok kararlı ağ ve öngörülebilir yeniden bağlanma davranışı istersiniz.
Kaynak profili:
- Tepe eşzamanlı soketler artı pay için yeterli RAM
- Her mesajda ağır JSON dönüştürmüyorsanız CPU mütevazı kalır
- Hızlı disk yalnızca aynı kutuda kalıcılık varsa (genelde olmamalı)
- Akıllı keepalive, heartbeat ve backpressure ayarları
- Kötü mobil handoff veya deploy sonrası yeniden bağlanma fırtınaları için pay
“Maksimum MB/s video” değil, eşzamanlı bağlantı ve yeniden bağlanma fırtınalarını ölçün. Bulut planlarındaki trafik kotaları metin için genelde cömerttir; soketi toplu ikili blob için kötüye kullanırsanız sorun olur. Büyük yükleri nesne depolamaya itin; sokette URL veya olay kimliği gönderin.
EuroVDC Bulut Sunucu planlarında pratik tabanlar:
- Cloud VPS Medium — 4 vCPU / 4 GB — erken sohbet ve bildirim hizmetleri; katalog yaklaşık €44.99/ay (KDV hariç; ürün sayfasından doğrulayın)
- Cloud VPS Medium Plus — 4 vCPU / 8 GB — eşzamanlılık büyüyünce rahat varsayılan; katalog yaklaşık €66.99/ay
- Cloud VPS Medium Max veya Large Plus — 16–24 GB RAM — yüksek eşzamanlı soketler, dikkatli birlikte konumlanmış Redis
vCPU peşinde koşmak yerine RAM payını tercih edin. Tek düğüm dosya tanımlayıcılarını veya Redis belleğini doyurunca, ihtiyacınız olmayan medya sınıfı XL kutu almadan önce ikinci yapışkan düğüm ve paylaşımlı bus ekleyin. Sofia veri merkezimizden yumuşak gecikme kontrolü: Looking Glass.
Operatör kontrol listesi
- Kamuya açık hostname’de güvenilir sertifikalı WSS
- Vekil upgrade başlıkları ve heartbeat aralığının üzerinde boşta zaman aşımları
- El sıkışmada kimlik doğrulama (token query, çerez veya ilk mesaj) — anonim soketleri erken reddedin
- İki yönlü heartbeat; ölü eşleri biçin; mesaj boyutu ve hızını sınırlayın
- Yük testlerinden önce
ulimit -n/ systemdLimitNOFILEyükseltin - İkinci uygulama düğümünden önce yapışkan oturumlar + Redis (veya eşdeğeri) planlayın
- Büyük yüklemeleri HTTPS’e ayırın; soketi olaylar için tutun
- Bağlantı, kopuş ve fan-out gecikmesini ölçün; yeniden bağlanma fırtınalarına alarm kurun
İlgili rehberler
Avrupa’da bir Cloud VPS sipariş edin, WSS’yi doğru sonlandırın ve yeniden bağlanmaları yalnızca ofis LAN’ından değil mobil ağlardan yük test edin. Tarayıcı medyası için WebRTC nedir ile devam edin. Karar matrisi ve hibrit kalıp için WebRTC vs WebSocket okuyun.
