--- title: TCP|第十四週 tags: 無線與行動網路導論 --- :::info 感覺好像少吃很多仙貝,總覺得聽下來不是很懂,老師也有說上過的人當複習。 ::: :::success 可以修 電腦網路導論 ::: # TCP TCP 全名叫做 Transmission Control Protocol。 從他的名稱可以知道,其目的是對傳輸進行控制,提供可靠的傳輸,和避免把網路塞爆。 他是 Transport layer,也就是第 4 層的。 控制的方法一樣利用到之前的老朋友,ACK,並搭配 sequence number 代表這是第幾個 ACK。 但是要注意的是: :::warning 不同層之間的 ACK 是不同的東西,最底下會提到 ::: ## Window Floor Control 在 TCP 中有個重要的東西叫做 Window ,白話一點是 Quota 的意思,代表可以有多少東西在外面傳,以免把網路塞爆。 如果很久沒收到 ACK,「可能」就是 Windows 給太大,把外面塞爆了,所以要減少 window 的量。 ## Congestion window / cwnd 這就是上面講的 window。 最基礎的版本就是值設成 1 MSS (Maximum Segment Size)。 ## Additive Increase Multiplicative decrease / AIMD 簡單來說就是增加用加法,減少用乘法;也就是說減少的速度比較快。 # 增加 增加分成兩個階段 Phase,並且跟 CWND 這個參數有關。在基礎款的協議中,CWND 通常設成 1。 ## 階段一 Slow Start 試水溫的階段,會有變快的趨勢,是還在「嘗試」的階段。 每次接收到一個 ACK,cwnd 就會加 1,但是要注意這樣的效果是「指數型成長」。 舉例如下:首先一開始 cwnd 是 1,然後現在收到 1 個 ACK,cwnd 就變成 2。 重點來了,cwnd 變成 2 代表,你可以傳輸兩個大小的東西出去,因此如果傳輸順利的話,下次收到的 ACK 就會變成 2,這樣 cwnd 會變成 4,所以以此類推,會再變成 8、16...。 所以一開始會長很快。 但是這樣一定會爆,所以會設置一個閾值,超過閾值就會進入第二階段。 ## 階段 2 Congestion Avoidance 線性成長的階段,公式是加 cwnd = 1 / cwnd,原理跟上面一樣。 或者換個角度想, cwnd 代表的是當前可以回傳的 ack 數量,所以除以 cwnd 就代表下一次可以傳輸的數量只會加 1。 兩個階段如下圖:  可以看到各個點對應的值跟上面敘述符合。 # 減少 說到減少,要先提在有線環境下的情況。 TCP 在有線的環境下,偵測到封包損失 packet loss 就會開始減少 windows。 因為在有線環境下,封包損失就代表負責轉運的路由器被塞爆了;所以現在在無線環境也以這個為基礎,覺得封包損失原因是自己把網路塞爆了。 但是... 其實有可能是因為傳輸環境不好 (BER 很高),造成封包損失,或是傳輸速度很慢,ACK 來不及回來等等,也就是說無線環境**多了很多其他因素造成封包損失**,並非全都是由堵塞造成的。 傳輸速度降低的方法,有兩種,一個是直接歸零,一個是砍半。 --- :::warning TCP是一個端到端的協議 ::: # 行動與無線 老師說回到第一堂課講的,對每個系統都要去注意,無線跟有線的差異,以及行動跟固定的差異。 在現在這個例子可以發現兩大問題: - 無線的環境可能會不好,也就是 BER 很大,造成誤判 - 所以高 BER 就很像是懲罰兩次 - 環境就已經不好傳輸了,還會被誤判為堵塞,造成傳輸速率下降,不就越來越慢 - 移動可能會造成換手的封包損失,也會被誤判 總結來說就是「環境問題」跟「換手問題」。 # Round Trip Time / RTT 一次的傳輸時間,也就是「傳遞出去」到「收到 ack」 的時間。  所以一段 RTT 之間可以傳的量就是我的 throughout,而沒有收到 ACK 就會假設是發生封包損失,也就是假設發生堵塞。 # Packet Loss 收不到 ACK 在無線 TCP 有兩種情況: - 超時,也就是超過預估時間沒有收到 - 會有個 Retransmission TimeOuts / RTO timer 來計時 - 收到重複的ACK - 重複 ACK 的來源是一個避免措施 在 TCP 當中,收到東西就一定會傳 ACK。如果正確的話,就會照著順序回傳 number; 但是如果接收方沒有照著順序收到封包,例如下圖中的 4 可能傳一傳不見了,當接收方收到的時候,發現跳號了,他就知道有可能是中間有人不見了,所以會回傳當前收到的最大 number 回去,也就是 3。  在無線的環境可能又會有多條路,所以可能有些人會超車。 所以會設定收到幾個重複的號碼以上才視為真的有人不見了。 # 無線傳輸的情形 - Limited bandwidth - 就是前面提到的傳輸速率很低 - 要記得調高收取 ACK 的 Timer - Long Round Trip Time - 高傳遞時間 - 常見於高緯衛星,延遲會很長 - 或是 2G 和 3G 的網路,延遲很長 - 因為耳朵聽得出時快時慢,但是聽不出同時快同時慢 - 所以以前才沒有這個問題 - High BER - 環境很差 - 很常用 FEC 校正碼效率也會不佳 - Short Flows - HTTP 等應用,常常需要傳一些小小的資料 - 而每次傳這些資料 TCP 就需要三方握手,花費會很高 - 老師說真正要傳輸的資料才是有效的資料,其他的都是cost,像是前面的建握手,校正碼等等 - Power consumption - 有時候 TCP 傳輸會持續很久,像前面的 Slow Start,要花一段時間等待到好的速度 - 這時候手機就要持續開著,就會有浪費電的問題 ### Mobile IP 專門設計給換手頻率少於一秒一次的。 老師說很像之前提到的 HLR、VLR 查找位置的那個關係。 # 問題 由於在無線的 TCP 中,收不到 ACK 就會預設認為是發生堵塞 congestion,因此觸發 congestion control。 但是實際上可能的原因,就是上面歸納出的 High BER 跟 Handoff。 而持續觸發 congestion control 的結果就是 window 很小,傳輸速率很慢。 # 解決方法 這個問題有非常多種解決的方法,但是也各有各的優缺點。 不過現在比較少有論文在介紹新的解決方法了,因為現在速度變很快,所以環境已經很像有線的情形。 解決方法依照修改的 Layer 而分類。 ## Link Layer 1. Robust link layer 就是加強環境,使用 FEC 和 ARQ。 2. TCP-Aware Link Layer solution 就是有名的 Snoop 方法 3. TCP-Unaware Link Layer solution TULIP 或 Delayed Duplicate ACK。 第 2 跟 3 個下面都會提到。 :::info 殘存 第四層跟第二層一起考量 ::: ## Transport Layer -- Split connection - Indirect TCP (I-TCP) - 有線端保持舊的 TCP ,而無線的用新的 TCP ,中間再去用介面接起來 - M-TCP - 改版改成不像 TCP。但是造成一個缺點,就是把 TCP 的端到端特性破壞掉了 ## Modified version of TCP 直接改版 TCP。 ## Other changes to TCP 修正原本 TCP 的選用選項。 ## New Transport Layer 使用新的協議。 ## WAP protocol stacks 直接是用一個另一種 protocol Stack 底下主要講 Link Layer 和 Transport Layer 的。 --- # Link layer 解法 從下圖可以看出,我們動手的地方是 Link Layer。  ## Hide Wireless Link Error from TCP 前面有提到,TCP 會誤判的原因之一就是環境太差,那我們就不要讓 TCP 去知道環境差的錯誤就好了。 - 方法一就是模擬出有線環境,也就是使用 FEC 降低 BER。 - 方法二是減少頻段的錯誤率,例如使用 - Automatic Repeat Request (ARQ) - ARQ 就是 retransmission - Forward Error Correction (FEC) - 就是校正碼 - Hybrid FEC/ARQ scheme - 是將 ARQ 的部分搭配 coding 技巧 ## TCP-aware Link Layer Solution 就是待會的重頭戲 Snoop。 ## 好處 - BS 不用維持 connection state - 保持 layered structure - 不讓 higher-layer 知道有 loss 發生 ## 缺點 - 無法解決 mobility 問題,也就是換手 - 畢竟主要是調整環境而已 - ARQ 的 retransmission 時間要很短,否則會被上層判定超時 - 並且需要多花力氣重新傳輸 ### 介紹一下 - FEC - 大多數的通訊系統都會用 FEC 來校正 - ARQ - Cellular system 通常都會用 - 但是在某些系統中 ARQ 是選用的,如 802.16 - AIRMAIL (1995) - FEC + ARQ - Hybrid ARQ - FEC + ARQ,並且搭配... - Soft combining - 收到多份有損壞的,可以合併成一份好的 - Promising technique in many systems # Snoop 意思就是偷聽或偷看。 會在 BS 裝一個 snoop agent,所以不需要改變有線網路的東西。 這個 snoop agent 會監測 UL 跟 DL,檢查所有的 TCP 活動。 並且如果偵測到一個 TCP segment,直到看到他的 ACK 送過來前,snoop agent 都會記著他,存在快取裡面;但是也不是都一直記著他,而是採用 Soft state ,就是有時效的資訊,也就是會讓他過期,不然一直堆著會爆。 ## 特務的活動 - 監測 Packet loss ,發生的情形可能為 - 收到重複的 ACK - 就是前面提過的 - 超時 - 就是遲遲沒有看到 ACK 回來 - 不讓有線網路知道發生 loss - 也就是上面說的,不讓 TCP 等高層知道發生 loss 了 - 方法就是攔截重複的 ACK,並重新傳送一次 下面是 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 號傳給 上層。 ## 優點 - 使用了 Soft State - 由於我們欺騙了上層,所以他就不會頻繁的降低 window - 因此我們的傳輸速度不會鋸齒狀的抖動 ## 缺點 - Link layer 要做很多事 - 破壞了模組化設計原則 modular layer design principle - 跟上面提到的保持層狀結構意思不一樣 - 需要修改 Mobile-side 的 TCP - 並且需要安插特務在 BS,也就是要修改 BS :::warning 所以感覺上,Link Layer 的第一個解法就是把環境盡力調整好 而第二個解法,也就是剛剛的 Snoop 那種的,是不告訴上面發生了錯誤 ::: # Split Connection -- Transport Layer 將原本 TCP 的特色「端到端連結 end-to-end connection」拆成兩段,Sender到 BS 和 BS 到 receiver;然後分別地處理有線和無線的 TCP。  # I-TCP / Indirect TCP 將有線跟無線的 Packets loss 分開來,並且使用兩個獨立的 Control flow,有可能會需要用到特殊的 Protocol 來控制參數。 I-TCP 就是使用了兩個標準的 TCP。跟 Snoopy 很像,這裡也有個特別角色,MSR。 ## Mobility Support Router / MSR 他擔任 Sender 跟 Receiver 之間的中介人,他的 ACK 代表了 Receiver 的 ACK;也就是上面 BS 所擔任的角色。 或者又叫做 Foreign Agent。 ### MSR 的活動 在 MSR 跟 Sender 之間是正常的 TCP,但是 MSR 跟 Receiver 之間的是「wireless TCP」。 - 首先 Sender 會將要傳送的訊息傳給 MSR,而 MSR 收到訊息後就會儲存在自己的 Buffer 內,並傳 ACK 給 Sender - 接著再將訊息傳給 Receiver - 這樣一旦發生 Packets Loss 的時候,Receiver 就可以直接向 MSR 請求,而非跟 Sender 請求。 如此一來 Sender 可以有更穩定的連接,並且更快的恢復 packets faster,還能夠處理 mobility。 下面是 Protocol Stack  ## 優點 - 不會動到有線網路 - 可能需要在無線網路有特殊的 TCP 設計 - 可能會更輕量、更節能 ## 缺點 - 不難發現,擔任 MSR 的就是 BS ,所以一樣會需要修改 BS - 並且用的是 Hard State - 因為資料會直接儲存在 MSR 裡面 - Sender 收到了 ACK 不代表 Receiver 收的到訊息 - 畢竟這些東西已經都由 MSR 負責了 - 破壞了端到端的設計 - 因為 MSR 負責接收所有 Sender 的資料,然後再傳給 Receiver - 也就是阻斷了 Receiver 跟 Sender 之間的連線 - 使用者的 Mobility 會造成問題 - 也就是換手的問題 :::warning 可以注意到,Snoop 就是為了避免破壞 End-to-End 的特性,而對 I-TCP 做的改進 ::: # M-TCP - 這個方法使用了一個酷東西叫做 TCP Persist Mode;並且一樣有一個中介角色叫做 Supervisor Host / SH。 - 這個 SH 的用途是跟之前 Snoop 一樣,監測 Sender 送來的資料,以及 receiver 發送回的 ACK。 - 如果 SH 沒有收到 ACK,就會回傳一個訊息叫做「advertised window = 0」 - Sender 就會進入 Persist Mode;那個 window 就是前面提到的 window - 但是這邊特地設成 0,就是有特殊的意義 - 直到 Persist Mode 結束之前,Sender 不會發送任何資料 - 並且會保持跟原先一樣的 RTT 和 CWND,也就是說依舊保持原先的速度 - 當收到「advertised window > 0」Sender 就會離開 Persist Mode - 然後恢復 RTT 跟 cwnd 的值 會這樣做的原因是因為,M-TCP 假設的環境都是很好的,所以如果沒有收到 ACK 就是預設發生換手。 若發生 Packets Loss,由於 SH 只會將收到的 ACK 轉給 Sender,所以是交由 Sender 處理,也就是說保持 End-to-End 的特性。 不像 I-TCP 的 MSR 的 ACK 代表了 Receiver,在 M-TCP 中 BS 要先收到 MH(Receiver) 的 ACK 才會發送 ACK。 :::warning 要記得發生 Packet Loss 也會回傳 ACK ::: :::success [救命網站](https://zhuanlan.zhihu.com/p/589721889) ::: ## Compressed M-TCP Compression 是 header 的 compression # End-to-End Approaches 或許我們可以在端到端做些事情來解決問題。 ## Explicit Loss Notification (ELN) 這個東西叫 ELN,他是一個 TCP 的 ACK 中的選項。如果發生 bit loss,也就是跳號的時候,那個選項就會被開啟,這樣 sender 也就可以知道發生跳號了。 這樣 window 就不會呈現鋸齒狀,降低傳輸速率,而是單純重新傳一遍來解決問題。 但是要注意的是,那個 bit 只代表了「猜測」環境不是由堵塞造成的,因為實際上到底發生了甚麼,我們依舊是不知道。 而判斷的方法,只能從有限的資訊推導,像是從網卡的資訊綜合判斷,也就是從 Link Layer 的狀態來判斷;但是畢竟資訊太有限,所以 tradeoff 就是也可能判斷錯誤。 ## 好處 - 他可以很容易的分辨是不是由堵塞發生的。 - 如果是移動的情景下,例如上次的 Multihop,這個東西蠻好猜中的,畢竟那個情景就是在討論很多人且移動的環境。 ## 缺點 - 但是他不容易分辨是不是兩個同時都有發生 - 需要修改有線端的 TCP,且從 loss packets 復原很慢 ## 跟 Snoop 比較 - 相同之處是都可以偵測到無線端的 packet loss - 但是缺點是一樣都要修改 BS - 不同之處是 - Snoop 是設計一個新的 link layer,不會動到 TCP - 也就是 Protocol dependent (TCP-aware) - ELN 則是修改了 TCP --- # 總結 ## TCP in “Wireless” Networks 這裡強調的是解決環境造成的 Packet loss 問題 - Link Layer Approach - FEC, ARQ - Split Approach - Link Layer Split (Snoop) - Transport Layer Split (I-TCP) - End-to-End Approach - Modify TCP (TCP SACK) - Change ACK algorithm - New Transport Layer Protocol - New protocol suite (e.g. WAP) ## TCP in “Mobile” Networks 這裡強調的是 Handoff 換手造成的 Packet loss 問題,所以上面的方法可能會不適用。 像是上面的兩個 Split Approach 都不行。 如果要減輕換手造成的 Packet loss,我們可以「無縫換手」 - 減少換手延遲 - 使用 Packets forwarding - 情境是如果換手之後,在原先基地台較晚的到的資料,會被轉送 forwarding 到新的基地台 - 也因此有可能會發生重複 ack 的問題 - 但如果有設閾值那就還好 ## 其他問題? 對於 802.11 來說,TCP 的 Data 跟 ACK,通通都只是「要傳的資料」,也就是說他並不知道優先順序,而剛好在 802.11 的環境是,搶到就是你的,所以會有一種很尷尬的情形,就是 A 傳了 TCP 的 Data 給 B,理論上 B 應該要在時間內傳送 TCP 的 ACK 回去。 但是對 802.11 來說,這兩個都只是要傳的資料,所以有可能 TCP 的 ACK 在時間內都傳不過去,因為都被搶走了,也就因此 ACK 超時了。
×
Sign in
Email
Password
Forgot password
or
By clicking below, you agree to our
terms of service
.
Sign in via Facebook
Sign in via Twitter
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet
Wallet (
)
Connect another wallet
New to HackMD?
Sign up