Interview_计网_day19

计网学习资料

计算机网络

2019 王道考研 计算机网络

可以看看概论的 \(OSI\) 参考模型，传输层，应用层部分。

\(IP\) 地址和 \(MAC\) 地址

  • \(MAC\) 地址是物理地址，用来定位网络设备的位置，不可改变，使用在数据链路层。
  • \(IP\) 地址是虚拟地址，为互联网上每一个网络和主机分配一个逻辑地址，可以动态变化，使用在网络层。

\(IP\) 层怎么知道报文给哪个应用程序。如何区分 \(TCP\) 和 \(UDP\) 报文

  1. 通过端口号区分。
  2. 通过 \(IP\) 数据报首部中的协议标识符字段区分。\(UDP\) 是 \(17\)，\(TCP\) 是 \(6\)。

\(TCP\) 和 \(UDP\) 区别/应用场景

区别：

  • 连接
    • \(TCP\) 是 面向连接 的通信，传输数据前必须建立连接。
    • \(UDP\) 是 无连接 的通信，传输数据前不用建立连接。
  • 服务对象
    • \(TCP\) 的每一条连接是 一对一 的。
    • \(UDP\) 的连接支持 一对一、一对多、多对一、多对多 的通信。
  • 可靠性和效率
    • \(TCP\) 提供 可靠的服务，保证数据无差错、无丢失、不重复、按序到达。但传输速度慢。
    • \(UDP\) 尽最大努力交付，不保证可靠交付。但传输速度快。
  • 数据报长度
    • \(TCP\) 数据报是动态长度的，报文长度根据 接收方窗口大小 和 网络拥塞情况 动态决定。
    • \(UDP\) 是面向报文的，对于上面传下来的数据报，添加首部后就交给网络层。不合并，不拆分，保留这些报文的边界。
  • 首部开销
    • \(TCP\) 首部开销大，首部固定 \(20\) 字节 + 选项(长度可变，最短 \(0\) 字节，最长 \(40\) 字节)
    • \(UDP\) 首部开销小，首部固定 \(8\) 字节。
  • 资源要求
    • \(TCP\) 对系统资源要求多。
    • \(UDP\) 对系统资源要求少。

应用场景：

  • 若保证 数据完整性 更重要的话，使用 \(TCP\) 协议，例如文件传输。
  • 若保证 数据实时性 更重要的话，使用 \(UDP\) 协议，例如 \(QQ\) 聊天、在线视频 (即时通信，速度要求高，但偶尔的间断不是问题)。

\(TCP\) 首部报文

(图片来自 https://blog.csdn.net/qq_32998153/article/details/79680704)

  1. 源端口、目的端口：通信发送方和接收方的端口。
  2. 序号：本报文段中第一个数据节点的序号。
  3. 确认号：下一个报文段希望收到的第一个数据节点的序号。
  4. 数据偏移：指出数据部分和报文起始处的距离。
  5. \(6\) 个控制位
    1. \(URG\)：紧急位，表示有一个紧急数据需要尽快发送，而不是在发送缓存中排队等待。
    2. \(ACK\)：确认位，当 \(ACK=1\) 时，确认号才有意义。
    3. \(PSH\)：推送位，表示有一个紧急数据需要尽快交付给应用进程，而不是在接收缓存中等待。
    4. \(RST\)：复位位，表示 \(TCP\) 传输过程中出现了严重错误，需要释放连接，然后重新建立连接。
    5. \(SYN\)：同步位，在建立连接时用来同步序号。
    6. \(FIN\)：终止位，当 \(FIN=1\) 时，表示数据传输完成，想要释放连接。
  6. 窗口：作为接收方让发送方设置其发送窗口的依据。
  7. 检验和：检验数据是否发生错误。
  8. 紧急指针：在 \(URG=1\) 时使用，表示本报文段中紧急数据的字节数。
  9. 选项：长度可变，最长可以有 \(40\) 字节

\(TCP\) 如何保证可靠性

  1. 检验和
    • 发送方在发送数据之前计算检验和并取反，填入数据报中检验和位置。
    • 接收方接收数据报后，再次将所有数据求和并取反，如果得到的结果是全 \(0\) 的，则说明没有发生错误。
  2. 序列号
    • \(TCP\) 为每个字节的数据都进行了编号，这就是序列号。
    • 序列号保证了 \(TCP\) 传输的可靠性和数据的有序到达，提高了效率、去除了重复数据。
  3. 确认应答
    • 接收方每次收到数据后，都会进行确认，发送 \(ACK\) 报文，其中的确认号告诉发送方接收到了哪些数据，希望下一次从哪里开始发。
  4. 超时重传
    • 发送方发送数据后，如果一直没有等到确认报文，则认为数据丢失，则会重新发送数据。
    • 等待的时间通过 \(RTTs\) 计算，\(NewRTTs = (1- \alpha)*OldRTTs + \alpha*SampleRTTs\)，\(\alpha\) 取值一般为 \(0.125\)。
  5. 连接管理
    • 三次挥手、四次握手
  6. 流量控制
  7. 拥塞控制
    • 与流量控制不同的点在于，流量控制是对发送方和接收方之间的调节，拥塞控制是对整个网络全局性的调节。

\(TCP\) 流量控制

如果发送方发送数据太快，接收方来不及接收，可能使数据丢失。流量控制就是用来控制发送方的发送速度的。

\(TCP\) 的流量控制通过 滑动窗口 来实现，发送方窗口不可以超过接收方窗口大小。

接收方每次收到数据报后，在确认报文的窗口位置告诉对方自己的窗口大小，发送方收到确认报文以后，调整自己的窗口大小。

如果接收方再一次确认报文中，将窗口设为了 \(0\)，那么发送方就停止发送，直到接收方在发送一个确认报文，重新设置窗口值后，才可以继续发送。

如果接收方重新设置窗口值的报文丢失，发送方等了很久都没有收到，这就会陷入一个僵局。当然发送方也有打破僵局的方法，发送方定时发送一个 测试报文，询问接收方是否可以继续发送，如果可以，接收方就会告诉发送方此时它可以接收的窗口大小。如果不可以，发送方就继续等待，重置定时器。

\(TCP\) 拥塞控制

当过多数据注入到网络中，使网络中的 对资源的需求>可提供资源 时，这就是网络拥塞。

\(TCP\) 的拥塞控制方法有四种：慢开始、拥塞避免、快重传、快恢复。发送双方都有一个拥塞窗口 \(cwnd\)。

(图片来自 https://blog.csdn.net/m0_37962600/article/details/79993310)

  • 慢开始和拥塞避免
    • 最开始的时候，由于不清楚网络的情况，所以发送方最开始的拥塞窗口为 \(1\)，每经过一个往返时间 \(RTT\)，\(cwnd\) 翻倍。当 \(cwnd\) 超过慢开始门限以后，则使用拥塞避免算法。
    • 为了使 \(cwnd\) 缓慢的增大，每经过一个 \(RTT\)，\(cwnd\) 增长 \(1\)。在这过程中，一旦发生网络拥塞，则将慢开始门限设为当前值的一半，并重新设置 \(cwnd\) 为 \(1\)，重新启动慢开始。
  • 快重传和快恢复
    • 快重传要求在收到一个失序的报文段后就立即发送重复确认，发送方只要连续收到三个重复的确认，就认为这个报文段丢失，然后立即重传。
    • 当发送方连续收到了三个重复确认，就乘法减半，慢开始门限设置为当前值的一半，\(cwnd\) 设置为现在的慢开始门限，然后进行拥塞避免算法。

\(TCP\) 三次握手

(图片来自 https://blog.51cto.com/fengbaoli/1782250)

\(seq：\) 序号，\(ack：\) 确认号

  • \(Round\ 1：\) 客户端发送连接建立请求报文段，无应用层数据。

\[ SYN=1，seq=x(随机) \]

  • \(Round\ 2：\) 服务器端为该 \(TCP\) 连接分配缓存和变量，并向客户端发送确认报文端，允许连接，无应用层数据。

\[ SYN=1，ACK=1，seq=y(随机)，ack=x+1 \]

  • \(Round\ 3：\) 客户端为该 \(TCP\) 连接 分配缓存和变量，并向服务器端发送确认的确认，此时可以携带数据。

\[ SYN=0，ACK=1，seq=x+1，ack=y+1 \]

三次握手的目的是：连接服务器指定端口，建立 \(TCP\) 连接，同步连接双方的序列号和确认号，交换 \(TCP\) 窗口大小信息。

为什么需要回传 \(SYN\)

为了告诉发送端我收到的信息是你发送的请求建立连接的信号。

已经传了 \(SYN\)，为什么需要传 \(ACK\)

为了确保通信双方无误，传了 \(SYN\) 代表发送方到接收方的信号没问题，传 \(ACK\) 为了确认接收方到发送方的信号没问题。

\(TCP\) 为什么不可以两次握手

假设只有两次握手，一开始客户端向服务器端发送了第一个请求建立连接的信息，但这时由于网络拥塞，信息迟迟没有到底服务器端。

客户端没有等待服务器端发来的确认信息，则又发送了第二个请求建立连接的信息并正确建立了 \(TCP\) 连接，于是客户端和服务端开始了正常的数据传输。

直到数据传输完成，关闭连接后。第一个迟到的连接到达服务器端，服务器端认为客服换又想和我建立连接，于是同意了连接，并开始等待客户端发送数据，然后对于客户端来说，并没有发送新的请求，则会丢弃服务器的信息，那么服务器端就会一直处于等待状态，造成资源的浪费。

\(TCP\) 为什么不用四次握手

经过三次握手以后，客户端和服务器端都确定了自己能够得到对方的信息，也确定了自己发送的信息对方可以收到，那么就不需要多余的第四次了。

\(TCP\) 四次挥手

(图片来自 https://blog.51cto.com/fengbaoli/1782250)

  • \(Round\ 1：\) 客户端发送连接释放报文段，停止发送数据，主动关闭 \(TCP\) 连接。

\[ FIN=1，seq=u \]

  • \(Round\ 2：\) 服务器端回送一个确认报文段，此时客户端到服务器的连接已经释放了，处于 半关闭状态。此时如果服务器端有数据想要发给客户端，客户端仍然要接收。

\[ ACK=1，seq=v，ack=u+1 \]

  • \(Round\ 3：\) 服务器端发完数据以后，发送连接释放报文段，主动关闭 \(TCP\) 连接

\[ FIN=1，ACK=1，seq=w，ack=u+1 \]

  • \(Round\ 4：\) 客户端回复一个确认报文段，等待 \(2MSL\) 后，连接彻底关闭

\[ ACK=1，seq=u+1，ack=w+1 \]

\(TCP\) 四次挥手中 \(TIME\_WAIT\) 为什么要等待 \(2MSL\)

  • 原因 \(1：\) 保证最后一个 \(ACK\) 报文段能够到达 \(B\)。假如这个报文段丢失，服务器端没有收到 \(ACK\) 报文段，就会认为自己的 \(FIN\) 报文段可能在中途丢失，于是再发送一遍，如果客户端没有等待 \(2MSL\) 而提早关闭，就会收不到这个报文段，自然也不会发出 \(ACK\) 报文段，这样使得服务器端一直处于等待状态，造成资源浪费。
  • 原因 \(2：\) 在 \(A\) 发送最后一个 \(ACK\) 报文段后，在经过 \(2MSL\) 时间，就可以使本次连接持续时间内产生的所有报文段都从网络中消失了。这样可以使下一次建立连接的时候不会有上一次残留的报文段。

\(TIME\_WAIT\) 状态危害

每一个连接都要占用一个文件描述符，但系统的文件描述符是有限的，所以如果 \(TIME\_WAIT\) 状态的连接太多，就会导致可用连接减少。

如何避免 \(TIME\_WAIT\)

可以设置 \(SO\_REUSEADDR\) 套接字选项。

这么做的目的是通知操作系统，如果端口忙且 \(TCP\) 连接位于 \(TIME\_WAIT\) 状态时可以重用端口。

posted @ 2020-02-29 23:57  Jiaaaaaaaqi  阅读(288)  评论(0)  编辑  收藏  举报