计算机网络

典型回答 ping是用来探测本机与网络中另一主机之间是否可达的命令，如果两台主机之间ping不通，则表明这两台主机不能建立起连接。利用ping命令可以检查网络是否通畅或者网络连接速度，很好地分析和判定网络故障。 ping的原理是基于ICMP（Internet Control Messages Protocol）来工作的，即因特网信报控制协议； ping命令利用了ICMP两种类型的控制消息：“echo request”（回显请求）、“echo reply”（回显应答）。 在主机A上执行ping命令，目标主机是B。在A主机上就会发送“echo request”（回显请求）控制消息，主机B正确接收后即发回“echo reply”（回显应答）控制消息，通过对方回复的数据包来确定两台网络机器是否连接相通，时延是多少。 ping命令本身处于应用层，相当于一个应用程序。它使用的ICMP协议是一个网络层协议，也就是说，ping是一个应用层直接使用网络层协议的例子。像我们常见的HTTP协议是依赖的传输层协议TCP/UDP，而传输层的协议再依赖网络层的IP协议。 扩展知识 ✅ping为什么不需要端口？

典型回答 跨域访问问题（Cross-Origin Resource Sharing，CORS）是由浏览器的同源策略引起的安全限制。同源策略是一种浏览器安全策略，它要求网页中的所有资源必须来自同一个域名、协议和端口，否则浏览器会阻止跨域的资源请求。 所以，如果在浏览器访问过程中发现域名、端口或者协议不同的时候，就会出现跨域问题。 域名不同：如从a.com的页面请求b.com的资源。 协议不同：如从http的页面请求https的资源。 端口不同：当页面的端口与请求的资源的端口不一致时，同样会触发跨域问题。 解决跨域访问问题的方法有以下几种： CORS（推荐）：CORS是一种机制，通过在服务器端设置相应的响应头来解决跨域问题。服务器在响应中添加Access-Control-Allow-Origin头，指定允许跨域访问的域名或通配符*，使得浏览器可以放行跨域请求。CORS是目前最常用的解决跨域问题的方式，支持现代浏览器。 1 2 3 4 @CrossOrigin(origins = "*") public class HollisTestController { } JSONP：JSONP是一种跨域通信的技术，它利用<script>标签可以跨域访问的特性，通过动态创建<script>标签来加载跨域资源，服务器返回一个包含回调函数的JavaScript脚本，客户端通过回调函数处理响应数据。不过JSONP只支持GET请求，且只能用于跨域请求JSON数据。 代理服务器：可以通过在同源域名下设置一个代理服务器，实现跨域访问。前端将请求发送给代理服务器，代理服务器再转发请求给目标服务器，并将响应返回给前端，从而绕过跨域限制。这种方式需要部署额外的代理服务器，适用于一些特殊情况。 扩展知识 二级域名跨域吗？ 浏览器实施了同源策略，即网页中的脚本只能访问与其来源相同的资源。同源的定义包括协议（如http与https）、域名和端口号，如果这三者中有任何一个不同，就会被视为跨域请求。 www.hollischuang.com中获取 www.a.hollischuang.com中的资源，同样的规则适用。浏览器会将这两个视为不同的源，除非服务器在响应中配置了允许跨域访问的 CORS 头部。

典型回答 TCP（Transmission Control Protocol，传输控制协议）和UDP（User Datagram Protocol，用户数据报协议）是两种主要的网络传输协议，都位于传输层。 ✅介绍一下OSI七层模型？ 他们主要有以下区别： 连接类型 TCP 是一种面向连接的协议。在发送数据之前，它需要建立连接，这通过三次握手过程完成。结束后通过四次挥手断开连接。 UDP 是无连接的协议。它发送数据而不预先建立连接。 可靠性 TCP 提供可靠的数据传输，通过确认和重传机制来确保数据的正确送达。 **UDP 不保证数据的可靠送达。**它发送数据但不确认接收方是否收到，因此可能会丢失数据包。 速度和效率 TCP 由于其握手和确认机制，速度通常比UDP慢，但更可靠。 UDP 由于缺乏复杂的错误检查和恢复机制，通常比TCP更快，适用于对实时性要求较高的应用。 数据流控制和拥塞控制 TCP 有流量控制和拥塞控制机制，可以调整数据传输速率以避免网络拥堵。 UDP 没有内置的流量控制或拥塞控制机制。 ✅介绍下TCP是如何实现拥塞控制的？ 头部大小 TCP 头部较大，最小为20字节，因为它包含更多的控制信息。 UDP 头部较小，仅8字节，使得其开销更小。 在使用场景上，TCP 通常用于需要高可靠性的应用，如网页浏览、电子邮件、文件传输等。UDP 适用于实时应用，如视频流、在线游戏和语音通话，其中一些数据丢失是可以接受的。 TCP UDP 连接类型 面向连接，需要三次握手和四次挥手 无连接 可靠性 可靠的数据传输 不保证数据可靠性送达 头部大小 20-60字节长度 固定8字节 速度 比UDP慢 比TCP快 顺序性 所有数据包按特定顺序传递给接收者 数据报以无特定顺序送达 错误检测机制 提供了流量控制、拥塞控制 只有基本的错误检测机制，如校验和 上层协议 HTTP, HTTPs, FTP, SMTP, Telnet DNS, DHCP, TFTP, SNMP, RIP, VoIP 应用场景 web浏览器、文件传输、邮件 网络游戏，视频流，语音通话等

典型回答 ✅ping的原理是什么？ ping 命令在网络诊断中是一种常用工具，用于测试目标主机的连通性和响应时间。 ping 命令是基于 ICMP 协议的，ICMP 是 IP 协议的一部分，用于传递控制消息。ping命令本身处于应用层，相当于一个应用程序。它使用的ICMP协议是一个网络层协议。 但是，我们通常用到的端口号，其实是传输层（如 TCP 和 UDP）的一部分，用于区分同一 IP 地址上的多个服务或应用程序。 由于，ping是一个应用层直接使用网络层协议的例子，不涉及到传输层，所以不需要指定端口号。

典型回答 TCP重传率是一个衡量TCP网络性能的重要指标，它指的是在TCP通信过程中，由于数据包丢失、损坏或确认（ACK）未按预期到达而导致的数据包重传的比例或率。 TCP协议通过重传机制来保证数据传输的可靠性，但过高的重传率通常意味着网络质量问题，如网络拥塞、链路不稳定或质量差，从而导致网络吞吐量下降和延迟增加。所以，我们通常可以通过查看TCP重传率的指标来定位网络问题。 在Linux系统中，可以通过多种方式查看TCP重传率，以下是一些常用的方法： netstat****命令：netstat是一个强大的网络工具，可以显示网络连接、路由表、接口统计等信息。使用netstat -s可以查看TCP统计信息，其中包括重传的数据包数量。 1 2 3 4 5 6 7 $netstat -s | grep -i retrans 63570 segments retransmited TCPLostRetransmit: 10865 13197 fast retransmits 27 retransmits in slow start 1 SACK retransmits failed TCPSynRetrans: 24056 63570 segments retransmitted: 表示共有63,570个TCP段因为未被确认而被重传。这是一个指示网络中可能存在问题（如拥塞、信号质量不佳等）的重要信号。 TCPLostRetransmit: 10865: 指的是因为超时而被判定为丢失，随后触发重传的段数量为10,865。这可能表明网络延迟较高或网络稳定性问题。 13197 fast retransmits: “快速重传”机制触发的重传次数为13,197。快速重传通常在发送方收到三个重复的确认（duplicate ACKs）时触发，不需要等待重传计时器超时，这可以更快地恢复丢包情况。 27 retransmits in slow start: 在TCP的慢启动阶段，有27个段被重传。慢启动是TCP连接初始化和某些网络事件后用于控制网络拥塞的一种机制。 1 SACK retransmits failed: 表示有一个通过选择性确认（Selective Acknowledgment, SACK）机制尝试的重传失败。SACK是一种改进的确认机制，允许接收方指示哪些数据已被接收，哪些需要重传，从而提高网络效率。 TCPSynRetrans: 24056: 表示有24,056个SYN段（用于建立TCP连接的握手过程中的第一个包）被重传。这个数值异常高，可能指示着网络上存在大量的连接尝试被延迟或丢弃，这可能是网络拥堵的迹象，或者是某种形式的网络攻击，如SYN洪水攻击。 ss命令：ss是另一个实用工具，用于显示套接字统计信息。它可以提供类似于netstat的信息，但性能更好。使用ss -ti可以查看每个TCP连接的详细状态，包括重传次数。 1 $ss -ti | grep -i retrans tcpdump和wireshark：这些工具可以捕获网络上的数据包，通过分析数据包来计算重传率。这种方法更为直接和详细，但也更复杂，需要对TCP协议和网络分析有较深的理解。 ...

典型回答 网络分区指的是在一个分布式网络中，由于网络故障导致网络被划分为两个或多个互不通信的区域的情况。 在这种情况下，系统的不同部分无法相互通信，但各自可能仍然在正常工作。网络分区是CAP定理（一致性、可用性、分区容错性）中“P”（Partition tolerance，分区容错性）的来源。 ✅什么是CAP理论，为什么不能同时满足？ 完全避免网络分区是不现实的，这也是为啥CAP中P必须有的原因。然而，可以采取一些措施来减少网络分区的发生频率，并减轻其对系统的影响。 冗余连接：在关键的网络节点使用多条物理连接，以避免单点故障。 高质量的网络硬件：使用高性能的路由器和交换机，减少硬件故障的概率。 实时监控：持续监控网络的状态，包括流量、延迟、丢包率等。 故障预警：设置自动警报机制，在检测到网络异常时及时通知。 分区容错：设计系统时，考虑到网络分区的可能性，并确保系统可以在网络分区期间继续提供服务（虽然可能是有限的服务）。 扩展知识 网络分区和脑裂 脑裂是网络分区的一个具体表现，在集群环境中尤为常见。 它通常指的是在一个有状态的集群系统中，由于网络分区导致原本应该相互协调工作的节点（如数据库服务器）被划分到了不同的网络区域，并且每个区域的节点认为自己是“主节点”，从而开始独立地处理请求。这种情况可能导致数据不一致性和其他一系列问题。 ✅什么是脑裂？如何解决？ 网络分区是导致脑裂的原因之一。脑裂是网络分区在特定场景（如有状态服务的集群）中的表现形式。简单来说，网络分区是问题的根源，脑裂是由于网络分区在特定系统中所产生的后果。

典型回答 如果大家看过下面这篇： ✅为什么需要HTTP/2，他解决了什么问题？ 就会知道，HTTP/1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。 这种其实就是短连接，所以，短连接的指的就是客户端与服务器之间的连接在每次请求完成后立即关闭，下一次请求需要重新建立连接 。 比较典型的应用场景就是HTTP 1.0，除此之外还有邮件协议（SMTP、POP3）、数据库连接（如 MySQL 短连接）等，也都是用短连接实现的。 短连接的优点是节约服务器资源，因为连接关闭后，服务器就不需要维护大量空闲连接了。也能避免服务器长时间维持过多连接，适合轻量级应用。 但是他的缺点更加明显，那就是每次链接都需要重新建立，比如HTTP 1.0中，每次网络请求都需要重新进行TCP的三次握手和四次挥手。有很多额外的性能开销。 那和短连接对比，**长连接指的就是客户端与服务器建立 TCP 连接后，保持连接状态，可以进行多次数据交互，避免频繁建立和关闭连接的开销。 ** 长连接在HTTP 1.1（ 使用 Connection: keep-alive）开始就广泛应用了，而且在很多其他的应用，比如聊天室、IM通信、游戏、视频直播等等，都是需要长连接的。 长连接的优点是减少 TCP 连接建立和关闭的开销，提高性能。他是用于高并发场景，如即时通讯、流媒体、物联网设备通信等。 缺点是服务器需要维护大量连接，可能导致资源占用增加（如文件描述符、内存）。连接可能因超时断开，需要心跳检测（KeepAlive 机制）来维持连接。 **** 短连接 长连接 连接建立 每次请求都要重新建立连接 连接建立后持续存在 数据传输 仅传输一次请求和响应 可以多次传输数据 资源占用 连接关闭后释放资源 服务器需要维护连接 通信方式 适用于一次性请求 适用于持续通信 适用场景 HTTP 1.0、API 请求、邮件协议 WebSocket、IM、流媒体、游戏 服务器压力 小（连接断开后不占用资源） 大（需要维护更多连接） 连接效率 低（频繁握手） 高（减少握手次数） 扩展知识 长连接维护方式 由于 TCP 长连接可能因网络波动、服务器策略等原因断开，通常会使用以下方式维持连接： 心跳机制（KeepAlive） 定期发送心跳包，告诉服务器“我还在线”。 服务器若长时间未收到心跳，则关闭连接。 常用于 WebSocket、MQTT（物联网协议）、数据库连接池等。 重连机制 如果连接断开，客户端会尝试自动重新连接，避免手动重启。

典型回答 301 和 302 都是 HTTP 重定向状态码，所谓重定向就是从一个URL跳转到另一个URL。 但301和302还是有较大的区别的： 301 是永久重定向。资源已经永久移动到新的 URL，浏览器和搜索引擎会缓存这个重定向结果，适合永久链接更换。 302 是临时重定向，资源临时移动到新的 URL，客户端不应该缓存，后续请求仍然访问旧 URL。 扩展知识 短链适合301还是302？ ✅让你实现一个短链服务，你会考虑哪些问题?

典型回答 这里其实考察的是TCP的三次握手，以及HTTPS相比HTTP中需要增加的TLS/SSL，但是其实TLS的数据交换并不叫握手，没有这么叫的，他只是数据交换而已。 需要TCP的3次握手，在根据TLS的版本，做2-4步的加密通道建立（TLS 1.2需要4步，TLS 1.3需要2步）。 首先是需要进行TCP的三次握手，用来建立TCP的连接 第一次握手：客户端发送SYN包（同步序列编号）到服务器，进入SYN_SENT状态。 第二次握手：服务器返回SYN-ACK包（确认客户端的SYN），进入SYN_RCVD状态。 第三次握手：客户端发送ACK包确认服务器的SYN，完成TCP连接建立。 ✅什么是TCP三次握手、四次挥手？ 接下来通过TLS来建立加密通道，根据不同的版本看，情况不一样。以TLS 1.2为例（需2个往返，共4步）： ClientHello：发送客户端支持的TLS版本、加密算法、随机数。 ServerHello：服务器选定TLS版本、加密算法、随机数；发送证书（身份验证）、ServerKeyExchange（密钥参数，如ECDHE）。 客户端验证证书：生成预主密钥，用服务器公钥加密后发送；计算会话密钥。 Finish：双方发送加密的Finished消息验证握手完整性。 对于TLS 1.3来说，做了优化（1个往返，共2步）： ClientHello：包含支持的加密算法和密钥共享（Key Share）。 ServerHello：选择参数、发送证书、生成会话密钥并直接响应。 （图片来自网络） 扩展知识 为什么HTTPS不在TCP握手的时候直接把加密干了 其实最主要的原因就是职责问题，TCP他是一个是传输层协议，只负责“可靠地传数据”；而 TLS 是应用层/会话层的安全协议，负责“加密、认证和完整性”。两者目标不同，职责分离。TLS 必须在 TCP 之上运行，因为加密需要建立在可靠的连接基础上。

典型回答 ✅为什么需要HTTP/2，他解决了什么问题？ ✅什么是HTTP/3的QUIC协议？ 前面两篇文章分别介绍了HTTP 1.X、2和3的特性，这一篇是把3个放一起比较一下。 特性/版本 HTTP/0.9 HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/3 发布年份 1991 1996 1997 2015 2022 多路复用 ❌ ❌ ❌ ✅ ✅ 连接复用 ❌ ❌ ✅（Keep-Alive） ✅ ✅ 二进制格式 ❌ ❌ ❌ ✅ ✅ 首部压缩 ❌ ❌ ❌ ✅（HPACK） ✅（QPACK） 服务器推送 ❌ ❌ ❌ ✅ ⚠️ 被移除（多数实现不支持） 使用协议 TCP TCP TCP TCP QUIC (UDP) 延迟优化 ❌ ❌ 部分支持 很好 最佳（支持 0-RTT） 明文/加密 明文 明文 明文 可加密（常用 TLS） 强制加密（TLS over QUIC） HTTP/1.1（目前仍广泛使用） 默认启用 Keep-Alive（连接复用）。 HTTP/2 使用 二进制帧格式，更高效。 支持 多路复用（多个请求并发共用一个 TCP 连接，避免队头阻塞）。 支持 头部压缩（HPACK）。 支持 服务端推送（Server Push）。 缺点：仍然基于 TCP，存在队头阻塞（Head-of-Line Blocking）。 ...