一.HTTP與TCP的關係
- HTTP屬於應用層協議，主要解決如何包裝數據；
- 在傳輸層使用TCP協議，主要解決數據如何在網絡中傳輸；
- 在網絡層使用IP協議，主要解決網絡路由和尋址問題；
- HTTP把TCP分割好的各種數據包封裝到IP包裏面傳送給接收方。
二.短連接、長連接、websocket、postmessage作用
1.短連接：（佔用較多內存和帶寬）。
在HTTP/1.0中，默認使用的是短連接。瀏覽器和服務器每進行一次HTTP操作，就建立一次連接，但服務器向發送響應數據後，將關閉TCP，中斷連接。WEB網站的http服務一般都用短鏈接，因爲長連接對於服務端來說會耗費一定的資源，而像WEB網站這麼頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源；併發量大，但每個用戶無需頻繁操作情況下，使用短連接更好。
2.長連接：（省時間，少帶寬）。
但從 HTTP/1.1起，默認使用長連接。會在響應頭有加入這行代碼： Connection:keep-alive；TCP連接在發送後將仍然保持打開狀態，瀏覽器可以繼續通過相同的連接發送請求，即把多個HTTP請求合併爲一個。也就是說，在一個HTTP連接中，可以發送多個Request，接收多個Response。但是請記住 Request = Response， 在HTTP中永遠是這樣，也就是說一個request只能有一個response。而且這個response也是被動的，不能主動發起。數據庫的連接用長連接， 如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket 創建也是對資源的浪費。
3.WebSocket：（無需循環等待（長輪詢），CPU和內存資源不以客戶端數量衡量，而是以客戶端事件數衡量。）
WebSocket是HTML5出的協議，IE10以上瀏覽器支持，跟HTTP協議沒有關係。只是借用了HTTP的協議來完成一部分握手。HTTP是不支持持久連接的（長連接，循環連接的不算），Websocket是一個持久化的協議；
4.PostMessage：可以安全地實現跨源通信。IE8以上支持。主窗口通過postMessageAPI向異域的窗口發送數據，在異域的頁面腳本中始終監聽message事件，當獲取主窗口數據時處理數據或者以同樣的方式返回數據從而實現跨窗口的異域通訊。
三.Websocket握手過程（參考：https://www.cnblogs.com/oshyn/p/3574497.html）
Websocket協議定義爲ws和wss協議，分別爲普通請求和基於SSL的安全傳輸，佔用端口與http協議系統，ws爲80端口，wss爲443端口。
ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]
其中port是可選項，query前接“?”。
1.當建立一個Websocket連接時，連接狀態是CONNECTING，客戶端通過HTTP請求與WebSocket服務端協商升級協議，需要提供host、port、resource-name和一個是否是安全連接的標記，也就是一個WebSocket URI，採用的是標準的HTTP報文格式，且只支持GET方法。
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
這個升級的HTTP請求頭中的字段順序是可以隨便的。與普通HTTP請求相比多了一些字段。
- Sec-WebSocket-Protocol：字段表示客戶端可以接受的子協議類型，也就是在Websocket協議上的應用層協議類型。上面可以看到客戶端支持chat和superchat兩個應用層協議，當服務器接受到這個字段後要從中選出一個協議返回給客戶端。
- Upgrade：告訴服務器這個HTTP連接是升級的Websocket連接。
- Connection：告知服務器當前請求連接是升級的。
- Origin：該字段是用來防止客戶端瀏覽器使用腳本進行未授權的跨源攻擊，這個字段在WebSocket協議中非常重要。服務器要根據這個字段判斷是否接受客戶端的Socket連接。可以返回一個HTTP錯誤狀態碼來拒絕連接。
- Sec-WebSocket-Key：爲了表示服務器同意和客戶端進行Socket連接，服務器端需要使用客戶端發送的這個Key進行校驗，然後返回一個校驗過的字符串給客戶端，客戶端驗證通過後才能正式建立Socket連接。服務器驗證方法是：首先進行 Key + 全局唯一標示符（GUID）“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”連接起來，然後將連接起來的字符串使用SHA-1哈希加密，再進行base64加密，將得到的字符串返回給客戶端作爲握手依據。其中GUID是一個對於不識別WebSocket的網絡端點不可能使用的字符串。
發送請求的要求（排查錯誤的方法/連接失敗的原因）：
- 請求的WebSocket URI必須要是定義的有效的URI。
- 如果客戶端已經有一個WebSocket連接到遠程服務器端，不論是否是同一個服務器，客戶端必須要等待上一個連接關閉後才能發送新的連接請求，也就是同一客戶端一次只能存在一個WebSocket連接。如果想同一個服務器有多個連接，客戶端必須要串行化進行。如果客戶端檢測到多個到不同服務器的連接，應該限制一個最大連接數，在web瀏覽器中應該設定最多可以打開的標籤頁的數目。這樣可以防止到遠程服務器的DDOS攻擊，但這是對到多個服務器的連接，如果是到同一個服務器連接，並沒有數目限制。
- 如果使用了代理服務器，那麼客戶端建立連接的時候需要告知代理服務器向目標服務器打開TCP連接。
- 如果連接沒有打開，一定是某一方出現錯誤，此時客戶端必須要關閉再次連接的嘗試。
- 連接建立後，握手必須要是一個有效的HTTP請求
- 請求的方式必須是GET，HTTP協議的版本至少是1.1
- Upgrade字段必須包含而且必須是"websocket"，Connection字段必須內容必須是“Upgrade”
- Sec-Websocket-Version必須，而且必須是13
2.服務器返回響應頭，客戶端驗證通過後將建立連接，此時狀態爲OPEN。
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
Sec-WebSocket-Accept是根據客戶端請求首部的Sec-WebSocket-Key計算出來的：
計算公式爲：
- 將
Sec-WebSocket-Key跟258EAFA5-E914-47DA-95CA-C5AB0DC85B11拼接。 - 通過SHA1計算出摘要，並轉成base64字符串。
3.判斷服務器返回的響應頭是否同意握手的依據：
- 首行返回的是HTTP/1.1協議版本和狀態碼101，表示變換協議（Switching Protocol）
- Upgrade 和 Connection：這兩個字段是服務器返回的告知客戶端同意使用升級並使用websocket協議，用來完善HTTP升級響應
- Sec-WebSocket-Accept：服務器端將加密處理後的握手Key通過這個字段返回給客戶端表示服務器同意握手建立連接。
- Sec-Websocket-Procotol：服務器選擇的一個應用層協議。
瀏覽器解析響應頭字段，如果Sec-WebSocket-Accept字段的信息符合要求就會建立連接，同時就可以發送WebSocket的數據幀了。如果該字段不符合要求或者爲空或者HTTP狀態碼不爲101，就不會建立連接。
服務器端響應步驟：
- 解析握手請求頭：獲取握手依據Key並進行處理，檢測HTTP的GET請求和版本是否準確，Host字段是否有權限，Upgrade字段中websocket是一個與大小寫無關的ASCII字符串，Connection字段是一個大小寫無關的"Upgrade"ASCII字符串，Websocket協議版本必須爲13，其他的關於Origin、Protocol和Extensions可選。
- 發送握手響應頭：檢測是否是wss協議連接，如果是就是用TLS握手連接，否則就是普通連接。服務器可以添加額外的驗證信息到客戶端進行驗證。當進行一系列驗證之後，服務器必須返回一個有效的HTTP響應頭。響應頭中每一行一個字段，結束必須爲“\r\n”，使用的ABNF語法。
除了上述必要頭字段之外，其他的HTTP協議定義的字段都可以使用，如Set-Cookie等。
同樣類似AJAX的是，WebSocket對象也有一個readyState屬性，用來表示對象實例當前所處的鏈接狀態，有四個值：
- 0：表示正在連接中（CONNECTING）；
- 1：表示連接成功，可以通信（OPEN）；
- 2：表示連接正在關閉（CLOSING）；
- 3：表示連接已經關閉或打開連接失敗（CLOSED）；
四.PostMessage(跨源通信)
以上這些跨域技術都只適用於客戶端請求異域服務端資源的情景。而除此之外，有時候我們還需要在異域的兩個客戶端之間共享數據，例如頁面與內嵌iframe窗口通訊，頁面與新打開異域頁面通訊。
任何域都可以通過postMessage發送跨域信息，因此只要有消息通過postMessage發送過來，腳本都會接收並進行處理。如何鑑別發送至頁面的信息呢？答案是通過 message事件監聽函數的事件對象，我們稱它爲event，該對象有三個屬性：
- data：值爲其他window傳遞過來的對象；
- origin：值爲消息發送方窗口的域名；
- source：值爲對發送消息的窗口對象的引用；
很顯然的，我們應該着重檢測event對象的origin屬性，建立一個白名單對origin屬性進行檢測通常是一個明智的做法。
-------------------------------<本節完>------------------------------------------