首页 > 代码库 > 网络编程之socket新解

网络编程之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时,我们会发现第三个连接请求将是无法连接。

  

 

网络编程之socket新解