背景

最近面试了很多的学生，发现很多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的原理，掌握粘包问题，能够取得更好的面试结果。

TCP新手误区–粘包的处理相关推荐

TCP和UDP 粘包消息保护边界
在socket网络程序中,TCP和UDP分别是面向连接和非面向连接的.因此TCP的socket编程,收发两端(客户端和服务器端)都要有一一成对的socket,因此,发送端为了将多个发往接收端的包,更有 ...
计网 - TCP 的封包格式：TCP 为什么要粘包和拆包？
文章目录 Pre TCP 的拆包和粘包 TCP数据发送 TCP Segment Sequence Number 和 Acknowledgement Number MSS(Maximun Segment ...
Python3之socket编程（TCP/UDP，粘包问题，数据传输、文件上传）
一.socket的定义 Socket是应用层与TCP/IP协议族通信的中间软件抽象层,它是一组接口.在设计模式中,Socket其实就是一个门面模式,它把复杂的TCP/IP协议族隐藏在Socket接口后 ...
Netty(三) 什么是 TCP 拆、粘包？如何解决？
前言记得前段时间我们生产上的一个网关出现了故障. 这个网关逻辑非常简单,就是接收客户端的请求然后解析报文最后发送短信. 但这个请求并不是常见的 HTTP ,而是利用 Netty 自定义的协议. 有个 ...
python串口数据分包_python TCP Socket的粘包和分包的处理详解
概述在进行TCP Socket开发时,都需要处理数据包粘包和分包的情况.本文详细讲解解决该问题的步骤.使用的语言是Python.实际上解决该问题很简单,在应用层下,定义一个协议:消息头部+消息长度+ ...
tcp业务层粘包和半包理解及处理
tcp粘包处理 tcp是流式传输的,是安全的, 可靠的,顺序的. udp是数据报协议,是不可靠的. 面试中经常被问到tcp粘包是如何处理的,通过百度和自己的理解,这里做笔记记录. 如果有不对,请指正~ ...
解决TCP网络传输“粘包”问题
当前在网络传输应用中,广泛采用的是TCP/IP通信协议及其标准的socket应用开发编程接口(API).TCP/IP传输层有两个并列的协议:TCP和UDP.其中TCP(transport contro ...
TCP通讯处理粘包详解
一般所谓的TCP粘包是在一次接收数据不能完全地体现一个完整的消息数据.TCP通讯为何存在粘包呢?主要原因是TCP是以流的方式来处理数据,再加上网络上MTU的往往小于在应用处理的消息数据,所以就会引发一 ...
tcp协议与粘包现象【转http://www.cnblogs.com/wzd24/archive/2007/12/24/1011932.html】
Socket开发之通讯协议及处理在Socket应用开发中,还有一个话题是讨论的比较多的,那就是数据接收后如何处理的问题.这也是一个令刚接触Socket开发的人很头疼的问题. 因为Socket的TCP ...
UNIX网络编程——解决TCP网络传输“粘包”问题
当前在网络传输应用中,广泛采用的是TCP/IP通信协议及其标准的socket应用开发编程接口(API).TCP/IP传输层有两个并列的协议:TCP和UDP.其中TCP(transport ...

TCP新手误区–粘包的处理

背景

问题

原因

缓存发送

分包发送

解决

短连接

长连接

定长结构

不定长结构

总结

TCP新手误区–粘包的处理相关推荐

最新文章

热门文章