WebSocket

WebSocket, tek bir TCP bağlantısı üzerinden tam çift yönlü iletişim kanalı sağlayan bir bilgisayar iletişim protokolüdür. WebSocket protokolü IETF tarafından 2011 yılında RFC 6455 ile standart hale getirilmiş ve WebIDL içerisindeki WebSocket API W3C tarafından standart hale getirilmektedir.

WebSocket, web tarayıcılarında ve web sunucularında uygulanmak üzere tasarlanmıştır, fakat herhangi bir istemci veya sunucu uygulaması tarafından uygulanabilmektedir. WebSocket protokolü, TCP tabanlı bağımsız bir protokoldür. HTTP ile tek ilişkisi, HTTP sunucuları tarafından bir Upgrade isteği olarak yorumlanmasıdır.[1] WebSocket protokolü, sunucuya ve sunucudan gerçek zamanlı veri aktarımını sağlayarak, tarayıcı ile web sunucusu arasında etkileşimi sağlamaktadır. Bu, sunucunun istemci istemeden tarayıcıya içerik gönderebileceği ve bağlantıyı açık tutarak istediği zaman mesaj alabilmesini veya gönderebilmesini sağlayan standart bir yöntem ile sağlanmaktadır. Bu şekilde, tarayıcı ile sunucu arasında iki yönlü devam eden bir iletişim gerçekleşebilmektedir. İletişim TCP 80 portu (veya TLS ile şifrelenmiş bağlantılarda 443 portu) üzerinden gerçekleşmektedir ve bu, güvenlik duvarı kullanarak Internet web trafiğini engelleyen ortamlar için bir avantaj olmaktadır. Benzer iki yönlü sunucu-tarayıcı iletişimi Comet gibi standart olmayan stopgap teknolojileri tarafından sağlanmaktaydı.

WebSocket protokolü, Google Chrome, Microsoft Edge, Internet Explorer, Firefox, Safari ve Opera dahil pek çok tarayıcı tarafından desteklenmektedir. WebSocket ayrıca sunucu üzerindeki web uygulamalarının da desteğini gerektirmektedir.

Genel bakış

HTTP’den farklı olarak, WebSocket protokolü tam çift yönlü iletişim sağlamaktadır.[2][3] İlave olarak, WebSocket TCP protokolünün üzerinde mesaj akışına imkân tanımaktadır. TCP tek başına, mesaj kavramı kullanmadan byte akışı ile ilgilenmektedir. WebSocket protokolünden önce, 80 protokolü üzerinden tam çift yönlü iletişim Comet kanalları üzerinden yapılabilmekteydi; fakat, Comet uygulaması çok yaygın değildir ve TCP el sıkışması ve HTTP başlıkları yüzünden küçük mesajlar için verimsiz olmaktadır. WebSocket protokolü, webin güvenlik ilkelerini etkilemeksizin bu problemleri çözmeyi amaçlamaktadır.

WebSocket protokolü tanımı, şifreli ve şifresiz trafik için kullanılan iki yeni uniform resource identifier (URI) [4] formatı olan ws ve wss ifadelerini tanımlamaktadır. Şema adı ve fragment dışında (# desteklenmemektedir), diğer URI bileşenleri için genel URI biçimini kullanacak şekilde tanımlanmıştır.[5]

Tarayıcının Geliştirici Araçlarını kullanarak, geliştiriciler WebSocket paketleri ile WebSocket el sıkışmasını inceleyebilmektedir.[6]

Tarih

WebSocket, HTML5 tanımında ilk olarak, TCP tabanlı soket API’si yerine TCPConnection olarak anılmıştır.[7] Haziran 2008’de, Michael Carter tarafından, WebSocket olarak bilinen protokolün ilk versiyonu olan bir takım çalışma gerçekleştirilmiştir.[8]

Bunun üzerine kısa bir süre sonra Ian Hickson ve Michael Carter tarafından #whatwg IRC chat odasındaki[9] işbirliği ile WebSocket ismi verilmiştir ve sonrasında Ian Hickson tarafından HTML5 tanımında yer alacak şekilde yazılmıştır ve Michael Carter tarafından bir blog üzerinde duyurulmuştur.[10] Aralık 2009’da, varsayılan olarak WebSocket protokolü standartlarını tamamen uygulayan ilk tarayıcı Google Chrome 4 olmuştur.[11] Sonrasında, Şubat 2010’da WebSocket protokolünün geliştirilmesi, W3C ve whatwg IRC grubundan IET’ye geçmiştir ve Ian Hickson gözetiminde iki değişime uğramıştır.[12]

Protokol tamamlandıktan ve birden çok tarayıcı tarafından varsayılan olarak desteklendikten sonra, Aralık 2011’de Ian Fette gözetiminde RFC tamamlanmıştır.[13]

Browser implementation

WebSocket protokolünün güvenli bir versiyonu, Firefox 6,[14] Safari 6, Google Chrome 14,[15] Opera 12.10 ve Internet Explorer 10 tarafından uygulanmaktadır.[16] Detaylı bir protokol test raporu[17] bu tarayıcıların spesifik protokol özelliklerine uyumluluğunu listelemektedir.

Protokolün daha eski ve daha az güvenli bir versiyonu, Opera 11, Safari 5 ve iOS 4.2'de bulunan Safari mobil versiyonunda uygulanmıştır.[18] iOS7'deki BlackBerry tarayıcısı WebSocket protokolünü uygulamaktadır.[19] Açıklıklar yüzünden, Firefox 4 ve 5[20] ile Opera 11[21] üzerinde devre dışı bırakılmıştır.

Ayrıca, SPDY üzerinde WebSocket protokolünün deneysel bir uygulamasına imkân tanıyan Google Chrome için --enable-websocket-over-spdy komut satırı anahtarı bulunmaktadır.[22]

Desteklenme Durumu
Protokol Taslak Tarihi
 Internet Explorer Firefox[23] (PC) Firefox (Android) Chrome (PC, Mobile) Safari (Mac, iOS) Opera (PC, Mobile) Android Browser
hixie-7517 Mart 2017 tarihinde Wayback Machine sitesinde arşivlendi. 4 Şubat 2010 4 5.0.0
hixie-76

hybi-00

 6 Mayıs 2010

23 Mayıs 2010

 4.0 (devre dışı bırakıldı) 6 5.0.1 11.00 (disabled)
7 hybi-07 22 Nisan 2011 6[24][lower-alpha 1]
8 hybi-10 11 Temmuz 2011 7[26][lower-alpha 1] 7 14[27]
13 Şablon:IETF RFC Aralık 2011 10[28] 11 11 16[29] 6 12.10[30] 4.4

Protokol El Sıkışması

Bir WebSocket bağlantısı kurmak için istemci, aşağıdaki örnekte gösterildiği gibi sucununun WebSocket el sıkışma cevabı gönderdiği bir WebSocket el sıkışma isteği göndermektedir.[31]

İstemci isteği (HTTP’de olduğu gibi, her bir satır \r\n ile bitmektedir ve sonda ilave bir boş satır bulunmak zorundadır):

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

Sunucunun cevabı:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

El sıkışma, sunucuların aynı port üzerinden hem HTTP bağlantılarını hem de WebSocket bağlantılarını işleyebilmesi açısından HTTP’ye benzemektedir. Bağlantı kurulduğunda, iletişim, HTTP protokolüne uymayan iki taraflı bir ikili protokole dönüşmektedir.

Upgrade başlığına ek olarak, istemci base64 ile kodlanmış rastgele bytelardan oluşan bir Sec-WebSocket-Key başlığını da göndermektedir. Sunucu ise Sec-WebSocket-Accept başlığı ile anahtar değerinin özeti ile cevap vermektedir. Bu yöntem, önceki bir WebSocket trafiğinin tekrar oynatılmasını engellemeye çalışmaktadır[32] ve herhangi bir kimlik doğrulama, gizlilik veya bütünlük kontrolü sağlamamaktadır. Özet fonksiyonu 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 sabit değerini Sec-WebSocket-Key başlığındaki (base64 kodlaması çözülmemiş) değere eklemekte, SHA-1 özet fonksiyonunu uygulamakta ve sonucu base64 kullanarak kodlamaktadır.[33]

Bağlantı kurulduktan sonra, istemci ve sunucu WebSocket verisini tam çift yönlü modda gönderebilmektedir. Veri, payload tarafından takip edilen küçük bir başlık ile minimal bir şekilde çerçevelenmektedir. WebSocket iletişimi, tek bir mesajın birkaç veri çerçevesi içerisine dağılabileceği mesajlarla tanımlanmaktadır. Bu, verinin ilk kısmının bilindiği fakat mesajın toplam büyüklüğünün bilinmediği durumlarda, mesajların gönderilebilmesine izin vermektedir (FIN biti ile işaretlenip sona erişilene kadar veri çerçevelerini arka arkaya göndermektedir). Protokol üzerinde yapılan eklentilerle, farklı veri akışlarının eş zamanlı olarak çoklanması için de kullanılabilmektedir (örneğin bir soketin kullanımını tek bir büyük payload için tekelleştirilmesini önlemek için).

(Güvenlik açısından) Sunucu tarafında bağlantı kurulurken Origin başlığının doğrulanması, Siteler Arası WebSocket Çalma (Cross-Site WebSocket Hijacking) saldırılarına karşı koruma açısından önem taşımaktadır. Bu saldırı bağlantı çerezler veya HTTP kimlik doğrulaması ile doğrulandığında mümkün olabilmektedir. WebSocket üzerinden hassas veriler iletilirken, WebSocket bağlantısını doğrulamak için token veya benzer koruma mekanizmalarının kullanılması faydalı olacaktır.[34]

Proxy geçişi

WebSocket protokolü istemci uygulamaları, web tarayıcısının hedef makine ve porta bağlanırken bir vekil sunucu kullanıp kullanmadığını tespit etmeye çalışmaktadır ve eğer kullanıyorsa, kalıcı bir tünel oluşturmak için HTTP CONNECT metodunu kullanmaktadır.

WebSocket protokolünün kendisi vekil sunucuların ve güvenlik duvarlarının farkında olmasa da, HTTP’ye uygun bir el sıkışmayı desteklemektedir ve böylece HTTP sunucularının varsayılan HTTP ve HTTPS portlarını (80 ve 443) bir WebSocket ağ geçidiyle veya sunucusuyla paylaşmasına izin vermektedir. WebSocket protokolü, WebSocket ve Güvenli WebSocket bağlantılarını belirtmek için ws:// ve wss:// öneklerini tanımlamaktadır. Her iki yöntemde, bağlantıyı WebSocket’a yükseltmek için bir HTTP yükseltme mekanizması kullanmaktadır. Bazı vekil sunucular şeffaftır ve WebSocket ile çalışabilmektedir; diğerleri ise WebSocket protokolünün çalışmasını engelleyecektir ve bağlantının sonlanmasına yol açacaktır. Bazı durumlarda, ilave vekil sunucu yapılandırması gerekebilmektedir ve bazı vekil sunucuların WebSocket protokolünü desteklemesi için yükseltilmesi gerekebilmektedir.

Eğer şifrelenmemiş WebSocket trafiği, WebSocket desteği olmayan bir şeffaf vekil sunucu üzerinden akıyorsa, bağlantı muhtemelen başarısız olacaktır.[35]

Eğer şifreli WebSocket bağlantısı kullanılıyorsa, Güvenli WebSocket bağlantısında Transport Layer Security (TLS) kullanılması, tarayıcı bir vekil sunucu kullanacak şekilde yapılandırıldığında, HTTP CONNECT komutunun çalıştırılmasını sağlamaktadır. Bu, Güvenli WebSocket istemcisi ile WebSocket sunucusu arasında HTTP vekil sunucusu aracılığıyla düşük seviye birebir TCP iletişimini sağlayan bir tünel kurmaktadır. Şeffaf vekil sunucularda, tarayıcı vekil sunucunun varlığından habersizdir ve hiçbir HTTP CONNECT paketi yollanmamaktadır. Ancak, kablodaki trafik şifreli olduğu için, aradaki şeffaf vekil sunucular şifreli trafiğin geçmesine izin verebilmektedir. Bu yüzden, Güvenli WebSocket kullanıldığında, WebSocket bağlantısının başarılı olma ihtimali artmaktadır. Şifrelemenin olması kaynak kullanımı açısından bir miktar yük oluşturacaktır, fakat güvenli bir tünel üzerinden geçebileceği için daha yüksek bir başarı oranı sağlamaktadır.

2010 ortalarında verilen bir taslak (hixie-76 versiyonu) ters vekil sunucularla ve ağ geçitleriyle uyumluluğu, başlıklardan sonra 8 byte’dan oluşan bir anahtar eklediği ve bu anahtarı Content-Length: 8 başlığında belirtmediği için bozmuştur.[36] Bu veri tüm aradaki cihazlar tarafından iletilmeyeceği için protokol başarısızlığına yol açabilmektedir. Bu yüzden, daha yeni taslaklar (örneğin hybi-09[37]) bu problemi çözerek anahtar veriyiSec-WebSocket-Key başlığına koymaktadır.

Notlar
  1. Gecko-based browsers versions 6–10 implement the WebSocket object as "MozWebSocket",[25] requiring extra code to integrate with existing WebSocket-enabled code.

Kaynakça
  1. Şablon:Cite IETF
  2. "Glossary:WebSockets". Mozilla Developer Network. 2015. 14 Eylül 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 8 Nisan 2017.
  3. HTML5 WebSocket: A Quantum Leap in Scalability for the Web
  4. Graham Klyne, (Ed.) (14 Kasım 2011). "IANA Uniform Resource Identifer (URI) Schemes". Internet Assigned Numbers Authority. 25 Nisan 2013 tarihinde kaynağından arşivlendi. Erişim tarihi: 10 Aralık 2011.
  5. Şablon:Cite IETF
  6. Wang, Vanessa; Salim, Frank; Moskovits, Peter (Şubat 2013). "APPENDIX A: WebSocket Frame Inspection with Google Chrome Developer Tools". The Definitive Guide to HTML5 WebSocket. Apress. ISBN 978-1-4302-4740-1. 31 Aralık 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Nisan 2013.
  7. "HTML 5". www.w3.org. 16 Eylül 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 17 Nisan 2016.
  8. "[whatwg] TCPConnection feedback from Michael Carter on 2008-06-18 (whatwg.org from June 2008)". lists.w3.org. 27 Nisan 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 17 Nisan 2016.
  9. "IRC logs: freenode / #whatwg / 20080618". krijnhoetmer.nl. 21 Ağustos 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 18 Nisan 2016.
  10. "Comet Daily » Blog Archive » Independence Day: HTML5 WebSocket Liberates Comet From Hacks". 23 Nisan 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 17 Nisan 2016.
  11. "Web Sockets Now Available In Google Chrome". Chromium Blog (İngilizce). 31 Mart 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 17 Nisan 2016.
  12. <[email protected]>, Ian Hickson. "The WebSocket protocol". tools.ietf.org. 17 Mart 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 17 Nisan 2016.
  13. <[email protected]>, Ian Hickson. "The WebSocket protocol". tools.ietf.org. 6 Mart 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 17 Nisan 2016.
  14. Dirkjan Ochtman (27 Mayıs 2011). "WebSocket enabled in Firefox 6". Mozilla.org. 26 Mayıs 2012 tarihinde kaynağından arşivlendi. Erişim tarihi: 30 Haziran 2011.
  15. "Chromium Web Platform Status". 4 Mart 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 3 Ağustos 2011.
  16. "WebSockets (Windows)". Microsoft. 28 Eylül 2012. 25 Mart 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Kasım 2012.
  17. "WebSockets Protocol Test Report". Tavendo.de. 27 Ekim 2011. 22 Eylül 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 10 Aralık 2011.
  18. Katie Marsal (23 Kasım 2010). "Apple adds accelerometer, WebSockets support to Safari in iOS 4.2". AppleInsider.com. 8 Kasım 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Mayıs 2011.
  19. "Web Sockets API". BlackBerry. 10 Haziran 2011 tarihinde kaynağından arşivlendi. Erişim tarihi: 8 Temmuz 2011.
  20. Chris Heilmann (8 Aralık 2010). "WebSocket disabled in Firefox 4". Hacks.Mozilla.org. 6 Mart 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Mayıs 2011.
  21. Aleksander Aas (10 Aralık 2010). "Regarding WebSocket". My Opera Blog. 15 Aralık 2010 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Mayıs 2011.
  22. Peter Beverloo. "List of Chromium Command Line Switches". peter.sh. 8 Nisan 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 10 Aralık 2011.
  23. "WebSockets (support in Firefox)". developer.mozilla.org. Mozilla Foundation. 30 Eylül 2011. 26 Mayıs 2012 tarihinde kaynağından arşivlendi. Erişim tarihi: 10 Aralık 2011.
  24. "Bug 640003 - WebSockets - upgrade to ietf-06". Mozilla Foundation. 8 Mart 2011. Erişim tarihi: 10 Aralık 2011.
  25. "WebSockets - MDN". developer.mozilla.org. Mozilla Foundation. 30 Eylül 2011. 26 Mayıs 2012 tarihinde kaynağından arşivlendi. Erişim tarihi: 10 Aralık 2011.
  26. "Bug 640003 - WebSockets - upgrade to ietf-07(comment 91)". Mozilla Foundation. 22 Temmuz 2011.
  27. "Chromium bug 64470". code.google.com. Google. 25 Kasım 2010. 31 Aralık 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 10 Aralık 2011.
  28. "WebSockets in Windows Consumer Preview". IE Engineering Team. Microsoft. 19 Mart 2012. 6 Eylül 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 23 Temmuz 2012.
  29. "WebKit Changeset 97247: WebSocket: Update WebSocket protocol to hybi-17". trac.webkit.org. Erişim tarihi: 10 Aralık 2011.
  30. "A hot Opera 12.50 summer-time snapshot". Opera Developer News. 3 Ağustos 2012. 5 Ağustos 2012 tarihinde kaynağından arşivlendi. Erişim tarihi: 3 Ağustos 2012.
  31. Şablon:Cite IETF
  32. "Main Goal of WebSocket protocol". IETF. 22 Nisan 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 25 Temmuz 2015. The computation [...] is meant to prevent a caching intermediary from providing a WS-client with an cached WS-server reply without actual interaction with the WS-server.
  33. Şablon:Cite IETF
  34. Christian Schneider (31 Ağustos 2013). "Cross-Site WebSocket Hijacking (CSWSH)". Web Application Security Blog. 31 Aralık 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 8 Nisan 2017.
  35. Peter Lubbers (16 Mart 2010). "How Web Sockets Interact With Proxy Servers". C4Media Inc. 8 Mayıs 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 10 Aralık 2011.
  36. Willy Tarreau (6 Temmuz 2010). "WebSocket -76 is incompatible with HTTP reverse proxies" (email). Internet Engineering Task Force. 17 Eylül 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 10 Aralık 2011.
  37. Ian Fette (June 13, 2011).

Dış bağlantılar
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.