TCP/UDP的接收缓冲区和发送缓冲区

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/Swallow_he/article/details/84392285

1、TCP. SO_RCVBUF & TCP. SO_SNDBUF

每个TCP socket在内核中都有一个发送缓冲区和一个接收缓冲区,TCP的全双工的工作模式以及TCP的流量(拥塞)控制便是依赖于这两个独立的buffer以及buffer的填充状态。

1.1 接收端冲区

接收缓冲区把数据缓存入内核,应用进程一直没有调用recv()进行读取的话,此数据会一直缓存在相应socket的接收缓冲区内。不管进程是否调用recv()读取socket,对端发来的数据都会经由内核接收并且缓存到socket的内核接收缓冲区之中。

recv(),就是把内核缓冲区中的数据拷贝到应用层用户的buffer里面,并返回;

1.2发送缓冲区

进程调用send()发送的数据的时候,最简单情况(也是一般情况),将数据拷贝进入socket的内核发送缓冲区之中,然后send便会在上层返回。换句话说,send()返回之时,数据不一定会发送到对端去(和write写文件有点类似)。

send(),仅仅是把应用层buffer的数据拷贝进socket的内核发送buffer中,发送是TCP的事情,和send其实没有太大关系。

1.3 实际应用

接收缓冲区被TCP和UDP用来缓存网络上来的数据,一直保存到应用进程读走为止。

对于TCP,如果应用进程一直没有读取,接收缓冲区满了之后,发生的动作是:接收端通知发发端,接收窗口关闭(win=0)。这个便是滑动窗口的实现。保证TCP套接口接收缓冲区不会溢出,从而保证了TCP是可靠传输。因为对方不允许发出超过所通告窗口大小的数据。 这就是TCP的流量控制,如果对方无视窗口大小而发出了超过窗口大小的数据,则接收方TCP将丢弃它。

1.4 问题

能发出多少TCP包以及每个包承载多少数据,除了受到自身服务器配置和环境带宽影响,对端的接收状态也能影响你的发送状况。

查看测试机的socket发送缓冲区大小,如图1所示:

http://blog.chinaunix.net/attachment/201309/25/29075379_1380094314RfyB.jpg

第一个值是一个限制值,socket发送缓存区的最少字节数;
第二个值是默认值;
第三个值是一个限制值,socket发送缓存区的最大字节数;

根据实际测试,发送缓冲区的尺寸在默认情况下的全局设置是16384字节,即16k
proc文件系统下的值和sysctl中的值都是全局值,应用程序可根据需要在程序中使用setsockopt()对某个socket的发送缓冲区尺寸进行单独修改。

解决思路:通过合理的设置“TCP.SO_RCVBUF & TCP.SO_SNDBUF”来提高系统的吞吐量以及快速检测tcp链路的连通性; 这两个选项就是来设置TCP连接的两个buffer尺寸的。

2、UDP接收缓冲区

每个UDP socket都有一个接收缓冲区,没有发送缓冲区,从概念上来说就是只要有数据就发,不管对方是否可以正确接收,所以不缓冲,不需要发送缓冲区。

UDP:当套接口接收缓冲区满时,新来的数据报无法进入接收缓冲区,此数据报就被丢弃。UDP是没有流量控制的;快的发送者可以很容易地就淹没慢的接收者,导致接收方的UDP丢弃数据报。

3、总结

这也是TCP可靠,UDP不可靠的表现。

猜你喜欢

转载自blog.csdn.net/Swallow_he/article/details/84392285
今日推荐