JAVA WAB系列--HTTP攻略

HTTP:是互联网上应用最为广泛的一种网络协议,是一个客户端和服务器端请求和应答的标准(TCP),用于从WWW服务器传输超文本到本地浏览器的传输协议,它可以使浏览器更加高效,使网络传输减少。


HTTP 状态码详解


1xx:信息性状态码,表示服务器已接收了客户端请求,客户端可继续发送请求。

  • 100(Continue / 继续):如果服务器收到头信息中带有 100-continue 的请求,这是指客户端询问是否可以在后续的请求中发送附件。在这种情况下,服务器用 100(SC_CONTINUE) 允许客户端继续或用 417 (Expectation Failed) 告诉客户端不同意接受附件。这个状态码是 HTTP 1.1 中新加入的。
  • 101(Switching Protocols / 转换协议):101 (SC_SWITCHING_PROTOCOLS) 状态码是指服务器将按照其上的头信息变为一个不同的协议。这是 HTTP 1.1 中新加入的。

2xx:成功状态码,表示服务器已成功接收到请求并进行处理

  • 200(OK / 正常):返回正常
  • 201(Created / 已创建):表示服务器在请求过程中已经建立了新文档,应在头信息中给出他的 URL
  • 202(Accepted / 接受):告诉客户端,请求还在执行,没有处理完
  • 203 (Non-Authoritative Information / 非官方信息):状态码 203 (SC_NON_AUTHORITATIVE_INFORMATION) 是表示文 - 档被正常的返回,但是由于正在使用的是文档副本所以某些响应头信息可能不正确。这是 HTTP 1.1 中新加入的。
  • 204(NO Content / 无内容):在并没有新文档的情况下,204 (SC_NO_CONTENT) 确保浏览器继续显示先前的文档。这各状态码对于用户周期性的重载某一页非常有用,并且你可以确定先前的页面是否已经更新。
  • 205 (Reset Content / 重置内容):重置内容 205 (SC_RESET_CONTENT) 的意思是虽然没有新文档但浏览器要重置文档显示。这个状态码用于强迫浏览器清除表单域。这是 HTTP 1.1 中新加入的。
  • 206 (Partial Content / 局部内容):206 (SC_PARTIAL_CONTENT) 是在服务器完成了一个包含 Range 头信息的局部请求时被发送的。这是 HTTP 1.1 中新加入的。

3xx:用户已经移动的文件并且常被包含在定位头信息中指定的新的地址信息

  • 300(Multiple Choices / 多重选择):表示被请求的文件可以在多个地方得到,并将在放回的文档中列出。如果服务器有首选设置,首选项将会被列于定位相应头的信息中。
  • 301(Moved Permanently):指所请求的文档在别的地方,文档新的 URL 会定位相应头信息中给出。浏览器会自动连接到新的 URL
  • 302(Found / 找到):与 301 有些类似,只是定位头信息中所给的 URL 应被理解为临时交换地址而不是永久的。注意:在 HTTP 1.0 中,消息是临时移动 (Moved Temporarily) 的而不是被找到,因此 HttpServletResponse 中的常量是 SC_MOVED_TEMPORARILY 不是我们以为的 SC_FOUND。
  • 303 (See Other / 参见其他信息):这个状态码和 301、302 相似,只是如果最初的请求是 POST,那么新文档(在定位头信息中给出)要用 GET 找回。这个状态码是新加入 HTTP 1.1 中的。
  • 304(Not Modified / 为修正):当客户端有一个缓存的文档,通过提供一个 If-Modified-Since 头信息可指出客户端只希望文档在指定日期之后有所修改时才会重载此文档,用这种方式可以进行有条件的请求。304 (SC_NOT_MODIFIED)是指缓冲的版本已经被更新并且客户端应刷新文档。另外,服务器将返回请求的文档及状态码 200。servlet 一般情况下不会直接设置这个状态码。它们会实现 getLastModified 方法并根据修正日期让默认服务方法处理有条件的请求。这个方法的例程已在 2.8 部分 (An Example Using Servlet Initialization and Page Modification Dates / 一个使用 servlet 初始化和页面修正日期的例子) 给出。
  • 305(Use Proxy / 使用代理):表示所请求的文档要通过定位头信息中的代理服务器获得
  • 307(Temporary Redirect / 临时重定向):浏览器处理 307 状态的规则与 302 相同。307 状态被加入到 HTTP 1.1 中是由于许多浏览器在收到 302 响应时即使是原始消息为 POST 的情况下仍然执行了错误的转向。只有在收到 303 响应时才假定浏览器会在 POST 请求时重定向。添加这个新的状态码的目的很明确:在响应为 303 时按照 GET 和 POST 请求转向;而在 307 响应时则按照 GET 请求转向而不是 POST 请求。注意:由于某些原因在 HttpServletResponse 中还没有与这个状态对应的常量。该状态码是新加入 HTTP 1.1 中的。

4xx:用户指定客户端的错误

  • 400(Bad Request / 错误请求):指出客户端请求中的语法错误
  • 401(Unauthorized / 未授权):表示客户端在授权头信息中没有有效的身份信息时,访问收到密码保护的页面。这个授权必须包含一个 WWW-Authenticate 的授权信息头
  • 403(Forbidden / 禁止):表示除非拥有授权,否则服务器拒绝提供所请求的资源。
  • 404(Not Found):无法找到资源
  • 405 (Method Not Allowed / 方法未允许):指出请求方法 (GET, POST, HEAD, PUT, DELETE, 等) 对某些特定的资源不允许使用。该状态码是新加入 HTTP 1.1 中的。
  • 406 (Not Acceptable / 无法访问):表示请求资源的 MIME 类型与客户端中 Accept 头信息中指定的类型不一致。406 是新加入 HTTP 1.1 中的。
  • 407 (Proxy Authentication Required / 代理服务器认证要求):与 401 状态有些相似,只是这个状态用于代理服务器。该状态指出客户端必须通过代理服务器的认证。代理服务器返回一个 Proxy-Authenticate 响应头信息给客户端,这会引起客户端使用带有 Proxy-Authorization 请求的头信息重新连接。该状态码是新加入 HTTP 1.1 中的。
  • 408 (Request Timeout / 请求超时):是指服务端等待客户端发送请求的时间过长。该状态码是新加入 HTTP 1.1 中的。
  • 409 (Conflict / 冲突):该状态通常与 PUT 请求一同使用,409 (SC_CONFLICT) 状态常被用于试图上传版本不正确的文件时。该状态码是新加入 HTTP 1.1 中的。
  • 410 (Gone / 已经不存在):告诉客户端所请求的文档已经不存在并且没有更新的地址。410 状态不同于 404,410 是在指导文档已被移走的情况下使用,而 404 则用于未知原因的无法访问。该状态码是新加入 HTTP 1.1 中的。
  • 411 (Length Required / 需要数据长度):表示服务器不能处理请求(假设为带有附件的 POST 请求),除非客户端发送 Content-Length 头信息指出发送给服务器的数据的大小。该状态是新加入 HTTP 1.1 的。
  • 412 (Precondition Failed / 先决条件错误):状态指出请求头信息中的某些先决条件是错误的。该状态是新加入 HTTP 1.1 的。
  • 413 (Request Entity Too Large / 请求实体过大):告诉客户端现在所请求的文档比服务器现在想要处理的要大。如果服务器认为能够过一段时间处理,则会包含一个 Retry-After 的响应头信息。该状态是新加入 HTTP 1.1 的。
  • 414 (Request URI Too Long / 请求 URI 过长):状态用于在 URI 过长的情况时。这里所指的 “URI” 是指 URL 中主机、域名及端口号之后的内容。例如:在 URL–http://www.42one.xyz:8080/we/look/silly/now / 中 URI 是指 / we/look/silly/now/。该状态是新加入 HTTP 1.1 的。
  • 415 (Unsupported Media Type / 不支持的媒体格式):意味着请求所带的附件的格式类型服务器不知道如何处理。该状态是新加入 HTTP 1.1 的。
  • 416 (Requested Range Not Satisfiable / 请求范围无法满足):表示客户端包含了一个服务器无法满足的 Range 头信息的请求。该状态是新加入 HTTP 1.1 的。奇怪的是,在 servlet 2.1 版本 API 的 HttpServletResponse 中并没有相应的常量代表该状态。
  • 417 (Expectation Failed / 期望失败):如果服务器得到一个带有 100-continue 值的 Expect 请求头信息,这是指客户端正在询问是否可以在后面的请求中发送附件。在这种情况下,服务器也会用该状态 (417) 告诉浏览器服务器不接收该附件或用 100 (SC_CONTINUE)状态告诉客户端可以继续发送附件。该状态是新加入 HTTP 1.1 的。

5xx:用户指定服务器的错误

  • 500 (Internal Server Error / 内部服务器错误):是常用的 “服务器错误” 状态。该状态经常由 CGI 程序引起也可能(但愿不会如此!)由无法正常运行的或返回头信息格式不正确的 servlet 引起。
  • 501 (Not Implemented / 未实现):告诉客户端服务器不支持请求中要求的功能。例如,客户端执行了如 PUT 这样的服务器并不支持的命令。
  • 502 (Bad Gateway / 错误的网关):被用于充当代理或网关的服务器;该状态指出接收服务器接收到远端服务器的错误响应。
  • 503 (Service Unavailable / 服务无法获得):表示服务器由于在维护或已经超载而无法响应。例如,如果某些线程或数据库连接池已经没有空闲则 servlet 会返回这个头信息。服务器可提供一个 Retry-After 头信息告诉客户端什么时候可以在试一次。
  • 504 (Gateway Timeout / 网关超时):该状态也用于充当代理或网关的服务器;它指出接收服务器没有从远端服务器得到及时的响应。该状态是新加入 HTTP 1.1 的。
  • 505 (HTTP Version Not Supported / 不支持的 HTTP 版本):是说服务器并不支持在请求中所标明 HTTP 版本。该状态是新加入 HTTP 1.1 的。

HTTP有哪些方法?


  • HTTP1.0定义了三种请求方法: GET, POST 和 HEAD方法
  • HTTP1.1新增了五种请求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT

HTTP方法的具体作用是什么?


  • GET: 通常用于请求服务器发送某些资源
  • HEAD: 请求资源的头部信息, 并且这些头部与 HTTP GET 方法请求时返回的一致. 该请求方法的一个使用场景是在下载一个大文件前先获取其大小再决定是否要下载, 以此可以节约带宽资源
  • OPTIONS: 用于获取目的资源所支持的通信选项
  • POST: 发送数据给服务器
  • PUT: 用于新增资源或者使用请求中的有效负载替换目标资源的表现形式
  • DELETE: 用于删除指定的资源
  • PATCH: 用于对资源进行部分修改
  • CONNECT: HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器
  • TRACE: 回显服务器收到的请求,主要用于测试或诊断

GET和POST有什么区别?


提交位置

  • GET 提交,请求的数据会附在 URL 之后(就是把数据放置在 HTTP 协议头中),以? 分割 URL 和传输数据,多个参数用 & 连接;例 如:login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果数据是英文字母 / 数字,原样发送,如果是空格,转换为 +,如果是中文 / 其他字符,则直接把字符串用 BASE64 加密,得出如: %E4%BD%A0%E5%A5%BD,其中%XX 中的 XX 为该符号以 16 进制表示的 ASCII。

  • POST 提交:把提交的数据放置在是 HTTP 包的包体中。上文示例中红色字体标明的就是实际的传输数据

因此,GET 提交的数据会在地址栏中显示出来,而 POST 提交,地址栏不会改变

传输数据的大小

首先声明:HTTP 协议没有对传输的数据大小进行限制,HTTP 协议规范也没有对 URL 长度进行限制。

而在实际开发中存在的限制主要有:

GET: 特定浏览器和服务器对 URL 长度有限制,例如 IE 对 URL 长度的限制是 2083 字节 (2K+35)。对于其他浏览器,如 Netscape、FireFox 等,理论上没有长度限制,其限制取决于操作系 统的支持。

因此对于 GET 提交时,传输数据就会受到 URL 长度的 限制。

POST: 由于不是通过 URL 传值,理论上数据不受 限。但实际各个 WEB 服务器会规定对 post 提交数据大小进行限制,Apache、IIS6 都有各自的配置。

安全性

POST 的安全性要比 GET 的安全性高。比如:通过 GET 提交数据,用户名和密码将明文出现在 URL 上,因为 (1) 登录页面有可能被浏览器缓存;(2)其他人查看浏览器的历史纪录,那么别人就可以拿到你的账号和密码了,除此之外,使用 GET 提交数据还可能会造成 Cross-site request forgery 攻击

Http get,post,soap 协议都是在 http 上运行的

  • get:请求参数是作为一个 key/value 对的序列(查询字符串)附加到 URL 上的
    查询字符串的长度受到 web 浏览器和 web 服务器的限制(如 IE 最多支持 2048 个字符),不适合传输大型数据集同时,它很不安全

  • post:请求参数是在 http 标题的一个不同部分(名为 entity body)传输的,这一部分用来传输表单信息,因此必须将 Content-type 设置为: application/x-www-form- urlencoded。post 设计用来支持 web 窗体上的用户字段,其参数也是作为 key/value 对传输。
    但是:它不支持复杂数据类型,因为 post 没有定义传输数据结构的语义和规则。

  • soap:是 http post 的一个专用版本,遵循一种特殊的 xml 消息格式
    Content-type 设置为: text/xml 任何数据都可以 xml 化。

总结

  • 数据传输方式不同:GET请求通过URL传输数据,而POST的数据通过请求体传输。
  • 安全性不同:POST的数据因为在请求主体内,所以有一定的安全性保证,而GET的数据在URL中,通过历史记录,缓存很容易查到数据信息。
  • 数据类型不同:GET只允许 ASCII 字符,而POST无限制
  • GET无害: 刷新、后退等浏览器操作GET请求是无害的,POST可能重复提交表单
  • 特性不同:GET是安全(这里的安全是指只读特性,就是使用这个方法不会引起服务器状态变化)且幂等(幂等的概念是指同一个请求方法执行多次和仅执行一次的效果完全相同),而POST是非安全非幂等

PUT和POST都是给服务器发送新增资源,有什么区别?


PUT 和POST方法的区别是,PUT方法是幂等的:连续调用一次或者多次的效果相同(无副作用),而POST方法是非幂等的。

除此之外还有一个区别,通常情况下,PUT的URI指向是具体单一资源,而POST可以指向资源集合。

举个例子,我们在开发一个博客系统,当我们要创建一篇文章的时候往往用POST https://www.42one.xyz/articles,这个请求的语义是,在articles的资源集合下创建一篇新的文章,如果我们多次提交这个请求会创建多个文章,这是非幂等的。

PUT https://www.42one.xyz/http-status-code的语义是更新对应文章下的资源(比如修改作者名称等),这个URI指向的就是单一资源,而且是幂等的,比如你把『刘德华』修改成『蔡徐坤』,提交多少次都是修改成『蔡徐坤』

ps: 『POST表示创建资源,PUT表示更新资源』这种说法是错误的,两个都能创建资源,根本区别就在于幂等性


PUT和PATCH都是给服务器发送修改资源,有什么区别?


PUT和PATCH都是更新资源,而PATCH用来对已知资源进行局部更新。

http的请求报文是什么样的?


例子:

1
2
3
4
5
6
7
8
9
GET /2019/08/01/http-status-code/ HTTP/1.1
Host: localhost:4000
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Referer: http://localhost:4000/
Accept-Encoding: gzip, deflate, br

请求报文有4部分组成:

  • 请求行包括:请求方法字段、URL字段、HTTP协议版本字段。它们用空格分隔。例如,GET /index.html HTTP/1.1。
  • 请求头部:请求头部由关键字/值对组成,每行一对,关键字和值用英文冒号“:”分隔
  1. User-Agent:产生请求的浏览器类型。
  2. Accept:客户端可识别的内容类型列表。
  3. Host:请求的主机名,允许多个域名同处一个IP地址,即虚拟主机。
  • 空行:请求头部后面的空行是必须的.即使第四部分的请求数据为空,也必须有空行。

  • 请求体: post put等请求携带的数据


http的响应报文是什么样的?


例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
HTTP/1.1 200 OK
X-Powered-By: Hexo
Content-Type: text/html
Date: Thu, 01 Aug 2019 09:04:05 GMT
Connection: keep-alive
Transfer-Encoding: chunked

<html>
<head></head>
<body>
<!--body goes here-->
</body>
</html>

请求报文有4部分组成:

  • 响应行: 由协议版本,状态码和状态码的原因短语组成,例如HTTP/1.1 200 OK。(第一行)
  • 响应头:响应部首组成(第二到六行)
  • 空行
  • 响应体:服务器响应的数据

HTTP的部首有哪些?


通用首部字段(General Header Fields):请求报文和响应报文两方都会使用的首部

  • Cache-Control 控制缓存 ✨
  • Connection 连接管理、逐条首部 ✨
  • Upgrade 升级为其他协议
  • via 代理服务器的相关信息
  • Wraning 错误和警告通知
  • Transfor-Encoding 报文主体的传输编码格式 ✨
  • Trailer 报文末端的首部一览
  • Pragma 报文指令
  • Date 创建报文的日期

请求首部字段(Reauest Header Fields):客户端向服务器发送请求的报文时使用的首部

  • Accept 客户端或者代理能够处理的媒体类型 ✨
  • Accept-Encoding 优先可处理的编码格式
  • Accept-Language 优先可处理的自然语言
  • Accept-Charset 优先可以处理的字符集
  • If-Match 比较实体标记(ETage) ✨
  • If-None-Match 比较实体标记(ETage)与 If-Match相反 ✨
  • If-Modified-Since 比较资源更新时间(Last-Modified)✨
  • If-Unmodified-Since比较资源更新时间(Last-Modified),与 If-Modified-Since相反 ✨
  • If-Rnages 资源未更新时发送实体byte的范围请求
  • Range 实体的字节范围请求 ✨
  • Authorization web的认证信息 ✨
  • Proxy-Authorization 代理服务器要求web认证信息
  • Host 请求资源所在服务器 ✨
  • From 用户的邮箱地址
  • User-Agent 客户端程序信息 ✨
  • Max-Forwrads 最大的逐跳次数
  • TE 传输编码的优先级
  • Referer 请求原始放的url
  • Expect 期待服务器的特定行为

响应首部字段(Response Header Fields):从服务器向客户端响应时使用的字段

  • Accept-Ranges 能接受的字节范围
  • Age 推算资源创建经过时间
  • Location 令客户端重定向的URI ✨
  • vary 代理服务器的缓存信息
  • ETag 能够表示资源唯一资源的字符串 ✨
  • WWW-Authenticate 服务器要求客户端的验证信息
  • Proxy-Authenticate 代理服务器要求客户端的验证信息
  • Server 服务器的信息 ✨
  • Retry-After 和状态码503 一起使用的首部字段,表示下次请求服务器的时间

实体首部字段(Entiy Header Fields):针对请求报文和响应报文的实体部分使用首部

  • Allow 资源可支持http请求的方法 ✨
  • Content-Language 实体的资源语言
  • Content-Encoding 实体的编码格式
  • Content-Length 实体的大小(字节)
  • Content-Type 实体媒体类型
  • Content-MD5 实体报文的摘要
  • Content-Location 代替资源的yri
  • Content-Rnages 实体主体的位置返回
  • Last-Modified 资源最后的修改资源 ✨
  • Expires 实体主体的过期资源 ✨

HTTP的keep-alive是干什么的?


在早期的HTTP/1.0中,每次http请求都要创建一个连接,而创建连接的过程需要消耗资源和时间,为了减少资源消耗,缩短响应时间,就需要重用连接。在后来的HTTP/1.0中以及HTTP/1.1中,引入了重用连接的机制,就是在http请求头中加入Connection: keep-alive来告诉对方这个请求响应完成后不要关闭,下一次咱们还用这个请求继续交流。协议规定HTTP/1.0如果想要保持长连接,需要在请求头中加上Connection: keep-alive。

keep-alive的优点:

  • 较少的CPU和内存的使用(由于同时打开的连接的减少了)
  • 允许请求和应答的HTTP管线化
  • 降低拥塞控制 (TCP连接减少了)
  • 减少了后续请求的延迟(无需再进行握手)
  • 报告错误无需关闭TCP连接

为什么有了HTTP为什么还要HTTPS?


https是安全版的http,因为http协议的数据都是明文进行传输的,所以对于一些敏感信息的传输就很不安全,HTTPS就是为了解决HTTP的不安全而生的。

HTTPS是如何保证安全的?

过程比较复杂,我们得先理解两个概念

对称加密

即通信的双方都使用同一个秘钥进行加解密,比如特务接头的暗号,就属于对称加密

对称加密虽然很简单性能也好,但是无法解决首次把秘钥发给对方的问题,很容易被hacker拦截秘钥。

非对称加密

  1. 私钥 + 公钥= 密钥对
  2. 即用私钥加密的数据,只有对应的公钥才能解密,用公钥加密的数据,只有对应的私钥才能解密
  3. 因为通信双方的手里都有一套自己的密钥对,通信之前双方会先把自己的公钥都先发给对方
  4. 然后对方再拿着这个公钥来加密数据响应给对方,等到到了对方那里,对方再用自己的私钥进行解密

非对称加密虽然安全性更高,但是带来的问题就是速度很慢,影响性能。

解决方案

那么结合两种加密方式,将对称加密的密钥使用非对称加密的公钥进行加密,然后发送出去,接收方使用私钥进行解密得到对称加密的密钥,然后双方可以使用对称加密来进行沟通。

此时又带来一个问题,中间人问题

如果此时在客户端和服务器之间存在一个中间人,这个中间人只需要把原本双方通信互发的公钥,换成自己的公钥,这样中间人就可以轻松解密通信双方所发送的所有数据。

所以这个时候需要一个安全的第三方颁发证书(CA),证明身份的身份,防止被中间人攻击。

证书中包括:签发者、证书用途、使用者公钥、使用者私钥、使用者的HASH算法、证书到期时间等

但是问题来了,如果中间人篡改了证书,那么身份证明是不是就无效了?这个证明就白买了,这个时候需要一个新的技术,数字签名

数字签名就是用CA自带的HASH算法对证书的内容进行HASH得到一个摘要,再用CA的私钥加密,最终组成数字签名。

当别人把他的证书发过来的时候,我再用同样的Hash算法,再次生成消息摘要,然后用CA的公钥对数字签名解密,得到CA创建的消息摘要,两者一比,就知道中间有没有被人篡改了。

这个时候就能最大程度保证通信的安全了。


HTTP2相对于HTTP1.x有什么优势和特点?


二进制分帧

帧:HTTP/2 数据通信的最小单位消息:指 HTTP/2 中逻辑上的 HTTP 消息。例如请求和响应等,消息由一个或多个帧组成。

流:存在于连接中的一个虚拟通道。流可以承载双向消息,每个流都有一个唯一的整数ID

HTTP/2 采用二进制格式传输数据,而非 HTTP 1.x 的文本格式,二进制协议解析起来更高效。

服务器推送

服务端可以在发送页面HTML时主动推送其它资源,而不用等到浏览器解析到相应位置,发起请求再响应。例如服务端可以主动把JS和CSS文件推送给客户端,而不需要客户端解析HTML时再发送这些请求。

服务端可以主动推送,客户端也有权利选择是否接收。如果服务端推送的资源已经被浏览器缓存过,浏览器可以通过发送RST_STREAM帧来拒收。主动推送也遵守同源策略,服务器不会随便推送第三方资源给客户端。

头部压缩

HTTP/1.x会在请求和响应中中重复地携带不常改变的、冗长的头部数据,给网络带来额外的负担。

  • HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键-值对,对于相同的数据,不再通过每次请求和响应发送
  • 首部表在HTTP/2的连接存续期内始终存在,由客户端和服务器共同渐进地更新;
  • 每个新的首部键-值对要么被追加到当前表的末尾,要么替换表中之前的值。

你可以理解为只发送差异数据,而不是全部发送,从而减少头部的信息量

多路复用

HTTP 1.x 中:如果想并发多个请求,必须使用多个 TCP 链接,且浏览器为了控制资源,还会对单个域名有 6-8个的TCP链接请求限制。

HTTP2中

  • 同域名下所有通信都在单个连接上完成。
  • 单个连接可以承载任意数量的双向数据流。
  • 数据流以消息的形式发送,而消息又由一个或多个帧组成,多个帧之间可以乱序发送,因为根据帧首部的流标识可以重新组装
0%