基于tcp的应用层消息边界如何定义
聊聊基于tcp的应用层消息边界如何定义
背景
2018年笔者有幸接触一个项目要用到长连接实现云端到设备端消息推送，所以借机了解过相关的内容，最终是通过rabbitmq+mqtt实现了相关功能，同时在心里也打了一个问号“如果自己实现长连接框架，该怎么定义消息的边界呢？”，之后断断续续整理了一些，一直不成体系，最近放假了整理出来跟大家交流一番。
为什么需要消息边界
消息边界并非长连接场景才需要，即使是短连接也可能需要，拿我们比较常用的http1.0协议（http1.1稍微复杂一些，后面会单独说）来说，它基于tcp这个传输协议来传递消息，而tcp协议又是一个面向流的协议，怎么能识别出已经到了流的末尾呢？我们需要一种规则来定义消息的边界，告诉对方读取已经到了末尾，可以结束了。
举一个生活中的例子来帮助理解，2020年由于疫情的原因，平日里都是在线下会议室开会，特殊时期演变成了线上会议。不知道大家有没有遇到过这种情况，线下开会时通过观察别人的动作、神情很容易知道他说完了，这时候下一个人就可以接着发言了，但是线上开会时这样就行不通了，你如果想发言是不是得先确认下别人有没有说完，如果直接发言可能会打断别人，这样很不礼貌，为什么会出现这种情况呢？因为你不知道他到底有没有结束发言，更专业一点说你不知道是否到达了消息的边界。那怎么改进呢，如果每个人发言完毕都显示的告诉别人“我说完了”，是不是会好一些呢，“我说完了”这四个字就是一种消息的边界，给接收方传达一种消息结束的讯息。
TCP层面的分析
（本节来源于https://netty.io/wiki/user-guide-for-4.x.html#wiki-h3-10）
在基于流的传输（例如TCP / IP）中，将接收到的数据存储到套接字接收缓冲区中。不幸的是，基于流的传输的缓冲区不是数据包队列而是字节队列。这意味着，即使您将两个消息作为两个独立的数据包发送，操作系统也不会将它们视为两个消息，而只是一堆字节。因此，不能保证读取的内容与远端写的完全一样。例如，假设操作系统的TCP / IP栈已收到三个数据包：
由于是基于流的协议，因此很有可能在应用程序中读到以下四个分段：
因此，无论是服务器端还是客户端，接收方都应将接收到的数据整理到一个或多个有意义的帧中，以使应用程序逻辑易于理解。在上面的示例中，正确的数据应采用以下格式：
消息边界的种类
前面介绍了消息边界的定义以及作用，这一节我们来看看大概会有哪几种消息边界。
1.特殊字符：比如上面提到的“我说完了”这就是一种特殊字符作为消息边界的例子，以特殊字符为边界的典型产品有我们熟知的redis，客户端和服务器发送的命令或数据一律以 \r\n （CRLF）结尾，还有Netty中的DelimiterBasedFrameDecoder。
2.基于消息长度：比如约定了消息长度为4k字节，接收方每次读取4k字节以后就认为已到达消息边界，结束本次读取。当然现实中消息长度一般是变长的，这样就需要设计一个约定好的消息头部，将消息长度作为头部的一部分传输过去，以长度为边界的例子有Dubbo、http
、websocket，Netty中的FixedLengthFrameDecoder、LengthFieldBasedFrameDecoder等。
附上一张dubbo协议头，供大家体会
redis如何解析完整消息
上面说过，redis是通过\r\n来作为消息边界的，下面我将从源码角度分析下redis具体是如何处理的。
1.这里通过telnet来发送内联格式命令请求redis，之所以没有选用redis-cli是想模拟一条指令redis-server分多次收到的情况，在telnet模式下，每输入一个字符，就会发送给redis-server端，而redis-cli不是，它是按下回车时才会发送整体输入的命令，redis-server端是分多次还是一次收到完整的命令，这个取决于底层，如果想模拟分多次收到，这个过程较为复杂。
2.redis-server端每次有输入时会触发readQueryFromClient(networking.c)函数，对redis执行流程感兴趣的可以参考我之前的文章“redis源码学习之工作流程初探”。
3.redis-server将收到的内容暂存到redisClient的querybuf中，如果没有收到\r\n就等待，直到收到\r\n才将querybuf中的内容解析成指令执行。
测试步骤如下：
- telnet 中输入g
- debug查看redisClient中querybuf的值，目前只有g
- telnet中输完get a按回车以后，redisClient中querybuf保存了所有的输入get a \r\n
源码分析如下：
readQueryFromClient
void readQueryFromClient(aeEventLoop *el, int fd, void *privdata, int mask) { redisClient *c = (redisClient*) privdata; int nread, readlen; size_t qblen; REDIS_NOTUSED(el); REDIS_NOTUSED(mask); server.current_client = c; readlen = REDIS_IOBUF_LEN; /* If this is a multi bulk request, and we are processing a bulk reply * that is large enough, try to maximize the probability that the query * buffer contains exactly the SDS string representing the object, even * at the risk of requiring more read(2) calls. This way the function * processMultiBulkBuffer() can avoid copying buffers to create the * Redis Object representing the argument. */ if (c->reqtype == REDIS_REQ_MULTIBULK && c->multibulklen && c->bulklen != -1 && c->bulklen >= REDIS_MBULK_BIG_ARG) { int remaining = (int)((unsigned)(c->bulklen+2)-sdslen(c->querybuf)); if (remaining < readlen) readlen = remaining; } qblen = sdslen(c->querybuf); if (c->querybuf_peak < qblen) c->querybuf_peak = qblen; c->querybuf = sdsMakeRoomFor(c->querybuf, readlen); //从fd中读取内容，读取的内容存到redisClient的querybuf中 nread = read(fd, c->querybuf+qblen, readlen); if (nread == -1) { if (errno == EAGAIN) { nread = 0; } else { #ifdef _WIN32 redisLog(REDIS_VERBOSE, "Reading from client: %s",wsa_strerror(errno)); #else redisLog(REDIS_VERBOSE, "Reading from client: %s",strerror(errno)); #endif freeClient(c); return; } } else if (nread == 0) { redisLog(REDIS_VERBOSE, "Client closed connection"); freeClient(c); return; } #ifdef WIN32_IOCP aeWinReceiveDone(fd); #endif if (nread) { sdsIncrLen(c->querybuf,nread); c->lastinteraction = server.unixtime; if (c->flags & REDIS_MASTER) c->reploff += nread; } else { server.current_client = NULL; return; } if (sdslen(c->querybuf) > server.client_max_querybuf_len) { sds ci = getClientInfoString(c), bytes = sdsempty(); bytes = sdscatrepr(bytes,c->querybuf,64); redisLog(REDIS_WARNING,"Closing client that reached max query buffer length: %s (qbuf initial bytes: %s)", ci, bytes); sdsfree(ci); sdsfree(bytes); freeClient(c); return; } //正常的读取，继续执行processInputBuffer processInputBuffer(c); server.current_client = NULL; }
processInputBuffer
void processInputBuffer(redisClient *c) { /* Keep processing while there is something in the input buffer */ while(sdslen(c->querybuf)) { /* Immediately abort if the client is in the middle of something. */ if (c->flags & REDIS_BLOCKED) return; /* REDIS_CLOSE_AFTER_REPLY closes the connection once the reply is * written to the client. Make sure to not let the reply grow after * this flag has been set (i.e. don't process more commands). */ if (c->flags & REDIS_CLOSE_AFTER_REPLY) return; /* Determine request type when unknown. */ //判断协议类型，如果是*开头的就是redis的统一请求协议，否则就是内联协议 if (!c->reqtype) { if (c->querybuf[0] == '*') { c->reqtype = REDIS_REQ_MULTIBULK; } else { c->reqtype = REDIS_REQ_INLINE; } } //走内联协议的处理函数processInlineBuffer if (c->reqtype == REDIS_REQ_INLINE) { //如果命令不完整或者解析失败，不会执行命令 if (processInlineBuffer(c) != REDIS_OK) break; } else if (c->reqtype == REDIS_REQ_MULTIBULK) { if (processMultibulkBuffer(c) != REDIS_OK) break; } else { redisPanic("Unknown request type"); } /* Multibulk processing could see a <= 0 length. */ if (c->argc == 0) { resetClient(c); } else { /* Only reset the client when the command was executed. */ //命令解析完成，执行具体的命令对应的函数 if (processCommand(c) == REDIS_OK) resetClient(c); } } }
processInlineBuffer
int processInlineBuffer(redisClient *c) { char *newline; int argc, j; sds *argv, aux; size_t querylen; /* Search for end of line */ newline = strchr(c->querybuf,'\n'); /* Nothing to do without a \r\n */ //最后一个字符不是\n，返回REDIS_ERR，说明命令不完整，继续等待 if (newline == NULL) { if (sdslen(c->querybuf) > REDIS_INLINE_MAX_SIZE) { addReplyError(c,"Protocol error: too big inline request"); setProtocolError(c,0); } return REDIS_ERR; } /* Handle the \r\n case. */ //继续判断是否是以\r\n结尾的，如果是就截取\r\n前面的内容为参数 if (newline && newline != c->querybuf && *(newline-1) == '\r') newline--; /* Split the input buffer up to the \r\n */ querylen = newline-(c->querybuf); aux = sdsnewlen(c->querybuf,querylen); argv = sdssplitargs(aux,&argc); sdsfree(aux); if (argv == NULL) { addReplyError(c,"Protocol error: unbalanced quotes in request"); setProtocolError(c,0); return REDIS_ERR; } /* Newline from slaves can be used to refresh the last ACK time. * This is useful for a slave to ping back while loading a big * RDB file. */ if (querylen == 0 && c->flags & REDIS_SLAVE) c->repl_ack_time = server.unixtime; /* Leave data after the first line of the query in the buffer */ sdsrange(c->querybuf,querylen+2,-1); /* Setup argv array on client structure */ if (c->argv) zfree(c->argv); c->argv = zmalloc(sizeof(robj*)*argc); /* Create redis objects for all arguments. */ for (c->argc = 0, j = 0; j < argc; j++) { if (sdslen(argv[j])) { c->argv[c->argc] = createObject(REDIS_STRING,argv[j]); c->argc++; } else { sdsfree(argv[j]); } } zfree(argv); return REDIS_OK; }
Netty FixedLengthFrameDecoder、LengthFieldBasedFrameDecoder如何解析完整消息
有兴趣的小伙伴可以看看FixedLengthFrameDecoder、LengthFieldBasedFrameDecoder源码的java doc说明，里面讲的比较详细，在此不再重复。
总结
网络上其他作者将这类问题称之为TCP“粘包”和“拆包”，与本文提到的消息边界本质上没有太多区别，之所以没有继续叫“拆包”是不想把概念复杂化，回到本质其实就是需要一种机制来定义消息的边界，帮助应用层来正确的解析消息。
通过redis源码的简单分析，大体可以得到解决这类问题的关键点有以下两步：
1.需要一种边界的定义，基于特殊字符、基于长度等；
2.消息接收端需要暂存收到的内容，不到边界时等待，直到符合边界条件（收到了特殊字符或者收到的字节数达到约定的长度）。
虽说不是一个高大上的知识点，但是通过查资料和阅读源码也解决了心中的困惑，过程中通过发散式的学习也了解到Netty框架针对这类问题的解决方案，算是对Netty的认识又深入了一点。
