1.Http連接基礎
Http協議承載了互聯網上的主要流量，然而說到傳輸，還要回歸到最基本的網絡分層模型TCP/IP。TCP/IP是全球計算機及網絡設備都在使用的一種常用的分組交互網絡分層協議集。客戶端可以打開一條TCP/IP連接，與世界上的任何服務器進行數據交換，并且交換的數據永遠不會丟失，受損或失序。
下面是常見的TCP/IP分層協議，分為安全與非安全版本。
由圖可知，HTTP的整個傳輸過程可以描述為“HTTP over TCP over IP”。TCP是可靠地傳輸協議，就好像一條管道，從TCP連接一段填入的字節會從另外一端以原有的順序，正確的傳送出來。
TCP層與IP層都有自己的協議，他們對數據的關注點不同。總的來說，TCP段包含了目的端口與源端口，用來建立程序之間的連接。IP段包含了目的IP與源IP，用來進行網絡尋址，最終建立機器之間的連接。而一條TCP連接正是根據這四點唯一對應的：
不同的連接不可以擁有完全相同的四個屬性。對于一般功能而言，自己發起的連接中源端口號是隨機生成的。
2.http連接性能
由于http數據是通過TCP傳輸的，http連接的性能很大程度上取決于TCP通道的性能。我們先分析一個正常的http事務。
客戶端如果拿到的是域名，則需要先從DNS服務器中解析獲得服務器IP地址，這個過程稱為“DNS查詢”，需要花費一定的時間。
客戶端與服務器進行三次握手建立連接。
建立連接后，客戶端會發送有真正含義的請求報文。
服務器接收到請求后開始處理。
服務器處理完畢后，發送響應給客戶端。
客戶端收到響應后，與服務器進行四次揮手，斷開連接。
從上面的流程可以看出來，真正的有業務意義的階段是“請求-處理-響應”，其他階段時間消耗都是與業務無關的。因此可以從這上面思考如何優化TCP性能。
3.TCP連接性能聚焦
TCP連接的性能通常從下面5個方面考慮：
TCP建立握手
捎帶確認的TCP延遲確認算法
TCP慢啟動的擁塞控制
數據聚集的Nagle算法
TIME_WAIT時延與端口耗盡
3.1 TCP建立握手
從上面的圖中可以看出，一次正常的交互需要經過DNS查詢、握手、揮手等與數據傳輸無關的操作。如果每次傳輸的數據都很少，那么這種操作所占用的比例就會增加，這將大大降低HTTP的性能。由于HTTP是建立在TCP連接的基礎上的，所以握手的過程是對HTTP不可見的，HTTP只能看到建立連接發生了時延。三次握手的過程這里不做贅述，感興趣的請查閱相關資料。
三次握手簡單來說是建立連接前的三次交互來確認連接可以建立，有SYN,ACK+SYN,ACK三次報文通信。對于一些小的HTTP事務，比如握手后告知頁面304了，這種事務中在TCP建立上可能會法費一半甚至更多的時間。
解決方案：我們可以通過重用TCP連接來減少這種性能上的損失，比如持久連接。
3.2 延遲確認
因特網是無法保證數據可靠傳輸的，因為在網絡路由超負荷的情況下，允許丟棄任意網絡分組。所以，TCP實現了一套自己的確認機制來保障數據可靠傳輸。
每個TCP段都有一個序號和數據校驗和，接受者在接受完整之后會向發送者送回確認分組，這樣保證了這個分組的可靠傳輸。如果發送者在一定時間窗口內沒有接收到響應的確認分組，則認為這個分組已經丟失，對該分組進行重發。
由于確認報文很小，所以TCP允許在發往相同方向的數據分組中對其進行“捎帶”，就是這種捎帶出了問題。TCP將返回確認信息與輸出信息集合在一起，可以有效的利用網絡連接。因此為了找到相同方向的數據分組來進行捎帶，很多TCP棧實現了一種“延時確認”的算法。這種算法將確認信息放入緩沖區，在一定的時間窗口內（一般是100-200毫秒）找不到輸出分組，則對確認數據進行單獨發送。
如果請求響應并沒有較多的數據傳輸過程，則滿足捎帶確認的可能性就很低。通常，延遲確認算法會引入相當大的時延。
解決方案：根據操作系統的不容，可以調整或禁止延遲確認算法。
3.3 慢啟動與擁塞控制
TCP傳輸過程有慢啟動與擁塞控制的概念。
TCP在建立連接開始的時候，會進行慢啟動，數據窗口會逐漸指數變大，在達到閾值后會線性增長。當發生某次超時之后，會迅速減小窗口到最小，重新開始慢啟動，通知減小之前的閾值。
在這種機制的保障下，一個TCP連接是會進行自我調整的，因此一個新的連接的傳輸效率是不如老連接的。
解決方案：我們通過重用連接，可以使得傳輸效率提升，比如持久連接。
3.4 Nagle算法與TCP_NODELAY
Nagle算法與延時確認算法有些類似。不過Nagle算法關注的是發送方，為了保證不大量發送小的數據報文造成3.1的問題。該算法鼓勵每次發送大的數據組，如果數據分組不夠大，則放在緩存區等待與其他數據分組結合起來達到上限后一起發送，或者其他分組被確認后發送。
而對于一些小的數據分組而言，可能很多個也無法攢夠一次發送的數量。當這時接收端也采用延時確認算法之后，事情就變得恐怖了。對于發送端而言，很多小的數據分組沒有成功發送，因為第一個分組發送之后，服務端進行了延時確認200ms，在這段時間過去之后發送端的第二個分組才會被發送，這樣的排隊阻塞簡直是噩夢。
解決方案：可以在協議棧中設置TCP_NODELAY來禁用Nagle算法。
3.5 TIME_WAIT時延與端口耗盡
當一個TCP連接完成四次揮手關閉之后，會進入TIME_WAIT狀態，在等待2MSL之后會釋放該TCP連接。因為TCP的分組可能不是按照順序到達的，我們假設一個分組在網絡中最多存貨1MSL，則2MSL之后基本上就可以認為確實結束了。如果在2MSL之間服務端沒有接收到LAST_ACK發送的FIN對應的響應，則TIME_WAIT會再次發送ACK。
之前有說過，一個TCP可以通過下面四個屬性來確認。
而對于一個服務來說，之后源端口是不確定的，因為每次源端口都是隨機生成的。但是源端口是有數量限制的，比如60000個端口，MSL是60秒。則連接速率就被限制在60000/120=500次/秒。如果不進行相關的優化，操作系統就無法發起更多的連接。
解決方案：可以增加請求端機器，通過負載均衡的方法降低端口耗盡的可能性，或者在服務端使用幾個虛擬IP增加連接的組合。
4 總結
HTTP建立在TCP的基礎上，如果我們在工作中發現HTTP建立連接的效率很低，可以考慮從上面的五個角度分析是否達到了相關的瓶頸，并通過推薦方案解決問題。
以上這篇高效管理http連接的方法就是小編分享給大家的全部內容了，希望能給大家一個參考，也希望大家多多支持腳本之家。
