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财富值.