** 這個實驗我沒有約到沒有問題的機子（連續三台機子都是壞的...）因此僅供參考
1、根據2.6中步驟3回答：TCP的連接和建立采用的是： 三次握手 方式，PCA是 主動打開方(C) ，PCB是 被動打開方(S) 。先點擊發送再點擊接收，會出現什么問題？為什么？
答：先點擊發送再點擊接受會導致連接失敗，而且如果沒有應用進程被動打開，那么主動打開的應用進程無法建立連接。
因為C/S模式下，若Server沒有啟動，那么Client就連接不上。服務器和客戶端的結合需要看TCP狀態機，必須存在被動打開方才能夠連接。
2、根據2.6中步驟5，結合預習報告，分析TCP連接的建立過程，根據TCP建立過程的三個報文，先填寫下表：
| 字段名稱 |
第一條報文 |
第二條報文 |
第三條報文 |
| 報文序號 |
3 |
4 |
5 |
| Sequence Number |
0 |
0 |
1 |
| Acknowledgement Number |
|
1 |
1 |
| Ack |
0 |
1 |
1 |
| Syn |
1 |
1 |
0 |
3、根據2.6中步驟6回答：
TCP連接建立時，其報文首部與其它TCP報文不同，有一個“Option”字段，它的作用是什么，值為多少？結合IEEE802.3協議規定的以太網最大幀長度分析此數據是怎樣得出的。
答：Option字段的值中包含一個最大報文段長度（Maximum segment size，MSS），取C/S兩方承載的MSS中取較小的值。MSS應用於數據傳送階段，在本實驗中得到的MSS值是1460 bytes。
MSS＝最大MTU長度－IP首部固定長度（20）－TCP首部固定長度（20）＝1500－20－20＝1460
4、根據2.6中步驟7：結合預習報告，分析TCP連接的釋放過程，選擇TCP連接撤消的四個報文，將報文信息填入下表。
| 字段名稱 |
第一條報文 |
第二條報文 |
第三條報文 |
第四條報文 |
| 報文序號 |
385 |
386 |
387 |
388 |
| Sequence Number |
355911 |
1 |
1 |
355912 |
| Acknowledgement Number |
1 |
355911 |
355912 |
2 |
| Ack |
1 |
1 |
1 |
1 |
| Fin |
1 |
0 |
1 |
0 |
5、根據2.6中步驟8：分析TCP數據傳送階段的前8個報文，將報文信息填入下表。
| 報文序號 |
報文種類 (發送/確認) |
序號字段 |
確認號字段 |
數據長度 |
被確認報文序號 |
窗口 |
| 6 |
發送 |
1 |
1 |
140 |
|
5840 |
| 7 |
確認 |
1 |
1401 |
0 |
13 |
8400 |
| 8 |
發送 |
1401 |
1 |
1460 |
14 |
5840 |
| 9 |
發送 |
2861 |
1 |
1460 |
|
5840 |
| 10 |
確認 |
1 |
2861 |
0 |
|
11680 |
| 11 |
確認 |
1 |
4321 |
0 |
16 |
14600 |
| 12 |
發送 |
4321 |
1 |
1460 |
17 |
5840 |
| 13 |
確認 |
1 |
5781 |
0 |
19 |
17520 |
請寫出TCP數據部分長度的計算公式。數據傳送階段第一個報文的序號字段值是否等於連接建立時第三個報文的序號？
答：TCP數據部分長度 = IP總長度 - IP首都長度 - TCP首部長度
數據傳送階段第一個報文的序號字段值 等於 連接建立時第三個報文的序號。
6. 根據3.6.1中“ 滑動窗口機制和窗口偵查機制分析”步驟6回答：
（1） 分析數據發送部分的前幾條報文，描述發送方發送窗口的變化，並解釋為什么？
答：發送方發送窗口的大小線性增大，每次遞增2920。
因為數據發送部分前幾條報文時處於慢啟動狀態，擁塞窗口cwnd指數規律增長，而滑動窗口rwnd線性增長。一般而言rwnd < cwnd，而且發送窗口=min[cwnd, rwnd]，因此發送窗口的大小也隨着rwnd線性增長。
（2） 指出從哪個序號的報文能夠看出接收端開始休眠，並解釋理由。
如果接收緩存大於65535，在接收窗口值持續減少前接收端已開始休眠。
如果接收緩存小於等於65535，在接收窗口值持續減少時接收端開始休眠。
因為其后通告的接收窗口越來越小，（左邊沿在不斷向右移動，而右邊沿不再移動），接收方在窗口范圍外的可用緩存已被使用完，表明接收方在窗口范圍外的可用緩存被已確認的數據占據着，應用程序進程沒有再從緩存中讀取這些已確認的數據，即表明其已開始休眠
（3）分析文件send2-組座號-tcpsndwnddata.txt，選中三次握手連接建立后的前4條報文記錄（3條DATA報文、1條ACK報文，序號為4、5、6、7），記下發送方發送窗口的相關值（rcv_wnd , snd_wnd_left , snd_wnd_point , snd_wnd_left+cwnd , snd_wnd_left+rcv_wnd , (snd_wnd_point- left)）。按下表分析計算接收方（及發送方）的窗口的相關值。
5號報文（sender----data---->receiver）
|
|
rcv_wnd |
snd_wnd_left |
snd_wnd_pointer |
snd_wnd_left+cwnd和 snd_wnd_left+rcv_wnd |
snd_wnd_point- left |
| 發送方發出報文 |
5840 |
2379935191 |
2379938051 |
2379939571 |
2860 |
| 發送窗口右邊沿 |
2379941031 |
||||
|
|
通告的接收窗口 |
接收窗口左邊沿 |
接收窗口指針 |
接收窗口右邊沿 |
在接收緩存中的數據量（即未確認的數據） |
| 接收方接到DATA前 |
2 |
2379935191 |
2379936591 |
2379935191 |
1400 |
| 接收方接到DATA后 |
3 |
2379935191 |
2379938051 |
2379935191 |
2860 |
6號報文（sender----data---->receiver）
|
|
rcv_wnd |
snd_wnd_left |
snd_wnd_pointer |
snd_wnd_left+cwnd和 snd_wnd_left+rcv_wnd |
snd_wnd_point- left |
| 發送方發出報文 |
5840 |
2379935191 |
2379939511 |
2379939571 |
4320 |
| 發送窗口右邊沿 |
2379941031 |
||||
|
|
通告的接收窗口 |
接收窗口左邊沿 |
接收窗口指針 |
接收窗口右邊沿 |
在接收緩存中的數據量（即未確認的數據） |
| 接收方接到DATA前 |
3 |
2379935191 |
2379938051 |
2379935191 |
2860 |
| 接收方接到DATA后 |
3 |
2379935191 |
2379939511 |
2379935191 |
4320 |
7號報文（receiver ----ack----> sender）
|
|
通告的接收窗口 |
接收窗口左邊沿 |
接收窗口指針 |
接收窗口右邊沿 |
在接收緩存中的數據量（即未確認的數據） |
| 接收方發出ACK |
4 |
2379935191 |
2379935191 |
2379941031 |
0 |
|
|
rcv_wnd |
snd_wnd_left |
snd_wnd_pointer |
snd_wnd_left+cwnd和 snd_wnd_left+rcv_wnd |
snd_wnd_point- left |
| 發送方接到ACK后 |
8400 |
2379936591 |
2379939511 |
2379942431 2379944991 |
2920 |
| 發送窗口右邊沿 |
2379944991 |
||||
| 發送方接到ACK前 |
5840 |
2379935191 |
2379939511 |
2379939571 |
4320 |
| 發送窗口右邊沿 |
2379941031 |
||||
（1） 根據文件send2-組座號-tcpsndwnddata.txt中發送方的發送窗口相關值進行分析，接收方開始休眠后，描述接收窗口的變化，指出窗口收縮、窗口合攏、窗口張開對應的開始報文序號，並記下send2-組座號-tcpsndwnddata.txt文件中的對應報文的數值記錄（pkt_seqno，pkt_type，..，……）。
窗口收縮：右邊沿向左移動，RFC強烈不建議使用，一般不發生。
窗口合攏：窗口的左邊沿向右邊沿靠近，發生在接收窗口持續減小期間：
166 snd_data
167 rcv_ack
168 snd_data
169 snd_data
170 snd_data
171 snd_data
172 snd_data
173 rcv_ack
174 snd_data
175 rcv_ack
窗口張開：當窗口的右邊沿向右移動時將允許發送更多的數據，一般發生在休眠結束后通告大窗口時
180 rcv_ack
181 snd_data
182 rcv_ack
183 snd_data
184 rcv_ack
7. 根據3.6.1中“ 滑動窗口機制和窗口偵查機制分析”步驟7回答：
寫出窗口偵查開始的報文序號，窗口偵查報文數據長度、窗口偵查報文發送的時間規律。
窗口偵查報文指的是Keep-Alive報文，長度為5840
每相鄰兩條窗口偵查報文Keep-Alive報文 時間差組成的數據序列的規律：成倍增加規律
13、根據4.6中步驟7：
（1）分析UDP報文結構：選中第一個UDP報文，將UDP協議樹中各字段名、字段長度、字段值、字段表達信息，填入下表。並繪制UDP報文結構，詳細繪制UDP協議樹字段。
| 字段名 |
字段長度 |
字段值 |
字段表達信息 |
| Source Port |
2 bytes |
murray(1123) |
源端口：1123 |
| Destination |
2 bytes |
1030 |
目的端口：1030 |
| Length |
2 bytes |
13 |
報文長度：13 |
| Checksum |
2 bytes |
0x301d |
校檢碼：0x301d |
（2）UDP報文結構與TCP報文結構有什么區別？
答：UDP報文僅有源端口、目的端口、報文長度、校檢碼和數據組成。
TCP除此之外還有seq、ack、偏移字段等字段，用於保證傳輸的可靠性。
（3）在步驟5交換機S1和S2之間的網線拔掉期間，PCA向PCB發送的UDP消息，在步驟6交換機S1和S2之間的網線重新插上之后，PCB是否還能收到？請解釋為什么會出現這種現象？
答：PCA會向PCB發送i’m fine, and you?
在步驟6交換機S1和S2之間的網線重新插上之后，PCB不能收到。因為UDP是不可靠傳輸協議，因此因為拔掉網線而發送失敗后報文就丟失了。
（4）綜合分析TCP協議和UDP協議的不同之處。
| UDP |
TCP |
| 無連接 |
面向連接 |
| 不可靠傳輸，無流量控制和擁塞控制 |
可靠傳輸，使用流量控制和擁塞控制 |
| 支持一對一、一對多、多對一、多對多交互通信 |
只支持一對一通信 |
| 面向報文 |
面向字節流 |
| 首部8字節 |
首部20~60字節 |
| 適用於實時應用 |
適用於要求可靠傳輸的應用。 |