HTTP長連接短連接以及websockect

HTTP協議與TCP/IP協議的關系

TCP/IP是個協議組，可分為三個層次：網絡層、傳輸層和應用層。

在網絡層有IP協議、ICMP協議、ARP協議、RARP協議和BOOTP協議。

在傳輸層中有TCP協議與UDP協議。

在應用層有:TCP包括FTP、HTTP、TELNET、SMTP等協議；UDP包括DNS、TFTP等協議。

HTTP的長連接和短連接本質上是TCP長連接和短連接。HTTP屬於應用層協議，在傳輸層使用TCP協議，在網絡層使用IP協議。

IP協議主要解決網絡路由和尋址問題，TCP協議主要解決如何在IP層之上可靠的傳遞數據包，使在網絡上的另一端收到發端發出的所有包，並且順序與發出順序一致。TCP有 可靠，面向連接的特點。

 

HTTP協議中的長短連接？

http1.0協議里面默認短連接，需要在request里面增加Connection：keep-alive

http1.1協議里面默認長連接

 

短連接的操作步驟是：
建立連接——數據傳輸——關閉連接…建立連接——數據傳輸——關閉連接
長連接的操作步驟是：
建立連接——數據傳輸…（保持連接）…數據傳輸——關閉連接

http長連接缺點：

基於http協議的長連接減少了請求,減少了建立連接的時間,但是每次交互都是由客戶端發起的,客戶端發送消息,服務端才能返回客戶端消息。因為客戶端也不知道服務端什么時候會把結果准備好，所以客戶端的很多請求是多余的,僅是維持一個心跳,浪費了帶寬。

在長連接中一般是沒有條件能夠判斷讀寫什么時候結束，所以必須要加長度報文頭。讀函數先是讀取報文頭的長度，再根據這個長度去讀相應長度的報文。 

WebSockect就是為了解決長連接這個缺點：

發送 http 請求后服務端如果沒有返回則連接是一直連着的，等服務端有東西要“推送”給瀏覽器時，相當於給之前發送的這個 http 請求回了一個 http 響應。然后這個保持的時間比較長的 http 連接就斷了。然后瀏覽器再次發送一個 http 請求，服務器端再 hold 住不返回，等待有東西需要“推送”給瀏覽器時，再給這個 http 請求一個響應，然后斷開連接。循環往復。一旦瀏覽器不給服務器發送 http 請求，那么服務器是不能主動給瀏覽器推送消息的，因為根本沒有連着的連接給你推。

WebSocket 則不同，它握手后建立的連接是不會斷的（除了意外情況和程序主動掐斷）。不需要瀏覽器在每次收到服務器推送的消息后再發起請求。而且服務器端可以隨時給瀏覽器推送消息，不需要等瀏覽器發 http 請求，因為 WebSocket 的連接一直在沒斷。

在段時間內突然發生大量短連接？1s內5000個短連接

（客戶端和服務端都可能發生）：率先發生主動關閉的一方所在的操作系統的socket端口和句柄被用盡（TIME-WAIT階段），系統無法再發起新的連接，解決方案是可以采用長連接（或者把TIME-WAIT的時間設置的短一點，也可以擴大端口范圍）

 

webSocket對比輪詢，長輪詢，流？

輪詢 ：客戶端以一定的時間間隔向服務端發出請求，以頻繁請求的方式來保持客戶端和服務器端的同步。

缺點：當客戶端以固定頻率向 服務器發起請求的時候，服務器端的數據可能並沒有更新，服務端在沒有數據更新的時候也要返回數據，這樣會帶來很多無謂的網絡傳輸，所以這是一種非常低效的實時方案。

 

長輪詢：長輪詢是對定時輪詢的改進和提高，目地是為了降低無效的網絡傳輸。當前端向后台發請求，后台數據如果還沒有更新則不返回，直到后台數據更新了再返回給前端，前端收到后台返回的數據后才發下一次請求。在無消息的情況下不會頻繁的請求。但是請求在后台一直懸掛，連接長時間保持，浪費資源。

 

這兩種模式有一個共同的缺點，就是除了真正的數據部分外，服務器和客戶端還要大量交換 HTTP header，信息交換效率很低。（WebSocket就能很好的解決這個問題，無論是在性能還是數據傳輸量的大小方面）

 

流 ：技術方案通常就是在客戶端的頁面使用一個隱藏的窗口向服務端發出一個長連接的請求。服務器端接到這個請求后作出回應並不斷更新連接狀態以保證客戶端和服務 器端的連接不過期。通過這種機制可以將服務器端的信息源源不斷地推向客戶端。

缺點：這種機制在用戶體驗上有一點問題，需要針對不同的瀏覽器設計不同的方案來改進 用戶體驗，同時這種機制在並發比較大的情況下，對服務器端的資源是一個極大的考驗。

WebSockect是什么？

HTML5開始提供的一種瀏覽器與服務器進行全雙工通訊的網絡技術，屬於應用層協議。它基於TCP傳輸協議，並復用HTTP的握手通道。

它相比HTTP長連接的協議？

1. 支持雙向通信，實時性更強。
2. 更好的二進制支持。
3. 較少的控制開銷（這個很關鍵）。連接創建后，ws客戶端、服務端進行數據交換時，協議控制的數據包頭部較小。在不包含頭部的情況下，服務端到客戶端的包頭只有2~10字節（取決於數據包長度），客戶端到服務端的的話，需要加上額外的4字節的掩碼。而HTTP協議每次通信都需要攜帶完整的頭部。

WebSockect建立連接的過程？

WebSocket復用了HTTP的握手通道。具體指的是，客戶端通過HTTP請求與WebSocket服務端協商升級協議。協議升級完成后，后續的數據交換則遵照WebSocket的協議。

步驟：

1.客戶端：申請協議升級

首先，客戶端發起協議升級請求。可以看到，采用的是標准的HTTP報文格式，且只支持GET方法。

GET / HTTP/1.1
Host: localhost:8080
Origin: http://127.0.0.1:3000
Connection: Upgrade //表示要升級協議
Upgrade: websocket  //表示要升級到websockect
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: w4v7O6xFTi36lq3RNcgctw==

2、服務端：響應協議升級。

服務端返回內容如下，狀態代碼101表示協議切換。

HTTP/1.1 101 Switching Protocols
Connection:Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: Oy4NRAQ13jhfONC7bP8dTKb4PTU=

 

Sec-WebSocket-Key/Accept的作用

主要作用在於提供基礎的防護，減少惡意連接、意外連接。

Sec-WebSocket-Key/Sec-WebSocket-Accept 的換算，只能帶來基本的保障，但連接是否安全、數據是否安全、客戶端/服務端是否合法的 ws客戶端、ws服務端，其實並沒有實際性的保證。

 

參考：

https://www.cnblogs.com/chyingp/p/websocket-deep-in.html