TCP

这是一个TCP/IP的思维导图，介绍了网路层、数据链路层、面试常考题、拥塞控制机制、TCP重传、如何解决2MSL产生的问题、等待2MSL会产生的问题、为什么要等待2MSL、TCP挥手为什么要4次、初始序列号ISN的取值等一系列的问题，非常的全面哦！

TCP/IP

• 网络层
  • ICMP（Internet Control Message Protocol）- 互联网控制报文协议
    • 主要功能
      • 确认 IP 包是否成功送达目标地址
      • 报告发送过程中 IP 包被废弃的原因和改善网络设置等
• 数据链路层
  • VRRP
• 面试常考题
  • PING命令的原理
    • 底层使用ICMP实现
    • 发送ICMP回显请求消息给目的主机。ICMP协议规定：目的主机必须返回ICMP回送应答消息给源主机。如果源主机在一定时间内收到应答，则认为主机可达
    • 网络上的机器都有唯一确定的IP地址，我们给目标IP地址发送一个数据包，对方就要返回一个同样大小的数据包，根据返回的数据包我们可以确定目标主机的存在，可以初步判断目标主机的操作系统等
  • Traceroute（Linux）/Tracert（Windows）的原理
• 初始序列号 ISN 的取值
  • RFC793 中认为 ISN 要和一个假的时钟绑定在一起ISN 每四微秒加一，当超过 2 的 32 次方之后又从 0 开始，要四个半小时左右发生 ISN 回绕
• SYNC超时了怎么处理
  • client 发送 SYN 至 server 然后就挂了，此时 server 发送 SYN+ACK 就一直得不到回复，怎么办
    • 阶梯性重试：在 Linux 中就是默认重试 5 次，并且就是阶梯性的重试，间隔就是1s、2s、4s、8s、16s，再第五次发出之后还得等 32s 才能知道这次重试的结果，所以说总共等63s 才能断开连接
• SYN Flood 攻击怎么办
  • 可以开启 tcp_syncookies，那就用不到 SYN 队列了
    • SYN 队列满了之后 TCP 根据自己的 ip、端口、然后对方的 ip、端口，对方 SYN 的序号，时间戳等一波操作生成一个特殊的序号（即 cookie）发回去，如果对方是正常的 client 会把这个序号发回来，然后 server 根据这个序号建连
  • 调整 tcp_synack_retries
    • 减少重试的次数
  • 设置 tcp_max_syn_backlog 增加 SYN 队列数
  • 设置 tcp_abort_on_overflow SYN 队列满了直接拒绝连接
• TCP挥手为什么要4次
  • TCP 是全双工协议，也就是说双方都要关闭，每一方都向对方发送 FIN 和回应 ACK
  • 另外被动方一端在响应ACK时，可能数据还未传输完毕，所以ACK跟FIN分开发
• TCP双端同时挥手时的状态转换
  • 双方都主动发起断开请求所以各自都是主动发起方，状态会从 FIN_WAIT_1 都进入到 CLOSING 这个过度状态然后再到 TIME_WAIT
• 为什么要等待2MSL
  • MSL 是 Maximum Segment Lifetime，即报文最长生存时间，RFC 793 定义的 MSL 时间是 2 分钟，Linux 实际实现是 30s，那么 2MSL 是一分钟
  • 就是怕被动关闭方没有收到最后的 ACK，如果被动方由于网络原因没有到，那么它会再次发送 FIN， 此时如果主动关闭方已经 CLOSED 那就傻了，因此等一会儿
  • 假设立马断开连接，但是又重用了这个连接，就是五元组完全一致，并且序号还在合适的范围内，虽然概率很低但理论上也有可能，那么新的连接会被已关闭连接链路上的一些残留数据干扰，因此给予一定的时间来处理一些残留数据
• 等待 2MSL 会产生什么问题
  • 如果服务器主动关闭大量的连接，那么会出现大量的资源占用，需要等到 2MSL 才会释放资源
  • 如果是客户端主动关闭大量的连接，那么在 2MSL 里面那些端口都是被占用的，本地随机端口只有 65535 个，如果端口耗尽了就无法发起主动的新连接
• 如何解决 2MSL 产生的问题
  • 快速回收（不建议），即不等 2MSL 就回收
    • 在NAT环境，有概率会出现握手RESET。原因是开启了 tcp_tw_recycle（tcp_timestamps 也是打开的情况下），在 60 秒内对于同源 IP 的连接请求中 timestamp 必须是递增的，不然认为其是过期的数据包就会丢弃；而在NAT环境只会修改源目ip端口，不会修改包的时间戳，经过NAT传输的有概率时间戳较晚被RESET
  • 重用
    • 开启 tcp_tw_reuse（依赖开启tcp_timestamps ）
      • tcp_tw_reuse 是发起新连接的时候，可以复用超过 1s 的处于 TIME_WAIT 状态的连接
• TCP重传
  • 超时重传
    • 超时重传机制是为了解决什么问题
      • TCP 要提供可靠的传输，那么网络又是不稳定的如果传输的包对方没收到却又得保证可靠那么就必须重传
        • 超时重传的时间 RTO，即 Retransmission Timeout
          • 1.先采样 RTT
            • Karn / Partridge 算法
              • 不采样重传的RTT
            • Jacobson / Karels 算法
          • 2.SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT)
            • ALPHA 是一个平滑因子取值在 0.8~0.9之间
          • 3.RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]]
            • UBOUND 就是超时时间上界-1分钟
            • LBOUND 是下界-1秒钟
            • BETA 是一个延迟方差因子，取值在 1.3~2.0
  • 快速重传
    • 为什么还需要快速重传机制
      • 超时重传是按时间来驱动的，如果是网络状况真的不好的情况，超时重传没问题，但是如果网络状况好的时候，只是恰巧丢包了，那等这么长时间就没必要。 于是又引入了数据驱动的重传叫快速重传，什么意思呢？就是发送方如果连续三次收到对方相同的确认号，那么马上重传数据。 因为连续收到三次相同 ACK 证明当前网络状况是 ok 的，那么确认是丢包了，于是立马重发，没必要等这么久
  • SACK（Selective Acknowledgment）的引入是为了解决什么问题
    • 它的引入就是为了解决发送方不知道该重传哪些数据的问题
    • SACK 就是接收方会回传它已经接受到的数据，这样发送方就知道哪一些数据对方已经收到了，所以就可以选择性的发送丢失的数据
    • 如果数据是多段不连续的， SACK 也可以发送，比如 SACK 0-500,1000-1500，2000-2500。就表明这几段已经收到了
  • D-SACK 又是什么东西
    • D-SACK 其实是 SACK 的扩展，它利用 SACK 的第一段来描述重复接受的不连续的数据序号，如果第一段描述的范围被 ACK 覆盖，说明重复了
• 拥塞控制机制
  • 具体实现
    • 1.慢启动
      • 慢启动，就是新司机上路慢慢来，初始化 cwnd（Congestion Window）为 1，然后每收到一个 ACK 就 cwnd++ 并且每过一个 RTT ，cwnd = 2*cwnd，线性中带着指数，指数中又夹杂着线性增长
    • 2.拥塞避免
      • 然后到了一个阈值，也就是 ssthresh（slow start threshold）的时候就进入了拥塞避免阶段。 这个阶段是每收到一个 ACK 就 cwnd = cwnd + 1/cwnd并且每一个 RTT 就 cwnd++。可以看到都是线性增
    • 快速重传/恢复（拥塞发生）
      • 然后就是一直增，直到开始丢包的情况发生，前面已经分析到重传有两种，一种是超时重传，一种是快速重传。 如果发生超时重传的时候，那说明情况有点糟糕，于是直接把 ssthresh 置为当前 cwnd 的一半，然后 cwnd 直接变为 1，进入慢启动阶段
      • 如果是快速重传，那么这里有两种实现
        • TCP Tahoe
          • 和超时重传一样的处理
        • TCP Reno
          • 这个实现是把 cwnd = cwnd/2 ，然后把 ssthresh 设置为当前的 cwnd
      • 然后进入快速恢复阶段，将 cwnd = cwnd + 3（因为快速重传有三次），重传 DACK 指定的包，如果再收到一个DACK则 cwnd++，如果收到是正常的 ACK 那么就将 cwnd 设为 ssthresh 大小，进入拥塞避免阶段
        • 可以看到快速恢复就重传了指定的一个包，那有可能是很多包都丢了，然后其他的包只能等待超时重传，超时重传就会导致 cwnd 减半，多次触发就指数级下降
          • 所以又搞了个 New Reno，多加了个 New，它是在没有SACK 的情况下改进快速恢复，它会观察重传 DACK 指定的包的响应 ACK 是否是已经发送的最大 ACK，比如你发了1、2、3、4，对方没收到 2，但是 3、4都收到了，于是你重传 2 之后 ACK 肯定是 5，说明就丢了这一个包。 不然就是还有其他包丢了，如果就丢了一个包就是之前的过程一样，如果还有其他包丢了就继续重传，直到 ACK 是全部的之后再退出快速恢复阶段。 简单的说就是一直探测到全部包都收到了再结束这个环节
          • 还有个 FACK，它是基于 SACK 用来作为重传过程中的拥塞控制，相对于上面的 New Reno 我们就知道它有 SACK 所以不需要一个一个试过去
  • TCP拥塞控制算法
    • TCP Tahoe and Reno
    • TCP Vegas
    • TCP New Reno
    • TCP Hybla
    • TCP BIC
    • TCP CUBIC
    • Agile-SD TCP
    • TCP Westwood+
    • Compound TCP
    • TCP proportional Rate Reduction
    • TCP BBR
    • C2TCP
    • Elastic-TCP
    • NATCP/NACubic
    • 其他