網路應用
網路應用的體系結構
客戶機/服務器結構(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協議與訊息
總結
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/85075.html
標籤：其他