1、小故事与前言

最近返校做毕业设计，嵌入式和服务器需要敲定一个通信协议。

我问："服务端选什么协议，MQTT或者Websocket？"

他来句："TCP"

我又确认了一遍："用什么通信协议？"

他又来了句："TCP"

给我气笑了。最后在我的坚持下，他才勉强以他啥都能做，以我为准的理由妥协了。

简单回想盘点下问题：

1. TCP如何处理消息半包，粘包
2. TCP如何确认应用状态
3. TCP如何处理服务认证问题

他的回答：

1. 消息发送，服务端加个标识字符检验，进行数据帧分割
2. 发个心跳包

2、TCP与应用层协议

TCP位于传输层，而这位大哥想做的就是基于Socket去完成网络消息传输。（Socket本身并不是协议，而是一个调用接口，通过Socket，我们才能使用TCP/IP协议）

MQTT，Websocket属于应用层协议，基于TCP。

一.消息半包、粘包

①介绍

首先，如果你使用过Java的原生Socket API，并进行过实验，你就能知道Socket是无法处理半包与粘包的。

什么是半包与粘包？可以参考我的Netty进阶文章

②演示

测试演示：

服务端代码：

缩小服务端的接收缓冲区为20字节，客户端10次发送"abc"数据。

请不要拿readUTF方法进行测试，sendUTF与readUTF是配套使用的，jdk原生进行了半包粘包的处理，对于发送消息添加了额外的消息用于处理问题。

如readLine等方法都是基于特定条件的处理了半包粘包问题（如本方法为换行划分一个消息帧），不适用于通用消息的网络传输。

import java.io.DataInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.net.InetSocketAddress;
import java.net.ServerSocket;
import java.net.Socket;

/**
 * @author  zko0
 * @date  2023/3/5 0:02
 * @description
 */
public class SimpleSocketServer {
     public static void main(String[] args) {
          DataInputStream dataInputStream=null;
          ServerSocket serverSocket=null;
          Socket accept=null;
          try {
               serverSocket= new ServerSocket(8081);
               System.out.println("socket服务创建");
               //accept
               accept = serverSocket.accept();
               System.out.println("client连接");
               //只设置接收缓冲区大小
               accept.setReceiveBufferSize(10);
               InputStream inputStream = accept.getInputStream();
               dataInputStream= new DataInputStream(inputStream);
               while (true){
                    //创建byte数组用于接收数据
                    byte[] bytes=new byte[10];
                    dataInputStream.read(bytes);
                    System.out.println(new String(bytes));
               }
          } catch (IOException e) {
               e.printStackTrace();
          }finally {
               try {
                    if (dataInputStream!=null)dataInputStream.close();
                    if (serverSocket!=null)serverSocket.close();
                    if (accept!=null)accept.close();
               } catch (IOException e) {
                    e.printStackTrace();
               }
          }
     }
}

客户端代码：

public class SimpleSocketClient {
    public static void main(String[] args) {
        Socket socket =null;
        DataOutputStream dataOutputStream=null;
        try{
            socket=new Socket("127.0.0.1", 8081);
            System.out.println("socket连接");
            OutputStream outputStream= socket.getOutputStream();
            dataOutputStream= new DataOutputStream(outputStream);
            for (int i = 0; i < 10; i++) {
                dataOutputStream.writeBytes("abc");
            }
            dataOutputStream.flush();
            while (true);
        }catch (IOException e) {
            e.printStackTrace();
        }
    }
}

测试结果：

如下图所示，Server接收Client消息存在着半包粘包问题，一次消息abc无法被完整接收，在服务端第一次接收到了a，第二次接收到了bc+abc+ab一次完整+两次一半的消息。

很明显，如果服务端直接通过获取的消息进行处理，是存在问题的，对于TCP消息，需要进行半包和粘包的处理，才能使用消息。

③问题解决

正如那位“高含金量选手”所说，要对半包粘包进行处理。但是这种处理不仅仅是直接使用标识符就可以的，对于多出的额外信息或者不足的消息，是需要保留来拼凑出完整消息的。这部分你可以参考一下Java中readLine()方法

解决方式：

1. 使用标识符进行消息帧分割

   这种方式只适用于特定场景，因为在发送的消息中如果存在你的标识符，那么在进行帧解码的时候，就会将这部分内容作为标识符将字符串分割。由于分割位置错误，一次消息你可能会得到分割后的多个错误消息。

   就比如readLine()使用于读取一行数据。

2. 使用短连接

   这种方式可以解决粘包的问题，但是无法解决半包问题。因为一次发送后，连接就会中断。那么Server获取的数据只会小于单次发送的数据。

3. 定长帧解码器

   在发送数据中，定义协议。如设置前5个字节代表发送数据的长度。

   如果发送abc三字节内容，发送数据为：0 0 0 0 3 97 98 99

   服务器读取前5个字节，就知道需要再读取3字节内容，为一次完整数据。如果单次只读取了2字节，那么会等待1个字节内容，拼凑出最后的3字节，单次完整消息。

   你可以参考readUTF()方法，思路相同。

二.心跳

如果你了解TCP，你就会知道TCP协议是自带心跳的。

KEEP_ALIVE
在TCP协议里，本身的心跳包机制SO_KEEPALIVE，系统默认设置的是7200秒的启动时间，默认是关闭的。

有三个参数可以设置：p_keepalive_time、tcp_keepalive_probes、tcp_keepalive_intvl

分别表示连接闲置多久才开始发心跳包、连发几次心跳包没有回应表示连接已断开、心跳包之间间隔时间。

但是众所周知，几乎所有基于TCP协议的应用层协议，都自定义了心跳报文：如WebSocket，MQTT

Socket中Client关闭，Server能自动感受到连接断开啊？：

当SocketClient应用关闭，系统调用Socket的close、或者进程结束。操作系统会发送FIN数据包给服务器，所以Sevrer能够关闭TCP连接。

如果你在Client运行中，拔掉网线或者关闭电源。这时Client是没有机会发送FIN数据包的，这时Server就无法感知到Client已经断开了连接。

为什么TCP自带心跳还需要应用层定义心跳：

1. TCP心跳机制是传输层实现的，只要当前连接是可用的，对端就会ACK我们的心跳，而对于当前对端应用是否能正常提供服务，TCP层的心跳机制是无法获知的。
2. tcp_keepalive_time参数的设置是秒级，对于极端情况，我们可能想在毫秒级就检测到连接的状态，这个TCP心跳机制就无法办到
3. 通用性，应用层心跳功能不依赖于传输层协议，如果有一天我们想将传输层协议由TCP改为UDP，那么传输层不提供心跳机制了，应用层的心跳是通用的，此时或许只用修改少量地方代码即可；
4. 如果连接中存在Sock Proxy或者NAT，他们可能不会处理TCP的Keep Alive包

三.应用报文

这部分比较偏向应用层内容，仅为个人感想。

在应用层协议中，协议报文都是对应用每个功能定制，且缩小了数据量的。

以MQTT3.1举例

MQTT第一次报文为CONNETCT报文。在一个网络连接上，客户端只能发送一次CONNECT报文。服务端必须将客户端发送的第二个CONNECT报文当作协议违规处理并断开客户端的连接 。

报文内容：

1. 固定头：1--->确定了报文的类型：CONNECT

2. 可变头：

   • 第6位：用户名标志 User Name Flag
   • 第7位：密码标志 Password Flag

3. 有效载荷：CONNECT报文的有效载荷（payload）包含一个或多个以长度为前缀的字段，可变报头中的标志决定是否包含这些字段。如果包含的话，必须按这个顺序出现：客户端标识符，遗嘱主题，遗嘱消息，用户名，密码。

仅仅是一个客户端连接报文，就设计的非常全面且优雅，且完全契合应用目的。

3、小结

个人思考后，个人认为将应用层协议分为通用协议与特定系统协议俩种。

通用协议：如HTTP协议，Websocket，MQTT协议，搭载用户自定义数据体进行通讯

特定系统协议：如Mysql协议，Redis的RESP协议，都是基于特定应用自己开发的一套网络协议

对于应用开发，个人认为通用协议更为合理，不仅进行了上述众多问题的处理。而且还有对应协议的应用意义：如身份验证等。

实在难以想象那种代码水平是否能将Socket自定义协议与消息处理写出基本的骨架出来。希望技术人员专注于技术，共同进步，不要盲目自大。

如果你有较好思考，欢迎指点。