网络协议栈(6)RFC793TCP连接时部分异常流程及实现

一、一些边界及不和谐情况
一直以为TCP的connect就是通过三次握手来实现的，但是今天看书看到说有同时打开，这个时候是四次握手。正是印证只有想不到，没有做不到的道理。当然这里不是说这是TCP的bug，而是TCP在自己的RFC中预见并讨论了这种情况，其中说明了这种同时打开出现的场景以及TCP应该表现的行为。最后的结论是相当让人镇精的，因为这个连接时可以建立起来的，而且是被TCP协议允许的，虽然这是一种非传统的连接练级方式。
看了一下RFC793《TRANSMISSION CONTROL PROTOCOL》第3.4.  Establishing a connection，里面还描述了另外一些比较冷僻的路径，其中不仅涉及到了同时打开，甚至还有崩溃之后的恢复等问题，看来这个协议还的确是尝试在不可靠的IP层上建立一个可靠的连接，即使崩溃也要有确定、预知的行为，或者说，死也要死个明白。
下面的网址是相关内容的网络上的一个文档http://www.freesoft.org/CIE/Course/Section4/10.htm，当然也可以到http://www.rfc-editor.org/搜索793看完整的TCP规范。
二、同时打开
在这这里有一个比较生动的图片，其中形象的描述了这里的流程 http://www.tcpipguide.com/free/diagrams/tcpopensimul.png。这里可以看到，两个套接口真的是心有灵犀，同时向对方发出连接请求，既然它们是这么的有缘分，那TCP规范就没有理由让这么一对有情人(哦，是有情套接口)不成眷属：

TCP RFC的3.4.  Establishing a connection中描述了这个过程，这里和三次握手最为明显的区别和特征就是当发送启动方发送了SYN报文之后，它受到的回应报文里有SYN标志，但是没有ACK标志，这个是和三次握手最为明显的区别，并且是协议栈可以感知的一个严重问题，所以不能套用三次握手的模式，而必须使用专门的代码进行控制。
我们现在就是看一下内核中对于这个连接的处理方法：
tcp_v4_do_rcv--->>>tcp_rcv_state_process--->>>tcp_rcv_synsent_state_process
    if (th->ack) {
        /* rfc793:
……
        return -1;
    }
走到这里，说明是th->ack没有置位，所以就是上面说的特殊情况，可能是同时打开的一个特征，
    if (th->syn) {
        /* We see SYN without ACK. It is attempt of
         * simultaneous connect with crossed SYNs.
         * Particularly, it can be connect to self.
         */
        tcp_set_state(sk, TCP_SYN_RECV);这里最为重要的就是即使没有ack，同样进入TCP_SYN_RECV，只要对方回应了ACK之后，就可以进入ESTABLISHED状态，
……      
   tcp_send_synack(sk);自己本着团结互助的原则，同样给对方发送一个ACK，从而让对方也进入连接状态，从而它们两个就建立了连接。
这里还有神奇的一个特征，它们都不需要侦听，连个都是只要bind之后，不需要执行listen系统调用成为侦听套接口，这真是和谐家庭的典范！
三、重复SYN
没有找图，就用RFC的说明将就点看了。

      TCP A                                                TCP B

  1.  CLOSED                                               LISTEN

  2.  SYN-SENT    --> <SEQ=100><CTL=SYN>               ...

  3.  (duplicate) ... <SEQ=90><CTL=SYN>               --> SYN-RECEIVED

  4.  SYN-SENT    <-- <SEQ=300><ACK=91><CTL=SYN,ACK>  <-- SYN-RECEIVED

  5.  SYN-SENT    --> <SEQ=91><CTL=RST>               --> LISTEN
  

  6.              ... <SEQ=100><CTL=SYN>               --> SYN-RECEIVED

  7.  SYN-SENT    <-- <SEQ=400><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED

  8.  ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK>      --> ESTABLISHED

                    Recovery from Old Duplicate SYN

                               Figure 9.

 这里看一下TCP A的处理流程，这里TCP A 之前发送的序列号为90的报文在网上迷茫了一段时间，然后竟然又神奇的到达了TCP B。但是在A游荡的过程中，TCP A已经不耐烦了，重新发送了一个同步报文，这次它的序列号比原来的序列号可能要大(如果相等的话，服务器多接受一次相同的同步消息是没有关系的，坏就坏在可能受到不同的seq号的消息)。规范里说，server对这个同步是没有判断能力的，因为server本质工作就是等待SYN连接，进门都是客，也不好就直接拒绝一个连接。但是连接的发送方是知道自己的情况的，因为server的响应(IP+TCPPORT)报文可以唯一确定本机上的一个套接口，这个套接口又是有状态的，所以这个client套接口就可以知道服务器是不是受到了重复的早期同步报文。这里一点是，TCP的server(listen状态的server socket)总是对第一个SYNC做出正确的反应，即在请求seq的基础上加一作为ack_seq，然后给出自己的seq，并在回应报文中置位SYN和ACK标志。好了，服务器到时利索了，那就看客户端了。客户端的实现代码为：
tcp_v4_do_rcv--->>tcp_rcv_state_process--->>>tcp_rcv_synsent_state_process
if (th->ack) {
        /* rfc793:
         * "If the state is SYN-SENT then
         *    first check the ACK bit
         *      If the ACK bit is set
         *      If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send
         *        a reset (unless the RST bit is set, if so drop
         *        the segment and return)"
         *
         *  We do not send data with SYN, so that RFC-correct
         *  test reduces to:
         */
        if (TCP_SKB_CB(skb)->ack_seq != tp->snd_nxt) 对于上面的例子，这里的TCP_SKB_CB(skb)->ack_seq为91，而tp->snd_nxt则为101，即上面第二行中的101报文的确认号。因为确认中的90报文是半路杀出的程咬金，所以客户端是不承认(或者感知不到)这个SYN的。
            goto reset_and_undo;
……
reset_and_undo:
    tcp_clear_options(&tp->rx_opt);
    tp->rx_opt.mss_clamp = saved_clamp;
    return 1;

然后返回到tcp_v4_do_rcv函数中
    if (tcp_rcv_state_process(sk, skb, skb->h.th, skb->len)) {这里返回值为1，所以reset
        rsk = sk;
        goto reset;
    }
……
reset:
    tcp_v4_send_reset(rsk, skb);这里就发送了reset，对方要倒霉了，这属于单方面反悔行为。
四、一方猝死之后的再连接
这种情况发生在两个套接口是正在友好连接的时候，之后由于系统崩溃，此时整个系统信息丢失。其实也没有必要系统崩溃，只要这个进程被内核强制关闭就好了(未确认)。就好像电视剧里演绎的，突然间来了一个大的动荡，从此那人儿杳无音讯，然后过一段时间，他/她又突然出现，此时他们的再次接触会擦出什么样的火花？

      TCP A                                           TCP B

  1.  (CRASH)                               (send 300,receive 100)

  2.  CLOSED                                           ESTABLISHED

  3.  SYN-SENT --> <SEQ=400><CTL=SYN>              --> (??)

  4.  (!!)     <-- <SEQ=300><ACK=100><CTL=ACK>     <-- ESTABLISHED

  5.  SYN-SENT --> <SEQ=100><CTL=RST>              --> (Abort!!)

  6.  SYN-SENT                                         CLOSED

  7.  SYN-SENT --> <SEQ=400><CTL=SYN>              -->

                     Half-Open Connection Discovery

                               Figure 10.
此时的状态是对方还处于甜蜜的连接状态建立态，而此时的TCP A经过一次涅槃之后再次来连接TCP B(我们可以认为这货失意了)。这里就造成TCP B就很困惑，在第三行可以看到 TCP 的状态为 “？？”(神马情况??)。此时由于连接已经建立，所以TCP B 变得比较固执，它认为TCP A此时只是一个恶意的玩笑，所以它再次强调一下，自己希望收到的报文序列号是100(即第四行的ACK=100，并且自己的当前序列号为300)，希望对方别逗了。
此时轮到TCP A大吃一惊了"!!"，所以一不做二不休，直接复位一下连接吧，所以发送了RST。虽然这是一封绝交信，但是基本的礼仪还是要遵守的，比方说它依然是使用了对方希望的序列号100，虽然它之前对这个序列号一无所知(因为它是是刚创建的套接口，并且它自主选择的序列号为第三行中体现的400，此时为了弄死对方，它违心的选择了对方ack中要求的序列号100)。
当这个包含着RST标志的报文到达对方之后，对方只能就范，被推倒了，直接abort。
这里TCP A 发送RST的流程其实是和第三节中描述的路径相同的，同样是不满足
  if (th->ack) {
        /* rfc793:
         * "If the state is SYN-SENT then
         *    first check the ACK bit
         *      If the ACK bit is set
         *      If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send
         *        a reset (unless the RST bit is set, if so drop
         *        the segment and return)"
         *
         *  We do not send data with SYN, so that RFC-correct
         *  test reduces to:
         */
        if (TCP_SKB_CB(skb)->ack_seq != tp->snd_nxt) 这里TCP_SKB_CB(skb)->ack_seq100，而tp->snd_nxt为401。
            goto reset_and_undo;
五、TCP_SKB_CB(skb)->ack_seq 的初始化
位于函数
int tcp_v4_rcv(struct sk_buff *skb)：

    TCP_SKB_CB(skb)->seq = ntohl(th->seq);
    TCP_SKB_CB(skb)->end_seq = (TCP_SKB_CB(skb)->seq + th->syn + th->fin +
                    skb->len - th->doff * 4);
    TCP_SKB_CB(skb)->ack_seq = ntohl(th->ack_seq);即是和TCP头中的名字相同并一一对应的。
……
        {
            if (!tcp_prequeue(sk, skb))
            ret = tcp_v4_do_rcv(sk, skb);
        }