应用协议学习

CMUX

是一种串口通信协议,意思是串口的多路复用

说人话就是通过虚拟出串口，把一个串口的数据发到多个客户端

帧

  • 解决了什么问题？
    实际的应用中，一个物理串口某一时间段内只能传输一个上层应用的数据流，如果有多个数据流同时要发送怎么办?使用CMUX！

  • 应用场景是什么？
    TE和MS中间！TE就是终端设备，运行应用程序提供界面的。MS是移动站，具有调制解调器可进行无线通讯！

  • 物理实现是怎么样的？
    多路复用是一个层，这个层将底层的物理串口连接用于收发数据，并为上层提供了多个逻辑上独立的收发通道，每个通道就是一个DLC链路。TE端的MUX主动发起通道建立请求，并设置通道参数，而MS端的MUX则等待TE端的服务请求，并根据自身能力提供相应的服务。

  • 帧是什么？
    帧类型包括控制帧和信息帧。
    控制帧用于建立、拆除虚拟链路，包括SABM命令（建立DLC）、UA响应（确认响应SABM DISC）、DM响应（建立失败后响应DISC）和DISC命令（通知对端拆除DLC），在DLC0发送DISC，相当于关闭cmux。
    信息帧用于传输数据，包括UIH命令和响应、UI命令和响应。

SABM 把指定的一端设为ABM（异步平衡模式），另一端接收后回UA，并把DLC发送接收状态置零。

+什么是异步平衡模式？
控制帧只有一字节

UIH发送不带V(S) V(R)也就是不带发送接收序列号，只计算地址域、控制域和长度域的FCS，FCS是帧校验序列。

  • UI和UIH有什么不同？
    UI帧也是携带数据的信息帧，但它不带有标头检查。与UIH帧不同的是，UI帧的完整性对所有域（地址域、控制域、长度域和信息域）进行计算。

简单来说，UIH帧在传输过程中只对一部分字段进行完整性检验，而UI帧对所有字段进行完整性检验。在使用UIH和UI帧时，需要根据具体需求选择合适的帧类型。

帧结构

image

  1. 标志域

位于开始和结束，0xF9普通模式，0x7E为高级模式，高级模式可以带错误恢复功能

  1. 地址域

image
63 条通道是因为3--8一共六位，0--63

  1. 控制域
    image

  2. 信息域
    只有UI帧、UIH帧才有

  3. 长度域
    image
    同地址域的第一位，1代表是长度域，0表示后续还有个字节

  4. 校验域

看不懂

实操

N725为例

待更新，目前还没找NEOWAY_CMUX软件/。。

TCP

传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议。

演进流程

对于A发给B

  1. UDP不可靠，如果A发送的包丢了，B一脸懵逼

  2. 咋解决呢？让B收到后给A发个ack确认呗！如果A一定时间内没收到确认，就重发啊！

这就是停止等待协议

  1. A寻思，要等待上个包确认才能发，那效率好低，于是出现了流水线式发送，也就是不必收到确认，直接发。

  2. 但是实际的场景中，并不一定是先发的先到，这就会导致ACK乱了套了，收到的第一个ACK可能是第五个包的回应
    怎么办呢？ 加序号啊！

  3. A发送的时候加个seq序号，B回应ACK也加个序号，注意，这个序号实际上是收到的seq+1，这是协议规定
    这个序号有个偷懒的方法，就是收到 seq = 3 的ack，实际上表示seq = 1 和 seq = 2 两个都收到了

  4. 看似没有问题了吧，但是实际中，AB的接受能力不一定一样啊！A发了一百个，B累死累活才接收5个，这咋办？
    AB给对方发包，顺带一个窗口大小的值即可，每次都会带，所以是可更新的

假设B窗口大小为5，
image

  1. 有没有可能，其实是网络不好，错怪了B呢?

那就要A自己试可行的窗口大小了，毕竟网络环境不会直接告诉你
image

当A发给B时，他要选择，网络造成的和B接受能力造成的窗口最小值

  1. 三次握手，四次挥手

**A：我准备好了 SYN
B: 收到 ACK，我也准备好了 SYN
A: 收到 ACK **

**A：我要走了 FIN
B: 收到 ACK ,我还有点事没处理完
B：我处理完了，我也要走了 FIN
A: 收到 ACK **

image

  1. 帧结构
    image

TCP报文的结构如下：
源端口号（Source Port）：用于标识发送方的应用程序的端口号。
目的端口号（Destination Port）：用于标识接收方的应用程序的端口号。
序列号（Sequence Number）：用于标识发送的数据流中的每个字节的位置。
确认号（Acknowledgment Number）：用于确认收到的数据流中的下一个字节的位置。
数据偏移（Data Offset）：表示TCP头部的长度，以4字节为单位。
保留（Reserved）：保留字段，用于将来的扩展。
控制位（Flags）：用于标识TCP报文的各种控制信息，如SYN、ACK、FIN等。
窗口大小（Window Size）：表示发送方的接收窗口大小，用于流量控制。
校验和（Checksum）：用于检验TCP头部和数据的完整性。
紧急指针（Urgent Pointer）：用于标识紧急数据的位置。
选项（Options）：可选的TCP扩展选项，如最大段大小、时间戳等。
填充（Padding）：用于填充TCP头部，使其长度为4的倍数。

下面对TCP报文的各个部分进行详细说明：

  1. 端口号：TCP使用端口号来标识不同的应用程序。源端口号标识发送方的应用程序，目的端口号标识接收方的应用程序。

  2. 序列号：TCP通过序列号来标识数据流中每个字节的位置。接收方通过确认号来告知发送方已经成功接收到哪些字节。

  3. 数据偏移：TCP头部的长度是可变的，通过数据偏移字段来指示TCP头部的长度，以4字节为单位。TCP头部最小长度为20字节。

  4. 控制位：TCP报文的控制位用于标识各种控制信息，如SYN用于建立连接，ACK用于确认，FIN用于关闭连接等。

  5. 窗口大小：窗口大小用于流量控制，表示发送方的接收窗口大小。窗口大小是一个16位字段，表示可以接收的字节数。

  6. 校验和：TCP头部和数据的校验和用于检验报文的完整性。接收方在收到报文后会计算校验和，如果校验和不匹配，则认为报文存在损坏。

  7. 紧急指针：紧急指针用于标识紧急数据的位置。紧急数据通常是指需要优先处理的数据。

  8. 选项：TCP头部中可以包含一些可选的选项字段，用于进行各种扩展。常见的选项包括最大段大小、时间戳等。

UDP

UDP提供不可靠服务，优势是开销小

UDP是面向报文的，对应用层交下来的报文，添加首部后直接交付到IP层，既不合并，也不拆分，保留这些报文的边界。对IP层交上来UDP用户数据报，在去除首部后就原封不动地交付给上层应用进程，报文不可分割，是UDP数据报处理的最小单位。

  • TCP首部20字节，UDP首部8字节

源端口号：占用2个字节，表示发送端的端口号。
目标端口号：占用2个字节，表示接收端的端口号。
长度：占用2个字节，表示UDP数据报文的长度，包括头部和数据部分。
校验和：占用2个字节，用于检测UDP数据报文在传输过程中是否发生错误。
数据：占用剩余的字节，表示实际要传输的数据。

校验和可选，源端口不想校验就全填0。
计算校验时，需要在UDP数据报之前增加12字节的伪首部，只是在计算校验和，临时添加在UDP数据报的前面。伪首部既不向下传送也不向上递交，而仅仅是为了计算校验和。既检查了UDP数据报，又对IP数据报的源IP地址和目的IP地址进行了检验。

UDP的校验和是一种简单的校验机制，校验和的计算方法如下：

  1. 将UDP数据报分成若干16位(2字节)的字节对，若不是偶数就填0（例如，如果数据报有20字节，则有10个字节对）。
  2. 将每个字节对相加，并将结果存储在一个16位的变量中。
  3. 如果相加的结果超过了16位的最大值（65535），则-65535重新开始。
  4. 最后，将结果按位取反，得到校验和的值。
  5. 将校验和的值添加到UDP数据报的头部中的校验和字段。

校验不通过也可以发给上层，但需要附上错误信息

  • UDP灵活性很差，当使用UDP进行通信时，一次发送数据会将整个数据报发送出去，而接收端也需要一次性接收整个数据报。
    如果需要分段传输或者循环接受等，考虑在应用层处理或者选TCP

  • UDP通信是建立在两个主机之间的，通过两个主机之间的端口进行通信。端口号是用来识别应用程序的！！！如果目的端口没有应用程序，就丢弃报文，通过ICMP发送错误给对方主机！！！

FTP

ftp工作于应用层，基于传输层的TCP

双重链接

FTP客户端和服务端之间的连接是双重的，具体解释如下：

  1. 双重连接：FTP使用了两个独立的连接，可同时链接。控制连接用于传输控制命令和响应，而数据连接则用于传输实际的数据文件。

  2. 控制连接：客户端每次调用FTP服务端，都会建立一个控制连接的会话。通过控制连接，客户端可以发送命令给FTP服务端，如登录、目录浏览、文件上传下载等。FTP客户端发送命令后，服务端会响应相应的结果。

  3. 数据连接：当客户端需要传输数据文件时，会与FTP服务端建立一个数据连接的会话。数据连接的建立可以通过主动模式或被动模式来实现。在数据连接建立后，实际的数据文件会通过数据连接进行传输

主动模式 被动模式

主动被动是相对服务端、数据连接而言的，控制连接肯定是服务端被动的

使用场景

  1. 服务端性能不好，被动
  2. 服务端可能不支持主动，采用被动；不支持被动就采用主动
  3. 客户端有防火墙，服务端的数据连接被墙了，被动
  4. 客户端是私有IP，有NAT且没有应用层网关，被动，有应用层网关，主动，因为应用层网关可以把映射的公有IP解析成私有

NAT是把私有IP转公有的方式，只是假转换，私有IP可以重复因为局域网隔开了，公有不可以，虽然NAT了但客户端还是内部保密的

建立连接过程

控制连接，肯定是客户端主动，服务端被动！！！！！！所有的指令双方指的都是两个控制进程（一进程一端口）间！！！！

  1. 客户端启动控制进程，打开一个本地端口，使用TCP连接到服务端的FTP控制端口（通常是21），建立控制连接
  2. 服务端主进程收到请求，派生出一个控制进程，和客户端建立链接
  3. 二者通过控制进程校验用户名密码等
  4. 客户端想发数据了！！命令pasv给服务端
  5. 服务端收到！！派生出另一个进程叫数据进程，把这个进程所在的端口告诉客户端！！！
  6. 客户端收到！！也派生一个数据进程，链接对方数据进程的端口号，进行传输！！
  7. 传输完毕后俩数据进程都关闭，如果后面没事儿了，俩控制进程也关了

上述是被动模式，也就是服务端是受，客户端是攻，如果主动模式，只需把456换为：客户端派进程发端口，服务端派进程发端口 客户端发数据即可

传输方式等

  1. 传输方式
    流模式：以连续的流式传输数据，适用于文本文件和ASCII码文件。
    块模式：将数据分割为固定大小的块进行传输，适用于二进制文件和大型文件。
    压缩模式：在传输之前对数据进行压缩，以减少传输时间和带宽占用。

  2. 数据结构
    文件结构（File Structure）：将文件作为一个整体进行传输。
    记录结构（Record Structure）：将文件按记录进行划分传输。
    页结构（Page Structure）：将文件按页进行划分传输。

  3. 文件类型
    NVT ASCII码：一种规定了字符编码和控制字符的ASCII码，用于在网络上传输文本文件。
    EBCDIC：一种用于字符编码的二进制编码系统。在EBCDIC系统中，需要同时在客户端和服务端都使用EBCDIC系统才能正确传输文件。
    图像文件：这指的是包括图像、音频、视频等二进制文件。在传输图像文件时，数据会以连续的比特流的形式发送。
    Local模式：在Local模式下，客户端和服务端之间会进行协商，根据本地系统的特性和要求来确定传输方式。

HTTP

超文本传输协议，位于应用层，客户端发起一个HTTP请求到服务器上指定端口（默认端口为80）

工作原理

客户端发送请求：当用户在浏览器中输入网址或点击链接时，浏览器充当客户端，向服务器发送HTTP请求。请求中包含了请求的方法（例如GET、POST）、目标URL、HTTP版本等信息。

服务器响应请求：服务器接收到客户端的请求后，根据请求的内容进行处理。服务器会解析请求头信息，确定请求的资源，同时生成相应的响应。

服务器返回响应：服务器通过HTTP响应发送回客户端。响应包含了HTTP状态码（例如200表示成功，404表示资源不存在）、响应头和响应体等信息。

客户端接收响应：浏览器（客户端）接收到服务器发送的HTTP响应后，会解析响应头信息。根据响应头中的内容，浏览器可能会执行不同的操作，例如渲染网页、下载文件等。

客户端显示响应内容：浏览器根据响应体中的数据，将网页的HTML、CSS和JavaScript解析并渲染，最终呈现给用户

HTTP本来是无状态的，比如我把淘宝的A商品收藏了，然后收藏了B，收藏B时服务端已经忘了我收藏过A，为了解决可以用cookie

请求方法

均为客户端请求服务端的！！！

  1. get
    向指定的资源发出“显示”请求
  2. post
    向指定资源提交数据，请求服务器进行处理（例如提交表单或者上传文件）
  3. head
    同get，但只返回元信息，如响应头
  4. put
    向指定资源位置上传其最新内容
  5. delete
    请求服务器删除Request-URI所标识的资源。
  6. trace
    回显服务器收到的请求，主要用于测试
  7. options
    使服务器传回该资源所支持的所有HTTP请求方法
  8. connect
    建立与目标资源的双向链接

要写一个httpserver，至少要实现get和head

GET提交的数据会放在URL之后，也就是请求行里面，如EditBook?name=test1&id=123456.（请求头里面那个content-type做的这种参数形式，后面讲） POST方法是把提交的数据放在HTTP包的请求体中.

GET提交的数据大小有限制（因为浏览器对URL的长度有限制），而POST方法提交的数据没有限制.

状态码

1xx消息——请求已被服务器接收，继续处理
2xx成功——请求已成功被服务器接收、理解、并接受
3xx重定向——需要后续操作才能完成这一请求
4xx请求错误——请求含有词法错误或者无法被执行
5xx服务器错误——服务器在处理某个正确请求时发生错误3

报文结构

image

MQTT

位于应用层
image
图中可以看出，三个身份，发布者订阅者都是客户端，代理是服务端，发布订阅可以是同一个客户端

  • 消息类型分为主题和内容
  • 订阅者订阅主题topic后，会收到内容playload

客户端与服务端

  1. 客户端 发送、订阅、退订消息；主动连接或断开服务器
  2. 服务端 接收发送的消息、推送消息、处理订阅退订、接收客户端的连接请求

订阅与主题

  1. 订阅包括主题筛选器和Qos，一个会话（客户端与服务端的连接）多个订阅，一个订阅只属于一个会话

  2. 会话可以跨越多个网络连接，说人话就是在家用wifi，出门用流量，不会中断

方法

（1）Connect。等待与服务器建立连接。

（2）Disconnect。等待MQTT客户端完成所做的工作，并与服务器断开TCP/IP会话。

（3）Subscribe。等待完成订阅。

（4）UnSubscribe。等待服务器取消客户端的一个或多个topics订阅。

（5）Publish。MQTT客户端发送消息请求，发送完成后返回应用程序线程。

报文结构

  1. 固定头

必定有，两字节

  • 第一字节，7--4位是数据包类型(比如这个包是客户到服务器用于发布的)，3--0位是不同类型数据包的具体标识

  • 第二字节是可拓展的，通常是保存后面两部分的总大小，不直接保存，前七位保存最后一位1表示不够，再开一个字节

  1. 可变头

可以没有，通常是报文的特定属性和参数

  1. 消息体

一般都有

posted @ 2023-09-11 14:44  __Zed  阅读(253)  评论(2)    收藏  举报