网络协议相关面试题及解答

已于 2023-12-14 00:28:17 修改
阅读量898 收藏 4
点赞数
分类专栏： 面试 文章标签： 面试
于 2022-10-16 22:42:37 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Mr_XiMu/article/details/127306938
版权

网络协议相关面试题及解答

1 Nginx

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

1.1 Nginx是什么

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

1.2 Nginx优点

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

1.3 Nginx应用场景

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

1.4 什么是正向代理

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

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

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

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

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

1.5 什么是反向代理

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

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

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

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

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

1.6 什么是CDN

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

特点：

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

工作原理：

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

  1. 轮询（Round Robin）：这是默认的负载均衡策略。Nginx按顺序将每个新的请求分发给下一个后端服务器，依次循环。这对于均匀地分配请求到所有服务器很有用。
upstream backend {
    server server1.example.com;
    server server2.example.com;
}
  1. 权重（Weighted Round Robin）：可以为每个后端服务器分配不同的权重，以控制流量分发的比例。较高权重的服务器会获得更多的请求。
upstream backend {
    server server1.example.com weight=3;
    server server2.example.com weight=2;
    server server3.example.com weight=1;
}
  1. IP哈希（IP Hash）：Nginx使用客户端的IP地址来选择一个后端服务器。这对于确保特定客户端的请求始终路由到同一个服务器很有用，例如会话保持。
upstream backend {
    ip_hash;
    server server1.example.com;
    server server2.example.com;
}
  1. 最少连接（Least Connections）：Nginx会将新的请求路由到当前连接数最少的后端服务器，以平衡服务器的负载。
upstream backend {
    least_conn;
    server server1.example.com;
    server server2.example.com;
}
  1. 基于响应时间的负载均衡：Nginx可以根据后端服务器的响应时间来分配请求。它会优先选择响应时间较短的服务器。
upstream backend {
    least_time first_byte;
    server server1.example.com;
    server server2.example.com;
}
  1. 备用服务器（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。
  1. 配置Server块：在Nginx配置中，找到或创建一个Server块，通常是用于特定虚拟主机或站点的配置。在该块内，可以进一步配置长连接相关的选项。
server {
    listen 80;
    server_name example.com;

    # 其他服务器配置

    location / {
        # 配置代理或处理长连接的方式
    }
}
  1. 处理长连接方式：根据需求，可以在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

HTTP请求的请求头
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

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应用程序中跟踪用户状态和维护会话信息的方式，但它们在实现和工作原理上有一些重要的区别：

  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 Transparency）来增加安全性。如果客户端在验证数字证书时发现任何问题，应立即中断连接，以防止建立不安全的通信渠道。

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连接建立过程中起着重要的作用，确保了连接的正常建立和管理。当连接终止时，也有相应的队列来管理连接的释放。
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，因为这样更有利于应对突发流量。
举个例子，当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中接收方无法处理！

应用层的处理方式

应用层的处理简单易行！并且不仅可以解决接收方造成的粘包问题，还能解决发送方造成的粘包问题。
解决办法：循环处理，应用程序从接收缓存中读取分组时，读完一条数据，就应该循环读取下一条数据，直到所有数据都被处理完成，但是如何判断每条数据的长度呢？

  • 格式化数据，每条数据都要实现约定好格式（开始符、结束符），显而易见在数据内部中不能出现开始符和结束符！
  • 发送长度：发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置。
封包处理粘包问题

所谓封包，就是给一段数据加上包头，这样一来数据包就分为包头和包体两部分内容，包头其实上是个大小固定的结构体，其中有个结构体成员变量表示包体的长度，这是个很重要的变量，其他的结构体成员可根据需要自己定义。根据包头长度固定以及包头中含有包体长度的变量就能正确地拆分出一个完整的数据包。对于拆包，目前最常用的是以下两种方式：

动态缓冲区暂存方式

大概过程描述如下：

  1. 为每一个连接动态分配一个缓冲区，同时把此缓冲区和SOCKET关联，常用的是通过结构体关联。
  2. 当接收到数据时首先把此段数据存放在缓冲区中。
  3. 判断缓存区中的数据长度是否够一个包头的长度，如不够，则不进行拆包操作。
  4. 根据包头数据解析出里面代表包体长度的变量。
  5. 判断缓存区中除包头外的数据长度是否够一个包体的长度，如不够，则不进行拆包操作。
  6. 取出整个数据包，这里的"取"的意思是不光从缓冲区中拷贝出数据包,而且要把此数据包从缓存区中删除掉，删除的办法就是把此包后面的数据移动到缓冲区的起始地址（环形缓冲可以优化这里）。

这种方法有两个缺点：

  • 为每个连接动态分配一个缓冲区增大了内存的使用。
  • 有三个地方需要拷贝数据，一个地方是把数据存放在缓冲区，一个地方是把完整的数据包从缓冲区取出来，一个地方是把数据包从缓冲区中删除.第二种拆包的方法会解决和完善这些缺点。

可以采用环形缓冲（定义两个指针，分别指向有效数据的头和尾，在存放数据和删除数据时只是进行头尾指针的移动），但是还是不能解决第一个缺点以及第一个数据拷贝，只能解决第三个地方的数据拷贝(这个地方是拷贝数据最多的地方)。第2种拆包方式会解决这两个问题。

利用底层的缓冲区来进行拆包

由于TCP也维护了一个缓冲区，所以我们完全可以利用TCP的缓冲区来缓存我们的数据，这样一来就不需要为每一个连接分配一个缓冲区了。另一方面我们知道recv或者wsarecv都有一个参数，用来表示我们要接收多长长度的数据.利用这两个条件我们就可以对第一种方法进行优化。

直接用底层的缓冲区直接进行拆包，固然可以免于拷贝到缓冲区，但是这样每次接收，都要做逻辑处理，对于频繁接收数据的场景，这种方法效率并不高。而如果我们一次性接收到很多数据，然后利用动态缓冲区暂存，进行异步处理。一次接收，多次处理，效率反而会更高。

6 UDP

UDP（User Datagram Protocol，用户数据报协议）同TCP一样都是传输层协议，用于在计算机网络上传输数据。与TCP（Transmission Control Protocol）不同的是UDP是一种无连接协议，它提供的是一种简单的，但不可靠的数据传输机制。

6.1 UDP特点

  1. 无连接性：UDP是一种无连接协议，意味着在数据传输前不需要在发送端和接收端之间建立连接。这使得UDP的数据传输速度较快，因为不需要进行握手和连接管理。
  2. 不可靠性：UDP不提供数据传输的可靠性，它不保证数据的完整性和顺序性。这意味着数据包在传输过程中可能会丢失、重复、乱序或损坏，而UDP本身不提供机制来处理这些问题。因此，如果应用程序需要可靠的数据传输，它需要自行处理这些问题。
  3. 低开销：UDP的头部开销较小，相对于TCP来说，UDP头部只包含源端口、目标端口、数据长度和校验和等字段，因此UDP的开销较小，有助于降低网络传输的额外负担。这使得UDP适用于那些对传输延迟敏感且可以容忍一定数据丢失的应用，如实时音视频传输和在线游戏。
  4. 广播和多播支持：UDP支持广播和多播通信，允许一台计算机将数据包发送给多个目标计算机，而不是仅限于点对点通信。
  5. 没有流量控制（No Flow Control）：UDP不提供流量控制机制，因此发送端可以随时发送数据，而不需要等待接收端的确认。这可以在某些情况下导致网络拥塞。
  6. 应用场景：UDP通常用于那些不需要强制的可靠性和流量控制的应用，如实时音频和视频流、在线游戏、DNS（域名系统）查询、SNMP（简单网络管理协议）等。
  7. 快速响应：由于UDP的无连接性和低开销，它通常用于需要快速响应的应用，如实时通信和媒体流传输，这些应用更注重低延迟而不是数据的可靠性。

注意：
UDP的设计目标是提供一种轻量级的数据传输机制，适用于那些对速度和实时性要求较高、可以容忍一些数据丢失的应用。然而，由于它的不可靠性，对数据完整性和可靠性要求较高的应用通常会选择使用TCP。在选择UDP或TCP时，应根据应用的特性和需求做出明智的选择。

6.2 TCP和UDP区别

  1. 连接性
    • TCP是一种面向连接的协议，它在数据传输前需要在发送端和接收端之间建立连接，通过三次握手建立连接，然后再进行数据传输。连接建立后，数据传输是可靠的，有序的，并且会进行错误检查和重传。
    • UDP是一种无连接的协议，数据包的传输不需要建立连接。每个UDP数据包都是独立的，不会像TCP那样维护连接状态，因此UDP更加轻量级，但不提供连接的可靠性和状态管理。
  2. 可靠性
    • TCP提供可靠的数据传输，它确保数据的完整性、顺序性和可靠性。如果数据包丢失或损坏，TCP会进行重传，直到数据到达接收端。
    • UDP不提供可靠性保证，它不进行数据包的重传。如果数据包丢失或损坏，UDP不会主动处理，这使得UDP更适用于那些对数据可靠性要求较低的应用。
  3. 头部开销
    • TCP头部相对较大，包含各种控制字段，用于建立和维护连接，这增加了数据包的开销。
    • UDP头部相对较小，只包含基本的源端口、目标端口、数据长度和校验和字段，因此UDP的开销较小。
  4. 延迟和速度
    • 由于TCP的连接建立和数据重传机制，它的传输速度可能较慢，尤其在高丢包率或高延迟的网络环境中。
    • UDP由于无连接性和较小的头部开销，通常传输速度较快，适合对延迟要求较高的应用。
  5. 应用场景
    • TCP适用于对数据可靠性和顺序性要求高的应用，如网页浏览、电子邮件传输、文件下载和大多数Web应用。
    • UDP适用于对速度和实时性要求高、可以容忍一些数据丢失的应用，如实时音视频传输、在线游戏、VoIP通信、DNS查询等。

总结：
TCP和UDP是根据不同的需求和应用场景而设计的两种不同的传输协议。选择哪种协议取决于应用的特性和要求，以及对可靠性和速度的权衡。有些应用可能需要同时使用TCP和UDP来满足不同的需求。

6.3 UDP使用场景

UDP（User Datagram Protocol，用户数据报协议）通常用于那些对数据传输速度和低延迟要求较高，可以容忍一定数据丢失的应用场景。以下是一些常见的UDP使用场景：

  1. 实时音频和视频传输：UDP适用于实时音频和视频传输，如视频会议、在线直播和实时音视频通话。虽然UDP可能会导致一些数据包的丢失，但对于这些应用来说，快速的数据传输和低延迟更为重要。
  2. 在线游戏：多人在线游戏通常使用UDP来传输游戏数据，因为游戏需要快速响应时间，且可以容忍少量的数据包丢失。UDP还允许游戏服务器向多个客户端广播游戏状态。
  3. VoIP（Voice over IP）通信：VoIP应用使用UDP来传输语音数据，以实现实时语音通话。尽管可能会丢失一些声音样本，但低延迟对于语音通话至关重要。
  4. DNS（域名系统）查询：DNS查询通常使用UDP进行，因为它需要快速响应查询请求，且查询结果通常可以容忍一定程度的数据丢失。
  5. SNMP（简单网络管理协议）：SNMP是一种网络管理协议，通常使用UDP来传输管理信息。虽然SNMP可以容忍一些数据包的丢失，但它仍然提供了用于检测错误和请求重传的机制。
  6. 传感器数据传输：在物联网（IoT）和传感器网络中，UDP常用于传输传感器数据。由于传感器数据通常需要实时收集和传输，UDP是一个合适的选择。
  7. Trivial File Transfer Protocol（TFTP）：TFTP是一个简单的文件传输协议，通常使用UDP进行文件传输。尽管TFTP不提供可靠性，但它足够用于一些简单的文件传输场景。

注意：
UDP不适用于那些对数据完整性和可靠性要求非常高的应用，如文件传输和大多数Web应用。在选择UDP时，必须权衡快速响应时间和可靠性之间的权衡，并确保应用程序能够处理可能的数据丢失情况。UDP通常用于对速度和实时性要求较高、可以容忍一些数据丢失的应用。

6.4 基于（使用）UDP的协议有哪些

  1. DNS（域名系统）：DNS使用UDP来进行域名解析查询。DNS查询通常需要快速响应时间，因此使用UDP而不是TCP，尽管UDP可能会导致一些查询失败或超时。
  2. DHCP（动态主机配置协议）：DHCP用于自动分配IP地址和其他网络配置参数。DHCP客户端通过UDP向DHCP服务器发送请求，以获取配置信息。
  3. SNMP（简单网络管理协议）：SNMP用于网络设备监控和管理。SNMP通常使用UDP来传输管理信息。
  4. TFTP（Trivial File Transfer Protocol）：TFTP是一个简单的文件传输协议，通常用于小型文件的传输。TFTP使用UDP来传输文件，但不提供可靠性。
  5. NTP（网络时间协议）：NTP用于同步计算机和设备的时间。NTP使用UDP来进行时间同步。
  6. RTP（实时传输协议）：RTP用于实时音频和视频传输，如视频会议和实时流媒体。RTP通常与RTCP（RTP控制协议）一起使用，二者都使用UDP来传输媒体数据和控制信息。
  7. Syslog：Syslog是用于日志记录和远程日志传输的协议，通常使用UDP进行日志消息的传输。
  8. NFS（网络文件系统）：NFS是一种用于在网络上共享文件系统的协议，它可以使用UDP或TCP进行文件传输。在某些情况下，NFS可能会选择使用UDP以提高性能。
  9. Voice over IP（VoIP）通信：一些VoIP应用使用UDP来传输语音数据，以实现实时语音通话。UDP的低延迟特性对VoIP通信很有帮助。
  10. 在线游戏：多人在线游戏通常使用UDP来传输游戏数据，以实现低延迟和快速响应时间。

这些是一些使用UDP作为传输协议的常见协议和应用。UDP在这些应用中通常用于对速度和实时性要求较高、可以容忍一些数据丢失的情况。需要注意的是，UDP不提供数据的可靠性保证，因此在使用UDP的应用中，必须考虑如何处理可能的数据丢失和乱序。

6.5 UDP如何实现可靠性传输

UDP（User Datagram Protocol）本身并不提供可靠性传输，它是一种无连接、不可靠的传输层协议。然而，如果需要在UDP上实现可靠性传输，应用程序可以自行实现一些机制来处理数据的完整性、顺序性和可靠性。以下是一些常见的方法来实现在UDP上实现可靠性传输：

  1. 应用层协议：在应用层实现可靠性。这意味着在应用程序中编写代码来确保数据的完整性和顺序性。例如，在数据包中添加序列号，以确保数据包的顺序，并在接收端进行缓冲和排序。还可以在数据包中添加校验和字段，以检测数据包的损坏，并进行重传。
  2. 重传机制：实现基于时间或事件的重传机制。如果发送方在一定时间内未收到接收方的确认，它可以选择重新发送数据包。这种重传机制可以通过定时器来实现。
  3. 确认和反馈：接收方可以向发送方发送确认消息，告知发送方哪些数据包已成功接收，哪些需要重传。发送方可以根据接收方的确认来进行重传。
  4. 超时处理：发送方可以设置超时时间，如果在超时时间内未收到确认，就认为数据包丢失，然后进行重传。
  5. 流量控制：实现流量控制以防止数据包的拥塞。发送方可以根据接收方的处理能力和网络状况来控制发送速度，以避免数据包的丢失。

需要强调的是，实现可靠性传输需要额外的开销和复杂性，这可能会降低UDP的性能和简洁性。因此，使用TCP通常是更简单和可靠的选择，因为TCP已经内置了可靠性传输机制。但如果某些特定应用需要UDP的低延迟和快速响应时间，同时又需要可靠性，那么可以考虑在应用层实现可靠性传输机制。

总结：
实现可靠性传输需要根据具体的应用需求来设计和实现相应的机制，以确保数据的可靠性、完整性和顺序性。这些机制通常需要在发送端和接收端之间进行协商和协作。

6.6 利用udp实现了可靠的数据传输的协议有哪些

  1. RDT（Reliable Data Transfer）：RDT是一种通用的可靠数据传输协议，它可以在UDP上实现可靠性数据传输。RDT使用序列号和确认消息来实现数据包的可靠性传输。有两个主要的RDT版本，分别是RDT 1.0和RDT 2.0，它们提供了不同级别的可靠性。
  2. TFTP（Trivial File Transfer Protocol）：TFTP是一个简单的文件传输协议，通常使用UDP进行传输。虽然TFTP本身在UDP上实现了可靠性传输，但它的可靠性机制相对简单，主要是通过重传丢失的数据包来实现的。
  3. QUIC（Quick UDP Internet Connections）：QUIC是一种基于UDP的传输协议，用于加速互联网连接。它包括了强大的可靠性和安全性特性，包括有序的数据传输、错误校验和流控制，以实现可靠的数据传输。
  4. DTLS（Datagram Transport Layer Security）：DTLS是TLS（Transport Layer Security）的UDP版本，用于在不可靠的UDP上实现加密和可靠性传输。DTLS提供了TLS的安全性，同时通过序列号和重传来实现可靠性传输。
  5. SCTP（Stream Control Transmission Protocol）：SCTP是一种面向消息的传输协议，可以在UDP上实现。它提供了可靠的、有序的数据传输，以及流控制和错误检测机制。
  6. WebSocket over UDP：WebSocket是一种协议，它通常在TCP上运行，但也可以在UDP上实现。通过使用序列号和确认消息，WebSocket over UDP可以实现可靠性的数据传输。

注意：
尽管这些协议和技术可以在UDP上实现可靠性数据传输，但它们通常会增加一些开销和复杂性，以确保数据的完整性和顺序性。选择合适的协议和技术取决于应用的具体需求和性能要求。在设计和实现时，应仔细考虑网络条件、应用场景和可靠性需求。

6.7 UDP包接收的时序不一致怎么解决

当使用UDP进行数据传输时，数据包的时序可能会不一致，也就是说，数据包的顺序可能不同于它们发送的顺序。这种不一致通常是由于网络中的不同路径、拥塞或丢包等因素引起的。

要解决UDP包接收的时序不一致问题，可以考虑以下几种方法：

  1. 数据包排序：在接收端，可以维护一个缓冲区，并根据数据包的序列号（可以在数据包中添加）对数据包进行排序。通过按照序列号排序，可以确保数据包按照正确的顺序被处理。如果有数据包丢失，可以等待一段时间来等待它的重传，以确保数据包的完整性和顺序性。
  2. 时间戳：数据包可以包含时间戳信息，接收端可以根据时间戳来确定数据包的到达顺序。请注意，这种方法可能会受到时钟不同步的影响，因此需要小心处理。
  3. 缓冲和重传：在接收端，可以使用缓冲区来存储乱序的数据包，然后等待缺失的数据包到达或超时后进行重传。这可以确保数据包的顺序性。
  4. 应用层协议：可以在应用层协议中定义自己的机制来处理乱序的数据包。例如，如果正在实现自定义的实时传输协议，可以在应用层定义数据包的顺序和处理方式。
  5. 保留有限历史：在接收端，可以保留有限历史数据包，以便重新排序或处理乱序的数据包。一旦数据包到达，它可以与已缓存的数据包进行比较，以确定正确的顺序。

注意：
解决UDP包接收的时序不一致问题通常需要根据具体的应用需求来设计和实现，因为不同的应用可能有不同的容忍度和处理方式。在设计解决方案时，还需要考虑网络延迟、丢包率以及应用的实时性等因素。

7 网络七层协议

参考1：网络七层协议
网络七层协议
记忆口诀：
物联（链）网传话，表示应用（七层）

计算机网络通常使用OSI（Open Systems Interconnection）模型或七层模型来描述不同层次的通信协议和功能。这个模型将网络通信分为七个层次，每个层次执行特定的任务，以便实现数据的传输和交换。以下是七层模型中的每个层次及其主要功能：

  1. 物理层（Physical Layer）
    • 功能：物理层处理底层硬件传输，如电缆、光纤、物理接口和信号传输。
    • 主要任务：数据位的传输和接收，物理介质的选择和控制，信号编码和调制。
  2. 数据链路层（Data Link Layer）
    • 功能：数据链路层负责数据帧的传输和物理层之间的通信。
    • 主要任务：帧的创建、帧的传输和接收、物理地址（MAC地址）的管理、错误检测和校正。
  3. 网络层（Network Layer）
    • 功能：网络层负责数据包的路由和转发，实现不同子网之间的通信。
    • 主要任务：IP地址分配、路由表的构建、数据包的寻址和路由选择。
  4. 传输层（Transport Layer）
    • 功能：传输层提供端到端的通信，确保数据可靠性、流控制和差错恢复。
    • 主要任务：端口号分配、数据分段、错误检测和重传、流控制。
  5. 会话层（Session Layer）
    • 功能：会话层建立、管理和终止通信会话，处理会话中的同步和控制。
    • 主要任务：会话建立和维护、对话同步和恢复。
  6. 表示层（Presentation Layer）
    • 功能：表示层处理数据的格式和编码，确保不同设备之间的数据兼容性。
    • 主要任务：数据加密和解密、数据压缩和解压、数据格式转换。
  7. 应用层（Application Layer）
    • 功能：应用层是用户和应用程序之间的接口，负责应用程序的通信和交互。
    • 主要任务：提供应用层协议、用户界面、应用程序和服务的交互。

注意：
七层模型是一个理论上的概念，实际上的网络通信通常使用TCP/IP协议栈，它将七层模型的一些层次合并在一起。TCP/IP协议栈包括四个主要层次：网络接口层（对应物理层和数据链路层）、网络层、传输层和应用层，其中的功能和任务与七层模型中的对应层次有些差异。不过，七层模型仍然是一种有用的理论框架，用于理解和描述不同层次的通信协议和功能。

7.1 TCP、UDP是在哪一层

TCP（Transmission Control Protocol）和UDP（User Datagram Protocol）是在网络协议模型中的传输层协议。传输层是计算机网络七层模型中的第四层，负责在通信实体之间提供端到端的数据传输、流控制、差错检测和重传等功能。TCP和UDP是两种常见的传输层协议，它们用于实现不同类型的数据传输服务。

具体来说：

  • TCP提供可靠的、面向连接的通信，确保数据的完整性和可靠性。它使用握手、确认、序列号和重传等机制来保证数据的可靠传输。
  • UDP提供不可靠的、面向无连接的通信，适用于需要低延迟和高吞吐量的应用。UDP不提供数据重传和流控制，因此在数据传输时速度较快，但可能会导致数据丢失或乱序。

这两种协议在传输层负责数据的可靠传输，但它们具有不同的特性，适用于不同的应用场景。

7.2 HTTP、SSH是在哪一层

HTTP（Hypertext Transfer Protocol）和SSH（Secure Shell）是在计算机网络协议模型中的不同层次：

  • HTTP：HTTP位于计算机网络协议模型中的应用层。它是用于在Web浏览器和Web服务器之间传输超文本文档和其他资源的协议。HTTP用于获取网页、发送表单数据、上传文件等，通常运行在TCP之上。
  • SSH：SSH位于计算机网络协议模型中的应用层，但它还涉及传输层的一些功能。SSH是用于安全远程访问和数据传输的协议，它提供了对终端会话和文件传输的加密和认证支持。SSH通常运行在TCP之上，并通过密码、公钥、私钥等方式进行身份验证和安全通信。

虽然HTTP和SSH都在应用层中操作，但它们有不同的目的和功能。HTTP用于传输Web内容，而SSH用于加密和安全的远程访问和文件传输。因此，它们在网络协议模型中虽然位于同一层次，但服务的性质和用途不同。

7.3 网络交换机位于网络的哪一层

网络交换机通常位于网络七层协议模型中的第二层，即数据链路层（Data Link Layer）。数据链路层主要负责物理介质的访问、数据的帧化和以太网等数据链路相关的功能。

交换机在这一层上通过物理地址（MAC地址）来决定将数据帧转发到哪个端口，以实现局域网内设备之间的通信。这与路由器位于网络七层模型中的第三层（网络层）的工作方式有所不同，路由器则更多地关注IP地址和路由表，用于实现跨网络的数据传输。

7.4 在浏览器输入一个百度地址后，它这个协议是怎么流转的？发了一个请求出来，然后它整个这个用户的这个发请求的行为到搜索端整个这个过程，它的协议是怎么流转的？能简单描述一下这个过程吗？

整理后：在浏览器上输入一个网址后，从请求发送到结果返回整个过程，它的协议是怎么流转的？

从在浏览器中输入一个网址到最终获得网页内容的过程涉及多个协议和步骤，通常涉及以下几个关键阶段：

  1. DNS解析（Domain Name System）：当在浏览器中输入网址时，浏览器首先需要将域名解析为IP地址，以确定要访问的服务器的位置。浏览器会向本地DNS服务器发送DNS查询请求，如果本地DNS服务器没有缓存该域名的IP地址，则会递归地查询根域名服务器、顶级域名服务器和权威域名服务器，最终获取到目标服务器的IP地址。
  2. 建立TCP连接（Transmission Control Protocol）：一旦浏览器知道了目标服务器的IP地址，它将尝试建立到该服务器的TCP连接。这个过程通常涉及三次握手，其中浏览器和服务器之间互相确认并建立连接。
  3. 发起HTTP请求：一旦TCP连接建立，浏览器将发送一个HTTP请求到服务器，该请求中包含了要获取的资源的详细信息，例如请求的页面、文件、图像等。
  4. 服务器处理请求：服务器收到HTTP请求后，会根据请求中的信息，定位到相应的资源，然后进行处理。这可能涉及到在服务器上执行动态生成内容的脚本、查询数据库或其他操作。
  5. 服务器响应：服务器处理完成后，将生成一个HTTP响应，其中包含了所请求资源的数据，以及响应的元数据，例如响应状态码、头部信息等。
  6. 数据传输：一旦服务器生成响应，它将通过已建立的TCP连接将数据传输回浏览器。这是通过将数据分成小块（数据包）并通过互联网传输的方式完成的。
  7. 浏览器渲染：一旦浏览器接收到响应数据，它将解析HTML、CSS和JavaScript等内容，并将页面渲染在浏览器窗口中。这包括将HTML解析为DOM（文档对象模型）树、加载并应用CSS样式，执行JavaScript代码等操作。
  8. 呈现页面：最终，浏览器将呈现完整的页面，包括文本、图像、链接、表单和其他元素。用户可以与页面进行交互，点击链接、填写表单等操作。

在整个过程中，HTTP（Hypertext Transfer Protocol）是主要的应用层协议，用于定义浏览器和服务器之间的通信方式。HTTP负责在请求和响应之间传递数据，以及定义请求的方法（例如GET、POST）、状态码（例如200 OK、404 Not Found）等信息。

总结：
这个过程涉及多个协议和步骤，从DNS解析到数据传输和页面呈现，都需要按照一定的规范和协议来完成。这使得浏览器能够在用户输入网址后获取并显示网页内容。

7.5 计算机网络四层模型和七层模型有什么区别？

  1. OSI模型更详细，分为七层，而TCP/IP模型更简洁，只有四层。
  2. OSI模型中有更多的抽象层，以更准确地描述不同的网络功能。
  3. TCP/IP模型是实际应用更广泛的模型，因为它是互联网协议的基础。
  4. OSI模型是一种理论上的模型，而TCP/IP模型更加贴近实际的网络实施和运营。

7.6 TCP四层模型是哪四层？

TCP/IP四层模型：

  1. 网络接口层（Network Interface Layer）：对应于OSI模型的物理层和数据链路层，处理物理介质和数据链路的细节。
  2. 网际层（Internet Layer）：对应于OSI模型的网络层，负责路由和寻址，实现数据包的传输。
  3. 传输层（Transport Layer）：对应于OSI模型的传输层，提供端到端的数据传输和错误检测。
  4. 应用层（Application Layer）：对应于OSI模型的会话、表示和应用层，提供网络应用和服务。

8 DNS是基于哪个协议的

DNS（Domain Name System，域名系统）是基于两种主要的传输层协议之一进行通信的，这两种协议分别是：

  • UDP（User Datagram Protocol）：DNS通常使用UDP来进行域名解析查询。UDP是一种无连接的、不可靠的传输协议，适用于对数据传输速度和低延迟要求较高的应用场景。DNS查询通常比较小且需要快速响应，因此使用UDP作为传输协议是合适的。
  • TCP（Transmission Control Protocol）：尽管DNS主要使用UDP，但在某些情况下，例如对于较大的DNS响应或DNS区域传输（Zone Transfer）等，DNS服务器和客户端可以选择使用TCP来进行通信。TCP是一种可靠的传输协议，适用于需要数据可靠性和完整性的情况。

总结：
DNS主要使用UDP来进行域名解析查询，但也可以选择使用TCP来处理特定的情况。这种灵活性允许DNS在不同的应用场景中进行通信，以满足不同的需求。

9 MQTT协议

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是一种轻量级的、基于发布/订阅模式的通信协议，用于传输低带宽、高延迟或不可靠网络环境下的消息数据。MQTT最初由IBM开发，并成为OASIS标准。

MQTT协议的一些重要特点和概念：

  1. 发布/订阅模式：MQTT采用发布/订阅模式，其中客户端可以订阅一个或多个主题（Topic），并且发布者将消息发布到特定主题。订阅了相同主题的客户端将接收到发布到该主题的消息。
  2. 主题（Topic）：主题是消息的逻辑通道，用于标识消息的内容。客户端可以订阅特定主题，以接收与该主题相关的消息。主题通常是一个字符串，可以是层次结构化的，例如"home/living-room/temperature"。
  3. QoS（Quality of Service）：MQTT支持不同的QoS级别，用于控制消息传输的可靠性和交付保证。有三个QoS级别可供选择：0（最多一次交付，不可靠）、1（至少一次交付，可靠但可能会有重复）、2（只有一次交付，最可靠但开销较大）。
  4. 保留消息：MQTT支持保留消息，允许发布者发布一个主题的消息并将其保留，以便新的订阅者可以立即接收到最新的消息。
  5. 遗嘱消息（Last Will and Testament）：客户端可以设置一个遗嘱消息，以指定在客户端异常断开连接时，将自动发布的消息。
  6. 保持活动连接：MQTT客户端通常保持活动连接到MQTT代理（服务器），这有助于减少连接建立和断开的开销，同时提供实时消息传输能力。
  7. 适用于受限环境：MQTT设计用于受限的网络环境，如低带宽、高延迟或不稳定的网络连接。它具有较小的头部开销，并且支持保持连接和最小化数据传输的机制。
  8. 多平台支持：MQTT协议在多个平台和编程语言中都有广泛的实现和支持，使得不同设备和系统可以轻松地进行MQTT通信。

MQTT通常用于物联网（IoT）应用，传感器网络，远程监控和控制系统等需要在低带宽和高延迟环境中传输数据的场景。由于其轻量级和可靠性，它成为了一种流行的通信协议，用于连接和管理大量的设备和传感器。

9.1 MQTT的应用场景

  1. 物联网（IoT）：MQTT是物联网领域最常用的通信协议之一。它可以用于连接和管理大量的传感器、设备和物联网节点。MQTT的轻量级特性使其适用于资源有限的嵌入式设备，而其发布/订阅模式允许设备之间灵活地交换信息。
  2. 远程监控和控制：MQTT用于实时监控和控制应用，如监控设备状态、远程控制智能家居设备、远程机器控制等。通过MQTT，用户可以远程监视设备并发送指令，以实现实时响应。
  3. 传感器网络：MQTT可用于传感器网络，用于将传感器数据传输到中央数据存储或监控系统。传感器可以定期发布数据到MQTT主题，而订阅者可以实时接收并处理这些数据。
  4. 智能城市：MQTT可用于构建智能城市系统，监控交通、环境、能源等信息。它可以用于交通信号控制、垃圾桶状态监测、能源消耗监测等应用。
  5. 远程日志和故障排查：MQTT可以用于设备或应用程序的远程日志记录和故障排查。设备可以将日志数据发布到MQTT主题，以便运维人员或开发人员远程监视和分析问题。
  6. 智能农业：在农业领域，MQTT可用于监控农田中的传感器数据，例如土壤湿度、气温、光照等，以帮助农民优化农业操作。
  7. 航空航天：MQTT在航空航天领域用于飞行器、卫星和地面控制中心之间的通信，以传输实时数据和控制指令。
  8. 实时消息传递：MQTT可以用于实时消息传递应用，如即时通讯、实时位置共享和多人游戏，以提供快速的消息传递服务。

注意：
MQTT的轻量级特性和可靠性使其在各种应用场景中得到广泛应用。它提供了一种高效、可扩展和可靠的方式来连接和管理设备、传感器和应用程序，并在受限的网络条件下传输消息。因此，MQTT已经成为物联网和实时通信领域的核心通信协议之一。

10 Modbus通信协议

参考1：详解Modbus通信协议

Modbus是一种常见的通信协议，用于在自动化和控制系统中传输数据。该协议最初由Modicon（现在是施耐德电气）开发，并在1980年代广泛推广和采用。Modbus协议具有简单、轻量级和可靠的特性，适用于工业自动化、仪表控制和数据采集等领域。以下是Modbus通信协议的一些关键特点：

  1. 通信类型：Modbus支持多种通信类型，包括串行通信（如RS-232、RS-485）和以太网通信（Modbus TCP/IP）。这使得它适用于不同的物理介质和网络环境。
  2. 通信模式：Modbus支持主从模式的通信。在Modbus通信中，一个主站（通常是一个控制系统或计算机）可以与多个从站（通常是设备、传感器或仪表）进行通信。主站负责发出请求，而从站负责响应请求。
  3. 数据传输：Modbus协议可以用于读取和写入数据，包括读取寄存器、写入寄存器、读取输入状态、写入线圈等操作。这些操作允许控制系统与各种设备进行数据交换和控制。
  4. 数据格式：Modbus数据通常以16位或32位的寄存器方式组织，数据可以是整数、浮点数、布尔值等不同类型。通常，Modbus使用大端字节序（Big-Endian）来表示数据。
  5. 寄存器地址：Modbus通信中，每个数据点都有一个唯一的寄存器地址，用于标识该数据点。主站使用这些地址来指定要读取或写入的数据点。
  6. 异常处理：Modbus协议定义了一些异常代码，用于处理错误情况。如果从站无法满足请求，它可以返回异常响应。
  7. 多个变种：Modbus协议有多个变种，包括Modbus RTU（二进制传输）、Modbus ASCII（ASCII字符传输）和Modbus TCP/IP（以太网传输）。每个变种有不同的物理层和传输特性，可以根据需求选择。
  8. 广泛应用：Modbus协议在工业自动化、楼宇自动化、能源管理、电力系统监测、制造业等多个领域中得到广泛应用。

总结：
Modbus是一种简单而强大的通信协议，适用于连接各种设备和系统，用于监控、控制和数据采集。它的开放性和广泛的支持使其成为了自动化领域的通信标准之一。需要注意的是，Modbus协议不提供安全性和加密机制，因此在网络中使用时需要采取额外的安全措施。

12 DS协议有了解过吗

因相关介绍略少，暂未找到何时答案。

13 XSS攻击是什么？

跨站脚本攻击（Cross-Site Scripting，XSS）是一种Web应用程序中常见的安全漏洞，攻击者通过在用户访问的页面中注入恶意脚本，达到在用户浏览器中执行恶意代码的目的。

XSS攻击的主要原理是攻击者能够向Web页面中插入恶意的脚本代码，这些脚本代码会在用户浏览器中执行。攻击者可以通过不信任的输入渠道，比如用户输入、URL参数、Cookie、或者通过一些其他途径注入这些恶意脚本。

XSS攻击主要分为三种类型：

  1. 存储型 XSS（Stored XSS）：攻击者将恶意脚本存储在目标服务器上，然后用户在浏览器中请求包含了这个恶意脚本的页面时，攻击就会发生。这通常涉及到用户输入的存储，比如留言、评论等地方。
  2. 反射型 XSS（Reflected XSS）：攻击者构造包含恶意脚本的URL，然后将这个URL发送给目标用户。用户点击这个URL时，恶意脚本会在用户浏览器中执行。这种类型的 XSS 不会将脚本存储在目标服务器上，而是通过用户的交互行为触发。
  3. DOM型XSS：这种类型的XSS不涉及服务器端的漏洞，而是通过恶意修改页面的DOM结构来实现攻击。攻击者构造的URL或者提交的数据可能导致浏览器在解析页面时执行恶意脚本。

XSS攻击可能导致的危害包括：

  • 窃取用户敏感信息，如登录凭证、Cookie等。
  • 利用用户身份执行恶意操作。
  • 欺骗用户输入敏感信息。
  • 破坏页面结构和显示。

为了防止XSS攻击，开发者可以采取以下措施：

  1. 输入验证和过滤： 对用户输入的数据进行严格的验证和过滤，确保只接受合法的输入。
  2. 输出编码： 在将用户输入或其他动态内容插入HTML、JavaScript、CSS或URL中时，使用合适的编码方式，如HTML转义、JavaScript转义等。
  3. 使用安全的 API： 避免使用不安全的API，比如document.write、innerHTML等，而选择使用更安全的 API，如textContent、createElement等。
  4. 设置 HTTP 头： 在HTTP头中设置Content Security Policy（CSP）可以帮助限制页面加载外部资源的方式，从而减少XSS攻击的风险。
  5. Cookie 设置： 使用HttpOnly属性来设置Cookie，使其不能被JavaScript访问，减少敏感信息泄露的风险。

14 CSRF一般可以通过什么去缓解？

跨站请求伪造（Cross-Site Request Forgery，CSRF）是一种攻击方式，攻击者通过伪造用户已经认证过的请求，以用户的身份执行未经授权的操作。为了缓解CSRF攻击，可以采取以下一些措施：

  1. 同源策略：利用浏览器的同源策略，确保网站只能请求同源的资源。这样可以防止恶意网站发起对其他网站的CSRF攻击。
  2. Anti-CSRF Token：在每个表单或敏感操作的请求中包含一个随机生成的Anti-CSRF Token。这个Token存储在用户的会话中，并在用户提交请求时验证Token的有效性。攻击者由于无法获取用户会话中的Token，因此无法成功伪造请求。
  3. SameSite Cookie 属性：使用SameSite Cookie属性来限制第三方站点对用户Cookie的访问。SameSite可以设置为"Lax" 或 “Strict”，以减少第三方站点对用户Cookie的滥用。
    Set-Cookie: cookieName=cookieValue; SameSite=Lax;
  4. Referer 检查：服务器端可以检查请求头中的Referer字段，确保请求是从合法的来源发起的。然而，Referer字段并不总是可靠，因为有些浏览器可能会限制或省略Referer头。
  5. 双重提交 Cookie：在用户的会话中设置一个双重提交Cookie，该Cookie的值同时存储在用户的Cookie中和请求参数中。服务器在接收到请求时验证Cookie中的值和请求参数中的值是否一致。
  6. 使用 HTTP-only Cookie：将敏感的Cookie标记为HTTP-only，这样它们就不能通过 JavaScript 访问。这可以降低CSRF攻击的成功率。
  7. 利用 SameSite Cookie 属性：利用SameSite Cookie属性，该属性可以限制在请求中包含Cookie的方式，从而减少CSRF的风险。设置为"Strict"将完全禁止第三方站点发送Cookie，而"Lax"则限制了在一些情况下的Cookie发送。

总体而言，采取多层次的防御策略是缓解CSRF攻击的有效途径。组合使用Anti-CSRF Token、SameSite Cookie属性、双重提交Cookie等方法可以提高安全性。

15 浏览器怎么去判断一个请求是不是跨域请求？

浏览器判断请求是否跨域是通过同源策略（Same-Origin Policy）来实现的。同源策略是一种安全机制，它限制一个页面从一个源加载的文档或脚本如何与来自另一个源的资源进行交互。同源策略涉及到以下几个方面：

  1. 协议（Protocol）：同源策略要求协议必须相同。例如，从 http://example.com 加载的页面只能请求 http://api.example.com 而不能请求 https://api.example.com。
  2. 域名（Domain）：同源策略要求域名必须相同。例如，从 http://example.com 加载的页面只能请求 http://api.example.com 而不能请求 http://api.other.com。
  3. 端口（Port）：同源策略要求端口必须相同。例如，从 http://example.com:8080 加载的页面只能请求 http://api.example.com:8080 而不能请求 http://api.example.com:9090。

如果请求的协议、域名和端口有一个不同，就被认为是跨域请求。浏览器在判断跨域时会检查请求的来源（Origin）和目标资源的Origin是否相同。Origin是由协议、域名和端口组成的。

例如：

  • 请求：http://example.com的Origin是http://example.com。
  • 请求：https://api.example.com的Origin是https://api.example.com。

如果这两者不相同，则认为是跨域请求。在JavaScript中，可以通过document.domain、window.location等方式获取当前页面的Origin，也可以通过浏览器的控制台查看网络请求的Origin。

需要注意的是，有一些跨域资源共享（CORS）的机制可以允许跨域请求，但这需要服务器明确地设置相关的HTTP头部，以允许来自其他源的请求。

16 像那种网络类似的问题，比如说我抓包抓不到或收不到包，或者是什么调用不通，但这种问题那我们是这么查的？

回答：抓包的话，首先的话要看这个网络是否通，然后还有一方面就是这个服务是否正常，然后还有的话就是要看这个实际是否有数据，然后的话就是排查一下这个程序中是否有出现一些错误？如果有的话就排查一下这个具体的日志，查看日志。

西木Qi
关注
  • 0
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
网络协议相关面试题
qq_42828949的博客
09-23 6380
s
Java 面试知识点解析(五)——网络协议篇
anye0005的博客
05-18 917
前言： 在遨游了一番 Java Web 的世界之后，发现了自己的一些缺失，所以就着一篇深度好文：知名互联网公司校招 Java 开发岗面试知识点解析 ，来好好的对 Java 知识点进行复习和学习一番，大部分内容参照自这一篇文章，有一些自己补充的，也算是重新学习一下 Java 吧。 前序文章链接： Java 面试知识点解析(一)——基础知识篇 Java 面试知识点解析(二)——高并...
2024年Go最全网络协议相关面试题及解答_网络协议面试(1)，2024年最新吃透这份Golang高级工程师面试497题解析
最新发布
2401_84904581的博客
05-11 932
HTTPS使用一种称为消息摘要算法（）的算法来确保数据的完整性。具体来说，HTTPS通常使用SHA-256（Secure Hash Algorithm 256位）或其他类似的消息摘要算法。在HTTPS安全通信中，数字签名和消息摘要使用了以下几种算法：MD5是一个128位长度的消息摘要算法，用于产生数据的数字签名，校验数据完整性。但MD5已被证实存在弱点，可以被碰撞攻击。SHA-1是160位长度输出的密码HASH算法，相比MD5更加安全可靠，但理论上也可能受到碰撞攻击。SHA-2SHA-2代表了一系列。
网络协议常用面试题汇总(一)
故不积跬步无以至千里
08-09 2232
Buffer：与Channel进行交互，数据是从Channel读入缓冲区，从缓冲区写入Channel中的；flip方法：反转此缓冲区，将position给limit，然后将position置为0，其实就是切换读写模式；clear方法：清除此缓冲区，将position置为0，把capacity的值给limit。rewind方法：重绕此缓冲区，将position置为0；可减少一次系统空间到用户空间的拷贝。但Buffer创建和销毁的成本更高，不可控，通常会用内存池来提供性能。...
网络协议面试
一个千万开发人员中的程序员
05-19 178
1、浏览器输入url按回车，背后经历了什么？ 首先，在地址栏输入一串url，先解析url，看url是否合法 浏览器先查看浏览器缓存->系统缓存->路由器缓存，如果缓存中有缓存数据，会直接在屏幕上显示页面内容 在发送http请求前，需要域名解析（DNS解析），解析获取相应的IP地址 浏览器向服务器发起tcp连接，与浏览器建立起tcp三次握手 握手成功后，浏览器向服务器发送http请求，...
前端面试题及答案.zip
04-18
"前端面试题及答案.zip"这个压缩包很可能包含了丰富的前端面试题目以及相应的解答，旨在帮助求职者或希望提升技能的前端工程师更好地准备面试。让我们来深入探讨一些可能涵盖的知识点。 1. HTML/CSS基础： - HTML...
Java面试题及答案包含大厂面试真题
02-21
Java作为一门广泛应用于企业级应用开发的编程语言，其面试题涵盖了从基础语法到高级特性的各个层面。针对阿里巴巴、百度等大厂的面试真题，我们可以深入探讨以下几个Java相关的重要知识点： 1. **Java基础**：这...
2021最新Java面试题及答案V2.0.pdf.zip
06-02
这份"2021最新Java面试题及答案V2.0.pdf"压缩包文件显然是为准备Java程序员面试的人们精心编排的资料，包含了最新的面试问题和对应的解答。下面我们将深入探讨其中可能涵盖的一些关键知识点。 1. **Java基础** - *...
HTTP 60 道面试题及答案.docx
07-09
HTTP面试题涵盖的主题广泛，涉及网络编程的基本概念、网络协议、TCP/IP协议栈以及相关协议如TCP和UDP的区别。以下是对这些知识点的详细说明： **网络编程**： 网络编程是多台计算机之间的数据交换，主要基于请求/...
Java 面试题汇总及解答
02-09
Java作为一门广泛应用于企业级应用开发的编程语言，其面试题涵盖了众多方面，包括基础语法、面向对象特性、异常处理、集合框架、多线程、内存管理、IO流、网络编程、反射机制、JVM优化等多个领域。以下是对这些知识...
TCP/IP协议知识点总结与面试
08-09
总结的一些TCP/IP重要知识点和面试问题
计算机网络协议-公司面试题
07-27
网络协议-公司面试题 网络协议-公司面试题
【面试】网络协议
情绪瓜皮皮丶的学习之路
09-04 600
面试题整理--网络协议
网络协议面试题
小小学渣的博客
09-23 1350
1. 什么是TCP/IP和UDP协议 TCP/IP协议即传输控制/网络协议，是面向连接的协议，发送数据之前需要建立连接，TCP提供可靠传输服务。 UCP协议即用户数据报协议，属于TCP/IP协议族中的一种。是无连接的协议，发送数据之前无需建立连接，不可靠传输。 2. TCP与UDP的区别 TCP是面向连接的，而UDP是面向无连接的 TCP只支持点对点通信，UDP支持1-1、1-n、n-1、n-n。 TCP是以字节为单位发送数据的，而UDP是整个报文一次发完。 3. TCP与UDP的应用场景 对某些实
网络协议面试知识点整理
积极分子
04-21 2256
网络面试知识点总结
面试题系列（五）-网络协议
遇见更好的自己
01-16 1415
1.UDP/TCP的区别UDP 是用户数据报协议: 主要用在实时性要求高以及对质量相对较弱的地方,但面对现在高质量的线路不是容易丢包除非是一些拥塞条件下, 如流媒体 TCP 是传输控制协议:是面连接的,那么运行环境必然要求其可靠性不可丢包有良好的拥塞控制机制如http ftp telnet 等 2.什么是三次握手与四次挥手？三次握手 第一次握手：建立连接时，客户端发送同步
【全网最全】面试高频知识点汇总 网络协议专题 （持续更新）
Steve Wang's blog
09-24 928
TCP、UDP协议的区别 类型 面向连接 传输可靠性 传输形式 传输效率 所需资源 应用场景 首部字节 TCP 面向连接 可靠 字节流 慢 快 要求通讯数据可靠(文件传输、邮件传输) 20-60 UDP 无连接 不可靠 数据报文段 快 少 要求通信速度快(域名转换) 8个字节 TCP提供面向连接的服务。数据传送之前必须先建立连接，数据传送结束后要释放连接。TCP不提供广播或者多播服务。 TCP的可靠性体现在传递数据之前，会有三次握手来建立连接，数据传递时，有确认、窗口、重传、拥塞控制
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值