recv,write,send,read,recvfrom,sendto区别，详解

参考文章：

Linux网络编程（一）

 
网络编程（24）—— linux中write和read函数的阻塞试验 

网络编程中的read，write函数

send和recv只是内核缓冲区和应用程序缓冲区之间的搬运工

[c++,linux]网络编程之 send,recv 函数 

。。。

下面， 我们看一幅图， 了解一下send和recv函数所处的位置(这幅图是我在网上找的， 不太清晰， 请凑合看一下)：



  为了简便起见， 我们仅考虑单向的数据流， 即A（客户端）向B（服务端）发送数据。 在应用程序Program A中， 我们定义一个数组char szBuf[100] = "tcp"; 那么这个szBuf就是应用程序缓冲区（对应上图的Program A中的某块内存）， send函数对应上面蓝色的Socket API, 内核缓冲区对应上面的黄色部分。 我们看到， send函数的作用是把应用程序缓冲区中的数据拷贝到内核缓冲区， 仅此而已。 内核缓冲区中的数据经过网卡， 经历网络传到B端的网卡(TCP协议)，
然后进入B的内核缓冲区， 然后由recv函数剪切/复制到Program B的应用程序缓冲区。

强调一下：

        1. 对于客户端A， 其发送的内核缓冲区和接收的内核缓冲区是不一样的, 互不干扰. 服务端B也同理。

                         发送端和接收端都有read和write的缓冲区。

        2. recv函数是剪切还是复制， 由最后一个参数决定， 我们在之前的博文已经讲述过了。

                       




 1. 当A向B发送数据时， A上的wireshark可以抓到对应的包， 因为数据经过了A的网卡。（不管B是否有去recv）

 2. 当B向A发送数据时， A上的wireshark也可以抓到对应的包,    因为数据到达了A的内核缓冲区， 也经历了A的网卡。（不管A是否有去recv）

补充：

1.首先知道，套接字描述符是用来标定系统为当前的进程划分的一块缓冲空间的，类似于文件描述符，不过二者有些区别；
2.其次应该知道的是，这块缓冲空间并不是一开始就被系统划分给进程的；
3. 对于 server 端而言，划分系统缓冲空间的时刻是： 当server 决定接收来自 client 的连接请求，
即 accept 方法成功执行，返回一个 > 0 的整数（也就是新的套接字描述符），这个套接字指向的缓冲区包含read缓冲区和write缓冲区
系统才会为其分配缓冲空间，自然， 这块缓冲空间是通过 accept 新的套接字描述符来指定的 ；
4. 对于 client 端而言，划分系统缓冲空间的时刻是： 当 client 端执行 connect 函数正确的时候，
connect 函数正确执行，说明此 client 端的连接请求已经被 server 端接收，剩下的就需要系统为 client 划分缓冲空间，
用来接收来自于 server 端的返回结果。 这个时候，系统才会为其分配缓冲空间，
而该缓冲空间使用 client 一开始创建套接字的 socket 函数的返回值标定即可。这个套接字指向的缓冲区包含read缓冲区和write缓冲区

目前为止，用到的recv和send函数的最后一个参数，都是0.就当做read和write函数吧。(后面的阻塞实验中，将read替换为recv，recv最后一个参数为0，得到的结果是一样的)

不过也不完全一样，看文章最后部分

read/write的语义：为什么会阻塞？

write在什么情况下会阻塞？当kernel的该socket的发送缓冲区已满时。对于每个socket，拥有自己的send buffer和receive buffer。从Linux 2.6开始，两个缓冲区大小都由系统来自动调节（autotuning），但一般在default和max之间浮动。

# 获取socket的发送/接受缓冲区的大小：（后面的值是在我在Linux 2.6.38 x86_64上测试的结果）

sysctl net.core.wmem_default #126976

sysctl net.core.wmem_max　　　　 #131071

sysctl net.core.wmem_default #126976

sysctl net.core.wmem_max #131071

已经发送到网络的数据依然需要暂存在send buffer中，只有收到对方的ack后，kernel才从buffer中清除这一部分数据，为后续发送数据腾出空间。接收端将收到的数据暂存在receive buffer中，自动进行确认。但如果socket所在的进程不及时将数据从receive buffer中取出，最终导致receive buffer填满，由于TCP的滑动窗口和拥塞控制，接收端会阻止发送端向其发送数据。这些控制皆发生在TCP/IP栈中，对应用程序是透明的，应用程序继续发送数据，最终导致send buffer填满，write调用阻塞。

一般来说，由于接收端进程从socket读数据的速度跟不上发送端进程向socket写数据的速度，最终导致发送端write调用阻塞。

write

#include <unistd.h>
ssize_t write(int fd, const void *buf, size_t count);

1
2

从

buf

中向

fd

中写入

count

个字节，成功时返回实际写入的字节数。

而read调用的行为相对容易理解，从socket的receive buffer中拷贝数据到应用程序的buffer中。read调用阻塞，通常是发送端的数据没有到达。

#include <unistd.h>
ssize_t read(int fd, void *buf, size_t count);

1
2
从

fd

中读取

count

个字节到

buf

中，成功时返回读取到的字节，文件指针也随之移动相应距离（很好理解）。

linux中write和read函数的阻塞试验

man了一下write和read，发现其文档中都有下面一句话：

ERRORS

       EA
4000
GAIN The file descriptor fd refers to a file other than a  socket  and  has  been

              marked non-blocking (O_NONBLOCK), and the write would block.

翻译过来就是：

         如果文件描述符不是socket的话，该函数是非阻塞的，否则该函数是阻塞的。 为了验证这个问题，进行如下实验，主要验证read函数的阻塞特性
linux中write和read函数的阻塞试验


客户端在write之后，打印出"writed,begin block"的信息，然后read函数开始阻塞，只有在服务端sleep完，返回数据后才会结束阻塞，如果sleep完，再次发送数据，则会立即返回不会阻塞。这时关闭服务端，再次发送也不会阻塞。只有sleep中，read缓冲区的值为空时，才能达到目的。

结果如下：


以上代码，足以证明了read函数的阻塞特性。。。。。

blocking（默认）和nonblock模式下read/write行为的区别：

将socket fd设置为nonblock（非阻塞）是在服务器编程中常见的做法，采用blocking IO并为每一个client创建一个线程的模式开销巨大且可扩展性不佳（带来大量的切换开销），更为通用的做法是采用线程池+Nonblock I/O+Multiplexing（select/poll，以及Linux上特有的epoll）。

// 设置一个文件描述符为nonblock

int set_nonblocking(int fd)

{

int flags;

if ((flags = fcntl(fd, F_GETFL, 0)) == -1)

flags = 0;

return fcntl(fd, F_SETFL, flags | O_NONBLOCK);

}

几个重要的结论：

1. read总是在接收缓冲区有数据时立即返回，而不是等到给定的read buffer填满时返回。

只有当receive buffer为空时，blocking模式才会等待，而nonblock模式下会立即返回-1（errno = EAGAIN或EWOULDBLOCK）

2. blocking的write只有在缓冲区足以放下整个buffer时才返回（与blocking read并不相同）

nonblock write则是返回能够放下的字节数，之后调用则返回-1（errno = EAGAIN或EWOULDBLOCK）

对于blocking的write有个特例：当write正阻塞等待时对面关闭了socket，则write则会立即将剩余缓冲区填满并返回所写的字节数，再次调用则write失败（connection reset by peer），这正是下个小节要提到的：

 read/write对连接异常的反馈行为：

对应用程序来说，与另一进程的TCP通信其实是完全异步的过程：

1. 我并不知道对面什么时候、能否收到我的数据

2. 我不知道什么时候能够收到对面的数据

3. 我不知道什么时候通信结束（主动退出或是异常退出、机器故障、网络故障等等）

对于1和2，采用write() -> read() -> write() -> read() ->...的序列，通过blocking read或者nonblock read+轮询的方式，应用程序基于可以保证正确的处理流程。

对于3，kernel将这些事件的“通知”通过read/write的结果返回给应用层。

假设A机器上的一个进程a正在和B机器上的进程b通信：某一时刻a正阻塞在socket的read调用上（或者在nonblock下轮询socket）

当b进程终止时，无论应用程序是否显式关闭了socket（OS会负责在进程结束时关闭所有的文件描述符，对于socket，则会发送一个FIN包到对面）。

”同步通知“：进程a对已经收到FIN的socket调用read，如果已经读完了receive buffer的剩余字节，则会返回EOF:0

”异步通知“：如果进程a正阻塞在read调用上（前面已经提到，此时receive buffer一定为空，因为read在receive buffer有内容时就会返回），则read调用立即返回EOF，进程a被唤醒。

socket在收到FIN后，虽然调用read会返回EOF，但进程a依然可以其调用write，因为根据TCP协议，收到对方的FIN包只意味着对方不会再发送任何消息。 在一个双方正常关闭的流程中，收到FIN包的一端将剩余数据发送给对面（通过一次或多次write），然后关闭socket。

但是事情远远没有想象中简单。优雅地（gracefully)关闭一个TCP连接，不仅仅需要双方的应用程序遵守约定，中间还不能出任何差错。

假如b进程是异常终止的，发送FIN包是OS代劳的，b进程已经不复存在，当机器再次收到该socket的消息时，会回应RST（因为拥有该socket的进程已经终止）。a进程对收到RST的socket调用write时，操作系统会给a进程发送SIGPIPE，默认处理动作是终止进程，知道你的进程为什么毫无征兆地死亡了吧：）

from 《Unix Network programming, vol1》 3rd Edition：

"It is okay to write to a socket that has received a FIN, but it is an error to write to a socket that has received an RST."

通过以上的叙述，内核通过socket的read/write将双方的连接异常通知到应用层，虽然很不直观，似乎也够用。

这里说一句题外话：

不知道有没有同学会和我有一样的感慨：在写TCP/IP通信时，似乎没怎么考虑连接的终止或错误，只是在read/write错误返回时关闭socket，程序似乎也能正常运行，但某些情况下总是会出奇怪的问题。想完美处理各种错误，却发现怎么也做不对。

原因之一是：socket（或者说TCP/IP栈本身）对错误的反馈能力是有限的。

recv和send函数：

这里只描述同步Socket的send函数的执行流程。当调用该函数时，send先比较待发送数据的长度len和套接字s的发送缓冲的 长度，如果len大于s的发送缓冲区的长度，该函数返回SOCKET_ERROR；如果len小于或者等于s的发送缓冲区的长度，那么send先检查协议 是否正在发送s的发送缓冲中的数据，如果是就等待协议把数据发送完，如果协议还没有开始发送s的发送缓冲中的数据或者s的发送缓冲中没有数据，那么 send就比较s的发送缓冲区的剩余空间和len，如果len大于剩余空间大小send就一直等待协议把s的发送缓冲中的数据发送完，如果len小于剩余 空间大小send就仅仅把buf中的数据copy到剩余空间里（注意并不是send把s的发送缓冲中的数据传到连接的另一端的，而是协议传的，send仅仅是把buf中的数据copy到s的发送缓冲区的剩余空间里）。如果send函数copy数据成功，就返回实际copy的字节数，如果send在copy数据时出现错误，那么send就返回SOCKET_ERROR；如果send在等待协议传送数据时网络断开的话，那么send函数也返回SOCKET_ERROR。

要注意send函数把buf中的数据成功copy到s的发送缓冲的剩余空间里后它就返回了，但是此时这些数据并不一定马上被传到连接的另一端。如 果协议在后续的传送过程中出现网络错误的话，那么下一个Socket函数就会返回SOCKET_ERROR。（每一个除send外的Socket函数在执 行的最开始总要先等待套接字的发送缓冲中的数据被协议传送完毕才能继续，如果在等待时出现网络错误，那么该Socket函数就返回 SOCKET_ERROR）

注意：在Unix系统下，如果send在等待协议传送数据时网络断开的话，调用send的进程会接收到一个SIGPIPE信号，进程对该信号的默认处理是进程终止。

这里只描述同步Socket的recv函数的执行流程。当应用程序调用recv函数时，recv先等待s的发送缓冲 中的数据被协议传送完毕，如果协议在传送s的发送缓冲中的数据时出现网络错误，那么recv函数返回SOCKET_ERROR，如果s接收缓冲区中没有数据或者协议正在接收数据，那么recv就一直等待，只到 协议把数据接收完毕。当协议把数据接收完毕，recv函数就把s的接收缓冲中的数据copy到buf中（注意协议接收到的数据可能大于buf的长度，所以 在这种情况下要调用几次recv函数才能把s的接收缓冲中的数据copy完。recv函数仅仅是copy数据，真正的接收数据是协议来完成的），recv函数返回其实际copy的字节数。如果recv在copy时出错，那么它返回SOCKET_ERROR；如果recv函数在等待协议接收数据时网络中断了，那么它返回0。

注意：在Unix系统下，如果recv函数在等待协议接收数据时网络断开了，那么调用recv的进程会接收到一个SIGPIPE信号，进程对该信号的默认处理是进程终止。

自己总结一下，个人理解，正确性日后再纠正：

udp中，recvfrom相当于connect+recv

sendto相当于connect+send(如果前面执行过recvfrom或sendto，这里的connect就不用执行了吧)

tcp中，recvfrom相当于recv+getpeername()

sendto相当于send+getsockname().

先这样吧