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