java套接字socket编程--tcp参数

Java 套接字 Socket 编程-TCP 参数 在 Java 的 Socket 中，主要包含了以下可设置的 TCP 参数。 属性 说明 默认值 SO_TIMEOUT 对 ServerSocket 来说表示等待连接的最长空 等待时间; 对 Socket 来说表示读数据最长空等 待时间。 0 TCP_NODELAY 是否一有数据就马上发送。 false SO_LINGER 优雅地关闭套接字，或者立刻关闭。 -1 SO_SNDBUF 发送数据的缓冲区大小。 8K SO_RCVBUF 接收数据的缓冲区大小。 8K SO_KEEPALIVE 是否启用心跳机制。 false SO_REUSEADDR 是否地址重用。 false BACKLOG 服务端处理线程全忙后，允许多少个新请求进 入等待。 50 1.1 BACKLOG BACKLOG 用于构造服务端套接字 ServerSocket 对象，标识当服务器请求处理线程全满时，用于临 时存放已完成三次握手的请求的队列的最大长度。如果未设置或所设置的值小于 1，Java 将使用默认值 50。 ServerSocket serverSocket = new ServerSocket(8080, 100); 1.2 TCP_NODELAY 在 TCP/IP 协议中，无论发送多少数据，总是要在数据前面加上协议头，同时，对方接收到数据，也 需要发送 ACK 表示确认。为了尽可能的利用网络带宽， TCP 总是希望尽可能的发送足够大的数据。这里 就涉及到一个名为 Nagle 的算法，该算法的目的就是为了尽可能发送大块数据，避免网络中充斥着许多 小数据块。 TCP_NODELAY 选项，就是用于启用或关于 Nagle 算法。如果要求高实时性，有数据发送时就马上 发送，就将该选项设置为 true 关闭 Nagle 算法；如果要减少发送次数减少网络交互，就设置为 false 等 累积一定大小后再发送。默认为 false。 Socket 中操作该属性的方法如下： void setTcpNoDelay(boolean on) 启用/禁用 TCP_NODELAY（启用/禁用 Nagle 算法）。 boolean getTcpNoDelay() 测试是否启用 TCP_NODELAY。 关于 Nagle 算法介绍，请参考附录部分。 1.3 SO_TIMEOUT 对于服务端套接字 ServerSocket 来说，SO_TIMEOUT 表示服务端 accept 方法空等待客户端连接 的最长时间；对于客户端套接字 Socket 来说，SO_TIMEOUT 表示输入流读取数据 read 方法的最长等待 时间。一旦超过设置的 SO_TIMEOUT，程度将抛出超时异常。 ServerSocket/Socket 中操作该属性的方法如下： int getSoTimeout() 返回 SO_TIMEOUT 的设置。 void setSoTimeout(int timeout) 启用/禁用带有指定超时值的 SO_TIMEOUT，以毫秒为单位。 使用示例： ServerSocket serverSocket = new ServerSocket(8080); serverSocket.setSoTimeout(30000); Socket clientSocket = serverSocket.accept(); clientSocket.setSoTimeout(20000); 1.4 SO_LINGER 当调用 closesocket 关闭套接字时，SO_LINGER 将决定系统如何处理残存在套接字发送队列中的数 据。处理方式无非两种：丢弃或者将数据继续发送至对端，优雅关闭连接。事实上，SO_LINGER 并不被 推荐使用，大多数情况下我们推荐使用默认的关闭方式（即下方表格中的第一种情况） 。 下方代码段显示 linger 结构语法，表格为不同参数情况下的套接字行为。 typedef struct linger u_short l_onoff; /开关，零或者非零 u_short l_linger; /优雅关闭最长时限 linger; 各字段与对应行为如下表所示。 l_onoff l_linger closesocket 行为 发送队列 底层行为 零 忽略 立即返回。 保持直至发送完 成。 系统接管套接字并保证将 数据发送至对端。 非零 零 立即返回。 立即放弃。 直接发送 RST 包，自身立 即复位，不用经过 2MSL 状态。对端收到复位错误 号。 非零 非零 阻塞直到 l_linger 时间超时或 数据发送完成。(套接字必须设 置为阻塞) 在超时时间段内 保持尝试发送， 若超时则立即放 弃。 超时则同第二种情况，若 发送完成则皆大欢喜。 Socket 中操作该属性的方法如下： void setSoLinger(boolean on, int linger) 启用/禁用具有指定逗留时间（以秒为单位）的 SO_LINGER。 Linger 最大取值为 65535。 int getSoLinger() 返回 SO_LINGER 的设置。默认值为 -1。 由于 getSoLinger()方法返回的-1 没有太多意思，我们查看到 Java 的默认实现 PlainSocketImpl.c 文件中，赋值操作代码片段如下所示。 /* * Class: java_net_PlainSocketImpl * Method: socketSetOption * Signature: (IZLjava/lang/Object;)V */ JNIEXPORT void JNICALL Java_java_net_PlainSocketImpl_socketSetOption(JNIEnv *env, jobject this, jint cmd, jboolean on, jobject value) switch (cmd) case java_net_SocketOptions_SO_SNDBUF : case java_net_SocketOptions_SO_RCVBUF : case java_net_SocketOptions_SO_LINGER : case java_net_SocketOptions_IP_TOS : if (cmd = java_net_SocketOptions_SO_LINGER) if (on) optval.ling.l_onoff = 1; optval.ling.l_linger = (*env)-GetIntField(env, value, fid); else optval.ling.l_onoff = 0; optval.ling.l_linger = 0; optlen = sizeof(optval.ling); else optval.i = (*env)-GetIntField(env, value, fid); optlen = sizeof(optval.i); break; /* Boolean - int */ default : optval.i = (on ? 1 : 0); optlen = sizeof(optval.i); 从蓝色字体部分代码可以看出，只要赋值为 false，则底层 linger 结构中的 l_onoff 和 l_linger 的值 均为 0，符合表中的第一种情况。 1.5 SO_SNDBUF 发送缓冲区的大小设置，默认为 8K。 Socket 中操作该属性的方法如下： void setSendBufferSize(int size) 将此 Socket 的 SO_SNDBUF 选项设置为指定的值。 int getSendBufferSize() 获取此 Socket 的 SO_SNDBUF 选项的值，该值是平台在 Socket 上输出时使用的缓冲区大小。 1.6 SO_RCVBUF 接收缓冲区大小设置，默认为 8K。该属性既可以在 ServerSocket 实例中设置，也可以在 Socket 实例中设置。 ServerSocket/Socket 中操作该属性的方法如下： void setReceiveBufferSize(int size) 将此 Socket 的 SO_RCVBUF 选项设置为指定的值。 int getReceiveBufferSize() 获取此 Socket 的 SO_RCVBUF 选项的值，该值是平台在 Socket 上输入时使用的缓冲区大小。 1.7 SO_KEEPALIVE 套接字本身是有一套心跳保活机制的，不过默认的设置并不像我们一厢情愿的那样有效。在双方 TCP 套接字建立连接后（即都进入 ESTABLISHED 状态）并且在两个小时左右上层没有任何数据传输的情 况下，这套机制才会被激活。 很多人认为两个小时的时间设置得很不合理。为什么不设置成为 10 分钟，或者更短的时间？（可以 通过 SO_KEEPALIVE 选项设置。 ）但是这样做其实并不被推荐。实际上这套机制只是操作系统底层使用的 一个被动机制，原理上不应该被上层应用层使用。当系统关闭一个由 KEEPALIVE 机制检查出来的死连接 时，是不会主动通知上层应用的，只有在调用相应的 IO 操作在返回值中检查出来。 在UNIX 网络编程第 1 卷中也有详细的阐述： SO_KEEPALIVE 保持连接检测对方主机是否崩溃，避免（服务器）永远阻塞于 TCP 连接的输入。设 置该选项后，如果 2 小时内在此套接口的任一方向都没有数据交换， TCP 就自动给对方 发一个保持存活 探测分节(keepalive probe)。这是一个对方必须响应的 TCP 分节. 它会导致以下三种情况：对方接收一切 正常：以期望的 ACK 响应。2 小时后，TCP 将发出另一个探测分节。对方已崩溃且已重新启动：以 RST 响应。套接口的待处理错误被置为 ECONNRESET，套接口本身则被关闭。对方无任何响应：源自 berkeley 的 TCP 发送另外 8 个探测分节，相隔 75 秒一个，试图得到一个响应。在发出第一个探测分节 11 分钟 15 秒后若仍无响应就放弃。套接口的待处理错误被置为 ETIMEOUT，套接口本身则被关闭。如 ICMP 错误是“host unreachable(主机不可达)” ，说明对方主机并没有崩溃，但是不可达，这种情况下 待处理错误被置为 EHOSTUNREACH。 因此，忘记 SO_KEEPALIVE，在应用层自己写一套保活机制比较靠谱。 Socket 中操作该属性的方法如下： boolean getKeepAlive() 测试是否启用 SO_K