WebSockets protokolü vs HTTP

SORU

5 ŞUBAT 2013, Salı

WebSockets protokolü vs HTTP

Websocket ve HTTP hakkında birçok bloglar ve tartışma vardır, ve pek çok geliştirici ve siteleri kuvvetle websockets savunucusu, ama ben hala nedenini anlayamıyorum.

örneğin (websocket severlerin argümanlar):

HTML5 Web Yuva iletişim—tam çift yönlü, Web üzerinden tek bir soket üzerinden çalışan çift yönlü iletişim kanalı web sonraki evrimi temsil ediyor. ( http://www.websocket.org/quantum.html )

HTTP akışı destekler: istek vücut akış(büyük dosyaları yüklerken kullandığınız) ve vücudun tepkisini izle.

Sürekli yoklama yaptığında yapımı sırasında WebSocket, istemci ve 2 bayt her hangi kare başına sunucu veri alışverişi ile bağlantısı, http başlık 8 kilo byte göre.

Bu yüzden 2 bayt tcp ve tcp protokolleri altında havai içermez?

GET /about.html HTTP/1.1
Host: example.org

Bu ~48 bayt http başlık.

http - http://ru.wikipedia.org/wiki/Chunked_transfer_encoding kodlama yığını :

23
This is the data in the first chunk
1A
and this is the second one
3
con
8
sequence
0

Böylece, her parça başına yükü büyük değil.

Ayrıca her iki protokol TCP üzerinden çalışır, uzun süre canlı bağlantı ile tüm TCP sorunlar hala vardır.

Soru:

Neden websockets protokolü daha mı iyi?
Neden http protokolü güncelleştirme yerine taşındı?

CEVAP

5 ŞUBAT 2013, Salı

1) Neden WebSockets protokolü daha iyi?

WebSockets müşteri için özellikle düşük gecikme için düşük gecikmeli iletişim gerektiren durumlar için daha iyi mesajlar sunucuya. Müşteri veri sunucusu için oldukça düşük gecikme süresi uzun tutulan bağlantıları kullanarak alabilirsiniz ve transfer yığın halinde. Ancak, bu her istemci mesajı sunucuya için kurulacak yeni bir bağlantı gerektirir sunucu gecikme için istemci ile yardımcı olmuyor.

Senin 48 bayt HTTP sıkışması değil gerçekçi için gerçek dünya HTTP tarayıcı bağlantı yeri var genellikle birkaç kilobayt veri parçasi olarak gönderilmesini talep (her iki yönde de dahil olmak üzere birçok başlık ve tanımlama bilgisi verileri. İşte Chrome yanıt/: bir isteği bir örnek

Örnek (cookie veri olmadan, 490 kurabiye veri bayt dahil olmak üzere 2800 bayt) istek:

GET / HTTP/1.1
Host: www.cnn.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [[[2428 byte of cookie data]]]

Örnek cevap (355 bayt):

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 13 Feb 2013 18:56:27 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: CG=US:TX:Arlington; path=/
Last-Modified: Wed, 13 Feb 2013 18:55:22 GMT
Vary: Accept-Encoding
Cache-Control: max-age=60, private
Expires: Wed, 13 Feb 2013 18:56:54 GMT
Content-Encoding: gzip

Hem HTTP hem de WebSockets eşdeğer büyüklükteki ilk bağlantı el sıkışma, ama bir WebSocket bağlantı ilk el sıkışma olduğunu bir kez yapılan ve daha sonra küçük mesajlar sadece 6 bayt Tepegöz (2 başlık ve 4 İÇİN MASKE değeri). Gecikme yük ayrıştırma//o başlıkları tanıtıcı depolamak için mantıktan çok başlıkları boyutu, ama. Buna ek olarak, TCP bağlantı kur gecikme muhtemelen her istek için boyut veya işleme zaman daha büyük bir faktördür.

2) Neden oldu HTTP protokolü güncelleştirme yerine taşındı?

Re-mühendis HTTP protokolü SPDY HTTP 2.0 gibi daha iyi performans ve düşük gecikme elde etmek için yoğun bir çaba var. Bu durumu iyileştirmek için normal HTTP istekleri, ama muhtemelen WebSockets ve/veya WebRTC DataChannel olacak hala düşük gecikme için istemci sunucuya veri aktarımı daha HTTP protokolü (ya da kullanacağı bir mod görünen bir sürü gibi WebSockets neyse).

Güncelleme:

Burada protokoller hakkında düşünmek için bir çerçeve

TCP: düşük seviye, iki yönlü, tam çift yönlü ve garantili sipariş katmanı aktarım. Hayır tarayıcı desteği (eklenti/Flash) hariç).
HTTP 1.0: istek-yanıt Aktarım Protokolü TCP üzerinde katmanlı. İstemci tam bir istekte, sunucu tam bir yanıt verir, ve sonra bağlantıyı kapattı. İstek metodları (GET, POST, HEAD), sunucudaki kaynakları için özel işlem anlamı var.
HTTP 1.1: HTTP istek-yanıt niteliği 1.0, ama bağlantı birden çok tam istekleri için açık kalmasını sağlar tam yanıt (istek başına bir yanıt)/uyguluyor. Hala istek dolu bir başlık ve ancak bağlantıyı yeniden kullanılan ve kapalı yanıt vardır. HTTP 1.1 de ayrıca özel işlem anlamlar içeren bazı ek istek yöntemleri (SEÇENEKLER, PUT, DELETE, TRACE, CONNECT) eklendi. HTTP 2.0 taslak önerisi introduction belirtildiği gibi, ancak HTTP 1.1 ardışık bu büyük ölçüde HTTP 1.1 programı tarayıcıları ve sunucuları arasında gecikme çözmek için sınırları çok yaygın olarak dağıtılır.
Uzun zamandır yoklarbir çeşit "sunucu hemen yanıt yok (1.0 veya 1.1) (veya sadece kısmen başlıkları ile yanıt verir) istemciye HTTP" isteği. hack Sunucu yanıtı sonra, istemci hemen yeni bir istek (HTTP 1.1 eğer aynı bağlantı ile) gönderir.
İzle, HTTP: çeşitli teknikler (parçalı/yanıt yığını) sunucu tek bir istemci isteği için birden fazla yanıt göndermek için izin. W3C Server-Sent Events text/event-stream MIME tipi kullanarak bu standart bir hale getiriyor. Tarayıcı API WebSocket API için oldukça benzer) EventSource API denir.
Kuyruklu yıldız/sunucu itmebu uzun anket ve HTTP akış içeren bir terimdir. Kuyruklu yıldız kütüphaneler çoğu zaman farklı teknikler deneyin ve çapraz tarayıcı en üst düzeye çıkarmak için destek ve siteler için Sunucu Desteği.
WebSockets: Taşıma katmanı dahili HTTP dostu Yükseltme bir el sıkışma kullandığı TCP. WebSockets bir ileti aktarımını temel alan bir akarsu taşıma TCP, aksine: mesaj Tel ayrılmış ve yeniden toplandı-tam uygulama için teslimattan önce. WebSocket bağlantı çift yönlü, tam çift yönlü ve uzun ömürlüdür. İlk el sıkışma isteği, yanıt/sonra, işlem mantığı yok ve mesaj yükü başına çok az şey var. İstemci ve sunucu herhangi bir anda mesaj gönderebilir ve mesaj alındığı zaman uyumsuz olarak işlemesi gerekir.
SPDYbir Google HTTP daha verimli bir tel protokolünü kullanarak ama tüm HTTP semantik bakımı (istek/yanıt, kurabiye, kodlama) uzatılması teklifi başlattı. SPDY yeni bir çerçeve biçimi (uzunluk öneki Kare) tanıtır ve yeni çerçeve katman üzerine HTTP istek/yanıt çiftleri katman için bir yol belirtir. Başlıkları sıkıştırılmış olabilir ve yeni başlıkları bağlantı kurulduktan sonra gönderilebilir. Tarayıcılar ve sunucular SPDY gerçek dünya uygulamaları vardır.
HTTP 2.0: var SPDY benzer hedefleri: HTTP semantik koruyarak bekleme süresi ve yük. HTTP azaltmak Mevcut taslak SPDY türetilmiştir ve çok benzer bir el sıkışma ve bir çerçeve için WebSocket standardını yükseltme sıkışması ve veri bir çerçeve tanımlar. Alternatif HTTP 2.0 taslak önerisi (httpbis hızlı hareket) kullanır aslında WebSockets için aktarım katmanı ve ekler çoklu SPDY ve HTTP eşleme gibi bir WebSocket uzantısı (WebSocket uzantıları müzakere sırasında el sıkışma).
CU-WebRTC WebRTC/: peer-to-peer tarayıcılar arasında bağlantı sağlamak için öneriler. Bu rakamlar taşıma/TCP yerine SDP veri birimi olduğundan daha düşük ortalama ve maksimum gecikme iletişimi sağlamak olabilir. Bu sonraki tüm paketleri (sipariş teslimat garantisi) teslim gecikme paketleri gecikme ani bırakılan paketler kaynaklanan TCP sorunu kaçınan/mesajları dışı sipariş teslim sağlar.