Java知识点整理 4 — 计算机网络

Phoenixxxxxxxxxxxxx

已于 2024-06-18 16:29:17 修改

阅读量1.1k

点赞数 31

分类专栏： Java 文章标签：网络计算机网络

于 2024-03-07 16:57:39 首次发布

本文链接：https://blog.csdn.net/konghaoran1/article/details/136510074

版权

Java 专栏收录该内容

21 篇文章 0 订阅

订阅专栏

一. 计算机网络基础

1.网络分层模型

OSI七层模型：

OSI五层模型：应用层、传输层、网络层、数据链路层、物理层。

TCP/IP四层模型：应用层、传输层、网络层、网络接口层。

2.为什么要分层

复杂的系统需要分层，因为每一层都需要专注于一类事情。网络分层的原因也是一样，每一层只专注于做一类事情。

各层之间相互独立：各层之间不需要关心其他层是如何实现的，只需要知道自己如何调用下层提供好的功能就可以了（可以简单理解为接口调用）。这个和开发时系统进行分层是一个道理。
提高了灵活性和可替换性：每一层都可以使用最适合的技术来实现，只需要保证你提供的功能以及暴露的接口的规则没有改变就行了。并且，每一层都可以根据需要进行修改或替换，而不会影响到整个网络的结构。这个和平时开发系统的时候要求的高内聚、低耦合的原则也是可以对应上的。
大问题化小：分层可以将复杂的网络问题分解为许多比较小的、界线比较清晰简单的小问题来处理和解决。这样使得复杂的计算机网络系统变得易于设计，实现和标准化。平时开发的时候，一般会将系统功能分解，然后将复杂的问题分解为容易理解的更小的问题是相对应的，这些较小的问题具有更好的边界（目标和接口）定义。

3.TCP三次握手与四次挥手

建立连接——三次握手：

第一次握手 ：客户端发送SYN包（SEQ = x）到服务器，并进入SYN_SENT状态，等待服务器确认。SYN是同步序列编号。
第二次握手 ：服务器收到SYN包，会确认客户端的SYN（ACK = x+1），同时自己也发送一个SYN包（SEQ = y），即SYN+ACK包，此时服务器进入SYN_RECV状态。
第三次握手 ：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK（ACK = y+1），发送完后，客户端和服务器进入ESTABLISHED状态，完成三次握手。ESTABLISHED状态表示连接建立成功，可以传输数据。

为什么要三次握手？

三次握手的目的是建立可靠的通信信道，双方都确认自己与对方的发送和接收都是正常的。

第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常
第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

第二次握手传回了ACK，为什么还要传回SYN？

服务端传回发送端所发送的 ACK 是为了告诉客户端：“我接收到的信息确实就是你所发送的信号了”，这表明从客户端到服务端的通信是正常的。回传 SYN 则是为了建立并确认从服务端到客户端的通信。

如果客户端第一次发送建立连接的SYN，服务端没有收到怎么办？

客户端迟迟收不到服务端的 SYN-ACK 报文（第二次握手），就会触发超时重传机制，重传 SYN 报文，而且重传的 SYN 报文的序列号都是一样的。

当客户端超时重传 3 次 SYN 报文后，由于 tcp_syn_retries 为 3(可设置)，已达到最大重传次数，于是再等待一段时间（时间为上一次超时时间的 2 倍），如果还没收到服务端的第二次握手，客户端就会断开连接。

断开连接——四次挥手：

第一次挥手 ：客户端发送一个 FIN（SEQ=x）标志的数据包到服务端，用来关闭客户端到服务器的数据传送。然后，客户端进入 FIN-WAIT-1 状态。
第二次挥手 ：服务端收到这个 FIN（SEQ=x）标志的数据包，它发送一个 ACK （ACK=x+1）标志的数据包到客户端。然后，此时服务端进入CLOSE-WAIT状态，客户端进入FIN-WAIT-2状态。
第三次挥手 ：服务端关闭与客户端的连接并发送一个 FIN (SEQ=y)标志的数据包到客户端，请求关闭连接，然后，服务端进入LAST-ACK状态。
第四次挥手 ：客户端发送 ACK (ACK=y+1)标志的数据包到服务端，并且进入TIME-WAIT状态，服务端在收到 ACK (ACK=y+1)标志的数据包后进入 CLOSE 状态。此时，如果客户端等待 2MSL 后依然没有收到回复，就证明服务端已正常关闭，随后，客户端也可以关闭连接了。

只要四次挥手没有结束，客户端和服务端就可以继续传输数据！

为什么要四次挥手？

TCP可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知，等对方确认后进入半关闭状态。当另一方也没有数据再发送时，就发出连接释放的通知，对方确认后就完全关闭了 TCP 连接。

举个例子：A 和 B 打电话，通话即将结束后。

第一次挥手：A 说“我没啥要说的了”。
第二次挥手：B 回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话。
第三次挥手：于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”。
第四次挥手：A 回答“知道了”，这样通话才算结束。

为什么不能将服务端发送的FIN和ACK合并，变成三次挥手？

因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复 ACK，表示接收到了断开连接的请求。等到数据发完之后再发 FIN，断开服务器到客户端的数据传送。

如果第二次挥手服务端的ACK没有送达客户端，会怎样？

客户端没有收到ACK确认，会重新发送FIN请求。

为什么第四次挥手客户端需要等待2倍的MSL(报文最大生存时间)时间后才进入closed状态？

第四次挥手时，客户端发送给服务器的 ACK 有可能丢失，如果服务端因为某些原因而没有收到 ACK 的话，服务端就会重发 FIN，如果客户端在 2*MSL 的时间内收到了 FIN，就会重新发送 ACK 并再次等待 2MSL，防止 Server 没有收到 ACK 而不断重发 FIN。

TCP四次挥手，服务端大量进程处于close wait状态，什么原因，如何解决？

说明服务端后续没有向客户端正常发送FIN请求进入LAST_ACK状态。

4.TCP和UDP

传输层协议

TCP（Transmission Control Protocol，传输控制协议）：提供 面向连接 的，可靠的数据传输服务。
UDP（User Datagram Protocol，用户数据协议）：提供 无连接 的，尽最大努力 的数据传输服务（不保证数据传输的可靠性），简单高效。

二者区别：

选择场景：

UDP 一般用于即时通信，比如：语音、视频、直播等等。这些场景对传输数据的准确性要求不是特别高，比如你看视频即使少个一两帧，实际给人的感觉区别也不大。
TCP 用于对传输准确性要求特别高的场景，比如文件传输、发送和接收邮件、远程登录等等。

5.HTTP基于TCP还是UDP

HTTP/3.0 之前是基于 TCP 协议的，而 HTTP/3.0 将弃用 TCP，改用 基于 UDP 的 QUIC 协议 。主要为了解决HTTP/2中存在的队头阻塞问题。由于HTTP/2在单个TCP连接上使用了多路复用，受到 TCP 拥塞控制的影响，少量的丢包就可能导致整个TCP连接上的所有流被阻塞。

6.队头阻塞问题

在 HTTP/2.0 中，多个 HTTP 请求和响应共享一个 TCP 连接，如果其中一个请求或响应因为网络拥塞或丢包而被阻塞，那么后续的请求或响应也无法发送，导致整个连接的效率降低。

HTTP/3.0 在一定程度上解决了队头阻塞问题，一个连接建立多个不同的数据流，这些数据流之间独立互不影响，某个数据流发生丢包了，其数据流不受影响（本质上是多路复用+轮询）。

7.TCP如何保证传输的可靠性？

基于数据块传输：数据被分割成 TCP数据块传输，再传输给网络层，数据块被称为报文段。
对数据包排序以及去重：TCP为了保证不丢包，给每个包一个序列号，有了序列号能将接收到的数据排序，并去掉重复的数据。
校验和: TCP保持首部和数据的检验和，目的是检测数据在传输过程中的变化。如果收到段的校验和有差错，TCP会丢弃这个报文段和不确认收到此报文段。
超时重传: 发送方发送数据之后，启动一个定时器，等待接收端确认收到这个报文段。接收端对已成功收到的包发回一个确认信息（ACK）。如果发送端在一定的往返时延（RTT）内未收到确认消息，那对应的数据包就被假设已丢失并重传。
流量控制: TCP连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送接收端缓冲区能容纳的数据。当接收端来不及处理发送端的数据时，会提示发送端降低发送速率，防止包丢失。TCP 利用滑动窗口实现流量控制。
拥塞控制: 当网络拥塞时，减少数据的发送。

8.TCP如何实现流量控制？

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，发送方不能发送数据。

为什么要流量控制：因为发送方与接收方的速率不一定相等，如果发送方速率过大，接收方一时间处理不过来，就会将暂时无法处理的数据放到接收缓冲区，如果后续接受缓冲区满了，那么新的数据只能丢弃，所以会造成网络资源的浪费。因此通过流量控制使得发送方与接收方达到一种动态平衡才是最好的。

9.TCP如何实现拥塞控制？

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。

TCP发送方维持一个拥塞窗口（cwnd）。拥塞窗口大小取决于网络的拥塞程度并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

TCP拥塞控制采用了四种算法，慢开始、拥塞避免、快重传和快恢复。在网络层也可以使路由器采用适当的分组丢弃策略，以减少网络拥塞的发生。

慢开始： 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1，每经过一个传播轮次，cwnd 加倍。
拥塞避免： 拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间 RTT 就把发送方的 cwnd 加 1.
快重传与快恢复： 在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。（当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。）

10.ARQ协议

自动重传请求（Automatic Repeat-reQuest，ARQ）是 OSI 模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认信息（Acknowledgements，就是我们常说的 ACK），它通常会重新发送，直到收到确认或者重试超过一定的次数。

ARQ 包括停止等待 ARQ 协议和连续 ARQ 协议。

停止等待 ARQ 协议

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

连续ARQ协议

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

11.超时重传

当发送方发送数据之后，它启动一个定时器，等待目的端确认收到这个报文段。接收端实体对已成功收到的包发回一个相应的确认信息（ACK）。如果发送端实体在合理的往返时延（RTT）内未收到确认消息，那么对应的数据包就被假设为已丢失并进行重传。

RTT（Round Trip Time）：往返时间，也就是数据包从发出去到收到对应 ACK 的时间。
RTO（Retransmission Time Out）：重传超时时间，即从数据发送时刻算起，超过这个时间便执行重传。

RTO 的确定是一个关键问题，因为它直接影响到 TCP 的性能和效率。如果 RTO 设置得太小，会导致不必要的重传，增加网络负担；如果 RTO 设置得太大，会导致数据传输的延迟，降低吞吐量。因此，RTO 应该根据网络的实际状况，动态地进行调整。

RTT 的值会随着网络的波动而变化，所以 TCP 不能直接使用 RTT 作为 RTO。为了动态地调整 RTO，TCP 协议采用了一些算法，如加权移动平均（EWMA）算法，Karn 算法，Jacobson 算法等，这些算法都是根据往返时延（RTT）的测量和变化来估计 RTO 的值。

二. HTTP

1.网页浏览的全过程

完整流程：

在浏览器中输入指定网页的 URL。
浏览器通过 DNS 协议，获取域名对应的 IP 地址。
浏览器根据 IP 地址和端口号，向目标服务器发起一个 TCP 连接请求。
浏览器在 TCP 连接上，向服务器发送一个 HTTP 请求报文，请求获取网页的内容。
服务器收到 HTTP 请求报文后，处理请求，并返回 HTTP 响应报文给浏览器。
浏览器收到 HTTP 响应报文后，解析响应体中的 HTML 代码，渲染网页的结构和样式，同时根据 HTML 中的其他资源的 URL（如图片、CSS、JS 等），再次发起 HTTP 请求，获取这些资源的内容，直到网页完全加载显示。
浏览器在不需要和服务器通信时，可以主动关闭 TCP 连接，或者等待服务器的关闭请求。

2.网络层的核心功能

转发与路由

转发：将分组从路由器的输入端口转移到合适的输出端口。
路由：确定分组从源到目的经过的路径。

3.HTTP和HTTPS的区别

端口号：HTTP 默认是 80，HTTPS 默认是 443。
URL 前缀：HTTP 的 URL 前缀是http://，HTTPS 的 URL 前缀是https://。
安全性和资源消耗：HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。

4.HTTP/1.0和HTTP/1.1的区别

连接方式: 1.0 为短连接，1.1 支持长连接。
状态响应码: 1.1中加入了大量状态码，比如，100 (Continue)—在请求大资源前的预热请求，409 (Conflict)—请求与当前资源的规定冲突，410 (Gone)—资源已被永久转移，而且没有任何已知的转发地址。
缓存处理: 1.0 中主要使用 header 里的 If-Modified-Since，Expires 作为缓存判断的标准，1.1 引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match。
带宽优化: 1.0 中存在一些浪费带宽的现象，例如客户端只需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，1.1 在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便开发者自由选择以便充分利用带宽和连接。
Host头处理: 1.1在请求头中加入了Host字段，允许在同一ip地址上托管多个域名，从而支持虚拟主机的功能。

5.HTTP/1.1和HTTP/2.0的区别

多路复用（Multiplexing）：HTTP/2.0 在同一连接上可以同时传输多个请求和响应（可以看作是 HTTP/1.1 中长链接的升级版本），互不干扰。HTTP/1.1 则使用串行方式，每个请求和响应都需要独立的连接，而浏览器为了控制资源会有 6-8 个 TCP 连接都限制。这使得 HTTP/2.0 在处理多个请求时更加高效，减少了网络延迟和提高了性能。
二进制帧（Binary Frames）：HTTP/2.0 使用二进制帧进行数据传输，而 HTTP/1.1 则使用文本格式的报文。二进制帧更加紧凑和高效，减少了传输的数据量和带宽消耗。
头部压缩（Header Compression）：发出多个请求，头一样或相似，会去掉重复部分。
服务器推送（Server Push）：HTTP/2.0 支持服务器推送，可以在客户端请求一个资源时，将其他相关资源一并推送给客户端，从而减少了客户端的请求次数和延迟。而 HTTP/1.1 需要客户端自己发送请求来获取相关资源。

6.HTTP/2.0和HTTP/3.0的区别

传输协议：HTTP/2.0 是基于 TCP 协议实现的，HTTP/3.0是基于QUIC协议实现的，是UDP协议的升级版本，具有加密、重传等新功能。
连接建立：HTTP/2.0 需要经过经典的 TCP 三次握手过程（由于安全的 HTTPS 连接建立还需要 TLS 握手，共需要大约 3 个 RTT）。由于 QUIC 协议的特性（TLS 1.3，TLS 1.3 除了支持 1 个 RTT 的握手，还支持 0 个 RTT 的握手）连接建立仅需 0-RTT 或者 1-RTT。这意味着 QUIC 在最佳情况下不需要任何的额外往返时间就可以建立新连接。
队头阻塞：HTTP/2.0 多请求复用一个 TCP 连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。由于 QUIC 协议的特性，HTTP/3.0 在一定程度上解决了队头阻塞（Head-of-Line blocking, 简写：HOL blocking）问题，一个连接建立多个不同的数据流，这些数据流之间独立互不影响，某个数据流发生丢包了，其数据流不受影响（本质上是多路复用+轮询）。
错误恢复：HTTP/3.0 具有更好的错误恢复机制，当出现丢包、延迟等网络问题时，可以更快地进行恢复和重传。而 HTTP/2.0 则需要依赖于 TCP 的错误恢复机制。
安全性：HTTP/2.0 和 HTTP/3.0 在安全性上都有较高的要求，支持加密通信，但在实现上有所不同。HTTP/2.0 使用 TLS 协议进行加密，而 HTTP/3.0 基于 QUIC 协议，包含了内置的加密和身份验证机制，可以提供更强的安全性。

7.cookie和session的区别

它们都用来存储数据，但cookie是在客户端存储数据，session在服务端存储数据。cookie安全性相对较低，可能被用户恶意修改，session安全性相对较高。cookie容量通常比较小，一般在几KB或几十KB之间，session一般没有容量限制。

三. ARP协议

ARP 协议，全称 地址解析协议（Address Resolution Protocol），它解决的是网络层地址和链路层地址之间的转换问题。因为一个 IP 数据报在物理上传输的过程中，总是需要知道下一跳（物理上的下一个目的地）该去往何处，但 IP 地址属于逻辑地址，而 MAC 地址才是物理地址，ARP 协议解决了 IP 地址转 MAC 地址的一些问题。

工作原理：ARP表、广播问询、单播响应。