1.HTTP協(xié)議用于客戶端和服務(wù)器端之間的通信

HTTP協(xié)議和TCP/IP協(xié)議族內(nèi)的其他眾多的協(xié)議相同，用于客戶端和服務(wù)端之間的通信。請求訪問文本或圖像等資源的一端稱為客戶端，而提供資源響應(yīng)的一端稱為服務(wù)器端。

2.通過請求和響應(yīng)的交換達成通信

HTTP協(xié)議規(guī)定，請求從客戶端發(fā)出，最后服務(wù)器端響應(yīng)請求并返回。請求時先從客戶端開始建立通信的，服務(wù)器端在沒有接收到請求之前不會發(fā)送響應(yīng)。
請求報文是由請求方法、請求URL、協(xié)議版本、可選的請求首部字段和內(nèi)容實體構(gòu)成的。
響應(yīng)報文基本上由協(xié)議版本、狀態(tài)碼（表示請求成功或失敗的數(shù)字代碼）、用以解釋狀態(tài)碼的原因短語、可選的響應(yīng)首部字段以及實體主體構(gòu)成。

3.HTTP是不保存狀態(tài)的協(xié)議

HTTP是一種不保存狀態(tài)，即無狀態(tài)協(xié)議。HTTP協(xié)議自身不對請求和響應(yīng)之間的通信狀態(tài)進行保存。也就是說在HTTP這個級別，協(xié)議對于發(fā)送過的請求或響應(yīng)都不做持久化處理。可是隨著Web的不斷發(fā)展，因無狀態(tài)而導(dǎo)致業(yè)務(wù)處理變得棘手的情況增多了。比如，用戶登錄到一家購物網(wǎng)站，即使他跳轉(zhuǎn)到該站的其他頁面后，也需要能繼續(xù)保持登錄狀態(tài)。針對這個實例，網(wǎng)站為了能夠掌握是誰發(fā)送的請求，需要保存用戶的狀態(tài)。
HTTP/1.1雖然是無狀態(tài)協(xié)議，但為了實現(xiàn)期望的保存狀態(tài)功能，于是引入了Cookie技術(shù)。有了Cookie再用HTTP協(xié)議通信，就可以管理狀態(tài)了。

4.請求URI定位資源

HTTP協(xié)議使用URI定位互聯(lián)網(wǎng)上的資源。正是因為URI的特定功能，在互聯(lián)網(wǎng)上任意位置的資源都能訪問到。當(dāng)客戶端請求訪問資源而發(fā)送請求時，URI需要將作為請求報文中的請求URI包含在內(nèi)。除此之外，如果不是訪問特定資源而是對服務(wù)器本身發(fā)起請求，可以用一個*來代替URI。

5.告知服務(wù)器意圖的HTTP方法

GET：用來請求訪問已被URI識別的資源。指定的資源經(jīng)服務(wù)器端解析后返回響應(yīng)內(nèi)容。
POST：用來傳輸實體的主體，雖然用GET方法也可以傳輸實體的主體，但一般不會用GET方法進行傳輸，而是用POST方法。POST的主要目的并不是獲取響應(yīng)的主體內(nèi)容。
PUT：用來傳輸文件。就像FTP協(xié)議的文件上傳一樣，要求在請求報文的主體中包含文件的內(nèi)容，然后保存到請求URI指定的位置。但是鑒于HTTP/1.1的PUT方法自身不帶驗證機制，任何人都可以上傳文件，所以一般不采用該方法。
HEAD：和GET方法一樣，只是不返回報文主體部分，用于確認(rèn)URI的有效性及資源更新的日期時間等。
DELETE：用來刪除文件，是與PUT相反的方法。按請求刪除指定的資源，和PUT方法一樣不帶驗證機制。
OPTIONS：用來查詢針對請求URI指定的資源支持的方法。
TRACE：讓W(xué)eb服務(wù)器將之前的請求通信環(huán)回給客戶端的方法。
CONNECT：要求在與代理服務(wù)器通信時建立隧道，實現(xiàn)用隧道協(xié)議進行TCP通信。主要使用SSL（Secure Sockets Layer，安全套接層）和TLS（Secure Sockets Layer Security，傳輸層安全）協(xié)議把通信內(nèi)容加密后經(jīng)網(wǎng)絡(luò)隧道傳輸。
在HTTP/1.1之后，又陸續(xù)擴展了一些方法，其中使用中較多的是PATCH方法，PATCH請求與PUT請求類似，同樣用于資源的更新。二者存在不同：1.PATCH一般用于資源的部分更新，而PUT一般用于資源的整體更新。2.當(dāng)資源不存在是，PATCH會創(chuàng)建一個新的資源，而PUT只會對已有的資源進行更新。

6.使用方法下達命令

向請求URI指定的資源發(fā)送請求報文時，采用稱為方法的命令。方法的作用在于，可以指定請求的資源按期望產(chǎn)生某種行為。

7.持久連接節(jié)省通信量

HTTP協(xié)議的初始版本中，每進行一次HTTP通信就要斷開一次TCP連接，以當(dāng)年的通信情況來說沒有多大問題，隨著HTTP的普及，文檔中包含大量圖片的情況多了起來。使用瀏覽器瀏覽一個包含多張圖片的HTML頁面時，在發(fā)送請求訪問HTML頁面資源的同時，也會請求該HTML頁面的其他資源。因此，每次的請求都會造成無謂的TCP連接建立和斷開，增加通信量的消耗。
為了解決上述問題，HTTP/1.1和一部分的HTTP/1.0想出了持久連接（HTTP Persistent Connections，也稱為HTTP keep-alive或HTTP connection reuse）的方法。持久連接的特點是，只要任意一段沒有明確提出斷開連接，則保持TCP連接狀態(tài)。
持久連接使得多數(shù)請求以管線化方式發(fā)送成為可能，從前發(fā)送請求后需要等待并收到響應(yīng)，才能發(fā)送下一個請求。管線化技術(shù)出現(xiàn)后，不用等待響應(yīng)亦可直接發(fā)送下一個請求。這樣就能做到同時并行發(fā)送多個請求，而不需要一個接一個地等待響應(yīng)了。

8.使用Cookie的狀態(tài)管理

HTTP是無狀態(tài)協(xié)議，它不對之前發(fā)生過的請求和響應(yīng)的狀態(tài)進行管理。也就是說，無法根據(jù)之前的狀態(tài)進行本次的請求處理。而無狀態(tài)協(xié)議也有它的優(yōu)點，由于不保存狀態(tài)，自然可減少服務(wù)器的CPU及內(nèi)存資源的消耗。從另一側(cè)面來說，也正是因為HTTP協(xié)議本身是非常簡單的，所以才會被應(yīng)用到各種場景里。保留無狀態(tài)協(xié)議這個特征的同時又要解決類似的矛盾問題，于是引入了Cookie技術(shù)。Cookie技術(shù)通過在請求和響應(yīng)報文中寫入Cookie信息來控制客戶端的狀態(tài)。
Cookie會根據(jù)從服務(wù)器發(fā)送的響應(yīng)報文內(nèi)的一個叫做Set-Cookie的首部字段信息，通知客戶端保存Cookie。當(dāng)下次客戶端再往該服務(wù)器發(fā)送請求時，客戶端會自動在請求報文中加入Cookie值后發(fā)送出去。
服務(wù)器端發(fā)現(xiàn)客戶端發(fā)送過來的Cookie后，會去檢查究竟是從哪一個客戶端發(fā)送的連接請求，然后對比服務(wù)器上的記錄，最后得到之前的狀態(tài)信息。