如果客户端和服务端是同步串行的 socket 通信,是不是不用考虑粘包的问题了
資深大佬 : zxCoder 3
如果客户端和服务端是同步串行的 socket 通信,是不是不用考虑粘包的问题了
就客户端发一个命令,服务端接收处理后发送回复,客户端收到回复,再发送下一个命令
大佬有話說 (16)
如果客户端和服务端是同步串行的 socket 通信,是不是不用考虑粘包的问题了
就客户端发一个命令,服务端接收处理后发送回复,客户端收到回复,再发送下一个命令
对于 TCP 连接,你想发一个消息的时候呼叫快递员。快递员还没到,你可能又想发第二个消息了。等快递员来了,你都准备好 3 个消息了。快递员发觉你这三个消息是通过同一个 TCP 连接发出去的,因此把他们打包在同一个快递箱子里了(这三个加起来还没到 1500 字节)用一个快递单号发出去了。这就是粘包。
然后你想发第四个消息,于是再次呼叫快递员。这第四个消息有 1600 字节。快递员发现一个包装箱放不下,于是把你的货拆成了两箱发出去,第一箱 1500,第二箱 100 。第二箱还没装满,如果你有其他消息要发,可以和第二箱一起打包发走。
TCP 是面向连接的,快递员只要发现是同一个连接的数据,就会自动帮你合箱。所以如果你连着发送两坨数据,就有可能粘包。
UDP 则不同。UDP 没有连接,信息与信息之间毫无关系。所以你即使连续发送 100 个每个只有 1 字节的信息,也会分成 100 个快递箱发出去。这绝不会粘包,但坏处是你得付 100 单快递费,性价比低,而且丢了不管。UDP 虽然不能合箱,但提供拆箱服务,如果你想发 1600 字节的数据,UDP 也能帮你拆成两箱。有趣的是,这是一个可选的服务,你可以明确选择声明拒绝拆箱,那么快递小哥发现超重之后会直接拒发快递。(你不用自己检测是否超过 1500 字节,因为有的快递能发大包,一个包能装下 9000 字节)