瀏覽器輸入一個網址發生了什么(二)： TCP模塊封裝和傳輸機制
本系列文章開始將圍繞著“往瀏覽器輸入網址后發生了什么”介紹計算機網絡的相關基礎知識。上節簡單的介紹了http報文封裝和dns請求獲取目標IP。
接上文：瀏覽器輸入一個網址發生了什么(一) 揭秘DNS請求和解析全流程
本節將介紹http報文在協議棧中如何進一步處理并發送到網絡中。這里說的協議棧是指TCP/IP協議棧。
對于TCP傳輸而言，請求的發送和接收需要通過連接進行；而UDP傳輸則不用；本節會先介紹TCP傳輸的過程再介紹UDP傳輸。
在此之前，需要先介紹一些相關概念。
一、協議棧
協議棧是由多個具有層級的協議模塊組合而成的一個軟件程序。每個協議模塊通常都要和上下層的兩個其他協議模塊通信。最低級的協議總是描述與物理硬件交互，為每個高級的層次增加更多的特性。
協議是計算機在網絡通信時需要遵循的規范和約定，而協議棧則是這種規范和約定的實現，也就是具體的代碼和函數以供上層調用。每一層協議模塊都是為上一層協議模塊服務，本層的協議模塊完成某個操作只需要調用下層模塊的方法而無需關注其具體怎么實現。
二、套接字與連接
對于TCP傳輸而言，請求的發送和接收需要通過連接進行。我們可以把連接看做是一條端到端之間的管道，這條管道的兩端都既可以是發送方也可以是接收方，數據在這條管道是雙向流動的。而建立這條管道的出入口我們稱之為套接字，分別在客戶端和服務端兩方，兩方需要先創建套接字才能建立連接。連接建立后，請求和響應會通過套接字發出并通過這個管道進行傳輸。
當然管道只是一個比喻，現實中是不存在這么一個管道。
對于UDP傳輸，雖然不需要建立連接，但是依舊要創建套接字，并通過套接字發送和接收包。
三、什么是套接字
套接字本質是存放諸如IP地址、端口號、通信操作狀態這樣的通信控制信息的內存空間里的數據。協議棧在執行操作時會用到這些控制信息，如封裝報文時需要知道通信對象的IP和端口，如協議棧需要知道數據發送后經過了多長時間仍未返回以便重發，如比對序號是否正確，如保存窗口大小從而將窗口大小帶到TCP頭部通知通信的另一方，這都要查詢套接字的控制信息得知。
協議棧是根據套接字中記錄的控制信息來工作的。
在windows下執行netstat可以顯示套接字內容。如下圖所示，每一行就是一個套接字：
- 第一列：協議，通常為TCP或UDP，表示該套接字是為TCP傳輸還是UDP傳輸而創建的。
- 第二列：本地端的ip和端口；如果安裝了多塊網卡則會顯示不同的IP；0.0.0.0表示不綁定IP地址。
- 第三列：遠程端的IP和端口；0.0.0.0表示還未開始通信，沒有綁定IP和端口；此外，UDP協議中的套接字不綁定對方地址和端口因此顯示*:*。
- 第四列：通信狀態；LISTENING 等待對方連接；ESTABLISHED 完成連接正在通信。
- 第五列：使用該套接字程序的進程ID。
回到正題。
當客戶端程序（瀏覽器）拿到目標IP地址后，會經歷：創建套接字、連接、發送數據、接收數據、斷開連接、刪除套接字。如下圖所示
1.創建套接字
應用程序(瀏覽器)調用socket()方法，然后工作會切到操作系統的協議棧進行。協議棧會先分配一個用于存放套接字的內存空間，并向其寫入初始狀態，協議棧會返回一個代表套接字的描述符（一個整型）給瀏覽器。
之后當瀏覽器需要收發數據時（connect/read/write）就需要向協議棧提供這個描述符。協議棧會根據這個描述符找到對應的套接字進行操作。
2.建立連接
創建套接字后，應用程序（瀏覽器）會調用connect方法，工作會切換到操作系統的協議棧，由協議棧負責將本地的套接字和服務器的套接字進行連接。
連接的本質是通信雙方交換控制信息并記錄到雙方套接字中，之后的每一次數據收發時數據包都要帶上套接字中的控制信息。例如在本地套接字中記錄下服務器的ip和端口，并告知服務器請求方的ip和端口，讓服務端把客戶端的ip端口記錄到服務端套接字中，此外還有其他的控制信息。
另外，連接操作過程中，通信雙方還會分配一塊用于臨時存放收發數據的內存空間。
四、TCP控制信息（TCP頭部）
上面所說的控制信息會寫入到TCP報文的頭部發送到服務端，如下所示：
上面這些字段都是保存在套接字中，并且在需要構建頭部的時候從套接字中取出這些信息。再通信雙方的不斷通信的過程中會更新到套接字中（如窗口和序號）。
五、TCP傳輸的數據包
無論是連接、收發數據和斷開連接，通信雙方都需要通過發送數據包來進行。
對于連接和斷開連接而言，無需傳遞應用程序（瀏覽器）數據，因此數據包只用包含控制信息（也就是頭部信息）。而收發數據時的包會包含控制信息和數據塊內容。應用程序的數據可能會很大，因此協議棧會將數據切分為一個個數據塊，每個數據塊都添加上頭部控制信息做成包再發送。
如下所示：
下面我們正式介紹連接的過程：
- 應用程序（瀏覽器）調用socket庫的connect(<套接字的描述符>, <服務端的IP和端口>, ...)
- 工作切換到TCP/IP協議棧，協議棧構建包含諸多控制信息（通信雙方的端口，窗口，序號，ACK號等）的TCP頭部（TCP報文），并將頭部中的SYN比特位置為1，表示該報文是向服務端請求建立連接而建的。
- TCP模塊將構建好的TCP報文（該報文只包含頭部信息，沒有數據內容）交給IP模塊，由IP模塊進一步封裝成包（添加IP頭部和MAC頭部），IP模塊再通過網卡將包轉為電信號，借由網線傳輸給服務端。（包是如何根據IP地址找到服務器，以及包在網絡中的傳輸過程會在后面介紹）。
- 包到達服務端之后（通過網線、網卡到達服務端協議棧），根據報文中指定的端口找到服務端對應的套接字。服務端的套接字從監聽狀態變成正在連接的狀態，并且還會將報文中的控制信息寫入到套接字中保存。
- 之后服務端的協議棧也會封裝響應報文，該過程和上述A/B/C步驟類似，并且報文中的TCP頭部的SYN和ACK位置為1，意味著服務端向發送方發起連接請求(SYN=1)和接收到發送方的包(ACK=1)。
- 響應包到達發送方后，協議棧會把套接字的連接狀態改為已連接，并將服務端的IP和端口保存到套接字中。然后封裝一個ACK為1的包給服務端表示接受到服務端的連接請求包。
- 服務端接收到客戶端的ACK為1的包后連接操作才算完成。
到此為止，客戶端和服務端的套接字都保存了對方的信息，控制流程從操作系統回到了應用程序，之后可以開始真正發送客戶端的http消息了。在執行close之前，連接會一直保持。
上述雙方交換3次數據包的過程也是大家熟悉的“三次握手”過程。
http消息封裝成網絡包發送
連接完成以后，應用程序（瀏覽器）會調用socket庫的write()方法將數據（封裝好的http消息）傳遞給協議棧，由協議棧發送給服務端。
在講數據收發流程之前，需要先介紹一些數據收發的細節和重點：
六、網絡包
包是網絡數據在網絡層（如IP包和以太網包）的稱呼。
包是由記錄了控制信息的頭部和包的內容組成。IP頭部和MAC頭部是在網絡層添加的，因此都能被稱為包：
TCP模塊負責將http消息加上TCP頭部控制信息，并將這些數據傳遞給下一層的IP模塊，由IP模塊封裝IP頭部和MAC頭部形成網絡包，其中TCP頭部記錄著通信雙方的端口號，IP頭部記錄著通信雙方的IP。無論是連接階段的數據還是數據收發的數據都會經過IP模塊的封裝和發送。
IP頭部：
PS：IP地址不是分配給計算機的而是分配給網卡的。因此如果計算機內包含多塊網卡就可以擁有多個IP地址。如果客戶端和服務端主機有多個IP地址，那么在IP頭部中填寫哪個IP地址取決于協議棧想讓哪塊網卡發送數據包，并把數據包發送到服務器的哪塊網卡上。
MAC頭部：
下章節再對IP頭部和MAC頭部進行介紹。這里我們只需要知道添加了這兩個頭部之后數據就變成網絡包，再經由IP模塊傳遞給網卡，傳遞給網卡的時候，網絡包才算正式離開了協議棧。
其他層的網絡數據稱呼：
- 幀：數據在數據鏈路層的單位
- 包：數據在網絡層的單位
- 段：數據在傳輸層的單位
- 消息：數據在應用層的單位
七、數據發送時機
協議棧不一定會在一收到數據就馬上發出去，也可能是先將數據存到內部的發送緩沖區，等到積累到一定程度后再發送。
這樣做的原因是應用程序每次傳遞多少數據給協議棧是不定的，有些應用程序是逐字或逐行節傳遞給協議棧，有些是一次性傳遞整個請求的所有數據給協議棧，如果應用程序每次傳遞給協議棧的數據很少，且協議棧每接收到一次數據就馬上發送就會發送大量的小包導致網絡效率下降。
每次傳遞多少數據給協議棧是由應用程序決定的。
是否讓協議棧一接收到應用程序的數據就馬上發送也是由應用程序進行系統調用時的指定的一些選項決定的。
譬如對于瀏覽器這種會話型應用程序而言，它會指定讓協議棧馬上發送數據以避免延遲。
如果應用程序決定讓協議棧先緩存數據再發送的話，那么協議棧會根據兩個要素決定發送的時機：一個是網絡包能容納的最大數據長度，一個是應用程序傳遞數據的頻率（每次傳遞數據的時間間隔）
網絡包能容納的最大數據長度: 協議棧規定一個網絡包能容納的最大長度是MTU（在以太網中是1500字節），即IP頭部+TCP頭部+真實數據 <= 1500。除去頭部，真實數據的最大長度是MSS = 1500 - 20 - 20 = 1460。當協議棧收到的數據接近或超過MSS的長度時再發出去就可以避免發送大量小包的問題。
應用程序傳遞數據的時間間隔：
當應用程序傳遞消息的頻率不高的時候，如果每次都要等到長度接近MSS就會造成較大的發送延遲。協議棧中有一個計時器，當經過一定時間后即便緩沖區數據沒有達到MSS也會將其封裝為包發送出去。
八、大數據拆分
一般GET請求方式的HTTP消息不會很長，一個網絡包（這里的包是指IP模塊發出去的包）就能裝下。但如果要傳遞表單甚至上傳文件就可能超過一個包容納的數據量（MSS），此時發送緩沖區的數據量會大于MSS。這時協議棧的TCP模塊會將發送緩沖區中的數據（也就是http消息）以MSS為單位進行拆分為多個數據塊，每個塊被單獨添加TCP頭部，單獨封裝為網絡包傳輸。
在拆分數據時，TCP模塊會計算好每一塊數據的第一個字節是整體數據的第幾個字節，以此作為每塊數據的TCP頭部中的序號（序號是應用程序的數據序號而不是網絡包的長度序號）。
接收方可以根據接收到每個網絡包的長度減去頭部長度得到每個數據塊的長度。然后通過當前最新序號+數據塊長度得知下一個接收到的包的序號應該是多少。接收方返回的應答包的ACK號應該是當前最新序號+數據塊長度+1，下一次發送方應該發送的序號也應該是接收方上一次回包的ACK號。
例如：當前序號為A，包的長度是1460。那么響應包ACK號應該是A+1460+1 。接收方應該接收到的下一個包的序號應該是A+1460+1 = A + 1461。如果接收方收到的下個包的序號比A+1461大，就說明中間有包遺漏。
序號告訴接收方當前發送方已經發送了多少字節的數據，ACK告訴發送方當前接收方接收了多少字節的數據（所以同理，發送方能通過ACK號判斷接收方的回包是否有丟包）。
每次發送方發出的網絡包都會得到接收方包含ACK號的回包，這種機制成為確認應答機制。
實際通信中，序號不是從1開始，而是用隨機數計算出來的一個初始值。在連接階段，雙方設置SYN為1的時候，初始的序號也會被設置好并由通信雙方互相發送給對方（同理初始ACK號也在連接階段通知給對方）。
也就是說，通信的時候序號是有兩個，一個是客戶端生成的序號，一個是服務端生成的序號，因為TCP數據的收發是雙向的（例如服務端會接收到客戶端的包時回包，服務端也會在返回響應數據時主動發送包[這里不是指ACK包，而是返回http響應消息的網絡包]，所以客戶端不只是發送方，服務端不只是接收方，應該是客戶端和服務端都既能是發送方也能是接收方）。同理ACK號也有兩個。
如下：
序號和ACK號的出現是為了告訴通信雙方每次發包發送了多少數據和接收了多少數據從而判斷是否有丟包。丟包會引發TCP的重傳機制，重傳是TCP模塊獨有的錯誤補償機制，網卡、路由器、集線器一旦檢測到錯誤會直接丟棄包而不會重傳。
九、重傳機制之ACK號等待時間
當發送方發送包后會等待接收方返回帶有ACK號的回包（在這個等待過程中發送方不會什么都不做，這里涉及到后面要介紹的滑動窗口，這里先不提），這段等待的時間叫做ACK號的等待時間，如果超過了這段時間都沒有接收到回包，發送方會認為這個包在網絡中丟失，因而重新發送這個包。
發送方丟包 或者 發送方的包到達接收方后接收方的回包丟包 或者 接收方的回包因為網絡擁塞而返回緩慢都可能造成接收方等待超過ACK號的超時時間而引起重傳。
TCP模塊怎么設置一個合適的ACK等待時間？
由于不同服務器的距離不同，或者不同網絡環境下網絡擁塞的情況不同（如局域網內可能幾毫秒能返回ACK號，而在互聯網中遇到擁塞可能幾百毫秒才能返回），ACK等待時間不是一個固定的時間，而是動態變化的時間。TCP模塊會持續測量多次ACK號的返回時間，如果前幾次ACK號返回變慢就會延長等待時間，如果前幾次ACK號能馬上返回則縮短等待時間。
每次因為超過等待時間導致的重傳會延長這個超時時間，如果多次重傳后仍未收到確認包則會斷開連接。
十、重傳機制之快速重傳
快速重傳是比超時重傳更有效率的重傳方式，當接收方接收到亂序的報文（如 1-3-2，或者1-3-4）時，會立刻不延遲的返回重復ACK的回包給發送方，發送方重復接收到3次相同的ACK號之后就會重發丟失的包。如下所示：
圖中發送方第一個包到達，接收方返回ACK號為ACK2的回包；但發送方的第二個報文丟失，之后第3~5個包到達接收方，接收方通過確認包的序號得知第二個包沒有發送過來，因此對第3~5的包返回重復的ACK號（ACK2）。
接收方接收到多次重復的ACK號為ACK2的響應包之后得知第2個包沒有發送到接收方，就會重新發送第2個包（序號為ACK2的包），并且重發第3~5個包（因為發送方得到的最新ACK號是ACK2，因此會重發序號為ACK2以后的所有包）。接收方接收到第2~5個包后，統一回復了一個ACK號為ACK6的包。
如果使用了SACK選項，發送方只會重發第2個包，而不會重發3~5。
十一、簡述滑動窗口
如果TCP模塊發送一個包并等待回包的過程中什么都不做會顯得十分浪費。為了減少這樣的浪費，TCP模塊使用滑動窗口的方式發送包，也就是說它不會非得等到一個包回包之后才發下一個包，而是連續發送多個包并連續接收多個回包。如下所示：
接收方在接收到包會先存放到接收緩沖區，TCP模塊會從緩沖區中獲取包并計算包的ACK號，將多個包的數據塊組裝起來還原為原本的數據并傳遞給接收方的應用程序。
如果包到達的速度要比數據處理并傳遞給應用程序的速度快，那么緩沖區中數據就會越積越多最后溢出，溢出之后，接收方就無法接受后面的包。
如下圖所示，當接收方收到包之后，會馬上從接收緩沖區中取出包并處理，緩沖區的空間會得到釋放，然后在返回包的TCP頭部注明接收緩沖區的剩余空間（也是窗口大小），這樣發送方收到回包后就知道下次發送的數據量不要超過這個窗口的大小的數據量。
在接收方不斷發送數據的過程中，它會自動計算自己用掉了多少窗口大小，當計算到窗口大小為0時會暫停發送包。在這個過程中如果接收方回包，發送方會根據回包中的TCP頭部窗口大小來更新自己套接字內的窗口大小（自動計算過程為4380->2920->1460，此時接收方返回ACK包并告知窗口大小剩余2920，發送方會更新當前窗口大小為2920，再從2920繼續自動計算，2920->1460->0，此時暫停，直到接收方的ACK包又到達發送方，發送方再更新窗口大小，又開始繼續發包）。這就是滑動窗口的基本思路。
這張圖是為了講解方便，故意體現一種接收方來不及處理收到的包，導致緩沖區被填滿的情況。實際上，接收方在收到數據之后馬上就會開始進行處理，如果接收方的性能高，處理速度比包的到達速率還快，緩沖區馬上就會被清空，并通過窗口字段告知發送方。
還有，圖中只顯示了從右往左發送數據的操作，實際上和序號、ACK號一樣，發送操作也是雙向進行的。
另外需要注意的是：接收方不會對發送方的每個包都發送回包，因為接收方發送回包其實是為了通知發送方ACK號和窗口大小（也就是告訴發送方我收到了多少包以及我還能接收你多少包），所以接收方在一段時間內連續收到發送方多個包后可能只會發送一個回包里面記錄著當前最新的ACK號（即最后一個來包對應的ACK號）和最新的窗口大小，中間的ACK號會省略，這樣減少了包的數量提升了網絡通信的效率。
當服務端接收完客戶端某個HTTP消息的所有包并還原為http消息時，服務端的應用程序就對這個http請求進行處理，再響應數據封裝為http響應消息，經過協議棧封裝成一個個包返回給客戶端。這時服務端變成了發送方，而客戶端變成接收方。
1.接收http響應消息
當協議棧將http消息以多個包的形式發送完畢之后，工作流程回到應用程序（瀏覽器），應用程序會調用read()接收響應消息。工作流程再次轉移到協議棧。
響應消息到達客戶端主機后會先暫存在接收緩沖區，協議棧會嘗試從緩沖區獲取數據，如果緩沖區中沒有數據，則協議棧會暫停接收工作去做其他事情。直到消息到達才會將數據傳遞給應用程序，即把數據復制到應用程序指定的內存地址（數據量大的情況下不會一次性全傳遞給應用程序，而是會分多次傳遞）。
在這一步中，還略過了很多的細節，如協議棧會檢查收到的數據塊和TCP頭部，判斷是否有數據丟失；向服務器方更新窗口大小；將多塊數據按照序號拼接為原始的數據，等等。這些過程和客戶端發送發送方時的過程類似。
2.服務器斷開連接并刪除套接字
發送完數據的一方會主動發起斷開連接的操作。在Web通信中，服務器一方是最后發送數據的一方因此會主動關閉連接。
- 服務器會應用程序會調用Socket庫的close函數，工作流程轉到協議棧，協議棧會生成FIN比特位為1的TCP頭部，委托IP模塊發送給客戶端。此時服務器會進入關閉等待狀態并記錄到套接字中。
- 客戶端收到服務端關閉連接的包后，會進入關閉等待的狀態并記錄到套接字中。并且發送一個ACK包給服務端表示已經收到了關閉連接的請求。
- 客戶端不會馬上關閉連接，而是等應用程序將接收緩沖區中所有數據接收完畢（等待read()過程結束）。
- 當操作系統中接收緩沖區的數據接收完畢后，工作流程回到應用程序，應用程序調用Socket庫的close函數，工作流程轉到協議棧，客戶端的協議棧也會生成一個FIN比特位為1的TCP包通過IP模塊發送給服務端，告訴服務端可以關閉連接了。
- 服務端收到FIN比特位為1的TCP包后會回一個ACK包。客戶端接收到ACK包后會關閉連接（關閉連接的實質是刪除套接字），而服務端會不會馬上關閉連接（即不會馬上刪除套接字），而是進入到time-wait的等待狀態（將socket的狀態標記為time-wait），time-wait狀態結束后服務器才會真正關閉連接和刪除套接字。
以上過程就是大家熟知的“四次揮手”過程。
服務端不馬上不關閉連接而是進入time-wait狀態是為了防止誤操作。例如當客戶端是主動發起斷開連接的一端（假定客戶端的套接字是綁定54305這個端口），那么最后發送ACK包的會是客戶端，如果這個ACK包丟包，服務端等待一段時間沒有收到這個ACK包會重新發FIN包給客戶端。
假如客戶端沒有time-wait狀態而是在發送ACK包后直接關閉連接（即刪除套接字，釋放54305這個端口），那么客戶端可能會為其他連接生成一個新的套接字綁定54305這個端口。服務端重發的FIN包到達客戶端后，客戶端根據包頭部的接收方端口找到了新的套接字上就會導致該新套接字上的連接關閉。
time-wait狀態一般會持續幾分鐘。
附：使用UDP協議收發包
相比于TCP協議，使用UDP協議發送包無需建立連接（通信雙方服務交換控制消息），因此數據的收發相比于TCP減小了開銷和發送延遲更加高效。但是UDP協議沒有TCP協議的安全傳輸機制如確認應答機制，重傳和窗口等。
UDP頭部的控制信息：
UDP適用于以下場景：
a. 短數據
如果可以僅用一個包就將所有數據發送給對端，那么就無需建立連接以保存雙方的IP和端口以及其他信息到套接字中。而且數據少意味著傳輸的包數量少，丟包的可能性就會減小，也就無需像TCP那樣對包的送達狀態進行監控。如果丟包，協議棧收不到對方的回復是不會自行重發數據包的，應用程序可以自行組織重發數據（需要開發應用程序的人編寫重試邏輯）。
b.視頻和音頻數據
音頻和視頻數據必須在規定的時間內送達，一旦送達晚了，就會錯過播放時機，導致聲音和圖像卡頓。如果像TCP一樣通過接收確認應答來檢查錯誤并重發，重發的過程需要消耗一定的時間，因此重發的數據很可能已經錯過了播放的時機。
此外，音頻和視頻數據中缺少了某些包并不會產生嚴重的問題，只是會產生一些失真或者卡頓而已，一般都是可以接受的。使用UDP發送數據的效率會更高。
上面的操作都是圍繞著傳輸層TCP模塊介紹數據的收發。其實TCP報文還需要在網絡層的IP模塊中經過添加IP頭部和MAC頭部封裝成包再委托給網卡發送出去。
