HTTP協(xié)議

在 OSI 七層模型中，HTTP協(xié)議位于最頂層的應(yīng)用層中。通過瀏覽器訪問網(wǎng)頁就直接使用了 HTTP 協(xié)議。使用 HTTP 協(xié)議時，客戶端首先與服務(wù)端的 80 端口建立一個 TCP 連接，然后在這個連接的基礎(chǔ)上進行請求和應(yīng)答，以及數(shù)據(jù)的交換。

HTTP 有兩個常用版本，分別是 1.0 和 1.1。主要區(qū)別在于 HTTP 1.0 中每次請求和應(yīng)答都會使用一個新的 TCP 連接，而從 HTTP 1.1 開始，運行在一個 TCP 連接上發(fā)送多個命令和應(yīng)答。因此大幅度減少了 TCP 連接的建立和斷開，提高了效率。

常用的HTTP方法有哪些？

GET：用于請求訪問已經(jīng)被URL（統(tǒng)一資源標(biāo)識符）識別的資源，可以通過URL傳參給服務(wù)器。

POST：用于傳輸信息給服務(wù)器，主要功能與Get方法類似，但一般推薦POST方式。

PUT：傳輸文件，報文主體包含文件內(nèi)容，保存到對應(yīng)URL位置。

HEAD：獲取報文首部，與GET方法類似，只是不返回報文主體，一般用于驗證URL是否有效。

DELET：刪除文件，與PUT方法相反，刪除對應(yīng)URL位置的文件。

OPTIONS：查詢相應(yīng)URL支持的HTTP方法。

get和post的區(qū)別

get是從服務(wù)器上獲取數(shù)據(jù)，post是向服務(wù)器傳送數(shù)據(jù)。

get是把參數(shù)數(shù)據(jù)隊列加到提交表單的ACTION屬性所指的URL中，值和表單內(nèi)各個字段一一對應(yīng)，在URL中可以看到。post是通過HTTP 的post機制，將表單內(nèi)各個字段與其內(nèi)容放置在HTML header內(nèi)一起傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。

對于get方式，服務(wù)器端用Request.QueryString獲取變量的值，對于post方式，服務(wù)器端用Request.Form獲取提交的數(shù)據(jù)。

get傳送的數(shù)據(jù)量較小，因為受URL限制，不能大于2KB，但是效率高。

post傳送的數(shù)據(jù)量較大，一般被默認為不受限制，所以上傳文件時只能用post。但理論上，IIS4中最大量為80KB，IIS5中為100KB。

get安全性非常低，因為URL是可見的，可能會泄露私密信息，如密碼等，post安全性較高。但是執(zhí)行效率卻比Post方法好。

get方式只能支持ASCII字符，向服務(wù)器傳的中文字符可能會亂碼。

post支持標(biāo)準(zhǔn)字符集，可以正確傳遞中文字符。

get請求可以被緩存，可以被收藏為書簽，但 post 不行。

get請求會保留在瀏覽器的歷史記錄中，post 不會。

SO：

1、get方式的安全性較Post方式要差些，包含機密信息的話，建議用Post數(shù)據(jù)提交方式；

2、在做數(shù)據(jù)查詢時，建議用Get方式；而在做數(shù)據(jù)添加、修改或刪除時，建議用Post方式

PS：?POST 請求僅比 GET 請求略安全一點，它的數(shù)據(jù)不在 URL 中，但依然以明文的形式存放于 HTTP 的請求頭中。

HTTP請求報文與響應(yīng)報文格式

請求報文包含三部分：

請求行：包含請求方法、URI、HTTP版本信息

請求首部字段

請求內(nèi)容實體

響應(yīng)報文包含三部分：

狀態(tài)行：包含HTTP版本、狀態(tài)碼、狀態(tài)碼的原因短語

響應(yīng)首部字段

響應(yīng)內(nèi)容實體

常見的HTTP相應(yīng)狀態(tài)碼

200：請求被正常處理

204：請求被受理但沒有資源可以返回

206：客戶端只是請求資源的一部分，服務(wù)器只對請求的部分資源執(zhí)行GET方法，相應(yīng)報文中通過Content-Range指定范圍的資源。

301：永久性重定向

302：臨時重定向

303：與302狀態(tài)碼有相似功能，只是它希望客戶端在請求一個URI的時候，能通過GET方法重定向到另一個URI上

304：發(fā)送附帶條件的請求時，條件不滿足時返回，與重定向無關(guān)

307：臨時重定向，與302類似，只是強制要求使用POST方法

400：請求報文語法有誤，服務(wù)器無法識別

401：請求需要認證

403：請求的對應(yīng)資源禁止被訪問

404：服務(wù)器無法找到對應(yīng)資源

500：服務(wù)器內(nèi)部錯誤

503：服務(wù)器正忙

常見HTTP首部字段

通用首部字段（請求報文與響應(yīng)報文都會使用的首部字段）

Date：創(chuàng)建報文時間

Connection：連接的管理

Cache-Control：緩存的控制

Transfer-Encoding：報文主體的傳輸編碼方式

請求首部字段（請求報文會使用的首部字段）

Host：請求資源所在服務(wù)器

Accept：可處理的媒體類型

Accept-Charset：可接收的字符集

Accept-Encoding：可接受的內(nèi)容編碼

Accept-Language：可接受的自然語言

響應(yīng)首部字段（響應(yīng)報文會使用的首部字段）

Accept-Ranges：可接受的字節(jié)范圍

Location：令客戶端重新定向到的URI

Server：HTTP服務(wù)器的安裝信息

實體首部字段（請求報文與響應(yīng)報文的的實體部分使用的首部字段）

Allow：資源可支持的HTTP方法

Content-Type：實體主類的類型

Content-Encoding：實體主體適用的編碼方式

Content-Language：實體主體的自然語言

Content-Length：實體主體的的字節(jié)數(shù)

Content-Range：實體主體的位置范圍，一般用于發(fā)出部分請求時使用

一次完整的HTTP請求事務(wù)包含以下四個環(huán)節(jié)

建立起客戶機和服務(wù)器連接。

建立連接后，客戶機發(fā)送一個請求給服務(wù)器。

服務(wù)器收到請求給予響應(yīng)信息。

客戶端瀏覽器將返回的內(nèi)容解析并呈現(xiàn)，斷開連接。

一次完整的HTTP請求所經(jīng)歷的7個步驟

HTTP通信機制是在一次完整的HTTP通信過程中，Web瀏覽器與Web服務(wù)器之間將完成下列7個步驟：

建立TCP連接->發(fā)送請求行->發(fā)送請求頭->（到達服務(wù)器）發(fā)送狀態(tài)行->發(fā)送響應(yīng)頭->發(fā)送響應(yīng)數(shù)據(jù)->斷TCP連接

建立TCP連接

在HTTP工作開始之前，Web瀏覽器首先要通過網(wǎng)絡(luò)與Web服務(wù)器建立連接，該連接是通過TCP來完成的，該協(xié)議與IP協(xié)議共同構(gòu)建 Internet，即著名的TCP/IP協(xié)議族，因此Internet又被稱作是TCP/IP網(wǎng)絡(luò)。HTTP是比TCP更高層次的應(yīng)用層協(xié)議，根據(jù)規(guī)則， 只有低層協(xié)議建立之后才能，才能進行更層協(xié)議的連接，因此，首先要建立TCP連接，一般TCP連接的端口號是80。

Web瀏覽器向Web服務(wù)器發(fā)送請求行

一旦建立了TCP連接，Web瀏覽器就會向Web服務(wù)器發(fā)送請求命令。例如：GET /sample/hello.jsp HTTP/1.1。

Web瀏覽器發(fā)送請求頭

瀏覽器發(fā)送其請求命令之后，還要以頭信息的形式向Web服務(wù)器發(fā)送一些別的信息，之后瀏覽器發(fā)送了一空白行來通知服務(wù)器，它已經(jīng)結(jié)束了該頭信息的發(fā)送。

Web服務(wù)器應(yīng)答

客戶機向服務(wù)器發(fā)出請求后，服務(wù)器會客戶機回送應(yīng)答， HTTP/1.1 200 OK ，應(yīng)答的第一部分是協(xié)議的版本號和應(yīng)答狀態(tài)碼。

Web服務(wù)器發(fā)送應(yīng)答頭

正如客戶端會隨同請求發(fā)送關(guān)于自身的信息一樣，服務(wù)器也會隨同應(yīng)答向用戶發(fā)送關(guān)于它自己的數(shù)據(jù)及被請求的文檔。

Web服務(wù)器向瀏覽器發(fā)送數(shù)據(jù)

Web服務(wù)器向瀏覽器發(fā)送頭信息后，它會發(fā)送一個空白行來表示頭信息的發(fā)送到此為結(jié)束，接著，它就以Content-Type應(yīng)答頭信息所描述的格式發(fā)送用戶所請求的實際數(shù)據(jù)。

Web服務(wù)器關(guān)閉TCP連接

一般情況下，一旦Web服務(wù)器向瀏覽器發(fā)送了請求數(shù)據(jù)，它就要關(guān)閉TCP連接，然后如果瀏覽器或者服務(wù)器在其頭信息加入了這行代碼：

Connection:keep-alive

TCP連接在發(fā)送后將仍然保持打開狀態(tài)，于是，瀏覽器可以繼續(xù)通過相同的連接發(fā)送請求。保持連接節(jié)省了為每個請求建立新連接所需的時間，還節(jié)約了網(wǎng)絡(luò)帶寬。

HTTP優(yōu)化

TCP復(fù)用：TCP連接復(fù)用是將多個客戶端的HTTP請求復(fù)用到一個服務(wù)器端TCP連接上，而HTTP復(fù)用則是一個客戶端的多個HTTP請求通過一個TCP連接進行處理。前者是負載均衡設(shè)備的獨特功能；而后者是HTTP 1.1協(xié)議所支持的新功能，目前被大多數(shù)瀏覽器所支持。

內(nèi)容緩存：將經(jīng)常用到的內(nèi)容進行緩存起來，那么客戶端就可以直接在內(nèi)存中獲取相應(yīng)的數(shù)據(jù)了。

壓縮：將文本數(shù)據(jù)進行壓縮，減少帶寬

SSL加密（SSL Acceleration）：使用SSL協(xié)議對HTTP協(xié)議進行加密，在通道內(nèi)加密并加速

TCP緩沖：通過采用TCP緩沖技術(shù)，可以提高服務(wù)器端響應(yīng)時間和處理效率，減少由于通信鏈路問題給服務(wù)器造成的連接負擔(dān)。

HTTP的缺點

通信使用明文不加密，內(nèi)容可能被竊聽

不驗證通信方身份，可能遭到偽裝

無法驗證報文完整性，可能被篡改

HTTP1.1版本新特性

默認持久連接節(jié)省通信量，只要客戶端服務(wù)端任意一端沒有明確提出斷 - 管線化，客戶端可以同時發(fā)出多個HTTP請求，而不用一個個等待響應(yīng)

斷點續(xù)傳 （實際上就是利用HTTP消息頭使用分塊傳輸編碼，將實體主體分塊傳輸）

Cookie和Session的區(qū)別

HTTP 是一種無狀態(tài)的連接，客戶端每次讀取 web頁面時，服務(wù)器都會認為這是一次新的會話。但有時候我們又需要持久保持某些信息，比如登錄時的用戶名、密碼，用戶上一次連接時的信息等。這些信息就由 Cookie 和 Session 保存。

Cookie

cookie實際上是一小段文本信息?？蛻舳苏埱蠓?wù)器，如果服務(wù)器需要記錄該用戶狀態(tài)，就使用response向客戶端瀏覽器頒發(fā)一個cookie，客戶端瀏覽器會把cookie保存起來，當(dāng)瀏覽器再次請求訪問該網(wǎng)站時，瀏覽器把請求的網(wǎng)站連同該cookie一同提交給服務(wù)器，服務(wù)器檢查該cookie，以此來辨認用戶狀態(tài)。

簡單來說，cookie的工作原理可總結(jié)如下：client連接server

client生成cookie（有效期）,再次訪問時攜帶cookie

server根據(jù)cookie的信息識別用戶身份

Session

Session是服務(wù)器端使用的一種記錄客戶端狀態(tài)的機制，使用上比Cookie簡單一些。同一個客戶端每次和服務(wù)端交互時，不需要每次都傳回所有的 Cookie 值，而是只要傳回一個 ID，這個 ID 是客戶端第一次訪問服務(wù)器的時候生成的，而且每個客戶端是唯一的。這樣每個客戶端就有了一個唯一的 ID，客戶端只要傳回這個 ID 就行了，這個 ID 通常是 name為 JSESIONID 的一個 Cookie。Session依據(jù)這個id來識別是否為同一用戶（只認ID不認人）。

區(qū)別：

cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上。

cookie不是很安全，別人可以分析存放在本地的COOKIE并進行COOKIE欺騙

考慮到安全應(yīng)當(dāng)使用session。

session會在一定時間內(nèi)保存在服務(wù)器上。當(dāng)訪問增多，會比較占用你服務(wù)器的性能

考慮到減輕服務(wù)器性能方面，應(yīng)當(dāng)使用COOKIE。

單個cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。