粘包问题及解决

1>先模拟ssh，编写一个远程执行命令的程序

    其实也就是客户端输入命令，再由服务端执行并返回结果的一个过程，基于之前的简单通信脚本，改一下，如下

    当服务端收取命令之后，用subpcocess模块执行命令，并且把执行结果返回给客户端，客户端解码展示，客户端

    的代码及执行结果如下

2>粘包问题

    客户端更改接收字符串位数的上限，200，并且再传递一个新的命令，如‘查看C盘的文件’，但是注意返回结果，并不是当     前命令的结果，而是上一条命令的剩余部分！

理解TCP也称‘流式协议’，其实这个问题也很好理解，因服务端这边给客户端发送的数据肯定超过200字节，

而客户端这边这一次只收取200字节，所以，没取完的剩余部分依然存留在IO缓冲区（也可以理解为服务端

通往客户端的管道）里，等到客户端下一次来取值，所以，客户端再发送另外一个命令，服务端这边执行并把

新的结果再从管道传送给客户端，客户端取值就从上次的剩余部分开始了。

这就是-------粘包现象

粘包问题只存在于TCP，not UDP

3>粘包问题解析

    看一下客户端的‘粘包现象’，进行TCP协议通信时，，会启用

    一种优化方法（Nagle算法），将数据量小且发送间隔小的数据包合并成一个大的数据包发送，（这样可以节省网络IO

    ，减少延迟），所以如下所示，客户端发送了两次数据，但是服务端却一次就收完了，因为在发送时就合并了，所以服务端

    的第二次收取，没有任何数据。

    

    记住一点：客户端的发送与服务端的接收并不是一对一的关系，他们实质上都是把数据拷贝只各自的操作系统，

    至于操作系统怎么发，何时发，应用程序就根本管不到了。

4>解决粘包问题

    既然产生这个问题的原因就是----客户端设定的接收值小于实际值，其实也就是客户端并不知道服务端究竟会传多少数据

    过来（因为就是把接收的最大值写成无限大，也有超过的可能），所以，可以这样解决：发送端在发送数据前，把自己将

    要发送的字节流总大小让接收端知晓，然后接收端来一个死循环接收完所有数据。

    解决这个问题之前，先介绍一个内置的库，struck

    

    如上，不管原始数据大小（应该也有个范围），它的pack方法都能转换成一个4位长度的Bytes类型数据，然后再通过

    unpack解开，得到一个元祖类型的数据格式，第一个就是真实的值，所以，可以把个值加在真实数据的前面（头部），

    就当做数据的描述信息，告知对方我的数据大小，对方收到后，先取钱4个字节，解码得到数据大小，这样，知道了

    数据的大小，就知道如何收取数据了。

    步骤拆解，如下服务端的写法（注意下面的send，两次虽然分开写了，但是他们会组装到一起发送，nagle算法）

    客户端的写法

    这样写其实也可以。只是也有 total_size[0] 超出接收范围的情况。

5>更高级的解决粘包问题的方法

    上面的方法始终都有数据超出范围的风险，接下来设计一个字典类型的头部信息，让头部信息能包含更多数据，也更完美

    的解决 数据范围这个问题，

    因为始终还是在服务端返回数据问题，所以还是从服务端开始分析，优化，分解步骤

    思路：服务端步骤： 1>接收命令，2>执行命令，3>【注意注意：这里并不是发送结果也不是发送头大小】，而是先

    设计一个dic类型的头信息，里面至少应该包含真实文件的大小，再发送这个头信息的固定长度，4>发送头部信息，

    5>发送真实数据。

               客户端步骤：1>发送命令，2>接收头部信息大小，3>根据头部信息大小接收头部信息，4>根据头部信息中真实

     数据大小，接收真实数据。（这里的2,3,4步就是对应服务端的3,4,5）

    服务端代码如下

客户端