Can you summarize the following document?
        
  HTTP是一個客戶端(使用者)和服務端(網站)之間請求和應答的標準,通常使用TCP協議。通過使用網頁瀏覽器、網路爬蟲或者其它的工具,客戶端發起一個HTTP請求到伺服器上指定埠(預設埠為80)。我們稱這個客戶端為使用者代理程式(user agent)。應答的伺服器上儲存著一些資源,比如HTML檔案和影象。我們稱這個應答伺服器為源伺服器(origin server)。在使用者代理和源伺服器中間可能存在多個「中間層」,比如代理伺服器、閘道器或者隧道(tunnel)。  儘管TCP/IP協議是網際網路上最流行的應用,但是在HTTP協議中並沒有規定它必須使用或它支援的層。事實上HTTP可以在任何網際網路協議或其他網路上實現。HTTP假定其下層協議提供可靠的傳輸。因此,任何能夠提供這種保證的協議都可以被其使用,所以其在TCP/IP協議族使用TCP作為其傳輸層。  通常,由HTTP客戶端發起一個請求,建立一個到伺服器指定埠(預設是80埠)的TCP連線。HTTP伺服器則在那個埠監聽客戶端的請求。一旦收到請求,伺服器會向客戶端返回一個狀態,比如"HTTP/1.1 200 OK",以及返回的內容,如請求的檔案、錯誤訊息、或者其它資訊。

  HTTP/1.1協議中共定義了八種方法(也叫“動作”)來以不同方式操作指定的資源:  方法名稱是區分大小寫的。當某個請求所針對的資源不支援對應的請求方法的時候,伺服器應當返回狀態碼405(Method Not Allowed),當伺服器不認識或者不支援對應的請求方法的時候,應當返回狀態碼501(Not Implemented)。  HTTP伺服器至少應該實現GET和HEAD方法,其他方法都是可選的。當然,所有的方法支援的實現都應當符合下述的方法各自的語義定義。此外,除了上述方法,特定的HTTP伺服器還能夠擴充套件自定義的方法。例如:

  對於GET和HEAD方法而言,除了進行獲取資源資訊外,這些請求不應當再有其他意義。也就是說,這些方法應當被認為是“安全的”。 客戶端可能會使用其他“非安全”方法,例如POST,PUT及DELETE,應該以特殊的方式(通常是按鈕而不是超連結)告知客戶可能的後果(例如一個按鈕控制的資金交易),或請求的操作可能是不安全的(例如某個檔案將被上傳或刪除)。  但是,不能想當然地認為伺服器在處理某個GET請求時不會產生任何副作用。事實上,很多動態資源會把這作為其特性。這裡重要的區別在於使用者並沒有請求這一副作用,因此不應由使用者為這些副作用承擔責任。

  假如在不考慮諸如錯誤或者過期等問題的情況下,若干次請求的副作用與單次請求相同或者根本沒有副作用,那麼這些請求方法就能夠被視作“冪等(idempotence)”的。GET,HEAD,PUT和DELETE方法都有這樣的冪等屬性,同樣由於根據協議,OPTIONS,TRACE都不應有副作用,因此也理所當然也是冪等的。  假如一個由若干請求組成的請求序列產生的結果,在重複執行這個請求序列或者其中任何一個或多個請求後仍沒有發生變化,則這個請求序列便是“冪等”的。但是,可能出現一個由若干請求組成的請求序列是“非冪等”的,即使這個請求序列中所有執行的請求方法都是冪等的。例如,這個請求序列的結果依賴於某個會在下次執行這個序列的過程中被修改的變數。

  超文字傳輸協議已經演化出了很多版本,它們中的大部分都是向下相容的。在 RFC 2145 中描述了HTTP版本號的用法。客戶端在請求的開始告訴伺服器它採用的協議版本號,而後者則在響應中採用相同或者更早的協議版本。

  已過時。只接受GET一種請求方法,沒有在通訊中指定版本號,且不支援請求頭。由於該版本不支援POST方法,因此客戶端無法向伺服器傳遞太多資訊。

  這是第一個在通訊中指定版本號的HTTP協議版本,

  持久連線被預設採用,並能很好地配合代理伺服器工作。還支援以管道方式在同時傳送多個請求,以便降低線路負載,提高傳輸速度。  HTTP/1.1相較於HTTP/1.0協議的區別主要體現在:

  當前版本,於2015年5月作為網際網路標準正式釋出。

  所有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

  發出的請求資訊(message request)包括以下幾個: 請求行和標題必須以<CR><LF>作為結尾。空行內必須只有<CR><LF>而無其他空格。在HTTP/1.1協議中,所有的請求頭,除Host外,都是可選的。

  GET / HTTP/1.1 Host: www.google.com  (末尾有一個空行。第一行指定方法、資源路徑、協議版本;第二行是在1.1版裡必帶的一個header作用於指定主機)

  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 (緊跟著一個空行,並且由HTML格式的文字組成了Google的主頁)  在HTTP1.0,單一TCP連線內僅執行一個“客戶端傳送請求—伺服器傳送應答”週期,之後釋放TCP連線。在HTTP1.1優化支援持續活躍連線:客戶端連續多次傳送請求、接收應答;批次多請求時,同一TCP連線在活躍(Keep-Live)間期內複用,避免重複TCP初始握手活動,減少網路負荷和響應週期。此外支援應答到達前繼續傳送請求(通常是兩個),稱為「流線化」(stream)。

  Gopher是1990年代早期被HTTP取代的內容傳遞協議。SPDY是Google開發的HTTP的替代方案,它被新版本的HTTP協議HTTP/2所取代。
超文字傳輸協定(,縮寫:HTTP)是一種用於分散式、協作式和超媒體資訊系統的應用層協議。HTTP是全球資訊網的資料通訊的基礎。