既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
server server1.example.com;
server server2.example.com;
}
4. **最少连接（Least Connections）**：`Nginx`会将新的请求路由到当前连接数最少的后端服务器，以平衡服务器的负载。
upstream backend {
least_conn;
server server1.example.com;
server server2.example.com;
}
5. **基于响应时间的负载均衡**：`Nginx`可以根据后端服务器的响应时间来分配请求。它会优先选择响应时间较短的服务器。
upstream backend {
least_time first_byte;
server server1.example.com;
server server2.example.com;
}
6. **备用服务器（Backup Servers）**：可以指定一个或多个备用服务器，当所有主要服务器都不可用时，请求将被路由到备用服务器。
upstream backend {
server server1.example.com;
server server2.example.com backup;
}
### 1.8 Nginx如何配置长连接
1. **HTTP块配置**：首先，需要在Nginx配置中找到或创建一个`HTTP`块。在这个块内部，可以配置全局的HTTP选项。
http {
keepalive_timeout 120s;
keepalive_requests 10000;
}
* **keepalive\_timeout**：`HTTP`连接的最大空闲时间（以秒为单位）。在超过这个时间后，连接将被关闭，为0的时候禁用长连接。
* **keepalive\_requests**：设置一个客户端可以在单个连接上发送的最大请求数。设置它有助于防止单个连接过度使用资源。当达到最大请求数目且所有已有请求结束后，连接被关闭，默认值为100。
2. **配置Server块**：在`Nginx`配置中，找到或创建一个`Server`块，通常是用于特定虚拟主机或站点的配置。在该块内，可以进一步配置长连接相关的选项。
server {
listen 80;
server_name example.com;
# 其他服务器配置
location / {
# 配置代理或处理长连接的方式
}
}
3. **处理长连接方式**：根据需求，可以在`location`块内配置`Nginx`来处理长连接。例如，如果要代理`WebSocket`连接，可以使用以下配置：
location /websocket {
proxy_pass http://backend-server;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “upgrade”;
}
这个示例配置了`Nginx`以代理`WebSocket`请求，并通过`proxy_set_header`指令设置升级头部，以确保`WebSocket`连接正常工作。
4. **测试配置**：在完成配置后，确保使用`nginx -t`命令检查配置文件的语法是否正确。如果一切正常，请使用`nginx -s reload`重新加载`Nginx`以应用新配置。
## 2 HTTP
### 2.1 HTTP里有哪些常见的请求方法？
1. **GET**：用于请求服务器发送特定资源（通常是网页或文件）。`GET`请求是幂等的，它只是从服务器获取信息，不应该对服务器状态产生影响。
2. **POST**：用于向服务器提交数据，通常用于提交表单数据或执行对服务器状态产生影响的操作。`POST`请求不幂等，因为它可能会修改服务器上的数据。
3. **PUT**：用于请求服务器存储一个资源，通常用于更新或创建资源。`PUT`请求是幂等的，多次相同的`PUT`请求应该具有相同的结果。
4. **DELETE**：用于请求服务器删除指定的资源。`DELETE`请求是幂等的，多次相同的`DELETE`请求应该具有相同的结果。
5. **HEAD**：类似于`GET`请求，但不返回响应正文。它用于获取与`GET`请求相同的响应头信息，但不获取响应正文，通常用于检查资源的元数据或确认资源是否存在。
6. **OPTIONS**：用于请求服务器提供有关资源的通信选项，例如支持的请求方法、允许的来源等信息。它用于`CORS`（跨域资源共享）和预检请求。
7. **PATCH**：用于部分更新资源，通常用于更新资源的一部分而不是整个资源。`PATCH`请求是幂等的，多次相同的`PATCH`请求应该具有相同的结果。
8. **TRACE**：用于在调试和诊断中回显服务器接收到的请求，通常不常用，并且可能会存在安全风险。
9. **CONNECT**：用于在客户端和服务器之间建立网络连接，通常用于代理服务器。它用于将客户端连接到目标服务器。
### 2.2 HTTP的长连接和短连接有什么区别
参考1：[http的长连接和短连接的区别]( )
**长连接与短连接介绍**
1. **长连接**：客户端与服务端先建立连接，连接建立后不断开，以便在一段时间内进行多次请求和响应。这减少了`TCP`连接的建立和关闭的开销。
2. **短连接**：客户端与服务端每个HTTP请求都会建立一个新的`TCP`连接，并在请求完成后立即关闭连接。
**长连接与短连接的操作过程**
1. **长连接的操作步骤是**：建立连接——数据传输…（保持连接）…数据传输——关闭连接。
2. **短连接的操作步骤是**：建立连接——数据传输——关闭连接…建立连接——数据传输——关闭连接。
**长连接与短连接的使用时机**
1. **长连接**：长连接多用于操作频繁，点对点的通讯，而且连接数不能太多的情况。每个`TCP`连接的建立都需要三次握手，每个`TCP`连接的断开要四次握手。
如果每次操作都要建立连接然后再操作的话处理速度会降低，所以每次操作下次操作时直接发送数据就可以了，不用再建立`TCP`连接。
适用于客户端和服务端通信频繁的场景，例如聊天室，实时游戏，数据库的连接用长连接，如果用短连接频繁的通信会造成`socket`错误，频繁的`socket`创建也是对资源的浪费。
2. **短连接**：适用于一次性请求和响应的情况，例如普通的网页浏览，其中每个资源都是单独请求的。
### 2.3 HTTP的状态码，504有遇到过吗
**1xx - 信息性状态码：**
1. **100 Continue（继续）**：客户端可以继续发送请求。通常用于客户端发送带有大型请求体的`POST`请求，服务器在接收一部分后发送此状态码以通知客户端继续发送。
2. **101 Switching Protocols （切换协议）**：服务器已经理解客户端的请求，将切换到不同的协议，如`WebSocket`。
**2xx - 成功状态码：**
1. **200 OK（成功）**：服务器已成功处理了请求。
2. **201 Created（已创建）**：请求成功并且服务器创建了新的资源。
3. **202（已接受）**：服务器已接受请求，但尚未处理。
4. **204 No Content（无内容）**：服务器成功处理了请求，但没有返回任何内容。一般在只需要从客户端往服务器发送信息，而对客户端不需要发送新信息内容的情况下使用。
**3xx - 重定向状态码：**
1. **301 Moved Permanently（永久移动）**：资源被永久性移动到了新的`URL`。客户端应该使用新的`URL`重新请求。
2. **302 Found（临时移动）**：资源被临时性移动到了新的`URL`。客户端应该使用新的`URL`重新请求。
**4xx - 客户端错误状态码：**
1. **400 Bad Request（错误请求)**：服务器端无法理解客户端发送的请求，请求报文中可能存在语法错误。
2. **401 Unauthorized(未授权)** ：需要身份验证才能访问资源。
3. **403 Forbidden（禁止)**： 服务器拒绝了请求，通常由于权限问题。
4. **404 Not Found（未找到)**：请求的资源不存在。
5. **405（方法禁用)** ：禁用请求中指定的方法。
**5xx - 服务器错误状态码：**
1. **500 Internal Server Error（服务器内部错误）**： 服务器在处理请求时发生了内部错误。
2. **502 Bad Gateway**：服务器作为网关或代理服务器时，从上游服务器接收到无效的响应。
3. **503（服务不可用）**：服务器当前无法处理请求，通常由于过载或维护。
4. **504 Gateway Timeout（网关超时）**：服务器作为网关或代理，但是没有及时从上游服务器收到请求。
5. **505（HTTP 版本不受支持）**：服务器不支持请求中所用的HTTP协议版本。
### 2.4 GET和POST的区别
1. **数据传输方式**
* **GET**：`GET`请求将数据附加在`URL`的末尾，以查询字符串的形式发送。数据以键值对的形式出现在`URL`中，使用?分隔参数，使用&分隔多个参数。由于数据在`URL`中可见，`GET`请求不适合传输敏感信息。
* **POST**：`POST`请求将数据包含在请求的正文中，而不是在URL中。因此，`POST`请求对于传输敏感信息更安全，因为数据不会在`URL`中可见。`POST`请求通常用于提交表单数据、上传文件等情况。
2. **请求长度**
* **GET**：由于数据附加在`URL`上，`GET`请求对于发送的数据长度有限制，通常在2048个字符左右，这取决于浏览器和服务器的配置。因此，GET请求适合用于发送较小的数据。
* **POST**：`POST`请求没有特定的长度限制，可以用于发送较大的数据，例如上传文件或包含大量文本的表单。
3. **可见性**
* **GET**：由于`GET`请求中的数据出现在`URL`中，因此数据是可见的，容易被用户和浏览器记录。这使得`GET`请求适合用于书签、历史记录等场景。
* **POST**：`POST`请求中的数据在请求正文中，不会显示在`URL`中，因此更适合用于传输敏感数据，但不能像`GET`请求那样轻松地进行书签和共享。
4. **缓存**
* **GET**：由于`GET`请求是幂等的，可以被浏览器和代理服务器缓存，以提高性能。
* **POST**：`POST`请求通常不会被缓存，因为它们可能会导致服务器状态的变化。
5. **请求幂等性**
* **GET**：`GET`请求是幂等的，多次发送相同的`GET`请求应该产生相同的结果，而不会对服务器状态产生影响。它通常用于获取资源或执行只读操作。
* **POST**：`POST`请求通常不是幂等的，多次发送相同的`POST`请求可能会对服务器状态产生不同的影响，因为它通常用于提交数据或执行会修改服务器状态的操作。
### 2.5 什么是无状态协议，HTTP是无状态协议吗，怎么解决
无状态协议（Stateless Protocol）是指协议在处理请求时不会记住之前的`请求`或`会话信息`，每个请求都是独立的，服务器不会保存客户端的状态信息。
`HTTP`是一种无状态协议，每个`HTTP`请求都是相互独立的，服务器不会记住之前的请求或会话信息。这意味着服务器无法直接识别多个请求之间的关联，每个请求都需要提供足够的信息来说明其意图。
**为了解决`HTTP`的无状态性，通常使用以下方法：**
1. **Cookies**：`Cookies`是一种在客户端和服务器之间存储状态信息的机制。服务器可以在响应中设置一个`Cookie`，客户端将它保存并在后续的请求中发送回服务器。这允许服务器跟踪客户端的会话信息，例如用户的登录状态或购物车内容。
2. **会话管理**：服务器可以为每个客户端创建一个唯一的会话标识符（`Session ID`），并在客户端的请求中包含该标识符。服务器可以使用会话标识符来关联多个请求，从而跟踪用户的会话状态。
3. **URL参数**：在`URL`中包含参数来传递状态信息。这通常用于在`Web`应用程序中实现`RESTful API`，但不适合敏感信息，因为参数在URL中可见。
4. **隐藏表单字段**：在`HTML`表单中添加隐藏字段来传递状态信息。这通常用于`Web`应用程序，以便在不使用`Cookies`的情况下维护会话状态。
5. **URL重写**：一些`Web`框架和服务器可以通过URL重写来隐藏会话标识符，以改善安全性和可用性。
6. **JWT（JSON Web Tokens）**：`JWT`是一种用于在客户端和服务器之间传递可验证的信息的标准。它可以包含有关用户身份和状态的信息，并由服务器签名以确保数据的完整性和安全性。
### 2.6 HTTP请求的组成
参考1：[Http协议的组成]( )
1. **请求行（Request Line）：请求行是HTTP请求的第一行，包含了以下三个要素：**
* **请求方法（HTTP Method）**：指定客户端的动作或操作类型，比如`GET`、`POST`、`PUT`、`DELETE`等。
* **请求的资源路径（Request URI）**：指定要请求的资源的路径，通常是相对于服务器的根目录的路径，例如`/index.html`。
* **协议版本（HTTP Version）**：指定使用的`HTTP`协议版本，例如`HTTP/1.1`。
2. **请求头部（Request Headers）**：请求头部包含了一系列的元数据，用于提供请求的相关信息，例如：
* **Host**：指定目标服务器的主机名和端口号。
* **User-Agent**：指定发起请求的用户代理，通常是浏览器信息。
* **Accept**：指定可接受的响应内容类型。
* **Content-Type**：指定请求正文（如果有的话）的`MIME`类型。
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8
3. **空行（Blank Line）**：请求行和请求头部之间必须有一个空行，用于分隔头部信息和请求正文。
4. **请求正文（Request Body）**：请求正文是可选的，通常用于包含客户端向服务器发送的数据，例如表单数据或请求主体。请求正文的存在和格式取决于请求的方法和目的。
当请求方式是`POST`时，请求体会有请求参数格式如下：
username=zhangsan&password=123
当请求方式时`GET`时，请求参数是不会出现在请求体中，会拼接在`URL`地址后面：
http://localhost:8080…？username=zhangsan&password=123
### 2.7 HTTP响应的组成
1. **状态行（Status Line）：状态行是`HTTP`响应的第一行，包含了以下三个要素：**
* **协议版本（HTTP Version）**：指定使用的`HTTP`协议版本，例如`HTTP/1.1`。
* **状态码（Status Code）**：指定了响应的处理结果，是一个三位数的数字，例如200表示成功，404表示资源未找到。
* **状态消息（Status Message）**：与状态码相关的人类可读的描述，用于提供关于状态码的更多信息。
2. **响应头部（Response Headers）：响应头部包含了一系列的元数据，用于提供响应的相关信息，例如：**
* **Content-Type**：指定响应正文的`MIME`类型，告诉客户端如何解析响应的内容。
* **Content-Length**：指定响应正文的长度（字节数）。
* **Server**：指定响应的服务器信息。
* **Date**：指定响应生成的日期和时间。
* **其他自定义或标准头部字段**。
Content-Type: text/html; charset=utf-8
Content-Length: 12345
Server: Apache/2.4.41 (Ubuntu)
Date: Thu, 01 Sep 2023 12:00:00 GMT
3. **空行（Blank Line）**：状态行和响应头部之间必须有一个空行，用于分隔头部信息和响应正文。
4. **响应正文（Response Body）**：响应正文包含了服务器返回给客户端的实际数据。它的内容和格式取决于响应的性质，例如在`HTML`页面请求中，响应正文通常包含`HTML`文档；在文件下载请求中，响应正文包含文件内容。
例如：
Hello, World!
### 2.8 Cookies机制和Session机制的区别
`Cookies`机制和`Session`机制都是用于在`Web`应用程序中跟踪用户状态和维护会话信息的方式，但它们在实现和工作原理上有一些重要的区别：
1. **存储位置**
* **Cookies**：`Cookies`是在客户端（通常是浏览器）中存储的小型文本文件。服务器在响应中设置`Cookies`，然后浏览器将它们存储在客户端的文件系统中。每次请求都会将`Cookies`发送回服务器，以便服务器可以读取和修改它们。
* **Session**：`Session`数据通常存储在服务器上。服务器为每个会话创建一个唯一的标识符（通常是`会话ID`），并将此标识符存储在`Cookies`中或通过`URL`参数传递给客户端。然后，服务器使用这个标识符来查找和维护与客户端会话相关的数据。
2. **数据存储**
* **Cookies**：`Cookies`可以存储在客户端的浏览器中，但由于安全性和隐私考虑，通常只存储一些小型的标识符或少量的非敏感数据。`Cookies`通常有大小限制（通常是几`KB`）。
* **Session**：`Session`数据存储在服务器上，可以存储大量的数据，包括敏感信息。服务器根据`会话ID`来关联客户端的数据，因此客户端无法直接访问或修改会话数据。
3. **生命周期**
* **Cookies**：`Cookies`可以具有不同的生命周期。它们可以是会话`Cookies`，只在浏览器会话期间存在，或者可以设置为持久`Cookies`，可以在指定的时间段内存在。
* **Session**：`Session`数据通常与用户会话相关联，一旦会话结束，通常会话数据也会被销毁。会话的生命周期通常由服务器管理，可以在服务器上配置。
4. **安全性**
* **Cookies**：`Cookies`可以存储在客户端，因此可能会受到一些安全威胁，例如跨站脚本攻击（`XSS`）或跨站请求伪造攻击（`CSRF`）。为了增加安全性，`Cookies`可以标记为`HTTP Only`，以防止`JavaScript`访问它们。
* **Session**：`Session`数据通常存储在服务器上，客户端无法直接访问或修改它们，因此通常比`Cookies`更安全。
5. **性能**
* **Cookies**：`Cookies`需要在每个`HTTP`请求中发送到服务器，这可能会增加网络流量。同时，浏览器会将`Cookies`附加到每个请求中，可能会导致一些额外的开销。
* **Session**：`Session`数据存储在服务器上，不需要在每个请求中发送，因此通常不会增加网络流量，但可能会占用服务器资源，特别是在大规模应用程序中。
选择`Cookies`还是`Session`取决于应用程序的需求和安全性考虑。通常，`Cookies`用于存储较小且不敏感的数据，而`Session`用于存储更大和敏感的数据。在实际应用中，它们经常一起使用，例如，使用`Cookies`存储`会话ID`，然后使用`会话ID`关联服务器上的`Session`数据。
### 2.9 RPC和HTTP的区别
`RPC`（Remote Procedure Call，远程过程调用）和`HTTP`（Hypertext Transfer Protocol，超文本传输协议）都是用于不同系统之间通信的协议，但它们在工作方式和应用领域上有一些重要的区别：
1. **通信模型**
* **RPC**：`RPC`是一种远程通信协议，用于不同计算机或进程之间的函数调用。它允许一个程序在另一个程序上调用函数，就像本地函数一样，而不需要直接管理底层通信细节。`RPC`通常用于跨越网络的分布式应用程序。
* **HTTP**：`HTTP`是一种应用层协议，用于在客户端和服务器之间传输超文本文档和其他资源。`HTTP`通常用于`Web`应用程序中，它的主要目标是在浏览器和服务器之间传递`HTML`页面、图像、样式表和其他`Web`资源。
2. **数据格式**
* **RPC**：`RPC`协议可以使用多种数据格式，如`XML-RPC`、`JSON-RPC`、`Protocol Buffers`等，用于序列化和反序列化函数参数和返回值。
* **HTTP**：`HTTP`主要使用文本或二进制格式来传输数据。通常，`HTTP`使用`HTML`、`XML`、`JSON`等格式来表示资源。
3. **通信方式**
* **RPC**：`RPC`通常采用请求-响应方式进行通信。客户端发起请求，服务器执行请求并返回响应。
* **HTTP**：`HTTP`也使用请求-响应模型，但它可以支持不同的`HTTP`方法（如`GET`、`POST`、`PUT`、`DELETE`）来表示不同的操作，从而实现更复杂的交互。
4. **应用场景**
* **RPC**：`RPC`通常用于构建分布式系统，例如微服务架构，其中不同的服务需要相互调用。它更适合用于应用程序内部的通信，以便不同的组件之间可以相互调用函数。
* **HTTP**：`HTTP`主要用于构建`Web`应用程序，支持浏览器与服务器之间的通信。它适用于提供`Web`页面、`API`、资源传输和`Web`服务。
5. **协议与规范**
* **RPC**：`RPC`通常需要使用特定的`RPC`框架或库，如`gRPC`、`Apache Thrift`、`Java RMI`等。这些框架提供了远程调用的支持。
* **HTTP**：`HTTP`是一种通用的应用层协议，任何具备`HTTP`支持的系统都可以使用，无需依赖特定的框架。
**总结：**
`RPC`和`HTTP`都是用于不同类型的通信的协议，`RPC`主要用于构建分布式系统中不同组件之间的远程调用，而`HTTP`主要用于构建`Web`应用程序中浏览器和服务器之间的通信。选择哪种协议取决于应用程序需求和架构。有时，它们也可以结合使用，例如使用`HTTP`来传输`RPC`请求和响应。
### 2.10 HTTP的握手是什么样的
`HTTP`协议本身并不包括握手过程，但它通常是在底层的传输层协议（如`TCP`）上进行握手的。以下是基于`TCP`的`HTTP`握手过程：
1. **建立TCP连接**：`HTTP`通常在传输层使用`TCP`协议。客户端首先与服务器的IP地址和端口建立`TCP`连接。这是一个三步握手的过程，包括客户端发送一个`SYN`包（请求建立连接），服务器回应`SYN-ACK`包（确认并同意建立连接），最后客户端发送`ACK`包（确认连接建立）。
2. **客户端发送HTTP请求**：一旦`TCP`连接建立，客户端可以发送`HTTP`请求。`HTTP`请求由`HTTP`方法（如`GET`、`POST`、`PUT`等）、请求头（包括主机名、`User-Agent`等信息）和请求体（如果有的话）组成。
3. **服务器接收和处理请求**：服务器接收到客户端的`HTTP`请求后，会根据请求中的信息进行处理。这可能包括查找请求的资源、执行相关操作或生成`HTTP`响应。
4. **服务器发送HTTP响应**：服务器生成`HTTP`响应，包括响应状态码、响应头和响应体。响应状态码指示请求的结果，如`200`表示成功，`404`表示资源未找到，`500`表示服务器内部错误等。
5. **客户端接收HTTP响应**：客户端接收到服务器的`HTTP`响应后，会解析响应，处理响应头和响应体，并采取相应的行动，例如渲染网页内容或执行其他操作。
6. **关闭TCP连接**：一旦`HTTP`事务完成，`TCP`连接可以被关闭。关闭`TCP`连接是一个四步挥手的过程，包括客户端发送`FIN`包（请求关闭连接），服务器回应`ACK`包（确认关闭请求），服务器发送`FIN`包（请求关闭连接），最后客户端回应`ACK`包（确认关闭请求）。这个过程是为了确保数据的完整性和可靠性。
**总结：**
`HTTP`握手是建立在`TCP`连接之上的，它包括建立`TCP`连接、发送`HTTP`请求、接收`HTTP`响应和关闭`TCP`连接的步骤。这些步骤使客户端能够与服务器进行通信并交换数据。握手过程的细节可能会因使用的`HTTP`版本、传输层协议（如`HTTPS`）、安全性协议等而有所不同。
### 2.11 Websocket协议和HTTP的关系是什么？
WebSocket（WS）协议和HTTP（Hypertext Transfer Protocol）协议是两种不同的协议，但它们之间存在一定的关系。以下是它们之间的一些关键区别和联系：
1. 协议类型：
* HTTP是一种请求-响应协议，通常用于在客户端和服务器之间传输文本和二进制数据。它是无状态的，每个请求和响应之间是独立的。
* WebSocket是一种全双工通信协议，允许在客户端和服务器之间建立持久连接，实现实时的双向通信。它是建立在HTTP基础上的协议，通过HTTP/1.1协议的升级机制实现。
2. 握手过程：
* HTTP协议是基于请求-响应模型的，每次通信都需要进行握手，发送请求并等待服务器的响应。这种模式适用于单次请求的场景。
* WebSocket则是通过HTTP握手建立连接，之后就可以在已建立的连接上进行双向通信，无需重新握手。WebSocket握手通常使用HTTP协议的升级头（Upgrade Header）来切换协议。
3. 持久连接：
* HTTP是一种短连接协议，每次请求和响应之间都会关闭连接，需要重新建立连接。
* WebSocket是一种长连接协议，通过在握手时建立的连接，保持连接的状态，使得客户端和服务器可以在连接上进行实时的双向通信。
4. 数据格式：
* HTTP数据的传输通常使用明文的文本或者二进制格式，如JSON或XML。
* WebSocket允许在已建立的连接上直接发送二进制数据，同时也支持文本数据的传输。
5. 端口：
* HTTP默认使用端口80，而HTTPS使用端口443。
* WebSocket则通常使用与HTTP相同的端口，例如，如果你的网站使用HTTPS，WebSocket就使用端口443。
虽然WebSocket协议和HTTP协议是不同的协议，但由于WebSocket握手是通过HTTP协议进行的，因此它们在某种程度上关联在一起。WebSocket协议的引入主要是为了解决 HTTP协议在实时双向通信方面的限制，使得Web应用能够更有效地实现实时通信。
## 3 HTTPS
参考1：[HTTP和HTTPS协议，看一篇就够了]( )
### 3.1 HTTP和HTTPS的区别
`HTTP`（Hypertext Transfer Protocol）和`HTTPS`（Hypertext Transfer Protocol Secure）是两种用于在客户端和服务器之间传输数据的协议，它们之间的主要区别在于安全性和数据传输方式：
1. **安全性**
* **HTTP**：`HTTP`是一种不安全的协议，数据在传输过程中以明文形式传输。这意味着如果恶意方在网络中截取`HTTP`通信，他们可以轻松地读取和修改传输的数据，包括敏感信息，如用户名、密码、信用卡号等。因此，`HTTP`不适合用于传输敏感信息的应用程序。
* **HTTPS**：`HTTPS`是`HTTP`的安全版本，使用`SSL/TLS`协议进行数据加密和身份验证。通过`HTTPS`传输的数据被加密，因此即使被截取，也无法轻松读取或修改。`HTTPS`通信使用公钥和私钥，确保客户端和服务器之间的通信是安全的。这使得`HTTPS`非常适合用于处理敏感信息的应用程序，如在线支付、网上银行、电子邮件等。
2. **URL前缀**
* **HTTP**：`HTTP`网站的`URL`通常以"http://"开头，例如：http://www.example.com。
* **HTTPS**：`HTTPS`网站的`URL`通常以"https://"开头，例如：https://www.example.com。
3. **端口**
* **HTTP**：`HTTP`默认使用端口80进行通信。
* **HTTPS**：`HTTPS`默认使用端口443进行通信。
4. **证书**
* **HTTP**：`HTTP`不需要使用数字证书，因为它不提供加密和身份验证。
* **HTTPS**：为了建立`HTTPS`连接，服务器需要使用数字证书来验证其身份。客户端会验证证书的有效性，并确保与服务器的通信是加密的。证书通常由受信任的第三方机构颁发，以确保服务器的身份。
5. **性能**
* **HTTP**：`HTTP`通信速度较快，因为不需要加密和解密数据，但不安全。
* **HTTPS**：`HTTPS`通信速度较慢，因为需要加密和解密数据，但更安全。
**总结：**
`HTTP`和`HTTPS`之间的主要区别在于安全性。`HTTP`是一种不安全的协议，适用于不涉及敏感信息的普通网站，而`HTTPS`通过加密和身份验证提供了更高的安全性，适用于需要保护敏感信息的应用程序。在现代互联网中，推荐在处理用户数据时使用`HTTPS`以提供更高的安全性。
### 3.2 HTTPS实现原理
`HTTPS`（Hypertext Transfer Protocol Secure）实现了`HTTP`协议的安全版本，其主要原理是通过加密和身份验证来确保通信的机密性和完整性。HTTPS的实现原理涉及以下关键概念和步骤：
1. **加密通信**
* **对称加密**：在`HTTPS`通信开始时，客户端和服务器之间建立一个对称密钥，该密钥用于加密和解密通信中的数据。对称密钥是一种快速加密和解密数据的方法，但必须在通信开始时安全地传输。
* **非对称加密**：在对称密钥协商期间，服务器会向客户端发送自己的CA证书，证书里包含公钥，客户端使用该公钥加密对称密钥，然后将其发送回服务器。服务器使用其私钥解密对称密钥。这个过程称为非对称加密，其中公钥用于加密，私钥用于解密。
2. **数字证书**
* 服务器通常需要通过数字证书来验证其身份。数字证书由受信任的第三方证书颁发机构（`Certificate Authority，CA`）签发，包含了服务器的公钥和与服务器相关的信息，同时也包含`CA`的数字签名。客户端可以使用`CA`的公钥来验证服务器证书的有效性，确保连接到的服务器是合法的。
3. **握手过程**：当客户端尝试连接到`HTTPS`服务器时，会发生一个握手过程，其中包括以下步骤：
1. 客户端向服务器发送一个随机数和支持的加密算法列表。
2. 服务器选择一个加密算法和使用自己的私钥生成一个随机数，然后将这些信息与数字证书一起发送给客户端。
3. 客户端使用服务器的公钥解密服务器发送的信息，并验证证书的有效性。如果一切正常，客户端生成一个会话密钥（对称密钥），然后使用服务器的公钥加密该密钥并发送回服务器。
4. 服务器使用其私钥解密会话密钥，然后双方都具备了相同的对称密钥，用于加密和解密通信数据。
4. **加密通信**：一旦握手成功，客户端和服务器之间的通信将使用对称密钥进行加密和解密。这确保了数据在传输过程中的机密性和完整性，使第三方无法轻松地读取或修改数据。
**总结：**
`HTTPS`的实现原理涉及使用对称和非对称加密，数字证书以及握手过程来确保通信的安全性。客户端和服务器之间的通信在加密的环境下进行，同时服务器的身份也得到验证，以防止中间人攻击和数据泄漏。这使得`HTTPS`成为保护敏感信息和确保通信隐私的重要工具。
### 3.3 CA的数字证书中包括哪些信息
参考：[查看google浏览器里的证书]( )
1. **颁发者（Issuer）**：证书颁发机构（`CA`）的名称和相关信息，用于标识颁发该证书的机构。
2. **颁发对象**：证书持有者的相关信息。
3. **主题（Subject）**：证书持有者（通常是网站）的名称和相关信息，用于标识该证书所属实体。
4. **公钥（Public Key）**：证书持有者的公钥，用于加密通信和验证数字签名。
5. **有效期（Validity）**：证书的生效日期和失效日期，指示证书的有效期限。
6. **序列号（Serial Number）**：证书的唯一序列号，用于标识该证书的唯一性。
7. **签名算法（Signature Algorithm）**：用于生成证书签名的算法类型，例如`RSA`、`DSA`、`ECDSA`等。
8. **签名（Signature）**：由证书颁发机构使用其私钥对证书数据进行签名生成的数字签名，用于验证证书的完整性和真实性。
9. **扩展字段（Extensions）**：包含一些额外的信息，如证书用途、密钥用法、颁发者信息等。
这些信息组成了证书数据的主要内容，用于验证证书的有效性和真实性。浏览器和其他应用程序使用这些信息来建立信任链，确认证书的合法性，并确保安全的通信。
### 3.4 SSL建立连接过程
`SSL（Secure Sockets Layer，安全套接字层）`是一种用于在网络上建立安全连接的协议，它的后续版本被称为`TLS（Transport Layer Security，传输层安全性）`。`SSL/TLS`协议的建立连接过程通常包括以下步骤：
1. **客户端Hello**：客户端向服务器发送一个`ClientHello`消息，其中包含以下信息：
1. 客户端支持的`SSL/TLS`协议版本。
2. 一个随机数，该随机数将用于生成会话密钥。
3. 支持的密码套件列表，包括加密算法、哈希算法等。
2. **服务器Hello**
1. 服务器从客户端发送的`ClientHello`消息中选择一个支持的`SSL/TLS`协议版本。
2. 服务器生成一个随机数，将其发送给客户端。
3. 服务器选择一个密码套件，通知客户端使用哪种加密算法和哈希算法。
4. 服务器发送其数字证书，证书包含服务器的公钥以及与证书相关的信息。
3. **身份验证和密钥交换**
1. 客户端验证服务器的证书有效性。包括检查证书是否过期、证书颁发机构是否可信任，证书的颁发机构（`CA`）的信任链，以确保服务器的身份。
2. 客户端生成一个预主密钥（`Pre-Master Secret`），并使用数字证书的公钥加密它，然后发送给服务器。
3. 服务器使用其私钥解密客户端发送的预主密钥，然后双方都使用预主密钥生成主密钥（`Master Secret`）。
4. **会话密钥的生成**
1. 客户端和服务器使用各自的随机数以及主密钥生成会话密钥。
2. 会话密钥是对称密钥，用于加密和解密通信中的数据。
5. **完成握手**
1. 客户端发送一个`Finished`消息，该消息包含前面握手消息的哈希值，以验证握手消息的完整性。
2. 服务器发送一个`Finished`消息，同样包含前面握手消息的哈希值。
3. 一旦客户端和服务器都收到对方的`Finished`消息，握手过程完成。
6. **安全通信**
现在，客户端和服务器都使用会话密钥加密和解密通信中的数据。通信过程中的数据都会使用这个密钥进行保护。
一旦握手完成，`SSL/TLS`会话建立，双方可以安全地通信，保护数据的机密性和完整性。这个过程确保了通信双方的身份验证、密钥交换和安全通信。一旦建立了`SSL/TLS`连接，通信双方可以开始在加密的环境中传输数据，防止数据泄露和中间人攻击。这是安全的`HTTPS`连接的基础。
### 3.5 HTTPS的加密协议是什么
`HTTPS（Hypertext Transfer Protocol Secure）`的加密协议通常是`TLS（Transport Layer Security，传输层安全性）`协议。`TLS`是`SSL（Secure Sockets Layer，安全套接字层）`的后续版本，目前广泛用于保护网络通信的安全性。`TLS`协议提供了数据的加密、完整性验证和身份验证，以确保通信在传输过程中是安全的。
**TLS协议的核心功能包括：**
1. 加密：`TLS`使用对称密钥和非对称密钥加密算法来保护数据的机密性，防止第三方截取和读取数据。
2. 完整性验证：`TLS`使用哈希函数来验证数据的完整性，确保数据在传输过程中没有被篡改。
3. 身份验证：`TLS`通过数字证书来验证通信双方的身份，确保客户端连接到的服务器是合法的。
总结：
`HTTPS`的加密协议通常是`TLS`，它通过加密、完整性验证和身份验证来保护网络通信的安全性。选择`TLS`的版本取决于安全性要求和兼容性考虑。
### 3.6 HTTPS怎么保证服务器给客户端下发的公钥是真正的公钥，而不是中间人伪造的公钥呢？
`HTTPS`通过数字证书来确保客户端收到的服务器公钥是真实有效的，而不是中间人伪造的公钥。这是通过以下方式实现的：
1. **数字证书**：服务器必须获得数字证书，由受信任的第三方机构（`Certificate Authority，CA`）颁发。数字证书包含以下信息：
1. 服务器的公钥。
2. 服务器的标识信息，如域名。
3. `CA`的数字签名。
2. **CA信任链**：客户端的浏览器或操作系统内置了一组受信任的根证书颁发机构（`Root Certificate Authorities`）。这些根`CA`的公钥已被预安装在客户端设备中，并被广泛信任。服务器的数字证书必须由其中一个受信任的`CA`颁发，否则客户端将不信任该证书。
3. **数字签名验证**：当客户端连接到服务器时，服务器会将其数字证书发送给客户端。客户端使用预先安装的根`CA`的公钥来验证服务器证书的数字签名。如果数字签名验证通过，客户端就可以确信证书是由受信任的`CA`颁发的。
4. **域名匹配**：客户端还会检查证书中的域名信息是否与用户试图连接的域名匹配。这是为了防止中间人攻击，其中攻击者可能会伪造证书，并尝试欺骗客户端连接到错误的服务器。
**总结：**
`HTTPS`通过数字证书和`CA`信任链来确保服务器提供的公钥是真实有效的。只有在证书由受信任的`CA`颁发，并且数字签名验证通过且域名匹配时，客户端才会信任服务器的公钥。这种机制防止了中间人攻击，确保了通信的安全性和服务器的身份验证。如果数字证书无效或被篡改，客户端将拒绝建立连接。
### 3.7 第三方攻击者能否让自己的证书显示出来的信息也是服务端呢？
第三方攻击者（中间人攻击者）通常无法获得合法服务器的有效数字证书，因为服务器的数字证书是由受信任的证书颁发机构（`CA`）颁发的，而`CA`通常会执行严格的验证程序来确保只有合法服务器才能获得证书。但中间人攻击者可以尝试使用自己伪造的证书来欺骗客户端，称为自签名证书，以尝试进行攻击。
**中间人攻击的工作原理通常如下：**
1. 攻击者与客户端建立加密通道，同时与服务器建立另一个加密通道。攻击者同时伪装成客户端和服务器。
2. 攻击者向客户端提供自己伪造的数字证书，宣称它是服务器的数字证书。
3. 客户端通常会尝试验证伪造证书的有效性，但攻击者可以提供自己伪造的根证书，声称它是受信任的`CA`的根证书。如果客户端不对证书进行严格的验证，它可能会相信攻击者伪造的证书。
4. 一旦客户端相信了攻击者伪造的证书，它会使用攻击者提供的公钥来加密通信数据，攻击者也可以解密这些数据，然后将其重新加密并传递给真正的服务器。
5. 攻击者以类似的方式伪装成客户端，向服务器发送数据，然后将服务器的响应重新加密并传递给客户端。这使得攻击者可以窃听、修改或篡改通信内容。
为了防止中间人攻击，客户端应严格验证服务器的数字证书，确保它是由受信任的`CA`颁发的，而且证书中的信息与服务器的域名匹配。此外，服务器也可以采用一些安全措施，如公钥固定（`Pin`）或使用证书透明度（`Certificate Transparenc`y）来增加安全性。如果客户端在验证数字证书时发现任何问题，应立即中断连接，以防止建立不安全的通信渠道。
### 3.8 HTTPS优缺点
`HTTPS（Hypertext Transfer Protocol Secure）`是一种用于在网络上建立安全连接的协议，它通过数据加密、身份验证和完整性验证来保护通信的安全性。`HTTPS`具有许多优点，但也有一些缺点。
**优点：**
1. **数据加密**：`HTTPS`使用加密算法来保护数据在传输过程中的机密性。这意味着即使数据被截取，也无法轻松读取其内容，因此能够有效防止信息泄漏。
2. **完整性验证**：`HTTPS`使用哈希函数来验证数据的完整性，确保数据在传输过程中没有被篡改。这有助于防止中间人攻击和数据篡改。
3. **身份验证**：`HTTPS`通过数字证书来验证服务器的身份。客户端可以确保连接到的服务器是合法的，这防止了伪装和中间人攻击。
4. **用户信任**：`HTTPS`使用受信任的第三方证书颁发机构（`CA`）颁发的数字证书。这增加了用户对网站的信任，因为他们可以相信其连接是安全的。
5. **SEO优化**：搜索引擎（如`Google`）更喜欢使用`HTTPS`保护的网站，因此使用`HTTPS`可以提高网站的搜索引擎排名。
6. **法规合规性**：许多法规和合规性要求要求网站使用`HTTPS`来保护用户数据，特别是对于敏感信息的处理，如支付信息和个人身份信息。
7. **Cookie安全**：`HTTPS`可以帮助防止`Cookie`劫持攻击，因为`Cookie`在传输过程中也会被加密。
**缺点：**
1. **性能开销**：加密和解密数据会引入一些性能开销，使`HTTPS`通信相对于`HTTPS`略显慢一些。然而，现代硬件和`TLS`协议的改进已经减小了这种性能开销。
2. **成本**：获得有效的数字证书可能需要支付一些费用，尤其是如果选择使用受信任的商业`CA`颁发的证书。
3. **配置和维护**：配置和维护`HTTPS`服务器可能比`HTTP`更复杂，尤其是在大型网络中。
4. **不是绝对安全**：虽然`HTTPS`提供了很高的安全性，但它也不是绝对安全的。它仍然可能受到一些攻击，如某些类型的中间人攻击或恶意软件感染。
**总结：**
`HTTPS`在保护通信的安全性和隐私方面具有很大的优势，尤其是在处理敏感信息的应用程序中。然而，它也需要考虑性能开销和一些配置和维护工作。对于大多数`Web`应用程序来说，使用`HTTPS`是非常值得的，因为它提供了必要的保护和用户信任。
### 3.9 HTTPS的证书是谁验证谁
在`HTTPS`通信中，数字证书的验证过程如下：
1. 证书颁发机构(`CA`)验证网站的身份并向其颁发证书。
2. 网站将证书发送给访问的客户端。
3. 客户端获取证书后，验证证书的颁发机构是否为可信的`CA`。
4. 客户端验证证书的内容是否与网站地址匹配。
5. 如果一切验证通过，客户端就可以信任该证书真实属于该网站。
所以简单来说：
1. `CA`验证网站，向网站颁发证书。
2. 客户端验证`CA`是否可信任，以及证书是否与网站匹配。
3. 最后客户端验证证书的有效性和网站的合法性。
**总结：**
`HTTPS`证书验证中，`CA`验证网站，而用户验证`CA`和证书本身。这个双向验证机制让`HTTPS`证书系统能够安全可靠地运行。
### 3.10 HTTPS单向认证时谁验证谁
在`HTTPS`单向认证中，一般情况下是客户端验证服务器的身份，而不是服务器验证客户端的身份。这是`HTTPS`的标准配置方式，也被称为单向`SSL`认证。
**HTTPS通信中的验证通常如下：**
1. 服务器验证：服务器获得数字证书，其中包含服务器的公钥以及一些服务器相关的信息，如域名。服务器将其数字证书发送给客户端。
2. 客户端验证（可选）：在标准的单向`SSL`认证中，客户端可以选择验证服务器的证书。客户端使用受信任的根`CA`的公钥来验证服务器证书的有效性，包括证书的签名和域名匹配。如果客户端选择验证服务器的证书并且验证通过，它可以信任服务器的身份。
3. 连接建立：一旦服务器的证书被验证通过（如果客户端进行了验证），客户端和服务器之间建立连接，并使用服务器的公钥加密通信数据。
**总结：**
`HTTPS`的标准配置中，通常是客户端验证服务器的身份，而服务器通常不验证客户端的身份。客户端通过验证服务器的证书来确保连接到的服务器是合法的，从而防止中间人攻击。如果需要服务器验证客户端的身份，可以使用双向认证（双向`SSL`认证）来实现，其中客户端和服务器都会验证对方的身份。
### 3.11 HTTPS客户端如何验证服务端证书的合法性
在`HTTPS`通信中，客户端通过验证服务器证书的合法性来确认连接到的服务器的身份。这个验证过程通常包括以下步骤：
1. **获取服务器证书**：服务器在握手过程中将其数字证书发送给客户端。
2. **验证证书的签发机构（`CA`）**：客户端使用本地受信任的根证书颁发机构（`CA`）的公钥来验证服务器证书是否由受信任的`CA`签发。根证书通常是预装在操作系统或浏览器中的。
3. **验证证书的有效期**：客户端检查服务器证书的有效期，确保它没有过期。如果证书已过期，客户端将认为连接不安全。
4. **验证证书的域名匹配**：客户端检查服务器证书中的域名信息是否与用户试图连接的域名匹配。这是为了防止中间人攻击，其中攻击者可能会伪造证书并欺骗客户端连接到错误的服务器。
5. **验证证书的签名**：客户端使用根`CA`的公钥来验证服务器证书的数字签名。如果签名验证通过，客户端可以确信证书未被篡改。
如果服务器证书通过上述验证步骤，客户端就可以信任服务器的身份，并继续建立安全连接，使用服务器的公钥来加密通信数据。
**注意：**
客户端可以选择是否验证服务器证书。在某些情况下，如果客户端无法验证服务器的证书或不进行验证，连接仍然可以建立，但会警告用户连接不安全。然而，为了最大程度地确保安全，建议客户端始终验证服务器证书的合法性。
### 3.12 HTTPS信息摘要的算法是什么
`HTTPS`使用一种称为消息摘要算法（`Message Digest Algorithm`）的算法来确保数据的完整性。具体来说，`HTTPS`通常使用`SHA-256（Secure Hash Algorithm 256位）`或其他类似的消息摘要算法。
**在HTTPS安全通信中，数字签名和消息摘要使用了以下几种算法：**
1. **MD5(Message-Digest Algorithm 5)**：`MD5`是一个128位长度的消息摘要算法，用于产生数据的数字签名，校验数据完整性。但`MD5`已被证实存在弱点，可以被碰撞攻击。
2. **SHA-1(Secure Hash Algorithm 1)**：`SHA-1`是160位长度输出的密码`HASH`算法，相比`MD5`更加安全可靠，但理论上也可能受到碰撞攻击。
3. **SHA-2**：`SHA-2`代表了一系列`SHA`算法，包括`SHA-224`、`SHA-256`、`SHA-384`、`SHA-512`等变种。其中`SHA-256`是目前广泛使用的数字签名和消息摘要算法。
4. **SHA-3**：`SHA-3`是最新的安全`HASH`算法标准，采用`Keccak`算法，可以产生`224`、`256`、`384`、`512`位长度的消息摘要。其安全性得到广泛认可。
5. **HMAC**：`HMAC(Hash-based Message Authentication Code)`是将`HASH`算法与密钥结合，生成包含`HASH`算法和密钥的消息摘要，提高了安全性。
**总结：**
`HTTPS`中常用的消息摘要和数字签名算法是`SHA-2`(特别是`SHA-256`)和`HMAC`，以及最新的`SHA-3`算法。这些算法安全性强，抗破解能力高。
`SHA-256`是`SHA-2`家族中的一种，它是一种密码学安全的哈希函数，用于生成数据的固定长度的哈希值。`SHA-256`会将输入数据（如`HTTP`报文或`HTTPS`数据）转换成256位（32字节）的哈希值。如果在传输过程中数据被篡改，即使是微小的更改，也会导致哈希值发生显著变化，从而使客户端能够检测到数据的篡改。
`SHA-256`被广泛用于`HTTPS`通信中的消息摘要生成，以确保传输的数据在传输过程中没有被篡改。这有助于防止中间人攻击和确保数据的完整性。同时，`SHA-256`也是当前广泛使用的加密哈希算法之一，具有较高的安全性和广泛的应用范围。
### 3.13 HTTPS交换的是什么
`HTTPS`通信主要交换的内容包括`SSL/TLS`握手信息、加密的`HTTP`请求和响应以及用于验证数据完整性的消息摘要。这些机制确保了`HTTPS`通信的安全性和隐私。
其实也就是建立连接的过程。
### 3.14 HTTPS数据传输用什么加密方式
`HTTPS`数据传输使用对称加密和非对称加密结合的方式来保障数据的安全性和保密性。
以下是`HTTPS`通信中常用的加密方式：
1. **对称加密**：对称加密使用相同的密钥来加密和解密数据，因此被称为"对称"。在`HTTPS`通信中，客户端和服务器在`SSL/TLS`握手过程中协商出一个对称的会话密钥（`Session Key`）。这个会话密钥用于加密和解密实际的`HTTPS`数据。常见的对称加密算法包括：
* `AES（Advanced Encryption Standard`）：目前广泛使用的对称加密算法之一，支持不同的密钥长度，如`AES-128`、`AES-256`等。
2. **非对称加密**：非对称加密使用一对密钥，包括公钥和私钥，其中一个用于加密，另一个用于解密。在`HTTPS`通信中，服务器拥有一对公钥和私钥，其中公钥被包含在服务器的数字证书中，而私钥是服务器保密的。非对称加密主要用于`SSL/TLS`握手阶段，以安全地协商对称会话密钥。常见的非对称加密算法包括：
* `RSA（Rivest–Shamir–Adleman）`：常用于数字证书中的非对称加密算法。
3. **数字签名**：数字签名是一种非对称加密的应用，用于验证数字证书的有效性。服务器的数字证书包含服务器的公钥和由证书颁发机构（`CA`）签名的信息。客户端使用`CA`的公钥来验证证书的签名，以确保证书是合法的。
`HTTPS`通信的基本过程是：在握手阶段，服务器和客户端协商出一个对称的会话密钥，该密钥用于加密和解密`HTTP`数据。这个对称会话密钥由服务器的非对称公钥加密传输给客户端，客户端使用私钥解密得到该密钥。之后，客户端和服务器使用对称密钥来加密和解密通信数据，保障数据的机密性和完整性。
**总结：**
`HTTPS`使用对称加密和非对称加密（包括数字签名）来保障通信数据的安全性和保密性。这种综合使用不同的加密方式，使得`HTTPS`通信变得安全可靠。
## 4 HTTP2相比HTTP1有什么优势
**注意**：`HTTP2不是HTTPS`，两者别搞成一个了。
`HTTP/2`是`HTTP/1`的后续版本，它引入了一些重要的改进，以提高性能和效率。以下是`HTTP/2`相比`HTTP/1`的一些主要优势：
1. **多路复用（Multiplexing）**：`HTTP/2`允许多个请求和响应同时在一个连接上进行传输，而不像`HTTP/1`那样需要建立多个连接。这意味着可以在一个连接上并行发送多个请求和响应，减少了连接建立和维护的开销，提高了性能。
2. **二进制格式**：`HTTP/2`采用了二进制传输格式，而`HTTP/1`使用文本格式。二进制格式更加紧凑和高效，减少了数据传输的大小，从而提高了效率。
3. **头部压缩**：`HTTP/2`支持头部字段的压缩，减少了请求和响应中的重复头部信息的传输，降低了带宽使用，加快了页面加载速度。
4. **服务器推送（Server Push）**：`HTTP/2`允许服务器在客户端请求之前主动推送资源。这使得服务器可以预测客户端可能需要的资源，并在请求之前发送，减少了往返延迟，提高了加载速度。
5. **优化的流量控制**：`HTTP/2`引入了更有效的流量控制机制，可以更精细地管理数据流的传输和优先级，确保关键资源能够更快地加载。
6. **支持Header压缩算法**：`HTTP/2`使用`HPACK`压缩算法来压缩头部信息，减少了数据传输的开销。这有助于提高性能，特别是在低带宽或高延迟网络环境下。
7. **安全性**：虽然不是`HTTP/2`的本质特性，但它鼓励网站采用加密（通过`HTTPS`），因为大多数现代浏览器只支持`HTTP/2`超过`HTTPS`。因此，`HTTP/2`可以提高通信的安全性。
**总结：**
`HTTP/2`相对于`HTTP/1`具有更高的性能、更低的延迟和更高的效率，可以改善网站的加载速度和用户体验。因此，许多网站和服务已经采用了`HTTP/2`来提供更快的性能。
### 4.1 GRPC是HTTP2还是HTTP1
`GRPC`使用`HTTP/2`作为其底层的传输协议，而不是`HTTP/1`。`GRPC`是一个高性能的远程过程调用（`RPC`）框架，它使用`HTTP/2`来实现通信，具有诸多优势，包括多路复用、头部压缩、流控制等特性，使其成为现代分布式系统中的常用工具。`HTTP/2`的性能和效率改进使得`GRPC`可以更高效地处理大量的并发请求，同时提供更小的延迟和更低的带宽消耗。因此，`GRPC`的底层协议是`HTTP/2`，而不是`HTTP/1`。
## 5 TCP
`TCP（Transmission Control Protocol，传输控制协议）`是计算机网络中的一种常用的传输层协议，它提供可靠的、面向连接、点到点的数据传输服务。
### 5.1 TCP和HTTP的区别
`HTTP（Hypertext Transfer Protocol）`和`TCP（Transmission Control Protocol）`是计算机网络中的两个不同的协议，它们在网络通信中扮演不同的角色，有以下主要区别：
1. 层级关系：
* `TCP`是传输层协议，负责在网络上可靠地传输数据，处理数据的分段、顺序控制、流量控制等网络传输的底层细节。
* `HTTP`是应用层协议，构建在传输层之上，用于定义客户端和服务器之间的通信规则，以便请求和传输超文本（通常是网页）和其他数据。
2. 功能：
* `TCP`主要负责数据传输的可靠性和有序性。它确保数据能够从一个端点安全地传输到另一个端点，而不会损坏、丢失或乱序。
* `HTTP`主要负责定义客户端和服务器之间的请求和响应的格式，以及如何处理和呈现文档或数据。
3. 连接性：
* `TCP`是一种面向连接的协议，它建立持久的连接来传输数据，通常使用客户端-服务器模型。
* `HTTP`可以基于`TCP`连接，但它是一种无状态协议，每个请求都是独立的，服务器不会保持与客户端的持久连接。
4. 端口：
* `TCP`使用端口号来标识不同的网络应用程序或服务。例如，`Web`服务器通常使用`TCP`端口80或443。
* `HTTP`通常基于`TCP`连接，使用`HTTP`默认端口80（非加密）或443（加密）。
5. 通信内容：
* `TCP`传输的是原始二进制数据流，它没有关于数据的上下文或语义。
* `HTTP`传输的是基于文本的消息，这些消息包含请求或响应的元信息和数据，以及用于标识资源的`URL`。
6. 应用领域：
* `TCP`是一个通用的协议，用于支持各种应用程序和服务的可靠通信，包括`HTTP`。
* `HTTP`主要用于互联网上的超文本传输，用于在`Web`浏览器和`Web`服务器之间传输网页、图像、视频、`API`数据等。
**总结：**
`TCP`提供了网络通信的底层基础，而`HTTP`构建在`TCP`之上，定义了用于`Web`数据传输的规则和语义。`HTTP`使用`TCP`作为它的传输层协议之一，但还包括其他应用层协议，如`HTTPS（HTTP over TLS/SSL）`等，以提供安全性和隐私保护。
### 5.2 HTTP是在TCP之上运行，两者的包会有什么区别
1. `TCP`的数据包包含源端口和目标端口，`HTTP`不包含端口信息。
2. `TCP`的包头简单，只包含源端口、目标端口、序号、确认号等信息。`HTTP`的数据包更复杂，包含请求方法、URL、协议版本、请求头部、消息体等信息。
3. `TCP`关注传输， `packets`只包含数据。`HTTP`关注应用信息，`packets`包含具体的请求或响应详情。
4. `TCP`的`packets`按顺序传输，`HTTP`的`packets`可以乱序。
5. `TCP`需要建立连接、流量控制和拥塞控制。`HTTP`运行在`TCP`连接上，可以忽略这些问题。
6. `TCP`对数据包的大小没有限制。`HTTP`一般将数据包限制在1500字节以内。
7. `TCP`的`packets`只有头部。`HTTP`的`packets`有头部、消息体等完整结构。
8. `TCP`是面向连接的协议。`HTTP`本质上是无连接的。
**总结：**
两者分别工作在不同层次，`TCP`负责底层传输，`HTTP`负责具体的应用数据交互，两者的包结构和功能有着明显的区别。
### 5.3 TCP特点
1. **可靠性**：`TCP`提供可靠的数据传输。它确保数据从发送端准确地传输到接收端，通过使用序号、确认和重传机制来实现数据的可靠性。如果数据包丢失、损坏或乱序，`TCP`将负责重新发送数据，以确保完整性和正确性。
2. **面向连接**：`TCP`是一种面向连接的协议，连接的建立需要经过三次握手过程，以确保双方都准备好进行数据传输。连接的关闭也需要经过四次挥手过程。
3. **流量控制**：`TCP`使用流量控制机制来防止数据包的积压和数据传输过程中的数据流过快。接收端可以通知发送端其可接受的数据量，从而调整发送速率，以适应接收端的处理能力。
4. **拥塞控制**：`TCP`具有拥塞控制机制，它可以在网络拥塞时减缓数据发送速率，以防止过度拥塞，保持网络的稳定性。拥塞控制通过检测丢失的数据包和计算往返时间来实现。
5. **面向字节**：`TCP`将数据视为一系列字节的流，而不是消息或数据包。这允许`TCP`在传输时对数据进行分段、重组和流动控制，以适应不同的网络条件。
6. **双工通信**：`TCP`支持全双工通信，允许双方同时发送和接收数据，这使得实时应用和互动应用能够进行高效的双向通信。
7. **端口和套接字**：`TCP`使用端口来区分不同的应用程序和服务。套接字是应用程序与`TCP`协议交互的接口，通过套接字可以进行数据的读取和写入。
8. **可靠性和复杂性**：`TCP`提供高度的可靠性和数据完整性，但它也引入了一些复杂性和额外的开销，如握手、确认和拥塞控制。这些机制确保了数据的可靠传输，但有时也会引入一些延迟。
**总结：**
`TCP`是一种非常可靠的协议，适用于需要可靠数据传输和连接性能的应用程序，如网页浏览、电子邮件、文件传输、实时通信等。它是互联网中的基础协议之一，确保了数据在网络中的可靠传输。
### 5.4 TCP使用场景
`TCP（Transmission Control Protocol，传输控制协议）`适用于需要可靠的、面向连接的数据传输的场景。以下是一些常见的`TCP`使用场景：
1. **Web浏览**：当在浏览器中访问网页时，浏览器使用`HTTP`协议（通常是`HTTP over TCP`）与`Web`服务器建立`TCP`连接来请求网页内容。`TCP`确保了网页数据的可靠传输，以便正确显示网页。
2. **电子邮件**：`SMTP（Simple Mail Transfer Protocol`）和`POP3（Post Office Protocol）`或`IMAP（Internet Message Access Protocol）`等电子邮件协议使用`TCP`来传输电子邮件消息，以确保邮件的可靠传输和正确接收。
3. **文件传输**：`FTP（File Transfer Protocol）`和`SFTP（SSH File Transfer Protocol）`等协议使用`TCP`来传输文件。这些协议需要可靠的数据传输，以防止文件损坏或丢失。
4. **远程登录**：`SSH（Secure Shell）`和`Telnet`等协议用于远程登录到计算机系统。`SSH`使用`TCP`来提供加密的、安全的远程访问。
5. **数据库访问**：许多数据库管理系统（如`MySQL`、`PostgreSQL`、`Oracle`）使用`TCP`来进行数据库查询和数据传输。可靠性对于数据库操作至关重要。
6. **VoIP电话**：`Voice over Internet Protocol（VoIP）`电话系统使用`TCP`或`UDP`（在某些情况下）来传输音频数据。虽然`UDP`在`VoIP`中更常见，但某些应用也使用`TCP`以确保更可靠的音频传输。
7. **在线游戏**：某些在线游戏使用`TCP`来传输游戏数据，特别是需要高度可靠性的游戏。虽然`UDP`更常用于实时游戏，但`TCP`适用于一些策略性或回合制游戏。
8. **HTTPS安全通信**：`HTTPS`协议使用`TLS/SSL`建立在`TCP`上，以确保加密和安全性，用于保护敏感数据的传输，如信用卡信息和登录凭据。
9. **Web服务**：当使用`SOAP`、`RESTful API`等协议进行`Web`服务调用时，通常会使用`HTTP over TCP`来进行通信。
**总结**：
`TCP`适用于需要可靠性、面向连接和数据完整性的应用场景。它确保数据的可靠传输，适用于许多互联网应用，尤其是需要高度可靠性的应用。然而，由于`TCP`引入了一些额外的开销，可能会引入一些延迟，因此在某些实时性要求较高的应用中，可能会使用`UDP`等协议。
**注释**：`"HTTP over TCP"` 就是使用传输控制协议（`TCP`）作为`HTTP`协议的底层传输协议。在这种情况下，`HTTP`数据通过`TCP`连接进行传输，以确保数据的可靠性和完整性。
### 5.5 基于（使用）TCP的协议有哪些
1. **HTTP（Hypertext Transfer Protocol）**：`HTTP`是用于在`Web`浏览器和`Web`服务器之间传输超文本文档的协议。它是互联网上最常见的应用层协议之一，通常使用`TCP`作为传输层协议。
2. **HTTPS（HTTP Secure）**：`HTTPS`是`HTTP`的安全版本，通过在`HTTP`上加入`TLS/SSL`层来加密数据传输。它使用`TCP`作为底层传输协议，以确保加密的、安全的通信。
3. **FTP（File Transfer Protocol）**：`FTP`是用于文件传输的协议，它使用`TCP`来传输文件。`FTP`允许用户上传和下载文件到和从远程服务器。
4. **SMTP（Simple Mail Transfer Protocol）**：`SMTP`是用于电子邮件传输的协议，用于从发送方电子邮件客户端发送电子邮件到接收方电子邮件服务器。`SMTP`使用`TCP`来传输电子邮件消息。
5. **POP3（Post Office Protocol version 3） 和 IMAP（Internet Message Access Protocol）**：这两个协议用于从电子邮件服务器上检索电子邮件。`POP3`和`IMAP`都使用`TCP`来建立连接并下载电子邮件。
6. **SSH（Secure Shell）**：`SSH`是用于安全远程登录和文件传输的协议。它使用`TCP`作为底层传输协议，并提供加密和认证功能，以保护远程会话的安全。
7. **Telnet**：`Telnet`是一种用于远程登录到远程主机的协议，但它不提供加密，因此安全性较低。它使用`TCP`来传输终端会话。
8. **MySQL**：`MySQL`是一种流行的关系型数据库管理系统，它使用`TCP`来建立与数据库服务器的连接并进行数据查询和操作。
9. **RDP（Remote Desktop Protocol）**：`RDP`用于远程桌面连接，允许用户远程控制和操作远程计算机。它使用`TCP`来传输桌面会话数据。
10. **XMPP（Extensible Messaging and Presence Protocol）**：`XMPP`是一种实时通信协议，用于即时消息传递和在线状态。它使用`TCP`来传输消息。
**总结：**
这些协议是构建互联网和计算机网络中各种应用和服务的关键组成部分，它们依赖于`TCP`来提供可靠的数据传输。每个协议都具有不同的用途和特性，但它们都使用`TCP`作为传输层协议，以确保数据的可靠性和正确性。
### 5.6 TCP三次握手
参考1：[HTTP协议常问的面试题（吐血整理）]( ) 看 `16 TCP三次握手和四次挥手`。
`TCP`的三次握手（`Three-Way Handshake`）是建立`TCP`连接的过程，用于确保通信的双方都准备好传输数据。以下是`TCP`三次握手的过程：
1. **第一步 - 客户端发送连接请求**：
1. 客户端首先向服务器发送一个特殊的`TCP`包，称为`SYN`（同步）包。
2. 这个包包含客户端随机选择的一个初始序列号（`Client ISN，Initial Sequence Number`），该序列号用于标识客户端发送的数据，以及一个标志位`SYN=1`，表示这是一个连接请求。
2. **第二步 - 服务器确认连接请求**：
1. 服务器收到客户端的连接请求（`SYN`包）后，如果同意建立连接，会回复一个包，通常称为`SYN-ACK`包。
2. 这个包包含了服务器分配用于标识服务器发送的数据的初始序列号（`Server ISN`），以及标志位`SYN=1`和`ACK=1`，表示这是对客户端请求的确认，并且服务器也准备好建立连接。
3. **第三步 - 客户端确认服务器的确认**：
1. 客户端收到服务器的确认（`SYN-ACK包`）后，会向服务器发送一个确认包（`ACK包`）。
2. 这个包包含标志位`ACK=1`，表示客户端接受了服务器的确认，并且连接已建立。
3. 此时，双方都已确认连接的建立，可以开始传输数据。
完成了这个三次握手过程后，`TCP`连接就建立成功了，客户端和服务器都可以开始在连接上进行数据传输。**每个数据包都会包含一个序列号，用于标识数据的顺序和完整性，以确保数据能够正确地传输和接收**。
**注意：**
三次握手是用于建立`TCP`连接的过程。在连接结束后，会使用四次挥手过程来正常关闭连接。这些握手和挥手过程是`TCP`协议中的关键步骤，以确保数据的可靠传输和连接的正确终止。
### 5.7 TCP在握手完成之后，A到B发送数据，中间有个数据被篡改，它会怎处理
`TCP`在数据传输过程中，包括握手阶段之后，会使用一种校验和机制来检测数据是否被篡改。这个校验和通常称为`TCP`校验和（`TCP Checksum`）。
当数据从发送端`A`到接收端`B`时，`TCP`发送端会计算校验和并将其附加到数据包的头部。接收端`B`收到数据包后会进行以下处理：
1. **校验和验证**：接收端`B`会计算接收到的数据包的校验和，并将结果与数据包头部中的校验和进行比较。
2. **比较校验和**：如果接收端计算出的校验和与数据包头部中的校验和匹配，说明数据包在传输过程中没有被篡改，数据被接受并继续传递给上层应用程序。
3. **校验和不匹配**：如果接收端计算出的校验和与数据包头部中的校验和不匹配，说明数据包在传输过程中可能受到了篡改或损坏。接收端会丢弃这个数据包，不传递给上层应用程序，并可以选择发送一个通知给发送端`A`请求重新发送数据。
这种校验和机制帮助确保了`TCP`传输中数据的完整性。如果数据包在传输过程中被篡改或损坏，接收端会检测到这一问题，并丢弃损坏的数据包，从而保护了数据的可靠性。如果发生数据包丢失或篡改，`TCP`会负责重新传输数据，直到接收端确认接收到正确的数据。
**总结：**
`TCP`使用校验和机制来检测和处理数据传输中的篡改或损坏问题，以确保数据的可靠性和完整性。这是`TCP`协议的一个重要特性，有助于提高网络通信的可靠性。
### 5.8 TCP三次握手的两种队列
参考1：[TCP连接三次握手中的重要数据结构：半连接队列和全连接队列]( )
在`TCP`三次握手的时候，服务端会维护两个队列：`监听队列（Listen Queue）`和`已完成队列（Completed Connection Queue）`。
1. **监听队列（Listen Queue）**：
* 监听队列也称为“半连接队列”或“未完全建立连接的队列”。
* 在服务端（通常是服务器）调用listen函数后，它会等待客户端的连接请求。
* 当客户端发送`SYN`（同步）包进行连接请求时，服务器会将这个请求放入监听队列中，等待后续的第二次握手。
* 监听队列的大小可以通过操作系统的配置进行设置，这个设置限制了同时等待连接的数量。如果队列已满，新的连接请求会被拒绝。
2. **已完成队列（Completed Connection Queue）**：
* 已完成队列也称为“全连接队列”或“已建立连接的队列”。
* 在服务器成功进行了第二次握手，接受了客户端的连接请求后，连接就会从监听队列移动到已完成队列中。
* 已完成队列中的连接表示已经建立，可以进行数据传输。
* 服务器会从已完成队列中取出连接，分配资源，为连接提供服务，并在完成后进行释放。
**总结：**
监听队列用于存放等待服务器确认的连接请求，而已完成队列用于存放已经建立的连接，准备进行数据传输。这两个队列在`TCP`连接建立过程中起着重要的作用，确保了连接的正常建立和管理。当连接终止时，也有相应的队列来管理连接的释放。
#### 5.8.1 TCP三次握手的两种队列溢出
不管是半连接队列还是全连接队列，都有最大长度限制，超过限制时，内核会直接丢弃，或返回`RST`包。
**半连接队列溢出：**
客户端发送SYN报文和服务端进行第一次握手，**此时服务端将此请求信息放在半连接队列中**并回复`SYN+ACK`给客户端。这里也就是SYN攻击的点，攻击方要做的就是不停的建立连接，但是却不给出`ACK`确认，导致半连接队列满了，其他请求无法进入。
**全连接队列溢出：**
**当服务端并发处理大量请求时**，如果`TCP`全连接队列过小，就容易溢出。发生`TCP`全连接队溢出的时候，后续的请求就会被丢弃，这样就会出现服务端请求数量上不去的现象。
**全连接队列满了，就只会丢弃连接吗？**
实际上，丢弃连接只是`Linux`的默认行为，我们还可以选择向客户端发送`RST`复位报文，告诉客户端连接已经建立失败。
`tcp_abort_on_overflow` 共有两个值分别是0和1，其分别表示：
0 ：表示如果全连接队列满了，那么`server`丢弃`client`发过来的`ack`；
1 ：表示如果全连接队列满了，那么`server`发送一个`reset` 包给 client，表示废掉这个握手过程和这个连接；
如果要想知道客户端连接不上服务端，是不是服务端`TCP`全连接队列满的原因，可以把`tcp_abort_on_overflow`设置为1，这时如果在客户端异常中可以看到很多`connection reset by peer`的错误，那么就可以证明是由于服务端 TCP 全连接队列溢出的问题。
**通常情况下，应当把tcp\_abort\_on\_overflow设置为0，因为这样更有利于应对突发流量。**
举个例子，当`TCP`全连接队列满导致服务器丢掉了`ACK`，与此同时，客户端的连接状态却是`ESTABLISHED`，进程就在建立好的连接上发送请求。只要服务器没有为请求回复`ACK`，请求就会被多次重发。如果服务器上的进程只是短暂的繁忙造成`accept`队列满，那么当`TCP`全连接队列有空位时，再次接收到的请求报文由于含有`ACK`，仍然会触发服务器端成功建立连接。
### 5.9 TCP如何实现可靠性传输
`TCP`（`Transmission Control Protocol，传输控制协议`）通过一系列机制来实现可靠性传输，确保数据从发送端到接收端的可靠传输。
以下是`TCP`实现可靠性传输的主要机制：
1. **序列号和确认号**：`TCP`在每个数据包中包含序列号（`Sequence Number`）和确认号（`Acknowledgment Number`）。序列号用于标识数据的顺序，确认号用于确认接收到的数据。接收端会发送确认，指示它已经成功接收并准备好接收下一个数据包。
2. **数据重传**：如果发送端没有收到来自接收端的确认，或者接收端检测到丢失的数据包，`TCP`会触发数据重传机制。发送端会重新发送丢失的数据包，直到接收到确认为止。
3. **流量控制**：`TCP`使用流量控制机制，确保发送端不会以过快的速度发送数据，从而防止数据包的积压和网络拥塞。接收端可以通知发送端其可接受的数据量，以调整发送速率。
4. **拥塞控制**：`TCP`还具有拥塞控制机制，可以在网络拥塞时减缓数据发送速率，以防止过度拥塞并提高网络的稳定性。拥塞控制通过检测丢失的数据包和计算往返时间来实现。
5. **有序交付**：`TCP`确保数据按正确的顺序交付给应用层。即使数据包在传输过程中到达的顺序与发送顺序不同，`TCP`也会将它们按正确的顺序交给应用程序。
6. **校验和验证**：`TCP`使用校验和机制来检测数据包在传输过程中是否发生了损坏。如果数据包在传输过程中损坏，接收端会通知发送端丢弃损坏的数据包，并要求重新发送。
7. **超时和重传策略**：`TCP`使用超时和重传策略来处理丢失的数据包。如果一个数据包的确认没有及时到达，`TCP`将触发重传机制，重新发送该数据包。
8. **窗口机制**：`TCP`使用窗口机制来调整发送和接收的数据量，以提高效率。窗口大小可以根据网络条件进行动态调整。
9. **连接建立和断开的握手过程**：`TCP`的连接建立和断开过程也是可靠性的一部分。三次握手确保了双方都准备好建立连接，四次挥手确保了连接的正常终止。
**总结：**
`TCP`通过这些机制和策略，以及其他一些技术手段，来实现可靠性传输，确保数据在网络中的可靠传输和正确接收。这使得`TCP`成为一种非常可靠的协议，适用于各种需要可靠性传输的应用，如网页浏览、电子邮件、文件传输等。
### 5.10 TCP建立连接的时候为什么是三次握手，不是两次或四次
`TCP`建立连接采用三次握手的过程，而不是两次或四次，是为了确保双方都准备好进行可靠的数据传输，并且避免出现不必要的连接建立。
**以下是三次握手的原因和过程：**
1. **确保双方都愿意建立连接**：通过三次握手，确保了客户端和服务器都愿意建立连接。如果只有两次握手，那么可能会导致一方不知道对方是否愿意建立连接，从而引发不确定性和安全问题。
2. **防止旧连接的问题**：在网络中，已经关闭连接的数据包可能在某段时间内仍然存在，这是因为网络中的数据包可能会延迟或复制。如果只有两次握手，可能会导致在新连接中误认为是旧连接的数据包，从而引发问题。通过第三次握手，可以确保是新的连接，防止这种问题的发生。
3. **防止连接资源浪费**：如果连接建立后不进行三次握手的确认，那么服务器可能会浪费资源来处理无效的连接请求。
**总结：**
三次握手确保了双方都准备好建立连接，避免了可能导致数据传输问题的情况。它是`TCP`协议设计的一部分，旨在提供可靠性和安全性，确保通信的正常进行。虽然三次握手引入了一些额外的开销，但这个开销在大多数情况下是合理的，以确保数据传输的可靠性。
### 5.11 TCP四次挥手
参考：[你需要知道的 TCP 四次挥手]( )
`TCP`的四次挥手是用于正常关闭`TCP`连接的过程，确保数据的可靠传输和连接的正确终止。以下是`TCP`四次挥手的过程：
1. **第一次挥手 - 客户端发送连接关闭请求（FIN from Client）**：
* 客户端首先决定关闭连接，它向服务器发送一个带有`FIN（Finish，结束）`标志的`TCP`数据包给服务器，表示客户端不再发送数据给服务器，但仍然愿意接收来自服务器的数据。
* 客户端进入`FIN_WAIT_1`状态，等待服务器的确认或拒绝。
2. **第二次挥手 - 服务器确认关闭请求（ACK from Server）**：
* 服务器接收到客户端的`FIN`后，会发送一个带有确认`ACK`标志的`TCP`数据包给客户端，表示服务器已收到客户端的关闭请求。
* 此时服务器进入`CLOSE_WAIT`状态，客户端继续等待来自服务器的可能未发送完的数据。
3. **第三次挥手 - 服务器发送连接关闭请求（FIN from Server）**：
* 当服务器确定不再有数据要发送给客户端时，服务器发送一个带有`FIN`标志的`TCP`数据包给客户端，表示服务器也准备好关闭连接。
* 服务器进入`LAST_ACK`状态，等待客户端的确认。
4. **第四次挥手 - 客户端确认关闭请求（ACK from Client）**：
* 客户端收到服务器的`FIN`包后进入`TIME_WAIT`状态，会发送一个`ACK`包作为确认，并等待一段时间以确保可能在网络中滞留的`ACK`数据包到达服务器。
* 服务器收到这个`ACK`后，进入`CLOSED`状态，连接完全关闭。
* 客户端则会等一段时间再进入关闭状态，释放资源，结束`TIME_WAIT`状态。因为第四次挥手不一定能成功发给服务端，所以要等一下，看看服务端会不会因为没收到第四次挥手，而重发第三次挥手。
在四次挥手的过程中，双方都有机会发送`FIN`和`ACK`包，以确保连接的正常关闭。这可以防止出现连接的半关闭状态，确保数据的可靠传输和连接的正常终止。
**注意：**
* 和`TCP`三次握手不同。`TCP`关闭连接的挥手足足有四次。这是因为第二次挥手和第三次挥手之间可能有一些服务端需要发送的处理比较慢的数据要返回，所以没有将这两次挥手合并。
* `TIME_WAIT`状态的存在是为了处理可能在网络中延迟的`ACK`包，以确保连接正常关闭。这个状态的持续时间相对较短，通常在几分钟内自动结束，以释放资源。
### 5.12 TCP前面加个防火墙，那TCP的包会在哪一步被拦截掉？
如果在`TCP`连接前面加上一个防火墙，那么`TCP`的数据包会在以下几个步骤被防火墙拦截：
1. 三次握手建立连接时，防火墙可以拦截`SYN`包，导致无法建立连接。
2. 数据传输过程中，防火墙可以拦截任何一个方向的`TCP`数据包。
3. 四次挥手断开连接时，防火墙可以拦截`FIN/ACK`包，导致无法正常断开。
4. 如果启用了状态检测，防火墙可以拦截不符合预期状态的`TCP`包。
5. 防火墙也可以拦截重传的`TCP`包。
6. 防火墙可以过滤指定端口的`TCP`包，直接阻止连接。
**总结：**
防火墙可以在`TCP`连接的任何一个阶段进行数据包的拦截、过滤或`state`检测，从而达到阻止某些连接或限制某些通信的目的。最直接的方法是直接过滤目标端口的`TCP`数据包。
### 5.13 TCP一个端口可以并发接收多少请求
`TCP`协议本身并没有限制一个端口能够接收的并发请求的数量，而是受限于多个因素，包括操作系统的设置、硬件资源、应用程序的设计和负载等。以下是影响一个端口能够接收多少并发请求的一些关键因素：
1. **操作系统的资源限制**：操作系统在内核级别管理网络连接，因此它会限制一个端口可以接受的并发连接数量。这个限制通常受操作系统的配置和资源限制（如文件描述符限制）的影响。不同的操作系统和版本可能会有不同的默认设置，但通常可以通过操作系统的配置来调整这些限制。
2. **硬件资源**：硬件资源如处理器、内存和网络适配器的性能也会影响一个端口能够处理的并发请求数量。更强大的硬件可以处理更多的并发连接。
3. **应用程序的设计**：应用程序的设计和实现方式对并发请求的处理有重要影响。例如，使用多线程或多进程模型可以提高并发性，或者使用事件驱动的非阻塞`I/O`可以有效地处理大量并发请求。
4. **负载均衡**：负载均衡器可以帮助分发来自不同客户端的请求到多个服务器端口上，从而提高整个系统的并发处理能力。
5. **请求处理时间**：请求处理的时间长度也会影响端口的并发请求处理能力。如果请求需要较长的时间来处理，那么端口可能会在某一时刻积累大量的等待请求。
6. **网络拓扑和带宽**：网络拓扑和带宽限制也可能对并发连接产生影响。如果网络连接速度较慢或带宽有限，那么可能会限制并发请求的处理速度。
需要注意的是，不同的应用场景和需求会对并发请求的要求产生不同的影响。因此，在设计和部署应用程序时，需要考虑到上述因素，并根据具体需求进行优化和配置，以确保能够满足所需的并发请求处理能力。同时，监测和性能测试也是评估系统能够处理多少并发请求的重要手段。
### 5.14 TCP可能有几万个、几十万个、上百万个链接都在这个端口上，怎么知道它是哪个链接，对应哪个用户，对应哪个请求？
`TCP`是传输层协议，可以通过上面的应用层以及以下条件获取到。
1. **源IP地址和目标IP地址**：每个`TCP`连接都有一个源`IP`地址和一个目标`IP`地址，通过这些`IP`地址，可以确定连接的两端。这可以帮助区分不同的用户或请求，特别是在多个客户端同时连接到同一个服务器端口的情况下。
2. **源端口和目标端口**：每个`TCP`连接都有一个源端口和一个目标端口。源端口通常是客户端随机选择的，而目标端口通常是服务器上监听的端口。通过这些端口，可以将连接与特定应用程序或服务相关联。
3. **会话标识符**：有些应用层协议在`TCP`连接上使用会话标识符或令牌，以将连接与特定的用户或请求相关联。例如，`HTTP`协议使用会话标识符来跟踪用户的会话状态。
4. **日志记录**：在服务器上，可以配置日志记录，以跟踪连接和请求的详细信息。通过查看服务器日志，可以了解哪个`IP`地址在哪个端口上建立了连接，以及与之相关的请求或操作。
5. **应用层协议**：有些应用层协议在其数据包中包含有关用户或请求的信息。例如，`HTTP`请求包括URL和`HTTP`头，这些信息可以帮助确定请求的内容和来源。
6. **网络分析工具**：网络分析工具可以用于监视和分析网络流量。可以使用这些工具来捕获和分析`TCP`数据包，以查看连接的详细信息，包括源`IP`、目标`IP`、源端口、目标端口等。
7. **负载均衡器和代理服务器**：如果有负载均衡器或代理服务器位于服务器端和客户端之间，它们通常会在处理连接时添加一些信息，以帮助将连接路由到正确的后端服务器或应用程序实例。
综合使用这些方法，可以帮助确定特定`TCP`连接对应哪个用户或请求。这在网络管理、安全监控和故障排除等方面都非常有用。不过，具体的方法可能因网络配置和应用程序的不同而异。
### 5.15 tcp粘包拆包是怎么发生的？该怎么解决？就是接到数据以后怎么解决呢？
参考1：[TCP粘包现象分析及处理方式]( )
#### 5.15.1 为什么TCP会粘包，UDP不会粘包
* `TCP`是面向流的的传输协议，发送端可以一次发送不定长度的数据，而接收端也可以一次提取不定长度的数据。即这种传输方式是无保护消息边界的。
* `UDP`是面向数据报的传输协议，发送的`UDP`报文都被接收端视为一条消息，若消息太长被分片，`UDP`协议也会完成组合后才呈现在内核缓冲区；且`UDP`报文有消息头，对于接收端来说，易于区分处理。即这种传输方式是有保护消息边界的。
#### 5.15.2 TCP粘包现象产生原因
发送方和接收方对数据的处理都有可能引发粘包现象。
* 发送方：`TCP`为了提高传输效率，会在收集到足够多数据后才一起发送，同时一条数据太长，`TCP`还会将数据进行拆分发生。这将会导致三种情况发生：
1. 多条数据被组合成一条数据发送。
2. 长数据被拆分成片段分别发送。
3. 长数据被拆分的片段和短数据一起发送。
* 接收方：接收方收到的数据会保存在缓存中，如果应用层提取数据不够快就会导致缓存中多条数据粘在一起。
#### 5.15.3 粘包处理方式
不是所有时候都要去处理粘包，比如类似于文件传输这样发送的数据无结构，那么接收方正常接受存储就行，不必考虑分包问题。
只有在`TCP`长链接且发送不同结构数据时（数据毫不相干，或者必须分开解读），那就需要处理粘包问题了。
##### 发送方的处理方式
可以关闭`Nagle`算法，通过`TCP_NODELAY`选项来关闭。缺点是`TCP`传输效率降低。
**`Nagle`算法主要做两件事：**
1. 只有上一个分组得到确认，才会发送下一个分组；
2. 收集多个小分组，在一个确认到来时一起发送。正是`Nagle`算法造成了发送方有可能造成粘包现象。
##### 接收方的处理方式
`TCP`中接收方无法处理！
##### 应用层的处理方式
**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**
**[需要这份系统化的资料的朋友，可以添加戳这里获取](https://bbs.csdn.net/topics/618658159)**
**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**
什么TCP会粘包，UDP不会粘包
* `TCP`是面向流的的传输协议，发送端可以一次发送不定长度的数据，而接收端也可以一次提取不定长度的数据。即这种传输方式是无保护消息边界的。
* `UDP`是面向数据报的传输协议，发送的`UDP`报文都被接收端视为一条消息，若消息太长被分片，`UDP`协议也会完成组合后才呈现在内核缓冲区；且`UDP`报文有消息头，对于接收端来说，易于区分处理。即这种传输方式是有保护消息边界的。
#### 5.15.2 TCP粘包现象产生原因
发送方和接收方对数据的处理都有可能引发粘包现象。
* 发送方：`TCP`为了提高传输效率，会在收集到足够多数据后才一起发送，同时一条数据太长，`TCP`还会将数据进行拆分发生。这将会导致三种情况发生：
1. 多条数据被组合成一条数据发送。
2. 长数据被拆分成片段分别发送。
3. 长数据被拆分的片段和短数据一起发送。
* 接收方：接收方收到的数据会保存在缓存中，如果应用层提取数据不够快就会导致缓存中多条数据粘在一起。
#### 5.15.3 粘包处理方式
不是所有时候都要去处理粘包，比如类似于文件传输这样发送的数据无结构，那么接收方正常接受存储就行，不必考虑分包问题。
只有在`TCP`长链接且发送不同结构数据时（数据毫不相干，或者必须分开解读），那就需要处理粘包问题了。
##### 发送方的处理方式
可以关闭`Nagle`算法，通过`TCP_NODELAY`选项来关闭。缺点是`TCP`传输效率降低。
**`Nagle`算法主要做两件事：**
1. 只有上一个分组得到确认，才会发送下一个分组；
2. 收集多个小分组，在一个确认到来时一起发送。正是`Nagle`算法造成了发送方有可能造成粘包现象。
##### 接收方的处理方式
`TCP`中接收方无法处理！
##### 应用层的处理方式
[外链图片转存中...(img-qnugNjx4-1715899823917)]
[外链图片转存中...(img-rTqIFss1-1715899823917)]
**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**
**[需要这份系统化的资料的朋友，可以添加戳这里获取](https://bbs.csdn.net/topics/618658159)**
**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
