計算機網絡-網絡應用

網絡應用

網絡應用的體系結構

客戶機/服務器結構(Client-Server, C/S)，點對點結構(Peer-to-peer, P2P)，混合結構(Hybrid)5

客戶機/服務器結構

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

例子：Web

純P2P結構

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

混合結構

可否將兩種結構混合在一塊兒使用？混合可以利用二者的優勢同時規避二者的缺點嗎？

例如Napster：文件傳輸使用P2P結構，文件的搜索採用C/S結構——集中式，每一個節點向中央服務器登記本身的內容，每一個節點向中央服務器提交查詢請求，查找感興趣的內容

網絡應用進程通訊

進程：主機上運行的程序

客戶機進程:發起通訊的進程，服務器進程:等待通訊請求的進程

同一主機上運行的進程之間如何通訊？進程間通訊機制，操做系統提供

不一樣主機上運行的進程間如何通訊？消息交換

套接字: Socket

進程間通訊利用socket發送/接收消息實現，相似於寄信，發送方將消息送到門外郵箱，發送方依賴（門外的）傳輸基礎設施將消息傳到接收方所在主機，並送到接收方的門外，接收方從門外獲取消息，傳輸基礎設施向進程提供API：傳輸協議的選擇，參數的設置

如何尋址進程？

不一樣主機上的進程間通訊，那麼每一個進程必須擁有標識符,尋址主機——IP地址,爲主機上每一個須要通訊的進程分配一個端口號,進程的標識符:IP地址+端口號

應用層協議

網絡應用需遵循應用層協議

• 公開協議
  • 由RFC(Request For Comments)定義
  • 容許互操做
  • HTTP, SMTP, ......
• 私有協議
  • 多數P2P文件共享應用6

應用層協議的內容

• 消息的類型(type)
  • 請求消息
  • 響應消息
• 消息的語法(syntax)/格式
  • 消息中有哪些字段(field)？
  • 每一個字段如何描述
• 字段的語義(semantics)
  • 字段中信息的含義
• 規則(rules)
  • 進程什麼時候發送/響應消息進程如何發送/響應消息

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

數據丟失(data loss)/可靠性(reliability):某些網絡應用可以容忍必定的數據丟失：網絡電話,某些網絡應用要求100%可靠的數據傳輸：文件傳輸，telnet

時間(timing)/延遲(delay): 有些應用只有在延遲足夠低時才「有效」,網絡電話/網絡遊戲

帶寬(bandwidth):某些應用只有在帶寬達到最低要求時才「有效」：網絡視頻,某些應用可以適應任何帶寬——彈性應用：email

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

• TCP服務
  • 面向鏈接: 客戶機/服務器進程間須要創建鏈接
  • 可靠的傳輸
  • 流量控制: 發送方不會發送速度過快，超過接收方的處理能力
  • 擁塞控制: 當網絡負載太重時可以限制發送方的發送速度
  • 不提供時間/延遲保障
  • 不提供最小帶寬保障
• UDP服務
  • 無鏈接
  • 不可靠的數據傳輸
  • 不提供：
    • 可靠性保障
    • 流量控制
    • 擁塞控制
    • 延遲保障
    • 帶寬保障

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

Web應用

超文本傳輸協議: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鏈接,服務器不維護任何有關客戶端過去所發請求的信息，即無狀態

狀態的協議更復雜:需維護狀態(歷史信息)，若是客戶或服務器失效，會產生狀態的不一致，解決這種不一致代價高

HTTP鏈接

• 非持久性鏈接(NonpersistentHTTP)
  • 每一個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 +文件發送時間

持久性鏈接

非持久性鏈接的問題:每一個對象須要2個RTT,操做系統須要爲每一個TCP鏈接開銷資源(overhead),瀏覽器會怎麼作？打開多個並行的TCP鏈接以獲取網頁所需對象,給服務器端形成什麼影響？

持久性鏈接:發送響應後，服務器保持TCP鏈接的打開,後續的HTTP消息能夠經過這個鏈接發送

無流水(pipelining)的持久性鏈接:客戶端只有收到前一個響應後才發送新的請求,每一個被引用的對象耗時1個RTT

帶有流水機制的持久性鏈接:HTTP 1.1的默認選項,客戶端只要遇到一個引用對象就儘快發出請求,理想狀況下，收到全部的引用對象只需耗時約1個RTT

HTTP消息格式

HTTP協議有兩類消息:請求消息(request),響應消息(response),請求消息:ASCII：人直接可讀

TTP請求消息

HTTP請求消息的通用格式

上傳輸入的方法

POST方法:網頁常常須要填寫表格(form),在請求消息的消息體(entity body)中上傳客戶端的輸入

URL方法:使用GET方法,輸入信息經過request行的URL字段上傳

HTTP響應消息

• HTTP響應狀態代碼
  • 200 OK
  • 301 Moved Permanently
  • 400 Bad Request
  • 404 Not Found
  • 505 HTTP Version Not Supported

Cookie技術

爲何須要Cookie？

HTTP協議無狀態不少應用須要服務器掌握客戶端的狀態，如網上購物，如何實現？

Cookie技術:某些網站爲了辨別用戶身份、進行session跟蹤而儲存在用戶本地終端上的數據（一般通過加密）。RFC6265

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

Cookie的原理

Cookie可以用於：身份認證,購物車,推薦,Web e-mail,.......

Web緩存/代理服務器技術

功能:在不訪問服務器的前提下知足客戶端的HTTP請求。

爲何要發明這種技術？

縮短客戶請求的響應時間,減小機構/組織的流量,在大範圍內(Internet)實現有效的內容分發(CDN)

Web緩存/代理服務器:用戶設定瀏覽器經過緩存進行Web訪問,瀏覽器向緩存/代理服務器發送全部的HTTP請求,若是所請求對象在緩存中，緩存返回對象,不然，緩存服務器向原始服務器發送HTTP請求，獲取對象，而後返回給客戶端並保存該對象,緩存既充當客戶端，也充當服務器,通常由ISP(Internet服務提供商)架設

Web緩存示例

假定：對象的平均大小=100,000比特,機構網絡中的瀏覽器平均每秒有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應用的構成組件:郵件客戶端(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碼

SMTP交互示例

SMTP協議使用持久性鏈接,要求消息必須由7位ASCII碼構成,SMTP服務器利用CRLF.CRLF肯定消息的結束

與HTTP對比:

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

Email消息格式與POP3協議

Email消息格式

SMTP：email消息的傳輸/交換協議,RFC 822：文本消息格式標準

• 頭部行(header)
  • To
  • From
  • Subject
• 消息體(body)
  • 消息自己
  • 只能是ASCII字符

Email消息格式：多媒體擴展

MIME：多媒體郵件擴展RFC 2045, 2056

過在郵件頭部增長額外的行以聲明MIME的內容類型

郵件訪問協議

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

• POP: Post Office Protocol [RFC 1939]
  • 認證/受權(客戶端<-->服務器)和下載
• IMAP: Internet Mail Access Protocol [RFC 1730]
  • 更多功能
  • 更加複雜
  • 可以操縱服務器上存儲的消息
• HTTP：163, QQ Mail等。

POP協議

IMAP協議

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

DNS概述

Internet上主機/路由器的識別問題,IP地址,域名：www.hit.edu.cn;問題：域名和IP地址之間如何映射？

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

• DNS服務
  • 域名向IP地址的翻譯
  • 主機別名
  • 郵件服務器別名
  • 負載均衡：Web服務器
• 問題：爲何不使用集中式的DNS？
  • 單點失敗問題
  • 流量問題
  • 距離問題
  • 維護性問題

分佈式層次式數據庫

DNS根域名服務器

本地域名解析服務器沒法解析域名時，訪問根域名服務器,根域名服務器:若是不知道映射，訪問權威域名服務器,得到映射,向本地域名服務器返回映射

全球有13個根域名服務器b

TLD和權威域名解析服務器

頂級域名服務器(TLD, top-level domain): 負責com, org, net,edu等頂級域名和國家頂級域名，例如cn, uk, fr等;Network Solutions維護com頂級域名服務器,Educause維護edu頂級域名服務器

權威(Authoritative)域名服務器：組織的域名解析服務器，提供組織內部服務器的解析服務,組織負責維護,服務提供商負責維護

本地域名解析服務器

不嚴格屬於層級體系,每一個ISP有一個本地域名服務器(默認域名解析服務器),當主機進行DNS查詢時，查詢被髮送到本地域名服務器,做爲代理(proxy)，將查詢轉發給（層級式）域名解析服務器系統8

DNS查詢示例

迭代查詢:被查詢服務器返回域名解析服務器的名字,「我不認識這個域名，可是你能夠問題這服務器」

遞歸查詢:將域名解析的任務交給所聯繫的服務器

若是本地域名服務器無緩存，當採用遞歸方法解析另外一網絡某主機域名時，用戶主機、本地域名服務器發送的域名請求消息數分別爲:一條、一條

域名遞歸解析過程當中，主機向本地域名服務器發送DNS查詢，被查詢的域名服務器代理後續的查詢，而後返回結果。因此，遞歸查詢時，若是本地域名服務器無緩存，則主機和本地域名服務器都僅須要發送一次查詢

DNS記錄緩存和更新

只要域名解析服務器得到域名—IP映射，即緩存這一映射,一段時間事後，緩存條目失效（刪除）,本地域名服務器通常會緩存頂級域名服務器的映射,所以根域名服務器不常常被訪問

記錄的更新/通知機制:RFC 2136,Dynamic Updates in the Domain Name System (DNS UPDATE)

DNS記錄和消息格式

DNS記錄

DNS協議與消息

總結