HTTP 1.0 2.0 3.0详解
HTTP
HTTP全称超文本传输协议,是一种属于应用层的通信协议。它允许将超文本标记语言文档(HTML)从Web服务器传输到客户端的浏览器。
HTTP报文结构
请求报文结构
请求方法:
- GET:一般用来请求已被URI识别的资源,指定的资源经服务器解析后返回响应内容;也可以用来提交表单信息,但不安全。
- POST:一般用来传输实体的主体,主要目的不是获取响应主体的内容
- PUT:从客户端向服务器传送更新内容,具有幂等性,多次PUT请求结果一样。
- HEAD:类似于GET请求,只不过返回的响应中没有具体内容,用于获取报头。
- DELETE:请求服务器删除指定资源
- OPTIONS:用来查询针对URI指定资源支持的方法
- TRACE:回显服务器收到的请求,主要用于测试和诊断
- CONNECT:开启一个客户端与请求资源的双向沟通通道,它可以用来创建隧道。应用于代理服务器的实现。
GET与POST的区别
- GET一般是去获取数据,也可以提交数据,但多数是获取。POST一般是去提交数据。
- GET用于提交时的URL有长度限制,POST没有长度限制,数据放在主体中。
- GET是幂等操作,多次请求不会对服务器造成改变,POST不是幂等的,多次请求会影响服务器。
- GET因为数据会放在URL中,安全性较差。POST安全性高一些。
常见请求报文字段
- Accept :客户端希望获得资源的类型。
- Accept-Encoding :客户端支持的压缩算法。
- Accept-Language :客户端支持的语言。
- Host :当前请求的域名。
- Connection :客户端是否希望使用 TCP 长连接。
- User-Agent :用户代理的信息。该字段标注了发送方的一些信息,你可以通过它来知道请求方的浏览器、操作系统版本等等
响应报文结构
状态码:
- 1XX:代表请求已被接受,需要继续处理。
- 2XX:代表请求已经被服务器端成功接收,操作被成功接收并处理。
- 3XX:表示重定向到了一个新的URL。代表客户端需要采取进一步操作才能完成请求。
- 4XX:表示请求错误。代表客户端发生了错误。
- 5XX:表示服务器发生了错误
状态码示例
- 200:请求已成功,响应头、响应体返回此响应
- 202:已接受请求,但还没有处理完成。
- 206:部分内容,服务器成功处理了GET的部分内容。(断点续传)
- 301:永久移动,请求的资源被永久移到了新的URI,客户端使用新的URI
- 302:临时移动,客户端继续使用原有的URI
- 400:客户端请求错误,服务器无法理解
- 401:请求需要用户身份认证
- 403:服务器理解客户端请求,但是拒绝执行此请求
- 404:服务器找不到客户端请求的资源
- 500:服务器内部错误
- 502:充当网关或代理服务器,从远端服务器收到一个无效的请求
常见响应报文字段
- Content-Type :服务端返回的资源类型,可以带上使用的编码格式。
- Content-Encoding :返回资源使用的压缩格式。
- Content-Length :HTTP 消息体的长度。
- Date :HTTP 响应报文生成的时间
- Connection :服务端决定使用长连接还是短连接。
- Server :使用了哪种服务器。
四种报文头
HTTP报文头大致分为四类:
- 通用报文头:既可以用在请求报文中,也可以用在响应报文中。
- 请求报文头
- 响应报文头
- 实体报文头
通用报文头
请求报文头
响应报文头
实体报文头
cookie和session
cookie
- HTTP 是无状态协议,说明它不能以状态来区分和管理请求和响应。Cookie 技术通过在请求和响应报文中写入Cookie 信息来控制客户端的状态。
- 服务器收到客户端请求,生成cookie,记录相应的信息,并在响应报文中附带上cookie。
- 客户端收到服务器的响应报文并保存Cookie。当下次客户端再往该服务器发送请求时,客户端会自动在请求报文中加入Cookie 值后发送出去。
- 服务器端发现客户端发送过来的Cookie 后,会对比服务器上的记录,最后得到之前的状态信息。
session
Session 对象存储特定用户会话所需的属性及配置信息。这样,当用户在应用程序的 Web 页之间跳转时,存储在 Session 对象中的变量将不会丢失,而是在整个用户会话中一直存在下去。当用户请求来自应用程序的 Web 页时,如果该用户还没有会话,则 Web 服务器将自动创建一个 Session 对象。当会话过期或被放弃后,服务器将终止该会话。
鉴于HTTP 是无状态协议,之前已认证成功的用户状态无法通过协议层面保存下来。即,无法实现状态管理,因此即使当该用户下一次继续访问,也无法区分他与其他的用户。于是我们会使用Cookie 来管理Session,以弥补HTTP 协议中不存在的状态管理功能。
Session 管理及Cookie 状态管理(基于表单的认证)
- 客户端把用户ID 和密码等登录信息放入报文的实体部分,通常是以POST 方法把请求发送给服务器。而这时,会使用HTTPS 通信来进行HTML 表单画面的显示和用户输入数据的发送。
- 服务器会发放用以识别用户的Session ID。通过验证从客户端发送过来的登录信息进行身份认证,然后把用户的认证状态与Session ID 绑定后记录在服务器端。 向客户端返回响应时,会在首部字段Set-Cookie 内写入Session ID(如PHPSESSID=028a8c…)。
- 客户端接收到从服务器端发来的Session ID 后,会将其作为Cookie 保存在本地。下次向服务器发送请求时,浏览器会自动发送Cookie,所以Session ID 也随之发送到服务器。服务器端可通过验证接收到的Session ID 识别用户和其认证状态。
HTTP1.0
1.0的HTTP版本,是一种无状态,短连接的应用层协议。 HTTP1.0规定浏览器和服务器保持短暂的链接。
浏览器每次请求都需要与服务器建立一个TCP连接,服务器处理完成以后立即断开TCP连接(短连接),服务器不跟踪每个客户单,也不记录过去的请求(无状态)。
这种无状态性可以借助cookie/session机制来做状态记录和身份认证。
特点
- 无状态:服务器不跟踪客户请求,不记录客户状态信息
- 短连接/无连接:每次发送请求都要重新建立tcp请求,即三次握手,非常浪费性能
- 不允许断点续传,而且不能只传输对象的一部分,要求传输整个对象
缺点:
- 无法复用连接:每次发送请求,都需要进行一次TCP连接,而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率变低。
- 队头阻塞(head of line blocking):由于HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送,假设前一个请求响应一直不到达,那么下一个请求就不发送,后面的请求就阻塞了。
HTTP1.1
HTTP1.1继承了HTTP1.0的简单,克服了HTTP1.0性能上的问题。
特点
- 连接方式 : HTTP 1.1 支持长连接,可以同时开启多个TCP连接。
- 管道(pipeline)网络传输:只要第一个请求发出去了,不必等其响应回来,就可以发第二个请求出去,可以减少整体的响应时间。
- 允许断点续传 :引入了 range 头域,它允许只请求资源的某个部分。
缺点
- 队头阻塞:服务器是按请求的顺序响应的,如果服务器响应慢,会招致客户端一直请求不到数据;
- 请求 / 响应头部(Header)未经压缩就发送:首部信息越多延迟越大。只能压缩 Body 的部分;
- 服务器只能被动响应:请求只能从客户端开始
HTTP2.0
特点
- 二进制分帧:HTTP2.0通过在应用层和传输层之间增加一个二进制分帧层,改进传输性能。
- 多路复用(并行传输):2.0将消息拆分成了一个个帧,针对不同的消息的帧,用独一无二的 流 ID 来区分,不同流的帧是可以乱序发送的,因此可以并发不同的流。服务器可以通过流 ID 将帧有序组装成消息。HTTP2.0依此可以实现并发交错地发送消息 。
- 流(stream):已建立连接上的双向字节流。
- 头部压缩:
- HTTP2.0使用编码压缩来减少需要传输的头部大小
- 通讯双方各自缓存一份header_files表,避免重复header的传输,减少需要传输的大小。
- 服务器推送 :服务器还可以主动向客户端推送资源。
缺点:
- TCP丢失重传导致阻塞:http 2.0虽然支持多路复用,但是所有消息的传输是基于一个TCP连接。TCP中前一个stream丢包重传导致后一个stream被阻塞,从而后面所有的消息传输都会阻塞。而HTTP1.1中可以开启多个TCP连接,就不存在这个问题。
HTTP3.0
Google搞了一个基于UDP协议的QUIC协议,并且命名为HTTP3.0
特点
- 基于UDP的多路复用(无队头阻塞):基于UDP,一个连接上的多个stream之间没有依赖,即使丢包,只需要重发丢失的包即可,不需要重建整个连接。不会导致其他的消息被阻塞。
- 更快的连接建立:
- 握手过程只需要 1 RTT,握手的目的是为确认双方的「连接 ID」,连接迁移就是基于连接 ID 实现的。
- QUIC 内部包含了 TLS,它在自己的帧会携带 TLS 里的“记录”,再加上 QUIC 使用的是 TLS/1.3,因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商
- 基于ID识别(方便的连接迁移):连接迁移时,不再用TCP四元组确定一个连接,而是用一个64位随机数来确定这个连接。无论网络环境如何变化,只要ID不变,就能迅速重新连上。
HTTPS
HTTPS在HTTP的基础上加了一层SSL/TSL四次握手来完成对称加密的操作,HTTPS一般加密URL和传输资源。
HTTP和HTTPS的区别
- HTTP 是超文本传输协议,信息是明文传输,存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷,在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议,使得报文能够加密传输。
- HTTP 连接建立相对简单, TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后,还需进行四次 SSL/TLS 的握手过程,才可进入加密报文传输。
- HTTPS的传输效率不如HTTP效率高
- 两者的默认端口不一样,HTTP 默认端口号是 80,HTTPS 默认端口号是 443。
SSL/TSL流程
握手阶段
- 客户端发起请求
- 服务器返回证书和公钥
- 客户端从CA验证证书(防止中间人攻击)
- 证书合法,生成私钥(随机数)
- 用公钥加密私钥并发送给服务器
- 服务器解密获得私钥
传输阶段
- 用私钥加解密,完成对称传输
原文地址:https://blog.csdn.net/qq_45233572/article/details/142525529
免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!