Linux TCP包头设置SEQ值,linux 协议栈tcp的rst报文中，seq的选取问题

之前在《深入理解并行编程》的群里，有个小米的兄弟问了一个问题，服务器A发包给服务器B，Seq是1，但是在未能收到服务器B的报文回复的情况下，发送了

rst，但是rst报文中，对应的seq是1461，一堆人都在猜测，为什么seq跳变了，由于当时只看到一半的图片，所以我让他发送完整报文出来之后，我

发现其实rst的seq不是1的原因，并不是因为跳变，而是正常的，因为发送给B的报文，长度为1460，但是这个报文没有得到回复，所以在超时之后，应用程序关闭了这条连接，

导致内核协议栈发送了一个rst报文，而rst报文选取seq的时候，并不是选取的确定已经发送的seq，而是当前连接已经用掉的seq，也就是当前seq，哪怕这个报文没有收到回复，也会使用。

具体看代码：

/* We get here when a process closes a file descriptor (either due to

* an explicit close() or as a byproduct of exit()'ing) and there

* was unread data in the receive queue. This behavior is recommended

* by RFC 2525, section 2.17. -DaveM

*/

void tcp_send_active_reset(struct sock *sk, gfp_t priority)

{

struct sk_buff *skb