Soru HTTP Çağırma, Uzun Çağırma, HTTP Akışı ve WebKontrollerini Anlama


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!


93
2017-09-23 18:27


Menşei


Sunucu Gönderilen Olaylar İki yönlü iletişime ihtiyaç duymadığınız zaman da bakmaya değer. - leggetter
Bu gerçekten yararlı bir soru. Birden fazla yazarın katkıda bulunabileceği tek bir cevap varsa, potansiyel olarak daha yararlı olacağını düşünüyorum. - leggetter
@leggetter Teşekkürler Phil, sunucuyla ilgili olaylarla ilgili ipucu için teşekkürler. İki yönlü iletişim senaryoları hakkında bilgi edinmek istiyorum. Teşekkürler. - Software Guy
HTTP Akışı ve Uzun Yoklama ile iki yönlü iletişim için 2. bağlantıya ihtiyacınız vardır. Sunucu -> istemci 'push' iletişimi ve istemci için ikinci kısa süreli bağlantı -> sunucu iletişimleri için daha uzun bir bağlantı kuruldu. Bu ikinci bağlantı, abonelikler kurmak ve verileri değiştirmek gibi şeyler yapmak için kullanılır. Bu nedenle, EventSource iki yönlü bir çözümde kullanılabilir ve aslında aslında HTTP Akışı ve Uzun Yoklama'dan doğan standartlaştırılmış bir çözümdür. - leggetter
Yazdığım tekniklerin bu sınıflandırmasına da göz atmak isteyebilirsiniz: stackoverflow.com/questions/12078550/... - Alessandro Alinone


Cevaplar:


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.


74
2017-09-23 20:57



Güzel yanıt için çok teşekkürler Kanaka. Lütfen http akışının neden / nasıl websockets'dan daha yüksek bir gecikme olduğunu söyler misiniz? belki basit bir örnekle? çok teşekkürler. - Software Guy
@SoftwareGuy. Birçok sebep. Son tarayıcılarda, veriden haberdar olmak için XMLHTTPRequest onprogress olay işleyicisini kullanabilirsiniz. Ancak, spec 50ms'in en küçük bildirim aralığı olduğunu söylüyor. Aksi halde yanıt verisi için anket yapmalısınız. Ayrıca, istemci yeni bir HTTP bağlantısı kurar ve böylece gidiş dönüş gecikmesini önemli ölçüde artırır. Ayrıca, birçok web sunucusu 30 saniyeden sonra HTTP bağlantılarını kestirir veya bu nedenle sunucu itme bağlantısını tekrar tekrar kurmanız gerektiği anlamına gelir. Yerel bir ağda 5-10ms WebSocket roundtrip gecikme gördüm. HTTP akış gecikmesi muhtemelen 50 ms'dir. - kanaka
Detaylı cevap için çok teşekkürler :) - Software Guy
Bağlantı kurulduktan sonra HTTP akışının WebSockets'tan daha yüksek bir gecikme olduğuna inanmıyorum. Yeni bir veri parçası alındığında çoğu tarayıcıda xhr.onreadystatechange olay patlayacak ve yeni verilere xhr.responseText. HTTP akışıyla ilgili temel problemler, çapraz tarayıcıyı nasıl kullandığınızın tutarsızlıklarıdır (çok parçalı değiştirme, responseText büyümeyi sürdürür, ilk arabellek temizliği vb.). Açıkçası, çift yönlü iletişim istediğinizde ana gecikme sorunu ortaya çıkıyor ve sorun olan 2. bağlantı. - leggetter
@Nathan iyi bir yüksek lisans tezi projesi gibi geliyor! Elbette, yoklama sistemi bir olay odaklı modelden daha yoğun tutacaktır, ancak güç tasarruflarının tam olarak ne olduğu, farklı ölçeklerde oldukça kapsamlı deneysel testlere ihtiyaç duyacaktır. - kanaka


Ç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!


13
2017-09-24 06:47



Mükemmel yardım ve bilgi için çok teşekkürler Robin. 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? - Software Guy
StackOverflow, yanıt yorumlarında boyutu sınırlandırdığından, aşağıda yanıtımı verdim: stackoverflow.com/questions/12555043/... - Robin Zimmermann
@RobinZimmermann, cevabım benim favorim. Gerçekten iyi bir cevap için +1. - securecurve


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.


10
2017-09-24 16:26



mükemmel detay Robin, çok teşekkürler! Tam cevabınızı takdir ediyorum. Buradaki tüm harika insanlardan çok şey öğrendim zaten! :) - Software Guy
Robin için bir başka +1 - securecurve


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).


4
2017-09-23 19:20



Teşekkürler thejuice, sizin tarafınızdan vurgulanan çoklu eşzamanlı bağlantıların yanı sıra, websockets ile ilgili varsayımların kalanı da doğru mu? - Software Guy