网络相关

_yile
65 阅读6分钟

1、从输入url到页面加载完整的过程

image.png

2、浏览器缓存机制/HTTP缓存机制/强缓存和协商缓存

  • 浏览器缓存是对之前请求过的资源进行缓存从而达到请求优化。
  • header响应头里面包含了控制缓存的字段
  • 缓存分为强缓存和协商缓存，再次请求资源时会先判断是否命中强缓存
  • 判断expires或者cache-control，判断资源是否过期（同时存在则优先cache-control）
  • 没有过期则从缓存中读取数据，先内存再硬盘
  • 过期则发送请求到服务器判断是否命中协商缓存
  • 协商缓存判断etag与if-none-match或者last-modified与if-modified-since（同时存在优先etag）
  • 协商缓存生效则返回304，从缓存中读取；不生效则返回200和请求结果

TCP三次握手和四次挥手

截屏2022-12-07 15.19.07.png

  • 三次：确保双方都有接受和发送的能力（通信的能力）
  • 四次：确保数据都传输完成

HTTP与HTTPS区别

  • 安全性：http是明文传输，https使用SSL/TSL进行了加密相对更安全（付费）
  • 端口：连接方式和端口不一样，http是80，https是443
  • 性能：https由于加密和多次连接，性能不如http
  • SEO：https更有利于seo
  • 用户信任：https浏览器显示安全锁图标，增强用户信任度

websocket特点

  • 持双向通信，实时性更强
  • 可以发送文本，也可以发送二进制数据
  • 建立在TCP协议之上，服务端的实现比较容易
  • 数据格式比较轻量，性能开销小，通信高效
  • 没有同源限制，客户端可以与任意服务器通信
  • 协议标识符是ws（如果加密，则为wss），服务器网址就是 URL
  • 与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。

get、post区别，put是什么

  • get
    • 用于获取资源
    • 参数在url中
    • 重复请求会返回相同的数据，对服务器资源没有影响，可以被浏览器缓存
    • 数据暴露在url中。安全性相对较低
  • post
    • 用于保存或更新资源
    • 参数在body中
    • 重复请求可能会产生副作用（数据被重复创建或修改），例如提交表单，不会被浏览器缓存
    • 安全性相较于get高
  • put
    • 用于更新或创造资源
    • 参数在body中
    • 重复请求会被覆盖，不会被浏览器缓存
    • 安全性相较于get高

cookie、session、token

  • cookie通过set-cookie设置存储在客户端下次请求会自动带上，有跨域限制
  • session存储在服务端，与cookie信息一一对应
  • token存储在本地，自定义传递，无跨域限制

localStorage、sessionStorage、Cookie

  • localStorage：持久存储、同源不同窗口都可以共享、关闭浏览器数据消失、通过js访问、大小限制为5mb
  • sessionStorage：临时存储、同源同一窗口使用，关闭窗口数据消失、通过js访问、大小限制为5mb
  • Cookie：临时存储(设置过期时间)+持久存储、同一域名下都可以访问、通过http请求访问、大小限制为4kb

HTTP常见状态码

状态码第一位数字决定了不同的响应状态，有如下：

  • 1表示消息
  • 2表示成功
  • 3表示重定向
  • 4表示请求错误
  • 5表示服务器错误
400 Bad Request    - 参数传递错误、请求语法错误等
401 Unauthorized   - 身份验证失败或会话过期
403 Forbidden      - 服务器理解请求，但拒绝执行（权限问题）
404 Not Found      - 请求地址不存在或资源不存在
405 Method Not Allowed - 请求方法不被允许（方法使用错误）
408 Request Timeout - 请求超时

跨域

协议、域名、端口不一致则会产生跨域

跨域解决方案：

  • JSONP

    link、img、script、iframe不会产生跨域问题

    方法：在客户端定义全局onSuccess函数，通过script发送请求，服务端返回一串字符串，在客户端当作一段js执行，调用onSuccess函数

    缺点：

    • 只能发送get请求；
    • 被注入恶意代码容易出现安全问题；
    • 不好调试,在调用失败的时候不会返回任何状态码

  • CORS

    cors允许浏览器向跨域服务器发送XMLHttpRequest请求，需要客户端和服务端同时支持 遇到复杂请求是会进行预检查，发生options请求，是浏览器自行发起的不会影响实际功能

    CORS跨域问题的解决方法

    3.1 设置CORS响应头

  • Access-Control-Allow-Origin：指定允许访问该资源的源。可以设置为具体域名（如http://example.com），也可以设置为*表示允许任何源。
  • Access-Control-Allow-Methods：指定允许哪些HTTP方法（如GET、POST、PUT等）进行跨域请求。
  • Access-Control-Allow-Headers：指定允许哪些HTTP头部字段在跨域请求中使用。
  • Access-Control-Allow-Credentials：如果设置为true，则允许跨域请求携带认证信息（如cookies）。但此时Access-Control-Allow-Origin不能设置为*，必须指定具体的域名。

3.2 使用预检请求（Preflight Request）

  • 对于某些复杂的跨域请求（如PUT、DELETE或使用非简单头部的POST请求），浏览器会先发送一个OPTIONS方法的预检请求，以检查服务器是否允许该跨域请求。
  • 预检请求会包含Access-Control-Request-Method和Access-Control-Request-Headers等字段，用于告知服务器实际请求将使用的方法和头部。
  • 服务器在接收到预检请求后，需要检查请求头中的字段，并决定是否允许该跨域请求。如果允许，则需要在响应头中设置相应的CORS字段。

3.3 后端配置CORS

  • 在后端代码中，可以通过设置HTTP响应头来启用CORS。具体实现方式取决于后端使用的编程语言和框架。
  • 例如，在Java Spring框架中，可以使用@CrossOrigin注解来指定允许跨域请求的源、方法和头部。

3.4 使用代理服务器（如Nginx）

  • 在某些情况下，使用代理服务器（如Nginx）也可以解决跨域问题。通过配置代理服务器，可以将前端请求转发到后端服务器，并在转发过程中修改请求和响应的头部信息，以实现跨域请求。
avatar
文章
阅读
粉丝