tcp数据包接收流程整理.docVIP

二是当前没有进程 /用户等待处理该 sk 上的报文,即 tp-ucopy.task为 0时,也不能使用 pre_queue。 我们来看这里面两个判断项,前面的说明过了,后面一个条件的成立是在什么情况下呢?通过查阅资 料,其实进程不锁定 sock ,除了①还没开始处理数据,还有另外一种情况,②就是获取的数据不够多,进程 休眠等待数据。想要不返回 0,也就说需要 tp-ucopy.task! =null, 表示当前正在等待数据,可是进入到这里 的 先决条件 就是 sock 没有被锁住,所以只有可能是第二种情况,当出现这种情况,不返回 0,我们继续往下 看。 然后就是直接调用 __skb_queue_tail(tp-ucopy.prequeue, skb; 将数据包加入到 prequeue 的等待队列当中 去。 不过,当 skb 刚刚挂载到 prequeue 当中, tcp_prequeue紧接着就会将该数据包取下,然后唤醒等待进程,处 理数据包去了,这里调用的使用一个 sk-sk_backlog_rcv(sk, skb函数指针, sk 是在 tcp_v4_rcv(当中通过 __inet_lookup_skb(tcp_hashinfo, skb, th-source, th-dest;获得的,依据当前进程上下文(ftrace ,可以判 断,该函数指针指向的是 tcp_v4_do_rcv(sk, skb, 我们接着看 tcp_v4_do_rcv(sk, skb, 它是应用层系统调用 跟 内核数据包传递的交互之处,下面有一张图, 很好的解释了整个流程。 我们先继续看 tcp_v4_do_rcv, 其中会调用 tcp_rcv_established, tcp_recvmsg当中调用 release_sock,其中又 _release_sock,又调用函数指针,处理 ......backlog 里的东西 这里所说的处理 prequeue 应该是以防万一,真正的 prequeue 处理还是在上面的 tcp_prequeue fast path需要一些附加条件, 其含义是复制到用户空间或者按序进入receive_queue的处理路径,slow path指的是乱序报文的处理以及其他不符合 fast path的数据包的处理方式。这些path与数据报文进入那个队列没有关系,一般是将fast path分为两类: 直接复制进用户空间的路径是most-fast-path,没有进程上下文导致按序的skb进入receive_queue的是more-fast-path。 由于处理乱序包或缓冲区用尽这些情况很麻烦,因此处理这些情况的path就是slow-path,具体是什么path是根据 tcp语义和数据包特性来确定的,和具体协议栈的实现没有关系。 (队列 1 tcp_prequeue_process里面有这么一段,处理 backlog if (copied = target { /* Do not sleep, just process backlog. */ release_sock(sk; lock_sock(sk; } else sk_wait_data(sk, timeo; (sk_wait_data - wait for data to arrive at sk_receive_queue 估计这里释放 sock ,下面的才可以将数据添加到 prequeue 里面有一个 sk_wait_event, 里面会调用 release_sock (队列 2 还有这一段,处理 prequeue , do prequeue while ((skb = __skb_dequeue(tp-ucopy.prequeue != NULL sk_backlog_rcv(sk, skb; 很明显,将 prequeue 当中的 skb 填充到 receive_queue当中去 (队列 3 当然,依据下面所说的法则,最先处理的应当是 receive_queue,开头有这样一段代码 /* Next get a buffer. */ skb_queue_walk(sk-sk_receive_queue, skb 从receive_queue当中获取skb指针,经过判断(验证数据包之后, goto found_ok_skb; 然后我们去看那个 标号处,这中间越过了 backlog 和 prequeue 的处理之处,然后我们看到了 skb_copy_datagram_iovec(skb, offset, msg-msg_iov, used;拷贝到用户空间。 通过上面 3个接收队列的处理我们可以发现,当 receive_queue当中没有数据的时候就会调用处理另两个队列 填充接收队列。