![]()
{"ops":[{"insert":"前言"},{"attributes":{"header":1},"insert":"\n"},{"insert":"今天继续讲 TCP 更进一步的知识。（巨复杂，做好心理准备）\n如果文章和别人的文章很相似，不是复制，而是我看别人的文章看多了，大多都背下来了……所以就会导致和别人相似……\n不多说了，发车！\n前情回顾"},{"attributes":{"header":1},"insert":"\n"},{"insert":"上期地址： CV21335319\nTCP 是一种面向连接的、可靠的、基于字节流的传输层协议；TCP 能够处理历史遗留数据包；TCP 重传分为超时重传（以时间驱动）与快速重传（以数据驱动）。\n滑动窗口"},{"attributes":{"header":1},"insert":"\n"},{"insert":"用传统的 TCP 传输数据，有一个缺点：必须收到 Ack 回应，才能传输下一个数据。\n这将会导致传输效率随着 RTT 的增长而大幅减缓，所以 TCP 引入了"},{"attributes":{"bold":true},"insert":"滑动窗口"},{"insert":"这个概念。\n滑动窗口（Window），本质上是连接双方开辟的一片储存（缓存）空间，专为一个 TCP 连接服务。\n首先看看发送方的滑动窗口：\n"},{"attributes":{"color":"#2ac864"},"insert":"已发送并收到 Ack"},{"insert":" | "},{"attributes":{"color":"#00aeec"},"insert":"已发送但未收到 Ack"},{"insert":" | "},{"attributes":{"color":"#ffb027"},"insert":"未发送但在接收方处理范围内"},{"insert":" |"},{"attributes":{"color":"#f85a54"},"insert":" 未发送且超出接收方处理范围"},{"insert":"\n接收方有一个处理范围，每次 Ack 都会通报处理范围，以便发送方合理安排数据的发送。\n现假设一个发送方的滑动窗口：\n"},{"attributes":{"color":"#2ac864"},"insert":"10 11 12 13"},{"insert":" | "},{"attributes":{"color":"#00aeec"},"insert":"14 15 16 17 18 19 20"},{"insert":" | "},{"attributes":{"color":"#ffb027"},"insert":"21 22 23"},{"insert":" | "},{"attributes":{"color":"#f85a54"},"insert":"24 25 26 27"},{"insert":"\n如果发送方收到了 5 字节的 Ack，那么滑动窗口便会向右移动 5 字节，如下：\n"},{"attributes":{"color":"#2ac864"},"insert":"10 11 12 13 14 15 16 17 18"},{"insert":" | "},{"attributes":{"color":"#00aeec"},"insert":"19 20"},{"insert":" | "},{"attributes":{"color":"#ffb027"},"insert":"21 22 23 24 25 26 27 28"},{"insert":" | "},{"attributes":{"color":"#f85a54"},"insert":"29 30 31"},{"insert":"\n那么发送方就可以继续发送黄色区域的内容；这便是滑动窗口的作用。\n接收方的滑动窗口：\n"},{"attributes":{"color":"#2ac864"},"insert":"已接收"},{"insert":" | "},{"attributes":{"color":"#00aeec"},"insert":"未接收但在处理范围内"},{"insert":" | "},{"attributes":{"color":"#f85a54"},"insert":"未接收且不在处理范围内"},{"insert":"\n"},{"attributes":{"color":"#18191c"},"insert":"这个比较好理解，就不多说了。"},{"insert":"\n窗口关闭"},{"attributes":{"header":2},"insert":"\n"},{"insert":"假定一个服务端作为接收方。此时服务器肥肠的繁忙，128G 的内存已经填满了 127.8G，那么此时服务端应该如何处理？\n如果客户端仍然向服务端扔数据包，那么服务器迟早宕机。\n为了解决客户端继续发数据包的情况，服务端会在资源紧缺时通报一个为零的窗口。\n通报的窗口为 0 时，客户端便会暂停发送数据，转而等待服务端的数据包。服务端满血复活后，会发送数据包，告诉客户端当前的窗口，该数据包称为"},{"attributes":{"bold":true},"insert":"通报非零窗口数据包"},{"insert":"。（非专业说法，仅为了方便表述）\n"},{"attributes":{"bold":true},"insert":"不过，窗口关闭其实有风险。"},{"insert":"\n如果服务端在窗口关闭后，通报非零窗口数据包丢失，会发生什么？\n此时，客户端一直会等待服务端的非零窗口通报，而服务端也会一直等待客户端的数据，此时就形成了死锁的局面。\n为了防止死锁，客户端每隔一段时间便会发送 TCP Keep-Alive 报文，用于探测 TCP 连接是否存活，当然也可以用于探测服务端窗口。\nTCP Keep-Alive 报文无论丢失还是得到为零窗口，都会等待双倍的超时时间。\n曾经有个笑话，等了这么长时间，服务器还是繁忙，你还能上王者吗？\n流量控制"},{"attributes":{"header":2},"insert":"\n"},{"insert":"接收方即使只有 1 字节的滑动窗口，发送方还是会义无反顾的把这一字节发出去。\n要知道，TCP 头、IP 头、MAC 头，加起来总共有几十字节；为了一字节数据，搭上这么大开销，属实浪费。\n所以发送方不能无脑的乱扔数据，要考虑接收方的处理能力。\n解决方法也很简单，发送方不要把接收方的滑动窗口填满，取接收方滑动窗口的 80% 左右即可。\n拥塞控制"},{"attributes":{"header":1},"insert":"\n"},{"insert":"不是已经有流量控制了吗？为啥还要有拥塞控制？\n流量控制是为了防止数据堆满接收方的内存，而拥塞控制是为了防止数据填满整个网络。\nTCP 允许数据包在没有收到 Ack 时继续发送，因此发送方能够一次性发送多个数据包。\n但是这样存在一个缺点，数据包太多，就容易造成拥塞，拥塞后就容易丢包，丢包后又会再次重传，再次导致数据包变多，导致恶性循环。\n因此，TCP 会在网络拥塞时牺牲自己，减少一次性发送的数据包数量，避免拥塞。\n面试中经常遇到一个问题：“TCP 和 UDP 的区别是什么”，其中有一点区别就在这里。\nTCP：丢包了？那怎么能行呢？赶紧重传一下，是我发的太快了，还是网络不好？\nUDP：丢包了？关我【字段删除】事\n慢启动算法"},{"attributes":{"header":2},"insert":"\n"},{"insert":"TCP 连接中有一个变量，叫做 Cwnd，拥塞窗口。这便是一次性发送的数据包数量。\n在慢启动算法中，Cwnd 初始值为 1，每发送一组数据包，都会将 Cwnd 翻倍。\n那么慢启动算法到何时结束？\n每个连接还有一个变量 SSThresh，慢启动门限。当 Cwnd < SSThresh 时，使用慢启动算法；否则使用拥塞避免算法。\n拥塞避免算法"},{"attributes":{"header":2},"insert":"\n"},{"insert":"拥塞避免算法中，每收到一个 Ack，Cwnd 增加 1/Cwnd。换句话说，每完成一组数据包的发送，Cwnd += 1。\n出现超时重传"},{"attributes":{"header":2},"insert":"\n"},{"insert":"出现超时重传时，处理方法如下：\nSSThresh = Cwnd/2\nCwnd = 1\n由于该处理方法将 Cwnd 设为 1，因此它比较突然，用户体验可能是突然卡了一下。\n出现快速重传"},{"attributes":{"header":2},"insert":"\n"},{"insert":"出现快速重传时，若本轮共有 m 个数据包收到 Ack，处理方法如下：\nCwnd = Cwnd/2\nSSThresh = Cwnd\nCwnd += m\nTCP 认为快速重传是意外的丢包，并不是严重的网络堵塞，不会突然降低，因此不会造成巨大影响。\n总结"},{"attributes":{"header":1},"insert":"\n"},{"insert":"本期讲了 TCP 滑动窗口与拥塞控制（是不是巨复杂？）\n这些都是我在看春晚的时候拿手机码出来的……点个赞吧……\n好了，两千字了，先水到这里。\n"}]}
标签：
