與http協議區別：

• http是需要客戶端發送一個請求之后，服務器才回一個response給客戶端，即“一個request對應一個response”,雖然http是基于全雙工的tcp協議而定制的，但是http協議確實沒做到真正的全雙工！假設在客戶端沒發送一個http的request給服務器而服務器卻首先發送一個response給客戶端的話，那么客戶端是沒法接受這個response的！網上很多人覺得這個很不好，其實嘛，我倒是覺得這是一種保護客戶端的舉措，試想，如果客戶端在沒發起請求的時候反而隨便接受來自服務器可以的東西，那么，這是很容易造成不法分子的攻擊的?。ㄖ劣谠趺垂?，你可以想象淘寶店知道了你的地址之后給你整天寄‘有害’的快遞的話，你會舒服么？）
  但是，有些場景非常需要服務器自己發送數據給客戶的！但是鑒于上面的攻擊問題，我們有沒有一種好的解決方式呢？有的，那就是通過websocket協議來實現，那么websocket協議到底是怎么實現的呢？

• 我們都知道，http中一個request對應一個response，但是如果我們這樣：一個http對應多個response，比如：股票網站需要實時刷新網站上面的數據，刷新的時間基本是基于毫秒的！此時的http的一個request對應一個response就不適用了，試想，有哪個客戶為了刷新股票數據然后就去不停的手動點擊發起request來接受服務端的response，所以我們此時希望服務端智能一點，我們希望我們只需要點擊一次網頁就能夠不停的給我刷新網頁，當然服務器也不是閑著蛋疼不停的給你發送response，畢竟這樣消耗的資源太大了，我們為了節省資源同時也是合乎邏輯的決定:當且僅你請求的數據在服務器有更新的時候，服務器才會給你發送更新后的數據，而不是不停的給客戶端發送沒更新的數據。這個跟上面的攻擊就有很明顯的不同了，首先，客戶端事先需要發起一次http協議，然后服務端在有數據更新的時候才返回更新的數據給客戶端，此時客戶端接受到更新數據渲染在頁面中去，然后繼續等待服務器再一次新的數據（此時不用再發送http的request請求了），從這里可以看出，其實websocket協議更像是基于tcp/ip的http的變種而已，而已還基于一次的http請求。離開了http請求的話，websocket協議也是不能運作的！但是他不是基于http協議，因為跟http協議有著本值的區別，他只是順便利用了一次http協議而已！之后的多次response都會由服務器自動返回給客戶端。

• websocket完美的解決了上面的攻擊問題和http協議的不足！

與tcp的區別：

• 說實話我想不到跟tcp有什么特別的相像之處,他們完全是不同層面的東西,tcp在七層模型的網絡層,http和websocket都在七層模型的會話層,websockt確實只需要一次request,但是他確實不是一次"握手"就可以了,但是在這里使用握手真的合適么?我們都知道tcp才有握手之說,但是某些博文硬生生說出了握手這個詞,我的天!!
  注意這里他們所說的握手跟tcp的三次握手四次揮手完全不是一個東西,我之前看其他博文看到只需要一次握手的websocket,剛開始時候我以為網絡要逆天了?結果卻是這么一個東西,不過這個協議確實在某些場合還是很有用的!我看到招聘網上寫了Django+Daphne,然后順著Daphne才找到了這個websocket協議,看了下博文,發現很多誤解,于是就發了這篇博文做解釋!

• 接下來放上幾張七層網絡和五層(或者四層)網絡的圖,當然我一般不喜歡分為5層,一般都是分為4層,也就是合并最下面的2層:

  
  
  image.png
  
  
  image.png
  
  
  image.png
  
  
  image.png