纸上学来终学浅，绝知此事要躬行。
今日和友人争辩快速重传，只拿着书本上的东西和人对飙近20分钟，还自认为略有取胜，真是汗颜加羞愧。
中文版计算机网络，书上还写着接收到3次重复ACK启用快速重传。TCP/IP详解卷上写着TCP启用FACK算法，会比对ACK和最高水位SACK间的跨度，明确未确认skb包个数，和快速重传阈值dupthresh比较，以此为据，启用快速重传。
指导用书提供了这个检测“快速重传机制”的思想。
但看了点书，就觉得这东西了如指掌，这是旧时代书生的做派，可惜我一个新时代青年也沾染上了这恶习，再次表示惭愧。
这个时代，什么东西都在变，尤其技术变得更快，更何况TCP还开源。拿着纸面上的东西和人争的面红耳赤，到头来也只是跳梁小丑，自取其辱。但好在我这人算进取，知错能改，这次的教训只是让好朋友看了个笑话，自然不打紧。
那就说说“进化后”的TCP-FACK，书本上通俗易懂的“快速重传”和“FACK算法”在如今的Linux上又是如何实现。
Linux的TCP-FACK实现关键函数tcp_force_fast_retransmit是这样
static bool tcp_force_fast_retransmit(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
return after(tcp_highest_sack_seq(tp),
tp->snd_una + tp->reordering * tp->mss_cache);
}
其实，从这里就可以看出不少信息，一是函数的命名tcp_force_fast_retransmit，这基本告诉开发者，FACK算法已经是TCP“快速重传”所必须的。通读一版“快速重传机制”的整体流程，果然验证了这一点，这意味着FACK不再是启动失效，而是TCP默认生效并且不可取缔的（net.ipv4.sysctl_tcp_fack的设置没用了）。二是FACK的快速重传检测机制依旧顺承的是SACK，只有SACK生效，FACK才能发挥作用，但SACK并不是必须的，SACK没有启动时，tcp_force_fast_retransmit里与SACK挂钩的变量走初始值，这也意味着FACK不会生效。
光说有点干，给张图。
现在，Linux实现的TCP-FACK很直达胸意，又没有将责任推卸给其他，这里TCP值得肯定。
FACK也就这点东西，一个很简单的启发式。最后再说下Linux里，怎么实现的重复ACK触发“快速重传”，因为上面FACK没有涉及，但这又是每个CS专业接触最多的。但为了避免跑题，不过细解读，只给个出处。
拥塞状态机转移函数tcp_fastretrans_alert，给出了检测快速重传的结果。
bool do_lost = num_dupack || ((flag & FLAG_DATA_SACKED) &&
tcp_force_fast_retransmit(sk));
num_dupack表示的就是重复ACK计数。
返回值do_lost将指导后面标记LOST的tcp_update_scoreboard函数，是否将未明确的重传队列数据包的控制块上sacked标记成TCPCB_LOST，以此表示数据包丢失，驱动tcp_xmit_retransmit_queue快速重传。
TCP也不是越描越黑，这是我盼望的。
我也不是赵括，再说赵括也是被黑化了的，但光看书就高谈阔论确实不妥，容易打脸，懂得都懂，是吧，陶苏。