---
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 超時了。