1、HTTP 協議與 TCP/IP 協議的關系
HTTP 的長連接和短連接本質上是 TCP 長連接和短連接。HTTP 屬于應用層協議,在傳輸層使用 TCP 協議,在網絡層使用 IP 協議。IP 協議主要解決網絡路由和尋址問題,TCP 協議主要解決如何在 IP 層之上可靠的傳遞數據包,使在網絡上的另一(yī)端收到發端發出的所有包,并且順序與發出順序一(yī)緻。TCP 有可靠,面向連接的特點。
2、如何理解HTTP協議是無狀态的
HTTP 協議是無狀态的,指的是協議對于事務處理沒有記憶能力,服務器不知(zhī)道客戶端是什麽狀态。也就是說,打開(kāi)一(yī)個服務器上的網頁和你之前打開(kāi)這個服務器上的網頁之間沒有任何聯系。HTTP 是一(yī)個無狀态的面向連接的協議,無狀态不代表 HTTP 不能保持 TCP 連接,更不能代表 HTTP 使用的是 UDP 協議(無連接)。
3、什麽是長連接、短連接?
短連接
連接->傳輸數據->關閉連接
HTTP是無狀态的,浏覽器和服務器每進行一(yī)次HTTP操作,就建立一(yī)次連接,但任務結束就中(zhōng)斷連接。
也可以這樣說:短連接是指Socket連接後發送後接收完數據後馬上斷開(kāi)連接。
長連接
連接->傳輸數據->保持連接 -> 傳輸數據-> 。。。->關閉連接。
長連接指建立Socket連接後不管是否使用都保持連接。
在 HTTP/1.0 中(zhōng),默認使用的是短連接。也就是說,浏覽器和服務器每進行一(yī)次 HTTP 操作,就建立一(yī)次連接,但任務結束就中(zhōng)斷連接。如果客戶端浏覽器訪問的某個 HTML 或其他類型的 Web 頁中(zhōng)包含有其他的 Web 資(zī)源,如JavaScript 文件、圖像文件、CSS 文件等;當浏覽器每遇到這樣一(yī)個 Web 資(zī)源,就會建立一(yī)個 HTTP 會話(huà)。
但從 HTTP/1.1 起,默認使用長連接,用以保持連接特性。使用長連接的 HTTP 協議,會在響應頭有加入這行代碼:
Connection:keep-alive
在使用長連接的情況下(xià),當一(yī)個網頁打開(kāi)完成後,客戶端和服務器之間用于傳輸 HTTP 數據的 TCP 連接不會關閉,如果客戶端再次訪問這個服務器上的網頁,會繼續使用這一(yī)條已經建立的連接。Keep-Alive 不會永久保持連接,它有一(yī)個保持時間,可以在不同的服務器軟件(如 Apache )中(zhōng)設定這個時間。實現長連接要客戶端和服務端都支持長連接。
HTTP 協議的長連接和短連接,實質上是 TCP 協議的長連接和短連接。
3.1 TCP 連接
當網絡通信時采用 TCP 協議時,在真正的讀寫操作之前,server 與 client 之間必須建立一(yī)個連接,當讀寫操作完成後,雙方不再需要這個連接 時它們可以釋放(fàng)這個連接,連接的建立是需要 3 次握手的,而釋放(fàng)則需要 4 次握手,所以說每個連接的建立都是需要資(zī)源消耗和時間消耗的。
3.2 TCP短連接
我(wǒ)(wǒ)們模拟一(yī)下(xià) TCP 短連接的情況,client 向 server 發起連接請求,server 接到請求,然後雙方建立連接。client 向 server 發送消息,server 回應client,然後一(yī)次讀寫就完成了,這時候雙方任何一(yī)個都可以發起 close 操作,不過一(yī)般都是 client 先發起 close 操作。爲什麽呢,一(yī)般的 server 不會回複完 client 後立即關閉連接的,當然不排除有特殊的情況。從上面的描述看,短連接一(yī)般隻會在 client/server 間傳遞一(yī)次讀寫操作
短連接的優點是:管理起來比較簡單,存在的連接都是有用的連接,不需要額外(wài)的控制手段。
3.3 TCP 長連接
接下(xià)來我(wǒ)(wǒ)們再模拟一(yī)下(xià)長連接的情況,client 向 server 發起連接,server 接受 client 連接,雙方建立連接。Client 與 server 完成一(yī)次讀寫之後,它們之間的連接并不會主動關閉,後續的讀寫操作會繼續使用這個連接。
首先說一(yī)下(xià) TCP/IP 詳解上講到的 TCP 保活功能,保活功能主要爲服務器應用提供,服務器應用希望知(zhī)道客戶主機是否崩潰,從而可以代表客戶使用資(zī)源。如果客戶已經消失,使得服務器上保留一(yī)個半開(kāi)放(fàng)的連接,而服務器又(yòu)在等待來自客戶端的數據,則服務器将應遠等待客戶端的數據,保活功能就是試圖在服務 器端檢測到這種半開(kāi)放(fàng)的連接。
如果一(yī)個給定的連接在兩小(xiǎo)時内沒有任何的動作,則服務器就向客戶發一(yī)個探測報文段,客戶主機必須處于以下(xià) 4 個狀态之一(yī):
客戶主機依然正常運行,并從服務器可達。客戶的TCP響應正常,而服務器也知(zhī)道對方是正常的,服務器在兩小(xiǎo)時後将保活定時器複位。
客戶主機已經崩潰,并且關閉或者正在重新啓動。在任何一(yī)種情況下(xià),客戶的 TCP 都沒有響應。服務端将不能收到對探測的響應,并在75秒後超時。服務器總共發送 10 個這樣的探測 ,每個間隔 75 秒。如果服務器沒有收到一(yī)個響應,它就認爲客戶主機已經關閉并終止連接。
客戶主機崩潰并已經重新啓動。服務器将收到一(yī)個對其保活探測的響應,這個響應是一(yī)個複位,使得服務器終止這個連接。
客戶機正常運行,但是服務器不可達,這種情況與 2 類似,TCP 能發現的就是沒有收到探查的響應。
3.4 長連接短連接操作過程
短連接的操作步驟是:
建立連接——數據傳輸——關閉連接…建立連接——數據傳輸——關閉連接
長連接的操作步驟是:
建立連接——數據傳輸…(保持連接)…數據傳輸——關閉連接
4、長連接和短連接的優點和缺點
由上可以看出,長連接可以省去(qù)較多的 TCP 建立和關閉的操作,減少浪費(fèi),節約時間。對于頻(pín)繁請求資(zī)源的客戶來說,較适用長連接。
不過這裏存在一(yī)個問題,存活功能的探測周期太長,還有就是它隻是探測 TCP 連接的存活,屬于比較斯文的做法,遇到惡意的連接時,保活功能就不夠使了。
在長連接的應用場景下(xià),client 端一(yī)般不會主動關閉它們之間的連接,client 與 server 之間的連接如果一(yī)直不關閉的話(huà),會存在一(yī)個問題,随着客戶端連接越來越多,server 早晚有扛不住的時候,這時候 server 端需要采取一(yī)些策略,如關閉一(yī)些長時間沒有讀寫事件發生(shēng)的連接,這樣可 以避免一(yī)些惡意連接導緻server 端服務受損;如果條件再允許就可以以客戶端機器爲顆粒度,限制每個客戶端的最大(dà)長連接數,這樣可以完全避免某個蛋疼的客戶端連累後端服務。
短連接對于服務器來說管理較爲簡單,存在的連接都是有用的連接,不需要額外(wài)的控制手段。但如果客戶請求頻(pín)繁,将在 TCP 的建立和關閉操作上浪費(fèi)時間和帶寬。
長連接和短連接的産生(shēng)在于 client 和 server 采取的關閉策略,具體(tǐ)的應用場景采用具體(tǐ)的策略,沒有十全十美的選擇,隻有合适的選擇。
5、什麽時候用長連接,短連接?
長連接多用于操作頻(pín)繁,點對點的通訊,而且連接數不能太多情況。每個 TCP 連接都需要三步握手,這需要時間,如果每個操作都是先連接,再操作的話(huà)那麽處理速度會降低很多,所以每個操作完後都不斷開(kāi),次處理時直接發送數據包就 OK 了,不用建立 TCP 連接。例如:數據庫的連接用長連接, 如果用短連接頻(pín)繁的通信會造成 socket 錯誤,而且頻(pín)繁的 socket 創建也是對資(zī)源的浪費(fèi)。
而像 WEB 網站的 http 服務一(yī)般都用短鏈接,因爲長連接對于服務端來說會耗費(fèi)一(yī)定的資(zī)源,而像 WEB 網站這麽頻(pín)繁的成千上萬甚至上億客戶端的連接用短連接會更省一(yī)些資(zī)源,如果用長連接,而且同時有成千上萬的用戶,如果每個用戶都占用一(yī)個連接的話(huà),那可想而知(zhī)吧。所以并發量大(dà),但每個用戶無需頻(pín)繁操作情況下(xià)需用短連好。
6、長連接和短連接的生(shēng)命周期有多久?
短連接在建立連接後,完成一(yī)次讀寫就會自動關閉了。
正常情況下(xià),一(yī)條TCP長連接建立後,隻要雙不提出關閉請求并且不出現異常情況,這條連接是一(yī)直存在的,操作系統不會自動去(qù)關閉它,甚至經過物(wù)理網絡拓撲的改變之後仍然可以使用。所以一(yī)條連接保持幾天、幾個月、幾年或者更長時間都有可能,隻要不出現異常情況或由用戶(應用層)主動關閉。
在編程中(zhōng),往往需要建立一(yī)條TCP連接,并且長時間處于連接狀态。所謂的TCP長連接并沒有确切的時間限制,而是說這條連接需要的時間比較長。
7、怎樣檢測長連接是否中(zhōng)斷?
1、在應用層使用heartbeat來主動檢測
對于實時性要求較高的網絡通信程序,往往需要更加及時的獲取已經中(zhōng)斷的連接,從而進行及時的處理。但如果對方的連接異常中(zhōng)斷,往往是不能及時的得到對方連接已經中(zhōng)斷的信息,操作系統檢測連接是否中(zhōng)斷的時間間隔默認是比較長的,即便它能夠檢測到,但卻不符合我(wǒ)(wǒ)們的實時性需求,所以需要我(wǒ)(wǒ)們進行手工(gōng)去(qù)不斷探測。
2、改變socket的keepalive選項,以使socket檢測連接是否中(zhōng)斷的時間間隔更小(xiǎo),以滿足我(wǒ)(wǒ)們的及時性需求。有關的幾個選項使用和解析如下(xià):
A、我(wǒ)(wǒ)們在檢測對端以一(yī)種非優雅的方式斷開(kāi)連接的時候,可以設置SO_KEEPALIVE屬性使得我(wǒ)(wǒ)們在2小(xiǎo)時以後發現對方的TCP連接是否依然存在。用法如下(xià):
keepAlive = 1;setsockopt(listenfd, SOL_SOCKET, SO_KEEPALIVE, (void*)&keepAlive, sizeof(keepAlive));
B、如果我(wǒ)(wǒ)們不想使用這麽長的等待時間,可以修改内核關于網絡方面的配置參數,也可設置SOCKET的TCP層(SOL_TCP)選項TCP_KEEPIDLE、TCP_KEEPINTVL和TCP_KEEPCNT。
TCP_KEEPIDLE:開(kāi)始首次KeepAlive探測前的TCP空閉時間(默認2h)
TCP_KEEPINTVL:兩次KeepAlive探測間的時間間隔(默認75s)
TCP_KEEPCNT:斷開(kāi)前的KeepAlive探測次數
如果心跳函數要維護客戶端的存活,即服務器必須每隔一(yī)段時間必須向客戶段發送一(yī)定的數據,那麽使用SO_KEEPALIVE是有很大(dà)的不足的。因爲SO_KEEPALIVE選項指"此套接口的任一(yī)方向都沒有數據交換"。在Linux 2.6系列上,上面話(huà)的理解是隻要打開(kāi)SO_KEEPALIVE選項的套接口端檢測到數據發送或者數據接受就認爲是數據交換。因此在這種情況下(xià)使用 SO_KEEPALIVE選項 檢測對方是否非正常連接是完全沒有作用的,在每隔一(yī)段時間發包的情況, keep-alive的包是不可能被發送的。上層程序在非正常斷開(kāi)的情況下(xià)是可以正常發送包到緩沖區的。非正常端開(kāi)的情況是指服務器沒有收到"FIN" 或者 "RST"包。