黏包现象
让我们基于tcp先制作一个远程执行命令的程序（命令ls -l ; lllllll ; pwd）
执行远程命令的模块
需要用到模块subprocess
subprocess通过子进程来执行外部指令，并通过input/output/error管道，获取子进程的执行的返回信息。
import os
import subprocess
ret = os.popen('dir').read()
print(ret)
print('*'*50)
ret = subprocess.Popen('dir',shell=True,stdout=subprocess.PIPE,
stderr=subprocess.PIPE)
print(ret.stdout)
print(ret.stderr)
shell= True 可以执行一个普通系统命令
stdout 表示一个容器，返回正常的信息
stderr 存放错误信息的容器
执行输出：
驱动器 E 中的卷是 file
卷的序列号是 8077-D7B9
E:\python_script\day30\黏包 的目录
2018/05/07 14:54 <DIR> .
2018/05/07 14:54 <DIR> ..
2018/05/07 14:54 236 a.py
1 个文件 236 字节
2 个目录 183,394,840,576 可用字节
**************************************************
<_io.BufferedReader name=3>
<_io.BufferedReader name=4>
执行一个错误的命令
import os
import subprocess
ret = os.popen('ls').read()
print(ret)
print('*'*50)
ret = subprocess.Popen('ls',shell=True,stdout=subprocess.PIPE,
stderr=subprocess.PIPE)
print('out:',ret.stdout.read().decode('gbk'))
print('err:',ret.stderr.read().decode('gbk'))
执行输出：
os.popen() 执行一个错误的命令，显示乱码
而subprocess则不会，它还是比较完善的。
基于tcp协议实现的黏包
用server端，让客户端执行一个命令
server.py
import socket
sk = socket.socket()
sk.bind(('127.0.0.1',9000))
sk.listen()
conn,addr = sk.accept()
while True:
cmd = input('>>>')
conn.send(cmd.encode('utf-8'))
if cmd == 'q': break
ret1 = conn.recv(1024)
print('stdout : ', ret1.decode('gbk'))
ret2 = conn.recv(1024)
print('stderr : ',ret2.decode('gbk'))
conn.close()
sk.close()
client.py
import socket
import subprocess
sk = socket.socket()
sk.connect(('127.0.0.1',9000))
while True:
cmd = sk.recv(1024).decode('utf-8')
print(cmd)
if cmd == 'q':break
ret = subprocess.Popen(cmd,shell=True,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)
out = ret.stdout.read()
err = ret.stderr.read()
print(out,'*****\n',err)
sk.send(b'out :'+out)
sk.send(b'error :'+err)
sk.close()
先执行server.py，再执行client.py，执行效果如下：
首先是执行了help命令，再执行dir命令
但是为什么都是显示help的命令结果呢？
这就是黏包现象
因为每次执行，固定为1024字节。它只能接收到1024字节，那么超出部分怎么办？
等待下一次执行命令dir时，优先执行上一次，还没有传完的信息。传完之后，再执行dir命令
总结：
发送过来的一整条信息
由于server端没有及时接受
后来发送的数据和之前没有接收完的数据黏在了一起
这就是著名的黏包现象
那么udp会发现黏包现象吗？实践一下，就知道了
基于udp协议实现的黏包
server.py
#_*_coding:utf-8_*_
from socket import *
import subprocess
ip_port=('127.0.0.1',9000)
bufsize=1024
udp_server=socket(AF_INET,SOCK_DGRAM)
udp_server.setsockopt(SOL_SOCKET,SO_REUSEADDR,1)
udp_server.bind(ip_port)
while True:
#收消息
cmd,addr=udp_server.recvfrom(bufsize)
print('用户命令----->',cmd)
#逻辑处理
res=subprocess.Popen(cmd.decode('utf-8'),shell=True,stderr=subprocess.PIPE,stdin=subprocess.PIPE,stdout=subprocess.PIPE)
stderr=res.stderr.read()
stdout=res.stdout.read()
#发消息
udp_server.sendto(stderr,addr)
udp_server.sendto(stdout,addr)
udp_server.close()
client.py
from socket import *
ip_port=('127.0.0.1',9000)
bufsize=1024
udp_client=socket(AF_INET,SOCK_DGRAM)
while True:
msg=input('>>: ').strip()
udp_client.sendto(msg.encode('utf-8'),ip_port)
err,addr=udp_client.recvfrom(bufsize)
out,addr=udp_client.recvfrom(bufsize)
print(err)
if err:
print('error : %s'%err.decode('gbk'),end='')
if out:
print(out.decode('gbk'), end='')
先执行server.py，再执行client.py，执行效果如下：
>>: ipconfig
Traceback (most recent call last):
File "E:/python_script/day30/黏包/client.py", line 11, in <module>
out,addr=udp_client.recvfrom(bufsize)
OSError: [WinError 10040] 一个在数据报套接字上发送的消息大于内部消息缓冲区或其他一些网络限制，或该用户用于接收数据报的缓冲区比数据报小。
在客户端执行ipconfig，就报错了，提示缓冲区过大。所以说udp不会出现黏包
总结：
只有TCP有粘包现象，UDP永远不会粘包
subprocess不能运行windows help命令，不是因为udp问题，而是subprocess问题。
黏包成因
TCP协议中的数据传递
tcp协议的拆包机制
当发送端缓冲区的长度大于网卡的MTU时，tcp会将这次发送的数据拆成几个数据包发送出去。
MTU是Maximum Transmission Unit的缩写。意思是网络上传送的最大数据包。MTU的单位是字节。 大部分网络设备的MTU都是1500。如果本机的MTU比网关的MTU大，大的数据包就会被拆开来传送，这样会产生很多数据包碎片，增加丢包率，降低网络速度。
面向流的通信特点和Nagle算法
TCP（transport control protocol，传输控制协议）是面向连接的，面向流的，提供高可靠性服务。
收发两端（客户端和服务器端）都要有一一成对的socket，因此，发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小且数据量小的数据，合并成一个大的数据块，然后进行封包。
这样，接收端，就难于分辨出来了，必须提供科学的拆包机制。 即面向流的通信是无消息保护边界的。
对于空消息：tcp是基于数据流的，于是收发的消息不能为空，这就需要在客户端和服务端都添加空消息的处理机制，防止程序卡住，而udp是基于数据报的，即便是你输入的是空内容（直接回车），也可以被发送，udp协议会帮你封装上消息头发送过去。
可靠黏包的tcp协议：tcp的协议数据不会丢，没有收完包，下次接收，会继续上次继续接收，己端总是在收到ack时才会清除缓冲区内容。数据是可靠的，但是会粘包。
基于tcp协议特点的黏包现象成因
发送端可以是一K一K地发送数据，而接收端的应用程序可以两K两K地提走数据，当然也有可能一次提走3K或6K数据，或者一次只提走几个字节的数据。
也就是说，应用程序所看到的数据是一个整体，或说是一个流（stream），一条消息有多少字节对应用程序是不可见的，因此TCP协议是面向流的协议，这也是容易出现粘包问题的原因。
而UDP是面向消息的协议，每个UDP段都是一条消息，应用程序必须以消息为单位提取数据，不能一次提取任意字节的数据，这一点和TCP是很不同的。
怎样定义消息呢？可以认为对方一次性write/send的数据为一个消息，需要明白的是当对方send一条信息的时候，无论底层怎样分段分片，TCP协议层会把构成整条消息的数据段排序完成后才呈现在内核缓冲区。