由TCP三路握手引出的问题及深度理解socket编程

最近在复习tcp三路握手三路握手以及四路挥手时，想到平时抓包正常是的状态，那当SYN发后，若服务器异常，会出现什么？于是先去查了相关书籍，找到了以下的流程图：

于是知道可能返回的是RST，但心里还是不踏实，于是自己开始验证一下：
于是先在确定服务器程序正常并且可以正常抓包看到三路握手时，开始模拟服务器异常，我们都知道，服务器程序在运行时，首先是调用socket（）函数，过来以此是bind（），listen（），acccept()函数，想起刚开始学习时，accept()函数用于链接客户端，所以，我便在accept（）函数前加了sleep（100），用来模拟服务器异常，以便得到服务器异常时情况，如图：

执行结果如下：

看到结果，很是疑惑，起初怀疑是sleep（100）太短，抓包时过了时间，于是，又去修改了代码，直接while死循环，让服务器停在accept前，但结果还是成功完成了三路握手，没头绪的我，仔细回忆操作细节，在操作无误后，开始怀疑是否时代码出了问题，于是去再一次查了listen（）函数，还有accept（）函数的用法，如图：

在这里，发现accept（）函数调用时，三路握手已经完成，这便验证了，我之前的实验结果，于是新的问题产生了：三路握手到底什么时候产生的，既然不是accept（）函数，那么就极可能是listen（）函数了，于是又去查了listen（）函数，结果如下：

我们看到，在socket服务器端代码中, 调用socket, bind 之后, 服务器默认时主动连接模式, 此时调用listen函数.
listen()函数: 当socket创建一个套接口时, 它默认欸主动套接口, listen函数将未连接的套接口转换未被动套接口(即服务器变为被动连接模式), 第二个参数规定了内核未此套接口排队的最大连接个数.
而这个图让我注意到，listen（）函数本身并不能三路握手，这是和我之前的理解一致的，但是这个第二个参数，是两部分的和，看到这我明白了，三路握手是在listen（）函数后有内核完成，而accept（）函数只是从已连接的链表中拿走链接，链接并不是这个时候发生的，到这里，发现平时学习时还是有些粗心，也感谢这次想法，纠正了知识点。

接下来我将while（1）放在了listen（）前 ，果然，得到了想要的接结果 如下图：

抓包结果：

通过观察现象可以发现, 我们在服务器端listen()函数之前进入死循环, 这时通过TCP Test Tool 客户端进行连接, 发生了三路握手中的第一次握手, 客户端发送了一个 SYN = 1, 此时三路握手发生异常, 服务器端给客户端发送 RST = 1, ACK = 1 的一个报文, 进行重连, 通过抓包可以看到一共重连了5次!!