HTTP

简单说一下HTTP？

  1. HTTP：超⽂本传输协议（HyperText Transfer Protocol），用于超文本传输的应用层协议。
  2. 超文本：即超越了普通文本的文本，它是⽂字、图⽚、视频等的混合体，具备超链接，能从⼀个超⽂本跳转到另外⼀个超⽂本。
  3. HTML：超文本标记语言，是一种标识性的语言。HTML 文本是由 HTML 命令组成的描述性文本，是最常见的超文本。
  4. URL：HTTP使用统一资源定位符（URL）来标识与定位服务器上的资源，如常见的网址。
  5. 浏览器：浏览器（Web Broser），是检索、查看互联网上网页资源的应用程序，是使用 HTTP 协议的主要载体。
  6. HTTP 协议用于客户端和服务器之间的通信。用户在客户端使用浏览器，通过点击超链接或者输入URL来获取HTTP服务器上的资源，这些资源通过HTTP协议传送给客户端。

URI和URL的区别？

  1. URI：统一资源标识符（uniform resource identifier），用来在Web上标识一个资源。Web上的可用资源，如HTML文档、图像、视频片段、程序等都是用URI来定位的。
  2. URL：统一资源定位符（uniform resource locator），它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何访问这个资源。URL一般由三部组成：
    1. 协议(或称为服务方式)
    2. 存有该资源的主机IP地址(有时也包括端口号)
    3. 主机资源的具体地址。如目录和文件名等。
  3. 比如 https://example.com/page.html是URI也是URL，因为它在标识资源的同时还说明了应该使用HTTPS去访问该资源。而 example.com/page.html就是个URI而不是URL，它只是标识了资源的位置，但没有提供该用什么协议去访问该资源。

HTTP的发展，各版本的特点？

  1. HTTP1.0:
    1. 简单、快速、灵活
    2. 短连接：短连接的含义是限制每次连接只处理一个请求。服务器处理完客户的一次请求后就会断开连接，这种方式比较简单，能节省服务器的资源消耗。
    3. 无状态：无状态是指协议对于事务处理没有记忆能力，客户端发送HTTP请求后，服务器根据请求响应数据，但它不会记录客户端的信息，无法判断某次请求与上一次请求是否来自同一客户端和用户。
  2. HTTP1.1：
    1. 长连接：默认持久连接，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，可以发送多次HTTP请求 。
    2. 管道化：客户端可以发出多个HTTP请求，只要前一个请求发送出去之后就可以继续发送第二个请求，而不用一个个等待响应之后再发送，但是服务器同一时间只能处理一个HTTP请求，后续到达的HTTP请求需要排队等待。
    3. 断点续传：就是可以将一个大数据，分段传输，客户端可以慢慢显示。
  3. HTTP2.0：
    1. 二进制编码：HTTP2.0采用二进制格式而非文本格式
    2. 多路复用：HTTP2.0支持多路复用，客户端可以同时发送多个HTTP请求，服务器也可以同时进行处理，不用进行排队。但在底层仍受到TCP层的限制，会出现队头阻塞问题。
    3. 报头压缩：HTTP2.0使用报头压缩，降低了头部开销
    4. 推送缓存：服务端可以在发送页面HTML时主动推送其它资源，而不用等到浏览器解析到相应位置，发起请求再响应。
  4. HTTP3.0：
    1. 基于UDP：弃用 TCP，改用基于UDP的QUIC协议，彻底解决HTTP2.0的队头阻塞问题，每个流（Stream）独立传输，丢包只影响当前流。
    2. 连接迁移：使用连接 ID（而非 IP+端口）标识会话，设备切换网络（如 Wi-Fi 转 4G）时连接保持，解决TCP因客户端IP变化需重新建立连接的问题。
    3. 内置加密：原生集成TLS1.3，所有流量默认加密，无明文传输。
    4. 快速连接：将TLS握手与传输层握手合并为一步，减少连接建立的开销。在首次连接时，仅需一次RTT即可完成（传输层连接建立和安全传输保证）。并且在首次连接后，客户端可以缓存会话密钥，下次连接时直接发送加密数据，无需再次进行握手。

HTTP长连接和短连接的区别？

  1. 在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次TCP连接，任务结束就中断TCP连接。
  2. 从HTTP/1.1起，默认使用长连接，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接。

一个 TCP 连接中多个HTTP 请求可以同时发送吗？

  1. HTTP1.0不支持。
  2. HTTP1.1可以发送多个HTTP请求，但无法做到同时发送与同时响应。
  3. HTTP2.0支持，但仍受到TCP限制，导致队头阻塞。
  4. HTTP3.0完全支持。

说说HTTP/2.0多路复用的队头阻塞问题？

  1. HTTP/2.0 允许在同一个 TCP 连接上并行传输多个请求/响应（称为“流”），避免了 HTTP/1.1 的队头阻塞（需按顺序处理请求）。
  2. 虽然 HTTP/2.0 在应用层实现了多路复用，但底层仍依赖 TCP 的可靠传输。比如序号为 1 的数据包丢失，即使序号 2、3 已到达，接收方也会等待 1 重传成功后再处理后续数据，
  3. HTTP/2.0的所有流共享同一个HTTP连接，所有流的数据包混合在同一个 TCP 管道中。如果某个流的数据包丢失，服务器会要求客户端重传该包，即使后续其他流的包都正常接收，但服务器仍然会在TCP层阻塞它们，直到丢失的包重传成功。

浏览器对同一域名建立的TCP 连接数有没有限制？

  1. 有。Chrome 最多允许对同一个 Host 建立六个 TCP 连接。不同的浏览器有一些区别。
  2. 建立多个TCP连接的操作常发生在HTTP1.1，因为不支持多路复用，资源只能顺序加载，这样会导致用户体验不佳，因此常会多开几个TCP连接提升传输速度。

一次完整的HTTP请求过程包括哪些内容？

  1. 域名解析
  2. 发起TCP的3次握手
  3. 建立TCP连接后发起HTTP请求
  4. 服务器响应HTTP请求
  5. 浏览器得到html代码
  6. 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等）
  7. 浏览器对页面进行渲染呈现给用户。

HTTP 报文是什么样的，它的组成格式是什么？

  1. HTTP 报文主要由三大部分组成：
    1. 起始行（start line）：描述请求或响应的基本信息；
    2. 头部字段（header）：使用 key-value 形式更详细地说明报文；
    3. 消息正文（entity）：实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据。
  2. 其中起始行和头部字段并称为请求头或者响应头，统称为 Header；消息正文也叫做实体，称为 body。
  3. HTTP 协议规定每次发送的报文必须要有 Header，但是可以没有 body，也就是说头部信息是必须的，实体信息可以没有。而且在 Header 和 body 之间必须要有一个空行（CRLF）。
  4. HTTP有两种报文：请求报文和响应报文。
    1. 请求报文：由客户端发送给服务端的报文，由请求行、请求头部、请求数据构成
    2. 响应报文：服务端回复客户端的报文，由状态行、响应头部、响应数据构成

常见的HTTP请求方法你知道多少？

  1. HTTP请求方法是请求报文的请求行的第一个字段，决定此次请求的类型。
  2. HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD方法。
  3. HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

常见的HTTP请求头字段有哪些？

  1. Host：指定目标服务器的域名和端口号。每个 HTTP 请求都必须包含这个头部，以便服务器识别客户端请求的目标
  2. User-Agent：客户端的浏览器或应用程序的标识字符串。它通常包含浏览器的名称、版本、操作系统等信息。
  3. Accept：指定客户端能够处理的响应内容类型。浏览器或客户端应用程序通常会根据自己能处理的格式来设置此字段。
  4. Accept-Encoding：指定客户端支持的内容编码方式，用于支持数据压缩（如 gzip、deflate）
  5. Accept-Language：指定客户端能够处理的语言类型。这个字段通常用于实现国际化，告诉服务器客户端的语言首选项
  6. Authorization：包含客户端的身份验证信息，通常在需要认证的 API 请求或网页请求中使用。常见的认证方式有基本认证（Basic）、Bearer Token 等。
  7. Cookie：携带客户端保存的 cookie数据。
  8. Connection：指定当前连接的选项。Connection: keep-alive 表示保持连接活跃，Connection: close 表示请求完成后关闭连接。
  9. Content-Type：指定请求体（body）中数据的类型，常用于 POST 或 PUT 请求，表明请求中发送的数据类型。
  10. Content-Length：指定请求体的大小，以字节为单位。这个字段在发送请求体（如 POST 数据）时非常重要。
  11. Referer：指定当前请求页面的来源地址。通常用于同个域名下的网页跳转，告诉服务器请求是从哪个页面发起的。
  12. Origin：指定发起请求的源（协议 + 域名 + 端口），常用于跨域请求（CORS）中，浏览器会自动填充该字段。与 Referer 不同，Origin 仅包含源的协议、域名和端口，而不包含路径、查询参数或锚点，

常见的HTTP响应头字段有哪些？

  1. Content-Type：指定返回内容的媒体类型（MIME 类型），表明响应体的格式
  2. Content-Length：指定响应体的字节数。浏览器可以使用此字段来确定响应体的大小
  3. Cache-Control：用于控制响应内容的缓存机制，指定缓存的相关策略，如是否缓存、缓存的最大时间等
  4. Expires：指定响应内容过期的时间点
  5. ETag：服务器为资源生成的唯一标识符（通常是哈希值）。客户端可以使用 ETag 来判断资源是否发生变化，从而决定是否重新获取资源。
  6. Location：在重定向响应中，指示客户端应该跳转到的新 URL。常用于 3xx 状态码（如 301、302）中。
  7. Set-Cookie：服务器设置 cookie。客户端收到响应时会将 cookie 保存在本地，以便下次请求时发送给服务器。
  8. Server：包含服务器的名称和版本号，通常由 Web 服务器软件（如 Apache、Nginx、IIS 等）自动生成。
  9. Strict-Transport-Security (HSTS)：告知浏览器仅通过 HTTPS 连接访问该服务器，避免中间人攻击。
  10. Access-Control-Allow-Origin：：用于跨域资源共享（CORS），指定允许哪些源可以访问该资源。通常在跨域请求的响应中使用。
  11. Content-Encoding：指定响应体的压缩方式
  12. Content-Disposition：指定响应体如何显示或处理（如下载文件）
  13. WWW-Authenticate：服务器在要求客户端进行认证时，返回此字段以告知客户端如何进行身份验证。
  14. Refresh：指定页面自动刷新或跳转的时间间隔，常用于实现自动重定向或刷新。

URL长度限制怎么回事？

  1. 实际上HTTP协议没有对传输的数据大小进行限制，也没有对URL长度进行限制。
  2. 对 URL 限制的大多是浏览器和服务器。因为处理长URL要消耗比较多的资源，为了考虑性能和安全，两者会对URL长度加限制。

在HTTP请求方法中，GET 和 POST 的区别？

  1. get重点在从服务器上获取资源，post重点在向服务器发送数据。
  2. get也可以向服务器传输数据。比如说我们想要获取资源需要登录验证用户权限，这时候需要将账号密码传输给服务器，get方法可以传输这些数据给服务器。
  3. get传输的数据都放在HTTP报文的请求行里，属于URL的一部分。数据以键值对即field（字段）= value的形式置于请求行的URL字段后面，以“？”分割URL和数据，多个数据用”&”连接，比如 HTTP://127.0.0.1/Test/login.action?name=admin&password=admin，所以这些数据用户是可见的。
  4. post传输数据的方法是将字段与对应值封存在请求数据中发送给服务器，这个过程对用户是不可见的。
  5. Get传输的数据量小，因为受URL长度限制，但效率较高；Post可以传输大量数据，数据大小理论上没有限制，所以上传文件时只能用Post方式；
  6. GET请求会被浏览器主动缓存，而POST不会，除非手动设置。
  7. POST的安全性要比GET的安全性高。通过GET提交数据，用户名和密码将明文出现在URL上，还会被浏览器进行缓存，容易被其他人查看。通过post提交数据，数据出现在请求数据中，在地址栏上不可见，也不会被浏览器缓存，安全性较高。

常见的HTTP状态码你知道多少？

  1. 状态码由三位数字组成，第一个数字定义了响应的类别，共分五种类别:
    1. 1xx：指示信息–表示请求已接收，继续下一步处理
    2. 2xx：成功–表示请求已成功处理
    3. 3xx：重定向–表示需要更改请求对象
    4. 4xx：客户端错误–请求有错误
    5. 5xx：服务器端错误–服务器未能实现合法的请求
  2. 下面来说一些比较常见的状态码
    1. 「100 Continue」：初始的请求已经接受，客户应当继续发送请求的其余部分
    2. 「200 OK」： 表示⼀切正常。
    3. 「204 No Content」：也是常见的成功状态码，但响应头没有 body 数据。
    4. 「206 Partial Content」：应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，⽽是其中的⼀部分，也是服务器处理成功的状态。
    5. 「301 Moved Permanently」：表示永久重定向，说明资源不存在了，需⽤新的URL访问。
    6. 「302 Found」：表示临时重定向，说明资源还在，但暂时要用另⼀个URL来访问。
    7. 「304 Not Modified」：不具有跳转的含义，表示资源未修改，重定向已存在的缓冲⽂件，也称缓存重定向，⽤于缓存控制。
    8. 「400 Bad Request」：表示客户端请求的报⽂有错误，但只是个笼统的错误。
    9. 「401 Unauthorized」：该状态码表示发送的请求需要有认证信息
    10. 「403 Forbidden」：表示服务器禁⽌访问资源，并不是客户端的请求出错。
    11. 「404 Not Found」：表示请求的资源在服务器上不存在或未找到。
    12. 「500 Internal Server Error」：与 400 类型，是个笼统通⽤的错误码，服务器发⽣了什么错误，我们并不知道。
    13. 「501 Not Implemented」：表示客户端请求的功能还不⽀持，类似“即将开业，敬请期待”的意思。
    14. 「502 Bad Gateway」：通常是服务器作为网关或代理时返回的错误码，表示服务器⾃身⼯作正常，访问后端服务器发⽣了错误。
    15. 「503 Service Unavailable」：表示服务器当前很忙，暂时⽆法响应服务器，类似“⽹络服务正忙，请稍后重试”的意思。

什么是RESTful API？

  1. 一个Web网站相当于是一个软件APP，这种软件采用客户端/服务器模式，建立在分布式体系上，通过HTTP协议通信。
  2. RESTful架构，就是一种基于HTTP协议的软件架构风格，用于设计网络应用程序的接口。
  3. RESTful架构遵循REST原则，即Representational State Transfer（表现层状态转移），具体如下：

    1. 资源（Resources）：所有数据或服务被抽象为资源，每个资源有唯一标识符（URI），例如：https://api.example.com/users/123

    2. 表现层（Representation）：资源的外在表示即为表现层，如文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现。URI只用来标识资源，而不代表它的形式。

    3. 统一接口（Uniform Interface）：使用标准的HTTP方法操作资源：

      1. GET：获取资源
      2. POST：创建资源
      3. PUT/PATCH：更新资源（全量/部分）
      4. DELETE：删除资源

    4. 无状态（Stateless）：服务端不保存客户端状态，每次请求必须包含所有必要信息

    5. 可缓存（Cacheable）：响应应明确是否可缓存，以提高性能

    6. 分层系统（Layered System）：客户端无需直接连接服务器，可通过中间层（如负载均衡、代理）通信。

Cookie和Session了解吗？

  1. Cookie：
    1. 由于HTTP是无状态的，服务器不会去记忆客户端的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存⽤来对外提供服务。
    2. 但也因为无状态，服务器没有记忆能力，它在完成有关联性的操作时会⾮常麻烦。例如登录->添加购物⻋->下单->结算->支付，这些操作都要知道⽤户的身份才⾏。但服务器不知道这些请求是有关联的，每次都要问⼀遍身份信息。
    3. 为了解决无状态引起的问题，引入了cookie机制。Cookie 是在客户端第⼀次请求后，服务器发送到用户浏览器并保存在本地的一小块数据。它会在浏览器之后向同一服务器再次发起请求时被携带上，用于告知服务端两个请求是否来自同一客户端。
    4. Cookie的缺点：每次请求都会需要携带Cookie 数据，因此会带来额外的性能开销。Cookie存储了用户信息，并且明文存放在本地浏览器，容易被窃取和篡改，不够安全。
  2. Session：
    1. Session和Cookie类似，都是用来存储用户信息。
    2. Session 存储在服务器端，通常存储在服务器上的文件、数据库或者内存中。
    3. Session以键值对的方式进行存储，用户信息存储于Session，使用Session ID标识。
    4. 在客户端登录完成之后，服务器会创建对应的session存储用户信息，然后把Session ID 发送给客户端进行保存。客户端后续访问服务器时会带着Session ID，服务器拿到 Session ID之后，则会在相应的数据中查找，如果找到对应的 session 就可以确认用户信息。
    5. Session ID可以通过Cookie存储，或直接放置在浏览器请求的URL中发送给服务器。
    6. Session将大部分信息交由服务器存储，而在浏览器本地仅存储一串SessionID，攻击者无法以此直接获取用户信息，也无法进行篡改，因为服务器会直接验证不通过。
    7. Session的缺点：所有用户的数据都存放在服务器，容易造成服务器压力过大。在分布式场景下表现不良，需要同步机制确保多台分布式服务器上的Session数据是一致的。

Cookie和Session的区别？

  1. 存储位置：Cookie存放在客户端，Session存放在服务端。
  2. 安全性：Cookie存放在客户端，容易被窃取和篡改。Session存储在服务端，客户端仅存放Session ID，数据比较安全。
  3. 存储类型：Cookie只能存放字符串，Session可存放各种数据类型。
  4. 空间限制：Cookie大小受限于浏览器，session大小受限于系统内存或者数据库大小。
  5. 生命周期：Cookie可设置过期时间，Session通常随浏览器的关闭而失效，也可用服务端主动销毁。

Cookie和Session的适应场景？

  1. Cookie只能存储字符串，Session则可以存储任何数据，因此在考虑数据复杂性时首选 Session。
  2. Cookie 存储在浏览器中，容易被恶意查看。Session存储在服务端，存储的数据比较安全。因此考虑数据安全性时首选Session。
  3. 对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的，因此不建议将所有的用户信息都存储到 Session 中，应该是两者混用。

Cookie的字段有哪些？

  1. name=value：这是 cookie 的核心内容，包含 cookie 的名称和对应的值。例如：user=JohnDoe
  2. expires：指定 cookie 的过期时间，格式为 GMT 时间。cookie 在过期时间到达时自动被删除。如果未设置该属性，cookie 默认为会话 cookie，即浏览器关闭时会删除
  3. max-age：指定 cookie 从创建时间开始的有效期（秒）。与 expires 类似，但 max-age 是相对时间而不是绝对时间
  4. path：指定 cookie 有效的路径范围。只有当请求的 URL 路径匹配该 cookie 的 path 时，cookie 才会被发送
  5. domain：指定 cookie 有效的域名范围。可以设置为当前域的父域名，使得多个子域共享同一个 cookie。只有当前请求的域名和cookie中的domain域匹配时，cookie才会被发送。
  6. secure：如果设置了 secure，cookie 仅会通过 HTTPS 连接发送，确保数据传输的安全性
  7. HttpOnly：如果设置了 HttpOnly，cookie 只能通过 HTTP 请求发送，无法通过 JavaScript 的 document.cookie 访问，从而增加安全性，防止跨站脚本攻击（XSS）
  8. SameSite：SameSite 属性用于限制跨站请求时发送 cookie 的行为，防止跨站请求伪造（CSRF）。它有三个值：
    1. Strict：仅在同站点请求时发送 cookie，完全防止跨站请求发送
    2. Lax：在某些跨站请求（如 GET 请求）中发送 cookie，但在其他类型的请求中不发送
    3. None：允许在所有情况下跨站点发送 cookie，但需要与 secure 属性一起使用

Cookie的使用流程？

  • 服务器控制：
    • 服务器可以通过 Set-Cookie HTTP 响应头来设置 cookie。服务器通过这个响应头将 cookie 发送给浏览器，并规定该 cookie 的属性，如有效期、作用域、路径、域名等。
    • 服务器可以通过这些 cookie 属性来指定 cookie 的使用范围和过期时间，但最终是否将 cookie 发送到服务器是由浏览器决定的。
  • 浏览器控制：
    • 浏览器在接收到 Set-Cookie 响应时，会根据 cookie 的属性（如 domain、path、secure 等）将它保存到本地，并决定将 cookie 在何时、以何种方式发送。
    • 当浏览器发起请求时，它会自动检查请求的 URL 是否与某个已保存的 cookie 的 domain 和 path 匹配。如果匹配，浏览器会将相关的 cookie 附加到请求的 Cookie 请求头中，发送到服务器。

说说HTTP请求头的Keep-Alive头部

  1. Keep-Alive是HTTP请求头中的一个特殊头部，它的作用是控制 HTTP 连接的保持时间和最大请求数，适用于 HTTP/1.0或HTTP/1.1
  2. timeout：指定空闲连接在关闭前的最大存活时间（单位：秒）。timeout=5 表示 如果 5 秒内没有新的请求，服务器就会关闭连接。
  3. max：指定 一个 Keep-Alive 连接最多能处理的 HTTP 请求次数。max=100 表示 这个连接最多能处理 100 个请求，之后服务器会主动关闭连接。
  4. HTTP/1.0 使用的是“短连接”，即每个请求都会建立并关闭 TCP 连接。 Keep-Alive 头部在 HTTP/1.0 不是标准特性，但一些服务器和客户端（如 Nginx、Apache）扩展了这个功能。但是要使用它的话，就必须加上头部 Connection: Keep-Alive。
  5. HTTP/1.1 默认开启 Keep-Alive，即 TCP 连接会自动保持，不需要额外指定 Connection: Keep-Alive。但是，Keep-Alive 头部的 timeout 和 max 仍然可以用于控制连接的存活时间和最大请求数。

网络通信中的缓存存在的原因是什么？如何实现的？

  1. 原因：
    1. 缓解服务器压力；
    2. 降低客户端获取资源的延迟：
  2. 实现方法：
    1. 让代理服务器进行缓存；
    2. 让客户端浏览器进行缓存。

WebSocket是什么？

  1. WebSocket 是一种网络通信协议，用于在客户端（如浏览器）和服务器之间建立持久化、全双工的通信通道。它基于传统的HTTP，但又摆脱了传统HTTP的“请求-响应”模型，允许双方随时主动发送数据，非常适合需要实时交互的应用场景，比如实时聊天和在线多人游戏。
  2. WebSocket是基于HTTP1.1的应用层协议，在HTTP2.0和3.0上的兼容性较差。
  3. 要想启动Websocket，只需再URL指明协议使用 ws://（非加密）或 wss://（SSL 加密）即可，然后其通信过程如下所示，需要一次RTT（这里仅限HTTP层的RTT）：
    1. 客户端发送一个带有 Upgrade: websocket 头的 HTTP 请求
    2. 服务器返回一个带有 101 Switching Protocols 状态行的HTTP响应，确认升级协议
    3. 连接建立后，双方通过WebSocket帧传输数据，无需重复握手。
  4. WebSocket 通信的基本单位是帧（Frame），它定义了数据如何封装、传输和解析。客户端和服务器通过交换帧来实现双向通信。这些帧有多种类型，主要用于承载不同数据若一个数据包太大，则可以分片用多个帧传输数据：
    1. Ping/Pong：心跳机制帧
    2. Continuation Frame：分片帧
    3. Text Frame：文本帧
    4. Binary Frame：二进制帧

HTTP中的幂等是什么？

  1. 幂等的核心特点：
    1. 多次请求 = 单次请求：论客户端发送一次还是多次相同的请求，服务器端的最终状态一致。（例如多次调用 DELETE /users/123，资源 123在第一次请求后已被删除，后续请求仍返回 404，但不会改变服务器状态。）
    2. 副作用仅发生一次：即使请求被重复执行（如因网络重试），额外的请求不会导致额外的数据变更或资源操作。
  2. 各个HTTP方法的幂等性：
    1. GET：幂等，获取资源，不修改服务器状态。
    2. PUT：幂等，替换资源，多次调用会覆盖为相同值。
    3. DELETE：幂等，删除资源后，后续请求可能返回 404，但服务器状态不变。
    4. POST：非幂等，每次请求可能创建新资源（如提交订单），重复调用会导致多次副作用。
    5. PATCH：非幂等，部分更新资源，可能因逻辑不同导致发生变化（如递增计数器）。
  3. 幂等的重要性：在网络不可靠时，具有幂等性的方法更加安全，因为即使产生多次请求，也不会导致服务器状态变更。而非幂等的方法则可能会导致错误，比如重复下单。
  4. 如何保证幂等性：
    1. 唯一标识：客户端生成唯一ID（如 X-Idempotency-Key），服务端记录已处理的请求。
    2. 版本控制：使用资源版本号（如 ETag）确保更新基于最新状态。
    3. 设计API逻辑：如 POST创建资源时，先检查是否已存在（避免重复）。

HTTPS

什么是SSL/TLS？

  1. HTTP 由于是明文传输，意味着在传输过程中的信息，对外部是完全可见的，因此技术人员可以很方便进行抓包读取数据，为我们调试⼯作带了极⼤的便利性。
  2. 明文传输所带来的缺陷就是不安全。在数据安全上存在以下三个⻛险：
    1. 使用明文进行通信，内容可能会被窃听；
    2. 不验证通信方的身份，通信方的身份有可能遭遇伪装；
    3. 无法证明报文的完整性，报文有可能遭篡改。
  3. 为了解决这个问题，在HTTP 与 TCP 层之间加⼊了 SSL/TLS协议。后面常将HTTP与SSL/TLS合并称为HTTPS。
  4. SSL/TLS：SSL是早期互联网用于加密数据的协议，但由于存在严重漏洞而被废弃。TLS与SSL一样用于加密数据，它是SSL的升级版，比起SSL它更安全、更高效，是现代加密通信的标准协议。

什么是HTTPS？

HTTPS 并不是新协议，而是让HTTP先和SSL/TLS 通信，再由SSL/TLS和TCP通信，也就是说HTTPS使用了隧道进行通信。通过使用SSL/TLS，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。

什么是加密？

加密就是对明文数据按某种特殊算法进行处理，使其成为不可读的一段代码，这段代码被称为“密文“。密文可以通过”密钥“解密，还原出原来的明文。通过这种方法可以保护数据，不被非法窃取和阅读。

密钥的类型你了解多少？

  1. 对称密钥：由一组相同的密钥对组成，加密和解密使用同一个密钥。
  2. 非对称密钥：由一组不同的密钥对组成，加密与解密必须使用不同的密钥，这两个密钥分别叫做公钥和私钥。公钥是可以公开给所有人的，而私钥需要自己保密的。使用公钥加密的数据只有使用私钥才能解开。使用私钥加密的数据只有使用公钥才能解开。
  3. 实际上私钥不是用来加密的，他是一种签名手段，准确的说法应该是 「私钥签名，公钥验签」，一般所说的非对称密钥指的是公钥加密，私钥解密。

说说怎么利用密钥给数据加密？

  1. 对称密钥加密：使用对称密钥来加密和解密数据
    1. 优点：数据加密和解密的运算速度快
    2. 缺点：通信双方在交换密钥时必须明文通信，无法安全地将密钥传输给对方
  2. 非对称密钥加密：使用非对称密钥来加密和解密数据，用公钥进行加密，再用密钥进行解密。
    1. 优点：由于公钥的公开性，可以安全地将密钥传输给对方。
    2. 缺点：数据加密和解密的运算速度慢。
  3. 非对称加密和非对称加密都有一个共同缺点，它们只能保证通信的内容不会泄漏，即“防窃听”，却没能解决“伪装”和“篡改”，不能保证通信方的身份有效性。

HTTPS采用的是对称密钥加密还是非对称密钥加密？

HTTPS采用了混合加密，这种加密方式结合了对称密钥加密和非对称密钥加密各自的优点，保证安全性的前提下让加密解密速度变快。

  1. 首先使用一组非对称密钥来加密传输一组对称密钥，来保证传输过程的安全性。
  2. 通信双方再使用对称密钥来加密通信过程中的数据，来保证通信过程的效率。
  3. 混合加密只保证“防窃听”，想解决“伪装”和“篡改”需使用“签名”与“数字签名”。

签名是什么意思？

  1. 签名是一种身份认证机制，它保证了每一个通信方都拥有自己的专属标签，其他人难以伪造，而且其他人能够验证这个标签，确认它确实属于某一个通信方。
  2. 签名机制的实现可以用非对称密钥解决，我们可以用私钥进行签名，再用公钥进行验签。
  3. 在通信之前，发送方利用私钥对通信内容加密生成签名，将签名连同通信内容一同发送，对方可利用公钥解密该签名，确保签名的正确性。
  4. 由于私钥的保密性，其他人无法伪装。又由于公钥的公开性，任何一个人都可以通过公钥解开私钥加密的数据来进行身份验证。

说说签名的缺点？

签名是利用非对称密钥的加密解密来实现的，而非对称密钥的加密解密依赖于复杂的数学运算，当数据量大的时候，计算签名会非常耗时。为了解决这一问题，引入了摘要和数字签名。

说说摘要？

  1. 一段信息，经过摘要算法处理而得到的一串定长的哈希值，就是摘要(dijest)。
  2. 信息可以是任意长度，而摘要是定长，摘要算法将无限长的数据映射成有限长的数据。
  3. 摘要是不可逆转的，它不存在解密，从摘要反推原信息也很难。
  4. 原数据如果发生变化，那么计算出来的摘要也会发生变化。如果两个数据算出来的摘要是一样的，说明两个数据是完全相同。

数字签名是什么？

  1. 数字签名需要先对通信数据生成摘要，再对摘要进行签名运算，得到的签名即数字签名。
  2. 在通信时，发送方先生成数字签名，将数字签名连同通信内容一同发送，对方可利用公钥解密该数字签名，得到一段摘要。（如果公钥解密失败，说明对方身份被“伪装”）
  3. 第二步则对通信内容使用摘要算法生成摘要（前提是摘要算法公开），与上一段摘要进行比对看是否一致，可验证内容是否被“篡改”。

数字签名和签名的不同？

  1. 签名：直接对通信数据利用私钥生成签名。
  2. 数字签名：先对通信数据生成摘要，再对摘要利用私钥生成签名。

利用混合加密和数字签名是否充分保证了通信安全？

  1. 利用混合加密，我们可以对数据进行加密传输，具备“防窃听”。
  2. 利用数字签名，我们可以验证对方身份和比对数据完整性，具备“防篡改”和“防伪装”。
  3. 混合加密和数字签名他们都利用了非对称密钥加密技术，那么就必须保证一个前提：某个通信方的公钥能够通过网络安全地传输给对方，而不会被其他人篡改或伪装。
  4. 如下所示，在传输公钥这一步没能做到“防篡改”和“防伪装”，导致后续的通信均失败。
  5. 上面提到，数字签名可以保证“防篡改”和“仿伪装”，但数字签名前提是安全地把公钥传输给对方，这就导致了死锁，为了解决这个问题，我们引入了“数字证书”和第三方机构“CA”

CA是什么？

数字证书认证机构（CA，Certificate Authority），是客户端与服务器双方都可信赖的第三方机构，它具备颁布“数字证书”的职能。

数字证书是什么？

  1. 数字证书是一个标志服务器身份信息的数字认证，人们可以在网上用它来识别服务器身份。
  2. 一个X.509（国际标准化的数字证书格式）数字证书包含了以下内容，注意以下内容都是明文的。
    1. 版本（Version）：证书格式版本（如 v3）
    2. 序列号（Serial Number）：CA 颁发的证书唯一标识符。
    3. 签名算法（Signature Algorithm）：标注了生成哈希值（摘要）的哈希算法和生成数字签名的加密算法。
    4. 颁发者（Issuer）：CA 的名称
    5. 有效期（Validity）：证书的有效期
    6. 主体（Subject）：证书持有者的信息，比如服务器域名
    7. 公钥（Public Key）：服务器的公钥
    8. 扩展信息（Extensions）：一些额外信息，如密钥用途。
  3. 数字证书的制作流程：
    1. 服务器向CA提出证书申请，CA会将服务器的身份信息和公钥打包到一起生成数字证书。
    2. CA对这个数字证书计算哈希值生成摘要，用 CA 的私钥加密摘要生成数字签名
    3. 签名被附加到证书的数字签名字段
  4. 数字证书的使用流程：
    1. 服务器向CA申请一个数字证书，然后将该证书保存到服务器中。
    2. 如果客户端想发起连接，则将证书发送给客户端。
    3. 客户端获取证书后，利用CA的公钥来对证书中的数字签名字段验签，获取保存在其中的哈希值（摘要）。
    4. 客户端对除去数字签名字段外的数字证书明文部分生成哈希值（摘要），这里使用的哈希算法在证书中就有标注。
    5. 验证前两步的摘要是否相同，相同即可证明对方身份，并且获取对方的公钥。之后就可以利用对方公钥来进行混合加密，确保接下来通信过程的安全。

数字证书是否是明文的？

  1. 数字证书中只有签名字段是加密的，它由 CA 的私钥生成，用于验证证书的完整性。其他部分全部都是明文的。
  2. 尽管证书内容是明文，但依然安全，因为数字证书的设计主要是用于防篡改（任何对证书内容的修改都会导致哈希值变化，使签名验证失败）和防伪装（只有持有 CA 私钥的机构能生成有效签名，伪造证书会被客户端拒绝），它并不防窃听。
  3. 再者说，证书本身包含的服务器公钥就是可以公开的，因此并不会影响安全性。

数字证书的可靠性由谁保证？

  1. 数字证书由CA颁布，其中包含了服务器的公钥，如果想要验证证书真伪，就需要用到CA的公钥，此时就有个怪圈，万一CA的公钥被伪造，那么证书不也变得不安全吗？
  2. 为了证明CA的数字证书以及CA的公钥是可靠的，在各个CA之间设立了层级关系。每一层CA都有一个验证自身身份的数字证书，其中放置了CA的公钥，而用于验证证书真伪的签名字段则用上层CA的私钥去进行数字签名。这样一层套一层，一层验证一层的CA公钥的体系被称为证书链。
  3. 位于最上层的CA被称为根CA，它的数字证书（根证书）是自签的，也就是用自己的私钥对包含自己公钥的数字证书进行了数字签名。根证书一般由操作系统和浏览器预装在计算机内部，它的可靠性无需靠证书链验证。即使根证书无法使用，客户端也可进行网上查询对比，以此判断证书的可靠性。

数字签名和数字证书的区别？

  1. 数字证书本身就包含了数字签名，数字证书明文存储了服务器公钥、身份信息等数据，然后使用CA的私钥生成数字签名，最后CA会将这些信息（包括数字签名）打包成最终的数字证书。
  2. 数字签名可由任何一方制作，数字证书只能由CA颁布。

crt文件和pem文件是什么？

  1. crt文件是一种证书文件，用于存储数字证书，它有两种格式：
    1. PEM 格式（ASCII 文本，以 -----BEGIN CERTIFICATE----- 开头）
    2. DER 格式（二进制格式，不可直接阅读）
  2. pem文件是一种通用格式的文件，既可以用于存储证书，也可以存储私钥，使用ASCII文本存储，一般使用BASE64编码。

BASE64编码是什么？

  1. BASE64 是一种将二进制数据转换为可打印ASCII字符的编码方式，目的是让二进制数据能在纯文本环境中安全传输或存储（如电子邮件、JSON、配置文件等）。
  2. BASE64编码后的文本只能用数字，大小写字母以及 +/=组成，容易识别。

如果想对一个域名配置HTTPS，至少需要哪些文件？

  1. 证书文件：
    1. 用于存放服务器申请的数字证书。
    2. 由于CA公钥也需要被验证真伪，因此证书文件中不仅包含了服务器申请的数字证书，还存放了用于验证CA公钥的CA本身的数字证书。
    3. 这样一层一层接下去，整个证书文件中会存放多个中间CA的数字证书，这就是所谓的证书链。直到某个CA的数字证书可以由根证书存放的公钥验证时，才无需继续存放。
    4. 数字证书的存储格式为二进制，为了兼容性和可读性，证书文件中以BASE64进行编码，并将各个数字证书通过特定的分隔符 -----BEGIN CERTIFICATE-----分开。
  2. 私钥文件：
    1. 用于存放于服务器公钥对应的私钥
    2. 私钥的存储格式为二进制，为了兼容性和可读性，同样以BASE64编码。

说说HTTPS的通信过程？

  1. HTTPS使用了混合加密+数字证书的机制。
  2. 混合加密：在通信正式开始前，先使用一组非对称密钥来加密传输一组对称密钥，这样双方就获得了一组相同的对称密钥，之后的通信过程都使用对称密钥来加密传输数据，确保数据的机密性，实现“防窃听”，同时还具有较高的加密解密效率。
  3. 数字证书：为了确保服务器公钥可以不被篡改和伪装地传输给客户端，服务器使用了数字证书来确保公钥可靠性。首先由服务器向CA申请数字证书，服务器获得数字证书后会保存到本地。之后客户端想要进行通信时，就将数字证书发送给客户端，客户端获取证书后利用CA的公钥进行验证。验证通过即可证明对方身份，并且获取对方的公钥，之后的通信就可以利用该公钥完成接下来的混合加密。

HTTPS和HTTP的区别？

  1. HTTPS采用了混合加密+数字证书，安全性更高。
  2. HTTP和HTTPS使用的端口不一样，前者是80，后者是443。

RSA和DH算法是什么？

  1. RSA算法是一种非对称加密算法，前文所指的非对称加密和签名大多使用该算法实现。
  2. DH算法（Diffie-Hellman）是一种非对称加密算法，让通信双方在不传输密钥的情况下，通过公开交换信息生成一个相同的共享密钥（用于后续对称加密），它的过程包括以下几步：
    1. 参数准备：双方事先公开几个协商好的参数（攻击者可获取）。
    2. 临时私钥：双方各自在本地生成临时私钥（攻击者不可获取）。
    3. 临时公钥：双方使用之前协商好的参数和私钥生成临时公钥，然后再将临时公钥发送给对方（攻击者可获取）。
    4. 共享密钥：双方将对方的临时公钥、本地的临时私钥以及之前协商好的参数生成共享密钥，之后就可以利用这对共享密钥进行对称加密了。这对计算出来的共享密钥完全相同，而攻击者由于无法获取双方本地生成的临时私钥，因为也就无法获取相应的共享密钥了。
  3. 前向加密：
    1. 前向加密是一种加密通信的安全特性，确保即使私钥泄露，过去的通信记录也无法被解密。
    2. RSA算法无法确保前向加密，因为如果私钥被破解，那么之前的通信记录都会被获取，一个好的解决方法是定期更换公私钥。
    3. DH算法自带前向加密属性，因为每次都需要通信双方临时生成公私钥，如果每次选用的参数不同，那么最后生成的共享密钥也不同，即使私钥被破解，攻击者也只能获取某次连接的通信记录。

什么是TLS握手，TLS各个版本的TLS握手有什么不同？

  1. TLS握手是客户端（如浏览器）和服务器（如网站）在建立加密通信通道前，协商加密参数、验证身份并生成共享密钥的过程。
  2. TLS从1.0到1.2的TLS握手在本质上没有什么不同，主要分为以下几步，总消耗为2次RTT
    1. 客户端->服务器：发送客户端目前支持的TLS版本和加密算法参数
    2. 服务器->客户端：选择客户端支持的TLS版本，并发送证书文件给客户端
    3. 客户端->服务器：客户端验证数字证书，本地生成对称密钥，并用服务器的公钥加密后发送给服务器
    4. 服务器->客户端：服务器解密数据后拿到对称密钥，并回复应答给客户端，完成TLS握手
  3. TLS1.2支持版本降级、RSA和DH算法，所以前面的第一次RTT非常重要，无法省去。
  4. TLS1.3舍去了使用RSA交换密钥，仅使用DH算法，不支持版本降级。因此，TLS握手得到了极大的优化：
    1. 1-RTT：仅需一次RTT（用于交换临时公钥）就能完成握手，不再需要协商加密算法参数和TLS版本了，之后使用计算出来的共享密钥就可以进行对称加密了。
    2. 0-RTT：在客户端重复连接同一服务端时（如网页刷新），0次RTT就可以安全连接，仅需用到客户端之前缓冲的共享密钥即可。
  5. 值得注意的是，以上提出的TLS握手仅局限于TLS层，如果底层使用的是TCP，则需要额外加上一次RTT完成TCP握手。但这种情况是将TCP和TLS层完全分开的情况，实际上在TCP第一轮RTT时，就可以附加TLS的第一轮RTT，因此TCP+TLS的RTT次数跟单TLS没有区别。
  6. 如果使用的是HTTP3.0，因为底层使用的是UDP，那么此时整个连接都只需要一次RTT即可完成。

TLS的版本降级攻击是什么？

  1. 因为TLS支持版本降级，所以攻击者可以通过篡改TLS握手消息，强制让客户端和服务端都使用旧版不安全的 TLS（如 1.0/1.1），从而利用旧版本漏洞解密通信。
  2. TLS1.3中，这种攻击被完全阻断，因为TLS1.3不支持版本降级，如果客户端要求使用TLS1.2及以下的版本，会直接返回错误。

TLS1.3还需要用到数字证书吗？

需要。虽然TLS1.3不使用RSA生成的公私钥来交换对称密钥，但仍需要使用数字证书来进行身份认证，确保服务器不被伪装。

  1. 在TLS握手时，服务器会生成临时公钥，然后用自己注册到CA的公钥所对应的私钥来对临时公钥作数字签名，并将临时公钥，数字证书和数字签名发送给客户端。
  2. 客户端收到消息后，验证数字证书真伪，然后拿到数字证书中的公钥，最后用该公钥验证临时公钥是否被篡改或伪装。
  3. 实际上服务器不仅是对临时公钥作数字签名，还对很多服务器和客户端共有的信息来作数字签名，进一步确保可靠性，只不过本文简化了这一操作。

SNI是什么？

SNI（Server Name Indication）是 TLS协议的扩展功能，用于解决 单台服务器托管多个 HTTPS 网站时的证书匹配问题。它的核心作用是让客户端在 TLS 握手阶段明确告诉服务器自己要访问哪个域名，从而服务器能返回正确的证书。它有以下特点

  1. 必须明文传输：SNI 在 TLS 握手初期发送，尚未加密，容易被泄露
  2. 依赖客户端支持：现代浏览器和操作系统均支持 SNI，但旧设备可能不行
  3. 服务器需配置多证书：服务器需要使用类似Nginx、Apache等工具配置虚拟主机，为每个域名绑定独立证书。

其他

Token是什么？

  1. Token（令牌）是一种用于 身份验证（Authentication）和授权（Authorization） 的凭证，通常由服务器生成并发送给客户端，客户端在后续请求中携带该 Token 以证明身份或权限。以下是几种常见的Token：
  2. Session Token（会话令牌）：用于维护用户登陆状态，以 Cookie 形式存储和发送，比如Session ID。
  3. JWT（JSON Web Token）：无状态（Stateless）身份验证，适用于 RESTful API。通常放在请求头的 Authorization 字段。
  4. OAuth2 Access Token（访问令牌）：第三方授权（如 Google、GitHub 登录）。通常放在请求头的 Authorization 字段。

详细说说JWT？

  1. JWT是一种无状态的身份验证机制，它存储在客户端，具有强大的防篡位和防伪装能力
  2. JWT由三部分组成，它们之间使用 .区分：
    1. Header（头部）：说明令牌类型（JWT）和签名算法（后面会用到）
    2. Payload（负载）：存放用户数据（比如用户名）和JWT有效期
    3. Signature（签名）：对Header和Payload生成的签名，用于验证JWT未被伪装和篡改
  3. JWT的工作原理：客户端提交用户名和密码，服务端验证通过后会生成JWT。这里服务器会在本地保存一个私钥，这个私钥可以对JWT作签名，然后将签名和JWT的其余信息组合在一起生成完整的JWT并发送给客户端。之后服务端再接收到JWT时，就可以再次使用私钥验证JWT了，防止第三方的篡改和伪装。

为什么JWT是无状态的，它与Session的区别在哪里？

  1. Session的问题：
    1. Session是一种有状态的身份验证机制，服务端必须存储用户的会话数据，客户端仅保存一个随机生成的Session ID。
    2. Session对分布式不友好，多台分布式服务器之间需要同步Session数据才能验证客户信息。即使在后端使用数据库统一处理，也容易因为单点故障而导致服务失效。
  2. JWT的解决方案：
    1. JWT是一种无状态的身份验证机制，它将用户数据直接存储在JWT的Payload部分，并通过签名确保数据完整性。服务端无需存储任何会话信息，只需验证签名和过期时间即可。
    2. JWT对分布式很友好，因为多个用户的JWT可以用同一个的私钥去验证，这样在多台分布式服务器上同步就非常简单，服务器也不需要去查询数据库。

JWT的缺点？

  1. 无法主动废止：默认情况下，JWT在过期前始终有效
  2. 数据暴露：JWT 的 Payload（负载） 仅是 Base64 编码，而非加密，任何人都可以解码查看内容。
  3. 性能损耗：JWT的长度通常比Session ID要长，每次请求都会在 Authorization 头或 Cookie 中携带，增加网络开销。

如果JWT泄露了怎么办？

  1. 短期令牌：若使用短期有效期（如15-30分钟），可等待其自动过期，但需配合其他措施
  2. 动态密钥轮换：定期更换JWT签名密钥
  3. 异常行为检测：监控同一令牌在不同IP/设备的使用情况
  4. 仅限HTTPS：确保所有传输通过TLS加密
  5. 避免本地存储风险：浏览器端避免 localStorage，优先使用 HttpOnly、Secure、SameSite=Strict的Cookie

什么是CORS

  1. 为了安全，浏览器会限制网页中的脚本只能访问同协议、同域名、同端口的资源，这就是浏览器的同源策略（SOP）限制。目前，大部分浏览器对于一些简单的跨域请求，是允许直接发送的，而对于一些复杂请求，则会收到SOP的限制，除非使用CORS解除限制。
  2. 如果没有SOP，假设你登录了银行网站（A），同时打开了恶意网站（B）。B的脚本可以通过浏览器悄悄访问A的页面内容（如账户余额），窃取数据。
  3. CORS（Cross-Origin Resource Sharing，跨域资源共享）是一种基于HTTP头的安全机制，用于控制浏览器是否允许一个网页的脚本访问来自不同域（源）的资源，它需要浏览器和服务器的共同协作才可完成。
  4. 在受到SOP限制时，浏览器会发送 OPTIONS 预检请求给到脚本想访问的其他资源所在的网站，询问服务器是否允许跨域。
  5. 服务器可以自定义配置，比如允许某个源使用某个方法来访问本服务器上的资源。这样在收到 OPTIONS 预检请求

SQL注入攻击是什么？

  1. 大部分HTTP服务在客户端第一次登陆时，都会要求输入用户名和密码，服务端收到后，会利用这些信息在数据库中查询，以验证客户端身份。
  2. SQL注入攻击就是在这种场景下，在输入字段中插入恶意SQL代码，来篡改SQL查询语句，以达到非法访问、篡改或删除数据库数据的攻击方式。
  3. 比如以下就是最常见的SQL注入攻击 
    //正常的SQL查询如下，用户输入 admin 和 123456，程序拼接成合法SQL语句
SELECT * FROM users WHERE username = 'admin' AND password = '123456';

//攻击者使用SQL注释符'--'，导致后面的条件被忽略，无需密码即可登录。
SELECT * FROM users WHERE username = 'admin' -- ' AND password = '123';
  4. 常见的防御方式包括：
    1. 对用户输入过滤。
    2. 使用参数化查询，不拼接SQL，而是用占位符传递参数。
    3. 使用成熟的数据库代码框架（ORM），避免直接编写SQL语句。

XSS攻击是什么？

  1. XSS（Cross-Site Scripting，跨站脚本攻击）是一种通过向网页注入恶意脚本（通常是JavaScript），在用户浏览时执行的攻击方式。XSS最主要的用途是用来窃取用户Cookie，传播恶意病毒等。
  2. XSS的核心原理在于客户端和服务器没有对用户输入的内容进行严格过滤，导致恶意脚本被存入数据库或直接插入页面。XSS分为三大类：反射性、存储型、DOM型
  3. 反射型XSS：攻击者构造恶意URL并诱导用户点击，服务器没有对URL进行过滤，直接将URL的参数输出到页面，导致恶意脚本执行，如下 
    https://example.com/search?q=<script>alert('XSS')</script>
  4. 存储型XSS：攻击者在论坛/评论区提交含恶意脚本的内容，服务器没有对内容进行过滤，直接存储该内容并显示给其他用户，导致其他用户浏览页面时，脚本自动执行。如下 
    <script>stealCookie()</script>
  5. DOM型XSS：这是一种纯客户端攻击，攻击者同样构造恶意URL，但该URL不会被完整发送到服务器。比如URL中的#号字段，是用于同页面下的跳转，仅在客户端生效，并不会被发往服务器。这样恶意URL在跳转到对应页面时就会执行恶意脚本了。如下 
    https://example.com/#<img src=x onerror=alert('XSS')>
  6. XSS之所以叫作“跨站”攻击，是因为本来存储在攻击者服务器上的恶意脚本，被客户端误以为属于当前访问的目标网站，绕过了浏览器的SOP限制，因此允许其访问该站的Cookie等数据，并自动执行脚本。
  7. 防御措施：
    1. 客户端和服务端应该对用户输入和URL进行过滤。
    2. Cookie设置HTTP Only属性，使得恶意的JS脚本无法读取，只能通过HTTP发送和接受。
    3. 使用现代化的Web框架，大部分都有抵御XSS的相应策略。

CSRF攻击是什么？

  1. CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种利用用户已登录的身份，在用户不知情的情况下，诱导其执行非预期操作的攻击方式。攻击者通过伪造请求（如转账、改密码），欺骗用户的浏览器以合法身份向目标网站发送恶意请求。
  2. CSRF的攻击流程如下：
    1. 用户已登录目标网站A，并且在本地存储了其身份验证信息，比如Cookie
    2. 攻击者伪造一个正常网站B，让用户访问，该网站包含一个伪造请求，用于向A提交某个操作。
    3. 由于浏览器会在访问相应网站时附上身份认证信息，因此服务器验证通过，执行该伪造请求，而用户此时并不知情，攻击者也无需获取用户的身份认证信息，可以对任何用户实施该攻击。
  3. 防御措施：
    1. CSRF Token：服务端生成随机Token发送给客户端，如果客户端发送的请求没有该Token，则不执行相关操作。该机制不同于Cookie等机制，在访问目标网站时并不会被自动嵌入，这就要求攻击者必须持有该Token才可以完成请求伪造。
    2. SameSite Cookie：设置Cookie的 SameSite 属性，限制跨站请求携带Cookie。
    3. Origin和Referer：通过这两个HTTP头部字段，服务器可以很容易区分出该请求的来源，以此验证用户身份。
    4. CROS：服务器配置CROS，限制跨域请求来源和跨域请求方法。

说说DNS劫持？

  1. DNS劫持（DNS Hijacking）是一种网络攻击手段，通过篡改DNS解析结果，将用户对合法域名的访问重定向到恶意服务器，从而窃取数据、植入恶意软件或展示虚假内容。
  2. DNS劫持有几种方法实现：篡改本地DNS设置、攻击公共DNS服务器，或者在中间劫持DNS解析包并进行篡改。
  3. HTTPS可以有效抵御DNS劫持，因为证书和加密的双重保证下，DNS劫持很难成功，但在以下几种情况下不行：
    1. 攻击者攻击CA获取私钥，伪造合法证书
    2. 用户强制跳过证书警告，访问不安全网站
    3. 攻击者通过DNS劫持，将使用HTTPS访问目标服务器的IP修改为使用HTTP访问

什么是DoT/DoH？

  1. 传统DNS：域名解析以明文形式通过UDP/TCP传输，容易被监听、劫持或篡改（如广告注入、网络监控）。
  2. DoT（DNS over TLS）：DNS改用TCP的853端口来进行域名解析，并使用TLS加密，防止攻击者窃听、劫持和篡改。
  3. DoH（DNS over HTTPS）：将DNS请求封装在 HTTPS 中（使用TLS加密），与网页浏览流量混合，难以被识别或干扰。值得注意的是，HTTPS依赖域名系统，那么在DoH下，DNS服务器的IP地址也需要依赖域名解析来获取，也就是嵌套。为了安全起见，可以将域名解析服务器的IP地址写入本地主机的Host文件中，直接通过IP地址来进行DoH请求。
  4. DoT的853端口容易被屏蔽，而且不如DoH隐蔽，因为DoH与网页流量混合到一起，难以区分。

什么是ESNI？

  1. 在 HTTPS 连接时，客户端会以明文发送当前想要访问的域名，即SNI（例如访问 example.com），告知服务器要连接哪个网站。这样导致的问题是，即使流量被 TLS 加密，SNI 仍可被中间人（如 ISP、防火墙）监听，暴露用户访问的域名。
  2. ESNI是加密的SNI，它使用以下步骤来加密SNI，确保SNI不会被第三方查看，保护隐私：
    1. 客户端向DNS服务器发送查询，以查询网站的IP地址。
    2. DNS响应中会包含服务器的IP地址以及服务器提前注册到DNS服务器上的公钥。
    3. 客户端向服务器发送请求连接的消息，其中会使用DNS响应中的公钥对SNI部分进行加密。
    4. 服务器使用自己的私钥解密SNI，并发送对应的证书给客户端，此后就是正常的TLS握手步骤。
  3. ESNI通常需要DoH来配合，因为ESNI的目的是保护客户端访问的域名不被第三方查看，可是如果在DNS解析时不进行加密，那么会导致域名在域名解析这一步就被泄露，使得ESNI没有太大的意义。
  4. 在ESNI的最后一步，服务器需要将证书明文发生给客户端，此时证书会包含客户端请求的域名，那么会导致SNI泄露吗？实际上并不会，很多网站都采用了泛域名证书，证书不暴露具体子域名。此外，多个域名可能共用同一个证书，攻击者也无法精确匹配用户访问的具体网站。

什么是ECH?

  1. ECH（Encrypted Client Hello，加密客户端问候） 是 TLS 1.3 的扩展协议，用于加密整个 ClientHello 消息（包括 SNI 和 TLS 指纹），彻底防止中间人窥探用户访问的网站。它是 ESNI（Encrypted SNI）的升级版，进一步增强了隐私保护。
  2. ECH的工作流程与ESNI基本相同，但不同点在于ECH加密了整个TLS握手消息，隐藏了更多信息，攻击者无法简单通过TLS的握手特征来判断SNI（因为ESNI只加密了SNI，不同的SNI有不同的加密特征）。并且，ECH支持服务器返回一个通用证书，真正的证书通过加密通道传输，彻底隔绝攻击者探查。
  3. ECH同样需要DoH才可以彻底保证安全性。

什么是DoS和DDoS攻击？

  1. DoS (Denial of Service)：拒绝服务攻击是一种网络攻击，其目的是使目标服务器或网络资源无法处理合法的请求。这种攻击通常通过发送大量的请求到目标服务器，使其资源耗尽，从而无法响应合法用户。
  2. DDoS (Distributed Denial of Service)：分布式拒绝服务攻击是DoS攻击的一种形式，它使用多个计算机或网络资源来发起攻击。这些计算机通常是被恶意软件感染的僵尸网络（Botnet）的一部分，它们被远程控制来同时向目标发送大量请求。
  3. 网络层DDoS：网络层的DDoS攻击通常使用ICMP协议的数据包，这种攻击可以消耗被攻击者的网络带宽。
  4. 传输层DDoS：传输层的DDoS攻击主要是发送大量的SYN数据包给目标系统，但不会回复确认包，从而使目标系统的半连接队列占满，无法响应正常请求，通常被称为“三次握手攻击”或“SYN攻击”。
  5. 应用层DDoS：应用层的DDoS攻击（以HTTP为例）通常是攻击者向目标Web服务器发送一个HTTP请求，但不会一次性发送完整的请求头，而是每隔一定时间重复发送一小部分数据。这使得连接保持打开状态，占用服务器的连接队列。
  6. 放大攻击：放大攻击是一种特殊的DDoS攻击，它利用反射和放大技术来实现，最常见的是DNS放大攻击。攻击者伪造成被攻击者的IP地址，向DNS服务器发送大量的DNS请求，DNS服务器会相应DNS响应给被攻击者，由于DNS响应一般比DNS请求的数据量要大，导致被攻击者在短时间内需要处理大量的DNS响应。

参考资料

《计算机网络》

《看完这篇HTTP，跟面试官扯皮就没问题了》

《HTTP协议简单解释》

《【区别】摘要、数字签名、数字证书》

《【计算机网络】HTTP常见面试题》

《session、cookie、token 详解》

《Web基础：Token》

《一文彻底搞懂加密、数字签名和数字证书...》

《理解RESTful架构》