1. 應用層協議原理

1.1 網路應用程式體系結構

應用程式體系結構（application architecture） 由應用程式研發者設計，規定了如何在各種端系統上組織該應用程式，

• 客戶 — 服務器體系結構（client-server architecture）：有一個總是打開的主機稱為服務器，它服務于來自許多其他稱為客戶端的主機的請求，客戶端之間不直接通信，
• P2P體系結構（P2P architecture）：應用程式在間斷連接的主機之間直接通信，不必通過專門的服務器，

1.2 行程通信

作業系統中進行通信的實際上是行程（process）而不是程式，一個行程可以被認為是運行在端系統中的一個程式，

在兩個不同的端系統上的行程，通過跨越計算機網路交換報文（message）而相互通信，發送并生成并向網路中發送報文，接收行程接收這些報文并可能通過回送報文進行回應，

• 客戶端和服務器行程
  • 對每對通信行程，我們通常將這兩個行程之一標識為客戶（client），而另一個行程標識為服務器（server），
  • 在一對行程之間的通信會話場景中，發起通信的（即在該會話開始時發起于其他行程的聯系）的行程成為客戶端（client），在會話開始時等待聯系的行程是服務器（server），
• 行程與計算機網路之間的介面
  • 從一個行程向另一個行程發送的報文必須通過下面的網路，行程用過一個稱為套接字（socket） 的軟體介面向網路發送報文和從網路接收報文，
  • 套接字是同一臺主機內應用層和運輸層之間的介面，由于該套接字是建立網路應用程式的可編程介面，因此套接字也被稱為應用程式和網路之間的應用編程介面（Application Programming Interface，API），
• 行程尋址
  • 在一臺主機上運行的行程為了向另一臺主機上運行的行程發送分組，需要標識接收行程，從而定義了兩種資訊，① 主機的地址（由 IP 確定）② 目的主機中指定接收行程的識別符號（由埠號確定），

1.3 可供應用程式使用的運輸服務

包括因特網在內的很多網路提供了不止一種運輸層協議，當開發一個應用時，必須選擇一種可用的運輸層協議，大體能夠從四個方面對應用程式服務要求進行分類

• 可靠資料傳輸
  • 確保應用程式的一端發送的資料正確、完全地交付給接收資料的行程，
  • 當應用程式使用可靠資料傳輸的傳輸層協議時，只要將要發送的資料傳輸進套接字，就可以完全相信該資料可以完整無差錯地到達接收方，
• 吞吐量
  • 在一條網路路徑上的兩個行程之間的通信會話中，可用吞吐量就是指發送行程能夠向接收行程交付位元的速率，
• 定時
  • 定時和吞吐量都是關于速度的，
  • 定時是對資料從發送到到達所需時間的要求，而吞吐量是對資料交付速度的要求，
• 安全性
  • 運輸層可以為應用程式提供一些安全服務，以防止傳輸的資料以某種方式在這兩個行程之間被察覺到，這些安全服務包括：資料的加解密、資料的完整性和端點鑒別等，

1.4 因特網提供的運輸服務

提供的傳輸服務主要包括以下兩種，在運輸層博客中會詳細介紹，

• TCP
• UDP

1.5 應用層協議

應用層協議（application-layer protocol） 定義了運行在不同端系統上的應用程式行程如何相互傳遞報文，

• 交換的報文型別，例如請求報文和回應報文，
• 各種報文型別的語法，如報文中的各個欄位及這些欄位是如何描述的，
• 欄位的語意，即這些欄位中的資訊的含義，
• 確定一個行程何時以及如何發送報文，對報文進行回應的規則，

2. Web 和 HTTP

Web 的應用程式協議是超文本傳輸協議（HyperText Transfer Protocol，HTTP），他是Web的核心，由兩個程式實作，一個客戶端程式和一個服務器程式，客戶程式和服務器程式運行在不同的端系統中，通過交換HTTP報文進行會話，

HTTP定義了這些報文的結構以及客戶端和服務端進行報文交換的方式，

HTTP 使用TCP作為它的支撐運輸協議，

客戶端向它的套接字介面發送HTTP請求報文并從它的套接字介面接收HTTP回應報文，

因為HTTP服務器并不保存關于客戶的任何訊息，所以我們說HTTP是一個無狀態協議，

具體HTTP內容比較多，可以看博主另一篇博客

HTTP 和 HTTPS

3. FTP：檔案傳送協議

F T P是另一個常見的應用程式，它是用于檔案傳輸的 Internet 標準，我們必須分清檔案傳送（file transfer）和檔案存取 (file access)之間的區別，前者是 F T P提供的，后者是如 N F S 等應用系統提供的，

FTP是在兩個相連的計算機之間進行檔案傳輸時使用的協議，

互聯網上有一種FTP服務器是允許任何人進行訪問的，這種服務器叫做匿名服務器（anonymous ftp）登錄這些服務器時使用匿名（anonymous）或ftp都可以

FTP 使用兩條TCP連接：一條用來控制，另一條用于資料（檔案）的傳輸，

• 控制連接：
  • 以通常的客戶服務器方式建立，服務器以被動方式打開眾所周知的用于F T P的埠（ 2 1），等待客戶的連接，客戶則以主動方式打開 T C P埠2 1，來建立連接，
  • 控制連接始終等待客戶與服務器之間的通信，該連接將命令從客戶傳給服務器，并傳回服務器的應答，
  • 控制用的連接，在用戶要求斷開之前會一直保持連接狀態，不過，絕大多數FTP服務器都會對長時間沒有任何新命令輸入的用戶的連接強制斷開
• 資料傳輸連接：
  • 在TCP21號埠上進行檔案GET（RETR）、PUT（STOR）、以及檔案一覽（LIST）等操作時，每次都會建立一個用于資料傳輸的TCP連接，
  • 資料的傳輸和檔案一覽表的傳輸正是在這個新建的連接上進行，當資料傳送完畢之后，傳輸資料的這條連接也會被斷開，然后會在控制用的連接上繼續進行命令或應答的處理，
  • 資料傳輸用的TCP連接通常使用埠20，

FTP中請求命令中使用著“RETR”等4位ASCII碼字串，而針對這些命令的應答則使用如“200”等3位數字的ASCII碼字串，

4. 因特網中的電子郵件

因特網電子郵件系統有三個核心組件：用戶代理（user agent）、郵件服務器（mail server）、SMTP（簡單郵件傳輸協議，Simple Mail Transfer Protocol），

如下展示了交換電子郵件的程序

• 每個接收方在某個郵件服務器上有一個郵箱，管理和維護發送給他的報文，
• 發送的方郵件服務器中有一個報文佇列（message queue）中保持報文，就算對方的郵件服務器故障，也可以存盤下了以后嘗試再次發送，

4.1 SMTP

SMTP 是因特網電子郵件中主要的應用層協議，它使用TCP可靠資料傳輸服務，

SMTP大致作業流程如下

• 客戶端SMTP（運行在發送方郵件服務器主機上）在25號埠建立一個到服務器SMTP的TCP連接，
  • 如果服務器沒有開機，客戶端會稍后繼續嘗試，
• 一旦連接建立，服務器和客戶端之間就會進行某些應用層的握手，
  • 表明發送方郵件地址，接受方郵件地址等，
• 握手完畢之后，客戶端發送該報文，發送成功之后如果還要發送別的報文，可以繼續利用該TCP連接發送，發送完則關閉TCP連接，

另外，SMTP 一般不使用中間郵件服務器發送郵件，意味著，如果郵件的接收方沒有開機，那么郵件會一直保存在發送方的郵件服務器上，

與HTTP的對比

1. HTTP是一個拉協議（pull protocol），即用戶使用HTTP從服務器上拉取資訊，而SMTP是一個推協議（push protocol），即通常是發送郵件服務器將檔案推向接受檔案服務器，
2. SMTP報文需要采用ASCII碼格式，而HTTP資料不受這種要求限制，
3. TTP將每個物件封裝在自己的回應報文里，而SMTP則將所有的報文物件放到一個報文之中，

4.2 郵件報文格式

電子郵件由三部分組成：

• 信封（envelope）：是郵件服務器用來交付的，
• 首部（header）：由用戶代理使用，
• 正文（body）：是發送用戶發給接收用戶報文的內容，

用戶代理接收我們指定為正文的部分，加上一些首部欄位，并把結果傳到 郵件服務器，發送方郵件服務器加上一些首部欄位，加上信封，并把結果發送到另一個 接收方服務器，

4.3 郵件訪問協議：POP3 和 IMAP

SMTP是郵件服務器之間發送郵件報文的協議，并不是用戶通過代理和郵件服務器之間通信的協議；用戶代理使用郵件訪問協議來從郵件服務器上獲取郵件資訊；目前常用的郵件訪問協議有POP3（Post Office Protocol-Version 3）、因特網郵件訪問協議（IMAP，Internet Mail Access protocol）和HTTP

POP3

當用戶代理打開一個到郵件服務器埠110上的TCP連接后，POP3就開始作業，

POP3 按照三個階段進行作業：特許、事務處理和更新，

• 特許階段：用戶代理發送（以明文形式）用戶名和口令以鑒別用戶，
• 事務處理階段：用戶代理取回報文，同時還可以做洗掉、取消洗掉等標記或者統計郵件資訊，
  • 可以對郵件使用下載并洗掉或者下載并保存的方式，所以可以設定不同標記，
  • 使用下載并洗掉可能出現的問題時，采用不同機器無法收取同一封郵件，
• 更新階段：客戶端發出quit指令，結束POP3會話，郵件服務器洗掉被標記為洗掉的報文，

在用戶代理與郵箱服務器之間的POP3會話期間，該POP3服務器保留了一些狀態資訊，特別是標記了哪些用戶報文被標記為洗掉了，但是POP3服務器并不在POP3繪畫程序中攜帶狀態資訊，大大簡化了POP3服務的實作，

IMAP

IMAP（Internet Message Access Protocol） 與POP類似，也是接收電子郵件的協議，在POP中郵件由客戶端進行管理，而在IMAP中郵件則由服務器進行管理，

• 使用IMAP時，可以不必從服務器上下載所有的郵件也可以閱讀，由于IMAP是在服務器端處理MIME資訊，所以它可以實作當某一封郵件含有10個附件時“只下載其中的第7個附件”的功能，這在帶寬較窄的線路上起著非常重要的作用，

• 且IMAP在服務器上對“已讀/未讀”資訊和郵件分類進行管理，因此，即使在不同的計算機上打開郵箱，也能保持同步，

• IMAP，在服務器上保存和管理郵件資訊，就如同在自己本地客戶端的某個閃存中管理自己的資訊一樣簡單，

補充：什么是MIME

• 很長一段時間里，互聯網中的電子郵件只能處理文本格式的郵件，不過現在，電子郵件所能發送的資料型別已被擴展到MIME（Multipurpose Internet Mail Extensions，廣泛用于互聯網并極大地擴展了資料格式，） ，可以發送靜態影像、影片、聲音、程式等各種形式的資料，
• MIME基本上由首部和正文（資料）兩部分組成，
• 并且MIME經過一些設定和操作可以將多個MIME訊息組合成為一個MIME訊息，這就叫做multipart，

基于Web的電子郵件

用戶使用HTTP協議和郵件服務器通信，用戶代理就是普通的瀏覽器，但是，郵件服務器之間任然使用SMTP協議，

5. DNS：因特網的目錄服務

因特網上的主機和人一樣，可以使用主機名（hostname）進行標識，這被人易于接受，但是因為主機名可能由不定長的字母數字組成，路由器難以處理，所以也可以通過 IP地址（IP address）進行標識，

5.1 DNS 提供的服務

因為人們喜歡使用易于接受的主機名，而路由器喜歡定長的，有層次結構的IP，所以采取了一個辦法，提供將主機名轉換成IP地址的目錄服務，這就是域名系統（Domain Name System，DNS），

• DNS是一個由分層的DNS服務器實作的分布式資料庫，
• 一個使得主機能夠查詢分布式資料庫的應用層協議，
• DNS協議運行在UDP之上，使用53號埠，

DNS通常是由其他應用層協議所使用的，包括HTTP，SMTP和FTP，將用戶提供的主機名決議為IP地址，

DNS提供的重要服務

• 主機別名：有著復雜主機名的主機能有用一個或者多個別名，應用程式可以呼叫DNS來獲得主機別名對應的規范主機名以及主機的IP地址，
• 郵件服務器別名：同理，電子郵件應用程式呼叫DNS，對提供的主機決議到對應的電子郵件地址，
• 負載分配：DNS也用于在冗余的服務器之間進行負載分配，

5.2 DNS作業機理

先論述DNS作業程序的總體概括：

1. 應用程式將呼叫DNS的客戶端，并指明需要轉換的主機名，
2. 用戶主機上的DNS接收到后，向網路中發送一個DNS查詢報文，所有的DNS請求和回答報文使用UDP資料報經埠53發送，
3. 經過時延之后，用戶主機上的DNS接收到一個提供所希望映射的DNS回答報文，這個映射結果則被傳遞到呼叫DNS的應用程式，

為什么不簡單的使用一個DNS服務器，而采用分布式的資料庫？

• 單點故障：如果這個DNS服務器崩潰，那么整個因特網也隨之癱瘓，
• 通信容量：單個服務器無法處理所有的DNS查詢，
• 遠距離的集中式資料庫：遠距離的查詢會造成嚴重的時延，
• 維護：單個DNS服務器為了防止資料丟失需要保留所有記錄，不利于主機的添加更新等，

為了處理擴展性的問題，DNS使用了大量的DNS服務器，它們以層次方式組織，并且分布在全世界范圍，沒有一臺DNS服務器有因特網上所有主機的映射，

大致來說，有 3 種型別的DNS服務器，

• 根DNS服務器
  • 有四百多個根名字服務器遍及全世界，由13個不同的組織管理，
  • 根名字服務器提供TLD服務器的IP地址，
• 頂級域（Top-Level Domain，TLD）DNS服務器
  • 對于每個頂級域（如com、org、net、edu和gov）和所有國家的頂級域（如 uk、jp），都有TLD服務器集群，
  • TLD服務器提供了權威DNS服務器的IP地址，
• 權威DNS服務器
  • 在因特網上具有公共可訪問主機的每個組織機構必須提供公共可訪問的DNS記錄，這些記錄將這些主機的名字映射為IP地址，

另外還有一類重要的DNS服務器，稱為本地DNS服務器，嚴格來說，他不屬于DNS層次結構，但是它的作用也至關重要，

本地DNS服務器可能與主機的距離很近，當主機發出DNS請求時，請求被發往本地DNS服務器，它起著代理的作用，并將該請求轉發到DNS服務器層次結構中，

DNS 主要有兩種查詢方式

• 遞回查詢
  • 如果請求的接收者不知道所請求的內容，那么接收者將扮演請求者，發出有關請求，直到獲得所需要的內容，然后將內容回傳給最初的請求者，
  • 在遞回查詢中，要給請求者想要的答案
• 迭代查詢
  • 接收者沒有請求者所需要的準確內容，接收者將告訴請求者，如何去獲得，但是自己并不去發出請求，

從請求主機到本地DNS服務器的查詢是遞回的，其余查詢是迭代的，

DNS快取

為了改善時延性能并減少在因特網上到處傳輸的DNS報文數量，DNS廣泛使用了快取技術，

原理也十分簡單，當某DNS服務器接收到一個DNS的回答，它能將映射快取在本地存盤器中，

所以總體的查詢IP程序如下圖：

5.3 DNS記錄和報文

共同實作分布式資料庫的所有DNS服務器存盤了資源記錄(Resource Record，RR)，而RR提供了主機名到IP地址的映射資訊，每個DNS回答報文包含了一個或多個資源記錄，

資源記錄時一個包含了下列四個欄位的的4元組，

(Name, Value, Type, TTL)

TTL 是 （Time To Live）是記錄的生存時間，它決定了資源記錄應當從快取中洗掉的時間，

我們忽略TTL欄位，討論其他三個欄位的觀念，Name 和 Value 的值取決于Type，自己搭建過網站的應該都知道，在域名決議的時候，有多種決議型別，包括 A，NS，CNAME和MX，

• 如果Type=A，則Name 是主機名，Value 是主機對應的IP地址，
• 如果 Type = NS ，則 Name 是個域，Value則是如何獲得該域下主機IP地址的權威DNS服務器的主機名，
• 如果 Type = CNAME ，則 Value 是別名為 Name 的主機對應的規范主機名，
• 如果 Type = MX ，則 Value 是個別名為 Name 的郵件服務器的規范主機名，

5.3.1 DNS 報文

DNS報文有兩種，即查詢報文和回答報文，并且兩種報文有著相同的結構，

• 前12位元組為首部區域，
  • 識別符號是一個用來標記該查詢的16位元數，該標志符會被復制到相應的回答報文里，以便匹配請求和回答，
  • 標志欄位有若干標志，用來指出報文的型別（請求還是回應）、查詢型別（遞回還是迭代）、是否是所請求名字的權威DNS服務器，
  • 4個有關數量的欄位，用來指示4類資料區域出現的數量，
• 問題區域：包含了正在進行的查詢資訊，包括名字欄位、查詢型別；
• 回答區域：包含了對最初請求的名字的資源記錄，回答報文的回答區域可以包含多條RR，因此一個主機名能有多個IP地址，
• 權威區域：包含了其他權威服務器的資訊，
• 附加區域：包含了其它有幫助的記錄，

另外，如果想向DNS資料庫插入記錄，就是當你向某些注冊登記機構注冊域名時，需要向該機構提供你的基本和輔助權威DNS服務器的主機名字和IP地址，然后，注冊機構確保一個型別為NS和型別為A的記錄輸入對應的頂級域名服務器，并且你需要確保你的Web服務器的型別A資源記錄和用于郵件服務器的型別MX資源記錄被輸入到你對應的權威服務器中，

6. P2P 檔案分發

使用P2P體系結構，對總是打開的基礎設施服務器有最小的（或者沒有的）依賴，

成對間歇連接的主機（稱為對等方）彼此直接通信，這些對等方并不為服務提供商所擁有，而是受用戶控制的桌面計算機和膝上計算機，

P2P 體系結構有很強的自擴展性，每一臺機器既可以作為客戶端，去下載別的服務器的資源，又可以作為服務器為其他客戶端提供資源，

BitTorrent 是一種用于檔案分發的流行P2P協議，

7. 內容分發網（CDN）

為了應對向分布于全世界的用戶分發巨量視頻資料的挑戰，幾乎所有主要的視頻流公司都利用內容分發網（Content Distribution Network，CDN），CDN管理分布在多個地理位置上的服務器，在它的服務器中存盤視頻的副本，并且試圖將每個用戶請求定向到一個將提供最好的用戶體驗的CDN位置，

CDN 操作細節

• 當用戶主機中的一個瀏覽器指令檢索一個特定的視頻時，CDN必須截獲該請求，
• 確定此事適合用于該客戶的CDN服務器集群，
  • 一種選擇集群策略是選擇地理上最為鄰近的集群，
  • 另一種是對集群做周期性的實時測量，選擇最好的集群，
• 將客戶的請求重定向到該集群的某臺服務器，
  • 大多數CDN利用DNS來截獲和重定向請求，