TCP协议为啥要累积确认，报文段的单独确认不是更高效，可以减少冗余发送？
TCP协议为什么要累积确认，报文段的单独确认不是更高效，可以减少冗余发送？？？
如题
比如依次三个数据报 A B C，当前接收端收到了A和C，但是都到C时由于使用累积确认，ack是B的首字节序号，所以发送端不知道C已经被成功接收，如果超时，C也会重发，造成了发送冗余。但是单独确认就不会有这个问题，个中缘由还请高手给解释一下！！！
------解决方案--------------------
SACK应该更节省资源吧，如果发送端有很多包等待确认的话，SACK能成批确认，（确认操作是要在缓冲队列重查询的）效率更高些。但是丢包的确是个问题，没仔细想过。楼主说的GBN和SR全称是？
------解决方案--------------------
ack是用于丢包检测，并且提供拥塞信息的，最开始只有rto超时重传的机制并不会累积ack，后面改良增加了快速重传机制，当收到3条同样的ack，注意是同样的，此时就认为发生丢包，不用等到rto就可以直接重传了，效率提高了一点。
累积ack3条就是为了快速重传和恢复
如题
比如依次三个数据报 A B C，当前接收端收到了A和C，但是都到C时由于使用累积确认，ack是B的首字节序号，所以发送端不知道C已经被成功接收，如果超时，C也会重发，造成了发送冗余。但是单独确认就不会有这个问题，个中缘由还请高手给解释一下！！！
------解决方案--------------------
SACK应该更节省资源吧，如果发送端有很多包等待确认的话，SACK能成批确认，（确认操作是要在缓冲队列重查询的）效率更高些。但是丢包的确是个问题，没仔细想过。楼主说的GBN和SR全称是？
------解决方案--------------------
ack是用于丢包检测，并且提供拥塞信息的，最开始只有rto超时重传的机制并不会累积ack，后面改良增加了快速重传机制，当收到3条同样的ack，注意是同样的，此时就认为发生丢包，不用等到rto就可以直接重传了，效率提高了一点。
累积ack3条就是为了快速重传和恢复