HTTP权威指南—HTTP连接

1. HTTP是如何使用TCP连接的
HTTP连接是报文传输的关键通道！TCP/IP连接是安全可靠传输，一条TCP/IP连接能够连接到可能运行在世界各地的服务器应用程序，在客户端和服务器之间交换的报文永远不会丢失、受损或失序。当出现计算机或网络崩溃时，客户端与服务器端的连接仍然会断开，这种情况下，会通知客户端和服务器端的通信中断了。
HTTP报文，首先会以流的形式通过一条打开的TCP连接按序输出，TCP收到数据流，会将数据流分成称作段的小数据块，分装成IP分组，后传入数据链路层通过因特网传输。

HTTP与HTTPS协议栈的区别？
HTTPS是HTTP的安全版本，在HTTP与TCP之间插入了一层TLC或SSL的密码加密层

如何区别不同的TCP链接?
一条TCP连接通过 源IP地址、目的IP地址、源端口号、目的端口号识别；不同的TCP连接不会有相同的4个值

TCP套接字

为什么TCP/IP是安全可靠的？
TCP/IP是如何实现可靠传输的

2. TCP连接的时延、瓶颈以及存在的障碍
与建立TCP连接，以及传输请求和响应报文的时间相比，事务处理时间可能是很短的。除非客户端或服务器超载，或正在处理复杂的动态资源，否则HTTP时延就是由TCP网络时延构成的。

TCP/IP连接是可靠性传输，但是因特网自身是无法确保可靠传输的。若因特网路由超负荷，是会随意丢弃分组的，所以TCP只能靠自己的确认机制来确保数据能够成功传输，每个发送的TCP段都有序列号和数据完整性校验和来确认是否收到的数据是完整的。这也是为什么TCP需要建立连接进行三次握手、结束连接四次挥手。

导致时延的原因
（1）事务时延
· DNS解析 
耗费时间有限，客户端都会有一个DNS缓存，用于存储近期访问站点的IP地址，若访问的是已经缓存的，很快就可以获取目的IP。
· 连接建立时延
客户端向服务器发送请求后，会有一个等待服务器响应请求的时间，通常1-2秒，HTTP事务多的时候，时间会叠加。
· 请求时延
连接建立后，客户端向服务器发送请求，即请求传输时间。
· 处理时延
服务器接收请求后，需要对请求进行处理的时间。
· 响应时延
服务器处理结束后，需要对客户端发送响应，即响应传输时间。
理解了HTTP传输流程，就不难懂事务时延产生的原因。
（2）性能时延
· TCP建立握手 
TCP三次握手带来的时间是可以估量的，无非就是客户端发送一个TCP分组，服务器返回TCP分组进行确认，客户端再次发送TCP分组进行连接成功确认的开销。小的HTTP事务反而会在TCP建立上花费的时间占比更高，可以通过重用现存连接来减少TCP建立时延所造成的影响
· TCP慢启动拥塞机制 
慢启动可以限制TCP端点在任意时刻可以传输的分组数，接收端每成功接收一个分组，发送端就有了发送另外两个分组的权限 -打开拥塞窗口机制
· 数据聚集的Nagle算法及用于捎带确认的TCP延迟确认算法
发送 大量 单字 节 分组 的 行为 称为“ 发送 端 傻 窗口 综合症”。 这种 行为 效率 很低、 违反 社会 道德，哈哈哈。
由于TCP数据流接口，TCP栈中可以放置任意尺寸的数据，TCP段至少包含40字节的标记和首部（IP首部20字节、TCP首部20字节）中装载数据过少，会导致效率低下、网络性能下降等，nagle算法只有在其他分组被确认挂起时，可以发送非全尺寸的数据，其他情况下的数据会被缓存起来等待满足全尺寸之后再发送。
这样会产生时延问题：一个HTTP报文无法填满一个HTTP分组的时候，会继续等待，若下一个报文永远不会到来，会因此产生时延；另外，nagle算法与延迟确认之间的交互问题，Nagle会阻止数据的发送，直到确认分组抵达，但确认分组自身会被延迟确认延迟100-200ms
HTTP应用程序可以设置TCP_NODELAY,禁用Nagle算法。
· TIME_WAIT时延和端口耗尽
TIME_WAIT端口耗尽是很严重的性能问题，很少遇到这种情况。遇到TIME_WAIT端口耗尽问题，可以增加客户端负载生成机器的数量，或者确保客户端和服务器在循环使用几个虚拟IP地址以增加更多的连接组合。
3. HTTP的优化，包括并行连接、keep-alive（持久连接）和管道化连接
HTTP连接性能的优化：并行连接、持久连接、管道化连接、复用连接
并行连接：允许客户端打开多条连接，并行的执行多个HTTP任务。能够提高页面的加载速度，克服单跳连接的空载时间和带宽限制

并行连接并不总是最快的。当客户端的网络带宽不足以支撑多个并行连接时，会出现每个对象都会竞争有限的带宽，使得加载更加缓慢。并且打开大量的连接也会消耗更多的内存资源，服务器或代理在同时处理很多连接时，性能就会严重下降。
实际中，浏览器可以控制并行连接的数量，一般限制为4个。
持久连接：
两种类型——HTTP/1.0 keep-alive 连接和HTTP/1.1 persistent连接
HTTP/1.1允许HTTP设备在事务处理结束后将TCP保持在打开状态，以便未来的HTTP请求重用现存连接。在事务处理结束后仍然保持在打开状态的TCP连接，直到客户端或服务器决定关闭为止被称为持久连接。非持久连接会在事务处理结束后关闭。优点：可以避开缓慢的连接建立阶段、慢启动的拥塞阶段
缺点：需要维护持久连接的数量，不然会累积出大量空闲连接，耗费资源
客户端发送Connect首部 Connent:Keep-Alive，给服务器端，并指明需要保持连接活跃的数量以及持续的时间，若服务器响应首部中未包含Connent:Keep-Alive首部，客户端会默认服务器不支持持久连接，服务器端会在处理完请求后关闭连接
keep-alive与哑代理之间的纠葛

对于单个中继器，相对较老不能识别connection首部，对于客户端请求内容中的connection首部进行忽略，直接转发到服务器端，服务器端同样返回keep-alive，进入持久连接的准备，而客户端收到持久连接的响应后，继续发送第二个连接时，哑代理在等待连接关闭并挂起当前请求。
Proxy-Connection在这种情况下应天而降，若遇到盲中继，它会将无意义的Proxy-Connection首部转发给web服务器，服务器识别不到该首部，会忽略该首部不会带来任何问题，若为聪明的代理（能理解持久连接的握手动作），会用一个Connection首部代替Proxy-Connection,将其转发给服务器建立持久连接请求。
此时又有问题了啊~ 若多个代理出现既有哑代理也有聪明代理的情况还是会出现这个问题呀~

后来HTTP进化了到了1.1 使用Persistent（官方正品）代替了过时的Keep-Alive，但是现在仍旧有很多Keep-Alive随处可见，与1.0不同，进化版的持久连接默认都是激活的，啥意思呢，就是只要是个连接，我都认为你是勇士，都是持久连接！如何告诉服务器我想断开连接了，你走你的阳关道我走我的独木桥，那就在报文中添加一个Connection：close首部，服务器就接收到你想离开的决心啦
一个客户端对一个服务器或代理最多只能维护两条持久连接，以防服务器过载
管道化连接：

HTTP/1.1允许在持久连接上可选的实用请求管道，注意是持久连接才可以使用管道化。管道化有什么优势，让人这么向往！它可以在发送第一个请求，等待请求响应的过程中，连续发送多个请求，无需等待第一个请求响应之后再发送——省时高效小能手。但是，服务器端扔按照发送请求的顺序进行响应