TCP协议相关

Posted 2021-07-14 iOS小菜鸟

TCP 协议

可靠传输

TCP 协议是如何实现可靠传输的？

• ARQ 协议：ARQ 协议是自动重传请求（Automatic Repeat Request），通过接受端发送 ACK 确认包（确认）并且在规定的时间内（超时）来确认发送方发送的数据是否完全送达。实现在不可靠的网络上实现可靠的数据传输的错误控制协议。如果发送方在规定的时间内没有收到接收方的确认包，就会进行数据重传，在有效的重传次数内一直未收到确认包，将会放弃数据传输。

• 拥塞控制相关字段：
• MSS：最大报文长度(Maximum Segment Size)，每个段最大的数据部分大小，在 TCP 建立连接时确定。
• cwnd：拥塞窗口(Congestion Window)，控制每次能发送数据包的数量。
• rwnd：接收窗口(Receiver Window)，用于流量控制，控制发送方一次可发送的数据包。
• swnd：发送窗口(Send Window)，发送方可以发送的数据包数量。 其实发送方的发送窗口大小取决于拥塞窗口和接收窗口中的最小值，哪个小就使用哪个做传输数据的限制！
• 当发送方收到 0 窗口通知时，这时发送方停止发送数据报文；
• 并且同时开启一个定时器，隔一段时间就发个测试报文去询问接收方的窗口大小；
• 如果接收方的窗口还是 0，则发送方再次刷新启动定时器。如果接收窗口大于 0，则可以发送数据报文给服务器。
• 优缺点：
• 优点是可以连续发送多个数据包，提高信道的利用率。
• 缺点是只要其中一个包出错，后面所有包都要重发，降低了传输速率，这种协议不一定就比停止等待 ARQ 协议好。
• 优点是通过一来一回的传输方式来保证数据安全可靠和有序地送达。
• 缺点是每次发送数据包后都会停止等待接收方的确认，导致信道利用率太低，大部分时间都是空闲的。
• 无差错情况：若发送方发送数据后在规定的时间内接收到确认包，没有出现数据包丢失，则会继续发送下一个数据包。
• 有差错情况：若发送方在发送数据过程中丢包或接收方在发送确认包的过程丢包这 2 种情况下，发送方都会进行数据包自动重传，然后继续等待接受方的确认！但是如果是接收方发送的确认包延时送达或者发送方发送的数据包延时送达，接收的一方则会将重复的数据包进行接收，但不做任何的处理。

• 停止等待 ARQ 协议：停止等待协议是发送方发送一个数据包后，会在设置的有效时间内等待接受方发送回来的确认包，当收到确认包后，再进行下一个数据包的发送。

• 优缺点：

• 后退 N 帧 ARQ 协议：发送方不用等待收到确认包才继续发送下个数据包，而是可以连续发送多个数据包，等到检测出失序的数据包后，会要求发送方正确收到的数据包后面的所有数据包都要重发，简单来说就是接收方只允许接收有序的数据包，一旦有一个数据包超时未能正确地送达，则该数据包和它后面的所有数据包都要重发

• 连续 ARQ 协议：由于停止等待协议的信道利用率太低，所以使用连续 ARQ 协议来进行改善。通过发送一组数据包，再等待接收方的 ACK 确认。连续 ARQ 协议都是配合滑动窗口协议来进行数据传输的，滑动窗口协议是双方规定每次可以发送数据的字节数，通过接收方的确认号来往后滑动窗口位置。

• 假设客户端第一次发送编号 1-5 总共 5 个数据包，服务器收到后，发送确认包通知客户端已经接收到的数据包编号，然后让客户端继续发送下一组数据。连续 ARQ 协议使得服务器通过累积的方式通知客户端这一组编号为 1-5 的数据都被我接收了，期望客户端继续发送下一组数据！

• 假设客户端在发送一组数据包的过程中出现了丢包，如第二组编号 6-10 的数据包，编号 7 丢了，之前第一种做法是通过回退 N 帧协议，也就是从丢失编号的数据包开始继续往后分组发送！由于这种传输方式会导致传输效率太低，所以后面发展了选择性确认(SACK)，服务器可以通过发送确认包，并通过在 TCP 确认包中告知客户端丢失数据包，可以通过 TCP 首部的选项字段来告知丢失的数据包编号，最多通知丢包个数是 4 个！这样客户端就可以对丢失的数据包进行再次重传。真正做到了保证数据传输的可靠性！

  TCP 协议是如何进行流量控制的？

• 如果接收方的缓冲区数据已经满了，发送方还是不断地进行数据发送，那接收方只能将数据包全部丢掉，这种情况会极大的浪费网络资源！所以我们就要进行流量控制，让发送方发送数据包的速度不要太快，让接收方有时间对数据包进行处理！TCP 流量控制其实是通过接收方发送数据包里面的 TCP 首部包含有窗口大小的字段，来告知发送方当前可以发送的数据包个数，来达到控制传输数据的流量控制！

• 流量控制原理：

• 存在一种特殊的情况，假设一开始接收方发送给发送方 0 窗口的报文段，过了一段时间，接收方有了一些存储空间，给发送方发送了一个非 0 窗口的报文，但是此报文在发送过程中丢失了，这样会导致发送方一直处于等待状态，双方陷入僵局！这种情况死锁的情况，发送方接收到接收方 0 窗口的报文后，开启一个定时器，每隔一段时间去询问接收方的窗口大小，这样就不会导致双方死锁！

  TCP 协议是如何进行拥塞控制的？

• 拥塞控制是为了防止过多的数据注入到网络中，避免网络中的路由器或链路过载，出现网络堵塞！拥塞控制是一个全局性的过程，涉及链路中的所有主机和路由器，是需要大家共同努力来进行维护的！

• 拥塞控制的方法：
  

• 慢开始：不会一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小，cwnd 指数级增长。

• 拥塞避免：当慢开始 cwnd 到达阀值 ssthresh 后，让拥塞窗口缓慢增长，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍。这样拥塞窗口按线性规律缓慢增长。

• 快重传：快重传要求接收方在收到一个失序的报文段后就立即发出重复确认而不要等到自己发送数据时再进行确认。快重传规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期才进行发送。

• 快恢复：当发送方连续收到三个重复确认，说明网络出现了拥塞情况了，这时就执行 “乘法减小” 算法，把 ssthresh 值减为拥塞峰值的一半。与慢开始不同是现在不执行慢开始算法又重新从 0(cwnd 初始值)开始传，而是把 cwnd 值设置为新的 ssthresh 值减半后继续通过拥塞避免进行窗口线性增大。