# 無線及寬頻網路 week6 1102951
## 第一題
### 實驗截圖
**<p class="text-center">100_30_95.txt(紅色鉛直線與綠線)表原實驗
100_30_90.txt(藍色鉛直線與粉線)表改為90%信賴區間</p>**
### 簡要說明
已知在95%信賴區間(原實驗)下，Z值為1.96，而在90%信賴區間(新實驗)下，Z值為1.645，因此，利用信賴區間公式，我們可以知道，在其他條件不變的情況下(平均值、標準差、樣本數相同，粉色線覆蓋綠色線，因此不可見)，95%信賴區間的範圍會較90%信賴區間的範圍還要來得小，在上圖的鉛直線也驗證了此事
## 第二題
### 實驗截圖
**<p class="text-center">100_30_95.txt(紅色鉛直線與綠線)表原實驗
100_300_95.txt(藍色鉛直線與粉線)表樣本數改為300次</p>**
### 簡要說明
已知在原實驗中，在每個速率做了30次實驗，而在新實驗中，在每個速率做了300次實驗，因此，我們可以預知的是，平均將稍有不同(綠線與粉線不重疊)，並且利用信賴區間公式，我們可以知道，在Z值不變的情況下，樣本數的增加，將意味著信賴區間範圍的縮小，在上圖的鉛直線也驗證了此事
## 第三題
### FIFO實驗截圖
**<p class="text-center">q-myfifo-10(紅線)表原實驗
q-myfifo-20(綠線)表TCP改為20條</p>**
### FIFO簡要說明
由圖片可以觀察到：

1. **佇列長度上升速度**：在佇列啟動時，無論是10條TCP連線還是20條TCP連線，佇列長度都迅速增加並在短時間內達到穩定狀態。綠線的上升速度比紅線快一些，這是因為TCP連線數量越多，數據包進入佇列的速率越快，因此佇列長度上升得更快。

2. **穩定狀態**：當佇列達到一定長度後，佇列長度保持在一個穩定的範圍內，10條TCP連線和20條TCP連線的佇列長度都維持在接近50的區間內。這意味著佇列的容量已接近飽和，並且DropTail策略會將進入的超過佇列容量的數據包直接丟棄。

3. **佇列長度波動**：在穩定狀態下，紅線與綠線的佇列長度會有些許波動。這是因為TCP連線在接收到丟包訊號後會自動調整傳輸速率，從而導致佇列長度有所變化。TCP連線數越多 (綠線20條)，波動幅度略微大於10條連線的波動幅度 (紅線)，表明在負載較大時，佇列長度的變化更加顯著。

4. **DropTail策略的影響**：DropTail是一種被動式的佇列管理策略，它只會在佇列已滿時丟棄進入的數據包，因此佇列的長度會維持在一個固定的範圍內。然而，這種策略可能會導致TCP連線同時發生擁塞 (全局同步現象)，進而影響整體網路的傳輸效率。
### RED實驗截圖
**<p class="text-center">q-RED-10(紅線)表原實驗
q-RED-20(綠線)表TCP改為20條</p>**
### RED簡要說明
由圖片可以觀察到：
1. **佇列長度波動**：佇列長度在不同TCP連線數下呈現不同的波動。隨著連線數增加 (從10條到20條)，綠線的波動頻率略高，佇列的長度有更頻繁的變化，表明隨著TCP連線數增多，系統負載增加，佇列的變動也變得更不穩定。

2. **佇列長度趨勢**：從紅線與綠線的走勢來看，隨著時間推移，佇列長度會在一定區間內波動，但不會無限增長，這是RED算法的特性之一。RED透過隨機丟包的方式，在佇列過長時主動減少佇列長度，從而避免擁塞崩潰 (congestion collapse)。

3. **負載影響**：當佇列中處理的TCP連線數量增加 (例如從10條增加到20條時)，可以看到佇列的波動幅度加大，這意味著負載加重後，系統必須更頻繁地調整佇列長度來避免擁塞。
## 第四題
### Delay實驗截圖
### Delay簡要說明
#### 由圖片可以觀察到：

1. **DropTail FIFO + 10條TCP連線 (延遲4.379053秒)**
DropTail FIFO 佇列的延遲較高，這是因為DropTail策略並不會在擁塞即將發生時主動丟包，而是在佇列滿了之後才丟棄數據包。這樣會導致佇列長度達到極限時，數據包在佇列中等待的時間變長，進而造成較大的延遲。TCP流量通常會調整自己的傳輸速率以應對丟包現象，這進一步加劇了佇列中的積壓現象，最終導致較大的延遲。

2. **RED + 10條TCP連線 (延遲1.237935秒)**
RED策略的延遲顯著降低，這是因為RED會在佇列開始變長時主動丟包，而不是等到佇列滿了再丟棄。這種主動丟包策略會讓TCP協議提早感知到網路擁塞，從而降低傳輸速率，減少數據包的排隊時間，因此佇列的延遲比DropTail更小。

3. **DropTail FIFO + 10條CBR連線 (延遲5.876449秒)**
CBR (Constant Bit Rate)流量在DropTail下的延遲比TCP流量更大。CBR流量是固定速率的傳輸，它不會像TCP那樣根據網路擁塞情況動態調整自己的傳輸速率，因此當佇列滿了之後，CBR流量會持續填滿佇列，導致數據包的等待時間非常長，最終導致更高的延遲。

4. **RED + 10條CBR連線 (延遲1.799565秒)**
使用RED的情況下，CBR的延遲比在DropTail下要小得多。儘管CBR無法像TCP那樣動態調整速率，但RED通過主動丟棄部分數據包來減少佇列長度，從而減少數據包等待的時間。這使得RED在處理CBR流量時也能顯著降低延遲。

#### 延遲變動原因總結：
- **DropTail FIFO的高延遲**：由於DropTail佇列在接近滿載時才開始丟包，這導致了數據包的長時間等待，特別是在CBR流量下，無法調整速率的流量會導致佇列過度積壓。
- **RED的低延遲**：RED的優勢在於它的主動丟包機制，這種機制使網路能夠提早處理擁塞問題，減少佇列的長度和數據包的排隊時間，因此延遲大大降低。
- **CBR流量的影響**：由於CBR流量是固定速率的，無法根據擁塞情況調整傳輸速率，因此在擁塞的情況下，其延遲通常會比TCP流量更大。但RED策略可以有效緩解這一問題。

總結來說，RED相較於DropTail FIFO更能有效地降低延遲，無論是針對TCP還是CBR流量。
### Throughput實驗截圖
### Throughput簡要說明
此為r1-r2的頻寬，兩者皆相同為值56kbps
### Queue Length實驗截圖
**<p class="text-center">FIFO Queue Length</p>**
**<p class="text-center">RED Queue Length</p>**
### Queue Length簡要說明
FIFO為被動式佇列管理，直至Queue滿時滿時才回丟棄即將進來的封包，反之RED為主動式佇列管理，當Queue到達一定水平時，將會有機率丟棄Queue內之封包
### 總結
當使用UDP流量時，RED的機制雖然會主動且提早丟棄封包，這樣的做法能減少佇列長度，進而降低傳送延遲，但對throughput並沒有提升。RED無法提升throughput的原因是，佇列管理的核心目的不僅是丟棄封包，還是提供提前的警示。TCP協議會根據這些警示來調整傳送速度，以避免佇列過滿並減少封包丟棄。然而，UDP協議不會響應這些警示，因此即使有預警，UDP流量仍然可能導致佇列過滿，無法減少封包丟棄。總的來說，佇列管理策略更適合TCP，對UDP的效果有限。