用Wireshark分析Socket连接建立的过程

0. 安装Wireshark，但是默认情况下，Wireshark无法捕获127.0.0.1的报文

解决方案：安装npcap，替换默认的winpacp，重新启动Wireshark，就可以看到一个名字中含有Loopback的接口，针对它来抓包就行了

 

1. 用telnet向未被监听的9090端口发送连接请求

telnet窗口一闪而过，抓包结果如下

可以看出，未被监听的端口会直接返回RST包，导致Telnet无法正常建立连接。

 

2. 开启echo server监听9090端口，然后使用telent向9090端口发送连接请求

可以清楚的看到TCP的三次握手过程，现在Telnet已经与echo server建立了TCP连接了

 

3. 在第二步的基础上，使用telenet向echo server发送数据

我在Telnet里输入了abc三个字符，下图是抓包结果

可以看到一共有12个包，每四个包为一组，对应于Telnet中的一次输入

这四个包分别对应于 客户端发送字符->服务器ack->服务器发送echo->客户端ack

 

4. 在BIO模式的echo server中插入断点

使用BIO模式的echo server，但是在调用ServerSocket.accept()方法处下断点，让程序跑到此处停顿。

然后启动Telnet向服务器发送数据，结果如下：

可以看到在这种情况下，居然可以完成三次握手协议，正常建立连接（但此时服务端正卡在accept()方法上）

对于客户端后续发送的数据，服务端也能及时发送ack，只是无法发送echo罢了。一旦放开echo server的断点，服务器就能正常工作了，前面没收到echo的数据也不会丢失。

 

5. 在NIO模式的echo server中插入断点

与BIO模式相近，ServerSocketChannel只要与端口绑定，对于Telnet的连接请求，无需服务端调用accept方法就能完成三次握手。

客户端后续发送的数据，服务端也能正常返回ack。

 

6. 为什么只需要完成监听端口，无需调用accept方法就能完成三次握手呢？

我之前的想法是：accept方法在收到客户端发过来的syn包后就会从阻塞状态中退出，在此同时返回ack+syn包，完成三次握手（这个想法太奇怪了）

实际上是tcp底层维护了两个队列：半连接队列与全连接队列。操作系统收到Telnet的tcp连接请求后会自动完成三次握手建立TCP连接，然后将这个连接放到全连接队列中。而accept方法则是将TCP连接从这个全连接队列中提取出来罢了。

简单测试一下，在创建ServerSocket对象的时候，将backlog设置为1，然后将断点设置在accept方法处（不让程序从TCP全连接队列中提取连接）。然后开启两个Telnet客户端，结果第一个Telnet可以正常连接，第二个Telnet直接闪退了。

抓包如下图所示：

可以清楚的看到从6078到9090的TCP连接成功的完成了三次握手，从6079到9090的TCP连接则握手失败了。

 

参考资料：

关于TCP 半连接队列和全连接队列