java.net.ServerSocket详解

先介绍介绍网络知识

TCP/IP协议

TCP/IP是个协议组，可分为三个层次：网络层、传输层和应用层。
在网络层有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议。
在传输层中有TCP协议与UDP协议。
在应用层有FTP、HTTP、TELNET、SMTP、DNS等协议。
因此，HTTP本身就是一个协议，是从Web服务器传输超文本到本地浏览器的传送协议。
TCP有一个连接检测机制，就是如果在指定的时间内（一般为2个小时）没有数据传送，会给对端发送一个Keep-Alive数据报，使用的序列号是曾经发出的最后一个报文的最后一个字节的序列号，对端如果收到这个数据，回送一个TCP的ACK，确认这个字节已经收到，这样就知道此连接没有被断开。如果一段时间没有收到对方的响应，会进行重试，重试几次后，向对端发一个reset，然后将连接断掉。
在Windows中，第一次探测是在最后一次数据发送的两个小时，然后每隔1秒探测一次，一共探测5次，如果5次都没有收到回应的话，就会断开这个连接。

HTTP协议

HTTP协议是建立在请求/响应模型上的。首先由客户建立一条与服务器的TCP链接，并发送一个请求到服务器，请求中包含请求方法、URI、协议版本以及相关的MIME样式的消息。服务器响应一个状态行，包含消息的协议版本、一个成功和失败码以及相关的MIME式样的消息。
HTTP/1.0为每一次HTTP的请求/响应建立一条新的TCP链接，因此一个包含HTML内容和图片的页面将需要建立多次的短期的TCP链接。一次TCP链接的建立将需要3次握手。
另外，为了获得适当的传输速度，则需要TCP花费额外的回路链接时间（RTT）。每一次链接的建立需要这种经常性的开销，而其并不带有实际有用的数据，只是保证链接的可靠性，因此HTTP/1.1提出了可持续链接的实现方法。HTTP/1.1将只建立一次TCP的链接而重复地使用它传输一系列的请求/响应消息，因此减少了链接建立的次数和经常性的链接开销。

Socket

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。

ServerSocket重要属性

backlog

用于ServerSocket，配置ServerSocket的最大客户端等待队列。等待队列的意思。
下面这个服务器最多可以同时连接3个客户端，其中2个等待队列：

int backlog = 2;ServerSocket serverSocket = new ServerSocket(port, backlog);

这个参数设置为-1表示无限制，默认是50个最大等待队列，如果设置无限制，那么你要小心了，如果你服务器无法处理那么多连接，那么当很多客户端连到你的服务器时，每一个TCP连接都会占用服务器的内存，最后会让服务器崩溃的。
另外，就算你设置了backlog为10，如果你的代码中是一直Socket clientSock = serverSocket.accept(),假设我们的机器最多可以同时处理100个请求，总共有100个线程在运行，然后你把在100个线程的线程池处理clientSock，不能处理的clientSock就排队，最后clientSock越来越多，也意味着TCP连接越来越多，也意味着我们的服务器的内存使用越来越高(客户端连接进程，肯定会发送数据过来，数据会保存到服务器端的TCP接收缓存区)，最后服务器就宕机了。所以如果你不能处理那么多请求，请不要循环无限制地调用serverSocket.accept(),否则backlog也无法生效。如果真的请求过多，只会让你的服务器宕机(相信很多人都是这么写，要注意点)

TcpNoDelay

public boolean getTcpNoDelay() throws SocketExceptionpublic void setTcpNoDelay(boolean on) throws SocketException

在默认情况下，客户端向服务器发送数据时，会根据数据包的大小决定是否立即发送。当数据包中的数据很少时，如只有1个字节，而数据包的头却有几十个字节（IP头+TCP头）时，系统会在发送之前先将较小的包合并到软大的包后，一起将数据发送出去。在发送下一个数据包时，系统会等待服务器对前一个数据包的响应，当收到服务器的响应后，再发送下一个数据包，这就是所谓的Nagle算法；在默认情况下，Nagle算法是开启的。
这种算法虽然可以有效地改善网络传输的效率，但对于网络速度比较慢，而且对实现性的要求比较高的情况下（如游戏、Telnet等），使用这种方式传输数据会使得客户端有明显的停顿现象。因此，最好的解决方案就是需要Nagle算法时就使用它，不需要时就关闭它。而使用setTcpToDelay正好可以满足这个需求。当使用setTcpNoDelay（true）将Nagle算法关闭后，客户端每发送一次数据，无论数据包的大小都会将这些数据发送出去。
当我们调用下面代码，如:

Socket socket = new Socket();  socket.connect(new InetSocketAddress(host, 8000));  InputStream in = socket.getInputStream();  OutputStream out = socket.getOutputStream();  String head = "hello ";  String body = "world\r\n";  out.write(head.getBytes());  out.write(body.getBytes());

我们发送了hello，当hello没有收到ack确认(TCP是可靠连接，发送的每一个数据都要收到对方的一个ack确认，否则就要重发)的时候，根据纳格算法，world不会立马发送，会等待，要么等到ack确认(最多等100ms对方会发过来的)，要么等到TCP缓冲区内容>=MSS，很明显这里没有机会，我们写了world后再也没有写数据了，所以只能等到hello的ack我们才会发送world，除非我们禁用纳格算法，数据就会立即发送了。
纳格算法参考:http://zh.wikipedia.org/wiki/%E7%B4%8D%E6%A0%BC%E7%AE%97%E6%B3%95
另外有一篇讲解纳格算法和delay ack的文章(挺不错的):http://blog.csdn.net/frankggyy/article/details/6624401
对于交互型的应用（譬如telnet），经常存在的情况是客户端和服务端之间需要频繁地进行一些小数据交换，譬如telnet可能每敲一个键盘都需要将数据发送到服务端。为了避免这种情况会产生大量小数据包，提出了Nagle算法。Nagle算法要求每次在发送端最后只有一个未被确认的包，因此上一个包发送出去还没有接收到响应之前，要求发送的包回先放在缓冲区，接收到响应之后，会将缓冲区中的包合并成一个包发送出去（可以看到，响应回地越快，发送出去的数据也会越快）。
需要注意的是，由Nagle算法要求只能有一个未被确认的包，因此窗口参数会失效，在大数据量传送的情况下会使网络吞吐量下降，因此对于大数据量的交互，应该关闭Nagle算法，Nagle算法比较适合小数据量频繁交换的情景。我们可以使用TCP_NODELAY关闭Nagle算法。

SoLinger

public int getSoLinger() throws SocketExceptionpublic void setSoLinger(boolean on, int linger) throws SocketException

这个Socket选项可以影响close方法的行为。在默认情况下，当调用close方法后，将立即返回；如果这时仍然有未被送出的数据包，那么这些数据包将被丢弃。如果将linger参数设为一个正整数n时（n的值最大是65，535），在调用close方法后，将最多被阻塞n秒。在这n秒内，系统将尽量将未送出的数据包发送出去；如果超过了n秒，如果还有未发送的数据包，这些数据包将全部被丢弃；而close方法会立即返回。如果将linger设为0，和关闭SO_LINGER选项的作用是一样的。
如果底层的Socket实现不支持SO_LINGER都会抛出SocketException例外。当给linger参数传递负数值时，setSoLinger还会抛出一个IllegalArgumentException例外。可以通过getSoLinger方法得到延迟关闭的时间，如果返回-1，则表明SO_LINGER是关闭的。例如，下面的代码将延迟关闭的时间设为1分钟：

if(socket.getSoLinger() == -1) socket.setSoLinger(true, 60);

当我们调用socket.close()返回时，socket已经write的数据未必已经发送到对方了，例如

Socket socket = new Socket();  socket.connect(new InetSocketAddress(host, 8000));  InputStream in = socket.getInputStream();  OutputStream out = socket.getOutputStream();  String head = "hello ";  String body = "world\r\n";  out.write(head.getBytes());  out.write(body.getBytes()); socket.close();

这里调用了socket.close()返回时,hello和world未必已经成功发送到对方了，如果我们设置了linger而不小于0，如:

bool on = true;int linger = 100;....socket.setSoLinger(boolean on, int linger)......socket.close();

那么close会等到发送的数据已经确认了才返回。但是如果对方宕机，超时，那么会根据linger设定的时间返回。

UrgentData和OOBInline

TCP的紧急指针，一般都不建议使用，而且不同的TCP/IP实现，也不同，一般说如果你有紧急数据宁愿再建立一个新的TCP/IP连接发送数据，让对方紧急处理。
所以这两个参数，你们可以忽略吧，想知道更多的，自己查下资料。

SoTimeout

public int getSoTimeout() throws SocketExceptionpublic void setSoTimeout(int timeout) throws SocketException

这个Socket选项在前面已经讨论过。可以通过这个选项来设置读取数据超时。当输入流的read方法被阻塞时，如果设置timeout（timeout的单位是毫秒），那么系统在等待了timeout毫秒后会抛出一个InterruptedIOException例外。在抛出例外后，输入流并未关闭，你可以继续通过read方法读取数据。
如果将timeout设为0，就意味着read将会无限等待下去，直到服务端程序关闭这个Socket.这也是timeout的默认值。如下面的语句将读取数据超时设为30秒：

socket1.setSoTimeout(30 * 1000);

当底层的Socket实现不支持SO_TIMEOUT选项时，这两个方法将抛出SocketException例外。不能将timeout设为负数，否则setSoTimeout方法将抛出IllegalArgumentException例外。
设置socket调用InputStream读数据的超时时间，以毫秒为单位，如果超过这个时候，会抛出java.net.SocketTimeoutException。

KeepAlive

public boolean getKeepAlive() throws SocketExceptionpublic void setKeepAlive(boolean on) throws SocketException

如果将这个Socket选项打开，客户端Socket每隔段的时间（大约两个小时）就会利用空闲的连接向服务器发送一个数据包。这个数据包并没有其它的作用，只是为了检测一下服务器是否仍处于活动状态。如果服务器未响应这个数据包，在大约11分钟后，客户端Socket再发送一个数据包，如果在12分钟内，服务器还没响应，那么客户端Socket将关闭。如果将Socket选项关闭，客户端Socket在服务器无效的情况下可能会长时间不会关闭。SO_KEEPALIVE选项在默认情况下是关闭的，可以使用如下的语句将这个SO_KEEPALIVE选项打开：

socket1.setKeepAlive(true);

keepalive不是说TCP的常连接，当我们作为服务端，一个客户端连接上来，如果设置了keeplive为true，当对方没有发送任何数据过来，超过一个时间(看系统内核参数配置)，那么我们这边会发送一个ack探测包发到对方，探测双方的TCP/IP连接是否有效(对方可能断点，断网)，在Linux好像这个时间是75秒。如果不设置，那么客户端宕机时，服务器永远也不知道客户端宕机了，仍然保存这个失效的连接。
SO_KEEPALIVE 保持连接检测对方主机是否崩溃，避免（服务器）永远阻塞于TCP连接的输入。
设置该选项后，如果2小时内在此套接口的任一方向都没有数据交换，TCP就自动给对方 发一个保持存活探测分节(keepalive probe)。这是一个对方必须响应的TCP分节.它会导致以下三种情况：
1、对方接收一切正常：以期望的ACK响应，2小时后，TCP将发出另一个探测分节。
2、对方已崩溃且已重新启动：以RST响应。套接口的待处理错误被置为ECONNRESET，套接 口本身则被关闭。
3、对方无任何响应：源自berkeley的TCP发送另外8个探测分节，相隔75秒一个，试图得到一个响应。在发出第一个探测分节11分钟15秒后若仍无响应就放弃。套接口的待处理错误被置为ETIMEOUT，套接口本身则被关闭。如ICMP错误是“host unreachable(主机不可达)”，说明对方主机并没有崩溃，但是不可达，这种情况下待处理错误被置为 EHOSTUNREACH。
有关SO_KEEPALIVE的三个参数详细解释如下:
（16）tcp_keepalive_intvl，保活探测消息的发送频率。默认值为75s。
发送频率tcp_keepalive_intvl乘以发送次数tcp_keepalive_probes，就得到了从开始探测直到放弃探测确定连接断开的时间，大约为11min。
（17）tcp_keepalive_probes，TCP发送保活探测消息以确定连接是否已断开的次数。默认值为9（次）。
注意：只有设置了SO_KEEPALIVE套接口选项后才会发送保活探测消息。
（18）tcp_keepalive_time，在TCP保活打开的情况下，最后一次数据交换到TCP发送第一个保活探测消息的时间，即允许的持续空闲时间。默认值为7200s（2h）。
在一个TCP连接建立之后，我们会很奇怪地发现，默认情况下，如果一端异常退出（譬如网络中断后一端退出，使地关闭请求另一端无法接收到），TCP的另一端并不能获得这种情况，仍然会保持一个半关闭的连接，对于服务端，大量半关闭的连接将会是非常致命的。SO_KEEPALIVE提供了一种手段让TCP的一端（通常服务提供者端）可以检测到这种情况。如果我们设置了SO_KEEPALIVE，TCP在距离上一次TCP包交互2个小时（取决于操作系统和TCP实现，规范建议不低于2小时）后，会发送一个探测包给另一端，如果接收不到响应，则在75秒后重新发送，连续10次仍然没有响应，则认为对方已经关闭，系统会将该连接关闭。一般情况下，如果对方已经关闭，则对方的TCP层会回RST响应回来，这种情况下，同样会将连接关闭。

SendBufferSize和ReceiveBufferSize

TCP发送缓存区和接收缓存区,默认是8192，一般情况下足够了，而且就算你增加了发送缓存区，对方没有增加它对应的接收缓冲，那么在TCP三握手时，最后确定的最大发送窗口还是双方最小的那个缓冲区，就算你无视，发了更多的数据，那么多出来的数据也会被丢弃。除非双方都协商好。

SO_REUSEADDR

public boolean getReuseAddress() throws SocketException           public void setReuseAddress(boolean on) throws SocketException

错误的说法：
通过这个选项，可以使多个Socket对象绑定在同一个端口上。
正确的说明是：
如果端口忙，但TCP状态位于 TIME_WAIT ，可以重用 端口。如果端口忙，而TCP状态位于其他状态，重用端口时依旧得到一个错误信息， 抛出“Address already in use： JVM_Bind”。如果你的服务程序停止后想立即重启，不等60秒，而新套接字依旧 使用同一端口，此时 SO_REUSEADDR 选项非常有用。必须意识到，此时任何非期 望数据到达，都可能导致服务程序反应混乱，不过这只是一种可能，事实上很不可能。
这个参数在Windows平台与Linux平台表现的特点不一样。在Windows平台表现的特点是不正确的， 在Linux平台表现的特点是正确的。
在Windows平台，多个Socket新建立对象可以绑定在同一个端口上，这些新连接是非TIME_WAIT状态的。这样做并没有多大意义。
在Linux平台，只有TCP状态位于 TIME_WAIT ，才可以重用 端口。这才是正确的行为。

public class Test {    public static void main(String[] args) {        try {            ServerSocket socket1 = new ServerSocket();            ServerSocket socket2 = new ServerSocket();            socket1.setReuseAddress(true);            socket1.bind(new InetSocketAddress("127.0.0.1", 8899));            System.out.println("socket1.getReuseAddress():"+ socket1.getReuseAddress());            socket2.setReuseAddress(true);            socket2.bind(new InetSocketAddress("127.0.0.1", 8899));            System.out.println("socket2.getReuseAddress():"+ socket1.getReuseAddress());        } catch (Exception e) {            e.printStackTrace();        }    }}

使用SO_REUSEADDR选项时有两点需要注意：
1. 必须在调用bind方法之前使用setReuseAddress方法来打开SO_REUSEADDR选项。因此，要想使用SO_REUSEADDR选项，就不能通过Socket类的构造方法来绑定端口。
2. 必须将绑定同一个端口的所有的Socket对象的SO_REUSEADDR选项都打开才能起作用。如在例程4-12中，socket1和socket2都使用了setReuseAddress方法打开了各自的SO_REUSEADDR选项。
在Windows操作系统上运行上面的代码的运行结果如下：
这种结果是不正确的。

socket1.getReuseAddress():truesocket2.getReuseAddress():true

在Linux操作系统上运行上面的代码的运行结果如下：
这种结果是正确的。因为第一个连接不是TIME_WAIT状态的，第二个连接就不能使用8899端口；
只有第一个连接是TIME_WAIT状态的，第二个连接就才能使用8899端口；

socket1.getReuseAddress():truejava.net.BindException: Address already in use    at java.net.PlainSocketImpl.socketBind(Native Method)    at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383)    at java.net.ServerSocket.bind(ServerSocket.java:328)    at java.net.ServerSocket.bind(ServerSocket.java:286)    at com.Test.main(Test.java:15)

SO_SNDBUF

public int getSendBufferSize() throws SocketExceptionpublic void setSendBufferSize(int size) throws SocketException

在默认情况下，输出流的发送缓冲区是8096个字节（8K）。这个值是Java所建议的输出缓冲区的大小。如果这个默认值不能满足要求，可以用setSendBufferSize方法来重新设置缓冲区的大小。但最好不要将输出缓冲区设得太小，否则会导致传输数据过于频繁，从而降低网络传输的效率。
如果底层的Socket实现不支持SO_SENDBUF选项，这两个方法将会抛出SocketException例外。必须将size设为正整数，否则setSendBufferedSize方法将抛出IllegalArgumentException例外。

SO_RCVBUF

public int getReceiveBufferSize() throws SocketExceptionpublic void setReceiveBufferSize(int size) throws SocketException

在默认情况下，输入流的接收缓冲区是8096个字节（8K）。这个值是Java所建议的输入缓冲区的大小。如果这个默认值不能满足要求，可以用setReceiveBufferSize方法来重新设置缓冲区的大小。但最好不要将输入缓冲区设得太小，否则会导致传输数据过于频繁，从而降低网络传输的效率。
如果底层的Socket实现不支持SO_RCVBUF选项，这两个方法将会抛出SocketException例外。必须将size设为正整数，否则setReceiveBufferSize方法将抛出IllegalArgumentException例外。

SO_OOBINLINE

 public boolean getOOBInline() throws SocketException public void setOOBInline(boolean on) throws SocketException

如果这个Socket选项打开，可以通过Socket类的sendUrgentData方法向服务器发送一个单字节的数据。这个单字节数据并不经过输出缓冲区，而是立即发出。虽然在客户端并不是使用OutputStream向服务器发送数据，但在服务端程序中这个单字节的数据是和其它的普通数据混在一起的。因此，在服务端程序中并不知道由客户端发过来的数据是由OutputStream还是由sendUrgentData发过来的。下面是sendUrgentData方法的声明：

public void sendUrgentData(int data) throws IOException

虽然sendUrgentData的参数data是int类型，但只有这个int类型的低字节被发送，其它的三个字节被忽略。下面的代码演示了如何使用SO_OOBINLINE选项来发送单字节数据。

package mynet;import java.net.*;import java.io.*;class Server{    public static void main(String[] args) throws Exception    {        ServerSocket serverSocket = new ServerSocket(1234);        System.out.println("服务器已经启动，端口号：1234");        while (true)        {            Socket socket = serverSocket.accept();            socket.setOOBInline(true);            InputStream in = socket.getInputStream();            InputStreamReader inReader = new InputStreamReader(in);            BufferedReader bReader = new BufferedReader(inReader);            System.out.println(bReader.readLine());            System.out.println(bReader.readLine());            socket.close();        }    }}public class Client{    public static void main(String[] args) throws Exception    {        Socket socket = new Socket("127.0.0.1", 1234);        socket.setOOBInline(true);        OutputStream out = socket.getOutputStream();        OutputStreamWriter outWriter = new OutputStreamWriter(out);        outWriter.write(67);              // 向服务器发送字符"C"        outWriter.write("hello world\r\n");        socket.sendUrgentData(65);        // 向服务器发送字符"A"        socket.sendUrgentData(322);        // 向服务器发送字符"B"        outWriter.flush();        socket.sendUrgentData(214);       // 向服务器发送汉字”中”        socket.sendUrgentData(208);        socket.sendUrgentData(185);       // 向服务器发送汉字”国”        socket.sendUrgentData(250);        socket.close();    }}

由于运行上面的代码需要一个服务器类，因此，在加了一个类名为Server的服务器类，关于服务端套接字的使用方法将会在后面的文章中详细讨论。在类Server类中只使用了ServerSocket类的accept方法接收客户端的请求。并从客户端传来的数据中读取两行字符串，并显示在控制台上。

测试

由于本例使用了127.0.0.1，因Server和Client类必须在同一台机器上运行。
运行Server

java mynet.Server

运行Client

java mynet.Client

在服务端控制台的输出结果

服务器已经启动，端口号：1234ABChello world中国

在ClienT类中使用了sendUrgentData方法向服务器发送了字符’A’（65）和’B’（66）。但发送’B’时实际发送的是322，由于sendUrgentData只发送整型数的低字节。因此，实际发送的是66.十进制整型322的二进制形式如图1所示。
图1 十进制整型322的二进制形式

从图1可以看出，虽然322分布在了两个字节上，但它的低字节仍然是66.
在Client类中使用flush将缓冲区中的数据发送到服务器。我们可以从输出结果发现一个问题，在Client类中先后向服务器发送了’C’、”hello world”r”n”、’A’、’B’.而在服务端程序的控制台上显示的却是ABChello world.这种现象说明使用sendUrgentData方法发送数据后，系统会立即将这些数据发送出去；而使用write发送数据，必须要使用flush方法才会真正发送数据。
在Client类中向服务器发送”中国”字符串。由于”中”是由214和208两个字节组成的；而”国”是由185和250两个字节组成的；因此，可分别发送这四个字节来传送”中国”字符串。
注意：在使用setOOBInline方法打开SO_OOBINLINE选项时要注意是必须在客户端和服务端程序同时使用setOOBInline方法打开这个选项，否则无法命名用sendUrgentData来发送数据。

SO_LINGER/ SO_REUSEADDR

TCP正常的关闭过程如下（四次握手过程）：

(FIN_WAIT_1) A —FIN—> B(CLOSE_WAIT)
(FIN_WAIT_2) A <–ACK– B(CLOSE_WAIT)
(TIME_WAIT)A <–FIN—- B(LAST_ACK)
(TIME_WAIT)A —ACK-> B(CLOSED)
Ø A端首先发送一个FIN请求给B端，要求关闭，发送后A段的TCP状态变更为FIN_WAIT_1，接收到FIN请求后B端的TCP状态变更为CLOSE_WAIT
Ø B接收到ACK请求后，B回一个ACK给A端，确认接收到的FIN请求，接收到ACK请求后，A端的TCP状态变更为为FIN_WAIT_2。
Ø B端再发送一个FIN请求给A端，与连接过程的3次握手过程不一样，这个FIN请求之所以并不是与上一个请求一起发送，之所以如此处理，是因为TCP是双通道的，允许在发送ACK请求后，并不马上发FIN请求，即只关闭A到B端的数据流，仍然允许B端到A端的数据流。这个ACK请求发送之后，B端的TCP状态变更为LAST_ACK，A端的状态变更为TIME_WAIT。
Ø A端接收到B端的FIN请求后，再回B端一个ACK信息，对上一个FIN请求进行确认，到此时B端状态变更为CLOSED，Socket可以关闭。
除了如上正常的关闭（优雅关闭）之外，TCP还提供了另外一种非优雅的关闭方式RST(Reset)
(CLOSED) A —RST–> B (CLOSED)
Ø A端发送RST状态之后，TCP进入CLOSED状态，B端接收到RST后，也即可进入CLOSED状态。
在第一种关闭方式上（优雅关闭），非常遗憾，A端在最后发送一个ACK请求后，并不能马上将该Socket回收，因为A并不能确定B一定能够接收到这个ACK请求，因此A端必须对这个Socket维持TIME_WAIT状态2MSL(MSL=Max Segment Lifetime，取决于操作系统和TCP实现，该值为30秒、60秒或2分钟)。如果A端是客户端，这并不会成为问题，但如果A端是服务端，那就很危险了，如果连接的Socket非常多，而又维持如此多的TIME_WAIT状态的话，那么有可能会将Socket耗尽（报Too Many Open File）。
服务端为了解决这个TIME_WAIT问题，可选择的方式有三种：
Ø 保证由客户端主动发起关闭（即做为B端）
Ø 关闭的时候使用RST的方式
Ø 对处于TIME_WAIT状态的TCP允许重用
一般我们当然最好是选择第一种方式，实在没有办法的时候，我们可以使用SO_LINGER选择第二种方式，使用SO_REUSEADDR选择第三种方式
Java代码 收藏代码
public void setSoLinger(boolean on, int linger) throws SocketException
public void setReuseAddress(boolean on) throws SocketException
第一个on表示是否使用SO_LINGER选项，linger（以秒为单位）表示在发RST之前会等待多久，因为一旦发送RST，还在缓冲区中还没有发送出去的数据就会直接丢弃。

保持socket长连接

在实际开发中我们常常会遇到：如何保证socket长连接？
这方面一般来说比较成熟的有两种方法：

自己心跳

在应用层制定协议，发心跳包，这也是C#，JAVA等高级语言比较常用的方法。客户端和服务端制定一个通讯协议，每隔一定时间（一般15秒左右），由一方发起，向对方发送协议包；对方收到这个包后，按指定好的通讯协议回一个。若没收到回复，则判断网络出现问题，服务器可及时的断开连接，客户端也可以及时重连。

依赖KeepAlive

通过TCP协议层发送KeepAlive包。这个方法只需设置好你使用的TCP的KeepAlive项就好，其他的操作系统会帮你完成。操作系统会按时发送KeepAlive包，一发现网络异常，马上断开。我就是使用这个方法，也是重点向大家介绍的。
使用第二种方法的好处，是我们在应用层不需自己定协议，通信的两端，只要有一端设好这个值，两边都能及时检测出TCP连接情况。而且这些都是操作系统帮你自动完成的。有的公司的服务端代码就是早写好的，很难改动。以前也没加入心跳机制，后面要改很麻烦，要求检测连接的工作尽量客户端单独完成。
还有一个好处就是节省网络资源。KeepAlive包，只有很简单的一些TCP信息，无论如何也是比你自己设计的心跳包短小的。然后就是它的发送机制，在TCP空闲XXX秒后才开始发送。自己设计心跳机制的话，很难做到这一点。
这种方法也是有些缺陷的。比如某一时刻，网线松了，如果刚好被KeepAlive包检测到，它会马上断开TCP连接。但其实这时候TCP连接也算是established的，只要网线再插好，这个连接还是可以正常工作的。
一般KeepAlive设定TCP15秒钟空闲。

KeepAlive详细介绍

什么是keepalive定时器？

在一个空闲的（idle）TCP连接上，没有任何的数据流，许多TCP/IP的初学者都对此感到惊奇。也就是说，如果TCP连接两端没有任何一个进程在向对方发送数据，那么在这两个TCP模块之间没有任何的数据交换。你可能在其它的网络协议中发现有轮询（polling），但在TCP中它不存在。言外之意就是我们只要启动一个客户端进程，同服务器建立了TCP连接，不管你离开几小时，几天，几星期或是几个月，连接依旧存在。中间的路由器可能崩溃或者重启，电话线可能go down或者back up，只要连接两端的主机没有重启，连接依旧保持建立。
这就可以认为不管是客户端的还是服务器端的应用程序都没有应用程序级（application-level）的定时器来探测连接的不活动状态（inactivity），从而引起任何一个应用程序的终止。然而有的时候，服务器需要知道客户端主机是否已崩溃并且关闭，或者崩溃但重启。许多实现提供了存活定时器来完成这个任务。
存活定时器是一个包含争议的特征。许多人认为，即使需要这个特征，这种对对方的轮询也应该由应用程序来完成，而不是由TCP中实现。此外，如果两个终端系统之间的某个中间网络上有连接的暂时中断，那么存活选项（option）就能够引起两个进程间一个良好连接的终止。例如，如果正好在某个中间路由器崩溃、重启的时候发送存活探测，TCP就将会认为客户端主机已经崩溃，但事实并非如此。
存活（keepalive）并不是TCP规范的一部分。在Host Requirements RFC罗列有不使用它的三个理由：（1）在短暂的故障期间，它们可能引起一个良好连接（good connection）被释放（dropped），（2）它们消费了不必要的宽带，（3）在以数据包计费的互联网上它们（额外）花费金钱。然而，在许多的实现中提供了存活定时器。
一些服务器应用程序可能代表客户端占用资源，它们需要知道客户端主机是否崩溃。存活定时器可以为这些应用程序提供探测服务。Telnet服务器和Rlogin服务器的许多版本都默认提供存活选项。
个人计算机用户使用TCP/IP协议通过Telnet登录一台主机，这是能够说明需要使用存活定时器的一个常用例子。如果某个用户在使用结束时只是关掉了电源，而没有注销（log off），那么他就留下了一个半打开（half-open）的连接。在图18.16，我们看到如何在一个半打开连接上通过发送数据，得到一个复位（reset）返回，但那是在客户端，是由客户端发送的数据。如果客户端消失，留给了服务器端半打开的连接，并且服务器又在等待客户端的数据，那么等待将永远持续下去。存活特征的目的就是在服务器端检测这种半打开连接。

keepalive如何工作？

在此描述中，我们称使用存活选项的那一段为服务器，另一端为客户端。也可以在客户端设置该选项，且没有不允许这样做的理由，但通常设置在服务器。如果连接两端都需要探测对方是否消失，那么就可以在两端同时设置（比如NFS）。
若在一个给定连接上，两小时之内无任何活动，服务器便向客户端发送一个探测段。（我们将在下面的例子中看到探测段的样子。）客户端主机必须是下列四种状态之一：
1) 客户端主机依旧活跃（up）运行，并且从服务器可到达。从客户端TCP的正常响应，服务器知道对方仍然活跃。服务器的TCP为接下来的两小时复位存活定时器，如果在这两个小时到期之前，连接上发生应用程序的通信，则定时器重新为往下的两小时复位，并且接着交换数据。
2) 客户端已经崩溃，或者已经关闭（down），或者正在重启过程中。在这两种情况下，它的TCP都不会响应。服务器没有收到对其发出探测的响应，并且在75秒之后超时。服务器将总共发送10个这样的探测，每个探测75秒。如果没有收到一个响应，它就认为客户端主机已经关闭并终止连接。
3) 客户端曾经崩溃，但已经重启。这种情况下，服务器将会收到对其存活探测的响应，但该响应是一个复位，从而引起服务器对连接的终止。
4) 客户端主机活跃运行，但从服务器不可到达。这与状态2类似，因为TCP无法区别它们两个。它所能表明的仅是未收到对其探测的回复。
服务器不必担心客户端主机被关闭然后重启的情况（这里指的是操作员执行的正常关闭，而不是主机的崩溃）。当系统被操作员关闭时，所有的应用程序进程（也就是客户端进程）都将被终止，客户端TCP会在连接上发送一个FIN。收到这个FIN后，服务器TCP向服务器进程报告一个文件结束，以允许服务器检测这种状态。
在第一种状态下，服务器应用程序不知道存活探测是否发生。凡事都是由TCP层处理的，存活探测对应用程序透明，直到后面2，3，4三种状态发生。在这三种状态下，通过服务器的TCP，返回给服务器应用程序错误信息。（通常服务器向网络发出一个读请求，等待客户端的数据。如果存活特征返回一个错误信息，则将该信息作为读操作的返回值返回给服务器。）在状态2，错误信息类似于“连接超时”。状态3则为“连接被对方复位”。第四种状态看起来像连接超时，或者根据是否收到与该连接相关的ICMP错误信息，而可能返回其它的错误信息。
windows 实现:
在一个正常的TCP连接上，当我们用无限等待的方式调用下面的Recv或Send的时候：

   ret=recv(s,&buf[idx],nLeft,flags);

或

   ret=send(s,&buf[idx],nLeft,flags);

如果TCP连接被对方正常关闭，也就是说，对方是正确地调用了closesocket(s)或者shutdown(s)的话，那么上面的Recv或Send调用就能马上返回，并且报错。这是由于closesocket(s)或者shutdown(s)有个正常的关闭过程，会告诉对方“TCP连接已经关闭，你不需要再发送或者接受消息了”。但是，如果是网线突然被拔掉，TCP连接的任何一端的机器突然断电或重启动，那么这时候正在执行Recv或Send操作的一方就会因为没有任何连接中断的通知而一直等待下去，也就是会被长时间卡住。这种情形解决的办法是启动TCP编程里的keepAlive机制。

    struct TCP_KEEPALIVE inKeepAlive = {0};    unsigned long ulInLen = sizeof(struct TCP_KEEPALIVE);    struct TCP_KEEPALIVE utKeepAlive = {0};    unsigned long ulOutLen = sizeof(struct TCP_KEEPALIVE);    unsigned long ulBytesReturn = 0;    inKeepAlive.onoff=1;    inKeepAlive.keepaliveinterval=5000; //单位为毫秒    inKeepAlive.keepalivetime=1000;      //单位为毫秒    ret=WSAIoctl(s, SIO_KEEPALIVE_VALS, (LPVOID)&inKeepAlive, ulInLen,                           (LPVOID)&outKeepAlive, ulOutLen, &ulBytesReturn, NULL, NULL);

此处的keepalivetime表示的是TCP连接处于畅通时候的探测频率，一旦探测包没有返回，就以keepaliveinterval的频率发送，经过若干次的重试，如果探测包都没有返回，那么就得出结论：TCP连接已经断开，于是上面的Recv或Send调用也就能马上返回，不会无限制地卡住了。

什么是HTTP Keep Alive

HTTP Keep-Alive 很大程序上被误解了，下面介绍一下它在HTTP/1.0和HTTP/1.1版本下是如何工作的，以及其在JAVA中的运行原理及优化建议。
HTTP是一个请求<->响应模式的典型范例，即客户端向服务器发送一个请求信息，服务器来响应这个信息。在老的HTTP版本中，每个请求都将被创建一个新的客户端->服务器的连接，在这个连接上发送请求，然后接收请求。这样的模式有一个很大的优点就是，它很简单，很容易理解和编程实现；它也有一个很大的缺点就是，它效率很低，因此Keep-Alive被提出用来解决效率低的问题。
具体说，HTTP构建在TCP之上。在HTTP早期实现中，每个HTTP请求都要打开一个socket连接。这种做效率很低，因为一个Web 页面中的很多HTTP请求都指向同一个服务器。例如，很多为Web页面中的图片发起的请求都指向一个通用的图片服务器。持久连接的引入解决了多对已请求服务器导致的socket连接低效性的问题。它使浏览器可以再一个单独的连接上进行多个请求。浏览器和服务器使用Connection头ilai指出对Keep-Alive的支持。

HTTP/1.0

在HTTP/1.0版本中，并没有官方的标准来规定Keep-Alive如何工作，因此实际上它是被附加到HTTP/1.0协议上，如果客户端浏览器支持Keep-Alive，那么就在HTTP请求头中添加一个字段 Connection: Keep-Alive，当服务器收到附带有Connection: Keep-Alive的请求时，它也会在响应头中添加一个同样的字段来使用Keep-Alive。这样一来，客户端和服务器之间的HTTP连接就会被保持，不会断开（超过Keep-Alive规定的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接

HTTP/1.1

在HTTP/1.1版本中，官方规定的Keep-Alive使用标准和在HTTP/1.0版本中有些不同，默认情况下所在HTTP1.1中所有连接都被保持，除非在请求头或响应头中指明要关闭：Connection: Close ，这也就是为什么Connection: Keep-Alive字段再没有意义的原因。另外，还添加了一个新的字段Keep-Alive:，因为这个字段并没有详细描述用来做什么，可忽略它

HTTP Keep Alive的注意点

Not reliable（不可靠）

HTTP是一个无状态协议，这意味着每个请求都是独立的，Keep-Alive没能改变这个结果。另外，Keep-Alive也不能保证客户端和服务器之间的连接一定是活跃的，在HTTP1.1版本中也如此。唯一能保证的就是当连接被关闭时你能得到一个通知，所以不应该让程序依赖于Keep-Alive的保持连接特性，否则会有意想不到的后果

Keep-Alive和POST

在HTTP1.1细则中规定了在一个POST消息体后面不能有任何字符，还指出了对于某一个特定的浏览器可能并不遵循这个标准（比如在POST消息体的后面放置一个CRLF符）。而据我所知，大部分浏览器在POST消息体后都会自动跟一个CRLF符再发送，如何解决这个问题呢？根据上面的说明在POST请求头中禁止使用Keep-Alive，或者由服务器自动忽略这个CRLF，大部分服务器都会自动忽略，但是在未经测试之前是不可能知道一个服务器是否会这样做。

HTTP Keep Alive 优化例子与总结

例子分析

问题现象： 一个JSP页面，居然要耗时40多秒。网页中有大量的图片的CSS
问题解决： 原因也找了半天，原来Apache配置里面，把Keep-Alive的开关关闭了。这个是个大问题，工程师为什么要关闭它，原来他考虑的太简单了，我们知道Apache适合处于短连接的请求，处理时间越短，并发数才能上去，原来他是这么考虑，但是没有办法，只能这样了，还是打开Keep-Alive开关吧。
当然，不是所有的情况都设置KeepAlive为On，下面的文字总结比较好：
【在使用apache的过程中，KeepAlive属性我一直保持为默认值On，其实，该属性设置为On还是Off还是要具体问题具体分析的，在生产环境中的影响还是蛮大的。

KeepAlive选项到底有什么用处？如果你用过Mysql ，应该知道Mysql的连接属性中有一个与KeepAlive 类似的Persistent Connection，即：长连接(PConnect)。该属性打开的话，可以使一次TCP连接为同一用户的多次请求服务，提高了响应速度。
比如很多网页中图片、CSS、JS、Html都在一台Server上，当用户访问其中的Html网页时，网页中的图片、Css、Js都构成了访问请求，打开KeepAlive 属性可以有效地降低TCP握手的次数(当然浏览器对同一域下同时请求的图片数有限制，一般是2 见下文章节 减少域名解释的开销)，减少httpd进程数，从而降低内存的使用(假定prefork模式)。MaxKeepAliveRequests 和KeepAliveTimeOut 两个属性在KeepAlive =On时起作用，可以控制持久连接的生存时间和最大服务请求数。

不过，上面说的只是一种情形，那就是静态网页居多的情况下，并且网页中的其他请求与网页在同一台Server上。当你的应用动态程序(比如：php )居多，用户访问时由动态程序即时生成html内容，html内容中图片素材和Css、Js等比较少或者散列在其他Server上时，KeepAlive =On反而会降低Apache 的性能。为什么呢？
前面提到过，KeepAlive =On时，每次用户访问，打开一个TCP连接，Apache 都会保持该连接一段时间，以便该连接能连续为同一client服务，在KeepAliveTimeOut还没到期并且MaxKeepAliveRequests还没到阈值之前，Apache 必然要有一个httpd进程来维持该连接，httpd进程不是廉价的，他要消耗内存和CPU时间片的。假如当前Apache 每秒响应100个用户访问，KeepAliveTimeOut=5，此时httpd进程数就是100*5=500个(prefork 模式)，一个httpd进程消耗5M内存的话，就是500*5M=2500M=2.5G，夸张吧？当然，Apache 与Client只进行了100次TCP连接。如果你的内存够大，系统负载不会太高，如果你的内存小于2.5G，就会用到Swap，频繁的Swap切换会加重CPU的Load。

现在我们关掉KeepAlive ，Apache 仍然每秒响应100个用户访问，因为我们将图片、js、css等分离出去了，每次访问只有1个request，此时httpd的进程数是100*1=100个，使用内存100*5M=500M，此时Apache 与Client也是进行了100次TCP连接。性能却提升了太多。

总结

1、当你的Server内存充足时，KeepAlive =On还是Off对系统性能影响不大。
2、当你的Server上静态网页(Html、图片、Css、Js)居多时，建议打开KeepAlive 。
3、当你的Server多为动态请求(因为连接数据库，对文件系统访问较多)，KeepAlive 关掉，会节省一定的内存，节省的内存正好可以作为文件系统的Cache(vmstat命令中cache一列)，降低I/O压力。
PS：当KeepAlive =On时，KeepAliveTimeOut的设置其实也是一个问题，设置的过短，会导致Apache 频繁建立连接，给Cpu造成压力，设置的过长，系统中就会堆积无用的Http连接，消耗掉大量内存，具体设置多少，可以进行不断的调节，因你的网站浏览和服务器配置 而异。

减少域名解释的开销

对于HTTP/1.0来说可以充分利用浏览器默认最大并发连接数比HTTP/1.1多的好 处，实现不增加新域名的开销而更高的并行下载，减少域名解释的开销（注：IE 6,7在HTTP/1.0中默认最大并发连接数为4，在HTTP/1.1中默认最大并发连接数为2，IE8都为6，Firefox2在HTTP/1.0中 默认最大并发连接数为2 在HTTP/1.1中默认最大并发连接数为8，firefox 3默认都是6），根据10年7月Google索引的42亿个网页的统计报告，每张网页里包含29.39个图片，7.09个外部脚本，3.22个外部CSS 样式表，如果设置了Keep-Alive并且合理控制Keep-Alive TimeOut这个参数可以大量的节约连接的开销，提高相应速度。如果设置不好，在大并发的情况小，因维持大量连接而使服务器资源耗尽，而对于目前国内大 部分的用户使用的还是IE6，7的情况。