面试题：HTTP/1.1如何优化

HTTP/1.1如何优化

学习资源 小林coding 2022.3.31

可以使用KeepAlive将HTTP从短连接改为长连接

从底层传输层出发 通过减少TCP连接建立和断开的次数 减少网络的延迟 从而提高协议的传输效率

三种优化思想

• 尽量避免发送HTTP请求
• 在需要发送HTTP请求时 考虑如何减少请求次数
• 减少服务器的HTTP响应的数据大小

如何避免发送HTTP请求

HTTP请求 客户端和服务器交互数据

对于一些具有重复性的HTTP请求 -> 每次获取数据一样 -> 缓存至本地 -> 下次直接读取本地的数据 不必通过网络获取服务器的相应

缓存如何实现

客户端把第一次请求以及响应的数据保存在本地磁盘上

请求的URL作为key 响应作为value 两者形成映射关系

后续发起相同请求 直接查询对应K-V

缓存不是最新的？

发送HTTP响应时 估算一个过期的时间 客户端查看响应头信息时 一旦发现缓存的响应是过期的 就会重新发网络请求

如果过期时间到了之后还是老数据？

在客户端重新发送请求时 请求Etag上面带上请求响应头中的摘要

摘要是唯一标识响应的资源

如果摘要相同 服务器仅返回 不包含包体的304Not Modified响应

缓存性能优化 CPU cache Page Cache Redis Cache

如何减少HTTP请求次数

• 减少重定向请求次数
• 合并请求
• 延迟发送请求

减少重定向请求次数

由于资源迁移 维护 客户端不知情 服务器返回302响应码和Location头部

客户端重新发送请求获得资源

如果重定向过多 客户端就要多次发起请求 降低性能

将重定向的工作交由代理服务器完成 减少HTTP请求次数

当代理服务器知晓重定向规则之后 可以进一步减少消息传递次数

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-driguKj3-1648694582867)(https://cdn.jsdelivr.net/gh/xiaolincoder/ImageHost4@main/网络/http1.1优化/重定向响应码.png)]

合并请求

将多个访问的小文件的请求合并成一个大的请求 虽然传输的总资源还是一样 但是减少请求 意味着减少了重复发送的HTTP头部

HTTP/1.1 请求响应模型 第一个发送的请求 未收到响应 请求阻塞 -> 浏览器会同时发送5-6个请求 每一个请求都是不同的TCP连接

合并请求减少了TCP连接的数量 省去了TCP握手和慢启动过程耗费的时间

图片 CSS Image Sprites 合并 之后分割

Webpack 打包大文件 base64

问题： 当大资源中的某一个小文件发生变化之后 客户端必须重新下载整个完整的大资源文件 带来额外的网络消耗

延迟发送请求

按需获取方式

懒加载 当用户向下滑动页面的时候 再向服务器获取接下来的资源

如何减少HTTP响应的数据大小

压缩

1. 有损压缩
2. 无损压缩

无损压缩

信息不被破坏 恢复原样 适用于 文本 可执行 程序源代码

1. 针对代码语法规则压缩 去除多余符号
2. 无损压缩 对原始资源建立统计模型 将常出现的数据用较短的二进制比特序列表示 不常出现的用较长的二进制比特序列表示 生成二进制比特序列 哈夫曼编码

gzip是常见的无损压缩 客户端支持的压缩算法 会在HTTP请求中通过头部中的Accept-Encoding字段告诉服务器

服务器收到后 从中选择 然后通过响应头中的 content-encoding字段告诉客户端该资源使用的压缩算法

有损压缩

将次要资源舍弃 牺牲质量 提高压缩比 常见于 视频 图片 音频

通过HTTP请求头 Accept中 q质量因子 告诉服务器期望的资源质量

增量数据 ： 只需要在静态关键帧后使用增量数据 减少总数据量

总结

优化HTTP/1.1方法

1. 避免HTTP请求发送 -> 缓存
2. 减少HTTP请求 -> 合并发送 减少重定向（代理服务器） 按需发送（懒加载）
3. 减少响应数据 -> 压缩

最近学的HTTP之前的也有点遗忘了 是时候该往前复习一下下QAQ