连接管理
- HTTPS比HTTP多了一层TSL或者SSL的安全层
- 位于HTTP和TCP之间
- TCP连接通过源IP,源端口号,目的IP,目的端口号确定唯一连接
- 并行连接
- 一个HTML页面可能包含多个资源(文字,图片,视频等)
- 如果收到一个资源才请求下一个则太慢,我们可以并行请求
- 浏览器端同时开启多个http connection的方式从服务端获取数据资源
- 缺陷
- 但是如果网络带宽太小,并行请求都去竞争有限的带宽,则每个对象都会加载很慢
- 并且大量的连接会消耗很多内存资源,特别会对服务器造成压力
- 所以一般浏览器只会少量并行(4个左右)
- 所以一般浏览器只会少量并行(4个左右)
- 持久连接
-
好处
- 一次传输完成后不断开TCP连接,避免了建立和关闭连接的消耗和延迟
- 例如程序和数据库的连接应该用长连接
- 一次传输完成后不断开TCP连接,避免了建立和关闭连接的消耗和延迟
-
缺陷
- 一不小心可能会积累大量空闲连接,消耗服务器和客户端资源
- 像WEB网站这样可能存在成千上万客户端的连接的服务,用短连接会更省一些资源
- 并发量大,但每个用户无需频繁操作情况下需用短连好
- 一不小心可能会积累大量空闲连接,消耗服务器和客户端资源
-
HTTP1.1默认为持久连接(Connection:Keep-Alive)
-
- 哑代理
- 代理服务器可能不支持keep-alive连接,但是他仍然会直接转发客户端的持久连接请求首部到服务器。
- 如果服务器同意持久连接并告知给客户端,客户端会以为该连接保持打开而不会执行关闭连接操作
- 当客户端在同一连接上发送下一个请求时,代理却忽略了该请求
- 此时浏览器一直阻塞,直到连接超时
- 因此实际上代理服务器不会转发HTTP1.0的Connection首部
- 管道化连接(pipeline)
- HTTP1.1在持久连接的基础上支持管道连接
- 可以不用等第一条消息返回响应就发送下一条消息
- 在理想情况下,所有资源的获取仅仅需要一个RTT时长(Round Trip Time)
- 而非pipeline的情况下,所有资源获取需要N个RTT时长(N表示资源个数)
- 只有幂等的方法才能使用pipeline
- 例如POST是非幂等的,因此不能使用pipeline
- 队头阻塞
- client端可以不必等待上一个response返回即可发送下一个request,但在server端必须根据收到的request的顺序来返回response
- 因为HTTP是一个无状态的协议,每条request无法知道哪条response是返回给他的
- 如果server端来处理pipeline请求的时候出现问题,那么排在后面的request都会被block
- 一些产品使用pipeline后产生的问题:Safari使用pipeline后发生了图片互换问题,AFNetworking在下载文件时遇到的问题
- 所以主流浏览器上默认下该功能都是关闭状态
- client端可以不必等待上一个response返回即可发送下一个request,但在server端必须根据收到的request的顺序来返回response