# 計算機網路 Ch02 - Application Layer

###### tags: `計網`

[]()

:::danger
🛠 施工中
:::

## 2.4 DNS: domain name system

### iterated query

### recursive query

### DNS resource records(RR)

* type=A: hostname/IP address
* type=NS: domain/authoritative server name for this domain
* type=CNAME: alias name/canonical name
* type=MX: mailserver list/names of mailserver

## 2.5 peer-to-peer(P2P)
### P2P 架構

* 沒有一個永遠開機的server
* host和host間直接做連線，不經由server
* peer間會間斷性的連線並更改IP

#### 應用
* File distribution(BitTorrent)
* Streaming(KanKan)
* VoIP(Skype)

### client-server vs. P2P
假設一個情境: server必須將檔案大小為F的檔案，傳送給N個使用者，所需要花的時間是多少?

* **u~s~**: server上傳頻寬
* **d~i~**: 第i個peer下載頻寬
* **u~i~**: 第i個peer上傳頻寬

#### File distribution time: client-server

* server上傳一份檔案要花 **F/u~s~**，上傳N份檔案就要花 **NF/u~s~**
* peer下載速度最慢所要花 **F/d~min~**

#### File distribution time: P2P

* server只需要上傳一份檔案: **F/u~s~**
* peer下載速度最慢所要花 **F/d~min~**
* 檔案的總量還是 **NF**，只不過讓所有的使用者去分擔上傳的頻寬: **u~s~ + Σu~i~**

#### 效能比較

* Client-Server: 呈線性增長。
* P2P: 使用者越多，上傳速度越快。

### BitTorrent

* chunks: 檔案被分割成好幾個 256Kb 的小區段。
* torrent: 由一群peer彼此交換chunk的群集。
* tracker: 追蹤所有torrent中的使用者，以及檔案流向。

但問題來了，如果有人取得完整檔案就離開(自私)的話，就可能導致檔案遺失，因此設計了 **requesting chunks** 和 **tit-for-tat** 機制。

#### requesting chunks
1. 先看其他peer目前所擁有的chunks。
2. 請求獲取最稀少的chunks。

#### tit-for-tat

1. 取寄送chunk給自己最快的前四名成為Top 4 peer(unchoked)，每十秒更新一次。
2. 和Top4交換chunk。
3. 每三十秒寄chunk給隨機一個peer(optimistically unchoked)，有可能成為他的Top4。
4. 其他非Top 4 peer和optimistically unchoked的peer，則稱為choked，這些choked不會接收到來自你的chunk。

## 2.6 video streaming and content distribution networks (CDNs)
影片串流，因應大量觀看影片的需求。

挑戰:
* 巨大的傳輸流量
* 不同裝置間的相容性

解決方法:
* 分散式主機
* 優化應用層

只要黑影的輪廓或者紀錄畫面間的差異就好

每次傳1/24秒的片段
預留5~10秒的buffer，預先載好影片，不會因為網路短暫中斷而導致影片卡住

### DASH: Dynamic, Adaptive Streaming over HTTP
#### server
* divides video file into multiple chunks -> 將影片切割成片段
* each chunk stored, encoded at different rates -> 每個片段分成不同的解析度
* **manifest file**: provides URLs for different chunks -> 提供不同片段和解析度的URL
#### client
* buffer
* periodically measures server-to-client bandwidth -> 依照網路頻寬決定下載的解析度

因此在client端必須知道什麼時候要下載chunk? 下載什麼解析度的? 以及要去哪裡下載? 這就是前面說的**優化應用層**

### Content Distribution Networks (CDNs)
類似proxy的概念，儲存影片的副本CDN節點，從最靠近的CDN節點中取得影片

* enter deep: 放在區域中某個連結網路的server
* bring home: 放在POP

以Netflix為例:


#### over the top(OTT)問題
1. From which CDN node to retrieve content? 離自己最近的
2. Viewer behavior in presence of congestion? 換解析度較低的chunk
3. What content to place in which CDN node? 影片的副本

#### CDN content access(運作方式)