質是有區別的，socket是一個長連接，啟動后會一直連接，而且服務端和客戶端都可以主動發送信息，主要用于實時通訊和業務推送等，ajax就是一個短連接。只能有客戶端發起請求，然后一次請求完成之后就關閉了。

1.本質不同

Ajax,即異步JavaScript和XML，是一種創建交互式網頁應用的網頁開發技術；

WebSocket是HTML5一種新的協議，實現了瀏覽器與服務器全雙工通信。其本質是先通過HTTP/HTTPS協議進行握手后創建一個用于交換數據的TCP連接，服務端與客戶端通過此TCP連接進行實時通信。

2.生命周期不同

websocket建立的是長連接，在一個會話中一直保持連接；而ajax是短連接，數據發送和接受完成后就會斷開連接。

3.適用范圍不同

websocket一般用于前后端實時數據交互，而ajax前后端非實時數據交互。

4.發起人不同

Ajax技術需要客戶端發起請求，而WebSocket服務器和客戶端可以相互推送信息。

5.用法不同

ajax：

websocket:

一下 http 和 https

參考回答：

https 的 SSL 加密是在傳輸層實現的。

(1)http 和 https 的基本概念

http: 超文本傳輸協議， 是互聯網上應用最為廣泛的一種網絡協議， 是一個客戶端和服 務器端請求和應答的標準 (TCP) ， 用于從 WWW 服務器傳輸超文本到本地瀏覽器的傳 輸協議， 它可以使瀏覽器更加高效， 使網絡傳輸減少。

https: 是以安全為目標的 HTTP 通道， 簡單講是 HTTP 的安全版， 即 HTTP 下加入 SSL 層， HTTPS 的安全基礎是 SSL， 因此加密的詳細內容就需要 SSL。

https 協議的主要作用是：建立一個信息安全通道，來確保數組的傳輸，確保網站的真實 性。

(2)http 和 https 的區別？

http 傳輸的數據都是未加密的，也就是明文的， 網景公司設置了 SSL 協議來對 http 協議 傳輸的數據進行加密處理，簡單來說 https 協議是由 http 和 ssl 協議構建的可進行加密傳 輸和身份認證的網絡協議， 比 http 協議的安全性更高。

主要的區別如下：

Https 協議需要 ca 證書， 費用較高。

http 是超文本傳輸協議， 信息是明文傳輸， https 則是具有安全性的 ssl 加密傳輸協議。 使用不同的鏈接方式， 端口也不同， 一般而言， http 協議的端口為 80， https 的端口為443。

http 的連接很簡單，是無狀態的；HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳 輸 、身份認證的網絡協議， 比 http 協議安全。

(3)https 協議的工作原理

客戶端在使用 HTTPS 方式與 Web 服務器通信時有以下幾個步驟， 如圖所示。 客戶使用 https url 訪問服務器， 則要求web 服務器建立 ssl 鏈接。

web 服務器接收到客戶端的請求之后， 會將網站的證書 (證書中包含了公鑰) ， 返回或 者說傳輸給客戶端。

客戶端和 web 服務器端開始協商 SSL 鏈接的安全等級， 也就是加密等級。

客戶端瀏覽器通過雙方協商一致的安全等級，建立會話密鑰，然后通過網站的公鑰來加 密會話密鑰， 并傳送給網站。

web 服務器通過自己的私鑰解密出會話密鑰。

web 服務器通過會話密鑰加密與客戶端之間的通信。

(4)https 協議的優點

使用HTTPS 協議可認證用戶和服務器， 確保數據發送到正確的客戶機和服務器；

HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳輸 、身份認證的網絡協議， 要比 http 協議安全， 可防止數據在傳輸過程中不被竊取 、改變， 確保數據的完整性 。 HTTPS 是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻 擊的成本。

谷歌曾在 2014 年 8 月份調整搜索引擎算法， 并稱“比起同等 HTTP 網站， 采用 HTTPS 加密的網站在搜索結果中的排名將會更高”。

(5)https 協議的缺點

https 握手階段比較費時， 會使頁面加載時間延長 50%， 增加 10%~20%的耗電。

https 緩存不如 http 高效， 會增加數據開銷。

SSL 證書也需要錢， 功能越強大的證書費用越高。

SSL 證書需要綁定 IP， 不能再同一個 ip 上綁定多個域名， ipv4 資源支持不了這種消耗。

tcp 三次握手， 一句話概括

參考回答：

客戶端和服務端都需要直到各自可收發， 因此需要三次握手。

簡化三次握手：

<img width="487" alt="2018-07-10 3 42 11" src="https://user-images.githubusercontent.com/ 17233651/42496289-1c6d668a-8458-11e8-98b3-65db50f64d48.png">

從圖片可以得到三次握手可以簡化為：C 發起請求連接 S 確認，也發起連接 C 確認我們 再看看每次握手的作用： 第一次握手： S 只可以確認 自己可以接受 C 發送的報文段第 二次握手： C 可以確認 S 收到了自己發送的報文段， 并且可以確認 自己可以接受 S 發 送的報文段第三次握手： S 可以確認 C 收到了自己發送的報文段。

TCP 和 UDP 的區別

參考回答：

( 1) TCP 是面向連接的， udp 是無連接的即發送數據前不需要先建立鏈接。

( 2) TCP 提供可靠的服務 。也就是說， 通過 TCP 連接傳送的數據， 無差錯， 不丟失， 不重復， 且按序到達;UDP 盡最大努力交付， 即不保證可靠交付 。 并且因為 tcp 可靠， 面向連接， 不會丟失數據因此適合大數據量的交換。

( 3) TCP 是面向字節流，UDP 面向報文，并且網絡出現擁塞不會使得發送速率降低 (因 此會出現丟包， 對實時的應用比如 IP 電話和視頻會議等) 。

( 4) TCP 只能是 1 對 1 的， UDP 支持 1 對 1,1 對多。

( 5) TCP 的首部較大為 20 字節， 而 UDP 只有 8 字節。

( 6) TCP 是面向連接的可靠性傳輸， 而 UDP 是不可靠的。

WebSocket 的實現和應用

參考回答：

(1)什么是 WebSocket?

WebSocket 是 HTML5 中的協議， 支持持久連續， http 協議不支持持久性連接 。Http1.0 和 HTTP1.1 都不支持持久性的鏈接， HTTP1.1 中的 keep-alive， 將多個 http 請求合并為 1 個

(2)WebSocket 是什么樣的協議， 具體有什么優點？

HTTP 的生命周期通過 Request 來界定， 也就是 Request 一個 Response， 那么在 Http1.0 協議中， 這次 Http 請求就結束了 。在 Http1.1 中進行了改進， 是的有一個 connection： Keep-alive，也就是說，在一個 Http 連接中，可以發送多個 Request，接收多個 Response。 但是必須記住， 在 Http 中一個 Request 只能對應有一個 Response， 而且這個 Response 是被動的， 不能主動發起。

WebSocket 是基于 Http 協議的，或者說借用了 Http 協議來完成一部分握手，在握手階段 與 Http 是相同的。我們來看一個 websocket 握手協議的實現，基本是 2 個屬性，upgrade， connection。

基本請求如下：

GET /chat HTTP/1.1

Host: server.example.com

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==

Sec-WebSocket-Protocol: chat, superchat

Sec-WebSocket-Version: 13

Origin: http://example.com

多了下面 2 個屬性：

Upgrade:webSocket
Connection:Upgrade

告訴服務器發送的是websocket

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

HTTP 請求的方式， HEAD 方式

參考回答：

head： 類似于 get 請求， 只不過返回的響應中沒有具體的內容， 用戶獲取報頭 options： 允許客戶端查看服務器的性能， 比如說服務器支持的請求方式等等。

一個圖片 url 訪問后直接下載怎樣實現？

參考回答：

請求的返回頭里面， 用于瀏覽器解析的重要參數就是 OSS 的 API 文檔里面的返回http 頭， 決定用戶下載行為的參數。

下載的情況下：

x-oss-object-type: Normal
x-oss-request-id: 598D5ED34F29D01FE2925F41
x-oss-storage-class: Standard

說一下 web Quality (無障礙)

參考回答：

能夠被殘障人士使用的網站才能稱得上一個易用的 (易訪問的) 網站。 殘障人士指的是那些帶有殘疾或者身體不健康的用戶。

使用 alt 屬性：

<img src="person.jpg" alt="this is a person"/>

有時候瀏覽器會無法顯示圖像 。具體的原因有：

用戶關閉了圖像顯示

瀏覽器是不支持圖形顯示的迷你瀏覽器

瀏覽器是語音瀏覽器 (供盲人和弱視人群使用)

如果您使用了alt 屬性， 那么瀏覽器至少可以顯示或讀出有關圖像的描述。

幾個很實用的 BOM 屬性對象方法?

參考回答：

什么是 Bom? Bom 是瀏覽器對象 。有哪些常用的 Bom 屬性呢？

(1)location 對象

location.href-- 返回或設置當前文檔的 URL

location.search -- 返回 URL 中的查詢字符串部分 。 例

如 http://www.dreamdu.com/dreamdu.php?id=5&name=dreamdu 返回包括(?)后面的內 容?id=5&name=dreamdu

location.hash -- 返回 URL#后面的內容， 如果沒有#， 返回空

location.host -- 返回 URL 中的域名部分， 例如 www.dreamdu.com

location.hostname -- 返回 URL 中的主域名部分， 例如 dreamdu.com

location.pathname -- 返回 URL 的域名后的部分 。例如 http://www.dreamdu.com/xhtml/ 返 回/xhtml/

location.port -- 返回 URL 中的端口部分 。 例如 http://www.dreamdu.com:8080/xhtml/ 返回8080

location.protocol -- 返回 URL 中的協議部分。例如 http://www.dreamdu.com:8080/xhtml/ 返 回(//)前面的內容 http:

location.assign -- 設置當前文檔的 URL

location.replace() -- 設置當前文檔的 URL， 并且在 history 對象的地址列表中移除這個 URL location.replace(url);

location.reload() -- 重載當前頁面

(2)history 對象

history.go() -- 前進或后退指定的頁面數 history.go(num);

history.back() -- 后退一頁

history.forward() -- 前進一頁

(3)Navigator 對象

navigator.userAgent -- 返回用戶代理頭的字符串表示(就是包括瀏覽器版本信息等的字 符串)。

navigator.cookieEnabled -- 返回瀏覽器是否支持(啟用)cookie。

說一下 HTML5 drag api

參考回答：

dragstart： 事件主體是被拖放元素， 在開始拖放被拖放元素時觸發， 。

darg： 事件主體是被拖放元素， 在正在拖放被拖放元素時觸發。

dragenter： 事件主體是目標元素， 在被拖放元素進入某元素時觸發。

dragover： 事件主體是目標元素， 在被拖放在某元素內移動時觸發。

dragleave： 事件主體是目標元素， 在被拖放元素移出目標元素是觸發。

drop： 事件主體是目標元素， 在目標元素完全接受被拖放元素時觸發。

dragend： 事件主體是被拖放元素， 在整個拖放操作結束時觸發。

說一下 http2.0

參考回答：

首先補充一下， http 和 https 的區別， 相比于 http,https 是基于 ssl 加密的 http 協議

簡要概括： http2.0 是基于 1999 年發布的 http1.0 之后的首次更新。

提升訪問速度 (可以對于， 請求資源所需時間更少， 訪問速度更快， 相比 http1.0)

允許多路復用：多路復用允許同時通過單一的 HTTP/2 連接發送多重請求-響應信息。改 善了： 在 http1.1 中， 瀏覽器客戶端在同一時間， 針對同一域名下的請求有一定數量限 制 (連接數量) ， 超過限制會被阻塞。

二進制分幀：HTTP2.0 會將所有的傳輸信息分割為更小的信息或者幀，并對他們進行二 進制編碼、首部壓縮、服務器端推送。

補充 400 和 401 、403 狀態碼

參考回答：

(1)400 狀態碼： 請求無效

產生原因：

前端提交數據的字段名稱和字段類型與后臺的實體沒有保持一致。

前端提交到后臺的數據應該是 json 字符串類型， 但是前端沒有將對象 JSON.stringify 轉化成字符串。

解決方法：

對照字段的名稱， 保持一致性，將 obj 對象通過 JSON.stringify 實現序列化。

(2)401 狀態碼： 當前請求需要用戶驗證

(3)403 狀態碼： 服務器已經得到請求， 但是拒絕執行

fetch 發送 2 次請求的原因

參考回答：

fetch 發送 post 請求的時候， 總是發送 2 次， 第一次狀態碼是 204， 第二次才成功？

原因很簡單， 因為你用 fetch 的 post 請求的時候， 導致 fetch 第一次發送了一個 Options 請求，詢問服務器是否支持修改的請求頭，如果服務器支持，則在第二次中發送真正的 請求。

說一下 web worker

參考回答：

在 HTML 頁面中，如果在執行腳本時，頁面的狀態是不可相應的，直到腳本執行完成后， 頁面才變成可相應 。web worker 是運行在后臺的 js， 獨立于其他腳本， 不會影響頁面你 的性能 。并且通過 postMessage 將結果回傳到主線程 。這樣在進行復雜操作的時候， 就 不會阻塞主線程了。

如何創建 web worker：

檢測瀏覽器對于 web worker 的支持性

創建 web worker 文件 (js， 回傳函數等)

創建 web worker 對象

對 HTML 語義化標簽的理解

參考回答：

HTML5 語義化標簽是指正確的標簽包含了正確的內容，結構良好，便于閱讀， 比如nav 表示導航條， 類似的還有 article 、header 、footer 等等標簽。

iframe 是什么？有什么缺點？

參考回答：

定義： iframe 元素會創建包含另一個文檔的內聯框架

提示： 可以將提示文字放在<iframe></iframe>之間， 來提示某些不支持 iframe 的瀏覽器 缺點： 會阻塞主頁面的 onload 事件 搜索引擎無法解讀這種頁面， 不利于 SEO iframe 和主頁面共享連接池， 而瀏覽器對相同區域有限制所以會影響性能。

Doctype 作用?嚴格模式與混雜模式如何區分？ 它們有何意義?

參考回答：

Doctype 聲明于文檔最前面， 告訴瀏覽器以何種方式來渲染頁面， 這里有兩種模式， 嚴 格模式和混雜模式。

嚴格模式的排版和 JS 運作模式是 以該瀏覽器支持的最高標準運行。

混雜模式， 向后兼容， 模擬老式瀏覽器， 防止瀏覽器無法兼容頁面。

Cookie 如何防范 XSS 攻擊

參考回答：

XSS (跨站腳本攻擊) 是指攻擊者在返回的 HTML 中嵌入 javascript 腳本，為了減輕這些 攻擊， 需要在 HTTP 頭部配上， set-cookie：

httponly-這個屬性可以防止 XSS,它會禁止 javascript 腳本來訪問 cookie。

secure - 這個屬性告訴瀏覽器僅在請求為 https 的時候發送 cookie。

結果應該是這樣的： Set-Cookie=<cookie-value>.....

一句話概括 RESTFUL

參考回答：

就是用URL 定位資源， 用 HTTP 描述操作。

講講 viewport 和移動端布局

參考回答：

可以參考這篇文章：

響應式布局的常用解決方案對比(媒體查詢、百分比、rem 和 vw/vh)

click 在 ios 上有 300ms 延遲， 原因及如何解決？

參考回答：

(1)粗暴型， 禁用縮放

<meta name="viewport" content="width=device-width, user-scalable=no">

(2)利用 FastClick， 其原理是：

檢測到 touchend 事件后， 立刻出發模擬 click 事件， 并且把瀏覽器 300 毫秒之后真正出 發的事件給阻斷掉。

addEventListener 參數

參考回答：

addEventListener(event, function, useCapture)

其中， event 指定事件名； function 指定要事件觸發時執行的函數； useCapture 指定事件 是否在捕獲或冒泡階段執行。

介紹知道的 http 返回的狀態碼

參考回答：

100 Continue 繼續 。客戶端應繼續其請求。

101 Switching Protocols 切換協議。服務器根據客戶端的請求切換協議。只能切換到更 高級的協議， 例如， 切換到HTTP 的新版本協議。

200 OK 請求成功 。一般用于 GET 與 POST 請求。

201 Created 已創建 。成功請求并創建了新的資源。

202 Accepted 已接受 。 已經接受請求， 但未處理完成。

203 Non-Authoritative Information 非授權信息。請求成功。但返回的 meta 信息不在原 始的服務器， 而是一個副本。

204 No Content 無內容 。服務器成功處理， 但未返回內容 。在未更新網頁的情況下， 可確保瀏覽器繼續顯示當前文檔。

205 Reset Content 重置內容。服務器處理成功， 用戶終端 (例如： 瀏覽器) 應重置文 檔視圖 。可通過此返回碼清除瀏覽器的表單域。

206 Partial Content 部分內容 。服務器成功處理了部分 GET 請求。

300 Multiple Choices 多種選擇。請求的資源可包括多個位置，相應可返回一個資源特 征與地址的列表用于用戶終端 (例如： 瀏覽器) 選擇。

301 Moved Permanently 永久移動。請求的資源已被永久的移動到新 URI，返回信息會 包括新的 URI，瀏覽器會自動定向到新 URI。今后任何新的請求都應使用新的 URI 代替。

302 Found 臨時移動。與 301 類似。但資源只是臨時被移動。客戶端應繼續使用原有 URI。

303 See Other 查看其它地址 。與 301 類似 。使用 GET 和 POST 請求查看。

304 Not Modified 未修改 。所請求的資源未修改， 服務器返回此狀態碼時， 不會返回 任何資源。客戶端通常會緩存訪問過的資源，通過提供一個頭信息指出客戶端希望只返 回在指定日期之后修改的資源。

305 Use Proxy 使用代理 。所請求的資源必須通過代理訪問。

306 Unused 已經被廢棄的 HTTP 狀態碼。

307 Temporary Redirect 臨時重定向 。與 302 類似 。使用 GET 請求重定向。

400 Bad Request 客戶端請求的語法錯誤， 服務器無法理解。

401 Unauthorized 請求要求用戶的身份認證。

402 Payment Required 保留， 將來使用。

403 Forbidden 服務器理解請求客戶端的請求， 但是拒絕執行此請求。

404 Not Found 服務器無法根據客戶端的請求找到資源 (網頁) 。通過此代碼， 網站 設計人員可設置"您所請求的資源無法找到"的個性頁面。

405 Method Not Allowed 客戶端請求中的方法被禁止。

406 Not Acceptable 服務器無法根據客戶端請求的內容特性完成請求。

407 Proxy Authentication Required 請求要求代理的身份認證， 與 401 類似， 但請求者 應當使用代理進行授權。

408 Request Time-out 服務器等待客戶端發送的請求時間過長， 超時。

409 Conflict 服務器完成客戶端的 PUT 請求是可能返回此代碼，服務器處理請求時發 生了沖突。

410 Gone 客戶端請求的資源已經不存在。410 不同于 404，如果資源以前有現在被永 久刪除了可使用410 代碼， 網站設計人員可通過 301 代碼指定資源的新位置。

411 Length Required 服務器無法處理客戶端發送的不帶 Content-Length 的請求信息。

412 Precondition Failed 客戶端請求信息的先決條件錯誤。

413 Request Entity Too Large 由于請求的實體過大，服務器無法處理， 因此拒絕請求。 為防止客戶端的連續請求，服務器可能會關閉連接。如果只是服務器暫時無法處理，則 會包含一個 Retry-After 的響應信息。

414 Request-URI Too Large 請求的 URI 過長 ( URI 通常為網址) ， 服務器無法處理。

415 Unsupported Media Type 服務器無法處理請求附帶的媒體格式。

416 Requested range not satisfiable 客戶端請求的范圍無效。

417 Expectation Failed 服務器無法滿足 Expect 的請求頭信息。

500 Internal Server Error 服務器內部錯誤， 無法完成請求。

501 Not Implemented 服務器不支持請求的功能， 無法完成請求。

502 Bad Gateway 作為網關或者代理工作的服務器嘗試執行請求時， 從遠程服務器接 收到了一個無效的響應。

503 Service Unavailable 由于超載或系統維護，服務器暫時的無法處理客戶端的請求。 延時的長度可包含在服務器的 Retry-After 頭信息中。

504 Gateway Time-out 充當網關或代理的服務器， 未及時從遠端服務器獲取請求。

505 HTTP Version not supported 服務器不支持請求的 HTTP 協議的版本， 無法完成處 理。

http 常用請求頭

參考回答：

強， 協商緩存

參考回答：

緩存分為兩種： 強緩存和協商緩存， 根據響應的header 內容來決定。

強緩存相關字段有 expires， cache-control 。如果 cache-control 與 expires 同時存在的話， cache-control 的優先級高于 expires。

協商緩存相關字段有 Last-Modified/If-Modified-Since， Etag/If-None-Match。

講講 304

參考回答：

304：如果客戶端發送了一個帶條件的 GET 請求且該請求已被允許，而文檔的內容 (自 上次訪問以來或者根據請求的條件) 并沒有改變， 則服務器應當返回這個 304 狀態碼。

強緩存 、協商緩存什么時候用哪個

參考回答：

因為服務器上的資源不是一直固定不變的，大多數情況下它會更新，這個時候如果我們 還訪問本地緩存，那么對用戶來說，那就相當于資源沒有更新，用戶看到的還是舊的資 源；所以我們希望服務器上的資源更新了瀏覽器就請求新的資源，沒有更新就使用本地 的緩存， 以最大程度的減少因網絡請求而產生的資源浪費。

參考 https://segmentfault.com/a/1190000008956069

前端優化

參考回答：

降低請求量： 合并資源， 減少 HTTP 請求數， minify / gzip 壓縮， webP， lazyLoad。

加快請求速度： 預解析 DNS， 減少域名數， 并行加載， CDN 分發。

緩存： HTTP 協議緩存請求， 離線緩存 manifest， 離線數據緩存 localStorage。

渲染： JS/CSS 優化， 加載順序， 服務端渲染， pipeline。

文為轉載，尊重原作者的著作版權。

偶然在知乎上看到一篇回帖，瞬間覺得之前看的那么多資料都不及這一篇回帖讓我對 websocket 的認識深刻有木有。所以轉到我博客里，分享一下。比較喜歡看這種博客，讀起來很輕松，不枯燥，沒有布道師的陣仗，純粹為分享。廢話這么多了，最后再贊一個~

一、websocket與http

WebSocket是HTML5出的東西（協議），也就是說HTTP協議沒有變化，或者說沒關系，但HTTP是不支持持久連接的（長連接，循環連接的不算）

首先HTTP有 1.1 和 1.0 之說，也就是所謂的 keep-alive ，把多個HTTP請求合并為一個，但是 Websocket 其實是一個新協議，跟HTTP協議基本沒有關系，只是為了兼容現有瀏覽器的握手規范而已，也就是說它是HTTP協議上的一種補充可以通過這樣一張圖理解

有交集，但是并不是全部。

另外Html5是指的一系列新的API，或者說新規范，新技術。Http協議本身只有1.0和1.1，而且跟Html本身沒有直接關系。。通俗來說，你可以用HTTP協議傳輸非Html數據，就是這樣=。=

再簡單來說，層級不一樣。

二、Websocket是什么樣的協議，具體有什么優點

首先，Websocket是一個持久化的協議，相對于HTTP這種非持久的協議來說。簡單的舉個例子吧，用目前應用比較廣泛的PHP生命周期來解釋。

HTTP的生命周期通過 Request 來界定，也就是一個 Request 一個 Response ，那么在 HTTP1.0 中，這次HTTP請求就結束了。

在HTTP1.1中進行了改進，使得有一個keep-alive，也就是說，在一個HTTP連接中，可以發送多個Request，接收多個Response。但是請記住 Request=Response ， 在HTTP中永遠是這樣，也就是說一個request只能有一個response。而且這個response也是被動的，不能主動發起。

教練，你BB了這么多，跟Websocket有什么關系呢？_(:з」∠)_好吧，我正準備說Websocket呢。。

首先Websocket是基于HTTP協議的，或者說借用了HTTP的協議來完成一部分握手。

首先我們來看個典型的 Websocket 握手（借用Wikipedia的。。）

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com復制代碼

熟悉HTTP的童鞋可能發現了，這段類似HTTP協議的握手請求中，多了幾個東西。我會順便講解下作用。

Upgrade: websocket
Connection: Upgrade復制代碼

這個就是Websocket的核心了，告訴 Apache 、 Nginx 等服務器：注意啦，我發起的是Websocket協議，快點幫我找到對應的助理處理~不是那個老土的HTTP。

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13復制代碼

首先， Sec-WebSocket-Key 是一個 Base64 encode 的值，這個是瀏覽器隨機生成的，告訴服務器：泥煤，不要忽悠窩，我要驗證尼是不是真的是Websocket助理。

然后， Sec_WebSocket-Protocol 是一個用戶定義的字符串，用來區分同URL下，不同的服務所需要的協議。簡單理解：今晚我要服務A，別搞錯啦~

最后， Sec-WebSocket-Version 是告訴服務器所使用的 Websocket Draft（協議版本），在最初的時候，Websocket協議還在 Draft 階段，各種奇奇怪怪的協議都有，而且還有很多期奇奇怪怪不同的東西，什么Firefox和Chrome用的不是一個版本之類的，當初Websocket協議太多可是一個大難題。。不過現在還好，已經定下來啦~大家都使用的一個東西~ 脫水： 服務員，我要的是13歲的噢→_→

然后服務器會返回下列東西，表示已經接受到請求， 成功建立Websocket啦！

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=Sec-WebSocket-Protocol: chat復制代碼

這里開始就是HTTP最后負責的區域了，告訴客戶，我已經成功切換協議啦~

Upgrade: websocket
Connection: Upgrade復制代碼

依然是固定的，告訴客戶端即將升級的是 Websocket 協議，而不是mozillasocket，lurnarsocket或者shitsocket。

然后， Sec-WebSocket-Accept 這個則是經過服務器確認，并且加密過后的 Sec-WebSocket-Key 。 服務器：好啦好啦，知道啦，給你看我的ID CARD來證明行了吧。。

后面的， Sec-WebSocket-Protocol 則是表示最終使用的協議。

至此，HTTP已經完成它所有工作了，接下來就是完全按照Websocket協議進行了。具體的協議就不在這闡述了。

【文章福利】小編推薦自己的linuxC/C++語言交流群：832218493，整理了一些個人覺得比較好的學習書籍、視頻資料共享在里面，有需要的可以自行添加哦！~!

——————技術解析部分完畢——————

你TMD又BBB了這么久，那到底Websocket有什么鬼用， http long poll ，或者ajax輪詢 不都可以實現實時信息傳遞么。

好好好，年輕人，那我們來講一講Websocket有什么用。來給你吃點胡（蘇）蘿（丹）卜（紅）

三、Websocket的作用

在講Websocket之前，我就順帶著講下 long poll 和 ajax輪詢 的原理。

ajax輪詢

ajax輪詢的原理非常簡單，讓瀏覽器隔個幾秒就發送一次請求，詢問服務器是否有新信息。

場景再現：

客戶端：啦啦啦，有沒有新信息(Request)

服務端：沒有（Response）

客戶端：啦啦啦，有沒有新信息(Request)

服務端：沒有。。（Response）

客戶端：啦啦啦，有沒有新信息(Request)

服務端：你好煩啊，沒有啊。。（Response）

客戶端：啦啦啦，有沒有新消息（Request）

服務端：好啦好啦，有啦給你。（Response）

客戶端：啦啦啦，有沒有新消息（Request）

服務端：。。。。。沒。。。。沒。。。沒有（Response） —- loop

long poll

long poll 其實原理跟 ajax輪詢 差不多，都是采用輪詢的方式，不過采取的是阻塞模型（一直打電話，沒收到就不掛電話），也就是說，客戶端發起連接后，如果沒消息，就一直不返回Response給客戶端。直到有消息才返回，返回完之后，客戶端再次建立連接，周而復始。

場景再現：

客戶端：啦啦啦，有沒有新信息，沒有的話就等有了才返回給我吧（Request）

服務端：額。。 等待到有消息的時候。。來 給你（Response）

客戶端：啦啦啦，有沒有新信息，沒有的話就等有了才返回給我吧（Request） -loop

從上面可以看出其實這兩種方式，都是在不斷地建立HTTP連接，然后等待服務端處理，可以體現HTTP協議的另外一個特點，被動性。

何為被動性呢，其實就是，服務端不能主動聯系客戶端，只能有客戶端發起。

簡單地說就是，服務器是一個很懶的冰箱（這是個梗）（不會、不能主動發起連接），但是上司有命令，如果有客戶來，不管多么累都要好好接待。

說完這個，我們再來說一說上面的缺陷（原諒我廢話這么多吧OAQ）

從上面很容易看出來，不管怎么樣，上面這兩種都是非常消耗資源的。

ajax輪詢 需要服務器有很快的處理速度和資源。（速度）long poll 需要有很高的并發，也就是說同時接待客戶的能力。（場地大小）

所以 ajax輪詢 和 long poll 都有可能發生這種情況。

客戶端：啦啦啦啦，有新信息么？

服務端：月線正忙，請稍后再試（503 Server Unavailable）

客戶端：。。。。好吧，啦啦啦，有新信息么？

服務端：月線正忙，請稍后再試（503 Server Unavailable）

客戶端：然后服務端在一旁忙的要死：冰箱，我要更多的冰箱！更多。。更多。。（我錯了。。這又是梗。。）

言歸正傳，我們來說Websocket吧

通過上面這個例子，我們可以看出，這兩種方式都不是最好的方式，需要很多資源。

一種需要更快的速度，一種需要更多的’電話’。這兩種都會導致’電話’的需求越來越高。

哦對了，忘記說了HTTP還是一個狀態協議。

通俗的說就是，服務器因為每天要接待太多客戶了，是個健忘鬼，你一掛電話，他就把你的東西全忘光了，把你的東西全丟掉了。你第二次還得再告訴服務器一遍。

所以在這種情況下出現了，Websocket出現了。他解決了HTTP的這幾個難題。首先，被動性，當服務器完成協議升級后（HTTP->Websocket），服務端就可以主動推送信息給客戶端啦。所以上面的情景可以做如下修改。

客戶端：啦啦啦，我要建立Websocket協議，需要的服務：chat，Websocket協議版本：17（HTTP Request）

服務端：ok，確認，已升級為Websocket協議（HTTP Protocols Switched）

客戶端：麻煩你有信息的時候推送給我噢。。

服務端：ok，有的時候會告訴你的。

服務端：balabalabalabala

服務端：balabalabalabala

服務端：哈哈哈哈哈啊哈哈哈哈

服務端：笑死我了哈哈哈哈哈哈哈

就變成了這樣，只需要經過一次HTTP請求，就可以做到源源不斷的信息傳送了。（在程序設計中，這種設計叫做回調，即：你有信息了再來通知我，而不是我傻乎乎的每次跑來問你 ）

這樣的協議解決了上面同步有延遲，而且還非常消耗資源的這種情況。那么為什么他會解決服務器上消耗資源的問題呢？

其實我們所用的程序是要經過兩層代理的，即HTTP協議在Nginx等服務器的解析下，然后再傳送給相應的Handler（PHP等）來處理。簡單地說，我們有一個非常快速的 接線員（Nginx） ，他負責把問題轉交給相應的 客服（Handler） 。

本身接線員基本上速度是足夠的，但是每次都卡在客服（Handler）了，老有客服處理速度太慢。，導致客服不夠。Websocket就解決了這樣一個難題，建立后，可以直接跟接線員建立持久連接，有信息的時候客服想辦法通知接線員，然后接線員在統一轉交給客戶。

這樣就可以解決客服處理速度過慢的問題了。

同時，在傳統的方式上，要不斷的建立，關閉HTTP協議，由于HTTP是非狀態性的，每次都要重新傳輸 identity info （鑒別信息），來告訴服務端你是誰。

雖然接線員很快速，但是每次都要聽這么一堆，效率也會有所下降的，同時還得不斷把這些信息轉交給客服，不但浪費客服的處理時間，而且還會在網路傳輸中消耗過多的流量/時間。

但是Websocket只需要一次HTTP握手，所以說整個通訊過程是建立在一次連接/狀態中，也就避免了HTTP的非狀態性，服務端會一直知道你的信息，直到你關閉請求，這樣就解決了接線員要反復解析HTTP協議，還要查看identity info的信息。

同時由客戶主動詢問，轉換為服務器（推送）有信息的時候就發送（當然客戶端還是等主動發送信息過來的。。），沒有信息的時候就交給接線員（Nginx），不需要占用本身速度就慢的客服（Handler）了

——————–

至于怎么在不支持Websocket的客戶端上使用Websocket。。答案是： 不能

但是可以通過上面說的 long poll 和 ajax 輪詢 來 模擬出類似的效果