网络编程- 黏包现象（四）

详细讲解地址：https://www.cnblogs.com/mys6/p/10587673.html

 

socket接受和发送的都是字节码，需要decode（即接受decode（'utf-8'或'gbk'）,反之encode（'utf-8'或'gbk'）成字节码发送）成对应的string

TCP：必须先启动server端，再启动client端

UDP：server端和client无先后启动顺序

网站下载视频常用的是TCP协议长连接，因为文件过大（比如几个G），分成无数小数据包，下载完后再拼接起来，文件过大无法用UDP，因为网络跟不上速度

 

基于TCP的黏包现象（虽黏包但不丢包，这次未显示完，下次会再次显示上次未显示完的）

server端

client端

客户端发送（dir;ls   >>ipcongfig   >>dir  ）后发现一种现象（即黏包现象）

 

基于UDP的模拟请求（虽不黏包，这次未显示的内容下次不会再显示，但产生丢包现象/不可靠）

server端

 

client端

 

类似我们平时QQ发消息时，遇到提示：消息过长不让发，请以文件发送，因为太长就会有丢包现象（UDP发送长度限制）

 

 

一

正常的情况：

 

二、面向流的通信特点和Nagle算法

TCP（transport control protocol，传输控制协议）是面向连接的，面向流的，提供高可靠性服务。
收发两端（客户端和服务器端）都要有一一成对的socket，因此，发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小且数据量小的数据，合并成一个大的数据块，然后进行封包。
这样，接收端，就难于分辨出来了，必须提供科学的拆包机制。 即面向流的通信是无消息保护边界的。 
对于空消息：tcp是基于数据流的，于是收发的消息不能为空，这就需要在客户端和服务端都添加空消息的处理机制，防止程序卡住，而udp是基于数据报的，即便是你输入的是空内容（直接回车），也可以被发送，udp协议会帮你封装上消息头发送过去。 
可靠黏包的tcp协议：tcp的协议数据不会丢，没有收完包，下次接收，会继续上次继续接收，己端总是在收到ack时才会清除缓冲区内容。数据是可靠的，但是会粘包。

1、Nagle算法优化方法的坏处就是黏包现象

到最后send的1和2分不开

 

发送端可以是一K一K地发送数据，而接收端的应用程序可以两K两K地提走数据，当然也有可能一次提走3K或6K数据，或者一次只提走几个字节的数据。
也就是说，应用程序所看到的数据是一个整体，或说是一个流（stream），一条消息有多少字节对应用程序是不可见的，因此TCP协议是面向流的协议，这也是容易出现粘包问题的原因。
而UDP是面向消息的协议，每个UDP段都是一条消息，应用程序必须以消息为单位提取数据，不能一次提取任意字节的数据，这一点和TCP是很不同的。
怎样定义消息呢？可以认为对方一次性write/send的数据为一个消息，需要明白的是当对方send一条信息的时候，无论底层怎样分段分片，TCP协议层会把构成整条消息的数据段排序完成后才呈现在内核缓冲区。

例如基于tcp的套接字客户端往服务端上传文件，发送时文件内容是按照一段一段的字节流发送的，在接收方看了，根本不知道该文件的字节流从何处开始，在何处结束

此外，发送方引起的粘包是由TCP协议本身造成的，TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一个TCP段。若连续几次需要send的数据都很少，通常TCP会根据优化算法把这些数据合成一个TCP段后一次发送出去，这样接收方就收到了粘包数据。

UDP不会发生黏包

UDP（user datagram protocol，用户数据报协议）是无连接的，面向消息的，提供高效率服务。 
不会使用块的合并优化算法，, 由于UDP支持的是一对多的模式，所以接收端的skbuff(套接字缓冲区）采用了链式结构来记录每一个到达的UDP包，在每个UDP包中就有了消息头（消息来源地址，端口等信息），这样，对于接收端来说，就容易进行区分处理了。 即面向消息的通信是有消息保护边界的。 
对于空消息：tcp是基于数据流的，于是收发的消息不能为空，这就需要在客户端和服务端都添加空消息的处理机制，防止程序卡住，而udp是基于数据报的，即便是你输入的是空内容（直接回车），也可以被发送，udp协议会帮你封装上消息头发送过去。 
不可靠不黏包的udp协议：udp的recvfrom是阻塞的，一个recvfrom(x)必须对唯一一个sendinto(y),收完了x个字节的数据就算完成,若是y;x数据就丢失，这意味着udp根本不会粘包，但是会丢数据，不可靠。

补充说明:

 

    用UDP协议发送时，用sendto函数最大能发送数据的长度为：65535- IP头(20) – UDP头(8)＝65507字节。用sendto函数发送数据时，如果发送数据长度大于该值，则函数会返回错误。（丢弃这个包，不进行发送） 

    用TCP协议发送时，由于TCP是数据流协议，因此不存在包大小的限制（暂不考虑缓冲区的大小），这是指在用send函数时，数据长度参数不受限制。而实际上，所指定的这段数据并不一定会一次性发送出去，如果这段数据比较长，会被分段发送，如果比较短，可能会等待和下一次数据一起发送。

 

练习

# 默写 TCP UDP 文件夹中的代码
# 完成一个上传和下载文件的小程序
 # server端 :根据客户端需求自定义
 # client端
 # 客户端启动之后
 # 选择 上传操作 还是 下载操作
 # 如果是上传操作 : 输入要上传的文件路径
 # 基础需求 :直接将文件上传到默认目录
 # 进阶需求 :将文件上传到指定目录
 # 如果是下载文件 : 输入要下载的文件路径
 # 基础需求 : 直接将文件下载到当前目录
 # 进阶需求 :将文件下载到指定目录
# 字符串
# 文件 - 读文件 转码 写文件