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==

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

服務端返回內容以下，狀態代碼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