一、應用層協議原理
1、網絡應用程序體系結構
應用程序體系結構由應用程序研發者設計，規定了如何在各種端系統上組織該應用程序。現代網絡用用程序中有兩種主流體系結構：客戶-服務器體系結構或對等體系機構（P2P）：
- 在客戶-服務器體系結構中，客戶相互之間不直接通信，此外服務器具有固定的、周知的地址稱爲IP地址。
- 在一個P2P體系結構中，對位於數據中心的專用服務器有最小（或沒有）依賴。應用程序在間斷連接的主機對直接使用直接通信，這些主機對被稱爲對等方。如文件共享和下載加速器等軟件。P2P體系結構的特徵之一是它的自擴展性，每個對等方通過向其他對等方分發文件也爲系統增加服務能力。，它們通常不需要龐大的服務器基礎設施和服務器帶寬。但其安全性和可靠性會面臨一些挑戰。
部分應用具有混合的體系結構，它結合了客戶-服務器和P2P元素，如許多即時訊息應用。
2、進程通信
用操作系統的術語來說，進行通信的是進程而不是程序。在兩個不同端系統上的進程，通過跨域計算機網絡交換報文而相互通信。
2.1、客戶和服務器進程
網絡應用程序由成對的進程組成，這些進程通過網絡相互發送報文。在一對進程之間的通信會話場景中，發起通信的進程被標識爲客戶，在會話開始時等待聯繫的進程是服務器。在P2P文件共享系統中，一個進程既能上傳文件又能下載文件，所以進程既是客戶又是服務器。
2.2、進程與計算機網絡之間的接口
進程通過一個稱爲套接字的軟件接口向網絡發送報文和從網絡接受報文，可以把進程想象爲房子，套接字類比爲門，門與門之間的是傳輸設施。由於套接字是建立網絡應用程序的可編程接口，因此套接字也稱爲應用程序和網絡之間的應用程序編程接口。應用程序開發者可以控制套接字在應用層端的一切，但是對其在運輸層端幾乎沒有控制權，僅能選擇運輸層協議，設定幾個運輸層參數。
2.3、進程尋址
在因特網中主機由IP地址標識，目的地端口號來標識對應的應用程序。
3、可供應用程序使用的運輸服務
包括因特網在內的很多網絡提供了不止一種運輸層協議，當開發一個應用時，必須選擇一種可用的運輸層協議。應用程序進行根據可靠數據傳輸、吞吐量、定時和安全性四個方面考量選擇對應的協議。
4、因特網提供的運輸服務
因特網（更一般的是TCP/IP網絡）爲應用程序提供兩個運輸層協議，即UDP和TCP
4.1、TCP服務
TCP服務模型包括面向連接服務和可靠數據傳輸服務，當某個應用程序調用TCP作爲其運輸協議時，該應用程序就能獲得來自TCP的這兩種服務：
- 面向連接的服務：在應用程序數據報文開始流動之前，TCP讓客戶和服務器相互交換運輸層控制信息，這個所謂的握手過程提醒客戶和服務器，讓它們爲大量分組做準備。在完成握手後，一個TCP連接就在兩個進程的套接字之間建立了。這條連接是全雙工的，即連接雙方的進程可以在此連接上同時進行報文收發。當應用程序結束報文發送後，必須拆除連接
- 可靠的數據傳送服務：通信進程能夠依靠TCP、無差別按適當順序交付所有發送的數據。當應用程序的一端將字節流傳送進套接字時，它能夠依靠TCP將相同的字節交付給接收方的套接字，而沒有字節的丟失和冗餘。
TCP協議還擁有擁塞控制機制，當發送方和接受方之間的網絡出現擁塞時，TCP的擁塞控制機制會抑制發送進程。TCP擁塞控制同時也試圖限制每個TCP連接，使它們達到公平共享網絡帶寬的目的。
4.2、UDP服務
UDP是一種不提供不必要服務的輕量級運輸協議，它提供最小服務。它是無連接的，因此在兩個進程通信前沒有握手過程。它提供一種不可靠數據傳輸服務。此外，它也沒有擁塞控制機制。
5、應用層協議
應用層協議定了了運行在不同端系統上的應用程序進程如何互相傳遞報文，特別是應用層協議定義了：
- 交換報文的類型，如請求報文和響應報文；
- 各種報文類型的語法，如報文中的各個字段如何定義和描述；
- 字段的語義，即這些字段中信息的含義；
- 確定一個進程何時及如何讓發送報文，對報文進行響應的規則。
二、Web和Http
1、Http概述
Web的應用層協議是超文本傳輸協議，它是Web的核心。Http由兩個程序實現，一個客戶程序和一個服務器程序。Http定義了Web客戶向服務器請求Web頁面的方式，以及服務器向客戶傳送Web頁面的方式。
Http使用TCP作爲它的支撐運輸協議。一旦客戶向它的套接字接口發送了一個請求報文，該報文就脫離了客戶控制並進入TCP的控制。需要注意的是服務器向客戶發送被請求的文件，而不存儲任何關於該客戶的狀態，所以說HTTP是一個無狀態協議。
2、非持續連接和持續連接
客戶可以發出一些列請求並且服務器對每個請求進行響應時，由於這一系列請求可以以規則的間隔週期性或間斷性的發出，且當這些請求是經TCP進行的，應用程序開發者就需要做出一個選擇，即每個請求/響應對是經一個單獨的TCP連續發送，還是所有的請求及其響應經相同的TCP連接發送。前者被稱爲非持續連接，後者被稱爲持續連接。HTTP既能使用非持續連接也能使用持續連接，其默認使用持續連接，但可配置爲非持續連接。
2.1、採用非持續連接的HTTP
在非持續連接中，每個TCP連接只傳輸一個請求報文和響應報文，但在默認情況下，大部分瀏覽器打開5~10個並行的TCP連接，而每條連接處理一個請求響應事務。往返時間（RTT）是指一個短分組從客戶端到服務器然後再返回客戶所花費的時間，RTT包括分組傳播時延，分組的中間路由器和交換機上的排隊時延以及分組處理時延。三次握手中的前兩部分花費了一個RTT，第三部分的確認操作可以結合發送報文操作，而服務器響應報文後又花費一個RTT，所以粗魯來講，總的響應時間就是兩個RTT加上服務器傳輸HTML的時間
非持續連接有兩個缺點：必須爲每個請求對象建立和維護一個全新的連接，這意味這Web服務器和客戶都要分配TCP的緩衝區和保持TCP變量，這無疑是一種負擔。每個對象的傳輸都需要經受兩倍的RTT時延
2.2、採用持續連接的HTTP
在採用Http1.1持續連接的情況下，一個完整的Web頁面可以用單個持續TCP連接進行傳送，甚至位於同一臺服務器的多個Web頁面在從該服務器發送給同一個客戶時，可以在單個持續TCP連接上進行，它們可以一個接一個的發送，而不必等待對未決請求的回答。如果一條連接經過一段時間後仍未被使用，HTTP服務器就關閉該連接。Http/2是在Http1.1基礎上構建的，它允許在相同連接中多個請求和回答交錯，並增加了在該連接中優化HTTP報文請求和回答的機制。
3、HTTP報文格式
3.1、HTTP請求報文
Http請求報文的第一行叫做請求行（request line），後繼的行叫做首部行（header line）。請求行有三個字段：方法字段，URL字段和HTTP版本字段。首部行中的Host爲Web代理高速緩存提供需要；Connection：Open/Close指明是否使用持續連接；User-agent指明用戶代理，即向服務器發送請求的瀏覽器的類型；Accept-language表示用戶想得到的對象的版本。另外首部後面會有一個實體體，使用Get方法時實體體爲空，使用Post方法時實體體纔有內容。
3.2、HTTP響應報文
響應報文有三個部分，一個初始狀態行，6個首部行以及實體體（entity body）。實體體是報文的主要部分，它包含了所請求的對象本身。狀態行有三個字段，協議版本字段，狀態碼和相應的狀態信息。首部行中的Connection指明是否需要持續連接；Date爲服務器從它的文件系統中檢索到該對象，將對象插入響應報文併發送該響應報文的時間；Server表示它是由Apache服務器產生的，類似請求報文中的User-agent；Last-modified指示了對象創建或最後修改的日期和時間。它對於緩存服務器來說非常重要；Content-Length指示了被髮送對象的字節數；Content-Type指示了實體體中的對象是HTML文件。
4、用戶與服務器的交互：Cookie
Web站點爲了能夠識別用戶，或限制用戶的訪問，或將內容與用戶身份聯繫起來，爲此Http使用了Cookie。Cookie技術有4個組件：
- 在Http響應報文中的一個Cookie首部行；
- 在Http請求報文中的一個Cookie首部行；
- 在用戶端系統中保留一個Cookie文件，並由用戶的瀏覽器進行管理；
- 位於Web站點的一個後端數據庫；
Cookie可以用於標識一個用戶，後續會話中，瀏覽器向服務器傳遞一個Cookie首部，從而服務器標識了用戶。因此Cookie可以在無狀態的Http之上建立一個用戶會話層。
5、Web緩存
Web緩存器也叫代理服務器，它是能夠代表初始Web服務器來滿足HTTP請求的網絡實體。Web緩存器即是服務器又是客戶，當它接受瀏覽器的請求併發迴響應時它是一個服務器，當它向服務器發出請求並接受響應時，它是一個客戶。通過使用內容分發網絡CDN，Web緩存器正在因特網中發揮這越來越重要的作用。
6、條件Get方法
儘管高速緩存能夠減少用戶感受到的響應時間，但同時也引入了一個問題，即存放在緩存器中的對象副本可能是陳舊的，幸好Http協議有一種機制，允許緩存器證實它的對象是最新的。這種機制就是條件Get方法。如果請求報文使用Get方法，並且請求報文中包含一個If-Modified-Since首部行，那麼Http請求報文就是一個條條件Get請求報文。條件Get報文會將Last-Modified的值告訴服務器，服務器對比這兩個時間判斷對象有無更新。如果該對象沒有更新，則返回一個帶有304狀態碼 Not Modified的報文，沒有包含對象；如果對象已更新，則返回一個帶有被請求對象的報文。
三、因特網中的電子郵件
因特網電子郵件系統有3個主要組成部分：用戶代理，郵件服務器和簡單郵件傳輸協議。
- 用戶代理允許用戶閱讀、回覆、轉發、保存和撰寫郵件，如Outlook就是用戶代理的例子。
- 郵件服務器是電子郵件體系的核心，從發送方的用戶代理開始，傳送到發送方的電子郵件服務器，再傳送到接受方的電子郵件服務器，最後到接收方，如果發送方不能將郵件交付給接收方，則會將郵件保存在服務器的報文隊列中，每30分鐘進行一次嘗試，如若不能成功則會刪除該報文並通知發送方。
- SMTP是因特網電子協議中的應用層協議，它使用TCP可靠數據傳輸服務。它既可以表現爲客戶，也可以表現爲服務器。
1、SMTP
SMTP一般不使用中間郵件服務器發送郵件，當郵件保存至發送方電子郵件服務器的報文隊列中後，SMTP客戶端會建立與接收方的TCP連接，如果接受方因沒有開機等原因，發送方會在稍後繼續嘗試連接。一旦連接建立，SMTP的客戶與服務就會執行某些應用層的握手。
SMTP限制所有郵件的體部分只能採用簡單的7比特ASCII表示，即在用SMTP發送郵件之前，需要將二進制的多媒體數據編碼爲ASCII碼，並在傳輸後將ASCII碼還原爲多媒體數據。而按照ASCII碼的表示方法，每個報文以CRLF.CRLF結束，其中CR和LF分別表示爲回車和換行。需要指出的是SMTP使用持續連接。
2、與Http的對比
SMTP和Http都用於從一臺主機向另一臺主機傳送文件，HTTP是用Web服務器向Web客戶傳送文件，SMTP則是從一個郵件服務器向另一個郵件服務器傳送文件，兩者使用持續連接，但也有一些重要的區別：
- HTTP是拉協議，它由接收方發起，從服務器拉取部分信息；SMTP是推協議，即發送郵件服務器把文件推向接收服務器，且連接由發送方發起；
- SMTP要求報文使用7比特的ASCII碼格式，HTTP則不受此限制；
- 當處理一個既包含文本又包含圖形的文檔，HTTP把每個對象封裝到它自己的HTTP響應報文中，而SMTP則把所有報文對象放在報文中；
3、郵件報文格式
郵件報文由包含環境信息的首部和報文體組成，首部行和報文體用空行（即回車換行）進行分隔。每個首部行包含一些可讀的文本，由關鍵字，冒號和值組成，每個首部必須含有一個From：首部行和To：首部行，一個首部也許包含一個Subject：首部行以及其他可選的首部行。
4、郵件訪問協議
接收方不能通過SMTP得到報文，因爲取報文是一個拉動作，而SMTP是一個取協議，所以我們需要引入一個特殊的郵件訪問協議來解決難題，該協議將接受方的郵件服務器上的報文傳送至用戶代理。目前有一些流行的郵件訪問協議，包括第三版的郵局協議（POP3）、因特網郵件訪問協議（IMAP）以及Http。
4.1、POP3
POP3協議簡單，故功能有限。它按照三個階段進行工作：特許，事務處理及更新。第一階段用戶代理以明文形式發送用戶名和口令鑑別用戶；第二階段用戶代理取回報文，在該階段用戶代理可以對報文進行刪除標記，取消報文刪除標記，獲取郵件統計信息等動作；第三階段出現在客戶發出quit命令之後，目的是結束該POP3對話，這時該郵件服務器刪除被標記爲刪除的報文。
特許階段有兩個主要的命令user
4.2、IMAP
POP3協議沒有爲用戶提供任何創建遠程文件夾併爲報文指派文件夾的方法，IMAP正是爲此應運而生。IMAP可以將報文與文件夾聯繫起來，併爲用戶提供了在遠程文件夾中查詢郵件的命令，按指定條件去查詢匹配的郵件，它還維護了IMAP會話的用戶狀態信息，IMAP另一個重要的特性是它具有允許用戶代理獲取報文某些部分的命令。
4.3、基於Web的電子郵件
在此種情況下，郵件服務器之間仍然使用SMTP發送和接受郵件，而郵件服務器和瀏覽器之間的傳遞則是使用Http協議。
四、DNS：因特網的目錄服務
主機的一種標識方式是使用主機名，但由於路由器無法處理這類不定長的字母數字組合，主機也可以使用IP地址進行標識。
1、DNS提供的服務
我們需要一種能進行主機名到IP地址轉換的目錄服務，來處理由於不同需求而存在的主機名和IP地址。這就是域名系統（Domain Name System,DNS）的主要任務。DNS是一個由分層的DNS服務器實現的分佈式數據庫，也是一個使得主機能夠查詢分佈式數據庫的應用層協議。DNS協議運行在UDP之上，使用53端口。
DNS通常是由其他應用層協議所使用的，包括HTTP、SMTP和FTP，將用戶提供的主機名解析爲IP地址。它還提供一些重要的服務：
-
主機別名：有着複雜主機名的主機擁有一個或多個別名，其複雜主機名稱爲規範主機名，應用程序可以調用DNS來獲取主機別名對應的規範主機名及IP地址；
-
郵件服務器別名：電子郵件應用程序可以調用DNS，對提供的主機名別名進行解析，以獲取該主機的規範主機名及其IP地址；
-
負載分配：DNS也用在冗餘的服務器之間進行負載分配，DNS數據庫存儲着這些IP地址的集合，當客戶對映射到某地址集合的名字發出一個DNS請求時，該服務器用IP地址的整個集合進行響應，但在每個回答中循環這些地址次序
2、DNS工作機理概述
DNS的一種簡單設計是在因特網只使用一個DNS服務器，該服務器包含所有的映射。但會有以下問題：
- 單點故障：如果該DNS服務器故障，整個因特網會隨着癱瘓；
- 通信容量：單個DNS服務器不得不處理所有的DNS查詢；
- 遠距離的集中式數據庫：不能臨近所有查詢客戶，中間還會經過低速和擁塞的鏈路，導致嚴重的時延；
- 維護：不得不保留所有的因特網主機記錄，導致中央數據庫龐大，還不得不解決頻繁更新的問題；
2.1、分佈式、層次數據庫
爲了處理擴展性問題，DNS使用了大量的DNS數據庫，它們以層次的方式組織，並分佈在全世界範圍內。大致來說，有3種類型的DNS服務器：根DNS服務器，頂級域（TLD）DNS服務器和權威DNS服務器：
- 根DNS服務器：根服務器提供TLD服務器的IP地址
- 頂級域DNS服務器：每個頂級域（com、org、net等）和所有國家的頂級域（uk、ca、jp）等，都有TLD服務器
- 權威DNS服務器：在因特網上具有公共可訪問主機的每個組織必須提供公共可訪問的DNS記錄，這些記錄將這些主機的名字映射爲IP地址。
還有一類重要的DNS服務器，稱爲本地DNS服務器。每個ISP都有一臺本地DNS服務器，當主機與某個ISP連接時，該ISP提供一臺主機的IP地址，該主機具有一臺或多臺其本地DNS服務器的IP地址。在實踐中，從請求主機到本地DNS服務器的查詢是遞歸的，其餘的查詢是迭代的。
2.2、DNS緩存
當DNS服務器接受一個DNS回答時，它能將映射緩存在本地存儲器中，但這種映射並不是永久的。
3、DNS記錄和報文
共同實現DNS分佈式數據庫的所有DNS服務器存儲了資源記錄（Resource Record），RR提供了主機名到IP地址的映射。每個DNS回答報文包含一條或多條資源記錄。TTL是該記錄的生存時間，同時記錄還有不同的類型，Name和Value的值取決於Type。
- Type=A時，Name是主機名，Value是該主機名對應的IP地址；
- Type=NS時，Name是個域，Value是知道如何獲得該域中主機IP地址的權威DNS服務器的主機名；
- Type=CNAME時，Value是別名爲Name的郵件服務器的規範主機名；
- Type=MX時，Value是個別名爲Name的郵件服務器的規範主機名；
3.1 、DNS報文
DNS報文有查詢和回答兩種報文，並且它們有着相同的格式
- 前12個字節是首部區域。第一個字段是一個16比特的數，用於標識該查詢，這個標識符會被複制到對查詢的回答報文中，以便讓客戶用它來匹配發送的請求和接受到的回答。標識字段含有若干標誌，如1比特的”查詢/回答"標誌位指出是查詢保溫還是回答報文，1比特的請求名字是否爲權威DNS服務器的標誌位，1比特的是否遞歸查詢的標誌位等。此外在該首部中，還有4個關於數量的字段，指出了在首部後的4類數據區域出現的數量
- 問題區域包含正在進行的查詢信息，包括名字字段，類型字段等；
- 來自DNS服務器的回答中，回答區域包含了對最初請求的名字的資源記錄，回答區域中可以包含多條RR，因此一個主機名能夠有多條IP地址；
- 權威區域包含了其他權威服務器的記錄；
- 附加區域包含了其他有幫助的記錄。
3.2、在DNS數據庫中插入記錄
如何註冊登記你的域名？首先你要在註冊等級機構註冊你的域名，提供你的基本和輔助權威DNS服務器的名字和IP地址。註冊登記機構將確保一個類型NS和類型A的記錄輸入TLD com服務器，你還要確保用於Web服務器的類型A資源記錄和用於郵件服務器的類型MX資源記錄被輸入你的權威DNS服務器中。每臺DNS服務器中的內容都是靜態配置的，最近DNS協議添加了一個更新選項，可以通過DNS報文對數據庫中的內容進行動態添加或刪除。
五、P2P文件分發
在P2P文件分發中，每個對等方能夠向其他對等放重新分發它已經收到的該文件的任何部分，從而在分發過程中協助該服務器，目前最爲流行的P2P文件分發協議是BitTorrent
1、P2P體系結構的擴展性
對於客戶-服務器體系結構，隨着對等方數量的增加，分發時間呈線性增長且沒有界。對於P2P體系結構，最小分發時間不僅總是小於客戶-服務器體系結構的分發時間，並且對於任意的對等方數量N，總是小於文件長度/鏈路的上載速率。因此，具有P2P體系結構的應用程序能夠是自擴展的，這種自擴展的原因是：對等放除了是比特的消費者外還是它們的重新分發者
2、BitTorrent
BitTorrent是一種用於文件分發的流行P2P協議。參與一個特定文件分發的所有對等方的集合被稱爲一個洪流。在一個洪流中的對等方彼此下載等長度的文件快，典型的文件塊長度爲256K。當一個對等方首次加入一個洪流時，他沒有塊，隨着時間的流逝，它積累了越來越多的塊。當它下載塊時，也爲其他對等方上載了多個塊，一旦某對等放獲得了整個文件，它也許離開洪流，也許留在洪流繼續爲其他對等方上載塊。同時，任何對等方可能在任何時候僅具有塊的子集就離開洪流，並在以後重新加入該洪流中。
每個洪流具有一個基礎設施節點，稱爲追蹤器，當一個對等方加入某洪流時，它向追蹤器註冊自己，並週期性地通知追蹤器它仍在洪流中。以這種方式，追蹤器跟蹤參與在洪流中的對等方。一個給定的洪流可以在任何時刻具有數以百計或數以千計的對等放。
六、視頻流和內容分發網
1、因特網視頻-略
2、HTTP流和DAS
由於客戶可用的帶寬大小有很大的不同，這導致了一種新型基於HTTP的流的研發，它常常被稱爲經HTTP的動態適應性流（Dynamic Adaptive Streaming over HTTP，DASH）。在DASH中，視頻編碼爲幾個不同的版本，其中每個版本具有不同的比特率，對應不同的質量水平。
使用DASH後，每個視頻版本存儲在HTTP服務器中，每個版本都有一個不同的URL，HTTP服務器也有一個告示文件，爲每個版本提供了一個URL及其比特率。
3、內容分發網
爲例應對向分佈於全世界的用戶分發巨量視頻的挑戰，幾乎所有主要的視頻流量公司都利用內容分發網（Content Distribution NetWork，CDN）。CDN可以是住專用CDN，即它由內容提供商自己所擁有；也可以是第三方CDN，它代表多個內容提供商分發內容。CDN常用兩種不同的服務器安置原則：
深入：通過在遍及全球的接入ISP中部署服務器集羣來深入到ISP的接入網中。但因這種高度分佈式設計，維護和管理集羣的任務成爲挑戰
邀請做客：通過在少量關鍵位置建造大集羣來邀請到ISP做客，不是將集羣放在接入ISP中，而是CDN將它們的集羣放置在因特網交換點。
3.1、CDN操作
大多數CDN利用DNS來截獲和重定向請求，來確定此時適合用於該用戶的CDN服務器集羣，並將客戶的請求重新定向到該集羣的某臺服務器，
3.2、集羣選擇策略
任何CDN，其核心是集羣選擇策略，即動態的將客戶定向到CDN中的某個服務器集羣或數據中心的機制。一種簡單的策略是指派客戶到地理上最爲臨近的集羣，但可能存在地理臨近集羣並非最近集羣的問題。還有一種是基於當前流量條件爲客戶決定最好的集羣，CDN能夠對其集羣和客戶之間的時延和丟包性能執行週期性的實時測量，其缺點是許多LDNS被配置爲不響應這些探測。