TCP/IP 与OSI

TCP/IP

TCP/IP 四层模型是一个分层网络通信模型，
它将网络通信过程分为四个层次，这四层分别是：网络接口层、互联网层、传输层和应用层。

• 网络接口层负责在计算机和网络硬件之间传输数据，负责在物理网络上发送和接收数据帧，包括以太网、Wi-Fi 等协议
• 互联网层（网络层）通过 IP 协议提供数据包的路由和转发
• 传输层负责在两个主机之间提供端到端的通信服务，常见的协议有 TCP 和 UDP
• 应用层通过各种协议提供网络应用程序的功能，如 HTTP、FTP、SMTP 等协议

OSI

OSI（Open Systems Interconnection）七层模型将网络通信分为七个层次，每一层都有特定的功能，且每层相对独立，可以与其他层交互但不会影响其他层的内部实现。

七层模型从高到低依次为：

1. 应用层（Application Layer）：用户交互界面，提供网络服务，如HTTP、FTP、SMTP等。
2. 表示层（Presentation Layer）：数据格式转换、加密、解密，如JPEG、MPEG、SSL/TLS等。
3. 会话层（Session Layer）：建立、管理、终止会话，如NetBIOS、RPC等。
4. 传输层（Transport Layer）：可靠传输，流量控制，错误检测，如TCP、UDP等。
5. 网络层（Network Layer）：路径选择和逻辑地址（IP）管理，如IP、ICMP等。
6. 数据链路层（Data Link Layer）：物理地址（MAC）寻址，错误检测与纠正，如以太网、PPP等。
7. 物理层（Physical Layer）：比特流传输，物理连接，如光纤、网线、无线电波等。
   

区别

• OSI 七层模型 是另一个著名的网络模型，它将网络通信过程分为七个层次：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。
• 简化与实用性：TCP/IP 四层模型是对 OSI 七层模型的简化，省略了会话层和表示层，将数据链路层和物理层合并为网络接口层。这种简化更符合实际应用中的网络协议栈实现。
• 应用层的差异：在 OSI 模型中，应用层、表示层和会话层是分开的，而在 TCP/IP 模型中，它们被合并成了单一的应用层。这种设计简化了上层协议的开发和实现。

用户从输入URL到页面展示发生了什么

1）浏览器解析 URL

浏览器会解析 URL，根据请求信息生成对应的 HTTP 请求报文。

2）DNS 解析

请求需要知晓服务器域名对应的 IP 地址才能通信，浏览器会检查本地缓存、操作系统缓存，甚至路由器缓存。如果未命中缓存，浏览器向配置的 DNS 服务器发送查询请求，DNS 服务器递归查询最终返回 IP 地址。

3）TCP或者UDP

接着浏览器会调用 Socket 库委托协议栈工作，根据指定的情况选择 TCP 或 UDP。

如果使用 TCP，需要通过三次握手建立连接。需要在数据发送前通过三次握手与服务端建立连接。

此时得到了封装了 HTTP 数据的 TCP 数据包。

4）IP

在 TCP 数据包的基础上，再封装源地址 IP 和目标地址 IP 等信息，得到网络包。有了 IP 就能在多个网络节点中确定数据包的传输路径，最终能找到目标服务器。

5）MAC

得到网络包后，需要在 IP 头部的前面加上 MAC 头部，封装发送方 MAC 地址和接收方目标 MAC 地址。

MAC 用来确保子网内设备两点之间的通信寻址。（IP 是多个网络节点传输寻址）

6）网卡

这个时候，网络包还是存储在内存中的二进制数据，需要网卡把二进制数据转换为电信号，通过网线进行传输。

7）交换机

通过网线会连到交换机，交换机是二层网络设备。工作在 MAC 层，它会根据数据包中的 MAC 头找到另一个设备连接在交换机的哪个端口，然后传输。

如果找不到对应的端口，则会向交换机上的所有端口(除了源端口)广播。

8）路由器

路由器也是进行转发，但它是三层网络设备，包含 IP 层。利用路由器，数据在不同网络节点之间转发，最后到达服务器。

9）层层验证

服务器确认 MAC 地址匹配、IP 地址匹配，如果是 TCP 协议则看看序列号是否匹配，若匹配根据端口找到对应的监听进程，此时服务器上对应的应用就接收到数据了。

10）服务器处理

服务器接收到请求后，处理相应的业务逻辑，生成 HTTP 响应。这其间可能涉及到读取数据库、访问文件系统等。最终会生成响应给客户端（又是一层一层的封装 TCP、IP、MAC 等头部数据，得到最终传输的数据包），从网卡到交换机到路由器…

11）浏览器接收响应并渲染页面

经过多个路由器转发后，浏览器最终会接收到服务器返回的响应，进行页面渲染展示。

HTTP常见状态码

常见的http状态码分为5大类,每个状态码由3位数字组成,第一位表示类别

1XX 信息响应

• 100 Continue：服务器已接收请求的初步部分，客户端应继续请求。
• 101 Switching Protocols：服务器同意切换协议，如从 HTTP 切换到 WebSocket。

2XX 成功

• 200 OK：请求成功，服务器返回所请求的资源或数据。
• 201 Created：请求成功并创建了新的资源，常用于 POST 请求。
• 204 No Content：请求成功但服务器不返回任何内容，常用于删除操作。

3XX 重定向

• 301 Moved Permanently：资源已永久移动到新的 URL，客户端应使用新 URL 访问。
• 302 Found：资源临时移动到新的 URL，客户端应继续使用原来的 URL。
• 304 Not Modified：资源未修改，客户端可以使用缓存版本。

4XX 客户端错误

• 400 Bad Request：请求无效或语法错误，服务器无法处理。
• 401 Unauthorized：请求需要身份验证，客户端未提供有效的凭证。
• 403 Forbidden：服务器理解请求但拒绝执行，通常是权限问题。
• 404 Not Found：请求的资源在服务器上未找到。

5XX 服务端错误

• 500 Internal Server Error：服务器内部错误，无法完成请求。
• 502 Bad Gateway：服务器作为网关或代理，从上游服务器接收到无效响应。
• 503 Service Unavailable：服务器暂时无法处理请求，通常是因为过载或维护。

扩展知识

1）常见的重定向机制：

• 301 Moved Permanently 和 302 Found 都用于重定向，但前者用于永久重定向，通常会更新客户端的书签，而后者用于临时重定向，不会更新书签。
• 307 Temporary Redirect 与 302 Found 类似，但要求客户端必须使用相同的 HTTP 方法进行重定向请求，保证重定向的语义一致性。

2）4xx 与 5xx 状态码的区别：

• 4xx 系列状态码表示客户端的问题，如请求的格式错误（400）、未经授权访问（401）、请求的资源不存在（404）等。客户端应根据这些状态码调整请求内容或行为。
• 5xx 系列状态码表示服务器的内部问题，如服务器错误（500）、服务不可用（503）等。通常，客户端需要稍后重试请求。

3）204 和 304 区别：

• 204 No Content：适用于不需要返回响应体的成功操作，比如删除资源或表单提交后的页面跳转。
• 304 Not Modified：用于缓存机制中，当资源未修改时，服务器通过返回该状态码，通知客户端继续使用缓存资源，减少带宽消耗。

4）401 和 403 区别：

• 状态码 401 Unauthorized 和 403 Forbidden 常用于访问控制。当用户未认证时，返回 401 提示用户登录，而在用户认证后发现无权访问资源时，返回 403 提示权限不足。

HTTP请求报文

# 请求行
POST /api/user HTTP/1.1
# 请求头
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: application/json
Content-Type: application/json
Authorization: Bearer abcdefg12345
# 空行# 请求体
{"username": "johndoe","password": "password123"
}

组成

• 请求行（Request Line）：包含请求方法（如GET、POST）、请求的资源路径（如/index.html）、以及HTTP协议版本（如HTTP/1.1）。
• 请求头（Request Headers）：包含各种键值对，用于传递客户端环境、请求内容、认证信息等。
• 空行（Blank Line）：用于分隔请求头和请求体。
• 请求体（Request Body）：仅在POST、PUT等方法中存在，包含需要发送到服务器的数据。

HTTP响应报文

组成

• 状态行：由HTTP协议版本号、状态码和状态消息三部分组成。例如：HTTP/1.1 200 OK。
• 响应头部(header)：包含服务器返回的一些附加信息，比如内容类型、内容长度、服务器信息等。
• 空行：用来分隔响应头部和响应体。
• 响应体(body)：服务器返回给客户端的具体内容，比如HTML代码、JSON数据等。

//状态行
HTTP/1.1 200 OK 
//响应头
Date: Mon, 27 Jul 2023 12:00:00 GMT 
Content-Type: text/html; charset=UTF-8 Content-Length: 138 
Connection: keep-alive 
//空行//响应体
<html> <head> <title>示例页面</title> </head> <body> <h1>欢迎来到我的示例页面！</h1> </body> </html>

HTTP请求方法

• GET：请求指定的资源，通常用于获取数据，不包含请求体。
• POST：向服务器提交数据，通常用于表单提交，数据在请求体中。
• PUT：用于更新资源，数据也在请求体中。
• DELETE：请求删除指定资源。

get 与post请求区别

GET

作用：从服务器获取资源
参数传递：GET请求的参数一般写在URL中，不安全
参数长度：GET传送的数据量小，小于2KB
编码方式：GET只能进行URL编码
缓存机制：GET请求会被浏览器主动缓存
请求参数会被完整的保存在浏览器
产生的URL可以为保存为书签
时间消耗：GET请求一次产生一个TCP数据包
请求流程：对于GET请求，浏览器会把请求的头部和数据一起发送，服务器响应200
安全幂等：由于GET请求是获取资源，因此GET是安全的，并且因为它不会修改服务器的资源，因此它每次返回的结果是一样的，因此它是幂等的。

POST

作用：向服务器提交资源
参数传递：参数存放在请求体，对数据类型无限制
参数长度：默认不受限制
编码方式：支持多种编码方式
缓存机制：POST不会被浏览器主动缓存
POST的参数不会被保留在历史记录
POST产生的URL不能保存为书签
时间消耗：一次产生两个TCP数据包
请求流程：浏览器会先发送头部，服务器在响应100之后，浏览器才会继续发送请求数据，服务器响应200，返回数据
安全幂等：POST请求向服务器提交资源，会改变服务器的资源，因此不安全，每次POST请求都会改变资源，因此返回的结果不一样，因此不幂等。

HTTP1.0 HTTP1.1 HTTP2.0区别

HTTP/1.0 版本主要增加以下几点：

• 增加了 HEAD、POST 等新方法。
• 增加了响应状态码。
• 引入了头部，即请求头和响应头。
• 在请求中加入了 HTTP 版本号。
• 引入了 Content-Type ，使得传输的数据不再限于文本。
  HTTP/1.1 版本主要增加以下几点：
• 新增了连接管理即 keepalive ，允许持久连接。
• 支持 pipeline，无需等待前面的请求响应，即可发送第二次请求。
• 允许响应数据分块（chunked），即响应的时候不标明Content-Length，客户端就无法断开连接，直到收到服务端的 EOF ，利于传输大文件。
• 新增缓存的控制和管理。
• 加入了 Host 头，用在你一台机子部署了多个主机，然后多个域名解析又是同一个 IP，此时加入了 Host 头就可以判断你到底是要访问哪个主机。

HTTP/2 版本主要增加以下几点：

• 是二进制协议，不再是纯文本。
• 支持一个 TCP 连接发起多请求，移除了 pipeline。
• 利用 HPACK 压缩头部，减少数据传输量。
• 允许服务端主动推送数据。

http 1.0与http 1.1

更新主要是因为 HTTP/1.0 很大的性能问题，就是每请求一个资源都得新建一个 TCP 连接，而且只能串行请求。

http2.0 与http1.1

随着 HTTP/1.1 的发布，互联网也开始了爆发式的增长，这种增长暴露出 HTTP 的不足，主要还是性能问题，而 HTTP/1.1 无动于衷。

http3.0 与http2.0

这 HTTP/2 还没捂热， HTTP/3 怎么就来了？
这次又是 Google，它自己突破自己，主要也是源自于痛点，这次的痛点来自于 HTTP 依赖的 TCP。

HTTP 2.0 与HTTP3.0区别

基于的传输层协议不同：

• HTTP/2：基于 TCP，使用二进制分帧层（Binary Framing Layer）实现多路复用。
• HTTP/3：基于 UDP，使用 QUIC 协议（Quick UDP Internet Connections），提供类似TCP 的可靠性和多路复用。
  2） 性能和可靠性区别：
• HTTP/2：解决了HTTP/1.x中的队头阻塞问题，但仍然受制于TCP的队头阻塞，尤其在高延迟或丢包情况下。
• HTTP/3：通过 QUIC 协议，避免了 TCP 队头阻塞，即使在网络不稳定的情况下也能提供更好的性能。
  3）从安全性角度来看：
• HTTP/2：可以使用 TLS 加密（HTTPS），但加密并非强制要求。
• HTTP/3：默认使用 QUIC 自带的 TLS 1.3加密，安全性更高，且加密是强制的。
  4） 从连接建立速度：
• HTTP/2：需要 TCP 三次握手和 TLS 握手，连接建立相对较慢。
• HTTP/3：QUIC 集成了连接建立和加密握手，连接建立速度更快，尤其在初次连接时。

quic

QUIC（Quick UDP Internet Connections）是一种由 Google 开发的基于 UDP 的传输层协议，旨在改进 HTTP/2 的性能。QUIC 的设计目标是减少连接延迟，提高传输效率和安全性。

HTTP与HTTPS的区别

1）数据传输安全性：

• HTTP：数据以明文传输，容易被窃听、篡改。
• HTTPS：通过 SSL/TLS 协议对数据进行加密传输，提供数据机密性和完整性保障。
  2）端口号：
• HTTP：默认使用端口 80。
• HTTPS：默认使用端口 443。
  3）性能：
• HTTP：无加密过程，连接建立速度稍快。
• HTTPS：基于 HTTP上又加了 SSL（Secure Sockets Layer）或 TLS（Transport Layer Security） 协议来实现的加密传输,加解密过程增加了计算开销，握手时间较长，但现代硬件和协议优化已使性能差距减小。
  4）SEO 影响：
• HTTP：搜索引擎一般会降低未加密站点的排名。
• HTTPS：搜索引擎更倾向于优先展示 HTTPS 网站。

https相较于http在三次握手之后还需要进行SSL/TLS 的握手过程，才可进入加密报文传输。

https 工作原理

HTTPS 的原理在 HTTP 的基础上加入了 SSL/TLS 协议，使通信加密：

1. 握手阶段：
   1）客户端发起 HTTPS 请求后，先与服务器进行 SSL/TLS 握手。
   2）服务器返回 SSL/TLS 证书，客户端验证证书的合法性。
   3）若证书通过验证，客户端将生成一个对称加密的密钥，并使用服务器的公钥加密这个密钥，发送给服务器。
   4）服务器用自己的私钥解密出对称加密密钥，此时，客户端和服务器都持有相同的对称密钥。
2. 数据传输阶段：
   • 客户端和服务器使用生成的会话密钥对传输的数据进行加密和解密。
   • 所有传输的数据（如HTTP请求和响应）都通过加密通道进行，确保数据在传输过程中保持机密性和完整性。

强制缓存 与协商缓存

对于重复的http请求,每次请求得到的数据一样,
便可把缓存响应的数据到本地

http缓存方式分为强制缓存与协商缓存

强制缓存

浏览器判断缓存是否过期,决定是否使用缓存的主动权在浏览器
利用响应头部字段实现,表示资源在客户端缓存的有效期
Cache-Control 相对时间(优先级高)
Expires 绝对时间

协商缓存

通过服务端告知是否可以使用本地缓存
当本地资源过期,访问服务端,服务端判断数据是否变化,没有变化,就返回304状态码,客户端从本地缓存中加载资源否则就更新资源

TCP与UDP的区别

TCP 提供了可靠、面向连接的传输，适用于需要数据完整性和顺序的场景；UDP 则提供了更轻量、面向报文的传输，适用于实时性要求高的场景。

主要可以从以下五个方面来看待它们的不同：

1）连接性：

• TCP：面向连接的协议。通信前需要建立连接（三次握手），通信结束后需要断开连接（四次挥手）。
• UDP：无连接的协议。不需要建立连接，直接发送数据包。

2）可靠性：

• TCP：可靠传输协议。通过确认机制、重传机制、序列号、流量控制和拥塞控制确保数据不丢失、不重复、按顺序到达。
• UDP：不可靠传输协议。不提供确认和重传机制，数据包可能丢失、重复或乱序。

3）数据传输方式：

• TCP：面向字节流的协议。数据作为一个连续的流传输，可以按需分片和重组。
• UDP：面向报文的协议。数据作为独立的报文（数据包）传输，保留了应用层的消息边界。

4）性能：

• TCP：由于需要连接建立、确认和重传机制，传输速度相对较慢，但提供了可靠性。
• UDP：传输速度快，因为没有连接建立和维护的开销，也没有确认和重传机制。

5）应用场景：

• TCP：适用于需要可靠传输的应用，如网页浏览（HTTP/HTTPS）、文件传输（FTP）、电子邮件（SMTP/IMAP）等。
• UDP：适用于对速度要求高但对可靠性要求不高的应用，如视频直播、在线游戏、DNS 查询等。

TCP 如何确保可靠性

TCP（传输控制协议）是一种基于连接的、可靠性强的传输层协议，它通过一系列机制来确保数据的可靠传输。以下是TCP确保可靠性的几个关键机制：

1. 字节流传输与序列号：

   • TCP采用字节流传输的方式，将应用层发送的数据划分成以字节为单位的报文段（Segment），并进行序列号标记。
   • 每个报文段都包含一个序列号，用于标识该报文段在数据流中的位置。这样，接收方就能按序重组数据，确保数据的完整性。

2. 确认重传机制：

   • TCP使用确认应答（ACK）机制来确认数据的成功接收。
   • 接收方在收到报文段后，会发送一个ACK报文，其中包含下一个期望接收的报文段的序列号。
   • 如果发送方在一定时间内没有收到ACK，则认为该报文段可能丢失，会重新发送该报文段。

3. 超时重传与快速重传：

   • 超时重传：发送方在发送报文段后设置一个定时器（RTO，重传超时时间）。如果定时器超时仍未收到ACK，则重传该报文段。
   • 快速重传：如果接收方收到一个失序的报文段（即序列号不连续），它会立即发送一个重复的ACK。当发送方连续收到三个相同的重复ACK时，会立即重传相应的报文段，而无需等待超时定时器到期。

4. 滑动窗口机制：

   • TCP利用滑动窗口机制实现流量控制和拥塞控制。
   • 发送方和接收方都有一个窗口，用于控制数据的发送和接收速率。窗口的大小会根据网络的拥塞状况和接收方的处理能力动态调整。
   • 通过滑动窗口，TCP可以确保发送方不会发送过多的数据导致接收方处理不过来，从而避免数据丢失。

5. 头部校验和：

   • 在TCP传输过程中，每个报文段都会添加一个头部校验和，用于检测数据在传输过程中是否损坏或被篡改。
   • 如果接收方发现校验和不匹配，则会丢弃该报文段，并请求发送方重传。

6. 连接管理机制：

   • TCP使用三次握手建立连接，确保双方都已准备好进行数据传输。
   • 在数据传输完毕后，使用四次挥手断开连接，确保双方都已正确释放资源。

7. 选择性确认重传（SACK）：

   • SACK是一种扩展机制，允许接收方告诉发送方哪些具体的数据包已经收到，哪些还没有收到。
   • 这样，发送方可以只重传那些确实丢失的数据包，而不是重传整个数据流，从而提高了重传效率。

UDP怎么实现可靠运输

就需要在应用层引入额外的机制，以下是一些常见的方法：

1. 确认机制（ACK）：

   • 发送方发送数据后，等待接收方的确认（ACK）。
   • 接收方在接收到数据包后，发送ACK确认包给发送方，表示已经成功接收。
   • 如果在一定时间内没有收到ACK确认包，发送方则重传数据。

2. 序列号：

   • 为每个数据包分配一个唯一的序列号，用于检测丢失和重复的数据包。
   • 接收方可以根据序列号对接收到的数据包进行排序。

3. 超时重传：

   • 发送方设置超时时间，如果在超时时间内没有收到接收方的ACK确认包，则进行重传。
   • 通过调整超时时间可以平衡传输延迟和可靠性。

4. 拥塞控制：

   • 根据网络状况调整发送速率，避免拥塞。
   • 可以通过引入滑动窗口机制来实现流量控制和拥塞控制。

5. 差错检测：

   • 发送方在数据包中包含校验和等信息，用于检测数据包是否出错。
   • 接收方在接收到数据包后，通过计算校验和来检测数据中的错误。
   • 如果发现错误，则要求发送方重传数据包。

6. 纠错码和冗余信息：

   • 发送方可以使用纠错码对数据包进行处理，添加少量的冗余信息来检测和纠正传输过程中的错误。
   • 接收方在接收数据包时，根据纠错码进行纠正。
   • 另外，还可以添加冗余信息（如FEC）来提高数据包的可靠性。

7. 重传机制：

   • 可以采用停等协议、回退重传或选择性重传等方式来实现重传机制。
   • 停等协议中每包数据发送后都需要等到接收端回复再发送下一包数据。
   • 回退重传中发送端会连续发送多个数据包，当其中的数据包丢失时，接收端会回复最大连续收到的数据包，后续再进行数据重传。
   • 选择性重传会针对丢失的包进行补发，而不会全部重传。

三次握手的过程,为什么是三次

TCP的三次握手是建立TCP连接的过程，确保数据的可靠传输。

1. 第一次握手：客户端向服务器发送一个SYN（同步）包，用来发起连接，此时客户端进入SYN_SENT状态，等待服务器确认。这个SYN包中，客户端将标志位SYN置为1，选择一个初始序列号SeqNum，然后将这个包发送给服务器。这个SYN包相当于客户端向服务器发出请求：“我想建立连接，你收到了吗？”
2. 第二次握手：服务器收到SYN包后，回复一个SYN+ACK（同步+确认）包。服务器将标志位SYN和ACK都置为1，确认号ACKnum设置为客户端的初始序列号SeqNum+1，同时选择一个自己的初始序列号SeqNum（我们称之为k），然后将这个SYN+ACK包发送给客户端。此时，服务器进入SYN_RECV状态。这一步是为了确认服务器的接收能力正常，并同时向客户端表示自己也具备发送能力。
3. 第三次握手：客户端收到服务器的SYN+ACK包后，再回复一个ACK（确认）包。客户端将标志位ACK置为1，确认号ACKnum设置为服务器的初始序列号SeqNum（即k）+1，同时将序列号SeqNum设置为自己的初始序列号（在第一次握手时选择的）。然后将这个ACK包发送给服务器。这个包相当于客户端告诉服务器：“我收到你的同意了，我们可以开始传输数据了。”至此，客户端和服务器都进入ESTABLISHED状态，完成三次握手，连接建立成功。

那么，为什么需要三次握手呢？这主要是为了确保双方都能正确地发送和接收数据，都有发送与接收能力

1. 确认双方的发送和接收能力：第一次握手时，客户端发送SYN包给服务器，但此时客户端无法确认服务器是否收到了。通过第二次握手，服务器回复SYN+ACK包，确认了服务器的接收能力，并同时表示自己也具备发送能力。再通过第三次握手，客户端回复ACK包，确认了客户端的接收能力。这样，双方都能确认彼此的发送和接收能力正常。
2. 抵御网络中的重复包：在网络传输过程中，可能会发生丢包或延迟等情况。通过三次握手，可以确保双方都是基于最新、有效的请求来建立连接的，从而抵御网络中的重复包。
3. 对连接进行同步处理：在三次握手过程中，双方都会根据自己的状态机进行状态转换。只有经过三次握手，双方才能确认彼此的工作状态，保证接下来的数据传输是可靠的。

综上所述，TCP的三次握手过程是为了确保双方都能正确地发送和接收数据，从而建立可靠的连接。

四次挥手的过程,为什么是四次

TCP四次挥手的过程

TCP的四次挥手过程用于断开一个已经建立的连接，确保双方都能正确地释放资源。具体过程如下：

1. 第一次挥手：客户端（或主动关闭方）向服务器（或被动关闭方）发送一个FIN报文段，表示客户端想要关闭连接。此时，客户端进入FIN_WAIT_1状态。
2. 第二次挥手：服务器收到客户端的FIN报文段后，发送一个ACK报文段作为确认，表示已经收到客户端的关闭请求。此时，服务器进入CLOSE_WAIT状态，等待自己这边的数据传输完毕。
3. 第三次挥手：当服务器确认自己这边的数据传输已经完毕后，它也会向客户端发送一个FIN报文段，表示服务器也想要关闭连接。此时，服务器进入LAST_ACK状态。
4. 第四次挥手：客户端收到服务器的FIN报文段后，发送一个ACK报文段作为确认，表示已经收到服务器的关闭请求。此时，客户端会等待一段时间（通常是2MSL，即报文段最大生存时间的两倍），以确保服务器收到了这个ACK报文段。之后，客户端和服务器都进入CLOSED状态，连接正式关闭。

为什么需要四次挥手

TCP连接是全双工的，这意味着数据可以在两个方向上同时传输。因此，在关闭连接时，每个方向上的数据传输都需要被独立地关闭。这就是为什么需要四次挥手的原因：

1. 确保数据传输的完整性：通过四次挥手，双方都能确保自己这边的数据传输已经完毕，并且对方已经收到了关闭请求。这避免了在连接关闭后还有未传输完毕的数据。
2. 防止旧数据包的干扰：在连接关闭过程中，可能会存在一些延迟的数据包在网络中。通过四次挥手中的TIME_WAIT状态（即客户端在发送最后一个ACK报文段后等待2MSL的时间），可以确保这些延迟的数据包不会干扰到已经关闭的连接。
3. 释放资源：四次挥手过程还负责适当地释放在建立连接时分配的资源，如端口号、内存缓冲区等。这有助于确保系统的稳定性和性能。

综上所述，TCP的四次挥手过程是为了确保双方都能正确地关闭连接，并释放相关资源。

http 的keep-Alive 是什么,tcp的keep-alive和http的是一个东西吗

HTTP的Keep-Alive

HTTP的Keep-Alive，也称为HTTP持久连接或HTTP连接复用，是HTTP协议中的一种机制。
它的主要作用是在短时间内复用同一个TCP连接来发送和接收多个HTTP请求/响应，而不是为每一个新的请求/响应打开新的连接。
这样做的好处是减少了建立和关闭TCP连接所带来的开销，提高了HTTP通信的效率。

在HTTP/1.0中，Keep-Alive并不是默认开启的，需要客户端在请求头中通过设置“Connection: Keep-Alive”来显式地请求使用持久连接。而在HTTP/1.1中，Keep-Alive已经成为了默认的行为，除非在请求头或响应头中设置了“Connection: close”，否则连接将被视为持久连接。

持久连接的超时时间通常由服务器决定，客户端可以在请求头中通过“Keep-Alive: timeout=N”来建议一个超时时间，但服务器可能会忽略这个建议。在超时时间到达之前，如果客户端没有发送新的请求，服务器可能会主动关闭连接。

TCP的keep-alive

TCP的keep-alive是TCP协议中的一种保活机制，用于检测长时间没有数据传输的连接是否仍然存活。
它的实现是由TCP层（传输层、内核态）负责的，而不是由应用层（如HTTP）负责的。

当TCP连接的两端长时间没有数据传输时（通常默认配置是2小时，但这个时间可以根据需要进行调整），TCP层会发送keep-alive探针（即探测报文）来检测连接是否仍然存活。如果连接仍然存活，对端会回复一个ACK报文，此时keep-alive定时器会被重置，连接继续保持。如果连续多个keep-alive探针都没有得到回应，TCP层会认为连接已经失效，并关闭该连接。

需要注意的是，TCP的keep-alive并不是默认开启的，需要应用程序在创建TCP连接时通过socket接口设置SO_KEEPALIVE选项来显式地启用它。此外，TCP的keep-alive只能检测连接是否存活，而不能检测连接是否可用（例如，某一方发生了死锁，无法在连接上进行任何读写操作，但操作系统仍然可以响应网络层的keep-alive包）。

区别总结

1. 层面不同：HTTP的Keep-Alive是由应用层（用户态）实现的，而TCP的keep-alive是由TCP层（传输层、内核态）实现的。
2. 作用不同：HTTP的Keep-Alive用于复用TCP连接来发送和接收多个HTTP请求/响应，减少建立和关闭TCP连接的开销。而TCP的keep-alive用于检测长时间没有数据传输的连接是否仍然存活。
3. 默认状态不同：在HTTP/1.1中，Keep-Alive是默认开启的；而在TCP中，keep-alive默认是关闭的，需要应用程序显式地启用它。

dns查询过程

DNS查询过程

DNS（Domain Name System，域名系统）是一个将域名和IP地址相互映射的分布式数据库，
能够使人更方便地访问互联网，而不需要记住能够被计算机直接读取的IP数串。
DNS查询过程主要可以分为以下几个步骤：

1. 查询浏览器DNS缓存：
   • 当用户在浏览器中输入一个域名时，浏览器会首先检查自己的DNS缓存中是否已经存储了该域名的IP地址。
   • 如果缓存中有该域名的IP地址，则浏览器会直接使用该IP地址进行访问，无需进行后续的DNS查询。
   • 浏览器的DNS缓存时间通常较短，例如Chrome浏览器对每个域名会默认缓存60秒。
2. 查询操作系统DNS缓存：
   • 如果浏览器DNS缓存中没有找到该域名的IP地址，则浏览器会向操作系统发起DNS查询请求。
   • 操作系统也会检查自己的DNS缓存，如果缓存中有该域名的IP地址，则直接返回给浏览器。
3. 查询本地Host文件：
   • 如果操作系统DNS缓存中也没有找到该域名的IP地址，则系统会检查本地Host文件。
   • Host文件是一个静态的域名解析文件，用于将特定的域名映射到指定的IP地址。
   • 如果Host文件中存在该域名的映射关系，则系统会使用该IP地址进行访问。
4. 查询本地DNS服务器：
   • 如果以上步骤都没有找到该域名的IP地址，则系统会向本地DNS服务器发起查询请求。
   • 本地DNS服务器是一个递归DNS服务器，它会代表客户端向其他DNS服务器发起查询请求，直到找到该域名的IP地址。
   • 本地DNS服务器会首先查询自己的缓存，如果缓存中有该域名的IP地址，则直接返回给客户端。
   • 如果缓存中没有该域名的IP地址，则本地DNS服务器会向根域名服务器发起查询请求。
5. 迭代查询上级域名服务器：
   • 根域名服务器会告诉本地DNS服务器顶级域名（如.com、.org等）服务器的位置。
   • 本地DNS服务器再向顶级域名服务器发起查询请求，顶级域名服务器会告诉本地DNS服务器权威域名服务器的地址。
   • 本地DNS服务器再向权威域名服务器发起查询请求，权威域名服务器会查询并将对应的IP地址返回给本地DNS服务器。
6. 返回IP地址给客户端：
   • 本地DNS服务器缓存该域名与对应IP地址的映射关系，并将IP地址返回给客户端。
   • 客户端（浏览器）收到IP地址后，就可以根据该IP地址访问对应的服务器了。

注意事项

• DNS查询过程中涉及的各个缓存（浏览器缓存、操作系统缓存、本地DNS服务器缓存）都有助于提高DNS查询的效率，减少查询时间。
• DNS查询的结果可能会受到TTL（Time To Live，生存时间）的影响。TTL是DNS记录中设置的一个值，表示该记录被缓存的时间。在TTL到期之前，即使DNS记录发生变化，缓存中的记录也不会被更新。

cdn是什么,为什么cdn查询比较快

CDN是什么

CDN（Content Delivery Network）是一个由多个地理位置分散的服务器节点组成的分布式网络架构，用于加速互联网内容的分发。

当用户请求内容时，CDN 会根据用户的地理位置，将请求转发到最近的缓存服务器上。这样可以减少数据传输的延迟，提高用户访问速度，同时减轻源服务器的负载。

CDN 通常用于加速静态内容（如图片、视频、静态页面等）的访问，提高网站的性能和用户体验。

CDN 的工作原理可以简略分为以下几步：
1）内容缓存：CDN 在多个地理位置分布的服务器节点上缓存网站的静态资源（如图片、视频、JS 文件等）。这些节点成为 “边缘服务器”。
2）用户请求重定向：当用户请求某个内容时，CDN 利用 DNS 重定向的方式，将用户的请求引导到距离用户最近的、具有该内容缓存的边缘服务器。
3）内容传输：边缘服务器响应用户请求，传输缓存内容给用户，大大减少了传输延迟和带宽消耗。

CDN查询为什么比较快

CDN查询之所以比较快，主要得益于以下几个关键因素：

1. 分布式缓存：CDN通过在全球范围内部署大量的缓存服务器，将网站的内容分发到最接近用户的网络边缘节点上。当用户访问网站时，可以直接从最近的缓存节点上获取内容，而无需回源站获取，从而大大减少了网络延迟和带宽消耗。
2. 智能调度：CDN的智能调度系统会根据用户的地理位置、网络状况以及各节点的负载情况等因素，动态地选择最优的节点来响应用户的请求。这种智能调度机制确保了用户能够始终获得最快的访问速度。
3. 缓存更新策略：CDN的缓存服务器会定期从源站更新内容，以确保用户能够获取到最新的信息。同时，CDN还会根据内容的访问频率和更新周期等因素，制定合理的缓存过期时间和替换算法，以提高缓存命中率和减少回源请求的次数。
4. 负载均衡：CDN的负载均衡设备会实时监控各节点的负载情况，并根据需要动态地调整各节点的负载分配。这种负载均衡机制确保了每个节点都能够高效地处理用户的请求，避免了单点过载和瓶颈问题。

谈一谈你理解的websocket

WebSocket是什么

WebSocket是一种在单个TCP连接上进行全双工通信的协议。
在传统的Web应用中，客户端与服务器之间的通信通常基于HTTP请求/响应模型，这种模型在每次通信时都需要建立连接、发送请求、接收响应，然后关闭连接，这种通信方式对于实时性要求较高的应用来说显得效率低下。而WebSocket则提供了一种更加高效的通信方式，它允许服务器主动向客户端推送数据，而无需客户端每次都发送请求。

WebSocket的通信过程大致如下：首先，客户端通过HTTP请求与服务器进行握手，建立一个WebSocket连接；然后，双方就可以通过这个连接进行双向通信，直到一方主动关闭连接。这种通信方式极大地简化了客户端与服务器之间的交互，提高了通信效率。

在前端开发中，WebSocket的应用非常广泛，比如实时聊天应用、在线游戏、实时数据推送等场景，都离不开WebSocket的支持。它使得客户端能够实时地接收到服务器的数据更新，从而提供更加流畅和丰富的用户体验。

WebSocket的工作原理

WebSocket的工作原理可以分为握手阶段和通信阶段：

1. 握手阶段：
   • 客户端发起一个HTTP请求，请求升级到WebSocket协议。这个请求包含了一些特殊的头信息，表明客户端希望建立WebSocket连接。
   • 服务器收到这个请求后，会检查是否支持WebSocket协议。如果支持，服务器将回复一个HTTP 101状态码，表示成功升级到WebSocket协议。此时，客户端和服务器之间的连接就变成了全双工连接，可以双向通信。
2. 通信阶段：
   • 一旦WebSocket连接建立，客户端和服务器就可以互相发送消息。这些消息都是以帧（frames）的形式进行传输，而不是传统的HTTP请求和响应。
   • 服务器可以主动向客户端推送消息，而客户端也可以主动向服务器发送消息。这种双向通信在实时性要求高的应用中非常有用。

WebSocket的优点

1. 实时性：WebSocket能够实时地双向通信，服务器可以主动推送数据到客户端，而不需要客户端发送请求。
2. 减少网络流量：相比于传统的HTTP请求响应模式，WebSocket连接只需要进行一次握手，之后就可以保持长连接，减少了网络流量和延迟。
3. 较少的开销：WebSocket使用较少的开销来维持连接，因为在连接建立后，客户端和服务器之间的通信只需要少量的头信息。
4. 跨平台支持：WebSocket协议可以在多种平台上使用，包括桌面应用、移动应用和Web应用。

WebSocket的应用场景

1. 实时聊天：WebSocket可以用于实现即时通讯，如在线聊天室、多人游戏等。通过WebSocket，客户端和服务器可以实时地发送和接收消息。
2. 实时数据更新：WebSocket可以用于实时地推送数据更新，如实时股票行情、实时天气预报等。服务器可以实时地将最新的数据推送给客户端。
3. 协同编辑：WebSocket可以用于实现多人协同编辑，如在线文档协作、团队代码编辑等。多个用户可以同时编辑同一个文档或代码文件，他们的编辑结果会实时地同步到其他用户的界面上。
4. 实时监控：WebSocket可以用于实时监控系统，如监控设备的运行状态、实时监测交通流量等。服务器可以实时地将监控数据推送给客户端。