我有一个HTTP Web服务有时连接设置以一种奇怪的方式失败：
在哪种情况下客户端系统可以决定使用RST数据包进行回复？ 我可以想象这发生在SYN，ACK包含例如。 不正确的序列号（但这似乎不适用于我的情况 – 序列号看起来不错）。 所以我对一个详尽的:-)列表感兴趣，客户端收到SYN，ACK包后会发送一个RST包。
特别是，客户端应用程序代码（在Linux下使用普通的BSD风格套接字API）是否有可能导致这个RST包， 通过调用close()而三次握手仍在进行？
closures：问题是我的代码（在客户端）的一个愚蠢的错误。
在这种情况下，客户端使用非阻塞套接字，所以connect()调用会在内核持续等待来自服务器的SYN，ACK数据包时立即返回。 不幸的是，客户端代码非常不耐烦：如果连接在几百毫秒之后没有build立，客户端会在套接字上调用close() 。
在less数情况下，来自服务器的SYN，ACK数据包在通过networking的时候会被延迟几百毫秒。 当延迟回复最终到达客户端主机时，内核会看到套接字已经closures，并将SYN，ACK回复视为属于无效套接字。 这就是为什么它会回复一个RST数据包到服务器。
所以是的，应用程序代码（在Linux下使用普通的BSD风格的套接字API）可能导致这个RST数据包：通过使用一个非阻塞套接字并在三方握手仍在进行时closures连接。