TCP协议存在粘包现象，UDP协议不存在粘包现象。
粘包：只有TCP有粘包现象，UDP没有
接收数据过大，不能一次收完，其余数据还在缓存里，（从服务端缓存流到客户端缓存），网速快，瞬间从服务端到了客户端，如果不快可能没有1024字节。第二次，继续收上一次数据的后续1024，因为上次的数据过大，没接收完，继续接收。这就叫粘包。
之后的命令，都受到了，一次数据过大的影响。
原因：
TCP是流式协议，数据像水流一样粘在一起，没有边界区分。
接收数据过大，不能一次接收完全，残留的数据，会在下一次接收的时候，继续接收，接着上一次的接收。
解决：通过循环接收，接收完全，后再进行发送下一次数据
接收的最大数据量，应用缓存区大小。
接收数据过大，缓存放不下。
通过 协议 ，设置报头
先拿到数据的总大小
循环接收数据
知道收到的大小完全
一定要及时的退出循环，否则阻塞程序在这里接收了，，，
流式协议：可以send好几次，数据会存在缓存里
TCP:nagle算法：将两个 时间间隔短 ， 数据量小 的，结合为一个数据块。（流式协议）
UDP:数据没人收，就没了的，一次接收不了，剩下的数据就没了
TCP协议是可靠协议，是流式协议。
所以，数据的传输存在粘包现象，如果一次的发送数据过大，接收一次不能接收完全，那剩下的数据不会丢失，会在下次接收继续接收这些数据，
所以，每次接收数据的结果会混乱，
所以，每一次传输接收数据都要接收完全后，才进行下一次的发送。
这种现象，就叫粘包。
为了避免，出现粘包，要通过报头，来获取数据的大小等信息。循环取出所有的数据后，就可以开始下一次的发送了。
struct：
将数字转为固定长度的bytes类型
stuct.pack('i',111)
i 模式：将数字转为整型的bytes类型 ，即四个字节长度
stuct.unpack('i',x)
得到一个元组，第一个元素，为解压出来的值
接收端先接收，比如，4个字节。
用json，将头部序列化，别的应用也能反序列化得到头部信息（比如，字典 ）
repr，str，eval，只能python用
服务端：
1 不断地从半连接池中获得链接请求，建立双向连接，产生链接对象，
2 进行循环，传输数据。
socketserver 模块：实现并发
UDP:最终还是一个一个来的，是不断的'建立链接',,,不断地运行同一段代码，后，在接收另外一个输入，，，如果，第一段代码没执行完，那第二段数据，就不会接收了，总之，它只有一段代码，不能同时接收两个客户端的输入，只是有时候速度太快了，貌似是并发，但实际上不是。
udp产生的是元组，第一个元素，bytes 数据，第二个元素是socket对象
putty
vim
0.0.0.0 代表所有的机器都可以访问
wget 下载地址
cat
本实例安全组：
3000/8000的端口
vim etc/profix