一道複雜的三次握手和HTTP的RTT計算題

記載於《計算機網絡——自頂向下方法》的第二章P10題,可以說是這一章最難的題目了
題幹如下:
考慮一條10米短鏈路,某發送方經過它能夠以150bps速率雙向傳輸。假定包含數據的分組是100000比特長,僅包含控制(如ACK或握手)的分組是200比特長。假定N個並行連接每個都獲得1/N的鏈路帶寬。現在考慮HTTP協議,並且假定每個下載對象是100Kb長,這些初始下載對象包含10個來自相同發送方的引用對象。在這種情況下,經非持續HTTP的並行實例的並行下載有意義嗎?現在考慮持續HTTP。你期待這比非持續的情況有很大增益嗎?評價並解釋你的答案。

答案:
請注意,每個下載的對象可以完全放入一個數據包中。令Tp表示客戶端和服務器之間的單向傳播延遲。
首先考慮使用非持久連接的並行下載。並行下載將允許10個連接共享150位/秒的帶寬,每個連接只有15個位/秒因此,接收所有對象所需的總時間爲:
在這裏插入圖片描述
現在考慮一個持久的HTTP連接,所需的總時間爲:
在這裏插入圖片描述
解析:
首先我們要明白,一般在計算延時的時候,分組的數據大小是不被計算在內的,這就一定程度上增加了迷惑性。
我們看一下三次握手的過程:
在這裏插入圖片描述
前兩次握手花費的時間是兩個控制分組的傳輸時間+RTT=傳輸時間+2*Tp
因爲客戶端在兩次握手之後立即向客戶端發送第一個對象,所以第三次握手的數據傳輸時間不被計算在內,這裏我們就可以理解我們平常說的往返時延在三次握手裏面其實是前面兩次握手的時延。
第三次控制對象的傳輸實際上和數據對象的傳輸是並行的,不需要重複計算。
之後,因爲是非持續的HTTP連接,所以等待第一次連接斷開後並行傳輸後面的引用對象。
有人可能會疑惑:爲什麼不能一開始就並行傳輸原對象和引用對象呢?
當然是因爲只有原對象傳輸完才能夠確定引用的具體是那些對象了。
之後並行連接引用對象,因爲可以完全並行,所以是2個RTT也就是四個Tp+兩次控制+數據傳輸時間。
對於持續http,建立握手之後不需要重複建立,總共只需要三個RTT就夠了。
其實理解之後挺簡單,只不過自己想的話覺得有些難以理解,所以我單獨記錄出來希望能幫助大家( ̄▽ ̄)/

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章