还有个 FACK，它是基于 SACK 用来作为重传过程中的拥塞控制，相对于上面的 New Reno 我们就知道它有 SACK 所以不需要一个一个试过去，具体我不展开了。
还有哪些拥塞控制算法？从维基上看有这么多。
本来我还想哔哔几句了，哔哔了之后又删了，感觉说了和没说一样，想深入但是实力不允许，有点惆怅啊。
各位看官自个儿查查吧，或者等我日后修炼有成再来哔哔。
总结说了这么多来总结一下吧。
TCP 是面向连接的，提供可靠、有序的传输并且还提供流控和拥塞控制，单独提取出 TCP 层而不是在 IP层实现是因为 IP 层有更多的设备需要使用，加了复杂的逻辑不划算。
三次握手主要是为了定义初始序列号为了之后的传输打下基础，四次挥手是因为 TCP 是全双工协议，因此双方都得说拜拜。
SYN 超时了就阶梯性重试，如果有 SYN攻击，可以加大半队列数，或减少重试次数，或直接拒绝。
TIME_WAIT 是怕对方没收到最后一个 ACK，然后又发了 FIN 过来，并且也是等待处理网络上残留的数据，怕影响新连接。
TIME_WAIT 不建议设小，或者破坏 TIME_WAIT 机制，如果真想那么可以开启快速回收，或者重用，不过注意受益的对象。
超时重传是为了保证对端一定能收到包，快速重传是为了避免在偶尔丢包的时候需要等待超时这么长时间，SACK 是为了让发送方知道重传哪些。
D-SACK 是为了让发送方知道这次重传的原因是对方真的没收到还是自己太心急了 RTO 整小了，不至于两眼一抹黑。
滑动窗口是为了平衡发送方的发送速率和接收方的接受数率，不至于瞎发，当然还需要注意 Silly Window 的情况，同时还要注意纳格算法和延迟确认不能一起搭配。
而滑动窗口还不够，还得有个拥塞控制，因为出行你我他，安全靠大家，TCP 还得跳出来看看关心下当前大局势。
最后至此就差不多了，不过还是有很多很多细节的，TCP 协议太复杂了，这可能是我文章里面图画的最少的一篇了，你看复杂到我图都画不来了哈哈哈。
今天我就说了个皮毛，如有纰漏请赶紧后台联系鞭挞我。
https://www.ionos.com/digitalguide/server/know-how/introduction-to-tcp/
https://www.ibm.com/developerworks/cn/linux/l-tcp-sack/
https://coolshell.cn/articles/11564.html/
https://tools.ietf.org/html/rfc793
https://nmap.org/book/tcpip-ref.html
我是 yes，从一点点到亿点点，我们下篇见。