HTTP协议(超文本传输协议)是一个基于请求与响应,无状态的,应用层协议,常基于TCP/IP协议传输数据。

版本 产生时间 内容 发展现状
HTTP/0.9 1991年 不涉及数据包传输,规定客户端和服务器之间通信格式,只能GET请求 没有作为正式的标准
HTTP/1.0 1996年 传输内容格式不限制,增加PUT、PATCH、HEAD、 OPTIONS、DELETE命令 正式作为标准
HTTP/1.1 1997年 持久连接(长连接)、节约带宽、HOST域、管道机制、分块传输编码 2015年前使用最广泛
HTTP/2 2015年 多路复用、服务器推送、头信息压缩、二进制解析等 逐渐覆盖市场
HTTP/3 QUIC基于UDP

多路复用:一个TCP连接内包含多个HTTP请求和响应

状态码

名称 类别
1XX 请求正在处理
2XX 成功
3XX 重定向
4XX 客户端错误
5XX 服务端错误

200 成功

204 处理成功,但无数据实体返回

301 永久重定向

302 临时重定向

307 临时重定向,302会把POST改为GET,但307不会

401 缺少HTTP认证信息

403 没有权限

404 没有资源

Cookie和Session

Cookie和Session都是为了保存客户端和服务端之间的交互状态,实现机制不同。

  1. Cookie是保存在客户端而Session就保存在服务端的
  2. Cookie有大小和数量都有限制,如果很大,每次要请求都要带上,这样就影响了传输效率
  3. Cookie是存在客户端的可能被禁用、删除、篡改,是不安全的
  4. Session是基于Cookie来实现的,每次传输只把代表客户端的唯一ID写在客户端的Cookie中

缓存机制

HTTP缓存根据是否需要向服务器发起请求可以被分为两类,强制缓存和协商缓存。

  1. 强制缓存命中和未命中

强制缓存命中

  1. 协商缓存命中和未命中

协商缓存

强制缓存如何判断缓存是否失效?

通过Expires[ HTTP1.0 ] / Cache-Control [ HTTP1.1 ]

expires: Mon, 22 Mar 2021 05:20:09 GMT 下一次到期时间(采用绝对时间,客户端时间可修改,所以不合理)

cache-control: private, max-age=31536000 采用相对时间

Cache-Control 是最重要的规则。常见的取值有private、public、no-cache、max-age,no-store,默认为private。

  1. private: 客户端可以缓存
  2. public: 客户端和代理服务器都可缓存
  3. max-age=xxx: 缓存的内容将在 xxx 秒后失效
  4. no-cache: 需要使用对比缓存来验证缓存数据
  5. no-store: 所有内容都不会缓存

协商缓存如何判断是否失效?

  1. 浏览器第一次请求数据时,服务器会将缓存标识和数据一起返回给客户端
  2. 再次请求数据时,客户端将备份道德缓存标识发送给服务器,服务器根据缓存表标识进行判断,成功后返回304状态码,可使用缓存数据

两种缓存标识: Last-Modified / If-Modified-SinceEtag / If-None-Match

Last-Modified / If-Modified-Since

Last-Modified : 服务器在响应请求时,返回资源最后修改的时间

If-Modified-Since:再次请求服务器时,通过此字段通知上次请求时,服务器返回的资源修改的最后时间

如果资源修改时间 > If-Modified-Since,说明资源被改动过,返回状态码200;如果小于或者等于If-Modified-Since,说明资源无新修改,则响应HTTP304,告诉浏览器继续使用Cache。

Etag / If-None-Match

第一次客户端访问资源的时候,服务端返回资源内容的同时返回了ETag:1234,告诉客户端:这个文件的标签是1234,我如果修改了我这边的资源的话,这个标签就会不一样了。

第二次客户端访问资源的时候,由于缓存中已经有了Etag为1234的资源,客户端要去服务端查询的是这个资源有木有过期呢?所以带上了If-None-Match: 1234。告诉服务端:如果你那边的资源还是1234标签的资源,你就返回304告诉我,不需要返回资源内容了。如果不是的话,你再返回资源内容给我就行了。服务端就比较下Etag来看是返回304还是200。

HTTPS

基于HTTP协议,通过SSL或者TLS提供加密处理数据、验证对方身份以及数据完整性保护。

混合加密:结合非对称加密和对称加密技术。客户端使用对称加密生成密钥对传输数据进行加密,然后使用非对称加密的公钥再对秘钥进行加密,所以网络上传输的数据是被秘钥加密的密文和用公钥加密后的秘密秘钥,因此即使被黑客截取,由于没有私钥,无法获取到加密明文的秘钥,便无法获取到明文数据。

数字摘要:通过单向hash函数对原文进行哈希,将需加密的明文“摘要”成一串固定长度(如128bit)的密文,不同的明文摘要成的密文其结果总是不相同,同样的明文其摘要必定一致,并且即使知道了摘要也不能反推出明文。

数字签名技术:数字签名建立在公钥加密体制基础上,是公钥加密技术的另一类应用。它把公钥加密技术和数字摘要结合起来,形成了实用的数字签名技术。

非对称加密过程需要用到公钥进行加密,那么公钥从何而来?其实公钥就被包含在数字证书中,数字证书通常来说是由受信任的数字证书颁发机构CA,在验证服务器身份后颁发,证书中包含了一个密钥对(公钥和私钥)和所有者识别信息。数字证书被放到服务端,具有服务器身份验证和数据传输加密功能。

SSL过程

  1. client向server发送请求,连接443端口,发送随机值1和客户端支持的加密算法
  2. server接收到信息之后,返回随机值2和协商好的加密算法
  3. server给client发送第二个响应报文是数字证书,服务器必须有一套数字证书,可以自己制作,也可以向组织申请。区别就是自己办法的证书需要客户端验证通过才可以访问,而使用受信任的公司申请的证书不会弹出提示页面,这套证书其实就是一对公钥和私钥,包含了证书颁发机构、过期时间、服务端的公钥,服务端域名等信息
  4. 客户端TLS解析证书验证公钥是否有效比如颁发机构、过期时间等。如果异常,则弹出警告框,如果没有问题,则生成一个随机值(预主密钥)
  5. 加密会话,客户端认证证书通过后,会通过随机值1、随机值2和预主密钥组装会话密钥,然后通过证书的公钥加密会话密钥。
  6. 传送加密信息,这部分传送的是用证书加密后的会话密钥,目的是让服务端使用密钥解密得到的随机值1、随机值2和预主密钥。
  7. 验证传输,客户端通过会话密钥加密一条消息发送给服务端,主要验证服务端能否正常接收客户端加密的消息
  8. 同样服务端也会通过会话密钥加密一条消息传回给客户端,如果客户端能够正常接收的话,表明SSL层连接建立完成了

成本考虑:

  1. SSL证书需要购买申请,功能越强大的证书费用越高
  2. SSL证书通常需要绑定IP,不能在同一IP上绑定多个域名,IPv4资源不可能支撑这个消耗(SSL有扩展可以部分解决这个问题,但是比较麻烦,而且要求浏览器、操作系统支持,Windows XP就不支持这个扩展,考虑到XP的装机量,这个特性几乎没用)。
  3. 根据ACM CoNEXT数据显示,使用HTTPS协议会使页面的加载时间延长近50%,增加10%到20%的耗电。
  4. HTTPS连接缓存不如HTTP高效,流量成本高。
  5. HTTPS连接服务器端资源占用高很多,支持访客多的网站需要投入更大的成本。
  6. HTTPS协议握手阶段比较费时,对网站的响应速度有影响,影响用户体验。比较好的方式是采用分而治之,类似12306网站的主页使用HTTP协议,有关于用户信息等方面使用HTTPS。

TCP三次握手

为什么需要三次握手呢?为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。

比如:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段,但是server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求,于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了,由于client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据,但server却以为新的运输连接已经建立,并一直等待client发来数据。所以没有采用“三次握手”,这种情况下server的很多资源就白白浪费掉了。

TCP四次挥手

为什么需要四次挥手呢?TCP是全双工模式,当client发出FIN报文段时,只是表示client已经没有数据要发送了,client告诉server,它的数据已经全部发送完毕了;但是,这个时候client还是可以接受来server的数据;当server返回ACK报文段时,表示它已经知道client没有数据发送了,但是server还是可以发送数据到client的;当server也发送了FIN报文段时,这个时候就表示server也没有数据要发送了,就会告诉client,我也没有数据要发送了,如果收到client确认报文段,之后彼此就会愉快的中断这次TCP连接。

References

https://www.jiqizhixin.com/articles/2020-07-24-12

https://cloud.tencent.com/developer/article/1552083