HTTP-状态码及演变过程

HTTP

超文本传输协议。HTTP是在计算机中用于两点之间传输文字、图片、音频、视频等超文本数据的约定和规范

  • 超文本:超越了普通文本的文本,是文字、图片、视频等的混合体。HTML是最常见的超文本,经过浏览器解释,呈现出有文字、画面的网页
  • 传输:HTTP协议是双向协议,一方请求,另一方应答,在两点之间进行数据传输,不局限于服务器→浏览器,也可以是服务器→服务器
  • 协议:使用计算机能理解的语言确立了一种计算机之间交流通信的规范(两个以上的参与者),以及相关的各种控制和错误处理方式(行为约定和规范)

状态码

  1. 1xx 属于提示信息,是协议处理中的一种中间状态
  2. 2xx表示服务器成功处理了客户端的请求
    • 200 ok成功状态码,表示一切正常,如果是非head请求,服务器返回的响应头都会有body数据
    • 204 no content200 ok基本相同,但响应头没有body数据
    • 206 partial content应用于HTTP分块下载或断点续传,表示响应返回部分body数据
  3. 3xx表示客户端请求的资源发生了变动,需要客户端用新的url重新发送请求获取资源,即重定向。
    • 301 moved permanently永久重定向,说明请求的资源已经不存在,需要改用新的url再次访问
    • 302 moved temporarily临时重定向,说明请求的资源还在,暂时需要用另一个url来访问
    • 304 not modified 不具有跳转的含义,表示资源未修改,重定向已存在的缓存文件,即缓存重定向,用于缓存控制
  4. 4xx表示客户端发送的报文有误,服务器无法处理
    • 400 bad request客户端请求的报文有错误
    • 403 forbidden服务器禁止访问资源
    • 404 not found请求的资源在服务器上不存在或未找到,无法提供给客户端
  5. 5xx表示客户端请求报文正确,但服务器在处理请求时发生了错误
    • 500 internal server error400 bad request类似,笼统的错误码
    • 501 not implement 表示客户端请求的功能还不支持
    • 502 bad gateway 通常是服务器作为网关或代理时返回的错误码,表示服务器自身正常工作,访问后端服务器发生了错误
    • 503 service unavailable 表示服务器当前很忙,暂时无法响应服务器

常见字段

  • Host 客户端发送请求时,用于指定服务器的域名
  • Content-Length服务器在返回数据时,表面本次响应的数据长度
  • Connection 常用于客户端要求服务器使用TCP持久连接,以便其他请求复用
    • Connection:Keep-AliveHTTP/1.1默认是持久连接,为了兼容,需要指定Connection首部字段的值为Keep-Alive
  • Content-Type用于服务器回应客户端,本次数据是什么格式
    • 客户端使用Accept告知服务器自己可以接受哪些数据格式
    • Content-Type:text/html; charset=utf-8表明发送的是网页,编码格式为utf-8
  • Content-Encoding说明数据的压缩方式,表示服务器返回的数据使用了什么压缩方式
    • 客户端使用Accept-Encoding告知服务器自己可以接受哪些数据压缩方式
    • Content-Encoding:gzip表示服务器返回的数据采用了gzip方式压缩

请求类型

  • GET:请求从服务器获取资源。GET方法是只读操作,无论操作多少次,服务器上的数据都是安全的,且每次结果都是相同的,因此为安全且幂等的
  • POST:向URL指定的资源提交数据,数据放在报文的body里。POST方法是新增提交数据的操作,会修改服务器上的资源,所以是不安全的,且多次提交数据就会创建多个资源,所以是不幂等的
  • HEAD:类似GET请求,不过返回的响应中没有具体的内容,用于获取报头

以上为HTTP/1.0定义的请求方法

HTTP协议中的安全幂等

安全:请求方法不会破坏服务器上的资源

幂等:多次执行相同的操作,结果都是相同的

  • PUT:从客户端向服务器传送的数据取代指定的文档的内容
  • DELETE:请求服务器删除指定的页面
  • CONNECT:HTTP/1.1中预留给能够将连接改为管道方式的代理服务器
  • OPTIONS:允许客户端查看服务器的性能
  • TRACE:回显服务器收到的请求,用于测试或诊断
  • PATCH:对PUT方法的补充,用来对已知资源进行局部更新

以上为HTTP/1.1新增的六种请求方法

HTTP/1 HTTPS HTTP/2 HTTP/3

在这里插入图片描述

HTTP/1.0

  • 默认短连接,每发起一个请求,需要新建一次TCP连接,并且是串行请求

HTTP/1.1

  • 优点:简单、灵活、易于扩展、应用广泛、跨平台
    • 简单:报文格式是header+body,头部信息是key-value简单文本的形式,易于理解,降低学习和使用门槛
    • 灵活、易于扩展:HTTP协议里的各类请求方法,URI/URL、状态码、头字段等每个组成要求没有固定,允许开发人员自定义和扩充。HTTP工作在应用层,下层可以任意变化
    • 应用广泛、跨平台
  • 缺点:无状态、明文传输、不安全
    • 无状态:服务器不会记忆HTTP的状态,不需要额外资源记录状态信息,能减轻服务器的负担。但在完成有关联性的操作时会很麻烦,例如登录验证后的系列操作,每次都需要询问一遍身份信息。
    • 明文传输:便于阅读,但信息容易被窃取
    • 不安全:明文通信,容易被窃听;不验证通信方身份,容易冒充;无法证明报文的完整性,有可能被篡改
  1. 改进

    • 长连接,默认持久连接,减少了TCP连接的重复建立和断开所造成的额外开销,减轻了服务端的负载。持久连接的特点是只要一端没有明确提出断开连接,则保持TCP连接状态

    • 可以进行管道网络传输。即在同一个TCP连接中,客户端可以发起多个请求,只要第一个请求发出去了,不必等其回来,就可以发第二个请求出去,减少整体的响应时间

  2. 瓶颈

    • 请求-应答模式加剧了HTTP的性能问题,服务器按顺序响应请求,若某个请求由于某种原因阻塞,后面排队的请求一同被阻塞,会导致客户端一直请求不到数据,即队头阻塞

    • 请求/响应头部未经压缩就发送,首部信息越多延迟越大。

    • 发送冗长的首部,每次发送相同的首部造成浪费

    • 没有请求优先级

    • 请求只能从客户端开始,服务端被动响应

HTTPS

  • HTTP是超文本传输协议,信息是明文传输,存在安全风险。HTTPS为解决HTTP不安全的缺陷,在TCP和HTTP网络层之间加入了SSL/TLS安全协议,使得报文能够加密传输

  • HTTP连接建立相对简单,TCP三次握手后便可进行HTTP的报文传输。HTTPS在TCP三次握手之后,还需进行SSL/TLS的握手过程,才可进入加密报文传输

  • HTTP端口是80,HTTPS端口是443

  • HTTPS协议需要向CA(证书权威机构)申请数字证书,保证服务器的身份是可信的

  • HTTPS如何保证安全

    • 混合加密:在通信建立前采用非对称加密方式交换会话密钥;通信过程中使用堆成加密的会话密钥加密明文数据
    • 摘要算法:能够为数据生成独一无二的指纹,用于校验数据的完整性,解决了篡改的风险
    • 数字证书:借助第三方权威机构CA(数字证书认证机构),将服务器公钥放在数字证书中,只要证书是可信的,公钥就是可信的。通过数字证书的方式保证服务器公钥的身份,解决冒充的风险
  • HTTPS如何建立

    1. 客户端向服务器索要并验证服务器的公钥
    2. 双方协商产生会话密钥
    3. 双方采用会话密钥进行加密通信

    前两步为SSL/TLS的建立过程,即握手阶段

  • SSL/TLS的建立过程

    1. client Hello:客户端向服务器发起加密通信请求
      1. 客户端支持的SSL/TLS协议版本
      2. 客户端生成的随机数(client random)
      3. 客户端支持的密码套件列表
    2. server hello:服务器收到客户端请求时,向客户端发出以下响应
      1. 确认SSL/TLS协议版本,若浏览器不支持,则关闭加密通信
      2. 服务器生成的随机数(server random)
      3. 确认的密码套件列表
      4. 服务器的数字证书
    3. 客户端响应:客户端收到服务器响应后,首先通过浏览器或操作系统中的CA公钥,确认服务器的数字证书的真实性。若证书没问题,客户端会从数字证书中取出服务器的公钥,用其加密报文,向服务器发送以下信息
      1. 客户端生成的随机数(pre-master key),该随机数将被服务器公钥加密
      2. 加密通信算法改变通知。表示随后的信息都将使用会话密钥加密通信
      3. 客户端握手结束通知。表示客户端的握手阶段已经结束,同时把之前所有内容发生的数据做个摘要,供服务器校验
      4. 使用双方协商的加密算法加密client randomserver randompre-master key三个随机数,生成通信的会话密钥
    4. 服务器响应
      1. 取出客户端发送的随机数,使用双方协商的加密算法加密client randomserver randompre-master key三个随机数,生成通信的会话密钥
      2. 加密通信算法改变通知。表示随后的信息都将使用会话密钥加密通信
      3. 服务器握手结束通知。表示服务器的握手阶段已经结束,同时把之前所有内容发生的数据做个摘要,供客户端校验

HTTP/2

  1. 改进
    • 基于HTTPs的,安全性有保障
    • 头部压缩:HPACK算法:在客户端和服务器同时维护一张头信息表,所有字段存入表中,生成索引号,之后就不会发送相同字段,只发送索引号,提高速度
    • 二进制格式:头信息和数据体都是二进制,统称为帧,收到报文后,无需将明文转成二进制,而是直接解析二进制报文,提高了数据传输的效率
    • 数据流:数据包不用按顺序发送,数据包会做标记,指明其属于哪个回应,每个请求或响应的所有数据包,称为一个数据流。每个数据流都有唯一编号,客户端发出的编号为奇数,服务器发出的数据编号为偶数。客户端还可以指定数据流的优先级。服务器优先响应优先级高的请求
    • 多路复用:在一个TCP连接中并发多个请求或响应,不用按顺序一一对应
    • 服务器推送:服务器可以主动向客户端发送消息
  2. 瓶颈
    • 多个HTTP请求复用一个TCP连接,下层的TCP协议不知道有多少个HTTP请求,一旦发生丢包现象,就会触发TCP的重传机制。

HTTP/3

  • HTTP/3把下层的TCP协议改成了UDPUDP是无连接不可靠的协议,不会出现HTTP/1.1的队头阻塞和HTTP/2的丢包重传问题
  • 基于UDPQUIC协议可以实现类似TCP的可靠性传输
  • QUIC协议可以保证传输的可靠性,当某个流发生丢包时,只会阻塞这个流,其他流不会受到影响
  • HTTPS建立一个连接,需要6次交互:先是建立三次握手,如何是TLS/1.3的三次握手。QUIC将6次交互合并为3次,减少了交互次数
  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值