世界上几乎所有的 HTTP 通信都是由 TCP/IP 承载的,客户端可以打开一条TCP/IP连接,连接到任何地方的服务器。一旦连接建立,客户端和服务器之间交换的报文就永远不会丢失、受损或失序
TCP(Transmission Control Protocol)传输控制协议,是一种面向连接的、可靠的、基于字节流的传输层通信协议。通俗来讲,TCP就是双方通信的一个规范标准,负责对数据的传输进行一定的控制
HTTP 要传送一条报文时,会以流的形式将报文数据的内容通过一条打开的 TCP 连接按序传输。TCP 收到数据流之后,会将数据流分成被称作段的小数据块,并将段封装在 IP 分组中,通过因特网进行传输。所有这些工作都是由 TCP/IP 软件来处理的、HTTP 程序员什么都看不到
每个 TCP 段都是由 IP 分组承载,从一个 IP 地址发送到另一个 IP 地址,每个 IP 分组包括:
IP 首部包含了源和目的 IP 地址、长度和其他一些标记。TCP 段的首部包含了 TCP 端口号、TCP 控制标记,以及用于数据排序和完整性检查的一些数字值
TCP 段首部格式如下:
源端口号就是指本地端口,目的端口号就是远程端口
序号,也称序列号(Sequence Number),用于 TCP 通信过程中某一传输方向上字节流的每个字节的编号,以防止乱序问题。简单来说,就是在传输过程中用序列号来标记自己的位置,保证数据能按序传输
确认序号,也称确认序列号(Acknowledgment Numbe),是接收确认端所期望收到的下一序列号。确认序号应当是上次已成功收到数据字节序号加 1,只有当标志位中的 ACK 标志为 1 时该确认序列号的字段才有效。主要用来解决不丢包的问题
标志位,TCP Flag,TCP 首部中有 6 个标志比特,它们中的多个可同时被设置为 1,主要是用于操控 TCP 的状态机,依次为 URG,ACK,PSH,RST,SYN,FIN
ACK
表示应答域有效,这个标识可以理解为发送端发送数据到接收端,发送的时候 ACK 为 0,标识接收端还未应答,一旦接收端接收数据之后,就将 ACK 置为 1,发送端接收到之后,就知道了接收端已经接收了数据
表示同步序列号,用来建立 TCP 连接。SYN 标志位和 ACK 标志位搭配使用,当连接请求的时候,SYN = 1,ACK = 0;连接被响应的时候,SYN = 1,ACK = 1;这个标志的数据包经常被用来进行端口扫描。扫描者发送一个只有 SYN 的数据包,如果对方主机响应了一个数据包回来 ,就表明这台主机存在这个端口
表示发送端已经达到数据末尾,也就是说双方的数据传送完成,没有数据可以传送了,发送 FIN 标志位的 TCP 数据包后,连接将被断开。这个标志的数据包也经常被用于进行端口扫描
TCP 三次握手,即建立 TCP 连接,需要客户端和服务端总共发送 3 个包以确认连接的建立。在 Socket 编程中,这一过程由客户端执行 connect 来触发
TCP 握手的目的有三个:
为什么是三次握手,而不是一次、二次呢?因为有可能出现这种情况:客户端发送了一个连接请求,但出现网络延迟,导致客户端没有及时收到服务端的响应,就会认为本次请求失效。而这时原本延迟的请求又来到服务端,服务端确认并保持等待状态,但实际上此时客户端并没有与服务端连接的意思,这就会导致服务器一直处于等待状态,造成资源浪费
TCP 四次挥手,即终止 TCP 连接,需要客户端和服务端总共发送 4 个包以确认连接的断开。在 Socket 编程中,这一过程由客户端或服务端任一方执行 close 来触发
为什么是四次挥手呢?因为关闭连接时,己方收到对方的 FIN 报文,仅仅表示对方不再向自己发送数据,但还能接受数据。己方可能还有数据要发送给对方,所以不能向三次握手一样直接把 ACK 和 SYN 放一起发送,而是先发送 ACK,直到没有数据要发送了,才是 FIN 确认关闭连接
HTTP 位于 TCP 上层,所以 HTTP 事务的性能在很大程度上取决于底层 TCP 通道的性能
为了避免网络延迟导致的数据丢失,TCP 实现了自己的确认机制来确保数据的成功传输
每个 TCP 段都有一个序列号和数据完整性校验和。每个段的接收者收到完好的段时,都会向发送者回送小的确认分组。如果发送者没有在指定的窗口时间内收到确认信息,发送者就认为分组已被破坏或损毁,并重发数据
由于确认报文很小,所以 TCP 允许将返回的确认信息与输出的数据分组结合在一起,更有效地利用网络。为了增加确认报文找到同向传输数据分组的可能性,TCP 实现了一种【延迟确认】算法,延迟确认算法会在一个特定的窗口时间(通常是 100-200 毫秒)内将输出确认存放在缓冲区中,以寻找能够捎带它的输出数据分组。如果在那个时间段内没有输出数据分组,就将确认信息放在单独的分组中传送
TCP 数据传输的性能还取决于 TCP 连接的使用期,TCP 连接会随着时间进行自我调节,起初会限制连接的最大速度,如果数据成功传输,会随着时间的推移提高传输的速度,这种调节被称为 TCP 慢启动,用于防止因特网的突然过载和拥塞
TCP 慢启动限制了一个 TCP 端点在任意时刻可以传输的分组数。简单来说,每成功接收一个分组,发送端就有了发送另外两个分组的权限。如果某个 HTTP 事务有大量数据要发送,是不能一次将所有分组都发送出去的,必须发送一个分组,等待确认,然后发送两个分组,每个分组都必须被确认,然后发送四个分组,以此类推,这种方式被称为【打开拥塞窗口】
由于存在这种拥塞控制特性,所以新连接的传输速度会比已经交换过一定量数据的连接慢一些
TCP 有一个数据流接口,应用程序可以通过它将任意尺寸的数据放入 TCP 栈中,即使一次只放一个字节。但是,每个 TCP 段都至少装载了40个字节的标记和首部如果 TCP 发送了大量包含少量数据的分组,网络的性能就会严重下降
Nagle 算法试图在发送一个分组之前,将大量 TCP 数据绑定在一起,以提高网络效率。Nagle 算法鼓励发送全尺寸的分组,只有当所有其他分组都被确认之后,Nagle 算法才允许发送非全尺寸的分组。如果其他分组仍然在传输过程中,就将那部分数据缓存起来。只有当挂起分组被确认,或者缓存中积累了足够发送一个全尺寸分组的数据时,才会将缓存的数据发送出去
Nagle 算法会引发几种 HTTP 性能问题,首先,小的 HTTP 报文可能无法填满一个分组,可能会因为等待那些永远不会到来的额外数据而产生时延。其次,Nagle 算法与延迟确认之间的交互存在问题,Nagle 算法会阻止数据的发送,直到有确认分组抵达为止,但确认分组自身会被延迟确认算法延迟 100-200 毫秒
HTTP应用程序常常会禁用 Nagle 算法,如果要使用的话,一定要确保会向TCP写入大块的数据,不会产生一堆小分组
当某个 TCP 端点关闭 TCP 连接时,会在内存中维护一个小的控制块,用来记录最近所关闲连接的 IP 地址和端口号。这类信息只会维持一小段时间,通常是所估计的最大分段使用期的两倍(称为 2MSL,通常为两分钟左右),以确保在这段时间内不会创建具有相同地址和端口号的新连接
2MSL 的连接关闭延迟在某些情况下会出现问题,例如客户端每次连接到服务器时,都会获得一个新的端口,以实现连接的唯一性,但由于可用端口的数量有限(比如 60000 个),而且在 2MSL 秒(比如 120 秒)内连接是无法重用的,连接率就被限制在 60000/120=500 次/秒,如果服务器的连接率高于 500 次/秒,就会遇到端口耗尽问题
如果只对连接进行简单的管理,TCP 的性能时延可能会叠加起来。比如,假设有一个包含了三个嵌入图片的 Web 页面,测览器需要发起四个 HTTP 事务来显示此页面:一个用于顶层的 HTML 页面,三个用于嵌入的图片。如果每个事务都需要建立一条新的连接,那么连接时延和慢启动时证就会叠加起来
除了串行加载引入的实际时延之外,加载一幅图片时,页面上其他地方都没有动静也会让人觉得速度很慢,用户更希望能够同时加载多幅图片。并行加载的另一个缺点是,有些沟览器在对象加载完毕之前无法获知对象的尺寸,而它们可能需要尺寸信息来决定将对象放在屏幕的什么位置,所以在加载了足够多的对象之前,无法在屏靠上显示任何内容
HTTP 允许客户端打开多条连接,并行地执行多个 HTTP 事务,提高加载速度,但并不是绝对的,在带宽较小的情况下,并行执行多个 HTTP 事务带来的性能提升就很小,甚至没什么提升。而且,打开大量连接会消耗大量的资源
Web 客户端经常会打开到同一个站点的连接,比如,一个 Web 页面上的大部分内嵌图片通常都来自同一个 Web 站点。因此,对某服务器 HTTP 请求的应用程序很可能会在不久的将来发起更多的请求。因此,HTTP/1.1 允许 HTTP 设备在事务处理结束之后会将 TCP 连接保持在打开状态,以便在未来重用现存的连接发起 HTTP 请求,称为持久连接,直到客户端或服务器决定将其关闭为止。持久连接可以避免缓慢的连接建立阶段,以及慢启动的拥塞适应阶段,以便更快速地进行数据传输。通常情况下,持久连接和并行连接配合使用
实现 HTTP/1.0 的客户端可以通过包含 Connection:Keep-Alive 首部请求将一条连接保持在打开状态,如果服务器愿意为下一条请求将连接保持在打开状态,就在响应中包含相同的首部。如果响应中没有 Connection:Keep-Alive 首部,客户端就认为服务器不支特 Keep-alive,会在收到响应报文之后关闭连接
可以用 Keep-A1ive 通用首部中指定的,由逗号分隔的选项来调节 keep-alive 的行为
Connection: Keep-Alive
Keep-Alive: max=5, timeout=120
HTTP/1.1 逐渐停止对 keep-alive 连接的支持,用一种名为持久连接(persistentconnection)的改进型设计取代了它。,HTTP/1.1 默认所有连接都是持久的,要在事务处理结束之后关闭连接,必须向报文中显式地添加一个 Connection: close
首部。客户端收到响应后,除非响应中包含 connection: close
首部,否则连接就维持在打开状态。但是,客户端和服务端仍然可以随时关闭空闲的连接,不发送 connection: close
并不意味着服务端承诺永远将连接保持在打开状态
HTTP/1.1 允许在持久连接上可选的使用管道,在响应到达之前,可以将多条请求放入队列,当第一条请求到达服务器,第二条和第三条请求也可以开始发送了。在高时延网络条件下,这样可以降低网络的环回时间,提高性能
对管道化连接有几点注意事项: