OSI 7层模型和TCP/IP 4层模型
OSI 7层模型 | TCP/IP 4层模型 | 对应网络协议 |
---|---|---|
应用层 | 应用层 | http, ftp,smtp |
表示层 | 应用层 | |
会话层 | 应用层 | dns |
传输层 | 传输层 | tcp,udp,端口 |
网络层 | 网络层 | ip |
数据链路层 | 数据链路层 | |
物理层 | 数据链路层 |
http状态码
- 1XX- 信息型,服务器收到请求,需要请求者继续操作。
- 2XX- 成功型,请求成功收到,理解并处理。
- 3XX - 重定向,需要进一步的操作以完成请求。
- 4XX - 客户端错误,请求包含语法错误或无法完成请求。
- 5XX - 服务器错误,服务器在处理请求的过程中发生了错误。
常用状态码
- 200 成功
- 301 永久重定向
- 302 临时重定向
- 304 协商缓存
- 400 错误请求
- 401 缺少身份验证
- 403 禁止访问
- 404 资源丢失
- 500 服务器故障
https
解决了以下问题
-
数据加密 传输内容进行混淆解决明文传输
-
身份验证 通信双方验证对方的身份真实性
-
数据完整性保护 检测传输的内容是否被篡改或伪造
https在原来的TCP传输层上多了安全传输层协议(TLS)或者安全套接层(SSL),因此https也称HTTP over TLS 或 HTTP over SSL
http | https |
---|---|
TCP | SSL/TLS |
IP | TCP |
mac | IP |
mac |
SSL(Secure Sockets Layer) 发展到v3阶段时,互联网工程组把它改名为 TLS(传输层安全,Transport Layer Security),正式标准化,SSL 是 TLS 前身。
- tls1.2
- tls1.3
加密方式
HTTPS采用对称加密和非对称密钥加密混合的加密方式,使用非对称加密加密对称加密的密钥,随后使用对称加密来传输数据
认证方式
数字证书
HTTP中没有加密机制,可以通过SSL(Secure Socket Layer 安全套接层)或TLS(Transport Layer Security 安全层传输协议)的组合使用,加密HTTP的通信内容。
http+ssl/tls
tls1.2
tls1.3
Tcp
Udp
如何优化https
对称加密
- 加密原文和解密成原文都使用一个秘钥
- 常用的只有 AES 和 ChaCha20
- 缺点是密钥如何安全传输
非对称加密
- 有2个密钥,一个公钥,一个私钥
- 公钥公开,私钥保存在服务器,无需传输
- 常用加密算法有RSA
详细流程
- 客户端使用 https url 访问服务器,则要求 web 服务器
建立 ssl 链接
。 - web 服务器接收到客户端的请求之后,会
将网站的证书(证书中包含了公钥),传输给客户端
。 - 客户端生成一个随机数(会话密钥),用上一步证书中的公钥进行加密,并将加密后的信息发送给服务端
- 服务端获取后,通过私钥进行解密,获取到随机数(会话密钥)
- 客户端和服务端通过随机数(会话密钥)进行对称加解密
缓存
http请求
- 请求头
- 请求行
- 空行
- 请求体
请求头 | 作用 |
---|---|
Accept | 接收类型,表示浏览器支持的MIME类型(对标服务端返回的Content-Type) |
Content-Type | 客户端发送出去实体内容的类型 |
Cache-Control | 指定请求和响应遵循的缓存机制,如no-cache |
If-Modified-Since | 对应服务端的Last-Modified,用来匹配看文件是否变动,只能精确到1s之内 |
Expires | 缓存控制,在这个时间内不会请求,直接使用缓存,服务端时间 |
Max-age | 代表资源在本地缓存多少秒,有效时间内不会请求,而是使用缓存 |
If-None-Match | 对应服务端的ETag,用来匹配文件内容是否改变(非常精确) |
Cookie | 有cookie并且同域访问时会自动带上 |
Referer | 该页面的来源URL(适用于所有类型的请求,会精确到详细页面地址,csrf拦截常用到这个字段) |
Origin | 最初的请求是从哪里发起的(只会精确到端口)),Origin比Referer更尊重隐私 |
User-Agent | 用户客户端的一些必要信息,如UA头部等 |
http响应
- 状态行
- 响应头
- 空行
- 响应体
响应头 | 作用 |
---|---|
Cache-Control | 指定请求和响应遵循的缓存机制,如no-cache |
Content-Type | 服务端返回的实体内容的类型 |
Last-Modified | 请求资源的最后修改时间 |
ETag | 资源的特定版本的标识符,类似于指纹 |
Expires | 应该在什么时候认为文档已经过期,从而不再缓存它 |
Server | 服务器的一些相关信息 |
Set-Cookie | 设置和页面关联的cookie,服务器通过这个头部把cookie传给客户端 |
Access-Control-Allow-Origin | 服务器端允许的请求Origin头部(譬如为*) |
http1.1
- 持久化连接
- 浏览器为每个域名最多同时维护6个TCP持久连接;
- 使用CDN的实现域名分片机制。
Keep-Alive
http1.0默认关闭keep-alive,需要请求头和响应头添加Connection: Keep-Alive
http1.1默认开启keep-alive,如果需要关闭,请求头需添加Connection:close
缺点
- 安全性不足
- 性能不高
Http2.0
- 二进制分帧传输
- 头部压缩
- 多路复用,一个域名共用一个链接
- 性能瓶颈在tcp连接上
- 开启http2.0需要启用https协议
Http3.0
http2使用多路复用实现了多个请求在一个tcp中传输,任意一个出现丢包,即会阻塞所有的请求,丢包率增加,http2效率反而更差
基于udp实现的http3.0协议,
tcp和udp区别
- TCP 是面向连接的,UDP 是无连接的即发送数据前不需要先建立链接。
- 对系统资源的要求(TCP较多,UDP少)
- UDP程序结构较简单,TCP 的首部较大为 20 字节,而 UDP 只有 8 字节。
- TCP 是面向字节流,UDP 面向报文,并且网络出现拥塞不会使得发送速率降低(因此会出现丢包,对实时的应用比如 IP 电话和视频会议等)。
- TCP保证数据正确性,UDP可能丢包,TCP 提供可靠的服务。也就是说,通过 TCP 连接传送的数据,无差错, 不丢失,不重复,且按序到达;UDP 尽最大努力交付,即不保证可靠交付。并且因为 tcp 可靠,面向连接,不会丢失数据因此适合大数据量的交换。
- TCP保证数据顺序,UDP不保证
- TCP 只能是 1 对 1 的,UDP 提供单播,多播,广播,支持 1 对 1,1 对多。
UDP | TCP | |
---|---|---|
是否连接 | 无连接 | 面向连接 |
是否可靠 | 不可靠传输,不使用流量控制和拥塞控制 | 可靠传输,使用流量控制和拥塞控制 |
连接对象个数 | 支持一对一,一对多,多对一和多对多交互通信 | 只能是一对一通信 |
传输方式 | 面向报文 | 面向字节流 |
首部开销 | 首部开销小,仅8字节 | 首部最小20字节,最大60字节 |
适用场景 | 适用于实时应用(IP电话、视频会议、直播等) | 适用于要求可靠传输的应用,例如文件传输 |