應用層協議原理

創建一個新的網絡應用

（1）$編程$

• 能夠在不同的端系統上運行
• 通過網絡基礎設施提供的服務，使應用進程間彼此通信
• 如 Web：
  • Web服務器軟件與瀏覽器軟件間的通信

（2）$網絡核心中沒有應用層軟件$

• 網絡核心設備并不在應用層起作用，即網絡核心沒有應用層功能
• 網絡應用被限制在端系統上
  • 加速了網絡應用的開發和部署

$核心$：編寫出能夠在 不同端系統 和 通過網絡彼此通信 的應用

應用程序體系結構

• 從研發者角度來看，網絡體系結構是固定的，并為應用程序提供特定的服務集合
• 由應用程序研發者設計，規定如何在各種端系統上組織該應用程序

（1）$C/S體系結構$

• 服務器：
  • 一個一直運行的主機
  • 固定的IP地址、周知的端口號（約定）
  • 服務客戶主機的請求
  • 常出現一臺單獨的服務器主機跟不上所有客戶請求情況（宕機）
  • 拓展性：通過建立服務器場
    • 數據中心（配置大量的主機）進行拓展
    • 拓展性差
• 客戶端
  • 主動與服務器進行通信
  • 與互聯網有間歇性的連接
  • 可能是動態的IP地址
  • 不直接與其他客戶端進行通信

（2）$P2P體系結構$

• （幾乎）沒有一直運行的服務器

• 任意端系統之間可以直接進行通信

• 每一個節點既可以是客戶端又可以是服務器

  • $自拓展性$：

    新的 peer（對等）節點帶來服務請求，但也帶來新的服務能力

• 參與通信的主機間歇性連接且可以動態改變IP地址

  • $難以管理$

• 例子：Gnutella，迅雷

（3）$C/S和P2P體系結構的混合體$

• Napster

  • 文件搜索：集中
    • 主機在中心服務器上注冊其資源
    • 主機向中心服務器查詢資源的地址
  • 文件傳輸：P2P
    • 任意對等節點之間進行通信傳輸

• 即時通行

  • 在線檢測：集中
    • 當有用戶上線時，就會中心服務器注冊其IP地址
    • 用戶與中心服務器進行聯系，以找到器在線好友的位置
  • 兩個用戶之間的聊天：P2P

進程通信

$進程$：在主機上運行的應用程序

• 在同一個主機內，使用$進程間通信機制$進行通信（操作系統定義）
• 不同主機，通過交換$報文$來進行通信
  • 使用OS（操作系統）提供的通信服務
  • 按照應用協議交換報文
    • 借助傳輸層提供的服務

$分布式進程通信需要解決的問題$

問題 1： 進程標識和尋址問題（服務用戶）

• 進程為了接受報文，必須有一個 $標識$

  即 SAP（發送也需要標識）

  • 主機：有唯一的32位的 $IP地址$
    • 但是僅僅有IP地址并不能唯一標識一個進程，因為一般而言一臺端系統上有很多應用進程在運行
  • 所采用的傳輸層協議：TCP or UDP
  • $端口號$（Port Number）：發送的進程被指定運行在接收主機上的接收進程

• 一些知名的端口號例子： 所有因特網標準協議的周知端口號列表

  • HTTP：TCP 80
  • Mail：TCP 25
  • ftp ： TCP 2

• 一個進程：用 IP + port標識端節點

• 本質上：一對主機進程之間的通信有2個端節點構成

問題 2：傳輸層-應用層是如何提供服務（服務）

$1.傳輸層提供的服務??需要穿過層間的信息$

• 層間接口必須要攜帶必要信息
  • 要傳輸的報文：對于本層來說：SDU
  • 誰傳的：對方的應用進程的標識： IP + TCP（UDP）的端口號
  • 傳給誰：對方的應用進程的標識：對方的IP + TCP（UDP）的端口號
• 傳輸層實體：TCP 或者 UDP實體（硬件/軟件），根據這些信息進行TCP報文段（UDP數據報）的封裝
  • 源端口號，目標端口號，數據等
  • 將 IP 地址往下交給IP實體，用于封裝IP數據報文：源IP，目標IP

$2.傳輸層提供的服務??層間信息的代表$

? ~ ~??對于傳輸的貨物來說，每次都傳輸貨物，IP + TCP（UDP）的端口號這三個信息，太繁瑣易錯，不便于管理，為了減少層間傳輸的信息量，可以采用Socket

• 用個代號標識通信的雙方或者單方：TCP Socket（是一個本地的標號，對方并不知道）

  • 例如：建立一個TCP socket，實際上操作系統會返回一個整數，這個整數就可以代表 <我的IP，我的端口號，他的IP，他的端口號>這個四元組，以后當我通過這個socket去發送傳輸報文的時候，直接調用這個標識加速報文的傳輸

• 就像對OS打開文件返回的句柄一樣

  • 對句柄的操作，就是對文件的操作

• $TCPsocket$：

  • TCP 服務，兩個進程之間的通信之前需要建立連接
    • 兩個進程通信通常會持續一段時間，通信關系穩定
  • 可以用一個整數表示兩個應用實體之間的通信關系
    • $本地$的標識
  • 穿過層間接口的信息量 $最小$
  • TCP socket：源IP，源端口，目標IP，目標端口

• $TCP之上的套接字（socket）$

  ? 對于使用面向連接服務（TCP）的應用而言，套接字是 4 元組的一個具有本地意義的標識

  • 4元組：< 源IP，源port，目標IP，目標port>

  • 唯一的指定了一個會話（2 個進程之間的會話關系）

  • 不必在每一個報文的發送都要指定這個4元組，而是直接操作這個整數

  • 就像使用操作系統打開一個文件，OS返回一個文件句柄一樣，以后使用這個文件句柄，而不是使用這個文件的目錄名，文件名

  • 簡單，便于管理

• $UDPsocket$：

  • UDP 服務，兩個進程之間的通信之前無需建立連接
    • 每個報文都是獨立傳輸的
    • 前后報文可能交給不同的分布式進程
  • 因此，只能用一個整數標識本應用實體的標識
    • 因為對于這個報文可能同時也傳給另一個分布式進程
  • 穿過層間接口的信息大小最小
  • UDP socket：本地IP，本地端口
  • 但是傳輸報文時，必須要提供對方IP，port
    • 接受報文時，傳輸層需要上傳對方的IP，port

• $UDP之上的套接字（socket）$

  ? 對于使用無連接服務（UDP）的應用而言，套接字是 2 元組的一個具有本地意義的標識

  • 2元組：IP，port（發送源端指定）
  • UDP套接字指定應用所在的一個端節點（end point）
  • 在發送數據報文時，采用創建好的本地套接字（標識ID），這樣就不必在發送每個報文中指明自己所采用的 IP和 port
  • 但是在發送報文時，必須指定對方的 IP 和 port （另一個端節點）

• $套接字$

  • 進程向套接字發送報文，或從套接字接收報文
  • 套接字 可類比為 門戶
    • 發送進程時將報文推出門戶（發送進程依賴于傳輸層設施在另一側的門戶將報文交付給接收進程）
    • 接收進程從另一側門戶收到報文（依賴于傳輸層設施）
  • 也被稱為應用程序和網絡之間的應用程序編程接口（API）

問題 3： 如何使用傳輸層提供的服務，實現應用進程之間的報文交換，實現應用（用戶使用服務）

• 定義應用層協議：報文格式，解釋，時序等等
• 編制程序，使用OS提供的API，調用網絡基礎設施提供通信服務傳輸報文，實現應用時序等等

$1.應用層協議$

• 定義了：運行在不同端系統上的應用進程如何相互交換報文
  • 交換的報文類型：請求報文和應答報文
  • 各種報文類型的語法：報文中的各個字段及其描述
  • 字段的語義：即字段取值的含義
  • 何時進程，如何發送報文及報文進行應答的規則
• 應用層協議僅僅是應用的一部分
  • Web應用：HTTP協議，web客戶端，web服務器，HTML
• $公開協議$：
  • 由RFC文檔定義
  • 允許互操作
  • 如 HTTP，SMTP（簡單郵件傳輸協議）
• $專用（私有）協議$：
  • 協議不公開
  • 如：Skypc

$2.應用需要傳輸層提供什么樣的服務$

• $數據丟失率$
  • 有些應用要求100%的可靠數據傳輸（如文件）
  • 有些應用（如交談式音頻，視頻）能容忍一定比例下的數據丟失
• $吞吐量$
  • 一些應用（如多媒體）必須需要最小限度的吞吐量，從而使得應用能夠有效運轉（帶寬敏感應用）
  • 一些應用能夠充分利用可供使用的吞吐量（彈性應用）
• $延遲$
  • 一些應用出于有效性考慮，對數據傳輸由嚴格的時間限制
    • Internet電話，交互式游戲
    • 延遲，延遲差
• $安全性$
  • 機密性
  • 完整性
  • 可認證性（端點鑒別）

$3.Internet傳輸層提供的服務$

• $TCP服務$
  • $可靠的傳輸服務$
  • $流量控制$：發送方不會淹沒接收方
  • $擁塞控制$：當網絡出現擁塞時，TCP的擁塞機制會抑制發送方
  • $不能提供的服務$：時間保證，最小吞吐量和安全性
  • $面向連接$：要求在客戶端進程和服務器進程之間建立連接（結束報文發送時，必須拆除該連接）
• $UDP服務$
  • $不可靠的傳輸服務$
  • $不提供的服務$：可靠性，流量控制，擁塞控制，帶寬保證，建立連接

思考 ： 為什么要有 UDP？（必要性）

• 能夠區分不同的進程，而IP服務不能
  • 在IP提供的主機到主機端到端功能的基礎上，區分了主機上的應用進程
• 無需建立連接：省去了建立連接的時間，適合事務性的應用
• 不做可靠性的工作，例如檢錯重發，適合那些對實時性要求比較高而對正確性要求不高的應用
  • 因為如果為了實現可靠性（準確性，保序等等），必須付出時間的代價（檢錯重發）
• 沒有擁塞控制和流量控制，應用能夠按照設定的速度發送數據
  • 而在TCP上的應用，應用發送數據的數據和主機向網絡發送數據的實際速度是不一致的，因為有流量控制和擁塞控制

$TCP安全$

• $TCP\&UDP$
  • 都沒有加密機制（發送進程傳進其套接字的數據，與經網絡傳送到目的進程的數據相同
  • 明文通過互聯網傳輸，甚至密碼
• $SSL(安全套接字層)$
  • 在TCP上面實現，提供加密的TCP連接
  • 私密性
  • 數據完整性
  • 端到端的鑒別
• $SSL在應用層$
  • 應用程序采用SSL庫，SSL庫提供TCP通信
• $SSLsocketAPI$
  • 應用通過API將明文數據交給socket，SSL將其加密在互聯網上傳輸
  • 詳細在第 8 章

應用層中的實例

$(1)Web\&HTTP$

• $Web頁$：由一些$對象$組成

• 對象可以是 HTML文件，JPEG圖像，Java小程序，聲音剪輯文件等等

• Web頁含有一個$基本的HTML文件$，該基本HTML文件又可以包含若干個對象的引用（鏈接）

• 通過$URL$對每個對象進行引用

• $訪問協議，用戶名，口令字，端口等等$

• URL格式：

• $HTTP$：超文本傳輸協議

• Web的應用層協議

• C/S模式（用戶/服務器）

• 客戶：請求，接收和顯示Web對象的瀏覽器

• 服務器：對客戶的請求做出響應，進而發送對象的Web服務器

• $使用TCP$ 作為運輸協議（而不是在UDP上運行）

  • 客戶發起一個與服務器的TCP連接（建立套接字），端口號為 80
  • 服務器接受客戶的TCP連接請求
  • 在瀏覽器（HTTP客戶端）與Web服務器（HTTP服務器server）交換HTTP報文（應用層協議報文）
  • TCP連接關閉

• HTTP是$無狀態的$

  • 服務器并不維護關于客戶的任何信息
    • 假如某個特定的客戶在短短幾秒內兩次請求同一個對象，服務器并不會對剛剛已經向客戶提供了該對象而不做出響應，而是重新發送該對象
  • 因為維護狀態的協議是很復雜的
    • 必須維護歷史信息（狀態）
    • 如果 服務器 / 客戶端死機，那么它們的狀態信息可能不一致（但是通信過程中，我們必須保證二者的狀態信息一致）
    • 無狀態的服務器能夠支持更多的客戶端

• $FTP?$

• $Email，SMTP，POP3，IMAP$

• $DNS$

• $P2P應用$

• $CDN$

套接字編程

• TCP 套接字（Socket）編程

• UDP 套接字編程

以上內容尚未完全，隨著今后學習的推進，我會繼續對其進行補充與完善。

總結

以上是生活随笔為你收集整理的“ 食物链 “ 顶端的 《应用层》原理总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。