1) WebSockets protokolü neden daha iyi?
WebSockets, özellikle istemciden sunucuya iletilerin düşük gecikme süresi için düşük gecikmeli iletişim içeren durumlar için daha iyidir. Sunucudan istemciye veriler için, uzun süreli bağlantılar ve yığın aktarımı kullanarak oldukça düşük gecikme süresi elde edebilirsiniz. Ancak, bu her istemciden sunucuya ileti için yeni bir bağlantı kurulmasını gerektiren istemciden sunucuya gecikme süresine yardımcı olmaz.
48 baytlık HTTP el sıkışmanız, birçok başlık ve çerez verisi dahil olmak üzere, isteğin bir parçası olarak (her iki yönde) genellikle birkaç kilobayt veri gönderildiği gerçek dünyadaki HTTP tarayıcı bağlantıları için gerçekçi değildir. Chrome'u kullanmaya yönelik bir istek / yanıt örneği:
Örnek istek (çerez verileri dahil 2800 bayt, çerez verileri olmayan 490 bayt):
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 yanıt (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 boyutlu ilk bağlantı tokalaşmalarına sahiptir, ancak WebSocket bağlantısıyla ilk tokalaşma bir kez gerçekleştirilir ve daha sonra küçük iletilerin yalnızca 6 bayt ek yükü vardır (başlık için 2 ve maske değeri için 4). Gecikme yükü başlıkların büyüklüğünden çok değil, mantıktan bu başlıkların ayrıştırılması / ele alınması / saklanmasıdır. Ayrıca, TCP bağlantı kurulum gecikmesi her istek için büyüklük veya işlem süresinden muhtemelen daha büyük bir faktördür.
2) HTTP protokolünü güncellemek yerine neden uygulandı?
SPDY , HTTP 2.0 ve QUIC gibi daha iyi performans ve daha düşük gecikme süresi sağlamak için HTTP protokolünü yeniden tasarlama çabaları vardır . Bu, normal HTTP isteklerinin durumunu iyileştirir, ancak WebSockets ve / veya WebRTC DataChannel'in istemciden sunucuya veri aktarımı için HTTP protokolünden daha düşük gecikme süresine sahip olması muhtemeldir (veya WebSockets'e çok benzeyen bir modda kullanılacaktır) neyse).
Güncelleme :
İşte web protokollerini düşünmek için bir çerçeve:
- TCP : düşük seviyeli, çift yönlü, tam çift yönlü ve garantili sipariş taşıma katmanı. Tarayıcı desteği yok (eklenti / Flash hariç).
- HTTP 1.0 : TCP üzerinde katmanlı istek-yanıt aktarım protokolü. İstemci bir tam istekte bulunur, sunucu bir tam yanıt verir ve ardından bağlantı kapatılır. İstek yöntemleri (GET, POST, HEAD) sunucudaki kaynaklar için belirli işlemsel anlamlara sahiptir.
- HTTP 1.1 : HTTP 1.0'ın istek yanıtı niteliğini korur, ancak bağlantının birden çok tam istek / tam yanıt (her istek için bir yanıt) için açık kalmasına izin verir. İstekte ve yanıtta hala tam başlıklar var, ancak bağlantı yeniden kullanılıyor ve kapatılmıyor. HTTP 1.1 ayrıca belirli işlemsel anlamları olan bazı ek istek yöntemleri (OPTIONS, PUT, DELETE, TRACE, CONNECT) ekledi. Bununla birlikte, HTTP 2.0 taslak teklifinin girişinde belirtildiği gibi , HTTP 1.1 boru hattı yaygın olarak dağıtılmaz, bu nedenle tarayıcılar ve sunucular arasındaki gecikmeyi çözmek için HTTP 1.1'in kullanımını büyük ölçüde sınırlar.
- Uzun anket : istemcinin isteğine hemen yanıt vermediği (veya yalnızca üstbilgilerle kısmen yanıt verdiği) HTTP'ye bir tür "hack" (1.0 veya 1.1). Bir sunucu yanıtından sonra istemci hemen yeni bir istek gönderir (HTTP 1.1 üzerinden aynı bağlantıyı kullanarak).
- HTTP akışı : sunucunun tek bir istemci isteğine birden fazla yanıt göndermesine izin veren çeşitli teknikler (çok parçalı / yığınlanmış yanıt). W3C, bunu bir MIME türü kullanarak Sunucu tarafından Gönderilen Olaylar olarak standartlaştırmaktadır
text/event-stream. Tarayıcı API'sine (WebSocket API'sine oldukça benzer) EventSource API adı verilir.
- Kuyruklu yıldız / sunucu aktarımı: Bu, uzun anket ve HTTP akışını içeren bir şemsiye terimdir. Kuyruklu yıldız kütüphaneleri, çapraz tarayıcı ve çapraz sunucu desteğini en üst düzeye çıkarmak için genellikle birden fazla tekniği destekler.
- WebSockets : HTTP dostu bir Yükseltme anlaşması kullanan bir aktarım katmanı yerleşik TCP. Akış aktarımı olan TCP'den farklı olarak, WebSockets mesaj tabanlı bir aktarımdır: mesajlar kabloda sınırlandırılır ve uygulamaya teslim edilmeden önce tam olarak yeniden birleştirilir. WebSocket bağlantıları iki yönlü, tam çift yönlü ve uzun ömürlüdür. İlk el sıkışma isteği / yanıtından sonra, işlemsel semantik yoktur ve mesaj başına yükü çok azdır. İstemci ve sunucu istediği zaman ileti gönderebilir ve ileti makbuzunu eşzamansız olarak işlemelidir.
- SPDY : Google, HTTP'yi daha verimli bir tel protokolü kullanarak genişletmek, ancak tüm HTTP anlambilimini (istek / yanıt, çerezler, kodlama) korumak için başlattı. SPDY yeni bir çerçeveleme biçimi (uzunluk ön ekli çerçevelerle) sunar ve HTTP istek / yanıt çiftlerini yeni çerçeveleme katmanına katmanlamanın bir yolunu belirler. Bağlantılar kurulduktan sonra başlıklar sıkıştırılabilir ve yeni başlıklar gönderilebilir. Tarayıcılarda ve sunucularda SPDY'nin gerçek dünya uygulamaları vardır.
- HTTP 2.0 : SPDY ile benzer hedeflere sahiptir: HTTP anlambilimini korurken HTTP gecikmesini ve ek yükü azaltın. Mevcut taslak, SPDY'den türetilmiştir ve bir el sıkışma ve el sıkışma ve çerçeveleme için WebSocket standardına çok benzeyen bir yükseltme anlaşması ve veri çerçevesi tanımlar. Alternatif bir HTTP 2.0 taslak teklifi (httpbis-speed-mobility) aslında taşıma katmanı için WebSockets kullanır ve SPDY çoğullama ve HTTP eşlemesini WebSocket uzantısı olarak ekler (el sıkışma sırasında WebSocket uzantıları üzerinde anlaşılır).
- WebRTC / CU-WebRTC : tarayıcılar arasında eşler arası bağlantıya izin veren öneriler. Altta yatan aktarım TCP yerine SDP / datagram olduğundan, bu daha düşük ortalama ve maksimum gecikme iletişimini etkinleştirebilir. Bu, sonraki tüm paketlerin teslimini geciktiren (sipariş dışı teslimatı garanti etmek için) bırakılan paketlerin neden olduğu gecikme ani artışlarının TCP sorununu önleyen paketlerin / mesajların sipariş dışı teslim edilmesine izin verir.
- QUIC : TCP'ye göre web gecikmesini azaltmayı amaçlayan deneysel bir protokoldür. Yüzeyde QUIC, UDP'de uygulanan TCP + TLS + SPDY'ye çok benzer. QUIC, HTTP / 2'ye eşdeğer çoğullama ve akış kontrolü, TLS'ye eşdeğer güvenlik ve TCP'ye bağlantı semantiği, güvenilirlik ve tıkanıklık kontrolü eşdeğeri sağlar. TCP işletim sistemi çekirdeklerine ve orta kutu ürün yazılımına uygulandığından, TCP'de önemli değişiklikler yapmak imkansızdır. Bununla birlikte, QUIC UDP'nin üzerine kurulduğundan, böyle bir sınırlama yaşamamaktadır. QUIC, HTTP / 2 anlambilimi için tasarlanmış ve optimize edilmiştir.
Kaynaklar :
- HTTP :
- Sunucu Tarafından Gönderilen Etkinlik :
- WebSockets :
- SPDY :
- HTTP 2.0 :
- WebRTC :
- QUIC :
