深度思考计算机网络面经之三

计算机网络

.1 说说你对tcp滑动窗口的理解

TCP 滑动窗口是 TCP 协议流量控制的一个重要机制。它的主要目的是确保发送方不会因为发送太多数据而使接收方不堪重负。下面我会详细地描述滑动窗口的概念：

1. 窗口的大小：

   • 滑动窗口的大小（以字节为单位）表示发送方在等待确认之前可以发送的最大数据量。
   • 该大小可以是固定的，但在现代的 TCP 实现中，它是动态变化的，这种机制称为拥塞控制。

2. 发送窗口与接收窗口：

   • 发送方维持一个发送窗口，而接收方维持一个接收窗口。
   • 发送窗口大小决定了发送方可以发送多少数据，在接收到确认之前不需要等待。
   • 接收窗口大小告诉发送方接收方还能接受多少数据。

3. 滑动的概念：

   • 当发送方发送了一些数据并收到其确认后，窗口“滑动”前进，使得更多的数据可以被发送。
   • 这个“滑动”的概念意味着，与其说窗口的大小是变化的，不如说窗口的起始和结束点是变化的。

4. 数据流与确认：

   • 当发送方发送了数据包，它会等待接收方的确认。如果在一个特定的超时时间内未收到确认，发送方会重新发送该数据包。
   • 当接收方确认数据包，它实际上是确认了到目前为止已收到的所有连续数据包。

5. 拥塞控制：

   • TCP 使用滑动窗口的概念来处理网络拥塞。
   • 如果网络出现拥塞（例如，由于数据包丢失），发送方将减小其窗口大小，从而减少发送的数据量。当网络条件改善时，窗口大小将逐渐增大。

6. 窗口大小的通告：

   • 在 TCP 头部有一个字段叫做窗口大小（Window Size），接收方用这个字段通告其当前的接收窗口大小。

总的来说，TCP 的滑动窗口协议是一种允许发送方和接收方之间有动态的、自适应的数据流量控制的机制。这种机制确保了高效的数据传输，同时防止了网络的过度拥塞。

.1.1 GBN和SR的区别

对，你指出的确实是对的。我之前的描述更偏向了 Go-Back-N (GBN) 滑动窗口协议的特点。

确实，除了 GBN，还有一个叫做选择重传 (Selective Repeat, SR) 的滑动窗口策略。

1. Go-Back-N (GBN):

   • 当发送方在等待确认时，它可以连续发送多个数据包，但有一个限制，即这些数据包的数量不超过窗口的大小。
   • 如果发送方没有在超时时间内收到某个数据包的确认，它会重新发送该数据包及其后面的所有数据包，即使它们可能已经被接收方正确接收。
   • 接收方只发送下一个期望的数据包序号作为确认，它不会缓存或确认后面的任何乱序的数据包。

2. 选择重传 (Selective Repeat, SR):

   • 与 GBN 不同，SR 允许接收方接收乱序的数据包，并缓存它们。
   • 如果接收方没有收到预期的数据包，它会等待，因为它预期可能会迟些时候收到。
   • 发送方为每个发送的数据包设置单独的计时器。如果某个数据包的计时器到期但该数据包还没有被确认，只有该数据包会被重新发送，而不是像 GBN 那样重新发送一系列数据包。
   • 接收方对每个独立接收的数据包都发送确认。

感谢你指出这一点，这两种策略确实在处理数据流与确认方面有所不同。

.1.2 滑动窗口，滑动的是发送方和接收方两方吧？在GBN协议下，发送方的窗口怎么滑，接收方呢？在SR协议下，发送方的窗口怎么滑，接收方呢？

确实，滑动窗口协议在发送方和接收方都有窗口，这两个窗口都会进行“滑动”。以下是详细解释：

1. Go-Back-N (GBN):

   • 发送方:
     • 当发送方收到数据包的 ACK（确认）时，它知道该数据包及之前的所有数据包都已经被接收方正确接收了。
     • 窗口会根据收到的确认滑动。例如，如果窗口大小是 4，发送方发送了数据包 1、2、3、4，然后收到了数据包 2 的确认，那么窗口会滑动，使得发送方可以发送数据包 5（假设窗口始终为连续的四个数据包，滑动后的窗口现在覆盖数据包 3、4、5、6）。
   • 接收方:
     • 在 GBN 中，接收方的窗口大小通常为 1，这意味着接收方一次只期望接收一个数据包，即当前期望的数据包序号。
     • 如果接收方收到了期望的数据包，它会发送一个确认，并期望下一个数据包。如果收到了乱序的数据包，它通常会丢弃并重新发送上次的确认。

2. 选择重传 (Selective Repeat, SR):

   • 发送方:
     • 发送方有一个更复杂的滑动窗口。当发送方收到一个特定数据包的确认时，它知道该数据包已被正确接收。
     • 这允许发送方只对尚未被确认的数据包进行超时重传，而不是像 GBN 那样重新发送所有的数据包。
     • 当发送方接收到一个数据包的 ACK 时，它会更新其窗口，但这不像 GBN 中那样总是线性滑动。窗口会根据已确认的数据包进行“滑动”。
   • 接收方:
     • 接收方的窗口与 GBN 不同，因为它可以缓存乱序接收的数据包。
     • 接收方会对每个正确接收的数据包发送确认。
     • 如果接收方的窗口内所有数据包都已接收并确认，那么窗口会滑动到下一个尚未接收的数据包。

总结：在滑动窗口协议中，确实有两个窗口：一个在发送方，一个在接收方。这两个窗口都会“滑动”，但它们的滑动方式和逻辑取决于正在使用的协议版本（GBN 还是 SR）。

.1.3 详细描述一下SR的滑动方式

在 SR 协议中，当发送方收到某个数据包的 ACK 时，窗口的滑动仍然是线性的，但其复杂性来自于如何处理窗口内的数据包。

让我更详细地解释 SR 协议下发送方窗口的滑动方式：

在 SR 协议中，发送方的窗口确实是线性滑动的，但与 GBN 不同的是，SR 的发送方会维护一个缓冲区，记录窗口内每个数据包的状态（是否已确认）。

例如，如果滑动窗口大小为 4，且初始包含数据包序号 1、2、3、4。发送方发送了这四个数据包，但只收到了数据包 2 和 4 的 ACK。

在此情况下，数据包 1 和 3 仍未被确认，但数据包 2 和 4 已被确认。

窗口的滑动将基于最早的、尚未确认的数据包。因此，虽然数据包 2 和 4 已经被确认，但窗口不会滑动，因为数据包 1 尚未得到确认。

只有当数据包 1 和 3 都收到 ACK 时，窗口才会滑动，使下一个未确认的数据包（在此例中为数据包 5）进入窗口。

所以，虽然 SR 的发送方窗口的滑动是线性的，但滑动的时机取决于窗口内最早的、尚未确认的数据包是否已得到确认。

2.1.4 发送方发送数据的时候，会综合考量发送窗口、接收窗口以及拥塞窗口的大小对吧，取其中的最小值

对，你说得对。

在实际的 TCP 流量控制中，发送方会考虑以下三个窗口的大小来决定实际可以发送的数据量：

1. 发送窗口（Send Window）: 这是发送方根据自身的缓冲区和处理能力设定的最大发送数据量。

2. 接收窗口（Receive Window）: 这是接收方告诉发送方的值，表示接收方还能接受多少数据。这个值经常在 TCP 头部的窗口大小字段（Window Size field）中发送给发送方，反映了接收方当前的接收能力和其缓冲区的可用空间。

3. 拥塞窗口（Congestion Window）: 这是发送方根据网络状况（主要是网络拥塞）动态调整的一个值。它表示在当前网络状况下发送方认为可以发送的数据量。

当发送方准备发送数据时，实际可以发送的数据量是上述三个窗口大小中的最小值。

这种机制确保了：

1. 发送方不会因为发送太多数据而超出自己的处理能力。
2. 接收方不会因为接收到太多数据而超出其处理能力或缓冲区大小。
3. 由于网络拥塞，数据不会在网络中积累，导致数据包丢失率增加。

因此，确实是取这三个窗口大小的最小值作为实际可以发送的数据量。

.2 如果没有使用滑动窗口退化成什么了

如果没有使用滑动窗口协议，那么数据通信可能会退化成一个简单的停-等 (Stop-and-Wait) 协议。在这种协议中，以下是典型的数据通信特点：

1. 单一数据包传输：发送方一次只发送一个数据包，然后停止发送并等待接收方的确认。

2. 高延迟：因为发送方在发送一个数据包后必须等待确认，所以如果网络的往返时间 (Round-Trip Time, RTT) 很长，那么这种协议的效率会很低。

3. 低吞吐量：由于同时只有一个数据包在传输，所以网络的带宽利用率通常会很低，尤其是在高带宽或高延迟的网络中。

4. 简单性：虽然停-等协议效率低，但它相对简单。不需要维护复杂的缓冲区或窗口状态，只需要跟踪最后一个已发送或已确认的数据包。

在实际应用中，尽管停-等协议简单，但其效率问题使得它在许多情境中不适用。滑动窗口协议，如 TCP 中的实现，更能有效地利用网络带宽，提供更好的吞吐量和响应时间。

防爆破

.1 防爆破有了解吗

答：

当然了解。爆破攻击，通常称为暴力破解攻击（Brute Force Attack），是一种试图猜测用户名、密码或其他认证凭据的攻击方法，通常通过尝试所有可能的组合来实现。以下是一些常见的防爆破策略和建议：

1. 账户锁定：在短时间内连续多次登录失败后，暂时锁定账户。这可以阻止攻击者连续尝试。

2. 延迟响应：每次登录失败后，增加下一次尝试的响应时间。这会使暴力破解变得非常缓慢。

3. 验证码：使用图形验证码、短信验证码或其他形式的二次验证，以确保真实用户的身份。

4. 多因素认证：使用如短信、电子邮件、硬件令牌或生物特征等多种认证方式，增加破解的难度。

5. 登录尝试次数限制：限制用户在一定时间内的登录尝试次数。

6. IP 黑名单：检测并记录多次登录失败的IP地址，并将其加入黑名单，阻止其进一步的登录尝试。

7. 密码复杂性：要求用户设置复杂的密码，包括大写字母、小写字母、数字和特殊字符，并定期更改密码。

8. 账户名策略：避免使用容易猜测的账户名，如“admin”或“root”。

9. 日志和监控：记录所有的登录尝试，并使用监控工具检测异常行为。

10. 使用Web应用防火墙 (WAF)：WAF可以帮助检测和阻止暴力破解攻击。

11. 教育用户：教育用户不要使用容易猜测的密码，并定期更改密码。

12. 密码哈希：在存储密码时，使用强哈希函数（如bcrypt或Argon2）并加盐，以增加破解的难度。

这些策略可以单独或组合使用，以提高系统的安全性。最重要的是，定期审查和更新安全策略，以应对新的威胁和攻击手段。

.2 密码哈希：在存储密码时，使用强哈希函数（如bcrypt或Argon2）并加盐，以增加破解的难度。为什么这种可以增加破解的难度呢

密码哈希和加盐是密码存储的两个关键技术，它们可以显著增加破解密码的难度。以下是为什么这两种技术可以增加破解难度的原因：

1. 密码哈希：

   • 不可逆性：哈希函数是一种单向函数，这意味着从哈希值很难（或说几乎不可能）反推出原始输入。因此，即使攻击者获得了哈希值，他们也无法直接知道原始密码。
   • 确定性：对于同一个输入，哈希函数总是产生相同的输出。但是，即使是微小的输入变化，也会产生截然不同的哈希值。这使得攻击者无法通过分析哈希值的模式来猜测密码。
   • 强哈希函数：如 bcrypt 和 Argon2 设计上是计算密集型的，这意味着生成哈希值需要相对较长的时间。这种特性使得暴力破解或字典攻击变得非常缓慢和不切实际。

2. 加盐：

   • 独特性：盐是一个随机生成的值，与每个密码结合在一起进行哈希。这意味着即使两个用户使用相同的密码，由于盐的不同，它们的哈希值也会不同。
   • 抵御彩虹表攻击：彩虹表是预先计算好的哈希值列表，用于快速查找和破解哈希值。通过为每个密码添加独特的盐，可以使彩虹表攻击变得不切实际，因为攻击者需要为每个可能的盐值生成一个新的彩虹表。
   • 增加破解成本：即使攻击者想要针对单一哈希值进行暴力破解或字典攻击，由于盐的存在，他们必须为每个哈希值单独进行破解，而不能一次性破解所有哈希值。

综上所述，密码哈希和加盐可以显著提高密码的安全性，使得攻击者即使获得了存储的哈希值，也很难破解出原始密码。

.3 有没有采用加token的方式，来防爆破呢

是的，使用令牌（token）是一种有效的方法来防止暴力破解攻击。这种方法通常与其他安全措施结合使用，以增强系统的安全性。以下是如何使用令牌来防止暴力破解的几种策略：

1. 限制令牌的有效期：为每个登录尝试生成一个短暂的、唯一的令牌，并在一定时间后使其失效。这意味着攻击者不能使用旧的或无效的令牌进行暴力破解。

2. 令牌计数器：为每个用户或IP地址设置一个令牌计数器。每次登录尝试都会消耗一个令牌。当令牌用完时，用户或IP地址将被暂时锁定，直到令牌重新生成。

3. 令牌桶：使用令牌桶算法限制登录尝试的速率。每个用户或IP地址都有一个令牌桶，桶中的令牌数量代表允许的登录尝试次数。每次登录尝试都会消耗一个令牌，而令牌会以固定的速率重新生成。

4. 双因素认证令牌：除了用户名和密码外，还需要一个一次性的令牌来登录。这个令牌可以通过硬件设备、短信或手机应用生成。即使攻击者知道用户名和密码，没有令牌也无法登录。

5. 验证码：在登录表单中添加一个验证码，要求用户输入显示的字符或数字。这可以确保真实的用户正在尝试登录，并阻止自动化的暴力破解工具。

6. JWT (JSON Web Tokens)：在某些应用中，可以使用JWT作为令牌，其中包含用户的身份信息和其他元数据。JWT可以被服务器验证，确保其内容没有被篡改。

使用令牌的方法不仅可以防止暴力破解，还可以增强系统的整体安全性。然而，令牌系统也需要适当的管理和维护，以确保其有效性和安全性。

拥塞控制的坏处

拥塞控制的坏处:
拥塞控制在计算机网络中是非常关键的，特别是在传输控制协议 (TCP) 中，它能够确保网络不会被过载。但与所有技术一样，拥塞控制也有其不足之处:

• 响应时间: 拥塞控制算法可能导致某些连接的响应时间增加，特别是在网络出现拥塞时。
• 资源未充分利用: 为了防止网络拥塞，拥塞控制有时可能过于保守，导致网络资源未被充分利用。
• 复杂性: 实施有效的拥塞控制策略可能会增加系统的复杂性。
• 不公平性: 不同的拥塞控制算法可能会对不同的流产生不公平的影响，尤其是当流之间存在竞争时。

timewait时间过长怎么办

TIME_WAIT时间过长怎么办:
在TCP连接中，当一个连接关闭时，这个连接可能会进入一个名为TIME_WAIT的状态。这是为了确保所有数据都已经传输到接收方并处理完毕。但是，如果有大量的连接迅速打开和关闭，这可能会导致大量的TIME_WAIT状态的连接，占用了很多资源。

解决这个问题的一些建议如下:

• 调整TIME_WAIT时间: 在某些操作系统中，可以调整TIME_WAIT状态的持续时间。但请注意，太低的值可能会引发其他问题。
• 端口重用: 开启端口重用可以使新的连接使用处于TIME_WAIT状态的端口。在Linux上，这可以通过设置/proc/sys/net/ipv4/tcp_tw_reuse为1来实现。
• 增加可用端口范围: 默认情况下，操作系统可能只允许使用一定范围内的端口。你可以增加这个范围来允许更多的并发连接。
• 连接池: 使用连接池来复用已经建立的连接，而不是频繁地创建和销毁连接。

当考虑上述解决方案时，重要的是要确保它们不会对系统的其他部分产生负面影响。在做出任何更改之前，最好先在非生产环境中进行测试。