您好,登錄后才能下訂單哦!
世界上幾乎所有的 HTTP 通信都是由 TCP/IP 承載的,TCP/IP 是全球計算機及網(wǎng)絡(luò)設(shè)備都 在使用的一種常用的分組交換網(wǎng)絡(luò)分層協(xié)議集??蛻舳藨?yīng)用程序可以打開一條 TCP/IP 連 接,連接到可能運行在世界任何地方的服務(wù)器應(yīng)用程序。一旦連接建立起來了,在客戶端 和服務(wù)器的計算機之間交換的報文就永遠不會丟失、受損或失序。
盡管報文不會丟失或受損,但如果計算機或網(wǎng)絡(luò)崩潰了,客戶端和服務(wù)器之間的通信仍然會被斷開。在這種情況下, 會通知客戶端和服務(wù)器通信中斷了。
當瀏覽器收到一個 URL 的時候,會執(zhí)行幾個相對應(yīng)的步驟,如下
瀏覽器解析出主機名;
瀏覽器查詢主機名的 IP 地址;
瀏覽器獲得端口號;
瀏覽器發(fā)起對該 IP 地址對應(yīng)端口號的鏈接;
瀏覽器向服務(wù)器發(fā)送一條 HTTP GET報文;
瀏覽器從服務(wù)器讀取 HTTP 相應(yīng)報文;
1.1、TCP 連接的基本知識
TCP 是可靠的數(shù)據(jù)管道
TCP 會按序、無差錯地承載 HTTP 數(shù)據(jù),TCP 為 HTTP 提供了一條可靠的比特傳輸管道。從 TCP 連接一端填入的字節(jié)會從另一端 以原有的順序、正確地傳送出來。
TCP 流是分段的、由 IP 分組傳送
TCP 的數(shù)據(jù)是通過名為 IP 分組(或 IP 數(shù)據(jù)報)的小數(shù)據(jù)塊來發(fā)送的。
這樣的話,如圖 HTTP 就是 “HTTP over TCP over IP” 這個“協(xié)議?!敝械淖铐攲恿恕F浒踩姹?HTTPS 就是在 HTTP 和 TCP 之間插入了一個(稱為 TLS 或 SSL 的)密碼加密層(安全層),就是在圖中的右半部分。
HTTP 要傳送一條報文時,會以流的形式將報文數(shù)據(jù)的內(nèi)容通過一條打開的 TCP 連接按 序傳輸。TCP 收到數(shù)據(jù)流之后,會將數(shù)據(jù)流砍成被稱作段的小數(shù)據(jù)塊,并將段封裝在 IP 分組中,通過因特網(wǎng)進行傳輸,如下圖中大家看到的內(nèi)容:
每個 TCP 段都是由 IP 分組承載,從一個 IP 地址發(fā)送到另一個 IP 地址的。
而每個 IP 分組中都包括:
一個 IP 分組首部(通常為 20 字節(jié));
一個 TCP 段首部(通常為 20 字節(jié));
IP 首部包含了源和目的 IP 地址、長度和其他一些標記。TCP 段的首部包含了 TCP 端口 號、TCP 控制標記,以及用于數(shù)據(jù)排序和完整性檢查的一些數(shù)字值。
保持 TCP 連接的持續(xù)不間斷地運行
在任意時刻計算機都可以有幾條 TCP 連接處于打開狀態(tài)。TCP 是通過端口號來保持所有 這些連接的正確運行的。端口號和雇員使用的電話分機號很類似。
這就和我之前舉得例子是一樣的,公司的總機和你自己的座機一樣,公司的總機號碼能將你接到前臺,而分機號 可以將你接到正確的雇員位置一樣,IP 地址可以將你連接到正確的計算機,而端口號則 可以將你連接到正確的應(yīng)用程序上去。TCP 連接是通過 4 個值來識別的:
源IP 地址
、源端口號
、目的IP 地址
、目的端口號
這 4 個值一起唯一地定義了一條連接。兩條不同的 TCP 連接不能擁有 4 個完全相同的地 址組件值(但不同連接的部分組件可以擁有相同的值)。
這里需要我們注意的是,有些連接共享了相同的目的端口號,有些連接使用了相同的源 IP 地址,有些使用了相同的目的 IP 地址,但沒有兩個不同連接所有的 4 個值都一樣。
TCP 套接字
操作系統(tǒng)提供了一些操縱其 TCP 連接的工具。為了更具體地說明問題,我們來看一個 TCP 編程接口,這些套接字我就不一一介紹了,我給大家一個表格,大家可以理解一下
套接字API調(diào)用 | 描 述 |
---|---|
s = socket() | 創(chuàng)建一個新的、未命名、未關(guān)聯(lián)的套接字 |
bind(s,) | 向套接字賦一個本地端口號和接口 |
connect(s,) | 創(chuàng)建一條連接本地套接字與遠程主機及端口的連接 |
listen(s,...) | 標識一個本地套接字,使其可以合法接受連接 |
s2 = accept(s) | 等待某人建立一條到本地端口的連接 |
套接字 API 允許用戶創(chuàng)建 TCP 的端點數(shù)據(jù)結(jié)構(gòu),將這些端點與遠程服務(wù)器的 TCP 端點進 行連接,并對數(shù)據(jù)流進行讀寫。TCP API 隱藏了所有底層網(wǎng)絡(luò)協(xié)議的握手細節(jié),以及 TCP 數(shù)據(jù)流與 IP 分組之間的分段和重裝細節(jié)。
TCP 客戶端和服務(wù)器是如何通過 TCP 套接字接口進行通信的
上圖中說明了可以怎樣通過套接字 API 來凸顯客戶端和服務(wù)器在實現(xiàn) HTTP 事務(wù)時所應(yīng)執(zhí)行的步驟。
TCP 連接握手需要經(jīng)過以下幾個步驟。如圖所示:
請求新的 TCP 連接時,客戶端要向服務(wù)器發(fā)送一個小的 TCP 分組(通常是 40 ~ 60 個字節(jié))。這個分組中設(shè)置了一個特殊的 SYN 標記,說明這是一個連接請求。
如果服務(wù)器接受了連接,就會對一些連接參數(shù)進行計算,并向客戶端回送一個 TCP 分組,這個分組中的 SYN 和 ACK 標記都被置位,說明連接請求已被接受。
我們永遠不會看到這些分組——這些分組都由 TCP/IP 軟件管理,對其是不可見 的。HTTP 程序員看到的只是創(chuàng)建 TCP 連接時存在的時延。
在這里我們需要注意的就是?TCP 連接的握手時延,通常 HTTP 事務(wù)都不會交換太多數(shù)據(jù),此時,SYN/SYN+ACK 握手(參見圖中的 a 段 和圖中的 b 段)會產(chǎn)生一個可測量的時延。TCP 連接的 ACK 分組(參見圖中的 c 段)通常都足夠大,可以承載整個 HTTP 請求報文,而且很多 HTTP 服務(wù)器響應(yīng)報文都可 以放入一個 IP 分組 中去(比如,響應(yīng)是包含了裝飾性圖片的小型 HTML 文件,或者是對瀏覽器高速緩存請求產(chǎn)生的 304 Not Modified 響應(yīng))。
TCP 慢啟動
TCP 數(shù)據(jù)傳輸?shù)男阅苓€取決于 TCP 連接的使用期(age)。TCP 連接會隨著時間進行自 我“調(diào)諧”,起初會限制連接的最大速度,如果數(shù)據(jù)成功傳輸,會隨著時間的推移提高傳輸 的速度。這種調(diào)諧被稱為 TCP 慢啟動(slow start),用于防止因特網(wǎng)的突然過載和擁 塞。
TCP 慢啟動限制了一個 TCP 端點在任意時刻可以傳輸?shù)姆纸M數(shù)。簡單來說,每成功接收 一個分組,發(fā)送端就有了發(fā)送另外兩個分組的權(quán)限。如果某個 HTTP 事務(wù)有大量數(shù)據(jù)要發(fā) 送,是不能一次將所有分組都發(fā)送出去的。必須發(fā)送一個分組,等待確認;然后可以發(fā)送 兩個分組,每個分組都必須被確認,這樣就可以發(fā)送四個分組了,以此類推。這種方式被 稱為“打開擁塞窗口”。
由于存在這種擁塞控制特性,所以新連接的傳輸速度會比已經(jīng)交換過一定量數(shù)據(jù)的、“已 調(diào)諧”連接慢一些。由于已調(diào)諧連接要更快一些,所以 HTTP 中有一些可以重用現(xiàn)存連接 的工具。
前面我們說了 TCP 連接,我們重新來分析一下 HTTP ,之前我也說過在 HTTP 1.0的時候和1.1之后,有 Keep-Alive ,關(guān)于 Keep-Alive 不懂的請翻看前面的公眾號的文章內(nèi)容,接下來我分幾個內(nèi)容給大家講述 HTTP 對連接上的處理。
并行連接:通過多條 TCP 連接發(fā)起并發(fā)的 HTTP 請求。
持久連接:重用 TCP 連接,以消除連接及關(guān)閉時延。
我們來看一下串行:
每個事務(wù)都需要(串行地建立)一條 新的連接,那么連接時延和慢啟動時延就會疊加起來
并行連接就是說 HTTP 允許客戶端打開多條連接,并行的去執(zhí)行多個 HTTP 的事務(wù),就會出現(xiàn)多條線路平行的情況。
其實并行連接并沒有說是頁面的傳輸速度,是因為多個對象同時在進展,所以,他的速度要比疊加起來,讓你在感覺上快不少。
持久連接
HTTP 1.1 允許 HTTP 設(shè)備在事務(wù)處理結(jié)束之后 將 TCP 連接保持在打開狀態(tài),以便為未來的 HTTP 請求重用現(xiàn)存的連接。在事務(wù)處理結(jié)束之后仍然保持在打開狀態(tài)的 TCP 連接被稱為持久連接。非持久連接會在每個事務(wù)結(jié)束之后關(guān)閉。持久連接會在不同事務(wù)之間保持打開狀態(tài),直到客戶端或服務(wù)器決定將其關(guān)閉為止。
管道化連接(也有人稱之為管線化)
HTTP/1.1 允許在持久連接上可選地使用請求管道。這是相對于 keep-alive 連接的又一性能優(yōu)化。在響應(yīng)到達之前,可以將多條請求放入隊列。當?shù)谝粭l請求通過網(wǎng)絡(luò)流向地球另一端的服務(wù)器時,第二條和第三條請求也可以開始發(fā)送了。在高時延網(wǎng)絡(luò)條件下,這樣做可以降低網(wǎng)絡(luò)的環(huán)回時間,提高性能。
其實管道化說白了就是 傳送過程中不需先等待服務(wù)端的回應(yīng),然后又發(fā)了幾條,瀏覽器將 HTTP 要求大批提交可大幅縮短頁面的加載時間,特別是在傳輸延遲(lag/latency)較高的情況下(如衛(wèi)星連接)。此技術(shù)之關(guān)鍵在于多個 HTTP 的要求消息可以同時塞入一個 TCP 分組中,所以只提交一個分組即可同時發(fā)出多個要求,借此可減少網(wǎng)絡(luò)上多余的分組并降低線路負載。
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。