【嵌入式八股20】嵌入式通信协议
一、各种协议对应的传输层协议
在网络通信中,不同的应用协议依赖于传输层的不同协议来实现数据传输。以下是一些常见协议及其在传输层所使用的协议情况:
| ping | ● | ||||
| traceroute | ● | ● | |||
| OSPF(路由协议) | ● | ||||
| RIP(路由协议) | ● | ||||
| BGP(路由协议) | ● | ||||
| BOOTP(引导协议) | ● | ||||
| DHCP | ● | ||||
| NTP(时间协议) | ● | ||||
| TFTP(低级 FTP) | ● | ||||
| SNMP(网络管理) | ● | ||||
| IGMP(组播管理) | ● | ||||
| SMTP(电子邮件) | ● | ||||
| telnet(远程登录) | ● | ||||
| SSH(安全远程登录) | ● | ||||
| FTP(文件传输) | ● | ||||
| HTTP(web) | ● | ||||
| NNTP(网络新闻) | ● | ||||
| LPR(远程打印) | ● | ||||
| DNS(域名系统) | ● | ● | |||
| NFS(网络文件系统) | ● | ● | |||
| Sun RPC(远程过程调用) | ● | ● | |||
| DCE RPC(远程过程调用) | ● | ● | |||
| IUA(ISDN) | ● | ||||
| M2UA/M3UA(SS7 电话信令) | ● | ||||
| H.248(媒体网关控制) | ● | ● | ● | ||
| H.323(IP 电话) | ● | ● | ● | ||
| H.248(IP 电话) | ● | ● | ● |
二、MQTT 协议
MQTT(Message Queuing Telemetry Transport)是一种轻量级的消息传输协议,广泛应用于物联网等领域。
官方文档:https://mcxiaoke.gitbooks.io/mqtt-cn/content/mqtt/04-OperationalBehavior.html
(一)MQTT 网络连接方式
MQTT 支持以下 3 种网络连接方式:
- tcp:使用 1883 端口,是最基本的连接方式,适用于大多数常规的 MQTT 通信场景。
- TLS:使用 8883 端口,基于 TCP 连接并提供了加密功能,确保数据传输的安全性,适用于对数据安全有较高要求的场景。
- websocket:通过 WebSocket 协议进行连接,使得 MQTT 能够在 Web 环境中更方便地集成和使用。
(二)主题过滤器(Topic Filter)
主题过滤器是订阅中包含的一个表达式,用于表示相关的一个或多个主题。它可以使用通配符,通过主题过滤器,客户端可以灵活地订阅感兴趣的主题,实现消息的高效分发和接收。
(三)控制报文(MQTT Control Packet)
MQTT 规范定义了十四种不同类型的控制报文,这些控制报文是通过网络连接发送的信息数据包,用于实现客户端与服务端之间的各种交互操作。具体如下:
| Reserved | 0 | 禁止 | 保留,不用于实际通信 |
| CONNECT | 1 | 客户端到服务端 | 客户端请求连接服务端,用于建立 MQTT 连接 |
| CONNACK | 2 | 服务端到客户端 | 连接报文确认,服务端对客户端的连接请求进行响应 |
| PUBLISH | 3 | 两个方向都允许 | 发布消息,用于客户端向服务端或服务端向客户端发送消息 |
| PUBACK | 4 | 两个方向都允许 | QoS 1 消息发布收到确认,用于确认 QoS 1 等级的消息已被接收 |
| PUBREC | 5 | 两个方向都允许 | 发布收到(保证交付第一步),用于 QoS 2 消息的保证交付流程 |
| PUBREL | 6 | 两个方向都允许 | 发布释放(保证交付第二步),继续 QoS 2 消息的保证交付流程 |
| PUBCOMP | 7 | 两个方向都允许 | QoS 2 消息发布完成(保证交互第三步),完成 QoS 2 消息的保证交付 |
| SUBSCRIBE | 8 | 客户端到服务端 | 客户端订阅请求,客户端向服务端请求订阅特定主题 |
| SUBACK | 9 | 服务端到客户端 | 订阅请求报文确认,服务端对客户端的订阅请求进行响应 |
| UNSUBSCRIBE | 10 | 客户端到服务端 | 客户端取消订阅请求,客户端向服务端请求取消对特定主题的订阅 |
| UNSUBACK | 11 | 服务端到客户端 | 取消订阅报文确认,服务端对客户端的取消订阅请求进行响应 |
| PINGREQ | 12 | 客户端到服务端 | 心跳请求,客户端向服务端发送心跳消息以保持连接活性 |
| PINGRESP | 13 | 服务端到客户端 | 心跳响应,服务端对客户端的心跳请求进行响应 |
| DISCONNECT | 14 | 客户端到服务端 | 客户端断开连接,客户端主动断开与服务端的连接 |
| Reserved | 15 | 禁止 | 保留,不用于实际通信 |
(四)大端模式
MQTT 数据格式使用大端模式存放。大端模式是一种数据存储方式,即数据的高位字节存放在内存的低地址处,低位字节存放在内存的高地址处。
(五)MQTT 控制报文结构
MQTT 控制报文由以下三个部分组成:
- 固定报头:总共是 2 - 5 个字节。
- 第 1 个字节:高 4 位表示控制报文类型,低 4 位表示控制报文类型的标志位。通过这 8 位可以快速识别控制报文的基本类型和相关标志信息。
- 第 2 - 5 字节:剩余长度,表示当前报文剩余部分的字节数,包括可变报头和 payload 的数据。剩余长度字段使用一个变长度编码方案,对小于 128 的值它使用单字节编码。更大的值按特定方式处理,低 7 位有效位用于编码数据,最高有效位用于指示是否有更多的字节。因此每个字节可以编码 128 个数值和一个延续位(continuation bit),剩余长度字段最大 4 个字节。具体如下: | 字节数 | 最小值 | 最大值 | | ---- | ---- | ---- | | 1 | 0 (0x00) | 127 (0x7F) | | 2 | 128 (0x80, 0x01) | 16383 (0xFF, 0x7F) | | 3 | 16 384 (0x80, 0x80, 0x01) | 2097151 (0xFF, 0xFF, 0x7F) | | 4 | 2 097 152 (0x80, 0x80, 0x80, 0x01) | 268435455 (0xFF, 0xFF, 0xFF, 0x7F) |
变长编码方案代码:
do
encodedByte = X MOD 128
X = X DIV 128
// if there are more data to encode, set the top bit of this byte
if ( X > 0 )
encodedByte = encodedByte OR 128
endif
'output' encodedByte
while ( X > 0 )
变长解码方案代码:
multiplier = 1
value = 0
do
encodedByte = 'next byte from stream'
value += (encodedByte AND 127) * multiplier
multiplier *= 128
if (multiplier > 128*128*128)
throw Error(Malformed Remaining Length)
while ((encodedByte AND 128) != 0)
- 可变报头(Variable header):某些 MQTT 控制报文包含一个可变报头部分,它在固定报头和负载之间。可变报头的内容根据报文类型的不同而不同,其中可变报头的报文标识符(Packet Identifier)字段存在于多个类型的报文里。
- 报文标识符(Packet Identifier):很多控制报文的可变报头部分包含一个两字节的报文标识符字段,这些报文包括
PUBLISH(QoS > 0 时), PUBACK,PUBREC,PUBREL,PUBCOMP,SUBSCRIBE, SUBACK,UNSUBSCIBE,UNSUBACK。控制报文必须包含一个非零的 16 位报文标识符(Packet Identifier)。客户端每次发送一个新的这些类型的报文时都必须分配一个当前未使用的报文标识符。如果一个客户端要重发这个特殊的控制报文,在随后重发那个报文时,它必须使用相同的标识符。当客户端处理完这个报文对应的确认后,这个报文标识符就释放可重用。QoS 1 的 PUBLISH 对应的是 PUBACK,QoS 2 的 PUBLISH 对应的是 PUBCOMP,与 SUBSCRIBE 或 UNSUBSCRIBE 对应的分别是 SUBACK 或 UNSUBACK。发送一个 QoS 0 的 PUBLISH 报文时,相同的条件也适用于服务端。需要注意的是,QoS 等于 0 的 PUBLISH 报文不能包含报文标识符。PUBACK, PUBREC, PUBREL 报文必须包含与最初发送的 PUBLISH 报文相同的报文标识符。类似地,SUBACK 和 UNSUBACK 必须包含在对应的 SUBSCRIBE 和 UNSUBSCRIBE 报文中使用的报文标识符。 - payload:某些 MQTT 控制报文在报文的最后部分包含一个有效载荷。对于 PUBLISH 来说有效载荷就是应用消息。各控制报文对有效载荷的需求情况如下: | 控制报文 | 有效载荷 | | ---- | ---- | | CONNECT | 需要 | | CONNACK | 不需要 | | PUBLISH | 可选 | | PUBACK | 不需要 | | PUBREC | 不需要 | | PUBREL | 不需要 | | PUBCOMP | 不需要 | | SUBSCRIBE | 需要 | | SUBACK | 需要 | | UNSUBSCRIBE | 需要 | | UNSUBACK | 不需要 | | PINGREQ | 不需要 | | PINGRESP | 不需要 | | DISCONNECT | 不需要 |
三、HTTP 协议
HTTP(HyperText Transfer Protocol)是用于在 Web 上传输超文本的协议,是客户端与服务器之间进行通信的基础。
(一)HTTP 请求方法
HTTP 协议永远都是客户端发起请求,服务器回送响应。常见的 HTTP 请求方法有以下几种:
- GET:用于请求服务器返回指定资源的内容,是最常用的请求方法之一。同时,它还可以返回服务器针对特定资源所支持的 HTTP 请求方法,也可以利用向 Web 服务器发送'*'的请求来测试服务器的功能性。
- PUT:向指定资源位置上传其最新内容,一般用于更新资源。
- POST:向指定资源提交数据进行处理请求,例如提交表单或者上传文件,数据被包含在请求体中。POST 请求可能会导致新的资源的创建和/或已有资源的修改。
- HEAD:向服务器索要与 GET 请求相一致的响应,只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下,就可以获取包含在响应消息头中的元信息,用于获取资源的基本信息而无需获取实际内容。
- DELETE:请求服务器删除 Request - URI 所标识的资源,用于删除服务器上的特定资源。
- TRACE:回显服务器收到的请求,主要用于测试或诊断,帮助开发者了解请求在网络中的传输情况。
- CONNECT:HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器,用于建立隧道连接。
- OPTIONS:返回服务器针对特定资源所支持的 HTTP 请求方法,也可以利用向 Web 服务器发送'*'的请求来测试服务器的功能性,用于查询服务器的能力和支持的方法。
(二)HTTP 状态码
HTTP 状态码用于表示服务器对客户端请求的处理结果,根据状态码的首位数字,可分为以下几类:
-
1xx:请求收到,继续处理
- 100:客户必须继续发出请求。表示服务器已收到请求的第一部分,客户端应继续发送剩余部分。
- 101:客户要求服务器根据请求转换 HTTP 协议版本,服务器将按照客户端的要求进行协议版本的转换。
-
2xx:操作成功收到,分析、接受
- 200:交易成功。表示请求已成功处理,服务器返回了客户端请求的资源。
- 201:提示知道新文件的 URL。服务器创建了新的资源,并返回了该资源的 URL。
- 202:接受和处理、但处理未完成。服务器已接受请求,但尚未完成处理,请求可能在后台继续执行。
- 203:返回信息不确定或不完整。服务器已成功处理请求,但返回的信息可能不完全或不完整。
- 204:请求收到,但返回信息为空。服务器已成功处理请求,但没有返回任何内容。
- 205:服务器完成了请求,用户代理必须复位当前已经浏览过的文件。用于指示客户端重置其浏览状态。
- 206:服务器已经完成了部分用户的 GET 请求。用于支持范围请求,服务器只返回了请求资源的一部分。
-
3xx:完成此请求必须进一步处理
- 300:请求的资源可在多处得到。服务器返回一个资源的多个位置,客户端可以选择其中一个位置进行访问。
- 301:删除请求数据。请求的资源已被永久移动到新的位置,服务器返回新的 URL,客户端应使用新的 URL 进行后续请求。
- 302:在其他地址发现了请求数据。请求的资源临时移动到新的位置,服务器返回新的 URL,客户端应使用新的 URL 进行本次请求,但下次请求可能仍使用原 URL。
- 303:建议客户访问其他 URL 或访问方式。服务器建议客户端使用另一个 URL 来获取资源,通常用于重定向到另一个资源。
- 304:客户端已经执行了 GET,但文件未变化。服务器通知客户端请求的资源没有发生变化,客户端可以使用本地缓存的资源。
- 305:请求的资源必须从服务器指定的地址得到。客户端必须使用服务器指定的代理服务器来访问资源。
- 306:前一版本 HTTP 中使用的代码,现行版本中不再使用。
- 307:申明请求的资源临时性删除。请求的资源临时不可用,服务器返回一个新的 URL,客户端应使用新的 URL 进行本次请求,但下次请求可能仍使用原 URL。
-
4xx:请求包含一个错误语法或不能完成
- 400:错误请求,如语法错误。客户端发送的请求存在语法错误,服务器无法理解请求。
- 401:未授权,客户端需要进行身份验证才能访问资源。具体细分如下:
- HTTP 401.1 - 未授权:登录失败
- HTTP 401.2 - 未授权:服务器配置问题导致登录失败
- HTTP 401.3 - ACL 禁止访问资源
- HTTP 401.4 - 未授权:授权被筛选器拒绝
- HTTP 401.5 - 未授权:ISAPI 或 CGI 授权失败
- 402:保留有效 ChargeTo 头响应。该状态码目前未被广泛使用,保留用于未来可能的支付相关功能。
- 403:禁止访问,服务器拒绝客户端访问资源。具体细分如下:
- HTTP 403.1 禁止访问:禁止可执行访问
- HTTP 403.2 - 禁止访问:禁止读访问
- HTTP 403.3 - 禁止访问:禁止写访问
- HTTP 403.4 - 禁止访问:要求 SSL
- HTTP 403.5 - 禁止访问:要求 SSL 128
- HTTP 403.6 - 禁止访问:IP 地址被拒绝
- HTTP 403.7 - 禁止访问:要求客户证书
- HTTP 403.8 - 禁止访问:禁止站点访问
- HTTP 403.9 - 禁止访问:连接的用户过多
- HTTP 403.10 - 禁止访问:配置无效
- HTTP 403.11 - 禁止访问:密码更改
- HTTP 403.12 - 禁止访问:映射器拒绝访问
- HTTP 403.13 - 禁止访问:客户证书已被吊销
- HTTP 403.15 - 禁止访问:客户访问许可过多
- HTTP 403.16 - 禁止访问:客户证书不可信或者无效
- HTTP 403.17 - 禁止访问:客户证书已经到期或者尚未生效
- 404:没有发现文件、查询或 URL。服务器无法找到客户端请求的资源。
- 405:用户在 Request-Line 字段定义的方法不允许。服务器不支持客户端使用的请求方法。
- 406:根据用户发送的 Accept 头,请求资源不可访问。客户端请求的资源无法以客户端接受的格式提供。
- 407:类似 401,用户必须首先在代理服务器上得到授权。客户端需要通过代理服务器进行访问,并且需要在代理服务器上进行身份验证。
- 408:客户端没有在用户指定的时间内完成请求。服务器等待客户端请求超时。
- 409:对当前资源状态,请求不能完成。请求与资源的当前状态冲突,无法完成请求。
- 410:服务器上不再有此资源且无进一步的参考地址。请求的资源已被永久删除,服务器无法提供该资源。
- 411:服务器拒绝用户定义的 Content-Length 属性请求。客户端请求中包含的 Content-Length 头字段无效,服务器拒绝处理该请求。
- 412:一个或多个请求头字段在当前请求中错误。客户端请求中的一个或多个头字段存在错误,服务器无法处理该请求。
- 413:请求的资源大于服务器允许的大小。客户端请求的实体内容过大,超过了服务器的限制。
- 414:请求的资源 URL 长于服务器允许的长度。客户端请求的 URL 过长,超过了服务器的限制。
- 415:请求资源不支持请求项目格式。客户端请求的资源格式不被服务器支持。
- 416:请求中包含 Range 请求头字段,在当前请求资源范围内没有 range 指示值,请求也不包含 If-Range 请求头字段。客户端的范围请求无效。
- 417:服务器不满足请求 Expect 头字段指定的期望值。如果是代理服务器,可能是下一级服务器不能满足请求要求,服务器无法满足客户端请求中 Expect 头字段指定的期望。
-
5xx:服务器执行一个完全有效请求失败
- HTTP 500 - 内部服务器错误:服务器在处理请求时发生内部错误,无法完成请求。
- HTTP 500.100 - 内部服务器错误 - ASP 错误:与 ASP(Active Server Pages)相关的内部服务器错误。
- HTTP 500-11 服务器关闭:服务器关闭,无法处理请求。
- HTTP 500-12 应用程序重新启动:服务器上的应用程序正在重新启动,暂时无法处理请求。
- HTTP 500-13 - 服务器太忙:服务器负载过高,无法处理请求。
- HTTP 500-14 - 应用程序无效:服务器上的应用程序无效,无法处理请求。
- HTTP 500-15 - 不允许请求 global.asa:不允许请求 global.asa 文件,可能是由于权限或配置问题。
- Error 501 - 未实现:服务器不支持请求的功能,无法完成请求。
- HTTP 502 - 网关错误:服务器作为网关或代理时,从上游服务器收到无效响应。
(三)长连接与短连接
- HTTP 1.0:使用短连接,即每次请求完成后,客户端与服务器之间的连接就会关闭。如果客户端需要再次发送请求,需要重新建立连接。这种方式在频繁请求的情况下,会增加连接建立和关闭的开销。
- HTTP 1.1:版本默认使用长连接,也称为持久连接。在长连接模式下,客户端与服务器建立一次连接后,可以在该连接上进行多次请求和响应,减少了连接建立的开销,提高了数据传输的效率。
(四)HTTP 请求消息格式
HTTP 请求消息由以下几部分组成:
- 请求行:包含请求方法、请求的资源路径和 HTTP 协议版本,例如:
GET /hello.htm HTTP/1.1。 - 通用信息头|请求头|实体头:包含各种头部字段,用于传递请求的相关信息,如客户端的接受能力、认证信息等。例如:
Accept: */*
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
If-Modified-Since: Wed, 17 Oct 2007 02:15:55 GMT
If-None-Match: W/"158-1192587355000"
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: 192.168.2.162:8080
Connection: Keep-Alive
- CRLF(回车换行):用于分隔请求行和头部字段,以及头部字段之间的分隔。
(五)HTTP 响应消息格式
HTTP 响应消息由以下几部分组成:
- 状态行:包含 HTTP 协议版本、状态码和状态码的描述,例如:
HTTP/1.1 200 OK。 - 通用信息头|响应头|实体头:包含各种头部字段,用于传递响应的相关信息,如资源的类型、长度、修改时间等。例如:
ETag: W/"158-1192590101000"
Last-Modified: Wed, 17 Oct 2007 03:01:41 GMT
Content-Type: text/html
Content-Length: 158
Date: Wed, 17 Oct 2007 03:01:59 GMT
Server: Apache-Coyote/1.1
- CRLF:用于分隔状态行和头部字段,以及头部字段之间的分隔。
(六)HTTP post 发送文件
使用 POST 方法可以发送文件内容。在发送文件时,通常需要设置合适的请求头字段,如Content-Type(一般设置为multipart/form-data)来指示请求体中包含文件数据。请求体中会包含文件的相关信息和文件内容本身,服务器接收到请求后,会根据请求头和请求体的信息来处理文件上传操作。
(七)HTTP 用户名密码机制
一种常见的使用 cookie 的方式来实现用户名密码机制:
- 当用户登录成功后,用 JavaScript 调用 cookie 的相关接口,创建一个浏览器上的全局变量,变量名和值由开发者自己约定。
- 每个页面载入时,检查 cookie 是否存在,其值是否为默认的那个值。如果不是的话,就跳转到登录页面,要求用户重新进行登录操作。
(八)HTTPS 的通信过程
HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer)是在 HTTP 的基础上通过传输加密和身份认证来确保通信安全的协议。其通信过程如下(可结合图片理解):
- 客户端发起请求:客户端向服务器发送一个 HTTPS 请求,请求中包含客户端支持的加密算法和协议版本等信息。
- 服务器响应:服务器收到请求后,选择一个双方都支持的加密算法和协议版本,并将服务器的数字证书发送给客户端。数字证书包含了服务器的公钥等信息。
- 客户端验证证书:客户端收到服务器的数字证书后,使用证书颁发机构(CA)的公钥来验证证书的有效性。如果证书有效,客户端会从中提取服务器的公钥。
- 生成会话密钥:客户端生成一个随机的会话密钥,使用服务器的公钥对其进行加密,并将加密后的会话密钥发送给服务器。
- 服务器解密会话密钥:服务器使用自己的私钥对客户端发送的加密会话密钥进行解密,得到会话密钥。
- 加密通信:双方使用会话密钥对后续的通信数据进行加密和解密,实现安全的数据传输。
(九)HTTPS、SSH 公钥、秘钥、对称加密、非对称加密、hash 算法
- 非对称加密:
- DES(Data Encryption Standard):是一种对称加密算法,其秘钥长度为 56bit。虽然曾经被广泛使用,但由于其密钥长度相对较短,在现代加密需求下,安全性逐渐受到挑战。
- AES(Advanced Encryption Standard):也是对称加密算法,秘钥长度支持 128、196 和 256 位。AES 被认为是一种安全且高效的加密算法,广泛应用于各种安全场景。
- 非对称加密:
- DSA(Digital Signature Algorithm):用于数字签名和认证中。和 RSA 不同之处在于它不能用作加密和解密,也不能进行密钥交换,只用于签名。它比 RSA 要快很多,并且 DSA 只能与 SHA-1 一起使用,而 RSA 可以与任何摘要算法一起使用。DSA 主要依赖于整数有限域离散对数难题。
- RSA:是一种常用的非对称加密算法,可用于加密、解密以及数字签名等操作。它基于大整数分解的数学难题,安全性较高,但计算效率相对较低。
- HASH 算法:
- MD5(Message - Digest Algorithm 5):曾经被广泛使用的哈希算法,用于生成数据的摘要。但由于其存在一些安全漏洞,如碰撞问题(不同的数据可能生成相同的摘要),在一些对安全性要求较高的场景中已不再推荐使用。
- SHA1(Secure Hash Algorithm 1):也是一种哈希算法,用于生成数据的摘要。与 MD5 类似,SHA1 也存在一定的安全风险,逐渐被更安全的哈希算法所取代。
- SHA256(Secure Hash Algorithm 256):是 SHA-2 系列哈希算法中的一种,生成的摘要长度为 256 位,具有较高的安全性,被广泛应用于各种需要数据完整性和认证的场景。
需要注意的是,DSA 用于签名,而 RSA 可用于签名和加密。
(十)数字签名和数字证书
- 数字签名:服务器把发送内容用 hash 算法生成摘要(即校验码),然后用私钥加密这个摘要,得到的加密结果就是数字签名。数字签名可以用于验证消息的完整性和来源的真实性,接收方可以使用服务器的公钥对数字签名进行解密,并与自己计算的摘要进行对比,以确认消息在传输过程中没有被篡改。
- 数字证书:证书中心把服务器的公钥和一些其他的必要信息(如服务器的身份信息、证书的有效期等)通过证书中心的私钥加密生成一个证书。服务器每次把数字签名、内容、数字证书一起发送给客户端,客户端用证书中心的公钥验证数字证书是不是可信任的。如果证书验证通过,客户端可以从证书中提取服务器的公钥,用于验证数字签名和后续的加密通信。
(十一)websocket
WebSocket 协议支持客户端与远程主机之间进行全双工通信,使得客户端和服务器可以在同一个连接上同时发送和接收数据。
- 协议标识符和地址格式:协议标识符是 ws(如果加密,则为 wss),服务器网址就是 URL,例如:
ws://example.com:80/some/path。 - websocket 握手协议:
- 浏览器请求:
GET /webfin/websocket/ HTTP/1.1
Host: localhost
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: xqBt3ImNzJbYqRINxEFlkg==
Origin: http://服务器地址
Sec-WebSocket-Version: 13
WebSocket 借用 HTTP 请求进行握手,相比正常的 HTTP 请求,多了一些内容。其中,Upgrade: websocket和Connection: Upgrade表示希望将 HTTP 协议升级到 WebSocket 协议;Sec-WebSocket-Key是浏览器随机生成的 base64 encode 的值,用来询问服务器是否支持 WebSocket。
- 服务器回应:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: K7DJLdLooIwIG/MOpvWFB3y3FE8=
服务器返回Upgrade: websocket和Connection: Upgrade告诉浏览器即将升级的是 WebSocket 协议,并通过Sec-WebSocket-Accept字段返回一个经过计算的值,用于确认服务器支持 WebSocket 协议。
3. HTML5 Web Socket API:
- 创建对象:var ws = new WebSocket(url,name);,其中url为 WebSocket 服务器的地址,name为发起握手的协议名称,为可选择项。
- 发送文本消息:ws.send(msg);,msg为文本消息,对于其他类型的数据可以通过二进制形式发送。
- 接收消息:ws.onmessage = (function(){...})();,通过该事件处理函数来处理接收到的消息。
- 错误处理:ws.onerror = (function(){...})();,用于处理 WebSocket 连接过程中发生的错误。
- 关闭连接:ws.close();,用于关闭 WebSocket 连接。
(十二)coap
COAP(Constrained Application Protocol)是一种适用于受限环境(如物联网设备)的应用层协议,与 HTTP 有一定的相似性,但也有其独特的特点。
- 与 HTTP 的比较:HTTP 与 COAP 协议都是通过 4 个请求方法(GET, PUT, POST, DELETE)对服务器端资源进行操作。两者之间明显的区别在于 HTTP 是通过文本描述方式描述协议包内容,协议包里面会包含一些空格符,换行符等,协议包可读性很强;而 COAP 是通过定义二进制各位段功能来描述协议包内容,因此 COAP 协议包大小更小,更紧凑,COAP 协议最小的协议包只有 4B,协议包需要经过解析后才能知道里面具体内容。
- coap 特点:
- 二进制通讯:采用二进制格式进行数据传输,提高了传输效率,减少了数据传输量。
- 请求与响应机制:对云端设备资源操作都是通过请求与响应机制来完成,类似 HTTP,设备端可通过 4 个请求方法(GET, PUT, POST, DELETE)对服务器端资源进行操作。
- 协议包轻量级:最小长度仅为 4B,非常适合资源受限的设备和低带宽网络环境。
- 支持可靠传输:具备数据重传和块传输机制,确保数据可靠到达,提高了通信的可靠性。
- 支持 IP 多播:即可以同时向多个设备发送请求,适用于需要向多个设备广播消息的场景。
- 非长连接通信:适用于低功耗物联网场景,减少了设备的功耗和资源占用。
- 协议结构:COAP 基于 UDP 之上,其协议结构如下: UDP--->Messages--->request/response--->payload
四、其他相关概念
- nb-iot:窄带物联网(Narrow Band Internet of Things),是一种专为物联网设计的低功耗广域网技术,具有覆盖广、连接多、速率低、成本低、功耗低、架构优等特点,主要用于连接使用无线蜂窝网络的各种设备和传感器。(此处可进一步展开介绍其技术原理、应用场景等内容)
- freertos:FreeRTOS 是一个迷你的实时操作系统内核,具有可裁剪、成本低、实时性高等特点,广泛应用于嵌入式系统开发中,为任务管理、内存管理、时间管理、通信机制等提供支持。(可补充其具体的功能模块和使用方法等内容)
- alios-things:AliOS Things 是阿里云面向物联网领域开发的操作系统,提供了丰富的物联网组件和服务,支持多种硬件平台,旨在帮助开发者快速开发物联网应用,实现设备的智能化连接和管理。(可详细介绍其架构、特点和优势等内容)
一些八股模拟拷打Point,万一有点用呢


查看3道真题和解析