專欄

計算機網路

網路應用（上）

網路應用（層）內容概述

• 網路應用體系結構
  • 客戶機/服務器
  • P2P
  • 混合結構
• 網路應用的服務需求
  • 可靠性
  • 帶寬
  • 時延
• Internet傳輸層服務模型
  • TCP
  • UDP
• 特定網路應用及協議
  • HTTP
  • SMTP，POP，IMAP
  • DNS
  • P2P應用
• Socket編程
  • TCP
  • UDP

網路應用的基本原理

網路應用體系結構

你使用過哪些網路應用？

網路應用有哪些特點？

與單機應用有哪些本質性的不同？

網路應用應采取什么樣的體系結構？

網路應用的體系結構

• 客戶機/服務器結構（Client-Server，C/S）
• 點對點結構（Peer-to-peer，P2P）
• 混合結構（Hybrid）

客戶機/服務器結構

• 服務器
  • 7*24小時提供服務
  • 永久性訪問地址/域名
  • 利用大量服務器實作可擴展性
• 客戶機
  • 與服務器通信，使用服務器提供的服務
  • 間歇性接入網路
  • 可能使用動態的IP地址
  • 不會與其他客戶機直接通信
• 例子：Web

純P2P結構

• 沒有永遠在線的服務器
• 任意端系統/節點之間可以直接通訊
• 節點間歇性接入網路
• 節點可能改變IP地址
• 優點：高度可伸縮
• 缺點：難于管理

混合結構

能否將兩種結構混合在一起使用？

混合能夠利用兩種的優點同時規避兩種的缺點嗎？

• Napster
  • 檔案傳輸使用P2P結構
• 檔案的搜索采用C/S結構——集中式
  • 每個節點向中央服務器登記自己的內容
  • 每個節點向中央服務器提交查詢請求，查找感興趣的內容
    

網路應用行程通信

網路應用的基礎：行程間通信

• 行程：
  • 主機上運行的程式
• 同一主機上運行的行程之間如何通信？
  • 行程間通信機制
  • 作業系統提供
• 不同主機上運行的行程間如何通信？
  • 訊息交換
    

套接字：Socket

• 行程間通信利用socket發送/接收訊息實作
• 類似于寄信
  • 發送方將資訊送到門外郵箱
  • 發送方依賴（門外的）傳輸基礎設施將訊息傳到接收方所在主機，并送到接收方的門外
  • 接收方從門外獲取資訊
• 傳輸基礎設施向行程提供API
  • 傳輸協議的選擇
  • 引數的設定

如何尋址行程

• 不同主機上的行程間通信，那么每個行程必須擁有識別符號
• 如何尋址主機？——IP地址
  • Q：主機有了IP地址后，是否足以定位行程？
  • A：否，同一主機上可能同時有多個行程需要通信，
• 埠號/Port number
  • 為主機上每個需要通信的行程分配一個埠號
  • HTTP Server：80
  • Mail Server：25
• 行程的識別符號
  • IP地址+埠號
    

應用層協議

• 網路應用需遵循應用層協議
• 公開協議
  • 由RFC(Request For Comments)定義
  • 允許互操作
  • HTTP，SMTP，…
    
• 私有協議
  • 多數P2P檔案共享應用

應用層協議的內容

• 訊息的型別（type）
  • 請求訊息
  • 回應訊息
• 訊息的語法（syntax）/格式
  • 訊息中有哪些欄位（field）？
  • 每個欄位如何描述
• 欄位的語意（semantics）
  • 欄位中資訊的含義
• 規則（rules）
  • 行程何時發送/回應資訊
    

網路應用需求

網路應用對傳輸服務的需求

• 資料丟失（data loss）/可靠性（reliability）
  • 某些網路應用能夠容忍一定的資料丟失：網路電話
  • 某些應用要求100%可靠的資料傳輸：檔案傳輸，telnet
• 時間（timing）/延遲（delay）
  • 有些應用只有在延遲足夠低時才“有效”
  • 網路電話/網路游戲
• 帶寬（bandwidth）
  • 某些應用只有在帶寬達到最低要求時才“有效”：網路視頻
  • 某些應用能夠適應任何帶寬——彈性應用：email

典型網路應用對傳輸服務的需求

Internet提供的傳輸服務

• TCP服務
  • 面向連接：客戶機/服務器行程間需要建立連接
  • 可靠的傳輸
  • 流量控制：發送方不會發送速度過快，超過接收方的處理能力
  • 擁塞控制：當網路負載過重時能夠限制發送方的發送速度
  • 不提供時間/延遲保障
  • 不提供最小帶寬保障
• UDP服務
  • 無連接
  • 不可靠的資料傳輸
  • 不提供：
    • 可靠性保障
    • 流量控制
    • 擁塞控制
    • 延遲保障
    • 帶寬保障

典型網路應用所使用的傳輸層服務

Web應用

Web應用概述

Web與HTTP

• World Wide Wed：Tim Berners-Lee
  • 網頁
  • 網頁互相鏈接
• 網頁（Web Page）包含多個物件（objects）
  • 物件：HTML檔案、JPEG圖片、視頻檔案、動態腳本等
  • 基本HTML檔案：包含對其他物件參考的鏈接
• 物件的尋址（addressing）
  • URL（Uniform Resoure Locator）：統一資源定位器 RFC1738
  • Scheme：//host:port/path
    

HTTP協議概述

• 萬維網應用遵循什么協議？

• 超文本傳輸協議

  • HyperText Transfer Protocol

• C/S結構

  • 客戶——Browser：請求、接收、展示Web物件
  • 服務器——Web Server：回應客戶的請求，發送物件

• HTTP版本：

• 1.0：RFC 1945

• 1.1：RFC 2068

• 使用TCP傳輸服務

  • 服務器在80埠等待客戶的請求
  • 瀏覽器發起到服務器的TCP連接（創建套接字Socket）
  • 瀏覽器接受來自瀏覽器的TCP連接
  • 瀏覽器（HTTP客戶端）與Web服務器（HTTP服務器）交換HTTP訊息
  • 關閉TCP連接

• 無狀態（stateless）

  • 服務器不維護任何有關客戶端過去所發請求的訊息
  • 為什么要采用無狀態的協議？

HTTP連接

HTTP連接的兩種型別

• 非持久性連接（Nonpersistent HTTP）
  • 每個TCP連接最多允許傳輸一個物件
  • HTTP 1.0版本使用非持久性連接
• 持久性連接（Persistent HTTP）
  • 每個TCP連接允許傳輸多個物件
  • HTTP 1.1版本默認使用持久性連接

非持久性連接

回應時間分析與建模

• RTT（Round Trip Time）
  • 從客戶端發送一個很小的資料包到服務器并回傳所經歷的時間
• 回應時間（Response time）
  • 發起、建立TCP連接：1個RTT
  • 發送HTTP請求訊息到HTTP回應訊息的前幾個位元組到達：1個RTT
  • 回應訊息中所含的檔案/物件傳輸時間
  • Total=2RTT + 檔案發送時間

持久性HTTP

• 非持久性連接的問題
  • 每個物件需要2個RTT
  • 作業系統需要為每個TCP連接開銷資源（overhead）
  • 瀏覽器會怎么做？
    • 打開多個并行的TCP連接以獲取網頁所需物件
    • 給服務器端造成影響
• 持久性連接
  • 發送回應后，服務器保持TCP連接的打開
  • 后續的HTTP訊息可以通過這個連接發送
  • 無流水（pipelining）的持久性連接
    • 客戶端只有收到前一個回應后才發送新的請求
    • 每個被參考的物件耗時1個RTT
  • 帶有流水機制的持久性連接
    • HTTP 1.1的默認選項
    • 客戶端只要遇到一個參考物件就盡快發出請求
    • 理想情況下，收到所有的參考物件只需耗時約1個RTT

HTTP訊息格式

HTTP請求訊息

• HTTP協議有兩類訊息
  • 請求訊息（request）
  • 回應資訊（response）
• 請求訊息
  • ASCII：人直接可讀
    

HTTP請求訊息的通用格式

上傳輸入的方法

• POST方法
  • 網頁經常需要填寫表格（form）
  • 在請求訊息的訊息體（entity body）中上傳客戶端的輸入
• URL方法
  • 使用GET方法
  • 輸入資訊通過request行的URL欄位上傳
    

方法的型別

• HTTP/1.0
  • GET
  • POST
  • HEAD
    • 請Server不要將所有請求的物件放入回應訊息中
• HTTP/1.1
  • GET，POST，HEAD
  • PUT
    • 將訊息體中的檔案上傳到URL欄位所指定的路徑
  • DELETE
    • 洗掉URL欄位所指定的檔案

HTTP回應訊息

HTTP回應狀態代碼

• 回應訊息的第一行
• 示例
  • 200 OK
  • 301 Moved Permanently
  • 400 Bad Request
  • 404 Not Found
  • 505 HTTP Version Not Supported
    

體驗HTTP

• 利用telnet登錄到某個Web服務器
  • telnet www.hit.edu.cn 80
• 輸入一個HTTP請求
  • GET /about/profile.htm HTTP/1.1
  • Host:www.hit.edu.cn
• 查看HTTP服務器所回傳的回應資訊
  

Cookie技術

為什么需要Cookie？

HTTP無狀態

很多應用需要服務器掌握客戶端的狀態，如網上購物，如何實作？

Cookie技術

• 某些網站為例辨別用戶身份、進行session跟蹤而存盤在用戶本地終端上的資料（通常經過加密），
• RFC6265

Cookie的組件

• HTTP回應訊息的cookie頭部行
• HTTP請求訊息的cookie頭部行
• 保存在客戶端主機上的cookie檔案，由瀏覽器管理
• Web服務端的后臺資料庫

Cookie的原理

Cookie的作用

• Cookie能夠用于：
  • 身份認證
  • 購物車
  • 推薦
  • Web e-mail
  • …
• 隱私問題
  

Web快取技術

• 功能
  • 在不訪問服務器的前提下滿足客戶端的HTTP請求，
• 為什么要發明這種技術？
  • 縮短客戶請求的回應時間
  • 減少機構/組織的流量
  • 在大范圍內（Internet）實作有效的內容分發
    
• Web快取/代理服務器
  • 用戶設定瀏覽器通過快取進行Web訪問
  • 瀏覽器向快取/代理服務器發送所有的HTTP請求
    • 如果所請求的物件在快取中，快取回傳物件
    • 否則，快取服務器向原始服務器發送HTTP請求，獲取物件，然后回傳給客戶端并保存該物件
  • 快取既充當服務器，也充當服務器
  • 一般由ISP（Internet服務提供商）架設

Web快取示例

• 假定：
  • 物件的平均大小=100,100位元
  • 機構網路中的瀏覽器平均每秒有15個到原始服務器的請求
  • 從機構路由器到原始服務器的往返延遲=2秒
• 網路性能分析：
  • 局域網（LAN）的利用率 = 15%
  • 接入互聯網的鏈路的利用率 = 100%
  • 總的延遲 = 互聯網上的延遲 + 訪問延遲 + 局域網延遲 = 2秒 + 幾分鐘 + 幾微秒

• 解決方案1
  • 提升互聯網接入帶寬 = 10Mbps
• 網路性能分析：
  • 局域網（LAN）的利用率 = 15%
  • 接入互聯網的鏈路的利用率 = 15%
  • 總的延遲 = 互聯網上的延遲 + 訪問延遲 + 局域網延遲 = 2秒 + 幾微秒 + 幾微秒
• 問題：
  • 成本太高

• 解決方案2
  • 安裝Web快取
  • 假定快取命中率是0.4
• 網路性能分析：
  • 40%的請求立刻得到滿足
  • 60%的請求通過原始服務器滿足
  • 接入互聯網的鏈路的利用率下降到60%，從而其延遲可以忽略不計，例如10微妙
  • 總的平均延遲 = 互聯網上的延遲 + 訪問延遲 + 局域網延遲 = 0.6 * 2.01 + 0.4 * n微秒 < 1.4秒

條件性GET方法

• 目標：
  • 如何快取版本有最新的版本，則不需要發送請求物件
• 快取：
  • 在HTTP請求訊息中宣告所持有版本的日期
  • If-modified-since:< date >
  • HTTP/1.0 304 Not Modified
    

Email應用

Email應用概述

Email應用的構成

• Email應用的構成組件

  • 郵件客戶端（user agent）
  • 郵件服務器
  • SMTP協議（Simple Mail Transfer Protocol）

• 郵件客戶端
  

  • 讀、寫Email訊息
  • 與服務器互動，收、發Email訊息
  • Outlook，Foxmail，Thunderbird
  • Web客戶端

• 郵件服務器（Mail Server）
  

  • 郵箱：存盤發給該用戶的Email
  • 訊息佇列（message queue）：存盤等待發送的Email

• SMTP協議

  • 郵件服務器之間傳遞訊息所使用的協議
  • 客戶端：發送訊息的服務器
  • 服務器：接收訊息的服務器

SMTP協議：RFC 2821

• 使用TCP進行email訊息的可靠傳輸
• 埠25
• 傳輸程序的三個階段
  • 握手
  • 訊息的傳輸
  • 關閉
• 命令/回應互動模式
  • 命令（command）：ASCII文本
  • 回應（response）：狀態代碼和陳述句
• Email訊息只能包含7位ASCII碼

Email應用示例

SMTP互動示例

動手嘗試SMTP互動

• telnet servername 25
• 服務器回傳代碼220
• 輸入以下命令與SMTP服務器互動
  • HELO
  • MALL FROM
  • RCPT TO
  • DATA
  • QUIT

SMTP協議

• 使用持久性連接
• 要求訊息必須由7位ASCII碼構成
• SMTP服務器利用CRLF.CRLF確定訊息的結束

與HTTP對比：

• HTTP：拉式（pull）
• SMTP：退式（push）
• 都使用命令/回應互動模式
• 命令和狀態代碼都是ASCII碼
• HTTP：每個物件封裝在獨立的回應訊息中
• SMTP：多個物件在由多個部分構成的訊息中發送

Email訊息格式與POP協議

Email訊息格式

• SMTP：email訊息的傳輸/交換協議
• RFC 822：文本訊息格式標準
  • 頭部行(header)
    • To
    • From 與SMTP不同
    • Subject
  • 訊息體(body)
    • 訊息本身
    • 只能是ASCII字符

多媒體擴展

• MIME：多媒體郵件擴展 RFC 2045，2056
  • 通過在郵件頭部增加額外的行以宣告MIME的內容型別
    

郵件訪問協議

• 郵件訪問協議：從服務器獲取郵件
  • POP：Post Office Protocol [RFC 1939]
• IMAP：Internet Mail Access Protocol [RFC 1730]
  • 更多功能
  • 更加復雜
  • 能夠操縱服務器上存盤的訊息
• HTTP：163，QQ Mail等，

POP協議

• 認證程序
  • 客戶端命令
    • User：宣告用戶名
    • Pass：宣告密碼
  • 服務器回應
    • +OK
    • -ERR
• 事物階段
  • List：列出訊息數量
  • Retr：用編號獲取訊息
  • Dele：洗掉訊息
  • Quit
• “下載并洗掉”模式
  • 用戶如果換了客戶端軟體，無法重讀該郵件
• “下載并保持”模式：不同客戶端都可以保留訊息的拷貝
• POP3是無狀態的

IMAP協議

• 所有訊息統一保存在一個地方：服務器
• 運行用戶利用檔案夾組織訊息
• IMAP支持跨會話（Session）的用戶狀態：
  • 檔案夾的名字
  • 檔案夾與訊息ID之間的映射

DNS應用

DNS概述

DNS：Domain Name System

• Internet上主機/路由器的識別問題
  • IP地址
  • 域名：www.hit.edu.cn
• 問題：域名和IP地址直接如何映射？
• 域名決議系統DNS
  • 多層命名服務器構成的分布式資料庫
  • 應用層協議：完成名字的決議
    • Internet核心功能，用應用層協議實作
    • 網路邊界復雜
• DNS服務
  • 域名向IP地址的翻譯
  • 主機別名
  • 郵件服務器別名
  • 負載均衡：Web服務器
• 問題：為什么不適應集中式的DNS？
  • 單點失敗問題
  • 流量問題
  • 距離問題
  • 維護性問題

分布式層次式資料庫

• 客戶端想要查詢www.amazon.com的IP
  • 客戶端查詢根服務器，找到com域名決議服務器
  • 客戶端查詢com域名決議服務器，找到amazon.com域名決議服務器
  • 客戶端查詢amazon.com域名決議服務器，獲得www.amazon.com的IP地址

DNS根域名服務器

• 本地域名決議服務器無法決議域名時，訪問根域名服務器
• 根域名服務器
  • 如果不知道映射，訪問權威域名服務器
  • 獲得映射
  • 向本地域名服務器回傳映射
• 全球有13個根域名服務器
  

TLD和權威域名決議服務器

• 頂級域名服務器（TLD，top-level domain）：負責com，org，net，edu等頂級域名和國家頂級域名，例如cn，uk，fr等
  • Network Solutions維護com頂級域名服務器
  • Educause維護edu頂級域名服務器
• 權威（Authoritative）域名服務器：組織的域名決議服務器，提供組織內部服務器的決議服務
  • 組織負責維護
  • 服務提供商負責維護

本地域名決議服務器

• 不嚴格屬于層級體系
• 每個ISP有一個本地域名服務器
  • 默認域名決議服務器
• 當主機進行DNS查詢時，查詢被發送到本地域名服務器
  • 作為代理（proxy），將查詢轉發給（層級式）域名決議服務器系統
    

DNS查詢示例

• Cis.poly.edu的主機想獲得gaia.cs.umass.edu的IP地址

• 迭代查詢

  • 被查詢服務器回傳域名決議服務器的名字
  • “我不認識這個域名，但是你可以問題這服務器”
    

• 遞回查詢

  • 將域名決議的任務交給所聯系的服務器
    

例題

如果本地域名服務器無快取，當采用遞回方法決議另一網路某主機域名時，用戶主機、本地域名服務器發送的域名請求訊息數分別為

• A.一條、一條
• B.一條、多條
• C.多條、一條
• D.多條、多條

【決議】域名遞回決議程序中，主機向本地域名服務器發送DNS查詢，被查詢的域名服務器代理后續的查詢，然后回傳結果，所以，遞回查詢時，如果本地域名服務器無快取，則主機和本地域名服務器都僅需要發送一次查詢，故正確答案為 A ，

DNS記錄快取和更新

• 只要域名決議服務器獲得域名——IP映射，即快取這一映射
  • 一段時間過后，快取條目失效（洗掉）
  • 本地域名服務器一般會快取頂級域名服務器的映射
    • 因此根域名服務器不經常被訪問
• 記錄的更新/通知機制
  • RFC 2136
  • Dynamic Updates in the Domain Name System (DNS UPDATE)

DNS記錄和訊息格式

DNS記錄

• 資源記錄（RR，resource records）
  
• Type=A
  • Name：主機域名
  • Value：IP地址
• Type=NS
  • Nama：域（edu.cn）
  • Value：該域權威域名決議服務器的主機域名
• Type=CHAME
  • Name：某一真實域名的別名
    • www.ibm.com - servereast.backup2.ibm.com
  • Value：真實域名
• Type=MX
  • value是與name相對應的郵件服務器

DNS協議與訊息

• DNS協議：
  • 查詢（query）和回復（reply）訊息
  • 訊息格式相同
    
• 訊息頭部
  • Identification：16位查詢編號，回復使用相同的編號
  • flags
    • 查詢或回復
    • 期望遞回
    • 遞回可用
    • 權威回答

如何注冊域名？

• 例子：你剛剛創建了一個公司“Network Utopia”
• 在域名管理結構（如Network Solutions）注冊域名networkutopia.com
  • 向域名管理機構提供你的權威域名決議服務器的名字和IP地址
  • 域名管理機構向com頂級域名決議服務器中插入兩條記錄
    
• 在權威域名服務器中為www.networkutopia.com加入Type A記錄，為networkutopia.com加入Type MX記錄