关于HTTP1.1的长连接

HTTP是一个构建在传输层的TCP协议之上的应用层的协议，在这个层的协议，是一种网络交互须要遵守的一种协议规范。

HTTP1.0的短连接

HTTP 1.0规定浏览器与server仅仅保持短暂的连接。浏览器的每次请求都须要与server建立一个TCP连接，server完毕请求处理后马上断开TCP连接，server不跟踪每一个客户也不记录过去的请求。这个过程大概能够描写叙述为：

1、建立连接：首先DNS解析过程。如把域名变成一个ip。假设url不包括port号，则会使用该协议的默认port号，HTTP协议的默认port号为80。然后三次握手建立一个TCP连接；

2、请求：连接成功后，開始向webserver发送请求。这个请求通常是GET或POST请求。

3、应答：webserver收到这个请求，进行处理。webserver会把文件内容传送给响应的web浏览器。包括：HTTP头信息，体信息。

4、关闭连接：当应答结束后，web浏览器与webserver必须四次握手断开连接，以保证其它web浏览器能够与webserver建立连接。

HTTP1.1的长连接

可是HTTP1.1開始默认建立的是长连接，即一旦浏览器发起HTTP请求，建立的连接不会请求应答之后立马断掉。

1、 一个复杂的具备非常多HTTP资源的网页会建立多少TCP连接，怎样使用这些连接？

2、 已经建立的TCP连接是否会自己主动断开。时间是多久？

对于第一个问题。如今浏览器都有最大并发连接数限制。应该说假设须要，就会尽量在同意范围内建立很多其它的TCP持久连接来处理HTTP请求，相同滴。一个TCP持久连接能够不断传输多个HTTP请求。可是假设上一个请求的响应还未收到，则不能处理下一个请求(Pipeling管道技术能够解决问题从而进一步提升性能)，所以说非常多浏览器事实上都能够改动同意最大并发连接数以提升浏览网页的速度。

对于第二个问题。

问题在于server端对于长连接的实现，特别是在对长连接的维护上。

FTP协议及SMTP协议中有NOOP消息，这个就能够觉得是心跳报文。但HTTP协议没有相似的消息，这样server端仅仅能使用超时断开的策略来维护连接。

设想超时时间非常短。那么有效空暇时间就非常短。换句话讲：一旦链路上没有数据发送，server端非常快就关闭连接。

也就是说事实上HTTP的长连接非常easy在空暇后自己主动断开，一般来说这个时间是300s左右。

參考资料

=====================================================================

1、HTTP1.1提升性能的手段

著作权归作者全部。

商业转载请联系作者获得授权。非商业转载请注明出处。
作者：Saviio
链接：http://www.zhihu.com/question/36469741/answer/67608570
来源：知乎

HTTP1.1里大概规范了几项提高性能的手段：

1. 持久连接 （keep-alive/persistent connection）
2. 并行连接
3. Pipelining

第一点之前已经说过了，所以不表。

第二点。由于现代网页通常包括了复数个（>=10）资源，而依照默认设定，一个连接中的每一个请求必须等待收到响应后才干发送下一个请求，所以假设复数的资源请求全部在一个连接one by one发送给server显然会非常慢，而为了弥补这一缺陷，浏览器一般会默认开启多个TCP连接，然后再依据每一个连接的状态在当中依次发送数据请求，并且client有权随意关闭超发的连接。各个浏览器同意的并行连接数大致是这样的（From SO）：

Firefox 2:  2

Firefox 3+: 6

Opera 9.26: 4

Opera 12:   6

Safari 3:   4

Safari 5:   6

IE 7:       2

IE 8:       6

IE 10:      8

Chrome:     6

由于TCP协议本身有慢启动的特征，会随着时间调谐连接的最大速度，因此在现代浏览器中持久连接和并行连接通常是搭配在一起使用的—— 一方面由于持久连接的存在。每一个TCP连接已经处于调谐后的状态。还有一方面持久连接能够避免又一次三次握手的开销。

关于第三点，
依照HTTP1.1的描写叙述。还有种能够提升性能的方案是管道化。能够在一个连接中发送多个请求不必等待前一个请求返回。

但这项技术比較easy踩坑，所以主流面向用户的浏览器，这项技术是被默认关闭。 

关于HTTP2：
HTTP2为了性能做了不少努力，比方提供了规范以支持连接的多路复用。

HTTP1.0须要加上keep-alive的请求首部。否则默认一个请求一个连接。

HTTP1.1之后keep-alive（持久连接）被默认启用，除非在响应中指定connection：close，否则webserver会假定全部连接都是持久的。

=====================================================================

葛佳祥。程序猿/PHPer/开源爱好者

石建文、小小的寂寞、知乎用户 等人赞同

@Saviio没有正面回答这个问题。只是关于HTTP中的持久连接理解得不错。

关于楼主的问题：假设第一个请求完毕后，再開始发送的第二个请求。就是1个tcp连接。假设是两个请求同一时候開始，或者第一个请求还未结束就開始第二个请求，就是两个tcp连接。

由于HTTP协议是同步的没有多路复用支持。一个管道同一时候仅仅能做一件事。

只是幸好现代计算机已经全然不用在乎几个tcp连接了，协议简单事实上挺好的。

=============================================================

2、关于火狐中HTTP參数的设置： 
about:config network.http.* 的相关參数
network.http.keep-alive 默认是 true 是否同意持久连接。这个默认就是 true，改成 false 的是大傻瓜。
network.http.keep-alive.timeout 默认是 300 持久连接同意的保持时间，这个调大了没意义，由于一般 server 设置的就是 300。

server 把你咔嚓了你还能有什么办法。
network.http.max-connections-per-server 默认是 8 连接同一个server同意的最大连接数。一般觉得在开启持久连接的情况下把这个数值调大没什么作用，并且不太道德。须要调大的情况比方：你同一时候从站点下 10 个大文件。
network.http.max-persistent-connections-per-server默认是 2 连接同一个server同意的最大持久连接数，这个数值 HTTP/1.1 标准推荐的是 2。调大了反而添加你自己的网络消耗。并且一般一个server同意的持久连接数是有限的，你调大了就可能造成别人可用的降低，假设大家都调大，就意味着网络效 率的丧失。我个人建议不要动这个数值。

network.http.pipelining 默认是 false 是否同意 pipelining，这个功能由于眼下还是试验阶段，所以默认没有打开。

强烈建议打开。
network.http.pipelining.maxrequests 默认是 4 每一个持久连接同意一次发送的请求数。假设 pipeline 里面有一个大图片或者执行时间较长的脚本，后面已经发送的请求就会被堵塞（注意server必须是依次回应请求）；而在这样的情况下。假设没有使用 pipelining，浏览器发现一个请求处理时间非常长。自然会使用还有一条持久连接用作兴许请求，甚至进一步开启非持久连接。

另外，假设server支持 pipelining 不好而过早的关闭连接，浏览器势必要又一次发送请求。基于这样的种原因。有人觉得这个数字设置得比 2 大反而会降低浏览速度。我个人的推荐是，这个数值普通情况能够保持默认值 4。假设浏览的站点有大量的静态小图片。或者网络速度较慢。能够尝试将其调大。
network.http.max-persistent-connections-per-proxy 默认是 4 每一个代理server同意的最大持久连接数。

4 是眼下比較公认的最合适的数值。虽然HTTP/1.1 的推荐值是 2。

network.http.proxy.keep-alive 默认是 true 连接代理server是否同意持久连接。true 挺好的。

network.http.proxy.pipelining 默认是 false 连接代理server是否同意 pipelining。眼下普遍觉得大多数代理server支持 pipelining 并不好。所以一般不建议打开。
pipelining 眼下是一个有争议的。仍旧在实验阶段的特性。

虽然它可能确实会加快浏览速度，可是这在一定程度上取决于网络的各项因素，所以不要盲目的依照网上建议的方式设置相关的參数。

============================================================

3、具体解释浏览器最大并发连接数

当我们在浏览网页的时候，对浏览速度有一个重要的影响因素，就是浏览器的并发数量。并发数量简单通俗的讲就是，当浏览器网页的时候同一时候工作的进行数量。

假设同一时候仅仅有2个并发连接数数量，那网页打开的时候仅仅能依赖于这2条线程，前面假设有打开慢的内容，就会直接影响到后面的内容打开。可是假设同一时候有很多其它的并发连接数。这样就会大大的提高网页载入速度。详情可查看我们之前公布的文章：并发连接数对浏览器载入速度的測试。

浏览器的并发连接数也并不是越大越好。

下表概括了基于主机上执行的IE浏览器的版本号的最大并发连接数、主机的连接速度和server的受支持的协议版本号。

<>

InternetExplorer 8+ 提供了一个 window. maxConnectionsPerServer 对象，server能够利用此对象来确定client计算机上的可用连接数。

在 Internet Explorer 8+ 中。maxConnectionsPerServer对于宽带连接将返回 6。除非用户或管理员已重写此默认值。在client计算机通过拨号连接时，假设连接到 HTTP 1.1 server，则 maxConnectionsPerServer 将返回 2；假设连接到 HTTP 1.0 server，则 maxConnectionsPerServer 将返回 4。

非常多人都说是：

实际情况（china）：

非常多client软件能够改动电脑的最大连接数。比方：迅雷、暴风影音等。

之前我们曾跟大家分享过怎样改动IE浏览器的并发连接数，假设你正在使用IE7及下面的更低版本号，最好还是尝试将连接数改动到6，这将有助于提升打开站点的速度。