（pdf如果有要的haul，私信吧）

Web 使用一種名為 HTTP（HyperText Transfer Protocol，超文本傳輸協(xié) 議 1）的協(xié)議作為規(guī)范，完成從客戶端到服務(wù)器端等一系列運(yùn)作流 程。而協(xié)議是指規(guī)則的約定。可以說，Web 是建立在 HTTP 協(xié)議上通 信的。?

現(xiàn)在已提出了 3 項(xiàng) WWW 構(gòu)建技術(shù)，htm,http,url

TCP/IP 協(xié)議族里重要的一點(diǎn)就是分層。TCP/IP 協(xié)議族按層次分別分 為以下 4 層：應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層。

TCP/IP 協(xié)議族各層的作用如下。?

應(yīng)用層?

應(yīng)用層決定了向用戶提供應(yīng)用服務(wù)時(shí)通信的活動(dòng)。 TCP/IP 協(xié)議族內(nèi)預(yù)存了各類通用的應(yīng)用服務(wù)。比如，FTP（File Transfer Protocol，文件傳輸協(xié)議）和 DNS（Domain Name System，域 名系統(tǒng)）服務(wù)就是其中兩類。 HTTP 協(xié)議也處于該層。?

傳輸層?

傳輸層對(duì)上層應(yīng)用層，提供處于網(wǎng)絡(luò)連接中的兩臺(tái)計(jì)算機(jī)之間的數(shù)據(jù) 傳輸。 在傳輸層有兩個(gè)性質(zhì)不同的協(xié)議：TCP（Transmission Control Protocol，傳輸控制協(xié)議）和 UDP（User Data Protocol，用戶數(shù)據(jù)報(bào) 協(xié)議）。?

網(wǎng)絡(luò)層（又名網(wǎng)絡(luò)互連層）?

網(wǎng)絡(luò)層用來處理在網(wǎng)絡(luò)上流動(dòng)的數(shù)據(jù)包。數(shù)據(jù)包是網(wǎng)絡(luò)傳輸?shù)淖钚?shù)據(jù)單位。該層規(guī)定了通過怎樣的路徑（所謂的傳輸路線）到達(dá)對(duì)方計(jì)算機(jī)，并把數(shù)據(jù)包傳送給對(duì)方。與對(duì)方計(jì)算機(jī)之間通過多臺(tái)計(jì)算機(jī)或網(wǎng)絡(luò)設(shè)備進(jìn)行傳輸時(shí)，網(wǎng)絡(luò)層所 起的作用就是在眾多的選項(xiàng)內(nèi)選擇一條傳輸路線。?

鏈路層（又名數(shù)據(jù)鏈路層，網(wǎng)絡(luò)接口層） 用來處理連接網(wǎng)絡(luò)的硬件部分。包括控制操作系統(tǒng)、硬件的設(shè)備驅(qū) 動(dòng)、NIC（Network Interface Card，網(wǎng)絡(luò)適配器，即網(wǎng)卡），及光纖等 物理可見部分（還包括連接器等一切傳輸媒介）。硬件上的范疇均在 鏈路層的作用范圍之內(nèi)。

：具體怎么實(shí)現(xiàn)呢

官方給出了解釋：

首先作為發(fā)送端的客戶端在應(yīng)用層 （HTTP 協(xié)議）發(fā)出一個(gè)想看某個(gè) Web 頁面的 HTTP 請(qǐng)求。 接著，為了傳輸方便，在傳輸層（TCP 協(xié)議）把從應(yīng)用層處收到的數(shù) 據(jù)（HTTP 請(qǐng)求報(bào)文）進(jìn)行分割，并在各個(gè)報(bào)文上打上標(biāo)記序號(hào)及端 口號(hào)后轉(zhuǎn)發(fā)給網(wǎng)絡(luò)層。 在網(wǎng)絡(luò)層（IP 協(xié)議），增加作為通信目的地的 MAC 地址后轉(zhuǎn)發(fā)給鏈 路層。這樣一來，發(fā)往網(wǎng)絡(luò)的通信請(qǐng)求就準(zhǔn)備齊全了。 接收端的服務(wù)器在鏈路層接收到數(shù)據(jù)，按序往上層發(fā)送，一直到應(yīng)用 層。當(dāng)傳輸?shù)綉?yīng)用層，才能算真正接收到由客戶端發(fā)送過來的 HTTP 請(qǐng)求。

這種把數(shù)據(jù)信息包裝起來的做法稱為封裝（encapsulate）。

：這就是將數(shù)據(jù)封裝起來了，然后交到服務(wù)器的時(shí)候被層層剝開

可能有人會(huì)把“IP”和“IP 地址”搞混，“IP”其實(shí)是一種協(xié)議的名稱。

：ip協(xié)議地址的作用是將數(shù)據(jù)發(fā)送到目標(biāo)處，且確實(shí)發(fā)到那里，依仗的條件是IP 地址和 MAC 地址（Media Access Control Address）。

IP 地址指明了節(jié)點(diǎn)被分配到的地址，MAC 地址是指網(wǎng)卡所屬的固定 地址。IP 地址可以和 MAC 地址進(jìn)行配對(duì)。IP 地址可變換，但 MAC 地址基本上不會(huì)更改

：在進(jìn)行通信的時(shí)候，可能會(huì)經(jīng)過多臺(tái)電腦才能中轉(zhuǎn)到指定位置，中轉(zhuǎn)電腦會(huì)采用arp來進(jìn)行搜索

ARP 是一種用以解析地址的協(xié)議，根據(jù)通信方 的 IP 地址就可以反查出對(duì)應(yīng)的 MAC 地址。

三次握手

數(shù)據(jù)分割成幾段，采用字節(jié)流服務(wù)（Byte Stream Service）

用 TCP 協(xié)議把數(shù)據(jù)包送出去后，TCP 不會(huì)對(duì)傳送后的情況置之不理，它一定會(huì)向?qū)Ψ酱_認(rèn)是否成功送達(dá)。 21握手過程中使用了 TCP 的標(biāo)志（flag） —— SYN（synchronize） 和 ACK（acknowledgement）。 發(fā)送端首先發(fā)送一個(gè)帶 SYN 標(biāo)志的數(shù)據(jù)包給對(duì)方。接收端收到后， 回傳一個(gè)帶有 SYN/ACK 標(biāo)志的數(shù)據(jù)包以示傳達(dá)確認(rèn)信息。最后，發(fā) 送端再回傳一個(gè)帶 ACK 標(biāo)志的數(shù)據(jù)包，代表“握手”結(jié)束。 若在握手過程中某個(gè)階段莫名中斷，TCP 協(xié)議會(huì)再次以相同的順序發(fā) 送相同的數(shù)據(jù)包。

這樣使數(shù)據(jù)變得可靠

get，post等http方法：

GET ：獲取資源 GET 方法用來請(qǐng)求訪問已被 URI 識(shí)別的資源。指定的資源經(jīng)服務(wù)器 端解析后返回響應(yīng)內(nèi)容。也就是說，如果請(qǐng)求的資源是文本，那就保 持原樣返回；如果是像 CGI（Common Gateway Interface，通用網(wǎng)關(guān)接 口）那樣的程序，則返回經(jīng)過執(zhí)行后的輸出結(jié)果。 使用 GET 方法的請(qǐng)求·響應(yīng)的例子請(qǐng)求 GET /index.html HTTP/1.1 Host: www.hackr.jp 響應(yīng) 返回 index.html 的頁面資源 請(qǐng)求 GET /index.html HTTP/1.1 Host: www.hackr.jp If-Modified-Since: Thu, 12 Jul 2012 07:30:00 GMT 響應(yīng) 僅返回2012年7 月12日7 點(diǎn)30分以后更新過的index.html頁面資源。如果未 有內(nèi)容更新，則以狀態(tài)碼304 Not Modified作為響應(yīng)返回 POST：傳輸實(shí)體主體 POST 方法用來傳輸實(shí)體的主體。 雖然用 GET 方法也可以傳輸實(shí)體的主體，但一般不用 GET 方法進(jìn)行 傳輸，而是用 POST 方法。雖說 POST 的功能與 GET 很相似，但 POST 的主要目的并不是獲取響應(yīng)的主體內(nèi)容。 使用 POST 方法的請(qǐng)求·響應(yīng)的例子 請(qǐng)求 POST /submit.cgi HTTP/1.1 Host: www.hackr.jp Content-Length: 1560（1560字節(jié)的數(shù)據(jù)） 響應(yīng) 返回 submit.cgi 接收數(shù)據(jù)的處理結(jié)果?

PUT：傳輸文件 PUT 方法用來傳輸文件。就像 FTP 協(xié)議的文件上傳一樣，要求在請(qǐng) 求報(bào)文的主體中包含文件內(nèi)容，然后保存到請(qǐng)求 URI 指定的位置。 36但是，鑒于 HTTP/1.1 的 PUT 方法自身不帶驗(yàn)證機(jī)制，任何人都可以 上傳文件 , 存在安全性問題，因此一般的 Web 網(wǎng)站不使用該方法。若 配合 Web 應(yīng)用程序的驗(yàn)證機(jī)制，或架構(gòu)設(shè)計(jì)采用 REST（REpresentational State Transfer，表征狀態(tài)轉(zhuǎn)移）標(biāo)準(zhǔn)的同類 Web 網(wǎng)站，就可能會(huì)開放使用 PUT 方法。 使用 PUT 方法的請(qǐng)求·響應(yīng)的例子 請(qǐng)求 PUT /example.html HTTP/1.1 Host: www.hackr.jp Content-Type: text/html Content-Length: 1560（1560 字節(jié)的數(shù)據(jù)） 響應(yīng)1 響應(yīng)返回狀態(tài)碼 204 No Content（比如 ：該 html 已存在于服務(wù)器上） 1 響應(yīng)的意思其實(shí)是請(qǐng)求執(zhí)行成功了，但無數(shù)據(jù)返回?！g者注?

HEAD：獲得報(bào)文首部 HEAD 方法和 GET 方法一樣，只是不返回報(bào)文主體部分。用于確認(rèn) URI 的有效性及資源更新的日期時(shí)間等。 圖：和 GET 一樣，但不返回報(bào)文主體 37使用 HEAD 方法的請(qǐng)求·響應(yīng)的例子 請(qǐng)求 HEAD /index.html HTTP/1.1 Host: www.hackr.jp 響應(yīng) 返回index.html有關(guān)的響應(yīng)首部?

DELETE：刪除文件 DELETE 方法用來刪除文件，是與 PUT 相反的方法。DELETE 方法按 請(qǐng)求 URI 刪除指定的資源。 但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一樣不帶驗(yàn)證機(jī) 制，所以一般的 Web 網(wǎng)站也不使用 DELETE 方法。當(dāng)配合 Web 應(yīng)用 程序的驗(yàn)證機(jī)制，或遵守 REST 標(biāo)準(zhǔn)時(shí)還是有可能會(huì)開放使用的。 使用 DELETE 方法的請(qǐng)求·響應(yīng)的例子 請(qǐng)求 DELETE /example.html HTTP/1.1 Host: www.hackr.jp 響應(yīng) 響應(yīng)返回狀態(tài)碼 204 No Content（比如 ：該 html 已從該服務(wù)器上刪除）?

OPTIONS：詢問支持的方法 OPTIONS 方法用來查詢針對(duì)請(qǐng)求 URI 指定的資源支持的方法。 38使用 OPTIONS 方法的請(qǐng)求·響應(yīng)的例子 請(qǐng)求 OPTIONS * HTTP/1.1 Host: www.hackr.jp 響應(yīng) HTTP/1.1 200 OK Allow: GET, POST, HEAD, OPTIONS （返回服務(wù)器支持的方法）

TRACE：追蹤路徑 TRACE 方法是讓 Web 服務(wù)器端將之前的請(qǐng)求通信環(huán)回給客戶端的方 法。發(fā)送請(qǐng)求時(shí)，在 Max-Forwards 首部字段中填入數(shù)值，每經(jīng)過一個(gè)服 務(wù)器端就將該數(shù)字減 1，當(dāng)數(shù)值剛好減到 0 時(shí)，就停止繼續(xù)傳輸，最 后接收到請(qǐng)求的服務(wù)器端則返回狀態(tài)碼 200 OK 的響應(yīng)。 客戶端通過 TRACE 方法可以查詢發(fā)送出去的請(qǐng)求是怎樣被加工修改 / 篡改的。這是因?yàn)?，?qǐng)求想要連接到源目標(biāo)服務(wù)器可能會(huì)通過代理 中轉(zhuǎn)，TRACE 方法就是用來確認(rèn)連接過程中發(fā)生的一系列操作。 但是，TRACE 方法本來就不怎么常用，再加上它容易引發(fā) XST（Cross-Site Tracing，跨站追蹤）攻擊，通常就更不會(huì)用到了。 使用 TRACE 方法的請(qǐng)求·響應(yīng)的例子 請(qǐng)求 TRACE / HTTP/1.1 Host: hackr.jp Max-Forwards: 2 HTTP/1.1 200 OK Content-Type: message/http 39響應(yīng) Content-Length: 1024 TRACE / HTTP/1.1 Host: hackr.jp Max-Forwards: 2（返回響應(yīng)包含請(qǐng)求內(nèi)容）?

CONNECT：要求用隧道協(xié)議連接代理 CONNECT 方法要求在與代理服務(wù)器通信時(shí)建立隧道，實(shí)現(xiàn)用隧道協(xié) 議進(jìn)行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接 層）和 TLS（Transport Layer Security，傳輸層安全）協(xié)議把通信內(nèi)容 加 密后經(jīng)網(wǎng)絡(luò)隧道傳輸。 CONNECT 方法的格式如下所示。 CONNECT 代理服務(wù)器名:端口號(hào) HTTP版本 使用 CONNECT 方法的請(qǐng)求·響應(yīng)的例子 請(qǐng)求 CONNECT proxy.hackr.jp:8080 HTTP/1.1 Host: proxy.hackr.jp 響應(yīng) HTTP/1.1 200 OK（之后進(jìn)入網(wǎng)絡(luò)隧道）

：以上了解即可

：在客戶端與服務(wù)器相互通信的過程中，初始的鏈接是每次傳輸通信都需要進(jìn)行tcp的斷開，相當(dāng)花費(fèi)資源，后面才有了持久鏈接

持久連接的特點(diǎn)是，只要任意一端 沒有明確提出斷開連接，則保持 TCP 連接狀態(tài)

cookie:

Cookie 技術(shù)通過在請(qǐng)求和響應(yīng)報(bào)文中寫入 Cookie 信 息來控制客戶端的狀態(tài)。 Cookie 會(huì)根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報(bào)文內(nèi)的一個(gè)叫做 Set-Cookie 的 首部字段信息，通知客戶端保存 Cookie。當(dāng)下次客戶端再往該服務(wù)器 發(fā)送請(qǐng)求時(shí)，客戶端會(huì)自動(dòng)在請(qǐng)求報(bào)文中加入 Cookie 值后發(fā)送出 去。服務(wù)器端發(fā)現(xiàn)客戶端發(fā)送過來的 Cookie 后，會(huì)去檢查究竟是從哪一 個(gè)客戶端發(fā)來的連接請(qǐng)求，然后對(duì)比服務(wù)器上的記錄，最后得到之前 的狀態(tài)信息。

產(chǎn)生的信息：

1. 請(qǐng)求報(bào)文（沒有 Cookie 信息的狀態(tài)） GET /reader/ HTTP/1.1 Host: hackr.jp *首部字段內(nèi)沒有Cookie的相關(guān)信息

2. 響應(yīng)報(bào)文（服務(wù)器端生成 Cookie 信息） HTTP/1.1 200 OK Date: Thu, 12 Jul 2012 07:12:20 GMT Server: Apache ＜Set-Cookie: sid=1342077140226724; path=/; expires=Wed, 10-Oct-12 07:12:20 GMT＞ Content-Type: text/plain; charset=UTF-8

3. 請(qǐng)求報(bào)文（自動(dòng)發(fā)送保存著的 Cookie 信息） GET /image/ HTTP/1.1 Host: hackr.jp Cookie: sid=1342077140226724

第三章

報(bào)文的結(jié)構(gòu)

常用的內(nèi)容編碼有以下幾種。 gzip（GNU zip） compress（UNIX 系統(tǒng)的標(biāo)準(zhǔn)壓縮） deflate（zlib） identity（不進(jìn)行編碼）

分塊傳輸編碼會(huì)將實(shí)體主體分成多個(gè)部分（塊）。每一塊都會(huì)用十六 進(jìn)制來標(biāo)記塊的大小，而實(shí)體主體的最后一塊會(huì)使用“0(CR+LF)”來標(biāo) 記。使用分塊傳輸編碼的實(shí)體主體會(huì)由接收的客戶端負(fù)責(zé)解碼，恢復(fù)到編 碼前的實(shí)體主體。 HTTP/1.1 中存在一種稱為傳輸編碼（Transfer Coding）的機(jī)制，它可 以在通信時(shí)按某種編碼方式傳輸，但只定義作用于分塊傳輸編碼中

透明代理 轉(zhuǎn)發(fā)請(qǐng)求或響應(yīng)時(shí)，不對(duì)報(bào)文做任何加工的代理類型被稱為透明代理 （Transparent Proxy）。反之，對(duì)報(bào)文內(nèi)容進(jìn)行加工的代理被稱為非 透明代理。?

利用網(wǎng)關(guān)可以由 HTTP 請(qǐng)求轉(zhuǎn)化為其他協(xié)議通信

隧道本身不會(huì)去解析 HTTP 請(qǐng)求。也就是說，請(qǐng)求保持原樣中轉(zhuǎn)給之 后的服務(wù)器。隧道會(huì)在通信雙方斷開連接時(shí)結(jié)束。通過隧道的傳輸，可以和遠(yuǎn)距離的服務(wù)器安全通信。隧道本 身是透明的，客戶端不用在意隧道的存在?

緩存在一些領(lǐng)域都很常見的用到，具體一些操作中的細(xì)節(jié)，比如驗(yàn)證有效性，是否已經(jīng)緩存可以在查資料了解其中到底呢么實(shí)現(xiàn)的

一些協(xié)議：

在 HTTP 出現(xiàn)之前的協(xié)議 在 HTTP 普及之前，也就是從互聯(lián)網(wǎng)的誕生期至今，曾出現(xiàn)過各式 各樣的協(xié)議。在 HTTP 規(guī)范確立之際，制定者們參考了那些協(xié)議的 功能。也有某些協(xié)議現(xiàn)在已經(jīng)徹底退出了人們的視線。接下來，我 們會(huì)簡(jiǎn)單介紹一下這些協(xié)議。 FTP（File Transfer Protocol） 傳輸文件時(shí)使用的協(xié)議。該協(xié)議歷史久遠(yuǎn)，可追溯到 1973 年前 后，比 TCP/IP 協(xié)議族的出現(xiàn)還要早。雖然它在 1995 年被 HTTP 的 流量（Traffic）超越，但時(shí)至今日，仍被廣泛沿用。 NNTP（Network News Transfer Protocol） 用于 NetNews 電子會(huì)議室內(nèi)傳送消息的協(xié)議。在 1986 年前后出 現(xiàn)，屬于比較古老的一類協(xié)議?，F(xiàn)在，利用 Web 交換信息已成主 流，所以該協(xié)議已經(jīng)不怎么使用了。 Archie 搜索 anonymous FTP 公開的文件信息的協(xié)議。1990 年前后出現(xiàn)，現(xiàn) 在已經(jīng)不常使用。 WAIS（Wide Area Information Servers） 以關(guān)鍵詞檢索多個(gè)數(shù)據(jù)庫使用的協(xié)議。1991 年前后出現(xiàn)。由于現(xiàn) 在已經(jīng)被 HTTP 協(xié)議替代，也已經(jīng)不怎么使用了。 Gopher 查找與互聯(lián)網(wǎng)連接的計(jì)算機(jī)內(nèi)信息的協(xié)議。1991 年前后出現(xiàn)，由 于現(xiàn)在已經(jīng)被 HTTP 協(xié)議替代，也已經(jīng)不怎么使用了。

從字面意思上很容易把 no-cache 誤解成為不緩存，但事實(shí)上 no-cache 代表不緩 存過期的資源，緩存會(huì)向源服務(wù)器進(jìn)行有效期確認(rèn)后處理資源，也許稱為 do-not- serve-from-cache-without-revalidation 更合適。no-store 才是真正地不進(jìn)行緩存，請(qǐng) 讀者注意區(qū)別理解。

HTTP/1.1 版本的默認(rèn)連接都是持久連接。為此，客戶端會(huì)在持 久連接上連續(xù)發(fā)送請(qǐng)求。當(dāng)服務(wù)器端想明確斷開連接時(shí)，則指定 Connection 首部字段的值為 Close。

警告碼：

警告碼 警告內(nèi)容 說明 110 Response is stale（響應(yīng)已過期） 代理返回已過期的資源 111 Revalidation failed（再驗(yàn)證失?。?代理再驗(yàn)證資源有效性時(shí)失?。ǚ?wù) 器無法到達(dá)等原因） 112 Disconnection operation（斷開連接操 作） 代理與互聯(lián)網(wǎng)連接被故意切斷 113 Heuristic expiration（試探性過期） 響應(yīng)的使用期超過24小時(shí)（有效緩存 的設(shè)定時(shí)間大于24小時(shí)的情況下） 199 Miscellaneous warning（雜項(xiàng)警告） 任意的警告內(nèi)容 214 Transformation applied（使用了轉(zhuǎn)換） 代理對(duì)內(nèi)容編碼或媒體類型等執(zhí)行了 某些處理時(shí) 299 Miscellaneous persistent warning（持久 雜項(xiàng)警告） 任意的警告內(nèi)容

Accept-Encoding: gzip, deflate Accept-Encoding 首部字段用來告知服務(wù)器用戶代理支持的內(nèi)容編碼及 內(nèi)容編碼的優(yōu)先級(jí)順序?？梢淮涡灾付ǘ喾N內(nèi)容編碼。 101下面試舉出幾個(gè)內(nèi)容編碼的例子。 gzip 由文件壓縮程序 gzip（GNU zip）生成的編碼格式 （RFC1952），采用 Lempel-Ziv 算法（LZ77）及 32 位循環(huán)冗余 校驗(yàn)（Cyclic Redundancy Check，通稱 CRC）。 compress 由 UNIX 文件壓縮程序 compress 生成的編碼格式，采用 Lempel- Ziv-Welch 算法（LZW）。 deflate 組合使用 zlib 格式（RFC1950）及由 deflate 壓縮算法 （RFC1951）生成的編碼格式。 identity 不執(zhí)行壓縮或不會(huì)變化的默認(rèn)編碼格式 采用權(quán)重 q 值來表示相對(duì)優(yōu)先級(jí)，這點(diǎn)與首部字段 Accept 相同。另 外，也可使用星號(hào)（*）作為通配符，指定任意的編碼格式。?

強(qiáng) ETag 值和弱 Tag 值 ETag 中有強(qiáng) ETag 值和弱 ETag 值之分。 強(qiáng) ETag 值 強(qiáng) ETag 值，不論實(shí)體發(fā)生多么細(xì)微的變化都會(huì)改變其值。 ETag: "usagi-1234" 弱 ETag 值 弱 ETag 值只用于提示資源是否相同。只有資源發(fā)生了根本改變，產(chǎn) 生差異時(shí)才會(huì)改變 ETag 值。這時(shí)，會(huì)在字段值最開始處附加 W/。 ETag: W/"usagi-1234"

這些子段太多了，大致了解一下，然后有用到的時(shí)候再查吧

HTTPS加密問題：

好好理解想想

證書有：EV SSL 證書 ，客戶端證書等

關(guān)于認(rèn)證：

如果使用 OpenSSL這套開源程序，每個(gè)人都可以構(gòu)建一套屬于 自己的認(rèn)證機(jī)構(gòu)，從而自己給自己頒發(fā)服務(wù)器證書。但該服務(wù)器 證書在互聯(lián)網(wǎng)上不可作為證書使用，似乎沒什么幫助。 獨(dú)立構(gòu)建的認(rèn)證機(jī)構(gòu)叫做自認(rèn)證機(jī)構(gòu)，由自認(rèn)證機(jī)構(gòu)頒發(fā)的“無 用”證書也被戲稱為自簽名證書。由自認(rèn)證機(jī)構(gòu)頒發(fā)的證書稱為自簽名證書 ，會(huì)涉及安全問題，瀏覽器不讓訪問，由自認(rèn)證機(jī)構(gòu)頒發(fā)的服務(wù)器證書之所以不起作用，是因?yàn)樗鼰o法 消除偽裝的可能性。

https是如何安全通信的呢：

步驟 1： 客戶端通過發(fā)送 Client Hello 報(bào)文開始 SSL通信。報(bào)文中包 含客戶端支持的 SSL的指定版本、加密組件（Cipher Suite）列表（所 使用的加密算法及密鑰長(zhǎng)度等）。?

步驟 2： 服務(wù)器可進(jìn)行 SSL通信時(shí)，會(huì)以 Server Hello 報(bào)文作為應(yīng)答。和客戶端一樣，在報(bào)文中包含 SSL版本以及加密組件。服務(wù)器的 加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來的。?

步驟 3： 之后服務(wù)器發(fā)送 Certificate 報(bào)文。報(bào)文中包含公開密鑰證 書。

步驟 4： 最后服務(wù)器發(fā)送 Server Hello Done 報(bào)文通知客戶端，最初階 段的 SSL握手協(xié)商部分結(jié)束。?

步驟 5： SSL第一次握手結(jié)束之后，客戶端以 Client Key Exchange 報(bào) 文作為回應(yīng)。報(bào)文中包含通信加密中使用的一種被稱為 Pre-master secret 的隨機(jī)密碼串。該報(bào)文已用步驟 3 中的公開密鑰進(jìn)行加密。?

步驟 6： 接著客戶端繼續(xù)發(fā)送 Change Cipher Spec 報(bào)文。該報(bào)文會(huì)提 示服務(wù)器，在此報(bào)文之后的通信會(huì)采用 Pre-master secret 密鑰加密。 （因?yàn)榈谝淮挝帐趾?，發(fā)送的key已經(jīng)使用pre-master-secret加密了）

步驟 7： 客戶端發(fā)送 Finished 報(bào)文。該報(bào)文包含連接至今全部報(bào)文的 整體校驗(yàn)值。這次握手協(xié)商是否能夠成功，要以服務(wù)器是否能夠正確 解密該報(bào)文作為判定標(biāo)準(zhǔn)。?

步驟 8： 服務(wù)器同樣發(fā)送 Change Cipher Spec 報(bào)文。?

步驟 9： 服務(wù)器同樣發(fā)送 Finished 報(bào)文。?

步驟 10： 服務(wù)器和客戶端的 Finished 報(bào)文交換完畢之后，SSL連接 就算建立完成。當(dāng)然，通信會(huì)受到 SSL的保護(hù)。從此處開始進(jìn)行應(yīng)用 層協(xié)議的通信，即發(fā)送 HTTP 請(qǐng)求。?

步驟 11： 應(yīng)用層協(xié)議通信，即發(fā)送 HTTP 響應(yīng)。?

步驟 12： 最后由客戶端斷開連接。斷開連接時(shí)，發(fā)送 close_notify 報(bào) 文。上圖做了一些省略，這步之后再發(fā)送 TCP FIN 報(bào)文來關(guān)閉與 TCP 的通信。 在以上流程中，應(yīng)用層發(fā)送數(shù)據(jù)時(shí)會(huì)附加一種叫做 MAC（Message Authentication Code）的報(bào)文摘要。MAC 能夠查知報(bào)文是否遭到篡 改，從而保護(hù)報(bào)文的完整性。

要進(jìn)行 HTTPS 通信，證書是必不可少的。而使用的證書必須向認(rèn) 證機(jī)構(gòu)（CA）購(gòu)買。證書價(jià)格可能會(huì)根據(jù)不同的認(rèn)證機(jī)構(gòu)略有不 同。通常，一年的授權(quán)需要數(shù)萬日元（現(xiàn)在一萬日元大約折合 600 人民幣）。

、

認(rèn)證：

HTTP/1.1 使用的認(rèn)證方式如下所示。?

BASIC 認(rèn)證（基本認(rèn)證） DIGEST 認(rèn)證（摘要認(rèn)證） SSL 客戶端認(rèn)證 FormBase 認(rèn)證（基于表單認(rèn)證） 此外，還有 Windows 統(tǒng)一認(rèn)證（Keberos 認(rèn)證、NTLM 認(rèn)證）

下面介紹認(rèn)證：

步驟 1： 當(dāng)請(qǐng)求的資源需要 BASIC 認(rèn)證時(shí)，服務(wù)器會(huì)隨狀態(tài)碼 401 Authorization Required，返回帶 WWW-Authenticate 首部字段的響應(yīng)。 該字段內(nèi)包含認(rèn)證的方式（BASIC） 及 Request-URI 安全域字符串 （realm）。?

步驟 2： 接收到狀態(tài)碼 401 的客戶端為了通過 BASIC 認(rèn)證，需要將 用戶 ID 及密碼發(fā)送給服務(wù)器。發(fā)送的字符串內(nèi)容是由用戶 ID 和密碼 構(gòu)成，兩者中間以冒號(hào)（:）連接后，再經(jīng)過 Base64 編碼處理。 假設(shè)用戶 ID 為 guest，密碼是 guest，連接起來就會(huì)形成 guest:guest 這 樣的字符串。然后經(jīng)過 Base64 編碼，最后的結(jié)果即是 Z3Vlc3Q6Z3Vlc3Q=。把這串字符串寫入首部字段 Authorization 后， 發(fā)送請(qǐng)求。 當(dāng)用戶代理為瀏覽器時(shí)，用戶僅需輸入用戶 ID 和密碼即可，之后， 瀏覽器會(huì)自動(dòng)完成到 Base64 編碼的轉(zhuǎn)換工作。?

步驟 3： 接收到包含首部字段 Authorization 請(qǐng)求的服務(wù)器，會(huì)對(duì)認(rèn)證 信息的正確性進(jìn)行驗(yàn)證。如驗(yàn)證通過，則返回一條包含 Request-URI 資源的響應(yīng)。 BASIC 認(rèn)證雖然采用 Base64 編碼方式，但這不是加密處理。不需要 任何附加信息即可對(duì)其解碼。換言之，由于明文解碼后就是用戶 ID 和密碼，在 HTTP 等非加密通信的線路上進(jìn)行 BASIC 認(rèn)證的過程 中，如果被人竊聽，被盜的可能性極高。 另外，除此之外想再進(jìn)行一次 BASIC 認(rèn)證時(shí)，一般的瀏覽器卻無法 實(shí)現(xiàn)認(rèn)證注銷操作，這也是問題之一。 BASIC 認(rèn)證使用上不夠便捷靈活，且達(dá)不到多數(shù) Web 網(wǎng)站期望的安 全性等級(jí)，因此它并不常用。

：這種情況其實(shí)在下載的時(shí)候我們可能會(huì)遇到，就像你用迅雷下載一個(gè)文件彈出站點(diǎn)的認(rèn)證消息，需要輸入賬號(hào)密碼，或者在git或者gitee 下載或者clone文件的時(shí)候

DIGEST 認(rèn)證

所謂質(zhì)詢響應(yīng)方式是指，一開始一方會(huì)先發(fā)送認(rèn)證要求給另一方，接 著使用從另一方那接收到的質(zhì)詢碼計(jì)算生成響應(yīng)碼。最后將響應(yīng)碼返 回給對(duì)方進(jìn)行認(rèn)證的方式

步驟 1： 請(qǐng)求需認(rèn)證的資源時(shí)，服務(wù)器會(huì)隨著狀態(tài)碼 401 Authorization Required，返 回帶 WWW-Authenticate 首部字段的響應(yīng)。 該字段內(nèi)包含質(zhì)問響應(yīng)方式認(rèn)證所需的臨時(shí)質(zhì)詢碼（隨機(jī)數(shù)， nonce）首部字段 WWW-Authenticate 內(nèi)必須包含 realm 和 nonce 這兩個(gè)字段的 信息。客戶端就是依靠向服務(wù)器回送這兩個(gè)值進(jìn)行認(rèn)證的。 nonce 是一種每次隨返回的 401 響應(yīng)生成的任意隨機(jī)字符串。該字符 串通常推薦由 Base64 編碼的十六進(jìn)制數(shù)的組成形式，但實(shí)際內(nèi)容依 賴服務(wù)器的具體實(shí)現(xiàn)。?

步驟 2： 接收到 401 狀態(tài)碼的客戶端，返回的響應(yīng)中包含 DIGEST 認(rèn) 證必須的首部字段 Authorization 信息。 首部字段 Authorization 內(nèi)必須包含 username、realm、nonce、uri 和 response 的字段信息。其中，realm 和 nonce 就是之前從服務(wù)器接收到 的響應(yīng)中的字段。 username 是 realm 限定范圍內(nèi)可進(jìn)行認(rèn)證的用戶名。 uri（digest-uri）即 Request-URI 的值，但考慮到經(jīng)代理轉(zhuǎn)發(fā)后 Request-URI 的值可能被修改，因此事先會(huì)復(fù)制一份副本保存在 uri 內(nèi)。response 也可叫做 Request-Digest，存放經(jīng)過 MD5 運(yùn)算后的密碼字符 串，形成響應(yīng)碼。 響應(yīng)中其他的實(shí)體請(qǐng)參見第 6 章的請(qǐng)求首部字段 Authorization。另 外，有關(guān) Request-Digest 的計(jì)算規(guī)則較復(fù)雜，有興趣的讀者不妨深入 學(xué)習(xí)一下 RFC2617。?

步驟 3： 接收到包含首部字段 Authorization 請(qǐng)求的服務(wù)器，會(huì)確認(rèn)認(rèn) 證信息的正確性。認(rèn)證通過后則返回包含 Request-URI 資源的響應(yīng)。 并且這時(shí)會(huì)在首部字段 Authentication-Info 寫入一些認(rèn)證成功的相關(guān)信 息。DIGEST 認(rèn)證提供了高于 BASIC 認(rèn)證的安全等級(jí)，但是和 HTTPS 的 客戶端認(rèn)證相比仍舊很弱。DIGEST 認(rèn)證提供防止密碼被竊聽的保護(hù) 機(jī)制，但并不存在防止用戶偽裝的保護(hù)機(jī)制。 DIGEST 認(rèn)證和 BASIC 認(rèn)證一樣，使用上不那么便捷靈活，且仍達(dá)不 到多數(shù) Web 網(wǎng)站對(duì)高度安全等級(jí)的追求標(biāo)準(zhǔn)。因此它的適用范圍也 有所受限。

SSL 客戶端認(rèn)證的認(rèn)證步驟?

為達(dá)到 SSL客戶端認(rèn)證的目的，需要事先將客戶端證書分發(fā)給客戶 端，且客戶端必須安裝此證書。 步驟 1： 接收到需要認(rèn)證資源的請(qǐng)求，服務(wù)器會(huì)發(fā)送 Certificate Request 報(bào)文，要求客戶端提供客戶端證書。?

步驟 2： 用戶選擇將發(fā)送的客戶端證書后，客戶端會(huì)把客戶端證書信 息以 Client Certificate 報(bào)文方式發(fā)送給服務(wù)器。?

?步驟 3： 服務(wù)器驗(yàn)證客戶端證書驗(yàn)證通過后方可領(lǐng)取證書內(nèi)客戶端的 165公開密鑰，然后開始 HTTPS 加密通信。

但是：

在多數(shù)情況下，SSL客戶端認(rèn)證不會(huì)僅依靠證書完成認(rèn)證，一般會(huì)和 基于表單認(rèn)證（稍后講解）組合形成一種雙因素認(rèn)證（Two-factor authentication）來使用。所謂雙因素認(rèn)證就是指，認(rèn)證過程中不僅需 要密碼這一個(gè)因素，還需要申請(qǐng)認(rèn)證者提供其他持有信息，從而作為 另一個(gè)因素，與其組合使用的認(rèn)證方式。 換言之，第一個(gè)認(rèn)證因素的 SSL客戶端證書用來認(rèn)證客戶端計(jì)算機(jī)， 另一個(gè)認(rèn)證因素的密碼則用來確定這是用戶本人的行為。 通過雙因素認(rèn)證后，就可以確認(rèn)是用戶本人正在使用匹配正確的計(jì)算 機(jī)訪問服務(wù)器。而且證書一般還是收費(fèi)的。

基于表單認(rèn)證

由于使用上的便利性及安全性問題，HTTP 協(xié)議標(biāo)準(zhǔn)提供的 BASIC 認(rèn) 證和 DIGEST 認(rèn)證幾乎不怎么使用。另外，SSL客戶端認(rèn)證雖然具有 高度的安全等級(jí)，但因?yàn)閷?dǎo)入及維持費(fèi)用等問題，還尚未普及。

步驟 1： 客戶端把用戶 ID 和密碼等登錄信息放入報(bào)文的實(shí)體部分， 通常是以 POST 方法把請(qǐng)求發(fā)送給服務(wù)器。而這時(shí)，會(huì)使用 HTTPS 通信來進(jìn)行 HTML表單畫面的顯示和用戶輸入數(shù)據(jù)的發(fā)送。?

步驟 2： 服務(wù)器會(huì)發(fā)放用以識(shí)別用戶的 Session ID。通過驗(yàn)證從客戶 端發(fā)送過來的登錄信息進(jìn)行身份認(rèn)證，然后把用戶的認(rèn)證狀態(tài)與 Session ID 綁定后記錄在服務(wù)器端。 向客戶端返回響應(yīng)時(shí)，會(huì)在首部字段 Set-Cookie 內(nèi)寫入 Session ID（如 PHPSESSID=028a8c…）。 你可以把 Session ID 想象成一種用以區(qū)分不同用戶的等位號(hào)。然而，如果 Session ID 被第三方盜走，對(duì)方就可以偽裝成你的身份進(jìn) 行惡意操作了。因此必須防止 Session ID 被盜，或被猜出。為了做到 這點(diǎn)，Session ID 應(yīng)使用難以推測(cè)的字符串，且服務(wù)器端也需要進(jìn)行 有效期的管理，保證其安全性。 另外，為減輕跨站腳本攻擊（XSS）造成的損失，建議事先在 Cookie 內(nèi)加上 httponly 屬性。?

步驟 3： 客戶端接收到從服務(wù)器端發(fā)來的 Session ID 后，會(huì)將其作為 Cookie 保存在本地。下次向服務(wù)器發(fā)送請(qǐng)求時(shí)，瀏覽器會(huì)自動(dòng)發(fā)送 Cookie，所以 Session ID 也隨之發(fā)送到服務(wù)器。服務(wù)器端可通過驗(yàn)證 接收到的 Session ID 識(shí)別用戶和其認(rèn)證狀態(tài)。

spdy設(shè)計(jì)模式:

使用 SPDY 后，HTTP 協(xié)議額外獲得以下功能。 多路復(fù)用流 通過單一的 TCP 連接，可以無限制處理多個(gè) HTTP 請(qǐng)求。所有請(qǐng)求 的處理都在一條 TCP 連接上完成，因此 TCP 的處理效率得到提高。 賦予請(qǐng)求優(yōu)先級(jí) SPDY 不僅可以無限制地并發(fā)處理請(qǐng)求，還可以給請(qǐng)求逐個(gè)分配優(yōu)先 級(jí)順序。這樣主要是為了在發(fā)送多個(gè)請(qǐng)求時(shí)，解決因帶寬低而導(dǎo)致響 應(yīng)變慢的問題。 壓縮 HTTP 首部 壓縮 HTTP 請(qǐng)求和響應(yīng)的首部。這樣一來，通信產(chǎn)生的數(shù)據(jù)包數(shù)量和 發(fā)送的字節(jié)數(shù)就更少了。 推送功能 支持服務(wù)器主動(dòng)向客戶端推送數(shù)據(jù)的功能。這樣，服務(wù)器可直接發(fā)送 數(shù)據(jù)，而不必等待客戶端的請(qǐng)求。 服務(wù)器提示功能 服務(wù)器可以主動(dòng)提示客戶端請(qǐng)求所需的資源。由于在客戶端發(fā)現(xiàn)資源 之前就可以獲知資源的存在，因此在資源已緩存等情況下，可以避免 發(fā)送不必要的請(qǐng)求

webscock之后：

WebDAV 內(nèi)新增的方法及狀態(tài)碼 WebDAV 為實(shí)現(xiàn)遠(yuǎn)程文件管理，向 HTTP/1.1 中追加了以下這些方 法。

PROPFIND ：獲取屬性?

PROPPATCH ：修改屬性?

MKCOL ：創(chuàng)建集合

COPY ：復(fù)制資源及屬性

MOVE ：移動(dòng)資源?

LOCK ：資源加鎖

UNLOCK ：資源解鎖 為配合擴(kuò)展的方法，狀態(tài)碼也隨之?dāng)U展。

102 Processing ：可正常處理請(qǐng)求，但目前是處理中狀態(tài)

207 Multi-Status ：存在多種狀態(tài)?

422 Unprocessible Entity ：格式正確，內(nèi)容有誤?

423 Locked ：資源已被加鎖?

424 Failed Dependency ：處理與某請(qǐng)求關(guān)聯(lián)的請(qǐng)求失敗，因此不再維持依賴關(guān)系

507 Insufficient Storage ：保存空間不足

html:

DOM 是用以操作 HTML文檔和 XML文檔的 API（Application Programming Interface，應(yīng)用編程接口）。使用 DOM 可以將 HTML內(nèi) 的元素當(dāng)作對(duì)象操作，如取出元素內(nèi)的字符串、改變那個(gè) CSS 的屬 性等，使頁面的設(shè)計(jì)發(fā)生改變。

CGI（Common Gateway Interface，通用網(wǎng)關(guān)接口）是指 Web 服務(wù)器在 接收到客戶端發(fā)送過來的請(qǐng)求后轉(zhuǎn)發(fā)給程序的一組機(jī)制。