TCP新手误区--粘包的处理

TCP新手误区–粘包的处理

背景

最近面试了很多的学生，发现很多TCP的新手对于TCP的使用有一些误区，而这些坑也是当初我曾经疑惑过得地方。网上很少有文章对这些问题有过详细的解析，即是有也只是直接给出结论和做法，没有人将其中的来龙去脉讲解清楚，所以我将这些问题的来龙去脉在这一系列的文章中讲述出来，希望能让广大TCP的新手避开这些坑。

问题

我面试时经常会问的一个问题是当TCP两端A、B建立了连接后，A端先发送100个字节，再发送100个字节。那么B端会分别收到两次100字节吗？
答案是不一定会，但是只有少数人能够正确的回答这个问题。如果能回答上这个问题那么我会接着问那么对于这种情况应该怎样处理才能正确的按照发送端发送的长度收到数据。能完美回答出这个问题的人就更少了。

原因

我们常说TCP是一种流式连接，这个流字到底怎么理解？它是指TCP的数据传输就像一种水流一样，并不区分不同数据包之间的界限。
就像我们打开水龙头后，水流自然的流出，我们并不知道背后水泵是分了几次将水供上来的。

缓存发送

其实仔细看过TCP协议内容的人就可以发现，TCP协议允许发送端将几次发送的数据包缓存起来合成一个数据包发送到网络上去，因为这样可以获得更高的效率，这一行为通常是在操作系统提供的SOCKET中实现，所以在应用层对此毫无所觉。
所以我们在程序中调用SOCKET的send发送了数据后操作系统有可能缓存了起来，等待后续的数据一起发送，而不是立即发送出去。send的文档中对此也有说明。

分包发送

网络传输的概念中有MTU的概念，也即是网络中一个数据包最大的长度。如果要发送超过这个长度的数据包，就需要分包发送。当调用SOCKET的send发送超过MTU的数据包时，操作系统提供的SOCKET实现会自动将这个数据包分割成几个不超过MTU的数据包发送。

当出现这些上面这些情况的时候，接收端就会发现接收到的数据和发送的数据的次数不一致。这个就是粘包现象。

解决

当我们传输如文件这种数据时，流式的传输非常适合，但是当我们传输指令之类的数据结构时，流式模型就有一个问题：无法知道指令的结束。所以粘包必须问题是必须解决的。

短连接

最简单的方法就是短连接，也就是需要发送数据的时候建立TCP连接，发送完一个数据包后就断开TCP连接，这样接收端自然就知道数据结束了。
但是这样的方法因为会多次建立TCP连接，性能低下。随便用用还可以，只要稍微对性能有一点追求的人就不会使用这种方法。

长连接

使用长连接能够获得更好的性能但不可避免的会遇到如何判断数据结构的开始与结束的问题。
而此时的处理方式根据数据结构的类型分两种方式。

定长结构

因为粘包问题的存在，接收端不能想当然的以为发送端一次发送了多少数据就能一次收到多少数据。如果发送端发送了一个固定长度的数据结构，接收端必须每次都严格判断接收到额数据的长度，当收到的数据长度不足时，需要再次接收数据，直到满足长度，当收到的数据多于固定长度时，需要截断数据，并将多余的数据缓存起来，视为长度不足需要再次接收处理。

不定长结构

定长的数据结构是一种理想的情况，真正的应用中通常使用的都是不定长的数据结构。
对于发送不定长的数据结构，简单的做法就是选一个固定的字符作为数据包结束标志，接收到这个字符就代表一个数据包传输完成了。
但是这只能应用于字符数据，因为二进制数据中很难确定结束字符到底是结束还是原本要传输的数据内容（使用字符来标识数据的边界在传输二进制数据时时可以实现的，只是实现比较复杂和低效。想了解可以参考以太网传输协议）。
目前最通用的做法是在每次发送的数据的固定偏移位置写入数据包的长度。
接收端只要一开始读取固定偏移的数据就可以知道这个数据包的长度，接下来的流程就和固定长度数据结构的处理流程类似。

所以对于处理粘包的关键在于提前获取到数据包的长度，无论这个长度是提前商定好的还是写在在数据包的开头。
因为在每次发送的数据的固定偏移位置写入数据包的长度的方法是最通用的一种方法，所以对这种方法实现中的一些容易出错误的地方在此特别说明。

• 通常我们使用2~4个字节来存放数据长度，多字节数据的网络传输需要注意字节序，所以要注意接受者和发送者要使用相同的字节序来解析数据长度。
• 每次新开始接收一段数据时不要急着直接去解析数据长度，先确保目前收到的数据已经足够解析出数据长度，例如数据开头的2个字节存储了数据长度，那么一定确保接收了2个字节以上的数据后才去解析数据长度。
  
  • 如果没做到这一点的服务器代码，收到了一个字节就去解析数据长度的，结果得到的长度是内存中的随机值，结果必然是崩溃的
• 有些非法客户端或者有bug的客户端可能会发出错误的数据，导致解析出的数据长度异常的大，一定要对解析出的数据长度做检查，事先规定一个合适的长度，一旦超过果断关闭SOCKET，避免服务器无休止的等待下去浪费资源。
  
  • 不要妄想说自己写的客户端不会出错，哪怕客户端不出错，只要其他任何一个使用TCP的客户端写错了端口，也足以让你崩溃，毕竟管得了自己管不了别人
• 处理完一个完整的数据包后一定检查是否还有未处理的数据，如果有的话要对这段多余的数据再次开始解析数据长度的过程。不要忙着去继续接受数据。
  
  • 这应该是最常犯的一个错误，很多人以为完整的处理了一个数据包后就万事大吉，可以重新开始处理流程，但是别忘了，收到的数据有可能带着下一个数据包的数据，别把他们忘掉

总结

TCP中的粘包的处理应该是任何一个网络编程人员都必须掌握的技能，但是很多被面试者向我表示从未听说过粘包问题。面试者如果对粘包问题没有任何的了解那么就谈不上所谓的精通、掌握SOCKET编程。所以我写这篇文章希望面试者能够深入理解TCP的原理，掌握粘包问题，能够取得更好的面试结果。