上一期咱们把TCP稳如泰山的三大核心机制——滑动窗口、流量控制、拥塞控制彻底盘明白了。这三者强强联手既守住了可靠传输的底线又大幅提升传输效率让数据既稳又快地跑在网络里。但TCP对性能的“抠搜”可不止于此在不牺牲可靠性的前提下它还在各种细节里疯狂优化减少无用报文、榨干每一点传输效率。本期咱们继续拆解TCP第7、第8个核心机制延迟应答与捎带应答✨。这俩机制不负责保证可靠纯纯是性能优化神器看完你会直呼TCP设计也太细了纯优化高性能的机制TCP核心机制7延迟应答延迟应答它是一个提升效率的机制这里边他是和我们的滑动窗口中的流量控制是有关系的。我们默认情况下接收方都是在接收到数据报的第一瞬间就返回ack但是呢我们可以通过延迟返回的方式来提高效率。那这样的延迟为什么就能够提高效率呢因为稍等一会的这个过程中接收方的应用程序它就可以多消费一部分数据了从而呢我们就可以反馈一个更大的滑动窗口给发送端。上一期我们谈到过流量控制我们说了我们的流量控制是根据接收方将接收缓冲区剩余容量的返回。然后的话如果我们多等一会再返回的话我们再等一会的这个过程中应用程序就会消耗掉缓冲区中的一部分数据从而返回的更大的滑动窗口大小从而让发送端发送更快自然就提高了效率[注意发送快就是代表你一次发的数据是比较多的。]那延迟应答具体要延迟多久呢注意你延迟太久也不行。如果延迟太久可能就会触发超时重传。所以针对这样的一个问题我们具体的等待时间是可配置的这样的时间一定要考虑超时重传的超时时间【一定要比超时时间短】那么这个延迟应答具体是怎么个延迟法呢它有两个方式1数量控制每隔n个包我就应答一次。这样的话我们返回的ack少了从而提高效率且不会因为少而影响可靠性因为确认应答它的序号能代表之前的所有数据都已收到。2时间限制超过最大延迟时间我就应答一次。【我们具体的等待时间是可配置的这样的时间一定要考虑超时重传的超时时间一定要比超时时间短】TCP核心机制8捎带应答捎带应答也是一种提升效率的机制。我们之前讨论的延迟应答是在滑动窗口基础上提高效率的而捎带应答则是在延迟应答的基础上进一步优化。换句话说基于延迟应答我们引入了捎带应答。在网络通信中最经典的模型就是“一问一答”客户端发送一个请求服务器返回一个响应。如下图所示图中的请求和响应属于业务数据而这些业务数据本身也需要通过 ACK 进行应答。应用程序在生成响应时需要经历一定的计算和逻辑处理这个过程会消耗时间。正常情况下ACK 和响应是分开发送的。但正如我们刚才提到的ACK 采用了延迟应答机制即会等待一小段时间再发送ACK在这个等待过程中很有可能响应也正好准备就绪。此时ACK 就可以“搭乘”响应的顺风车一起发送出去。这样一来返回的响应数据既承载了业务响应又起到了 ACK 的作用。疑问为什么我们说是“ACK搭响应的顺风车”而不是反过来“响应搭ACK的顺风车”核心在于延迟应答的等待对象。延迟应答的本质是“等”延迟应答机制是说收到数据后不立即返回ACK而是等一小段时间比如40ms~200ms希望在这段时间内本端应用层恰好也要向对端发送业务数据。如果能等到就把ACK和业务数据合并发送。谁在等谁当服务器收到客户端的请求后它需要返回ACK确认收到请求。同时服务器程序正在处理请求将要生成响应数据。延迟应答让ACK主动等待响应数据准备好。因此最后发出的是一个带ACK标志的响应数据包→ ACK搭了响应的便车。为什么不是反过来如果让“响应搭ACK”意味着响应数据去等待ACK先发。但ACK本身没有“等待响应”的动机ACK的唯一职责就是确认收到数据它没必要等。而且如果ACK先发了响应后到那就需要再发一个单独的响应包反而浪费了合并的机会。正是因为有延迟应答ACK才刻意滞后给了响应数据一个“赶上来”的时间窗口。一句话总结延迟应答创造了一个时间缓冲让本该单独发送的ACK有机会附着在即将发出的响应数据上所以是“小个子的ACK搭上了大个子的响应顺风车”。反过来响应数据没有理由去等一个已经可以随时发出的ACK。这种模型是否似曾相识我们在讲解 TCP 四次挥手时提到过通常情况下挥手需要四次但在特定机制下可以缩减为三次。这里的捎带应答正是实现四次挥手变为三次的关键所在。到这里TCP的延迟应答和捎带应答这两大高性能优化机制就讲完啦✅。它们依托滑动窗口与流量控制通过延迟ACK、让确认报文“搭顺风车”的方式大幅减少纯ACK报文数量让一问一答的网络交互更高效、更省带宽。TCP核心传输逻辑基本讲完但它面向字节流的特性还会带来经典的粘包问题再加上网络波动、断开、丢包等各种异常场景也是必须掌握的重点。下一期咱们直接进入TCP收尾阶段盘第9、第10个机制TCP 收尾面向字节流粘包问题与异常场景处理【传输层】。老铁们别忘了点赞、关注➕、收藏⭐咱们下期继续把TCP彻底吃透不见不散