2024年网络协议相关面试题及解答_网络协议面试(3)，Golang面试项目包装

最新推荐文章于 2024-07-13 20:38:58 发布

2401_84924864

最新推荐文章于 2024-07-13 20:38:58 发布

阅读量668

点赞数 11

文章标签： go 学习面试

本文链接：https://blog.csdn.net/2401_84924864/article/details/138931457

版权

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

1 Nginx

Nginx 极简教程（快速入门）
Nginx服务器高性能优化–轻松实现10万并发访问量

1.1 Nginx是什么

Nginx是一款开源的高性能、轻量级的Web服务器和反向代理服务器软件。可以用于HTTP、HTTPS、SMTP、POP3和IMAP协议。它可以实现非常高效的反向代理、负载平衡，可以处理2-3万并发连接数，官方监测能支持5万并发。

1.2 Nginx优点

高性能：Nginx以其出色的性能而闻名。它使用事件驱动的架构，可以处理大量并发连接，而且资源消耗较低，适合高流量的网站和应用程序。
低资源消耗：Nginx占用的系统资源相对较少，内存占用率低，这意味着可以在相同的硬件上服务更多的客户端请求。
负载均衡：Nginx支持多种负载均衡算法，可以将请求分发给多个后端服务器，以确保高可用性和性能。
反向代理：Nginx可以用作反向代理服务器，将客户端请求转发给后端服务器，以提供负载均衡、缓存、SSL、安全性等功能。
静态文件服务：Nginx能够高效地提供静态文件，如HTML、CSS、JavaScript和图像，减轻了后端服务器的负载。
SSL/TLS支持：Nginx支持SSL/TLS协议，可以用来加密连接，提供安全的HTTPS服务。
灵活的配置：Nginx的配置文件使用简洁的语法，易于理解和维护。可以轻松自定义各种设置，包括URL重写、重定向和HTTP头操作等。
模块化架构：Nginx的功能可以通过添加模块进行扩展，从而增加了定制和扩展的能力。
跨平台支持：Nginx可以在多种操作系统上运行，包括Linux、Windows、BSD等，因此适用于各种不同的环境。
活跃的社区和支持：Nginx有一个强大的社区，提供了广泛的文档、教程和插件，以及活跃的开发和维护团队，保证了持续的改进和更新。

1.3 Nginx应用场景

Web服务器：Nginx可用作传统的Web服务器，用于提供静态和动态内容，如HTML、CSS、JavaScript和后端应用程序生成的内容。
反向代理：Nginx常用作反向代理服务器，将客户端请求转发给后端服务器。这在负载均衡、缓存、SSL终结和应用程序加速方面非常有用。
负载均衡：Nginx支持多种负载均衡算法，可以将流量分发到多个后端服务器，以提高可用性和性能。这对于高流量的网站和应用程序非常重要。
缓存服务器：Nginx可以用作缓存服务器，将静态内容或动态内容的快照缓存起来，减轻后端服务器的负载，并提高响应速度。
SSL协议：Nginx可以终结SSL/TLS连接，将加密解密的负担从后端服务器卸载，从而提高性能和安全性。
反爬虫和安全性：Nginx可以配置用于拦截恶意爬虫、DDoS攻击和其他安全威胁的规则，提高应用程序的安全性。
URL重写和重定向：Nginx允许配置复杂的URL重写规则，用于更改URL结构、执行重定向或创建友好的URL。
静态文件服务：Nginx非常适合提供静态文件，如图像、音频和视频，特别是对于大型媒体站点或文件共享服务。
代理缓存：Nginx可以配置为代理和缓存外部资源，如API响应或静态文件，以减轻后端服务器的负载。
WebSocket代理：Nginx可以代理WebSocket连接，支持实时通信应用程序，如在线游戏、聊天和实时协作工具。
容器化部署：Nginx广泛用于容器化环境中，作为反向代理和负载均衡器，用于管理和路由容器之间的流量。
CDN（内容分发网络）：Nginx可以用于构建自定义CDN，加速内容分发并提供全球性能优化。

1.4 什么是正向代理

正向代理（Forward Proxy）是一种网络代理服务器的配置，它是代表客户端向外部服务器请求资源。在正向代理中，客户端不直接连接到目标服务器，而是通过正向代理服务器进行连接，然后由代理服务器将请求转发给目标服务器，最后将响应返回给客户端。正向代理典型代表是VPN，它的工作流程如下：

客户端配置：客户端需要配置使用正向代理服务器的地址和端口号。
请求发送：客户端发送请求到正向代理服务器。
代理服务器转发：正向代理服务器接收到客户端的请求后，它会像一个中间人一样，将请求转发给目标服务器。
目标服务器响应：目标服务器接收到来自代理服务器的请求，然后处理请求并发送响应。
响应返回：正向代理服务器将来自目标服务器的响应返回给客户端。

正向代理的主要特点和应用场景包括：

访问控制：正向代理可以用于访问控制，允许管理员限制特定客户端访问互联网资源，或者绕过地理位置限制。
隐私和匿名性：用户可以使用正向代理来隐藏其真实的IP地址，从而增强在线隐私和匿名性。
访问受限资源：有些互联网资源可能会限制特定地区或IP范围的访问。正向代理可以让用户绕过这些限制。
安全性：正向代理可以用于增加安全性，因为它可以在客户端和外部服务器之间添加一层防火墙，防止直接访问互联网。
内容过滤：管理员可以使用正向代理来过滤和监控客户端请求，以屏蔽或监测特定内容或域名。
加速访问：正向代理服务器可以缓存响应，从而加速客户端对相同资源的多次请求，减轻了目标服务器的负载。

总结：
正向代理充当了客户端和互联网资源之间的中间人，为客户端提供了一种访问外部资源的方式，同时可以增强隐私、安全性和控制访问。与之相反，反向代理是为了代表服务器向客户端提供服务，而正向代理是代表客户端向服务器请求资源。

1.5 什么是反向代理

反向代理（Reverse Proxy）是一种网络代理服务器的配置，它是代表服务器接收客户端的请求，然后将这些请求转发给内部服务器或资源。在反向代理中，客户端不直接连接到内部服务器，而是连接到反向代理服务器，然后由反向代理服务器根据请求的内容和规则来决定将请求转发给哪个内部服务器，并将内部服务器的响应返回给客户端。

反向代理的主要工作流程如下：

客户端发送请求：客户端发送请求到反向代理服务器，通常是对一个域名或IP地址的请求。
反向代理服务器接收请求：反向代理服务器接收到客户端的请求，并分析请求的内容。
决策和请求转发：根据一些规则和配置，反向代理服务器决定将请求转发给哪个内部服务器或资源。
内部服务器响应：内部服务器接收到来自反向代理服务器的请求，处理请求并生成响应。
响应返回：反向代理服务器将来自内部服务器的响应返回给客户端。

反向代理的主要特点和应用场景包括：

负载均衡：反向代理可以分发客户端请求到多个内部服务器，以平衡服务器负载，提高可用性和性能。
SSL协议：反向代理可以加入SSL/TLS连接，解密加密的流量，从而减轻了内部服务器的负担。
安全性：反向代理可以增强安全性，作为一道防火墙，过滤和检查客户端请求，以防止恶意流量和攻击。
缓存：反向代理可以缓存内部服务器生成的响应，以减轻服务器负载并加快响应速度。
Web应用防火墙（WAF）：反向代理可以用于实施Web应用防火墙，识别和阻止恶意请求，保护应用程序免受攻击。
内容压缩和优化：反向代理可以对响应进行压缩和优化，以减少带宽使用和提高页面加载速度。
集中化管理：反向代理提供了集中管理客户端请求和路由的能力，有助于简化系统管理和配置。
域名路由：反向代理可以根据域名或URL路径将请求路由到不同的内部服务器，用于多个虚拟主机或子域名的托管。

1.6 什么是CDN

CDN（Content Delivery Network）即内容分发网络，是一种用于提高网站和应用程序性能、可用性和安全性的网络基础架构。CDN通过将内容和数据分布到全球多个地理位置的服务器上，以减少用户访问内容时的延迟和带宽消耗。以下是CDN的主要特点和工作原理：

特点：

全球分布：CDN在全球范围内部署服务器，将内容和数据存储在离用户更近的地方，以减少数据传输的延迟。
负载均衡：CDN服务器通常使用负载均衡算法，将用户请求分发到最近的服务器，确保服务器资源充分利用并减轻负载。
内容缓存：CDN会缓存静态和动态内容，以减少源服务器的负载，提高响应速度，减少带宽成本。
DDoS防护：CDN通常具有强大的DDoS（分布式拒绝服务攻击）防护能力，可以帮助抵御网络攻击。
SSL协议：CDN可以加入SSL/TLS连接，减轻源服务器的负担，同时提供加密连接。
安全性：CDN可以提供安全性功能，如Web应用程序防火墙（WAF）和恶意流量过滤。
分级缓存：CDN可以配置为分层缓存，以根据内容类型和用户位置选择合适的缓存策略。

工作原理：

内容复制：网站或应用程序的静态和动态内容被复制到CDN的服务器上，通常由CDN提供商管理。
DNS解析：当用户发出请求时，他们的DNS解析请求被定向到最近的CDN服务器，而不是源服务器。
请求路由：CDN服务器接收到请求后，使用负载均衡算法将请求路由到最合适的缓存或源服务器。
内容提供：如果请求的内容存在于CDN缓存中，CDN服务器会立即提供缓存的内容。如果内容不在缓存中或者缓存已过期，CDN服务器会从源服务器获取最新内容，并在提供给用户之前缓存。
响应返回：CDN服务器将响应返回给用户，从而提供更快的响应时间和更好的性能。

CDN的主要优点包括提高网站和应用程序的加载速度，减轻源服务器的负载，提高可用性，减少带宽消耗，提供安全性和DDoS防护。许多大型网站和服务都依赖CDN来提供高质量的用户体验。常见的CDN提供商包括Akamai、Cloudflare、Amazon CloudFront、Fastly等。

1.7 Nginx的Upstream负载均衡策略

Nginx中的upstream模块允许配置负载均衡策略，以分发客户端请求到多个后端服务器。Nginx支持多种负载均衡算法，可以根据具体需求选择适合的策略。

轮询不需要特殊设置，是直接的默认方式。这三种方式优先级是不同，如下：

ip_hash > weight > 轮询

ip_hash是优先级最高，当配置了ip_hash，其他两种配置就会失效，只会根据ip_hash策略。配置了weight也是同样，轮询会失效。

下面是一些常见的Nginx负载均衡策略：

轮询（Round Robin）：这是默认的负载均衡策略。Nginx按顺序将每个新的请求分发给下一个后端服务器，依次循环。这对于均匀地分配请求到所有服务器很有用。

upstream backend {
    server server1.example.com;
    server server2.example.com;
}

权重（Weighted Round Robin）：可以为每个后端服务器分配不同的权重，以控制流量分发的比例。较高权重的服务器会获得更多的请求。

upstream backend {
    server server1.example.com weight=3;
    server server2.example.com weight=2;
    server server3.example.com weight=1;
}

IP哈希（IP Hash）：Nginx使用客户端的IP地址来选择一个后端服务器。这对于确保特定客户端的请求始终路由到同一个服务器很有用，例如会话保持。

upstream backend {
    ip_hash;
    server server1.example.com;
    server server2.example.com;
}

最少连接（Least Connections）：Nginx会将新的请求路由到当前连接数最少的后端服务器，以平衡服务器的负载。

upstream backend {
    least_conn;
    server server1.example.com;
    server server2.example.com;
}

基于响应时间的负载均衡：Nginx可以根据后端服务器的响应时间来分配请求。它会优先选择响应时间较短的服务器。

upstream backend {
    least_time first_byte;
    server server1.example.com;
    server server2.example.com;
}

备用服务器（Backup Servers）：可以指定一个或多个备用服务器，当所有主要服务器都不可用时，请求将被路由到备用服务器。

upstream backend {
    server server1.example.com;
    server server2.example.com backup;
}

1.8 Nginx如何配置长连接

HTTP块配置：首先，需要在Nginx配置中找到或创建一个HTTP块。在这个块内部，可以配置全局的HTTP选项。

http {
	keepalive_timeout 120s;
	keepalive_requests 10000;
}

keepalive_timeout：HTTP连接的最大空闲时间（以秒为单位）。在超过这个时间后，连接将被关闭，为0的时候禁用长连接。
keepalive_requests：设置一个客户端可以在单个连接上发送的最大请求数。设置它有助于防止单个连接过度使用资源。当达到最大请求数目且所有已有请求结束后，连接被关闭，默认值为100。

配置Server块：在Nginx配置中，找到或创建一个Server块，通常是用于特定虚拟主机或站点的配置。在该块内，可以进一步配置长连接相关的选项。

server {
    listen 80;
    server_name example.com;

    # 其他服务器配置

    location / {
        # 配置代理或处理长连接的方式
    }
}

处理长连接方式：根据需求，可以在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里有哪些常见的请求方法？

GET：用于请求服务器发送特定资源（通常是网页或文件）。GET请求是幂等的，它只是从服务器获取信息，不应该对服务器状态产生影响。
POST：用于向服务器提交数据，通常用于提交表单数据或执行对服务器状态产生影响的操作。POST请求不幂等，因为它可能会修改服务器上的数据。
PUT：用于请求服务器存储一个资源，通常用于更新或创建资源。PUT请求是幂等的，多次相同的PUT请求应该具有相同的结果。
DELETE：用于请求服务器删除指定的资源。DELETE请求是幂等的，多次相同的DELETE请求应该具有相同的结果。
HEAD：类似于GET请求，但不返回响应正文。它用于获取与GET请求相同的响应头信息，但不获取响应正文，通常用于检查资源的元数据或确认资源是否存在。
OPTIONS：用于请求服务器提供有关资源的通信选项，例如支持的请求方法、允许的来源等信息。它用于CORS（跨域资源共享）和预检请求。
PATCH：用于部分更新资源，通常用于更新资源的一部分而不是整个资源。PATCH请求是幂等的，多次相同的PATCH请求应该具有相同的结果。
TRACE：用于在调试和诊断中回显服务器接收到的请求，通常不常用，并且可能会存在安全风险。
CONNECT：用于在客户端和服务器之间建立网络连接，通常用于代理服务器。它用于将客户端连接到目标服务器。

2.2 HTTP的长连接和短连接有什么区别

参考1：http的长连接和短连接的区别

长连接与短连接介绍

长连接：客户端与服务端先建立连接，连接建立后不断开，以便在一段时间内进行多次请求和响应。这减少了TCP连接的建立和关闭的开销。
短连接：客户端与服务端每个HTTP请求都会建立一个新的TCP连接，并在请求完成后立即关闭连接。

长连接与短连接的操作过程

长连接的操作步骤是：建立连接——数据传输…（保持连接）…数据传输——关闭连接。
短连接的操作步骤是：建立连接——数据传输——关闭连接…建立连接——数据传输——关闭连接。

长连接与短连接的使用时机

长连接：长连接多用于操作频繁，点对点的通讯，而且连接数不能太多的情况。每个TCP连接的建立都需要三次握手，每个TCP连接的断开要四次握手。

如果每次操作都要建立连接然后再操作的话处理速度会降低，所以每次操作下次操作时直接发送数据就可以了，不用再建立TCP连接。

适用于客户端和服务端通信频繁的场景，例如聊天室，实时游戏，数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，频繁的socket创建也是对资源的浪费。
2. 短连接：适用于一次性请求和响应的情况，例如普通的网页浏览，其中每个资源都是单独请求的。

2.3 HTTP的状态码，504有遇到过吗

1xx - 信息性状态码：

100 Continue（继续）：客户端可以继续发送请求。通常用于客户端发送带有大型请求体的POST请求，服务器在接收一部分后发送此状态码以通知客户端继续发送。
101 Switching Protocols （切换协议）：服务器已经理解客户端的请求，将切换到不同的协议，如WebSocket。

2xx - 成功状态码：

200 OK（成功）：服务器已成功处理了请求。
201 Created（已创建）：请求成功并且服务器创建了新的资源。
202（已接受）：服务器已接受请求，但尚未处理。
204 No Content（无内容）：服务器成功处理了请求，但没有返回任何内容。一般在只需要从客户端往服务器发送信息，而对客户端不需要发送新信息内容的情况下使用。

3xx - 重定向状态码：

301 Moved Permanently（永久移动）：资源被永久性移动到了新的URL。客户端应该使用新的URL重新请求。
302 Found（临时移动）：资源被临时性移动到了新的URL。客户端应该使用新的URL重新请求。

4xx - 客户端错误状态码：

400 Bad Request（错误请求)：服务器端无法理解客户端发送的请求，请求报文中可能存在语法错误。
401 Unauthorized(未授权) ：需要身份验证才能访问资源。
403 Forbidden（禁止)：服务器拒绝了请求，通常由于权限问题。
404 Not Found（未找到)：请求的资源不存在。
405（方法禁用) ：禁用请求中指定的方法。

5xx - 服务器错误状态码：

500 Internal Server Error（服务器内部错误）：服务器在处理请求时发生了内部错误。
502 Bad Gateway：服务器作为网关或代理服务器时，从上游服务器接收到无效的响应。
503（服务不可用）：服务器当前无法处理请求，通常由于过载或维护。
504 Gateway Timeout（网关超时）：服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505（HTTP 版本不受支持）：服务器不支持请求中所用的HTTP协议版本。

2.4 GET和POST的区别

数据传输方式
- GET：GET请求将数据附加在URL的末尾，以查询字符串的形式发送。数据以键值对的形式出现在URL中，使用?分隔参数，使用&分隔多个参数。由于数据在URL中可见，GET请求不适合传输敏感信息。
- POST：POST请求将数据包含在请求的正文中，而不是在URL中。因此，POST请求对于传输敏感信息更安全，因为数据不会在URL中可见。POST请求通常用于提交表单数据、上传文件等情况。
请求长度
- GET：由于数据附加在URL上，GET请求对于发送的数据长度有限制，通常在2048个字符左右，这取决于浏览器和服务器的配置。因此，GET请求适合用于发送较小的数据。
- POST：POST请求没有特定的长度限制，可以用于发送较大的数据，例如上传文件或包含大量文本的表单。
可见性
- GET：由于GET请求中的数据出现在URL中，因此数据是可见的，容易被用户和浏览器记录。这使得GET请求适合用于书签、历史记录等场景。
- POST：POST请求中的数据在请求正文中，不会显示在URL中，因此更适合用于传输敏感数据，但不能像GET请求那样轻松地进行书签和共享。
缓存
- GET：由于GET请求是幂等的，可以被浏览器和代理服务器缓存，以提高性能。
- POST：POST请求通常不会被缓存，因为它们可能会导致服务器状态的变化。
请求幂等性
- GET：GET请求是幂等的，多次发送相同的GET请求应该产生相同的结果，而不会对服务器状态产生影响。它通常用于获取资源或执行只读操作。
- POST：POST请求通常不是幂等的，多次发送相同的POST请求可能会对服务器状态产生不同的影响，因为它通常用于提交数据或执行会修改服务器状态的操作。

2.5 什么是无状态协议，HTTP是无状态协议吗，怎么解决

无状态协议（Stateless Protocol）是指协议在处理请求时不会记住之前的请求或会话信息，每个请求都是独立的，服务器不会保存客户端的状态信息。

HTTP是一种无状态协议，每个HTTP请求都是相互独立的，服务器不会记住之前的请求或会话信息。这意味着服务器无法直接识别多个请求之间的关联，每个请求都需要提供足够的信息来说明其意图。

为了解决HTTP的无状态性，通常使用以下方法：

Cookies：Cookies是一种在客户端和服务器之间存储状态信息的机制。服务器可以在响应中设置一个Cookie，客户端将它保存并在后续的请求中发送回服务器。这允许服务器跟踪客户端的会话信息，例如用户的登录状态或购物车内容。
会话管理：服务器可以为每个客户端创建一个唯一的会话标识符（Session ID），并在客户端的请求中包含该标识符。服务器可以使用会话标识符来关联多个请求，从而跟踪用户的会话状态。
URL参数：在URL中包含参数来传递状态信息。这通常用于在Web应用程序中实现RESTful API，但不适合敏感信息，因为参数在URL中可见。
隐藏表单字段：在HTML表单中添加隐藏字段来传递状态信息。这通常用于Web应用程序，以便在不使用Cookies的情况下维护会话状态。
URL重写：一些Web框架和服务器可以通过URL重写来隐藏会话标识符，以改善安全性和可用性。
JWT（JSON Web Tokens）：JWT是一种用于在客户端和服务器之间传递可验证的信息的标准。它可以包含有关用户身份和状态的信息，并由服务器签名以确保数据的完整性和安全性。

2.6 HTTP请求的组成

参考1：Http协议的组成

请求行（Request Line）：请求行是HTTP请求的第一行，包含了以下三个要素：
- 请求方法（HTTP Method）：指定客户端的动作或操作类型，比如GET、POST、PUT、DELETE等。
- 请求的资源路径（Request URI）：指定要请求的资源的路径，通常是相对于服务器的根目录的路径，例如/index.html。
- 协议版本（HTTP Version）：指定使用的HTTP协议版本，例如HTTP/1.1。
请求头部（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

HTTP请求的请求头
3. 空行（Blank Line）：请求行和请求头部之间必须有一个空行，用于分隔头部信息和请求正文。
4. 请求正文（Request Body）：请求正文是可选的，通常用于包含客户端向服务器发送的数据，例如表单数据或请求主体。请求正文的存在和格式取决于请求的方法和目的。

当请求方式是POST时，请求体会有请求参数格式如下：

username=zhangsan&password=123

当请求方式时GET时，请求参数是不会出现在请求体中，会拼接在URL地址后面：

http://localhost:8080...？username=zhangsan&password=123

2.7 HTTP响应的组成

状态行（Status Line）：状态行是HTTP响应的第一行，包含了以下三个要素：
- 协议版本（HTTP Version）：指定使用的HTTP协议版本，例如HTTP/1.1。
- 状态码（Status Code）：指定了响应的处理结果，是一个三位数的数字，例如200表示成功，404表示资源未找到。
- 状态消息（Status Message）：与状态码相关的人类可读的描述，用于提供关于状态码的更多信息。
响应头部（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

HTTP响应的响应头
3. 空行（Blank Line）：状态行和响应头部之间必须有一个空行，用于分隔头部信息和响应正文。
4. 响应正文（Response Body）：响应正文包含了服务器返回给客户端的实际数据。它的内容和格式取决于响应的性质，例如在HTML页面请求中，响应正文通常包含HTML文档；在文件下载请求中，响应正文包含文件内容。
例如：

<!DOCTYPE html>
<html>
<head>
    <title>Example Page</title>
</head>
<body>
    <h1>Hello, World!</h1>
</body>
</html>

2.8 Cookies机制和Session机制的区别

Cookies机制和Session机制都是用于在Web应用程序中跟踪用户状态和维护会话信息的方式，但它们在实现和工作原理上有一些重要的区别：

存储位置
- Cookies：Cookies是在客户端（通常是浏览器）中存储的小型文本文件。服务器在响应中设置Cookies，然后浏览器将它们存储在客户端的文件系统中。每次请求都会将Cookies发送回服务器，以便服务器可以读取和修改它们。
- Session：Session数据通常存储在服务器上。服务器为每个会话创建一个唯一的标识符（通常是会话ID），并将此标识符存储在Cookies中或通过URL参数传递给客户端。然后，服务器使用这个标识符来查找和维护与客户端会话相关的数据。
数据存储
- Cookies：Cookies可以存储在客户端的浏览器中，但由于安全性和隐私考虑，通常只存储一些小型的标识符或少量的非敏感数据。Cookies通常有大小限制（通常是几KB）。
- Session：Session数据存储在服务器上，可以存储大量的数据，包括敏感信息。服务器根据会话ID来关联客户端的数据，因此客户端无法直接访问或修改会话数据。
生命周期
- Cookies：Cookies可以具有不同的生命周期。它们可以是会话Cookies，只在浏览器会话期间存在，或者可以设置为持久Cookies，可以在指定的时间段内存在。
- Session：Session数据通常与用户会话相关联，一旦会话结束，通常会话数据也会被销毁。会话的生命周期通常由服务器管理，可以在服务器上配置。
安全性
- Cookies：Cookies可以存储在客户端，因此可能会受到一些安全威胁，例如跨站脚本攻击（XSS）或跨站请求伪造攻击（CSRF）。为了增加安全性，Cookies可以标记为HTTP Only，以防止JavaScript访问它们。
- Session：Session数据通常存储在服务器上，客户端无法直接访问或修改它们，因此通常比Cookies更安全。
性能
- 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，超文本传输协议）都是用于不同系统之间通信的协议，但它们在工作方式和应用领域上有一些重要的区别：

通信模型
- RPC：RPC是一种远程通信协议，用于不同计算机或进程之间的函数调用。它允许一个程序在另一个程序上调用函数，就像本地函数一样，而不需要直接管理底层通信细节。RPC通常用于跨越网络的分布式应用程序。
- HTTP：HTTP是一种应用层协议，用于在客户端和服务器之间传输超文本文档和其他资源。HTTP通常用于Web应用程序中，它的主要目标是在浏览器和服务器之间传递HTML页面、图像、样式表和其他Web资源。
数据格式
- RPC：RPC协议可以使用多种数据格式，如XML-RPC、JSON-RPC、Protocol Buffers等，用于序列化和反序列化函数参数和返回值。
- HTTP：HTTP主要使用文本或二进制格式来传输数据。通常，HTTP使用HTML、XML、JSON等格式来表示资源。
通信方式
- RPC：RPC通常采用请求-响应方式进行通信。客户端发起请求，服务器执行请求并返回响应。
- HTTP：HTTP也使用请求-响应模型，但它可以支持不同的HTTP方法（如GET、POST、PUT、DELETE）来表示不同的操作，从而实现更复杂的交互。
应用场景
- RPC：RPC通常用于构建分布式系统，例如微服务架构，其中不同的服务需要相互调用。它更适合用于应用程序内部的通信，以便不同的组件之间可以相互调用函数。
- HTTP：HTTP主要用于构建Web应用程序，支持浏览器与服务器之间的通信。它适用于提供Web页面、API、资源传输和Web服务。
协议与规范
- 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握手过程：

建立TCP连接：HTTP通常在传输层使用TCP协议。客户端首先与服务器的IP地址和端口建立TCP连接。这是一个三步握手的过程，包括客户端发送一个SYN包（请求建立连接），服务器回应SYN-ACK包（确认并同意建立连接），最后客户端发送ACK包（确认连接建立）。
客户端发送HTTP请求：一旦TCP连接建立，客户端可以发送HTTP请求。HTTP请求由HTTP方法（如GET、POST、PUT等）、请求头（包括主机名、User-Agent等信息）和请求体（如果有的话）组成。
服务器接收和处理请求：服务器接收到客户端的HTTP请求后，会根据请求中的信息进行处理。这可能包括查找请求的资源、执行相关操作或生成HTTP响应。
服务器发送HTTP响应：服务器生成HTTP响应，包括响应状态码、响应头和响应体。响应状态码指示请求的结果，如200表示成功，404表示资源未找到，500表示服务器内部错误等。
客户端接收HTTP响应：客户端接收到服务器的HTTP响应后，会解析响应，处理响应头和响应体，并采取相应的行动，例如渲染网页内容或执行其他操作。
关闭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）协议是两种不同的协议，但它们之间存在一定的关系。以下是它们之间的一些关键区别和联系：

协议类型：
- HTTP是一种请求-响应协议，通常用于在客户端和服务器之间传输文本和二进制数据。它是无状态的，每个请求和响应之间是独立的。
- WebSocket是一种全双工通信协议，允许在客户端和服务器之间建立持久连接，实现实时的双向通信。它是建立在HTTP基础上的协议，通过HTTP/1.1协议的升级机制实现。
握手过程：
- HTTP协议是基于请求-响应模型的，每次通信都需要进行握手，发送请求并等待服务器的响应。这种模式适用于单次请求的场景。
- WebSocket则是通过HTTP握手建立连接，之后就可以在已建立的连接上进行双向通信，无需重新握手。WebSocket握手通常使用HTTP协议的升级头（Upgrade Header）来切换协议。
持久连接：
- HTTP是一种短连接协议，每次请求和响应之间都会关闭连接，需要重新建立连接。
- WebSocket是一种长连接协议，通过在握手时建立的连接，保持连接的状态，使得客户端和服务器可以在连接上进行实时的双向通信。
数据格式：
- HTTP数据的传输通常使用明文的文本或者二进制格式，如JSON或XML。
- WebSocket允许在已建立的连接上直接发送二进制数据，同时也支持文本数据的传输。
端口：
- 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）是两种用于在客户端和服务器之间传输数据的协议，它们之间的主要区别在于安全性和数据传输方式：

安全性
- HTTP：HTTP是一种不安全的协议，数据在传输过程中以明文形式传输。这意味着如果恶意方在网络中截取HTTP通信，他们可以轻松地读取和修改传输的数据，包括敏感信息，如用户名、密码、信用卡号等。因此，HTTP不适合用于传输敏感信息的应用程序。
- HTTPS：HTTPS是HTTP的安全版本，使用SSL/TLS协议进行数据加密和身份验证。通过HTTPS传输的数据被加密，因此即使被截取，也无法轻松读取或修改。HTTPS通信使用公钥和私钥，确保客户端和服务器之间的通信是安全的。这使得HTTPS非常适合用于处理敏感信息的应用程序，如在线支付、网上银行、电子邮件等。
URL前缀
- HTTP：HTTP网站的URL通常以"http://"开头，例如：http://www.example.com。
- HTTPS：HTTPS网站的URL通常以"https://"开头，例如：https://www.example.com。
端口
- HTTP：HTTP默认使用端口80进行通信。
- HTTPS：HTTPS默认使用端口443进行通信。
证书
- HTTP：HTTP不需要使用数字证书，因为它不提供加密和身份验证。
- HTTPS：为了建立HTTPS连接，服务器需要使用数字证书来验证其身份。客户端会验证证书的有效性，并确保与服务器的通信是加密的。证书通常由受信任的第三方机构颁发，以确保服务器的身份。
性能
- HTTP：HTTP通信速度较快，因为不需要加密和解密数据，但不安全。
- HTTPS：HTTPS通信速度较慢，因为需要加密和解密数据，但更安全。

总结：
HTTP和HTTPS之间的主要区别在于安全性。HTTP是一种不安全的协议，适用于不涉及敏感信息的普通网站，而HTTPS通过加密和身份验证提供了更高的安全性，适用于需要保护敏感信息的应用程序。在现代互联网中，推荐在处理用户数据时使用HTTPS以提供更高的安全性。

3.2 HTTPS实现原理

HTTPS（Hypertext Transfer Protocol Secure）实现了HTTP协议的安全版本，其主要原理是通过加密和身份验证来确保通信的机密性和完整性。HTTPS的实现原理涉及以下关键概念和步骤：

加密通信
- 对称加密：在HTTPS通信开始时，客户端和服务器之间建立一个对称密钥，该密钥用于加密和解密通信中的数据。对称密钥是一种快速加密和解密数据的方法，但必须在通信开始时安全地传输。
- 非对称加密：在对称密钥协商期间，服务器会向客户端发送自己的CA证书，证书里包含公钥，客户端使用该公钥加密对称密钥，然后将其发送回服务器。服务器使用其私钥解密对称密钥。这个过程称为非对称加密，其中公钥用于加密，私钥用于解密。
数字证书
- 服务器通常需要通过数字证书来验证其身份。数字证书由受信任的第三方证书颁发机构（Certificate Authority，CA）签发，包含了服务器的公钥和与服务器相关的信息，同时也包含CA的数字签名。客户端可以使用CA的公钥来验证服务器证书的有效性，确保连接到的服务器是合法的。
握手过程：当客户端尝试连接到HTTPS服务器时，会发生一个握手过程，其中包括以下步骤：
1. 客户端向服务器发送一个随机数和支持的加密算法列表。
2. 服务器选择一个加密算法和使用自己的私钥生成一个随机数，然后将这些信息与数字证书一起发送给客户端。
3. 客户端使用服务器的公钥解密服务器发送的信息，并验证证书的有效性。如果一切正常，客户端生成一个会话密钥（对称密钥），然后使用服务器的公钥加密该密钥并发送回服务器。
4. 服务器使用其私钥解密会话密钥，然后双方都具备了相同的对称密钥，用于加密和解密通信数据。
加密通信：一旦握手成功，客户端和服务器之间的通信将使用对称密钥进行加密和解密。这确保了数据在传输过程中的机密性和完整性，使第三方无法轻松地读取或修改数据。

总结：
HTTPS的实现原理涉及使用对称和非对称加密，数字证书以及握手过程来确保通信的安全性。客户端和服务器之间的通信在加密的环境下进行，同时服务器的身份也得到验证，以防止中间人攻击和数据泄漏。这使得HTTPS成为保护敏感信息和确保通信隐私的重要工具。

3.3 CA的数字证书中包括哪些信息

参考：查看google浏览器里的证书

颁发者（Issuer）：证书颁发机构（CA）的名称和相关信息，用于标识颁发该证书的机构。
颁发对象：证书持有者的相关信息。
主题（Subject）：证书持有者（通常是网站）的名称和相关信息，用于标识该证书所属实体。
公钥（Public Key）：证书持有者的公钥，用于加密通信和验证数字签名。
有效期（Validity）：证书的生效日期和失效日期，指示证书的有效期限。
序列号（Serial Number）：证书的唯一序列号，用于标识该证书的唯一性。
签名算法（Signature Algorithm）：用于生成证书签名的算法类型，例如RSA、DSA、ECDSA等。
签名（Signature）：由证书颁发机构使用其私钥对证书数据进行签名生成的数字签名，用于验证证书的完整性和真实性。
扩展字段（Extensions）：包含一些额外的信息，如证书用途、密钥用法、颁发者信息等。

这些信息组成了证书数据的主要内容，用于验证证书的有效性和真实性。浏览器和其他应用程序使用这些信息来建立信任链，确认证书的合法性，并确保安全的通信。

3.4 SSL建立连接过程

SSL（Secure Sockets Layer，安全套接字层）是一种用于在网络上建立安全连接的协议，它的后续版本被称为TLS（Transport Layer Security，传输层安全性）。SSL/TLS协议的建立连接过程通常包括以下步骤：

客户端Hello：客户端向服务器发送一个ClientHello消息，其中包含以下信息：
1. 客户端支持的SSL/TLS协议版本。
2. 一个随机数，该随机数将用于生成会话密钥。
3. 支持的密码套件列表，包括加密算法、哈希算法等。
服务器Hello
1. 服务器从客户端发送的ClientHello消息中选择一个支持的SSL/TLS协议版本。
2. 服务器生成一个随机数，将其发送给客户端。
3. 服务器选择一个密码套件，通知客户端使用哪种加密算法和哈希算法。
4. 服务器发送其数字证书，证书包含服务器的公钥以及与证书相关的信息。
身份验证和密钥交换
1. 客户端验证服务器的证书有效性。包括检查证书是否过期、证书颁发机构是否可信任，证书的颁发机构（CA）的信任链，以确保服务器的身份。
2. 客户端生成一个预主密钥（Pre-Master Secret），并使用数字证书的公钥加密它，然后发送给服务器。
3. 服务器使用其私钥解密客户端发送的预主密钥，然后双方都使用预主密钥生成主密钥（Master Secret）。
会话密钥的生成
1. 客户端和服务器使用各自的随机数以及主密钥生成会话密钥。
2. 会话密钥是对称密钥，用于加密和解密通信中的数据。
完成握手
1. 客户端发送一个Finished消息，该消息包含前面握手消息的哈希值，以验证握手消息的完整性。
2. 服务器发送一个Finished消息，同样包含前面握手消息的哈希值。
3. 一旦客户端和服务器都收到对方的Finished消息，握手过程完成。
安全通信
现在，客户端和服务器都使用会话密钥加密和解密通信中的数据。通信过程中的数据都会使用这个密钥进行保护。

一旦握手完成，SSL/TLS会话建立，双方可以安全地通信，保护数据的机密性和完整性。这个过程确保了通信双方的身份验证、密钥交换和安全通信。一旦建立了SSL/TLS连接，通信双方可以开始在加密的环境中传输数据，防止数据泄露和中间人攻击。这是安全的HTTPS连接的基础。

3.5 HTTPS的加密协议是什么

HTTPS（Hypertext Transfer Protocol Secure）的加密协议通常是TLS（Transport Layer Security，传输层安全性）协议。TLS是SSL（Secure Sockets Layer，安全套接字层）的后续版本，目前广泛用于保护网络通信的安全性。TLS协议提供了数据的加密、完整性验证和身份验证，以确保通信在传输过程中是安全的。

TLS协议的核心功能包括：

加密：TLS使用对称密钥和非对称密钥加密算法来保护数据的机密性，防止第三方截取和读取数据。
完整性验证：TLS使用哈希函数来验证数据的完整性，确保数据在传输过程中没有被篡改。
身份验证：TLS通过数字证书来验证通信双方的身份，确保客户端连接到的服务器是合法的。

总结：
HTTPS的加密协议通常是TLS，它通过加密、完整性验证和身份验证来保护网络通信的安全性。选择TLS的版本取决于安全性要求和兼容性考虑。

3.6 HTTPS怎么保证服务器给客户端下发的公钥是真正的公钥，而不是中间人伪造的公钥呢？

HTTPS通过数字证书来确保客户端收到的服务器公钥是真实有效的，而不是中间人伪造的公钥。这是通过以下方式实现的：

数字证书：服务器必须获得数字证书，由受信任的第三方机构（Certificate Authority，CA）颁发。数字证书包含以下信息：
1. 服务器的公钥。
2. 服务器的标识信息，如域名。
3. CA的数字签名。
CA信任链：客户端的浏览器或操作系统内置了一组受信任的根证书颁发机构（Root Certificate Authorities）。这些根CA的公钥已被预安装在客户端设备中，并被广泛信任。服务器的数字证书必须由其中一个受信任的CA颁发，否则客户端将不信任该证书。
数字签名验证：当客户端连接到服务器时，服务器会将其数字证书发送给客户端。客户端使用预先安装的根CA的公钥来验证服务器证书的数字签名。如果数字签名验证通过，客户端就可以确信证书是由受信任的CA颁发的。
域名匹配：客户端还会检查证书中的域名信息是否与用户试图连接的域名匹配。这是为了防止中间人攻击，其中攻击者可能会伪造证书，并尝试欺骗客户端连接到错误的服务器。

总结：
HTTPS通过数字证书和CA信任链来确保服务器提供的公钥是真实有效的。只有在证书由受信任的CA颁发，并且数字签名验证通过且域名匹配时，客户端才会信任服务器的公钥。这种机制防止了中间人攻击，确保了通信的安全性和服务器的身份验证。如果数字证书无效或被篡改，客户端将拒绝建立连接。

3.7 第三方攻击者能否让自己的证书显示出来的信息也是服务端呢？

第三方攻击者（中间人攻击者）通常无法获得合法服务器的有效数字证书，因为服务器的数字证书是由受信任的证书颁发机构（CA）颁发的，而CA通常会执行严格的验证程序来确保只有合法服务器才能获得证书。但中间人攻击者可以尝试使用自己伪造的证书来欺骗客户端，称为自签名证书，以尝试进行攻击。

中间人攻击的工作原理通常如下：

攻击者与客户端建立加密通道，同时与服务器建立另一个加密通道。攻击者同时伪装成客户端和服务器。
攻击者向客户端提供自己伪造的数字证书，宣称它是服务器的数字证书。
客户端通常会尝试验证伪造证书的有效性，但攻击者可以提供自己伪造的根证书，声称它是受信任的CA的根证书。如果客户端不对证书进行严格的验证，它可能会相信攻击者伪造的证书。
一旦客户端相信了攻击者伪造的证书，它会使用攻击者提供的公钥来加密通信数据，攻击者也可以解密这些数据，然后将其重新加密并传递给真正的服务器。
攻击者以类似的方式伪装成客户端，向服务器发送数据，然后将服务器的响应重新加密并传递给客户端。这使得攻击者可以窃听、修改或篡改通信内容。

为了防止中间人攻击，客户端应严格验证服务器的数字证书，确保它是由受信任的CA颁发的，而且证书中的信息与服务器的域名匹配。此外，服务器也可以采用一些安全措施，如公钥固定（Pin）或使用证书透明度（Certificate Transparency）来增加安全性。如果客户端在验证数字证书时发现任何问题，应立即中断连接，以防止建立不安全的通信渠道。

3.8 HTTPS优缺点

HTTPS（Hypertext Transfer Protocol Secure）是一种用于在网络上建立安全连接的协议，它通过数据加密、身份验证和完整性验证来保护通信的安全性。HTTPS具有许多优点，但也有一些缺点。

优点：

数据加密：HTTPS使用加密算法来保护数据在传输过程中的机密性。这意味着即使数据被截取，也无法轻松读取其内容，因此能够有效防止信息泄漏。
完整性验证：HTTPS使用哈希函数来验证数据的完整性，确保数据在传输过程中没有被篡改。这有助于防止中间人攻击和数据篡改。
身份验证：HTTPS通过数字证书来验证服务器的身份。客户端可以确保连接到的服务器是合法的，这防止了伪装和中间人攻击。
用户信任：HTTPS使用受信任的第三方证书颁发机构（CA）颁发的数字证书。这增加了用户对网站的信任，因为他们可以相信其连接是安全的。
SEO优化：搜索引擎（如Google）更喜欢使用HTTPS保护的网站，因此使用HTTPS可以提高网站的搜索引擎排名。
法规合规性：许多法规和合规性要求要求网站使用HTTPS来保护用户数据，特别是对于敏感信息的处理，如支付信息和个人身份信息。
Cookie安全：HTTPS可以帮助防止Cookie劫持攻击，因为Cookie在传输过程中也会被加密。

缺点：

性能开销：加密和解密数据会引入一些性能开销，使HTTPS通信相对于HTTPS略显慢一些。然而，现代硬件和TLS协议的改进已经减小了这种性能开销。
成本：获得有效的数字证书可能需要支付一些费用，尤其是如果选择使用受信任的商业CA颁发的证书。
配置和维护：配置和维护HTTPS服务器可能比HTTP更复杂，尤其是在大型网络中。
不是绝对安全：虽然HTTPS提供了很高的安全性，但它也不是绝对安全的。它仍然可能受到一些攻击，如某些类型的中间人攻击或恶意软件感染。

总结：
HTTPS在保护通信的安全性和隐私方面具有很大的优势，尤其是在处理敏感信息的应用程序中。然而，它也需要考虑性能开销和一些配置和维护工作。对于大多数Web应用程序来说，使用HTTPS是非常值得的，因为它提供了必要的保护和用户信任。

3.9 HTTPS的证书是谁验证谁

在HTTPS通信中，数字证书的验证过程如下：

证书颁发机构(CA)验证网站的身份并向其颁发证书。
网站将证书发送给访问的客户端。
客户端获取证书后，验证证书的颁发机构是否为可信的CA。
客户端验证证书的内容是否与网站地址匹配。
如果一切验证通过，客户端就可以信任该证书真实属于该网站。

所以简单来说：

CA验证网站，向网站颁发证书。
客户端验证CA是否可信任，以及证书是否与网站匹配。
最后客户端验证证书的有效性和网站的合法性。

总结：
HTTPS证书验证中，CA验证网站，而用户验证CA和证书本身。这个双向验证机制让HTTPS证书系统能够安全可靠地运行。

3.10 HTTPS单向认证时谁验证谁

在HTTPS单向认证中，一般情况下是客户端验证服务器的身份，而不是服务器验证客户端的身份。这是HTTPS的标准配置方式，也被称为单向SSL认证。

HTTPS通信中的验证通常如下：

服务器验证：服务器获得数字证书，其中包含服务器的公钥以及一些服务器相关的信息，如域名。服务器将其数字证书发送给客户端。
客户端验证（可选）：在标准的单向SSL认证中，客户端可以选择验证服务器的证书。客户端使用受信任的根CA的公钥来验证服务器证书的有效性，包括证书的签名和域名匹配。如果客户端选择验证服务器的证书并且验证通过，它可以信任服务器的身份。
连接建立：一旦服务器的证书被验证通过（如果客户端进行了验证），客户端和服务器之间建立连接，并使用服务器的公钥加密通信数据。

总结：
HTTPS的标准配置中，通常是客户端验证服务器的身份，而服务器通常不验证客户端的身份。客户端通过验证服务器的证书来确保连接到的服务器是合法的，从而防止中间人攻击。如果需要服务器验证客户端的身份，可以使用双向认证（双向SSL认证）来实现，其中客户端和服务器都会验证对方的身份。

3.11 HTTPS客户端如何验证服务端证书的合法性

在HTTPS通信中，客户端通过验证服务器证书的合法性来确认连接到的服务器的身份。这个验证过程通常包括以下步骤：

获取服务器证书：服务器在握手过程中将其数字证书发送给客户端。
验证证书的签发机构（CA）：客户端使用本地受信任的根证书颁发机构（CA）的公钥来验证服务器证书是否由受信任的CA签发。根证书通常是预装在操作系统或浏览器中的。
验证证书的有效期：客户端检查服务器证书的有效期，确保它没有过期。如果证书已过期，客户端将认为连接不安全。
验证证书的域名匹配：客户端检查服务器证书中的域名信息是否与用户试图连接的域名匹配。这是为了防止中间人攻击，其中攻击者可能会伪造证书并欺骗客户端连接到错误的服务器。
验证证书的签名：客户端使用根CA的公钥来验证服务器证书的数字签名。如果签名验证通过，客户端可以确信证书未被篡改。

如果服务器证书通过上述验证步骤，客户端就可以信任服务器的身份，并继续建立安全连接，使用服务器的公钥来加密通信数据。
注意：
客户端可以选择是否验证服务器证书。在某些情况下，如果客户端无法验证服务器的证书或不进行验证，连接仍然可以建立，但会警告用户连接不安全。然而，为了最大程度地确保安全，建议客户端始终验证服务器证书的合法性。

3.12 HTTPS信息摘要的算法是什么

HTTPS使用一种称为消息摘要算法（Message Digest Algorithm）的算法来确保数据的完整性。具体来说，HTTPS通常使用SHA-256（Secure Hash Algorithm 256位）或其他类似的消息摘要算法。

在HTTPS安全通信中，数字签名和消息摘要使用了以下几种算法：

MD5(Message-Digest Algorithm 5)：MD5是一个128位长度的消息摘要算法，用于产生数据的数字签名，校验数据完整性。但MD5已被证实存在弱点，可以被碰撞攻击。
SHA-1(Secure Hash Algorithm 1)：SHA-1是160位长度输出的密码HASH算法，相比MD5更加安全可靠，但理论上也可能受到碰撞攻击。
SHA-2：SHA-2代表了一系列SHA算法，包括SHA-224、SHA-256、SHA-384、SHA-512等变种。其中SHA-256是目前广泛使用的数字签名和消息摘要算法。
SHA-3：SHA-3是最新的安全HASH算法标准，采用Keccak算法，可以产生224、256、384、512位长度的消息摘要。其安全性得到广泛认可。
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通信中常用的加密方式：

对称加密：对称加密使用相同的密钥来加密和解密数据，因此被称为"对称"。在HTTPS通信中，客户端和服务器在SSL/TLS握手过程中协商出一个对称的会话密钥（Session Key）。这个会话密钥用于加密和解密实际的HTTPS数据。常见的对称加密算法包括：
- AES（Advanced Encryption Standard）：目前广泛使用的对称加密算法之一，支持不同的密钥长度，如AES-128、AES-256等。
非对称加密：非对称加密使用一对密钥，包括公钥和私钥，其中一个用于加密，另一个用于解密。在HTTPS通信中，服务器拥有一对公钥和私钥，其中公钥被包含在服务器的数字证书中，而私钥是服务器保密的。非对称加密主要用于SSL/TLS握手阶段，以安全地协商对称会话密钥。常见的非对称加密算法包括：
- RSA（Rivest–Shamir–Adleman）：常用于数字证书中的非对称加密算法。
数字签名：数字签名是一种非对称加密的应用，用于验证数字证书的有效性。服务器的数字证书包含服务器的公钥和由证书颁发机构（CA）签名的信息。客户端使用CA的公钥来验证证书的签名，以确保证书是合法的。

HTTPS通信的基本过程是：在握手阶段，服务器和客户端协商出一个对称的会话密钥，该密钥用于加密和解密HTTP数据。这个对称会话密钥由服务器的非对称公钥加密传输给客户端，客户端使用私钥解密得到该密钥。之后，客户端和服务器使用对称密钥来加密和解密通信数据，保障数据的机密性和完整性。

总结：
HTTPS使用对称加密和非对称加密（包括数字签名）来保障通信数据的安全性和保密性。这种综合使用不同的加密方式，使得HTTPS通信变得安全可靠。

4 HTTP2相比HTTP1有什么优势

注意：HTTP2不是HTTPS，两者别搞成一个了。

HTTP/2是HTTP/1的后续版本，它引入了一些重要的改进，以提高性能和效率。以下是HTTP/2相比HTTP/1的一些主要优势：

多路复用（Multiplexing）：HTTP/2允许多个请求和响应同时在一个连接上进行传输，而不像HTTP/1那样需要建立多个连接。这意味着可以在一个连接上并行发送多个请求和响应，减少了连接建立和维护的开销，提高了性能。
二进制格式：HTTP/2采用了二进制传输格式，而HTTP/1使用文本格式。二进制格式更加紧凑和高效，减少了数据传输的大小，从而提高了效率。
头部压缩：HTTP/2支持头部字段的压缩，减少了请求和响应中的重复头部信息的传输，降低了带宽使用，加快了页面加载速度。
服务器推送（Server Push）：HTTP/2允许服务器在客户端请求之前主动推送资源。这使得服务器可以预测客户端可能需要的资源，并在请求之前发送，减少了往返延迟，提高了加载速度。
优化的流量控制：HTTP/2引入了更有效的流量控制机制，可以更精细地管理数据流的传输和优先级，确保关键资源能够更快地加载。
支持Header压缩算法：HTTP/2使用HPACK压缩算法来压缩头部信息，减少了数据传输的开销。这有助于提高性能，特别是在低带宽或高延迟网络环境下。
安全性：虽然不是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）是计算机网络中的两个不同的协议，它们在网络通信中扮演不同的角色，有以下主要区别：

层级关系：
- TCP是传输层协议，负责在网络上可靠地传输数据，处理数据的分段、顺序控制、流量控制等网络传输的底层细节。
- HTTP是应用层协议，构建在传输层之上，用于定义客户端和服务器之间的通信规则，以便请求和传输超文本（通常是网页）和其他数据。
功能：
- TCP主要负责数据传输的可靠性和有序性。它确保数据能够从一个端点安全地传输到另一个端点，而不会损坏、丢失或乱序。
- HTTP主要负责定义客户端和服务器之间的请求和响应的格式，以及如何处理和呈现文档或数据。
连接性：
- TCP是一种面向连接的协议，它建立持久的连接来传输数据，通常使用客户端-服务器模型。
- HTTP可以基于TCP连接，但它是一种无状态协议，每个请求都是独立的，服务器不会保持与客户端的持久连接。
端口：
- TCP使用端口号来标识不同的网络应用程序或服务。例如，Web服务器通常使用TCP端口80或443。
- HTTP通常基于TCP连接，使用HTTP默认端口80（非加密）或443（加密）。
通信内容：
- TCP传输的是原始二进制数据流，它没有关于数据的上下文或语义。
- HTTP传输的是基于文本的消息，这些消息包含请求或响应的元信息和数据，以及用于标识资源的URL。
应用领域：
- TCP是一个通用的协议，用于支持各种应用程序和服务的可靠通信，包括HTTP。
- HTTP主要用于互联网上的超文本传输，用于在Web浏览器和Web服务器之间传输网页、图像、视频、API数据等。

总结：
TCP提供了网络通信的底层基础，而HTTP构建在TCP之上，定义了用于Web数据传输的规则和语义。HTTP使用TCP作为它的传输层协议之一，但还包括其他应用层协议，如HTTPS（HTTP over TLS/SSL）等，以提供安全性和隐私保护。

5.2 HTTP是在TCP之上运行，两者的包会有什么区别

TCP的数据包包含源端口和目标端口，HTTP不包含端口信息。
TCP的包头简单，只包含源端口、目标端口、序号、确认号等信息。HTTP的数据包更复杂，包含请求方法、URL、协议版本、请求头部、消息体等信息。
TCP关注传输， packets只包含数据。HTTP关注应用信息，packets包含具体的请求或响应详情。
TCP的packets按顺序传输，HTTP的packets可以乱序。
TCP需要建立连接、流量控制和拥塞控制。HTTP运行在TCP连接上，可以忽略这些问题。
TCP对数据包的大小没有限制。HTTP一般将数据包限制在1500字节以内。
TCP的packets只有头部。HTTP的packets有头部、消息体等完整结构。
TCP是面向连接的协议。HTTP本质上是无连接的。

总结：
两者分别工作在不同层次，TCP负责底层传输，HTTP负责具体的应用数据交互，两者的包结构和功能有着明显的区别。

5.3 TCP特点

可靠性：TCP提供可靠的数据传输。它确保数据从发送端准确地传输到接收端，通过使用序号、确认和重传机制来实现数据的可靠性。如果数据包丢失、损坏或乱序，TCP将负责重新发送数据，以确保完整性和正确性。
面向连接：TCP是一种面向连接的协议，连接的建立需要经过三次握手过程，以确保双方都准备好进行数据传输。连接的关闭也需要经过四次挥手过程。
流量控制：TCP使用流量控制机制来防止数据包的积压和数据传输过程中的数据流过快。接收端可以通知发送端其可接受的数据量，从而调整发送速率，以适应接收端的处理能力。
拥塞控制：TCP具有拥塞控制机制，它可以在网络拥塞时减缓数据发送速率，以防止过度拥塞，保持网络的稳定性。拥塞控制通过检测丢失的数据包和计算往返时间来实现。
面向字节：TCP将数据视为一系列字节的流，而不是消息或数据包。这允许TCP在传输时对数据进行分段、重组和流动控制，以适应不同的网络条件。
双工通信：TCP支持全双工通信，允许双方同时发送和接收数据，这使得实时应用和互动应用能够进行高效的双向通信。
端口和套接字：TCP使用端口来区分不同的应用程序和服务。套接字是应用程序与TCP协议交互的接口，通过套接字可以进行数据的读取和写入。
可靠性和复杂性：TCP提供高度的可靠性和数据完整性，但它也引入了一些复杂性和额外的开销，如握手、确认和拥塞控制。这些机制确保了数据的可靠传输，但有时也会引入一些延迟。

总结：
TCP是一种非常可靠的协议，适用于需要可靠数据传输和连接性能的应用程序，如网页浏览、电子邮件、文件传输、实时通信等。它是互联网中的基础协议之一，确保了数据在网络中的可靠传输。

5.4 TCP使用场景

TCP（Transmission Control Protocol，传输控制协议）适用于需要可靠的、面向连接的数据传输的场景。以下是一些常见的TCP使用场景：

Web浏览：当在浏览器中访问网页时，浏览器使用HTTP协议（通常是HTTP over TCP）与Web服务器建立TCP连接来请求网页内容。TCP确保了网页数据的可靠传输，以便正确显示网页。
电子邮件：SMTP（Simple Mail Transfer Protocol）和POP3（Post Office Protocol）或IMAP（Internet Message Access Protocol）等电子邮件协议使用TCP来传输电子邮件消息，以确保邮件的可靠传输和正确接收。
文件传输：FTP（File Transfer Protocol）和SFTP（SSH File Transfer Protocol）等协议使用TCP来传输文件。这些协议需要可靠的数据传输，以防止文件损坏或丢失。
远程登录：SSH（Secure Shell）和Telnet等协议用于远程登录到计算机系统。SSH使用TCP来提供加密的、安全的远程访问。
数据库访问：许多数据库管理系统（如MySQL、PostgreSQL、Oracle）使用TCP来进行数据库查询和数据传输。可靠性对于数据库操作至关重要。
VoIP电话：Voice over Internet Protocol（VoIP）电话系统使用TCP或UDP（在某些情况下）来传输音频数据。虽然UDP在VoIP中更常见，但某些应用也使用TCP以确保更可靠的音频传输。
在线游戏：某些在线游戏使用TCP来传输游戏数据，特别是需要高度可靠性的游戏。虽然UDP更常用于实时游戏，但TCP适用于一些策略性或回合制游戏。
HTTPS安全通信：HTTPS协议使用TLS/SSL建立在TCP上，以确保加密和安全性，用于保护敏感数据的传输，如信用卡信息和登录凭据。
Web服务：当使用SOAP、RESTful API等协议进行Web服务调用时，通常会使用HTTP over TCP来进行通信。

总结：
TCP适用于需要可靠性、面向连接和数据完整性的应用场景。它确保数据的可靠传输，适用于许多互联网应用，尤其是需要高度可靠性的应用。然而，由于TCP引入了一些额外的开销，可能会引入一些延迟，因此在某些实时性要求较高的应用中，可能会使用UDP等协议。

注释："HTTP over TCP" 就是使用传输控制协议（TCP）作为HTTP协议的底层传输协议。在这种情况下，HTTP数据通过TCP连接进行传输，以确保数据的可靠性和完整性。

5.5 基于（使用）TCP的协议有哪些

HTTP（Hypertext Transfer Protocol）：HTTP是用于在Web浏览器和Web服务器之间传输超文本文档的协议。它是互联网上最常见的应用层协议之一，通常使用TCP作为传输层协议。
HTTPS（HTTP Secure）：HTTPS是HTTP的安全版本，通过在HTTP上加入TLS/SSL层来加密数据传输。它使用TCP作为底层传输协议，以确保加密的、安全的通信。
FTP（File Transfer Protocol）：FTP是用于文件传输的协议，它使用TCP来传输文件。FTP允许用户上传和下载文件到和从远程服务器。
SMTP（Simple Mail Transfer Protocol）：SMTP是用于电子邮件传输的协议，用于从发送方电子邮件客户端发送电子邮件到接收方电子邮件服务器。SMTP使用TCP来传输电子邮件消息。
POP3（Post Office Protocol version 3）和 IMAP（Internet Message Access Protocol）：这两个协议用于从电子邮件服务器上检索电子邮件。POP3和IMAP都使用TCP来建立连接并下载电子邮件。
SSH（Secure Shell）：SSH是用于安全远程登录和文件传输的协议。它使用TCP作为底层传输协议，并提供加密和认证功能，以保护远程会话的安全。
Telnet：Telnet是一种用于远程登录到远程主机的协议，但它不提供加密，因此安全性较低。它使用TCP来传输终端会话。
MySQL：MySQL是一种流行的关系型数据库管理系统，它使用TCP来建立与数据库服务器的连接并进行数据查询和操作。
RDP（Remote Desktop Protocol）：RDP用于远程桌面连接，允许用户远程控制和操作远程计算机。它使用TCP来传输桌面会话数据。
XMPP（Extensible Messaging and Presence Protocol）：XMPP是一种实时通信协议，用于即时消息传递和在线状态。它使用TCP来传输消息。

总结：
这些协议是构建互联网和计算机网络中各种应用和服务的关键组成部分，它们依赖于TCP来提供可靠的数据传输。每个协议都具有不同的用途和特性，但它们都使用TCP作为传输层协议，以确保数据的可靠性和正确性。

5.6 TCP三次握手

参考1：HTTP协议常问的面试题（吐血整理）看 16 TCP三次握手和四次挥手。

TCP的三次握手（Three-Way Handshake）是建立TCP连接的过程，用于确保通信的双方都准备好传输数据。以下是TCP三次握手的过程：

第一步 - 客户端发送连接请求：
1. 客户端首先向服务器发送一个特殊的TCP包，称为SYN（同步）包。
2. 这个包包含客户端随机选择的一个初始序列号（Client ISN，Initial Sequence Number），该序列号用于标识客户端发送的数据，以及一个标志位SYN=1，表示这是一个连接请求。
第二步 - 服务器确认连接请求：
1. 服务器收到客户端的连接请求（SYN包）后，如果同意建立连接，会回复一个包，通常称为SYN-ACK包。
2. 这个包包含了服务器分配用于标识服务器发送的数据的初始序列号（Server ISN），以及标志位SYN=1和ACK=1，表示这是对客户端请求的确认，并且服务器也准备好建立连接。
第三步 - 客户端确认服务器的确认：
1. 客户端收到服务器的确认（SYN-ACK包）后，会向服务器发送一个确认包（ACK包）。
2. 这个包包含标志位ACK=1，表示客户端接受了服务器的确认，并且连接已建立。
3. 此时，双方都已确认连接的建立，可以开始传输数据。

完成了这个三次握手过程后，TCP连接就建立成功了，客户端和服务器都可以开始在连接上进行数据传输。每个数据包都会包含一个序列号，用于标识数据的顺序和完整性，以确保数据能够正确地传输和接收。

注意：
三次握手是用于建立TCP连接的过程。在连接结束后，会使用四次挥手过程来正常关闭连接。这些握手和挥手过程是TCP协议中的关键步骤，以确保数据的可靠传输和连接的正确终止。

5.7 TCP在握手完成之后，A到B发送数据，中间有个数据被篡改，它会怎处理

TCP在数据传输过程中，包括握手阶段之后，会使用一种校验和机制来检测数据是否被篡改。这个校验和通常称为TCP校验和（TCP Checksum）。

当数据从发送端A到接收端B时，TCP发送端会计算校验和并将其附加到数据包的头部。接收端B收到数据包后会进行以下处理：

校验和验证：接收端B会计算接收到的数据包的校验和，并将结果与数据包头部中的校验和进行比较。
比较校验和：如果接收端计算出的校验和与数据包头部中的校验和匹配，说明数据包在传输过程中没有被篡改，数据被接受并继续传递给上层应用程序。
校验和不匹配：如果接收端计算出的校验和与数据包头部中的校验和不匹配，说明数据包在传输过程中可能受到了篡改或损坏。接收端会丢弃这个数据包，不传递给上层应用程序，并可以选择发送一个通知给发送端A请求重新发送数据。

这种校验和机制帮助确保了TCP传输中数据的完整性。如果数据包在传输过程中被篡改或损坏，接收端会检测到这一问题，并丢弃损坏的数据包，从而保护了数据的可靠性。如果发生数据包丢失或篡改，TCP会负责重新传输数据，直到接收端确认接收到正确的数据。

总结：
TCP使用校验和机制来检测和处理数据传输中的篡改或损坏问题，以确保数据的可靠性和完整性。这是TCP协议的一个重要特性，有助于提高网络通信的可靠性。

5.8 TCP三次握手的两种队列

参考1：TCP连接三次握手中的重要数据结构：半连接队列和全连接队列
在TCP三次握手的时候，服务端会维护两个队列：监听队列（Listen Queue）和已完成队列（Completed Connection Queue）。

监听队列（Listen Queue）：
- 监听队列也称为“半连接队列”或“未完全建立连接的队列”。
- 在服务端（通常是服务器）调用listen函数后，它会等待客户端的连接请求。
- 当客户端发送SYN（同步）包进行连接请求时，服务器会将这个请求放入监听队列中，等待后续的第二次握手。
- 监听队列的大小可以通过操作系统的配置进行设置，这个设置限制了同时等待连接的数量。如果队列已满，新的连接请求会被拒绝。
已完成队列（Completed Connection Queue）：
- 已完成队列也称为“全连接队列”或“已建立连接的队列”。
- 在服务器成功进行了第二次握手，接受了客户端的连接请求后，连接就会从监听队列移动到已完成队列中。
- 已完成队列中的连接表示已经建立，可以进行数据传输。
- 服务器会从已完成队列中取出连接，分配资源，为连接提供服务，并在完成后进行释放。

总结：
监听队列用于存放等待服务器确认的连接请求，而已完成队列用于存放已经建立的连接，准备进行数据传输。这两个队列在TCP连接建立过程中起着重要的作用，确保了连接的正常建立和管理。当连接终止时，也有相应的队列来管理连接的释放。
TCP三次握手的半连接队列和全连接队列示意图

5.8.1 TCP三次握手的两种队列溢出

不管是半连接队列还是全连接队列，都有最大长度限制，超过限制时，内核会直接丢弃，或返回RST包。

半连接队列溢出：
客户端发送SYN报文和服务端进行第一次握手，此时服务端将此请求信息放在半连接队列中并回复SYN+ACK给客户端。这里也就是SYN攻击的点，攻击方要做的就是不停的建立连接，但是却不给出ACK确认，导致半连接队列满了，其他请求无法进入。

全连接队列溢出：
当服务端并发处理大量请求时，如果TCP全连接队列过小，就容易溢出。发生TCP全连接队溢出的时候，后续的请求就会被丢弃，这样就会出现服务端请求数量上不去的现象。

全连接队列满了，就只会丢弃连接吗？
实际上，丢弃连接只是Linux的默认行为，我们还可以选择向客户端发送RST复位报文，告诉客户端连接已经建立失败。
TCP三次握手的全连接队列参数配置图
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，因为这样更有利于应对突发流量。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

长度限制，超过限制时，内核会直接丢弃，或返回RST包。

通常情况下，应当把tcp_abort_on_overflow设置为0，因为这样更有利于应对突发流量。

[外链图片转存中…(img-xCLBb8DU-1715795098611)]
[外链图片转存中…(img-ViAoBkta-1715795098612)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

2401_84924864

关注

11
点赞
踩
13

收藏

觉得还不错? 一键收藏
0
评论
2024年网络协议相关面试题及解答_网络协议面试(3)，Golang面试项目包装

正向代理（Forward Proxy）是一种网络代理服务器的配置，它是代表客户端向外部服务器请求资源。在正向代理中，客户端不直接连接到目标服务器，而是通过正向代理服务器进行连接，然后由代理服务器将请求转发给目标服务器，最后将响应返回给客户端。正向代理典型代表是VPN客户端配置：客户端需要配置使用正向代理服务器的地址和端口号。请求发送：客户端发送请求到正向代理服务器。代理服务器转发：正向代理服务器接收到客户端的请求后，它会像一个中间人一样，将请求转发给目标服务器。目标服务器响应。
复制链接

扫一扫