SO_RCVBUF SO_SNDBUF
TCP socket在内核中都有一个发送缓冲区和一个接收缓冲区,不管进程是否读取socket,对端发来的数据都会经由内核接收并且缓存到socket的内核接收缓冲区之中.
read所做的工作,就是把内核缓冲区中的数据拷贝到应用层用户的buffer里面,仅此而已.
send所做的工作,最简单情况(也是一般情况),将数据拷贝进入socket的内核发送缓冲区之中,然后send便会在上层返回.
send返回之时,数据不一定会发送到对端,send仅仅是把应用层buffer的数据拷贝进socket的内核发送buffer中.
UDP socket都有一个接收缓冲区,没有发送缓冲区,UDP不保证数据一定发送成功,所以只要有数据就发,不管对方是否可以正确接收,所以不缓冲,不需要发送缓冲区.
接收缓冲区被TCP和UDP用来缓存网络上来的数据,一直保存到应用进程读走为止.对于TCP,如果应用进程一直没有读取,buffer满了之后,发生的动作是:通知对端TCP协议中的窗口关闭.这个便是滑动窗口的实现.
保证TCP套接口接收缓冲区不会溢出,从而保证了TCP是可靠传输.因为对方不允许发出超过所通告窗口大小的数据. 这就是TCP的流量控制,如果对方无视窗口大小而发出了超过窗口大小的数据,则接收方TCP将丢弃它.
UDP:当套接口接收缓冲区满时,新来的数据报无法进入接收缓冲区,此数据报就被丢弃.UDP是没有流量控制的；快的发送者可以很容易地就淹没慢的接收者,导致接收方的UDP丢弃数据报.
SO_RCVLOWAT SO_SNDLOWAT
每个套接口都有一个接收低水位和一个发送低水位.
接收低水位:对于TCP套接口而言,接收缓冲区中的数据必须达到规定数量,内核才通知进程“可读”.比如触发select或者epoll,返回“套接口可读”.
发送低水位:对于TCP套接口而言,和接收低水位一个道理.
理解接收低水位:如果应用程序没有调用recv()去读取socket的接受缓冲区的数据,则接受缓冲区数据将注一直保存在接受缓冲区中,所以随着接受缓冲区接受到更多发送端发送缓冲区中的数据,则肯定会导致接受缓冲区溢出,所以设置一个接受低水位,当epoll监听到某一个socket的接受缓冲区的数据超过了接受低水位,则触发读就绪,使得epoll循环返回,开始处理读I/O事件.
接收低水位: 默认为1字节
理解发送低水位:如果应用程序没有调用send()来copy应用程序buff中的数据到socket发送缓冲区中,则随着发送缓冲区的数据被内核通过tcp协议发送出去,最后socket发送缓冲区的数据越来越少,可用的剩余空间越来越多,最后超过发送缓冲区的发送低水位,则epoll监听到这个socket可写,使得epoll循环返回,开始处理写I/O事件.
发送低水位 : 默认为2048字节
SO_REUSEADDR
这个套接字选项通知内核,如果端口忙,但TCP状态位于 TIME_WAIT ,可以重用端口.如果端口忙,而TCP状态位于其他状态,重用端口时依旧得到一个错误信息,指明"地址已经使用中".如果服务程序停止后想立即重启,而新套接字依旧使用同一端口,此时SO_REUSEADDR 选项非常有用.必须意识到,此时任何非期望数据到达,都可能导致服务程序反应混乱,不过这只是一种可能,事实上很不可能.
一个套接字由相关五元组构成,协议、本地地址、本地端口、远程地址、远程端口.SO_REUSEADDR 仅仅表示可以重用本地本地地址、本地端口,整个相关五元组还是唯一确定的.所以,重启后的服务程序有可能收到非期望数据.必须慎重使用 SO_REUSEADDR 选项.
SO_REUSEPORT
https://my.oschina.net/miffa/blog/390931
SO_LINGER
此选项指定函数close对面向连接的协议如何操作(如TCP).内核缺省close操作是立即返回,如果有数据残留在套接口缓冲区中则系统将试着将这些数据发送给对方.