應(yīng)用層協(xié)議

在傳輸層之上，便是應(yīng)用層。傳輸層的 UDP 報文和 TCP 報文段的數(shù)據(jù)部分就是應(yīng)用層交付的數(shù)據(jù)。

應(yīng)用層直接為用戶提供服務(wù)，應(yīng)用層有很多協(xié)議，每一個協(xié)議對應(yīng)著計算機(jī)上的一個服務(wù)。

不同類型的網(wǎng)絡(luò)應(yīng)用有不同的通信規(guī)則，因此應(yīng)用層協(xié)議是多種多樣的，比如DNS、FTP、Telnet、SMTP、HTTP、RIP、NFS等協(xié)議都是用于解決其各自的一類問題。

應(yīng)用層協(xié)議(application-layer protocol)定義了運(yùn)行在不同端系統(tǒng)上的應(yīng)用程序如何相互傳遞報文。

應(yīng)用層協(xié)議定義了：

一、DNS

1、DNS 是什么

DNS 全名叫 Domain Name Server，中文俗稱“域名服務(wù)器”

在 Internet 上域名與 IP 地址之間是一一對應(yīng)的，域名雖然便于人們記憶，但機(jī)器之間只能互相認(rèn)識IP地址，它們之間的轉(zhuǎn)換工作稱為域名解析，域名解析需要由專門的域名解析服務(wù)器來完成，DNS 就是進(jìn)行域名解析的服務(wù)器，將域名(機(jī)器名) 轉(zhuǎn)換為 IP地址。

DNS 是一個分布式數(shù)據(jù)庫，提供了主機(jī)名和 IP 地址之間相互轉(zhuǎn)換的服務(wù)。

這里的分布式數(shù)據(jù)庫是指，每個站點只保留它自己的那部分?jǐn)?shù)據(jù)。

如果整個因特網(wǎng)都使用一個域名服務(wù)器，負(fù)荷太大， 所以 DNS 設(shè)計成一個分布式的數(shù)據(jù)庫，即使單個主機(jī)出故障也不會妨礙整個 DNS 系統(tǒng)。

另外 DNS 使得大多數(shù)域名都能在本地解析，僅少量解析需要在因特網(wǎng)上通信，因此 DNS 效率很高。

域名和 IP 是一對一關(guān)系嗎？

• 實際上域名和 IP 是多對多關(guān)系。
• 一個 IP 可以被多個域名指向（購買的虛擬主機(jī)）
• 一個域名下也可以有多個 IP（負(fù)載均衡）

2、域名結(jié)構(gòu)

• 域名指的是用點符號分割的計算機(jī)名字。
• IP地址對應(yīng)著網(wǎng)絡(luò)上的各個機(jī)器，但由于IP地址沒有具體字面含義，難以記憶，有時IP地址還會經(jīng)常更換。
• 引入域名來標(biāo)識某臺機(jī)器。域名是全球唯一的，每次申請域名，都會在域名服務(wù)器上查詢是否存在。
• 所有域名都是以“ . ”開始的。

域名結(jié)構(gòu)是樹狀結(jié)構(gòu)，樹的最頂端代表根域名

• 下一層是 .com、.cn 等頂級域名。
• 再下層就是二級、三級、四級域名。

• 頂級域名代表服務(wù)器或網(wǎng)站的性質(zhì)常見有com（商用）、cn（中國）、net（提供信息）、edu（教育）、gov（政府）等等。

• 二級域名：每個人都可以申請的，可以在頂級域名下申請，比如 www.esyc.com中esyc就是一個二級域名。在二級域名下你就可以注冊其他域名了。
• 三級域名：www.mail.esyc.com中mail就是三級域名。在www.esyc.com這個域名注冊這個三級域名的時候無需在征得com域名的同意。即一個域創(chuàng)建子域的時候不需要征求上級同意。

當(dāng)然域名可以3級可以4級可以5級等等，級別是沒有限制的，只需要滿足，一個域名的各個組成部分不超過63個字符長，總長不超過255個字符長。

3、域名服務(wù)器

● 根域名服務(wù)器：最高層次的域名服務(wù)器，根域名服務(wù)器知道所有頂級域名服務(wù)器的域名和IP地址。任何一個本地域名服務(wù)器要對互聯(lián)網(wǎng)上的任何域名進(jìn)行解析，只要自己無法解析，就會首先求助于根域名服務(wù)器。

● 頂級域名服務(wù)器：管理在該頂級域名服務(wù)器下注冊的所有二級域名。當(dāng)收到DNS查詢請求時，就給出相應(yīng)的回答（可能是最后的結(jié)果，也可能是下一步需要去找的域名服務(wù)器的IP地址）。

● 權(quán)限域名服務(wù)器（權(quán)威域名服務(wù)器）：負(fù)責(zé)一個區(qū)的域名服務(wù)器。當(dāng)一個權(quán)威域名服務(wù)器不能給出最終的查詢結(jié)果時，就會告訴發(fā)出請求方，下一步應(yīng)該去找哪一個權(quán)威域名服務(wù)器。

● 本地域名服務(wù)器（遞歸服務(wù)器）：主機(jī)發(fā)出 DNS 查詢請求時，該請求首先會發(fā)給本地域名服務(wù)器。

理論上講，任何標(biāo)準(zhǔn)域名的解析都需要經(jīng)過層級式的域名解析。

即首先要通過第一層的根域名服務(wù)器的指引，才能去下面的頂級域名服務(wù)器尋找。

但是實際應(yīng)用，提供接入服務(wù)的服務(wù)商的緩存域名服務(wù)器上可能已經(jīng)有了域名與 IP 映射的緩存。

4、DNS 解析流程

● 在瀏覽器中輸入 www.qq.com 域名，瀏覽器先檢查自身緩存中有沒有被解析過的這個域名對應(yīng)的 IP 地址，如果有，就調(diào)用這個 IP 映射，完成域名解析。

● 如果瀏覽器緩存中未命中，操作系統(tǒng)會檢查本地的 hosts 文件是否有該域名和 IP 的映射，如果有，就調(diào)用這個IP地址映射，完成域名解析。

● 如果 hosts 里也沒有這個域名的映射，則向本地域名服務(wù)器（LDNS）發(fā)送請求，看是否有這個域名的映射關(guān)系，如果有，直接返回，完成域名解析。（LDNS 一般在城市的某個角落，距離你不會很遠(yuǎn)，一般都會緩存域名解析結(jié)果，大約 80% 的域名解析到這里就完成了）

● 如果 LDNS 仍然未命中，LDNS 就向根服務(wù)器發(fā)送查詢請求，根服務(wù)器里面記錄的都是各個頂級域所在的服務(wù)器 IP，根服務(wù)器會根據(jù)域名后綴返回對應(yīng)的頂級域名服務(wù)器位置。當(dāng)向根請求 www.qq.com 的時候，根服務(wù)器就會返回 .com 服務(wù)器的位置信息。

● LDNS 拿到 .com 的權(quán)威服務(wù)器地址以后，就會詢問 .com 的權(quán)威服務(wù)器，知不知道 www.qq.com 的位置。這個時候 .com 權(quán)威服務(wù)器查找并返回 www.qq.com 服務(wù)器的地址。LDNS 繼續(xù)向 www.qq.com 的權(quán)威服務(wù)器去查詢這個地址，由 www.qq.com 的服務(wù)器給出了 IP 地址：202.173.11.10

● LDNS 服務(wù)器得到了 www.qq.com 對應(yīng)的 IP 地址后以 DNS 應(yīng)答包的方式傳遞給客戶機(jī)，并把域名和對應(yīng)的 IP 地址在本地緩存下來。

● 客戶機(jī)根據(jù) IP 地址建立連接，并在客戶端緩存域名/IP映射。

簡單來說，其實只有四步：

5、DNS 服務(wù)器查詢方式

（1）迭代查詢

DNS 服務(wù)器會向客戶機(jī)提供其他能夠解析查詢請求的 DNS 服務(wù)器地址。

• 當(dāng)客戶機(jī)發(fā)送查詢請求時，DNS 服務(wù)器并不直接回復(fù)查詢結(jié)果，而是告訴客戶機(jī)另一臺 DNS 服務(wù)器地址，
• 客戶機(jī)再向這臺 DNS 服務(wù)器提交請求，依次循環(huán)直到返回查詢的結(jié)果為止。
• 迭代查詢返回的是最佳的查詢點或者主機(jī)地址。本地域名服務(wù)器向根域名服務(wù)器的查詢通常是采用迭代查詢。

（2）遞歸查詢

DNS 服務(wù)器必須使用一個準(zhǔn)確的查詢結(jié)果回復(fù)客戶機(jī)。

• 如果DNS 服務(wù)器本地沒有存儲查詢目標(biāo)的 DNS 信息，那么該服務(wù)器會去詢問其他服務(wù)器（即代替客戶機(jī)去查詢，而不是讓客戶機(jī)自己進(jìn)行下一步查詢），并將返回的查詢結(jié)果提交給客戶機(jī)。
• 因此，遞歸查詢返回的查詢結(jié)果或者是所要查詢的IP地址，或者是報錯（表示無法查詢到所需的 IP 地址）。主機(jī)向本地域名服務(wù)器的查詢一般都是采用遞歸查詢。

6、DNS 緩存機(jī)制

DNS 緩存不僅產(chǎn)生于操作系統(tǒng)，瀏覽器、應(yīng)用程序以及 ISP（網(wǎng)絡(luò)服務(wù)提供商）都會對 DNS 進(jìn)行緩存。

一條域名的 DNS 記錄會在本地有兩種緩存：瀏覽器緩存和操作系統(tǒng)緩存。

• 在瀏覽器中訪問的時候，會優(yōu)先訪問瀏覽器緩存，如果未命中再訪問OS緩存，
• 最后再訪問 DNS 服務(wù)器（一般是ISP提供），然后 DNS 服務(wù)器會遞歸式的查找域名記錄并返回結(jié)果。

DNS 記錄會有一個 TTL 值（Time To Live，存活時間），單位是秒，代表這條記錄最長有效期是多少。

瀏覽器 DNS 緩存的時間跟 DNS 服務(wù)器返回的 TTL 值無關(guān)。

應(yīng)用程序的 DNS 緩存是由應(yīng)用程序控制的，比如 Java 網(wǎng)絡(luò)應(yīng)用程序的 DNS 緩存是由 JVM 的緩存策略控制的。

OS 緩存會參考 DNS 服務(wù)器響應(yīng)的 TTL 值，但是不完全等于 TTL 值。

● 瀏覽器 DNS 緩存：瀏覽器在獲取網(wǎng)站域名的實際 IP 地址后會對其 IP 進(jìn)行緩存，減少網(wǎng)絡(luò)請求的損耗。每種瀏覽器都有一個固定的 DNS 緩存時間，其中 Chrome 的過期時間是 1 分鐘，在這個期限內(nèi)不會重新請求 DNS。Chrome 瀏覽器看本身的 DNS 緩存時間比較方便，在地址欄輸入：chrome://net-internals/#dns，就能看到看瀏覽器的緩存。

● Java DNS 緩存：Java 網(wǎng)絡(luò)應(yīng)用程序的 DNS 緩存是由 JVM 的緩存策略控制的，可以直接設(shè)置緩存過期時間：java.security.Security.setProperty(“networkaddress.cache.ttl”, 10);

● ISP DNS 緩存：一般 ISP 服務(wù)器上緩存時間（15 min）比 OS 緩存時間長，就算刷新了本機(jī)操作系統(tǒng)的緩存，ISP 上仍然保留。

● Windows DNS 緩存：Windows 訪問 DNS 后會把記錄保存一段短暫的時間，可通過 ipconfig /displaydns 查看 windows 的 DNS 緩存、通過 ipconfig /flushdns 來清除緩存。

● IOS DNS 緩存：按照官方文檔說法，IOS 設(shè)備上每 24 小時刷新一次 DNS 緩存。

7、DNS 使用 UDP 還是 TCP

DNS 占用 53 號端口，同時使用 TCP 和 UDP 協(xié)議。

DNS 在進(jìn)行區(qū)域傳輸?shù)臅r候使用 TCP 協(xié)議，其它時候則使用 UDP 協(xié)議；

DNS 有兩種類型的 DNS 服務(wù)器：主 DNS 服務(wù)器和輔助 DNS 服務(wù)器

• 在一個區(qū)中主 DNS 服務(wù)器從自己本機(jī)的數(shù)據(jù)文件中讀取該區(qū)的 DNS 數(shù)據(jù)信息而輔助 DNS 服務(wù)器則從區(qū)的主 DNS 服務(wù)器中讀取該區(qū)的 DNS 數(shù)據(jù)信息。
• 當(dāng)一個輔助 DNS 服務(wù)器啟動時，它需要與主 DNS 服務(wù)器通信，并加載數(shù)據(jù)信息，即區(qū)域傳輸（zone transfer）。

區(qū)域傳送（主、輔 DNS 服務(wù)器通信）時使用 TCP

輔 DNS 服務(wù)器會定時（一般時3小時）向主域名服務(wù)器進(jìn)行查詢以便了解數(shù)據(jù)是否有變動。

如有變動，則會執(zhí)行一次區(qū)域傳送，進(jìn)行數(shù)據(jù)同步。

區(qū)域傳送將使用 TCP而不是 UDP，因為數(shù)據(jù)同步傳送的數(shù)據(jù)量比較大。

TCP是一種可靠的連接，保證了數(shù)據(jù)的準(zhǔn)確性。

域名解析時使用 UDP

客戶端向 DNS 服務(wù)器查詢域名，一般返回的內(nèi)容都不超過 512 字節(jié)，用 UDP 傳輸即可。不用經(jīng)過 TCP 三次握手，這樣 DNS 服務(wù)器負(fù)載更低，響應(yīng)更快。雖然從理論上說，客戶端也可以指定向 DNS 服務(wù)器查詢的時候使用 TCP，但事實上，很多 DNS 服務(wù)器進(jìn)行配置的時候，僅支持 UDP 查詢包。

二、萬維網(wǎng)

1、萬維網(wǎng)概述

• 萬維網(wǎng) WWW (World Wide Web) 并非某種特殊的計算機(jī)網(wǎng)絡(luò)。
• 萬維網(wǎng)是一個大規(guī)模的、聯(lián)機(jī)式的信息儲藏所。
• 萬維網(wǎng)用鏈接的方法能非常方便地從互聯(lián)網(wǎng)上的一個站點訪問另一個站點，從而主動地按需獲取豐富的信息。

這種訪問方式稱為“鏈接”。

通俗的來說萬維網(wǎng)的使用就是我們通過游覽器進(jìn)行網(wǎng)絡(luò)的通信，得到的是網(wǎng)頁及其其他的數(shù)據(jù)。

（1）超媒體與超文本

• 萬維網(wǎng)是分布式超媒體 (hypermedia) 系統(tǒng)，它是超文本 (hypertext) 系統(tǒng)的擴(kuò)充。
• 一個超文本由多個信息源鏈接而成。
• 利用一個鏈接可使用戶找到另一個文檔。
• 這些文檔可以位于世界上任何一個接在互聯(lián)網(wǎng)上的超文本系統(tǒng)中。
• 超文本是萬維網(wǎng)的基礎(chǔ)。
• 超媒體與超文本的區(qū)別是文檔內(nèi)容不同。超文本文檔僅包含文本信息，而超媒體文檔還包含其他表示方式的信息，如圖形、圖像、聲音、動畫，甚至活動視頻圖像。

（2）萬維網(wǎng)的工作方式

• 萬維網(wǎng)以客戶/服務(wù)器方式工作。
• 瀏覽器就是在用戶計算機(jī)上的萬維網(wǎng)客戶程序。
• 萬維網(wǎng)文檔所駐留的計算機(jī)則運(yùn)行服務(wù)器程序，因此這個計算機(jī)也稱為萬維網(wǎng)服務(wù)器。
• 客戶程序向服務(wù)器程序發(fā)出請求，服務(wù)器程序向客戶程序送回客戶所要的萬維網(wǎng)文檔。
• 在一個客戶程序主窗口上顯示出的萬維網(wǎng)文檔稱為頁面(page)。

（3）萬維網(wǎng)必須解決的問題

1）怎樣標(biāo)志分布在整個互聯(lián)網(wǎng)上的萬維網(wǎng)文檔？

使用統(tǒng)一資源定位符 URL (Uniform Resource Locator) 來標(biāo)志萬維網(wǎng)上的各種文檔。使每一個文檔在整個互聯(lián)網(wǎng)的范圍內(nèi)具有唯一的標(biāo)識符 URL。

2）用何協(xié)議實現(xiàn)萬維網(wǎng)上各種超鏈的鏈接？

在萬維網(wǎng)客戶程序與萬維網(wǎng)服務(wù)器程序之間進(jìn)行交互所使用的協(xié)議，是超文本傳送協(xié)議 HTTP (HyperText Transfer Protocol)。HTTP 是一個應(yīng)用層協(xié)議，它使用 TCP 連接進(jìn)行可靠的傳送。

3）怎樣使各種萬維網(wǎng)文檔都能在互聯(lián)網(wǎng)上的各種計算機(jī)上顯示出來，同時使用戶清楚地知道在什么地方存在著超鏈？

超文本標(biāo)記語言 HTML (HyperText Markup Language) 使得萬維網(wǎng)頁面的設(shè)計者可以很方便地用一個超鏈從本頁面的某處鏈接到互聯(lián)網(wǎng)上的任何一個萬維網(wǎng)頁面，并且能夠在自己的計算機(jī)屏幕上將這些頁面顯示出來。

4）怎樣使用戶能夠很方便地找到所需的信息？

為了在萬維網(wǎng)上方便地查找信息，用戶可使用各種的搜索工具（即搜索引擎）。

2、超文本傳送協(xié)議 HTTP

（1）HTTP 的操作過程

為了使超文本的鏈接能夠高效率地完成，需要用 HTTP 協(xié)議來傳送一切必須的信息。

從層次的角度看，HTTP 是面向事務(wù)的(transaction-oriented)應(yīng)用層協(xié)議，它是萬維網(wǎng)上能夠可靠地交換文件（包括文本、聲音、圖像等各種多媒體文件）的重要基礎(chǔ)。

（2）請求一個萬維網(wǎng)文檔所需的時間

每次的數(shù)據(jù)傳輸度需要進(jìn)行建立連接與釋放連接的過程，為了提高傳輸?shù)男?，提出了以下幾種方案：

不釋放連接、流水操作、代理服務(wù)器。

1）不釋放連接

• HTTP/1.0 協(xié)議每次傳完一個萬維網(wǎng)文檔后會釋放連接，故每請求一個文檔需要2×RTT的開銷。
• 萬維網(wǎng)服務(wù)器在發(fā)送響應(yīng)后仍然在一段時間內(nèi)保持這條連接，使同一個客戶（瀏覽器）和該服務(wù)器可以繼續(xù)在這條連接上傳送后續(xù)的 HTTP 請求報文和響應(yīng)報文。
• 這并不局限于傳送同一個頁面上鏈接的文檔，而是只要這些文檔都在同一個服務(wù)器上就行。
• 目前一些流行的瀏覽器（例如，IE 6.0）的默認(rèn)設(shè)置就是使用 HTTP/1.1。

2）流水與非流水

• 非流水線方式：客戶在收到前一個響應(yīng)后才能發(fā)出下一個請求。這使得客戶每訪問一次對象都只需要一個 RTT 時間。但服務(wù)器在發(fā)送完一個對象后，其 TCP 連接就處于空閑狀態(tài)，浪費了服務(wù)器資源。
• 流水線方式：客戶在收到 HTTP 的響應(yīng)報文之前就能夠接著發(fā)送新的請求報文。一個接一個的請求報文到達(dá)服務(wù)器后，服務(wù)器就可連續(xù)發(fā)回響應(yīng)報文。使用流水線方式時，客戶訪問所有對象只需要花費一個 RTT時間，使 TCP 連接中的空閑時間減少，提高了下載文檔效率。

3）代理服務(wù)器

• 代理服務(wù)器 (proxy server) 又稱為萬維網(wǎng)高速緩存 (Web cache)，它代表瀏覽器發(fā)出 HTTP 請求。
• 萬維網(wǎng)高速緩存把最近的一些請求和響應(yīng)暫存在本地磁盤中。
• 當(dāng)與暫時存放的請求相同的新請求到達(dá)時，萬維網(wǎng)高速緩存就把暫存的響應(yīng)發(fā)送出去，而不需要按 URL 的地址再去互聯(lián)網(wǎng)訪問該資源。
• 代理服務(wù)器既是一個服務(wù)器，有時也是一個客戶。

3、萬維網(wǎng)的文檔

（1）超文本標(biāo)記語言 HTML

HTML

（HyperText Markup Language） 中的 Markup 的意思就是“設(shè)置標(biāo)記”。

當(dāng)瀏覽器從服務(wù)器讀取 HTML 文檔后，就按照 HTML 文檔中的各種標(biāo)簽，根據(jù)瀏覽器所使用的顯示器尺寸和分辨率大小，重新排版并恢復(fù)出所讀取的頁面。

兩種不同的鏈接:

HTML還規(guī)定了鏈接的設(shè)置方法。每個鏈接都有一個起點和終點。

XML

• XML (Extensible Markup Language)是可擴(kuò)展標(biāo)記語言，它和HTML很相似。
• 但XML的設(shè)計宗旨是傳輸數(shù)據(jù)，而不是顯示數(shù)據(jù)（HTML是為了在瀏覽器上顯示數(shù)據(jù)）。
• XML 不是要替換 HTML，而是對 HTML 的補(bǔ)充。

XHTML

• XHTML (Extensible HTML) 是可擴(kuò)展超文本標(biāo)記語言，它與 HTML 4.01 幾乎是相同的。
• 但 XHTML 是更嚴(yán)格的 HTML 版本，也是一個 W3C 標(biāo)準(zhǔn)（2000年1月），是作為一種 XML 應(yīng)用被重新定義的 HTML，并將逐漸取代 HTML。
• 新的瀏覽器都支持 XHTML。

CSS

• CSS (Cascading Style Sheets) 是層疊樣式表，它是一種樣式表語言，用于為 HTML 文檔定義布局。
• CSS 與 HTML 的區(qū)別就是：HTML 用于結(jié)構(gòu)化內(nèi)容，而 CSS 則用于格式化結(jié)構(gòu)化的內(nèi)容。

（2）動態(tài)萬維網(wǎng)文檔

靜態(tài)文檔是指該文檔創(chuàng)作完畢后就存放在萬維網(wǎng)服務(wù)器中，在被用戶瀏覽的過程中，內(nèi)容不會改變。

動態(tài)文檔是指文檔的內(nèi)容是在瀏覽器訪問萬維網(wǎng)服務(wù)器時才由應(yīng)用程序動態(tài)創(chuàng)建。

動態(tài)文檔和靜態(tài)文檔之間的主要差別體現(xiàn)在服務(wù)器一端。

這主要是文檔內(nèi)容的生成方法不同。而從瀏覽器的角度看，這兩種文檔并沒有區(qū)別。

CGI (Common Gateway Interface) 是一種標(biāo)準(zhǔn)，它定義了動態(tài)文檔應(yīng)如何創(chuàng)建，輸入數(shù)據(jù)應(yīng)如何提供給應(yīng)用程序，以及輸出結(jié)果應(yīng)如何使用。萬維網(wǎng)服務(wù)器與 CGI 的通信遵循 CGI 標(biāo)準(zhǔn)。

（3）活動萬維網(wǎng)文檔

瀏覽器屏幕的連續(xù)刷新

每當(dāng)瀏覽器請求一個活動文檔時，服務(wù)器就返回一段程序副本在瀏覽器端運(yùn)行。

活動文檔程序可與用戶直接交互，并可連續(xù)地改變屏幕顯示。

由于活動文檔技術(shù)不需要服務(wù)器的連續(xù)更新傳送，對網(wǎng)絡(luò)帶寬的要求也不會太高。

三、HTTP 與 HTTPs 協(xié)議

• HTTP 是用于從萬維網(wǎng)（WWW）服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議，是基于 TCP/IP 協(xié)議之上的應(yīng)用層協(xié)議。
• HTTP 定義了客戶端如何從服務(wù)器請求 Web 頁面，以及服務(wù)器如何把 Web 頁面?zhèn)魉徒o客戶端。
• HTTP 采用了請求 / 響應(yīng)模型，客戶端向服務(wù)器發(fā)送一個請求報文，服務(wù)器以一個狀態(tài)行作為響應(yīng)。

1、HTTP 特點

（1）簡單快速：

客戶向服務(wù)器請求服務(wù)時，只需傳送請求方法和路徑。

請求方法常用的有 GET、HEAD、POST。

每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。

由于 HTTP 協(xié)議簡單，使得 HTTP 服務(wù)器的程序規(guī)模小，因而通信速度很快。

（2）靈活：

HTTP 允許傳輸任意類型的數(shù)據(jù)對象。 正在傳輸?shù)念愋陀?Content-Type 加以標(biāo)記。

（3）無連接：

無連接的含義是限制每次連接只處理一個請求。

服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后立即斷開連接。

采用這種方式可以節(jié)省傳輸時間。

HTTP使用TCP協(xié)議作為它的支撐運(yùn)輸協(xié)。

HTTP客戶首先發(fā)起一個與服務(wù)器的TCP連接，一旦建立連接，該瀏覽器和服務(wù)器就可以通過套接字接口訪問TCP。

（4）無狀態(tài)保存：

HTTP 協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。

• 缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大（缺點）。
• 另一方面，在服務(wù)器不需要先前信息時它的應(yīng)答就較快，可以更快地處理大量事務(wù)（優(yōu)點）。

補(bǔ)充：對于無狀態(tài)保存，如果用戶登錄一家購物網(wǎng)站，希望即使用戶跳轉(zhuǎn)到該站的其他頁面也能繼續(xù)保持登錄狀態(tài)。HTTP/1.1 雖然是無狀態(tài)協(xié)議，但為了實現(xiàn)保存狀態(tài)的功能，引入了 Cookie 技術(shù)。

對于無連接，早期的 HTTP 是請求響應(yīng)之后直接斷開，但現(xiàn)在的 HTTP/1.1 不直接斷開，而是等幾秒鐘，如果用戶在這幾秒鐘之內(nèi)有新的請求，那么還是通過之前的連接通道來收發(fā)消息，如果過了這幾秒鐘用戶沒有發(fā)送新的請求，那么就會斷開連接，這樣可以提高效率，減少短時間內(nèi)建立連接的次數(shù)，因為建立連接也是耗時的。

（5）支持 B/S 及 C/S 模式。

2、HTTP 各版本比較

3、HTTP 的請求與響應(yīng)報文

（1）HTTP 請求（Request）

客戶端發(fā)送一個 HTTP 請求到服務(wù)器的請求消息包括：請求行（request line）、請求頭部（header）、空行和請求數(shù)據(jù)四個部分。

HTTP 請求行

HTTP 請求頭

請求頭信息為 “名:值” 對，之間用冒號分隔。

請求頭參數(shù)包括：

空行

HTTP 請求頭的最后會有一個空行，表示請求頭部結(jié)束，接下來為請求數(shù)據(jù)，空行一定要有。

請求數(shù)據(jù)

請求數(shù)據(jù)不一定有，比如 get 請求就沒有請求數(shù)據(jù)。

（2）HTTP 響應(yīng)（Response）

服務(wù)器接收并處理客戶端發(fā)過來的請求后會返回一個 HTTP 的響應(yīng)消息，響應(yīng)包括：狀態(tài)行、響應(yīng)頭部、空行和響應(yīng)正文四個部分。

狀態(tài)行：

包括協(xié)議版本、狀態(tài)碼和狀態(tài)碼描述。協(xié)議版本和請求報文一致，狀態(tài)碼是一個 3 位數(shù)字。

比較常見的狀態(tài)碼有：

• 200 表示響應(yīng)成功；
• 302 表示跳轉(zhuǎn)，跳轉(zhuǎn)地址通過響應(yīng)頭中的 Location 屬性指定；
• 400 表示客戶端請求有語法錯誤，不能被服務(wù)器識別；
• 403 表示服務(wù)器接收到請求，但拒絕提供服務(wù)（認(rèn)證失?。?；

響應(yīng)頭部

4、HTTP 請求響應(yīng)步驟

（1）客戶端連接到 Web 服務(wù)器

用戶確定要訪問網(wǎng)頁的URL，并將其輸入到瀏覽器的地址欄中，瀏覽器向DNS服務(wù)器發(fā)出請求，獲取Web服務(wù)器域名所對應(yīng)的IP地址。

HTTP 客戶端通常就是瀏覽器，與 Web 服務(wù)器的 HTTP 端口（默認(rèn)為 80）建立一個 TCP 套接字連接，比如http://www.abc.com；

（2）發(fā)送 HTTP 請求

通過 TCP 套接字，客戶端向 Web 服務(wù)器發(fā)送一個請求傳輸網(wǎng)頁的 HTTP 請求報文。

一個請求報文由請求行、請求頭部、空行和請求數(shù)據(jù) 4 部分組成；

（3）服務(wù)器接受請求并返回 HTTP 響應(yīng)

Web 服務(wù)器解析請求，定位請求資源并將資源復(fù)本寫到 TCP 套接字，由客戶端讀取。

一個響應(yīng)由 狀態(tài)行、響應(yīng)頭部、空行和響應(yīng)數(shù)據(jù) 4 部分組成；

（4）釋放 TCP 連接

若 connection 模式為 close，則服務(wù)器主動關(guān)閉 TCP 連接，客戶端被動關(guān)閉連接，TCP 連接釋放；

若 connection 模式為 keepalive，則該連接會保持一段時間，在該時間內(nèi)可以繼續(xù)接收請求；

（5）客戶端瀏覽器解析 HTML 內(nèi)容

客戶端瀏覽器首先解析狀態(tài)行，查看表明請求是否成功的狀態(tài)代碼。

然后解析每一個響應(yīng)頭，響應(yīng)頭告知以下為若干字節(jié)的 HTML 文檔和文檔的字符集。

客戶端瀏覽器讀取響應(yīng)數(shù)據(jù) HTML，根據(jù) HTML 的語法對其進(jìn)行格式化，并在瀏覽器窗口中顯示；

5、HTTPS 協(xié)議

HTTPS（Secure Hypertext Transfer Protocol）安全超文本傳輸協(xié)議，使用安全套接字層（SSL）進(jìn)行信息交換

即 HTTPS 是使用了 TLS/SSL 加密的 HTTP 協(xié)議，基于非對稱加密算法和對稱加密算法的協(xié)作使用。

TLS/SSL 指加密的規(guī)范，介于 TCP 和 HTTP 之間的安全協(xié)議，不影響原有的 TCP 和 HTTP 協(xié)議。

（1）TLS/SSL協(xié)議的三個特性

TLS/SSL 協(xié)議就是客戶端和服務(wù)器之間實現(xiàn)安全交換信息的協(xié)議。

TLS/SSL 的功能實現(xiàn)主要依賴于三類基本算法：散列函數(shù) Hash、非對稱加密和對稱加密。

• 先利用非對稱加密實現(xiàn)身份認(rèn)證和密鑰協(xié)商
• 再通過對稱加密算法用協(xié)商好的密鑰對數(shù)據(jù)加密
• 最后基于散列函數(shù)驗證信息的完整性

（2）SSL 握手過程

● ClientHello：客戶端請求建立 SSL 連接，向服務(wù)器提供以下信息：

1）支持的 SSL 協(xié)議版本，比如 TLS1.0；

2）客戶端生成的隨機(jī)數(shù)，用于后續(xù)對稱加密階段生成對話密鑰；

3）支持的加密方法，比如RSA公鑰加密。

● SeverHello：服務(wù)器對客戶端的請求發(fā)出回應(yīng)，包括以下信息：

1）確認(rèn)使用的 SSL 協(xié)議版本，如果服務(wù)器與客戶端支持的版本不一致，服務(wù)器關(guān)閉通信；

2）服務(wù)器生成的隨機(jī)數(shù)，用于后續(xù)對稱加密階段生成對話密鑰；

3）確認(rèn)使用的加密方法，比如 RSA 公鑰加密；

4）服務(wù)器證書。（如果服務(wù)器也需要確認(rèn)客戶端的身份，就會再包含一項信息，即要求客戶端提供客戶端證書，比如金融機(jī)構(gòu)只允許認(rèn)證客戶連入自己的網(wǎng)絡(luò)）

● 客戶端收到服務(wù)器回應(yīng)后，驗證服務(wù)器證書的合法性，如果證書非可信機(jī)構(gòu)頒布、證書已過期等，會提出警告，選擇是否還要繼續(xù)通信。如果證書沒有問題，客戶端就從證書中取出服務(wù)器的公鑰。然后向服務(wù)器發(fā)送三個信息：

1）用公鑰加密的隨機(jī)數(shù)（pre-master key）；

2）編碼改變通知，表示隨后的信息將用雙方商量好的加密方法和密鑰發(fā)送；

3）客戶端握手結(jié)束通知，這一項同時也是前面發(fā)送的所有內(nèi)容的 hash 值，用于供服務(wù)器校驗。

● 服務(wù)器的最后回應(yīng)，服務(wù)器收到客戶端的 pre-master key 之后，計算生成本次會話所用的會話密鑰，然后向客戶端發(fā)送以下信息：

1）編碼改變通知，表示隨后的信息將用雙方商量好的加密方法和密鑰發(fā)送；

2）服務(wù)器握手結(jié)束通知，這一項同時也是前面發(fā)送的所有內(nèi)容的 hash 值，用于供客戶端校驗。

握手階段結(jié)束，客戶端和服務(wù)器進(jìn)入加密通信階段，就是使用 HTTP 協(xié)議，只不過通信內(nèi)容都用上面商定的會話密鑰進(jìn)行了加密。

（3）非對稱加密和對稱加密

1）非對稱加密：用于在 SSL 握手過程中加密生成的密碼。一對多通信，分為公鑰和私鑰，公鑰加密的信息只有私鑰能解開（甚至公鑰都不能解密出自己加密的信息），因此掌握公鑰的不同客戶端之間不能互相解密信息。常見非對稱加密算法有 RSA、ECC、DH 等。

2）對稱加密：用于加密真正要傳輸?shù)臄?shù)據(jù)。一對一通信，使用相同的密鑰對信息進(jìn)行加密和解密，只有掌握密鑰才能獲取信息，能夠防止信息竊聽。常見的對稱加密算法有 AES-CBC、DES、3DES、AES-GCM 等。不同節(jié)點采用的對稱密鑰不同，從而保證了信息只能由通信雙方獲取。

3）Hash 算法：用于驗證數(shù)據(jù)的完整性。哈希函數(shù)特性是單向不可逆，對輸入非常敏感，輸出長度固定，對原始數(shù)據(jù)的任何修改都會改變散列函數(shù)的結(jié)果，在這里用于防止信息篡改并驗證數(shù)據(jù)的完整性。常見的算法有 MD5、SHA1、SHA256（Secure Hash Algorithm，安全哈希算法）。散列函數(shù)不能脫離加密進(jìn)行信息防篡改，因為明文傳輸時中間人可以修改信息后重新計算信息摘要，因此需要對傳輸?shù)男畔⒓靶畔⒄M(jìn)行加密。

6、HTTP 和 HTTPs 區(qū)別

HTTPS 優(yōu)點：

HTTPS 缺點：

7、Web 緩存

Web緩存(Web cache)也叫代理服務(wù)器(proxy server)。

（1）WEB緩存的作用

（2）工作過程

1） 瀏覽器和代理服務(wù)器建立TCP連接，并將HTTP請求發(fā)送到代理服務(wù)器

2）代理服務(wù)器見檢查本地已存儲對象復(fù)本。如果存儲對象在其中，代理服務(wù)器向瀏覽器發(fā)送HTTP響應(yīng)報文返回該對象

3）如果代理服務(wù)器中沒有該請求對象，代理服務(wù)器和源服務(wù)器建立TCP連接，然后代理服務(wù)器向源服務(wù)器發(fā)送一個目標(biāo)對象的HTTP請求。源服務(wù)器接到請求后，將請求對象通過HTTP響應(yīng)發(fā)送給代理服務(wù)器

4）代理服務(wù)器收到請求的對象時，在本地建立該對象的副本，然后通HTTP響應(yīng)將對象發(fā)送給瀏覽器。

8、Web 頁面請求過程

（1）DHCP 配置主機(jī)信息

假設(shè)主機(jī)最開始沒有 IP 地址以及其它信息，那么就需要先使用 DHCP 來獲取。

① 主機(jī)生成一個 DHCP 請求報文，并將這個報文放入具有目的端口 67 和源端口 68 的 UDP 報文段中。

② 該報文段則被放入在一個具有廣播 IP 目的地址(255.255.255.255) 和源 IP 地址（0.0.0.0）的 IP 數(shù)據(jù)報中。

③ 該數(shù)據(jù)報則被放置在MAC 幀中，該幀具有目的地址 FF:FF:FF:FF:FF:FF，將廣播到與交換機(jī)連接的所有設(shè)備。

④ 連接在交換機(jī)的 DHCP 服務(wù)器收到廣播幀之后，不斷地向上分解得到 IP 數(shù)據(jù)報、UDP 報文段、DHCP 請求報文，之后生成 DHCP ACK 報文，該報文包含以下信息：IP 地址、DNS 服務(wù)器的 IP 地址、默認(rèn)網(wǎng)關(guān)路由器的 IP 地址和子網(wǎng)掩碼。該報文被放入 UDP 報文段中，UDP 報文段有被放入 IP 數(shù)據(jù)報中，最后放入 MAC 幀中。

⑤ 該幀的目的地址是請求主機(jī)的 MAC 地址，因為交換機(jī)具有自學(xué)習(xí)能力，之前主機(jī)發(fā)送了廣播幀之后就記錄了 MAC 地址到其轉(zhuǎn)發(fā)接口的交換表項，因此現(xiàn)在交換機(jī)就可以直接知道應(yīng)該向哪個接口發(fā)送該幀。

⑥ 主機(jī)收到該幀后，不斷分解得到 DHCP 報文。之后就配置它的 IP 地址、子網(wǎng)掩碼和 DNS 服務(wù)器的 IP 地址，并在其 IP 轉(zhuǎn)發(fā)表中安裝默認(rèn)網(wǎng)關(guān)。

（2）ARP 解析 MAC 地址

①: 主機(jī)通過瀏覽器生成一個 TCP 套接字，套接字向 HTTP 服務(wù)器發(fā)送 HTTP 請求。為了生成該套接字，主機(jī)需要知道網(wǎng)站的域名對應(yīng)的 IP 地址。

②: 主機(jī)生成一個 DNS 查詢報文，該報文具有 53 號端口，因為 DNS 服務(wù)器的端口號是 53。

③: 該 DNS 查詢報文被放入目的地址為 DNS 服務(wù)器 IP 地址的 IP 數(shù)據(jù)報中

④: 該 IP 數(shù)據(jù)報被放入一個以太網(wǎng)幀中，該幀將發(fā)送到網(wǎng)關(guān)路由器。

⑤: DHCP 過程只知道網(wǎng)關(guān)路由器的 IP 地址，為了獲取網(wǎng)關(guān)路由器的 MAC 地址，需要使用 ARP 協(xié)議。

⑥: 主機(jī)生成一個包含目的地址為網(wǎng)關(guān)路由器 IP 地址的 ARP 查詢報文，將該 ARP 查詢報文放入一個具有廣播目的地址（FF:FF:FF:FF:FF:FF）的以太網(wǎng)幀中，并向交換機(jī)發(fā)送該以太網(wǎng)幀，交換機(jī)將該幀轉(zhuǎn)發(fā)給所有的連接設(shè)備，包括網(wǎng)關(guān)路由器。

⑦: 網(wǎng)關(guān)路由器接收到該幀后，不斷向上分解得到 ARP 報文，發(fā)現(xiàn)其中的 IP 地址與其接口的 IP 地址匹配，因此就發(fā)送一個 ARP 回答報文，包含了它的 MAC 地址，發(fā)回給主機(jī)。

（3）DNS 解析域名

①: 知道了網(wǎng)關(guān)路由器的 MAC 地址之后，就可以繼續(xù) DNS 的解析過程了。

②: 網(wǎng)關(guān)路由器接收到包含 DNS 查詢報文的以太網(wǎng)幀后，抽取出 IP 數(shù)據(jù)報，并根據(jù)轉(zhuǎn)發(fā)表決定該 IP 數(shù)據(jù)報應(yīng)該轉(zhuǎn)發(fā)的路由器。

③:因為路由器具有內(nèi)部網(wǎng)關(guān)協(xié)議（RIP、OSPF）和外部網(wǎng)關(guān)協(xié)議（BGP）這兩種路由選擇協(xié)議，因此路由表中已經(jīng)配置了網(wǎng)關(guān)路由器到達(dá) DNS 服務(wù)器的路由表項。

④: 到達(dá) DNS 服務(wù)器之后，DNS 服務(wù)器抽取出 DNS 查詢報文，并在 DNS 數(shù)據(jù)庫中查找待解析的域名。

⑤: 找到 DNS 記錄之后，發(fā)送 DNS 回答報文，將該回答報文放入 UDP 報文段中，然后放入 IP 數(shù)據(jù)報中，通過路由器反向轉(zhuǎn)發(fā)回網(wǎng)關(guān)路由器，并經(jīng)過以太網(wǎng)交換機(jī)到達(dá)主機(jī)。

（4）HTTP 請求頁面

①: 有了 HTTP 服務(wù)器的 IP 地址之后，主機(jī)就能夠生成 TCP 套接字，該套接字將用于向 Web 服務(wù)器發(fā)送 HTTP GET 報文。

②: 在生成 TCP 套接字之前，必須先與 HTTP 服務(wù)器進(jìn)行三次握手來建立連接。生成一個具有目的端口 80 的 TCP SYN 報文段，并向 HTTP 服務(wù)器發(fā)送該報文段。

③: HTTP 服務(wù)器收到該報文段之后，生成 TCP SYN ACK 報文段，發(fā)回給主機(jī)。

④: 連接建立之后，瀏覽器生成 HTTP GET 報文，并交付給 HTTP 服務(wù)器。

⑤: HTTP 服務(wù)器從 TCP 套接字讀取 HTTP GET 報文，生成一個 HTTP 響應(yīng)報文，將 Web 頁面內(nèi)容放入報文主體中，發(fā)回給主機(jī)。

⑥: 瀏覽器收到 HTTP 響應(yīng)報文后，抽取出 Web 頁面內(nèi)容，之后進(jìn)行渲染，顯示 Web 頁面。

四、遠(yuǎn)程終端協(xié)議 TELNET

TELNET 是一個簡單的遠(yuǎn)程終端協(xié)議，也是互聯(lián)網(wǎng)的正式標(biāo)準(zhǔn)。

用戶用 TELNET 就可在其所在地通過 TCP 連接注冊（即登錄）到遠(yuǎn)地的另一個主機(jī)上（使用主機(jī)名或 IP 地址）。

TELNET 能將用戶的擊鍵傳到遠(yuǎn)地主機(jī)，同時也能將遠(yuǎn)地主機(jī)的輸出通過 TCP 連接返回到用戶屏幕。

這種服務(wù)是透明的，因為用戶感覺到好像鍵盤和顯示器是直接連在遠(yuǎn)地主機(jī)上。

客戶/服務(wù)器方式

現(xiàn)在由于 PC 的功能越來越強(qiáng)，用戶已較少使用 TELNET 了。TELNET 也使用客戶/服務(wù)器方式。

在本地系統(tǒng)運(yùn)行 TELNET 客戶進(jìn)程，而在遠(yuǎn)地主機(jī)則運(yùn)行 TELNET 服務(wù)器進(jìn)程。

和 FTP 的情況相似，服務(wù)器中的主進(jìn)程等待新的請求，并產(chǎn)生從屬進(jìn)程來處理每一個連接。

TELNET 使用網(wǎng)絡(luò)虛擬終端 NVT 格式 。

網(wǎng)絡(luò)虛擬終端 NVT 格式

客戶軟件把用戶的擊鍵和命令轉(zhuǎn)換成 NVT 格式，并送交服務(wù)器。

服務(wù)器軟件把收到的數(shù)據(jù)和命令，從 NVT 格式轉(zhuǎn)換成遠(yuǎn)地系統(tǒng)所需的格式。

向用戶返數(shù)據(jù)時，服務(wù)器把遠(yuǎn)地系統(tǒng)的格式轉(zhuǎn)換為 NVT 格式，本地客戶再從 NVT 格式轉(zhuǎn)換到本地系統(tǒng)所需的格式。

五、FTP

文件傳輸協(xié)議（FileTransfer Protocol，F(xiàn)TP）屬于 TCP/IP 協(xié)議族的應(yīng)用層協(xié)議，其傳輸層使用的是 TCP，基于客戶機(jī)/服務(wù)器模式工作，為數(shù)據(jù)傳輸提供了可靠保證。

FTP的工作過程

其實就是客戶機(jī)程序根據(jù)用戶需要發(fā)送命令，服務(wù)器程序響應(yīng)命令的過程。

需要建立兩種類型的連接：控制連接和數(shù)據(jù)連接。

• 控制連接傳送客戶機(jī)程序發(fā)出的命令和服務(wù)器返回的響應(yīng)信息
• 而數(shù)據(jù)連接則負(fù)責(zé)傳輸文件的內(nèi)容。

流程

（1）啟動FTP服務(wù)器：

由于FTP采用了客戶機(jī)/服務(wù)器工作模式，因此在創(chuàng)建FTP會話之前，首先必須啟動FTP服務(wù)器，并使其處于等待客戶機(jī)程序的FTP請求狀態(tài)。

（2）啟動FTP客戶機(jī)程序并建立控制連接：

啟動FTP客戶機(jī)程序，并向FTP服務(wù)器的21端口（控制連接端口）發(fā)出主動連接的請求，以期獲得FTP服務(wù)器的相應(yīng)權(quán)限。服務(wù)器響應(yīng)請求后便在用戶協(xié)議解釋器和服務(wù)器協(xié)議解釋器之間建立了一條TCP連接。

（3）建立數(shù)據(jù)連接并進(jìn)行文件傳輸：

用戶通過客戶機(jī)程序輸入FTP命令，服務(wù)器接收命令。如果命令正確且需要進(jìn)行文件傳輸，服務(wù)器使用TCP20端口在雙方之間建立另一條TCP連接，即數(shù)據(jù)連接，并通過該連接進(jìn)行文件傳輸。當(dāng)本次命令的文件傳輸完畢，關(guān)閉該數(shù)據(jù)連接。

（4）關(guān)閉FTP：

用戶執(zhí)行完其所需的FTP命令后，發(fā)出退出FTP命令，控制連接關(guān)閉，本次FTP服務(wù)結(jié)束。

常見的命令下：

六、電子郵件傳輸協(xié)議

一個電子郵件系統(tǒng)由三部分組成：

用戶代理、郵件服務(wù)器以及郵件協(xié)議。

需要發(fā)送者郵件代理、發(fā)送者郵件服務(wù)器、接收者郵件服務(wù)器，接收者代理4個程序的參與。

● 郵件服務(wù)代理（郵件服務(wù)器）MTA：郵件服務(wù)代理通常是計算機(jī)系統(tǒng)中的一個進(jìn)程，負(fù)責(zé)把郵件從源端傳輸?shù)侥康亩恕?/p>

● 用戶代理：用戶代理就是我們平時見到的Gmail，QQ郵箱之類的，其中有查看郵件等功能。

● 郵件傳輸過程：用戶編寫郵件后會存放在郵件服務(wù)器，發(fā)送時根據(jù)目的郵箱地址從DNS查找對方的郵件服務(wù)器地址并發(fā)送，目的郵件服務(wù)器將郵件存儲 。

郵件協(xié)議包含發(fā)送協(xié)議和讀取協(xié)議，發(fā)送協(xié)議常用 SMTP，讀取協(xié)議常用 POP3 和 IMAP。

電子郵件格式：

1、SMTP（Simple Mail Transfer Protocol）

簡單郵件傳輸協(xié)議SMTP（下層協(xié)議TCP，端口25）：一般用于發(fā)送郵件即由用戶代理發(fā)送到郵件服務(wù)器，或郵件服務(wù)器到達(dá)目的郵件服務(wù)器。 SMTP 是建立在傳輸層協(xié)議 TCP 上的可靠高效的郵件傳輸協(xié)議，采用請求/應(yīng)答方式來實現(xiàn)。整個工作過程包括連接建立、郵件傳送和連接釋放3個階段。

（1）連接建立：SMTP是基于客戶機(jī)/服務(wù)器模式工作的，郵件服務(wù)器在TCP的25端口守候客戶機(jī)的請求。當(dāng)需要發(fā)送郵件時，發(fā)送主機(jī)的SMTP客戶機(jī)向連接主機(jī)的SMTP服務(wù)器的TCP端口25發(fā)出建立連接請求，得到服務(wù)器確認(rèn)后連接建立。此后，SMTP客戶機(jī)再次向SMTP服務(wù)器發(fā)送HELO命令，并附上發(fā)送方主機(jī)名以確認(rèn)SMTP服務(wù)器是否已經(jīng)準(zhǔn)備好接收郵件。如果SMTP服務(wù)器應(yīng)答“250 XXXX”表示已準(zhǔn)備好接收郵件。（2）郵件傳送：SMTP客戶機(jī)得到SMTP服務(wù)器的肯定回答后，隨即可利用MAIL命令告訴SMTP服務(wù)器新的郵件發(fā)送操作已經(jīng)開始。如果SMTP服務(wù)器已經(jīng)準(zhǔn)備好接收郵件，則以250應(yīng)答代碼應(yīng)答。其后SMTP客戶機(jī)可以用RCPT命令發(fā)送郵件接收者的目的地址，以便SMTP服務(wù)器把郵件內(nèi)容最終傳送到收件人的郵箱中。如果命令被接收，則返回250應(yīng)答碼。然后SMTP客戶機(jī)可利用DATA命令告訴SMTP服務(wù)器下面將要發(fā)送郵件內(nèi)容。如果命令被接收，則SMTP服務(wù)器以354應(yīng)答碼應(yīng)答，并認(rèn)定以下的各行都是郵件內(nèi)容。發(fā)送完畢后，再發(fā)送

2、POP3

郵局協(xié)議版本3POP3協(xié)議（下層協(xié)議TCP，端口110）用于由郵件服務(wù)器接收郵件到用戶代理端。

（1）只要用戶從服務(wù)器上讀取了郵件，就把該郵件刪除，但是目前改進(jìn)的 POP3 已經(jīng)全面支持下載而不刪除原郵件。

（2）無論你在客戶端做了任何操作（如移動、標(biāo)記），都不會反映到服務(wù)器上，也就是只能單方面地從服務(wù)器“讀取”。POP3協(xié)議所用的是110端口。

3、IMAP

交互郵件訪問協(xié)議IMAP協(xié)議（下層協(xié)議TCP，端口143）用于由郵件服務(wù)器接收郵件到用戶代理端。

IMAP 協(xié)議中客戶端和服務(wù)器上的郵件保持同步，如果不手動刪除郵件，那么服務(wù)器上的郵件也不會被自動刪除。

IMAP 這種做法可以讓用戶隨時隨地去訪問服務(wù)器上的郵件。

同時它與 POP3 的本質(zhì)區(qū)別在于，在客戶端的操作（包括刪除）都會反映到服務(wù)器上，是一個雙向的通信。

七、Socket

TCP下的socket

處于應(yīng)用層和運(yùn)輸層之間，給出了一個接口，可以使用TCP協(xié)議進(jìn)行通信。

TCP 下 socket 流程：

到此這篇關(guān)于詳細(xì)講解計算機(jī)網(wǎng)絡(luò)——應(yīng)用層的文章就介紹到這了,更多相關(guān)計算機(jī)網(wǎng)絡(luò)應(yīng)用層內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！