# 計算機網路 ch1~3 筆記
## 計算機網路ch1
### 名詞解釋
`Bandwidth`: for `digital signal`，指單位時間內部連結路能夠通過的資料量，for analog signal則是利用 `hz` 赫茲( ex: `telephone signal`)
### What is the internet and protocal
`ISP` : `Internet service provider`
可以將 `protocal` 視為電腦與電腦溝通的基本規範，電腦類似人類有特定的問候語跟問法。
在 `protocal` 中會定義 `format` 、 `order` 、 `action taken`
### edge & core
`network edge` 大部分由 `host`(`server、host`)組成，而 `core` 大部分由一堆不同的 `ISP` 的 `router` 相連而成

### Network edge
#### Acess Network:
連接 `end system` 與 `first Router` 的網路，也可以說是最邊緣的網路

#### CMTS :
`Cable Modem Termination System`，混合網路與電視訊號進入 `HFC` 網路中或將網路訊號與電視訊號分離。

#### DSLAM:
`DSL access multiplexer`，混合網路訊號與電話訊號進入 `ADSL` 網路中或將網路訊號與電話訊號分離。

#### DSL:
`Digital Subscriber Line`

#### ADSL :
`A = Asymmetric`，由於多數人較常使用下載，所以才設計這種非對稱傳輸，如中華電信就是透過利用普通的銅電話線(`Coaxil cable`)同時傳輸較低頻的電話訊號與較高頻的網路訊號，網路再藉由`ADSL modem`轉成數位訊號(`coaxil cable` 速度相較 `fiber` 慢許多)。

#### HFC:
為一種將較低頻的電視訊號與較高頻的網路訊號，透過`fiber`傳輸到用戶家中，再用`Splitter`將訊號切成電視的訊號與網路訊號，網路訊號再由`cable modem` 轉為數位訊號，由於`fiber` 是利用全反射傳遞訊號，所以速度較快，干擾較少，錯誤率也較低。

#### Guide media :
`propagate in solid media : Copper、fiber、Coaxil`
#### Unguide media :
`propagate freely : radio`


### Network Core
**Packet-Switching**:應用程式在傳遞資料時，會先將要傳送的資料切成一塊一塊的`packet`(封包)，再將 `Packets` 一個一個地傳遞到 `Router` 中。而此時，正在傳遞中的 `Packet` 會儲存在 `Router` 的記憶體中，直到整個 `Packet` 都到達 `Router` 才會將 `Packet` 再往下一個`Router`送。(`store-and-forward`)

#### Queueing Delay & packet lost:
若因 `packet` 需要`link`時， `linker busy`的狀態導致 `packets` 到達的時間超越了 `Packet` 傳遞出去的時間，這時會造成 `Queueing` 的現象，而假如今天 `Router` 的記憶體已經滿載，就有可能會遺失掉 `Packet`。

#### Forwarding:
每一台 `Router` 都有其 `forwarding table` 其作用為會把目的地地址對應到 `Router` 某個 `Output port`然後把封包送出去，`aka switching`,`is a local action`,`Router`會依照 `routing algorithm` 所演算出的 `local forwarding table transmitt packets to next Router`

#### Routing:
`Router` 之間會互相傳遞自己的基本資訊，使 `Router` 能利用 `Routing algorithm` 演算出 `local forwarding table`

#### circuit switching:
通常用於電話通訊，他像是一家必須要預約的才能進入的餐廳，他能確保顧客都能享有最高的品質且不受干擾，但同時也會浪費掉其他沒被預約的座位與資源(原本是100Mbps，切成四等分，一次只能用25Mbps)。


#### circuit v.s. packet switching & FDM / TDM
在 `FDM` 中，link 的 頻譜會在所有建立的連續進行分割，`link` 會為每個連線在連線專門分配一個頻帶。
在 `TDM` 中，時間被分割成固定長度的 `frame`，每個 `frame` 再分割成固定數量的 `slot` ，網路為每個連現在每個 `frame` 分配一個專用的 `slot`

`circuit switching`:不適合即時服務，有變動且不可預測的端對端延遲
`packet switching`:更好的傳輸容量共享，更簡單更有效率、更低成本的時作。

### Packet Delay
#### Nodal Processing(Fixed)
- `Router` 檢查 `packet header` 並決定 `packet` 轉送方向的所需時間
- 標頭檢查
- 分析 `packet header`
- 決定 `packet` 的轉送路徑
- 查詢 `routing table` 以決定下一個 `router` 地址
- `error checking`
- 檢查從上游 `node` 傳送到 `router` 過程中可發生的位元錯誤
- 驗證 `packet` 的完整性
- 確保資料傳輸的可能
- 時間極小

#### Queueing delay(varible):
`Queueing delay` 是指 `packet` 在 `queue` 等待被傳輸到 `link` 所經歷的延遲時間，其視情況而定最低為`zero delay`，最糟為延遲很長，在實作中通常為`millsec ~ microsec`等級的延遲

#### Transmission delay(Fixed):
簡單來說為 `data` 從 `Router` 出去所花的時間，在 `packet switchig` 中通常採用 `FCFS` 的方式傳輸封包，`L` 為封包長度，`R`為 `router a to router b` 的 `transmission rate`，而傳輸延遲為 `L/R`，實際應用通常為`millsec -> microsec`。

路由器緩衝區 → [位元流] → 鏈路 → 下一個路由器
                ←─ L/R ─→
                傳輸時間

- 與距離無關

#### Propagation delay(fixed)
- `packet` 真正在實體電路上傳播所需要的時間
- 一旦位元被 `tranmission to link` 上，他需要傳播到 `router b`，從 `link` 開始處傳播到 `Router b`所需的時間就是傳播延遲
- `2*10^8 m/sec~ 3*10^8 m/s` 距離
- 定義為 `d/s` 其中 `d` 為兩個 `router` 的距離，`s`為`propagation speed for link`
- 與封包長度無關

### Queuing Delay and Packet Loss
何時 `Queueing delay` 很大?何時可以忽略不計?
- 流量抵達`queue`的速率
- `the link` 的傳輸速率
- 抵達流量的性質
#### 流量強度(Traffic Intensity)
以下為其參數:
- `a`:封包抵達 `queue` 的平均速率 `packet/s`
- `R`:傳輸速率 `bit/s`
- `L`:封包長度
平均位元抵達速率: $L \times a$
**Traffic Intensity** : $\frac {L \times a} R$
有三種情況:
- `La/R` < 1
- `queue` 能夠處理抵達的流量
- `queue` 長度保持穩定
- `La/R` > 1
- 抵達速率超過處理能力
- `queue length` 持續增長
- 最終導致`buffer overflow & packet loss`

#### End to End Delay
節點延遲會累積:`d_end-to-end = N * (d_proc + d_trans + d_prop)`
### throughput
資料在網路中傳送的速率，通常以 `bit/sec、kbps、Mbps`顯示
- `Instantaneous Throughput`:某一瞬間的實際資料傳輸速率
- `Average Throughput`:整個傳輸過程的平均速率計算方式為總資料量除以總花費時間
- 如圖b，無論`R1、R2`還是`RN`誰的速度最快，`throughtput`皆會等於最小的那一個。

### Protocal Layer
當您有一份報價單( data )要寄給海外的客戶﹐將之交給秘書之後﹐秘書會幫你把信封( header1 )打好﹐然後貼好郵票投進郵筒﹐然後郵局將信件分好類﹐再把相同地區的郵件放進更大的郵包( header2 )附運﹐然後航空公司也會把郵件和其它貨物一起用飛機貨櫃( hearder3 )運達目的機場﹔好了﹐目的地機場只接管不同飛機所運來的貨物﹐然後把郵包( header2 )交給對方郵局﹐郵局把郵件分好類之後﹐把信封( header1 )遞送到客戶那裡﹐然後客戶打開信封就可以看到報價單( data )了。

`Each layer relying on service provided by layer below(上用下的服務)`

### layer packets
#### application Layer:
`DNS`,人們方便命名的終端系統 `32bits network address`

#### Transport layer:
`transport application message`，有兩個 `protocal TCP/UDP`，封包稱為 `segment`

#### Network Layer :
`packet` 被稱為 `datagrams`

#### Linker Layer :
有許多`protocal` 如 `Ethernet、WIFI、DOCSIS`，這邊的封包被稱為`frame`

## 計算機網路ch2
### Network Application Architectures
- 應用程式架構是可以自行設計的，而網路架構是網路本身設計是無法更動的
- `Client-Server arch`
- `server`: 永遠 `online` ，擁有固定 `IP` 地址，負責處理所有用戶端的請求
- `Client`: 發送請求給伺服器，伺服器回應請求
- `Pros`:
- 用戶端不直接通訊
- 伺服器是系統的核心，容易管理與維護
- 需要資料中心來擴充算力及儲存能力
- `Web、FTP、Mail`等應用
- `Peer to Peer arch`
- 每個節點是用戶端也是伺服器，彼此直接通訊
- `Pros` :
- 不依賴資料中心 or 專用伺服器
- `desktop or notebook`
- `flexible`
- 檔案分享、即時通訊
- 可自行擴展系統
- 降低基礎設施成本
- `Cons`
- 節點不穩定，可能隨時上線 or 下線，管理與安全較困難

### Processing Communicating
在此是 `Process` 在進行通訊，可以將 `Process` 想為終端系統內運行中的一個程式，在同一台`end system`可以使用程序間通訊來互相溝通，在此只關心不同 `host` 的程序如何通訊
#### Client and Server Processes:
網路應用程式由一堆 `process` 組成，對於每一對通訊的程序會標記其中一個為 `client`，另一個則標記成 `server`，在 `P2P file sharing`中一個 `process`可以是`client or server` 在一對 `process` 通訊時，主動發起通訊被稱為 `client`，等待被聯絡以開始會話的程序為 `server`

#### The Interface Between the Process and the Computer Network
任何一個 `process` 發送到另一個 `process` 的 `message` 都必須經過底層網路， `process` 會透過 `socket` 的 `software interface` 將訊息送入網路，並從網路接收訊息 `socket`是 `host` 內應用層與傳輸層的介面稱為 `API`。


#### addressing Processes:
IP位址負責定位主機，埠號負責定位主機內的特定應用程式。兩者結合，才能讓網路上的資料正確無誤地送到目標應用程式，這是網路通訊可靠運作的基礎。

### Transport Services Available to Application
`socket` 是`application layer & transport layer`之間的 `interface` 發送端的應用程式會透過`socket`推送訊息。`socket`的另一端，傳輸層協定則負責將訊息傳送到接收端程序的`socket`。
`transport layer protcal` 可以為應用程式提供哪些服務呢?
- 可靠資料傳輸
- 吞吐量
- 時效性
- 安全性

### Transport Servuces Provided by the Internet
#### TCP services:
`TCP` 和 `UDP` 是 `transport layer` 最常用的兩種傳輸層協定，`TCP` 提供連線導向、可靠傳輸、順序保證、流量控制、壅塞控制等服務。
- 連線導向:資料傳送前，雙方必須先建立連線(`ex: handshaking`)，確保雙方都準備好
- 可靠傳輸:`TCP` 會檢查資料是否正確送達，若有遺失會自動重傳，並保證資料順序正確
- 壅塞控制: `TCP` 會根據網路狀況自動調整傳送速率，避免網路過載，確保整體網路效能。
- 因為 `TCP` 本身不加密資料，傳送過程很容易被竊聽
- `TLS/SSL` 是`application layer`對`tcp` 加密與驗證的增強技術，能確保資料在傳輸過程中的機密性、完整性、身分認證。
- 使用 `SSL` 時，應用程式需呼叫 `SSL` 相關 `API`，讓資料先加密在傳入 `TCP socket`

#### UDP services
UDP是一種「無附加功能」、輕量級的傳輸協定，只提供最基本的服務。UDP是無連線（connectionless）的，因此在兩個程序開始通訊前，不需要進行交握（handshaking）。
- 無連線、無交握、輕量級
- 不保證資料可靠送達也不保證順序
- 沒有壅塞控制，發送速率不受限制
- 適合對延遲敏感可以容忍資料遺失的應用(即時語音 or 視訊)

#### TCP/UDP未提供的服務
- 吞吐量保證：無法保證資料傳送速率
- 時效性保證：無法保證延遲在某個範圍內
- 安全性：需靠應用層（如SSL）實現
- 時間敏感應用的設計
雖然網際網路不保證時效性與吞吐量，但許多即時應用（如網路電話）透過設計技巧（如自適應編碼、緩衝）來適應網路環境
設計再聰明也有極限，當網路品質太差時，應用體驗仍會受影響

### Application-Layer Protocal
- 1. 應用層協定的定義與功能
- 應用層協定規範了應用程式之間如何通訊，包括訊息格式、內容、意義與傳送時機。
- 主要內容包含：訊息類型、語法、語意、傳送與回應規則。
- 2. 公開與專有協定
- 有些協定（如HTTP、SMTP）是公開的，任何人都可依據RFC實作，確保互通性。
- 有些協定（如Skype）是專有的，僅限特定廠商或應用使用。
- 3. 應用層協定 ≠ 網路應用程式
- 應用層協定只是應用程式的一部分，還有其他元件如用戶端、伺服器、文件格式等。
- 例如：Web應用包含HTML、瀏覽器、伺服器、HTTP協定；電子郵件應用包含郵件伺服器、用戶端、訊息格式、SMTP協定等。
- 4. 實作意義
- 遵循公開協定可確保不同廠商、不同平台的應用程式能互通。
- 協定設計良好，有助於應用程式的擴展性與維護性。

### The Web and HTTP
#### HTTP
`HTTP` 會使用 `TCP` 並且使用 `port` <font color="#f00">80</font>
- 1. `client` 會先 `initiates TCP connection to server`
- 2. `server` 會同意 `TCP connection from client`
- 3. `HTTP messages` 可以開始交換於 `browser(HTTP client)` 與 `Web server(HTTP server)` 之間
- 4. `TCP connection` 關閉
`HTTP` 的每次連線皆為獨立，不會每一次維持一樣的狀態與資訊
- `HTTP`是`WEB`的應用層`protocal`，`browser & server` 組成
- `browser & server` 透過交換 `HTTP`訊息(請求與回應) 來通訊。
- `HTTP` 定義了訊息的結構、交換流程與規則
- 一個網頁由多個物件組成，每個物件都有唯一的 `URL`
- `HTTP` 使用 `TCP` 為底層傳輸協定
- 用戶端與伺服器透過 `socket interface` 與 `TCP` 互動
- `HTTP` 不會記錄用戶端的狀態資訊，每次請求都獨立處理
- 這讓 `HTTP` 簡單、可擴展，但也沒辦法記住用戶登入狀態(使用Cookie解決)

#### Non-Persistent HTTP
- 1. `TCP` 連線開始
- 2. 最多只傳送 <font color="#f00">1</font> `object`
- 3. `TCP` 連線關閉
- 當要下載數過 `objects`時，就要 `request` 數次
- **RTT**: 封包從 `client` 到 `server` 再回到 `client` 的時間
- 建立 `TCP` 聯繫需要一個 `RTT`
- `HTTP` 請求/回應 需要一個 `RTT`
- `Non-Persistent HTTP` 總回應時間 ~= 2個 `RTT` + 伺服器傳送資料的時間


#### Persistent HTTP
- **Non-Persistent vs Persistent**
- `non-persistent` : 每個請求/回應用一個新的 `TCP` 聯繫，傳送完即關閉
- `persistent` : 多個請求/回應可共用同一條 `TCP` 聯繫，減少連線建立/關閉的開銷
- 1. `TCP` 聯繫開始
- 2. 在一次 `TCP` 連線中傳遞 <font color="#f00">數個</font> `objects`
- 3. `TCP` 連線關閉
- 支援 `pipelining` :可以連續發送多個請求，不需等待前一個回應。
- `HTTP/2`
- 多個請求/回應可以在同一個連線中 交錯傳送 `mulriplexing`
- `persistent HTTP transmission` = 一次的 `RTT`(開啟 `connection`)+每個 `objects` 的 `request / receive` 的 `RTT` + `file transmission time`

#### HTTP Request Message(ASCII)
- 1. `HTTP` 請求訊息結構
- 請求行: 方法、`URL`、`HTTP` 版本
- 標頭行: `Host` 、 `Connection`、`User-agent`、`Accept-language` 等
- 實體主體:通常用於 `POST` ，包含表單資料。
- 2.常見`HTTP`方法
- `POST`:提交資料，請求處理，資料放在實體主體，適合傳送大量或敏感資料
- `GET`:1.請求展示指定資源2.指應用於`request data`，資料附在 `URL` ，適合查詢
- `HEAD`:`request`與 `get`的 `response`，但沒有 `response message`中的 `body`
- `PUT` : 更新 `server` 的 `object`(可能會被管理員關閉此權限)
- `DELETE`:刪除資源
- 3.標頭行的用途
- `Host`: 指定主機，支援`virtual host`跟 代理快取
- `Connection`:控制連線是否持久
- `User-agent`:告知伺服器用戶端類型
- `Accept-language`: 內容協商，指定語言偏好


#### Response Status Codes
- `HTTP response`
- 狀態行:協定版本、狀態碼、狀態訊息
- 標頭行:如 `Connection` 、 `Date` 、`server` 、`Last-Modified`、`Content-Length`、`Content-Type`
- 實體主體
- 常見狀態碼
- `200 OK`: 成功
- `301 Moved Permanently` : 永久搬移
- `400 Bad Request` : 請求錯誤
- `404 NotFound` : 找不到資源
- `505 HTTP Version Not Supported`: 不支援的 `HTTP` 版本
- 標頭行的用途
- `Connection` : 控制連線是否持久
- `Date` : 回應產生時間
- `Server` : 伺服器資訊
- `Last-Modified` : 物件最後修改時間(`cache`)
- `Content-Length`:物件大小
- `Content-Type` : 物件型態 (`text/html`)
#### Cookie
- `Cookie` 由四個部分組成
- HTTP回應訊息中的`Set-cookie:`標頭行
- HTTP請求訊息中的`Cookie:`標頭行
- 由使用者瀏覽器管理、儲存在用戶端的Cookie檔案
- 網站後端的資料庫
- 流程:
- 用戶第一次造訪網站，伺服器產生唯一識別號，並回應中 `Set-cookie header` 傳給瀏覽器
- 瀏覽器將識別號存入本地 `Cookie file`
- 之後每次請求，瀏覽器自動在 `HTTP` 請求中加入 `Cookie header`傳送是別號給伺服器
- 伺服器可根據識別號查詢/更新後端資料庫，追蹤用戶行為。


#### Web Caching(aka Proxy server)


`Client` 發出 `request` 時，會先傳給 `Proxy`，如果欲拿到的 `objects` 已曾經 `cached` 在 `proxy` 中，則會直接從 `proxy` 傳遞那些 `objects` 如果沒有才會 `request origin server`
- 1. 減少 `request` 時間， `proxy` 比較靠近 `client`
- 2. 比較便宜，若今天因為網路頻寬不足導致 `queueing`，`solution 1`:換大一點的頻寬與網速，但太貴了若是能在我們自己的 `LAN` 建立一個 `Proxy server`，假設 `cache hit rate` 不低，可以大大減少使用 `LAN` 至 `Internet` 的頻寬。
- `cache effect`
- 降低回應時間
- 減少對外流量
- `Traffic Intensity` ~1 時，延遲會暴增，透過提升 `cache hit rate` 可以降低延遲
- `CDN` 透過全球分布式快取，將內容推進用戶，進一步提升效能


#### Conditional GET
- `cache` 可能拿到過時的資料
- `Conditional GET` 能讓 `cache` 問伺服器我的副本還是最新的嗎?
- 流程
- `cache` 紀錄物件的 `Last-Modified` 時間
- 下次有請求時，`cache` 用 `IF-Modified-Since` 發出條件式 `GET`
- 伺服器比對時間，若物件沒變，回應 `304 Not Modified`，快取直接回傳本地副本
- 若物件有變，伺服器回傳新物件，快取更新副本(如果不一樣，則會再將objects放入body傳回給client(status為200 OK).)

#### HTTP1.1 vs HTTP/2
- **HTTP/2**
大致上都跟 `http1` 差不多，但傳輸有著較大的不同，`http1.1`在傳送`objects` 時有著 `FCFS(first-come-first-service)`，所以當有很大的 `object` 在 `TCP` 傳遞時，後面的小`objects` 都會因為前面大 `objects`的傳送而被堵住，稱為 `Head of Line(HOL) blocking`，而`http/2` 大大改善了這一點， `http/2 divide objects into frames`然後再 `schedule frames` 像是 `Round Robin`。


**HTTP/3 **: `Http/3 adds security, per object error- and congestion control (more pipelining) over UDP`

### Email
**SMTP(Simple Mail Transfer Protocal**
`user agents, mail servers(mailbox, message queue)`
`The client SMTP will establish a TCP connection to port 25 at the server SMTP`
- 1.無論是傳遞信件，或是接受信件皆由 `SMTP server` 完成，而不是透過個人電腦
- 2.`three phase of transfer`
- 1. `SMTP handshaking(greeting)`
- 2. `SMTP transfer of message`
- 3. `SMTP closure`
- 3. `commands` : `ASCII text`
- 4. `response` : `status code and phrase`


#### mail server
- `mail server`裡面含有 `message queue & mail box`，`mail server`就像郵局可以幫忙大家收信，大家想要寄出的信件會排入 `message queue` 裡等待送出，而 `mail box`則是存入被寄件用戶們的信件，用戶可以利用 `user agent` 查看信件、刪除信件。
-

#### SMTP vs HTTP

- `SMTP` 是 <font color="#f00">push protocal</font> ，即`TCP`連線是由想要送出檔案的主機所建立
- `HTTP` 是 <font color="#f00">pull protocal</font> ，即`TCP`連線是由想要接收檔案的主機所建立
- 1. `both have ASCII command/response interaction, status codes`
- 2. `HTTP : each object encapsulated in its own response message`
- 3. `SMTP : multiple objects sent in multipart message`
- 4. `SMTP uses persistent connection`
- 5. `SMTP 只能用7-bit ASCII`
- 6. `SMTP 用"."做結尾`
#### Mail access protocol
- `SMTP`
- `IMAP`(比`SMTP`更多功能)
- `HTTP`(`gmail、hotmail`)

### DNS services
- 將主機名稱轉換為IP位址（最主要功能）
- **host aliasing**(主機別名):一台主機可有多個別名(當然也有正規主機名稱 `canonical hostname` 通常不好記)
- **Mail server aliasing**:`Mail server` 的正規主機名稱可能不好記，可以給別名，`dns`可由別名找出正規的主機名稱即`ip`
- **Load Distribution**:有些網站由許多伺服器組成，每個都有屬於自己的 `ip` ，`dns`可以將所有該網站的伺服器 `ip` 都對上同一個 `host name`，這樣就不會讓所有的 `request` 都集中在一台伺服器處理，而是可以分散出給所有電腦處理
- 1. 主機識別方式
- 主機名稱（hostname）：易記，適合人類
- IP位址：固定長度、階層結構，適合路由器與網路設備
- 2. DNS運作流程
- 應用程式（如瀏覽器）先查詢DNS取得IP位址，再與目標伺服器通訊
- DNS查詢會增加延遲，但快取可大幅減少查詢次數與延遲
- 3. DNS的架構
- 分散式資料庫，層級式伺服器架構
- 應用層協定，運作於UDP 53埠
### DNS server arch
- `DNS server` 是 `distributed and hierarchical` 的 `database`
- 集中式無法擴展，單點故障、流量過大、延遲高、維護困難
- 分散式、階層式能分攤負載、提升可靠性與效率
- 
- **root**:`Root name servers provide the IP addresses of the TLD servers.`提供TLD伺服器資訊
- 
- **TLD(Top Level Domain)**:提供授權DNS伺服器資訊
- `such as com, org, net, edu, and gov, and all of the country top-level domains such as uk, fr, ca, and jp. TLD servers provide the IP addresses for authoritative DNS servers.`
- **Authoritative**:提供最終主機名稱對應的IP位址
- `Every organization with publicly accessible hosts (such as Web servers and mail servers) on the Internet must provide publicly accessible DNS records that map the names of those hosts to IP addresses.`

- **Local DNS server(another important type)**:用戶端的代理，負責快取與查詢轉發
- `Each ISP has a local DNS server (also called a default name server). Local DNS server`通常會是個非常靠近使用者的`dns`伺服器，也通常會是預設的伺服器。每當`local dns` 沒有找到你要的網域名稱，才會去`root`找，找完再將結果存起來供下一次可以快速地尋找。

### Iterated vs recursive query
#### Iterated query**:
本地DNS伺服器幫用戶端查到底

#### recursive query:
每層只回應下一步該找誰

### DNS caching
`dns` 可以 `caching` 一些已查過的 `IP` ，這可以大大的加速 `response time`，但這是有時效限制的
- `Cache entries timeout(disappear) after some time(TTL)(time to live).`
- `TLD servers typically chased in local name servers.`
- 1. DNS快取的運作原理
- 儲存機制：DNS伺服器將收到的查詢結果（主機名稱→IP位址對應）暫存在本地記憶體
- 回應機制：當收到相同查詢時，直接從快取回應，無需重新查詢
- 適用範圍：任何DNS伺服器都可快取，包括本地DNS、TLD、授權DNS伺服器
- 2. 快取的效益
- 大幅降低延遲：避免重複的多層查詢，直接從本地快取回應
- 減少網路流量：減少DNS查詢訊息在網際網路上的傳輸
- 降低伺服器負載：減少對根、TLD、授權DNS伺服器的查詢壓力
- 提升整體效能：讓DNS系統更快速、有效率
- 3. 快取的生命週期（TTL, Time To Live）
- 有時限性：快取資料會在指定時間後過期（通常2天）
- 原因：主機名稱與IP位址對應會變動（如伺服器搬移、負載平衡）
- 4. 快取層級效應
- 本地DNS快取：最常用，直接服務用戶端查詢
- TLD快取：讓本地DNS可跳過根DNS伺服器查詢
- 根伺服器被繞過：因為TLD資訊被廣泛快取，根伺服器實際使用率很低
- 5. 快取策略
- 積極快取：任何收到的DNS資訊都儘可能快取
- 智慧快取：根據查詢頻率決定快取優先級
- 分層快取：不同層級的DNS伺服器都有快取功能

第一次查詢 cnn.com：
用戶端 → 本地DNS → 根DNS → .com TLD → cnn.com授權DNS
（完整查詢鏈，8個訊息）

幾小時後再次查詢 cnn.com：
用戶端 → 本地DNS → 直接回應（從快取）
（只需2個訊息）

### DNS Response & Records
`Resource records(RR) format` : `(name, value,type,TTL)`

- **Type=A**:
- `name`是 `canoncial` 主機名稱， `value` 是 `canoncial`主機名稱為 `name`的 `IP address`
- `(ex:relay1.bar.foo.com , 145.37.9.126 , A)`
- **Type=CNAME** :
- `name` 是主機的 `alias` ， `value` 是 `alias` 為 `name` 的正規主機名稱
- `ex:(foo.com , relay1.bar.foo.com ,CNAME)`
- **Type=NS** :
- `name` 是 `domain`，`value` 是該 `Authoritative DNS server` 名稱 (此`Authoritative(官方) DNS server`會去取得該網域內的主機ip位置)
- `ex:(foo.com , dns.foo.com , NS)`
- **Type=MX**
- `name` 是主機別名，`value` 是該 `mail server` 的正規名稱
- `ex:(foo.com , mail.bar.foo.com , MX)`
- `TTL` : `control caching time，balance effect & data新鮮度`
- DNS訊息設計
- 統一格式：查詢與回應使用相同格式，簡化協定設計
- 識別碼機制：讓用戶端能配對查詢與回應
- 旗標系統：提供豐富的控制選項（遞迴、授權等）
- 分區設計：問題、回答、授權、額外四區段滿足不同需求
- DNS註冊流程
- 分層管理：註冊商管理TLD層級，組織管理授權層級
- 記錄分布：NS和A記錄在TLD伺服器，Web/Mail記錄在授權伺服器
- 自動化流程：現代DNS支援動態更新，減少手動設定
- DNS安全考量
- 分散式優勢：多伺服器架構提供天然的容錯能力
- 快取防護：快取機制減少對上層伺服器的依賴
- 攻擊困難度：大規模攻擊需要巨大資源，且效果有限
- 持續演進：DNS安全機制不斷改進（如DNSSEC）
### Peer-to-Peer
- **client server**
- 中央伺服器承擔所有服務負載
- 需要永遠在線的基礎設施
- 頻寬需求隨用戶數線性增長
- 單點故障風險
- **P2P**
- `Pros`:大量user有資料需求，不會導致server崩潰，因為每個peers可以是server，也可以是client。具有scalability。
- `Cons`:管理複雜
### P2P file distribution
每個`peer`都可以提供自己的`capacity`來幫助`server`來`distribute` 檔案，不同於`client-server`的模式，在分配檔案時，`server`不需要`copy`每一份檔案給`peers`，反之，只要其中一個`peer`擁有檔案之後便可以透過此`peer`重新再分配檔案到其他`peers`。

**Client-Server arch傳輸時間**

**P2P arch傳輸時間**

**兩者比較**


**BitTorrent**
會將資料切成256kb為單位的chunks。
而在torrent中的peer可以互相傳遞對方所需或是自己所需的chunks(資料的一部分)。
每個peer不需要擁有整個資料，也能湊出一個完整的資料給有需求的peer。

Tracker : tracks peers participating in torrent
Torrent : group of peers exchanging chunks of a file

user可以透過向tracker註冊成為torrent裡的peer，
tracker會整理大家的IP，在需要的時候傳遞給有需求的peer做TCP connection。
當user獲得了想得到的檔案後，可以選擇selfishly的脫身，
也可以altruistically選擇留下來，將資料上傳給其他有需要的peers。

tit-for-tat(針鋒相對):
peer可以選擇性的貢獻，但假如一昧地享有資源而不貢獻，可能會被其他peers報復。
相對地，願意分享的，其他peers也相對會願意跟她分享。

Optimistically unchoke :
每隔10秒鐘，節點就會給那些對自己所擁有的文件塊感興趣的節點進行評估，從而決定它向哪些節點傳遞數據(預設的配置是允許同時最多給4個節點發送數據)。根據tit-for-tat演算法，節點會優先選擇那些向自己上傳數據速率最快的節點，同時阻塞所有其它的鄰居節點。為了提高整體性能，BT還採用了一種叫做“Optimistic unchoke"的演算法。也就是除了上述的四個節點之外，它還會在其它的節點中隨機選取一個節點向其傳遞。

### Video Streaming
`CDN : Content delivery network`
#### Multimedia video
會利用影片特別的編碼來降低冗餘的bits，
Spatial : 假如圖片中有一欄或一列重複的位元，會用類似(N*red)來代替N個3byte的儲存。
Temporal : 因為影片中圖與圖中常有重複的地方，則只需要儲存有更改的地方的資訊就好。

CBR : Constant bit rate ，有固定的編碼方式，每秒的資料大小固定。
VBR : Variable bit rate ，會藉由Spatial與Temporal等方式編碼，bit per sec不固定。

#### Streaming stored video
`During client video playout, playout timing must match original timing.`
但network delay是variable的(直接播放的話，可能突然delay變大就轉圈圈了)，所以必須要client-side buffer與playout delay。


DASH : Dynamic, Adaptive Streaming over HTTP
Server : server會將影片分割為好幾個chunks，並且會編碼成不同rate(畫質影像速率，畫質越高，速率越快)，並將檔案(分rate版本或是平均地)放進不同的nodes中，並提供不同chunks的URLs。
Client (決定方) : 定時測量CS間的頻寬，並選擇最符合的coding rate傳送，或是user可以自己決定要用哪一種畫質(rate)。
而Client的選擇是有intelligence的，
他需決定

- 1.when to request(避免buffer滿了)
- 2.what encoding rate to request(找出最符合CS之間頻寬的畫質)
- 3.where to request(越近越好，或是傳遞頻寬越快越好)

`Streaming video = encoding + DASH + playout buffering`

**CDNs**
不建議Content provider使用single server，因為一但該server毀了就全毀了，然後也會造成擁塞，CS距離長短不一。

CDN分散式架構有兩種 :

**enter deep : push CDN servers deep into many access networks (close to user) (設大量的servers在access network(Ex:區域網路))**

**bring home : smaller number of larger cluster (約10個) in POPs (point-of-presence) near access nets (設少量servers在網路連接點)**

入網點（POP，point-of-presence）是一個將網際網路從一個地方接到其他地方的存取點。POP必需有一個唯一的網際網路協定（IP）位址。

subscriber會先request Netflix的server，然後Netflix會request 該影片的manifest。
使用者再利用manifest去 CDN nodes上取得影片，並且挑選喜歡的畫質。

**OTT : "Over The TOP media services"**
OTT不需去建構與管理底層網路連線(皆是由ISP管理)，所以需要跟ISP簽約買頻寬，甚至協調(因為有時候可能是OTT業者server建置不夠，使user卡卡的，但user都會跑來罵ISP業者)。

### URL vs. URI
URL 是路徑，URI 是資源實際位置。
URI：localhost:80/user/save
URL：localhost:80/user
很清晰的就能看出要想找到 URI，必先找到它的 URL，這也就解釋了 URL 是 URI 的子集是啥意思了。只找到 URL 是不知道要做什麼的，只有找到 URI 才知道資源是啥，要幹些什麼事情。

## 計算機網路ch3
`socket`:一種 `OS` 提供的 `process` 通訊機制，應用層可以透過 `API socket` 來使用網路`socket`，以進行資料交換
### Transport service and Protocal
`Transport layer` 提供了應用層裡 `process` 在不同 `host` 中的 `logical communication`.
`Sender` 會將應用層的 `message` 切成一塊一塊的 `segments`，並往網路層傳送。
`Receiver`則會將`segment`重組為`message`，並往應用層做傳輸。

可以把 `host` 比喻為一個家，而 `process` 就如同家裡的 `kids`, `app messages` 就是信封裡面的 `letters` 。
當今天小孩們(`process`)要互相傳遞信件給對方，小孩們會先將信封交給`Ann`(老大)，藉由他們將信件拿到郵局寄，郵局再將信封傳遞到另一個家庭，`Bill`(老大)則將信封依照姓名(`port number`)發給小孩們(`processes`)。

**Network Layer: logical communication between <font color="#f00">host</font>**

**Transport Layer: logical communication between <font color="#f00">process</font>**

**TCP vs. UDP**
- `TCP`
- 1.可靠的，按照順序的傳輸
- 2.有 `congestion control`
- 3.有 `flow control`
- 4.有連線建立
- `UDP`
- 1.不可靠的，傳輸不會按照順序
- 2.只要收到資料就盡全力的傳輸
- 兩個 `protocal` 皆不包含 `delay` 保證 與 頻寬保證 等等。

### Multiplexing/demultiplexing
#### multiplexing at sender
multiplexing at sender:
收集多個`socket`的資料，用`header`(稍後將用在 `demultiplexing`)將每個`messager`片段封裝成`segment`。
demultiplexing at receiver:
利用`header`的資訊去傳遞`received segment`到正確的 `socket`。
#### How demultiplexing works
`host receive IP datagrams`，每一個 `datagram` 都有 `source IP` 跟 `destination IP`，每個 `datagram` 也會包含一個 `segment`，每一個 `segment`都會包含一個 `source port number` 跟 `destination port number`。

#### Connectionless Multiplexing and Demultiplexing
- `UDP socket`
- 當我們要傳送資料時，會先建立一個有標明 `host-local port number`的 `socket`(以`port number`去產生`socket`)
- `UDP socket`由兩個 `component` 組成: `dest ip` 、 `dest port number`
- 利用 `IP` 與 `port number` 去識別 `UDP socket`
- `data transmission`
- 當建立 `Datagram` 傳進 `UDP socket`，必須標明 `IP address` 、 `port number`
- 不同來源的 `source port number`或 `IP address`，只要是同一個 `dest IP address` 與 `port number`，就都會傳入同一個 `socket`
- `receive & multiplexing`
- 當 `host` 收到 `UDP segment` 時會透過`segment`的 `dest port number` 將 `segment` 送到指定的 `socket`
- `OS` 根據目標的`port number`自動進行 `demultiplexing`
- `UDP` 在 `demultiplexing` 時只有使用到 `dest port number`
#### Connection-Oriented Multiplexing and Demultiplexing
- `TCP socket` 有四個 `component`
- `source IP address`
- `source port number`
- `destination IP address`
- `destination port number`
- `TCP demultiplexing`
- `receiver` 利用以上四個 `element` 去傳送 `segment` 到指定的 `socket`
- 與`UDP`不同，`TCP`需要完整的四個 `element` 才能正確`routing`
- 即使目標`port number`一樣，不同來源的連線會建立不同的 `socket`
- 多連線支援
- 當有很多個 `segment` 指定要到同一個 `dest port number`
- `server` 會支援可以同時使用許多`TCP socket`

### Connectionless Transport: UDP
- `No Connection`
- 可以省去建立連線時的`RTT delay`
- UDP在發送`segment`之前沒有`handshaking`
- UDP被稱為無連線的 (`connectionless`)
- TCP需要`handshaking` (`1.5 RTT`)，UDP直接發送 `(0 RTT)`
- 這是 `DNS` 在 `UDP` 而不是 `TCP` 上運行的主要原因 - `DNS` 如果在 `TCP` 上運行會慢得多
- `Simple`
- 沒有連線狀態
- `UDP`不維護連線狀態，也不追蹤任何參數
- 不需要接收和發送緩衝區、擁塞控制參數、序列號和確認號參數
- 專用於特定應用程式的伺服器通常可以支援更多活躍用戶端（當應用程式在`UDP`而不是`TCP`上運行時）
- 每個`UDP`封包都是獨立處理的
- `Small Header Size`
- `TCP segment` 在每個 `segment` 中有`20`位元組的標頭開銷
- `UDP` 只有`8`位元組的開銷
- `UDP` 標頭開銷比 `TCP` 少`60%`
- 更適合小訊息和頻繁通訊
- `No Congestion Control`
- `UDP`不會管接收端的接收狀況，他會一直拼命的快速傳遞
- 導致常常可能`packet loss`，但 `UDP` 不會有 `congestion` 的問題
- 可以利用這點來處理 `congestion` 的問題
- 提供對發送什麼資料以及何時發送的更精細應用層控制
- 一旦應用程序將資料傳遞給 `UDP`，`UDP` 將立即將資料打包並立即傳遞給網路層
- `TCP` 的擁塞控制機制會在網路擁塞時限制發送者，而 `UDP` 不會
#### UDP application
- `DNS (Domain Name System)`
- 即時應用程式 `(Real-time Applications)`
- `VoIP` (網路電話)
- 即時視訊會議
- 線上遊戲
- 即時串流
- 網路管理
- `SNMP (Simple Network Management Protocol)`
- 多媒體應用程式
- 網路電話
- 即時視訊會議
- 儲存音訊和視訊的串流
#### 下層沒有的服務，UDP要在上層自己家
- `add needed reliability at application layer(QUIC protocol)`
- `add congestion control at application layer`

#### UDP trasmission
- `sender action` :
- `application layer` 會送 `message` 下來
- 決定 `UDP segment` 的 `header` 要放什麼
- 建立 `UDP segment`
- 將 `segment` 往 `Network layer` 送
- `receiver actions`
- 由 `network layer` 拿到 `segment`
- 進行 `UDP checksum`
- 取出應用層的 `message`
- 藉由 `socket` 將 `message demultiplexing to application layer`

#### UDP structure

#### UDP checksum
**Purpose** : 為了偵測傳遞時是否有傳遞錯誤
- `Sender check & calculate`
- 資料分割
- `sender` 會將 `segment` (包含 `UDP header` & `Ip address`)分成一列一列(一列 16-bit)
- 如果長度為奇數，尾巴會補 `0`
- 累積計算
- 全部做相加使用 `hex` 加法逐一累加所有 `16 bit`。
- `overflow`
- 若有`overflow`會再將 `overflow` 與 `sum` 做相加
- 採用 `warp - around`
- 補數轉換
- 最後再取 `1` 補數 作為 `checksum`
- 插入標頭
- `checksum value` 會放在 `UDP header`
- `Receiver check & verification`
- 重新計算
- `Receiver` 收到 `segment` 後，會先計算收到的 `segment` 的 `checksum`
- 使用 `sender` 相同的方法計算收到資料的 `checksum`
- 計算範圍包括 `UDP header & data & Ipv4 pseudo header`
- 比對驗證
- 是否與 `header` 中的 `checksum` 相符
- 錯誤判斷
- 相符:應該沒有 `error`
- 所有16位元字加上校驗和的總和應該是 1111111111111111
- 實際上還是有可能會有，因為加法不是一個很好的方式
- 某些特定模式的錯誤可能無法被檢測出來
- 不相符:偵測到 `error`
- 如果總和中有任何一個位元是0，表示檢測到傳輸錯誤



### Principles of reliable data transfer
- 基本目標： 提供可靠通道服務給上層
- 無資料損壞 (位元不會翻轉)
- 無資料丟失 (封包不會消失)
- 有序傳遞 (按發送順序到達)

可靠通道 = 完美的管道，提供：
1. 無資料損壞（位元完整性）
2. 無資料丟失（傳輸完整性）  
3. 有序傳遞（順序完整性）

理想狀況：上層 ←→ [可靠通道] ←→ 上層
現實狀況：上層 ←→ [RDT協定] ←→ [不可靠通道] ←→ [RDT協定] ←→ 上層


#### RDT 1.0
`rdt1.0` 使用完全可靠通道的可靠傳輸(最理想但不現實)
- 特性
- 沒有 `bit error` : `bit` 不會在傳輸過程中翻轉或損壞
- 沒有 `data loss`
- `protocol design`
- 簡化設計:底層通道完全可靠
- 發送端：接收上層資料 → 封裝成封包 → 直接發送
- 接收端：接收封包 → 提取資料 → 傳遞給上層
- 無需任何錯誤處理機制 - 因為不會發生錯誤
- 無需回饋機制 - 因為傳輸必定成功
- 無需重傳機制 - 因為不會有封包丟失

#### RDT2.0
`rdt2.0` 是具有位元錯誤通道的可靠傳輸
- 特性
- 會發生 `bit error`:位元可能在 `transmission` 、`routing`或儲存過程中被損壞
- 沒有 `packet loss`
- 保持順序:`packets` 按照發送順序到達
- `Automatic Repeat Request` 引入
- 錯誤檢測：
- 在封包中加入校驗和 `(checksum)`
- 接收端計算校驗和檢查封包是否損壞
- 確認回饋系統：
- `ACK (Acknowledgment)`- 正面確認，表示封包正確接收
- `NAK (Negative Acknowledgment)` - 負面確認，表示封包有錯誤
- 接收端根據校驗和結果發送`ACK`或`NAK`
- 重傳機制：
- 當收到`NAKs`時，會重新傳送封包
- 發送端等待`ACK`才會發送下一個封包
- 收到`NAK`時重新傳送相同封包
- 停止等待協定：
- 發送端必須等待確認才能繼續 - 確保每個封包都被正確接收
- 一次只能有一個封包在傳輸中 - 簡化錯誤處理
- 不會發送新資料直到當前封包被確認 - 保證可靠性
- 接收端：檢查校驗和
- 無錯誤 → 發送`ACK` + 傳遞資料給上層
- 有錯誤 → 發送`NAK` + 丟棄封包
- 發送端：
- 收到`ACK` → 發送下一個封包
- 收到`NAK` → 重新傳送當前封包
- `ACK/NAK`封包本身也可能損壞

#### RDT2.1
`RDT 2.1` - 改善`2.0`致命的缺點 –`ACK/NAK`有可能會損毀`(garbled、corrupted)`
- 重傳策略：
- 如果`ACK/NAK`損壞了，傳送端會重新傳送封包
- 採用簡單的重傳解決所有不確定情況
- 序號機制：
- 傳送端會在每個封包加上`sequence number`
- 使用`1`位元序號（`0和1`交替）區分不同封包
- 重複處理：
- 接受端會刪掉重複`(duplicate)`傳遞的封包
- 透過檢查序號識別重複封包
- 協定特性：
- 停止等待協定 - 一次只處理一個封包
- 雙向確認機制 - 同時使用`ACK`和`NAK`
#### RDT2.2
`rdt2.2` -`only ack protocol`
- 明確序號確認：
- 接受端須明確地加上經過確認封包的序號
- `ACK`訊息包含被確認封包的序號（`ACK,0 或 ACK,1`）
- 重複`ACK`等同`NAK`：
- 傳送重複序號的`ACK => NAK`，會重新傳送封包
- 發送端收到同一序號的重複`ACK`時，知道下一個封包傳輸失
- `Pros`
- 簡化協定設計 - 只需要一種確認類型
- 減少訊息種類 - 降低協定複雜度
- 同樣的可靠性保證 - 功能等同於`RDT 2.1`

#### RDT3.0
由於底層頻道可能會遺失封包，所以利用`timer`來倒數計時
- 封包可能完全丟失 - 不只是損壞，而是消失
- `ACK`也可能丟失 - 確認訊息也會遺失
- 需要檢測丟失並恢復 - 沒有訊息比收到錯誤訊息更難處理
- 超時重傳機制
- 計時器機制：
- 時間內，無收到`ACK`，會重傳封包
- 發送端為每個封包設定超時計時器
- 超時後自動重傳，不等待確認
- 重複處理增強：
- 忽略掉`duplicate`的封包或`ack`
- 處理因超時重傳造成的重複
- 序號機制有效識別重複內容
-

#### Pipelined protocols
可以同時傳遞多個還沒有被確認的 `packet`
- `Range of sequence numbers must be increased` - 序號範圍擴大
- `Buffering at sender and/or receiver` - 發送端和接收端緩衝
- `Two generic forms: go-Back-N, selective repeat` - 兩種錯誤恢復策略
- `Utilization`稍好一點(EX:增加3倍) - 大幅提升網路利用率
- 解決停止等待協定的效能瓶頸
- 

#### GO-BACK-N
- `sender`
- 大小最多為 `N` 的 `window`、允許連續的(`consecutive`) 未被確認的封包
- 滑動視窗機制，隨著`ACK`收到而向前移動
- 
- `comulative ACK`
- 確認小於或等於序號n的所有封包
- 一個`ACK`可以同時確認多個封包，提高效率
- `timer`
- `Timer for oldest in-flight packet`
- `Timeout(n):retransmit packet n and all higher seq# packets in window`
- 超時回退重傳所有未確認的封包
- `Receiver`
- 只使用 `ACK`
- 只接受 `in-order seq# packet & transmitt ACK`
- 只需記住`expectedseqnumber`
- 處理 `out-of-order packet`
- 刪除(沒有`buffer`)順序亂掉的 `packet` -> `receiver no register`
- `reACK packet with highest in-oreder seq number`
- 回傳最近成功接受的按順序的`packet ack`

#### Selective Repeat(SR)
- `Receiver`
- `Receiver individually acknowledges all correctly received pkts`
- 具備緩衝能力，可暫存亂序到達的正確封包，等待缺失封包後批次向上層傳遞
- `Sender`
- `Sender only resends pkts for which ACK not received`
- `sender timer for each unACKed pkt`
- `sender window`
- `sender window` :`N consecutive seq #'s `
- `Again limits seq #s of sent, unACKed pkts`
- 維持固定大小的滑動視窗，控制同時在網路中的未確認封包數量
- `Pros`
- 最佳化重傳效率
- 提升網路利用率
- 精確的錯誤恢復
- `Cons`
- 接收端需要複雜的緩衝管理
- 發送端需要多個計時器
- 視窗大小限制

### TCP(connection-oriented transport)

- 連接特性
- `point to point(one sender, one receiver)`
- `connection-oriented(handshaking init sender, receiver state before data exchange`
- `full duplex data`
- 可靠度保證
- `Reliable, in-order byte stream`
- `flow control`
- 效能
- `pipeline(TCP congestion and flow control set window size)`
- `Send&receive buffers`
- `Three-way Handshake`
- 客戶端發送特殊 `TCP` 段 (請求建立)
- `server` 回應第二個 `TCP` 段 (確認並回應)
- `client`發送第三個特殊段 (最終確認)
- `TCP transmission`
- `buffer system`
- `sender buffer` : `Three-way handshaking setup,tmep stroe data`
- `receiver buffer` : `tmp store receive data,application read receiver buffer data`
- 連接兩端各自維護自己的 `buffer`
- `transmission topology`
- `TCP` 可在方便時機發送緩衝資料
- `MSS(Maximum Segment Size)`:控制單一段的最大資料量
- `MSS setup`
- 基於`MTU(maximum transmission unit)`
- 確保 `TCP` 段 + `IP header` <= `link layer` 大小
- `TCP`序號與確認號機制
- `Sequence Number`
- `Segment`的`sequence number`是`data`內第一個`byte`的`sequence number`
- or 要傳出的`segment's data`裡第一個`byte`在`byte stream`裡的`number`
- `Acknowledgment Number`
- `ACK is the sequence number of the next byte of data that the host is waiting for`
- 另解：下一個預期會從另一端收到的第一個`byte`的`seq #``

- `byte stream view`
- TCP將資料視為無結構但有序的位元組流
- 序號基於位元組而非段
- 支援累積確認機制
- `TCP structure`
- 32位元序號欄位 - 標識段中第一個位元組的序號
- 32位元確認號欄位 - 指示期望接收的下一個位元組序號
- 16位元接收視窗欄位 - 用於流量控制
- 校驗和欄位 - 錯誤檢測
- 標誌欄位 - 包含ACK、SYN、FIN、RST等控制位元
- 資料欄位特性：
- 包含應用層資料塊
- 大小受MSS限制
- 大文件會分割成多個MSS大小的段

- `Telnet` 案例研究 - 互相傳遞"CIA" (必考)
- Echo Back機制：
- 每個字符從客戶端發送到伺服器
- 伺服器回音每個字符給客戶端
- 字符在網路中往返兩次才完成顯示
- 序號與確認號追踪： 以起始序號為例（客戶端42，伺服器79）：
- 字符傳輸過程：
- 客戶端發送字符 - 序號標識資料位置
- 伺服器確認並回音 - 確認號指示下一個期望位元組
- 客戶端確認回音 - 完成一個字符的往返
- 搭載確認 (Piggybacking)：
- 確認資訊搭載在資料段上
- 提高網路效率
- 減少單純確認段的數量
#### RTT & Timeout
- `How to set TCP timeout value： longer than RTT but RTT varies`
- `too short` : `premature timeout & unnecessary retransmission`
- `too long` : `slow reaction to segment loss`
- `how to estimate RTT?`
- `SampleRTT`：測量傳遞到接收確認的時間，不包含重傳
- 測量從段發送到收到確認的實際時間
- 重傳的段不納入`SampleRTT`計算
- 由於`SampleRTT will vary`，所以需要做點平均讓他平滑

`EstimatedRTT` 計算： 使用指數加權移動平均 ``(EWMA)`` 平滑`SampleRTT`變動：

EstimatedRTT = (1-α) × EstimatedRTT + α × SampleRTT

`DevRTT` 變異性測量： 測量`SampleRTT`偏離`EstimatedRTT`的程度：

DevRTT = (1-β) × DevRTT + β × |SampleRTT - EstimatedRTT|

`TimeoutInterval` 最終計算：

TimeoutInterval = EstimatedRTT + 4 × DevRTT


#### TCP sender


#### TCP fast retransmit

當中間有封包遺失，`receiver`會接受到不符合預期的封包，`receiver`會`send`重複的`ACK`(原先預期的封包)。當`sender`收到3次重複的`acks`時，他不會等`timer`，還是直接重傳。

#### TCP flowcontrol
在傳輸層中有`TCP socket receiver buffers`，用來暫存網路層傳來的資料，與讓應用層存取並刪除資料。
但我們必須做流量控制，不然可能會因送太快，應用層來不及拿走，`buffer`就滿到不能再存，進而遺失資料。
透過`TCP segment`結構的`header-receive window`來告訴`sender RcvWindow。`
`RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead]`

### Congestion Control
- 太多`sources`同時傳遞太快且太多資料導致網路無法`handle`
- 會導致較長的`delay`或是封包遺失
- `end-end congestion control`
- 利用推斷`loss`跟`delay`，去得知是否擁塞
- `TCP`採用的方法
- `Network-assitsted congestion control`
- `routers`會直接將擁塞的資訊透過經過的封包告訴傳送端與接收端

#### AIMD
- `additive-increase/multiplicative-decrease`
- 方法
- 將傳送速率再每個`RTT`都增加`1`個`MSS(Max Segment Size`)直到發生`loss`
- 當偵測到`loss`的時候
- 如果是收到到3次重複的`ACK` => `rate/2`
- 如果是因為`timeout` => 降成`1MSS`
#### TCP slow start
- 連線的初期，讓`rate`指數性成長
- 一開始`Cwnd = 1MSS`
- 每個`RTT`都會將`Cwnd*2`
- 每收到`1`個`ACK`，`Cwnd`就會增加一個`MSS`，傳出兩個`MSS`
#### TCP 的 congestion control
- `ssthresh : slow start threshold` 門檻值
- 當 `Cwnd` 低於 `ssthresh，sender`使用`slow start`，指數成長
- 當 `Cwnd` 高於 `ssthresh，sender`會進入`congestion-avoidance`，線性成長
- 當 偵測到`loss`時
- 如果是收到到`3`次重複的`ACK` => `ssthresh`會被設成`Cwnd/2，Cwnd`會設成`ssthresh+3 MSS`
- 如果是因為`timeout => ssthresh`會被設成`Cwnd/2，Cwnd`會降成`1MSS`

## Reference
[計算機網路筆記](https://hackmd.io/@UULi/BkI_5qlEK#%E5%90%84%E5%B1%A4%E7%9A%84%E5%B0%81%E5%8C%85)
[成大電通所-計算機網路講義](https://)
[Computer Network Tutorial
](https://www.geeksforgeeks.org/computer-network-tutorials/)