詳細(xì)講解計(jì)算機(jī)網(wǎng)絡(luò)——應(yīng)用層

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

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

應(yīng)用層直接為用戶提供服務(wù)，應(yīng)用層有很多協(xié)議，每一個(gè)協(xié)議對(duì)應(yīng)著計(jì)算機(jī)上的一個(gè)服務(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)用程序如何相互傳遞報(bào)文。

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

一、DNS

1、DNS 是什么

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3、域名服務(wù)器

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

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

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

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

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

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

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

4、DNS 解析流程

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

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

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

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

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

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

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

簡單來說，其實(shí)只有四步：

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

（1）迭代查詢

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

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

（2）遞歸查詢

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

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

6、DNS 緩存機(jī)制

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

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

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

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

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

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

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

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

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

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

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

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

7、DNS 使用 UDP 還是 TCP

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

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

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

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

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

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

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

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

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

域名解析時(shí)使用 UDP

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

二、萬維網(wǎng)

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

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

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

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

（1）超媒體與超文本

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）HTTP 的操作過程

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

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

（2）請(qǐng)求一個(gè)萬維網(wǎng)文檔所需的時(shí)間

每次的數(shù)據(jù)傳輸度需要進(jìn)行建立連接與釋放連接的過程，為了提高傳輸?shù)男剩岢隽艘韵聨追N方案：

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

1）不釋放連接

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

2）流水與非流水

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

3）代理服務(wù)器

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

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è)置方法。每個(gè)鏈接都有一個(gè)起點(diǎn)和終點(diǎn)。

XML

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

XHTML

• XHTML (Extensible HTML) 是可擴(kuò)展超文本標(biāo)記語言，它與 HTML 4.01 幾乎是相同的。
• 但 XHTML 是更嚴(yán)格的 HTML 版本，也是一個(gè) 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）動(dòng)態(tài)萬維網(wǎng)文檔

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

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

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

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

CGI (Common Gateway Interface) 是一種標(biāo)準(zhǔn)，它定義了動(dòng)態(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）活動(dòng)萬維網(wǎng)文檔

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

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

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

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

三、HTTP 與 HTTPs 協(xié)議

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

1、HTTP 特點(diǎn)

（1）簡單快速：

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

請(qǐng)求方法常用的有 GET、HEAD、POST。

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

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

（2）靈活：

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

（3）無連接：

無連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。

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

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

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

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

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

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

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

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

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

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

2、HTTP 各版本比較

3、HTTP 的請(qǐng)求與響應(yīng)報(bào)文

（1）HTTP 請(qǐng)求（Request）

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

HTTP 請(qǐng)求行

HTTP 請(qǐng)求頭

請(qǐng)求頭信息為 “名:值” 對(duì)，之間用冒號(hào)分隔。

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

空行

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

請(qǐng)求數(shù)據(jù)

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

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

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

狀態(tài)行：

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

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

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

響應(yīng)頭部

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

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

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

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

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

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

一個(gè)請(qǐng)求報(bào)文由請(qǐng)求行、請(qǐng)求頭部、空行和請(qǐng)求數(shù)據(jù) 4 部分組成；

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

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

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

（4）釋放 TCP 連接

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

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

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

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

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

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

5、HTTPS 協(xié)議

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

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

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

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

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

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

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

（2）SSL 握手過程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（3）非對(duì)稱加密和對(duì)稱加密

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

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

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

6、HTTP 和 HTTPs 區(qū)別

HTTPS 優(yōu)點(diǎn)：

HTTPS 缺點(diǎn)：

7、Web 緩存

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

（1）WEB緩存的作用

（2）工作過程

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

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

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

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

8、Web 頁面請(qǐng)求過程

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

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

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

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

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

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

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

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

（2）ARP 解析 MAC 地址

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

②: 主機(jī)生成一個(gè) DNS 查詢報(bào)文，該報(bào)文具有 53 號(hào)端口，因?yàn)?DNS 服務(wù)器的端口號(hào)是 53。

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

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

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

⑥: 主機(jī)生成一個(gè)包含目的地址為網(wǎng)關(guān)路由器 IP 地址的 ARP 查詢報(bào)文，將該 ARP 查詢報(bào)文放入一個(gè)具有廣播目的地址（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 報(bào)文，發(fā)現(xiàn)其中的 IP 地址與其接口的 IP 地址匹配，因此就發(fā)送一個(gè) ARP 回答報(bào)文，包含了它的 MAC 地址，發(fā)回給主機(jī)。

（3）DNS 解析域名

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

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

③:因?yàn)槁酚善骶哂袃?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ù)器的路由表項(xiàng)。

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

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

（4）HTTP 請(qǐng)求頁面

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

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

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

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

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

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

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

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

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

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

這種服務(wù)是透明的，因?yàn)橛脩舾杏X到好像鍵盤和顯示器是直接連在遠(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)程等待新的請(qǐng)求，并產(chǎn)生從屬進(jìn)程來處理每一個(gè)連接。

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ù)時(shí)，服務(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的工作過程

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

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

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

流程

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

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

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

啟動(dòng)FTP客戶機(jī)程序，并向FTP服務(wù)器的21端口（控制連接端口）發(fā)出主動(dòng)連接的請(qǐng)求，以期獲得FTP服務(wù)器的相應(yīng)權(quán)限。服務(wù)器響應(yīng)請(qǐ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é)議

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

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

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

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

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

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

郵件協(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é)議，采用請(qǐng)求/應(yīng)答方式來實(shí)現(xiàn)。整個(gè)工作過程包括連接建立、郵件傳送和連接釋放3個(gè)階段。

（1）連接建立：SMTP是基于客戶機(jī)/服務(wù)器模式工作的，郵件服務(wù)器在TCP的25端口守候客戶機(jī)的請(qǐng)求。當(dāng)需要發(fā)送郵件時(shí)，發(fā)送主機(jī)的SMTP客戶機(jī)向連接主機(jī)的SMTP服務(wù)器的TCP端口25發(fā)出建立連接請(qǐng)求，得到服務(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）無論你在客戶端做了任何操作（如移動(dòng)、標(biāo)記），都不會(huì)反映到服務(wù)器上，也就是只能單方面地從服務(wù)器“讀取”。POP3協(xié)議所用的是110端口。

3、IMAP

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

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

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

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

七、Socket

TCP下的socket

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

TCP 下 socket 流程：

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