Ger\u00e7ek zamanl\u0131 uygulamalar \u00e7a\u011f\u0131m\u0131z\u0131n vazge\u00e7ilmezi. Peki, anl\u0131k etkile\u015fim sa\u011flayan, h\u0131zl\u0131 ve verimli uygulamalar\u0131 WebSocket kullanarak nas\u0131l in\u015fa edebilirsiniz? Bu kapsaml\u0131 rehberle, kariyerinizin her a\u015famas\u0131ndaki bir yaz\u0131l\u0131mc\u0131 olarak WebSockets d\u00fcnyas\u0131na dalacak, temelden ileri seviyeye t\u00fcm merak ettiklerinizi ke\u015ffedeceksiniz!<\/p>\n
Dijital d\u00fcnyada her \u015fey anl\u0131k; sosyal medya ak\u0131\u015flar\u0131m\u0131zdan online oyunlara, canl\u0131 borsa verilerinden i\u015f birli\u011fi ara\u00e7lar\u0131na kadar her alanda ger\u00e7ek zamanl\u0131 bilgi ak\u0131\u015f\u0131na ba\u011f\u0131ml\u0131y\u0131z. Art\u0131k bir sayfan\u0131n g\u00fcncellenmesi i\u00e7in “yenile” butonuna basmak, hatta k\u0131sa s\u00fcreli gecikmeler bile kabul edilemez bir l\u00fcks haline geldi. Peki, bu anl\u0131k etkile\u015fim talebi nas\u0131l kar\u015f\u0131lan\u0131yor? \u0130\u015fte tam da bu noktada, geleneksel HTTP’nin s\u0131n\u0131rlar\u0131n\u0131 zorlayan ve web uygulamalar\u0131na adeta s\u00fcper g\u00fc\u00e7ler kazand\u0131ran bir teknoloji sahneye \u00e7\u0131k\u0131yor: WebSockets.<\/p>\n
D\u00fc\u015f\u00fcnsenize, bir sohbet uygulamas\u0131nda mesaj\u0131n\u0131z\u0131n saniyeler i\u00e7inde kar\u015f\u0131 tarafa ula\u015fmamas\u0131 ne kadar sinir bozucu olurdu? Ya da bir online oyunun hamlelerinin gecikmeli gelmesi, rekabet\u00e7i ruhunuzu nas\u0131l baltalard\u0131? \u0130\u015fte bu senaryolar, ger\u00e7ek zamanl\u0131 ileti\u015fimin ne denli kritik oldu\u011funu net bir \u015fekilde ortaya koyuyor. Eskiden bu t\u00fcr ihtiya\u00e7lar i\u00e7in istemcinin sunucuyu s\u00fcrekli “bir haber var m\u0131?” diye yoklad\u0131\u011f\u0131 (polling) veya daha sofistike “uzun yoklama” (long polling) gibi y\u00f6ntemler kullan\u0131l\u0131rd\u0131. Ancak bu metotlar, kaynak israf\u0131, y\u00fcksek gecikme ve karma\u015f\u0131k y\u00f6netim gibi dezavantajlar\u0131 beraberinde getiriyordu. Dolay\u0131s\u0131yla, web’in evrimiyle birlikte, daha verimli, \u00e7ift y\u00f6nl\u00fc ve kal\u0131c\u0131 bir ileti\u015fim kanal\u0131na olan ihtiya\u00e7 ka\u00e7\u0131n\u0131lmaz hale geldi. Tam da bu noktada, 2011 y\u0131l\u0131nda IETF taraf\u0131ndan standartla\u015ft\u0131r\u0131lan WebSocket protokol\u00fc, web d\u00fcnyas\u0131nda ger\u00e7ek bir devrim niteli\u011fi ta\u015f\u0131d\u0131. WebSocket, sadece bir teknoloji de\u011fil, ayn\u0131 zamanda kullan\u0131c\u0131 deneyimini ba\u015ftan a\u015fa\u011f\u0131 yeniden tan\u0131mlayan bir paradigmad\u0131r. Anl\u0131k etkile\u015fimin ve d\u00fc\u015f\u00fck gecikmenin yeni standart oldu\u011fu bu dinamik \u00e7a\u011fda, WebSockets’\u0131 anlamak ve uygulamalar\u0131n\u0131zda etkin bir \u015fekilde kullanmak, sizi di\u011ferlerinden bir ad\u0131m \u00f6ne ta\u015f\u0131yacakt\u0131r. Bu rehberde, WebSockets’\u0131n sadece teknik detaylar\u0131na de\u011fil, ayn\u0131 zamanda ger\u00e7ek d\u00fcnya uygulamalar\u0131ndaki g\u00fcc\u00fcne de odaklanaca\u011f\u0131z. Haydi, bu heyecan verici d\u00fcnyaya birlikte dalal\u0131m!<\/p>\n
Peki, WebSockets’\u0131 bu kadar \u00f6zel ve vazge\u00e7ilmez k\u0131lan ne? Cevap basit: HTTP’nin do\u011fas\u0131na ayk\u0131r\u0131 bir ihtiyac\u0131, yani “kal\u0131c\u0131 ve \u00e7ift y\u00f6nl\u00fc ileti\u015fimi” k\u00f6kten \u00e7\u00f6zen bir yap\u0131 sunmas\u0131. Geleneksel HTTP, her istek i\u00e7in yeni bir ba\u011flant\u0131 kurup, iste\u011fi i\u015fledikten sonra kapatan, “isteksiz” (stateless) bir protokold\u00fcr. Bu, web sayfalar\u0131 y\u00fcklemek gibi tek y\u00f6nl\u00fc ve k\u0131sa \u00f6m\u00fcrl\u00fc i\u015flemler i\u00e7in harika olsa da, s\u00fcrekli ve anl\u0131k veri ak\u0131\u015f\u0131 gerektiren durumlar i\u00e7in verimsizdir.<\/p>\n
HTTP’nin her istekte bir “el s\u0131k\u0131\u015fma” (handshake) s\u00fcreci ve ard\u0131ndan ba\u011flant\u0131 kapatma ad\u0131m\u0131, k\u00fc\u00e7\u00fck, s\u0131k ve \u00e7ift y\u00f6nl\u00fc veri transferleri i\u00e7in ciddi bir overhead olu\u015fturur. Bu durum, \u00f6zellikle mobil cihazlarda pil t\u00fcketimini art\u0131r\u0131rken, sunucu taraf\u0131nda da gereksiz kaynak kullan\u0131m\u0131na yol a\u00e7ar. \u00d6rne\u011fin, bir sohbet mesaj\u0131 g\u00f6ndermek i\u00e7in her seferinde yeni bir HTTP ba\u011flant\u0131s\u0131 a\u00e7\u0131p kapatmak, gereksiz gecikmelere ve bant geni\u015fli\u011fi israf\u0131na neden olur. Bu durum, “polling” gibi \u00e7\u00f6z\u00fcmlerle a\u015f\u0131lmaya \u00e7al\u0131\u015f\u0131lsa da, sunucuyu gereksiz yere me\u015fgul etme ve ger\u00e7ek zamanl\u0131 hissi tam olarak verememe gibi sorunlar\u0131 beraberinde getiriyordu. Uzun yoklama (long polling) k\u0131smen daha iyi olsa da, yine de tek y\u00f6nl\u00fc ileti\u015fimi maskelemek i\u00e7in kullan\u0131lan bir y\u00f6ntemden \u00f6teye ge\u00e7emedi.<\/p>\n
WebSocket ise bamba\u015fka bir yakla\u015f\u0131mla gelir. \u0130lk olarak, istemci ve sunucu aras\u0131nda standart bir HTTP\/1.1 y\u00fckseltme (upgrade) iste\u011fi ile bir “el s\u0131k\u0131\u015fma” ger\u00e7ekle\u015ftirilir. Bu el s\u0131k\u0131\u015fma ba\u015far\u0131l\u0131 oldu\u011funda, ba\u011flant\u0131 HTTP protokol\u00fcnden WebSocket protokol\u00fcne y\u00fckseltilir. En can al\u0131c\u0131 nokta ise burada ba\u015flar: Bu ba\u011flant\u0131, istemci veya sunucu taraf\u0131ndan a\u00e7\u0131k\u00e7a kapat\u0131lana kadar kal\u0131c\u0131 olarak a\u00e7\u0131k kal\u0131r. \u0130\u015fte bu “kal\u0131c\u0131 ba\u011flant\u0131”, WebSocket’in t\u00fcm b\u00fcy\u00fcs\u00fcn\u00fcn temelidir. Ba\u011flant\u0131 kurulduktan sonra, hem istemci hem de sunucu, ayn\u0131 a\u00e7\u0131k kanal \u00fczerinden birbirlerine anl\u0131k veri paketleri (mesajlar) g\u00f6nderebilirler. Bu, tam \u00e7ift y\u00f6nl\u00fc (full-duplex) ileti\u015fim demektir; yani veri ak\u0131\u015f\u0131 her iki y\u00f6nde de ayn\u0131 anda ve ba\u011f\u0131ms\u0131z olarak ger\u00e7ekle\u015febilir. Bu sayede, gereksiz ba\u015fl\u0131k bilgileri ve ba\u011flant\u0131 kurma\/kesme maliyetleri ortadan kalkar, b\u00f6ylece \u00e7ok daha d\u00fc\u015f\u00fck gecikmeyle ve y\u00fcksek verimlilikle ileti\u015fim sa\u011flan\u0131r. \u00d6zetle, WebSocket bir kez kurulan ba\u011flant\u0131 \u00fczerinden, \u0131\u015f\u0131k h\u0131z\u0131nda veri al\u0131\u015fveri\u015fi yapman\u0131z\u0131 sa\u011flayan, adeta \u00f6zel bir telefon hatt\u0131 gibidir. Dolay\u0131s\u0131yla, canl\u0131 ak\u0131\u015flar, anl\u0131k bildirimler, online oyunlar, i\u015f birli\u011fi platformlar\u0131 gibi uygulamalar i\u00e7in mutlak bir gerekliliktir.<\/p>\n
WebSocket’in g\u00fcc\u00fcn\u00fc anlad\u0131k, peki bu g\u00fcc\u00fc uygulamalar\u0131m\u0131za nas\u0131l entegre edece\u011fiz? Ger\u00e7ek zamanl\u0131 bir uygulaman\u0131n mimarisini tasarlarken, sadece kod yazmakla kalmay\u0131z; ayn\u0131 zamanda \u00f6l\u00e7eklenebilirlik, g\u00fcvenlik ve s\u00fcrd\u00fcr\u00fclebilirlik gibi kritik fakt\u00f6rleri de g\u00f6z \u00f6n\u00fcnde bulundurmal\u0131y\u0131z. Ba\u015far\u0131l\u0131 bir ger\u00e7ek zamanl\u0131 uygulaman\u0131n temelinde, iyi d\u00fc\u015f\u00fcn\u00fclm\u00fc\u015f bir mimari yatar.<\/p>\n
Temel bir WebSocket uygulamas\u0131, genellikle iki ana bile\u015fenden olu\u015fur: bir sunucu ve bir veya daha fazla istemci. \u0130stemci (genellikle bir web taray\u0131c\u0131s\u0131 veya mobil uygulama), sunucuya bir WebSocket ba\u011flant\u0131s\u0131 ba\u015flat\u0131r. Sunucu bu ba\u011flant\u0131y\u0131 kabul eder ve bu noktadan itibaren her iki taraf da veri g\u00f6nderebilir ve alabilir. Bu olduk\u00e7a basit g\u00f6r\u00fcnebilir, ancak ger\u00e7ek d\u00fcnya senaryolar\u0131 \u00e7ok daha karma\u015f\u0131kt\u0131r. \u00d6rne\u011fin, bir sohbet uygulamas\u0131nda, bir kullan\u0131c\u0131 mesaj g\u00f6nderdi\u011finde, sunucunun bu mesaj\u0131 ilgili t\u00fcm ba\u011fl\u0131 istemcilere (ayn\u0131 sohbetteki di\u011fer kullan\u0131c\u0131lara) iletmesi gerekir. Bu, genellikle sunucu taraf\u0131nda bir “mesaj y\u00f6nlendirme” veya “yay\u0131nlama” (broadcasting) mekanizmas\u0131 gerektirir.<\/p>\n
WebSocket uygulamalar\u0131nda farkl\u0131 ileti\u015fim modelleri kullanabiliriz:<\/p>\n
Bu modelleri etkili bir \u015fekilde y\u00f6netmek i\u00e7in sunucu taraf\u0131nda istemci ba\u011flant\u0131lar\u0131n\u0131, gruplar\u0131 ve kimlik do\u011frulama bilgilerini tutacak bir yap\u0131ya ihtiyac\u0131m\u0131z olur. Veri format\u0131 genellikle JSON olsa da, performans gerektiren durumlarda Binary (ikili) formatlar da kullan\u0131labilir. Bu tercih, veri boyutunu ve i\u015flem h\u0131z\u0131n\u0131 do\u011frudan etkileyecektir. \u00d6rne\u011fin, canl\u0131 bir borsa uygulamas\u0131nda anl\u0131k fiyat de\u011fi\u015fimleri i\u00e7in Binary format, JSON’a k\u0131yasla daha verimli olabilir.<\/p>\n
Tek bir WebSocket sunucusu, belirli bir say\u0131da e\u015f zamanl\u0131 ba\u011flant\u0131y\u0131 kald\u0131rabilir. Ancak uygulaman\u0131z b\u00fcy\u00fcd\u00fck\u00e7e ve kullan\u0131c\u0131 say\u0131s\u0131 artt\u0131k\u00e7a, tek bir sunucunun yetersiz kalaca\u011f\u0131 ka\u00e7\u0131n\u0131lmazd\u0131r. \u0130\u015fte burada “\u00f6l\u00e7eklenebilirlik” devreye girer. WebSocket uygulamalar\u0131n\u0131 yatay olarak \u00f6l\u00e7eklendirmek, yani birden fazla sunucu \u00e7al\u0131\u015ft\u0131rmak, geleneksel HTTP uygulamalar\u0131na g\u00f6re baz\u0131 ek zorluklar i\u00e7erir. \u00c7\u00fcnk\u00fc bir istemci, belirli bir sunucuyla kal\u0131c\u0131 bir ba\u011flant\u0131 kurar. E\u011fer bir y\u00fck dengeleyici (load balancer) kullan\u0131l\u0131yorsa, ayn\u0131 istemcinin her zaman ayn\u0131 sunucuya y\u00f6nlendirilmesi (sticky sessions) \u00f6nemlidir. Aksi takdirde, ba\u011flant\u0131 kopmalar\u0131 veya mesajlar\u0131n yanl\u0131\u015f sunucuya gitmesi gibi sorunlar ya\u015fanabilir. Daha da \u00f6nemlisi, birden fazla WebSocket sunucusu aras\u0131nda mesajlar\u0131n nas\u0131l senkronize edilece\u011fi sorunudur. \u00d6rne\u011fin, bir sohbet mesaj\u0131 g\u00f6nderildi\u011finde, bu mesaj\u0131n t\u00fcm ba\u011fl\u0131 sunuculardaki ilgili istemcilere iletilmesi gerekir. Bu senaryoda Redis Pub\/Sub, Kafka veya RabbitMQ gibi mesaj kuyruklar\u0131 (message brokers) ve yay\u0131nlama\/abone olma (publish\/subscribe) mekanizmalar\u0131 vazge\u00e7ilmez hale gelir. Bu ara\u00e7lar, sunucular aras\u0131 ileti\u015fimi kolayla\u015ft\u0131rarak, uygulaman\u0131z\u0131n milyonlarca e\u015f zamanl\u0131 kullan\u0131c\u0131ya hizmet vermesini sa\u011flayabilir.<\/p>\n
WebSocket ba\u011flant\u0131lar\u0131 kal\u0131c\u0131 oldu\u011fu i\u00e7in g\u00fcvenlik riskleri de artar. Kimlik do\u011frulama (authentication) ve yetkilendirme (authorization) mekanizmalar\u0131 kritik \u00f6neme sahiptir. Kullan\u0131c\u0131lar\u0131n yaln\u0131zca izinli olduklar\u0131 verilere eri\u015fmesini sa\u011flamal\u0131s\u0131n\u0131z. Ayr\u0131ca, WebSocket \u00fczerinden g\u00f6nderilen verilerin \u015fifrelenmesi (WSS – WebSocket Secure) zorunludur. Bu, genellikle SSL\/TLS sertifikalar\u0131 kullan\u0131larak sa\u011flan\u0131r ve trafi\u011fi dinlemelere kar\u015f\u0131 korur. Kimlik do\u011frulama i\u00e7in JWT (JSON Web Tokens) veya oturum tabanl\u0131 kimlik do\u011frulama gibi y\u00f6ntemler kullan\u0131labilir. Unutmay\u0131n, bir ger\u00e7ek zamanl\u0131 uygulaman\u0131n en zay\u0131f halkas\u0131, genellikle g\u00fcvenlik a\u00e7\u0131klar\u0131d\u0131r. Dolay\u0131s\u0131yla, ba\u015ftan sona sa\u011flam g\u00fcvenlik pratikleri uygulamak, uygulaman\u0131z\u0131n gelece\u011fi i\u00e7in hayati \u00f6nem ta\u015f\u0131r.<\/p>\n
Teorik bilgileri peki\u015ftirmek i\u00e7in, basit ama i\u015flevsel bir sohbet uygulamas\u0131 \u00fczerinden WebSocket geli\u015ftirmenin ad\u0131mlar\u0131n\u0131 inceleyelim. Bu b\u00f6l\u00fcmde, hem istemci hem de sunucu taraf\u0131nda neleri dikkate almam\u0131z gerekti\u011fini pratik \u00f6rneklerle g\u00f6rece\u011fiz. Unutmay\u0131n, ama\u00e7, WebSocket’in temel ak\u0131\u015f\u0131n\u0131 anlamak ve bu bilgiyi kendi projelerinize adapte edebilmektir.<\/p>\n
Piyasada WebSocket destekli bir\u00e7ok farkl\u0131 dil ve framework bulunmaktad\u0131r. Node.js ve Socket.IO k\u00fct\u00fcphanesi, sundu\u011fu kolayl\u0131k ve performans nedeniyle ger\u00e7ek zamanl\u0131 uygulamalar i\u00e7in olduk\u00e7a pop\u00fcler bir tercihtir. Python (Flask-SocketIO), Java (Spring WebSockets), Go (Gorilla WebSocket) gibi alternatifler de mevcuttur. Biz bu \u00f6rnekte Node.js ve Socket.IO’yu kullanaca\u011f\u0131z, \u00e7\u00fcnk\u00fc hem \u00f6\u011frenmesi kolayd\u0131r hem de geni\u015f bir topluluk deste\u011fi vard\u0131r.<\/p>\n
\u00d6ncelikle bir Node.js projesi olu\u015ftural\u0131m ve Socket.IO’yu kural\u0131m:<\/p>\n
\nnpm init -y\nnpm install express socket.io\n<\/pre>\n<\/code><\/p>\n
\u015eimdi server.js<\/code> dosyas\u0131n\u0131 olu\u015ftural\u0131m ve temel bir WebSocket sunucusu kural\u0131m:<\/p>\n\nconst express = require('express');\nconst app = express();\nconst http = require('http');\nconst server = http.createServer(app);\nconst { Server } = require(\"socket.io\");\nconst io = new Server(server);\n\napp.get('\/', (req, res) => {\n res.sendFile(__dirname + '\/index.html');\n});\n\nio.on('connection', (socket) => {\n console.log('Bir kullan\u0131c\u0131 ba\u011fland\u0131!');\n\n socket.on('chat message', (msg) => {\n io.emit('chat message', msg); \/\/ Gelen mesaj\u0131 t\u00fcm ba\u011fl\u0131 istemcilere yay\u0131mla\n console.log('Mesaj: ' + msg);\n });\n\n socket.on('disconnect', () => {\n console.log('Bir kullan\u0131c\u0131 ayr\u0131ld\u0131!');\n });\n});\n\nserver.listen(3000, () => {\n console.log('Sohbet sunucusu http:\/\/localhost:3000 adresinde \u00e7al\u0131\u015f\u0131yor');\n});\n<\/pre>\n<\/code><\/p>\n
Bu kod par\u00e7as\u0131 olduk\u00e7a yal\u0131n. io.on('connection', ...)<\/code> blo\u011fu, her yeni istemci ba\u011fland\u0131\u011f\u0131nda \u00e7al\u0131\u015f\u0131r. socket.on('chat message', ...)<\/code> ise istemciden 'chat message' ad\u0131nda bir olay (event) geldi\u011finde tetiklenir ve io.emit('chat message', msg)<\/code> ile bu mesaj\u0131 t\u00fcm ba\u011fl\u0131 istemcilere geri yans\u0131t\u0131r. \u0130\u015fte bu, ger\u00e7ek zamanl\u0131 ileti\u015fimin kalbi!<\/p>\n\u0130stemci Taraf\u0131 (HTML ve JavaScript)<\/h4>\n
\u015eimdi de index.html<\/code> dosyam\u0131z\u0131 olu\u015ftural\u0131m. Bu dosya, kullan\u0131c\u0131lar\u0131n mesaj g\u00f6nderece\u011fi ve alaca\u011f\u0131 basit bir aray\u00fcz i\u00e7erecek:<\/p>\n\n\n <\/ul>\n