跳到主要内容

http

webscoket特点

用于在浏览器和服务器之间建立持久性

  1. 双向通信:
    • 允许浏览器和服务器进行双向通信 聊天应用、实时游戏、股票行情等。
  2. 持久连接:
    • 连接是持久性的,一旦建立,连接就会一直保持,直到客户端或服务器主动关闭连接。
  3. 低延迟:
    • 握手比 HTTP 简单,因此建立连接的延迟较低。
  4. 轻量性:
    • WebSocket 协议的数据帧比 HTTP 报头更小
  5. 跨域支持:

WebSocket长轮询和短轮询?

短轮询(Short Polling):

  • 客户端定期向服务器发送请求,询问是否有新的数据。没有新数据,返回空响应,有新数据,返回数据并关闭连接。
  • 缺点:频繁的请求和响应会导致较高的网络开销和延迟,因为每次请求都需要建立和关闭连接。

长轮询(Long Polling):

  • 客户端向服务器发送请求后,服务器不会立即返回响应。没有新数据,保持打开连接,直到有新数据或超时。一旦有新数据或超时,服务器会返回响应,并关闭连接。
  • 优点:与短轮询相比,长轮询减少了请求的频率,从而减少了网络开销和延迟。
  • 缺点:仍然存在延迟,因为客户端需要等待服务器响应。此外,如果服务器长时间没有新数据,连接可能会超时,导致客户端需要重新发起请求。

为什么websorket可以实现跨域

  1. 不受 CORS(跨域资源共享)限制,因为它是基于不同的协议(wswss),而不是 HTTP。
  2. 浏览器在 WebSocket 握手时,会发送 Origin 头,服务器可以根据该头信息决定是否允许跨域连接。如果服务器接受,浏览器会继续建立连接。

webRtc websokcet 心跳包

WebRTC主要用于点对点的实时通信,它允许浏览器之间直接建立连接,无需通过服务器中转,从而实现低延迟的通信,

WebSocket是一种全双工的通信协议,它允许服务器和客户端之间通过单个TCP连接进行实时数据交换。用于需要服务器向客户端推送数据的场景,如实时聊天、股票行情更新等。

为了保持连接的有效性,通常需要发送心跳包心跳包是一种周期性发送的数据包,用于检测连接是否仍然活跃。如果在一定时间内没有收到对方的心跳包,可以认为连接已经断开,需要重新建立连接

如何维持websocket登录 深入 如何维持websocket登录时间 用户无感知

使用Token进行认证

在建立WebSocket连接之前,用户通常需要通过HTTP请求进行登录认证,并获取一个Token(如JWT)。这个Token可以包含用户的身份信息和过期时间。在WebSocket连接建立后,客户端会将Token发送给服务器,服务器验证Token的有效性后,允许用户建立连接。

心跳机制

为了维持WebSocket连接的活跃状态,客户端和服务器之间可以实现心跳机制。心跳机制是指客户端定期发送一个简单的消息(如空消息或特定格式的消息)给服务器,服务器收到后回复一个确认消息。如果在一定时间内没有收到心跳消息,服务器可以认为连接已经断开,并采取相应的措施。

Token刷新机制

Token通常有一个过期时间,为了维持用户登录状态,可以在客户端实现一个Token刷新机制。当Token即将过期时,客户端可以自动发起一个HTTP请求来刷新Token。刷新Token的过程可以是透明的,用户无需感知。

服务器端的会话管理

服务器端需要维护一个会话管理机制,用于跟踪每个WebSocket连接的状态。当客户端发送心跳消息时,服务器端可以更新会话的最后活跃时间。如果会话长时间未更新,服务器可以主动断开连接。

客户端的重连机制

即使服务器端采取了措施维持连接,网络问题或服务器重启等情况仍可能导致连接断开。因此,客户端需要实现重连机制。当检测到连接断开时,客户端应尝试重新连接,并在重新连接成功后,发送必要的信息(如用户ID、Token等)来恢复之前的会话状态。

token安全体现在什么地方,怎么实现的(用的jwt),路由拦截做了吗(比如未登录进入主页面)

身份验证与授权:通过 Token,我们可以确保用户身份的有效性并验证他们是否有访问某些资源的权限。

防止伪造和篡改:使用 JWT(JSON Web Token)时,Token 会被签名,防止了伪造和篡改,保证 Token 的合法性。

安全存储:Token 的存储方式会影响安全性。它应该存储在安全的位置(如 HTTPOnly cookies),避免被 JavaScript 访问。

过期和刷新机制:Token 通常有过期时间,过期后必须重新登录获取新的 Token,增强了安全性。可以通过 Refresh Token 来支持无缝的用户体验。

DNS域名解析的过程

DNS 是 Internet 中用于将域名转换为 IP 地址的一个分布式数据库系统

  1. 本地缓存查找
  2. 本地 DNS 服务器查询本地 DNS 服务器会进行递归查询,依次查找根域名服务器、顶级域名服务器和权威域名服务器,直到找到该域名的 IP 地址。
    • 根域名服务器: 负责解析顶级域名(如 .com、.org、.net 等)。
    • 顶级域名服务器: 负责解析该顶级域名下的二级域名(如 example.com)。
    • 权威域名服务器: 负责解析该域名的具体 IP 地址。
  3. 返回 IP 地址: 最终,权威域名服务器会将查询结果(域名对应的 IP 地址)返回给本地 DNS 服务器,本地 DNS 服务器再将结果返回给客户端浏览器。
  4. 缓存更新: 浏览器收到 IP 地址后,会将其缓存一定时间,以便下次访问同一域名时能够直接使用缓存,加快访问速度。

tcp连接 为什么需要三次?两次和四次不行吗?

  1. 为什么不能用两次握手?. 无法确保可靠连接的建立。
    • 第一次服务器并知道客户端的存在,客户端不知道服务器的存在。
    • 第二次服务器知道客户端的存在,但客户端不知道服务器是否收到自己的请求。
  2. 为什么需要三次握手? 三次握手可以确保TCP连接的可靠建立。
    • 第一次让客户端知道服务器的存在,并告诉服务器建立连接。
    • 第二次让服务器知道客户端的存在,并告诉客户端可以建立连接。
    • 第三次让客户端知道服务器收到了自己的连接请求。
  3. 为什么不能用四次握手?
    • 四次挥手也可以实现 TCP 连接的可靠释放,但不必要。
    • 三次挥手就可以完成连接的释放,第四次挥手其实是多余的。
  4. 为什么需要四次挥手?
    • 四次挥手可以确保 TCP 连接的可靠释放。
    • 第一次关闭方告诉被动关闭方要关闭连接。
    • 第二次被动关闭方收到关闭请求,并发送关闭确认。
    • 第三次关闭方知道自己的关闭请求被对方收到。
    • 第四次被动关闭方知道自己的关闭确认被收到。

tcp怎么保证可靠传输

  1. 每个数据包分配一个序列号,接收后会发送确认号给对方。
  2. 如果指定时间内没有收到确认号,就会重传数据包
  3. 滑动窗口机制来控制发送速率,避免接收方缓存溢出
  4. 检测到网络拥塞时,会自动降低发送速率。
  5. 接收方会重新计算校验和并与原校验和对比。
  6. 三次握手和四次挥手来建立和关闭连接,确保连接的可靠性。

如何实现一个tcp

  1. 建立 TCP 套接字
    • 使用操作系统提供的套接字 API 创建 TCP 套接字。
    • 定义套接字的地址族、类型和协议。
  2. 连接建立
    • 服务器端监听指定的端口,等待客户端的连接请求。
    • 客户端主动发起连接请求,经过三次握手完成连接建立。
  3. 数据传输
    • 使用 send() 和 recv() 函数在客户端和服务器端进行数据收发。
    • 处理乱序、丢包、重复等异常情况,保证数据的可靠性。
    • 实现流量控制和拥塞控制算法,动态调整发送速率。
  4. 连接释放
    • 任意一方主动发起连接释放请求,经过四次挥手完成连接关闭。
    • 释放系统资源,如套接字、缓存区等。
  5. 其他细节
    • 设计合理的数据结构,如维护 TCP 连接状态机。
    • 实现超时重传、滑动窗口等机制。
    • 处理各种异常情况,如 RST 报文、超时等。
    • 优化性能,如缓冲区管理、多线程/异步IO设计等。

tcp和udp的区别

  • TCP 是面向连接的协议,提供可靠的数据传输。UDP 是无连接的协议,不提供可靠性保证。

  • TCP 需要三次握手建立连接。 UDP 不需要建立连接,直接发送数据报。

  • UDP 比 传输速度较快。

  • TCP 头部较大,包含更多控制信息。 UDP 头部较小,开销较低。

  • TCP 适用于要求高可靠性的应用,如 Web 浏览、文件传输、电子邮件等。UDP 适用于对实时性要求较高,但可靠性要求较低的应用,如视频会议、在线游戏、流媒体等。

  • TCP 有流量控制和拥塞控制机制,可以根据网络状况调整发送速率。 UDP 没有流量控制和拥塞控制机制,发送速率由应用层决定。

浏览器TCP连接是串行的吗 浏览器每建立一个TCP连接都会绑定一个端口,假如有100个连接呢

TCP 连接是并行的,每个连接都可以独立处理数据,浏览器可以并行建立多个连接。

每个 TCP 连接绑定一个唯一的本地端口,可以同时存在多个连接,操作系统会动态分配端口。

浏览器会限制每个域名的最大连接数,例如 Chrome 默认限制每个域名最大 6 个连接。

如果有 100 个连接,操作系统会为每个连接分配不同的本地端口,确保这些连接可以并行处理。

常见的网络加密算法有什么

  1. 对称加密算法:
    • AES (Advanced Encryption Standard):目前最流行的对称加密算法之一,支持128/192/256位密钥。
    • DES (Data Encryption Standard):历史上广泛使用的对称加密算法,密钥长度为56位,现已逐渐淘汰。
    • 3DES (Triple DES):对DES算法进行三重加密以增强安全性。
  2. 非对称加密算法:
    • RSA (Rivest-Shamir-Adleman):基于大数分解的非对称加密算法,广泛应用于HTTPS、数字签名等场景。
    • ECC (Elliptic Curve Cryptography):基于椭圆曲线的非对称加密算法,相比RSA具有更高的安全性和效率。
  3. 哈希算法:
    • MD5 (Message Digest 5):历史上广泛使用的哈希算法,但已被证实存在安全隐患,不应再使用。
    • SHA-2 (Secure Hash Algorithm 2):目前最常用的哈希算法系列,包括SHA-256、SHA-384等。
    • SHA-3 (Secure Hash Algorithm 3):2015年颁布的新一代哈希算法标准。
  4. 其他算法:
    • Blowfish:一种快速高效的对称加密算法,适合嵌入式系统和硬件加速器。
    • ChaCha20-Poly1305:基于流密码的加密和认证算法,在对抗网络环境中具有优势。
    • SM2/SM3/SM4:中国国密算法标准,用于保护中国国内的网络和信息系统。

进程和线程的区别

  1. 定义
    • 进程是程序在执行过程中的一次动态执行过程。
    • 线程是进程中的一个执行单元,一个进程可以有多个线程。
  2. 资源分配
    • 进程是资源分配的基本单位
    • 线程是资源使用的基本单位
  3. 通信方式
    • 进程间通信一般使用IPC(进程间通信)机制,如管道、信号量、消息队列等。
    • 线程间通信相对简单,可以通过共享内存、加锁等方式实现。

进程的通信方法

  1. 管道(Pipe)
    • 管道是一种半双工的通信方式,数据只能单向流动。
    • 分为匿名管道和命名管道两种形式。
    • 匿名管道只能用于具有亲缘关系的进程之间(父子进程或兄弟进程)。
    • 命名管道(FIFO)可用于任意进程之间的通信。
  2. 消息队列(Message Queue)
    • 消息队列是消息的链接列表,存放在内核中。
    • 可以实现进程间有顺序地交换数据。
    • 消息队列独立于发送与接收进程,消息队列存在于系统中直到被明确删除。
  3. 信号量(Semaphore)
    • 信号量是一个计数器,可用于控制多个进程对共享资源的访问。
    • 通常用于实现进程间的互斥与同步。
    • 有二值信号量(二进制信号量)和整型信号量两种。
  4. 共享内存(Shared Memory)
    • 共享内存是最快的一种 IPC 方式,允许多个进程同时访问一块指定的内存区域。
    • 需要依靠某种同步机制(如信号量)来协调对共享内存的访问。
  5. 套接字(Socket)
    • 套接字是一种特殊的文件,提供了一种进程间通信(网络通信)的机制。
    • 可用于同一台主机上的进程间通信(Unix Domain Socket),或者不同主机之间的网络通信。
  6. 消息传递(Message Passing)
    • 消息传递是一种更高层次的IPC机制,通过发送和接受消息的方式实现进程间通信。
    • 消息传递可以是同步的,也可以是异步的,双方要通过事先约定的格式交换信息。

如何避免内存分配碎片化

  1. 对齐内存分配
    • 尽可能申请对齐的内存块,比如按 4 字节、8 字节或 16 字节对齐。这可以减少内存碎片。
    • 使用操作系统提供的内存分配函数,如 malloc、calloc 等,它们通常会自动进行内存对齐。
  2. 使用内存池技术
    • 预先分配一个大的内存块作为内存池,然后从内存池中分配小块内存给程序使用。
    • 内存池可以减少内存碎片,并提高内存分配效率。
  3. 采用伙伴系统分配算法
    • 伙伴系统是一种动态内存分配算法,可以高效地管理内存块,减少内存碎片。
    • 操作系统内核通常使用伙伴系统算法进行内存管理。
  4. 合理设计数据结构
    • 尽量使用连续的内存块,如数组而不是链表。
    • 对于动态分配的内存,可以使用内存池或者预分配一定量的内存。
  5. 定期整理内存碎片
    • 可以定期对已分配的内存块进行整理和合并,减少内存碎片。
    • 一些操作系统会自动执行内存整理,如Windows的内存整理工具。
  6. 采用可变长度内存分配
    • 使用可变长度的内存分配,如 realloc() 函数,可以根据需求动态调整内存块大小。
    • 这样可以减少内存浪费和碎片化问题。
  7. 使用专门的内存管理库
    • 一些第三方内存管理库,如jemalloc、tcmalloc 等,可以更好地管理内存并减少碎片化。
    • 这些库通常采用更优化的内存分配算

什么叫双token身份验证

增强型的身份验证方式

  1. 第一步骤:验证用户名和密码
  2. 第二步骤:提供第二重验证码

token有效期多久?refreshToken时间多久

  1. Access Token 有效期
    • 访问令牌(Access Token)的有效期通常设置较短,一般在15分钟到2小时之间。
    • 较短的有效期可以减少令牌被盗用的风险。
  2. Refresh Token 有效期
    • 刷新令牌(Refresh Token)的有效期通常会设置较长,通常在几天到几个月不等。
    • 较长的有效期可以减少用户频繁登录的烦恼。

例如,一个典型的设置方式如下:

  • Access Token 有效期: 1小时
  • Refresh Token 有效期: 7天

用户登录时,服务器会颁发一个 Access Token 和一个 Refresh Token。

客户端使用 Access Token 访问受保护资源,当 Access Token 过期时,客户端可以使用 Refresh Token 来申请获取新的 Access Token,无需用户重新登录。

Refresh Token 本身也会过期,届时用户需要重新登录以获取新的 Access Token 和 Refresh Token。

Refresh Token 的有效期设置较长的原因是:

  1. 避免用户频繁登录,提高用户体验。
  2. Refresh Token 本身也需要一定的有效期,以防止被盗用或滥用。

有其他的形式保持登陆态吗?不依赖后端可不可以保持登陆态

  1. Cookie 和 Session
    • 用户登录后,服务器会生成一个 Session ID 并将其存储在服务器端,同时将 Session ID 以 Cookie 的形式返回给客户端。
    • 之后客户端访问时,会携带 Cookie 中的 Session ID,服务器验证 Session ID 来确认用户身份。
  2. localStorage 和 sessionStorage
    • 用户登录后,前端可以将登录信息存储在 localStorage 或 sessionStorage 中。
    • 之后页面刷新或重新打开时,前端可以从 Web Storage 中读取登录状态,无需后端参与。
    • 这种方式适用于单页应用(SPA)等前端独立的场景。
  3. JWT (JSON Web Tokens)
    • 用户登录后,服务器颁发一个 JWT Token,包含用户信息的 payload 部分。
    • 之后客户端可以将 JWT Token 存储在 localStorage 或 Cookie 中,并在每次请求时附带 JWT Token。
    • 服务器验证 JWT Token 的签名即可确认用户身份,无需查询服务器端的会话信息。
    • 这种方式适用于前后端分离的应用,前端可以完全独立地保持登录状态。
  4. 浏览器 Credential[krɪˈdɛnʃəl] Management API
    • HTML5 提供了 Credential Management API,允许浏览器管理用户的登录凭证。
    • 用户登录后,前端可以将登录信息存储在浏览器的凭证管理系统中。
    • 之后页面刷新或重新打开时,浏览器可以自动填充登录信息,无需用户重新输入。
    • 这种方式提供了良好的用户体验,但需要浏览器支持 Credential Management API。

Session 能否不同域名

默认情况下,Session 是无法跨域的,因为浏览器会限制 cookie 的访问。可以通过设置 SameSite=None 和使用 HTTPS 来实现跨域的 Session。

  • 默认情况下:Cookie 是域绑定的,不能跨域共享。
  • 解决方案
    • 使用 单点登录(SSO):通过统一的认证中心实现跨域共享。
    • 使用 JSON Web Token(JWT):将用户信息存储在客户端,通过请求头传递。

token 一般存在哪,存在 localstorage 有什么不好

  1. 在Cookie 中,以便在后续请求中自动发送。
  2. 在 LocalStorage 中,以便在浏览器关闭后仍然保留。
  3. 可以存储在 SessionStorage 中,用于在当前会话中进行身份验证。
  4. 服务器端数据库:Token 也可以存储在服务器端的数据库中,提供更好的安全性和控制,需要额外的服务器端逻辑来处理 Token 的存储和检索。

将 Token 存储在 LocalStorage 中有一些潜在的问题:

  1. 安全性问题:LocalStorage 中的数据可以被浏览器中的其他脚本访问。
  2. 数据泄露问题:如果用户的设备被感染了恶意软件,那么恶意软件可能会读取 LocalStorage 中的数据,包括 Token。
  3. 跨域问题:LocalStorage 中的数据只能在同一来源的页面之间共享,如果页面需要与其他来源的页面进行通信,那么 Token 可能无法传递。

为了避免这些问题,可以考虑以下几点:

  1. 加密 Token:对 Token 进行加密,以确保即使数据被窃取,攻击者也无法解密和使用 Token。
  2. 设置存储期限:设置 Token 的存储期限,以便在一定时间后自动清除 Token,减少数据泄露的风险。
  3. 使用 HTTPS:确保页面使用 HTTPS 协议进行通信,以防止数据在传输过程中被窃取。
  4. 免存储敏感信息:尽量避免将敏感信息存储在 LocalStorage 中,例如用户密码等。

浏览器存储

  1. Cookie
    • 特点:
      • 可以存储少量数据(4KB左右)
      • 每次HTTP请求时会自动发送到服务器
      • 有过期时间,会随着浏览器关闭而清除
    • 应用场景:
      • 会话管理(登录状态、购物车等)
      • 个性化设置
      • 浏览器行为跟踪
  2. Web Storage
    • 分为:
      • localStorage: 永久存储,直到手动清除
      • sessionStorage: 临时存储,会话结束(浏览器关闭)后清除
    • 特点:
      • 可存储更多数据(5MB左右)
      • 仅在客户端保存,不会随请求发送到服务器
      • 提供更丰富的 API
    • 应用场景:
      • 离线应用缓存
      • 个人设置
      • 临时数据存储
  3. IndexedDB
    • 特点:
      • 可存储大量结构化数据(无限制)
      • 支持事务操作,保证数据完整性
      • 支持索引,可以高效地查询数据
    • 应用场景:
      • 离线Web应用
      • 大型数据存储
      • 复杂数据关系存储
  4. File API
    • 特点:
      • 允许JavaScript直接访问和操作本地文件
      • 可上传/下载文件
      • 可读取文件内容
    • 应用场景:
      • 文件上传/下载
      • 图片预览
      • 文件拖放

http缓存

  1. 强缓存:
    • 通过 Cache-ControlExpires 头部控制。
    • Cache-Control: max-age=3600 表示资源在 3600 秒内可以直接使用缓存。
    • Expires: Fri, 31 Dec 2024 23:59:59 GMT 表示资源在指定时间之前都可以使用缓存。
  2. 协商缓存:
    • 通过 Last-ModifiedIf-Modified-SinceETagIf-None-Match 头部实现。
    • Last-Modified 表示资源最后修改时间,If-Modified-Since 用于向服务器询问资源是否有更新。
    • ETag 表示资源的唯一标识符,If-None-Match 用于向服务器询问资源是否有变化。
  3. 浏览器缓存:
    • 浏览器会根据 Cache-Control 等头部信息自动管理缓存。
    • 用户手动清除浏览器缓存也会失效。
  4. CDN 缓存:
    • CDN 节点会缓存静态资源,减轻源站压力。
    • CDN 缓存通常优先于浏览器缓存。
  5. Service Worker 缓存:
    • Service Worker 可以完全控制资源的缓存和更新。
    • 可以离线访问页面,提升用户体验。

强缓存什么情况下会失效

强缓存可能在以下情况下失效:

  • 资源过期(如 ExpiresCache-Control 过期)。
  • 浏览器手动清除缓存。
  • 资源的 URL 发生变化。

http请求会有*个部分

  1. 请求方法:表示要对服务器执行的操作,常见的请求方法包括 GET、POST、PUT、DELETE 等。
  2. 请求头:包含了关于请求的额外信息,如客户端的类型、语言、接受的数据类型等。请求头以键值对的形式存在。
  3. 请求体:在某些请求方法中,如 POST 和 PUT,请求体可以包含要发送给服务器的数据。请求体的内容类型可以是表单数据、JSON、XML 等。

GET 请求通常不包含请求体。

cookie构成部分

  1. 名称。

  2. 值。

  3. 失效时间: expires 属性,

  4. 作⽤路径:path属性。

  5. 作⽤域:domain。

cookie和token都放在header为什么只劫持前者

  1. Cookie 的可见性:Cookie 的内容可以在浏览器的开发者工具中查看,这使得攻击者更容易获取 Cookie 的信息。
  2. Token 的设计:Token 通常是通过加密或签名等方式生成的,并且包含了一些特定的信息,如用户身份、权限等。相比之下,Cookie 的内容通常是简单的键值对,更容易被猜测或破解。

cookie和session的区别是什么

存储位置

  • Cookie 是存储在客户端浏览器中的小型文本文件。
  • Session 是存储在服务器端的会话信息。

安全性

  • Cookie 在客户端,容易被窃取或篡改。
  • Session 在服务器端,相对更加安全。

数据量

  • Cookie 的大小通常受到限制(通常不超过 4KB)。
  • Session 可以存储更多的信息,没有大小限制。

与客户端的交互方式

  • Cookie 会随每次 HTTP 请求自动发送到服务器。
  • Session 通过 Session ID 在客户端和服务器之间传递。

跨域限制

  • Cookie 受到同源策略的限制,不能跨域共享。
  • Session 可以通过 Session ID 在跨域的情况下进行共享。

cookie是怎么做到每次请求都带上的

  1. 通过 HTTP 响应头中的 Set-Cookie 指令向浏览器设置 Cookie。
  2. 将接收到的 Cookie 信息存储在本地,通常是存储在浏览器的 Cookie 数据库中。
  3. 当浏览器再次向同一个域名发起 HTTP 请求时,并将其添加到 HTTP 请求头的 Cookie 字段中。
  4. 服务器收到携带 Cookie 的 HTTP 请求后,可以解析 Cookie 信息;
  1. 隐私问题:敏感信息可能会被攻击者窃取,从而导致用户的隐私泄露。
  2. CSRF 攻击:跨站请求伪造
  3. 带宽消耗:Cookie 随请求自动携带会增加请求的大小,从而增加网络带宽的消耗。
  4. 存储限制:自动携带,并且包含大量的数据,可能会超出浏览器的存储限制,从而导致 Cookie 被丢弃或无法正确存储。
  5. 兼容性问题:不同的浏览器对 Cookie 的处理方式可能不同。

为了避免这些问题,可以采取以下措施:

  1. 加密和签名 Cookie
  2. 限制 Cookie 的范围,以减少 CSRF 攻击的风险。
  3. 设置 Cookie 的过期时间
  4. 优化 Cookie 的大小

http1.1的keep-alive

允许在单个 TCP 连接上发送多个 HTTP 请求和响应

http1.1的kepp-alive和http2.0多路复用有什么区别

  1. 连接管理

    • Keep-Alive:在 HTTP/1.1 中,Keep-Alive 是通过在请求和响应头中添加特定的字段来实现的。它允许在同一个 TCP 连接上发送多个请求和响应,避免了频繁的连接建立和关闭,从而提高了性能。
    • 多路复用:HTTP/2.0 则采用了多路复用的方式,它允许在同一个 TCP 连接上同时发送多个请求和响应,而不需要按照顺序依次发送。每个请求和响应都被分配了一个唯一的流标识符,服务器可以根据标识符来区分和处理不同的请求。
  2. 请求并发

    • Keep-Alive:虽然 Keep-Alive 可以在同一个连接上发送多个请求,但这些请求仍然是串行处理的
    • 多路复用:HTTP/2.0 的多路复用允许同时发送多个请求,并且这些请求可以在服务器端并行处理
  3. 头部压缩

    • Keep-Alive:HTTP/1.1 中没有对头部进行压缩的机制,头部信息可能会占用较多的带宽。
    • 多路复用:HTTP/2.0 引入了头部压缩机制,可以有效地减少头部信息的大小,提高传输效率。

http2与http1.1区别 了解http3

HTTP/2 和 HTTP/1.1 之间有以下主要区别:

  1. 传输协议:
    • 1、纯文本 2、使用二进制。
  2. 多路复用:
    • 1、一个 TCP 连接只能处理一个请求。 2、支持多路复用,一个 TCP 连接上并行处理多个请求。
  3. 头部压缩:
    • 1、中不回对头部压缩。2 HPACK 算法对头部进行压缩。

HTTP/3 是基于 QUIC 协议的新一代 HTTP 协议。它相比 HTTP/2 有以下主要改进:

  1. 传输协议:
    • 2、 TCP 作为传输层协议,存在一些局限性。3、基于 UDP的QUIC 协议。
  2. 连接建立:
    • 2、TCP 的三次握手。 3、基于 QUIC 快速建立连接。
  3. 流量控制:
    • 2、依赖于 TCP 流量控制。3、QUIC 实现了更灵活的流量控制。
  4. 安全性:
    • 2 依赖于 TLS 提供安全性。3 直接集成到 QUIC 中。

https为什么安全,它是对称加密还是非对称加密

  1. 使用会话密钥进行通信,即使密钥被破解,也只影响当前会话,不会影响其他会话。
  2. SSL/TLS 协议对内容进行加密,使用数字证书来验证。
  3. 可以检测数据在传输过程中是否被篡改。

握手阶段,通过非对称加密交换对称密钥,数据传输阶段,使用对称密钥进行加密和解密

HTTP 状态码

  • 100-199 (信息性状态码):
    • 100 Continue:客户端应继续发送请求。
    • 101 Switching Protocols:服务器根据客户端的请求切换协议。
  • 200-299 (成功状态码):
    • 200 OK:请求成功。
    • 201 Created:请求成功并创建了新的资源。
    • 204 No Content:请求成功,但响应不包含任何实体内容。
  • 300-399 (重定向状态码):
    • 301 Moved Permanently:请求的资源已永久移动到新位置。
    • 302 Found:请求的资源临时性地移动到新位置。 包含一个 Location 字段,
    • 304 Not Modified:客户端的缓存资源未发生变化。
  • 400-499 (客户端错误状态码):
    • 400 Bad Request:服务器无法理解请求的语法。
    • 401 Unauthorized:请求需要用户身份验证。
    • 403 Forbidden:服务器拒绝执行该请求。
    • 404 Not Found:服务器找不到请求的资源。
  • 500-599 (服务器错误状态码):
    • 500 Internal Server Error:服务器内部错误。
    • 501 Not Implemented:服务器不支持该请求的功能。
    • 503 Service Unavailable:服务器暂时无法处理请求。

资源返回304的含义、缓存有几种、

客户端发送的请求资源在服务端没有发生变化

作用:

  • 减少不必要数据传输,提高网页加载速度

  • 资源没有发生变化时,使用缓存副本,不需要重新下载

  • 浏览器缓存

  • 代理服务器缓存

  • CDN 缓存

  • 服务器端缓存

http和https区别

  1. 安全性:
    • HTTP: 数据传输是明文的,容易遭受中间人攻击,数据在传输过程中可能被窃取或篡改。
    • HTTPS: 数据传输是经过加密的,使用 SSL/TLS 协议对数据进行加密和认证,能够有效防止中间人攻击,提高了数据传输的安全性。
  2. 端口:
    • HTTP: 80 。
    • HTTPS: 443 。
  3. 证书:
    • HTTP: 不需要证书。
    • HTTPS: 由 CA(Certificate Authority)数字证书来验证服务器的身份。
  4. 性能:
    • HTTP: 无需加密和解密,性能比 HTTPS 更好。
  5. 应用场景:
    • HTTP: 非敏感数据的传输,如静态网页、图片等。
    • HTTPS: 需要保护隐私数据的场景,如电子商务、在线支付、登录验证等

什么事同源策略?服务端请求服务端会产生跨域嘛

浏览器安全机制。它规定,浏览器只允许当前页面访问来自同一个源的资源,这里的"源"指的是协议、域名和端口号

目的:为了防止跨站脚本(XSS)攻击和其他类型的跨域攻击

浏览器有同源策略,但是为何 CDN 请求资源的时候不会有跨域限制?

  • 原因
    • CDN 资源通常通过 <script><link><img> 等标签加载,这些标签不受同源策略限制。
    • 如果通过 fetchXMLHttpRequest 请求 CDN 资源,则需要 CDN 服务器配置 CORS 头部。

如何解决浏览器跨域问题?

  1. CORS (Cross-Origin Resource Sharing): 这是一种基于 HTTP 头的机制,它允许服务器指定哪些源站有权限访问哪些资源。

    • Access-Control-Allow-Origin: 指定允许跨域的源,可以是具体域名或 * 表示任意源。
    • Access-Control-Allow-Methods: 允许 GET、POST 和 PUT 方法的跨域请求
    • Access-Control-Allow-Headers: 指定允许的请求头。// 允许 Content-Type、Authorization 和 X-Requested-With 请求头
  2. JSONP (JSON with Padding):

    1. 创建<script> 标签,并设置 src 属性为后端url。
    2. Url后添加 callback 参数,指定了一个回调函数 handleResponse
    3. 创建 <script>触发浏览器发起跨域请求
    4. handleResponse 函数会接收到服务器返回的数据,并在控制台打印出来。
  3. Nginx 反向代理: 在 Nginx 上设置反向代理,将跨域的请求转发到目标服务器。

    # Nginx 配置文件
    events {
    worker_connections 1024;
    }

    http {
    server {
    listen 80;
    server_name example.com;

    location / {
    proxy_pass http://backend_servers;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
    }

    upstream backend_servers {
    server 192.168.1.100:8080;
    server 192.168.1.101:8080;
    }
    }
  4. postMessage(): 这是 HTML5 提供的一种跨文档消息传递机制,可用于窗口间的跨域通信。

    使用场景 postMessage() 主要应用于以下场景:

    1. 跨域通信: 当页面需要与来自不同域的 iframe、弹出窗口或其他标签页进行数据交换时,可以使用 postMessage() 来实现。
    2. 消息传递: 不同窗口或标签页之间可以使用 postMessage() 传递消息,而不需要直接访问对方的 DOM。
    3. 安全通信: 与 window.open() 打开的窗口通信时,可以使用 postMessage() 来保证通信的安全性。
  5. WebSocket: WebSocket 是一种双向通信协议,可以实现真正意义上的跨域通信。

    特点

    1. 现双方随时发送和接收数据,无需等待对方响应。
    2. 连接一旦建立,会一直保持打开状态,直到主动关闭。
    3. 无需像 HTTP 那样频繁地发起新的 TCP 连接,因此能够减少延迟。
    4. 文本数据还支持传输二进制数据。

    应用场景 实时聊天 实时游戏 实时数据推送 协作编辑 物联网

  6. webpack使用webpack-dev-server可以使用proxy

  7. node里面使用express和http-proxy-middleware使用,app.use('./',proxy())

csrf 和 xss

XSS:插⼊恶意 Script 代码。

防范措施:1、 Content-Security-Policy: default-src 'self';2.对输出的数据进⾏HTML编码

CSRF:攻击者借助受害者的 Cookie 骗取服务器的信任

JSONP 的返回值是什么格式,CORS 前后端怎么设置

//jsonp是一个JavaScript函数调用
<script>
function handleResponse(data) {
console.log(data);
}
</script>
<script src="https://example.com/data?callback=handleResponse"></script>


//CORS
fetch: made:cors
express: use(cors())

简述 CSRF、XSS、SQL 注入 和 DDoS 攻击的区别

CSRF、XSS、SQL注入和DDoS是四种常见的网络攻击方式,它们各自有不同的攻击手段和目的。下面简要介绍它们的区别:

CSRF(跨站请求伪造)

CSRF(Cross-Site Request Forgery)攻击是一种利用用户身份进行未授权操作的攻击方式。攻击者通过诱导用户访问一个恶意网站或点击恶意链接,利用用户在该网站上的会话(如Cookie)向目标网站发送请求,执行一些未授权的操作,如修改个人信息、转账等。

防御措施

  • 使用验证码。
  • 检查HTTP请求的来源(Referer)。
  • 使用CSRF令牌(Token)。

XSS(跨站脚本攻击)

XSS(Cross-Site Scripting)攻击是通过在网页中注入恶意脚本代码,当其他用户浏览该网页时,恶意脚本会在用户的浏览器中执行,从而盗取用户信息、篡改网页内容等。

防御措施

  • 对用户输入进行严格的过滤和转义。
  • 使用内容安全策略(CSP)限制脚本的执行。

SQL注入

SQL注入攻击是通过在Web表单输入或URL查询字符串中插入恶意SQL代码,当这些输入被服务器端的数据库查询处理时,攻击者可以执行任意SQL命令,从而获取数据库中的敏感信息、修改数据等。

防御措施

  • 使用参数化查询或预编译语句。
  • 对用户输入进行严格的验证和清理。
  • 使用数据库权限最小化原则。

DDoS(分布式拒绝服务攻击)

DDoS(Distributed Denial of Service)攻击是一种通过大量请求来使目标服务器或网络资源不可用的攻击方式。攻击者通常控制多个被感染的计算机(僵尸网络),同时向目标发送大量请求,导致正常用户无法访问服务。

防御措施

  • 使用DDoS防护服务。
  • 限制单个IP的连接数和请求频率。
  • 增加服务器的带宽和处理能力。

总结来说,CSRF利用用户身份进行未授权操作,XSS利用用户浏览器执行恶意脚本,SQL注入通过注入恶意SQL代码来攻击数据库,而DDoS通过大量请求使服务不可用。每种攻击都有其特定的防御策略,重要的是在开发和部署应用时,要采取适当的安全措施来防范这些攻击。

  • 禁止客户端脚本的访问权限,服务器端仍然可以读取和修改。
  • 能防止跨站请求攻击

HTTPS 哪些有薄弱的地方容易被攻击?

证书问题: 如果攻击者能够获取到一个有效的证书颁发机构(CA)的私钥,可以伪造任何网站的SSL证书。

协议漏洞

Heartbleed漏洞:Heartbleed是一个影响广泛使用的OpenSSL库的严重漏洞,攻击者可以利用它来窃取服务器内存中的敏感信息

用户行为:如果用户被诱导信任一个伪造的证书,他们可能会在不知情的情况下进行不安全的通信。

中间人攻击(MITM)

中间人攻击(Man-in-the-Middle Attack)是指攻击者在通信双方之间插入自己,窃取或篡改数据。防御措施包括使用 HTTPS、证书校验等

  • 公共Wi-Fi攻击
  • DNS欺骗:通过DNS欺骗,攻击者可以将用户重定向到一个恶意网站,

为了提高HTTPS的安全性,建议采取以下措施:

  • 定期更新和维护服务器软件,确保没有已知的安全漏洞。
  • 使用强加密算法和安全的协议版本,如TLS 1.2或TLS 1.3。
  • 确保服务器的SSL证书是有效的,并且由可信的CA签发。
  • 使用HSTS(HTTP Strict Transport Security)来强制浏览器只通过HTTPS访问网站。

HTTP 简单请求和复杂请求

简单请求(Simple Request)

  1. 请求方法为GET、HEAD或POST。
  2. 如果请求方法为POST,Content-Type头部必须是以下之一:
    • application/x-www-form-urlencoded
    • multipart/form-data
    • text/plain
  3. 请求中不包含自定义头部(除了Accept、Accept-Language、Content-Language和Content-Type)。

对浏览器会直接发送请求到服务器,不会触发预检请求。服务器响应后,浏览器会根据响应头来决定是否允许跨域请求。

复杂请求(Complex Request)

使用PUT或DELETE方法的请求、使用自定义头部的请求、使用非标准Content-Type的POST请求等。

浏览器会先发送一个预检请求(OPTIONS方法)到服务器,以询问服务器是否允许该跨域请求

预检请求会包含一个Access-Control-Request-Method头部,表明实际的请求方法,

以及一个Access-Control-Request-Headers头部,列出实际请求中包含的自定义头部。

服务器需要响应预检请求,

通过Access-Control-Allow-Methods头部来指定允许的请求方法,

通过Access-Control-Allow-Headers头部来指定允许的自定义头部。如果服务器允许跨域请求,

还需要在响应头中包含Access-Control-Allow-Origin头部,其值为允许跨域请求的源(Origin)。

关于JWT的问题:

◦ JWT是由什么组成的? **Header(头部) **Payload(负载)(关于实体和其他数据的声明) Signature(签名)

◦ JWT解决了什么问题? 允许服务器在不保存任何会话数据的情况下验证用户身份

◦ JWT相对以前的session+cookie模式有什么优点?

  1. 无状态:JWT 不需要服务器保存任何会话数据
  2. 可扩展性:可以轻松地在多个服务器之间共享
  3. 易于使用: 在客户端(如浏览器)和服务器之间轻松地通过 HTTP 头部传输。

TCP/ip5层模型,并且解释每层的作用

应用层用户与网络交互的接口如网页浏览、文件传输、电子邮件、域名解析 、数据格式化、数据加密、数据压缩等。

传输层负责端到端的数据传输服务。它确保数据包按顺序、无差错地传输,并提供流量控制和拥塞控制。传输层有两个主要协议: TCP,UDP

网络层负责将数据包从源主机传输到目标主机

数据链路层负责在相邻网络节点之间传输数据。它处理物理地址(如MAC地址)

物理层负责在物理介质上(如双绞线、光纤、无线信号等)传输原始比特流。

TCP 队首阻塞

TCP 队首阻塞是指在网络中,前面的包丢失会导致后面的包无法被处理,造成延迟。TCP 需要等待丢失的包被重传和确认后,才能继续处理后续包。

.keep-alive页面不想要这个缓存怎么办?

Keep-Alive是一种机制,它允许客户端和服务器之间保持一个持久的连接,而不是在每次请求后关闭连接

七层网络模型是 OSI 模型

  1. 物理层
  2. 数据链路层
  3. 网络层
  4. 传输层
  5. 会话层
  6. 表示层
  7. 应用层

对于经常变化的资源,通常会设置较短的缓存时间或使用no-cache来确保用户总是获取最新的内容