????????在因特網(wǎng)協(xié)議族（Internet Protocol Suite）中，TCP 層是位于 IP 層之上，應(yīng)用層之下的中間層。不同主機(jī)的應(yīng)用層之間經(jīng)常需要可靠的、像管道一樣的連接，但是 IP 層不提供這樣的流機(jī)制，而是提供不可靠的包交換。TCP 和 UDP 處在同一層——傳輸層，但是它們有很多的不同。TCP 是 TCP/IP 系列協(xié)議中最復(fù)雜的部分，它具有以下特點(diǎn)：

• TCP 提供可靠的數(shù)據(jù)傳輸服務(wù)，TCP 是面向連接的。應(yīng)用程序在使用 TCP 通信之前，先要建立連接，這是一個(gè)類似“打電話”的過(guò)程，通信結(jié)束后還要“掛電話”。
• TCP 連接是點(diǎn)對(duì)點(diǎn)的，一條 TCP 連接只能連接兩個(gè)端點(diǎn)。
• TCP 提供可靠傳輸，無(wú)差錯(cuò)、不丟失、不重復(fù)、按順序。
• TCP 提供全雙工通信，允許通信雙方任何時(shí)候都能發(fā)送數(shù)據(jù)，因?yàn)?TCP 連接的兩端都設(shè)有發(fā)送緩存和接收緩存。
• TCP 面向字節(jié)流。TCP 并不知道所傳輸?shù)臄?shù)據(jù)的含義，僅把數(shù)據(jù)看作一連串的字節(jié)序列，它也不保證接收方收到的數(shù)據(jù)塊和發(fā)送方發(fā)出的數(shù)據(jù)塊具有大小對(duì)應(yīng)關(guān)系。

1 TCP 協(xié)議

1.1 TCP 報(bào)文段結(jié)構(gòu)

????????TCP 是面向字節(jié)流的，而 TCP 傳輸數(shù)據(jù)的單元是 報(bào)文段 。一個(gè) TCP 報(bào)文段可分為兩部分：報(bào)頭和數(shù)據(jù)部分。數(shù)據(jù)部分是上層應(yīng)用交付的數(shù)據(jù)，而報(bào)頭則是 TCP 功能的關(guān)鍵。

????????TCP 報(bào)文段的報(bào)頭有前 20 字節(jié)的固定部分，后面 4n 字節(jié)是根據(jù)需要而添加的字段。如圖則是 TCP 報(bào)文段結(jié)構(gòu)：

字段解析

• 源端口、目的端口：各占 2 字節(jié)，端口是運(yùn)輸層與應(yīng)用層的服務(wù)接口，運(yùn)輸層的復(fù)用和分用功能都要通過(guò)端口才能實(shí)現(xiàn)。
• 序號(hào)：占 4 字節(jié)序，序號(hào)范圍 $[0，2^{3}2?1]$，序號(hào)增加到 $2^{3}2?1$ 后，下個(gè)序號(hào)又回到 0。TCP 是面向字節(jié)流的，通過(guò) TCP 傳送的字節(jié)流中的每個(gè)字節(jié)都按順序編號(hào)，而報(bào)頭中的序號(hào)字段值則指的是本報(bào)文段數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)。
• 確認(rèn)號(hào)：占 4 字節(jié)，是期望收到對(duì)方的下一個(gè)報(bào)文段的數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)。
• 數(shù)據(jù)偏移：占 4 位，它指出 TCP 報(bào)文段的數(shù)據(jù)起始處距離 TCP 報(bào)文段的起始處有多遠(yuǎn)，的單位是 32 位字（以 4 字節(jié)為計(jì)算單位）。
• 保留：占 6 位，保留為今后使用，但目前應(yīng)置為 0。
• 接收窗口：占 2 字節(jié)，用于流量控制，窗口值是指發(fā)送者自己的接收窗口大小，因?yàn)榻邮站彺娴目臻g有限，單位為字節(jié)。
• 檢驗(yàn)和：占 2 字節(jié)。檢驗(yàn)和字段檢驗(yàn)的范圍包括首部和數(shù)據(jù)這兩部分。在計(jì)算檢驗(yàn)和時(shí)，要在 TCP 報(bào)文段的前面加上 12 字節(jié)的偽首部。
• 緊急指針：2 字節(jié)。當(dāng) URG=1 時(shí)才有效，指出本報(bào)文段緊急數(shù)據(jù)的字節(jié)數(shù)。
• 選項(xiàng)：長(zhǎng)度可變。TCP 最初只規(guī)定了最大報(bào)文段長(zhǎng)度 MSS，表示緩存所能接收的報(bào)文段的數(shù)據(jù)字段的最大長(zhǎng)度是 MSS 個(gè)字節(jié)。

標(biāo)志字段

• 緊急 URG：當(dāng) URG = 1 時(shí)，表明緊急指針字段有效。它告訴系統(tǒng)此報(bào)文段中有緊急數(shù)據(jù)，應(yīng)盡快傳送(相當(dāng)于高優(yōu)先級(jí)的數(shù)據(jù))。
• 確認(rèn) ACK：只有當(dāng) ACK = 1 時(shí)確認(rèn)號(hào)字段有效，當(dāng) ACK = 0 時(shí)確認(rèn)號(hào)無(wú)效。
• 推送 PSH(PuSH)：接收 TCP 收到 PSH = 1 的報(bào)文段，就盡快地交付接收應(yīng)用進(jìn)程，不再等到整個(gè)緩存都填滿了后再向上交付。
• 復(fù)位 RST(ReSeT)：當(dāng) RST = 1 時(shí)，表明 TCP 連接中出現(xiàn)嚴(yán)重差錯(cuò)（如由于主機(jī)崩潰或其他原因）必須釋放連接，然后再重新建立運(yùn)輸連接。
• 同步 SYN：同步 SYN = 1 表示這是一個(gè)連接請(qǐng)求或連接接受報(bào)文。
• 終止 FIN(FINish)：用來(lái)釋放一個(gè)連接。FIN = 1 表明此報(bào)文段的發(fā)送端的數(shù)據(jù)已發(fā)送完畢，并要求釋放運(yùn)輸連接。

捕獲從計(jì)算機(jī)到遠(yuǎn)程服務(wù)器的批量 TCP 傳輸

????????我們需要使用 Wireshark 來(lái)獲取文件從計(jì)算機(jī)到遠(yuǎn)程服務(wù)器的 TCP 傳輸?shù)臄?shù)據(jù)包內(nèi)容。首先訪問(wèn)一個(gè)網(wǎng)頁(yè)，在網(wǎng)頁(yè)上輸入計(jì)算機(jī)上存儲(chǔ)的文件名（包含 Alice in Wonderland 的 ASCII 文本），然后使用 HTTP POST 方法將文件傳輸?shù)?Web 服務(wù)器（不使用 GET 方法的原因是我們希望大量數(shù)據(jù)從您的計(jì)算機(jī)傳輸?shù)搅硪慌_(tái)計(jì)算機(jī)）。而在此同時(shí)，要運(yùn)行 Wireshark 以獲取從您的計(jì)算機(jī)發(fā)送和接收的 TCP 區(qū)段的內(nèi)容。

1. 打開(kāi)瀏覽器，在 http://gaia.cs.umass.edu/wireshark-labs/alice.txt 查看 Alice in Wonderland 的 ASCII 檔案文件，將其保存；
2. 瀏覽 http://gaia.cs.umass.edu/wireshark-labs/TCP-wireshark-file1.html，能得到以下內(nèi)容；

3. 在此表單的"Browse…"按鈕在計(jì)算機(jī)上輸入包含 Alice in Wonderland 的文件名（完整路徑名）。這時(shí)不用按下"Upload alice.txt file"按鈕；
4. 啟動(dòng) Wireshark ，開(kāi)始捕獲，在 Wireshark 數(shù)據(jù)包捕獲選項(xiàng)視窗上按 OK；
5. 返回瀏覽器，按"Upload alice.txt file"將按鈕文件上傳到 gaia.cs.umass.edu 服務(wù)器。文件上傳后，瀏覽器窗口顯示一條簡(jiǎn)短的祝賀消息；
6. 停止 Wireshark 數(shù)據(jù)包捕獲，Wireshark 顯示內(nèi)容。

????????抓包軟件中的 TCP 分析

????????展開(kāi) Flags 的頭，得到的信息如下：

????????由此我們可以得到具體的 TCP 報(bào)文信息。

1.3 連接的建立與釋放

1.3.1 建立連接

????????TCP 是面向連接的，在傳輸 TCP 報(bào)文段之前先要?jiǎng)?chuàng)建連接，發(fā)起連接的一方被稱為客戶端，而響應(yīng)連接請(qǐng)求的一方被稱為服務(wù)端，而這個(gè)創(chuàng)建連接的過(guò)程被稱為三次握手：

• 第一次握手：客戶端將標(biāo)志位 SYN 置為 1 ，隨機(jī)產(chǎn)生一個(gè)值SEQ = X，并將該數(shù)據(jù)包發(fā)送給服務(wù)器，客戶機(jī)進(jìn)入 SYN_SENT(同步已發(fā)送) 狀態(tài)，等待服務(wù)器確認(rèn)；
• 第二次握手：服務(wù)端收到請(qǐng)求報(bào)文段后，向客戶端發(fā)送確認(rèn)報(bào)文段。確認(rèn)報(bào)文段的首部中 SYN=1，ACK=1，確認(rèn)號(hào)是 ack=x+1，同時(shí)為自己選擇一個(gè)初始序號(hào) seq=y。服務(wù)端進(jìn)入 SYN-RCVD（同步收到）狀態(tài)。
• 第三次握手：客戶端收到服務(wù)端的確認(rèn)報(bào)文段后，還要給服務(wù)端發(fā)送一個(gè)確認(rèn)報(bào)文段。這個(gè)報(bào)文段中 ACK=1，確認(rèn)號(hào) ack=y+1，而自己的序號(hào) seq=x+1。這個(gè)報(bào)文段已經(jīng)可以攜帶數(shù)據(jù)，如果不攜帶數(shù)據(jù)則不消耗序號(hào)，則下一個(gè)報(bào)文段序號(hào)仍為 seq=x+1。如果正確則連接建立成功，客戶端和服務(wù)器進(jìn)入 ESTABLISHED 狀態(tài)。

????????握手過(guò)程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后，客戶端與服務(wù)器才正式開(kāi)始傳送數(shù)據(jù)。理想狀態(tài)下，TCP 連接一旦建立，在通信雙方中的任何一方主動(dòng)關(guān)閉連接之前，TCP 連接都將被一直保持下去。

1.3.2 釋放連接

????????當(dāng)傳輸數(shù)據(jù)結(jié)束后，通信雙方都可以釋放連接，這個(gè)釋放連接過(guò)程被稱為釋放連接:

• 第一次揮手：此時(shí) TCP 連接兩端都還處于 ESTABLISHED 狀態(tài)，客戶端停止發(fā)送數(shù)據(jù)，并發(fā)出一個(gè) FIN 報(bào)文段。首部 FIN=1，序號(hào) seq=u（u 等于客戶端傳輸數(shù)據(jù)最后一字節(jié)的序號(hào)加 1）。客戶端進(jìn)入 FIN-WAIT-1（終止等待 1）狀態(tài)。
• 第二次揮手：服務(wù)端回復(fù)確認(rèn)報(bào)文段，確認(rèn)號(hào) ack=u+1，序號(hào) seq=v（v 等于服務(wù)端傳輸數(shù)據(jù)最后一字節(jié)的序號(hào)加 1），服務(wù)端進(jìn)入 CLOSE-WAIT（關(guān)閉等待）狀態(tài)。現(xiàn)在 TCP 連接處于半開(kāi)半閉狀態(tài)，服務(wù)端如果繼續(xù)發(fā)送數(shù)據(jù)，客戶端依然接收。
• 第三次揮手：客戶端收到確認(rèn)報(bào)文，進(jìn)入 FIN-WAIT-2 狀態(tài)，服務(wù)端發(fā)送完數(shù)據(jù)后，發(fā)出 FIN 報(bào)文段，FIN=1，確認(rèn)號(hào) ack=u+1，然后進(jìn)入 LAST-ACK(最后確認(rèn))狀態(tài)。
• 第四次揮手：客戶端回復(fù)確認(rèn)報(bào)文段，ACK=1，確認(rèn)號(hào) ack=w+1（w 為半開(kāi)半閉狀態(tài)時(shí)，收到的最后一個(gè)字節(jié)數(shù)據(jù)的編號(hào)） ，序號(hào) seq=u+1，然后進(jìn)入 TIME-WAIT（時(shí)間等待）狀態(tài)。

????????注意此時(shí)連接還沒(méi)有釋放，需要時(shí)間等待狀態(tài)結(jié)束后（4 分鐘）連接兩端才會(huì) CLOSED。設(shè)置時(shí)間等待是因?yàn)椋锌赡茏詈笠粋€(gè)確認(rèn)報(bào)文丟失而需要重傳。

1.3.3 TCP 的三次握手在 Wireshark 中分析

????????打開(kāi) Wireshark 抓包軟件，開(kāi)始抓包，打開(kāi)瀏覽器輸入 www.baidu.com，進(jìn)入網(wǎng)頁(yè)。停止抓包，在過(guò)濾窗口輸入TCP。

????????由下圖可知，先進(jìn)行了 TCP 三次傳輸，然后才開(kāi)始 HTTP 傳輸。

????????第一次握手：客戶端發(fā)送 SYN 報(bào)文到服務(wù)器；

????????第二次握手：服務(wù)器接收到客戶端的 SYN 報(bào)文，回復(fù) SYN + ACK 報(bào)文；

????????第三次握手：客戶端接收到服務(wù)端的 SYN + ACK 報(bào)文后，回復(fù) ACK 報(bào)文。

1.4 TCP 可靠傳輸?shù)膶?shí)現(xiàn)

• TCP 報(bào)文段的長(zhǎng)度可變，根據(jù)收發(fā)雙方的緩存狀態(tài)、網(wǎng)絡(luò)狀態(tài)而調(diào)整。
• 當(dāng) TCP 收到發(fā)自 TCP 連接另一端的數(shù)據(jù)，它將發(fā)送一個(gè)確認(rèn)。
• 當(dāng) TCP 發(fā)出一個(gè)報(bào)文段后，它啟動(dòng)一個(gè)定時(shí)器，等待目的端確認(rèn)收到這個(gè)報(bào)文段，如果不能及時(shí)收到一個(gè)確認(rèn)，將重發(fā)這個(gè)報(bào)文段。這就是稍后介紹的超時(shí)重傳。
• TCP 將保持它首部和數(shù)據(jù)的檢驗(yàn)和。如果通過(guò)檢驗(yàn)和發(fā)現(xiàn)報(bào)文段有差錯(cuò)，這個(gè)報(bào)文段將被丟棄，等待超時(shí)重傳。
• TCP 將數(shù)據(jù)按字節(jié)排序，報(bào)文段中有序號(hào)，以確保順序的正確性。
• TCP 還能提供流量控制。TCP 連接的每一方都有收發(fā)緩存。TCP 的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)。這將防止較快主機(jī)致使較慢主機(jī)的緩沖區(qū)溢出。

????????可見(jiàn)超時(shí)重發(fā)機(jī)制是 TCP 可靠性的關(guān)鍵，只要沒(méi)有得到確認(rèn)報(bào)文段，就重新發(fā)送數(shù)據(jù)報(bào)，直到收到對(duì)方的確認(rèn)為止。

1.5 超時(shí)重傳

????????TCP 規(guī)定，接收者收到數(shù)據(jù)報(bào)文段后，需回復(fù)一個(gè)確認(rèn)報(bào)文段，以告知發(fā)送者數(shù)據(jù)已經(jīng)收到。而發(fā)送者如果一段時(shí)間內(nèi)（超時(shí)計(jì)時(shí)器）沒(méi)有收到確認(rèn)報(bào)文段，便重復(fù)發(fā)送。

????????為了實(shí)現(xiàn)超時(shí)間重傳，需要注意：

• 發(fā)送者發(fā)送一個(gè)報(bào)文段后，暫時(shí)保存該報(bào)文段的副本，為發(fā)生超時(shí)重傳時(shí)使用，收到確認(rèn)報(bào)文后刪除該報(bào)文段。
• 確認(rèn)報(bào)文段也需要序號(hào)，才能明確是發(fā)出去的哪個(gè)數(shù)據(jù)報(bào)得到了確認(rèn)。
• 超時(shí)計(jì)時(shí)器比傳輸往返時(shí)間略長(zhǎng)，但具體值是不確定的，根據(jù)網(wǎng)絡(luò)情況而變

1.6 連續(xù) ARQ 協(xié)議

????????在實(shí)際應(yīng)用中的確不是這樣的，真實(shí)情況是，采用了流水線傳輸：發(fā)送方可以連續(xù)發(fā)送多個(gè)報(bào)文段(連續(xù)發(fā)送的數(shù)據(jù)長(zhǎng)度叫做窗口)，而不必每發(fā)完一段就停下來(lái)等待確認(rèn)。

????????實(shí)際應(yīng)用中，接收方也不必對(duì)收到的每個(gè)報(bào)文都做回復(fù)，而是采用累積確認(rèn)方式：接收者收到多個(gè)連續(xù)的報(bào)文段后，只回復(fù)確認(rèn)最后一個(gè)報(bào)文段，表示在這之前的數(shù)據(jù)都已收到。

????????這樣，傳輸效率得到了很大的提升

1.7 流量控制和擁塞控制

????????由于接收方緩存的限制，發(fā)送窗口不能大于接收方接收窗口。在報(bào)文段首部有一個(gè)字段就叫做窗口(rwnd)，這便是用于告訴對(duì)方自己的接收窗口，可見(jiàn)窗口的大小是可以變化的。

????????那么窗口的大小是如何變化的呢？TCP 對(duì)于擁塞的控制總結(jié)為“慢啟動(dòng)、加性增、乘性減”，如圖所示：

• 慢啟動(dòng) ：初始的窗口值很小，但是按指數(shù)規(guī)律漸漸增長(zhǎng)，直到達(dá)到慢開(kāi)始門(mén)限(ssthresh)。
• 加性增 ：窗口值達(dá)到慢開(kāi)始門(mén)限后，每發(fā)送一個(gè)報(bào)文段，窗口值增加一個(gè)單位量。
• 乘性減 ：無(wú)論什么階段，只要出現(xiàn)超時(shí)，則把窗口值減小一半。

2 實(shí)驗(yàn)分析

????????本篇使用下載好的包進(jìn)行分析，在過(guò)濾器指定窗口中輸入 “tcp” 過(guò)濾 Wireshark 視窗中顯示的數(shù)據(jù)包：

????????可以應(yīng)該看到的是計(jì)算機(jī)和 gaia.cs.umass.edu 之間的一系列 TCP 和 HTTP 訊息，首先是看到包含 SYN 訊息的初始三次握手

????????接下來(lái)有 HTTP POST 訊息。

????????在 Wireshark 顯示的 Info 列中有不少“[重新組裝的 PDU 的 TCP 段]”，以指示此 TCP 區(qū)段包含屬于上層協(xié)議訊息的數(shù)據(jù)（這里是 HTTP）。

????????還有 gaia.cs.umass.edu 返回到您的計(jì)算機(jī)的 TCP ACK 區(qū)段。

????????回答以下問(wèn)題：

1. 將文件傳輸?shù)?gaia.cs.umass.edu 的客戶端計(jì)算機(jī)（源）使用的 IP 地址和 TCP 端口號(hào)是什么？
   答：IP 地址：192.168.1.102；TCP 端口號(hào)：1161

2. gaia.cs.umass.edu 的 IP 地址是什么？ 在哪個(gè)端口號(hào)上發(fā)送和接收此連接的 TCP 區(qū)段？
   答：IP 地址：128.119.245.12；接收連接的端口號(hào)：80

????????現(xiàn)在我們關(guān)注 TCP 而不是 HTTP，因此更改 Wireshark 的“捕獲數(shù)據(jù)包列表”視窗，以便顯示有關(guān)包含 HTTP 訊息的 TCP 區(qū)段的信息。要讓 Wireshark 執(zhí)行此操作，選擇 Analyze-> Enabled Protocols。

????????然后取消勾選 HTTP 框，并選擇確定。

????????這些是計(jì)算機(jī)和 gaia.cs.umass.edu 之間發(fā)送的一系列 TCP 區(qū)段。

3. 用于在客戶端計(jì)算機(jī)和 gaia.cs.umass.edu 之間啟動(dòng) TCP 連接的 TCP SYN 區(qū)段的序列號(hào)是什么？將區(qū)段標(biāo)識(shí)為 SYN 區(qū)段的區(qū)段有什么功能？
   答：序列號(hào)為 0，功能是開(kāi)始三次握手，主機(jī)發(fā)送 SYN 請(qǐng)求服務(wù)器建立連接，這是三次握手的第一步。

4. gaia.cs.umass.edu 發(fā)送給客戶端計(jì)算機(jī)以回復(fù) SYN 的 SYNACK 區(qū)段的序列號(hào)是多少？
   答：序列號(hào)為 0。

5. SYNACK 區(qū)段中的 Acknowledgment 欄位的值是多少？
   答：Acknowledgment 欄位的值是 1。

Gaia.cs.umass.edu 是如何確定此 Acknowledgment 的數(shù)值的？在將區(qū)段標(biāo)識(shí)為 SYNACK 區(qū)段的區(qū)段在連線中有什么功能？
Ack 字段用于表示確認(rèn)字段中的值是有效的，功能是說(shuō)明服務(wù)器成功接收了我們發(fā)出的連接請(qǐng)求，并發(fā)送 SYN-ACK 確認(rèn)報(bào)文。

6. 包含 HTTP POST 命令的 TCP 區(qū)段的序列號(hào)是多少？
   答：序列號(hào)為 1，其中 PSH 表示有數(shù)據(jù)傳輸。

7. 將包含 HTTP POST 的 TCP 區(qū)段視為 TCP 連接中的第一個(gè)區(qū)段。前六個(gè) TCP 區(qū)段的長(zhǎng)度是多少？在這個(gè) TCP 連線中前 6 個(gè) TCP 區(qū)段的序列號(hào)是什么（包括包含 HTTP POST 的段）？每區(qū)段發(fā)送的時(shí)間是什么時(shí)候？收到的每個(gè)區(qū)段的 ACK 是什么時(shí)候？鑒于發(fā)送每個(gè) TCP 區(qū)段的時(shí)間與收到確認(rèn)的時(shí)間之間的差異，六個(gè)區(qū)段中每個(gè)區(qū)段的 RTT 值是多少？收到每個(gè) ACK 后，EstimatedRTT 值是什么？假設(shè)第一個(gè) EstimatedRTT 的值等于第一個(gè)區(qū)段的測(cè)量 RTT。

????????EstimatedRTT 運(yùn)算公式

EstimatedRTT = (1 - a) × EstimatedRTT + a × SampleRTT

????????其中 a 使用推薦值 0.125

• 區(qū)段一：
  

• 長(zhǎng)度：565

• 序列號(hào)：1

• 發(fā)送時(shí)間：2004 年 8 月 21 日 21：44:20.596858000

RTT:0.027460000 seconds
EstimatedRTT = RTT = 0.027460000 seconds
區(qū)段二：

長(zhǎng)度：1460
序列號(hào)：566
發(fā)送時(shí)間：2004 年 8 月 21 日 21：44:20.612118000

• RTT:0.035557000 seconds
• EstimatedRTT = 0.875 × 0.027460000 + 0.125 × 0.035557000 = 0.028472125 seconds
• 區(qū)段三：

• 長(zhǎng)度：1460
• 序列號(hào)：2026
• 發(fā)送時(shí)間：2004 年 8 月 21 日 21：44:20.624407000

• RTT:0.070059000 seconds
• EstimatedRTT = 0.875 × 0.028472125 + 0.125 × 0.070059000 = 0.033670484 seconds
• 區(qū)段四：

• 長(zhǎng)度：1460
• 序列號(hào)：3486
• 發(fā)送時(shí)間：2004 年 8 月 21 日 21：44:20.625071000

• RTT:0.114428000 seconds
• EstimatedRTT = 0.875 × 0.033670484 + 0.125 × 0.114428000 = 0.043765173 seconds
• 區(qū)段五：

• 長(zhǎng)度：1460
• 序列號(hào)：4946
• 發(fā)送時(shí)間：2004 年 8 月 21 日 21：44:20.647786000

• RTT:0.139894000 seconds
• EstimatedRTT = 0.875 × 0.043765173 + 0.125 × 0.139894000 = 0.055781277 seconds
• 區(qū)段六：

• 長(zhǎng)度：1460
• 序列號(hào)：6406
• 發(fā)送時(shí)間：2004 年 8 月 21 日 21：44:20.648538000

• RTT:0.189645000 seconds
• EstimatedRTT = 0.875 × 0.055781277 + 0.125 × 0.189645000 = 0.072514242 seconds

7. 對(duì)于整個(gè)跟蹤包，收到的最小可用緩沖區(qū)空間量是多少？缺少接收器緩沖區(qū)空間是否會(huì)限制發(fā)送方傳送 TCP 區(qū)段？
   答：對(duì)于服務(wù)器而言，收到的最小可用緩沖區(qū)空間量為 6780。

????????對(duì)于主機(jī)而言，收到的最小可用緩沖區(qū)空間量為 5840。

????????缺少接收器緩沖區(qū)空間會(huì)限制發(fā)送方傳送 TCP 區(qū)段，這是因?yàn)?TCP 的流量控制服務(wù)，能夠消除發(fā)送方使接收方緩存溢出的可能性，使得發(fā)送方的發(fā)送速率與接收方應(yīng)用程序的讀取速率相匹配。實(shí)現(xiàn)的方式是滑動(dòng)窗口協(xié)議，具體可參考后文附帶的資料。

8. 在跟蹤文件中是否有重傳的區(qū)段？

????????檢查數(shù)據(jù)包的時(shí)間序列：

9. 接收器通常在 ACK 中確認(rèn)多少數(shù)據(jù)？是否可以識(shí)別接收方每隔一個(gè)接收到的區(qū)段才發(fā)送確認(rèn)的情況？
   答：接收器通常在 ACK 中確認(rèn)序列號(hào)，可以確認(rèn)，根據(jù) ACK 序列號(hào)的順序來(lái)推測(cè)。

10. TCP 連接的吞吐量（每單位時(shí)間傳輸?shù)?節(jié)數(shù)）是多少？如何計(jì)算這個(gè)值？
    答：平均吞吐量 = 傳輸數(shù)據(jù)的比特?cái)?shù) F ÷ 接收方接收所有數(shù)據(jù)所用時(shí)間 T首先看看傳輸數(shù)據(jù)的比特?cái)?shù) F = 164090 bytes

????????再看看接收方接收所有數(shù)據(jù)所用時(shí)間 T = 5.297341000 seconds

????????現(xiàn)在檢查從客戶端服務(wù)器的每單位時(shí)間發(fā)送的數(shù)據(jù)量，從 Wireshark 窗口中的原始數(shù)據(jù)計(jì)算這些數(shù)值。

????????每個(gè)點(diǎn)代表一個(gè)發(fā)送的 TCP 區(qū)段，繪制區(qū)段的序列號(hào)與發(fā)送的時(shí)間，堆疊在一起的一組點(diǎn)表示發(fā)送方背靠背發(fā)送的一系列數(shù)據(jù)包。使用時(shí)序圖（Stevens）查看從客戶端發(fā)送到 gaia.cs.umass.edu 服務(wù)器的區(qū)段的序列號(hào)與時(shí)間關(guān)系圖。您能否確定 TCP 的慢啟動(dòng)階段的開(kāi)始和結(jié)束位置，以及擁塞避免接管的位置？

????????慢啟動(dòng)的原理是：連接開(kāi)始時(shí)，發(fā)送速率呈指數(shù)型增長(zhǎng)。因此 TCP 開(kāi)始發(fā)送的速率很慢，但是慢啟動(dòng)階段增長(zhǎng)很快

????????如圖所示，慢啟動(dòng)階段的開(kāi)始肯定是在第一個(gè) TCP 區(qū)段發(fā)出去的時(shí)候，也就是分組 5 發(fā)送的時(shí)候。

????????結(jié)束位置是什么時(shí)候？觀察到這樣的指數(shù)型增長(zhǎng)的速率在分組 23 處卡殼了，說(shuō)明這個(gè)時(shí)候發(fā)生了擁塞，進(jìn)入擁塞避免階段。

????????這個(gè)區(qū)域就是擁塞避免區(qū)段。

2. 評(píng)論測(cè)量數(shù)據(jù)與我們?cè)谖谋局醒芯康?TCP 的理想化行為的不同之處。

????????慢啟動(dòng)是 TCP 在擁塞控制方面做的努力之一，但是對(duì)于一些數(shù)據(jù)量較小的小文件，在網(wǎng)絡(luò)暢通的情況下發(fā)送非?？欤踔量赡茉诼龁?dòng)結(jié)束之前就已經(jīng)發(fā)送完畢。這個(gè)問(wèn)題要怎么理解呢？例如我需要發(fā)送一個(gè) 5 單位大小的文件，假定一個(gè)窗口在一個(gè)單位時(shí)間內(nèi)可以發(fā)送一個(gè)單位大小的數(shù)據(jù)報(bào)。如果是初始窗口為 1 個(gè)的慢啟動(dòng)，窗口按照指數(shù)型增長(zhǎng)，就需要 3 個(gè)單位時(shí)間才能發(fā)送完畢。而如果一開(kāi)始就擁有大于 5 個(gè)的窗口，則 1 個(gè)單位時(shí)間就可以發(fā)送完畢，這個(gè)時(shí)候慢啟動(dòng)反而來(lái)制約了文件的快速發(fā)送，從而影響了效率。

????????由此可見(jiàn)慢啟動(dòng)并不是永遠(yuǎn)都是高效的，在一些情況下效率不會(huì)達(dá)到最好。這種情況不可否認(rèn)，不過(guò)慢啟動(dòng)在擁塞控制方面的貢獻(xiàn)，在總體上仍然是一個(gè)很好的手法！文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-452375.html

參考

• 傳輸層：TCP協(xié)議：https://www.lanqiao.cn/courses/98/learning/?id=556&compatibility=false
• TCP協(xié)議與Wireshark實(shí)驗(yàn)：https://www.cnblogs.com/linfangnan/p/12809541.html
• TCP 協(xié)議分析：https://www.educoder.net/shixuns/5o8ne4m6/challenges

到了這里，關(guān)于《計(jì)算機(jī)網(wǎng)絡(luò)—自頂向下方法》 Wireshark實(shí)驗(yàn)（四）：TCP 協(xié)議分析的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！