HTTPS和CoAP协议介绍及对比

VictorLeo

已于 2024-08-10 22:27:48 修改

阅读量888

点赞数 25

分类专栏：网路编程文章标签： https 网络协议 http coap

于 2024-03-15 21:01:55 首次发布

本文链接：https://blog.csdn.net/jun_fire/article/details/136749877

版权

网路编程专栏收录该内容

3 篇文章 0 订阅

订阅专栏

协议HTTPS&CoAP

HTTP协议支持非持久连接和持久连接。非持久连接时，每个TCP连接在服务器返回对象后关闭，请求一个HTML文件所需时间是两个RTT加上服务器发送HTML所需时间；持久连接时就是保持TCP连接，如果一定时间间隔内仍未被使用，HTTP服务器才会关闭该连接。
HTTP是一个无状态协议，即不存储任何客户机的状态信息，当客户机短时间要求两次请求同一个对象时，服务器会发送两次，不会因为刚发了就不再发了。无状态是把双刃剑：无状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务。无状态的坏处，既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。例如登录->添加购物车->下单->结算->支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要问一遍身份信息。这样每操作一次，都要验证信息，这样的购物体验还能愉快吗？
- 对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术。Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。相当于，在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸SessionId」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了了。
- 还有token,使用 token 而不是 cookie 的最大优点应该就是无状态，后端不需要保持对 token 的记录，每个 token 都是独立的，包含了检查其有效性的所有数据，并通过申明传达了用户信息。服务器端的工作只需要在登录成功后，生成（或者 sign，签署） token，或者验证传入的 token 是否有效。有时候甚至不需要生成 token，第三方服务比如 Auth0 可以处理 token 的签发，服务器只需要验证 token 的有效性就可以。用户唯一标识（签名）放在token。token好处就是后端服务器无需存储，每次解密token就知道所需。
- cookie,token验证的区别
HTTP报文格式：每个URL地址由两部分组成，存放对象的服务器主机名和对象的路径名。例如http://www.someSchool.edu/someDepart/picture.gif，其中www.someSchool.edu是主机名，someDepart/picture.gif就是路径名。
HTTP文件传输
PUT和POST区别
- PUT 如果已经存在就替换，没有就新增
- PUT操作是幂等的。所谓幂等是指不管进行多少次操作，结果都一样。比如我用PUT修改一篇文章，然后在做同样的操作，每次操作后的结果并没有不同. POST操作既不是安全的，也不是幂等的，比如常见的POST重复加载问题：当我们多次发出同样的POST请求后，其结果是创建出了若干的资源。
- 要使用PUT请求，如果只想改变属性的值，并且其他属性不想被改变，你必须发送所有可访问属性/值，而不仅仅是你想要改变的那些。
- 总的来说，POST只是新增，但用POST新增时，你可以不指明详细的URI路径, 而等待服务端创建并返回URI, 而用PUT新增则必须同时给定详细的URI路径.
- POST和PUT请求之间的根本区别反映在Request-URI的不同含义中。POST请求中的URI标识将处理封闭实体的资源。该资源可能是数据接受过程，某个其他协议的入口，也可能是接受注释的单独实体。相比之下，PUT请求中的URI标识了请求中包含的实体 - 用户代理知道哪个URI是预期的，服务器不能尝试将请求应用到其他资源。如果服务器希望请求被应用到不同的URI，它必须发送301（永久移动）响应; 用户代理可以自行决定是否重定向请求。即POST的请求有可能会被重定向到另外一个地方，但PUT不会。

HTTPS

简言之，所谓 HTTPS，其实就是身披SSL协议这层外壳的 HTTP。HTTP 的端口号是 80，HTTPS 的端口号是 443
下面我们就来详细的叙述一下证书签名，证书分发以及证书验证的整个过程
1. 服务端人员使用RSA算法生成两个密钥，一个用来加密一个用来解密。将负责加密的那个密钥公布出去，所以我们称之为公钥(Public Key)，而用来解密的那个密钥，不能对外公布，只有服务端持有，所以我们称之为私钥(Private Key)。服务端在将Public Key进行分发证书之前需要向CA机构申请给将要分发的公钥进行数字签名。(服务器公钥负责加密，服务器私钥负责解密)
2. 生成数字签名公钥证书：对于CA机构来说，其也有两个密钥，我们暂且称之为CA私钥和CA公钥。CA机构将服务端的Public Key作为输入参数将其转换为一个特有的Hash值。然后使用CA私钥将这个Hash值进行加密处理，并与服务端的Public Key绑定在一起，生成数字签名证书。其实数字签名证书的本质就是服务端的公钥+CA私钥加密的Hash值。(CA私钥负责签名，CA公钥负责验证)。签名就是内容是公开的，看签名是否有效来判断内容是否有效！
3. 服务器获取到这个已经含有数字签名并带有公钥的证书，将该证书发送给客户端。当客户端收到该公钥数字证书后，会验证其有效性。大部分客户端都会预装CA机构的公钥，也就是CA公钥。客户端使用CA公钥对数字证书上的签名进行验证，这个验证的过程就是使用CA公钥对CA私钥加密的内容进行解密，将解密后的内容与服务端的Public Key所生成的Hash值进行匹配，如果匹配成功，则说明该证书就是相应的服务端发过来的。否则就是非法证书。

背景知识：
  非对称加密， 公钥加密的，只有私钥可以解密； 私钥加密的， 只有公钥可以解密
1. 如何防重放，
    1. 一次TCP连接中， 每条报文都有一条序号（用户自定义）， 相同或者没有增加就丢弃。 也有可能是不同TCP连接进行攻击， 这通过三个随机数解决，协商对称密钥会用到， 因为不同会话， 最终的密钥是不同的。 同时三个随机数使得，知道了密钥也无法破解历史会话， 因为历史会话由于随机数的存在所使用的密钥是不同的。 参考 https://zhuanlan.zhihu.com/p/360782536  ， 
2. 避免中间人攻击
    1. 通过证书，来避免。 浏览器或本地会预先存有一份证书。 （其实就是避免了pulic key交换过程）
3. 避免篡改
    1. 发送的时候除了发送原始数据 ， 还会发送校验值（md5）， 摘要加密， 如果篡改， 解密后校验值不一样
4. 避免窃听
    1. 加密了

WebSocket和 HTTP的区别

连接方式：HTTP是一种无状态的协议，每次请求都需要建立一次连接。而WebSocket是一种全双工协议，客户端和服务端之间只需要建立一次连接，就可以保持长时间的双向通信。
数据格式：HTTP是基于文本的协议，请求和响应的数据都是以文本格式传输。而WebSocket支持二进制数据和文本数据的传输，可以传输更复杂的数据类型。
通信方式：HTTP是一种请求-响应式的通信方式，客户端发送请求，服务端返回响应。而WebSocket支持服务端主动向客户端推送数据，客户端也可以主动向服务端发送数据。
协议头：HTTP协议头较为复杂，需要携带大量的元信息，包括请求方法、状态码、头信息、Cookie等。而WebSocket的协议头比较简单，只需要携带少量的信息，包括协议版本、连接方式、数据类型等。

总的来说，WebSocket是一种全双工、轻量级、低延迟的协议，适用于实时性要求高、数据量较大的场景，例如在线游戏、即时通讯等。而HTTP则适用于请求-响应式的通信场景，例如Web页面的数据传输、文件下载等。

CoAP

基础

CoAP也支持发布订阅模式
CoAP是基于UDP的，所以CoAP支持组播和广播
华为设备发现协议里就使用了CoAP协议
CoAP协议通过以下几个机制来实现传输的可靠性：
1. 可靠传输（Reliable Transmission）：CoAP支持使用重传机制来确保数据的可靠传输。当一条消息没有得到对方确认时，发送方会重复发送该消息。接收方在收到消息后会发送一个确认消息，以告诉发送方该消息已经收到。如果发送方在一定时间内没有收到确认消息，就会认为消息没有送达，会重新发送该消息。
2. 状态同步（State Synchronization）：CoAP支持使用可重复性请求和响应消息的发送，可以发送多个响应消息或者在不同时间点发送多个请求消息，从而保证通信双方的状态同步。就是可以发送多条重复的包，包括重复的请求包和重复的响应包来确保对端收到。对端如果收到多条会自行过滤。
3. 消息分片（Message Fragmentation）：CoAP协议支持将消息分片成多个小片段进行传输，以避免由于消息过大导致的数据包丢失和重传的问题。接收方在收到所有片段后再进行组装，确保消息的完整性和正确性。
- 需要注意的是，CoAP是一种轻量级的协议，对于传输可靠性的保证和控制并不像传统的TCP协议那样严格，而是根据不同的场景和需求灵活选择相应的机制。因此，在使用CoAP协议进行通信时，需要根据具体的应用场景和需求来选择和配置相应的传输可靠性机制。
COAP的安全性是用DTLS （DTLS全称为Datagram Transport Layer Security，中文名为数据包传输层安全性协议，它是基于TLS扩展，使之支持UDP协议，DTLS 1.0 基于 TLS 1.1，DTLS 1.2 基于 TLS 1.2）加密实现的。DTLS的实现需要的资源和带宽较多，如果是资源非常少的终端和极有限的带宽下可能会跑不起来。DTLS仅仅在单播情况下适用。

Coap协议是一种专门应用在受限设备或者受限网络（比如低功耗、高损失）上的网络传输协议。对于低功耗受限制设备而言，实现 TCP 和 HTTP显然是一个过分而苛刻的要求。为了让低功耗受限制设备可以接人互联网，CoAP 应运而生。CoAP 是一种应用层协议，它运行于 UDP 之上而不是像 HTTP 那样运行于 TCP 之上。CoAP 非常小巧，最小的数据包仅为 4 字节

一个简单的coap包.cap

下面是一条 CoAP 协议报文示例：
CON, GET, MID: 0x7b54, URI: /temperature, T: 0, TKL: 0
Uri-Host: example.com
Observe: 0
Accept: application/json

该报文解释如下：

- CON 表示这是一个确认可靠传输模式的请求报文（Confirmable）
- GET 表示该请求使用的是 GET 方法
- MID: 0x7b54 表示该报文的 Message ID 是 0x7b54
- URI: /temperature 表示请求的资源路径为 /temperature
- T: 0 表示该报文使用的协议版本为 1
- TKL: 0 表示 URI 中没有包含 Token
- Uri-Host: example.com 表示请求的主机名为 example.com
- Observe: 0 表示该请求不是一个观察者请求，服务器不需要返回观察状态
- Accept: application/json 表示客户端可以接受的响应格式为 JSON

需要注意的是，CoAP 协议的报文格式非常简洁，仅包含必要的信息，以便在 IoT 设备和无线传感器网络中实现低带宽和低功耗的通信。