网络面试题

1.TCP头部和IP头部信息

2.TCP和UDP的区别

• 知识点1：是否连接
• 知识点2：可靠性
• 知识点3：数据传输形式
• 知识点4：传输速度
• 知识点5：应用场景

3.TCP如何保证可靠性

• 相关机制：TCP分段/超时重传/流量控制/数据包校验/处理IP数据包等等

  1. TCP分段：应用数据被分割成合适的TCP段发送（对UDP来说，应用程序产生的数据段长度将保持不变）
  2. 超时重传：每发出一个TCP段都会启动一个"重传定时器"；如果不能及时收到一个确认，将重传这个报文段
  3. 流量控制：缓冲区固定大小，TCP接收端只允许另一端发送接收缓冲区所能接纳的数据（滑动窗口）
  4. 数据校验：TCP首部(校验和)；如果收到段的校验和有差错，会选择丢弃和不确认
  5. 处理IP数据包：a) 丢弃重复的IP数据包；b) 将失序的IP数据包重新排序后交

4.TCP三次握手和四次挥手

• 知识点1：握手挥手过程
• 知识点2：TCP包类型
• 知识点3：数据包携带信息
• 知识点4：有限状态机变化

5.TCP为什么采用三次握手

• 如果采用2次握手：S端如果收到已经失效的SYN连接请求后，就同意建立连接，然后开始等待C端发送数据，会导致资源极大浪费
• 如果采用4次握手：减少建立连接时间过长，影响工作效率（S端的ACK和SYN包就是一起发送的）

6.如果发送的SYN丢失会怎么办

• 相关机制：重传计时器/快速重传/SACK/D-SACK

1. 重传计时器：每次发送SYN包都会启用一个重传定时器，当超时时间到来，会进行重传

   • 解决：包丢失的重传问题
   • 问题：timeout会导致网络利用率降低

   • 计算公式1：RTO是根据RTT值而确定的

     # RTTm为RTT测量值；RTTs平滑值；RTTd偏差值
     RTTs=(1-a)*RTTs+a*RTTm   a通常为1/8
     RTTD= (1-b)*RTTD+b*|RTTm-RTTs|   b通常为1/4
     RTO=RTTs+4RTTD

   • 计算公式2：当无法获取RTT值时

     RTO=2*RTO

2. 快速重传：发送端接收三个相同序号的ACK包，即立刻进行重传，并不需要重传计时器的timeout时间

   • 解决：timeout问题，提高网络利用率
   • 问题：收到的ACK序号及已经发送的数据包需要重新发送

3. SACK：在TCP头加上SACK用来汇报收到的数据碎片

   • 解决：发送端可以根据回传回来的SACK判断需要重传数据包（Linux内核参数：tcp_sack）
   • 问题：当有恶意攻击者，SACK会消耗发送端的资源

4. D-SACK: 在TCP头加上SACK，通过ACK和SACK值判断丢失的数据包

   • 解决：重复收到数据问题（Linux内核参数：tcp_dsack）
   • 优点：可以让发送方知道，是发出去的包丢了，还是回来的ACK包丢了

   • 场景示例1： ACK包丢失问题

     Transmitted  Received    ACK Sent
     Segment      Segment     (Including SACK Blocks)
     # 3500-3999包丢失
     3000-3499    3000-3499   3500 (ACK dropped)
     3500-3999    3500-3999   4000 (ACK dropped)
     # ACK > SACK -> D-SACK：只需要发送4000+的数据包 
     3000-3499    3000-3499   4000, SACK=3000-3500

   • 场景示例2：网络延迟

     Transmitted    Received    ACK Sent
     Segment        Segment     (Including SACK Blocks)
     500-999        500-999     1000
     # 1000-1499延迟
     1000-1499      (delayed)
     # 快速重传 
     1500-1999      1500-1999   1000, SACK=1500-2000
     2000-2499      2000-2499   1000, SACK=1500-2500
     2500-2999      2500-2999   1000, SACK=1500-3000
     1000-1499      1000-1499   3000
     # ACK > SACK -> D-SACK: 只需发送3000+的数据包
                 1000-1499   3000, SACK=1000-1500

7.如果已经建立了连接，但是客户端突然出现故障了怎么办？

1. TCP连接设有一个保活计时器，如果客户端出现故障，服务器不能一直等下去，白白浪费资源

2. 服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2h

   • 若2h还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75s发送一次
   • 若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接

8.延迟确认机制

• 定义：ACK在收到数据后并不马上回复，而是等待一端时间(初始化值为40s)后，和要返回的数据一起传输，这样可以提高网络利用率和减少带宽消耗

• 分类：Linux中存在延迟ACK和快速ACK

  • 延迟ACK能够减少发送的分段从而节省带宽
  • 快速ACK能够及时通知发送方丢包，提升吞吐率，避免滑动窗口停等

9.TIME_WAIT相关问题

9-1.TIME_WAIT状态用来解决和避免的问题

• 防止主动关闭方的ACK包丢失问题
• 防止重复(旧)的数据包出现在本次连接问题

9-2.集群中处于TIME-WAIT状态的服务器过多的原因?

• 原因1：高并发短链接的TCP服务器上，当服务器处理完请求后正常主动关闭连接
• 短链接：“业务处理+传输数据时间”远远小于TIME-WAIT时间
• 场景1：1s的http短链接处理完业务，主动方关闭连接之后，会在T-W状态等待2MLS时间从而导致端口被占用

9-3.如何处理TIME-WAIT过多的问题

• Linux系统调优

  # /etc/sysctl.conf文件中：
  net.ipv4.tcp_tw_reuse=1        # 重用
  net.ipv4.tcp_tw_recycle=1    # 快速回收
  net.ipv4.tcp_tw_timestamps=1    # 时间戳一致
  net.ipv4.tcp_syncookies = 1        # SYN请求缓存（有一点点用处）

9-4.清理TIME-WAIT技巧

• 调整 net.ipv4.tcp_max_tw_buckets 参数；当超过默认值时内核会把过多的T-W连接清理掉
• 利用RTS包从外部清理，当内核收到RTS包后会产生错误从而终止连接

10.滑动窗口

10-1.相关问题

• 发送方根据接收端的窗口大小(WIN=xxx)来调整发送速率，实现端到端的流量控制
• 窗口： |已发送并确认|发送窗口|不允许发送|
• 发送窗口： |通知窗口：已发送并未收到确认|可用窗口：允许发送但未发送|
• 发送缓存：ad) TCP已发送但是没有收到确认的数据；b) 应用程序：TCP准备发送的数据
• 接收缓存：a) 未按序到达的数据；b) 应用程序：按序到达并未读取的数据

• 发送缓存和接收缓存都有大小限制，并可以重复使用

  • Linux系统相关内核参数：

    # 自动调节：
    net.ipv4.tcp_moderate_rcvbuf=1    # 默认为1:代表开启自动调节
    net.ipv4.tcp_adv_win_scale=1    # 默认为1:计算接收缓存和接收窗口的微调
    net.ipv4.tcp_wmem=4096    16384    4194304        # min值 defaults值 max值
    net.ipv4.tcp_rmem=4096    87380    6291456
    
    # 发送和接收缓存的默认值和最大值：
    net.core.rmem_default=212992
    net.core.rmem_max=212992
    net.core.wmem_default=212992
    net.core.wmem_max=212992

10-2.如果发送端接收到一个零窗口该怎么处理？

• 场景：当服务端处理能力不够的时候，可能会导致数据丢失，从而向发送端发送零窗口

• 发送端处理方式：

  1. 会暂时停止发送数据流
  2. 启用窗口定时器：当网络中没有发送且未确认的数据包且本端有待发送的数据包时

  3. 保持连接并传输探测(keep-alive报文)

     • 接收窗口不为0：继续发送数据包（清除超时时间的退避指数，删除零窗口探测定时器）
     • 接收窗口仍为0：重新设置零窗口探测定时器的下次超时时间，超时时间的设置和超时重传定时器的一样

11.拥塞控制

• 网络拥塞的原因：

• 1. 独享整个网络资源，TCP的流量控制必然会导致网络拥塞，只关注了对端接收空间，无法知道链路上的容量
  2. 路由器接入网络会拉低网络的总带宽，路由器如果出现瓶颈，很容易出现堵塞
• 拥塞控制主要依赖于拥塞窗口(cwnd)；所以发送端发送的真正窗口是：min(rwnd,cwnd)
• 拥塞控制的4种机制：慢开始/拥塞避免/快速重传/快速恢复

• 拥塞控制过程:

  1. 慢启动: 进行试探的过程 -> 一般从cwnd=1开始加倍增长
  2. 当cwnd > ssthresh初始值后开始拥塞避免-> 每次cwnd+1
  3. 判断网络拥塞
     a) 没收到ACK时，重新执行慢开始，并且将sshresh初始值重置为： 发生拥塞时的cwnd/2
     b) 收到3个重复ACK时，进行快速重传，
  4. 快速恢复： 从新ssthresh=[ 发生拥塞时的cwnd/2 ]开始执行拥塞避免

12.其他相关问题

• 子网掩码的作用

  • 确定网络地址和主机地址

• 北京一个站点ping广东的RTT在什么量级？描述什么样的时延？

  • 传输延迟
  • RTT = (2200km)/(2*10^5 km/s)*2

• ping和traceroute的工作原理

  • ping原理: 发送ICMP回显请求报文，等待ICMP响应报文
  • traceroute原理：通过封装一份UDP依次将TTL值置为1/2/3...;并发送给目的主机；当收到的响应报文目标地址是自己是就说明找到目标主机

• 如何防御SYN DDOS攻击

  • Linux内核参数调优
  • IPtables限制TCP连接频率
  • 智能DNS分流

• STP生成树协议

  • 作用：保证链路冗余的同时避免环路带来的广播风暴问题