感覺好像少吃很多仙貝,總覺得聽下來不是很懂,老師也有說上過的人當複習。
可以修 電腦網路導論
TCP 全名叫做 Transmission Control Protocol。
從他的名稱可以知道,其目的是對傳輸進行控制,提供可靠的傳輸,和避免把網路塞爆。
他是 Transport layer,也就是第 4 層的。
控制的方法一樣利用到之前的老朋友,ACK,並搭配 sequence number 代表這是第幾個 ACK。
但是要注意的是:
不同層之間的 ACK 是不同的東西,最底下會提到
在 TCP 中有個重要的東西叫做 Window ,白話一點是 Quota 的意思,代表可以有多少東西在外面傳,以免把網路塞爆。
如果很久沒收到 ACK,「可能」就是 Windows 給太大,把外面塞爆了,所以要減少 window 的量。
這就是上面講的 window。
最基礎的版本就是值設成 1 MSS (Maximum Segment Size)。
簡單來說就是增加用加法,減少用乘法;也就是說減少的速度比較快。
增加分成兩個階段 Phase,並且跟 CWND 這個參數有關。在基礎款的協議中,CWND 通常設成 1。
試水溫的階段,會有變快的趨勢,是還在「嘗試」的階段。
每次接收到一個 ACK,cwnd 就會加 1,但是要注意這樣的效果是「指數型成長」。
舉例如下:首先一開始 cwnd 是 1,然後現在收到 1 個 ACK,cwnd 就變成 2。
重點來了,cwnd 變成 2 代表,你可以傳輸兩個大小的東西出去,因此如果傳輸順利的話,下次收到的 ACK 就會變成 2,這樣 cwnd 會變成 4,所以以此類推,會再變成 8、16…。
所以一開始會長很快。
但是這樣一定會爆,所以會設置一個閾值,超過閾值就會進入第二階段。
線性成長的階段,公式是加 cwnd = 1 / cwnd,原理跟上面一樣。
或者換個角度想, cwnd 代表的是當前可以回傳的 ack 數量,所以除以 cwnd 就代表下一次可以傳輸的數量只會加 1。
兩個階段如下圖:
可以看到各個點對應的值跟上面敘述符合。
說到減少,要先提在有線環境下的情況。
TCP 在有線的環境下,偵測到封包損失 packet loss 就會開始減少 windows。
因為在有線環境下,封包損失就代表負責轉運的路由器被塞爆了;所以現在在無線環境也以這個為基礎,覺得封包損失原因是自己把網路塞爆了。
但是…
其實有可能是因為傳輸環境不好 (BER 很高),造成封包損失,或是傳輸速度很慢,ACK 來不及回來等等,也就是說無線環境多了很多其他因素造成封包損失,並非全都是由堵塞造成的。
傳輸速度降低的方法,有兩種,一個是直接歸零,一個是砍半。
TCP是一個端到端的協議
老師說回到第一堂課講的,對每個系統都要去注意,無線跟有線的差異,以及行動跟固定的差異。
在現在這個例子可以發現兩大問題:
總結來說就是「環境問題」跟「換手問題」。
一次的傳輸時間,也就是「傳遞出去」到「收到 ack」 的時間。
所以一段 RTT 之間可以傳的量就是我的 throughout,而沒有收到 ACK 就會假設是發生封包損失,也就是假設發生堵塞。
收不到 ACK 在無線 TCP 有兩種情況:
在 TCP 當中,收到東西就一定會傳 ACK。如果正確的話,就會照著順序回傳 number;
但是如果接收方沒有照著順序收到封包,例如下圖中的 4 可能傳一傳不見了,當接收方收到的時候,發現跳號了,他就知道有可能是中間有人不見了,所以會回傳當前收到的最大 number 回去,也就是 3。
在無線的環境可能又會有多條路,所以可能有些人會超車。
所以會設定收到幾個重複的號碼以上才視為真的有人不見了。
專門設計給換手頻率少於一秒一次的。
老師說很像之前提到的 HLR、VLR 查找位置的那個關係。
由於在無線的 TCP 中,收不到 ACK 就會預設認為是發生堵塞 congestion,因此觸發 congestion control。
但是實際上可能的原因,就是上面歸納出的 High BER 跟 Handoff。
而持續觸發 congestion control 的結果就是 window 很小,傳輸速率很慢。
這個問題有非常多種解決的方法,但是也各有各的優缺點。
不過現在比較少有論文在介紹新的解決方法了,因為現在速度變很快,所以環境已經很像有線的情形。
解決方法依照修改的 Layer 而分類。
就是加強環境,使用 FEC 和 ARQ。
就是有名的 Snoop 方法
TULIP 或 Delayed Duplicate ACK。
第 2 跟 3 個下面都會提到。
殘存
第四層跟第二層一起考量
直接改版 TCP。
修正原本 TCP 的選用選項。
使用新的協議。
直接是用一個另一種 protocol Stack
底下主要講 Link Layer 和 Transport Layer 的。
從下圖可以看出,我們動手的地方是 Link Layer。
前面有提到,TCP 會誤判的原因之一就是環境太差,那我們就不要讓 TCP 去知道環境差的錯誤就好了。
就是待會的重頭戲 Snoop。
意思就是偷聽或偷看。
會在 BS 裝一個 snoop agent,所以不需要改變有線網路的東西。
這個 snoop agent 會監測 UL 跟 DL,檢查所有的 TCP 活動。
並且如果偵測到一個 TCP segment,直到看到他的 ACK 送過來前,snoop agent 都會記著他,存在快取裡面;但是也不是都一直記著他,而是採用 Soft state ,就是有時效的資訊,也就是會讓他過期,不然一直堆著會爆。
下面是 Protocol 的樣子
上圖中,黃色大的是資料,紫色小的是 ACK;可以看到 37 號遺失了。
在這裡我們有使用一個技巧叫做 delayed ACK ,也就是每兩個封包才回傳 ACK,並固定回傳後者,以節省 ACK 的頻率。
先持續傳輸。可以看到我們的特務會持續記錄有哪些資料出去了。
此時接收端發現 37 號不見了,所以就會回傳重複的 ACK 回來。
可以注意到一件事情,重複的 ACK 不會進行 Delayed,所以可以看到他的頻率變回兩倍了。
同時可以看到特務有收到某號 ACK 後,就會「將該號以前的都刪掉」,為甚麼說「該號以前」,要繼續看下去。
可以看到,特務把重複的 ACK 丟掉了,也就是隱瞞的動作;而另一個重要的動作是,特務從自己的cache 中找出遺失的 37 號資料重新傳輸。
這裡的 BS 就會叫做 TCP-aware。
從上下兩張圖可以看到,特務的快取中記下越來越多資料,因為號碼都被 37 號卡著了
此時可以注意到,回傳的是 41 號,也就是收到 37 之前最大的號碼,這樣才可以用上面提到的原則,把特務快取中的號碼去除。
可以注意到另一件事情,沒有重複的 ACK,都會再傳到上層,但是像這裡重複的 ACK 36 號,就會被攔截下來,因為第一次的 36 號已經傳給上層了。
最後就是正常的將 41 號傳給 上層。
所以感覺上,Link Layer 的第一個解法就是把環境盡力調整好
而第二個解法,也就是剛剛的 Snoop 那種的,是不告訴上面發生了錯誤
將原本 TCP 的特色「端到端連結 end-to-end connection」拆成兩段,Sender到 BS 和 BS 到 receiver;然後分別地處理有線和無線的 TCP。
將有線跟無線的 Packets loss 分開來,並且使用兩個獨立的 Control flow,有可能會需要用到特殊的 Protocol 來控制參數。
I-TCP 就是使用了兩個標準的 TCP。跟 Snoopy 很像,這裡也有個特別角色,MSR。
他擔任 Sender 跟 Receiver 之間的中介人,他的 ACK 代表了 Receiver 的 ACK;也就是上面 BS 所擔任的角色。
或者又叫做 Foreign Agent。
在 MSR 跟 Sender 之間是正常的 TCP,但是 MSR 跟 Receiver 之間的是「wireless TCP」。
如此一來 Sender 可以有更穩定的連接,並且更快的恢復 packets faster,還能夠處理 mobility。
下面是 Protocol Stack
可以注意到,Snoop 就是為了避免破壞 End-to-End 的特性,而對 I-TCP 做的改進
會這樣做的原因是因為,M-TCP 假設的環境都是很好的,所以如果沒有收到 ACK 就是預設發生換手。
若發生 Packets Loss,由於 SH 只會將收到的 ACK 轉給 Sender,所以是交由 Sender 處理,也就是說保持 End-to-End 的特性。
不像 I-TCP 的 MSR 的 ACK 代表了 Receiver,在 M-TCP 中 BS 要先收到 MH(Receiver) 的 ACK 才會發送 ACK。
要記得發生 Packet Loss 也會回傳 ACK
Compression 是 header 的 compression
或許我們可以在端到端做些事情來解決問題。
這個東西叫 ELN,他是一個 TCP 的 ACK 中的選項。如果發生 bit loss,也就是跳號的時候,那個選項就會被開啟,這樣 sender 也就可以知道發生跳號了。
這樣 window 就不會呈現鋸齒狀,降低傳輸速率,而是單純重新傳一遍來解決問題。
但是要注意的是,那個 bit 只代表了「猜測」環境不是由堵塞造成的,因為實際上到底發生了甚麼,我們依舊是不知道。
而判斷的方法,只能從有限的資訊推導,像是從網卡的資訊綜合判斷,也就是從 Link Layer 的狀態來判斷;但是畢竟資訊太有限,所以 tradeoff 就是也可能判斷錯誤。
他可以很容易的分辨是不是由堵塞發生的。
如果是移動的情景下,例如上次的 Multihop,這個東西蠻好猜中的,畢竟那個情景就是在討論很多人且移動的環境。
這裡強調的是解決環境造成的 Packet loss 問題
這裡強調的是 Handoff 換手造成的 Packet loss 問題,所以上面的方法可能會不適用。
像是上面的兩個 Split Approach 都不行。
如果要減輕換手造成的 Packet loss,我們可以「無縫換手」
對於 802.11 來說,TCP 的 Data 跟 ACK,通通都只是「要傳的資料」,也就是說他並不知道優先順序,而剛好在 802.11 的環境是,搶到就是你的,所以會有一種很尷尬的情形,就是 A 傳了 TCP 的 Data 給 B,理論上 B 應該要在時間內傳送 TCP 的 ACK 回去。
但是對 802.11 來說,這兩個都只是要傳的資料,所以有可能 TCP 的 ACK 在時間內都傳不過去,因為都被搶走了,也就因此 ACK 超時了。