换从 HTTP/1.1 到 HTTP/2 是一个显著的升级，能够带来更好的性能和效率。以下是切换过程中需要考虑和执行的步骤：
-
服务器支持 确认服务器支持 HTTP/2：首先要确认你的 Web 服务器支持 HTTP/2。大多数现代服务器如 Nginx、Apache、IIS、Caddy 等都支持 HTTP/2，但可能需要启用或配置相应的模块。 升级或配置服务器：确保服务器软件版本足够新，并启用 HTTP/2 支持。例如，Nginx 中可以通过 listen 443 ssl http2; 来启用 HTTP/2。
-
TLS 配置 启用 HTTPS：HTTP/2 设计上要求使用 HTTPS（尽管理论上它可以在非加密连接上运行，但主流浏览器通常只在 HTTPS 上启用 HTTP/2）。如果你还没有启用 HTTPS，需要为你的站点配置 SSL/TLS 证书。 优化 TLS 配置：为获得最佳性能，确保使用现代的 TLS 协议版本（如 TLS 1.2 或更高），并禁用较旧的不安全的加密套件。
-
应用层适配 检查应用程序：尽管 HTTP/2 对客户端和服务器来说是透明的，但在某些情况下，你的应用可能需要适应新协议。例如，HTTP/2 允许并发多路复用（多条请求在同一连接上并行发送），这可能影响你的请求处理逻辑。 依赖的库或框架：如果你的应用依赖特定的 HTTP 库或框架，请确认它们也支持 HTTP/2，或者是否需要更新到支持 HTTP/2 的版本。
-
前端优化 减少资源合并：HTTP/2 提供了更高效的资源加载机制，如多路复用和头部压缩，使得传统的资源合并策略（如将多个CSS/JS文件合并成一个）可能不再必要。可以减少资源合并，利用 HTTP/2 的优势来并行加载更多资源。 移除域名分片：HTTP/2 不需要像 HTTP/1.1 那样通过域名分片来增加并发连接数，因为它在单一连接上支持并发请求。考虑取消域名分片策略以简化架构。
-
监控与调试 测试兼容性：测试你的应用在启用 HTTP/2 后的行为，特别是不同浏览器和客户端的兼容性。确保一切正常工作，没有意外的问题。 性能监控：监控性能指标（如加载时间、带宽使用量、服务器负载等）来评估 HTTP/2 的影响。可以使用工具如 Chrome DevTools 或 HTTP/2 专用的测试工具来检查协议的使用情况。
-
渐进式启用 逐步推广：可以考虑逐步启用 HTTP/2，而不是立即对所有用户开放。比如，你可以在部分服务器或子域上启用 HTTP/2，观察效果并解决潜在问题后，再全面推广。
-
浏览器兼容性 浏览器支持：大部分现代浏览器都支持 HTTP/2，但某些老版本的浏览器可能不完全支持。如果你的网站需要兼容旧浏览器，确保它们可以回退到 HTTP/1.1。
-
安全和隐私 增强的安全特性：HTTP/2 改进了对某些攻击（如头部注入、协议降级攻击等）的防护。确保你了解这些改进，并配置服务器以利用这些安全增强功能。 总结 切换到 HTTP/2 主要涉及服务器配置、应用适配和前端优化的调整。虽然大多数情况下，HTTP/2 是向后兼容的并且对用户透明，但为了充分利用其性能优势，还是需要进行一些调整和测试。在切换之前和之后，监控性能和用户体验，以确保升级顺利。 ————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
原文链接：blog.csdn.net/galoiszhou/…
http1:请求中同源地址最大为6个，总请求最大10个。
浏览器本身有队列，一次只会发送6-8到服务端（单个客户端），其他的都在本地排队，没有发送到服务端，所以浏览器的并发队列已经解决单个客户端的大并发问题了；客户端一次性发出大量请求，主要影响的是客户端本地（可能硬件配置较低），对服务端压力影响极其有限（单个客户端并发撑死8个），附一张正常情况下Chrome一次性发送30个请求到服务器的图片，connection表示TCP连接建立的时机
http2
若是使用的是 http2 的话，http2 的多路复用允许多个请求在一个单一的 TCP 连接上几乎同时进行数据传输，那这样就不会受到浏览器的同一域名下最大连接数的限制，客户端是可以一次性发送大量请求的，服务端仍然存在并发压力
单个资源的时间线
3.1 发起http请求
3.2 浏览器查找缓存（若缓存没命中）
3.3 发起DNS请求获取IP地址
3.4 利用IP地址和服务器建立TCP连接
3.5 等待服务器响应
3.6 若服务器响应头包含了重定向信息，则整个流程重新走一遍。
3.7 Queueing（排队）-》Resource Scheduling阶段
当浏览器发起一个请求，会有很多原因导致该请求不能被立即执行，而是需要排队等待，排队的原因有很多：
3.7.1 页面中的资源是有优先级的，比如 CSS、HTML、JavaScript 等都是页面中的核心文件，所以优先级最高；而图片、视频、音频这类资源就不是核心资源，优先级就比较低。通常当后者遇到前者时，就需要“让路”，进入待排队状态。
3.7.2 浏览器会为每个域名最多维护 6 个 TCP 连接，如果发起一个 HTTP 请求时，这 6 个 TCP 连接都处于忙碌状态，那么这个请求就会处于排队状态。
3.7.3 网络进程在为数据分配磁盘空间时，新的 HTTP 请求也需要短暂地等待磁盘分配结束。
3.8 Stalled（停滞）-》Connection Start阶段
排队完成后，就要进入发起连接状态，不过在发起连接之前，还有一些原因导致连接过程被推迟
3.9 Proxy Negotiation（代理协商阶段）-》Connection Start阶段
表示代理服务器连接协商所用的时间
3.10 DNS Lookup （dns查询）-》Connection Start阶段
Dns查询所用的时间
3.11 Initial connection/SSL 阶段 -》Connection Start阶段
也就是和服务器建立连接的阶段，这包括了建立 TCP 连接所花费的时间；不过如果你使用了 HTTPS 协议，那么还需要一个额外的 SSL 握手时间，这个过程主要是用来协商一些加密信息的
3.12 Request Sent
网络进程会准备请求数据，并将其发送给网络, 只需要把浏览器缓冲区的数据发送出去就结束了，并不需要判断服务器是否接收到了
3.13 Waiting(TTFB)
接下来就是等待接收服务器第一个字节的数据，TTFB 是反映服务端响应速度的重要指标，对服务器来说，TTFB 时间越短，就说明服务器响应越快。
3.14 Content Download 接收到第一个字节之后，进入陆续接收完整数据的阶段, 这意味着从第一字节时间到接收到全部响应数据所用的时间。
优化线上耗时项
4.1 排队（Queuing）时间过久
4.1.1 大概率是由浏览器为每个域名最多维护6个连接导致的（参考域名分片技术）
4.1.2 把站点升级到HTTP2（无6个连接限制）
4.2 第一字节（TTFB）时间过久
4.2.1 服务器生成页面数据的时间过久
4.2.2 网络原因
4.2.3 发送请求头时带上了多余的用户信息
4.3 content download 时间过久
4.3.1 单个请求content download过久，有可能是字节数太多，这个时候减少文件大小，比如压缩，去掉源码中不必要的注释。
原文链接：blog.csdn.net/RowanIT3/ar…
浏览器的渲染 (UI) 线程和js线程是互斥的，在执行js耗时操作时，页面渲染会被阻塞掉。当我们执行异步ajax的时候没有问题，但当设置为同步请求时，其他的动作（ ajax函数后面的代码，还有渲染线程）都会停止下来。即使我的DOM操作语句是在发起请求的前一句，这个同步请求也会“迅速”将UI****线程阻塞，不给它执行的时间。这就是代码失效的原因。
ajax请求回来之后 的js处理又是同步的
