TCP的可靠性与高效性的保证：确认应答、超时重传、流量控制、拥塞控制

TCP实现可靠性与高效性的机制主要有：

• 确认应答机制(ACK，通过序列号实现)
• 超时重传机制
• 流量控制
• 拥塞控制

TCP实现可靠性与高效性的机制

确认应答机制

每个TCP数据段都有一个编号，叫做序列号。
在TCP中，当发送端的数据到达接收主机时，接收端主机会返回客户端一个已收到数据的应答，叫做确认应答（ACK）。
TCP通过确认应答（ACK）实现可靠的数据传输。当发送端将数据发出之后会等待对端的确认应答。如果收到确认应答，说明发送的数据已经成功到达对端；反之，则数据丢失的可能性很大。


每一个序列号都有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据，下一次你从哪里开始发。

由上图分析：当主机1给主机2发送了1～1000这么多数据时，主机2如果收到了就会给主机1应答（ACK报文段，每一个ACK报文段中都带有对应的确认序列号），表示你给我发的1～1000的数据我已经全部收到了（收到哪些数据），下次你再给我发就给我从1001数据开始发（下次从哪里开始发）。那么主机1收到应答之后就知道对方已经收到了1~1000的全部数据，所以再一次发送数据的时候他就会从1001开始发，后面都是依此类推的情况。

当然了，当我们的主机1给主机2发送了数据之后，经过一端时间后主机1并没有收到主机2的应答的情况也是有的，所以这个时候为了确保数据的准确到达，TCP就有了超时重传机制。

超时重传机制

超时重传的超时是指在发送数据之后，重发数据之前，等待确认应答到来的那个特定的时间间隔。如果发送数据之后超过了这个时间仍未收到确认应答，发送端将进行数据重发。

主机A没有收到主机B的确认应答有以下两种情况：
(1)：发送的数据包丢失。客户端主机A发数据给主机B，但是数据包丢包了(可能因为网络拥堵等原因)，主机B根本没有收到数据包，那么自然不会发送ACK应答。
(2)：返回的ACK应答包丢失。客户端主机A发数据给主机B，主机B收到数据了并且回了ACK应答，但是ACK应答丢包了，主机A没有收到ACK应答。

情况(1)：发送的数据包丢失

由图分析：主机A给主机B发送了数据，可能因为其他的原因数据无法到达主机B.（比如网络拥堵）。这个时候主机A等待了一个特定的时间间隔之后发现主机B还没有确认应答，于是就再一次将上一次的数据重新发送过去。

情况(2)：返回的ACK应答包丢失。主机B收到了数据，也回传了确认应答报文，但是该报文丢失了。

主机B收到了主机A发来的数据，但是发给主机A的确认应答并没在特定的时间间隔内到达主机A，所以主机A也会因为没有收到确认应答而再次重新将数据发送过去。

这种情况下，主机B已经收到了主机A第一次发的数据包，因此主机B会收到很多重复的数据包，那么TCP协议需要能够识别出哪些数据包是重复的，并且把重复的数据包丢弃掉，这时候利用的就是序列号，可以很容易做到去重。

对于这两种情况，TCP有特定的时间间隔内的重传机制，如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会对数据进行重发，确保丢失的数据能发送到接收端。

tcpNoDelay参数
TCP发送数据包并不是需要挨个确认应答后再发送下一个数据的，可以通过设置这个tcpNoDelay参数来实现发送一个数据包后不需要等待确认应答后就立马发下一个数据包。可以在特定的时间间隔内收到确认应答即可，不需要立马收到ACK确认应答后才发送下一个数据包。

TCP只有收到ACK应答后才确认数据正确发送了。

TCP不确保应用层的传递的数据时完整的，TCP只确保每次发送出去的数据是完整的传递给接收方的应用层的。比如调用socket的Outputstream的write方法写出了一段数据后，这段数据即使被分割成多个TCP数据段，但是TCP也能够确保这分割成的多个TCP数据段最终是按照发送时的顺序拼接好并完整的传递给接收方的应用层的。

超时时间如何确定？

最理想的情况下，找到一个最小的时间，保证“确认应答一定在这个时间内返回”；
但是这个时间的长短，随着网络环境的不同，是有差异的；
如果时间设的太长，会影响整体的重传效率；
如果超时时间设的太短，有可能会频繁发送重复的数据包；

TCP为了保证无论在任何情况下都能进行比较高性能的通信，因此会动态计算这个最大超时时间。

• Linux中（BSD Unix和Windows也是如此），超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍；
• 如果重发一次之后，仍然得不到应答，等待2*500ms后再次进行重传；
• 如果仍得不到应答，等待4*500ms进行重传，依次类推，以指数形式递增；
• 累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接；

窗口机制

TCP协议中的窗口机制确保TCP的高效性。

滑动窗口

• 发送方和接收方都会维护一个数据帧的序列，这个序列被称作窗口。
• 发送方的窗口大小由接收方确认。

滑动窗口是动态计算的，比如客户端给服务端发了1000个字节的数据，但是服务端发现1000个数据好像自己处理不过来，那么在服务端给客户端的ACK应答中，滑动窗口的大小可能就调整为500，向客户端表示你下次不要发1000个字节的数据那么多了，你发500个数据吧。 当然也有可能服务端的处理能力比较大，滑动窗口的大小可能就调整为2000，那么下次客户端就每次发送2000个字节的数据。
滑动窗口的大小的确认是必须由接收方来确定的，不同的接收方的处理能力可能不一样，只有接收方自己才能确定滑动窗口的大小，发送方是不能确定的，接收方确定后在ACK应答数据包中将滑动窗口大小发送给发送方。
比如：你能吃多少碗饭别人是不知道的，别人可能先给你3碗，然后你吃了后发现没吃饱，自己可以吃5碗，于是你告诉别人你每顿可以吃5碗饭，于是以后别人每顿饭可能就给你5碗饭。

这部分了解即可，当然如果面试BAT高级开发岗位，岗位又恰好要求网络调优相关的，如果简历中也写了自己精通TCP协议…那么就可能问到这方面相关的更深的知识点了，比如滑动窗口的常见的四种滑动算法。

滑动窗口的目的

• 确保数据不丢失
  如果发送的数据丢失了可以重新发。

• 控制发送速度
  控制发送速度，以免接收方的缓存不够大导致溢出，同时控制流量也可以避免网络拥塞。

流量控制

拥塞控制

参考：
【网络】TCP的确认应答机制和超时重传机制
TCP协议可靠性保证（确认应答机制，超时重传机制，流量控制，拥塞窗口）
TCP协议滑动窗口机制-如何保证传输的高性能