超文字傳輸協議

超文字傳輸協定是一種用於分散式、協作式和超媒體資訊系統的應用層協議。HTTP是全球資訊網的資料通訊的基礎。設計HTTP最初的目的是為了提供一種釋出和接收HTML頁面的方法。透過HTTP或者HTTPS協議請求的資源由統一資源識別符號來標識。HTTP的發展是由提姆·柏內茲-李於1989年在歐洲核子研究組織進行協調，最終釋出了一系列的RFC，其中最著名的是1999年6月公佈的 RFC 2616，定義了HTTP協議中現今廣泛使用的一個版本——HTTP 1.1。2014年12月，網際網路工程任務組工作小組將HTTP/2標準提議遞交至進行討論，於2015年2月17日被批准。 HTTP/2標準於2015年5月以RFC 7540正式發表，取代HTTP 1.1成為HTTP的實現標準。協議概述.HTTP是一個客戶端。儘管TCP/IP協議是網際網路上最流行的應用，但是在HTTP協議中並沒有規定它必須使用或它支援的層。事實上HTTP可以在任何網際網路協議或其他網路上實現。HTTP假定其下層協議提供可靠的傳輸。因此，任何能夠提供這種保證的協議都可以被其使用，所以其在TCP/IP協議族使用TCP作為其傳輸層。通常，由HTTP客戶端發起一個請求，建立一個到伺服器指定埠的TCP連線。HTTP伺服器則在那個埠監聽客戶端的請求。一旦收到請求，伺服器會向客戶端返回一個狀態，比如"HTTP/1.1 200 OK"，以及返回的內容，如請求的檔案、錯誤訊息、或者其它資訊。請求方法.HTTP/1.1協議中共定義了八種方法來以不同方式操作指定的資源：向指定的資源發出「顯示」請求。使用GET方法應該只用在讀取資料，而不應當被用於產生「副作用」的操作中，例如在網路應用程式中。其中一個原因是GET可能會被網路爬蟲等隨意訪問。全方法。瀏覽器直接發出的GET只能由一個url觸發。GET上要在url之外帶一些引數就只能依靠url上附帶querystring。與GET方法一樣，都是向伺服器發出指定資源的請求。只不過伺服器將不傳回資源的本文部份。它的好處在於，使用這個方法可以在不必傳輸全部內容的情況下，就可以獲取其中「關於該資源的y資訊」。向指定資源提交資料，請求伺服器進行處理。資料被包含在請求本文中。這個請求可能會建立新的資源或修改現有資源，或二者皆有。每次提交，表單的資料被瀏覽器用編碼到HTTP請求的body裡。瀏覽器發出的POST請求的body主要有兩種格式，一種是application/x-www-form-urlencoded用來傳輸簡單的資料，大概就是"key1=value1&amp;key2=value2"這樣的格式。另外一種是傳檔案，會採用multipart/form-data格式。採用後者是因為application/x-www-form-urlencoded的編碼方式對於檔案這種二進位制的資料非常低效。向指定資源位置上傳其最新內容。請求伺服器刪除Request-URI所標識的資源。回顯伺服器收到的請求，主要用於測試或診斷。這個方法可使伺服器傳回該資源所支援的所有HTTP請求方法。用'*'來代替資源名稱，向Web伺服器傳送OPTIONS請求，可以測試伺服器功能是否正常運作。HTTP/1.1協議中預留給能夠將連線改為隧道方式的代理伺服器。通常用於SSL加密伺服器的連結。方法名稱是區分大小寫的。當某個請求所針對的資源不支援對應的請求方法的時候，伺服器應當返回狀態碼405。HTTP伺服器至少應該實現GET和HEAD方法，其他方法都是可選的。當然，所有的方法支援的實現都應當符合下述的方法各自的語義定義。此外，特定的HTTP伺服器還能夠擴充套件自定義的方法。例如：用於將區域性修改應用到資源。安全方法.對於GET和HEAD方法而言，除了進行獲取資源資訊外，這些請求不應當再有其他意義。也就是說，這些方法應當被認為是“安全的”。客戶端可能會使用其他“非安全”方法，例如POST，PUT及DELETE，應該以特殊的方式。但是，不能想當然地認為伺服器在處理某個GET請求時不會產生任何副作用。事實上，很多動態資源會把這作為其特性。這裡重要的區別在於使用者並沒有請求這一副作用，因此不應由使用者為這些副作用承擔責任。副作用.假如在不考慮諸如錯誤或者過期等問題的情況下，若干次請求的副作用與單次請求相同或者根本沒有副作用，那麼這些請求方法就能夠被視作“冪等(idempotence)”的。GET，HEAD，PUT和DELETE方法都有這樣的冪等屬性，同樣由於根據協議，OPTIONS，TRACE都不應有副作用，因此也理所當然也是冪等的。假如一個由若干請求組成的請求序列產生的結果，在重複執行這個請求序列或者其中任何一個或多個請求後仍沒有發生變化，則這個請求序列便是“冪等”的。但是，可能出現一個由若干請求組成的請求序列是“非冪等”的，即使這個請求序列中所有執行的請求方法都是冪等的。例如，這個請求序列的結果依賴於某個會在下次執行這個序列的過程中被修改的變數。版本.超文字傳輸協議已經演化出了很多版本，它們中的大部分都是向下相容的。在RFC 2145中描述了HTTP版本號的用法。客戶端在請求的開始告訴伺服器它採用的協議版本號，而後者則在響應中採用相同或者更早的協議版本。HTTP/0.9.已過時。只接受GET一種請求方法，沒有在通訊中指定版本號，且不支援請求頭。由於該版本不支援POST方法，因此客戶端無法向伺服器傳遞太多資訊。HTTP/1.0.這是第一個在通訊中指定版本號的HTTP協議版本。HTTP/1.1.預設採用持續連線，能很好地配合代理伺服器工作。還支援以管道方式在同時傳送多個請求，以便降低線路負載，提高傳輸速度。HTTP/1.1相較於HTTP/1.0協議的區別主要體現在：HTTP/2.當前版本，於2015年5月作為網際網路標準正式釋出。HTTP/3.最新版本，於2022年6月6日標準化為RFC9114。會拋棄使用TCP，透過UDP上使用QUIC來承載應用層資料。狀態碼.所有HTTP響應的第一行都是狀態行，依次是當前HTTP版本號，3位數字組成的狀態程式碼，以及描述狀態的短語，彼此由空格分隔。狀態程式碼的第一個數字代表當前響應的型別：雖然 RFC 2616 中已經推薦了描述狀態的短語，例如"200 OK"，"404 Not Found"，但是WEB開發者仍然能夠自行決定採用何種短語，用以顯示本地化的狀態描述或者自定義資訊。持續連線.在HTTP 0.9和1.0中，TCP連線在每一次請求/回應對之後關閉。在HTTP 1.1中，引入了保持連線的機制，一個連線可以重複在多個請求/回應使用。持續連線的方式可以大大減少等待時間，因為在發出第一個請求後，雙方不需要重新執行TCP交握程式。HTTP 1.1還改進了HTTP 1.0的頻寬。 例如，HTTP 1.1引入了分塊傳輸編碼，以允許傳遞內容可以在持續連線上被串流傳輸而不必使用到緩衝器。HTTP管道允許客戶端在收到每個回應之前傳送多個請求，進一步減少使用者感受到的滯後時間。協議的另一個補充是位元組服務，允許客戶端請求資源的某一部份，伺服器僅回應某資源的指明部分。協議例子.下面是一個HTTP客戶端與伺服器之間會話的例子，運行於www.google.com，埠80請求資訊.發出的請求資訊包括以下幾個:請求行和標題必須以而無其他空格。在HTTP/1.1協議中，所有的請求頭，除Host外，都是可選的。客戶端請求.GET / HTTP/1.1Host: www.google.com伺服器應答.HTTP/1.1 200 OKContent-Length: 3059Server: GWS/2.0Date: Sat, 11 Jan 2003 02:44:04 GMTContent-Type: text/htmlCache-control: privateSet-Cookie: PREF=ID=73d4aef52e57bae9:TM=1042253044:LM=1042253044:S=SMCc_HRPCQiqyX9j; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.comConnection: keep-alive在HTTP1.0，單一TCP連線內僅執行一個“客戶端傳送請求—伺服器傳送應答”週期，之後釋放TCP連線。在HTTP1.1最佳化支援持續活躍連線：客戶端連續多次傳送請求、接收應答；批次多請求時，同一TCP連線在活躍。類似協議.Gopher是1990年代早期被HTTP取代的內容傳遞協議。SPDY是Google開發的HTTP的替代方案，它被新版本的HTTP協議HTTP/2所取代。