欢迎光临散文网 会员登陆 & 注册

HTTP相关知识

2023-07-09 20:15 作者:大涛先生_  | 我要投稿

HTTP相关知识

http全称，超文本传输协议，属于应用层协议 ，属于无状态协议，面向对象的协议;

HTTP工作原理：

HTTP是基于客户/服务器模式，且面向连接的。典型的HTTP事务处理有如下的过程：^ [7]^

（1）客户与服务器建立连接；

（2）客户向服务器提出请求；

（3）服务器接受请求，并根据请求返回相应的文件作为应答；

（4）客户与服务器关闭连接。

发展阶段，

HTTP1.0和HTTP2.0的区别

总的区别就是：

  1. HTTP/2采用二进制格式而非文本格式

  2. HTTP/2是完全多路复用的，而非有序并阻塞的——只需一个连接即可实现并行

  3. 使用报头压缩，HTTP/2降低了开销

  4. HTTP/2让服务器可以将响应主动“推送”到客户端缓存中

1.多路复用和二进制帧

HTTP/1.x 有个问题叫线端阻塞(head-of-line blocking), 它是指一个连接(connection)一次只提交一个请求的效率比较高, 多了就会变慢。 HTTP/1.1 试过用流水线(pipelining)来解决这个问题, 但是效果并不理想(数据量较大或者速度较慢的响应, 会阻碍排在他后面的请求). 此外, 由于网络媒介(intermediary )和服务器不能很好的支持流水线, 导致部署起来困难重重。而多路传输(Multiplexing)能很好的解决这些问题, 因为它能同时处理多个消息的请求和响应; 甚至可以在传输过程中将一个消息跟另外一个掺杂在一起。所以客户端只需要一个连接就能加载一个页面。

多路复用允许单一的 HTTP/2 连接同时发起多重的请求-响应消息。如下图：

从这张图可以看出，请求index.html页面的时候，浏览器会去请求style.css和scripts.js的文件。左边的图是顺序加载两个个文件的，右边则是并行加载两个文件。

我们知道，TCP连接相当于两根管道（双工，一个用于服务器到客户端，一个用于客户端到服务器），管道里面数据传输是通过字节码传输，传输是有序的，每个字节都是一个一个来传输。

例如客户端要向服务器发送Hello、World两个单词，只能是先发送Hello再发送World，没办法同时发送这两个单词。不然服务器收到的可能就是HWeolrllod（注意是穿插着发过去了，但是顺序还是不会乱）。这样服务器就懵b了。

接上面的问题，能否同时发送Hello和World两个单词能，当然也是可以的，可以将数据拆成包，给每个包打上标签。发的时候是这样的①H ②W ①e ②o ①l ②r ①l ②l ①o ②d。这样到了服务器，服务器根据标签把两个单词区分开来。实际的发送效果如下图：

二进制分帧可以实现上面的效果，二进制分帧层在 应用层(HTTP/2)和传输层(TCP or UDP)之间。HTTP/2并没有去修改TCP协议而是尽可能的利用TCP的特性。

在二进制分帧层中， HTTP/2 会将所有传输的信息分割为帧（frame）,并对它们采用二进制格式的编码 ，其中 首部信息会被封装到 HEADER frame，而相应的 Request Body 则封装到 DATA frame 里面。

HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我「调谐」，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。

HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升。

2.首部压缩

在 HTTP/1 中，HTTP 请求和响应都是由「状态行、请求 / 响应头部、消息主体」三部分组成。一般而言，消息主体都会经过 gzip 压缩，或者本身传输的就是压缩过后的二进制文件（例如图片、音频），但状态行和头部却没有经过任何压缩，直接以纯文本传输。

随着 Web 功能越来越复杂，每个页面产生的请求数也越来越多，导致消耗在头部的流量越来越多，尤其是每次都要传输 UserAgent、Cookie 这类不会频繁变动的内容，完全是一种浪费。

我们再用通俗的语言解释下，压缩的原理。头部压缩需要在支持 HTTP/2 的浏览器和服务端之间：

  • 维护一份相同的静态字典（Static Table），包含常见的头部名称，以及特别常见的头部名称与值的组合；

  • 维护一份相同的动态字典（Dynamic Table），可以动态的添加内容；

  • 支持基于静态哈夫曼码表的哈夫曼编码（Huffman Coding）；

静态字典的作用有两个：

1）对于完全匹配的头部键值对，例如 “:method :GET”，可以直接使用一个字符表示；

2）对于头部名称可以匹配的键值对，例如 “cookie :xxxxxxx”，可以将名称使用一个字符表示。

HTTP/2 中的静态字典如下（以下只截取了部分，完整表格在这里）：

同时，浏览器和服务端都可以向动态字典中添加键值对，之后这个键值对就可以使用一个字符表示了。需要注意的是，动态字典上下文有关，需要为每个 HTTP/2 连接维护不同的字典。在传输过程中使用，使用字符代替键值对大大减少传输的数据量。

3.HTTP2支持服务器推送

服务端推送是一种在客户端请求之前发送数据的机制。当代网页使用了许多资源:HTML、样式表、脚本、图片等等。在HTTP/1.x中这些资源每一个都必须明确地请求。这可能是一个很慢的过程。浏览器从获取HTML开始，然后在它解析和评估页面的时候，增量地获取更多的资源。因为服务器必须等待浏览器做每一个请求，网络经常是空闲的和未充分使用的。

为了改善延迟，HTTP/2引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前。一个服务器经常知道一个页面需要很多附加资源，在它响应浏览器第一个请求的时候，可以开始推送这些资源。这允许服务端去完全充分地利用一个可能空闲的网络，改善页面加载时间

image-20230709201239294

其实说白了，就是HTTP2.0中，浏览器在请求HTML页面的时候，服务端会推送css、js等其他资源给浏览器，减少网络空闲浪费。

二、HTTP和HTTPS的区别

HTTPS：是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

SSL：是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。HTTPS就是在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

image-20230709201207124

HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。

两者主要区别如下：

   1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。

　　2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。

　　3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

　　4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

HTTPS的工作原理：

客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤，如图所示。

　　（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。

　　（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。

　　（3）客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。

　　（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。

　　（5）Web服务器利用自己的私钥解密出会话密钥。

　　（6）Web服务器利用会话密钥加密与客户端之间的通信。

https://www.cnblogs.com/frankyou/p/6145485.html

https://www.cnblogs.com/wqhwe/p/5407468.html

DNS基本概念

根域

就是所谓的 “.”，其实我们的网址 www.baidu.com 在配置当中应该是 www.baidu.com.（最后有一点），一般我们在浏览器里输入时会省略后面的点，而这也已经成为了习惯。根域服务器我们知道有 13 台，但是这是错误的观点。

根域服务器只是具有 13 个 IP 地址，但机器数量却不是 13 台，因为这些 IP 地址借助了任播的技术，所以我们可以在全球设立这些 IP 的镜像站点，你访问到的这个 IP 并不是唯一的那台主机。

域的划分

根域下来就是顶级域或者叫一级域，有两种划分方式，一种互联网刚兴起时的按照行业性质划分的 com.，net. 等，一种是按国家划分的如 cn.，jp.，等。具体多少你可以自己去查，我们这里不关心。

每个域都会有域名服务器，也叫权威域名服务器。Baidu.com 就是一个顶级域名，而 www.baidu.com 却不是顶级域名，他是在 baidu.com 这个域里的一叫做 www 的主机。

一级域之后还有二级域，三级域，只要我买了一个顶级域，并且我搭建了自己 BIND 服务器（或者其他软件搭建的）注册到互联网中，那么我就可以随意在前面多加几个域了（当然长度是有限制的）。

比如 a.www.baidu.com，在这个网址中，www.baidu.com 变成了一个二级域而不是一台主机，主机名是 a。

域名服务器

能提供域名解析的服务器，上面的记录类型可以是 A(address)记录，NS 记录（name server），MX（mail），CNAME 等。

A 记录是什么意思呢，就是记录一个 IP 地址和一个主机名字，比如我这个域名服务器所在的域 test.baidu.com，我们知道这是一个二级的域名，然后我在里面有一条 A 记录,记录了主机为 a 的 IP，查到了就返回给你了。

如果我现在要想 baidu.com 这个域名服务器查询 a.test.baidu.com，那么这个顶级域名服务器就会发现你请求的这个网址在 test.baidu.com 这个域中，我这里记录了这个二级域的域名服务器 test.baidu.com 的 NS 的 IP。我返回给你这个地址你再去查主机为 a 的主机把。

这些域内的域名服务器都称为权威服务器，直接提供 DNS 查询服务。（这些服务器可不会做递归哦）

DNS解析过程

那么我们的 DNS 是怎么解析一个域名的呢？

  1. 现在我有一台计算机，通过 ISP 接入了互联网，那么 ISP 就会给我分配一个 DNS 服务器，这个 DNS 服务器不是权威服务器，而是相当于一个代理的 dns 解析服务器，他会帮你迭代权威服务器返回的应答，然后把最终查到 IP 返回给你。

  2. 现在的我计算机要向这台 ISPDNS 发起请求查询 www.baidu.com 这个域名了，(这里其实准确来说不是 ISPDNS，而应该是用户自己电脑网络设置里的 DNS，并不一定是 ISPDNS。比如也有可能你手工设置了 8.8.8.8)。

  3. ISPDNS 拿到请求后，先检查一下自己的缓存中有没有这个地址，有的话就直接返回。这个时候拿到的 ip 地址，会被标记为非权威服务器的应答。

  4. 如果缓存中没有的话，ISPDNS 会从配置文件里面读取 13 个根域名服务器的地址（这些地址是不变的，直接在 BIND 的配置文件中）。

  5. 然后像其中一台发起请求。

  6. 根服务器拿到这个请求后，知道他是 com. 这个顶级域名下的，所以就会返回 com 域中的 NS 记录，一般来说是 13 台主机名和 IP。

  7. 然后 ISPDNS 向其中一台再次发起请求，com 域的服务器发现你这请求是 baidu.com 这个域的，我一查发现了这个域的 NS，那我就返回给你，你再去查。（目前百度有 4 台 baidu.com 的顶级域名服务器）。

  8. ISPDNS 不厌其烦的再次向 baidu.com 这个域的权威服务器发起请求，baidu.com 收到之后，查了下有 www 的这台主机，就把这个 IP 返回给你了，

  9. 然后 ISPDNS 拿到了之后，将其返回给了客户端，并且把这个保存在高速缓存中。

下面我们来用 nslookup 这个工具详细来说一下解析步骤：

27_DNS解析全过程.png

从上图我们可以看到:

  1. 第一行 Server 是：DNS 服务器的主机名 – 192.168.110.10

  2. 第二行A ddress 是： 它的 IP 地址 – 192.168.110.10#53

  3. 下面的 Name 是：解析的 URL – www.jsjzx.com

  4. Address 是：解析出来的 IP – 192.168.110

但是也有像百度这样的 DNS 比较复杂的解析:

28_DNS解析全过程.png

你会发现百度有一个 cname = www.a.shifen.com 的别名。这是怎么一个过程呢？我们用 dig 工具来跟踪一下，Dig 工具会在本地计算机做迭代，然后记录查询的过程。

29_DNS解析全过程.png

第一步是向我这台机器的 ISPDNS 获取到根域服务区的 13 个 IP 和主机名 [b-j].root-servers.net.。

30_DNS解析全过程.png

第二步是向其中的一台根域服务器（Servername 就是末行小括号里面的）发送 www.baidu.com 的查询请求，他返回了 com. 顶级域的服务器 IP（未显示）和名称，

31_DNS解析全过程.png

第三步，便向 com. 域的一台服务器 192.33.4.12 请求 www.baidu.com，他返回了 baidu.com 域的服务器 IP（未显示）和名称，百度有四台顶级域的服务器

32_DNS解析全过程.png

第四步呢，向百度的顶级域服务器（202.108.22.220）请求 www.baidu.com，他发现这个 www 有个别名，而不是一台主机，别名是 www.a.shifen.com。

33_DNS解析全过程.png

按照一般的逻辑，当 dns 请求到别名的时候，查询会终止，而是重新发起查询别名的请求，所以此处应该返回的是 www.a.shifen.com 而已。但是为什么返回 a.shifen.com 的这个域的 NS 呢？

我们可以尝试下面的这个命令：dig +trace shifen.com 看看有什么结果：

34_DNS解析全过程.png

你会发现第三步时 shifen.com 这个顶级域的域名服务器和 baidu.com 这个域的域名服务器是同一台主机（即：dns.baidu.com）！当我拿到 www.baidu.com 的别名 www.a.shifen.com 的时候，我本来需要重新到 com 域查找 shifen.com 域的 NS，但是因为这两个域在同一台 NS 上，所以直接向本机发起了，

shifen.com 域发现请求的 www.a.shifen.com 是属于 a.shifen.com 这个域的，于是就把 a.shifen.com 的这个 NS 和 IP 返回，让我到 a.shifen.com 这个域的域名服务器上查询 www.a.shifen.com。

于是我便从 ns X .a.shifen.com 中一台拿到了一条 A 记录，最终的最终也便是 www.baidu.com 的 IP 地址了。【此处也可以用 dig +trace www.a.shifen.com】跟踪一下，用一个图来说明一下(图中第三步的全世界只有 13 台是错误的)

35_DNS解析全过程.png

以下内容为在虚拟机中搭建 local dns 服务器得到的实验数据，纠正上述结论。在上面的分析中，我们用 dig 工具进行了追踪，但是 dig 没有继续追踪当我们从 baidu.com 拿到 cname 和 ns2.a.shifen.com 的 IP 之后的事情。

我们就所以然的下结论认为 local dns 会向 ns2.a.shifen.com 请求 www.a.shifen.com。其实这个想法是错误，在自己的本地搭建一个 local dns，抓取整个解析过程中是所有包，看看就明白拉。

实际的结果是虽然 dns.baidu.com 返回了 a.shifen.com 域的服务器地址和 IP，但是 local dns 并不是直接向上述返回的 IP 请求 www.a.shifen.com，而是再一次去请求 com 域，得到 shifen.com 域的服务器（也就是 baidu.com 的那四台），然后又请求 www.a.shifen.com，返回 a.shifen.com 的域的服务器，最后才是去请求 www.a.shifen.com，

虽然上面已经返回了 IP，但是实验的结果就是再走一遍 shifen.com 域的查询。

上图就是 localdns 在解析 www.baidu.com 的抓包全过程。蓝色那条就是在收到 cname 和响应的 a.shifen.com 的域名服务器 IP 地址之后，继续向 com 域请求 shifen.com。

这个图充分说明了返回 cname 的同时也返回了 ns2.a.shifen.com 的 IP。

相关术语

类型编码内容A1将 DNS 域名映射到 IPv4 地址，基本作用是说明一个域名对应了哪些 IPv4 地址NS2权威名称服务器记录，用于说明这个区域有哪些 DNS 服务器负责解析CNAME5别名记录，主机别名对应的规范名称SOA6起始授权机构记录，NS 记录说明了有多台服务器在进行解析，但哪一个才是主服务器，NS 并没有说明，SOA 记录了说明在众多 NS 记录里哪一台才是主要的服务器PTR12IP 地址反向解析，是 A 记录的逆向记录，作用是把 IP 地址解析为域名MX15邮件交换记录，指定负责接收和发送到域中的电子邮件的主机TXT16文本资源记录，用来为某个主机名或域名设置的说明AAAA28将 DNS 域名映射到 IPv6 地址，基本作用是说明一个域名对应了哪些 IPv6 地址

总结

因此总结一下便是：

  1. 本机向 local dns 请求 www.baidu.com

  2. local dns 向根域请求 www.baidu.com，根域返回 com. 域的服务器 IP

  3. 向 com. 域请求 www.baidu.com，com. 域返回 baidu.com 域的服务器 IP

  4. 向 baidu.com 请求 www.baidu.com，返回 cname www.a.shifen.com 和 a.shifen.com 域的服务器 IP

  5. 向 root 域请求 www.a.shifen.com

  6. 向 com. 域请求 www.a.shifenc.om

  7. 向 shifen.com 请求

  8. 向 a.shifen.com 域请求

  9. 拿到 www.a.shifen.com 的 IP

  10. local dns 返回本机 www.baidu.com cname www.a.shifen.com 以及 www.a.shifen.com 的 IP、

TCP相关知识

tcp简介 ：面向字节流 可靠的 面相连接的协议

面向连接：意味着交换数据之前，需要建立完整的TCP连接，

基于字节流：交换的数据格式是字节（byte）构成有序，但是无结构的 字节流，连接正常建立完成，客户端发送无特殊格式的字节流，存在缓冲结构用于接收数据。

TCP报文结构：

  1. 端口号：

  2. 序号

  3. 确认序号

  4. 首部长度

  5. 保留字段

  6. 控制位

  7. 窗口大小

  8. 校验和

  9. 紧急指针

  10. 选项

  11. 有效数据部分

可靠性：确保可靠性依靠如下手段

  1. 合理的数据大小：

  2. 校验和

  3. 序号和确认序号

  4. 超时重传

  5. 连接管理：三次握手，四次挥手

  6. 流量控制

  7. 拥塞控制

TCP 和 UDP 的区别

具体区别：

UDPTCP是否连接无连接面向连接是否可靠不可靠，没有确认机制、流量控制和拥塞控制可靠，有确认机制、流量控制和拥塞控制连接对象个数支持一对一，一对多，多对一和多对多交互通信只支持一对一通信传输方式面向报文面向字节流首部开销首部开销小，固定8字节首部开销较大，最小20字节，最大60字节适用场景适用于实时应用(IP电话、视频会议、直播等)适用于要求可靠传输的应用，如文件传输等

TCP的连接控制：

建立连接

三次握手：

  1. 第一次握手：客户端发送SYN=1 标识建立连接，并初始化seq，发送完成客户端进入 SYN-SENT状态，等待服务端确认

  2. 第二次握手：序号 seq 设置为服务器初始序号y。发送完报文段2后，服务器进入 SYN-RECEIVED 状态

  3. 第三次握手：客户端在收到报文段2后，向服务器发送报文段3，其 ACK 标志位为1，代表对服务器做出应答，确认序号字段 ack 为 y + 1，序号字段 seq 为 x + 1。此报文段发送完毕后，双方都进入 ESTABLISHED 状态，表示连接已建立。

常见面试题 1： TCP 建立连接为什么要三次握手而不是两次？

A1：

  1. TCP 实现了可靠的数据传输，原因之一就是 TCP 报文段中维护了序号字段和确认序号字段，如果是两次握手，只有发起方的初始序号可以得到确认，而另一方的初始序号则得不到确认。

  2. 三次握手才能让双方均确认自己和对方的发送和接收能力都正常

  3. 防止已过期的连接请求报文突然又传送到服务器，因而产生错误

常见面试题2： TCP 建立连接为什么要三次握手而不是四次？

A2：相比上个问题而言，这个问题就简单多了。因为三次握手已经可以确认双方的发送接收能力正常，双方都知道彼此已经准备好，而且也可以完成对双方初始序号值得确认，也就无需再第四次握手了。

常见面试题3： 有一种网络攻击是利用了 TCP 建立连接机制的漏洞，你了解吗？这个问题怎么解决？

A3：在三次握手过程中，服务器在收到了客户端的 SYN 报文段后，会分配并初始化连接变量和缓存，并向客户端发送 SYN + ACK 报文段，攻击者发送大量的 SYN 报文段到服务器请求建立连接，但是却不进行第三次握手，这会导致服务器打开大量的半开连接，消耗大量的资源，最终无法进行正常的服务。

四次挥手：

  1. 客户端发送关闭连接的报文段，FIN 标志位1，请求关闭连接，并停止发送数据。序号字段 seq = x (等于之前发送的所有数据的最后一个字节的序号加一)，然后客户端会进入 FIN-WAIT-1 状态，等待来自服务器的确认报文。

  2. 服务器收到 FIN 报文后，发回确认报文，ACK = 1， ack = x + 1，并带上自己的序号 seq = y，然后服务器就进入 CLOSE-WAIT 状态。服务器还会通知上层的应用程序对方已经释放连接，此时 TCP 处于半关闭状态，也就是说客户端已经没有数据要发送了，但是服务器还可以发送数据，客户端也还能够接收。

  3. 客户端收到服务器的 ACK 报文段后随即进入 FIN-WAIT-2 状态，此时还能收到来自服务器的数据，直到收到 FIN 报文段。

  4. 服务器发送完所有数据后，会向客户端发送 FIN 报文段，各字段值如图所示，随后服务器进入 LAST-ACK 状态，等待来自客户端的确认报文段。

  5. 客户端收到来自服务器的 FIN 报文段后，向服务器发送 ACK 报文，随后进入 TIME-WAIT 状态，等待 2MSL(2 * Maximum Segment Lifetime，两倍的报文段最大存活时间) ，这是任何报文段在被丢弃前能在网络中存在的最长时间，常用值有30秒、1分钟和2分钟。如无特殊情况，客户端会进入 CLOSED 状态。

  6. 服务器在接收到客户端的 ACK 报文后会随即进入 CLOSED 状态，由于没有等待时间，一般而言，服务器比客户端更早进入 CLOSED 状态。

常见面试题1： 为什么 TCP 关闭连接为什么要四次而不是三次？

A1：在数据发送完后，服务器会向客户单发送 FIN 报文，表示数据已经发送完毕，请求关闭连接，然后客户端再做出应答，因此一共需要四次挥手。

常见面试题2： 客户端为什么需要在 TIME-WAIT 状态等待 2MSL 时间才能进入 CLOSED 状态？

A2：客户端为了确保服务器收到了 ACK，会设置一个定时器，并在 TIME-WAIT 状态等待 2MSL 的时间，如果在此期间又收到了来自服务器的 FIN 报文段，那么客户端会重新设置计时器并再次等待 2MSL 的时间，如果在这段时间内没有收到来自服务器的 FIN 报文，那就说明服务器已经成功收到了 ACK 报文，此时客户端就可以进入 CLOSED 状态了。

TCP 的流量控制与滑动窗口

什么是 流量控制 ？

TCP 连接双方的主机都为该连接设置了发送缓存和接收缓存，这些缓存起到了蓄水池的作用

滑动窗口

发送缓存中的字节分类

  1. 第一类：已发送且已确认，这些数据已经发送成功并已经被确认的数据，比如图中的前31个bytes，这些数据其实的位置是在窗口之外了，下一步将被移出发送缓存。窗口内顺序最低的字节被确认之后，窗口左边界会向右移动，称为窗口合拢。

  2. 第二类：已发送但未收到确认，这部分数据已经被发送出去，但是还没有收到接收端的 ACK，认为并没有完成发送，这部分数据属于窗口内的数据。

  3. 第三类：未发送但是接收方已经准备好接收，这部分是尽快发送的数据，这部分数据已经被加载到缓存中，也在发送窗口中，正在等待发送，其实这个窗口是完全有接收方告知的，接收方告知当前可以接受这些数据，所以发送方需要尽快的发送。

  4. 第四类：未发送且接收方未准备好接收，这些数据属于未发送，同时接收端也不允许发送的，因为这些数据已经超出了发送端所接收的范围。


标签：

HTTP相关知识的评论 (共 条)

分享到微博请遵守国家法律