原文地址

HTTP協(xié)議

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

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

常用的HTTP方法有哪些？

• GET：用于請求訪問已經(jīng)被URL（統(tǒng)一資源標識符）識別的資源，可以通過URL傳參給服務器。
• POST：用于傳輸信息給服務器，主要功能與Get方法類似，但一般推薦POST方式。
• PUT：傳輸文件，報文主體包含文件內(nèi)容，保存到對應URL位置。
• HEAD：獲取報文首部，與GET方法類似，只是不返回報文主體，一般用于驗證URL是否有效。
• DELET：刪除文件，與PUT方法相反，刪除對應URL位置的文件。
• OPTIONS：查詢相應URL支持的HTTP方法。

get和post的區(qū)別

1. get是從服務器上獲取數(shù)據(jù)，post是向服務器傳送數(shù)據(jù)。
2. get是把參數(shù)數(shù)據(jù)隊列加到提交表單的ACTION屬性所指的URL中，值和表單內(nèi)各個字段一一對應，在URL中可以看到。post是通過HTTP 的post機制，將表單內(nèi)各個字段與其內(nèi)容放置在HTML header內(nèi)一起傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。
3. 對于get方式，服務器端用Request.QueryString獲取變量的值，對于post方式，服務器端用Request.Form獲取提交的數(shù)據(jù)。
4. get傳送的數(shù)據(jù)量較小，因為受URL限制，不能大于2KB，但是效率高。
   post傳送的數(shù)據(jù)量較大，一般被默認為不受限制，所以上傳文件時只能用post。但理論上，IIS4中最大量為80KB，IIS5中為100KB。
5. get安全性非常低，因為URL是可見的，可能會泄露私密信息，如密碼等，post安全性較高。但是執(zhí)行效率卻比Post方法好。
6. get方式只能支持ASCII字符，向服務器傳的中文字符可能會亂碼。
   post支持標準字符集，可以正確傳遞中文字符。
7. get請求可以被緩存，可以被收藏為書簽，但 post 不行。
8. get請求會保留在瀏覽器的歷史記錄中，post 不會。

SO：
1、get方式的安全性較Post方式要差些，包含機密信息的話，建議用Post數(shù)據(jù)提交方式；
2、在做數(shù)據(jù)查詢時，建議用Get方式；而在做數(shù)據(jù)添加、修改或刪除時，建議用Post方式

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

HTTP請求報文與響應報文格式

請求報文包含三部分：

• 請求行：包含請求方法、URI、HTTP版本信息
• 請求首部字段
• 請求內(nèi)容實體

響應報文包含三部分：

• 狀態(tài)行：包含HTTP版本、狀態(tài)碼、狀態(tài)碼的原因短語
• 響應首部字段
• 響應內(nèi)容實體

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

200：請求被正常處理
204：請求被受理但沒有資源可以返回
206：客戶端只是請求資源的一部分，服務器只對請求的部分資源執(zhí)行GET方法，相應報文中通過Content-Range指定范圍的資源。
301：永久性重定向
302：臨時重定向
303：與302狀態(tài)碼有相似功能，只是它希望客戶端在請求一個URI的時候，能通過GET方法重定向到另一個URI上
304：發(fā)送附帶條件的請求時，條件不滿足時返回，與重定向無關
307：臨時重定向，與302類似，只是強制要求使用POST方法
400：請求報文語法有誤，服務器無法識別
401：請求需要認證
403：請求的對應資源禁止被訪問
404：服務器無法找到對應資源
500：服務器內(nèi)部錯誤
503：服務器正忙

常見HTTP首部字段

通用首部字段（請求報文與響應報文都會使用的首部字段）
Date：創(chuàng)建報文時間
Connection：連接的管理
Cache-Control：緩存的控制
Transfer-Encoding：報文主體的傳輸編碼方式

請求首部字段（請求報文會使用的首部字段）
Host：請求資源所在服務器
Accept：可處理的媒體類型
Accept-Charset：可接收的字符集
Accept-Encoding：可接受的內(nèi)容編碼
Accept-Language：可接受的自然語言

響應首部字段（響應報文會使用的首部字段）
Accept-Ranges：可接受的字節(jié)范圍
Location：令客戶端重新定向到的URI
Server：HTTP服務器的安裝信息

實體首部字段（請求報文與響應報文的的實體部分使用的首部字段）
Allow：資源可支持的HTTP方法
Content-Type：實體主類的類型
Content-Encoding：實體主體適用的編碼方式
Content-Language：實體主體的自然語言
Content-Length：實體主體的的字節(jié)數(shù)
Content-Range：實體主體的位置范圍，一般用于發(fā)出部分請求時使用

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

1. 建立起客戶機和服務器連接。
2. 建立連接后，客戶機發(fā)送一個請求給服務器。
3. 服務器收到請求給予響應信息。
   4.客戶端瀏覽器將返回的內(nèi)容解析并呈現(xiàn)，斷開連接。

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

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

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

建立TCP連接

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

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

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

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

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

Web服務器應答

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

Web服務器發(fā)送應答頭

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

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

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

Web服務器關閉TCP連接

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

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

HTTP優(yōu)化

• TCP復用：TCP連接復用是將多個客戶端的HTTP請求復用到一個服務器端TCP連接上，而HTTP復用則是一個客戶端的多個HTTP請求通過一個TCP連接進行處理。前者是負載均衡設備的獨特功能；而后者是HTTP 1.1協(xié)議所支持的新功能，目前被大多數(shù)瀏覽器所支持。
• 內(nèi)容緩存：將經(jīng)常用到的內(nèi)容進行緩存起來，那么客戶端就可以直接在內(nèi)存中獲取相應的數(shù)據(jù)了。
• 壓縮：將文本數(shù)據(jù)進行壓縮，減少帶寬
• SSL加密（SSL Acceleration）：使用SSL協(xié)議對HTTP協(xié)議進行加密，在通道內(nèi)加密并加速
• TCP緩沖：通過采用TCP緩沖技術，可以提高服務器端響應時間和處理效率，減少由于通信鏈路問題給服務器造成的連接負擔。

HTTP的缺點

• 通信使用明文不加密，內(nèi)容可能被竊聽
• 不驗證通信方身份，可能遭到偽裝
• 無法驗證報文完整性，可能被篡改

HTTP1.1版本新特性

• 默認持久連接節(jié)省通信量，只要客戶端服務端任意一端沒有明確提出斷 - 管線化，客戶端可以同時發(fā)出多個HTTP請求，而不用一個個等待響應
• 斷點續(xù)傳 （實際上就是利用HTTP消息頭使用分塊傳輸編碼，將實體主體分塊傳輸）

Cookie和Session的區(qū)別

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

Cookie

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

簡單來說，cookie的工作原理可總結(jié)如下：
1，client連接server
2，client生成cookie（有效期）,再次訪問時攜帶cookie
3, server根據(jù)cookie的信息識別用戶身份

Session

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

區(qū)別：

1. cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務器上。
2. cookie不是很安全，別人可以分析存放在本地的COOKIE并進行COOKIE欺騙
   考慮到安全應當使用session。
3. session會在一定時間內(nèi)保存在服務器上。當訪問增多，會比較占用你服務器的性能
   考慮到減輕服務器性能方面，應當使用COOKIE。
4. 單個cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。