1. 長連接與短連接的區別，對web網頁的壓力區別大么
沒區別，只是盡量短點，對優化有點好處，畢竟有的有字數限制
2. 由WebRTC談起
原生支持： iOS13開始，使用URLSessionWebSocketTask類可實現像發送HTTP請求一樣的WebSocket功能。如果要對Web套接字（包括客戶端和伺服器支持）進行較低級別的控制，請查看Network框架： https://developer.apple.com/documentation/network 。
一、Socket
是對TCP/IP 協議的封裝，本質並不是一個協議，是應用層與 TCP/IP 協議族通信的中間軟體抽象層（類似於對底層的封裝），它是一組介面，讓你在使用的時候更方便操作。
二、WebSocket協議
是HTML5下一種新的協議，也是基於TCP的一種網路協議，它實現了 瀏覽器/客戶端 與 伺服器 全雙工(full-plex)通信——連接成功以後允許伺服器或客戶端的任何一方主動發送信息給對方。WebSocket協議由兩部分組成： 握手 和 數據傳輸 。Websocket是一個持久化的協議，只需要一次成功的HTTP握手，服務端會一直保留握手成功時的信息，直到客戶端或服務端關閉請求。
創建了WebSocket後，會有一個HTTP請求發送到伺服器以發起連接。取得伺服器響應後，建立的連接使用HTTP升級，從 HTTP協議 交換為 WebSocket協議 。WebSocket使用了自定義的協議，未加密的連接不再是 http:// ，而是 ws:// ，默認埠為 80 ；加密的連接也不是 https:// ，而是 wss:// ，默認埠為 443 。即，使用標準的HTTP伺服器無法實現WebSocket，只有支持WebSocket協議的伺服器才能正常工作。一旦WebSocket連接建立後，後續數據都以 幀序列 的形式傳輸。
WebSocket協議的特點包括：
（1）建立在 TCP 協議之上。
（2）與 HTTP 協議有著良好的兼容性。握手階段採用 HTTP 協議，默認埠也是80和443，因此握手時不容易屏蔽，能通過各種 HTTP 代理伺服器。
（3）數據格式比較輕量，性能開銷小，通信高效。如何體現通信高效？WebSocket通信格式沒有HTTP協議那麼多的固定報頭，且不用重復建立連接。
（4）可以發送文本，也可以發送二進制數據。
（5）沒有同源限制，客戶端可以與任意伺服器通信。（什麼是同源限制？協議相同，域名相同，埠相同。目的是為了保證用戶信息的安全，防止惡意的網站竊取數據。）
（6）協議標識符是ws（如果加密，則為wss），伺服器網址就是 URL。
（7）WebSocket通信協議於2011年被IETF定為標准RFC 6455，WebSocket API被W3C定為標准。
WebSocket如何實現長鏈接 ？創建了WebSocket後，會有一個HTTP請求發送到伺服器以發起連接。取得伺服器響應後，建立的連接使用HTTP升級，從HTTP協議交換為WebSocket協議。只需要一次成功的HTTP握手，服務端會一直保留握手成功時的信息，直到客戶端或服務端關閉請求。WebSocket之所以能持久連接原因是它運行在TCP協議上，TCP協議自身是長連接協議，所以WebSocket當然可以長連接啦。
WebSocket如何管理連接 ？RFC6455-5.5意見稿指明：WebSocket協議定義了Control Frame 控制幀。WebSocket的控制幀有： Close 、 Ping 、 Pong 。
Close幀 ：發起關閉請求；
Ping幀 ：通信發起方確認鏈路是否暢通的報文；
Pong幀 ：通信接收方回應鏈路是否暢通的報文。
WebSocket在建立連接之後，通信的基本數據幀格式如下圖（來源RFC6455-5.2）沒有Http協議那麼多固定的報頭，且不用重復建立連接，所以通信效率高：
WebSocket連接的生命周期：
CONNECTING ：使用Http發起請求，RFC6455-4（ https://tools.ietf.org/html/rfc6455#section-4 ）規定了Client和Server的報文格式。Server在響應時使用Http狀態碼是101（切換協議）。在握手時，WebSocket連接處於CONNECTING狀態。
OPEN ：握手成功之後，進入OPEN狀態。
CLOSING ：如果一方發起了CLOSE幀，那麼便標志著WebSocket連接進入了CLOSING狀態；
CLOSED ：當TCP連接關閉之後，那麼WebSocet連接便進入了CLOSED狀態。
三、WebRTC
名稱源自 網頁實時通信 （Web Real-Time Communication）的縮寫，是谷歌2010年以6820萬美元收購Global IP Solutions公司而獲得的一項技術，由Google、Mozilla和Opera等支持的、免費的開放式項目。通過簡單的API為瀏覽器和移動應用程序提供跨平台的 音視頻實時通信 （RTC：Real-Time Communications ）功能。WebRTC使得開發者在瀏覽器無需安裝任何插件就可以實現音視頻通信。
WebRTC提供了跨平台的音視頻核心技術，包括音視頻的採集、編解碼、網路傳輸、顯示等功能，支持的平台：Windows、Linux、Mac、Android及iOS。RTCPeerConnection是用於進行WebRTC調用以流式傳輸視頻和音頻以及交換數據的API，WebRTC使用RTCPeerConnection(對等連接)在瀏覽器之間傳遞 流數據 ，但也需要一種協調通信和發送控制消息的機制，這一過程稱為 信令 。信令處理過程需要客戶端之間來回傳遞消息，這個過程在WebRTC裡面是沒有實現的，需要自己創建。即WebRTC未指定信令方法和協議，需要開發者確保使用安全協議。所有WebRTC組件都必須進行加密，即 WebRTC是安全的 （如何保證安全？）。WebRTC這種技術可以讓開發者的精力集中在用戶體驗上而不是媒體流本身，因為API就會處理好媒體引擎的相關工作。
WebRTC 1.0 的重點是提供給開發者更多對媒體、數據通道的控制。而根據此前的提案（見後面的提案連接）顯示，下一版本的 WebRTC 將有可能使數據處理脫離主線程。使用 RTCDataChannels 傳輸數據，相比使用 WebSocket 會有更好的擁塞控制。（該段內容筆者未確認）
參考連接： http://www.sohu.com/a/275427719_458408
提案連接： https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf
如何保證安全 ：當連通性檢測完成後，WebRTC會開啟 DTLS （Datagram TLS）握手，用於協商出SRTP中加密RTP包的 對稱秘鑰 。該過程稱為DTLS-SRTP，保證了數據傳輸的安全性。
參考： https://imweb.io/topic/5a4a6cb2a192c3b460fce37f
RTP/RTCP 和 SRTP/SRTCP協議是什麼？參考： https://blog.csdn.net/thinkerleo1997/article/details/80233530
基本概念：
SDP ： 即會話描述協議（Session Description Protocol ），主要保存當前會話的媒體和傳輸信息，其中媒體信息包括 媒體類型 、 傳輸協議 、 媒體格式 等，傳輸信息包括媒體的遠程 地址信息 、 帶寬 等；它由多行KV格式的文本信息組成，具體可參考這里（ https://tools.ietf.org/pdf/draft-nandakumar-rtcweb-sdp-08.pdf ）。WebRTC通過 信令 建立一個SDP握手的過程，只有通過SDP握手，雙方才知道對方的信息，這是建立p2p通道的基礎。
Offer ： 通信的發起方對自己的sdp描述
Answer ： 通信的接收方對自己的sdp描述
信令 ：協商通信過程，傳遞基本的數據信息，其中包括SDP描述信息、會話控制信息（節點加入、退出及各類的業務控制信息等）、網路信息、錯誤信息等。是指控制建立連接和斷開連接的狀態的數據。在建立連接之前，信令必須發生在 帶外 （通過伺服器），但一旦建立連接，就可以通過已經建立的通道發送更新信令（如掛斷）。（這里要了解一下什麼叫「帶外（OOB：Out-Of-Band）」，網路： https://ke..com/item/out-of-band/15801641?fr=aladdin ）
OOB概述 ：傳輸層協議使用 帶外數據 （out-of-band，OOB）來發送一些重要的數據，如果通信一方有重要的數據需要通知對方時，協議能夠將這些數據快速地發送到對方。為了發送這些數據，協議一般不使用與 普通數據 相同的通道，而是使用另外的通道。linux系統的套接字機制支持低層協議發送和接受帶外數據。但是TCP協議沒有真正意義上的帶外數據。為了發送重要協議，TCP提供了一種稱為 緊急模式 （urgent mode）的機制。TCP協議在數據段中設置 URG 位，表示進入緊急模式。接收方可以對緊急模式採取特殊的處理。很容易看出來，這種方式數據不容易被阻塞，並且可以通過在我們的伺服器端程序裡面捕捉 SIGURG 信號來及時接受數據。
信令通道 ：與服務端建立連接和斷開連接的通道，對於WebRTC而言就是信令通道。
STUN 伺服器：是用來取外網地址的。
TURN 伺服器：是在P2P失敗時進行轉發的，中繼轉發。
STUN 和 TURN 伺服器的作用主要處理打洞與轉發，配合完成 ICE協議 。
ICE ：Interactive Connectivity Establishment，互動式連接建立。
WebRTC通信
基於WebRTC的點對點音視頻通信流程如下：
1）客戶端A初始化本地音視頻設備，創建一個用於Offer的SDP對象，該對象中保存當前音視頻的相關信息；
2）客戶端A通過信令伺服器將SDP信息發送給客戶端B；
3）客戶端B接收到A的SDP信息後保存，初始化本地音視頻設備並創建用於Answer的SDP對象；
4）客戶端B通過信令伺服器將SDP信息發送給客戶端A；
5）客戶端A、B通過交換SDP等信息，建立P2P通道進行音視頻傳輸；
示意圖如下圖所示：
WebRTC ICE（互動式連接建立）(ICE：Interactive Connectivity Establishment)
以下是呼叫信令期間發生的消息交換的高級過程，即： WebRTC 信令交互流程圖 ：
************************************************開始************************************************
##關鍵詞
--[SOMETHING]-->：表示從主叫方發送給被叫方的「SOMETHING」類型的消息。另一解釋是： 主叫方所要執行操作 。
<--[SOMETHING]--：表示從被叫方發送給主叫方的「SOMETHING」類型的消息。另一解釋是： 被叫方所要執行的操作 。
SS (Signal Service)：通過伺服器發送的信息（通過BCM 伺服器發送的信息）
DC (Data Channel)：通過WebRTC 數據通道 發送的消息
### Message Exchange / State Flow Overview （消息交換/狀態流概述）
| Caller（主叫方） | Callee（被叫方） |
+----------------------------+-------------------------+
開始撥出電話：`handleOutgoingCall`...
--[SS.CallOffer]-->
…並開始生成iceCandidate候選，先保存在本地。iceCandidate裡麵包含了SDP、公網地址、用來標識當前ice中流媒體的id(sdpMid)，這個公網地址是由STUN、TURN Server發過來的。
當生成iceCandidate候選後，將會調用方法`handleLocalAddedIceCandidate` ，並把這些iceCandidate保存起來。
被叫方收到來電，通過 `handleReceivedOffer` 發送呼叫應答
<--[SS.CallAnswer]--
1. 開始生成iceCandidate候選。
2. 立即通過`handleLocalAddedIceCandidate` 將它們發送給主叫方。
<--[SS.ICEUpdate]-- (多次發送)
主叫方收到應答後調用方法: `handleReceivedAnswer`，接著發送所有前面保存的iceCandidate候選 (在此之後生成的iceCandidate候選會立即發送)
--[SS.ICEUpdates]--> (多次發送)
完成交換iceCandidate候選後…（此時表示雙方身份已確認，接下來會通過P2P通道建立音視頻會話，這里會涉及NAT技術，有可能失失敗。如果失敗，主叫方會一直顯示呼叫中，被叫方不會顯示任何界面）雙方都調用方法: `handleIceConnected`
顯示遠程鈴聲用戶界面
1.連接到提供的數據通道
2.顯示來電界面
3.如果被叫人接聽電話
4.發送連接消息
<--[DC.ConnectedMesage]--
接收到的連接消息後顯示呼叫已連接。
主叫方掛斷（被叫方同樣可以掛斷）調用方法：
--[DC.Hangup]-->
--[SS.Hangup]-->
************************************************結束************************************************
上面的消息交換可以整理為如下的簡化版的WebRTC建立連接過程：
1）主叫方通過 createOffer 生成 SDP 描述
2）主叫方通過 setLocalDescription，設置本地的描述信息
3）主叫方將 offer SDP 發送給被叫方
4）被叫方通過 setRemoteDescription，設置遠端的描述信息
5）被叫方通過 createAnswer 創建出自己的 SDP 描述
6）被叫方通過 setLocalDescription，設置本地的描述信息
7）被叫方將 anwser SDP 發送給主叫方
8）主叫方通過 setRemoteDescription，設置遠端的描述信息。
只有通過 SDP握手 ，雙方才知道對方的信息，這是建立p2p通道的基礎。 通過SDP握手後，客戶端之間就會建立起一個點對點的直接通訊通道。但是由於我們所處的網路環境錯綜復雜，用戶可能處在私有內網內，使用p2p傳輸時，將會遇到 NAT (網路地址轉換)以及防火牆等阻礙。這個時候我們就需要在SDP握手時，通過STUN/TURN/ICE相關 NAT穿透技術 (也有稱為 打洞 或 穿牆 技術)來保障p2p鏈接的建立。
WebRTC的視頻部分 ，包含採集、編解碼(I420/VP8)、加密、媒體文件、圖像處理、顯示、網路傳輸與流控(RTP/RTCP)等功能。
視頻採集支持多種媒體類型，比如I420、YUY2、RGB、UYUY等，並可以進行幀大小和幀率控制。
WebRTC採用I420/VP8編解碼技術。VP8是Google收購ON2後的開源實現，並且也用在WebM項目中。VP8能以更少的數據提供更高質量的視頻，特別適合視頻會議這樣的需求。
視頻加密是WebRTC的video_engine一部分，相當於視頻應用層面的功能，給點對點的視頻雙方提供了數據上的安全保證，可以防止在Web上視頻數據的泄漏。
視頻加密在發送端和接收端進行加解密視頻數據，密鑰由視頻雙方協商，代價是會影響視頻數據處理的性能；也可以不使用視頻加密功能，這樣在性能上會好些。
視頻加密的數據源可能是原始的數據流，也可能是編碼後的數據流。估計是編碼後的數據流，這樣加密代價會小一些，需要進一步研究。
WebRTC的音頻部分 ，包含設備、編解碼(iLIBC/iSAC/G722/PCM16/RED/AVT、NetEQ)、加密、聲音文件、聲音處理、聲音輸出、音量控制、音視頻同步、網路傳輸與流控(RTP/RTCP)等功能。
WebRTC採用iLIBC/iSAC/G722/PCM16/RED/AVT編解碼技術。
WebRTC還提供NetEQ功能---抖動緩沖器及丟包補償模塊，能夠提高音質，並把延遲減至最小。
另外一個核心功能是基於語音會議的混音處理。
聲音處理針對音頻數據進行處理，包括回聲消除(AEC)、AECM(AEC Mobile)、自動增益(AGC)、降噪(NS)、靜音檢測(VAD)處理等功能，用來提升聲音質量。
丟包補償原理是什麼？
自動增益（AGC：Automatic Gain Control）概念？
TCP協議 ：屬於傳輸層，是可靠的、面向連接的。主要解決如何在IP層之上可靠地傳遞數據包，使得網路上接收端收到發送端所發出的所有包，並且順序與發送順序一致。TCP連接的建立依靠「三次握手」，而釋放則需要「四次握手」。
IP協議 ：屬於網路層，主要解決 網路路由和定址 問題。
Http協議 ：屬於應用層協議，一個簡單的請求-響應協議，是一種無狀態、非持久的協議，是被動性的，也就是只能客戶端發起。服務端不保留上一次與客戶端交互時的任何狀態，每次都要重新傳輸 identity info （鑒別信息），來告訴服務端你是誰。HTTP的長連接和短連接本質上是TCP長連接和短連接。HTTP1.1支持keep-alive。
Http與WebSocket區別與聯系
（1）Http與WebSocket是兩個完全不同的協議，都是基於TCP的。兩者唯一的聯系是WebSocket利用Http進行握手；具體說明請看：RFC6455-1.7( https://tools.ietf.org/html/rfc6455#section-5.5 )
（2）WS默認也使用80埠；WSS默認也使用443埠。
（3）Http協議局限性一大堆，比如明文傳輸、無法保證信息完整性、沒有身份驗證等。而WebSocket的出現則是為了解決Http協議只能由Client發起通信請求的問題。WebSocket是 全雙工通信 。
（4）HTTP是運行在TCP協議傳輸層上的應用協議，而WebSocket是通過HTTP協議協商如何連接，然後獨立運行在TCP協議傳輸層上的應用協議。
WebSocket僅僅是利用了HTTP協議做連接請求。WebSocket相當於一個簡化版的TCP傳輸子層（實際上WebSocket也是應用層協議）。WebSocket之所以能持久連接原因是它運行在TCP協議上，TCP協議自身是長連接協議，所以WebSocket當然可以長連接啦。如果你要問為什麼HTTP不是長連接，原因是早期的HTTP在發起每個請求，響應完成後就會關閉Socket。但是後來加了多路復用KeepAlive協議後HTTP協議已經可以實現長連接了，可以處理長連接事務了。至於添加WebSocket特性，是為了更好、更靈活，輕量的與伺服器通訊。因為WebSocket提供了簡單的消息規范，可以更快的適應長連接的環境，其實現在HTTP協議自身就可以做，但是不太輕便，因為HTTP是一種無狀態、非持久的協議，是被動性的，也就是只能客戶端發起。服務端不保留上一次與客戶端交互時的任何狀態，每次都要重新傳輸 identity info （鑒別信息），來告訴服務端你是誰，每次請求和應答都帶有完整的Http頭，佔用網路傳輸帶寬，增加了每次傳輸的數據量。為什麼HTML4不支持WebSocket？原因是WebSocket的協商機制HTML4底層API沒有實現。
WebSocket與Socket是沒什麼關系的
WebSocket協議 和 Http協議： 都是基於TCP的，所以他們都是可靠的協議，是在應用層。
Socket： 是對TCP/IP 協議的封裝，本質並不是一個協議，是應用層與 TCP/IP 協議族通信的中間軟體抽象層（類似於對底層的封裝），它是一組介面，讓你在使用的時候更方便操作。
WebSocket與WebRTC(Web Real-Time Communication)是什麼關系？
WebSocket： 是WebRTC的基礎，為WebRTC負責客服端發現和數據轉發。
TCP協議 ：參考 https://blog.csdn.net/Awille/article/details/79748193
SocketRocket ：Facebook的開源框架
WebRTC開發和VoIP開發之間有什麼區別與聯系？
待完善知識點：WebRTC移動端兼容性檢測，如何配置MediaStreamConstraints， 信令(iceCandidate, sessionDescription)傳輸方式的選擇，iceCandidate和sessionDescription設置的先後順序，STUN和TURN的概念，如何實現截圖及錄制視頻及上傳圖片和視頻功能，如何高效跟蹤錯誤？
WebRTC擁塞控制和碼率調節策略是怎麼樣的？在弱網環境下如何保證圖像不失真？
猜：好像是改RTCRtpEncodingParameters這個類里的ssrc參數。是改采樣頻率？
參考資料：
WebRTC網路： https://ke..com/item/WebRTC/5522744?fr=aladdin
WebRTC基礎知識： https://webrtc.org.cn/category/basic/
GoogleWebRTC-pod安裝文檔：https:// cocoapods.org/pods/GoogleWebRTC
GoogleWebRTC-iOS官網： https://webrtc.org/native-code/ios/
3. 什麼是長連接，什麼是短連接長連接和短連接的區別是什麼
長連接
一般指
TCP連接
連接時間較長，或者連接上就不斷開。
這種連接比較穩定
相對於UDP無連接而言，安全性更高，但是系統消耗的資源也更多
短連接
一般指
Http連接
短連接
連接時間短
一般數據發送後就關閉連接
系統資源消耗較少
不用資源去維持連接
但是不適合數據量大
或者大量重復請求數據
這樣反而消耗資源更高
4. 【小白學爬蟲筆記】持久連接、非持久連接
1. 對比
HTTP 0.9 已過時
HTTP1.0：非持續連接，每個連接只處理一個請求響應事務，有些伺服器端甚至還在用此，可以在一定時間內復用連接，具體復用時間的長短可以由伺服器控制，一般在15s左右。
HTTP 1.1 默認使用持續連接，不必為每一個WEB對象建立一個新的連接，一個連接可以傳送多個對象，但是伺服器端可能還是會設置一個限制，太長時間沒有讀寫事件，伺服器可能關閉之。
HTTP 2.0 多路復用（一個域只要一個TCP連接）實現真正的並發請求，降低延時，提高了帶寬的利用率。
在持久連接或者HTTP pipelining出現之前，每個連接的獲取都需要創建一個獨立的TCP連接。
2. 非持久連接示意
每個WEB對象都要建立新的連接。
假設某簡單頁麵包含1個HTML，2個PNG圖像，且都存儲在一台伺服器主機中。
客戶端輸入URL訪問首頁，http://www.abcdefg.com/path/index.html
第一步，客戶端與伺服器主機中的HTTP服務埠（默認為）建立TCP連接
第二步，客戶端發送HTTP請求/path/index.html
第三步，伺服器接收請求消息，從伺服器主機內存或硬碟拿去拿對象/sompath/index.html，發出該對象的響應。
第四步，伺服器告知TCP關閉這個TCP連接(TCP要等客戶收到這個響應消息後，才會真正終止這個連接)。
第五步，HTTP客戶接收響應消息。TCP連接終止。 該消息標明所拆裝的對象是一個HTML文件。客戶取出文件，分析後發現2個JPEG對象的引用。
第六步， 給每一個引用到的JPEG對象重復第一步到第四步
非持久連接，每個對象有2個RTT延遲
持久連接，帶管道線，所有引用對象，共經歷一個RTT延時；
持久連接，無管道線，每個引用對象一個RTT延時。
首先：HTTP的長連接和短連接本質上是TCP長連接和短連接。
1. 在HTTP1.0中，默認的是短連接，沒有正式規定 Connection:Keep-alive 操作；
在 HTTP1.1 中所有連接都是Keep-alive的，也就是默認都是持續連接的（Persistent Connection）。
2. 兩種的連接方式的區別如下圖所示
3. 從上圖可以看出，客戶端與伺服器建立持續連接後，在連接期間可以處理多個請求/響應（Request/Response）
HTTP權威指南：
HTTP/1.1 允許HTTP設備在事務處理結束以後將TCP連接保持在打開狀態，後面的HTTP Request/Response 依然可以通過這個TCP連接繼續傳送。
在事務結束之後仍然保持在打開狀態的TCP連接成為持久鏈接。非持久連接會在每個事務結束後關閉，持久連接會在不同事務（Request/Response）之間保持打開狀態，直到客戶端或伺服器決定將其關閉為止。
可以提高HTTP連接性能的方法：
並行連接
通過多條連接發起並發的HTTP請求。並行連接可以提高復合頁面的傳輸速度，但其連接也有一些缺點
每個事務都會打開/關閉一條新的連接，會耗費時間和帶寬。由於TCP慢啟動特性存在，每條連接的性能都會有所降低。可打開的並行連接數量實際上是有限的
持久化連接
Web客戶端經常會打開到同一個站點的連接。比如，一個Web頁面上的大部分內嵌圖片通常來自同一個Web站點，而且相當一部分指向其他對象的超鏈通常都指向同一個站點。初始化了對某伺服器HTTP請求的應用程序很可能會不久的將來對那台伺服器發起更多的請求，這種性質稱為站點局部性。
因此， HTTP/1.1允許HTTP設備在事務處理結束之後將TCP連接保持在打開狀態，以便為未來的HTTP請求重用現存的連接 。在事務處理結束之後仍然保持在打開狀態的TCP連接稱之為持久連接。持久連接會在不同事務之間保持打開狀態，直到客戶端或伺服器決定其關閉為之。重用已對目標伺服器打開的空閑持久連接，就可以避開緩慢的連接建立階段。而且，已經打開的連接還可以避免慢啟動的擁塞適應階段，以便更快速地進行數據傳輸。所以，持久連接降低了時延和連接建立的開銷，將連接保持在已調諧狀態，而且減少了打開連接的潛在數量。
持久連接和並行連接配合使用可能是最高效的方式。很多Web應用程序都會打開少量的並行連接，其中每個都是持久連接。持久連接有兩種類型
1）HTTP/1.0 + keep-alive 連接
2) HTTP/1.1 + persistent 連接
HTTP/1.0 keep-alive連接
現在很多客戶端和伺服器仍然在使用這些早期的keep-live連接。
實現HTTP/1.0 keep-live連接的客戶端可以通過包含Connection:Keep-Alive 的請求頭將一條連接保持在打開狀態。
響應中Keep-Alive首部是可選的，但只有在提供Connection：Keep-Alive時才能使用它。
Connection:Keep-Alive
Keep-Alive:max=5,timeout=120
這個例子說明了伺服器最多還會為另外5個事務保持連接的打開狀態，或者將打開狀態保持到連接空閑了2分鍾以後。
注意：
1 在HTTP/1.0中，keep-alive並不是默認使用的。客戶端必需發送一個Connection：Keep-Alive 請求首部來激活keep-alive連接。
2 如果伺服器願意為下一條請求將連接保持在打開狀態，就在響應頭中說明，如果響應頭中沒有Connection:Keep-Alive ，客戶端就認為伺服器不支持keep-live，會在發回響應報文後關閉連接。
3 只有在無需檢測到連接的關閉就可以確定報文實體主體部分長度的情況下，才能將連接保持在打開狀態--也就是說實體的主體部分必需有正確的Content-Length，
有多部件媒體類型（multipart/form-data ? 有boundary）或者用分塊傳輸編碼的方式進行了編碼。在一條keep-live信道中回送錯誤的Content-Length是很糟糕的事情，這樣的話，事務處理的另一端就無法精確地檢測出一條報文的結束和另一條報文的開始了。
HTTP/1.1 持久連接 Persistent Connection
HTTP/1.1逐漸停止了對keep-alive連接的支持，用一種名為持久連接的改進型設計取代了它。持久連接的目的與keep-alive連接的目的相同，但是工作機制更優些。HTTP/1.1就吃連接在默認情況下是激活的，除非特別指明，否則HTTP/1.1假定所有的連接都是持久的。要想在事務處理結束之後將連接關閉，HTTP/1.1應用程序必須向報文中顯示地添加一個Connection：close首部。
HTTP1.1客戶端載入在收到響應後，除非響應中包含了Connection：close首部，不然HTTP/1.1連接就仍然維持在打開狀態。但是，客戶端和伺服器仍然可以隨時關閉空閑的連接。不發送Connection：close並不意味這伺服器承諾永遠將連接保持在打開狀態。
注意：
1 只有當連接所有的報文都有正確的、自定義報文長度時，也就是說，實體主體部分的長度都和相應的Content-Length一致，或者用分塊傳輸編碼方式編碼的，連接才能持久保持。
2 如果客戶端不想在連接上發送其他請求了，就應該在最後一條請求中發送一個Connection：close請求首部
管道化連接
HTTP/1.1允許在持久連接上可選的使用請求管道。是相對於keep-alive連接的又一性能優化。在響應到達之前，可以將多條請求放入隊列，當第一條請求通過網路流向伺服器時，第二條和第三條請求也可以開始發送了。在高時延網路條件下，這樣做可以降低網路的環回時間，提高性能。
對管道連接的說明：
1）如果HTTP客戶端無法確認連接是持久的，就不應該使用管道
2）必須按照與請求相同的順序回送HTTP響應。
3）HTTP客戶端必須做好連接會在任意時刻關閉的准備，還要准備好重發所有未完成管道化的請求。
4）出錯的時候，管道連接會阻礙客戶端了解伺服器執行的是一些列管道化請求中的哪一些。由於無法安全地重試POST這樣的非冪請求，所以出錯時，就存在某些方法永遠不會被執行的風險。
5. 網路連接中的長連接和短鏈接是什麼意思
所謂短連接指建立SOCKET連接後發送後接收完數據後馬上斷開連接，一般銀行都使用短連接解釋2長連接就是指在基於tcp的通訊中，一直保持連接，不管當前是否發送或者接收數據。而短連接就是只有在有數據傳輸的時候才進行連接，客戶－伺服器通信/傳輸數據完畢就關閉連接。解釋3長連接和短連接這個概念好像只有移動的CMPP協議中提到了，其他的地方沒有看到過。通信方式各網元之間共有兩種連接方式：長連接和短連接。所謂長連接，指在一個TCP連接上可以連續發送多個數據包，在TCP連接保持期間，如果沒有數據包發送，需要雙方發檢測包以維持此連接。短連接是指通信雙方有數據交互時，就建立一個TCP連接，數據發送完成後，則斷開此TCP連接，即每次TCP連接只完成一對CMPP消息的發送。現階段，要求ISMG之間必須採用長連接的通信方式，建議SP與ISMG之間採用長連接的通信方式。解釋4短連接：比如http的，只是連接、請求、關閉，過程時間較短,伺服器若是一段時間內沒有收到請求即可關閉連接。
6. HTTP是長連接還是短連接
具體解釋如下：
在HTTP/1.0中，默認使用的是短連接。也就是說，瀏覽器和伺服器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接。如果客戶端瀏覽器訪問的某個HTML或其他類型的 Web頁中包含有其他的Web資源，如JavaScript文件、圖像文件、CSS文件等；當瀏覽器每遇到這樣一個Web資源，就會建立一個HTTP會話。
但從 HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭有加入這行代碼：
Connection:keep-alive
在使用長連接的情況下，當一個網頁打開完成後，客戶端和伺服器之間用於傳輸HTTP數據的 TCP連接不會關閉，如果客戶端再次訪問這個伺服器上的網頁，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的伺服器軟體（如Apache）中設定這個時間。實現長連接要客戶端和服務端都支持長連接。
HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。
7. 什麼是「長連接」和「短連接」
所謂短連接指建立SOCKET連接後發送後接收完數據後馬上斷開連接，一般銀行都使用短連接解釋2長連接就是指在基於tcp的通訊中，一直保持連接，不管當前是否發送或者接收數據。
而短連接就是只有在有數據傳輸的時候才進行連接，客戶－伺服器通信/傳輸數據完畢就關閉連接。解釋3長連接和短連接這個概念好像只有移動的CMPP協議中提到了，其他的地方沒有看到過。
通信方式
各網元之間共有兩種連接方式：長連接和短連接。所謂長連接，指在一個TCP連接上可以連續發送多個數據包，在TCP連接保持期間，如果沒有數據包發送，需
要雙方發檢測包以維持此連接。短連接是指通信雙方有數據交互時，就建立一個TCP連接，數據發送完成後，則斷開此TCP連接，即每次TCP連接只完成一對
CMPP消息的發送。
現階段，要求ISMG之間必須採用長連接的通信方式，建議SP與ISMG之間採用長連接的通信方式。解釋4短連接：比如http的，只是連接、請求、關閉，過程時間較短,伺服器若是一段時間內沒有收到請求即可關閉連接。
8. 瀏覽器和web伺服器是如何建立連接的
在HTTP/1.0中，默認使用的是短連接。也就是說，瀏覽器和伺服器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接。如果客戶端瀏覽器訪問的某個HTML或其他類型的 Web頁中包含有其他的Web資源，如JavaScript文件、圖像文件、CSS文件等；當瀏覽器每遇到這樣一個Web資源，就會建立一個HTTP會話。
但從HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭有加入這行代碼：
Connection:keep-alive
在使用長連接的情況下，當一個網頁打開完成後，客戶端和伺服器之間用於傳輸HTTP數據的 TCP連接不會關閉，如果客戶端再次訪問這個伺服器上的網頁，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的伺服器軟體（如Apache）中設定這個時間。實現長連接要客戶端和服務端都支持長連接。
HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。
我們模擬一下TCP短連接的情況，client向server發起連接請求，server接到請求，然後雙方建立連接。client向server 發送消息，server回應client，然後一次讀寫就完成了，這時候雙方任何一個都可以發起close操作，不過一般都是client先發起 close操作。為什麼呢，一般的server不會回復完client後立即關閉連接的，當然不排除有特殊的情況。從上面的描述看，短連接一般只會在 client/server間傳遞一次讀寫操作
短連接的優點是：管理起來比較簡單，存在的連接都是有用的連接，不需要額外的控制手段
9. 長鏈接、短鏈接與連接池
在了解連接池之前，我們需要對長、短鏈接建立初步認識。我們都知道，網路通信大部分都是基於 TCP/IP 協議，數據傳輸之前，雙方通過「 三次握手 」建立連接，當數據傳輸完成之後，又通過「 四次揮手 」釋放連接，以下是「三次握手」與「四次揮手」示意圖：
三次握手建立連接示意圖：
四次揮手釋放連接示意圖：
長、短連接是相對通信時間而言的。長連接相對短連接而言，多了一個 保持連接 的過程，可以在一個連接上可以連續發送多個數據包，在連接保持期間，如果沒有數據包發送，需要雙方發鏈路檢測包。
短連接的操作步驟是：
建立連接——數據傳輸——關閉連接…建立連接——數據傳輸——關閉連接
client向server發起連接請求，server接到請求，然後雙方建立連接。client向server發送消息，server回應client，然後一次請求就完成了。這時候雙方任意都可以發起close操作，不過一般都是client先發起close操作。上述可知，短連接一般只會在 client/server間傳遞一次請求操作。
短連接的優點是：管理起來比較簡單，存在的連接都是有用的連接，不需要額外的控制手段。
長連接的操作步驟是：
建立連接——數據傳輸…（保持連接）…數據傳輸——關閉連接
client向server發起連接，server接受client連接，雙方建立連接，client與server完成一次請求後，它們之間的連接並不會主動關閉，後續的讀寫操作會繼續使用這個連接。
TCP長連接保持的兩種辦法：
自定義心跳消息頭.，一般客戶端主動發送到服務端，伺服器接收後進行回應(也可以不回應)，以便能夠偵測連接是否異常斷開。
通過設置TCP keepalive的屬性，並設置發送底層心跳包的時間間隔。TCP keepalive是在底層定時發送心跳報文，伺服器端接收到底層的心跳報文直接丟棄，不關心其內容。
HTTP協議是無狀態的，在HTTP/1.0中默認使用短連接，客戶端和伺服器每進行一次HTTP操作，瀏覽器就會重新建立一個HTTP會話。
而從HTTP/1.1起，默認使用長連接，用以保持連接特性，使用長連接的HTTP協議，會在響應頭加入這行代碼：
在使用長連接的情況下，當一個網頁打開完成後，客戶端和伺服器之間用於傳輸HTTP數據的TCP連接不會關閉，客戶端再次訪問這個伺服器時，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的伺服器軟體中設定這個時間。實現長連接需要客戶端和服務端都支持長連接。
HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。
基於TCP/IP協議，我們可以知道，頻繁的連接創建和銷毀都需要消耗資源，而連接池是將已經創建好的連接保存在池中，當有請求來時，直接使用已經創建好的連接進行訪問，這樣省略了創建連接和銷毀連接的過程。這樣性能上得到了提高。
以資料庫連接池為例，基本原理如下：
連接池技術帶來的好處：
由於連接得到重用，避免了頻繁創建、釋放連接引起的大量性能開銷。在減少系統消耗的基礎上，另一方面也增進了系統運行環境的平穩性（減少內存碎片以及臨時進程/線程的數量）。
連接池在初始化過程中，往往已經創建了若干連接置於池中備用。此時連接的初始化工作均已完成。對於業務請求處理而言，直接利用現有可用連接，避免了連接初始化和釋放過程的時間開銷，從而縮減了系統整體響應時間。
在較為完備的連接池實現中，可根據預先的連接佔用超時設定，強制收回被佔用連接。從而避免了常規連接操作中可能出現的資源泄漏。
以PHP開發為例，基於PHP-FPM機制實現的Web服務，並不容易實現連接池，而常駐內存的開發框架，例如workerman、swoole 則可以簡單實現連接池功能。PHP-FPM機制下的連接池需要藉助第三方Proxy實現，例如：
10. 長連接、短連接是什麼意思哪位大神給講一下，不要太官方了，通俗易懂點，謝謝。
你好知友!
.
長連接與短連接
所謂長連接，指在一個TCP連接上可以連續發送多個數據包，在TCP連接保持期間，如果沒有數據包發送，需要雙方發檢測包以維持此連接，一般需要自己做在線維持。
短連接是指通信雙方有數據交互時，就建立一個TCP連接，數據發送完成後，則斷開此TCP連接，一般銀行都使用短連接。
比如http的，只是連接、請求、關閉，過程時間較短,伺服器若是一段時間內沒有收到請求即可關閉連接。
其實長連接是相對於通常的短連接而說的，也就是長時間保持客戶端與服務端的連接狀態
如果我的回答對你有幫助.請點擊我的回答下方【選為滿意回答】按鈕.及時採納你將會得到5財富值.