超文本傳輸協(xié)議（英文：HyperText Transfer Protocol，縮寫：HTTP）是一種用于分布式、協(xié)作式和超媒體信息系統(tǒng)的應(yīng)用層協(xié)議[1]。HTTP是萬維網(wǎng)的數(shù)據(jù)通信的基礎(chǔ)。

設(shè)計(jì)HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁面的方法。通過HTTP或者https協(xié)議請求的資源由統(tǒng)一資源標(biāo)識符（Uniform Resource Identifiers，URI）來標(biāo)識。

HTTP的發(fā)展是由蒂姆·伯納斯-李于1989年在歐洲核子研究組織（CERN）所發(fā)起。HTTP的標(biāo)準(zhǔn)制定由萬維網(wǎng)協(xié)會(huì)（World Wide Web Consortium，W3C）和互聯(lián)網(wǎng)工程任務(wù)組（Internet Engineering Task Force，IETF）進(jìn)行協(xié)調(diào)，最終發(fā)布了一系列的RFC，其中最著名的是1999年6月公布的 RFC 2616，定義了HTTP協(xié)議中現(xiàn)今廣泛使用的一個(gè)版本——HTTP 1.1。

2014年12月，互聯(lián)網(wǎng)工程任務(wù)組（IETF）的Hypertext Transfer Protocol Bis（httpbis）工作小組將HTTP/2標(biāo)準(zhǔn)提議遞交至IESG進(jìn)行討論[2]，于2015年2月17日被批準(zhǔn)。 HTTP/2標(biāo)準(zhǔn)于2015年5月以RFC 7540正式發(fā)表，取代HTTP 1.1成為HTTP的實(shí)現(xiàn)標(biāo)準(zhǔn)。

HTTP是一個(gè)客戶端終端（用戶）和服務(wù)器端（網(wǎng)站）請求和應(yīng)答的標(biāo)準(zhǔn)（TCP）。通過使用網(wǎng)頁瀏覽器、網(wǎng)絡(luò)爬蟲或者其它的工具，客戶端發(fā)起一個(gè)HTTP請求到服務(wù)器上指定端口（默認(rèn)端口為80）。我們稱這個(gè)客戶端為用戶代理程序（user agent）。應(yīng)答的服務(wù)器上存儲(chǔ)著一些資源，比如HTML文件和圖像。我們稱這個(gè)應(yīng)答服務(wù)器為源服務(wù)器（origin server）。在用戶代理和源服務(wù)器中間可能存在多個(gè)“中間層”，比如代理服務(wù)器、網(wǎng)關(guān)或者隧道（tunnel）。

盡管TCP/IP協(xié)議是互聯(lián)網(wǎng)上最流行的應(yīng)用，HTTP協(xié)議中，并沒有規(guī)定必須使用它或它支持的層。事實(shí)上，HTTP可以在任何互聯(lián)網(wǎng)協(xié)議上，或其他網(wǎng)絡(luò)上實(shí)現(xiàn)。HTTP假定其下層協(xié)議提供可靠的傳輸。因此，任何能夠提供這種保證的協(xié)議都可以被其使用。因此也就是其在TCP/IP協(xié)議族使用TCP作為其傳輸層。

通常，由HTTP客戶端發(fā)起一個(gè)請求，創(chuàng)建一個(gè)到服務(wù)器指定端口（默認(rèn)是80端口）的TCP連接。HTTP服務(wù)器則在那個(gè)端口監(jiān)聽客戶端的請求。一旦收到請求，服務(wù)器會(huì)向客戶端返回一個(gè)狀態(tài)，比如”HTTP/1.1 200 OK”，以及返回的內(nèi)容，如請求的文件、錯(cuò)誤消息、或者其它信息。

請求方法
HTTP/1.1協(xié)議中共定義了八種方法（也叫“動(dòng)作”）來以不同方式操作指定的資源：

GET
向指定的資源發(fā)出“顯示”請求。使用GET方法應(yīng)該只用在讀取數(shù)據(jù)，而不應(yīng)當(dāng)被用于產(chǎn)生“副作用”的操作中，例如在Web Application中。其中一個(gè)原因是GET可能會(huì)被網(wǎng)絡(luò)蜘蛛等隨意訪問。參見安全方法
HEAD
與GET方法一樣，都是向服務(wù)器發(fā)出指定資源的請求。只不過服務(wù)器將不傳回資源的本文部分。它的好處在于，使用這個(gè)方法可以在不必傳輸全部內(nèi)容的情況下，就可以獲取其中“關(guān)于該資源的信息”（元信息或稱元數(shù)據(jù)）。
POST
向指定資源提交數(shù)據(jù)，請求服務(wù)器進(jìn)行處理（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請求本文中。這個(gè)請求可能會(huì)創(chuàng)建新的資源或修改現(xiàn)有資源，或二者皆有。
PUT
向指定資源位置上傳其最新內(nèi)容。
DELETE
請求服務(wù)器刪除Request-URI所標(biāo)識的資源。
TRACE
回顯服務(wù)器收到的請求，主要用于測試或診斷。
OPTIONS
這個(gè)方法可使服務(wù)器傳回該資源所支持的所有HTTP請求方法。用’*’來代替資源名稱，向Web服務(wù)器發(fā)送OPTIONS請求，可以測試服務(wù)器功能是否正常運(yùn)作。
CONNECT
HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。通常用于SSL加密服務(wù)器的鏈接（經(jīng)由非加密的HTTP代理服務(wù)器）。
方法名稱是區(qū)分大小寫的。當(dāng)某個(gè)請求所針對的資源不支持對應(yīng)的請求方法的時(shí)候，服務(wù)器應(yīng)當(dāng)返回狀態(tài)碼405（Method Not Allowed），當(dāng)服務(wù)器不認(rèn)識或者不支持對應(yīng)的請求方法的時(shí)候，應(yīng)當(dāng)返回狀態(tài)碼501（Not Implemented）。

HTTP服務(wù)器至少應(yīng)該實(shí)現(xiàn)GET和HEAD方法，其他方法都是可選的。當(dāng)然，所有的方法支持的實(shí)現(xiàn)都應(yīng)當(dāng)匹配下述的方法各自的語義定義。此外，除了上述方法，特定的HTTP服務(wù)器還能夠擴(kuò)展自定義的方法。例如：

PATCH（由 RFC 5789 指定的方法）
用于將局部修改應(yīng)用到資源。
安全方法
對于GET和HEAD方法而言，除了進(jìn)行獲取資源信息外，這些請求不應(yīng)當(dāng)再有其他意義。也就是說，這些方法應(yīng)當(dāng)被認(rèn)為是“安全的”。 客戶端可能會(huì)使用其他“非安全”方法，例如POST，PUT及DELETE，應(yīng)該以特殊的方式（通常是按鈕而不是超鏈接）告知客戶可能的后果（例如一個(gè)按鈕控制的資金交易），或請求的操作可能是不安全的（例如某個(gè)文件將被上傳或刪除）。

但是，不能想當(dāng)然地認(rèn)為服務(wù)器在處理某個(gè)GET請求時(shí)不會(huì)產(chǎn)生任何副作用。事實(shí)上，很多動(dòng)態(tài)資源會(huì)把這作為其特性。這里重要的區(qū)別在于用戶并沒有請求這一副作用，因此不應(yīng)由用戶為這些副作用承擔(dān)責(zé)任。

副作用
假如在不考慮諸如錯(cuò)誤或者過期等問題的情況下，若干次請求的副作用與單次請求相同或者根本沒有副作用，那么這些請求方法就能夠被視作“冪等(idempotence)”的。GET，HEAD，PUT和DELETE方法都有這樣的冪等屬性，同樣由于根據(jù)協(xié)議，OPTIONS，TRACE都不應(yīng)有副作用，因此也理所當(dāng)然也是冪等的。

假如某個(gè)由若干個(gè)請求做成的請求序列產(chǎn)生的結(jié)果在重復(fù)執(zhí)行這個(gè)請求序列或者其中任何一個(gè)或多個(gè)請求后仍沒有發(fā)生變化，則這個(gè)請求序列便是“冪等”的。但是，可能出現(xiàn)若干個(gè)請求做成的請求序列是“非冪等”的，即使這個(gè)請求序列中所有執(zhí)行的請求方法都是冪等的。例如，這個(gè)請求序列的結(jié)果依賴于某個(gè)會(huì)在下次執(zhí)行這個(gè)序列的過程中被修改的變量。

版本
超文本傳輸協(xié)議已經(jīng)演化出了很多版本，它們中的大部分都是向下兼容的。在 RFC 2145 中描述了HTTP版本號的用法?？蛻舳嗽谡埱蟮拈_始告訴服務(wù)器它采用的協(xié)議版本號，而后者則在響應(yīng)中采用相同或者更早的協(xié)議版本。

HTTP/0.9
已過時(shí)。只接受GET一種請求方法，沒有在通訊中指定版本號，且不支持請求頭。由于該版本不支持POST方法，因此客戶端無法向服務(wù)器傳遞太多信息。

HTTP/1.0
這是第一個(gè)在通訊中指定版本號的HTTP協(xié)議版本，至今仍被廣泛采用，特別是在代理服務(wù)器中。

HTTP/1.1
持久連接被默認(rèn)采用，并能很好地配合代理服務(wù)器工作。還支持以管道方式在同時(shí)發(fā)送多個(gè)請求，以便降低線路負(fù)載，提高傳輸速度。

HTTP/1.1相較于HTTP/1.0協(xié)議的區(qū)別主要體現(xiàn)在：

緩存處理
帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用
錯(cuò)誤通知的管理
消息在網(wǎng)絡(luò)中的發(fā)送
互聯(lián)網(wǎng)地址的維護(hù)
安全性及完整性
HTTP/2
主條目：HTTP/2
當(dāng)前版本，于2015年5月作為互聯(lián)網(wǎng)標(biāo)準(zhǔn)正式發(fā)布。

狀態(tài)碼
參見：http狀態(tài)碼
所有HTTP響應(yīng)的第一行都是狀態(tài)行，依次是當(dāng)前HTTP版本號，3位數(shù)字組成的狀態(tài)代碼，以及描述狀態(tài)的短語，彼此由空格分隔。

狀態(tài)代碼的第一個(gè)數(shù)字代表當(dāng)前響應(yīng)的類型：

1xx消息——請求已被服務(wù)器接收，繼續(xù)處理
2xx成功——請求已成功被服務(wù)器接收、理解、并接受
3xx重定向——需要后續(xù)操作才能完成這一請求
4xx請求錯(cuò)誤——請求含有詞法錯(cuò)誤或者無法被執(zhí)行
5xx服務(wù)器錯(cuò)誤——服務(wù)器在處理某個(gè)正確請求時(shí)發(fā)生錯(cuò)誤
雖然 RFC 2616 中已經(jīng)推薦了描述狀態(tài)的短語，例如”200 OK”，”404 Not Found”，但是WEB開發(fā)者仍然能夠自行決定采用何種短語，用以顯示本地化的狀態(tài)描述或者自定義信息。

持續(xù)連線

使用多個(gè)連接和使用持久鏈接的對比
主條目：HTTP持久連接
在HTTP 0.9和1.0中，TCP連線在每一次請求/回應(yīng)對之后關(guān)閉。在HTTP 1.1中，引入了保持連線的機(jī)制，一個(gè)連接可以重復(fù)在多個(gè)請求/回應(yīng)使用。持續(xù)連線的方式可以大大減少等待時(shí)間，因?yàn)樵诎l(fā)出第一個(gè)請求后，雙方不需要重新運(yùn)行TCP握手程序。

HTTP 1.1還使改進(jìn)了HTTP 1.0的帶寬。 例如，HTTP 1.1引入了分塊傳輸編碼，以允許傳遞內(nèi)容可以在持續(xù)連線上被流傳輸而不必使用到緩沖器。HTTP管道允許客戶端在收到每個(gè)回應(yīng)之前發(fā)送多個(gè)請求，進(jìn)一步減少用戶感受到的滯后時(shí)間。協(xié)議的另一個(gè)補(bǔ)充是字節(jié)服務(wù)，允許客戶端請求資源的某一部分，服務(wù)器僅回應(yīng)某資源的指明部分。

協(xié)議例子
下面是一個(gè)HTTP客戶端與服務(wù)器之間會(huì)話的例子，運(yùn)行于www.google.com，端口80

請求信息
發(fā)出的請求信息（message request）包括以下幾個(gè):

請求行（例如GET /images/logo.gif HTTP/1.1，表示從/images目錄下請求logo.gif這個(gè)文件）
請求頭（例如Accept-Language: en）
空行
其他消息體
請求行和標(biāo)題必須以<CR><LF>作為結(jié)尾?？招袃?nèi)必須只有<CR><LF>而無其他空格。在HTTP/1.1協(xié)議中，所有的請求頭，除Host外，都是可選的。

客戶端請求
GET / HTTP/1.1
Host: www.google.com
（末尾有一個(gè)空行。第一行指定方法、資源路徑、協(xié)議版本；第二行是在1.1版里必帶的一個(gè)header作用指定主機(jī)）

服務(wù)器應(yīng)答
HTTP/1.1 200 OK
Content-Length: 3059
Server: GWS/2.0
Date: Sat, 11 Jan 2003 02:44:04 GMT
Content-Type: text/html
Cache-control: private
Set-Cookie: PREF=ID=73d4aef52e57bae9:TM=1042253044:LM=1042253044:S=SMCc_HRPCQiqy
X9j; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Connection: keep-alive
（緊跟著一個(gè)空行，并且由HTML格式的文本組成了Google的主頁）

在HTTP1.0，單一TCP連接內(nèi)僅執(zhí)行一個(gè)“客戶端發(fā)送請求—服務(wù)器發(fā)送應(yīng)答”周期，之后釋放TCP連接。在HTTP1.1優(yōu)化支持持續(xù)活躍連接：客戶端連續(xù)多次發(fā)送請求、接收應(yīng)答；批量多請求時(shí)，同一TCP連接在活躍（Keep-Live）間期內(nèi)復(fù)用，避免重復(fù)TCP初始握手活動(dòng)，減少網(wǎng)絡(luò)負(fù)荷和響應(yīng)周期。此外支持應(yīng)答到達(dá)前繼續(xù)發(fā)送請求（通常是兩個(gè)），稱為“流線化”（stream）。

類似協(xié)議
Gopher是1990年代早期被HTTP取代的內(nèi)容傳遞協(xié)議。SPDY是Google開發(fā)的HTTP的替代方案，它被新版本的HTTP協(xié)議HTTP/2所取代。