TCP协议如何保证可靠传输

本片主要谈论如何保证TCP可靠传输;

可靠性

1. 校验和
2. 序列号
3. 确认应答
4. 超时重传
5. 连接管理
6. 流量控制
7. 拥塞控制

确认应答(ACK)机制

TCP将每个字节的数据进行了编号,即为序列号;

1-1000是数据序号,确认序号是收到的数据序号+1;

超时重传机制

情况1: 数据丢包

• 主机A发送数据给主机B后,可能会因为网络拥堵等原因,数据无法到达主机B;
• 如果主机A在一定时间间隔内没有收到B的应答,A就会重新发送没有被应答的数据;

情况2: 确认应答(ACK)丢失

• 主机A将数据发送给主机B,主机B接收到了并对数据进行确认应答;
• 确认应答(ACK)可能因为网络阻塞或者丢包,无法到达主机A;
• 主机A在一定时间里没有收到主机B的确认,会重新发送没有被确认的数据;
• 但是,主机B其实已经收到了1-1000的数据,所以当第二次收到1-1000的数据时,会识别数据的序号,再根据序号,将重复的数据丢弃掉(去重)

特定的时间间隔是如何确定的?

• 理想情况下是找一个最小的时间,保证"确认应答一定能在这个时间内返回";
• 但是这个时间的长短,随着网咯环境的不同是由差异的;
• 如果超时时间设的太长会影响整体效率;
• 如果超时时间设的太短,可能会频繁的发送重读的包;

TCP为了保证在任何环境下都能比较高性能的通信,所以会动态计算这个时间

• Linux/Windows,超时以500ms为一个单位进行控制,每次判定超时重发的时间都是500ms的整倍数;
• 如果重发一次仍然得不到应答,那么会在等待2*500ms进行重传;
• 如果依旧等不到回应,会等待4*500ms以后在进行重传,以指数形式递增;
• 累计到一定的次数,TCP会认为网络或者对端主机异常,强制关闭连接;

流量控制

接收端的处理数据的速度有限,如果发送端发的太快,导致接受缓冲区很快满了,这个时候如果发送端继续发送数据,就会造成丢包,继而引起丢包等一系列的连锁反应.

因此TCP支持根据接收端的处理能力,来决定发送端的发送速度,这个机制就叫做流量控制;

• 接收端将自己可以接受的缓冲区大小放入TCP首部中的"窗口大小"字段,通过ACK端通知发送端;
• 窗口大小字段越大,说明网络吞吐量越高;
• 接收端一旦发现自己的缓冲区快要满了,就会将窗口大小设置成一个更小的值通知给发送端;
• 发送端接收到这个窗口以后,就会减慢自己的发送速度;
• 如果接收端缓冲区满了,就会将窗口置为0,这时发送方不再发数据,但是需要定期发送一个窗口探测数据段,使接收端把窗口大小告诉发送端;

TCP首部中,有一个16位的首部字段,就是存放窗口大小信息,但是16位数字表示的最大值为65535,其实TCP首部40个字节的中有一个窗口扩大因子M,实际窗口大小使  窗口字段的值左移M位;

拥塞控制

虽然TCP中已经有了滑动窗口这个绝招,可以高效可靠的发送大量的数据,但是如果在刚开始阶段就发送大量的数据,仍然可能因为问题!

在网络比较拥堵的情况下,贸然发送大量的数据,就很可能雪上加霜,使得网络更加拥堵,数据也无法送达;

TCP引入  慢启动 机制,先发送少量的数据,探探路,摸清当前的网络拥堵状态,再决定按照多大的速度进行传输数据;

• 此处的引入一个概念为拥塞窗口;
• 开始的时候,定义拥塞窗口的大小为1;
• 每收到一个ACK应答,拥塞窗口加1;
• 每次发送数据包的时候,将拥塞窗口和接收端主机反馈的窗口大小做比较,取较小的值为实际发送的窗口大小;

慢启动只是指刚开始启动的时候比较慢,但是增长的速度是非常快的

• 为了不增长的那么快,因此不能一直让拥塞窗口单纯的加倍;
• 此处引入一个慢启动的阈值;
• 当拥塞窗口超过这个阈值的时候,不再按照指数的方式增长,而是按照线性的方式增长;

• 当TCP开始启动的时候,慢启动阈值等于窗口最大值;
• 在每次超过重发的时候,慢启动阈值就会减少到原来的一半,同时拥塞窗口置为1;

少量的丢包,我们仅仅的触发超时重传;大量的丢包,我们就认为是网络拥塞;

当TCP通信开始后,网络吞吐量会逐渐上升;随着网络发生拥堵,吞吐量会理解下降;

拥塞控制,归根结底就是TCP协议想尽可能把数据传输给对方,但是又要避免给网络造成大大压力的折中方案;