1.應用層概述
應用層(Application Layer)
屬于計算機網絡體系結構中的最頂層,直接面向用戶,提供各種網絡服務和應用程序的接口
本文主要的學習內容如下:
(1)網絡應用進程通信方式
- 客戶端-服務器方式
- 點對點方式
- 混合方式
(2)網絡應用的需求與傳輸層服務
- 可靠性
- 帶寬
- 延遲
(3)各種網絡應用及協議
- Web應用 -> HTTP
- Email應用 -> SMTP、POP
- P2P應用
(4)Socket編程
- TCP
- UDP
2.網絡應用進程通信方式
進程:
主機上運行的程序
Question1:
同一主機上運行的進程之間如何通信?
Answer:
同一主機上運行的程序通過操作系統提供的進程間通信機制進行通信,這里不展開介紹
Question2:
不同主機上運行的進程之間如何通信?
Answer:
消息(數據)交換。主要有電路交換、報文交換和分組交換
Question3:
如何定位不同主機上運行的進程?
Answer:
不同主機的不同進程都擁有唯一的標識符,進程的標識符 = IP地址 + 端口號
注意1:
網絡應用通信需要遵守應用層協議,協議主要定義了以下規范
消息的類型(type):
請求消息、響應消息消息的語法格式(syntax):
消息中有哪些字段,每個字段如何描述/采取什么結構字段的語義(semantics):
字段中信息的含義規則(rules):
應用何時發送/接收消息,應用如何發送/接收消息
下面是網絡應用中的主要通信方式
2.1 客戶端-服務器方式(Client-Sever,CS)
服務器:
接受請求返回響應的終端
- 7*24(007)小時提供服務
- IP地址/域名長期固定
- 利用大量服務器實現可擴展性
客戶端:
發起請求接收響應的終端
- 與服務器通信,使用服務器提供的服務
- 間歇性接入網絡(不是一直在線)
- IP地址不固定(IP地址動態分配,網絡層在詳細介紹)
- 不會與其他客戶端直接通信
2.2 點對點方式(Peer-to-Peer,P2P)
- P2P結構中的每個節點都可以充當客戶端或服務器的角色
- 任意節點之間可以直接通訊
- 節點間歇性接入網絡
- 節點IP地址不固定
2.3 混合方式
Question:
能不能結合以上兩種方式的優點,規避缺點,設計一種新的通信方式/模型?
以Napster為例:
Napster 在文件傳輸和文件搜索方面采用了混合架構,結合了P2P和客戶端-服務器兩種結構。這種混合架構在當時是一個創新設計,既利用了P2P的優勢,又通過中央服務器提高了效率和可控性
(1)客戶端-服務器(CS)結構用于文件搜索:
- 中央服務器:Napster 使用一個中央服務器來維護一個所有共享文件的索引目錄。當用戶想要查找某個文件時,他們會向中央服務器發送搜索請求
(2)對等網絡(P2P)結構用于文件傳輸:
- 直接連接:一旦用戶選擇了要下載的文件,Napster 會直接連接文件所有者的計算機,建立點對點連接
- 文件傳輸:文件直接從文件所有者的計算機傳輸到請求者的計算機,而不經過中央服務器。這種方式大大提高了傳輸效率,并減輕了中央服務器的負擔
3.Web應用
3.1 Web應用結構與協議
Web應用
使用客戶端-服務器通信方式,客戶端與服務器之間使用HTTP/HTTPS協議進行通信
服務器:
接受并處理HTTP請求,返回HTTP響應。主要包括:
- Web頁面(HTML文檔):包含多種對象和鏈接‘
- Web對象(靜態/動態對象):可以是HTML文檔、圖像文件、視頻文件、音頻文件等
- URL(統一資源定位符):對象之間的尋址依靠URL
客戶端:
發送請求,接受并解析響應
3.2 HTTP協議
Java EE(17)——網絡原理——應用層HTTP協議
3.3 HTTPS協議
Java EE(18)——網絡原理——應用層HTTPS協議
3.4 Web緩存技術
目的:
在不訪問服務器的情況下滿足客戶端的HTTP/HTTPS請求
意義:
- 縮短客戶端的響應時間
- 減少服務器的并發量
在客戶端-服務器中間架設代理服務器用來保存緩存
- 當clientA發起HTTP請求某資源時,該HTTP會先到達代理服務器,代理服務器優先在自己的數據庫中查找。如果有相應資源,直接返回給clientA;如果沒有,則向原始服務器發送HTTP請求,原始服務器返回響應后,代理服務器先緩存該資源,再返回給clientA
- 當clientB再次請求相同資源時,HTTP請求將不會到達原始服務器,而是由代理服務器返回資源,一定程度上減輕了服務器的壓力
Question1:
如果當clientB發送請求時,該資源已經經歷了一次版本更新,如何保證獲取到最新版資源?
Answer1:
當代理服務器收到HTTP請求時,代理服務器會一個HTTP請求檢測該資源的版本是否和原始服務器中的一致。如果版本一致,原始服務器會返回304 Not Modified
,告訴代理服務器版本一致;如果版本不一致,原始服務器會返回最新版資源,代理服務器緩存后再返回給clientB
Question2:
既然每次代理服務器收到請求之后都會跟原始服務器檢測版本,會不會加重服務器負擔?
Answer2:
當版本一致時,原始服務器只會返回304 Not Modified
,并不攜帶額外資源,相較于客戶端直接訪問服務器的負擔會小很多
4.Email應用
4.1 Email應用的構成
Email應用的構成
- 郵件客戶端(user agent):撰寫、發送、接收和管理電子郵件的應用程序
- 郵件服務器:處理電子郵件的傳輸和存儲的計算機,負責在用戶之間傳遞郵件,并儲存用戶的郵件數據
- SMTP協議(Simple Mail Transfer):定義了郵件在互聯網上傳輸的標準
4.2 Email應用示例
A想發送一封郵件給B,該郵件會先傳輸到A對應的服務器③,再傳輸給B對應的服務器⑤,等到B上線的時候再接收郵件
Question:
為什么郵件不能直接發送到B?
Answer:
因為B不一定在線。想直接發送到B的前提是A和B要建立連接,但如果B不在線就無法建立連接,所以無法直接發送到B。但是B對應的服務器⑤一定在線,服務器⑤會保存該郵件等到B來接收
4.3 SMTP協議
概述:
- SMTP協議:簡單郵件傳輸協議
- 使用C/S結構工作在TCP的25號端口
- 持久連接
交互過程:
- 三次握手建立連接(傳輸層再詳細介紹)
- 身份認證
- 郵件傳輸
- 斷開連接
命令/響應交互模式
- 命令(command):ASCII文本
- 響應(response):狀態代碼和語句
協議格式:
頭部(header):
包含郵件的元信息,如發件人、收件人、主題等。常見頭部字段如下:
- From:發件人郵箱
- To:收件人郵箱
- Subject:郵件主題
- Date:發送日期
- Contect-Type:正文類型(body中的格式)
空行:
用于分割頭部和body
正文(body):
郵件的實際內容
注意:根據RFC5321規定,傳統的SMTP協議使用7為ASCII字符集進行通信,這意味著所有的SMTP命令、響應和header都必須是ASCII字符。因為SMTP協議必須使用ASCII字符集,直接傳輸非ASCII數據(如二進制文件)時會出問題,為了解決這個問題。引入了MIME(多用途互聯網郵件擴展),允許在電子郵件中使用非ASCII數據
4.4 POP3
客戶端向服務器發送電子郵件的時候使用SMTP協議,但客戶端讀取服務器中的郵件時使用郵件訪問協議(Post Office Protocol),本文介紹POP3協議
概述:
- POP3:郵局協議版本3(Post Office Protocol-Version 3)
- 作用是將存儲在郵件服務器上的電子郵件離線下載到本地
- 使用C/S結構工作在TCP的110號端口
交互流程:
Question:
為什么上面獲取某一封郵件后,要刪除該郵件呢?
Answer:這和POP3協議的訪問模式有關
訪問模式:
(1)下載并刪除模式:
客戶端下載郵件后刪除該郵件
- 優點:節省空間
- 缺點:如果用戶換了客戶端,就無法重讀該郵件
(2)下載并保持模式:
客戶端下載郵件不刪除該郵件
- 優點:不同的客戶端都可以保留郵件的拷貝
- 缺點:占用大量空間
5.P2P應用
5.1 文件分發耗時分析
Question:
從一個服務器向N個節點分發一個文件需要多長時間?
客戶端-服務器結構
- 服務器向網絡核心中串行地發送N個文件,所需時間:N×F/us
- 節點i下載,所需時間:F/min(di)
該結構所需時間dcs =
max{N×F/us,F/min(di)}
P2P結構
- 服務器必須向網絡核心中發送一個副本,所需時間:F/us
- 節點i下載,所需時間:F/min(di)
- 總下載量:NF,總上傳速率: U s + ∑ u i Us+\sum_{}^{} u_i Us+∑?ui?
該結構所需時間dP2P = max{F/us,F/min(di), N ? F / ( U s + ∑ u i ) N*F/(Us+\sum_{}^{} u_i) N?F/(Us+∑?ui?)}
客戶端-服務器結構 VS P2P結構
隨著節點數量的不斷增加,C/S結構完成文件轉發所需的時間線性增長,P2P結構完成文件轉發所需的時間趨于不變
5.2 P2P文件分發協議:BitTorrent
概述:
BitTorrent是最廣泛使用的P2P文件分發協議之一。它通過將文件分割成小塊(pieces),并允許多個用戶同時下載和上傳這些小塊,從而實現高效的文件分發
工作原理:
- 種子文件(.torrent): 包含有關要下載的文件的信息,如文件大小、名稱、tracker服務器的地址等
- Tracker服務器: 跟蹤參與下載的peer,并幫助peer之間建立連接。
- peer:BitTorrent網絡中任何一個正在下載或上傳文件的節點
- chunk:在BitTorrent協議中,文件被分割成多個較小的部分,每個部分稱為一個chunk
場景假設:
現在有一個peer(Alice)加入該torrent組,一開始Alice沒有任何chunk,隨著時間的推移會逐漸積累。Alice會向tracker注冊并獲取節點清單,與某些節點建立連接以獲取目標chunk(稀缺優先),在獲取chunk的同時Alice也會向其他peer發送chunk(tit-for-tat)
Question:
上述提到的稀缺優先和tit-for-tat是什么?
5.3 索引
P2P結構中的
索引
:信息到節點位置(IP地址+端口號)的映射
應用場景:
(1)文件共享
- 利用索引動態跟蹤節點所共享的文件的位置
- 節點告訴索引它擁有哪些文件
- 節點搜索索引,從而獲知能夠得到哪些文件
(2)即時消息(QQ)
- 索引負責將用戶名映射到位置
- 當用戶開啟即時通訊(Instant Message)應用時,需要通知索引它的位置
- 節點檢索索引,確定用戶的位置
5.3.1 集中式索引
- 節點加入時,向中央目錄服務器登記本節點的IP地址和擁有的資源
- 節點在中央目錄服務器中搜索索引,從而獲知目標資源在哪個節點中
- 節點之間直接建立連接來請求資源
缺點:
-
單點失效問題:中央服務器崩潰會導致整個網絡無法搜索資源
-
性能問題:中央服務器需要處理所有請求,導致負載過高
5.3.2 分布式索引
- 每個節點對它共享的文件進行索引,且只對它共享的文件進行索引
- 所有節點構成分布式網絡:任意兩個節點間有TCP連接,則構成分布式網絡的一條邊
- 節點通過洪泛式查詢搜索資源
缺點:
-
網絡擁塞:在大規模網絡中,大量的查詢請求會導致網絡擁塞
-
資源消耗:每個節點都需要處理大量的查詢請求
-
重復查詢:同一個查詢可不能會被多次處理,導致不必要資源浪費
5.3.2 混合式索引
介于集中式索引和分布式索引的方法
- 整個網絡中分為普通節點和超級節點
- 超級節點和其子節點(普通接待你)之間維持TCP連接,超級節點之間維持TCP連接
- 超級節點負責跟蹤子節點的內容