玉环建设规划局网站,网络推广公司十大排名,wordpress搜索对接公众号,云定制网站wmproxy
wmproxy是由Rust编写#xff0c;已实现http/https代理#xff0c;socks5代理#xff0c; 反向代理#xff0c;静态文件服务器#xff0c;内网穿透#xff0c;配置热更新等#xff0c; 后续将实现websocket代理等#xff0c;同时会将实现过程分享出来#xff…wmproxy
wmproxy是由Rust编写已实现http/https代理socks5代理 反向代理静态文件服务器内网穿透配置热更新等 后续将实现websocket代理等同时会将实现过程分享出来 感兴趣的可以一起造个轮子法
项目 wmproxy
gite: https://gitee.com/tickbh/wmproxy
github: https://github.com/tickbh/wmproxy
了解三种格式
Json
JSON是一种轻量级的数据交换格式被广泛使用在Web应用程序之间传输数据。JSON使用大括号{}来表示数据结构使用冒号:来连接键和值。JSON支持字符串、数字、布尔值、null、数组和对象等多种数据类型。JSON文件通常用于数据交换、存储等场景也可以用作配置文件。 JSON简单易读存储通用但JSON原生不支持注释用来做配置文件比较硬伤。 它流行度极高基本上每个程序员都和他打过交道。 多层级时对齐和缩进不好控制容易出错 Yaml
YAML被设计为一种可读性极强的数据序列化标准可以用来表达层次化数据。YAML使用空格缩进来表示数据层次结构。YAML支持浮点数、布尔值、字符串、数组、映射等多种数据类型。YAML文件通常用于配置文件、数据交换等场景。 与JSON及TOML相比结构比较紧凑 但相对用空格缩近编写及拷贝时出错的机率比JSON及TOML高许多 Toml
TOML 旨在成为一个语义明显且易于阅读的最小化配置文件格式。 TOML 应该能很容易地被解析成各种语言中的数据结构。
TOML是一种简洁明了的键值对格式被设计成可以很容易地映射为哈希表。TOML使用等号来连接键和值使用缩进来表示数据层次结构。TOML支持整数、浮点数、字符串、布尔值、数组、字典等多种数据类型。TOML文件通常用于配置文件、数据交换等场景。 它易于阅读和编写语法灵活 与JSON配置相比TOML在简洁性方面远远胜出 与YAML配置相比TOML在简洁性以及语法灵活性方面远远胜出。 三种格式测试数据的对比
我们用Rust的项目配置文件来做对比为了展示所有的类型格式有所变更。它以Toml来做配置文件我们首先先展示toml的格式 内容包含创建者创建时间项目名称项目依赖等信息如果我们将其转化成可配置的JSON格式时 toml
createtickbh
create_time2023-09-08T10:30:00Z
[project]
# 项目名称
namewmproxy
version1.1
editor2022
# 项目依赖
[project.dependencies]
wenmeng{version 0.1.21, default-features false, features [std, tokio]}
webparse{version 0.1, default-features false}行数12行注释两行全部顶格开头原生支持时间格式
json
{create: tickbh,create_time: 2023-09-08T10:30:00.000Z,project: {name: wmproxy,version: 1.1,editor: 2022,dependencies: {wenmeng: {version: 0.1.21,default-features: false,features: [std,tokio]},webparse: {version: 0.1,default-features: false}}}
}行数23行层次的递进比较多不容易对齐无法注释不支持时间格式
yaml
create: tickbh
create_time: 2023-09-08T10:30:00.000Z
project:# 项目名称name: wmproxyversion: 1.1editor: 2022# 项目依赖dependencies:wenmeng:version: 0.1.21default-features: falsefeatures:- std- tokiowebparse:version: 0.1default-features: false行数18行注释两行原生支持时间格式到features这级行深度相对较高但是一眼看上去比json清晰 相对来说JSON比较不适合做比较复杂的配置文件但VSCODE使用的拓展的JSON以支持注释功能。 接下来尝试将nginx.conf格式做转换
以下尝试的将
http {gzip on;server {listen 80; #监听80的服务端口server_name wm-proxy.com; #监听的域名location /products {proxy_pass http://127.0.0.1:8090/proxy;add_header Access-Control-Allow-Credentials true;add_header Access-Control-Allow-Origin *;}location / {root wmproxy;index index.html index.htm;}}
}我们也模仿类似的结构但是对于toml,yaml,json来说都没有一个key两个值的要么我们只能用对应的数组此时我来先来初步重构类似的结构。以下我们以toml结构为例我们分析table的级数有三级最外层为http中间层为server为数组最内层为location也为数组headers我们用之前提到过的mappings用proxy开头来表示重写Reqeust其它的来表示重写Response文件系统我们用上节提到的file_server。 我们先定义http的table他只有一个属性gzip为on
[http]
gzipon其次server为一个数组那么我们可以如下定义有绑定地址和server_name
[[http.server]]
bind_addr127.0.0.1:80
server_namewm-proxy.com再然后location也为一个数组定义如下
[[http.server.location]]
rule /products
reverse_proxy http://127.0.0.1:8090/proxy
headers [[, Access-Control-Allow-Credentials, true],[, Access-Control-Allow-Origin, *]
]
[[http.server.location]]
rule /
file_server { rootwmproxy, browse true, index[index.html, index.htm] }那么最终的结构为如下
[http]
gzipon
[[http.server]]
bind_addr127.0.0.1:80
server_namewm-proxy.com
[[http.server.location]]
rule /products
reverse_proxy http://127.0.0.1:8090/proxy
headers [[, Access-Control-Allow-Credentials, true],[, Access-Control-Allow-Origin, *]
]
[[http.server.location]]
rule /
file_server { rootwmproxy, browse true, index[index.html, index.htm] }而yaml的格式结构如下
http:gzip: onserver:- bind_addr: 127.0.0.1:80server_name: wm-proxy.comlocation:- rule: /productsreverse_proxy: http://127.0.0.1:8090/proxyheaders:- - - Access-Control-Allow-Credentials- true- - - Access-Control-Allow-Origin- *- rule: /file_server:root: wmproxybrowse: trueindex:- index.html- index.htm而json的格式结构如下
{http: {gzip: on,server: [{bind_addr: 127.0.0.1:80,server_name: wm-proxy.com,location: [{rule: /products,reverse_proxy: http://127.0.0.1:8090/proxy,headers: [[,Access-Control-Allow-Credentials,true],[,Access-Control-Allow-Origin,*]]},{rule: /,file_server: {root: wmproxy,browse: true,index: [index.html,index.htm]}}]}]}
}自建的好处是比较清晰可以自定义自己合适的结构但是编写者需要重新开始学习而用能用的配置文件需要遵循它的格式定义像toml文件如果层级很深他的key值配置会很长因为他一旦定义一个table就是从最顶级来解析但是编写者只要熟悉过这配置文件很快就能写出满意的配置文件而yaml的层级结构相对会需要去看对齐与否编写的时候需要额外注意因为弄错了缩进层级就会发生错误而json最后结尾的会有相当多的花括号相对比较容易弄错。JSON总体来说不太适合做比较复杂的配置文件
结语
在不考虑自建格式的情况下如nginx的nginx.conf如caddy的Caddyfile将会同时兼容toml及yaml格式的配置文件。
