结合Linux系统内核源码理解SYN_RECV状态

来源:本站
导读:目前正在解读《结合Linux系统内核源码理解SYN_RECV状态》的相关信息,《结合Linux系统内核源码理解SYN_RECV状态》是由用户自行发布的知识型内容!下面请观看由(电工技术网 - www.9ddd.net)用户发布《结合Linux系统内核源码理解SYN_RECV状态》的详细说明。
简介:结合Linux系统内核源码理解SYN_RECV状态

在tcp_v4_do_rcv中,有下面一段代码,是关于TCP连接建立时候的代码:

if (sk->sk_state == TCP_LISTEN) {

struct sock *nsk = tcp_v4_hnd_req(sk, skb);

if (!nsk)

goto discard;

if (nsk != sk) {

if (tcp_child_process(sk, nsk, skb))

goto reset;

return 0;

}

}

tcp_v4_hnd_req的返回值,不同情况下不同。

NULL 出现错误

nsk==sk 接受到SYN

nsk!=sk 接受到ACK

接受到ACK包时,tcp_v4_hnd_req函数会新建一个sock结构,并设置其初始状态为SYN_RECV,并返回新建的sock结构。

接着调用tcp_child_process函数,改变新建的sock的状态为ESTABLISHED。

(以下基于linux内核2.4.0)

SYN_RECV状态,顾名思义,是收到SYN包后应该置的状态。关于SYN_RECV状态,受某些教科书的误导,我以前一直理解为服务器收到SYN包后应该置此状态。也没细想到底是置那个socket的状态,最近在看三次握手协议在linux内核中的实现时,才仔细思考这个问题应该是置连接套接字的状态而非监听套接字的状态。

通常,SYN包只用于TCP三次握手协议中。常见的tcp三次握手协议过程(当然还有同时连接、

半连接等其它一些情况)如下:

1、client SYN包---> server

2、client <---SYN包/ACK包 server

3、client ACK包---> server

根据tcp状态图,对应下述4个状态的变化

a、client发送完毕,状态变成SYN_SEND;

b、server收到SYN报并发送ack确认包和SYN包,状态变为SYN_RECV

c、client发送ack包完毕,状态变成ESTABLISHED

d、server发送ack包完毕,状态变成ESTABLISHED

在linux内核中,上述几个状态对应为TCP_SYN_SEND、TCP_SYN_RECV、TCP_ESTABLISHED.

RFC793中关于SYN_RECV状态的描述如下:

SYN-RECEIVED - represents waiting for a confirming connection

request acknowledgment after having both received and sent a

connection request.

从上面可以看出,这个状态是在本端接收到对端连接请求,并发送连接对端请求后,等待对端应答时所置的状态。所以,本质上连接的过程是双方请求应答的来回, 应该称四次握手,只是常见的应用以c/s模式为主,而linux、包括绝大部分操作系统都把服务器端的应答和请求封装在一个包里面。

但在linux内核中,却是在监听套接字收到了客户端的ACK包后,才创建连接套接字并初始化为TCP_SYN_RECV状态,如下函数调用关系:

tcp_v4_rcv-->tcp_v4_do_rcv-->tcp_v4_hnd_req-->tcp_check_req-->

tcp_v4_syn_recv_sock-->tcp_create_openreq_child...

struct sock *tcp_create_openreq_child(struct sock *sk, struct open_request *req, struct sk_buff *skb)

{

struct sock *newsk = sk_alloc(PF_INET, GFP_ATOMIC, 0); /*创建连接sock结构*/

if(newsk != NULL) {

struct tcp_opt *newtp;

...

memcpy(newsk, sk, sizeof(*newsk));

newsk->state = TCP_SYN_RECV; /*置初始状态为SYN_RECV*/

//以下为一些初始化newsk结构的操作

...

}

这里似乎都正常了,但还有一点,服务器收到ACK包后,状态应该改为连接状态,而此时连接套接字的状态还是TCP_SYN_RECV

原因在于现在对ack包还没处理完,^_^,如下:

int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb)

{

...

if (sk->state == TCP_LISTEN) { //此处是监听套接字的状态

struct sock *nsk = tcp_v4_hnd_req(sk, skb); //获得了上面讲的连接套接字

if (!nsk)

goto discard;

if (nsk != sk) { //显然监听与连接套接字不等

if (tcp_child_process(sk, nsk, skb)) //此处调用tcp_rcv_state_process置套接字为连接建立状态

goto reset;

return 0;

}

}

...

}

可见,在linux内核中,SYN_RECV状态的保持时间是非常短暂的(也很难创建条件让此状态保持),这也是我们实际应用中通过netstat基本看不到这个状态的原因。

提醒:《结合Linux系统内核源码理解SYN_RECV状态》最后刷新时间 2024-03-14 01:07:13,本站为公益型个人网站,仅供个人学习和记录信息,不进行任何商业性质的盈利。如果内容、图片资源失效或内容涉及侵权,请反馈至,我们会及时处理。本站只保证内容的可读性,无法保证真实性,《结合Linux系统内核源码理解SYN_RECV状态》该内容的真实性请自行鉴别。