分層網絡模型（三）

應用層
1. 應用協議原理

在給定的一對進程之間的通訊會話中，發起通訊（即在該會話開始時與其餘進程聯繫）的進程被標示爲客戶機，在會話開始時等待聯繫的進程是服務器。

進程經過一個稱爲套接字的軟件接口在網絡上發送和接收報文。
能夠把套接字比做房子的門。
2. Web應用和HTTP協議（端口80）
2.1 HTTP

Web的應用層協議是超文本傳輸協議（HyperText Transfer Protocol, HTTP），它是Web的核心。

HTTP服務器不保存關於客戶機的任何信息，因此咱們說HTTP是一個無狀態協議。
2.1.1 非持久鏈接和持久鏈接

非持久鏈接
每一個TCP鏈接在服務器返回對象後關閉，即該鏈接並不爲其餘的對象而持續下來。
持久鏈接
在持久鏈接的狀況下，服務器在發送響應後保持該TCP鏈接打開。在相同的客戶機與服務器之間的後續請求和響應報文可經過相同的鏈接進行傳送。
2.2.2 HTTP報文格式

HTTP請求報文：
GRT /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/4.0
Accept-language: fr

請求行
首部行
瀏覽器請求對象somedir/page.html；
首部行，Host: www.someschool.edu定義了目標所在的主機；
首部行，Connection: close瀏覽器告訴服務器不但願使用持久鏈接，它要求服務器在發送完被請求的對象後就關閉鏈接；
首部行，User-agent定義用戶代理，即項服務器發送請求的瀏覽器的類型；
首部行Accept-language表示用戶想獲得該對象的法語版本。

HTTP響應報文
HTTP /1.1 200 OK
Connection: close
Data: Thu, 03 Jul 2003 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Sun, 6 May 2007 09:23:24 GMT
Connect-Length: 6821
Content-Type: text/html
(data data …)

初始狀態行：協議版本、狀態碼、相應狀態信息
6個首部行
實體主體
2.2.3 cookie

cookie用於標識用戶。用首次訪問站點時，可能須要提供一個用戶標識（多是名字），在後繼訪問中，瀏覽器向服務器傳遞一個cookie首部，供服務器識別該用戶。所以，cookie能夠在無狀態的HTTP上創建一個用戶會話層。

image
2. 文件傳輸協議：FTP（端口20、21）

HTTP和FTP都是文件傳輸協議。它們都運行在TCP上。
區別：FTP使用兩個並行的TCP鏈接來傳輸文件，一個是控制鏈接，一個是數據鏈接。控制鏈接用於在兩個主機之間傳輸控制信息，如用戶標識、口令、改變遠程目錄的命令以及「put」和「get」文件的命令。數據鏈接用於實際傳輸一個文件。
由於FTP協議使用一個分離的控制鏈接，因此也稱FTP的控制信息是帶外傳送的。HTTP是帶內發送控制信息的。
FTP服務器必須在整個會話期間保留用戶的狀態信息。
3. 電子郵件

因特網電子郵件系統有3個主要組成部分：用戶代理（user agent）、郵件服務器（mail server）和簡單郵件傳輸協議（Simple Mail Transfer Protocol, SMTP）。
3.1 SMTP(端口25)

SMTP和HTTP都用於從一臺主機向另外一臺主機傳送文件，HTTP從Web服務器向Web客戶機（一般是瀏覽器）傳送文件（也稱爲對象）；SMTP從一個郵件服務器向另外一個郵件服務器傳送文件（即電子郵件報文）。
區別：
第一：HTTP主要是一個拉協議（pull protocol）即人們能夠在方便的時候裝載Web服務器上的信息，用戶使用HTTP從該服務器拉取信息。TCP鏈接由想獲取文件的機器發起。
第二：SMTP是一個推協議（push protocol），發送郵件服務器把文件推向接收郵件服務器。TCP鏈接由要發送文件的機器發起。
3.2 郵件報文格式和MIME

一個典型地報文首部以下：
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Searching for the meaning of life

在首部以後，緊接着是一個空白行，而後是ACSII格式表示的報文主體。
3.2.1 非ASCII碼數據的MIME擴展

爲發送非ASCII文本的內容，發送方的用戶代理必須在報文中使用附加的首部行。這些額外的首部行（RFC 2045和RFC 2046），多用途因特網郵件擴展（Multipurpose Internet Mail Extension, MIME）是對RFC 822的擴展。

支持多媒體的兩個關鍵MIME首部是Content-Type:和Content-Transfer-Encoding:。
Content-Type: 首部容許接收用戶代理對報文采起適當的動做。例如，經過指出報文主體包含一個JPEG圖形，接收用戶代理能夠爲報文主體啓用一個JPEG圖形的解壓縮程序。
Content-Transfer-Encoding:首部行提示接收用戶代理該報文主體已經使用了ASCII編碼。

例如：
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Picture of yummy crepe.
MIME-Version: 1.0
和Content-Transfer-Encoding: base64
Content-Type:image/jpeg

(base64 encoded data…)
3.2.2 接收的報文

接收服務器一旦接收到具備RFC 822和MIME首部行的報文，就在該報文的頂部添加一個Received： 首部行。
該首部行定義了發送報文的SMTP服務器的名稱（from），接收該報文的SMTP服務器的名稱（by），以及接收服務器接收到的時間。
例如：
Received: from crepes.fr by hamburger.edu; 12 Oct 98 15:27:39 GMT
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Picture of yummy crepe.
MIME-Version: 1.0
和Content-Transfer-Encoding: base64
Content-Type:image/jpeg

(base64 encoded data…)
3.3 郵件訪問協議

接收方的用戶代理不能使用SMTP取回郵件，由於取郵件是一個拉操做，而SMTP協議是一個推協議。經過引入一個特殊的郵件訪問協議來解決這個難題，該協議將接收方郵件服務器上的郵件傳送給他的本地PC。目前有多個流行的郵件訪問協議，第三版的郵局協議（Post Office Protocol-Version 3, POP3）、因特網郵件訪問協議（Internet Mail Access Protocol, IMAP）以及HTTP。
3.3.1 POP

POP3按照三個階段進行工做：特許；事務處理；更新。
特許：用戶代理髮送（以明文形式）用戶名和口令以鑑別用戶。
事務處理：用戶代理取回報文。在這個階段，用戶代理還能進行以下操做：對報文作刪除標記，取消報文刪除標記，以及獲取郵件的統計信息。
更新：它出如今客戶機發出了quit命令以後，目的是結束該POP3會話，這時，郵件服務器刪除那些被標記爲刪除的報文。
3.3.2 IMAP

使用POP3是將文件夾和報文存放在本地機上，這會給移動用戶帶來問題。POP3不能讓用戶從任何一臺機器上對全部報文進行訪問。其沒有給用戶提供任何建立遠程文件夾以及爲報文指派文件夾的方法。
IMAP服務器把每一個報文與一個文件夾聯繫起來，當報文第一次到達服務器時，它是放在收件人的收件箱文件夾裏。
3.3.3 基於Web的電子郵件

用戶代理就是普通的瀏覽器，用戶和其遠程郵箱之間的通訊則經過HTTP進行。電子郵件報文從郵件服務器到瀏覽器，使用HTTP。郵件服務器和其餘郵件服務器之間發送和接收郵件時，仍然使用SMTP。
4. DNS：因特網的目錄服務

域名系統（Domain Name System）
DNS：一個由分層 DNS 服務器實現的分佈式數據庫；一個容許主機查詢分佈式數據庫的應用層協議。
DNS運行在 UDP 之上，使用 53 號端口。
用於將用戶提供的主機名解析爲 IP 地址。

結構：
1. 分佈式、層次數據庫
根DNS服務器；頂級域（TLD）服務器；權威DNS服務器。
2. DNS緩存
5. P2P應用

使用P2P體系結構，對老是打開的基礎設施服務器有最小的依賴。

BitTorrent是一種用於文件分發的流行P2P協議。用BitTorrent的術語來說，參與一個特定文件分發的全部對等方集合稱爲一個洪流（torrent）。
在一個洪流中，對等方彼此下載等長度的文件塊，塊長度一般爲256KB。