netty系列之IO基础详解

2022年6月4日09:07:37

建议阅读文件io和网络io了解IO基础知识
和rocketMq-broker篇之消息存储IO了解零拷贝知识

socket状态

1、SOCKET状态介绍

netty系列之IO基础详解

1、客户端独有的：（1）SYN_SENT （2）FIN_WAIT1 （3）FIN_WAIT2 （4）CLOSING （5）TIME_WAIT 。

2、服务器独有的：（1）LISTEN （2）SYN_RCVD （3）CLOSE_WAIT （4）LAST_ACK 。

3、共有的：（1）CLOSED （2）ESTABLISHED 。



LISTEN - 侦听来自远方TCP端口的连接请求；

SYN-SENT -在发送连接请求后等待匹配的连接请求；

SYN-RECEIVED- 在收到和发送一个连接请求后等待对连接请求的确认；

ESTABLISHED- 代表一个打开的连接，数据可以传送给用户；

FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；

FIN-WAIT-2 - 从远程TCP等待连接中断请求；

CLOSE-WAIT - 等待从本地用户发来的连接中断请求；

CLOSING -等待远程TCP对连接中断的确认；

LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认；

TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认；

CLOSED - 没有任何连接状态；

根据图
1.第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x;然后，客户端进入SYN_SEND状态，等待服务器的确认;

2.第二次握手：服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1);同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y;服务器端将上述所有信息放到一个报文段(即SYN+ACK报文段)中，一并发送给客户端，此时服务器进入SYN_RECV状态;

3.第三次握手：客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。

完成了三次握手，客户端和服务器端就可以开始传送数据。以上就是TCP三次握手的总体介绍。

那四次分手呢?

当客户端和服务器通过三次握手建立了TCP连接以后，当数据传送完毕，肯定是要断开TCP连接的啊。那对于TCP的断开连接，这里就有了神秘的“四次分手”。

1.第一次分手：主机1(可以使客户端，也可以是服务器端)，设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段;此时，主机1进入FIN_WAIT_1状态;这表示主机1没有数据要发送给主机2了;

2.第二次分手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1;主机1进入FIN_WAIT_2状态;主机2告诉主机1，我也没有数据要发送了，可以进行关闭连接了;

3.第三次分手：主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入CLOSE_WAIT状态;

4.第四次分手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态;主机2收到主机1的ACK报文段以后，就关闭连接;此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。

至此，TCP的四次分手就这么愉快的完成了。当你看到这里，你的脑子里会有很多的疑问，很多的不懂，感觉很凌乱;没事，我们继续总结。

为什么要三次握手?

既然总结了TCP的三次握手，那为什么非要三次呢?怎么觉得两次就可以完成了。那TCP为什么非要进行三次连接呢?在谢希仁的《计算机网络》中是这样说的：

为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

在书中同时举了一个例子，如下：

“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。（或者可能确认报文在网络中丢失，但是二次握手情况server端依然开启连接，创建socket）假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”

这就很明白了，防止了服务器端的一直等待而浪费资源。

为什么要四次分手?
四次握手的目的实际上就是让客户端和服务端感知到连接断开并释放 客户端和服务端彼此的socket资源
那四次分手又是为何呢?TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工 模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2， 它的数据已经全部发送完毕了;但是，这个时候主机1还是可以接受来自主机2的数据;当主机2返回ACK报文 段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的;当主机2也发送了FIN 报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此 就会愉快的中断这次TCP连接。如果要正确的理解四次分手的原理，就需要了解四次分手过程中的状态变化。

FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等 待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时， 它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报 文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK 报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。 (主动方)

FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即 有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。 (主动方)

CLOSE_WAIT：这种状态的含义其实是表示在等待关闭。怎么理解呢?当对方close一个SOCKET后发送FIN 报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实 际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个 SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关 闭连接。(被动方)

LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报 文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。(被动方)

TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。 如果FINWAIT1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无 须经过FIN_WAIT_2状态。(主动方)

CLOSED: 表示连接中断。

2、Socket连接为什么进行三次握手，而关闭需要进行四次握手？

这是为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。在另一部经典的《计算机网络》一书中讲“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。这两种不用的表述其实阐明的是同一个问题。
谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。主要目的防止server端一直等待，浪费资源。

但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文 和FIN报文多数情况下都是分开发送的。

3、 为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状 态？

这是因为双方虽然都同意关闭连接了，并且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报 文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报 文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。

三次握手和四次挥手对应到代码中

三次握手，完全由操作系统帮助完成，但是服务端socket在serverSocket.accept()后被创建
四次挥手，首先发起方调用socket.close(),服务端在收到close请求后，回复ack确认之后，也应该在数据发送完毕之后执行socket.close，发送请求和接收ack完成四次挥手.

Socket

ServerSocket的构造方法有以下几种重载形式：
◆ServerSocket()throws IOException
◆ServerSocket(int port) throws IOException
◆ServerSocket(int port, int backlog) throws IOException
◆ServerSocket(int port, int backlog, InetAddress bindAddr) throws IOException
在以上构造方法中，参数port指定服务器要绑定的端口（服务器要监听的端口），参数backlog指定客户连接请求队列的长度，参数bindAddr指定服务器要绑定的IP地址。
绑定的ip需要时本地拥有的ip地址，如果不是，会报错。

backLog含义

backlog的定义是已经建立tcp连接但未进行accept处理的SOCKET队列大小，已是（并非syn的SOCKET队列）。如果这个队列满了，将会发送一个ECONNREFUSED错误信息给到客户端,即 “Connection refused”

Socket socket=newSocket(www.javathinker.org,80);

就意味着在远程www.javathinker.org主机的80端口上，监听到了一个客户的连接请求。管理客户连接请求的任务是由操作系统来完成的。操作系统把这些连接请求存储在一个先进先出的队列中。许多操作系统限定了队列的最大长度，一般为50。当队列中的连接请求达到了队列的最大容量时，服务器进程所在的主机会拒绝新的连接请求。只有当服务器进程通过ServerSocket的accept()方法从队列中取出连接请求，使队列腾出空位时，队列才能继续加入新的连接请求。
对于客户进程，如果它发出的连接请求被加入到服务器的队列中，就意味着客户与服务器的连接建立成功，客户进程从Socket构造方法中正常返回。如果客户进程发出的连接请求被服务器拒绝，Socket构造方法就会抛出ConnectionException。
ServerSocket构造方法的backlog参数用来显式设置连接请求队列的长度，它将覆盖操作系统限定的队列的最大长度。值得注意的是，在以下几种情况中，仍然会采用操作系统限定的队列的最大长度：
◆backlog参数的值大于操作系统限定的队列的最大长度；
◆backlog参数的值小于或等于0；
◆在ServerSocket构造方法中没有设置backlog参数。

以下Client.java和例程3-2的Server.java用来演示服务器的连接请求队列的特性。
Client.java

importjava.net.*;publicclassClient{publicstaticvoidmain(String args[])throwsException{finalint length=100;String host="localhost";int port=8000;Socket[] sockets=newSocket[length];for(int i=0;i<length;i++){// 试图建立100次连接
      sockets[i]=newSocket(host, port);System.out.println("第"+(i+1)+"次连接成功");}Thread.sleep(3000);for(int i=0;i<length;i++){
      sockets[i].close();//断开连接}}}
importjava.io.*;importjava.net.*;publicclassServer{privateint port=8000;privateServerSocket serverSocket;publicServer()throwsIOException{
    serverSocket=newServerSocket(port,3);//连接请求队列的长度为3System.out.println("服务器启动");}publicvoidservice(){while(true){Socket socket=null;try{
        socket= serverSocket.accept();//从连接请求队列中取出一个连接System.out.println("New connection accepted "+
        socket.getInetAddress()+":"+socket.getPort());}catch(IOException e){
         e.printStackTrace();}finally{try{if(socket!=null)socket.close();}catch(IOException e){e.printStackTrace();}}}}publicstaticvoidmain(String args[])throwsException{Server server=newServer();Thread.sleep(60000*10);//睡眠10分钟//server.service();}}

Client试图与Server进行100次连接。在Server类中，把连接请求队列的长度设为3。这意味着当队列中有了3个连接请求时，如果Client再请求连接，就会被Server拒绝。下面按照以下步骤运行Server和Client程序。
（1）把Server类的main()方法中的“server.service();”这行程序代码注释掉。这使得服务器与8000端口绑定后，永远不会执行serverSocket.accept()方法。这意味着队列中的连接请求永远不会被取出。先运行Server程序，然后再运行Client程序，Client程序的打印结果如下：

第1次连接成功
第2次连接成功
第3次连接成功Exception in thread"main"java.net.ConnectException:Connection refused: connect        
        atjava.net.PlainSocketImpl.socketConnect(NativeMethod)
        atjava.net.PlainSocketImpl.doConnect(UnknownSource)
        atjava.net.PlainSocketImpl.connectToAddress(UnknownSource)
        atjava.net.PlainSocketImpl.connect(UnknownSource)
        atjava.net.SocksSocketImpl.connect(UnknownSource)
        atjava.net.Socket.connect(UnknownSource)
        atjava.net.Socket.connect(UnknownSource)
        atjava.net.Socket.(UnknownSource)
        atjava.net.Socket.(UnknownSource)
        atClient.main(Client.java:10)

把Server类的main()方法按如下方式修改：从以上打印结果可以看出，Client与Server在成功地建立了3个连接后，就无法再创建其余的连接了，因为服务器的队列已经满了。

publicstaticvoidmain(String args[])throwsException{Server server=newServer();//Thread.sleep(60000*10);  //睡眠10分钟
    server.service();}

作了以上修改，服务器与8 000端口绑定后，就会在一个while循环中不断执行serverSocket.accept()方法，该方法从队列中取出连接请求，使得队列能及时腾出空位，以容纳新的连接请求。先运行Server程序，然后再运行Client程序，Client程序的打印结果如下：

第1次连接成功
第2次连接成功
第3次连接成功
…
第100次连接成功

从以上打印结果可以看出，此时Client能顺利与Server建立100次连接。

设定绑定的IP地址

如果主机只有一个IP地址，那么默认情况下，服务器程序就与该IP地址绑定。ServerSocket的第4个构造方法ServerSocket(int port, int backlog, InetAddress bindAddr)有一个bindAddr参数，它显式指定服务器要绑定的IP地址，该构造方法适用于具有多个IP地址的主机。假定一个主机有两个网卡，一个网卡用于连接到Internet， IP地址为222.67.5.94，还有一个网卡用于连接到本地局域网，IP地址为192.168.3.4。如果服务器仅仅被本地局域网中的客户访问，那么可以按如下方式创建ServerSocket：

ServerSocket serverSocket=newServerSocket(8000,10,InetAddress.getByName("192.168.3.4"));

## 默认构造方法的作用
ServerSocket有一个不带参数的默认构造方法。通过该方法创建的ServerSocket不与任何端口绑定，接下来还需要通过bind()方法与特定端口绑定。
这个默认构造方法的用途是，允许服务器在绑定到特定端口之前，先设置ServerSocket的一些选项。因为一旦服务器与特定端口绑定，有些选项就不能再改变了。
在以下代码中，先把ServerSocket的SO_REUSEADDR选项设为true，然后再把它与8000端口绑定：

ServerSocket serverSocket=newServerSocket();
serverSocket.setReuseAddress(true);//设置ServerSocket的选项
serverSocket.bind(newInetSocketAddress(8000));//与8000端口绑定

如果把以上程序代码改为：

ServerSocket serverSocket=newServerSocket(8000);
serverSocket.setReuseAddress(true);//设置ServerSocket的选项

那么serverSocket.setReuseAddress(true)方法就不起任何作用了，因为SO_ REUSEADDR选项必须在服务器绑定端口之前设置才有效。

SO_REUSEADDR

SO_REUSEADDR是一个很有用的选项，一般服务器的监听socket都应该打开它。它的大意是允许服务器bind一个地址，即使这个地址当前已经存在已建立的连接，比如：

  • 服务器启动后，有客户端连接并已建立，如果服务器主动关闭，那么和客户端的连接会处于TIME_WAIT状态，此时再次启动服务器，就会bind不成功，报：Address already in use。
  • 服务器父进程监听客户端，当和客户端建立链接后，fork一个子进程专门处理客户端的请求，如果父进程停止，因为子进程还和客户端有连接，所以再次启动父进程，也会报Address already in use。

这次我们直接上代码，看看这两种情况：

1**、一般来说，一个端口释放后会等待两分钟之后才能再被使用 （首先申请断开连接的会进入timeWait状态），SO_REUSEADDR是让端口释放后立即就可以被再次使用。**
SO_REUSEADDR用于对TCP套接字处于TIME_WAIT状态下的socket，才可以重复绑定使用。server程序总是应该在调用bind()之前设置SO_REUSEADDR套接字选项。TCP，先调用close()的一方会进入TIME_WAIT状态
2、SO_REUSEADDR和SO_REUSEPORT
SO_REUSEADDR提供如下四个功能：
SO_REUSEADDR允许启动一个监听服务器并捆绑其众所周知端口，即使以前建立的将此端口用做他们的本地端口的连接仍存在。这通常是重启监听服务器时出现，若不设置此选项，则bind时将出错。
SO_REUSEADDR允许在同一端口上启动同一服务器的多个实例，只要每个实例捆绑一个不同的本地IP地址即可。对于TCP，我们根本不可能启动捆绑相同IP地址和相同端口号的多个服务器。
SO_REUSEADDR允许单个进程捆绑同一端口到多个套接口上，只要每个捆绑指定不同的本地IP地址即可。这一般不用于TCP服务器。
SO_REUSEADDR允许完全重复的捆绑：当一个IP地址和端口绑定到某个套接口上时，还允许此IP地址和端口捆绑到另一个套接口上。一般来说，这个特性仅在支持多播的系统上才有，而且只对UDP套接口而言（TCP不支持多播）。
SO_REUSEPORT选项有如下语义：
此选项允许完全重复捆绑，但仅在想捆绑相同IP地址和端口的套接口都指定了此套接口选项才行。

接收和关闭与客户的连接

ServerSocket的accept()方法从连接请求队列中取出一个客户的连接请求，然后创建与客户连接的Socket对象，并将它返回。如果队列中没有连接请求，accept()方法就会一直等待，直到接收到了连接请求才返回。
接下来，服务器从Socket对象中获得输入流和输出流，就能与客户交换数据。当服务器正在进行发送数据的操作时，如果客户端断开了连接，那么服务器端会抛出一个IOException的子类SocketException异常：
如果一端的Socket被关闭（或主动关闭，或因为异常退出而引起的关闭），另一端仍发送数据，发送的第一个数据包引发该异常(Connect reset by peer)。

java.net.SocketException:Connection reset by peer

示例客户端

publicclassSocketClient{publicstaticvoidmain(String[] args)throwsInterruptedException{try{// 和服务器创建连接Socket socket=newSocket("127.0.0.1",8088);// 要发送给服务器的信息OutputStream os= socket.getOutputStream();PrintWriter pw=newPrintWriter(os);
            pw.write("客户端发送信息");
            os.write("客户端发送信息".getBytes());
            os.flush();
            pw.flush();//   sleep(1000*60*60);//   socket.shutdownOutput();// 从服务器接收的信息InputStream is= socket.getInputStream();BufferedReader br=newBufferedReader(newInputStreamReader(is));//            String info = null;//            while((info = br.readLine())!=null){//                System.out.println("我是客户端，服务器返回信息："+info);//            }System.exit(0);
            br.close();
            is.close();
            os.close();
            pw.close();
            socket.close();}catch(Exception e){
            e.printStackTrace();}}

发送消息完毕直接结束当前进程,关闭客户端的socket.(注意根据四次挥手,客户端如果执行了socket.close不会立马关闭socket.要经过四次挥手才会关闭socket) 如果客户端关闭了socke,服务端依然发送消息就会报Connection reset by peer

这只是服务器与单个客户通信中出现的异常，这种异常应该被捕获，使得服务器能继续与其他客户通信。
以下程序显示了单线程服务器采用的通信流程：

publicvoidservice(){while(true){Socket socket=null;try{
      socket= serverSocket.accept();//从连接请求队列中取出一个连接System.out.println("New connection accepted "+
      socket.getInetAddress()+":"+socket.getPort());//接收和发送数据
      …}catch(IOException e){//这只是与单个客户通信时遇到的异常，可能是由于客户端过早断开连接引起的//这种异常不应该中断整个while循环
       e.printStackTrace();}finally{try{if(socket!=null)socket.close();//与一个客户通信结束后，要关闭Socket}catch(IOException e){e.printStackTrace();}}}}

与单个客户通信的代码放在一个try代码块中，如果遇到异常，该异常被catch代码块捕获。try代码块后面还有一个finally代码块，它保证不管与客户通信正常结束还是异常结束，最后都会关闭Socket，断开与这个客户的连接。

关闭ServerSocket

ServerSocket的close()方法使服务器释放占用的端口，并且断开与所有客户的连接。当一个服务器程序运行结束时，即使没有执行ServerSocket的close()方法，操作系统也会释放这个服务器占用的端口。因此，服务器程序并不一定要在结束之前执行ServerSocket的close()方法。
在某些情况下，如果希望及时释放服务器的端口，以便让其他程序能占用该端口，则可以显式调用ServerSocket的close()方法。例如，以下代码用于扫描1~65535之间的端口号。如果ServerSocket成功创建，意味着该端口未被其他服务器进程绑定，否者说明该端口已经被其他进程占用：

for(int port=1;port<=65535;port++){try{ServerSocket serverSocket=newServerSocket(port);
serverSocket.close();//及时关闭ServerSocket}catch(IOException e){System.out.println("端口"+port+" 已经被其他服务器进程占用");}}

以上程序代码创建了一个ServerSocket对象后，就马上关闭它，以便及时释放它占用的端口，从而避免程序临时占用系统的大多数端口。
ServerSocket的isClosed()方法判断ServerSocket是否关闭，只有执行了ServerSocket的close()方法，isClosed()方法才返回true；否则，即使ServerSocket还没有和特定端口绑定，isClosed()方法也会返回false。
ServerSocket的isBound()方法判断ServerSocket是否已经与一个端口绑定，只要ServerSocket已经与一个端口绑定，即使它已经被关闭，isBound()方法也会返回true。
如果需要确定一个ServerSocket已经与特定端口绑定，并且还没有被关闭，则可以采用以下方式：

boolean isOpen=serverSocket.isBound()&&!serverSocket.isClosed();

获取ServerSocket的信息

ServerSocket的以下两个get方法可分别获得服务器绑定的IP地址，以及绑定的端口：
◆public InetAddress getInetAddress()
◆public int getLocalPort()
前面已经讲到，在构造ServerSocket时，如果把端口设为0，那么将由操作系统为服务器分配一个端口（称为匿名端口），程序只要调用getLocalPort()方法就能获知这个端口号。如例程3-3所示的RandomPort创建了一个ServerSocket，它使用的就是匿名端口。

importjava.io.*;importjava.net.*;publicclassRandomPort{publicstaticvoidmain(String args[])throwsIOException{ServerSocket serverSocket=newServerSocket(0);System.out.println("监听的端口为:"+serverSocket.getLocalPort());}}

多次运行RandomPort程序，可能会得到如下运行结果：

C:\chapter03\classes>javaRandomPort
监听的端口为:3000C:\chapter03\classes>javaRandomPort
监听的端口为:3004C:\chapter03\classes>javaRandomPort
监听的端口为:3005

ServerSocket选项

ServerSocket有以下3个选项。
◆SO_TIMEOUT：表示等待客户连接的超时时间。
◆SO_REUSEADDR：表示是否允许重用服务器所绑定的地址。
◆SO_RCVBUF：表示接收数据的缓冲区的大小。

SO_TIMEOUT选项

◆设置该选项：public void setSoTimeout(int timeout) throws SocketException
◆读取该选项：public int getSoTimeout () throws IOException
SO_TIMEOUT表示ServerSocket的accept()方法等待客户连接的超时时间，以毫秒为单位。如果SO_TIMEOUT的值为0，表示永远不会超时，这是SO_TIMEOUT的默认值。
当服务器执行ServerSocket的accept()方法时，如果连接请求队列为空，服务器就会一直等待，直到接收到了客户连接才从accept()方法返回。如果设定了超时时间，那么当服务器等待的时间超过了超时时间，就会抛出SocketTimeoutException，它是InterruptedException的子类。
如例所示的TimeoutTester把超时时间设为6秒钟。

importjava.io.*;importjava.net.*;publicclassTimeoutTester{publicstaticvoidmain(String args[])throwsIOException{
  • 作者：qq_37436172
  • 原文链接：https://blog.csdn.net/qq_37436172/article/details/124910586
    更新时间：2022年6月4日09:07:37 ，共 13857 字。