秋招復習筆記系列目錄（不斷更新中）：

上一篇博客總結了計算機網絡的物理層、數據鏈路層和網絡層。這裏繼續總結運輸層和應用層。因爲應用層涉及到了HTTP協議，所以本博客對HTTP的介紹部分參考《圖解HTTP》做了詳細一點的介紹。

五、運輸層

1. 概述

1.1 作用

1.網絡層完成了主機之間端到端的通信，但運輸層完成了主機上不同應用程序（進程）之間端到端的通信。
2.對收到的報文進行差錯檢測。（網絡層只是檢測頭部，運輸層還要檢測數據部分）。

1.2端口

1.作用： 網絡層將數據交付的主機後，區分不同應用程序以準確交付到應用程序。
2.分類：
(1)服務器使用的端口：服務器使用的端口又分爲熟知端口（分配給最重要的應用程序的，如STP，SMTP等）和登記端口號（分配給普通應用的）
(2)客戶端使用的端口：數值爲49152~65535，僅在客戶端進程運行時才動態選擇。

2.用戶數據協議UDP

2.1特點

無連接： 發送數據前不需要建立連接
盡最大努力交付： 不保證可靠交付
面向報文： 應用層的報文，UDP添加首部就交給網絡層，不會對報文數據部分做改變。
沒有擁塞機制： 網絡發生擁塞不用降低發送效率
支持一對一、一對多、多對一、多對多的交互通信
首部開銷小

2.2 UDP首部格式

僞首部：只在計算校驗和時使用，不向上下傳遞
源端口：發送方的端口，在需要回復時選用
目的端口：接收方的端口
長度：數據報的長度
檢驗和：驗證數據部分是否有錯（有錯丟棄）

3.傳輸協議TCP

3.1 特點

面向連接：使用TCP協議之前，必須先建立連接
點對點：一個連接只能有兩個端點
提供可靠交付
提供全雙工通信
面向字節流

3.2 TCP的連接

TCP連接的端點爲套接字（socket），套接字的組成爲：
每一條TCP連接唯一地被通信兩端的兩個套接字所確定。

3.2 TCP報文段的首部

1.源端口和目的端口： 和UDP類似
2.序號： 發送的字節的序號，每個字節都有一個編號。採用模2³²運算，即編號到達2³²後，又從0開始編號
3.確認號： 期望收到對方下一個報文段的第一個數據字節的序號（如第B收到A的數據序號爲1，而數據長爲200字節，那確認好應該是201）。
4.數據偏移： 用於計算首部長度的（因爲TCP首部除20字節的確定部分外，有不確定部分）
5.確認ACK： 值爲1纔有效，0無效。連接建立後，所有報文的ACK值必須爲1。
6.同步SYN： 連接建立時用來同步序號，SYN=1而ACK爲0時，表明是一個連接請求報文段。對方同意連接後，發送SYN=1且ACK=1的響應報文。
7.終止FIN： 用來釋放一個連接，當FIN爲1時，表示數據已經發送完畢，要求釋放連接。
8.窗口： 窗口值作爲接收方讓發送方設置其發送窗口的依據。

4.可靠傳輸的工作原理

4.1 基礎——停止等待協議

停止等待協議發送數據時，存在三種情況：

1.無差錯情況：主機A向B發送一段分組，就進行等待，B收到分組後向A發送確認信息，A收到確認後繼續發送下一個分組。
2.出現差錯的情況：無論是A發送分組的過程中還是B返回確認信息的過程中出現差錯，都會造成A的等待，爲了防止一直等待，需要設置一個超時時間，超時後需要超時重傳。
3.確認丟失和確認遲到：處理如下：

停止等待的最大問題是信道利用率極低，故基於停止等待協議的基本原理，設計了連續ARQ協議和滑動窗口協議。如下，以提高信道利用率。

4.2 滑動窗口協議

1.滑動窗口的組成
整個滑動窗口分爲三個部分：

(1)已發送並收到確認的部分：這些已經發送成功且接收方的主機已處理完成
(2)允許發送的序號：根據接收方期望收到的序號和接收方的接受窗口以及網絡情況確定的窗口部分（不能大於接收方的接受窗口值）。
(3) 不允許發送的部分：未發送的在窗口外的部分。

2.發送過程
如下圖所示，發送窗口內的字節都允許被髮送，接收窗口內的字節都允許被接收。
當接受窗口接受完成並交付主機後，就將滑動窗口向前（圖中的右邊）移動。注意，接收窗口只會對窗口內最後邊（即靠近最左邊）一個按序到達的字節進行確認（即圖中最左邊的數據）。比如下圖，接收方收到了32、33，但是沒有收到31，那最後一個按序到達的仍然是31。發送方得到一個字節的確認之後，就知道這個字節之前的所有字節都已經被接收了。

接收方接收成功後，會對接收方發送確認，比如下圖31收到了，31,32,33就全部收到了，故接收方的滑動窗口會向前（右）移動（如下圖）。然後發送方會給接受方發送確認報文，發送的確認報文裏面，確認號變成了34，故接收方的滑動窗口也向前（右）移動。

按照上面的過程持續發送，直到圖中的P2和P3重合，說明此時全部是已發送但未收到確認的數據。此時就需要進行超時等待，一旦超時，就需要重傳。

3.超時重傳時間的選擇
TCP採用自適應算法確定超時重傳時間，以適應不同的網絡環境。
計算過程：設上一個報文傳輸的往返時間爲RTT，那多次傳輸加權平均往返時間爲：

α越小代表新舊RTT差別越小，越大則表示不同RTT差別越大。
有了上式，超時重傳時間RTO爲：

其中，RTT_D表示RTT偏差的加權平均值。

5.TCP流量控制

流量控制就是讓發送方發送數據速率不要太快，要讓接收方來得及接受。通過滑動窗口機制，利用控制TCP報文首部的窗口值字段，可以很方便地進行流量控制。

6.TCP的擁塞控制

6.1 概述

當請求的資源總數大於可用資源（如下圖），即供不應求時，會出現擁塞。

所謂擁塞控制就是防止過多的數據注入到網絡中，這樣可以使網絡中的路由器或鏈路不會過載。擁塞控制是一個全局的問題，而流量控制只是端到端的問題（注意區分）。擁塞控制的作用如下：

6.2 擁塞控制算法

1.慢開始：

(1)基本原理： 根據是否發生超時，發送方動態調整窗口的大小。基本原則是隻要沒出現擁塞，擁塞窗口就可以再增大一些，只要出現擁塞或有可能出現擁塞，就必須把擁塞窗口減小一些，緩解擁塞。
(2)算法
慢開始算法：
①慢開始： 開始時，設置擁塞窗口值爲1，能發送的報文數量是1。每次收到確認後，將擁塞窗口值加倍，因此之後發送方能夠發送的報文段數量爲：2、4、8（下圖中藍色框的部分）
②擁塞避免： 爲了防止擁塞窗口太大，當窗口值達到一定的閾值ssthresh時，窗口值每次增加1（下圖中紅色框部分）
③出現擁塞： 一旦出現超時情況，則將擁塞窗口重新設置爲1，且閾值ssthresh變爲原來的一半，重新開始慢開始（下圖中綠色部分）

快重傳和快恢復：
快重傳算法要求接收方每收到一個報文段要立即向發送方發送確認。 如下圖，發送了M1、M2，接收方沒收到M3，但收到M4，會馬上發送對M2的確認，接收到M5，M6也會重複確認M2，當發送方收到3個重複確認後，就知道接收方確實沒收到M3。 此時，對M3進行快重傳。
這種情況下，只是丟失了個別報文段，並沒有出現超時，所以沒必要將擁塞窗口重新設置爲1再慢開始。此時會將閾值ssthresh設爲原來的一半，然後讓窗口值=ssthresh，並開始擁塞避免（即擁塞窗口每次+1而不是翻倍）。如下圖紅框所示。

7.TCP的運輸連接管理

TCP的運輸連接管理包含三個部分的內容：連接建立、數據傳送、連接釋放。

7.1 連接建立——三次握手

第一次握手： 主機A向主機B發送連接請求，其中同步SYN=1而確認號ACK=0，選擇一個初始序號seq=x，表明這是一個連接請求報文。此時客戶端進入同步已發送狀態。
第二次握手： 主機B收到連接請求報文後，向A發送確認，此時SYN=1且ACK=1，確認號（不同於確認號ACK）爲x+1，同時也選擇一個初始的序號 y。此時服務器處於同步收到狀態。
第三次握手： 主機A收到B的確認後，還要給B發送確認。此時ACK=1，確認號爲y+1，自己的序號爲x+1。此時A進入已建立連接狀態。B收到A的確認後，也進入已建立連接狀態。

爲什麼需要第三次握手： 如果A發送的連接請求延時，A會再發送一條連接請求，此時連接建立成功。但此時如果B收到第一條連接請求，如果沒有第三次握手的話，會建立連接，但這個連接是不需要的，會浪費網絡資源。

7.2 連接釋放——四次揮手

第一次揮手： 主機A向主機B發送連接釋放報文，此時FIN=1，A進入終止等待狀態。
第二次揮手： 主機B收到連接釋放報文後，向A發送確認，此時確認號ACK=1。B進入關閉等待狀態。此時，B還能向A發送報文、
第三次揮手： 當 B 確定不需要發送報文了，則B再發送連接釋放報文，FIN=1。此時B進入最後確認狀態，等待A的確認
第四次揮手： A 收到後發出確認，進入 TIME-WAIT （終止等待）狀態，等待 2 MSL（最大報文存活時間）後釋放連接。B收到A的確認後，將釋放連接。

爲什麼需要等待2MSL：

客戶端接收到服務器端的 FIN 報文後進入此狀態，此時並不是直接進入 CLOSED 狀態，還需要等待一個時間計時器設置的時間 2MSL。這麼做有兩個理由：

(1)確保最後一個確認報文能夠到達。如果 B 沒收到 A 發送來的確認報文，那麼就會重新發送連接釋放請求報文，A 等待一段時間就是爲了處理這種情況的發生。
(2)防止出現三次揮手中“已失效的連接請求報文段”出現在連接中。等待2MSL，就可以使本連接持續時間內所有報文段都從網絡中消失。

六、應用層

1. 作用

應用進程之間進行通信，必須遵守嚴格的規則，應用層定義了這些規則。

2.域名系統DNS

2.1 作用

將互聯網上的主機名字轉換爲IP地址

2.2 層級結構

域名具具有層次結構，從後往前分別爲頂級域名、二級域名、三級域名等等

1.頂級域名
頂級域名分爲三類

國家頂級域名： 如cn表示中國
通用頂級域名： 如edu（教育機構）、com（公司）、gov（政府部門）
基礎結構域名： 只有arpa一個，用於反向域名解析

2. 域名層級結構
如下所示，頂級域名由國際組織制定，二級一般由國家定，三級使用機構自己定

2.3 域名服務器

1.管轄範圍
DNS的服務器的管轄範圍以“區”爲單位，而不是以“域”爲單位。區是域的子集

2.分類

根域名服務器：
頂級域名服務器： 負責管理該頂級域名服務器中註冊的所有二級域名
權限域名服務器： 負責一個區的域名服務器
本地域名服務器： 距離主機較近，域名解析時，先查同一ISP中的本地域名服務器

3.查詢過程

遞歸查詢： 本地域名服務器不知道IP地址，則以DNS客戶的身份，向其根域名服務器繼續發出查詢請求報文(即替主機繼續查詢)，而不是讓主機自己進行下一步查詢。
迭代查詢： 當根域名服務器收到本地域名服務器發出的迭代查詢請求報文時，要麼返回給本地域名服務器所要查詢的IP地址，要麼返回給本地域名服務器下一步應當查詢的域名服務器的IP地址。

3.文件傳輸協議FTP

3.1文件傳輸協議FTP

FTP的客戶和服務器之間要建立兩個並行的TCP連接：

控制連接： 整個會話期間一直打開，處理客戶端發送的請求
數據連接： 用來傳輸數據

3.2 簡單文件傳輸協議TFTP

類似於停止等待協議，發送完一個文件塊就等待對方確認。其使用UDP數據報，適用於1對多的傳輸。

4.萬維網WWW

4.1 統一資源定位符URL

1.作用： 相當於文件名在網絡範圍內的擴展，用於在互聯網中唯一地標誌一個資源。
2.組成： 一般由以下四部分組成：

4.2 超文本傳送協議Http

1.特點： Http使用面向連接的TCP作爲運輸層協議，有以下特點：

(1)無連接：交換Http報文之前不需要先建立HTTP連接
(2)無狀態：第二次訪問和第一次訪問相同

2.傳輸過程

3.Http報文結構
Http有請求報文和響應報文兩種報文：

請求報文：

方法： 包含以下幾種：
URL： 請求資源的統一資源定位符
首部行： 包含請求的其他信息，如下的一個Http報文所示：

響應報文

狀態碼： 返回請求的狀態，分爲5大類：

常用的狀態碼詳解如下：
首部行： 附帶其他的一些信息。如下圖所示的一個請求報文的首部：

下圖爲響應報文的首部：

首部字段分爲以下四類：
1.通用首部字段
2.請求首部字段：
3.響應首部字段
4.實體首部字段

4.3 在服務器上存儲用戶信息

1.Session
Session是存在服務器的一種用來存放用戶數據的類HashTable結構。當瀏覽器第一次發送請求時，服務器自動生成了一個HashTable和一個Session ID用來唯一標識這個HashTable，並將其通過響應發送到瀏覽器。當瀏覽器第二次發送請求，會將前一次服務器響應中的Session ID放在請求中一併發送到服務器上，服務器從請求中提取出Session ID，並和保存的所有Session ID進行對比，找到這個用戶對應的HashTable。
2.Cookie
後臺通過SetCookie將一些信息返回，瀏覽器收到後寫入瀏覽器保存，在以後的訪問中可以攜帶cookie信息，這樣就能追蹤用戶。
Session和Cookie通常配合使用，如下圖所示：

5.電子郵件

5.1 電子郵件系統的構成

1.用戶代理：用戶與電子郵件的接口，大多數情況下就是用戶電腦上的一個程序，有撰寫、顯示、處理、通信的功能。
2.郵件服務器：必須同時能夠充當客戶和服務器。
3.郵件發送協議（如SMTP）和郵件讀取協議（如POP3）

5.2 簡單郵件傳送協議SMTP

SMTP通信的三個階段：
1.連接建立： 通過TCP建立連接，不能使用中間的郵件服務器。
2. 郵件傳送： 先通過MAIL命令通知接受服務器，再通過RCPT命令，弄清對方是否做好接受郵件的準備。再通過DATA命令傳送郵件內容。
3.連接釋放： 客戶端發送QUIT命令，服務器給予確認，釋放連接。

5.3郵件讀取協議POP3和IMAP

1.POP3
只要用戶從服務器讀取了郵件，就將郵件刪除。後面改進後，可以不刪除。
2.IMAP
用戶與接收方郵件服務器建立TCP連接，用戶在自己計算機上操縱服務器郵箱，就像本地操作一樣。

七、網絡安全

1.概述

1.1 網絡攻擊的種類

1. 網絡攻擊
網絡攻擊分爲主動攻擊和被動攻擊兩種：

主動攻擊
- 篡改
- 惡意程序：包括計算機病毒、蠕蟲、特洛伊木馬、邏輯炸彈、後門入侵、流氓軟件
- 拒絕服務DoS（DoS攻擊）：向某個服務器不停發送大量分組，使其不能提供正常服務，甚至癱瘓
被動攻擊
- 被動攻擊是一種在不影響正常數據通信的情況下，獲取由原站發送的目的站的有效數據，通過監聽到的有效數據，從而對網絡造成間接的影響，影響所傳數據的保密性，泄露數據信息，如只是被動攻擊，不會對其傳輸造成直接的影響，不易監測。

下面是一些常見的攻擊手段：

2. 因輸出值轉義不同引發的安全漏洞

(1)跨站腳本攻擊XSS
- 通過存在安全漏洞的網站註冊用戶的瀏覽器內運行非法的HTML標籤或JS進行的一種攻擊，具體見這篇博客：https://www.jianshu.com/p/4fcb4b411a66
- 可能造成的影響：利用虛假輸入表單騙取用戶的個人信息、利用腳本竊取用戶的Cookie值、顯示僞造的文章或圖片。
(2)SQL注入攻擊
- SQL注入是指針對WEB數據庫，通過運行非法的SQL而產生的攻擊。
  舉例：
  比如說構造SQL語句的時候，正確的爲：
  
  因爲- -後面的會被註釋，flag=1的條件就會被忽略。
(3)OS命令注入攻擊
- 通過Web應用，執行非法的操作系統命令達到攻擊的目的，只要在能調用Shell函數的地方存在被攻擊的風險
(4)HTTP首部注入攻擊
- 指在響應報文的HTTP首部字段內插入首部信息或主體的攻擊。屬於被動攻擊。可能造成任意設置cookie、重定向至任意URL等問題。
(5) 郵件首部注入攻擊
- 攻擊者通過向郵件首部To或Subject內添加任意非法內容引起的攻擊，可在郵件中植入廣告或病毒。
(6)目錄遍歷攻擊
- 針對本無意公開的文件目錄，通過非法截斷其目錄路徑後，達成訪問目的的攻擊。

3.因設置或設計上的缺陷引發的漏洞

(1)強制瀏覽：
- 強制瀏覽一些原本非自願公開的文件。對於一些非自願公開的文件，通常通過隱藏URL的方式來保證安全，一旦泄露URL，就會造成強制瀏覽。
(2)不正確的錯誤消息處理
- 通過一些錯誤消息，來推測信息。如通過“密碼錯誤”的提示，可以知道用戶存在，而密碼錯誤這樣的信息。
(3)開放重定向
- 通過修改用戶重定向的地址，誘導用戶到別的網站

4.因爲會話管理疏忽引發的安全漏洞

(1)會話劫持
- 攻擊者拿到用戶的會話ID，使用此會話ID，僞裝成用戶，達到攻擊目的。
(2)會話固定攻擊
- 強制用戶使用攻擊者指定的會話ID，屬於被動攻擊
(3)跨站點請求僞造CSRF
- 攻擊者通過設定好的陷阱，強制對已經完成認證的用戶進行預期的個人信息或設定信息等某些狀態的更新。比如，攻擊者拿到你的身份，執行一些非法操作（如拿你的身份在評論中發表一些言論）。

1.2 安全網絡需要達到的目標

保密性、端點鑑別、信息的完整性、運行的安全性

2.密碼體制

2.1 對稱密碼體制

即加密密匙與解密密匙是使用相同的密碼體制。代表方法爲DES，其基本原理是每64位的數據產生一個64位的密文，最後將所有結果拼接起來，得到加密結果。爲了安全，有人提出了三重DES加密：先加密，再解密，再加密。

2.3 公匙密碼體制（非對稱加密）

公匙密碼體制使用不同的加密密匙和解密密匙。其原理是同時生成私匙和公匙一對密匙，公匙可以在公開，私匙不公開。如A要給B發送信息，B先將公匙發給A，A用公匙對信息加密後，再發送給B，B用私匙進行解密查看數據內容。

3.數字簽名

數字簽名需要保證報文鑑別（接收者能夠覈實簽名），報文的完整性（接收者確信報文沒被更改）、不可否認（發送者不能抵賴）。其過程爲A將簽名用私匙加密，然後和公匙一起傳輸給A，A可以用公匙進行解密查看簽名是否正確。

再對報文用不同的密匙進行加密，就能實現在數字簽名的同時保密報文：

4.報文鑑別

鑑別的作用是驗證通信的對方的確是自己所要通信的對象，而不是冒充者，並且所傳送的報文是完整的，沒有被別人篡改過。

4.1 報文鑑別

1.目的： 鑑別報文確實是報文發送者發送的
2.算法： 密碼散列函數

(1) 原理：通過散列函數，得到一個固定長度的散列值。這個過程是單向的。
(2) 代表算法：MD5和SHA-1
(3) 報文鑑別中散列函數的使用

4.2 實體鑑別

報文鑑別是每個報文都要鑑別，而實體鑑別只會在第一次連接的時候進行鑑別，其後發送數據時不再鑑別。
1.重放攻擊和： 對於實體鑑別，入侵者直接拿到連接時候的鑑別，然後僞裝成發送者，叫重放攻擊。
2.鑑別過程： 爲了防止重放攻擊，使用不重數來進行鑑別，如下所示：

5. 密匙分配

5.1 對稱密匙分配

建立密匙分配中心。A發送明文；密匙中心產生一次一密的會話密匙K_AB，並用A的公匙加密，同時也包含一個用B的公匙加密的憑據；A收到後，用私匙解密，得到票據，並將票據發送給B，B用私匙解密後確認票據，鑑別成功。

5.2 公匙的分配

建立認證中心CA，由認證中心頒發公匙。

6. 運輸層的安全協議

6.1 組成

1.安全套接字層SSL
2.運輸安全層TLS

6.2 SSL

1.原理： 在應用層和運輸層之間加一個SSL子層

2.SSL提供的安全服務

(1) SSL服務器鑑別：允許客戶端通過驗證服務器的z證書鑑別服務器
(2) SSL客戶鑑別：允許服務器鑑別客戶身份
(3) SSL會話加密：對客戶服務器端間發送的所有報文進行加密，並檢測報文是否被篡改。

3.安全會話的實現

八、HTTPS

1.定義

在HTTP協議上加入加密處理和認證（使用SSL協議）等機制，形成Https。即HTTPS=HTTP+SSL。HTTPS需要完成的任務就是SSL提供的安全服務（見第七章的SSL部分），即客戶端和服務端的鑑別以及報文是否被篡改的確認。

2.加密過程

通過第七部分的加密知識可知，對稱加密速度快，但密匙的分發存在問題；非對稱加密比較安全，但速度慢。爲了平衡，HTTPS採用混合加密的方式，即先用非對稱加密的方式傳送對稱加密的密匙，雙方確認後，以後的通信都用對稱加密的方式進行通信，如下：

但上述用非對稱加密的過程存在的問題是，無法鑑別公匙的來源。此時，就採用公匙分配中介紹的，由認證機構CA來進行公匙的分配。具體過程如下：

通過證書機構，就能完成客戶端和服務器身份鑑別的兩個任務。

4. 報文完整性鑑別

除了客戶端和服務端身份鑑別，HTTPS還要實現報文完整性保護，即要鑑別報文是否被篡改。SSL 提供報文摘要功能來進行報文完整性保護。
HTTP 也提供了 MD5 報文摘要功能，但不是安全的。例如報文內容被篡改之後，同時重新計算 MD5 的值，通信接收方是無法意識到發生了篡改。HTTPS 在發送數據時，會附帶一種叫MAC 的報文摘要，其比HTTP的報文摘要更安全的原因是：其先用MD5或SHA-1生成報文摘要，再對報文摘要利用加密，生成數字簽名，發送時，將數據和數字簽名一起發送。破解數字簽名的難度要遠遠大於HTTP中僅破解報文摘要的難度。

5. 認證

5.1 SSL客戶端認證

認證步驟：

1.接受到需要認證資源的請求，服務器會發送證書請求報文，要求客戶端提供客戶端證書
2.客戶端收到響應後，將客戶端證書發送給服務器
3.服務器驗證通過後，方可領取客戶端的公匙，然後開始加密通信。

5.2 基於表單認證

通過表單輸入的信息，來進行認證（即通過我們輸入的用戶名密碼進行認證）。由於基於表單的認證不收費，故通常使用基於表單的認證。爲了更加安全，可以將基於表單的認證和SSL客戶端認證結合起來一起使用。

6. 目前HTTP(s)存在的問題

6.1 存在的問題

儘管HTTP(s)已經在廣泛使用了，但仍存在以下問題：

1.一條連接只能發送一個請求
2.請求只能從客戶端發起，客戶端不能接收除響應以外的其他指令
3.請求/響應的首部未經壓縮就發送，首部信息越多延遲越大
4.發送冗餘的首部：每次發送相同的首部浪費較多

6.2 目前的解決辦法

Ajax： 如果不使用Ajax，那要刷新頁面內容就只能重新請求一次。而Aajx實現了在網頁加載完成以後，還能通過JS來發送請求。這樣，請求成功以後，就可以根據請求結果來局部更新頁面。Aajx可能會導致大量的請求產生，且未從根本上解決HTTP存在的問題。
Comt： 這是爲了實現推送功能而設計的一種方法。其實現原理是，客戶端請求後，服務器先響應，而是先將響應掛起。等到有推送信息的時候，再去響應。此方法會一直保持連接，會耗費較多資源。

6.3 HTTP2.0

HTTP2.0主要圍繞以下技術進行討論：

七. WebSocket

1 簡介

WebSocket是瀏覽器與服務器之間的全雙工通信標準。建立在HTTP協議基礎之上，一旦建立WebSocket連接，客戶端和服務器端任意一方都可以直接向對方發送報文。

2 特點

1.推送功能： 支持服務器向客服端的推送功能。
2.減少通信量： 一旦建立連接，就希望一直保持連接。這樣和HTTP相比，就能減少掉每次連接的開銷，同時，WebSocket首部信息較少。

3.連接過程

第一次握手： 和普通HTTP相比，第一次握手時，要將Upgrade字段設置爲websocket，告知服務器這是一個WebSocket連接。其次還有以下變化：

第二次握手： 服務器收到請求連接後，返回狀態碼101 Switching Protocols 的響應。

發送數據時，不再使用HTTP數據幀，而是使用WebSocket獨有的數據幀。

秋招準備之——計算機網絡知識整理（二）