计算机网络

计算机网络 —— TCP、UDP 和 ARP 的知识点总结

三次握手，四次挥手详解，TCP 与 UDP 区别，ARP 工作原理详解

Posted by ChenJY on August 3, 2017 | Viewed times
本站图床基于新浪微博，图片加载异常请强制刷新或直接访问语雀空间查阅文章备份

三次握手

image B 的 TCP 服务器进程先创建传输控制块 TCB，准备接受客户进程的连接请求，然后服务器进行就处于 LISTEN 状态，等待客户的连接请求。

A 的 TCP 客户进程也是首先创建传输控制块 TCB，然后向B发出连接请求报文段，这时首部中的同步位 SYN = 1，同时选择一个初始序号seq = x。TCP 规定，SYN 报文段（即 SYN = 1 的报文段）不能携带数据，但要消耗掉一个序号，此时，客户端进入 SYN-SENT（同步已发送）状态。

B 收到连接请求报文之后，若同意连接，则向 A 发送确认，在确认报文段中应把 SYN 和 ACK 位都置为1，确认序号是 ack = x + 1，同时也要为自己选择一个初始序号 seq = y。请注意，这个报文段也不能携带数据，但同样要消耗一个序号，这时，TCP 服务器进程进入 SYN-REVD 状态。

TCP 客户进程收到 B 的确认之后，还要向 B 给出确认。确认报文段的 ACK 置为 1，确认号 ack = y + 1，而自己的序号 seq = x + 1。TCP 的标准规定，ACK 报文段可以携带数据，但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍然是 seq = x + 1。这时 TCP 连接已经建立，A 进入 ESTABLISHED 状态。当 B 收到 A 的确认之后，也进入 ESTABLISHED 状态。

上述称为三次握手

为什么要三次？

采用三次握手是为了防止失效的连接请求报文段突然又传送到主机 B，因而产生错误。失效的连接请求报文段是指：主机 A 发出的连接请求没有收到主机 B 的确认，于是经过一段时间后，主机 A 又重新向主机 B 发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机 A 第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机 B，主机 B 以为是主机 A 又发起的新连接，于是主机 B 同意连接，并向主机 A 发回确认，但是此时主机 A 根本不会理会，主机 B 就一直在等待主机 A 发送数据，导致主机 B 的资源浪费。

四次挥手

image 四次挥手过程稍微复杂一些，还是结合双方状态来阐述一下。 数据传输结束之后，通信双方都可以释放连接，现在 A 和 B 均处于释放报文阶段，并停止再发送数据，主动关闭 TCP 连接。A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。

A 把释放报文段首部的 FIN 置为1，其序号为 seq = u，他等于前面一传送过的数据的最后一个字节的序号加 1。这时 A 进入 FIN-WAIT 1 状态，等到 B 的确认。请注意，TCP 规定，FIN 报文段即使不携带数据，他也消耗掉一个序号。

B 收到连接释放报文段之后，即发出确认，确认号是 ack = u + 1，而这个报文段自己的序号是 v， 等于 B 前面已传送过的数据的最后一个字节的序号加 1。然后 B 就进入 CLOSE-WAIT 状态。TCP 服务器进程这时候通知高层应用进程，因而从 A 到 B 这个方向的连接就释放了，这时的 TCP 连接处于半关闭状态（half-close），即 A 已经没有数据要发送了，但 B 若发送数据，A 仍需要接收。也就是说，从 B 到 A 这个方向的连接并未关闭，这个状态可能持续一段时间。

A收到来自B的确认后，就进入FIN-WAIT2状态 ，等待B发出的连接释放报文段。

若 B 已经没有要向 A 发送的数据了，其应用进程就通知 TCP 释放链接，这时 B 发出的连接释放报文段必须使 FIN = 1。现假定 B 的序号为 w（因为半关闭状态期间可能 B 还发送了一些数据）。B 还必须重复上次已发送过的确认号 ack = u + 1。这时 B 就进入了 LAST-ACK（最后确认状态）状态，等待 A 的确认。

A 在收到 B 的连接释放报文段之后，必须对此发出确认。在确认报文段中把 ACK 置为 1，确认号 ack = w + 1，而自己的序列号是 seq = u + 1（因为根据 TCP 标准，前面发送过的 FIN 报文段要消耗一个序列号）。然后进入到 TIME-WAIT（时间等待）状态。请注意，现在 TCP 连接还没有释放，必须经过时间等待计时器设置的时间 2 MSL 后，A 才进入 CLOSED 状态。时间 MSL 叫做最长报文段寿命，RPC 793 建议设置为 2 分钟，但实际工程中可根据实际情况调整。因此，从 A 进入到 TIME-WAIT 状态后，要经过 4 分钟才能进入 CLOSED 状态，才能开始建立下一个连接。当 A 撤销控制传输快 TCB 后，就结束了这次的 TCP 连接。

为什么A在TIME-WAIT之后要等待2MSL呢？

这里有两个理由：

  1. 保证 A 发送的最后一个 ACK 报文能到达 B。这个 ACK 报文很有可能丢失，因而使得处在 LAST-ACK 状态的 B 收不到对已发送的 FIN+ACK 报文段的确认。B 会超时重传这个 FIN + ACK 报文段，而 A 就能在 2 MSL 时间内收到这个重传的 FIN + ACK 报文段。接着 A 重传一次确认，重新启动 2 MSL 计时器。最后 A B 均能进入正常的 CLOSED 状态。

  2. 防止上一节提到的 “已失效的连接请求报文段” 出现在本链接中，A 在发送完最后一个 ACK 报文后，再经过时间 2 MSL，就可以使得本链接持续时间内所产生的所有报文段都从网络中消失。这样就可以使得下一个新连接中不会出现这种旧的连接请求报文段。

保活计时器

客户已主动与服务器建立 TCP 连接，但后来客户端出现故障，服务器收不到客户端的数据，因此服务器不能白白等下去，服务器每收到客户端的消息就重新设置保活计时器，通常是两小时，若两小时没再收到客户端发来的数据，服务器就发送探测报文段，以后每隔 75 分钟发送一次，若一连发送 10 个探测报文段仍然没有客户端的响应，服务器就认为客户端出现了故障，接着就关闭这个链接。

TCP的有限状态机

image

TCP 与 UDP 区别

TCP — 传输控制协议

  1. 面向连接，传数据前必须建立 TCP 连接
  2. 点对点的
  3. 提供可靠的交付，传输的数据无差错，不丢失，不重复，且按序到达
  4. 提供全双工通信，允许双方应用程序在任何时候都能发送数据，两端均设有发送缓存和接收缓存
  5. 面向字节流，TCP 不知道发送字节流的含义，需要应用程序自己解析还原

UDP — 用户数据报文协议

  1. 是无连接的，发送数据之前不需要建立连接，因此减少开销和发送数据之前的延迟
  2. 使用尽最大努力交付，既不保证可靠交付，因此主机不需要维持复杂的连接状态
  3. 面向报文，应用层交给 UDP 多长的报文，UDP 照样发送，UDP 一次交付一个完整的报文。因此应用程序必须选择合适的报文大小，太长 IP 层会进行分片降低效率；太短 IP 数据报的首部相对长度过大，也降低效率
  4. UDP 没有拥塞控制，适合 IP 电话，实施视频会议等要求源主机以恒定速率发包，并且允许丢失一些数据却不允许延迟的情况
  5. UDP 支持一对一，一对多，多对多的交互通信
  6. UDP 首部开销小，只有 8 字节，比 TCP 20 字节短

TCP 可靠传输的原理

停止等待协议

A 向 B 发送一组，B 收到返给 A 确认，A才继续发送。如果期间 A 未收到 B 的确认，一段时间后就超时重传，为了实现超时重传，A 在没法送完成一个分组的时候，需要设置一个超时计时器。如果超时计时器之前收到了 B 的确认信息，就撤销超时计时器。这里还需注意的是，A 必须保存一个上一次发送的组的副本，收到确认之后才能删除；分组与确认分组均要编号；超时计时器的时间要比数据传输往返的时间略长一些

流水线传输

连续 ARQ 协议

每收到一个确认，窗口向前滑动一位，确认可以不是每次都发，而是累积一定数量之后发送，表示在这之前的我都收到了。但会造成回退 N 问题。

滑动窗口协议
  1. 描述滑动窗口需要三个指针，p1 之前表示已发送且收到确认的部分
  2. p3 - p1 表示 A 的窗口大小
  3. p2 - p1 表示已发送未收到确认的部分
  4. p3 - p2 表示窗口内允许发送但是尚未发送的部分

其他知识点太多，可以看书。。。不写出来了

TCP 拥塞控制

当某段时间，资源总需求 > 可用资源数 的时候，网络性能就会明显变坏，吞吐量将下降。拥塞控制就是防止过多的数据注入到网络中，这样可以使得网络中的路由器或链路不至于过载。拥塞控制的前提是网络能承受现有的网络负荷。

和流量控制相比，拥塞控制是一种全局性的，而前者往往指的是点对点的通信量的控制，是一个端到端的问题。拥塞控制算法需要将控制报文发送给发送端，要它放慢速率这点和流量控制很相似，因此经常混淆。

几种拥塞控制的方法

  1. 慢开始：发送方维持一个叫拥塞窗口的变量，大小取决于网络的拥塞程度可以动态变化，发送窗口与之大小一样，发送方控制原则是 —— 只要网络没出现拥塞，拥塞窗口就增大一点，增加注入分组数，出现拥塞就减小一点，减小注入分组数。

  2. 拥塞避免：每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加一，而不是加倍，比慢开始增长缓慢得多。如果判断出现拥塞，就把门限设为出现拥塞时发送窗口大小的一半，cwnd 重新设置成1。

  3. 快重传：丢包之后即使发送对上一个接收到的包的重复确认，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段。

  4. 快恢复：将门限值减半，然后 cwnd 置为这个值，而不是1开始

ARP 协议

每个主机都有一个 ARP 高速缓存，里面有本局域网上各主机和路由器的 IP 地址到硬件地址的映射表，同一个局域网中，先查询自己的缓存 ARP 表。假设 A 要向局域网中的 B 主机发送 IP 数据报时，先查询自己的 ARP 缓存中是否有 B 的记录，没有就运行 ARP进程：

  1. ARP 进程在本局域网上广播发送一个 ARP 请求分组，告知自己的 IP 和 硬件地址，想要知道主机 IP 为 xxx 的硬件地址
  2. 局域网中所有主机都收到这个消息，然后 B 发现自己符合之后，记录一下 A 的 IP 和硬件地址，将自己的 IP 和硬件地址一对一的回复给 A
  3. ARP 缓存中的每个映射地址都需要设置生存时间，例如十到二十分钟
  4. 对于在不同局域网中的传输，需要借助路由器

参考资料

  • 《计算机网络 第五版》 谢希仁著

许可协议

Comment

CATALOG
    FEATURED TAGS
    年度总结 JVM JDK 源码分析 Redis Java Tech 论文阅读 分布式系统 操作系统
    FRIENDS