SO ve web üzerinde soru başlığımdaki anahtar kelimelerle ilgili birçok yazı okudum ve onlardan çok şey öğrendim. Okuduğum sorulardan bazıları, özel uygulama zorlukları ile ilgili iken, diğerleri genel kavramlara odaklanıyor. Ben sadece X teknolojisinin neden Y teknolojisi üzerinde icat edildiğini ve tüm kavramları ve nedenleri anladığımdan emin olmak istiyorum. İşte burada:
Http Yoklama: Temelde XmlHttpRequest kullanarak AJAX.
Http Uzun Yoklama: AJAX ancak sunucu bir güncelleme olduğunda, sunucu bir güncelleme olduğunda, sunucu yanıtı beklemeye alır, gönderir ve istemciden başka bir istek gönderebilir. Dezavantaj, ileri geri gönderilmeye ihtiyaç duyan ek başlık verileridir.
Http Akışı: Uzun yoklamada olduğu gibi, sunucu "Aktarım Kodlaması: parçalanmış" başlıklı bir üstbilgiye karşılık veriyor ve bu nedenle sunucu her veriyi gönderdiğinde yeni bir istek başlatmaya gerek duymuyor (ve dolayısıyla ek başlığın yükünü kaydediyor). Buradaki dezavantaj, sunucunun gönderdiği çoklu parçalar arasında ayrım yapmak için verilerin "anlaşılması" ve veri yapısını anlamamız gerektiğidir.
Java Uygulaması, Flash, Silverlight: Soket sunucularına tcp / ip üzerinden bağlanma yeteneği sağlarlar ancak eklentiler olduklarından, geliştiriciler bunlara bağlı kalmak istemezler.
WebSockets: Yukarıdaki yöntemlerin kısa yollarını aşağıdaki şekilde ele almaya çalışan yeni API'lardır:
- Java Appletler, Flash veya Silverlight gibi eklentiler üzerinden WebSockets'ın tek avantajı, WebSockets'ların yerel olarak tarayıcılara yerleşik olması ve eklentilere güvenmemesidir.
- WebSockets'ın http streaming üzerinden tek avantajı, alınan verileri "anlamak" ve ayrıştırmak için çaba harcamanıza gerek olmamasıdır.
- WebSockets'ın Long Polling üzerinden sağladığı tek avantaj, ekstra başlıkların boyutunun kaldırılması ve istek için soket bağlantısının açılması ve kapatılmasıdır.
Kaybettiğim başka önemli farklılıklar var mı? Eğer SO'da bulunan soruların çoğunu tek bir soruya yeniden sorduğum veya birleştirdiğim için özür dilerim, fakat sadece SO ve web üzerinde bu bilgi ile ilgili tüm bilgilerin dışında mükemmel bir anlam ifade etmek istiyorum.
Teşekkürler!
Tanımladığınızdan daha fazla fark var.
Dubleks / yönlü:
- Tek yönlü: HTTP anketi, uzun anket, akış.
- Çift Yönlü: WebSockets, eklenti ağı
Artan gecikme sırasına göre (yaklaşık):
- WebSockets
- Eklenti ağı
- HTTP akışı
- HTTP uzun anket
- HTTP yoklaması
CORS (çapraz kaynaklı destek):
- WebSockets: evet
- Eklenti ağı: Politika isteğiyle Flash (diğerleri hakkında emin değil)
- HTTP * (bazı yeni destek)
Yerel ikili veriler (yazılan diziler, lekeler):
- WebSockets: evet
- Eklenti ağı: Flash'ta değil (ExternalInterface genelinde URL kodlaması gerektirir)
- HTTP *: ikili tür desteğini etkinleştirmek için son teklif
Verimliliği azaltmada bant genişliği:
- Eklenti ağı: İlk politika isteği dışında Flash yuvaları ham
- WebSockets: bağlantı kurulumu el sıkışma ve kare başına birkaç bayt
- HTTP akışı (sunucu bağlantısının yeniden kullanımı)
- HTTP uzun anketi: her mesaj için bağlantı
- HTTP anketi: her mesaj için bağlantı + veri mesajı yok
Mobil cihaz desteği:
- WebSocket: iOS 4.2 ve üstü. Flash emülasyonu veya kullanarak bazı Android Android için Firefox veya Android için Google Chrome her ikisi de yerel WebSocket desteği sağlar.
- Eklenti ağları: Bazı Android. İOS'ta değil
- HTTP *: çoğunlukla evet
Javascript kullanım karmaşıklığı (en basitinden en karmaşıka). Kuşkusuz karmaşıklık ölçüleri biraz özneldir.
- WebSockets
- HTTP anketi
- Eklenti ağı
- HTTP uzun anket, akış
Ayrıca, HTTP akışının standartlaştırılması için bir W3C önerisi olduğunu unutmayın. Sunucu Gönderilen Olaylar. Şu anda evriminde oldukça erkendir ve WebSockets ile kıyaslanabilir basitliğe sahip standart bir Javascript API'si sağlamak için tasarlanmıştır.
Çok fazla yer tutan diğerlerinden bazı harika cevaplar. İşte biraz fazladan.
Java Appletler, Flash veya Silverlight gibi eklentiler üzerinden WebSockets'ın tek avantajı, WebSockets'ların yerel olarak tarayıcılara yerleşik olması ve eklentilere güvenmemesidir.
Bununla, bir soket bağlantısı kurmak için Java Applet'lerini, Flash'ı veya Silverlight'ı kullanabileceğinizi kastediyorsanız, o zaman bu mümkün olur. Bununla birlikte, kısıtlamalar nedeniyle gerçek dünyada çok sık kullanıldığını görmüyorsunuz.
Örneğin, aracılar bu trafiği kapatabilir ve kapatabilir. WebSocket standardı, mevcut HTTP altyapısıyla uyumlu olacak şekilde tasarlanmıştır ve bu nedenle, güvenlik duvarları ve proxy'ler gibi aracılar tarafından engellenmeye çok daha az eğilimlidir.
Ayrıca, WebSocket portu 80 ve 443'ü özel port gerektirmeden kullanabilir, protokol tasarımı sayesinde mevcut HTTP altyapısı ile mümkün olduğu kadar uyumludur.
Bu soket alternatiflerinin (Java, Flash ve Silverlight) çapraz kaynaklı bir mimaride güvenli bir şekilde kullanılması zordur. Bu nedenle, genellikle onları çapraz-kaynaklı kullanma teşebbüsleri, güvenli bir şekilde yapma çabalarına gitmek yerine, güvensizlikleri tolere edecektir.
Ayrıca, açılacak "standart olmayan" bağlantı noktaları (yöneticilerin yapması gereken bir şey) veya yönetilmesi gereken politika dosyaları da gerekebilir.
Kısacası, soket bağlantısı için Java, Flash veya Silverlight kullanmak, onu sık sık ciddi mimarilerde konuşlandırılmadığını yeterince sorunlu hale getiriyor. Flash ve Java, muhtemelen en az 10 yıl boyunca bu yeteneğe sahipti ve henüz yaygın değil.
WebSocket standardı, bu kısıtlamaları akılda tutarak yeni bir yaklaşımla başlayabildi ve umarız onlardan bazı dersler almayı umuyordu.
Bazı WebSocket uygulamaları, WebSocket bağlantısı kurulamadığında (eski bir tarayıcıda çalışırken veya aracı araya girdiğinde olduğu gibi) geri dönüşleri olarak Flash'ı (veya muhtemelen Silverlight ve / veya Java'yı) kullanır.
Bu durumlar için bir çeşit geri çekilme stratejisi akıllı olsa da, gerekli olsa bile, Flash ve diğerlerini kullananların çoğu, yukarıda açıklanan dezavantajlardan muzdarip olacaktır. Bu şekilde olmak zorunda değildir - Flash, Silverlight vb. Kullanarak güvenli çapraz-kaynaklı yetenekli bağlantılar elde etmek için bazı çözümler vardır - ancak çoğu uygulama bunu yapmaz çünkü kolay değildir.
Örneğin, çapraz bağlantı için WebSocket'a güveniyorsanız, bu iyi çalışır. Ancak daha sonra eski bir tarayıcıda veya güvenlik duvarı / proxy'de çalışıyorsanız ve Flash'a güveniyorsanız, geri dönüşünüz olarak, aynı çapraz kaynaklı bağlantıyı gerçekleştirmenin zor olacağını düşünün. Tabi ki güvenlik umurunda değilsen tabii.
Bu, biraz çalışmak için hazır değilseniz veya iyi yapmış bir çerçeveye gitmeye hazır olmadığınız sürece, yerel ve yerel olmayan bağlantılar için çalışan tek bir birleşik mimariye sahip olmak zordur. İdeal bir mimaride, bağlantıların doğal olup olmadığını fark etmezsiniz; Güvenlik ayarlarınız her iki durumda da çalışır; Kümeleme ayarlarınız hala çalışır; kapasite planlamanız devam edecektir; ve bunun gibi.
WebSockets'ın http streaming üzerinden tek avantajı, alınan verileri "anlamak" ve ayrıştırmak için çaba harcamanıza gerek olmamasıdır.
Bir HTTP akışının açılması ve verilerinizin dakikalar, saatler veya daha uzun bir süre boyunca akmasıyla geri oturmak kadar basit değildir. Farklı müşteriler farklı davranır ve bunu yönetmek zorundasınız. Örneğin, bazı istemciler verileri eşleştirecek ve bazı eşikler karşılanana kadar uygulamayı bırakmayacaktır. Daha da kötüsü, bazıları, bağlantı kapatılana kadar verileri uygulamaya aktarmaz.
Dolayısıyla, istemciye birden fazla ileti gönderiyorsanız, örneğin, istemci uygulamasının 50 mesaj verisi alınana kadar veri alma olasılığı yoktur. Bu çok gerçek zamanlı değil.
WebSocket kullanılamıyorsa HTTP akışı uygun bir alternatif olabilir, ancak bu bir derli toplu değildir. Gerçek dünya koşullarında Web'in kötülüklerinde sağlam bir şekilde çalışmak için iyi bir anlayışa ihtiyacı vardır.
Kaybettiğim başka önemli farklılıklar var mı?
Henüz kimsenin bahsettiği başka bir şey var, o yüzden onu getireceğim.
WebSocket protokolü, daha üst düzey protokoller için bir taşıma katmanı olarak tasarlanmıştır. JSON mesajlarını veya doğrudan bir WebSocket bağlantısı üzerinden gönderemediğiniz halde standart veya özel protokolleri de taşıyabilir.
Örneğin, insanlar zaten yaptığı gibi, WebSocket üzerinden AMQP veya XMPP yapabilirdiniz. Dolayısıyla bir müşteri, bir AMQP brokerinden, doğrudan aracıya (sanki bazı durumlarda) bağlıymış gibi mesajlar alabilir.
Veya bazı özel protokolü olan mevcut bir sunucunuz varsa, bunu WebSocket üzerinden taşıyabilir, böylece bu arka uç sunucusunu Web'e genişletebilirsiniz. Çoğu zaman, kuruluşta kilitlenmiş olan mevcut bir uygulama, arka uç altyapısını değiştirmek zorunda kalmadan WebSocket'ı kullanarak erişimi genişletebilir.
(Doğal olarak, tüm bunları güvenli bir şekilde yapmak isteyebilirsiniz, böylece satıcıya veya WebSocket sağlayıcısına danışın.)
Bazı kişiler WebSocket'ı Web için TCP olarak adlandırmışlardır. Çünkü TCP'nin üst düzey protokolleri taşıması gibi, WebSocket da, ancak bir şekilde Web altyapısıyla uyumlu.
Dolayısıyla, WebSocket üzerinden doğrudan JSON (veya herhangi bir şekilde) mesajı gönderilirken, her zaman mevcut protokolleri de dikkate almalıdır. Yapmak istediğiniz birçok şey için, muhtemelen bunu yapmak için düşünülen bir protokol var.
Eğer SO'da bulunan soruların çoğunu tek bir soruya yeniden sorduğum veya birleştirdiğim için özür dilerim, fakat sadece SO ve web üzerinde bu bilgi ile ilgili tüm bilgilerin dışında mükemmel bir anlam ifade etmek istiyorum.
Bu harika bir soruydu ve cevaplar çok bilgilendirici oldu!
Bir şey daha isteyebilirsem: Web akışları olmasa da, http akışının proxy'ler tarafından önbelleğe alınabileceğini söyleyen bir yere rastladım. Bu ne anlama geliyor?
(StackOverflow yorum yanıtlarının boyutunu sınırlandırır, bu yüzden satır içi değil, burada cevap vermek zorunda kaldım.)
İyi bir noktaya değindin. Bunu anlamak için geleneksel bir HTTP senaryosunu düşünün ... Bir tarayıcının bir web sayfası açtığını düşünün. http://example.comdiyelim. Sunucu, sayfa için HTML'yi içeren HTTP ile yanıt verir. Ardından tarayıcı sayfada kaynak olduğunu görür ve bu nedenle CSS dosyalarını, JavaScript dosyalarını ve görüntülerini sormaya başlar. Hepsi aynı olacak statik dosyalar herşey Onları isteyen müşteriler.
Bazı proxy'ler statik kaynakların önbelleğini alacaktır, böylece diğer istemcilerden gelen istekler, bunları elde etmek için merkezi web sunucusuna geri dönmek zorunda kalmak yerine, bu statik kaynakları proxy'den alabilir. Bu önbelleğe alma işlemidir ve isteklerinizi ve merkezi hizmetlerinizi işleyerek işlemek için harika bir stratejidir.
Yani müşteri # 1 istekleri http://example.com/images/logo.gifdiyelim. Bu istek, proxy'den, logo.gif'in hizmet verdiği merkezi web sunucusuna kadar gider. Logo.gif vekilden geçerken, vekil bu resmi kaydedecek ve adresi ile ilişkilendirecektir. http://example.com/images/logo.gif.
İstemci # 2 geldiğinde ve ayrıca istekleri http://example.com/images/logo.gifvekil, görüntüyü döndürebilir ve merkezdeki web sunucusuna geri iletişim gerektirmez. Bu, son kullanıcı için her zaman mükemmel olan daha hızlı bir yanıt verir, ancak aynı zamanda merkezde daha az yük olduğu anlamına gelir. Bu, azaltılmış donanım maliyetlerine, ağ maliyetlerinin azalmasına vb. Dönüşebilir. Bu iyi bir şey.
Sorun, web sunucusunda logo.gif güncellendiğinde ortaya çıkar. Proxy, yeni bir görüntü olduğunu bilmeden eski görüntüyü sunmaya devam edecektir. Bu, verinin sona ermesinden hemen sonra, vekilin sadece "sona ermeden" kısa bir süre için görüntüyü önbelleğe alacağı ve bir sonraki isteğin vekil sunucudan proxy'nin önbelleğini yenilediği web sunucusuna gideceği bir şeyle sonuçlanır. Ayrıca merkezi bir sunucunun bilinen önbelleklere ulaşabileceği daha gelişmiş çözümler de vardır, ve işler oldukça karmaşıklaşabilir.
Bu, sorunuza nasıl bağlanır?
Sunucunun bir istemciye HTTP akışını gerçekleştirdiği HTTP akışını sordunuz. Ancak veri akışı, veri göndermeyi durdurma dışında, normal HTTP gibidir. Bir web sunucusu bir resim sunuyorsa, sonunda sona eren istemciye HTTP gönderir: tüm resmi yolladınız. Ve eğer veri göndermek istiyorsanız, tam olarak aynıdır, ancak sunucu sadece çok uzun bir süre (kitlesel devasa bir görüntü gibi) gönderir, hatta hiç bitmez.
Proxy'nin bakış açısından, bir görüntü gibi statik bir kaynak için HTTP'yi veya HTTP akışından veriyi ayırt edemez. Her iki durumda da, istemci sunucunun bir isteğini yaptı. Vekil bu talebi ve aynı zamanda cevabı hatırladı. Talep geldiğinde, proxy aynı cevabı verir.
Dolayısıyla, müşteriniz hisse senedi fiyatları için bir talepte bulunduysa ve bir yanıt aldığında, bir sonraki müşteri aynı talebi yapabilir ve önbelleğe alınmış verileri alabilir. Muhtemelen istediğin şey değil! Hisse senedi fiyatları talep ederseniz, en son verileri istiyorsanız, doğru mu?
Yani bu bir sorun.
Bunun gibi sorunların üstesinden gelmek için püf noktaları ve çözümler var. Açıkçası, bugün kullanımda olduğu için çalışmak için HTTP akışını alabilirsiniz. Her şey son kullanıcı için şeffaftır, ancak bu mimarileri geliştiren ve sürdüren insanlar çemberler üzerinden atlamak ve bir bedel ödemek zorundadır. Daha fazla bakım, daha fazla donanım, daha karmaşık, daha fazla maliyet anlamına gelen aşırı karmaşık mimarilerle sonuçlanır. Ayrıca, geliştiricilerin genellikle uygulama, GUI ve iş mantığına odaklanmaları gerektiğinde sahip olmaları gereken bir şeyle ilgilenmeleri gerektiği anlamına gelir - temel iletişim konusunda endişelenmemeleri gerekir.
HTTP, bir istemcinin bir sunucuyla 2'ye bağlanabileceği bağlantı sayısını sınırlar (bu, alt etki alanları kullanılarak azaltılabilir) ve IE'nin bunu hevesle uyguladığı bilinmektedir. Firefox ve Chrome daha fazlasına izin veriyor (başımın üst kısmından tam olarak kaç tane hatırlayamasam da). Bu büyük bir sorun gibi görünmeyebilir, ancak gerçek zamanlı güncellemeler için sürekli olarak 1 bağlantı kullanıyorsanız, diğer tüm isteklerin diğer HTTP bağlantısı boyunca darboğazda olması gerekir. Ve istemcilerden daha açık bağlantıların olması, sunucuya daha fazla yük koyar.
WebSockets, TCP tabanlı bir protokoldür ve bu nedenle bu HTTP düzeyindeki bağlantı sınırından etkilenmez (ancak, elbette, tarayıcı desteği aynı değildir).