1.應用場景
| 根據具體的場景選擇合适的技術 長連接配接: 見下方 短連接配接: 見下方 |
2.學習/操作
| 1. HTTP協定與TCP/IP協定的關系 HTTP的長連接配接和短連接配接本質上是TCP長連接配接和短連接配接。 HTTP屬于應用層協定，在傳輸層使用TCP協定，在網絡層使用IP協定。 IP協定主要解決網絡路由和尋址問題，TCP協定主要解決如何在IP層之上可靠地傳遞資料包，使得網絡上接收端收到發送端所發出的所有包，并且順序與發送順序一緻。TCP協定是可靠的、面向連接配接的。 2. 如何了解HTTP協定是無狀态的 HTTP協定是無狀态的，指的是協定對于事務處理沒有記憶能力，伺服器不知道用戶端是什麼狀态。也就是說，打開一個伺服器上的網頁和上一次打開這個伺服器上的網頁之間沒有任何聯系。HTTP是一個無狀态的面向連接配接的協定，無狀态不代表HTTP不能保持TCP連接配接，更不能代表HTTP使用的是UDP協定（無連接配接）。 3. 什麼是長連接配接、短連接配接？ 在HTTP/1.0中預設使用短連接配接。也就是說，用戶端和伺服器每進行一次HTTP操作，就建立一次連接配接，任務結束就中斷連接配接。當用戶端浏覽器通路的某個HTML或其他類型的Web頁中包含有其他的Web資源（如JavaScript檔案、圖像檔案、CSS檔案等），每遇到這樣一個Web資源，浏覽器就會重建立立一個HTTP會話. 而從HTTP/1.1起，預設使用長連接配接，用以保持連接配接特性。使用長連接配接的HTTP協定，會在響應頭加入這行代碼：  在使用長連接配接的情況下，當一個網頁打開完成後，用戶端和伺服器之間用于傳輸HTTP資料的TCP連接配接不會關閉，用戶端再次通路這個伺服器時，會繼續使用這一條已經建立的連接配接。Keep-Alive不會永久保持連接配接，它有一個保持時間，可以在不同的伺服器軟體（如Apache）中設定這個時間。實作長連接配接需要用戶端和服務端都支援長連接配接。 HTTP協定的長連接配接和短連接配接，實質上是TCP協定的長連接配接和短連接配接。 3.1. TCP連接配接 當網絡通信時采用TCP協定時，在真正的讀寫操作之前，用戶端與伺服器端之間必須建立一個連接配接，當讀寫操作完成後，雙方不再需要這個連接配接時可以釋放這個連接配接。連接配接的建立依靠“三次握手”，而釋放則需要“四次握手”，是以每個連接配接的建立都是需要資源消耗和時間消耗的。 經典的三次握手建立連接配接示意圖：  3.2. TCP短連接配接 模拟一下TCP短連接配接的情況：client向server發起連接配接請求，server接到請求，然後雙方建立連接配接。client向server發送消息，server回應client，然後一次請求就完成了。這時候雙方任意都可以發起close操作，不過一般都是client先發起close操作。上述可知，短連接配接一般隻會在 client/server間傳遞一次請求操作。 短連接配接的優點是：管理起來比較簡單，存在的連接配接都是有用的連接配接，不需要額外的控制手段。 3.3. TCP長連接配接 我們再模拟一下長連接配接的情況：client向server發起連接配接，server接受client連接配接，雙方建立連接配接，client與server完成一次請求後，它們之間的連接配接并不會主動關閉，後續的讀寫操作會繼續使用這個連接配接。 TCP的保活功能主要為伺服器應用提供。如果用戶端已經消失而連接配接未斷開，則會使得伺服器上保留一個半開放的連接配接，而伺服器又在等待來自用戶端的資料，此時伺服器将永遠等待用戶端的資料。保活功能就是試圖在服務端器端檢測到這種半開放的連接配接。 如果一個給定的連接配接在兩小時内沒有任何動作，伺服器就向客戶發送一個探測封包段，根據用戶端主機響應探測4個用戶端狀态： 客戶主機依然正常運作，且伺服器可達。此時客戶的TCP響應正常，伺服器将保活定時器複位。 客戶主機已經崩潰，并且關閉或者正在重新啟動。上述情況下用戶端都不能響應TCP。服務端将無法收到用戶端對探測的響應。伺服器總共發送10個這樣的探測，每個間隔75秒。若伺服器沒有收到任何一個響應，它就認為用戶端已經關閉并終止連接配接。 用戶端崩潰并已經重新啟動。伺服器将收到一個對其保活探測的響應，這個響應是一個複位，使得伺服器終止這個連接配接。 客戶機正常運作，但是伺服器不可達。這種情況與第二種狀态類似。 4. 長連接配接和短連接配接的優點和缺點 由上可以看出，長連接配接可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間。對于頻繁請求資源的用戶端适合使用長連接配接。在長連接配接的應用場景下，client端一般不會主動關閉連接配接，當client與server之間的連接配接一直不關閉，随着用戶端連接配接越來越多，server會保持過多連接配接。這時候server端需要采取一些政策，如關閉一些長時間沒有請求發生的連接配接，這樣可以避免一些惡意連接配接導緻server端服務受損；如果條件允許則可以限制每個用戶端的最大長連接配接數，這樣可以完全避免惡意的用戶端拖垮整體後端服務。 短連接配接對于伺服器來說管理較為簡單，存在的連接配接都是有用的連接配接，不需要額外的控制手段。但如果客戶請求頻繁，将在TCP的建立和關閉操作上浪費較多時間和帶寬。 長連接配接和短連接配接的産生在于client和server采取的關閉政策。不同的應用場景适合采用不同的政策。 由上可以看出，長連接配接可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間。對于頻繁請求資源的客戶來說，較适用長連接配接。不過這裡存在一個問題，存活功能的探測周期太長，還有就是它隻是探測TCP連接配接的存活，屬于比較斯文的做法，遇到惡意的連接配接時，保活功能就不夠使了。在長連接配接的應用場景下，client端一般不會主動關閉它們之間的連接配接，Client與server之間的連接配接如果一直不關閉的話，會存在一個問題，随着用戶端連接配接越來越多，server早晚有扛不住的時候，這時候server端需要采取一些政策，如關閉一些長時間沒有讀寫事件發生的連接配接，這樣可 以避免一些惡意連接配接導緻server端服務受損；如果條件再允許就可以以用戶端機器為顆粒度，限制每個用戶端的最大長連接配接數，這樣可以完全避免某個蛋疼的用戶端連累後端服務。 短連接配接對于伺服器來說管理較為簡單，存在的連接配接都是有用的連接配接，不需要額外的控制手段。但如果客戶請求頻繁，将在TCP的建立和關閉操作上浪費時間和帶寬。 長連接配接和短連接配接的産生在于client和server采取的關閉政策，具體的應用場景采用具體的政策，沒有十全十美的選擇，隻有合适的選擇。 長連接配接/短連接配接操作過程 短連接配接的操作步驟是： 建立連接配接——資料傳輸——關閉連接配接...建立連接配接——資料傳輸——關閉連接配接 長連接配接的操作步驟是： 建立連接配接——資料傳輸...（保持連接配接）...資料傳輸——關閉連接配接 什麼時候用長連接配接，短連接配接？ 長連接配接多用于操作頻繁，點對點的通訊，而且連接配接數不能太多情況。每個TCP連接配接都需要三步握手，這需要時間，如果每個操作都是先連接配接，再操作的話那麼處理速度會降低很多，是以每個操作完後都不斷開，次處理時直接發送資料包就OK了，不用建立TCP連接配接。 例如：資料庫的連接配接用長連接配接， 如果用短連接配接頻繁的通信會造成socket錯誤，而且頻繁的socket建立也是對資源的浪費。 而像WEB網站的http服務一般都用短連接配接，因為長連接配接對于服務端來說會耗費一定的資源，而像WEB網站這麼頻繁的成千上萬甚至上億用戶端的連接配接用短連接配接會更省一些資源，如果用長連接配接，而且同時有成千上萬的使用者，如果每個使用者都占用一個連接配接的話，那可想而知,是以并發量大，但每個使用者無需頻繁操作情況下需用短連接配接好。 |
3.問題
| 1.如何設定長連接配接? HTTP/1.0中設定請求頭中設定Connection:keep-alive, 即為長連接配接 2.總結? 如果業務來往比較頻繁，則選擇長連接配接。 如果server要主動給client發資料，則選擇長連接配接。 |
4.參考
| https://www.cnblogs.com/gotodsp/p/6366163.html https://baike.baidu.com/item/%E9%95%BF%E8%BF%9E%E6%8E%A5 https://www.jianshu.com/p/b68d2b26f5f4 //http和socket之長連接配接和短連接配接差別 https://www.jianshu.com/p/813e89e115a8 //如何選擇TCP長連接配接與短連接配接 |
後續補充
...