第六章 計算機網絡-應用層

1.網絡應用概述

1. 網絡應用體系結構
   ① 客戶機/服務器 ② P2P ③ 混合結構
2. 網絡應用的服務需求
   ① 可靠性 ② 帶寬 ③ 時延
3. Internet傳輸層服務模型
   ① TCP ② UDP
4. 特定網絡應用及協議
   ① HTTP ② SMTP POP IMAP ③ DNS ④ P2P應用
5. Socket編程
   ① TCP ② UDP

2.網絡應用基本原理

2.1. 網絡應用的體系結構

1. 網絡應用：百度、QQ、Email、迅雷、支付寶、微信、百度雲、淘寶網、網易
2. 網絡應用的體系結構：客戶機/服務器結構（Client/Sever）、點對點結構（PeerToPeer）、混合結構

• 服務器：持續提供服務、永久性訪問地址/域名、利用大量服務器實現可擴展性
• 客戶機：使用服務器的服務、可能使用動態IP地址、不會與其餘客戶機直接通訊
• C/S舉例——Web
  計算機客戶端運行IE或者Sarari等瀏覽器，服務器運行Web服務器軟件
• P2P舉例——BT文件共享
  沒有永遠在線的服務器，任意端系統/節點直接能夠直接通信，節點可能改變IP地址
• 混合結構舉例——Napster
  文件傳輸使用P2P結構，文件的搜索採用C/S結構（集中式）

2.2. 網絡應用進程通訊（網絡應用的基礎）

• 進程：主機上運行的程序
• 同一主機上運行的進程之間通訊：進程間通訊機制、操做系統提供
• 不一樣主機上運行的進程之間通訊：消息交換/報文交換
  客戶機進程：發起通訊的進程
  服務器進程：等待通訊請求的進程
• 套接字：Socket
  進程間通訊利用socket發送/接收消息實現
  相似於寄信
  傳輸基礎設施向進程提供API（傳輸協議的選擇、參數的設置）
• 如何尋址進程
  進程有標識符：IP地址+端口號
  尋址主機——IP地址
  某一主機具體進程——端口號：每一個須要通訊的進程分配一個端口號
• 應用層協議
  公開協議：由RFC定義、容許互操做、HTTP、SMTP、...
  私有協議：多數P2P文件共享應用
• 應用層協議的內容
  消息類型：請求消息、響應消息
  消息的語法格式：字段、字段如何描述
  字段的語義：字段中信息的含義
  規則

2.3. 網絡應用的需求與傳輸層服務

1. 網絡應用的需求：數據丟失/可靠性（網絡電話容忍必定的數據丟失，文件傳輸要求100%可靠）、時間延遲、帶寬
2. Internet提供的傳輸服務：TCP服務（面向鏈接、可靠傳輸、流量控制、擁塞控制、不提供時間/延遲保障、不提供最小帶寬保障）、UCP服務（無鏈接、不可靠數據傳輸、不提供可靠性保障+流量控制+擁塞控制+延遲保障+帶寬保障）

3.Web應用

3.1Web應用概述

1. WorldWideWeb：網頁、網頁互相連接
2. 網頁包含多個對象：

• 對象：HTML文件、JEPG圖片、視頻文件、動態腳本等
• 基本HTML文件：包含對其餘對象引用的連接
• 對象的尋址：URL（協議://主機:端口號/路徑）

3. HTTP協議概述：萬維網應用遵循HTTP協議；C/S結構；使用TCP傳輸服務（80端口）；是無狀態協議（服務器不維護過去所發請求的信息）

3.2 HTTP鏈接類型

1. HTTP鏈接的兩種類型

• 非持久性鏈接：每一個TCP鏈接最多傳輸一個對象
• 持久性鏈接：每一個TCP鏈接容許傳輸多個對象

2. 響應事件分析與建模

• 非持久性鏈接：2RTT+文件發送時間（一個對象）
• 持久性鏈接：無流水的持久性鏈接（一個對象1RTT）、帶有流水機制的持久性鏈接（全部引用對象1RTT）

3.3 HTTP消息格式

1. 兩類消息：請求消息、響應消息
2. 請求消息消息格式：

• 請求行+頭部行（可擴展）+換行+entity body
• 請求消息通用格式：method、url、version、header field name、value、entity body..
• 上傳輸入的方法：
  （1） POST方法：網頁填寫表格（在請求消息的消息體entity body中上傳客戶端的輸入）
  （2） URL方法：使用GET方法（輸入信息經過request行的URL字段上傳）
• 方法的類型：
  HTTP/1.0：GET、POST、HEAD
  HTTP/1.1：GET、POST、HEAD、GET、DELETE

3. 響應消息消息格式：

• 狀態行+頭部行+空行+data

3.4 Cookie技術

1. Cookie技術：爲了辨別用戶身份、進行session跟蹤而儲存在用戶本地終端上的數據（RFC6265）
2. Cookie的組件：

• HTTP響應消息的cookie頭部行
• HTTP請求消息的cookie頭部行
• 保存在客戶端主機上的cookie文件，有瀏覽器管理
• Web服務器端的後臺數據庫

3. Cookie的原理：客戶端第一次訪問服務器，服務器會爲其建立ID，之後客戶端請求消息裏會有cookie id
4. Cookie的做用：能用於身份認證,購物車,推薦,Web e-mail
5. 隱私問題

3.5 Web緩存/代理服務器技術

1. 功能：不訪問服務器的前提下知足客戶端HTTP請求。能夠縮短客戶請求的響應時間；減小機構/組織的流量；在大範圍內實現有效的內容分發
2. Web緩存/代理服務器技術：

• 瀏覽器經過緩存進行Web訪問。若是請求對象在緩存中，緩存返回對象；不然向原始服務器發送HTTP請求，獲取對象，返回給客戶端並保存該對象
• 緩存即充當客戶端也充當服務器
• 通常由ISP（Internet服務提供商）架設

3. Web緩存實例

• 性能對比：原始服務器、提高互聯網接入帶寬、安裝Web緩存

4. 條件性GET方法

• 目標：緩存有最新版本，則不須要發送請求對象
• 緩存：在HTTP請求消息中聲明所持有版本的日期
• 服務器：若是版本是最新的，則響應消息中不包含對象

4.Email應用

4.1Email應用概述

1. Email應用的構成：郵件客戶端、郵件服務器、SMTP協議

• 郵件客戶端：如Foxmail、Web客戶端
• 郵件服務器：
  （1）郵箱：存儲發給該用戶的Email
  （2）消息隊列：存儲等待發送的Email
• SMTP協議：郵件服務器之間傳遞消息使用的協議（郵件服務器既充當客戶端又充當服務器)

2. SMTP協議：RFC 2821

• 使用TCP進行email消息的可靠傳輸
• 端口25
• 傳輸過程的三個階段：握手、消息的傳輸、關閉
• 命令/響應交互模式

3. Email應用實例
4. SMTP協議特色：

• 使用持久性鏈接
• 利用CRLF.CRLF肯定消息的結束

5. 與HTTP對比

• HTT是拉式；SMTP是退式
• 都使用命令/響應交互模式
• 命令和狀態碼都是ASCII碼
• HTTP：每一個對象封裝在獨立的響應消息中
• SMTP：多個對象在由多個部分構成的消息中發送

4.2 Email消息格式與POP協議

1. Email消息格式

• SMTP協議：頭部行header（To、From、Subject）+消息體body
  這裏的頭部行與SMTP命令不一樣
• 多媒體郵件擴展： MIME
  郵件頭部增長額外的行聲明MIME的內容類型

2. 郵件訪問協議：從服務器獲取郵件

• POP協議
• IMAP協議
• HTTP協議（Web瀏覽器收發郵件）

3. POP協議

• 認證過程：客戶端命令（User聲明用戶名、Pass聲明密碼）、服務器響應（+OK、-ERR）
• 事務階段：List、Retr、Dele、Quit
• 「下載並刪除」模式：換了客戶端軟件沒法重讀郵件
• 「下載並保持」模式：不一樣客戶端均可以保留消息的拷貝
• POP3是無狀態的

4. IMAP協議

• 全部消息統一保存在一個地方：服務器
• 容許用戶利用文件夾組織消息
• IMAP支持跨會話（session）的用戶狀態：文件夾名字、文件夾與消息ID之間的映射等

5.DNS應用

5.1DNS概述

1. Internet上主機/路由器的識別問題：IP地址、域名
2. 域名解析系統DNS

• 多層命名服務器構成的分佈式數據庫
• 應用層協議：完成名字的解析
• Internet核心功能，用應用層協議實現
• 網絡邊界複雜

不適用集中式的DNS緣由：單點失敗問題、流量問題、距離問題、維護性問題

3. DNS服務：域名向IP地址的翻譯、主機別名、郵件服務器別名、負載均衡（web服務器）
4. 分佈式層式數據庫：Root DNS servers—com DNS serves—Amazon.com DNS servers

• 根域名服務器
• 頂級域名服務器TLD：負責頂級域名com、org、net、edu等和國家頂級域名cn、uk、fr等
• 權威域名解析服務器：提供組織內部服務器的解析服務（組織負責維護或者服務提供商負責維護）
• 本地域名解析服務器：不屬於層級體系；每一個ISP有一個本地域名服務器；當主機進行DNS查詢時，查詢被髮送到本地域名服務器（做爲代理將查詢轉發給層級式）

5. DNS查詢示例

• 迭代查詢（平等詢問）：主機先訪問本地域名服務器——>本地域名服務器訪問根域名服務器——>我不認識這個域名，可是你能夠問這個服務器——>根域名服務器繼續訪問com域名服務器——>...
• 遞歸查詢（被指示）：主機先訪問本地域名服務器——>本地域名服務器訪問根域名服務器——>我幫你去問這個服務器——>根域名服務器訪問com域名服務器——>...

6. DNS記錄緩存和更新

• 只要域名解析服務器得到域名IP映射，即緩存這一映射（一段時間後緩存條目刪除；本地域名服務器通常會緩存頂級域名服務器的映射）

5.2 DNS記錄和消息

1. DNS記錄： 資源記錄RR

• Type=A
• Type=NS
• Type=CNAME
• Type=MS

2. DNS協議與消息

• 查詢和回覆（消息格式相同）
• 消息頭部：Identification、flag

3. 如何註冊域名
4. 找出那些在應用層實現的Internet核心服務，調研他們的協議、消息格式

6.P2P應用

6.1 原理與文件分發

1. 純P2P架構

• Peer-To-Peer
• 特色：沒有服務器；任意端系統之間直接通訊；節點階段性接入Internet、節點可能更換IP地址

2. 文件分發（客戶機/服務器 VS P2P）：隨着節點數目增長CS架構文件分發所需時間呈線性增加，P2P逐漸趨於水平
3. 應用：BitTorrent（比特流）協議

6.2 索引技術

1. 搜索信息

• P2P系統的索引：信息到節點位置（IP地址+端口號）的映射
• 文件共享（電驢）：利用索引動態跟蹤節點所共享的文件的位置；節點告訴索引它擁有哪些文件；節點搜索索引，從而獲知可以獲得哪些文件
• 即時消息（QQ）：索引負責將用戶名映射到位置；當用戶開啓IM應用時，須要通知索引它的位置；節點檢索索引，肯定用戶的IP地址

2. 集中式索引

• Napster最先採用這種設計：節點加入時，通知中央服務器IP地址和內容；其餘節點查找時，從其餘主機處獲取文件
• 問題：單點時效問題、性能瓶頸、版權問題

3. 洪泛式查詢：Query flooding

• 徹底分佈式架構
• Gnutella採用這種架構：查詢消息經過已有的TCP鏈接發送；節點轉發查詢消息；若是查詢命中，則利用反向路徑發回查詢節點

4. 層次式覆蓋網絡

• 介於集中式索引和洪泛查詢之間的方法：節點和超級節點間維持TCP鏈接；某些超級節點間維持TCP鏈接
• Skype採用這種架構：本質上是P2P的（用戶/節點對之間直接通訊）；私有應用層協議；索引負責維護用戶名和IP地址之間的映射（相似QQ）；索引分佈在超級節點上

還涉及到了Socket編程部分，做相關了解請查閱資料

附：本文內容出於哈爾濱工業大學聶蘭順老師的計算機網絡課程