[TOC]
## 简介
HTTP1.0最早在网页中使用是在1996年,那个时候只是使用一些较为简单的网页上和网络请求上,而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中,同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在:
1. **缓存处理**,在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准,HTTP1.1则引入了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
2. 带宽优化及网络连接的使用,HTTP1.0中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能,HTTP1.1则在请求头引入了**range头域**,它允许只请求资源的某个部分,即返回码是206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。
3. 错误通知的管理,在HTTP1.1中新增了24个错误状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除。
4. Host头处理,在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持**Host头域**,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。
5. **长连接,**HTTP 1.1支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟,在HTTP1.1中默认开启**Connection: keep-alive**,一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
## 缓存
### 强制缓存(不对比缓存)与 对比缓存
**强制缓存:本地有就不对比 对比缓存,每次都对比**
已存在缓存数据时,仅基于强制缓存,请求数据流程如下:
![](https://img.kancloud.cn/4f/f1/4ff1cfe8a793e8f28e3e2e074fd0f76c_865x332.png)
已存在缓存数据时,仅基于对比缓存,请求数据的流程如下:
![](https://img.kancloud.cn/5c/af/5caffa661024bbec05d1b331f30b9afb_947x340.png)
**缓存规则是包含在响应header里面的**
具体步骤如下:
![](https://img.kancloud.cn/3f/d1/3fd1de23dd0c28df7d9929e7d79f3410_554x528.png)
### expires
在HTTP/1.0中expires的值围服务器端返回的到期时间,即下一次请求时,请求时间小于服务器返回的到期时间,直接使用缓存数据,这里面有个问题,由于到期时间是服务器生成的,但是客户端的时间可能和服务器有误差,所以这就会导致误差,**所以到了HTTP1.1基本上不适用expires了,使用Cache-Control替代了expires**
### Cache-Control
Cache-Control 是最重要的规则。常见的取值有private、public、no-cache、max-age、no-store、默认是private。
响应头部意义Cache-Control:public响应被共有缓存,移动端无用Cache-Control:private响应被私有缓存,移动端无用Cache-Control:no-cache不缓存Cache-Control:no-store不缓存Cache-Control:max-age=6060秒之后缓存过期
举个例子。入下图:
![](https://img.kancloud.cn/c9/18/c918440482c3b5d11f9a23f7279df031_326x151.png)
图中Cache-Control仅指定了max-age所以默认是private。缓存时间是31536000,也就是说365内的再次请求这条数据,都会直接获取缓存数据库中的数据,直接使用。
### Last-Modified/If-Modified-Since
第一次请求时,服务器返回资源的**最后修改时间**,后面请求是带上最后修改时间。
对比缓存,顾名思义,需要进行比较判断是否可以使用缓存,客户端第一次发起请求时,服务器会将缓存标志和数据一起返回给客户端,客户端当二者缓存至缓存数据库中。再次其你去数据时,客户端将备份的缓存标志发送给服务器,服务器根据标志来进行判断,判断成功后,返回304状态码,通知客户端比较成功,可以使用缓存数据。
#### Last-Modified
是通过Last-Modified/If-Modified-Since来实现的,服务器在响应请求时,告诉浏览器资源的最后修改时间。
![](https://img.kancloud.cn/15/f1/15f1d6b06978b5603077e17d848544ec_591x221.png)
#### If-Modified-Since
再次请求服务器时,通过此字段通知服务器上次请求时,服务器返回最远的最后修改时间。服务器收到请求后发现有If-Modified-Since则与被请求资源的最后修改时间进行对比。若资源的最后修改时间大于If-Modified-Since,说明资源又被改动过,则响应整个内容,返回状态码是200.如果资源的最后修改时间小于或者等于If-Modified-Since,说明资源没有修改,则响应状态码为304,告诉客户端继续使用cache.
![](https://img.kancloud.cn/f6/46/f646fc3b4381dd2b2bfe0fe966f84ab6_597x247.png)
### ETag/If-None-Match(优先级高于Last-Modified/If-Modified-Since)
第一次请求时,服务器返回资源的**唯一标记位**,后面请求是带上最后修改时间。
#### Etag
服务响应请求时,告诉客户端当前资源在服务器的唯一标识(生成规则由服务器决定)
![](https://img.kancloud.cn/3d/e2/3de2deb149d64a6464ab32af94dede1b_592x219.png)
#### If-None-Match
再次请求服务器时,通过此字段通知服务器客户端缓存数据的唯一标识。服务器收到请求后发现有头部If-None-Match则与被请求的资源的唯一标识进行对比,不同则说明资源被改过,则响应整个内容,返回状态码是200,相同则说明资源没有被改动过,则响应状态码304,告知客户端可以使用缓存
![](https://img.kancloud.cn/3e/11/3e113993ce57cef9b9a8bf398f8d5e86_592x228.png)
### Range
如果服务器能够正常响应的话,服务器会返回 206 Partial Content 的状态码及说明.
如果不能处理这种Range的话,就会返回整个资源以及响应状态码为 200 OK .(这个要注意,要分段下载时,要先判断这个)
响应头就是 HTTP/1.1 206 Partial Content
#### 请求头格式
> Range: bytes=start-end
例如:
> Range: bytes=10- :第10个字节及最后个字节的数据
> Range: bytes=40-100 :第40个字节到第100个字节之间的数据.
注意,这个表示\[start,end\],即是包含请求头的start及end字节的,所以,下一个请求,应该是上一个请求的\[end+1, nextEnd\]
#### 响应头
* Content-Range
~~~
Content-Range: bytes 0-10/3103
~~~
这个表示,服务器响应了前(0-10)个字节的数据,该资源一共有(3103)个字节大小。
* Content-Type
~~~
Content-Type: image/png
~~~
表示这个资源的类型
* Content-Length
~~~
Content-Length: 11
~~~
表示这次服务器响应了11个字节的数据(0-10)
## Keep-Alive
[http协议里的keep-alive](https://www.jianshu.com/p/347416aafd3f)
[HTTP/1.1 持久连接](https://blog.csdn.net/duan15378766962/article/details/81073050)
我的理解:
1. http1.1协议里增加了 keepalive的支持, 并且默认开启
2. http1.1开启keepalive后,可以做到一个tcp上可以完成一个http请求后不会立刻关闭,而是存活一段时间。
3. 在这个时间内,有其他http请求也可以使用这个tcp连接,(但每次只有一个)
4. http2.0才真正做到了多个请求在一个tcp里并发。(每个请求分配一个requestID)
## 参考资料
[OKHttp源码解析(七)--中阶之缓存机制](https://www.jianshu.com/p/a68dc1ca6120)
[一文读懂http缓存](https://www.jianshu.com/p/227cee9c8d15)
- Android
- 四大组件
- Activity
- Fragment
- Service
- 序列化
- Handler
- Hander介绍
- MessageQueue详细
- 启动流程
- 系统启动流程
- 应用启动流程
- Activity启动流程
- View
- view绘制
- view事件传递
- choreographer
- LayoutInflater
- UI渲染概念
- Binder
- Binder原理
- Binder最大数据
- Binder小结
- Android组件
- ListView原理
- RecyclerView原理
- SharePreferences
- AsyncTask
- Sqlite
- SQLCipher加密
- 迁移与修复
- Sqlite内核
- Sqlite优化v2
- sqlite索引
- sqlite之wal
- sqlite之锁机制
- 网络
- 基础
- TCP
- HTTP
- HTTP1.1
- HTTP2.0
- HTTPS
- HTTP3.0
- HTTP进化图
- HTTP小结
- 实践
- 网络优化
- Json
- ProtoBuffer
- 断点续传
- 性能
- 卡顿
- 卡顿监控
- ANR
- ANR监控
- 内存
- 内存问题与优化
- 图片内存优化
- 线下内存监控
- 线上内存监控
- 启动优化
- 死锁监控
- 崩溃监控
- 包体积优化
- UI渲染优化
- UI常规优化
- I/O监控
- 电量监控
- 第三方框架
- 网络框架
- Volley
- Okhttp
- 网络框架n问
- OkHttp原理N问
- 设计模式
- EventBus
- Rxjava
- 图片
- ImageWoker
- Gilde的优化
- APT
- 依赖注入
- APT
- ARouter
- ButterKnife
- MMKV
- Jetpack
- 协程
- MVI
- Startup
- DataBinder
- 黑科技
- hook
- 运行期Java-hook技术
- 编译期hook
- ASM
- Transform增量编译
- 运行期Native-hook技术
- 热修复
- 插件化
- AAB
- Shadow
- 虚拟机
- 其他
- UI自动化
- JavaParser
- Android Line
- 编译
- 疑难杂症
- Android11滑动异常
- 方案
- 工业化
- 模块化
- 隐私合规
- 动态化
- 项目管理
- 业务启动优化
- 业务架构设计
- 性能优化case
- 性能优化-排查思路
- 性能优化-现有方案
- 登录
- 搜索
- C++
- NDK入门
- 跨平台
- H5
- Flutter
- Flutter 性能优化
- 数据跨平台