Java面试那点事——网络200304

1. TCP 是如何保证可靠传输数据的？

保证可靠稳定的传输最主要是通过：

• 拥塞控制
• 流量控制
• ARQ协议

除此之外还有：超时传送、丢弃重复、校验和、分割合适数据包

（1）拥塞控制

• 慢启动：不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小；
• 拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，这样拥塞窗口按线性规律缓慢增长。
• 快重传：快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
• 快回复：快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就执行 “乘法减小” 算法，把 ssthresh 门限减半，但是接下去并不执行慢开始算法：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将 cwnd 设置为 ssthresh 的大小，然后执行拥塞避免算法。

（2）流量控制

TCP 连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。（TCP 利用滑动窗口实现流量控制）

（3）ARQ协议

• 停止等待 ARQ 协议

停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复 ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组；在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认；

• 连续 ARQ 协议

连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

---

2. TCP 和 UDP 的区别？

TCP 的优点：可靠，稳定.
TCP 的缺点：慢，效率低，占用系统资源高，易被攻击

UDP 的优点：快，比 TCP 稍安全 UDP 没有 TCP 的握手、确认、窗口、重传、拥塞控制等机制，UDP 是一个无状态的传输协议
UDP 的缺点： 不可靠，不稳定

---

3. TCP 三次握手和四次挥手的过程？

三次握手：(我要和你建立链接，你真的要和我建立链接么，我真的要和你建立链接，成功)

• 第一次握手：客户端发送 syn 包 (syn=x) 到服务器，并进入 SYN_SEND 状态，等待服务器确认；

• 第二次握手：服务器收到 syn 包，必须确认客户的 ACK（ack=x+1），同时自己也发送一个 SYN 包（syn=y），即 SYN+ACK 包，此时服务器进入 SYN_RECV 状态；

• 第三次握手：客户端收到服务器的 SYN＋ACK 包，向服务器发送确认包 ACK (ack=y+1)，此包发送完毕，客户端和服务器进入 ESTABLISHED 状态，完成三次握手。

四次挥手：(我要和你断开链接；好的，断吧。我也要和你断开链接；好的，断吧)

• 第一次挥手：客户端主动关闭方发送一个 FIN，用来关闭客户端到服务端的数据传送，也就是客户端告诉服务端：我已经不会再给你发数据了 (当然，在 fin 包之前发送出去的数据，如果没有收到对应的 ack 确认报文，客户端依然会重发这些数据)，但是，此时客户端还可以接受数据。

• 第二次挥手：服务端收到 FIN 包后，发送一个 ACK 给客户端，确认序号为收到序号 + 1（与 SYN 相同，一个 FIN 占用一个序号）。

• 第三次挥手：服务端发送一个 FIN，用来关闭服务端到客户端的数据传送，也就是告诉客户端，我的数据也发送完了，不会再给你发数据了。

• 第四次挥手：客户端收到 FIN 后，发送一个 ACK 给服务端，确认序号为收到序号 + 1，至此，完成四次挥手。

---

4. TCP 为什么需要三次握手？只进行两次会出现什么问题？第三次握手失败的情况 TCP 是如何处理的？

（1）为什么 TCP 链接需要三次握手，两次不可以么，为什么？

客户端发出的连接请求报文并未丢失，而是在某个网络节点长时间滞留了，以致延误到链接释放以后的某个时间才到达 Server。这是，Server 误以为这是 Client 发出的一个新的链接请求，于是就向客户端发送确认数据包，同意建立链接。若不采用 “三次握手”，那么只要 Server 发出确认数据包，新的链接就建立了。由于 client 此时并未发出建立链接的请求，所以其不会理睬 Server 的确认，也不与 Server 通信；而这时 Server 一直在等待 Client 的请求，这样 Server 就白白浪费了一定的资源。若采用 “三次握手”，在这种情况下，由于 Server 端没有收到来自客户端的确认，则就会知道 Client 并没有要求建立请求，就不会建立链接。

（2）第 3 次握手失败会怎么办？

第三次失败，只有客户端处于成功状态（因为第 2 次服务器返回了 ACK），服务器端没有接收到客户端的 ACK。

这要分几种情况讨论：

• 客户端发出的 ACK 丢失了，发出的 下一个数据包 没有丢失，则服务端接收到下一个数据包（这个数据包里也会带上 ACK 信息），能够进入正常的 ESTABLISHED 状态

• 如果服务端和客户端都没有数据发送，或者服务端想发送数据（但是发不了，因为没有收到客户端的 ACK），服务器都会有定时器发送第二步 SYN+ACK 数据包，如果客户端再次发送 ACK 成功，建立连接。

• 如果一直不成功，服务器肯定会有超时设置，超时之后会给客户端发 RTS 报文，进入 CLOSED 状态，防止 SYN 洪泛攻击。

---

5. 为什么连接的时候是三次握手，关闭的时候却是四次握手？

TCP 是全双工模式，关闭连接时，当主机 B 收到主机 A 的 FIN 报文时，仅仅表示主机 A 不再发送数据了但是还能接收数据。此时，主机 B 也未必全部数据都发送给 A 了，所以 B 可以立即 close；也可以发送一些数据给 A 后，再发送 FIN 报文给对方来表示同意现在关闭连接，因此，主机 BACK 和 FIN 一般都会分开发送。

---

【Java 面试那点事】

这里致力于分享 Java 面试路上的各种知识，无论是技术还是经验，你需要的这里都有！

这里可以让你【快速了解 Java 相关知识】，并且【短时间在面试方面有跨越式提升】

面试路上，你不孤单！