TCP/IP源码学习(53)——TCP的连接过程的实现(2)

http://blog.chinaunix.net/uid-23629988-id-3179301.html

作者：gfree.wind@gmail.com

博客：blog.focus-linux.net   linuxfocus.blog.chinaunix.net 
 
本文的copyleft归gfree.wind@gmail.com所有，使用GPL发布，可以自由拷贝，转载。但转载请保持文档的完整性，注明原作者及原链接，严禁用于任何商业用途。
======================================================================================================
昨天写了一篇博文关于TCP的连接过程的实现——主要是接到第一个syn包的处理。那部分代码有不少地方没有看明白，只不过走了一遍流程。惭愧。

今天继续昨天的流程，在回复了syn+ack包后，新创建的request_sock结构被加入到父socket的icsk_accept_queue中。接下来不考虑错误等情况，如重传。接下来就考虑如何处理TCP三次握手中的最后一个ack包。

依然按照前文中的流程，最后一个ack包会进入函数tcp_v4_do_rcv。此时，仍然匹配的是父socket，即处于listening状态的socket，因此再次调用tcp_v4_hnd_req——前文并没有对这个函数，进行分析，只是说明了对于第一个syn包，该函数返回的仍然是传入的参数sock。

下面看一下tcp_v4_hnd_req的代码

static struct sock *tcp_v4_hnd_req(struct sock *sk, struct sk_buff *skb)
{
struct tcphdr *th = tcp_hdr(skb);
const struct iphdr *iph = ip_hdr(skb);
struct sock *nsk;
struct request_sock **prev;
/* Find possible connection requests. */
/*
上次处理syn包时，已经将对应的request_sock加入了icsk_accept_queue中的listen_opt，
因此这次可以找到req。
并且可以注意到这个函数还有一个返回值prev，为找到的request_sock在queue中的前一个元素。
返回前一个元素，可以在后面的tcp_check_req中，在移除req时，避免二次查找。
*/
struct request_sock *req = inet_csk_search_req(sk, &prev, th->source,
iph->saddr, iph->daddr);
if (req)
return tcp_check_req(sk, skb, req, prev);

...... ......

}

进入tcp_check_req

struct sock *tcp_check_req(struct sock *sk, struct sk_buff *skb,
struct request_sock *req,
struct request_sock **prev)
{
struct tcp_options_received tmp_opt;
const u8 *hash_location;
struct sock *child;
const struct tcphdr *th = tcp_hdr(skb);
__be32 flg = tcp_flag_word(th) & (TCP_FLAG_RST|TCP_FLAG_SYN|TCP_FLAG_ACK);
int paws_reject = 0;

//每次都要将saw_tstamp重置，因为其依赖于每一个TCP包

tmp_opt.saw_tstamp = 0;
if (th->doff > (sizeof(struct tcphdr)>>2)) {
//表明有option存在于TCP首部，解析TCP的option
tcp_parse_options(skb, &tmp_opt, &hash_location, 0);

/*
TCP首部含有Timestamp Option
该option有两个用途：
1.计算RTT
2.PAWS，即Protection Against Wrapped Sequence
参见RFC1323
*/

if (tmp_opt.saw_tstamp) {
//这里就是进行PAWS检查
tmp_opt.ts_recent = req->ts_recent;
/* We do not store true stamp, but it is not required,
* it can be estimated (approximately)
* from another data.
*/
tmp_opt.ts_recent_stamp = get_seconds() - ((TCP_TIMEOUT_INIT/HZ)<<req->retrans);
paws_reject = tcp_paws_reject(&tmp_opt, th->rst);
}
}

/* Check for pure retransmitted SYN. */
if (TCP_SKB_CB(skb)->seq == tcp_rsk(req)->rcv_isn &&
flg == TCP_FLAG_SYN &&
!paws_reject) {
/* 这是重发的syn包，因为sequence相同，回复syn+ack */
/*
* RFC793 draws ( It was fixed in RFC1122)
* this case on figure 6 and figure 8, but formal
* protocol description says NOTHING.
* To be more exact, it says that we should send ACK,
* because this segment (at least, if it has no data)
* is out of window.
*
* CONCLUSION: RFC793 (even with RFC1122) DOES NOT
* describe SYN-RECV state. All the description
* is wrong, we cannot believe to it and should
* rely only on common sense and implementation
* experience.
*
* Enforce "SYN-ACK" according to figure 8, figure 6
* of RFC793, fixed by RFC1122.
*/
req->rsk_ops->rtx_syn_ack(sk, req, NULL);
return NULL;
}

//省略一大堆检查和检验，感兴趣的朋友可以直接看代码。注释很清楚
...... ......

/* OK, ACK is valid, create big socket and
* feed this segment to it. It will repeat all
* the tests. THIS SEGMENT MUST MOVE SOCKET TO
* ESTABLISHED STATE. If it will be dropped after
* socket is created, wait for troubles.
*/
/*
tcp在IPv4下的实现为tcp_v4_syn_recv_sock。这里不去看tcp_v4_syn_recv_sock了，它的主要作用就是利用
sk, skb, req中的信息，生成一个新的socket。
*/
child = inet_csk(sk)->icsk_af_ops->syn_recv_sock(sk, skb, req, NULL);
if (child == NULL)
goto listen_overflow;

//利用prev将req从accept_queue的listen_opt中删除

inet_csk_reqsk_queue_unlink(sk, req, prev);
inet_csk_reqsk_queue_removed(sk, req);

//将这个req和新的socket child真正加入了父socket sock的accept queue中。
//这里不要与前文中的inet_csk_reqsk_queue_hash_add混淆，inet_csk_reqsk_queue_hash_add是将
//requst_sock加入到listen的队列中

inet_csk_reqsk_queue_add(sk, req, child);
//返回新生成的socket child
return child;

listen_overflow:
if (!sysctl_tcp_abort_on_overflow) {
inet_rsk(req)->acked = 1;
return NULL;
}

embryonic_reset:
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_EMBRYONICRSTS);
if (!(flg & TCP_FLAG_RST))
req->rsk_ops->send_reset(sk, skb);

inet_csk_reqsk_queue_drop(sk, req, prev);
return NULL;
}
那么对于tcp_v4_hnd_request最后返回的就是上面函数中新创建的socket，那么在tcp_v4_do_rcv中，就会进入下面的函数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;

/* 这个检查还是用来保证TCP状态的正确 */

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);
} else {
/* Alas, it is possible again, because we do lookup
* in main socket hash table and lock on listening
* socket does not protect us more.
*/
__sk_add_backlog(child, skb);
}

bh_unlock_sock(child);
sock_put(child);
return ret;
}

今天有些困了。三次握手中的最后一个ack包的处理还是没有看完。不继续坚持看了，没有效率了。明天继续了。在完成被动连接的三次握手，还会看看主动连接的流程