聊聊 HTTP 性能优化

作为用户的我们在 "上网冲浪" 的时候总是希望快一点,尤其是抢演唱会门票的时候,但是现实并非如此,有时候我们会遇到页面加载缓慢、响应延迟的情况。

而 HTTP 协议作为互联网世界的基础,从网站打开速度到移动应用的响应时间,HTTP 性能的优化直接关系到我们在网络世界的舒适体验程度。

更快的响应时间和速度能够提供更好的用户体验 ,不但如此,还可以降低服务器和网络带宽的使用,从而节省相关的成本

那么今天我们就来聊聊 HTTP 性能如何进行优化

数据压缩

随着互联网的发展,网路上传输的数据越来越大,随随便便一个文件几个 G 甚至上百 G,就算你是百兆、千兆带宽也扛不住。

如何能够在有限的带宽里传输更多的数据,常见的解决方式是数据压缩

如果压缩率能有 50%,例如 100K 的数据能够压缩成 50K 的大小,那么就相当于在带宽不变的情况下网速提升了一倍,加速的效果是非常明显的。

使用常见的压缩算法(如 gzip 和 br )对数据进行压缩,不但如此,我们可以对 HTTP 中传输的各种数据进行针对性地压缩,做到【对症下药】。

  • HTML/CSS/JS

对于这类纯文本格式数据,我们在进行压缩时通常会去除其中多余的空格、换行和注释等元素。尽管压缩后的文本可能看起来比较混乱,对人类可读性较差,但这对计算机并不影响流畅阅读。

  • JPG/JPEG/PNG

对于这类图片格式数据,虽然它本身已经被压缩过了,不能被 gzip、br 处理,但仍然有优化的空间。

例如,可以考虑去除图片中的拍摄时间、地点、机型等元数据,适度降低分辨率和缩小尺寸。

此外,尽量采用高压缩率的格式,有损格式可以选择 JPEG,而无损格式则可以考虑使用 webp 格式。

  • 小数据

对于较小的数据,HTTP 中有一种被称为 "资源合并"(Concatenation)的优化方式,即将多个小资源合并成一个大资源,通过单个请求下载到客户端,随后由客户端使用 JavaScript、CSS 等进行拆分使用。

这种方式虽然减少了请求的次数,但是处理起来比较麻烦。

需要注意的是,在数据压缩的时候应当注意选择适当的压缩率,不要追求最高压缩比,否则会耗费服务器的计算资源,增加响应时间,反而会"得不偿失"。

上面讲的都是针对 HTTP 报文里的 body 的压缩方式,对于 header 的压缩在 HTTP/1 里是没有的(HTTP/2 才有)。

不过我们可以采取一些手段来减少 header 的大小,不必要的字段就尽量不发(例如 User-Agent、Server、X-Powered-By)

使用缓存

数据 "千里迢迢" 从服务端到客户端,我们可以把这些 "来之不易" 的数据【暂时保存】起来,以便在下次请求时直接复用,从而避免多次请求带来的高昂成本。

比如说网站上访问量最高的网页、热点新闻,尤其是【读多写少】的数据,把它们缓存下来能够把巨大的流量挡在外面,减轻服务器的压力,对性能的改善是非常显著的。

HTTP 传输的每一个环节基本上都会有缓存,不过大致可以分成:

  • 浏览器端缓存

  • 服务端缓存

  • 中间传输缓存

在浏览器端,通过与服务端协商相关的缓存策略,将一些资源缓存到本地,以便在下次访问时进行复用。

常见的缓存策略包括 HTTP 头中的 Cache-ControlExpires 以及 ETag 等,通过这些标识,浏览器可以判断是否需要从服务端重新获取资源,或者直接使用本地缓存。

在服务端,可以借助专门的缓存中间件,如 Memcache 或 Redis,将计算得到的中间结果和资源存储在内存或硬盘中。

这样,Web 服务器在处理请求时会首先检查缓存,如果找到相应的数据,就能够立即返回给客户端,避免了访问后端服务或数据库的时间开销。

而关于中间传输的缓存,常见的有 HTTP 代理缓存和 CDN(Content Delivery Network,内容分发网络)。

HTTP 代理缓存,通过使用增加了缓存功能的 HTTP 代理服务器(例如 Nginx),缓存源服务器的数据,分发给下游的客户端。

而使用 CDN 把源服务器的内容逐级缓存到网络中的每一个 CDN 节点中,这样用户在上网的时候就不直接访问源站,而是访问离它最近的一个 CDN 节点(其实就是缓存了源服务器内容的代理服务器)

使用高性能 web 服务器

除了传输过程中对数据进行压缩和使用缓存,我们还可以在服务端下手。

首先我们应该选择高性能的 Web 服务器,最常见的应该就是 Nginx 了。

作为一款【高性能,轻量级】的 Web 服务器,【进程池+单线程】的工作模式让 Nginx 消耗较少的 CPU 和内存,非常轻量,而【I/O 多路复用】又使得 Nginx 的工作效率大大提升。

我们还可以通过 Nginx 实现【动静分离】:把动态页面和静态页面交给不同的服务器来解析,来加快解析速度,提高请求的访问效率,降低原来单个服务器的压力。

# Nginx 动静分离配置
server {
  listen 80 ; 
  
  location ~* \.(png)$ {
    root /var/images/png/;
  }
  
  location ~* \.(php)$ {
    proxy_pass http://php_back_end;
  }
}

不但如此,在配置 Nginx 的时候还应该开启 HTTP 长连接

这样做可以平均握手成本到多次请求中,避免了每个请求都要进行 TCP 连接建立和断开的开销,从而提高了性能。连接的复用使得后续的请求不再需要进行完整的三次握手过程,减少了连接建立的延迟。

升级 HTTP/2

除了上面的【数据压缩】、【使用缓存】、【使用高性能 web 服务器】,HTTP 性能优化还有一个选择,那就是【把协议由 HTTP/1 升级到 HTTP/2】

HTTP/2 基于 Google 的 SPDY 协议,完全兼容 HTTP/1,我们来看看它的一些优点。

  • 头部压缩

报文 Header 一般会携带 "User Agent"、"Cookie"、"Accept"、"Server" 等许多固定的头字段,多达几百字节甚至上千字节,但 Body 却经常只有几十字节(比如 GET 请求)

更要命的是,成千上万的请求响应报文里有很多字段值都是重复的,非常浪费,导致大量带宽消耗在了这些冗余度极高的数据上。

为了压缩头部,HTTP/2 开发了专门的 "HPACK" 算法:在客户端和服务器两端建立"字典",用索引号表示重复的字符串,还釆用哈夫曼编码来压缩整数和字符串,可以达到 50%~90% 的高压缩率。

  • 二进制格式

相较于 HTTP/1 里纯文本形式的报文,HTTP/2 全面采用二进制格式,既方便计算机解析,而且体积小、速度快,使性能大大提高。

除此之外,HTTP/2 使用虚拟的流(stream)传输消息,解决了"队头阻塞"问题,同时实现了"多路复用",提高连接的利用率;

今天这篇文章讲了 HTTP 性能优化的一些方法,希望能对你有帮助!

文章转载自: 咸鱼Linux运维

原文链接: https://www.cnblogs.com/edisonfish/p/18046199

体验地址: 引迈 - JNPF快速开发平台_低代码开发平台_零代码开发平台_流程设计器_表单引擎_工作流引擎_软件架构

相关推荐
唐 城18 分钟前
curl 放弃对 Hyper Rust HTTP 后端的支持
开发语言·http·rust
DevilHeart灬2 小时前
使用Grafana中按钮插件实现收发HTTP请求
http·grafana
总是学不会.6 小时前
第五篇:前后端如何“扯皮”——HTTP 在开发中的应用
java·网络·网络协议·http·开发
NoneCoder6 小时前
CSS系列(26)-- 动画性能优化详解
前端·css·性能优化
火狮6 小时前
鸿蒙Next API 12开发,使用@ohos/axios进行HTTP请求
http·华为·harmonyos
m0_748238277 小时前
WebClient HTTP 请求问题处理模板(泛型响应、忽略 SSL 证书等)
网络协议·http·ssl
我曾经是个程序员7 小时前
鸿蒙学习记录之http网络请求
服务器·学习·http
轩辰~8 小时前
网络协议入门
linux·服务器·开发语言·网络·arm开发·c++·网络协议
苏三说技术10 小时前
Redis 性能优化的18招
数据库·redis·性能优化
EasyDSS11 小时前
国标GB28181-2022平台EasyGBS:安防监控中P2P的穿透方法
网络协议·php·音视频·p2p