网络字节序和主机序
我在大小端问题一文中介绍了，不同的开发语言和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到包体长度的数据，就是一个完整的包体。
需要注意的是，发送端一般要把包体的长度转换为网络字节序，接收端再把包体长度转为主机字节序。
