應用層
- 2.1應用層協定原理
-
- 2.1.1網絡應用程式體系結構
- 2.1.2程序通信
-
- 1.客戶機伺服器程序
- 2.程序與計算機網絡之間的接口
- 2.1.3可控應用程式使用的運輸服務
-
- 1.可靠資料傳輸
- 2.吞吐量
- 3.定時
- 4.安全性
- 2.1.4網際網路提供的運輸服務
-
- 1.TCP
- 2.UDP
- 3.網際網路運輸層協定不提供的服務
- 4.程序尋址
- 2.1.5應用層協定
- 2.2Web應用和HTTP協定
-
- 2.2.1HTTP概況
- 2.2.2非持久連接配接和持久連接配接
- 2.2.3HTTP封包格式
-
- 1.請求封包
- 2.響應封包
- 2.2.4使用者與伺服器的互動:cookie
- 2.2.5緩存伺服器
- 2.2.6條件Get方法
- 2.3檔案傳輸協定:FTP
- 2.4網際網路中的電子郵件
-
- 2.4.1SMTP
- 2.4.2與HTTP的對比
- 2.4.3郵件封包格式和MIME
-
- 1.非ASCII碼資料的MIME擴充
- 2.接收的封包
- 2.4.4郵件通路協定
-
- 1.POP3
- 2.IMAP
- 3.基于Web的電子郵件
- 2.5DNS:網際網路的目錄服務
-
- 2.5.1DNS提供的服務
- 2.5.2DNS工作機理概述
-
- 1.分布式、層次資料庫
- 2.DNS緩存
- 2.5.3DNS記錄和封包
- 2.6P2P應用
-
- 2.6.1P2P檔案分發
-
- 1.P2P體系結構的擴充性
- 2.BitTorrent
- 2.6.2在P2P區域中搜尋資訊
- 2.6.3P2P網際網路電話:Skype
- 2.7TCP套接字程式設計
- 2.8UDP套接字程式設計
2.1應用層協定原理
2.1.1網絡應用程式體系結構
兩種主流體系結構:客戶機/伺服器和P2P
客戶機/伺服器體系結構:一個總是打開的主機(伺服器),服務于來自許多其他稱為客戶機的主機請求。伺服器具有固定的、周知的位址(IP位址)。
P2P體系結構:總是打開的基礎設施伺服器依賴最小,任意間斷連接配接的主機對(對等方),直接互相通信。不用通過專門的伺服器,适用于流量密集型應用程式,如檔案分發、檔案搜尋/共享、網際網路電話和IPTV。
2.1.2程序通信
1.客戶機伺服器程序
客戶機:發起通信的程序
伺服器:會話開始等待聯系的程序
2.程序與計算機網絡之間的接口
程序通過套接字的軟體接口在網絡上發送和接收封包。
套接字:應用程式和網絡之間的應用程式程式設計接口(API)。
應用程式開發者可以控制套接字在應用層端的所有東西,但對套接字的運輸層端幾乎沒有控制。對運輸層的控制:①選擇運輸層協定;②設定運輸層參數,如最大緩存、最大封包段長度等。
2.1.3可控應用程式使用的運輸服務
1.可靠資料傳輸
2.吞吐量
3.定時
4.安全性
2.1.4網際網路提供的運輸服務
網際網路上的應用使用兩個運輸層協定:TCP、UDP
1.TCP
面向連接配接的服務、可靠資料傳輸服務、擁塞控制
2.UDP
不提供不必要服務的輕量級運輸層協定,僅提供最小服務。無連接配接、無擁塞控制
3.網際網路運輸層協定不提供的服務
無吞吐量和定時保證
4.程序尋址
識别接收程序需定義兩種資訊:
①主機的名稱或位址
②指定目的主機上接收程序的辨別。即IP位址+端口号
2.1.5應用層協定
應用層協定定義了:
①交換的封包類型,如請求和響應封包
②各種封包類型的文法,如封包中各個字段及其較長的描述
③字段的語義,即包含在字段中的資訊的含義
④程序何時、如何發送封包及對封包進行響應的規則。
2.2Web應用和HTTP協定
2.2.1HTTP概況
HTTP:超文本傳輸協定,Web的核心。兩部分程式實作:一個客戶機程式和一個伺服器程式。
HTTP:定義封包格式以及客戶機和伺服器如何封包交換。
Web頁面:對象組成的。對象:檔案。
Web浏覽器:實作HTTP的用戶端。
Web伺服器:用于存儲Web對象,每個對象由URL尋址。
伺服器向客戶機發送被請求的檔案時,并不存儲任何關于該客戶機的狀态資訊。HTTP伺服器并不儲存關于客戶機的任何資訊,是以HTTP是一個無狀态協定。
2.2.2非持久連接配接和持久連接配接
非持久連接配接:每個請求/響應對是經一個單獨的TCP連接配接發送
持久連接配接:所有的連接配接及相應的響應經相同的TCP連接配接發送。
HTTP既可以使用非持久連接配接,也可以使用持久連接配接,預設方式使用持久連接配接。
2.2.3HTTP封包格式
HTTP封包:請求封包、響應封包
1.請求封包
①請求行
②首部行:方法字段、URL字段和HTTP協定版本字段
③Connection:Close首部行,是否使用持久連接配接
④User-agent:使用者代理,請求的浏覽器的類型
⑤Accept-language:使用者想得到對象的語言版本
2.響應封包
三部分組成:一個初始狀态行、6個首部行、實體主體。
狀态行有三個字段:協定版本、狀态碼和相應狀态資訊。
2.2.4使用者與伺服器的互動:cookie
Cookie技術有4個組成部分:
①HTTP響應封包中有一個cookie首部行;
②在HTTP請求封包中有一個cookie首部行;
③使用者端系統中保留一個cookie檔案(使用者浏覽器管理);④Web站點有一個後端資料庫。
2.2.5緩存伺服器
Web緩存器:代理伺服器,代表初始Web伺服器來滿足HTTP請求的網絡實體。有自己的磁盤存儲空間,并在存儲空間中儲存最近請求過的對象的拷貝。
2.2.6條件Get方法
條件get方法:允許緩存器證明它的對象是最新的。滿足一下兩個條件為條件GET方法:
①請求封包使用GET方法;
②請求封包中包含一個if-modified-since:首部行。
2.3檔案傳輸協定:FTP
FTP使用兩個并行的TCP連接配接來傳輸檔案,一個是控制連接配接,一個是資料連接配接。
控制連接配接:兩個主機之間傳輸控制資訊,如使用者辨別、密碼、改變遠端目錄的指令以及“put”和“get”檔案指令。
資料連接配接:實際傳輸一個檔案。
FTP使用一個分離的控制連接配接,是以FTP的控制資訊是帶外傳送的。
FTP伺服器必須在整個回話期間保留使用者的狀态資訊。
2.4網際網路中的電子郵件
電子郵件的3個主要組成部分:使用者代理、郵件伺服器、簡單郵件傳輸協定。
2.4.1SMTP
SMTP一般不使用中間郵件伺服器發送郵件,郵件并不在中間的某個郵件伺服器上存留。
2.4.2與HTTP的對比
相同點:都用于從一台主機向另一台主機傳送檔案;
傳送檔案的方式不同
HTTP使用Web伺服器向Web客戶機傳送檔案;SMTP從一個郵件伺服器向另一個郵件伺服器傳送檔案。
傳送方向不同
HTTP主要是一個拉協定,可以裝載Web伺服器上的資訊。
SMTP是一個推協定,發送郵件伺服器吧檔案推向接受郵件伺服器。
資料格式不同
SMTP要求封包使用7位ASCII碼格式。如果封包包含非7位ASCII字元或二進制資料,則封包必須按照7位ASCII碼進行編碼,HTTP無此限制。
處理其他媒體類型的文檔時不同
HTTP将每個對象封裝到自己的HTTP響應封包,SMTP将所有封包對象放在一個封包中。
控制方式不同
HTTP使用帶内控制,FTP使用帶外控制。
2.4.3郵件封包格式和MIME
郵件封包首部必須含有一個From:首部行和一個To:首部行,可以包含一個Subject:首部行或者其他可選首部行。首部行之後是一個空白行,然後是以ACSII格式表示的封包主體。
1.非ASCII碼資料的MIME擴充
MIME:多用途網際網路郵件擴充,滿足多媒體封包或攜帶有非ASCII文本格式的封包的需求。
支援多媒體的兩個關鍵MIME首部是Content-Type:和Content-Transfer-Encoding:
Content-Type:首部允許接收使用者代理對封包采取适當的動作。如啟用圖形解壓縮程式處理封包中的圖形。
Content-Transfer-Encoding:提示使用者代理該封包主體已使用ASCII編碼,支出所使用編碼類型。
根據Content-Transfer-Encoding:将封包主體還原成非ASCII格式,根據Content-Type決定采取何種動作處理封包主體。
2.接收的封包
接收封包會在封包的頂部添加Received:首部行,表示發送該封包的SMTP伺服器名稱(from),接收該封包的SMTP伺服器的名稱(by)以及接收伺服器收到的時間。如果有多條Received則是因為其中經過了多個SMTP伺服器。
2.4.4郵件通路協定
解決現在使用者通過客戶機/伺服器體系結構,通過本地運作代理閱讀郵件伺服器上的電子郵件問題。(傳統的是使用者代理與郵件伺服器在一台主機上)
本地使用者代理不能使用SMTP取回郵件,因為取郵件是一個拉操作,SMTP是一個推協定,這就需要郵件通路協定将郵件伺服器上的郵件傳送到本地PC。目前多個流行的郵件通路協定:第三版的郵局協定(POP3)、網際網路郵件通路協定(IMAP)以及HTTP。
1.POP3
協定簡單、功能有限。
端口:110
POP3按照三各階段進行工作:
特許:使用者代理(明文發送)發送使用者名和密碼鑒别
事務處理:使用者代理取回封包,對封包做删除标記,取消封包删除标記,擷取郵件的統計資訊
更新:出現在客戶機發出了quit指令之後,目的是結束POP3會話,郵件伺服器删除那些被标記為删除的封包。
2.IMAP
POP3協定隻能建立本地檔案夾,将下載下傳的郵件放入本地檔案夾中,不能建立遠端檔案夾以及為封包指派檔案夾的方法。
IMAP将每個封包與一個檔案夾聯系起來,封包第一次到達伺服器,放在收件人的收件箱檔案夾裡。IMAP為使用者提供了建立檔案夾以及在檔案夾之間移動郵件的指令。
還提供了在遠端檔案夾中查詢郵件的指令,按指定條件去查詢比對的郵件。維護了IMAP會話的使用者狀态資訊。允許使用者代理擷取封包元件的指令。
3.基于Web的電子郵件
使用Web浏覽器收發電子郵件。
使用者代理是普通的浏覽器,使用者和其遠端郵箱之間的通信通過HTTP進行。
2.5DNS:網際網路的目錄服務
2.5.1DNS提供的服務
DNS協定是應用層協定的原因:
1.使用C/S模式在通信的端系統之間運作
2.在通信的端系統之間通過下面的端到端運輸層協定傳送DNS封包。
識别主機的兩種方式:
1.主機名
2.IP位址
域名系統(DNS):進行主機名到IP位址轉換的目錄服務。
DNS:
1.一個分層的DNS伺服器實作的分布式資料庫;
2.一個允許主機查詢分布式資料庫的應用層協定。
DNS協定運作在UDP上,使用53端口,運作BIND軟體的UNIX機器。
DNS除了進行主機名到IP位址的轉換外,還提供了一些重要的服務:
-
主機名稱
複雜主機名的主機可以擁有一個或者多個别名。
- 郵件伺服器别名
-
負載配置設定
繁忙站點被備援配置設定在多台IP位址不同的伺服器上,一個IP位址集合對應于同一個規範主機名。DNS資料庫中存儲着這些IP位址集合,客戶機為映射到這個IP位址集合的名字發出一個DNS請求時,伺服器用包含這些位址的封包進行回答,但回答中旋轉這些位址排放的順序。(客戶機放IP位址在前面的伺服器發送HTTP請求封包)。
2.5.2DNS工作機理概述
1.分布式、層次資料庫
DNS伺服器有3中類型:
-
根DNS伺服器
網際網路上有13個根DNS伺服器(标号A到M),大部分位于北美洲。
-
頂級域DNS伺服器
這些伺服器負責頂級域名(如com、org、net、edu、gov)和所有國家的頂級域名(如uk、fr、ca、jp)
-
權威DNS伺服器
網際網路上具有公共可通路主機的每個組織機構必須提供公共可通路的DNS記錄,這些記錄将這些主機名-》IP位址。組織機構的權威DNS伺服器儲存DNS記錄。
組織機構可以選擇實作自己的權威DNS伺服器保持記錄或者支付費用将記錄存儲在某個服務提供商的權威DNS伺服器中。
本地DNS伺服器:主機的本地DNS伺服器臨近本主機、機構ISP的本地DNS伺服器可能與主機在同一區域網路;居民ISP的本地DNS伺服器與主機相隔不超過幾個路由器。
2.DNS緩存
目的:為了改善時延性能并減少在網際網路上到處傳輸的DNS封包數量。
DNS緩存原理:一個DNS伺服器将回答中的資訊緩存在本地存儲器。由于主機與主機名和IP位址間的映射絕不是永久的,是以DNS伺服器在一段時間(通常2天)後将丢棄緩存的資訊。
2.5.3DNS記錄和封包
實作DNS分布式資料庫的所有DNS伺服器共同存儲着資源記錄(RR),RR提供主機名到IP位址的映射。
資源記錄是一個包含下列字段的4元組:(Name,Value,Type,TTL)
Type:
A:Name:主機名,Value:主機名的IP位址
NS:Name:域,value:獲得域中主機IP位址的權威DNS伺服器的主機名。
CNAME:Name:主機名,value:規範主機名
MX:Name:郵件伺服器,value:規範主機名
1.DNS封包
DNS隻有查詢和回答封包。
2.在DNS資料庫中插入記錄
注冊登記機構:一個商業實體,驗證域名的唯一性,将域名輸入DNS資料庫,對所提供的服務收取少量費用。
DDoS帶寬洪泛攻擊:攻擊者向每個DNS根伺服器連續不斷發送大量分組,使大多數合法DNS請求得不到回答。
中間人攻擊:攻擊者截獲來自主機的請求并傳回僞造的回答。
2.6P2P應用
2.6.1P2P檔案分發
1.P2P體系結構的擴充性
對于客戶機/伺服器體系結構,随着對等方數量的增加,分發時間呈線性增長且沒有界。對于P2P體系結構,最小分發時間總小于C/S體系結構的分發時間,且任何多的對等方總是小于一個數。
2.BitTorrent
用于檔案分發的流行P2P協定。
重要的機制:每個洪流具有一個基礎設施節點,稱為追蹤器。當一個對等方加入洪流時,向追蹤器注冊,并周期性的通知追蹤器它仍在洪流中。
過程:選擇對等方-》建立并行TCP連接配接-》詢問每個臨近對他們所具有的塊清單-》對沒有的塊送出請求(最稀罕優先:根據沒有的塊從鄰居中确定最稀罕的塊,優先請求那些最稀罕的塊)-》響應鄰近塊請求(對換算法:确定鄰居優先權,這些鄰居以最高速率供給他資料,将資料塊發給鄰居,每過10秒選擇4個對等方,每過30秒随機選擇另外一個鄰居發送塊)。
2.6.2在P2P區域中搜尋資訊
P2P檔案共享系統有一個索引,它動态跟蹤對等方可供共享的檔案。對于對等方區域可供共享的每個檔案的靠背,索引維護一個記錄,該記錄将有關拷貝的資訊映射到具有該拷貝對等方的IP位址。随着對等方進入和退出以及對等方獲得檔案的新拷貝,索引進行動态更新。
及時訊息應用程式中,有一個映射使用者名與位置(IP位址)的索引。
組織和搜尋索引的3種方法:
1.集中式索引
一台大型伺服器提供索引服務。當使用者啟動P2P檔案共享應用程式時,該應用程式将它的IP位址以及可供共享的檔案名稱通知索引伺服器。索引伺服器從每個活動的對等方那裡收集這些資訊,進而建立一個集中式的動态索引,将每個檔案拷貝映射到一個IP位址集合。
集中式索引的缺點:
- 單點故障。索引伺服器崩潰,整個P2P應用随之崩潰。
- 性能瓶頸和基礎設施費用。大型P2P系統中,有成千上萬使用者,集中式伺服器必須維護一個龐大索引,每秒鐘必須對數千次查詢做出響應。
- 侵犯版權。P2P檔案共享系統允許使用者免費擷取受版權保護的内容。當P2P檔案共享公司有一台集中式索引伺服器時,法律程式迫使索引伺服器關閉。
2.查詢洪範
完全分布式方法。建立在GnutElla協定基礎上,索引全面的分布在對等方的區域中,每個對等方索引可供共享的檔案而不索引其他檔案。
這種設計中,對等方通過已經存在的TCP連接配接,向覆寫網絡中的相鄰對等方發送封包。當Alice要定位“network love”時,她的客戶機向所有的鄰居發送一條查詢封包,該封包包括關鍵詞“network love”。Alice的所有鄰居向他們所有鄰居轉發該封包,這些鄰居又接着向他們的所有鄰居轉發該封包。這個過程被稱為查詢洪範。
該查詢會在連接配接對等方的支撐網絡中産生大量流量。是以設計了範圍受限查詢洪範。(通過設定路徑計數實作)
覆寫網絡中的一個基本問題:如何處理對等方的加入和離開,假定新對等方X要加入覆寫網絡:
1)對等方X必須首先發現某些已經位于覆寫網絡中的其他對等方。解決引導跨接問題的一種方法:讓X維護一張對等方清單,這些對等方經常在覆寫網絡中開機;另一種方法:X聯系維護這種清單的跟蹤站點。
2)與清單上的對等方建立一個TCP連接配接,直到與某個對等方Y建立一個連接配接為止。
3)建立TCP連接配接後,發送一個Ping封包(包括計數字段)。一旦接受到ping封包,向覆寫網絡中所有鄰居轉發,直到計數字段為0.
4)隻要一個對等方Z接收到一個Ping封包,通過覆寫網絡回發一個Pong封包(包括Z的IP位址)
5)X接收pong封包,就直到覆寫網絡中許多對等方的IP位址,然後建立TCP連接配接,進而在覆寫網絡中建立多條邊。
3.層次覆寫
層次覆寫中并非所有對等方都是平等的。與網際網路高速連接配接并具有高可用性的對等方被指派為超級對等方,承擔更多的任務。一個超級對等方可能有幾百個普通對等方作為其自對等方。
一個新對等方與超級對等方之一建立一個TCP連接配接,新對等方将可共享的所有檔案高速超級對等方,超級對等方維護一個索引,索引包括其自對等方正在共享的所有檔案辨別符、有關檔案的中繼資料和保持這些檔案的子對等方的IP位址。
超級對等方之間互相建立TCP連接配接,形成一個覆寫網絡,超級對等方可以向其相鄰超級對等方轉發查詢。
與範圍受限查詢洪範設計相比,層次覆寫設計允許數量多得多的對等方檢查比對,而不會産生過量的查詢流量。
2.6.3P2P網際網路電話:Skype
使用者定位:包括一個用于将Skype使用者名映射到目前IP位址的索引,該索引跨越超級對等方進行分布。
Skype中繼:歸屬網絡中主機使用中繼呼叫對方。歸屬網絡中被配置成通過搭建NAT的路由器提供對網際網路的通路。NAT阻止歸屬網絡以外的主機向歸屬網絡中的主機發起通信。兩個Skype主叫方均具有NAT,則他們都不能接受他人發起的呼叫。可以通過超級對等方和中繼解決這個問題。Alice向系統注冊時被配置設定到一個非NAT的超級對等方,Alice向超級對等方發起會話,NAT隻不接受歸屬網絡之外發起的會話。Alice可以和超級對等方通過會話交換封包。Bob注冊同樣,放Alice呼叫Bob時,她通知超級對等方,超級對等方通知Bob的超級對等方,Bob的超級對等方通知Bob來自Alice的入呼叫。Bob接受呼叫,兩個超級對等方選擇一個非NAT第三方超級對等方(中繼節點),該中繼節點可以在Alice和Bob之間轉發資料。
2.7TCP套接字程式設計
網絡應用程式有兩類:
一類是網絡應用程式,如RFC所定義的标準協定的實作。客戶機程式和伺服器程式必須滿足該RFC所定義的規則。
另一類網絡應用程式是專用的網絡應用程式。客戶機程式和伺服器程式使用的應用層協定不必符合任何現有RFC。
運作在不同機器上的程序彼此通過向套接字發送封包來進行通信,套接字是應用程序和TCP之間的門。應用程式開發者在套接字的應用層一側可以控制所有東西,但是不能控制運輸層一側。
客戶機程序可以向套接字發送任意位元組的資料,TCP保證伺服器程序能夠按發送的順序接收到每個位元組的資料。TCP在客戶機程序和伺服器程序之間提供可靠位元組流服務。
2.8UDP套接字程式設計
UDP是無連接配接的服務,兩個程序間沒有建立管道時所需的初始握手階段。一個程序需要向另一個程序發送一批位元組時,該發送程序需為這批位元組附上目的程序位址。