《HTTP权威指南》第四章学习总结

吃透HTTP权威指南 第四章 TCP链接

  **定个小目标，吃透这本书，每天最少一章 CSDN 见**

1. TCP链接
   几乎所有的HTTP都是由TCP/IP承载的
   HTTP链接实际上就是通过TCP链接和使用了一个链接的规则，TCP链接在因特网是可靠的链接，HTTP的报文/数据传输都是在TCP的链接中传输的。
   HTTP的协议栈为 HTTP–>TCP–>IP;其他安全版的HTTPS 就是在HTTP和TCP中间插入了一个加密层
   HTTP要传输一条报文是会以流的形式将报文数据的内容通过一条打开的TCP链接按序传输,对与HTTP程序员来是说明都看不到（透明的），没个TCP端都是由一个IP分钟承载，从一个IP地址发送到另一个IP地址，每个IP分组中都包括一个IP分组首部（通常20字节），一个TCP段首部（通常20个字节）一个TCP数据库（0或者多个字节）。
   在任何时候计算机都可以由几条TCP链接处于打开状态，TCP是通过端口号来保持所有这些链接的正常运行的。
   <源IP地址，源端口号，目的IP地址，目的端口号>
   这四个值组成了一条链接，两个不同的TCP链接不能拥有4个完全相同的地址组件值。
   操作系统提供了一些操作TCP链接的工具，socket通信，

2. HTTP位于TCP的上次，所有HTTP事务的性能在很多程度上取决与TCP的通信能力，TCP内部是非常复杂的。
   HTTP事务的延时可能由几个方面构成的：
   客户端需要根据URL来确定服务器的IP地址和端口，客户端和服务器之间创建TCO链接，客户端发送数据到服务器，服务器吃力数据返回客户端
   建立一条心的TCO链接时，甚至是在发送任意数据之前，TCP软件之间会交换一些列的IP分组，对链接的有关参数进行沟通，如果链接只有少量的数据这些交换过程就会严重降低HTTP的性能。
   因为因特尔网本身无法确保可靠的分组传输,所有TCP实现了自己的机制来确保数据的成功传输。每个TCP段都由一个序列号和完整性校验和，来确保数据的完整性，如果服务器发送数据被破坏或者丢失都会发起重传机制。由于确认报文很小，所有TCP运行在法网相同法相的输出数据分组中对其进行"捎带"，TCP类别实现了一个“延迟确认”算法，它会在一个特定的窗口时间内将输出确认放到缓冲区中，以寻找额能够稍等它的输出数据分组，如果在那个时间段没有数据分组，就将确认信息单独发送，但有时确实没有其他数据段，所有这中算法可能会让延迟变的跟大，所有可以调整或禁止延迟确认算法，但一定要清晰的认识到自己在做什么。TCP还对网络丢包等做了一系列控制可优化，比如“拥塞控制”，具体的可以去网上查看，这里就不多说了。
   TCP鼓励使用全尺寸的数据段发送数据（1500字节），TCP中的Nagle算法或引发几种HTTP性能的问题，首先，小的HTTP报文可能无法填满一个分组，可能会引发等待那些永远不会到来的额外数据而产生按时，所有在使用的时候可以禁用Nagle算法。

3. HTTP链接的处理
   HTTP运行在客户端和最终的源端服务器之间存在一串HTTP中间实体（代理，高速缓存等），可以从客户端开始，逐条的将HTTP报文经过这些中间设备转发到源端服务器上去。在某性情况下，两相邻的HTTP应用程序会为他们共享的链接应用一组选项，比如可以用Connection:close来说明发完吓一跳报文后关闭链接。Connection中可以承载3中不同类型的变迁，因此有时会令人费解，（HTTP首部字段名，任意标签值，close）
   如果链接标签中包含了一个HTTP首部字段的名称，那么这个这个首部字段就包含了一些链接相关的星系，不能将其转发出去，在将报文转发出去之前，必须删除Connection首部的所有字段，由于Connection首部可以防止无意中对本地首部的转发，因此将逐条首部名放入Connection首部被称为“对首部的保护”
   如果只对链接进行简单的管理，TCP的性能时延可能会叠加起来，比如，由一个嵌入图片的web页面，浏览器需要发起4个HTTP事务来显示此页面，1一个用于顶层的HTML页面，3个用于嵌入的图片。如果每个事务都需要一条新的链接，那么链接时延和慢启动时延就会叠加起来。除了串行加载的引入的时间时延外，图片一张一张加载也会感觉很慢。串行加载的另一个缺点是，由些浏览器在对象加载完毕之前无法获知对象的尺寸，而且他们可能需要尺寸信息来决定将对象房子屏幕的什么位置上，所以在加载了诸侯多的对象之前，无法在屏幕上显示任何内容。在这中情况下，可能不能装置正常。由的浏览器会对这些情况做一些封装处理，等所有资源加载完毕再显示出来，处理这个还有几种现存的新兴的方法可以提高HTTP链接的性能，并行链接（通过多条TCP链接并发的HTTP请求）；持久链接（重用TCP链接，消除链接以及关闭时延）；管道化链接（通过共享的TCP链接发起并行的HTTP请求）；复用链接（交替传送请求和响应报文）

4. 并行连接
   因为串行链接太慢了,HTTP允许客户端打开多条链接，并行的执行多个HTTP事务，HTTP客户端可以通过多条HTTP链接来加快网络的延迟，但是这样并不能一定让数据传输变快，数据的传输速度还可网络的带宽有关。但这样依然能让人们感觉很快，因为多个组件同时出现在屏幕上时，用户能看的加载进展，感觉每个组件都在加载中。

5. 持久链接
   很多情况下HTTP客户端打开的到同一个站点的链接，比如一个WEB页面上的大部分内嵌来自同一个WEB站点，HTTP设备允许在事务处理结束后将TCP链接保持在打开状态，下一次传输的时候就不会有TCP的链接和慢启动了。因此很多WEB应用都会打开少量的并行链接，其中的每一个都是持久链接，辞旧链接有两种类型HTTP/1.0+ "keep-alive"链接 和HTTP/1.1 "persistent"链接。
   keep-Alive在使用过程中 客户端必须发送一个Connection：Keep-Alive，如果服务器没有检查到这个表示这次会话后就会关闭，客户端探明响应中没有Connection：Keep-Alive就知道服务器响应后会关闭链接,但是如果服务器不支持keep-alive，就不会传回Connection：Keep-Alive,还有在使用代理是要明确代理是怎么处理Connection：Keep-Alive的，大部分代理都绝不能转发Connection首部，或者名为Keep-Alive的首部，
   在一些浏览器的实现者们为了盲中继所带来在转发文件中引入了一个名为Proxy-Connection的新首部，很多浏览器都实现了这个很多代理也能够理解它，在代理是盲中继是，他会将Proxy-Connection发送服务器，而服务器不会处理Proxy-Connection，如果代理够聪明的话它会将Proxy-Connection替换成Connection,然后发送给服务器，达到预期的效果
   persistent connection是HTTP/1.1取代Connection：Keep-Alive的，与Connection：Keep-Alive不同，他说默认激活的，HTTP应用程序必须向报文显示的添加一个Connection：close首部，这是与以前版本很重要的区别。当HTTP客户端发送close的时候链接才会断开，但并不是不发生就永远都不断开。

6. 管道化链接
   HTTP/1.1允许在持久链接上可选的使用求情管道，这是keep-alive链接上的进一步性能优化，在响应到达之前，可以将多条请求方如队列，当第一条请求通过网络流向服务器时第二条第三条请求也可以开始发送了，在高时延的网络下，这样做可以降低网络的环回时间，提高性能。
   HTTP对管道化有几条限制
   必须确保链接的持久性
   请求和响应顺序必须是一样的
   不应该在管道中不安全的方法

7. 关闭链接的奥秘
   HTTP的链接可能在任何时间关闭，
   如果一个事务不管是执行一次还是很多此，得到的结果都是相同，这个事务就是幂等的，实现这们可以认为GET HEAD PUT DELETE TRACE和OPTIONS方法都共享这以特性，客户端不应该以管道方式传送非幂等请求（比如POST），否则传输链接的过早终止或造成一些不确定的后果，要发送一条非幂等求情，就需要等待来自前一条请求的响应状态。
   应用程序可以使用close来对TCP通信进行完全关闭，也可以使用shutdown来单独关闭输入或输出信道被称为半关闭
   一些简单的HTTP应用程序可以只有使用完全关闭，当应用程序开始与很多其他类型的HTTP客户端服务器和代理进行对话且开始使用管道话持久链接时，使用半关闭来方式在对等实体收到非预期的写入错误就变得很重要了。
   HTTP规定，正常关闭应该关闭他们的输出信道，然后等待链接另一端关闭输出信道，两端都告诉没有数据进行传输了然后在完全关闭

   ps：
   今天就到这了，如果有不对的地方请大家指出来