声明：全部内容来自JavaGuide

1.OSI七层协议和TCP/IP四层协议

OSI太过于复杂，且有些功能重复出现

2.HTTP

超文本传输协议

状态码：

1xx 提示消息，待处理

2xx 成功

3xx 重定向 301 永久重定向 304 不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件

4xx 客户端报文有误，服务端无法处理 403 服务端禁止访问资源 404 请求的资源服务器不存在

5xx 请求报文正确，服务段无法处理  500 通用错误码 501 暂不支持 503 服务器繁忙

解决沾包：HTTP 协议通过设置回车符、换行符作为 HTTP header 的边界，通过 Content-Length 字段作为 HTTP body 的边界，这两个方式都是为了解决“粘包”的问题

2.1.从一个URL到一个网页

1.输入URL，进行DNS解析获得服务器IP地址

2.通过IP地址和端口号建立TCP链接

3.在TCP连接的基础上发送HTTP请求报文，发送获取请求

4.服务器处理响应的请求

5.返回响应的结果

6.关闭TCP连接

7.浏览器渲染页面

2.2HTTP1.0

*默认短连接，TCP 连接复用率为 0：每次请求需独立建立 / 释放 TCP 连接，握手 / 挥手开销大，适用于早期 “单页面少量请求” 场景，无法应对多资源（图片、CSS、JS）的页面；

2.3HTTP1.1

1. 默认长连接，大幅提升效率默认启用 TCP 长连接（无需显式声明），一个连接可复用处理多个请求

2. 管道网络传输（不是默认开启，浏览器不支持）客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间

3. 队头阻塞服务器必须按照接收请求的顺序发送对这些管道化请求的响应。如果服务端在处理先请求时耗时比较长，那么后续的请求的处理都会被阻塞住，这称为「队头堵塞」

2.4HTTP2.0

基于HTTPS，安全性是有保障

1.头部压缩，提高速度

2.报文采用二进制格式，称为帧，增加数据传输的效率

3.引入了“流”的概念，在一条TCP连接上可以并行发送多个独立的请求和响应，每个流彼此独立互不影响，从应用层解决了队头堵塞的问题。

4.还支持服务器推送，服务器可以在请求前主动将可能需要的资源主动推送给浏览器，加快加载速度

5.TCP的限制TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这 1 个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题：一旦丢包会阻塞所有的HTTP请求

2.5HTTP3.0

最大的变化是使用QUIC协议替代TCP协议，QUIC基于UDP。QUIC最大的亮点是从底层支持“流”机制，而且这些流完全独立，每个流的丢包重传仅影响自身，不会阻塞同一连接中的其他流。

QUIC非常适合移动网络，QUIC引入了连接ID的概念，能让连接在不同IP地址和网络之间快速切换，十分稳定

1.最快 0RTT 延迟  QUIC内嵌了TLS，建立连接和加密一步完成

2.取消4元组，改用连接ID。非常适合移动网络

3.每个流丢包重传不影响其他流

4.基于UDP，为了绕开TCP在内核态的限制，在用户态实现可演进的可靠传输协议

2.6HTTPS

HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输

HTTP 默认端口号是 80，HTTPS 默认端口号是 443

信息加密：交互信息无法被窃取，混合加密的方式实现信息的机密性，解决了窃听的风险。
• 校验机制：无法篡改通信内容，篡改了就不能正常显示。摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险
• 身份证书：将服务器公钥放入到数字证书中，解决了冒充的风险。

机密性：通过 “非对称加密 + 对称加密” 结合的方式加密数据。

• 握手阶段用服务器公钥加密 “对称密钥”（非对称加密，确保密钥安全交换）；
• 后续数据传输用对称密钥加密（效率更高），防止数据被窃听（如 WiFi 嗅探、中间代理截取）

依赖 CA（证书颁发机构）颁发的 “数字证书”，证明服务器身份的真实性

SSL四次握手（RSA）

RSA有缺陷：一旦服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通讯密文都会被破解

ECDHE广泛使用：离散对数，安全性高；客户端可以在 TLS 协议的第 3 次握手后，第 4 次握手前，发送加密的应用数据，以此将 TLS 握手的消息往返由 2 RTT 减少到 1 RTT

1. ClientHello

首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。
在这一步，客户端主要向服务器发送以下信息：
（1）客户端支持的 TLS 协议版本，如 TLS 1.2 版本。
（2）客户端生产的随机数，后面用于生成「会话秘钥」条件之一。
（3）客户端支持的密码套件列表，如 RSA 加密算法。

2. SeverHello

服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容：
（1）确认 TLS 协议版本，如果浏览器不支持，则关闭加密通信。
（2）服务器生产的随机数，也是后面用于生产「会话秘钥」条件之一。
（3）确认的密码套件列表，如 RSA 加密算法。
（4）服务器的数字证书。

3.客户端回应

客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。
如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：
（1）一个随机数。该随机数会被服务器公钥加密。
（2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
（3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。

4. 服务器的最后回应
服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。
然后，向客户端发送最后的信息：
（1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

加密和解密

1. 对称加密（AES）：加密和解密使用同一把密钥（对称密钥）的算法。

2. 非对称加密：加密和解密使用一对密钥（公钥 + 私钥）：公钥公开，私钥保密；用公钥加密的数据只能用对应私钥解密，反之亦然。

HTTPS 中的加密逻辑（面试高频）

HTTPS 是 “对称加密 + 非对称加密 ” 的结合

HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。

HTTPS 协议本身到目前为止还是没有任何漏洞的，即使你成功进行中间人攻击，本质上是利用了客户端的漏洞（用户点击继续访问或者被恶意导入伪造的根证书），并不是 HTTPS 不够安全。

Websocket

原理：客户端与服务器通过一次 HTTP Upgrade 握手后，建立一条持久的 TCP 连接。之后，双方可以随时、主动地发送数据，实现真正的全双工、低延迟通信。

• 优点：
  • 实时性强：数据可即时双向收发，延迟极低。
  • 资源效率高：连接持续，无需反复建立/关闭，减少资源消耗。
  • 功能强大：支持服务端主动推送消息、客户端主动发起通信。
• 缺点：
  • 使用限制：需要服务器和客户端都支持 WebSocket 协议。对连接管理有一定要求（如心跳保活、断线重连等）。
  • 实现麻烦：实现起来比短轮询和长轮询要更麻烦一些。
  • WebSocket只有在建立连接时才用到了HTTP，升级完成之后就跟HTTP没有任何关系了

提到Websocket就得提到SSE,SSE相比Websocket会更简单，成本会低一点，因为SSE是单向通信，且本质上是长连接的HTTP请求，不需要特殊的服务器支持。区别在于SSE传输文本，Websocket用于传输文本和二进制

3.什么是PING

用来测试网络之间主机的连通性和网络延迟，如果PING不通，说明双方无法连接；如果RTT长，就说明网络延迟高。
原理就是发送ICMP报文实现的

4.DNS

DNS解决的是地址和IP映射的问题。

可以在UDP和TCP上运行，端口53
所谓DNS攻击就是有人篡改了DNS服务器返回的IP地址，使得用户访问的域名指向错误的IP地址。

5.TCP和UDP（重要）

1.面向连接：TCP是面向连接的，通过三次握手建立连接，四次挥手释放连接。UDP是无连接的，直接发报文就行。

2.是否可靠：TCP可靠，通过序列号，ACK，超时重传，流量控制，拥塞控制，确保无差错、不丢失、无重复且按顺序送达。
UDP不可靠，尽最大努力交付，发送报文之后不再理会，不保证达到、不保证顺序、不保证不重复。

3.是否有状态：TCP有状态，在两端维护一些信息：序列号、窗口大小、哪些发送了、哪些确认了。
UDP无状态，发送出去就什么都不管，所以开销小。

4.传输形式：TCP是传递字节流，可能会对数据进行拆分和合并。UDP传输报文，应用程序给多大数据快就传输多少，保留应用程序消息的边界。

什么是粘包：tcp发生数据是字节流，也就是01串在连接中流淌，没法区分完整的数据到底是什么。举例：发生“夏洛”和“特烦恼”，接收端收到的是“夏洛特烦恼”，那消息到底是“夏洛”和“特烦恼”还是“夏洛特”和“烦恼”呢？基于此，tcp需要加入一些自定义的规则，用于区分消息边界。比如加入消息头，消息头里写清楚一个完整的包长度是多少。

5.首部开销：TCP是点对点，UDP可以一对一，可以一对多，可以一对所有。
HTTP3.0之前使用TCP，而HTTP3.0使用基于UDP的QUIC协议

SYN报文什么时候会被丢弃

1.开启 tcp_tw_recycle 参数，并且在 NAT 环境下，造成 SYN 报文被丢弃
2.TCP 两个队列满了（半连接队列和全连接队列），造成 SYN 报文被丢弃

6.TCP三次握手和四次挥手

TCP的传输报文如果没收到那么都会触发超时重传

思考：为什么是3次握手，2次和4次都不行吗？
既然第二次握手传回了ACK，为什么还要发送SYN？
为什么要4次挥手？
为什么不能把服务器发送的 ACK 和 FIN 合并起来，变成三次挥手？
如果第二次挥手时服务器的 ACK 没有送达客户端，会怎样？
为什么第四次挥手客户端需要等待 2*MSL（报文段最长寿命）时间后才进入 CLOSED 状态？

6.1.三次握手

在 TCP 三次握手过程中，Linux 内核会维护两个队列来管理连接请求：

1. 半连接队列（也称 SYN Queue）：当服务端收到客户端的 SYN 请求时，此时双方还没有完全建立连接，它会把半连接状态的连接放在半连接队列。
2. 全连接队列（也称 Accept Queue）：当服务端收到客户端对 ACK 响应时，意味着三次握手成功完成，服务端会将该连接从半连接队列移动到全连接队列。如果未收到客户端的 ACK 响应，会进行重传，重传的等待时间通常是指数增长的。如果重传次数超过系统规定的最大重传次数，系统将从半连接队列中删除该连接信息。

为什么是3次握手，2次和4次都不行吗？：
4次握手：服务端在收到客户端的SYN之后，发送对客户端SYN的ACK，同时发送自己的SYN建立连接请求，再让客户端对服务端的SYN进行ACK确认，明显可以合并成一步，减少资源的使用。
2次握手：客户端发送SYN建立连接请求。服务端发送对客户端的SYN的ACK和自己的SYN请求。但是此时服务端不知道客户端有没有收到自己的消息，连接是否可靠就无法保障。

假如客户端发给服务端的ACK丢弃了，会重传吗？
其实不会，客户端发送给服务端的ACK丢弃了，服务端在超时之后，会重新发送自己的SYN请求，直到收到客户端的ACK为止，这才叫超时重传。

第三次握手可以携带数据吗？

可以。因为第三次握手的核心是ACK，只要TCP头部携带ack，确认号和序列号，就可以携带数据。但是使用场景不多，需服务器窗口 > 0，且客户端需提前有数据待发；多数场景下客户端会等握手完成再发数据

6.2.四次挥手

为什么需要四次挥手？
TCP是全双工通信，可以双向传输数据，那么我们就需要两次半关闭才能完全关闭连接。这就是为什么需要客户端和服务器各自发送自己的FIN请求断开和ACK确认对方的断开。

为什么不能把服务端的FIN和ACK合并成一起，三次握手不可以吗？

因为在服务端收到客户端的断开请求之后，可能还有数据没有传输完毕，这时先回复ACK表示确认断开的请求，等到数据发完之后再发送FIN断开请求。

其实也可以三次挥手

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

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

为什么服务端要等待2MSL才进入CLOSED？

2MSL时长 这其实是相当于至少允许报文丢失一次。比如，若 ACK 在一个 MSL 内丢失，这样被动方重发的 FIN 会在第 2 个 MSL 内到达，TIME_WAIT 状态的连接可以应对

7.TCP

可靠传输：

序列号/ACK，超时重传，校验和，滑动窗口

连接管理：

半连接/全连接，三次握手/四次挥手

流量控制：

接受窗口

拥塞控制：

慢启动、拥塞避免、快速恢复、快速重传

8.RPC

基于 TCP，就衍生了非常多的协议，比如 HTTP （超文本传输协议）和 RPC（远程过程调用）

TCP 是传输层的协议，而基于 TCP 造出来的 HTTP 和各类 RPC 协议，它们都只是定义了不同消息格式的应用层协议而已；RPC会建立一个连接池

关键区别：序列化上，其实TCP传输的无非是请求头和请求体，涉及到序列化和反序列化。RPC因为定制化程度更高，不用传输多余的信息，可以采用像是protobuf等保存结构体数据，因此性能会更好一些。