http協議進階（五）連線管理
幾乎所有的HTTP通訊都是由TCP/IP承載的，TCP/IP是全球計算機網路裝置都在使用的一種分組交換網路分層協議集。
它的特點是隻要連線建立，客戶端與伺服器之間的報文交換就永遠不會丟失、受損或失序。
一、TCP連線
1、TCP是可靠資料通道
TCP是英特網上的可靠連線，TCP為HTTP提供了一條可靠地位元傳輸通道，從TCP連線一端填入的位元組會從另一端以原有的順序、正確的傳送出來。
TCP會按序、無差錯的承載HTTP資料，如下圖：
2、TCP流是分段的，由IP分組傳送
TCP的資料是通過名為IP分組的小資料塊傳送的，HTTP就是“HTTP over TCP over IP”這個“協議棧”中的最頂層，其安全版本HTTPS就是在HTTP和TCP之間插入一個（TLS或SSL）密碼加密層。
如下圖所示：
HTTP在傳送一條報文時，會以流的形式將報文資料通過開啟的TCP連線按序傳輸。TCP收到資料流之後，將其劃分為被稱為段的小資料塊，封裝在IP分組中，通過英特網進行傳輸。
每個TCP段都是由IP分組承載，從一個IP地址傳送到另一個IP地址，其中包括：
①、一個IP分組首部（通常為20位元組）：包含源和目的IP地址、長度和其他一些標記；
②、一個TCP 段首部（通常為20位元組）：包含TCP埠號、TCP控制標記以及用於資料排序和完整性檢查的資料值；
③、一個TCP資料塊（0個或多個位元組）；
3、保持TCP連線不斷執行
TCP通過埠號來保持連線持續不斷的執行。IP地址可以連線到正確的計算機，埠號可以連線到正確的應用程式，TCP連線通過四個值來識別：
<源IP地址、源埠號、目的IP地址、目的埠號>
這四個值唯一的定義了一個連線（兩條不同的TCP連線不能擁有4個完全相同的地址元件值，不同連線部分可以擁有同樣的值）。
4、TCP套接字
作業系統提供了一些操縱TCP連線的程式設計介面，即套接字API，這個套接字API隱藏了所有的TCP和IP實現細節，下表是一些套接字API的主要介面：
| 套接字API呼叫 | 描述 |
| s= socket(<sparameters>) | 建立一個新的、未命名、未關聯的套接字 |
| bind(s,<local IP:port>) |
向套接字賦一個本地埠號和介面 |
| connect(s, <remote IP:port>) | 建立一條連線本地套接字與遠端主機及埠的連線 |
| listen(s,...) | 標識一個本地套接字，使其可以合法接受連線 |
| s2 = accept(s) | 等待某人建立一條到本地埠的連線 |
| n = read(s, buffer, n) | 嘗試從套接字向緩衝區讀取n個位元組 |
| n = write(s, buffer, n) | 嘗試從緩衝區中向套接字寫入n個位元組 |
| close(s) | 完全關閉TCP連線 |
| shutdown(s,<side>) | 只關閉TCP連線的輸出或輸入端 |
| getsockopt(s,...) | 讀取某個內部套接字配置選項的值 |
| setsockopt(s,...) | 修改某個內部套接字配置選項的值 |
套接字API允許使用者建立TCP的端點資料結構，將其與遠端伺服器的TCP端點進行連線，並對資料流進行讀寫。
TCP API隱藏了所有底層網路協議的握手細節，以及TCP資料流與IP分組之間的欄位和重灌細節。
二、TCP效能
1、HTTP事務的時延
首先來看一個HTTP請求的過程，如下圖：
一般來說，相比於建立TCP連線及傳輸請求和響應報文的時間，事務處理時間可能是很短的（除非客戶端或服務端超載或正在處理複雜的動態資源），否則HTTP時延是由TCP網路時延造成的。
http事務時延的原因有以下幾點：
①、DNS將伺服器域名轉換解析為一個IP地址所花費的時間；
②、客戶端向服務端傳送一個TCP連線請求所造成的時延（一般不會花費很多時間，但如果有很多的HTTP事務的話，時延就會變大）；
③、服務端處理請求報文以及回傳給客戶端，都需要花費一定的時間；
④、伺服器回送HTTP響應，也會花費一定的時間；
2、效能聚焦區域
常見的TCP相關時延如下：
①、TCP連線建立握手；
如下圖，新建TCP連線時會交換一系列的IP分組，對連線的有關引數進行溝通，如果連線只用來傳送少量資料，交換的過程就會嚴重降低HTTP效能。
②、TCP慢啟動擁塞機制；
TCP連線剛建立時為了防止網路突然過載和擁塞，會限制連結的最大速度，如果資料成功傳輸，會隨著時間的推移提高傳輸速度。
③、資料聚集的Nagle演算法；
④、用於捎帶確認的TCP延遲確認演算法；
⑤、TIME_WAIT時延和埠耗盡；
三、HTTP連線處理
目前現存和常用的連線方法大概有一下四種：
1、序列連線
最早的連線方式，即HTTP事務需要按順序進行傳輸，等待服務端完成處理並回傳，如下圖所示：
這樣做有兩個缺點：
①、TCP效能時延會不斷疊加；
②、在請求處理完成之前，客戶端無法對結果進行提前展示，只能被動等待；
2、並行連線
通過多條TCP連線發情併發的HTTP請求，如下圖所示：
並行連線有如下幾個特點：
①、可能會提高頁面載入速度，即連線請求和傳輸時間重疊，減小了連線時延和傳輸時延，但每個事務都會開啟/關閉一個新的連線，耗費時間和頻寬；
②、可以讓使用者“感覺更快”（與WEB頁面渲染的非同步展示類似的原理），但實際上，由於TCP慢啟動特性的存在，每個新連線的效能都會有所降低，且並行連結數量有限；
③、並行連線不一定比序列連線塊（受限於頻寬，可能造成資源競爭）；
3、持久連線
重用TCP連線，以消除連線及關閉時延，持久連線+並行連線，可能是最高效的連線方式，如下圖所示：
持久連線有兩種方式，分別為HTTP/1.0+的“Keep-alive”連線，以及HTTP/1.1的“persistent”連線。
Keep-alive：該首部只是請求將連線保持在活躍狀態，客戶端和服務端可以隨時關閉空閒的Keep-alive連線。
限制和規則：
①、必須客戶端傳送一個Connection：Keep-alive請求首部來啟用Keep-alive連線；
②、該首部必須隨請求的報文一起傳送；
③、只有在確定實體主體部分大小的情況下，連線才能保持在開啟狀態；
④、代理和閘道器必須執行Connection首部的規則；
Persistent：該首部預設情況下是啟用的，除非特別指明，否則HTTP/1.1假定所有連線都是持久的。
限制和規則：
①、如果需要在事務處理結束後將連線關閉，則應用程式必須向報文中顯式的新增一個Connection-close首部；
②、只有當連線上所有報文都有正確的、自動以報文長度時，連線才能持久保持；
③、每個持久連線都只適用於一跳傳輸；
④、應用程式可以在任意時刻關閉連線，但應該能夠從非同步關閉中恢復，重試這條請求；
⑤、一個客戶端對任何伺服器或代理最多隻能維護2條持久連線；
4、管道化連線
通過共享TCP連線發起併發的HTTP請求，這也是在持久連線的基礎上對效能的一種優化。
原理：在響應到達前，將多條請求放入佇列，在高延時網路條件下，可以降低網路環回時間，提高效能。
限制和規則：
①、如果HTTP客戶端無法確認連線是持久的，就不應使用管道連線；
②、必須按照與請求相同的順序回送HTTP響應；
③、客戶端必須做好連線會在任何時刻關閉的準備，以及重發所有未完成的管道化請求；
④、HTTP客戶端不應用管道化的方式傳送非冪等性請求（比如POST）；
四種不同連線方式的區別：
某些關於請求和響應首部的欄位詳細介紹，可以參考《HTTP權威指南》這本書中的內容。。。