TCP 封包分析

我們利用Wireshark 軟體分析 Server 端的封包，並且擷取 Server 端的 Rdesktop Media Server 和 Client 端的 rdesktop、MPlayer 間溝通的訊息。最後剖析 MPlayer 和 Rdesktop Media Server Web Server 間的 TCP 流量控制。實驗環境如下：

封包擷取軟體：Wireshark 1.0.3 連線桌面大小：1024*768 pixels bits per pixel：16 bpp

RDP Server：Microsoft Windows XP SP3，RDP 5.1 RDP Client：Linux Fedora 8，rdesktop-1.6.0

Media Server：Rdesktop Media Server Media Player：MPlayer 1.0rc2-4.1.2

5.1.1 播放影片封包分析

1. Rdesktop Media Server 傳送 PLAY 指令

圖5-1. Rdesktop Media Server 傳送 PLAY 指令

當使用者播放影片，Server 端 Rdesktop Media Server 的 TCP Socket Server 傳送播放 的指令給Client 端 rdesktop 的 MPlayer_Control_Thread()。MPlayer_Control_Thread()收到 播放指令後，呼叫MPlayer 並且指定檔案位址。

2. MPlayer 和 Rdesktop Media Server 建立 TCP 連線

圖5-2. MPlayer 和 Rdesktop Media Server 建立 TCP 連線

Client 端的 MPlayer 的 HTTP 開檔模組和 Server 端 Rdesktop Media Server 的 Web Server 利用三向交握建立 TCP 連線。這個 TCP 連線是用來傳送 HTTP 請求/回應/檔案資 料。

3. MPlayer 送出 HTTP 請求訊息

圖5-3. MPlayer 送出 HTTP 請求訊息

當TCP 連線建立完成，Client 端 MPlayer 的 HTTP 開檔模組發送 HTTP 請求訊息給 Server 端 Rdesktop Media Server 的 Web Server。

4. Rdesktop Media Server 回傳 HTTP 回應訊息

圖5-4. Rdesktop Media Server 回傳 HTTP 回應訊息

Rdesktop Media Server 的 Web Server 收到請求訊息後，回應訊息給 Client 端 MPlayer 的HTTP 開檔模組。

5. Rdesktop Media Server 開始傳送影片資料

圖5-5. Rdesktop Media Server 開始傳送影片資料 Server 端 Rdesktop Media Server 的 Web Server 開始傳送影片資料。

5.1.2 播放影片流量控制

MPlayer 播放影片，需要穩定的資料。而 Web Server 是利用 best effort 的方式傳送 影片資料。MPlayer 的 Cache2 大小有限，這邊的重點是觀察 MPlayer 如何利用 TCP window size 做流量控制。

Web Server 傳送資料時，將待傳送的資料放到 send buffer。透過網路將 send buffer 的資料傳送到接收端。接收端收到資料後，將資料放到receive buffer 並且回 ACK 訊息

到傳送端。MPlayer 的 Cache2 再到 receive buffer 取得影片資料。

圖5-6. Receiver window size 變小

如果Cache2 停止填充資料，代表不去 receive buffer 收取資料。最後 receive buffer 將越來越小，此時作業系統持續從傳送端接收TCP 封包，並在回 ACK 時將 window size 變小。傳送端收到接收端的ACK 訊息，得知接收端的 window size 變小，如圖 5-6。當 receive buffer 滿了，會回 ZeroWindow 的訊息到傳送端，如圖 5-7。此時傳送端收到 ACK 訊息後，停止傳送資料。

圖5-7. TCP ZeroWindow

傳送端停止傳送資料，接收端不再收到資料，也不會有 ACK 訊息給傳送端。但是

這樣 TCP 連線是否有斷線就不得而知。所以傳送端會傳送 ZeroWindowProbe 的訊息到 接收端，接收端收到後回傳ZeroWindowProbeAck 的訊息，這樣可以確保連線還存在，

如圖5-8。

圖5-8. TCP ZeroWindowProbe

當Cache2 到 receive buffer 收取資料，receive buffer 空間會釋放出來，此時接收端

會回傳TCP Window Update 的訊息，如圖 5-9。傳送端收到 window size 異動的訊息，就 可以繼續傳送資料。

圖5-9. TCP Window Update

如果Cache2 到 receive buffer 收取資料的速度比較慢，而傳送端傳送資料比較快，

最終receive buffer 將會溢位。此時也會傳送 Zero Window 的訊息，接收端因此停止傳送，

直到收到接收端TCP Window Update 的訊息，才繼續傳送。

5.1.3 播放影片時流量

影片檔案大小 43,141KB、長度 135.18 秒、MPlayer Cache2 大小設定 8192KB。圖 5-10 為播放影片的影片流量，橫軸單位為秒，縱軸單位為位元組，資料為每 0.1 秒的傳 輸量。5-11 為 Client 端 TCP 的 window size，橫軸單位為秒，縱軸單位為位元組。0 秒 位置為Rdesktop Media Server 傳送播放指令，將流量分成 3 個階段：

第1 階段(~4 秒)：

當Web Server 開始傳送影片，MPlayer 會先將資料填到 Cache2，填到將近 100%

才停止，這階段是以best effort 傳送，流量會比較大。Client 端 TCP window size 維 持在64KB。

第2 階段(4~20 秒)：

Cache2 填滿後，資料停止填充，Web Server 停止傳送資料到 MPlayer，這階段 的流量為0。Client 端 TCP window size 為 0。

第3 階段(20 秒~)：

當Cache2 被消耗到 50%，開始填充資料，並且維持在 50%的位置。這時候的

流量，即為MPlayer 消耗的資料量。最後播放快要結束時，影片最後的資料都存在 Cache2，此時 Web Server 已經將資料傳送完畢，TCP 連線將中斷。

圖5-10. 播放影片流量圖

圖5-11. Client 端 TCP window size

5.1.4 播放影片時 Cache2 狀態

圖5-12 為播放影片時 Cache2 的狀態，Cache2 大小設定為 8192KB，圖片中橫軸單 位為秒，縱軸單位為位元組。第 3.2 節說明了 Cache2 的機制，這邊將測量播放影片時 Cache2 的狀態。

新資料即未播放的影片資料，一開始從 0%填充到 100%即停止。當新資料剩餘

50%，即舊資料為 50%的大小，開始填充資料並且新資料維持在 50%。在播放即將結束 時，剩下的影片資料存在Cache2，此時新資料將從 50%被耗用到 0%。播放影片也隨即 結束。

圖5-12. 播放影片 Cache2 的狀態