网络字节序和主机序
我在大小端问题一文中介绍了,不同的开发语言和CPU有不同的字节序类型,有Little Endian和Big Endian。
所以没法保证客户端和服务端程序的字节序类型是一样,也就没法保证数据存储顺序是一样的,如果直接对某段数据进行网络传输,可能会导致数据的值在两端不一样。
而所有的网络协议都是采用的Big Endian,所以有时也会把Big Endian称为网络字节序。所以当两台采用不同字节序的主机进行网络通信时,在发送数据之前把字节序转换为网络字节序后再进行传输,接收数据后把网络字节序转换为主机字节序即可。
接口:
头文件:#include <arpa/inet.h>
- 网络字节顺序转换为主机字节顺序:
uint32_t ntohl(uint32_t netlong);
uint16_t ntohs(uint16_t netshort); - 主机字节顺序转换成网络字节顺序:
uint32_t htonl(uint32_t hostlong);
uint16_t htons(uint16_t hostshort);
TCP粘包问题
什么是粘包?
从接收缓冲区看,后一包数据的头紧接着前一包数据的尾。
粘包可能由发送端引起也有可能由接收端造成。TCP有粘包问题,UDP没有。
粘包产生的原因
首先来说tcp是流式协议,然后下面两种情况就会导致粘包
- Nagle算法导致发送端的粘包。当连续发送数据时,由于TCP协议的nagle算法,会将较小的内容拼接成大的内容,一次性发送到服务器端,因此造成粘包;
- 接收方接收数据不及时。TCP会把接收到的数据存在自己的TCP缓冲区中,然后通知应用层取数据。当应用层没有及时读取TCP缓冲区数据时,就会造成TCP缓冲区中存在多段数据。
解决粘包
解决粘包的方案是封包和解包。
封包就是给一段数据加上包头,这样数据包就分包头和包体两部分,一般我们规定包头的前四个字节用来记录包体的长度。解包就是在接收到数据包时,先获取到包体的长度,然后循环recv,直到recv到包体长度的数据,就是一个完整的包体。
需要注意的是,发送端一般要把包体的长度转换为网络字节序,接收端再把包体长度转为主机字节序。