3.1.1 - 網路應用(層)內容概述
網路應用體系結構
客戶機/伺服器
P2P
混合結構
網路應用的服務需求
可靠性
頻寬
時延
Internet傳輸層服務模型
TCP
UDP
特定網路應用及協議
HTTP
SMTP，POP，IMAP
Socket程式設計
TCP
UDP
3.2.1 - 網路應用體系結構
客戶機/伺服器結構(Client-Server，C/S)
伺服器
7*24小時提供服務
永久性訪問地址/域名
利用大量伺服器實現可擴充套件性
客戶機
與伺服器通訊，使用伺服器提供的服務
間歇性接入網路
可能使用動態IP地址
不會與其他客戶機直接通訊
點對點結構(Peer-to-peer，P2P)
沒有永遠線上的伺服器
任意端系統/節點之間可以直接通訊
節點間歇性接入網路
節點可能改變IP地址
優點：高度可伸縮
缺點：難於管理
混合結構(Hybrid)
Napster
檔案傳輸使用P2P結構
檔案的搜尋採用C/S結構——集中式
每個節點向中央伺服器登記自己的內容
每個節點向中央伺服器提交查詢請求，查詢感興趣內容
3.2.2 - 網路應用程序通訊
程序：主機上執行的程式
客戶機程序：發起通訊的程序
伺服器程序：等待通訊請求的程序
Q：同一主機上執行的程序之間如何通訊？
程序間通訊機制
作業系統提供
Q：不同主機上執行的程序間如何通訊？
訊息交換
套接字Socket
程序間通訊利用socket傳送/接收訊息實現
類似於寄信：
傳送方將訊息送到門外郵箱
傳送方依賴(門外的)傳輸基礎設施將訊息傳到接收方所在主機，並送到接收方的門外
接收方從門外獲取訊息
傳輸基礎設施向程序提供API
傳輸協議的選擇
引數的設定
Q：如何定址程序？
不同主機上的程序間通訊，那麼每個程序必須擁有識別符號
如何定址主機？——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)
程序何時傳送/響應訊息
程序如何傳送/響應訊息
3.2.3 - 網路應用需求
資料丟失(data loss)/可靠性(reliability)
某些網路應用能夠容忍一定的資料丟失：網路電話
某些網路應用要求100%可靠的資料傳輸：檔案傳輸，telnet
時間(timing)/延遲(delay)
有些應用只有在延遲足夠低時才“有效”
網路電話/網路遊戲
頻寬(bandwidth)
某些應用只有在頻寬達到最低要求時才“有效”：網路影片
某些應用能夠適應任何頻寬——彈性應用email
Internet提供的傳輸服務
①TCP服務
面向連線
客戶機/伺服器程序間需要建立連線
可靠的傳輸
流量控制
傳送方不會傳送速度過快，超過接收方的處理能力
擁塞控制
當網路負載過重時能夠限制傳送方的傳送速度
不提供：
時間/延遲保障
最小頻寬保障
②UDP服務
無連線
不可靠的資料傳輸
不提供：
可靠性保障
流量控制
擁塞控制
延遲保障
頻寬保障
3.3.1 - Web應用概述
World Wide Web：Tim Berners-Lee
網頁(Web Page)包含多個物件(objects)
物件：HTML檔案、JPEG圖片、影片檔案、動態指令碼等
基本的HTML檔案：包含對其他物件引用的連結
物件的定址(addressing)
URL(Uniform Resource Locator)：統一資源定位器
Scheme://host:port/path
HTTP協議概述
超文字傳輸協議 HyperText Transfer Protocol
C/S結構
客戶 Browser：請求、接收、展示Web物件
伺服器 Web Server：響應客戶的請求，傳送物件
使用TCP傳輸服務
伺服器在80埠等待客戶的請求
瀏覽器發起到伺服器的TCP連線(建立套接字Socket)
伺服器接收來自瀏覽器的TCP連線
瀏覽器(HTTP客戶端)與Web伺服器(HTTP伺服器)交換HTTP訊息
關閉TCP連線
無狀態(stateless)
伺服器不維護任何有關客戶端過去所發請求的資訊
PS：有狀態的協議更加複雜：
需維護狀態(歷史資訊)
如果客戶端或伺服器失效，會產生狀態的不一致，解決這種不一致的代價高
3.3.2 - HTTP連線型別
①非永續性連線(Nonpersistent HTTP)
每個TCP連線最多允許傳輸一個物件
HTTP 1.0版本使用非永續性連線
響應時間分析與建模
RTT(Round Trip Time)
從客戶端傳送一個很小的資料包到伺服器並返回所經歷的時間
響應時間(Response time)
發起、建立TCP連線：1個RTT
傳送HTTP請求訊息到HTTP響應訊息的前幾個位元組到達：1個RTT
響應訊息中所含的檔案/物件傳輸時間
Total = 2RTT + 檔案傳送時間
非永續性連線的問題
每個物件需要2個RTT
作業系統需要為每個TCP連線開銷資源(overhead)
瀏覽器會怎麼做？
開啟多個並行的TCP連線以獲取網頁所需物件
給伺服器端造成什麼影響？很大的TCP資源開銷
②永續性連線(Persistent HTTP)
每個TCP連線允許傳輸多個物件
HTTP 1.1版本預設使用永續性連線
傳送響應後，伺服器保持TCP連線的開啟
後續的HTTP訊息可以透過這個連線傳送
無流水(pipelining)的永續性連線
客戶端只有收到前一個響應後才傳送新的請求
每個被引用的物件耗時1個RTT
帶有流水機制的永續性連線
HTTP 1.1的預設選項
客戶端只要遇到一個引用物件就儘快發出請求
理想情況下，收到所有的引用物件只需耗時約1個RTT
3.3.3 - HTTP訊息格式
HTTP協議有兩類訊息
請求訊息(request)
響應訊息(response)
請求訊息
ASCII：人直接可讀
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欄位所指定的檔案)
3.3.4 - Cookie技術
Q：為什麼需要Cookie？
HTTP協議無狀態，但很多應用需要伺服器掌握客戶端的狀態，如網上購物，如何實現？引用Cookie技術
Cookie技術
某些網站為了辨別使用者身份、進行session跟蹤而儲存在使用者本地終端上的資料(通常經過加密)
RFC6265
Cookie的元件
HTTP響應訊息的cookie頭部行
HTTP請求訊息的cookie頭部行
儲存在客戶端主機上的cookie檔案，由瀏覽器管理
Web伺服器端的後臺資料庫
Cookie原理
Cookie作用
Cookie能夠用於：身份認證、購物車、推薦、Web email
3.3.5 - Web快取/代理伺服器技術
在不訪問伺服器的前提下滿足客戶端的HTTP請求
縮短客戶請求的響應時間
減少機構/組織的流量
在大範圍內(Internet)實現有效的內容分發
Web快取/代理伺服器
使用者設定瀏覽器透過快取進行Web訪問
瀏覽器向快取/代理伺服器傳送所有的HTTP請求
如果所請求物件在快取中，快取返回物件
否則，快取伺服器向原始伺服器傳送HTTP請求，獲取物件，然後返回給客戶端並儲存該物件
快取既充當客戶端，也充當伺服器
一般由ISP(Internet服務提供商)架設
Web快取示例
條件性GET方法
目標：
如果快取有最新的版本，則不需要傳送請求物件
快取：
在HTTP請求訊息中宣告所持有版本的日期
if-modified-since:
伺服器：
如果快取的版本是最新的，則響應訊息中不包含物件
HTTP/1.0 304 Not Modified
3.4.1 - Email應用概述
Email應用的構成元件
①郵件客戶端(user agent)
讀寫Email訊息
與伺服器互動，收、發Email訊息
Outlook、Foxmail、Thunderbird
Web客戶端
②郵件伺服器
郵箱：儲存發給該使用者的Email
訊息佇列(message queue)：儲存等待傳送的Email
③SMTP協議(Simple Mail Transfer Protocol)
郵件伺服器之間傳遞訊息所使用的協議
客戶端：傳送訊息的伺服器
伺服器：接收訊息的伺服器
RFC 2821
使用TCP進行email的可靠傳輸，埠25
傳輸過程的三個階段
握手、訊息的傳輸、關閉
命令/響應互動模式
命令(command)：ASCII文字
響應(response)：狀態程式碼和語句
使用永續性連線
要求訊息必須由7位ASCII碼構成
SMTP伺服器利用CRLF.CRLF確定訊息的結束
與HTTP對比
HTTP：拉式(pull)
SMTP：推式(push)
都使用命令/響應互動模式
命令和狀態程式碼都是ASCII碼
HTTP：每個物件封裝在獨立的響應訊息中
SMTP：多個物件在由多個部分構成的訊息中傳送
SMTP互動示例
3.4.2 - Email訊息格式與POP協議
SMTP：email訊息的傳輸/交換協議
RFC 822：文字訊息格式標準
頭部行(header)
To
From
Subject
訊息體(body)
訊息本身
只能是ASCII字元
MIME：多媒體郵件擴充套件 RFC 2045,2056
透過在郵件頭部增加額外的行以宣告MIME的內容型別
郵件訪問協議
從伺服器獲取郵件
POP：Post Office Protocol [RFC 1939]
認證/授權(客戶機<--->伺服器)和下載
①認證過程
客戶端命令
User：宣告使用者名稱
Pass：宣告密碼
伺服器響應
+OK
-ERR
②事務階段
List：列出訊息數量
Retr：用編號獲取訊息
Dele：刪除訊息
Quit
“下載並刪除”模式
使用者如果換了客戶端軟體，無法重讀該郵件
“下載並儲存”模式
不同客戶端都可以保留訊息的複製
POP3是無狀態的
IMAP：Internet Mail Access Protocol [RFC 1730]
更多功能、更加複雜、能夠操縱伺服器上儲存的訊息
所有訊息統一儲存在一個地方：伺服器
允許使用者利用資料夾組織訊息
IMAP支援跨會話(Session)的使用者狀態
資料夾的名字
資料夾與訊息ID之間的對映等
HTTP：163、QQ等
3.5.1 - DNS概述
DNS：Domain Name System
解決Internet上主機/路由器的識別問題
IP地址、域名
Q：域名和IP地址之間如何對映？
域名解析系統DNS
多層命名伺服器構成的分散式資料庫
應用層協議：完成名字的解析
Internet核心功能，用應用層協議實現
網路邊界複雜
DNS服務
域名向IP地址的翻譯
主機別名
郵件伺服器別名
負載均衡：Web伺服器
Q：為什麼不使用集中式的DNS？
單點失敗問題
流量問題
距離問題
維護性問題
分散式層次式資料庫
客戶端想要查詢www.amazon.com的IP
客戶端查詢根伺服器，找到com域名解析伺服器
客戶端查詢com域名解析伺服器，找到amazon.com域名解析伺服器
客戶端查詢amazon.com域名解析伺服器，獲得www.amazon.com的IP地址
DNS根域名伺服器
本地域名解析伺服器無法解析域名時，訪問根域名伺服器
根域名伺服器
如果不知道對映，訪問權威域名伺服器
獲得對映
向本地域名伺服器返回對映
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地址
迭代查詢
被查詢伺服器返回域名解析伺服器的名字
“我不認識這個域名，但你可以問這個伺服器”
遞迴查詢
將域名解析的任務交給所聯絡的伺服器
DNS記錄快取和更新
只要域名解析伺服器獲得域名——IP對映，即快取這一對映
一段時間後，快取條目失效(刪除)
本地域名伺服器一般會快取頂級域名伺服器的對映，因此根域名伺服器不經常被訪問
記錄的更新/通知機制
RFC 2136
Dynamic Updates in the Domain Name System(DNS UPDATE)
3.5.2 - DNS記錄和訊息
DNS記錄
資源記錄(RR，resource，records)
RR format：(name，value，type，ttl)
Type=A
Name：主機域名
Value：IP地址
Type=NS
Name：域(edu.cn)
Value：該域權威域名解析伺服器的主機域名
Type=CNAME
Name：某一真實域名的別名
Value：真實域名
Type=MX
Value是與name相對應的郵件伺服器
DNS協議與訊息
DNS協議
查詢(query)和回覆(reply)訊息
訊息格式相同
訊息頭部
Identification：16位查詢編號，回覆使用相同的編號
flags：查詢或回覆、期望遞迴、遞迴可用、權威回答
Q：如何註冊域名？
在域名管理機構註冊域名
向域名管理機構提供你的權威域名解析伺服器的名字和IP地址
域名管理機構向com頂級域名解析伺服器中插入兩條記錄
在權威域名解析伺服器中為www.networkuptopia.com加入TypeA記錄，為networkutopia.com加入TypeMX記錄