TCP/IP源码学习(54)——TCP的连接过程的实现(3)
2016-09-30 10:21
501 查看
http://blog.chinaunix.net/uid-23629988-id-3181446.html
作者:gfree.wind@gmail.com
博客:blog.focus-linux.net linuxfocus.blog.chinaunix.net
本文的copyleft归gfree.wind@gmail.com所有,使用GPL发布,可以自由拷贝,转载。但转载请保持文档的完整性,注明原作者及原链接,严禁用于任何商业用途。
======================================================================================================
上文在学习处理三次握手的最后一个ack的过程中,还没有完全走完流程。根据上文最后处
那么包的处理仍然是交给tcp_rcv_state_process。回忆第一篇文章中,tcp_rcv_state_process是根据child的状态来决定如何处理。而child是从父socket生成的。如果child的状态和父socket状态一样,肯定是有问题的。那么child的状态是何时改变的呢?
经过一番搜索,回到创建child的函数tcp_v4_sync_recv_sock->tcp_create_openreq_child->inet_csk_clone
说实话,这个结果让我觉得有些不爽。
首先这个函数名字叫做clone,结果生成的sock内部成员与传入的sock的内部成员不同,确实让我意想不到。另外这个函数是为所有面向连接的协议准备的。其名字为csk即connection sock,另外其位置位于inet_connection_sock.c中,都说明了这一点。这样的话,将其状态设置为TCP_SYN_RECV,与其通用性不符。
下面查看tcp_rcv_state_process处理TCP_SYN_RECV状态的代码:
这里处理完毕后,回到tcp_child_process
int tcp_child_process(struct sock *parent, struct sock *child,
struct sk_buff *skb)
{
int ret = 0;
int state = child->sk_state;
if (!sock_owned_by_user(child)) {
ret = tcp_rcv_state_process(child, skb, tcp_hdr(skb),
skb->len);
/* Wakeup parent, send SIGIO */
/*
对于这个ack包,state的状态即为child之前的状态,即TCP_SYN_RECV。
再成功处理了ack包后,child->sk_state变为TCP_ESTABLISHED
因此进入parent->sk_data_ready,仍然是一个异步通知的手段
*/
if (state == TCP_SYN_RECV && child->sk_state != state)
parent->sk_data_ready(parent, 0);
}
...... ......
}
这样这个ack包基本上已经处理完毕。但是还有一个问题,这个新建的child socket是何时添加到TCP的ehash中,即已经连接的hash表中。还是要回到tcp_v4_syn_recv_sock中,在该函数的结尾处,调用了__inet_hash_nolisten(newsk, NULL);将newsk加入父socket的ehash表中的。
为啥要将这个newsk加入到父socket的ehash表中呢?其实socket下面的ehash表就是全局变量tcp_hashinfo的ehash表。那么这里也就是将newsk加入到了全局变量tcp_hashinfo的ehash中。也就是说所有的已连接的TCP,都是保存在一个公共的hash表中。这样,再收到后面的包时,都可以匹配从全局的tcp_hashinfo的ehash中直接匹配到这个新连接的TCP。
作者:gfree.wind@gmail.com
博客:blog.focus-linux.net linuxfocus.blog.chinaunix.net
本文的copyleft归gfree.wind@gmail.com所有,使用GPL发布,可以自由拷贝,转载。但转载请保持文档的完整性,注明原作者及原链接,严禁用于任何商业用途。
======================================================================================================
上文在学习处理三次握手的最后一个ack的过程中,还没有完全走完流程。根据上文最后处
int tcp_child_process(struct sock *parent, struct sock *child, struct sk_buff *skb) { int ret = 0; int state = child->sk_state; if (!sock_owned_by_user(child)) { //到达这里 ret = tcp_rcv_state_process(child, skb, tcp_hdr(skb), skb->len); /* Wakeup parent, send SIGIO */ if (state == TCP_SYN_RECV && child->sk_state != state) parent->sk_data_ready(parent, 0); } ...... ...... }
那么包的处理仍然是交给tcp_rcv_state_process。回忆第一篇文章中,tcp_rcv_state_process是根据child的状态来决定如何处理。而child是从父socket生成的。如果child的状态和父socket状态一样,肯定是有问题的。那么child的状态是何时改变的呢?
经过一番搜索,回到创建child的函数tcp_v4_sync_recv_sock->tcp_create_openreq_child->inet_csk_clone
struct sock *inet_csk_clone(struct sock *sk, const struct request_sock *req, const gfp_t priority) { //首先clone统一的sock结构信息 struct sock *newsk = sk_clone(sk, priority); if (newsk != NULL) { //开始clone 面向连接的sock的信息 struct inet_connection_sock *newicsk = inet_csk(newsk); //在这里,newsk的状态被设置为TCP_SYN_RECV newsk->sk_state = TCP_SYN_RECV; newicsk->icsk_bind_hash = NULL; ...... ...... } return newsk; }
说实话,这个结果让我觉得有些不爽。
首先这个函数名字叫做clone,结果生成的sock内部成员与传入的sock的内部成员不同,确实让我意想不到。另外这个函数是为所有面向连接的协议准备的。其名字为csk即connection sock,另外其位置位于inet_connection_sock.c中,都说明了这一点。这样的话,将其状态设置为TCP_SYN_RECV,与其通用性不符。
下面查看tcp_rcv_state_process处理TCP_SYN_RECV状态的代码:
int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb, const struct tcphdr *th, unsigned int len) { struct tcp_sock *tp = tcp_sk(sk); struct inet_connection_sock *icsk = inet_csk(sk); int queued = 0; int res; tp->rx_opt.saw_tstamp = 0; ...... ...... res = tcp_validate_incoming(sk, skb, th, 0); if (res <= 0) return -res; /* step 5: check the ACK field */ if (th->ack) { //检查是否接受这个ack包 int acceptable = tcp_ack(sk, skb, FLAG_SLOWPATH) > 0; switch (sk->sk_state) { case TCP_SYN_RECV: if (acceptable) { tp->copied_seq = tp->rcv_nxt; smp_mb(); //完成了三次握手,sk的状态自然改为 TCP_ESTABLISHED tcp_set_state(sk, TCP_ESTABLISHED); //sk_state_change默认为sock_def_wakeup, 会唤醒sleep在该socket上的进程 sk->sk_state_change(sk); /* Note, that this wakeup is only for marginal * crossed SYN case. Passively open sockets * are not waked up, because sk->sk_sleep == * NULL and sk->sk_socket == NULL. */ //这里也仍然是一个wake动作,但是按照我的理解 //这里应该是处理socket作为文件描述符的异步操作,如epoll if (sk->sk_socket) sk_wake_async(sk, SOCK_WAKE_IO, POLL_OUT); tp->snd_una = TCP_SKB_CB(skb)->ack_seq; tp->snd_wnd = ntohs(th->window) << tp->rx_opt.snd_wscale; tcp_init_wl(tp, TCP_SKB_CB(skb)->seq); if (tp->rx_opt.tstamp_ok) tp->advmss -= TCPOLEN_TSTAMP_ALIGNED; /* Make sure socket is routed, for * correct metrics. */ icsk->icsk_af_ops->rebuild_header(sk); tcp_init_metrics(sk); tcp_init_congestion_control(sk); /* Prevent spurious tcp_cwnd_restart() on * first data packet. */ tp->lsndtime = tcp_time_stamp; tcp_mtup_init(sk); tcp_initialize_rcv_mss(sk); tcp_init_buffer_space(sk); tcp_fast_path_on(tp); } else { return 1; } break; } } else goto discard; /* step 6: check the URG bit */ tcp_urg(sk, skb, th); /* step 7: process the segment text */ //这时sk->sk_state的状态已经为TCP_ESTABLISHED /* 其实对于这个ack包,它只含有TCP的首部,没有数据。那么我认为在将tcp置为established后,不需要后面的操 作了 */ switch (sk->sk_state) { ...... ...... case TCP_ESTABLISHED: tcp_data_queue(sk, skb); queued = 1; break; } /* tcp_data could move socket to TIME-WAIT */ if (sk->sk_state != TCP_CLOSE) { tcp_data_snd_check(sk); tcp_ack_snd_check(sk); } if (!queued) { discard: __kfree_skb(skb); } return 0; }
这里处理完毕后,回到tcp_child_process
int tcp_child_process(struct sock *parent, struct sock *child,
struct sk_buff *skb)
{
int ret = 0;
int state = child->sk_state;
if (!sock_owned_by_user(child)) {
ret = tcp_rcv_state_process(child, skb, tcp_hdr(skb),
skb->len);
/* Wakeup parent, send SIGIO */
/*
对于这个ack包,state的状态即为child之前的状态,即TCP_SYN_RECV。
再成功处理了ack包后,child->sk_state变为TCP_ESTABLISHED
因此进入parent->sk_data_ready,仍然是一个异步通知的手段
*/
if (state == TCP_SYN_RECV && child->sk_state != state)
parent->sk_data_ready(parent, 0);
}
...... ......
}
这样这个ack包基本上已经处理完毕。但是还有一个问题,这个新建的child socket是何时添加到TCP的ehash中,即已经连接的hash表中。还是要回到tcp_v4_syn_recv_sock中,在该函数的结尾处,调用了__inet_hash_nolisten(newsk, NULL);将newsk加入父socket的ehash表中的。
为啥要将这个newsk加入到父socket的ehash表中呢?其实socket下面的ehash表就是全局变量tcp_hashinfo的ehash表。那么这里也就是将newsk加入到了全局变量tcp_hashinfo的ehash中。也就是说所有的已连接的TCP,都是保存在一个公共的hash表中。这样,再收到后面的包时,都可以匹配从全局的tcp_hashinfo的ehash中直接匹配到这个新连接的TCP。
相关文章推荐
- TCP/IP源码学习(54)——TCP的连接过程的实现(3)
- TCP/IP源码学习(53)——TCP的连接过程的实现(2)
- TCP/IP源码学习(52)——TCP的连接过程的实现(1)
- TCP/IP源码学习(53)——TCP的连接过程的实现(2)
- TCP/IP源码学习(52)——TCP的连接过程的实现(1)
- TCP/IP源码学习(52)——TCP的连接过程的实现(1)
- 结合redis设计与实现的redis源码学习-15-TCP网络连接(anet.c)
- socket实现tcp/ip服务端源码,无线程
- 《TCP-IP详解 卷2:实现》学习笔记—mbuf(存储器缓存)的结构
- TCP/IP 建立连接的过程?(3-way shake)
- LwIP 协议栈源码详解 ——TCP/IP 协议的实现(八: ARP 表 )
- LwIP 协议栈源码详解 ——TCP/IP 协议的实现(七:以太网数据接收)
- 建立tcp/ip连接,vc6实现客户端(发送数据)
- Linux学习之web服务器(1)--基于源码实现SSL的安全连接
- LwIP 协议栈源码详解 ——TCP/IP 协议的实现(三:动态内存管理)
- LwIP 协议栈源码详解 ——TCP/IP 协议的实现(九:ARP 表查询)
- LwIP 协议栈源码详解 ——TCP/IP 协议的实现(四:数据包 pbuf )
- ping源码代阅读(三)面向连接tcp/ip程序
- 配置PostgreSQL实现TCP/IP访问连接
- [CODE] 通过tcpserver实现对同一IP的最大连接数和连接频率的限制