深入理解TCP协议及其源代码

TCP三次握手理论

三次握手过程

第一次握手

客户端A向服务端B发出连接请求，同步位SYN=1，初始序列seq=x，连接请求报文段不能携带数据，但是要消耗一个序号，这时客户端A进入SYN-SENT（同步已发送状态）

第二次握手

服务端B收到请求报文段之后，向A发送后确认。将同部位SYN和确认位都置为1，确认序号ack=x+1，同时自己选择一个初始序号seq=y。连接接收报文也不能携带数据，但是也要消耗一个序号，这时服务端进入SYN-RCVD(同步收到状态)

第三次握手

A收到B的确认时候要给B一个确认。确认报文段的确认位ACK=1,确认号ack=y+1,自己的序号seq=x+1。这时,TCP连接已经建立，客户端进入ESTABLISHED（已建立连接状态）。B收到A发出的确认报文之后也进入已建立连接状态

状态转换

在TCP连接建立的过程中会涉及到状态的转换，下面以有限状态机的形式给出在连接建立、数据传送和连接终止时所发生事件之间是如何转换的。

三次握手源代码分析

经过前一次实验，我们调研了socket相关的系统调用，了解了在服务器端与客户端socket建立、连接、通信以及终止过程中所涉及到的系统调用。

其中，在服务器端相继调用__sys_socket、__sys_bind和__sys_listen内核函数后，服务器进入监听状态，即打开端口被动地等待客户端连接。当客户端调用__sys_connect发出连接时，这就是我们今天所探讨地tcp三次握手过程的开始了。

那么，在TCP三次握手这个过程中所涉及到的调用过程是怎样的呢？

创建Socket

socket(AF_INET, SOCK_DGRAM, IPPROTO_TCP)  

调用接口SYSCALL_DEFINE3(socket)

其中涉及两步关键操作：sock_create()与sock_map_fd()。

retval = sock_create(family, type, protocol, &sock);  
if (retval < 0)  
    goto out;  
retval = sock_map_fd(sock, flags & (O_CLOEXEC | O_NONBLOCK));  
if (retval < 0)  
    goto out_release;  

sock_create()用于创建socket，sock_map_fd()将之映射到文件描述符，使socket能通过fd进行访问。

在sock_create()中，与我们之前所分析的socket其他API处理逻辑一样，它直接调用了相对应的内核处理函数。

sock_create() -> __sock_create()

而我们从__sock_create()代码可以看到创建包含两步：sock_alloc()和pf->create()。

sock_alloc()分配了sock内存空间并初始化inode；pf->create()初始化了sk。

int __sock_create(struct net *net, int family, int type, int protocol,
             struct socket **res, int kern)
{
    int err;
    struct socket *sock;
    const struct net_proto_family *pf;

    /*
     *      Check protocol is in range
     */
    if (family < 0 || family >= NPROTO)
        return -EAFNOSUPPORT;
    if (type < 0 || type >= SOCK_MAX)
        return -EINVAL;

    /* Compatibility.

       This uglymoron is moved from INET layer to here to avoid
       deadlock in module load.
     */
    if (family == PF_INET && type == SOCK_PACKET) {
        pr_info_once("%s uses obsolete (PF_INET,SOCK_PACKET)\n",
                 current->comm);
        family = PF_PACKET;
    }

    err = security_socket_create(family, type, protocol, kern);
    if (err)
        return err;

    /*
     *  Allocate the socket and allow the family to set things up. if
     *  the protocol is 0, the family is instructed to select an appropriate
     *  default.
     */
    sock = sock_alloc();
    if (!sock) {
        net_warn_ratelimited("socket: no more sockets\n");
        return -ENFILE; /* Not exactly a match, but its the
                   closest posix thing */
    }

    sock->type = type;

#ifdef CONFIG_MODULES
    /* Attempt to load a protocol module if the find failed.
     *
     * 12/09/1996 Marcin: But! this makes REALLY only sense, if the user
     * requested real, full-featured networking support upon configuration.
     * Otherwise module support will break!
     */
    if (rcu_access_pointer(net_families[family]) == NULL)
        request_module("net-pf-%d", family);
#endif

    rcu_read_lock();
    pf = rcu_dereference(net_families[family]);
    err = -EAFNOSUPPORT;
    if (!pf)
        goto out_release;

    /*
     * We will call the ->create function, that possibly is in a loadable
     * module, so we have to bump that loadable module refcnt first.
     */
    if (!try_module_get(pf->owner))
        goto out_release;

    /* Now protected by module ref count */
    rcu_read_unlock();

    err = pf->create(net, sock, protocol, kern);
    if (err < 0)
        goto out_module_put;

    /*
     * Now to bump the refcnt of the [loadable] module that owns this
     * socket at sock_release time we decrement its refcnt.
     */
    if (!try_module_get(sock->ops->owner))
        goto out_module_busy;

    /*
     * Now that we're done with the ->create function, the [loadable]
     * module can have its refcnt decremented
     */
    module_put(pf->owner);
    err = security_socket_post_create(sock, family, type, protocol, kern);
    if (err)
        goto out_sock_release;
    *res = sock;

    return 0;

out_module_busy:
    err = -EAFNOSUPPORT;
out_module_put:
    sock->ops = NULL;
    module_put(pf->owner);
out_sock_release:
    sock_release(sock);
    return err;

out_release:
    rcu_read_unlock();
    goto out_sock_release;
}
EXPORT_SYMBOL(__sock_create);

这里，关于sock_alloc的过程我们不再过多涉及，重点内容是分析TCP三次握手的过程。

客户端流程

经过上一次实验中对客户端hello函数的分析，我们最终得出结论：

执行hello命令时，客户端所经历的流程为connect() -> send() -> recv()。

那么，按照这一过程我们对源码进行分析。

---

发送SYN报文，向服务器发起tcp连接

connect(fd, servaddr, addrlen);
    -> SYSCALL＿DEFINE3() 
    -> sock->ops->connect() == inet_stream_connect (sock->ops即inet_stream_ops)
    -> tcp_v4_connect()

其中，tcp_v4_connect()的结构图如下：

在该函数中，首先查找到达[daddr, dport]的路由项。

要注意的是由于是作为客户端调用，创建socket后调用connect，因而saddr, sport都是0，同样在未查找路由前，要走的出接口oif也是不知道的，因此也是0。在查找完路由表后(注意不是路由缓存)，可以得知出接口，但并未存储到sk中。

因此插入的路由缓存是特别要注意的：它的键值与实际值是不相同的，这个不同点就在于oif与saddr，键值是[saddr=0, sport=0, daddr, dport, oif=0]，而缓存项值是[saddr, sport=0, daddr, dport, oif]。

tmp = ip_route_connect(&rt, nexthop, inet->inet_saddr,  
                        RT_CONN_FLAGS(sk), sk->sk_bound_dev_if,  
                        IPPROTO_TCP,  
                        inet->inet_sport, usin->sin_port, sk, 1);  
if (tmp < 0) {  
    if (tmp == -ENETUNREACH)  
        IP_INC_STATS_BH(sock_net(sk), IPSTATS_MIB_OUTNOROUTES);  
    return tmp;  
}  

通过查找到的路由项，对inet进行赋值，可以看到，除了sport，都赋予了值，sport的选择复杂点，因为它要随机从未使用的本地端口中选择一个。

if (!inet->inet_saddr)  
    inet->inet_saddr = rt_rt_src;   
inet->inet_rcv_addr = inet->inet_saddr;  
……  
inet->inet_dport = usin->sin_port;  
inet->inet_daddr = daddr;  

状态从CLOSING转到TCP_SYN_SENT，这个在之前的TCP的状态转移图中阐述过了。

tcp_set_state(sk, TCP_SYN_SENT);  

插入到bind链表中。

err = inet_hash_connect(&tcp_death_row, sk); //== > __inet_hash_connect()  

当snum==0时，表明此时源端口没有指定，此时会随机选择一个空闲端口作为此次连接的源端口。low和high分别表示可用端口的下限和上限，remaining表示可用端口的数。

注意这里的可用只是指端口可以用作源端口，其中部分端口可能已经作为其它socket的端口号在使用了，所以要循环1~remaining，直到查找到空闲的源端口。

if (!snum) {  
    inet_get_local_port_range(&low, &high);  
    remaining = (high - low) + 1;  
    ……  
    for (i = 1; i <= remaining; i++) {  
        ……// choose a valid port  
    }  
}  

下面来看下对每个端口的检查，即//choose a valid port部分的代码。

这里要先了解下tcp的内核表组成，udp的表内核表udptable只是一张hash表，tcp的表则稍复杂，它的名字是tcp_hashinfo，在tcp_init()中被初始化，这个数据结构定义如下(省略了不相关的数据)：

struct inet_hashinfo {  
    struct inet_ehash_bucket *ehash;  
    ……  
    struct inet_bind_hashbucket *bhash;  
    ……  
    struct inet_listen_hashbucket  listening_hash[INET_LHTABLE_SIZE]  
                    ____cacheline_aligned_in_smp;  
};  

从定义可以看出，tcp表又分成了三张表ehash, bhash, listening_hash。

其中ehash, listening_hash对应于socket处在TCP的ESTABLISHED, LISTEN状态，bhash对应于socket已绑定了本地地址。

三者间并不互斥，如一个socket可同时在bhash和ehash中，由于TIME_WAIT是一个比较特殊的状态，所以ehash又分成了chain和twchain，为TIME_WAIT的socket单独形成一张表。

回到刚才的代码，现在还只是建立socket连接，使用的就应该是tcp表中的bhash。首先取得内核tcp表的bind表 – bhash，查看是否已有socket占用：

• 如果没有，则调用inet_bind_bucket_create()创建一个bind表项tb，并插入到bind表中，跳转至goto ok代码段；
• 如果有，则跳转至goto ok代码段。
  进入ok代码段表明已找到合适的bind表项(无论是创建的还是查找到的)，调用inet_bind_hash()赋值源端口inet_num。

for (i = 1; i <= remaining; i++) {  
    port = low + (i + offset) % remaining;  
    head = &hinfo->bhash[inet_bhashfn(net, port, hinfo->bhash_size)];  
    ……  
    inet_bind_bucket_for_each(tb, node, &head->chain) {  
        if (net_eq(ib_net(tb), net) && tb->port == port) {  
            if (tb->fastreuse >= 0)  
                goto next_port;  
            WARN_ON(hlist_empty(&tb->owners));  
            if (!check_established(death_row, sk, port, &tw))  
                goto ok;  
            goto next_port;  
        }  
    }  
        
    tb = inet_bind_bucket_create(hinfo->bind_bucket_cachep, net, head, port);  
    ……  
    next_port:  
        spin_unlock(&head->lock);  
}  
        
ok:  
    ……  
inet_bind_hash(sk, tb, port);  
    ……  
    goto out;  

在获取到合适的源端口号后，会重建路由项来进行更新：

err = ip_route_newports(&rt, IPPROTO_TCP, inet->inet_sport, inet->inet_dport, sk);  

函数比较简单，在获取sport前已经查找过一次路由表，并插入了key=[saddr=0, sport=0, daddr, dport, oif=0]的路由缓存项；现在获取到了sport，调用ip_route_output_flow()再次更新路由缓存表，它会添加key=[saddr=0, sport, daddr, dport, oif=0]的路由缓存项。这里可以看出一个策略选择，查询路由表->获取sport->查询路由表，为什么不是获取sport->查询路由表的原因可能是效率的问题。

if (sport != (*rp)->fl.fl_ip_sport ||  
                dport != (*rp)->fl.fl_ip_dport) {  
    struct flowi fl;  
        
    memcpy(&fl, &(*rp)->fl, sizeof(fl));  
    fl.fl_ip_sport = sport;  
    fl.fl_ip_dport = dport;  
    fl.proto = protocol;  
    ip_rt_put(*rp);  
    *rp = NULL;  
    security_sk_classify_flow(sk, &fl);  
    return ip_route_output_flow(sock_net(sk), rp, &fl, sk, 0);  
}  

write_seq相当于第一次发送TCP报文的ISN，如果为0，则通过计算获取初始值，否则延用上次的值。在获取完源端口号，并查询过路由表后，TCP正式发送SYN报文，注意在这之前TCP状态已经更新成了TCP_SYN_SENT，而在函数最后才调用tcp_connect(sk)发送SYN报文，这中间是有时差的。

if (!tp->write_seq)  
    tp->write_seq = secure_tcp_sequence_number(inet->inet_saddr,  
                                    inet->inet_daddr,  
                                    inet->inet_sport,  
                                    usin->sin_port);  
inet->inet_id = tp->write_seq ^ jiffies;  
err = tcp_connect(sk);  

---

客户端调用tcp_connect()发送SYN报文。

该函数的结构如下图所示。

几步重要的代码如下：

tcp_connect_init()中设置了tp->rcv_nxt=0，tcp_transmit_skb()负责发送报文，其中seq=tcb->seq=tp->write_seq，ack_seq=tp->rcv_nxt。

tcp_connect_init(sk);  
tp->snd_nxt = tp->write_seq;  
……  
tcp_transmit_skb(sk, buff, 1, sk->sk_allocation);  

收到服务端的SYN+ACK，发送ACK

tcp_rcv_synsent_state_process()

此时已接收到对方的ACK，状态变迁到TCP_ESTABLISHED。最后发送对方SYN的ACK报文。

tcp_set_state(sk, TCP_ESTABLISHED);  
tcp_send_ack(sk);  

服务器端流程

如之前replyhi命令执行时分析的一样，我们了解到服务端所经历的流程如下：

bind() -> listen() -> accept() -> recv() -> send()。

bind() -> inet_bind()

bind操作的主要作用是将创建的socket与给定的地址相绑定，这样创建的服务才能公开的让外部调用。当然对于socket服务器的创建来说，这一步不是必须的，在listen()时如果没有绑定地址，系统会选择一个随机可用地址作为服务器地址。

一个socket地址分为ip和port，inet->inet_saddr赋值了传入的ip，snum是传入的port，对于端口，要检查它是否已被占用，这是由sk->sk_prot->get_port()完成的(这个函数前面已经分析过，在传入port时它检查是否被占用；传入port=0时它选择未用的端口)。如果没有被占用，inet->inet_sport被赋值port，因为是服务监听端，不需要远端地址，inet_daddr和inet_dport都置0。

注意bind操作不会改变socket的状态，仍为创建时的TCP_CLOSE。

snum = ntohs(addr->sin_port);  
……  
inet->inet_rcv_saddr = inet->inet_saddr = addr->sin_addr.s_addr;  
if (sk->sk_prot->get_port(sk, snum)) {  
    inet->inet_saddr = inet->inet_rcv_saddr = 0;  
    err = -EADDRINUSE;  
    goto out_release_sock;  
}  
……  
inet->inet_sport = htons(inet->inet_num);  
inet->inet_daddr = 0;  
inet->inet_dport = 0;  

listen() -> inet_listen()

listen操作开始服务器的监听，此时服务就可以接受到外部连接了。在开始监听前，要检查状态是否正确，sock->state == SS_UNCONNECTED确保仍是未连接的socket，sock->type == SOCK_STREAM确保是TCP协议，old_state确保此时状态是TCP_CLOSE或TCP_LISTEN，在其它状态下进行listen都是错误的。

if (sock->state != SS_UNCONNECTED || sock->type != SOCK_STREAM)  
    goto out;  
old_state = sk->sk_state;  
if (!((1 << old_state) & (TCPF_CLOSE | TCPF_LISTEN)))  
    goto out;  

如果已是TCP_LISTEN态，则直接跳过，不用再执行listen了，而只是重新设置listen队列长度sk_max_ack_backlog，改变listen队列长也是多次执行listen的作用。如果还没有执行listen，则还要调用inet_csk_listen_start()开始监听。

inet_csk_listen_start()变迁状态至TCP_LISTEN，分配监听队列，如果之前没有调用bind()绑定地址，则这里会分配一个随机地址。

if (old_state != TCP_LISTEN) {  
    err = inet_csk_listen_start(sk, backlog);  
    if (err)  
        goto out;  
}  
sk->sk_max_ack_backlog = backlog;  

accept()

accept所涉及的调用栈比较深：accept() -> sys_accept4() -> inet_accept() -> inet_csk_accept()。

但accept()实际要做的事件并不多，它的作用是返回一个已经建立连接的socket(即经过了三次握手)。

这个过程是异步的，accept()并不亲自去处理三次握手过程，而只是监听icsk_accept_queue队列，当有socket经过了三次握手，它就会被加到icsk_accept_queue中，所以accept要做的就是等待队列中插入socket，然后被唤醒并返回这个socket。

而三次握手的过程完全是协议栈本身去完成的。换句话说，协议栈相当于写者，将socket写入队列，accept()相当于读者，将socket从队列读出。这个过程从listen就已开始，所以即使不调用accept()，客户仍可以和服务器建立连接，但由于没有处理，队列很快会被占满。

if (reqsk_queue_empty(&icsk->icsk_accept_queue)) {  
    long timeo = sock_rcvtimeo(sk, flags & O_NONBLOCK);  
    ……  
    error = inet_csk_wait_for_connect(sk, timeo);  
    ……  
}  
        
newsk = reqsk_queue_get_child(&icsk->icsk_accept_queue, sk);  

协议栈向队列中加入socket的过程就是完成三次握手的过程，客户端通过向已知的listen fd发起连接请求，对于到来的每个连接，都会创建一个新的sock，当它经历了TCP_SYN_RCV -> TCP_ESTABLISHED后，就会被添加到icsk_accept_queue中。

而监听的socket状态始终为TCP_LISTEN，保证连接的建立不会影响socket的接收。

接收客户端发来的SYN，发送SYN+ACK

所涉及到的内核函数为：tcp_v4_do_rcv()

tcp_v4_do_rcv()是TCP模块接收的入口函数。其主要结构如下图所示。

客户端发起请求的对象是listen fd，所以sk->sk_state == TCP_LISTEN，调用tcp_v4_hnd_req()来检查是否处于半连接，只要三次握手没有完成，这样的连接就称为半连接，具体而言就是收到了SYN，但还没有收到ACK的连接。

所以对于这个查找函数，如果是SYN报文，则会返回listen的socket(连接尚未创建)；如果是ACK报文，则会返回SYN报文处理中插入的半连接socket。其中存储这些半连接的数据结构是syn_table，它在listen()调用时被创建，大小由sys_ctl_max_syn_backlog和listen()传入的队列长度决定。

此时是收到SYN报文，tcp_v4_hnd_req()返回的仍是sk，调用tcp_rcv_state_process()来接收SYN报文，并发送SYN+ACK报文，同时向syn_table中插入一项表明此次连接的sk。

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)) {
            rsk = nsk;              
            goto reset;         
        }           
        return 0;       
    }   
}  
TCP_CHECK_TIMER(sk);   
if (tcp_rcv_state_process(sk, skb, tcp_hdr(skb), skb->len)) {
    rsk = sk;       
    goto reset;  
}  

tcp_rcv_state_process()处理各个状态上socket的情况。下面是处于TCP_LISTEN的代码段，处于TCP_LISTEN的socket不会再向其它状态变迁，它负责监听，并在连接建立时创建新的socket。实际上，当收到第一个SYN报文时，会执行这段代码，conn_request() => tcp_v4_conn_request。

case TCP_LISTEN:  
……  
    if (th->syn) {  
        if (icsk->icsk_af_ops->conn_request(sk, skb) < 0)  
            return 1;  
        kfree_skb(skb);  
        return 0;  
    }  

tcp_v4_conn_request()中注意两个函数就可以了：tcp_v4_send_synack()向客户端发送了SYN+ACK报文，inet_csk_reqsk_queue_hash_add()将sk添加到了syn_table中，填充了该客户端相关的信息。这样，再次收到客户端的ACK报文时，就可以在syn_table中找到相应项了。

if (tcp_v4_send_synack(sk, dst, req, (struct request_values *)&tmp_ext) || want_cookie)  
    goto drop_and_free;  
inet_csk_reqsk_queue_hash_add(sk, req, TCP_TIMEOUT_INIT);  

接收客户端发来的ACK

tcp_v4_do_rcv()

具体过程与收到SYN报文相同，不同点在于syn_table中已经插入了有关该连接的条目，tcp_v4_hnd_req()会返回一个新的sock: nsk，然后会调用tcp_child_process()来进行处理。在tcp_v4_hnd_req()中会创建新的sock，下面详细看下这个函数。

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)) {  
            rsk = nsk;  
            goto reset;  
        }  
        return 0;  
    }  
}  

tcp_v4_hnd_req()

之前已经分析过，inet_csk_search_req()会在syn_table中找到req，此时进入tcp_check_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()

syn_recv_sock() -> tcp_v4_syn_recv_sock()会创建一个新的sock并返回，创建的sock状态被直接设置为TCP_SYN_RECV，然后因为此时socket已经建立，将它添加到icsk_accept_queue中。

状态TCP_SYN_RECV的设置可能比较奇怪，按照TCP的状态转移图，在服务端收到SYN报文后变迁为TCP_SYN_RECV，但看到在实现中收到ACK后才有了状态TCP_SYN_RECV，并且马上会变为TCP_ESTABLISHED，所以这个状态变得无足轻重。

实际上，这样做的原因是因为listen和accept返回的socket是不同的，而只有真正连接建立时才会创建这个新的socket，在收到SYN报文时新的socket还没有建立，就无从谈状态变迁了。这里同样是一个平衡的存在，你也可以在收到SYN时创建一个新的socket，代价就是无用的socket大大增加了。

child = inet_csk(sk)->icsk_af_ops->syn_recv_sock(sk, skb, req, NULL);  
if (child == NULL)  
    goto listen_overflow;  
inet_csk_reqsk_queue_unlink(sk, req, prev);  
inet_csk_reqsk_queue_removed(sk, req);  
inet_csk_reqsk_queue_add(sk, req, child);  

tcp_child_process()

如果此时sock: child被用户进程锁住了，那么就先添加到backlog中__sk_add_backlog()，待解锁时再处理backlog上的sock；如果此时没有被锁住，则先调用tcp_rcv_state_process()进行处理，处理完后，如果child状态到达TCP_ESTABLISHED，则表明其已就绪，调用sk_data_ready()唤醒等待在isck_accept_queue上的函数accept()。

if (!sock_owned_by_user(child)) {  
    ret = tcp_rcv_state_process(child, skb, tcp_hdr(skb), skb->len);  
    if (state == TCP_SYN_RECV && child->sk_state != state)  
        parent->sk_data_ready(parent, 0);  
} else {  
    __sk_add_backlog(child, skb);  
}  

tcp_rcv_state_process()处理各个状态上socket的情况。

下面是处于TCP_SYN_RECV的代码段，注意此时传入函数的sk已经是新创建的sock了(在tcp_v4_hnd_req()中)，并且状态是TCP_SYN_RECV，而不再是listen socket，在收到ACK后，sk状态变迁为TCP_ESTABLISHED，而在tcp_v4_hnd_req()中也已将sk插入到了icsk_accept_queue上，此时它就已经完全就绪了，回到tcp_child_process()便可执行sk_data_ready()。

case TCP_SYN_RECV:  
    if (acceptable) {  
        ……  
        tcp_set_state(sk, TCP_ESTABLISHED);  
        sk->sk_state_change(sk);  
        ……  
        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);   
        ……  
}  

总结

最后，以图示来展示TCP三次握手涉及的过程。

运行追踪分析

首先，启动MenuOS系统，并使用gdb连接进行调试。

命令

break inet_init
break sock_create
break __sys_connect
break __sys_accept4
break tcp_v4_connect
break tcp_connect_init
break tcp_connect
break tcp_transmit_skb
break tcp_v4_do_rcv
break tcp_rcv_state_process

设置完断点，我们使用continue命令来看看是否可以捕获到这些断点。

continue 

我们首先捕获到的是inet_init断点。如我们之前分析的一样，该函数所完成的功能是TCP/IP协议栈的初始化，将所有的基础协议添加进来，因此在socket初始化之前需要先运行加载该函数。

---

继续向下运行。

这一次我们所捕获到三次__sys_socket，关于这一点我在上一篇博客中已经分析过这种情况了，此时进行的是socket的初始化过程，完成的是对网卡的配置与启动。

另外，由于sys_socketcall()是内核为socket设置的总入口，这里我们没有对__sys_socket设置断点，因此只捕获到sys_socketcall()。

接着，与我们之前的实验一样，在第一次gdb调试界面停止时我们输入replyhi命令，输入命令之后，gdb调试继续。并且再次捕获断点时可以看到我们捕获到了__sys_socket，即调用了该内核处理函数完成了我们服务器端socket的创建。

接着往下执行，我们捕获到了__sys_accept4，在qemu虚拟机中输入hello命令，来创建客户端socket。

---

好了，之前所捕获的系统调用都是连接建立之前所使用到的。

下面我们将捕获TCP三次连接相关的系统调用。

首先，我们捕获到__sys_connect，这一函数我们在之前的实验中已经提到过，它表示客户端已经准备好与服务器连接，将要发出连接请求。

我们所捕获到的下一个是tcp_v4_connect，这就是我们今天所分析的TCP三次握手相关的内容。经过之前的分析，我们知道它所做的工作是调用IP层的服务并构造SYN，准备发送SYN的事宜。

接着，我们捕获到了三次tcp_connect断点，经过之前的分析内容，我们知道该函数所做的是构建一个新的SYN并将其发送出去。

那么，为什么这里会出现三次调用呢？

仔细看gdb调试中所给出断点的详细信息，可以发现这三次调用具体所做的内容都不同。为了搞清它们具体做了什么，我们可以查看一下tcp_connect源码。

/* Build a SYN and send it off. */
int tcp_connect(struct sock *sk)
{
    struct tcp_sock *tp = tcp_sk(sk);
    struct sk_buff *buff;
    int err;

    tcp_call_bpf(sk, BPF_SOCK_OPS_TCP_CONNECT_CB, 0, NULL);

    if (inet_csk(sk)->icsk_af_ops->rebuild_header(sk))
        return -EHOSTUNREACH; /* Routing failure or similar. */

    tcp_connect_init(sk);

    if (unlikely(tp->repair)) {
        tcp_finish_connect(sk, NULL);
        return 0;
    }

    buff = sk_stream_alloc_skb(sk, 0, sk->sk_allocation, true);
    if (unlikely(!buff))
        return -ENOBUFS;

    tcp_init_nondata_skb(buff, tp->write_seq++, TCPHDR_SYN);
    tcp_mstamp_refresh(tp);
    tp->retrans_stamp = tcp_time_stamp(tp);
    tcp_connect_queue_skb(sk, buff);
    tcp_ecn_send_syn(sk, buff);
    tcp_rbtree_insert(&sk->tcp_rtx_queue, buff);

    /* Send off SYN; include data in Fast Open. */
    err = tp->fastopen_req ? tcp_send_syn_data(sk, buff) :
          tcp_transmit_skb(sk, buff, 1, sk->sk_allocation);
    if (err == -ECONNREFUSED)
        return err;

    /* We change tp->snd_nxt after the tcp_transmit_skb() call
     * in order to make this packet get counted in tcpOutSegs.
     */
    WRITE_ONCE(tp->snd_nxt, tp->write_seq);
    tp->pushed_seq = tp->write_seq;
    buff = tcp_send_head(sk);
    if (unlikely(buff)) {
        WRITE_ONCE(tp->snd_nxt, TCP_SKB_CB(buff)->seq);
        tp->pushed_seq  = TCP_SKB_CB(buff)->seq;
    }
    TCP_INC_STATS(sock_net(sk), TCP_MIB_ACTIVEOPENS);

    /* Timer for repeating the SYN until an answer. */
    inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
                  inet_csk(sk)->icsk_rto, TCP_RTO_MAX);
    return 0;
}
EXPORT_SYMBOL(tcp_connect);

嗯，这下我们就明白了。

原来，第一次调用我们进入tcp_connect这个函数，表示我们将使用该内核函数来完成客户端SYN的发送；

在第二次调用中，我们所执行的是tcp_connect_init(sk)这段代码，即完成初始化的工作，构建我们将要发送的SYN。

最后一次调用中，我们将构造好的SYN发送给服务器，向服务器发出TCP连接请求，而这里所使用的系统调用就是tcp_transmit_skb()，也就是我们之前没有捕获到的断点。

---

继续。

这次我们捕获到了tcp_v4_do_rcv和tcp_rcv_state_process这两个函数。

在之前的服务器端流程分析中，我们知道tcp_v4_do_rcv所完成的工作是接收客户端发来的SYN并发送SYN+ACK。后一个内核函数则是按照TCP状态机将此时服务器的状态修改为SYN-RCVD。

同样的，客户端在收到该消息之后，调用该内核函数来发送ACK消息，并修改客户端的状态。

最后，服务器接收到来自客户端的ACK消息，完成三次握手过程，修改状态为ESTABLISHED

至于如何区分这些操作，我们的依据就是调试信息中的套接字指针sk以及skb信息，根据这些信息我们就能够分辨出哪些是客户端的操作，哪些是服务器的操作。

此后，服务器端就准备开始与客户端之间的数据收发过程。

继续向下，这次我们捕获到tcp_write_xmit，它所完成的是将消息传递出去，而此时在Menuos系统中可以看到收发消息的列表，同样证明此时客户端与服务器完成了TCP三次连接，开始与服务器进行消息的发送与接收。

Ok，以上内容就是本次博客分享的全部了，如果有帮助到你，请给我点个推荐吧！

---

参考链接

tcp三次握手源码解析（服务端角度）

tcp_v4_connect函数

linux源码

tcp三次握手过程分析