如何理解HTTP的無鏈接、短鏈接、長鏈接?

0. 前言

HTTP有個特色叫「無鏈接」,然而爲了達到可靠的傳輸數據,HTTP確定是依靠可靠鏈接的,那什麼叫「無鏈接」呢?html

1. 無鏈接?有鏈接?

無鏈接:限制每次鏈接只處理一個請求。服務器處理完客戶的請求,並收到客戶的應答後,即斷開鏈接。採用這種方式能夠節省傳輸時間。web

可見,HTTP不是字面意義上的沒有鏈接,事實上,這個定義也符合HTTP短鏈接的定義,但無鏈接強調的是HTTP的特性,短鏈接可理解爲一種實現瀏覽器

無鏈接的含義也能夠結合HTTP無狀態的含義在應用層面上去理解:每個請求都擁有本身的請求體,指望接收到惟一的對應的響應體,而每一次的請求都相互獨立,與上一次或下一次的請求毫無關係,哪怕是在同一條鏈接中(後面說的長鏈接)。也正由於這個特性,咱們在考慮業務代碼實現的時候,無需考慮請求之間的關係,只需考慮業務是如何在當前請求完成的。服務器

而HTTP真正的鏈接,根據計算機網絡體系的協議棧可知,是經過運輸層的TCP協議實現的,下層向上層提供了可靠的鏈接,上層屏蔽了下層的具體實現,全部的操做均在可靠的鏈接基礎之上。HTTP使用TCP的目的是爲了保證數據傳輸的可靠性和完整性。websocket

簡單來講就是:網絡

  • TCP的面向鏈接是基於網絡底層的數據傳輸。
  • HTTP的無鏈接是基於應用層面的溝通交互。

2. 從短鏈接到長鏈接

  • HTTP/0.9:最先發布的1991年0.9版,該時期的HTTP協議十分簡單,只支持Get請求,採用短鏈接的方式,也就是說,客戶端和服務器每進行一次HTTP操做,就創建一次鏈接,任務結束就中斷鏈接。當客戶端瀏覽器訪問的某個HTML或其餘類型的Web頁中包含有其餘的Web資源(如JavaScript文件、圖像文件、CSS文件等),每遇到這樣一個Web資源,瀏覽器就會從新創建一個HTTP會話。
  • HTTP/1.0:1996年發佈,默認使用短鏈接,提出長鏈接(也叫持久鏈接)的概念,但當時僅提供初步的支持。
  • HTTP/1.1:1999年發佈,默認使用長鏈接,用以保持鏈接特性。使用長鏈接的HTTP協議,會在響應頭加入這行代碼:
    Connection:keep-alive

在使用長鏈接的狀況下,當一個網頁打開完成後,客戶端和服務器之間用於傳輸HTTP數據的TCP鏈接不會關閉,客戶端再次訪問這個服務器時,會繼續使用這一條已經創建的鏈接。Keep-Alive不會永久保持鏈接,它有一個保持時間,能夠在不一樣的服務器軟件(如Apache)中設定這個時間。實現長鏈接須要客戶端和服務端都支持長鏈接。socket

HTTP協議的長鏈接和短鏈接,實質上是TCP協議的長鏈接和短鏈接。spa

TCP短鏈接長鏈接都由客戶端發起,而TCP長鏈接的保活功能主要爲服務器應用提供。若是客戶端已經消失而鏈接未斷開,則會使得服務器上保留一個半開放的鏈接,而服務器又在等待來自客戶端的數據,此時服務器將永遠等待客戶端的數據。保活功能就是試圖在服務端器端檢測到這種半開放的鏈接。也由於短鏈接、長鏈接的實如今HTTP以外,與HTTP無關,從HTTP自身來看,HTTP依然是無鏈接的。計算機網絡

3. HTTP的長鏈接和WebSocket的長鏈接

  • HTTP的長鏈接:HTTP/1.1經過使用Connection:keep-alive進行長鏈接。在一次 TCP 鏈接中能夠完成多個 HTTP 請求,可是對每一個請求仍然要單獨發 header,Keep-Alive不會永久保持鏈接,它有一個保持時間,能夠在不一樣的服務器軟件(如Apache)中設定這個時間。這種長鏈接是一種「僞連接」,並且只能由客戶端發送請求,服務端響應。
  • WebSocket的長鏈接,是一個全雙工的鏈接,可由服務端主動發起信息。長鏈接第一次TCP鏈路創建以後,後續數據能夠雙方都進行發送,不須要發送請求頭。

HTTP/1.1中雙方並無創建正真的鏈接會話,服務端能夠在任何一次請求完成後關閉。WebSocket 它自己就規定了是正真的、雙工的長鏈接,兩邊都必需要維持住鏈接的狀態。code

4. 從HTTP/1.1到HTTP/2

HTTP/1.1:pipelining
HTTP/1.1時期,持久鏈接(長鏈接)的弊端被提出 —— HOLB(Head of Line Blocking)即持久鏈接下一個鏈接中的請求仍然是串行的,若是某個請求出現網絡阻塞等問題,會致使同一條鏈接上的後續請求被阻塞。

所以,HTTP/1.1中提出了pipelining概念,即客戶端能夠在一個請求發送完成後不等待響應便直接發起第二個請求,服務端在返回響應時會按請求到達的順序依次返回,這樣就極大地下降了延遲。然而pipelining並無解決HOLB的問題,由於響應依然是串行返回的,pipelining也所以沒有被普遍接受。

SPDY和HTTP/2:multiplexing
multiplexing即多路複用,鏈接共享,在SPDY中提出,同時也在HTTP/2中實現。multiplexing技術可以讓多個請求和響應的傳輸徹底混雜在一塊兒進行,經過streamId來互相區別。這完全解決了HOLB問題,同時還容許給每一個請求設置優先級,服務端會先響應優先級高的請求。

pipelining和multiplexing的對比,如圖:
pipelining和multiplexing

SPDY是由Google推出的協議,HTTP工做組採用了SPDY v2草案做爲制定HTTP 2.0標準的起點。HTTP/2標準於2015年5月以RFC 7540正式發表。至此,SPDY完成了歷史的使命,退出歷史的舞臺。

5. 結語

該文參考瞭如下文章:


Copyright © 2018, CSCW back-end Kanarien, All Rights Reserved
相關文章
相關標籤/搜索