Day5：應用層——CDN、 TCP 套接字程式設計、 UDP 套接字程式設計、小結

加油！偷博人！

0、killer application（殺手級應用）

1.網絡流量占比大

2.最能吸引使用者

比如，Video Application：youtube，tiktok，iqiyi，Tencent movie…

 視訊流量：占據着網際網路大部分的帶寬

 挑戰：異構性

 不同使用者擁有不同的能力（例如：有線接入和移動使用者；帶寬豐富和受限使用者）

 解決方案: 分布式的，應用層面的基礎設施

再來口水話談談視訊：

•  視訊：固定速度顯示的圖像序列。 e.g. 24 images/sec

•  網絡視訊特點：

   高碼率：>10x于音頻,高的網絡帶寬需求

   可以被壓縮

   90%以上的網絡流量是視訊

•  數字化圖像：像素的陣列

   每個像素被若幹bits表示

•  編碼：使用圖像内和圖像間的備援來降低編碼的比特數

   空間備援(圖像内)

   時間備援(相鄰的圖像間)

  例子如下

  

  frame幀

  

0.1存儲視訊的流化服務 （邊下邊看）

多媒體流化服務：DASH

•  DASH: Dynamic, Adaptive Streaming over HTTP（在http之上的動态自适應的流化技術）

•  伺服器:

   将視訊檔案分割成多個塊

   每個塊獨立存儲，編碼于不同碼率（8-10種）

   告示檔案（manifest file）: 提供不同塊的URL

•  用戶端:

   先擷取告示檔案

   周期性地測量伺服器到用戶端的帶寬

   查詢告示檔案,在一個時刻請求一個塊，HTTP頭部指定位元組範圍

   如果帶寬足夠，選擇最大碼率的視訊塊

   會話中的不同時刻，可以切換請求不同的編碼塊 (取決于當時的可用帶寬)

•  “智能”用戶端: 用戶端自适應決定

   什麼時候去請求塊 (不至于緩存挨餓，或者溢出)

   請求什麼編碼速率的視訊塊 (當帶寬夠用時，請求高品質的視訊塊)

   哪裡去請求塊 (可以向離自己近的伺服器發送URL，或者向高可用帶寬的伺服器請求)

  

  了解的太粗糙了，還不太懂

一、CDN （Content Distribution Networks）

 挑戰: 伺服器如何通過網絡向上百萬使用者同時流化視訊内容 (上百萬視訊内容)?

•  選擇1: 單個的、大的超級服務中心“megaserver”

   伺服器到用戶端路徑上跳數較多，瓶頸鍊路的帶寬小導緻停頓

   “二八規律”決定了網絡同時充斥着同一個視訊的多個拷貝，效率低（付費高、帶寬浪費、效果差）

   單點故障點，性能瓶頸

   周邊網絡的擁塞

  評述：相當簡單，但是這個方法不可擴充

•  選項2: 通過CDN，全網部署緩存節點，存儲服務内容，就近為使用者提供服務，提高使用者體驗

  •  enter deep: （一種部署政策“深入群衆”）

    将CDN伺服器深入到許多接入網

    更接近使用者，數量多，離使用者近，管理困難

    Akamai, 1700個位置

  •  bring home: （又一種部署政策“搶注關鍵”）

    部署在少數(10個左右)關鍵位置，如将伺服器簇安裝于POP附近（離若幹1stISP POP較近）

    采用租用線路将伺服器簇連接配接起來

    Limelight

中國藍汛，CDN服務提供商。做内容加速服務 （流媒體點播、實時多媒體，直播、春晚的直播）

1.舉個例子：

Netflix （譯為奈飛或網飛，是一家會員訂閱制的流媒體播放平台）買了Akamai的内容加速服務，對影視MadMen預先部署在緩存節點中（下圖邊緣的黑褐色節點）的。

• 當使用者點播MadMen，（左邊的小房子Where’s MadMen?)
• 然後就會拿到一個告示檔案manifest file。
• 在告示檔案中，就可以知道有哪些部署的節點可以點播。
• 于是優先選擇最近的、網絡擁塞最輕微的、流量較少的、即最優的一個節點，點播視訊（紅色箭頭）

  

在應用層、網絡邊緣來提供網絡加速服務。

2.CDN:“簡單”内容通路場景——一個簡單例子看看CDN的運作

這個圖很亂，我來解釋一下：

①：Bob浏覽netcema.com的網頁，找到一個自己喜歡的小電影（url是http://netcinema.com/6y7b23v ，當然這個url我沒試過是不是真的 ）并且滑鼠點選了。

②這個url去到local name server 名字解析伺服器代理

③然後local name server找到一級一級找到netcinema的權威名字伺服器。權威名字伺服器傳回一個重定向的一條url “http://kKingCDN.com…”告訴local name server “你要再去解析這個url”

④然後local name server去趙KingCDN的權威名字伺服器，得到了離Bob（客戶）the closest 一個cache節點。

⑤于是Bob（用戶端）就從local name server中知道了離自己最近的緩存節點。

⑥Bob 就向這個最近的緩存節點請求dash的流化服務，可以在網頁看小電影了

現在自己在看一張圖

一、TCP套接字程式設計

1.Socket程式設計

1. 應用程序使用傳輸層提供的服務才能夠交換封包，實作應用協定，實作應用

   TCP/IP：應用程序使用Socket API通路傳輸服務

   地點：界面上的SAP(Socket） 方式：Socket API

2. 目标: 學習如何建構能借助sockets進行通信的C/S應用程式socket: 分布式應用程序之間的門，傳輸層協定提供的端到端 服務接口

   

2種傳輸層服務的socket類型:

3.  TCP: 可靠的、位元組流的服務

4.  UDP: 不可靠（資料UDP資料報）服務

2.TCP套接字

套接字： 應用程序與端到端傳輸協定（TCP或UDP）之間的門戶

TCP服務： 從一個程序向另一個程序可靠地傳輸位元組流

3.TCP套接字程式設計

伺服器首先運作，等待連接配接建立

• 1：伺服器程序必須先處于運作狀态

   建立歡迎socket （建立一個socket傳回一個整數，還無意義）

   （再将這個整數）和本地端口捆綁

   在歡迎socket上阻塞式等待接收使用者的連接配接 （如果無人連接配接，則阻塞着）

  （建立捆綁等待 ，這些都是socket api函數）

用戶端主動和伺服器建立連接配接：

• 2：建立用戶端本地套接字（隐式捆綁到本地port）

   指定伺服器程序的IP位址和端口号，與伺服器程序連接配接

• 3 ：當與用戶端連接配接請求到來時

   伺服器接受來自使用者端的請求，解除阻塞式等待，傳回一個新的socket，（connection socket值）（與歡迎socket不一樣），與用戶端通信

   允許伺服器與多個用戶端通信

   使用源IP和源端口來區分不同的用戶端

• 4：連接配接API調用有效時，用戶端P與伺服器建立了TCP連接配接

  

4.C/S模式的應用樣例:

先看兩個資料結構，再進一步說明C/S socket 互動: TCP

下圖中Server調用bind函數時，參數&sad 就是上面的sockaddr_in{}的結構體。

在下面一點點的accept()中的 &cad也是sockaddr_in{}這樣的結構體

這個圖的解釋，頗費口舌，先附一下視訊連結，看看鄭老師的講解吧，21min19s處開始

大概是這樣的：

At first，Server 建立一個WelcomeSocket（）傳回一個随機的整數（比如說8888）。這個welcomeSocket函數中有一個參數，可以代表，所建立的是一個TCPsocket還是一個UDPsocket，甚至可以是一個IP socket。

這個時候socket表項,如下

socket	s_ip	s_port	c_ip	c_port
8888	/	/	/	/

And then,調用 bind()函數，将socket的随機值8888，綁定Server的ip（1.1.1.1）和端口号80.

同時假定，Client的ip為2.2.2.2，端口為777

表項更新如下

s_socket	s_ip	s_port	c_ip	c_port
8888	1.1.1.1	80	/	/

這個表項是應用層和傳輸層用的一個表項。

and then,Server調用connectionSocket =accept(welcomeSocket, &cad…)再8888這個socket等待，來自使用者的建立連接配接請求，沒client請求，就阻塞着…

Now ,it is time for client to establish connection request.

同樣，client調用socket(PF_INET,…)得到一個socket随機整數（比如說2222）。

但不一樣的是，client不用特意去bind，會有一個隐式的bind。比起伺服器，用戶端不用指定一個特定的端口去建立socket連接配接。

現在client也有了一個socket表項.

c_socket	c_ip	c_port	s_ip	s_port
2222	2.2.2.2	777	/	/

表項中其實還有一項，來表示狀态（目前是無效狀态的）

第六步，client調用connec()，向Server發起連接配接建立Request。（connect()的一個參數中就指明了Server中的ip：1.1.1.1和port：80的捆綁關系，于是c_socket表項在調用connect()的時候又更新了)

c_socket	c_ip	c_port	s_ip	s_port
2222	2.2.2.2	777	1.1.1.1	80

這個時候Server socket應答，建立連接配接，accept()解除阻塞傳回一個新的socket整數值（比如8899）

這個時候server的socket 多了一行新的，有表項效值。

s_socket	s_ip	s_port	c_ip	c_port
8888	1.1.1.1	80	/	/
8899	1.1.1.1	80	2.2.2.2	777

說明一下啊：

這裡fork了原來的welcomeSocket，得到新的8899有效socket 新程序，去和client的一個socket程序打交道。

而8888 這個老程序還是守候在80端口，等待新的client程序請求建立連接配接。

socket的值，代表了一個會話關系！

現在Socket Connection Established，就好辦了。開始通過connectionSocket和clientSocket來send、read、write reply。

最後覺得時候離開了，就close

紅色箭頭代表封包的互動

下面看一些實作代碼

代碼解釋就更費口舌了，，，還是看看鄭老師聲情并茂的講解吧！（37min30s處）

二、UDP Socket 程式設計

UDP: 在用戶端和伺服器之間沒有連接配接

• 沒有握手
• 發送端在每一個封包中明确地指定目标的IP位址和端口号
• 伺服器必須從收到的分組中提取出發送端的IP位址和端口号

UDP: 傳送的資料可能亂序，也可能丢失

1.Client/server socket 互動: UDP

看懂了上面TCP的Socket 程式設計，下面的UDP的Socket程式設計豈不是易如反掌？（但問題是還不懂上面）

三、小結