考虑下面的场景，server向client发送数据"_META_DATA_ _USER_DATA_"，要求" "之前的数据_META_DATA_在第一次recv中接收，剩下的recv调用读取_USER_DATA_部分的数据。因为tcp是stream协议，并且_META_DATA_数据不是定长的，所以没有办法保证一次recv调用不读到_USER_DATA_部分的数据，除非一次读取一个字符。这种场景下，recv的MSG_PEEK参数就发挥作用。
recv的原型是ssize_t recv(int s, void *buf, size_t len, int flags); 通常flags都设置为0，此时recv函数读取tcp buffer中的数据到buf中，并从tcp buffer中移除已读取的数据。把flags设置为MSG_PEEK，仅把tcp buffer中的数据读取到buf中，并不把已读取的数据从tcp buffer中移除，再次调用recv仍然可以读到刚才读到的数据。
针对上面的场景，recv(fd, buf, nbuf, MSG_PEEK) 查看数据，查看" "的位置pos，再recv(fd, buf, pos+2, 0) 读取（并移除）数据。
上述场景描述的比较极端，毕竟很多时候，就算在一次recv中读到了_USER_DATA_部分的数据，仍可以先把这部分数据保存起来，添加到后续的recv数据之前，但是如果不同的recv跨越很多函数，保存数据带来了额外的复杂度。还可以考虑另外的场景，同一个端口支持文本协议和二进制协议，利用MSG_PEEK看一下头几个字符，先判断是文本协议还是二进制协议，再做请求分发，也是不错的选择。当然，真正的recv之前调用使用MSG_PEEK导致额外的一次函数调用。