网络编程之socket新解

　　由于工作并不是很忙，闲暇之余就读了下tomcat的源代码。我是从事java服务器开发工作的，大体的一些服务器线程模型我都是了解的。其大部分都是由一个线程调用监听端口等待客户端的链接，建立连接后再交由其他的线程负责具体的网络io操作。可tomcat居然是用多个线程调用同一个ServerSocket实例的accept方法。我读过mina也读过netty的源码，自己在大学时也写过不少的基于socket通信的程序，但是这种用法自己从未想过也从未见过。（恕本人咕噜寡闻了，-_-|||）不免好奇，这么做原来没问题啊？可这么做能有什么好处吗？

　　要明白这么做的道理，恐怖不得不去搞清楚套接字的accept方法底层到底干了什么，与TCP的三步握手又是什么关系。我查了一些资料大体把这些搞明白了，在这里记录下来以加强自己的认识，也同时共享给哪些跟我一样对socket的认识有所偏差的人。

　　一、首先说一下TCP三步握手的基本流程，如下图：

　　首先，请求端（客户端）发送一个包含SYN标志的TCP报文，SYN即同步（Synchronize），同步报文会指明客户端使用的端口以及TCP连接的初始序号；

　　第二步，服务器在收到客户端的SYN报文后，进入SYN-RECEVIED状态并将这个还没有完全建立起的连接放到半连接队列。还要返回一个SYN+ACK的报文，表示客户端的请求被接受，同时TCP序号被加一，ACK即确认（Acknowledgment）。

　　第三步，客户端也返回一个确认报文ACK给服务器端，同样TCP序列号被加一，到此一个TCP连接完成。服务器端就会把此连接从半连接队列移除放入到完全连接队列。

　　注意说到的两个队列：半连接队列和完全连接队列

　　二、socket操作和TCP的关系

　　也许好多人都是认为，当我们调用ServerSocket的accept方法时，是在监听等待客户端的连接，当客户端请求服务器时就创立连接并返回与客户端通信的socket。实际呢却不是这样子的。我们来看一个现象

首先我们启动一个服务器程序，程序很简单：代码如下

public class Server {
 
    public static void main(String[] args) throws IOException {
        ServerSocket sSocket = new ServerSocket(3661, 2);//第二个参数的含义后边会讲解
        System.in.read();//防止程序退出
    }
 
}

　　可以看到，这里我们并没有调用serversocket的accept方法。如果按上边说的，accept方法是监听端口等待客户单的连接并完成连接的建立的话。我们这个服务器程序根本无法监听端口并完成连接建立。接下来验证一下，

　　首先运行服务程序程序，然后我们在命令行下用netstat -an查看一下端口情况：

可以看出端口依然被监听了，并处于tcp三步握手的LISTEN状态。接下来我们连接试试能不能进行连接，启动一个命令行窗口，执行：

　　telnet 127.0.0.1 3661。不要把这个关啦，再启动一个命令行窗口执行以下上边的netstat -an命令：

　　可以看到，连接已成功建立了，TCP已经进入ESTABLISHED阶段。看以看到，我们不调用accept方法一样可以监听端口并和客户端建立连接。

由此我们可以证明accept方法并不是监听端口等待客户端的连接并建立连接。那是什么起到了监听端口等待客户单连接的作用的，通过看源码我们会发现构造方法调用了bind方法。

　　看到这里想必都能知道，其实在我们调用accept返回一个socket时，tcp早已把三步握手的过程完成了，连接已经都建立好了。那我们的accept具体干什么事呢？还记得上边提到的完全连接队列吧。accept就是从完全连接队列取出连接并封装成socket。ServerSocket的构造方法参数backlog就是指定这个队列的大小。比如上边服务器程序我们制定了backlog的值为2，当我们用三个命令行分别调用telnet 127.0.0.1 3661时，我们会发现第三个连接请求将是无法连接。