完整的一次 HTTP 请求响应过程（一）
因特網無疑是人類有史以來最偉大的設計，它互聯了全球數億臺計算機、通訊設備，即便位于地球兩端的用戶也可在頃刻間完成通訊。
可以說『協議』是支撐這么一個龐大而復雜的系統有條不紊運作的核心，而所謂『協議』就是通訊雙方所必須遵守的規則，在這種規則下，不同的數據報可能被解析為不同的響應動作。
簡而言之，『協議』就是指如果發送和接收方按照這個規則進行數據報文的發送，即可在基本的數據傳輸之上得到某些特殊的功能或服務，否則你的數據別人是不認識的。例如：遵循 TCP 協議的兩端，可以在不可靠的網絡傳輸中得到可靠的數據傳輸能力。
整個計算機網絡是分層的，有七層模型，也有五層模型，個人覺得五層模型更利于理解。我們從上至下的介紹這五個層，它們分別是，應用層，運輸層，網絡層，數據鏈路層和物理層。
應用層
『應用層』算是距離用戶最近的一層了，主機上的一個個的進程就構成了『應用層』。比如你在你的瀏覽器地址欄輸入了 「www.baidu.com」，你的瀏覽器在應用層會做哪些事情呢？
首先瀏覽器會使用 DNS 協議返回域名「www.baidu.com」所對應的 IP 地址，關于 DNS 我們待會詳細介紹。
接著，應用層決定創建一個『TCP 套接字』，然后將這個請求動作封裝成一個 Http 數據報并推入套接字中。
套接字分為兩種類型，『TCP 套接字』和『UDP 套接字』，應用層同時可能會有幾十個數據報的發出，而運輸層也會收到所有的響應報文，那么它該如何區分這些報文到底是誰的響應報文呢？
而套接字就是用于區分各個應用層應用的，往往由端口號和 IP 地址進行標識，運輸層只要查看響應報文的源端口號和 IP 地址就能夠知道該將報文推送給哪個套接字了。
當一個應用層數據報被推動進套接字之后，應用層的所有工作也算是全部完成了，關于后續報文的去向，它已經不用管了。
這里還要說明一點的是，『TCP 套接字』和『UDP 套接字』兩者本質上的區別在于，前者保證數據報可靠地到達目的地，但是必然耗時，而后者不保證數據報一定能到達目的地，但是速度快，這也是應用層協議在選擇運輸層協議的時候需要考慮的一點。
關于 TCP 和 UDP，我們后續還會繼續說，下面我們看看域名解析協議 DNS 是如何運作的，它是如何將一個域名解析返回它的 IP 地址的。
DNS 原理
首先明確一點的是，DNS 是一個應用層協議，并且它選擇的運輸層協議是 UDP，所以你的域名解析過程一般會很快，但也會經常出現解析失敗的情況，然而刷新一下又好了。
在 DNS 服務器上，域名和它所對應的 IP 地址存儲為一條記錄，而所有的記錄都不可能只存儲在一臺服務器上，我相信無論多么強大的服務器都扛不住全球上億次的并發量吧。
大致來說，有三種類型的 DNS 服務器，根 DNS 服務器，頂級域 DNS 服務器和權威 DNS 服務器。
其中，頂級域 DNS 服務器主要負責諸如 com、org、net、edu、gov 等頂級域名。
根 DNS 服務器存儲了所有頂級域 DNS 服務器的 IP 地址，也就是說你可以通過根服務器找到頂級域服務器。例如：「www.baidu.com」，根服務器會返回所有維護 com 這個頂級域服務器的 IP 地址。
然后你任意選擇其中一個頂級域服務器，請求該頂級域服務器，該頂級域服務器拿到域名后應當能夠做出判斷并給出負責當前域的權威服務器地址，以百度為例的話，頂級域服務器將返回所有負責 baidu 這個域的權威服務器地址。
于是你可以任意選擇其中一個權威服務器地址，向它繼續查詢 「www.baidu.com」 的具體 IP 地址，最終權威服務器會返回給你具體的 IP 地址。
至此，我們簡單描述了一個域名解析的大致過程，還有一些細節之處并未提及，我們等會會通過一個實例來完整的看一下，下面描述一個非常重要的概念。
整個 DNS 解析過程中，有一個非常核心的人物我們一直沒介紹它，它就像主機的『助理』一樣，幫助主機查詢域名的 IP 地址。它叫做『本地 DNS 服務器』。
大家每次通過 DHCP 動態獲取 IP 地址的時候，這一點后文會說。其實路由器不僅給你返回了 IP 地址，還會告訴你一個 DNS 服務器地址，這個就是你的本地 DNS 服務器地址，也就是說，你的所有域名解析請求只要告訴它就行了，它會幫你查并返回結果給你的。
除此之外，本地 DNS 服務器往往是具有緩存功能的，通常兩天內的記錄都會被緩存，所以大部分時候你是感覺不到域名解析過程的，因為往往就是從緩存里拿的，非?？?。
下面我們看一個簡單的案例：
網上找的一個圖，自己畫實在太費時間了，但足以說明問題，現在假設請求 「www.xx.com」 。
作者：YangAM
鏈接：https://juejin.im/post/5b10be81518825139e0d8160
來源：掘金
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
?
- ①：主機向負責自己的本地 DNS 發送查詢報文，如果本地服務器緩存中有，將直接返回結果
- ②：本地服務器發現緩存中沒有，于是從內置在內部的根服務器列表中選一個發送查詢報文
- ③：根服務器解析一下后綴名，告訴本地服務器負責 .com 的所有頂級服務器列表
- ④：本地服務器選擇一個頂級域服務器繼續查詢，.com 域服務器拿到域名后繼續解析，返回負責 .xx 域的所有權威服務器列表
- ⑥：本地服務器從返回的權威服務器之一再次發送查詢報文，最終會從某一個權威服務器上得到具體的 IP 地址
- ⑧：向主機返回結果
其實整個 DNS 報文的發送與響應過程都是要走我們的五層協議的，只是這里重點在于理解 DNS 協議本身，所以并未提及其他層的具體細節，這里的強調是提醒你 DNS 只是一個應用層協議。
運輸層
運輸層的任務就是將應用層推出套接字的所有數據報收集起來，并且按照應用層指定的運輸層協議，TCP 或 UDP，重新封裝應用層數據報，并推給網絡層等待發送。
TCP 和 UDP 是運輸層的兩個協議，前者是基于連接的可靠傳輸協議，后者是無連接的不可靠傳輸協議，所以前者更適合于一些對數據完整性要求高的場合，后者則適合于那種可以允許數據丟失但對傳輸速率要求特別高的場景，例如：語音電話，視頻等，丟一兩個包最多卡頓一下，無傷大雅。
UDP
UDP 不同于 TCP 那樣復雜，它既不保證數據可靠的傳輸到目的地，也不保證數據按序到達目的地，僅僅提供了簡單的差錯檢驗。報文格式如下：
其中，數據就是應用層推出來的數據，源端口號用于響應報文的交付，目的端口號用于向目的進程交付數據，校驗和用于檢查傳輸過程中數據是否受損，如果受損，UDP 將直接丟棄該報文。
TCP
TCP 要稍微復雜些，它是面向連接的，并且基于連接提供了可靠的數據傳輸服務，它的數據報文格式如下：
單純的解釋報文格式中各個字段的含義并沒有太過實際的意義，你也很難理解了，在我們介紹 TCP 是如何『三次握手』，『四次揮手』以及『丟包重傳』等動作時，不間斷的會說明這些動作時如何使用報文中的相關字段的。
首先我們來看耳熟能詳的『三次握手』，這基本上是 TCP 的代名詞了，無論懂不懂具體原理的人，提到 TCP，基本上都是知道『三次握手』的。
而本身，TCP 的三次握手就是為了確保通訊雙方能夠穩定的建立連接并完成數據報文的請求與響應動作，至于為什么是三次握手而不是四次五次，這是一個哲學問題，這里就不做討論了。
第一步：
客戶端向服務端發送一份特殊的 TCP 報文，該報文并不包含應用層的數據，是一份特殊的報文，它的 TCP 首部中 SYN 字段值為 1 （參見上述報文格式）。
除此之外，客戶端還會隨機生成一個初始序號，填在報文的「序號」字段，代表當前報文的序號是這個，并且我后續的分組會基于這個序號遞增。
然后該報文將會經網絡層、鏈路層、物理層發送到服務端。
第二步：
如果分組丟失了，那么客戶端會經過某個時間間隔再次嘗試發送。
而如果分組準確的到達服務端了，服務端拆開 TCP 首部會看到，這是一個特殊的 SYN 握手報文，于是為此次連接分配緩存等資源。
接著服務端開始構建響應報文，SYN 是一個用于同步需要的字段，響應報文中依然會被置為 1，并且服務端也將隨機生成一個初始序號放置的響應報文的序號字段中。
最后，服務端還會為響應報文中的確認字段賦值，這個值就是客戶端發過來的那個序號值加一。
整體上的意思就是說，「我同意你的連接請求，我的初始序號為 xxx，你的初始序號我收到了，我等著你的下一個分組到來」
第三步：
客戶端收到服務端的響應報文，于是分配客戶端 TCP 連接所必須的緩存等資源，于是連接已經建立。
實際上從第三步開始，客戶端就可以攜帶應用層數據向服務端交換報文了，以后的每份報文中，SYN 都為 0，因為它只是用于同步初始序號的，這一點需要明確。
總的來說，整個『握手』過程大致如下圖所示：
下面我們看看拆除一條 TCP 連接的『四次揮手』是怎樣的過程。
因為一條 TCP 連接會消耗大量的主機資源，不僅僅服務端需要分配各種緩存資源，客戶端也同樣需要分配相應資源。因為 TCP 是『全雙工通信』，服務端和客戶端兩方其實是一樣的，誰是客戶誰是服務器是相對的。
強調這一點是為了說明，一條 TCP 連接不是只有客戶端才能斷開，服務端也同樣可以主動斷開連接，這一點需要清楚。
我們這里假設客戶端主動發起斷開連接的請求為例：
第一步：
客戶端構建一份特殊的 TCP 報文，該報文首部字段 FIN 被置為 1，然后發送該報文。
第二步：
服務端收到該特殊的 FIN 報文，于是響應客戶端一個 ACK 報文，告訴客戶端，請求關閉的報文已經收到，我正在處理。
第三步：
服務端發送一個 FIN 報文，告訴客戶端，我將要關閉連接了。
第四步：
客戶端返回一個 ACK 響應報文，告訴服務端，我收到你剛才發的報文了，我已經確認，你可以關閉連接了。
當服務端收到客戶端發送的 ACK 響應報文時，將釋放服務端用于該 TCP 連接的所有資源，與此同時，客戶端也會定時等待一定時間后完全釋放自己用于該連接的相關資源。
用一張圖更直觀的描述一下：
結合著圖與相關序號信息，我們再詳細說說其中的一些細節。
首先，客戶端發送一個特殊分組，該分組的序號為 u。發送完成之后，客戶端進入 FIN-WAIT-1 這個狀態，這個狀態下，該 TCP 連接的客戶端不再能發送數據報，但是是可以接受數據報的，它等待著服務端的響應報文。
接著，服務端收到客戶端發送的終止連接報文請求，服務端構建響應報文，告訴客戶端「序號 u+1 以前的分組我都收到了」，并且進入 CLOSE-WAIT 狀態，這個狀態持續時間很短。
服務端會緊接著發送它的 FIN 數據報，通知客戶端我服務端即將關閉連接，并隨即進入 LAST_ACK 狀態等待客戶端響應報文。
一旦客戶端收到這個 FIN 報文，將返回確認報文并進入 TIME-WAIT 狀態，等待 2MSL 時間間隔后完全釋放客戶端 TCP 連接所占用資源。
與此同時，當服務端收到客戶端最后的確認報文，就將直接斷開服務端連接并釋放相關資源。
至于為什么最后客戶端需要等 2MSL 時間長度再完全釋放 TCP 相關資源呢？
那是因為 2MSL 是一份報文存在于網絡中最長的時間，超過該時間到達的報文都將被丟棄，而如果客戶端最后的確認報文于網絡中丟失的話，服務端必將發起超時請求，重新發送第三次揮手動作，此時等待中的客戶端就可隨即重新發送一份確認請求。
這是為什么客戶端等待一個最長報文傳輸時間的原因。有人可能好奇為什么前面的各次請求都沒有做超時等待而只最后一次數據發送做了超時等待？
其實原因很簡單，相信你也能想到，就是 TCP 自帶計時能力，超過一定時間沒有收到某個報文的確認報文，會自動重新發送，而這里如果不做等待而直接關閉連接，那么我如何知道服務端到底收到沒我的確認報文呢。
通過等待一個最長周期，如果這個周期內沒有收到服務端的報文請求，那么我們的確認報文必然是到達了服務端了的，否則重復發送一次即可。
至此，TCP 的『三次握手』和『四次揮手』我們已經簡單描述完成了，下面我們看看 TCP 的一些其他特性，比如：可靠傳輸，擁塞控制等
首先我們來看 TCP 是如何實現可靠傳輸的，即如何解決網絡傳輸中丟包的問題。
TCP 使用『回退 N 步』協議實現的可靠傳輸，準確來說，TCP 是在它的基礎上進行了一部分優化。
『回退 N 步』協議也被稱作『滑動窗口』協議，即最多允許發送方有 N 個「已發送但未被確認」的數據報文，如圖所示，p1 到 p3 長度即為 N，這里的窗口指的就是 p1 到 p3 這個區間。
只有當發送端收到 p1 的確認報文后，整個窗口才能向前滑動，而實際上在沒有收到 p1 的確認報文前，即便它后面的報文已經被接收，服務端也僅僅會緩存這些『非預期的報文』
直到服務端收到最小預期的那個報文后，從緩存中取出已經到達的后續報文，合并并向上交付，然后向發送端返回一個確認報文。
當發送端窗口從左往右已經連續多個報文被確認后，整個窗口將向前滑動多個單位長度。
下面我們看一個例子：
這是一個發送方的窗口，灰色表示已經被確認的報文，黃色表示已發送但未被確認的報文，綠色表示下一個待發送的報文，白色表示不可用的報文。
這是我們假設服務端已經收到 6、7 兩份報文，但是它上一次向上交付給應用層的是 4 號報文，也就是說它在等 5 號報文，所以它暫時會將 6、7 兩個報文緩存起來，等到 5 號報文來了一并交付給應用層。
現在 5 號報文由于超時被重傳了，終于到達目的地了，如愿以償，服務端向上交付 5、6、7 三份報文，并返回一份確認報文，ACK = 8，表示序號 8 以前的所有報文都收到了。
當發送端收到這份確認報文后，5、6、7 變成灰色，窗口向前移動三個單位長度。
此外，我還想強調一個細節，TCP 是沒有否定確認的，所以如果服務端連續響應的多份報文是對同一序號的確認，那很有可能該序號以后的某個報文丟失。
例如：如果服務端發送多個對分組 5 的 ACK 確認，那說明什么？說明目前我服務端完整的向上交付的序號是 5 號，后續的報文我沒收到，你最好重新發一下別等待超時了。
這也是『快速重傳』的核心原理。
那么 TCP 的可靠傳輸我們也基本介紹完了，下面我們看看如果網絡擁塞的時候，TCP 是如何控制發送流量的呢？
TCP 認為：丟包即擁塞，需要降低發送效率，而每一次收到確認數據報即認為網絡通暢，會增加發送效率。
TCP 的擁塞控制算法包含三個部分，慢啟動、擁塞避免和快速恢復。
慢啟動的思想是，剛開始緩慢的發送，比如某個時間段內只發送一次數據報，當收到確認報文后，下一次同樣的時間間隔內，將發送兩倍速率的兩份數據報，并以此類推。
所以，短時間內，一個 TCP 連接的發送方將以指數級增長，但一旦出現丟包，即收到冗余的 ACK 確認，或者對于一個包的確認 ACK 始終沒收到而不得不啟動一次超時重傳，那么發送方認為「網絡是擁塞的」。
于是將速率直接調成一，即一個往返時間段，只發送一個分組，并且設置一個變量 ssthresh 表述一個閾值的概念，這個值是上次丟包時發送方發送速率的一半。
之后的發送方的發送效率一樣會以指數級增長，但是不同于第一次，這次一旦達到這個閾值，TCP 將進入『擁塞避免』模式，該模式下的發送效率將不再指數級增長，會謹慎的增長。
擁塞避免的思想是，每個往返時間段發送的所有數據報全部得到確認后，下一次就增加一個分組的發送，這樣緩慢的增長效率是謹慎的。
那么一旦出現發送端超時丟包，注意這里是超時，將發送速率置為一并重新進入慢啟動狀態，閾值就是當前發送效率的一半。
而如果是服務端返回多個冗余 ACK 以明確你丟包，TCP 認為這不是嚴重的，對于這種情況，TCP 減半當前發送效率并進入快速恢復階段。
快速恢復的基本思想是，收到幾個冗余的 ACK 就增加幾個分組的發送效率，就是說，你服務端不是沒收到我的幾個報文嗎，這兩次發送我提升速率迅速發給你。
當這期間出現了由發送端超時導致的丟包，同樣的處理方式，初始化發送速率為一并減半當前發送效率作為閾值，進入慢啟動階段。
當然，如果這期間收到了對丟失報文的確認，那么將適當降低發送效率并進入擁塞避免狀態。
這樣，整個 TCP 最核心的幾個思想都已經介紹完了，整個運輸層基本上也算明了了。關于運輸層，你應當有了一定的理解，我再總結一下。
運輸層的任務就是從應用層的各個進程的套接字那取回來所有需要發送的數據，然后選擇 TCP 或者 UDP 將數據封裝并推給下面的網絡層待發送。
未完，待續。。。
文章中的所有代碼、圖片、文件都云存儲在我的 GitHub 上：
(https://github.com/SingleYam/overview_java)
?
作者：YangAM
鏈接：https://juejin.im/post/5b10be81518825139e0d8160
來源：掘金
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
總結
以上是生活随笔為你收集整理的完整的一次 HTTP 请求响应过程（一）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 一个多线程死锁案例，如何避免及解决死锁问
- 下一篇： 完整的一次 HTTP 请求响应过程（二）