RPC TCP 常用参数设置

RPC TCP 常用参数设置

长连接一些常用配置

---

SO_REUSEPORT

linux kernel 3.9 支持此参数配置。建议不开启

linux

The new socket option allows multiple sockets on the same host to bind to the same port, and is intended to improve the performance of multithreaded network server applications running on top of multicore systems

SO_REUSEPORT支持多个进程或者线程绑定到同一端口，提高服务器程序的性能，解决的问题：

• 允许多个套接字 bind()/listen() 同一个TCP/UDP端口
  
  • 每一个线程拥有自己的服务器套接字
  • 在服务器套接字上没有了锁的竞争
• 内核层面实现负载均衡
• 安全层面，监听同一个端口的套接字只能位于同一个用户下面

SO_REUSEADDR

在端口释放后，可以被再次使用。在windows 不要开启次选项

windows上只有SO_REUSEADDR选项，没有SO_REUSEPORT。在windows上设置了SO_REUSEADDR的socket其行为与BSD上设定了SO_REUSEPORT和SO_REUSEADDRd的行为大致一样，只有一个差别：一个设置了SO_REUSEADDR的socket总是可以绑定到已经被绑定过的源地址和源端口，不管之前在这个地址和端口上绑定的socket是否设置了SO_REUSEADDR没有。这种行为在某种程度上有些危险因为它允许一个应用程序从别的应用程序上”偷取”已连接的端口。不用说，这对安全性有极大的影响，Microsoft意识到了这个问题，就加入了另一个socket选项: SO_EXECLUSIVEADDRUSE。设置了SO_EXECLUSIVEADDRUSE的socket确保一旦绑定成功，那么被绑定的源端口和地址就只属于这一个socket，其它的socket不能绑定，甚至他们使用了SO_REUSEADDR也没用1。

SO_BACKLOG

The maximum queue length for incoming connection indications (a
request to connect) is set to the backlog parameter. If a connection
indication arrives when the queue is full, the connection is refused2

TCP_NODELAY

true，不延迟，缓冲区有数据，尽量发送

SO_RCVBUF3

SO_SNDBUF

Netty:WRITE_BUFFER_HIGH_WATER_MARK

Netty:WRITE_WRITE_BUFFER_LOW_WATER_MARK

For instance, imagine you have a queue of tasks on server side that is filled by clients and processed by backend. In case clients send tasks too quick the length of the queue grows. One needs to introduce so named high watermark and low watermark. If queue length is greater than high watermark stop reading from sockets and queue length will decrease. When queue length becomes less than low watermark start reading tasks from sockets again.
Note, to make it possible for clients to adapt to speed you process tasks (actually to adapt window size) one shouldn’t make a big gap between high and low watermarks. From the other side small gap means you’ll be too often add/remove sockets from the event loop.
If the number of bytes queued in the write buffer exceeds writeBufferHighWaterMark value, Channel.isWritable() will start to return fals
Once the number of bytes queued in the write buffer exceeded the high water mark and then dropped down below this value, Channel.isWritable() will return true again.

---

1. http://blog.chinaunix.net/uid-28587158-id-4006500.html ↩
2. http://stackoverflow.com/questions/14075688/what-does-channeloption-so-backlog-do ↩
3. http://blog.chinaunix.net/uid-29075379-id-3905006.html ↩