大家好，今天来为大家解答HEADER CACHE-CONTROL【header cache-control】这个问题的一些问题点，包括也一样很多人还不知道，因此呢，今天就来为大家分析分析，现在让我们一起来看看吧！如果解决了您的问题，还望您关注下本站哦，谢谢~
于是我找到了一个很棒的开源的流程图软件——draw.io，它同样也提供了在线的地址——drawio在线地址
但她用了一会之后，感觉这个在线地址也不是那么的方便易用，提出了下面的问题：
- 这个在线地址部署在国外，平时使用会受网络影响
- 本身不提供文件存储的功能，它对接了多种存储介质，比如你可以下载到本地、或者托管到一些云盘或者 GitHub ，虽然说配置起来不是很麻烦，但也并不是开箱即用
- 本身不提供文件管理功能，它可以导入一个个文件，感觉就像是一个编辑器而已，并没有把我创建的、编辑的流程图统一管理起来，没有类似文件/文件夹列表的功能
所以，基于上面的种种问题，我就想着基于 drawio 魔改一个的绘图软件，并且自己后端实现存储，这样就可以让这个东西免费无限制且易用。
其实说是魔改，我们改的东西不多，主要是改变存储、读取的方式，以及有一些功能不需要的可以做一些删减，最后就是自己做一个平台把文件与流程图串起来。
这是项目的体验地址，欢迎大家体验：体验地址
首先先把 drawio 的代码拉下来，拉下来之后只需要关注 src/main/webapp 这个目录，所有的前端代码都在里面。
入口是 src/main/webapp/index.html 这个文件，我使用了 express 起了一个服务，一来是充当静态资源服务器，二来是充当开发环境的代理，规避接口调用时的跨域问题。
新建一个 server.js 文件，填入如下内容
然后运行一下这个 node 脚本，启动服务。
启动服务之后，这里有两点需要注意的地方：
- 如果你的服务器动在 3000 端口，那么你需要访问 http://localhost:3000/?dev=1
- 修改 src/main/webapp/index.html 的如下代码，不然静态资源的加载会有问题
随意修改一些东西，然后打开上述的链接，如果看到修改生效，那么就证明我们的开发环境启动成功了
大概看了一下 drawio 的代码，发现流程图的内容是 xml 格式的。对于文件的初始化流程，可以大概找到 App.js 的如下代码，绿色代码是我新加的。
mock 一下数据，把文件的标题与内容通过实例化一个 LocalFile ，并调用 loadFile 加载到画布上
然后我们就可以得到一幅流程图如下图所示
这里真正实现的时候，是根据 id 调用后端接口，去拿标题和内容，然后加载到编辑器中，到这一步，读取数据已经完成。
由于我们上面选择的存储介质是 LocalFile ，所以保存内容的逻辑在 LocalFile 这个类中，具体在下面打印的位置
在这个位置，我们可以把数据同步给后端进行更新。
除了内容之外，标题的更新我们也需要考虑。
标题更新的时候会走到下面这个方法，我们可以在这个方法中来发送接口给后端更新文档的标题
至此，基本的数据流向问题已经解决，在流程图层面，我们已经解决了读取数据及更新数据的问题，解决了这两个问题之后，我们就可以把流程图内容信息存在我们自己的服务器中。
还有一些其他配置项的修改，这个就根据我们自身的情况来，看看哪些东西是我们不想要的，哪些东西是要改的。
这里就得耐心去读一下它的源码了，没什么技巧，找到你自己想要改的地方，改它。这里我举两个例子。
第一个，图标的修改
上面框出来的图标，在下面的文件中，修改成你想要的图标就行。
第二个，菜单的修改，我这里对【文件】这个菜单删了很多，只保留了我觉得必要的东西
菜单在下面这个文件中，基本上就是找到你不想要的东西把它注释掉或者删掉。
这个项目打包的工具用的 ant ，它是一个基于 java 的打包工具。所以要打包我们先要装好 java 的 jdk 以及 ant 。
安装好后进入到 /etc/build 这个目录下，执行 ant 命令，就可以发现打包成功了。
部署的时候使用 nginx 开了一个目录，然后我比较偷懒。我把整个 webapp 目录都丢了上去，但是呢 webapp 目录又很大，我也不想每次通过 ftp 工具去传。
于是我就建了一个 git 仓库，把在我本地的 webapp 目录推了上去，然后在服务器拉取这个仓库。这样做了以后，我每次通过 ant 打包完之后推送代码，然后在服务器 pull 一下，代码就更新了。
还有一点要注意的是，这个项目的前端并没有使用一些现代化的打包工具，打包出来的文件名不会有 hash 。
为了避免缓存导致代码不生效的问题，我在 nginx 配置的时候使用了协商缓存，配置如下
在打包部署完成之后，发现了加载还是挺慢的，一个是我服务器的带宽比较小，另一个是确实加载了几个比较大的 js 文件。
首先 app.min.js 这个是主包，是不能省略的。然后看到 stenceils.min.js 跟 extensions.min.js ，看看他们可不可以不阻塞主流程。
大概看了一下 stenceils.min.js 的内容，它里面都是模版，好家伙，怪不得这么大；其次关于 extensions.min.js ，看了一下 /etc/build/build.xml 打包文件，它大概是做一些拓展逻辑的，比如说一些导入导出之类的。
所以这两个包的加载完毕与否，是不影响正常的主绘制流程使用的。
这里便是上面提到的两个包的加载入口，让这个加载函数加载完第一个包之后就执行回调函数即可。
这样之后，我们不需要再等待这个包加载完成就能开始用主要的绘图逻辑，这个包加载了 13S ，也就是说，我们不需要再等这 13S 。
首屏加载速度提升了 10多秒 啊兄弟们，恐怖如斯～
现在没有缓存的情况下，首屏加载 3S 左右，还是挺丝滑的
我另外用 React 实现了一个用户登录、管理文件的平台，目前做的功能有：
- 登录/注册/修改密码
- 文件列表，新增，修改，删除，重命名
目前来说做的还比较简单，只提供了最基本的文件管理功能，这个平台跟上面的绘图页面可以理解为是两个项目。
在新建或者打开的时候，会从这个平台跳转到绘图项目：
后端使用的 java ，使用的是 SpringBoot 搭建的项目。
相关技术栈：
- JWT：鉴权
- MongoDB：使用 Mongo-Plus 作为数据存储
- Redis：缓存
- Spring mail：邮件发送验证码
- transmittable-thread-local：上下文信息传输
后端实现主要分为三块：
在之前做 工具网站 的时候用到了 sa-token 框架，这个框架整体来说功能挺强大的，但对于小网站来说可能很多东西都不太需要。所以我这次基于 hutool 的工具类自己包了一层，实现了一个较为简洁的 JWT 鉴权流程。
这里封装了一个设置 token 以及解析 token 的工具类，登录成功后 token 就被设置到 cookie 中，请求过来时解析 cookie 中的 token 以获取用户信息。
这里包含了用户的注册、登录、修改密码等功能。
用户信息表的结构如下：
注册这里用到了邮箱验证码作为校验，验证码发送出去后会存在 redis 中，并设有有效期。
然后注册一个新邮箱作为发送验证码的邮箱，以 163邮箱 为例。
在这里开通 SMTP
然后引入邮件依赖
配置yml
具体的实现如下：
文件表里包括文件夹跟文件，主要通过 type 去区分。更详尽的表结构字段如下：
剩下的就是关于文件的一些增删改查逻辑，这里就不再放具体的代码。通过维护 parentId 跟 fileId 的对应关系，就可以实现文件树的逻辑。
这就是我基于 drawio 魔改的一个在线绘图软件，对于我们自身的要求来说是够用了。后续的拓展的话，我尽量还是以平台拓展为主，绘图功能拓展为辅，因为这个绘图功能已经很强大了，甚至对我来说，这个绘图我常用的还不到它功能的 10% ，所以我也不太想花太多精力去改它。
后续可能会拓展的点：
- 模版创建
- 模版市场
- 回收站
- 分享
如果你也有像我们一样的痛点，欢迎你体验我们的站点。如果你觉得有哪里用得觉得不舒服的地方，也欢迎随时与我们反馈。希望这个对你会有帮助～
以上就是本文的全部内容，如果你觉得有意思的话，点点关注点点赞吧～
作者：可乐鸡翅kele链接：https://juejin.cn/post/7352090806453567500
Nginx合集-限流配置方案参考
Nginx为我们提供了请求限制模块（ngx_http_limit_req_module）、基于令牌桶算法的流量限制模块（ngx_stream_limit_conn_module），可以方便的控制令牌速率，自定义调节限流，实现基本的限流控制
此模块已经合并至主线版本中，无需再额外编译添加
Nginx 并发限制的功能来自于ngx_http_limit_conn_module模块
模块的文档：Module ngx_http_limit_conn_module
limit_conn_zone只能配置在 http 范围内，可同时配置多条，被不同所引用；
$binary_remote_addr表示客户端请求的IP地址；
one自己定义的变量名（缓冲区）；
size设置为1m，大约为16000个ip地址（详细见文档）
limit_rate限制传输速度
limit_conn与limit_conn_zone对应，限制网络连接数
1、在http体添加配置说明
2、在server体添加限速实现
说明：为了减轻后端压力正常限制在接口层就可以
请求限制的功能来自于ngx_http_limit_req_module模块
模块文档：Module ngx_http_limit_req_module
limit_req_zone只能配置在 http 范围内；
$binary_remote_addr表示客户端请求的IP地址；
mylimit自己定义的变量名；
size设置为1m，大约为16000个ip地址（详细见文档）
rate请求频率，每秒允许多少请求；
limit_req与limit_req_zone对应
burst是配置超额处理,可简单理解为队列机制，让多余的请求可以先放到队列里，如果不加nodelay参数，队列里的请求不会立即处理，而是按照rate设置的速度，以毫秒级精确的速度慢慢处理
nodelay参数允许请求在排队的时候就立即被处理，也就是说只要请求能够进入burst队列，就会立即被后台worker处理，请注意，这意味着burst设置了nodelay时，系统瞬间的请求可能会超过rate设置的阈值。nodelay参数要跟burst一起使用才有作用
1、在http体添加配置说明
2、在server体添加限速实现
1、整体限制就把限速实现放在sever层入口
2、限制接口访问次数就放在接口配置
参考：
http请求
server层配置
用户评论
单身i
这个 HEADER CACHE-CONTROL的文章真太有帮助了！之前一直没弄清楚 Cache-Control 这玩意儿怎么用，现在终于明白了。感觉以后开发的时候可以用到好！
有16位网友表示赞同！
晨与橙与城
说起来 Header Cache-Control 我也是个新手, 很多情况下真的不知道该怎么设置才能达到预期效果。这篇博客正好解答了我一些疑惑，感谢作者!
有9位网友表示赞同！
我就是这样一个人
说的对！Cache-Control 是 HTTP 头的一种重要组成部分，设置它的参数可以帮助我们更好地控制资源的缓存策略，从而提高网站性能和用户体验。
有14位网友表示赞同！
苏樱凉
我也经常遇到HEADER CACHE-CONTROL的问题，特别是对于大文件的缓存，感觉总是把握不好，导致网站请求速度缓慢。这篇博客介绍了一些实用的技巧，希望能能有所帮助。
有16位网友表示赞同！
陌然淺笑
这篇文章写得相当详细，讲解了各种 Cache-Control 的参数和使用方法，还提供了很多实例案例，很有学习价值！
有12位网友表示赞同！
杰克
总觉得文章有点过于理论化，我希望以后能看到更多关于 HEADER CACHE-CONTROL 实施经验和案例的分享。
有20位网友表示赞同！
野兽之美
虽然文章解释得很清楚，但对于菜鸟来说还是有些难度，建议可以加入一些更简单的实例，更容易理解。
有20位网友表示赞同！
゛指尖的阳光丶
我曾经尝试使用 Cache-Control 来优化网站性能，结果反而让某些页面无法正常访问了。感觉 HEADER CACHE-CONTROL 并不是那么容易掌控…
有7位网友表示赞同！
念安я
我觉得HEADER CACHE-CONTROL的配置确实很灵活，可以根据不同的场景进行调整。文章没有提到一些比较高级的缓存策略，例如 ETags 和 Last-Modified。
有20位网友表示赞同！
失心疯i
对于网站开发者来说 HEADER CACHE-CONTROL 的掌握非常重要，这篇文章让我对 HTTP 缓存有了更深入的了解，感谢作者的分享！
有18位网友表示赞同！
浮世繁华
这篇博文很有帮助,但我感觉没有讲到一些比较常见的场景和问题，比如网络状况不良时的处理策略等等。
有13位网友表示赞同！
巷口酒肆
HEADER CACHE-CONTROL 的设置可能会影响 SEO 效果吗？我觉得应该再多提一点关于缓存与搜索引擎优化的关系。
有14位网友表示赞同！
无望的后半生
个人觉得文章的标题有点长，可以简短一些，更吸引读者注意力。
有8位网友表示赞同！
。婞褔ｖīｐ
感觉文章还是不错的，对 HEADER CACHE-CONTROL 有比较详细的解释，但建议加入一些图片或图表来辅助理解，这样能更直观地展示相关概念。
有16位网友表示赞同！
雨后彩虹
我一直觉得网站缓存是一个很重要的技术，感谢作者分享关于 HEADER CACHE-CONTROL 的知识！我会好好学习一下。
有11位网友表示赞同！
漫长の人生
文章中提到的技巧很棒，我已经在自己的项目中尝试使用这些方法，感觉网站速度确实有所提升！
有7位网友表示赞同！
←极§速
Cache-Control 是一个非常有用的 HTTP 头字段，作者的讲解很清晰易懂，对于想要了解缓存机制的人来说是一篇很好的入门文章。
有10位网友表示赞同！