Hangi durumlarda HTML5 WebSockets yerine AJAX uzun / kısa yoklama tercih edilir?


306

Arkadaşlar için küçük bir sohbet uygulaması oluşturuyorum, ancak bir sayfayı yenilemeyi zorlamak kadar manuel veya temel olmayan zamanında nasıl bilgi alacağından emin değilim.

Şu anda, bunu basit AJAX kullanarak uyguluyorum, ancak bu, kısa bir zamanlayıcı geçtiğinde düzenli olarak sunucuya vurmanın dezavantajına sahiptir.

Uzun / kısa oylamayı araştırırken HTML5 WebSockets ile karşılaştım. Bunu uygulamak kolay görünüyor , ancak bazı gizli dezavantajlar olup olmadığından emin değilim. Örneğin, WebSockets yalnızca belirli tarayıcılar tarafından desteklendiğini düşünüyorum. WebSockets için bilmem gereken başka dezavantajlar var mı?

Her iki teknoloji de aynı şeyi yapıyor gibi göründüğü için, biri ne tür senaryolarda birini diğerinin üzerinde kullanmayı tercih eder? Daha spesifik olarak, HTML5 WebSockets AJAX uzun / kısa yoklamayı geçersiz kıldı mı, yoksa WebSockets yerine AJAX'ı tercih etmek için zorlayıcı nedenler var mı?

Yanıtlar:


508

WebSockets kesinlikle gelecek.

Uzun yoklama, AJAX gibi her istek için bağlantı oluşturmayı önlemek için kirli bir çözümdür - ancak WebSockets olmadığında uzun yoklama oluşturulmuştur. WebSockets sayesinde artık uzun yoklama gidiyor.

WebRTC eşler arası iletişime izin verir.

WebSockets öğrenmenizi öneririm .

karşılaştırma:

farklı iletişim tekniklerinin

  • AJAX - requestresponse. Sunucuya bir bağlantı oluşturur, isteğe bağlı verilerle istek üstbilgileri gönderir, sunucudan bir yanıt alır ve bağlantıyı kapatır. Tüm önemli tarayıcılarda desteklenir.

  • Uzun anket - requestwaitresponse. AJAX'ın yaptığı gibi sunucuya bir bağlantı oluşturur, ancak canlı tutma bağlantısını bir süre açık tutar (uzun olmasa da). Bağlantı sırasında, açık istemci sunucudan veri alabilir. İstemci, bağlantı kapatıldıktan sonra, zaman aşımları veya veriler nedeniyle periyodik olarak yeniden bağlanmalıdır. Sunucu tarafında, AJAX ile aynı bir HTTP isteği gibi davranılır, ancak istek üzerine cevap uygulama mantığı tarafından tanımlanan şimdi veya gelecekte bir süre sonra gerçekleşir. destek tablosu (tam) | wikipedia

  • WebSockets - clientserver. Sunucuya bir TCP bağlantısı oluşturun ve gerektiği kadar açık tutun. Sunucu veya istemci bağlantıyı kolayca kapatabilir. İstemci HTTP uyumlu bir el sıkışma işleminden geçer. Başarılı olursa, sunucu ve istemci her zaman her iki yönde de veri alışverişi yapabilir. Uygulamanın her iki şekilde de sık sık veri alışverişi gerektirmesi etkilidir. WebSockets, istemciden sunucuya gönderilen her ileti için maskeleme içeren veri çerçevesine sahiptir, böylece veriler basitçe şifrelenir. destek tablosu (çok iyi) | wikipedia

  • WebRTC - peerpeer. Ulaşım istemciler arasında iletişim kurmak için ve ulaşım-agnostik, böylece UDP, TCP veya daha soyut katmanları kullanabilirsiniz. Bu genellikle güvenilirliğin ikincil olduğu ve birkaç karenin veya kalite ilerlemesindeki azalmanın yanıt süresi ve en azından bir miktar veri aktarımı lehine feda edilebildiği video / ses akışı gibi yüksek hacimli veri aktarımı için kullanılır. Her iki taraf (eşler) verileri birbirinden bağımsız olarak itebilir. Herhangi bir merkezi sunucudan tamamen bağımsız olarak kullanılabilse de, çoğu durumda geliştiricilerin eşleri "bağlamak" için hala merkezi sunucuları kullandıkları endPoints verilerini alıp vermenin bir yolunu gerektirir. Bu sadece bir bağlantı kurmak için gerekli verileri değiştirmek için gereklidir, bundan sonra merkezi bir sunucu gerekli değildir. destek tablosu (orta boy) | wikipedia

  • Sunucu Tarafından Gönderilen Etkinlikler - clientserver. İstemci, sunucuya kalıcı ve uzun süreli bağlantı kurar. İstemciye yalnızca sunucu veri gönderebilir. İstemci sunucuya veri göndermek istiyorsa, bunun için başka bir teknolojinin / protokolün kullanılması gerekir. Bu protokol, HTTP uyumludur ve çoğu sunucu tarafı platformunda uygulanması kolaydır. Bu, Uzun Çağırma yerine kullanılacak tercih edilen bir protokoldür. destek tablosu (IE hariç iyi) | wikipedia

Avantajları:

WebSockets sunucu tarafının ana avantajı, bir HTTP isteği (el sıkışmasından sonra) değil, uygun bir mesaj tabanlı iletişim protokolü olmasıdır. Bu , yüksek performans ve mimari avantajlar elde etmenizi sağlar . Örneğin, node.js'de, farklı yuva bağlantıları için aynı belleği paylaşabilirsiniz, böylece her biri paylaşılan değişkenlere erişebilir. Bu nedenle, veritabanını ortada bir değişim noktası olarak kullanmanıza gerek yoktur (AJAX veya PHP gibi bir dilde Long Polling gibi). Verileri RAM'de saklayabilir veya hatta yuvalar arasında yeniden yayınlayabilirsiniz.

Güvenlik Hususları

İnsanlar genellikle WebSockets güvenliğinden endişe duyarlar. Gerçek şu ki, çok az fark yaratıyor veya WebSockets'i daha iyi bir seçenek haline getiriyor. Her şeyden önce, AJAX ile MITM şansı daha yüksektir , çünkü her istek internet altyapısı üzerinden geçen yeni bir TCP bağlantısıdır. WebSockets ile, bağlantı kurulduktan sonra, veriler istemciden sunucuya aktarıldığında ek olarak zorlanan çerçeve maskelemesinin yanı sıra veri incelemek için daha fazla çaba gerektiren ek sıkıştırma ile aralarında müdahale etmek çok daha zordur. Tüm modern protokoller hem HTTP'yi hem de HTTPS'yi (şifreli) destekler.

PS

WebSockets'in genellikle ağ için çok farklı bir mantık yaklaşımına sahip olduğunu , daha çok gerçek zamanlı oyunların hepsinde olduğu gibi, http gibi olmadığını unutmayın.


15
Bu, kendi kendine uyumluluk ile ilgili değildir. En önemlisi, iletişimin gerçekleşme şeklini tamamen yeniden düşünmek üzeredir. RESTful API'ler İstek> Yanıt modeliyle çalıştığından, burada çift yönlü iletişim anlamsız olacaktır. Bu yüzden RESTful API'yi sorgulamak için WebSockets kullanmaya çalışmak - biraz garip bir girişimdir ve bundan hiçbir fayda göremez. RESTful API'sinden verilere ihtiyacınız varsa ancak gerçek zamanlı olarak, WebSockets gibi çift yönlü iletişim ile çalışacak verileri aktarmak için WebSockets api oluşturursunuz. Onlar karşılaştırılabilir olmayan açı açısından karşılaştırmak için çalışıyoruz :)
moka

2
Merhaba @ pithhelmet hepsi sunucu tarafı yazılım (dil / teknoloji) kendi kendine bağlıdır. WebSocket, TCP üzerinden bir katmandır ve TCP akışı uygulamaları yapmanın birçok yolu vardır. Modern web sunucuları olay tabanlı mimari kullanır ve iş parçacığı havuzlarında çok verimlidir. Hangi teknolojiyi kullanıyorsunuz? Node.js, IO için sahne arkasındaki olayları ve yürütme bağlamında tek iş parçacıklı olayı kullanır, bu nedenle inanılmaz derecede verimlidir. Her bağlantı için iş parçacığı kullanımı - CPU'nun yanı sıra RAM (iş parçacığı başına 1mb +) açısından çok verimsizdir, çünkü bu iş parçacıkları sadece boşta veya daha kötü olacak - sonsuz veri kontrol döngüsü.
moka

4
Uzun yoklama kirli bir çözüm değildir ve webSocket'tan farklıdır. Bu ikisinin farklı senaryoda kullanılması amaçlanmıştır.
bagz_man

5
@bagz_man Long Polling, teknolojinin tanım gereği izin vermediği ve standart bir alternatifin bulunmadığı sonuçlar elde etmek için teknolojinin "çılgın" bir kullanımıdır. Uzun Çağırmanın var olmasının nedeni, WS'nin tam olarak olmadığı gerçeğidir, Period.
moka

4
@moka: Cloudflare'nin ücretsiz seviyesi 400 + Gbps'lik bir saldırıyı kaldıracak. Cüzdanınız AWS faturasını alabilir mi? Ayrıca, AWS ve Cloudflare, menşeinize ilişkin şikayetlerle ilgili olarak karşıt görüşlere sahiptir. Tutarlıları tartıştığımız sürece akılda tutulması gereken bir şey. :)
danneu

11

Atladığınız rakip teknolojilerden biri Sunucu tarafından Gönderilen Etkinlikler / Etkinlik Kaynağı'dır. Uzun Çağırma, Web Soketleri, Sunucudan Gönderilen Olaylar (SSE) ve Kuyruklu Yıldız nedir? tüm bunlar hakkında iyi bir tartışmaya sahiptir. Bunların bazılarının sunucu tarafında diğerlerine göre daha kolay olduğunu unutmayın.


Bunların dışında, neye bakmayı önerirsiniz?
13'teki somdow

Uzun oylamada başarılı oldum, tek hile (bunun ve diğer teknolojiler için) bir sunucu iş parçacığının bağlanması değil. Eşzamansız sunucu kodu kullanmazsanız ölçeklenmez.
bmm6o

1
@somdow Maksims-Mihejevs sorunuzu cevabının ilk iki paragrafında güzelce yanıtladı. Web soketleri kullanın.
Jeff Sheffield

7

Sohbet uygulamaları veya sunucuyla sürekli görüşülen diğer uygulamalar WebSocketsiçin en iyi seçenektir. Ancak, yalnızca WebSocketsbunları destekleyen bir sunucuyla kullanabilirsiniz , bu nedenle gerekli kitaplıkları yükleyemezseniz bunları kullanma yeteneğinizi sınırlayabilir. Bu durumda, Long Pollingbenzer işlevler elde etmek için kullanmanız gerekir .


5
WebSockets her sunucu tarafından desteklenir ... Yalnızca node.js veya benzeri bir şey yüklemeniz gerekir.
noob

9
Evet, herhangi bir sunucunun WebSockets'i destekleyeceğini açıklamak için biraz tweaked. Ancak, barındırma hizmeti kullanıyorsanız, bunları kullanamayabilirsiniz.
Brant Olsen

Bu iş parçacığının biraz eski olduğunu anlıyorum ama ... WebSockets tüm çift yönlü iletişim için en iyi yanıt olmayabilir. Son zamanlarda, Spring 4'ün web soketi desteğine ilişkin belgelerin, WebSockets'in büyük miktarda veri veya düşük gecikme süresi taşımak için daha uygun olduğunu önerdiğini fark ettim. Bunlar uygulanabilir değilse veya bir öncelik değilse, uzun yoklama kullanmanızı öneririm. Bu görüşün tam gerekçesini bilmiyorum, Bahar milletlerinin genel olarak ne hakkında konuştuklarını bildiklerini düşündüm.
Stoney

1
@Stoney, websocket'i sunucuda (işleyicileri vb.) Kurmanız gerekeceği gerçeğinden ayrı olarak Websocket üzerinden uzun yoklama kullanmanız için hiçbir neden yoktur. Websocket çok daha hızlıdır (düşük gecikme süresi) ve sunucunun istemciyle istemeden "konuşmasına" olanak tanır. Bugünlerde sinyalr (websocket'in şimdiye kadar yapılmış en iyi uygulamalarından biri kullanıyorum - istemci ve sunucu üzerinde çalışıyor ve istemcinin sunucudaki ve istemcideki sunucudaki yöntemleri herhangi bir fark yokmuş gibi çağırmasına izin veriyor) yaptığım web sitesi - dinamik içerik yükleme, dipsiz sayfalar, vb.
DividedByZero

0

XHR yoklaması vs SSE ve WebSockets

  • XHR yoklaması Bir olay meydana geldiğinde cevaplanır (hemen ya da gecikmeden sonra). Sonraki etkinlikleri almak için müteakip taleplerde bulunulması gerekecektir.

    Tarayıcı, sunucunun yanıt vermeden önce verilerin kullanılabilir olmasını bekleyebilecek eşzamansız bir istekte bulunur. Yanıt, istemci tarafından yürütülecek kodlanmış veriler (genellikle XML veya JSON) veya Javascript içerebilir. Yanıtın işlenmesinin sonunda, tarayıcı bir sonraki etkinliği beklemek için başka bir XHR oluşturur ve gönderir. Böylece tarayıcı, her olay gerçekleştikçe yanıtlanması için her zaman sunucuyla bekleyen bir istek tutar. Vikipedi

  • Sunucu Gönderilen Olaylar İstemci sunucuya istek gönderir. Sunucu, istediği zaman web sayfasına yeni veriler gönderir.

    Geleneksel olarak, bir web sayfasının yeni veri almak için sunucuya bir istek göndermesi gerekir; yani, sayfa sunucudan veri ister. Sunucu tarafından gönderilen etkinliklerle, bir sunucunun web sayfasına mesajlar göndererek istediği zaman bir web sayfasına yeni veri göndermesi mümkündür. Bu gelen iletiler web sayfasının içindeki Etkinlikler + veriler olarak değerlendirilebilir. Mozilla

  • WebSockets İlk el sıkışmasından sonra (HTTP protokolü ile). İletişim, WebSocket protokolü kullanılarak çift yönlü olarak yapılır.

    El sıkışma bir HTTP isteği / yanıtı ile başlar ve sunucuların aynı bağlantı noktasındaki WebSocket bağlantılarının yanı sıra HTTP bağlantılarını da işlemesine izin verir. Bağlantı kurulduktan sonra iletişim, HTTP protokolüne uymayan çift yönlü bir ikili protokole geçer. Vikipedi

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.