前端 - HTTP 相关知识

已于 2023-12-20 18:23:25 修改
阅读量922 收藏 23
点赞数 17
文章标签： 前端 http 网络协议
于 2023-12-19 14:48:05 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/sinat_39145919/article/details/135082433
版权

涉及面试题

  1. http 常见状态码有哪些？
  2. http 常见的 Header 有哪些？
  3. 什么是Restful API？
  4. 描述一下 http 的缓存机制（重要）。

http 状态码

状态码分类

1xx - 服务器收到请求
2xx - 请求成功，如 200
3xx - 重定向，如 302
4xx - 客户端错误，如 404
5xx - 服务端错误，如 500

常见状态码

200 - 成功
301 - 永久重定向（配合 location，浏览器自动处理）
302 - 临时重定向（配合 location，浏览器自动处理）
304 - 资源未被修改
404 - 资源未找到
403 - 没有权限
500 - 服务器错误
504 - 网关超时

关于协议和规范

就是一个约定，要求大家都跟着执行，不要违法规范，例如 IE 浏览器。

http methods

传统的 methods

  1. get 获取服务器的数据
  2. post 向服务器提交数据

简单的网页功能，就这两个操作。

现在的 methods

  1. get 获取数据
  2. post 新建数据
  3. patch / put 更新数据
  4. delete 删除数据

Restful API

一种新的 API 设计方法（早已推广使用）。

  1. 传统 API 设计：把每个 url 当作一个功能。
  2. Restful API 设计：把每个 url 当作一个唯一的资源。

如何设计成一个资源？

  1. 尽量不用 url 参数。
  2. 用 method 表示操作类型。
不使用 url 参数
  1. 传统API设计：/api/list?pageIndex=2
  2. Restful API设计：/api/list/2
用 method 表示操作类型

  1. 传统 API 设计：
    post 请求： /api/create-blog
    post 请求： /api/update-blog?id=100
    get 请求： /api/get-blog?id=100

  2. Restful API 设计：
    post 请求： /api/blog
    patch 请求： /api/blog/100
    get 请求： /api/blog/100

http headers

常见的 Request Headers

  1. Accept - 浏览器可接收的数据格式
  2. Accept-Encoding - 浏览器可接收的压缩算法，如 gzip
  3. Accept-Languange - 浏览器可接收的语言，如 zh-CH
  4. Connection: keep-alive - 一次TCP连接重复使用
  5. cookie
  6. Host
  7. User-Agent - 简称UA，浏览器信息
  8. Content-type - 发送数据的格式，如application/json

常见的 Response Headers

  1. Content-type - 返回数据的格式，如application/json
  2. Content-length - 返回数据的大小，多少字节
  3. Content-Encoding - 返回数据的压缩算法，如gzip
  4. Set-Cookie

自定义 headers

// 网址：axios-js.com/docs/#Request-Config
headers: {'X-Requested-With': 'XMLHttpRequest'},

缓存相关的 headers

  1. Cache-Control、 Expires
  2. Last-Modified 、 If-Modified-Since
  3. Etag 、If-None-Match

http 缓存

关于缓存

什么是缓存？

可以把一些没有必要重新获取的资源缓存起来。

为什么需要缓存？

为了让页面加载更快一些。

哪些资源可以被缓存？

静态资源（js、css、img）。

强制缓存

浏览器初次请求，服务器如果觉得这个资源可以被缓存，服务器会返回资源和Cache-Control。

Cache-Control

是加在 Response Headers 中的，控制强制缓存的逻辑。
例如 Cache-control: max-age=31536000 // 单位是秒。
再次请求，只要判断 Cache-control 的时间，没有过期，则去查找本地缓存，返回资源；缓存失效，重新请求服务器，再返回新的资源和新的 Cache-control。

Cache-Control 的值

  1. max-age - 最大过期时间；
  2. no-cache - 不使用强制缓存，但是服务端有什么缓存操作并不影响；
  3. no-store - 不使用强制缓存，且不使用服务端的缓存；
  4. private - 只能允许最终用户作为缓存，比如手机、电脑、浏览器；
  5. public - 允许中间的一些路由/代理作为缓存。

关于 Expires

Expires: Wed, 22 Oct 2010 08:41:00 GMT
// Expires 是 HTTP/1 的产物，表示资源会在 ed, 22 Oct 2010 08:41:00 GMT 后过期，需要再次请求。并且 Expires 受限于本地时间，如果修改了本地时间，可能会造成缓存失效。
  1. 同在 Response Headers 中
  2. 同为控制缓存过期
  3. 已被 Cache-Control 代替

协商缓存（对比缓存）

服务端缓存策略

服务端来判断一个资源是不是可以用缓存的内容。
告诉客户端这份资源有没有变化，是否可以直接用上次请求的资源。

协商缓存

  1. 服务端判断客户端资源，是否和服务端资源一样；
  2. 一致则返回 304，否则返回 200 和最新的资源。

协商缓存的过程

  1. 浏览器初次请求，服务器返回资源和资源标识；
  2. 浏览器再次请求，携带上资源标识；
  3. 服务端返回 304；或者返回新的资源和新的资源标识。
资源标识

在 Response Headers 中，有两种：

  1. Last-Modified - 资源的最后修改时间
  2. Etag - 资源的唯一标识（一个字符串，类似人类的指纹）
Last-Modified（资源最后修改的时间）
  1. 浏览器初次请求，服务端返回资源和 Last-Modified，浏览器会缓存起来；
  2. 浏览器再次请求，Request Headers 带着 If-Modified-Since（值就是上次服务器返回的Last-Modified）；
  3. 服务端比较资源最后的修改时间。一致则服务端返回304；不一致则返回新的资源和新的Last-Modified。
Etag (服务器根据文件内容计算出的唯一标识，不能重复)

如果资源没改过，计算出来的 Etag 会和上次一样。

  1. 浏览器初次请求，服务器返回资源和 Etag，浏览器缓存资源和 Etag；
  2. 浏览器再次请求，Request Headers 带着 If-None-Match（值就是上次服务器返回的Etag）；
  3. 服务端比较 Etag是否一致。一致则服务端返回 304；不一致则返回新的资源和新的 Etag。
Last-Modifed 和 Etag 共存
  1. 会优先使用 Etag；
  2. Last-Modified 只能精确到秒级；
  3. 如果资源被重复生成，而内容不变，则 Etag 更精确。

浏览器三种刷新操作

正常操作

  1. 地址栏输入url；
  2. 跳转链接；
  3. 前进后退等。

手动刷新

  1. 按F5；
  2. 点击刷新按钮；
  3. 右击菜单刷新。

强制刷新

按ctrl+F5。

不同刷新操作，不同的缓存策略

  1. 正常操作：强制缓存有效，协商缓存有效；
  2. 手动刷新：强制缓存失效，协商缓存有效；
  3. 强制刷新：强制缓存失效，协商缓存失效。

浏览器缓存总结

在这里插入图片描述

http 版本

http 0.9

  1. 方法：get、head。

http 1.0

  1. 方法：
    get：向服务器请求数据；参数携带在url中；请求文件。
    head：向服务器请求数据；参数携带在url中，只返回header信息。
    post：向服务器提交数据；参数在请求体中。
  2. 一个 request 对应一个 response
  3. 每次发送请求都要进行 tcp 连接，响应后关闭连接

http 1.1

  1. 方法：get、post、put / patch（更新数据）、delete（删除数据）。
  2. 可以通过 content: keep-alive 进行长连接
  3. 一次 tcp 连接可以进行多个 request 请求
  4. 一个 request 依旧对应一个 response
  5. 响应有顺序
  6. 文本格式解析

http 2.0

  1. 二进制格式解析
  2. 多路复用：多个 request 请求，可以混在一起，response 响应不需要顺序，根据 id 找到对应的请求

http 对比 https

https

  1. SSL / TLS 加密传输
  • 对称加密（用同一个key加密解密）；
  • 非对称加密（用一个key加密，用另一个key解密）。
  1. 默认端口 443
  2. 需要证书
https 加密传输过程

在这里插入图片描述

http

  1. 明文传输
  2. 默认端口 80
  3. 不需要证书

tcp

tcp vs udp

tcp

TCP 会严格控制传输的正确性，一旦有某一个数据对端没有收到，就会停止下来直到对端收到这个数据。这种问题在网络条件不错的情况下可能并不会发生什么事情，但是在网络情况差的时候就会变成画面卡住，然后再继续播放下一帧的情况。

特点：

  1. 面向连接
  2. 传输安全可靠
  3. 字节传输
  4. 一对一
  5. 一旦有某一个数据对端没有收到，就会停止下来直到对端收到这个数据
upd

在这里插入图片描述
头部一共 8 个字节：

  1. 16位的源端口、16位的目的端口
  2. 整个数据报文的长度
  3. 整个数据报文的检验和（IPv4 可选 字段），该字段用于发现头部信息和数据中的错误

特点：

  1. 无连接
  2. 尽最大努力交付，可能会丢失
  3. 报文传输
  4. 高效
  5. 支持一对一、一对多、多对多、多对一的方式

tcp 报文格式

固定部分
  1. 20 字节
  2. 与连接相关的标识有：
  • seq序号：是本报文段所发送数据部分第一个字节的序列号。
    TCP 连接字节流中每一个字节都会有一个编号，而本字段的值指的是本报文段所发送数据部分第一个字节的序号。Sequence number，这个序号保证了 TCP 传输的报文都是有序的，对端可以通过序号顺序的拼接报文。
  • ack 确认号：表示期望收到的下一个报文段数据部分的第一个字节的编号。
    表示期望收到的下一个报文段数据部分的第一个字节的编号，编号为 ack-1 及以前的字节已经收到 Acknowledgement Number，这个序号表示数据接收端期望接收的下一个字节的编号 是多少，同时也表示上一个序号的数据已经收到。
  • SYN：当本字段为 1 时，表示这是一个连接请求或者连接接受报文。
    SYN=1：当SYN=1，ACK=0时，表示当前报文段是一个连接请求报文；当SYN=1，ACK=1时，表示当前报文段是一个同意建立连接的应答报文。
  • ACK：仅当本字段为 1 时，确认号才有效。
  • FIN：用来释放一个连接，为 1 时代表要求释放连接。
    当本字段为 1 时，表示此报文段的发送端数据已发送完毕，要求释放运输连接。
  1. 其他标识：
  • URG
    URG=1：该字段为一表示本数据报的数据部分包含紧急信息，是一个高优先级数据
    报文，此时紧急指针有效。紧急数据一定位于当前数据包数据部分的最前面，紧急
    指针标明了紧急数据的尾部 。
  • PSH
    PSH=1：该字段为一表示接收端应该立即将数据 push 给应用层，而不是等到缓冲
    区满后再提交。
  • RST
    RST=1：该字段为一表示当前 TCP 连接出现严重问题，可能需要重新建立 TCP 连
    接，也可以用于拒绝非法的报文段和拒绝连接请求。
选项部分
  1. 长度可变
  2. 如果不是 4 字节的倍数，会进行填充

三次握手

在这里插入图片描述

  1. 连接建立阶段：
  • 第一次握手：
    客户端的应用进程主动打开，并向服务端发出请求报文段。其首部中：SYN=1,seq=x。
  • 第二次握手：
    服务器应用进程被动打开。若同意客户端的请求，则发回确认报文，其首部中：SYN=1,ACK=1,ack=x+1,seq=y。
  • 第三次握手：
    客户端收到确认报文之后，通知上层应用进程连接已建立，并向服务器发出确认报文，其首部：ACK=1,ack=y+1。
  1. 当服务器收到客户端的确认报文之后，也通知其上层应用进程连接已建立。
    在这个过程中，通信双方的状态如下图，其中:
  • CLOSED：关闭状态、
  • LISTEN：收听状态、
  • SYN-SENT：同步已发送、
  • SYN-RCVD：同步收到、
  • ESTAB-LISHED：连接已建立

总结：

  1. 第一次握手：客服端发送 SYN=1, seq=x
  2. 第二次握手：服务端返回 SYN=1, ACK=1, seq=y, ack=x+1
  3. 第三次握手：客户端返回 ACK=1, seq=x+1, ack=y+1

四次挥手

在这里插入图片描述

  1. 连接释放阶段：
  • 第一次挥手：
    数据传输结束以后，客户端的应用进程发出连接释放报文段，并停止发送数据，其首部：FIN=1,seq=u。
  • 第二次挥手：
    服务器端收到连接释放报文段之后，发出确认报文，其首部：ack=u+1,seq=v。此时本次连接就进入了半关闭状态，客户端不再向服务器发送数据。而服务器端仍会继续发送。
  • 第三次挥手：
    若服务器已经没有要向客户端发送的数据，其应用进程就通知服务器释放TCP连接。这个阶段服务器所发出的最后一个报文的首部应为：FIN=1,ACK=1,seq=w,ack=u+1。
  • 第四次挥手：
    客户端收到连接释放报文段之后，必须发出确认：ACK=1,seq=u+1,ack=w+1。 再经过2MSL(最长报文端寿命)后，本次TCP连接真正结束，通信双方完成了他们的告别。
  1. 在这个过程中，通信双方的状态如下图，其中：
  • ESTAB-LISHED：连接建立状态；
  • FIN-WAIT-1：终止等待1状态；
  • FIN-WAIT-2：终止等待2状态；
  • CLOSE-WAIT：关闭等待状态；
  • LAST-ACK：最后确认状态；
  • TIME-WAIT：时间等待状态；
  • CLOSED：关闭状态。

总结：

  1. 第一次挥手：客户端发送 FIN=1, seq=m
  2. 第二次挥手：服务端返回 ACK=2, seq=n, ack=m+1
  3. 第三次挥手：服务端发送 FIN=1. ACK=1, seq=w, ack=m+1
  4. 第四次挥手：客户端发送 ACK=1, seq=m+1, ack=w+1

RTT

表示发送端发送数据到接收对端数据所需的往返事件。

出处：https://coding.imooc.com/lesson/400.html

丶清风不问烟雨
关注
  • 17
    点赞
  • 踩
  • 23
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值