转发乱序与TCP

我们知道，基于网络分层的思想，TCP与IP转发，可以说是互不干涉的，转发平面（或者路由器）尽力而为的转发报文；而TCP对下层链路是不感知的，为了最大带宽的利用率，启动后以慢启动方式快速的扩大拥塞窗口，直到丢包发生，进入拥塞避免阶段（收到对方3个冗余ACK）或者慢启动阶段（超时丢包）收缩拥塞窗口，接着又开始继续扩大拥塞窗口发送报文。

虽然IP转发可以不理会TCP的处理方式，协议并没有要求。但如果IP转发能够做点事情，帮助TCP链路更为平滑，岂不是更好。

下面举个多核转发乱序，导致TCP流量下降，以及如何解决的问题。

假设发送端发送了5个报文，序号分别是1,2,3,4,5，接收端期望也是按顺序收到1,2,3,4,5，如果接受端收到了1之后，没有收到2，但收到了3,4,5，接收端会发送3个ACK，应答报文指明了期望收到的序号是2，发送端连续收到了3个冗余ACK，会进入拥塞避免阶段，拥塞窗口收缩为一半+3个报文段的大小，拥塞窗口的收缩，将影响了发送端发送报文的流量。可以简单理解为开始水龙头是全部打开的，这时候水流是比较大的，在出现问题后，水龙头只打开一半多一点点，水流就降低了很多。

单核转发，问题并不大，通常是报文先到先处理，那么顺序是可以保证的。

但在多核转发下，问题就很容易出现了。对于同一个输入端口，有多个核处理报文，由于各种报文的处理路径并不一致（TCP/UDP/ICMP等等），可能有些报文处理的快些，有些报文处理的慢些。比如前面的例子，假如系统有5个核，分别处理上面报文的1,2,3,4,5，核2因某些原因处理的较慢或者说被阻塞了，核3,4,5处理的较快，就先把报文3,4,5转发出去了，接受端由于先收到的报文不是期望的，就连续发送了3个ACK过去，表示期望的报文序号是2，导致发送端的窗口收缩，流量下降。

实际这种情况是由于转发系统乱序引起的。

那么转发系统能做什么事情避免这种情况发生呢？可以进行保序处理，即在接受到报文后，打上一个序号，发送出去时按序发送，问题不就解决了。