recv和read相似，都可用来接收sockfd发送的数据，但recv比read多了一个参数，也就是第四个参数，它可以指定标志来控制如何接收数据。

原型：ssize_t recv(int sockfd, void *buf, size_t nbytes, int flags);

返回值：返回数据的字节长度；

              若无可用数据或对等方已经按序结束，返回0；

              若出错，返回-1.（APUE说法）

对于SOCK_STREAM套接字来讲，recv接收的数据可以比预期的少，recv的第四个参数可以选MSG_WAITALL标志来阻止这种行为，当flags为MSG_WAITALL时，recv会阻塞直到所指定的长度nbytes字节的数据全部返回，recv才会返回。

正常情况下recv 是会等待直到读取到nbytes长度的数据，但是这里的MSG_WAITALL也只是尽量读全，在有中断的情况下recv 还是可能会被打断，造成没有读完指定的nbytes的长度。使用这个标志recv会在以下三种情况发生时返回：

1) 当读到了指定的字节时,函数正常返回.返回值等于nbytes；

2) 当读到了文件的结尾时,函数正常返回.返回值小于nbytes(不知道对于SOCK_STREAM字节流是否也是这样)； 

3) 当操作发生错误时,返回-1,且设置错误为相应的错误号(errno)。

recv一次能接收的字节数nbytes应该与socket接收缓冲区的大小有关，当使用的套接字为SOCK_STREAM类型时，不能保证一次recv就能读取sockfd发送的所有数据，因此需要重复调用直到它返回0，可以采用如下方法实现：

对于SOCK_DGRAM和SOCK_SEQPACKET套接字，MSG_WAITALL并不改变什么，因为这些基于报文的套接字类型一次读取就返回整个报文。

如果flags为0，则recv和read一样。

在阻塞的tcp socket上使用read读取的数据长度和recv一样会发生返回值比指定长度短的情况。引用《UNIX网络编程 卷一 套接字联网API》3.9中的说法：  字节流套接口(如tcp套接口)上的read和write函数所表现的行为不同于通常的文件IO。字节流套接口上的读或写、输入或输出的字节数可能比要求的数量少。

但这不是错误状况，原因是内核中套接口的缓冲区可能已达到了极限。此时所需的是调用者再次调用read或write函数，以输入或输出剩余的字节。 

可以使用readn函数来实现循环读取以解决这个问题：

以上参考APUE和http://naso.iteye.com/blog/1927483，read和recv等函数的区别_xjbclz的专栏-CSDN博客_read和recv从网络读取数据的区别等博文完成。