“ 食物链 “ 顶端的 《应用层》原理总结
應用層協議原理
創建一個新的網絡應用
(1)編程\color{Turquoise}編程編程
- 能夠在不同的端系統上運行
- 通過網絡基礎設施提供的服務,使應用進程間彼此通信
- 如 Web:
- Web服務器軟件與瀏覽器軟件間的通信
(2)網絡核心中沒有應用層軟件\color{Turquoise}網絡核心中沒有應用層軟件網絡核心中沒有應用層軟件
- 網絡核心設備并不在應用層起作用,即網絡核心沒有應用層功能
- 網絡應用被限制在端系統上
- 加速了網絡應用的開發和部署
核心\color{Red}核心核心:編寫出能夠在 不同端系統 和 通過網絡彼此通信 的應用
應用程序體系結構
- 從研發者角度來看,網絡體系結構是固定的,并為應用程序提供特定的服務集合
- 由應用程序研發者設計,規定如何在各種端系統上組織該應用程序
(1)C/S體系結構\color{Orange}C/S 體系結構C/S體系結構
- 服務器:
- 一個一直運行的主機
- 固定的IP地址、周知的端口號(約定)
- 服務客戶主機的請求
- 常出現一臺單獨的服務器主機跟不上所有客戶請求情況(宕機)
- 拓展性:通過建立服務器場
- 數據中心(配置大量的主機)進行拓展
- 拓展性差
- 客戶端
- 主動與服務器進行通信
- 與互聯網有間歇性的連接
- 可能是動態的IP地址
- 不直接與其他客戶端進行通信
(2)P2P體系結構\color{Orange}P2P體系結構P2P體系結構
-
(幾乎)沒有一直運行的服務器
-
任意端系統之間可以直接進行通信
-
每一個節點既可以是客戶端又可以是服務器
-
自拓展性\color{Maroon}自拓展性自拓展性:
新的 peer(對等)節點帶來服務請求,但也帶來新的服務能力
-
-
參與通信的主機間歇性連接且可以動態改變IP地址
- 難以管理\color{Maroon}難以管理難以管理
-
例子:Gnutella,迅雷
(3)C/S和P2P體系結構的混合體\color{Orange}C/S和P2P體系結構的混合體C/S和P2P體系結構的混合體
-
Napster
- 文件搜索:集中
- 主機在中心服務器上注冊其資源
- 主機向中心服務器查詢資源的地址
- 文件傳輸:P2P
- 任意對等節點之間進行通信傳輸
- 文件搜索:集中
-
即時通行
- 在線檢測:集中
- 當有用戶上線時,就會中心服務器注冊其IP地址
- 用戶與中心服務器進行聯系,以找到器在線好友的位置
- 兩個用戶之間的聊天:P2P
- 在線檢測:集中
進程通信
進程\color{Red}進程進程:在主機上運行的應用程序
- 在同一個主機內,使用進程間通信機制\color{Maroon}進程間通信機制進程間通信機制進行通信(操作系統定義)
- 不同主機,通過交換報文\color{Maroon}報文報文來進行通信
- 使用OS(操作系統)提供的通信服務
- 按照應用協議交換報文
- 借助傳輸層提供的服務
分布式進程通信需要解決的問題\color{Turquoise}分布式進程通信需要解決的問題分布式進程通信需要解決的問題
問題 1: 進程標識和尋址問題(服務用戶)
-
進程為了接受報文,必須有一個 標識\color{Orange}標識標識
即 SAP(發送也需要標識)
- 主機:有唯一的32位的 IP地址\color{Maroon}IP地址IP地址
- 但是僅僅有IP地址并不能唯一標識一個進程,因為一般而言一臺端系統上有很多應用進程在運行
- 所采用的傳輸層協議:TCP or UDP
- 端口號\color{Maroon}端口號端口號(Port Number):發送的進程被指定運行在接收主機上的接收進程
- 主機:有唯一的32位的 IP地址\color{Maroon}IP地址IP地址
-
一些知名的端口號例子: 所有因特網標準協議的周知端口號列表
- HTTP:TCP 80
- Mail:TCP 25
- ftp : TCP 2
-
一個進程:用 IP + port標識端節點
-
本質上:一對主機進程之間的通信有2個端節點構成
問題 2:傳輸層-應用層是如何提供服務(服務)
1.傳輸層提供的服務??需要穿過層間的信息\color{Skyblue}1.傳輸層提供的服務--需要穿過層間的信息1.傳輸層提供的服務??需要穿過層間的信息
- 層間接口必須要攜帶必要信息
- 要傳輸的報文:對于本層來說:SDU
- 誰傳的:對方的應用進程的標識: IP + TCP(UDP)的端口號
- 傳給誰:對方的應用進程的標識:對方的IP + TCP(UDP)的端口號
- 傳輸層實體:TCP 或者 UDP實體(硬件/軟件),根據這些信息進行TCP報文段(UDP數據報)的封裝
- 源端口號,目標端口號,數據等
- 將 IP 地址往下交給IP實體,用于封裝IP數據報文:源IP,目標IP
2.傳輸層提供的服務??層間信息的代表\color{Skyblue}2.傳輸層提供的服務--層間信息的代表2.傳輸層提供的服務??層間信息的代表
? ~ ~??對于傳輸的貨物來說,每次都傳輸貨物,IP + TCP(UDP)的端口號這三個信息,太繁瑣易錯,不便于管理,為了減少層間傳輸的信息量,可以采用Socket
-
用個代號標識通信的雙方或者單方:TCP Socket(是一個本地的標號,對方并不知道)
- 例如:建立一個TCP socket,實際上操作系統會返回一個整數,這個整數就可以代表 <我的IP,我的端口號,他的IP,他的端口號>這個四元組,以后當我通過這個socket去發送傳輸報文的時候,直接調用這個標識加速報文的傳輸
-
就像對OS打開文件返回的句柄一樣
- 對句柄的操作,就是對文件的操作
-
TCPsocketTCP~ socketTCP?socket:
- TCP 服務,兩個進程之間的通信之前需要建立連接
- 兩個進程通信通常會持續一段時間,通信關系穩定
- 可以用一個整數表示兩個應用實體之間的通信關系
- 本地\color{Maroon}本地本地的標識
- 穿過層間接口的信息量 最小\color{Maroon}最小最小
- TCP socket:源IP,源端口,目標IP,目標端口
- TCP 服務,兩個進程之間的通信之前需要建立連接
-
TCP之上的套接字(socket)\color{blue}TCP 之上的套接字 (socket)TCP之上的套接字(socket)
? 對于使用面向連接服務(TCP)的應用而言,套接字是 4 元組的一個具有本地意義的標識
-
4元組:< 源IP,源port,目標IP,目標port>
-
唯一的指定了一個會話(2 個進程之間的會話關系)
-
不必在每一個報文的發送都要指定這個4元組,而是直接操作這個整數
-
就像使用操作系統打開一個文件,OS返回一個文件句柄一樣,以后使用這個文件句柄,而不是使用這個文件的目錄名,文件名
-
簡單,便于管理
-
-
UDPsocketUDP~ socketUDP?socket:
- UDP 服務,兩個進程之間的通信之前無需建立連接
- 每個報文都是獨立傳輸的
- 前后報文可能交給不同的分布式進程
- 因此,只能用一個整數標識本應用實體的標識
- 因為對于這個報文可能同時也傳給另一個分布式進程
- 穿過層間接口的信息大小最小
- UDP socket:本地IP,本地端口
- 但是傳輸報文時,必須要提供對方IP,port
- 接受報文時,傳輸層需要上傳對方的IP,port
- UDP 服務,兩個進程之間的通信之前無需建立連接
-
UDP之上的套接字(socket)\color{blue}UDP 之上的套接字 (socket)UDP之上的套接字(socket)
? 對于使用無連接服務(UDP)的應用而言,套接字是 2 元組的一個具有本地意義的標識
- 2元組:IP,port(發送源端指定)
- UDP套接字指定應用所在的一個端節點(end point)
- 在發送數據報文時,采用創建好的本地套接字(標識ID),這樣就不必在發送每個報文中指明自己所采用的 IP和 port
- 但是在發送報文時,必須指定對方的 IP 和 port (另一個端節點)
-
套接字\color{Maroon}套接字套接字
- 進程向套接字發送報文,或從套接字接收報文
- 套接字 可類比為 門戶
- 發送進程時將報文推出門戶(發送進程依賴于傳輸層設施在另一側的門戶將報文交付給接收進程)
- 接收進程從另一側門戶收到報文(依賴于傳輸層設施)
- 也被稱為應用程序和網絡之間的應用程序編程接口(API)
問題 3: 如何使用傳輸層提供的服務,實現應用進程之間的報文交換,實現應用(用戶使用服務)
- 定義應用層協議:報文格式,解釋,時序等等
- 編制程序,使用OS提供的API,調用網絡基礎設施提供通信服務傳輸報文,實現應用時序等等
1.應用層協議\color{Skyblue}1.應用層協議1.應用層協議
- 定義了:運行在不同端系統上的應用進程如何相互交換報文
- 交換的報文類型:請求報文和應答報文
- 各種報文類型的語法:報文中的各個字段及其描述
- 字段的語義:即字段取值的含義
- 何時進程,如何發送報文及報文進行應答的規則
- 應用層協議僅僅是應用的一部分
- Web應用:HTTP協議,web客戶端,web服務器,HTML
- 公開協議\color{Maroon}公開協議公開協議:
- 由RFC文檔定義
- 允許互操作
- 如 HTTP,SMTP(簡單郵件傳輸協議)
- 專用(私有)協議\color{Maroon}專用(私有)協議專用(私有)協議:
- 協議不公開
- 如:Skypc
2.應用需要傳輸層提供什么樣的服務\color{Skyblue}2.應用需要傳輸層提供什么樣的服務2.應用需要傳輸層提供什么樣的服務
- 數據丟失率\color{Maroon}數據丟失率數據丟失率
- 有些應用要求100%的可靠數據傳輸(如文件)
- 有些應用(如交談式音頻,視頻)能容忍一定比例下的數據丟失
- 吞吐量\color{Maroon}吞吐量吞吐量
- 一些應用(如多媒體)必須需要最小限度的吞吐量,從而使得應用能夠有效運轉(帶寬敏感應用)
- 一些應用能夠充分利用可供使用的吞吐量(彈性應用)
- 延遲\color{Maroon}延遲延遲
- 一些應用出于有效性考慮,對數據傳輸由嚴格的時間限制
- Internet電話,交互式游戲
- 延遲,延遲差
- 一些應用出于有效性考慮,對數據傳輸由嚴格的時間限制
- 安全性\color{Maroon}安全性安全性
- 機密性
- 完整性
- 可認證性(端點鑒別)
3.Internet傳輸層提供的服務\color{Skyblue}3.Internet~ 傳輸層提供的服務3.Internet?傳輸層提供的服務
- TCP服務\color{Maroon}TCP服務TCP服務
- 可靠的傳輸服務\color{CadetBlue}可靠的傳輸服務可靠的傳輸服務
- 流量控制\color{CadetBlue}流量控制流量控制:發送方不會淹沒接收方
- 擁塞控制\color{CadetBlue}擁塞控制擁塞控制:當網絡出現擁塞時,TCP的擁塞機制會抑制發送方
- 不能提供的服務\color{CadetBlue}不能提供的服務不能提供的服務:時間保證,最小吞吐量和安全性
- 面向連接\color{CadetBlue}面向連接面向連接:要求在客戶端進程和服務器進程之間建立連接(結束報文發送時,必須拆除該連接)
- UDP服務\color{Maroon}UDP服務UDP服務
- 不可靠的傳輸服務\color{CadetBlue}不可靠的傳輸服務不可靠的傳輸服務
- 不提供的服務\color{CadetBlue}不提供的服務不提供的服務:可靠性,流量控制,擁塞控制,帶寬保證,建立連接
思考 : 為什么要有 UDP?(必要性)
- 能夠區分不同的進程,而IP服務不能
- 在IP提供的主機到主機端到端功能的基礎上,區分了主機上的應用進程
- 無需建立連接:省去了建立連接的時間,適合事務性的應用
- 不做可靠性的工作,例如檢錯重發,適合那些對實時性要求比較高而對正確性要求不高的應用
- 因為如果為了實現可靠性(準確性,保序等等),必須付出時間的代價(檢錯重發)
- 沒有擁塞控制和流量控制,應用能夠按照設定的速度發送數據
- 而在TCP上的應用,應用發送數據的數據和主機向網絡發送數據的實際速度是不一致的,因為有流量控制和擁塞控制
TCP安全\color{Turquoise}TCP安全TCP安全
- TCP&UDP\color{CadetBlue}TCP \& UDPTCP&UDP
- 都沒有加密機制(發送進程傳進其套接字的數據,與經網絡傳送到目的進程的數據相同
- 明文通過互聯網傳輸,甚至密碼
- SSL(安全套接字層)\color{CadetBlue}SSL(安全套接字層)SSL(安全套接字層)
- 在TCP上面實現,提供加密的TCP連接
- 私密性
- 數據完整性
- 端到端的鑒別
- SSL在應用層\color{CadetBlue}SSL在應用層SSL在應用層
- 應用程序采用SSL庫,SSL庫提供TCP通信
- SSLsocketAPI\color{CadetBlue}SSL ~ ~socket~~ APISSL??socket??API
- 應用通過API將明文數據交給socket,SSL將其加密在互聯網上傳輸
- 詳細在第 8 章
應用層中的實例
(1)Web&HTTP\color{orange}(1) ~~Web ~~\& ~~HTTP(1)??Web??&??HTTP
-
Web頁\color{Turquoise}Web頁Web頁:由一些對象\color{Maroon}對象對象組成
-
對象可以是 HTML文件,JPEG圖像,Java小程序,聲音剪輯文件等等
-
Web頁含有一個基本的HTML文件\color{Maroon}基本的HTML文件基本的HTML文件,該基本HTML文件又可以包含若干個對象的引用(鏈接)
-
通過URL\color{Maroon}URLURL對每個對象進行引用
-
訪問協議,用戶名,口令字,端口等等\color{Maroon}訪問協議,用戶名,口令字,端口等等訪問協議,用戶名,口令字,端口等等
-
URL格式:
-
HTTP\color{Turquoise}HTTPHTTP:超文本傳輸協議
-
Web的應用層協議
-
C/S模式(用戶/服務器)
-
客戶:請求,接收和顯示Web對象的瀏覽器
-
服務器:對客戶的請求做出響應,進而發送對象的Web服務器
-
使用TCP\color{Maroon}使用TCP使用TCP 作為運輸協議(而不是在UDP上運行)
- 客戶發起一個與服務器的TCP連接(建立套接字),端口號為 80
- 服務器接受客戶的TCP連接請求
- 在瀏覽器(HTTP客戶端)與Web服務器(HTTP服務器server)交換HTTP報文(應用層協議報文)
- TCP連接關閉
-
HTTP是無狀態的\color{Maroon}無狀態的無狀態的
- 服務器并不維護關于客戶的任何信息
- 假如某個特定的客戶在短短幾秒內兩次請求同一個對象,服務器并不會對剛剛已經向客戶提供了該對象而不做出響應,而是重新發送該對象
- 因為維護狀態的協議是很復雜的
- 必須維護歷史信息(狀態)
- 如果 服務器 / 客戶端死機,那么它們的狀態信息可能不一致(但是通信過程中,我們必須保證二者的狀態信息一致)
- 無狀態的服務器能夠支持更多的客戶端
- 服務器并不維護關于客戶的任何信息
-
FTP?\color{orange}FTP*FTP?
-
Email,SMTP,POP3,IMAP\color{orange}Email , SMTP, POP3,IMAPEmail,SMTP,POP3,IMAP
-
DNS\color{orange}DNSDNS
-
P2P應用\color{orange}P2P 應用P2P應用
-
CDN\color{orange}CDNCDN
套接字編程
-
TCP 套接字(Socket)編程
-
UDP 套接字編程
以上內容尚未完全,隨著今后學習的推進,我會繼續對其進行補充與完善。
總結
以上是生活随笔為你收集整理的“ 食物链 “ 顶端的 《应用层》原理总结的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 隐马尔科夫模型c#语言算法实现,HMM学
- 下一篇: 高斯坐标反算坐标转经纬度