nginx

浏览器是如何渲染页面的 ？ 渲染的流程如下： 解析HTML文件，创建DOM树。自上而下，遇到任何样式（link、style）与脚本（script）都会阻塞（外部样式不阻塞后续外部脚本的加载）。 解析CSS。优先级：浏览器默认设置<用户设置<外部样式<内联样式<HTML中的style样式； 将CSS与DOM合并，构建渲染树（Render Tree） 布局和绘制，重绘（repaint）和重排（reflow） 从输入 URL 到页面展示到底发生了什么 转自：http://web.jobbole.com/91239/ 1、输入地址 当我们开始在浏览器中输入网址的时候，浏览器其实就已经在智能的匹配可能得 url 了，他会从历史记录，书签等地方，找到已经输入的字符串可能对应的 url，然后给出智能提示，让你可以补全url地址。对于 google的chrome 的浏览器，他甚至会直接从缓存中把网页展示出来，就是说，你还没有按下 enter，页面就出来了。 2、浏览器查找域名的 IP 地址 1、请求一旦发起，浏览器首先要做的事情就是解析这个域名，一般来说，浏览器会首先查看本地硬盘的 hosts 文件，看看其中有没有和这个域名对应的规则，如果有的话就直接使用 hosts 文件里面的 ip 地址。 2、如果在本地的 hosts 文件没有能够找到对应的 ip 地址，浏览器会发出一个

反向代理实例（一） 实现效果：实现效果：使用 n ginx 反向代理，访问 www.123.com 直接跳转到 127.0.0.1:8080 实现代码： 1） 启动一个 tomcat ，浏览器地址栏输入 127.0.0.1:8080 ，出现如下界面 2） 通过修改本地 host 文件，将 www. 123 .com 映射到 127.0.0.1 配置完成之后，我们便可以通过 www.123.com:8080 访问到第一步出现的 Tomcat初始界面。那么如何只需要输入 www.123.com 便可以跳转到 Tomcat初始界面呢？便用到 nginx的反向代理。 3） 在 nginx.conf 配置文件中增加如下配置 如上配置，我们监听80端口，访问域名为www.123.com，不加端口号时默认为80端口，故访问该域名时会跳转到127.0.0.1:8080路径上。在浏览器端输入 www.123.com 结果如下： 反向代理实例(二) 实现效果：使用 nginx 反向代理， 根据访问的路径跳转到不同端口的服务中 nginx 监听端口为 9001 访问 http://127.0.0.1:9001/edu/ 直接跳转到 127.0.0.1:808 1 访问 http://1 27.0.0.1:9001/vod/ 直接跳转到 127.0.0.1:808 2 实验代码 第一步，准备两个

1、简介 Nginx最为常见的一种功能就是配置反向代理。配置也是十分的简单，只需要用到proxy模块即可。 怎么查看nginx默认的安装模块？ 在nginx的安装目录下有个auto目录然后使用下边的命令就可以查看。 cat auto/options | grep YES 截取其中一部分，都是nginx安装的模块。 2、nginx反向代理配置 下边是配置nginx做为反向代理最为简单的配置 在nginx.conf中配置也可以，在vhosts利用虚拟主机配置也可以。 server { listen 80; #配置监听的端口号 server_name 192.168.8.3; #配置nginx的IP，或者需要被访问的域名 location / { proxy_pass http://192.168. 8 .2:8080; #配置需要被代理的访问地址，域名和IP都可以 index index.html index.htm index.php; } } 上边是最简单的配置，没有配置任何其它的东西。日志之类的都没有配置。 配置反向代理最为关键的字段就是proxy_pass这个字段。 格式：proxy_pass URL; URL是一个IP地址可以，是一个域名也可以。前提是代理的服务器能够访问后端的被代理的服务器。 来源： oschina 链接： https://my.oschina.net/u

近几年直播行业火爆，开源的直播软件解决方案有 SRS （Simple-RTMP-Server）和 nginx-rtmp-module ，前者是国人发起的一个优秀的开源项目，目前国内很多公司都使用它作为直播解决方案，由C++编写；后者依赖 Nginx ，以第三方模块的方式提供直播功能，由C编写。SRS采用多线程方式，性能优秀，经受住了众多场景的考验，但是SRS3已经闭源（更正，中间一段时间闭源，现在又开源了）；nginx-rtmp-module是采用多进程方式，Nginx的性能优秀，但是据网友测试，nginx-rtmp-module的性能不如SRS，并且nginx-rtmp-module的作者已经很久没有更新版本了，支持的功能也有限，例如不支持HTTP方式的FLV直播，而这是国内直播行业普遍采用的方式；不支持虚拟主机功能，在有多个IP地址的主机上无法根据域名选择不同配置；还有饱受诟病的播放响应延迟时间很长的问题（即俗称的不能秒播）等。 我在nginx-rtmp-module的基础上实现了基于HTTP方式的FLV直播功能，支持GOP缓存，减少播放响应延迟时间；支持流式和Transfer-Encoding: chunked两种HTTP响应格式；支持根据域名匹配不同配置的虚拟主机功能；修复nginx-rtmp-module没有listen配置项时，推流失败的问题；解决nginx-rtmp

Vue整合nginx：（1）开发环境npm run dev下，通过nginx解决前后端分离造成的跨域问题 参考文章： （1）Vue整合nginx：（1）开发环境npm run dev下，通过nginx解决前后端分离造成的跨域问题 （2）https://www.cnblogs.com/mysouler/p/10818612.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/u/4428122/blog/4888983

在公司规模较小的情况下我们可以通过docker官方仓库的方式来进行构建。 Docker Registry 作为 Docker 的核心组件之一负责镜像内容的存储与分发，客户端的 docker pull 以及 push 命令都将直接与 registry 进行交互,最初版本的 registry 由Python 实现,由于设计初期在安全性，性能以及API 的设计上有着诸多的缺陷， 该版本在 0.9 之后停止了开发，由新的项目 distribution（新的 docker register 被称为 Distribution）来重新设计并开发下一代 registry，新的项目由 go 语言开发， 所有的 API，底层存储方式，系统架构都进行了全面的重新设计已解决上一代registry 中存在的问题，2016 年 4 月份 rgistry 2.0 正式发布，docker 1.6 版本开始支持 registry 2.0，而八月份随着 docker 1.8 发布，docker hub 正式启用 2.1 版本registry 全面替代之前版本 registry，新版 registry 对镜像存储格式进行了重新设计并和旧版不兼容，docker 1.5 和之前的版本无法读取 2.0 的镜像，另外，Registry 2.4 版本之后支持了回收站机制，也就是可以删除镜像了，在 2.4

准备镜像源 rpm -ivh epel-release-latest-7.noarch.rpm // 安装扩展源 cd /etc/yum.repos.d/ mv backup /CentOS7-Base-163.repo./ yum clean all && yum makecache yum install -y ruby rubygems ruby-devel gem update --system // 升级 rubygems 版本 / 此图片为报错 gem install rubygems-update -v 2.3.0 // 报错什么版本就升级到什么版本 gem update --system // 再次升级 gem sources -l // 查看已存在的镜像源 gem sources -a http://mirrors.aliyun.com/rubygems/ // 将阿里云镜像源加入 gem sources --remove https://rubygems.org/ // 将国外镜像源移除 gem sources -l // 查看镜像源是否移入 gem install fpm // 安装 FAM 工具 tar xf nginx-1.14.2.tar.gz -C /usr/src/ cd /usr/src/nginx-1.14.2/ yum -y install

第一部分 Kafka架构与实战 1.1 概念和基本架构 1.1.1 Kafka介绍 Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多生产者、多订阅者，基 于zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日 志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。 主要应用场景是：日志收集系统和消息系统。 Kafka主要设计目标如下： 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。 * 同时支持离线数据处理和实时数据处理。 支持在线水平扩展 有两种主要的消息传递模式：点对点传递模式、发布-订阅模式。大部分的消息系统选用发布-订阅模式。Kafka就是一种发布-订阅模式。 对于消息中间件，消息分推拉两种模式。Kafka只有消息的拉取，没有推送，可以通过轮询实现消息的推送 Kafka在一个或多个可以跨越多个数据中心的服务器上作为集群运行。 Kafka集群中按照主题分类管理，一个主题可以有多个分区，一个分区可以有多个副本分区。

开源waf是网络安全的重要部分，Cloudflare认为：十年后数字经济的网络安全基础设施会像水过滤系统一样普及，而这个过滤系统的核心就是waf。对于服务器来说，部署WEB应用防火墙十分重要，这方面的开源waf很多，但优秀的太少，笔者经过大量搜索，并结合市场热度，整理出2021年十大开源waf供大家参考。 1、OpenResty OpenResty 是由中国人章亦春发起，把nginx和各种三方模块的一个打包而成的软件平台，核心就是nginx+lua脚本语言。主要是因为nginx是C语言编写，修改很复杂，而lua语言则简单得多，国内很多大公司如360、京东、gitee等都在用来作为web应用防火墙。 项目地址： https://github.com/openresty/ 2、AIHTTPS aihttps是hihttps的升级版，也是由中国人编写。特点是兼容ModSecurity规则，并且已经向人工智能方向进化：使用机器学习自主生成对抗规则，来防御包括：漏洞扫描、CC 、DDOS、SQL注入、XSS等。其商业版也开源，是目前商业化开源程度最高的WAF。 项目地址： https://github.com/qq4108863/ 官网： http://www.hihttps.com 3、ModSecurity ModSecurity是开源WAF的鼻祖，是一个开源的跨平台Web应用程序防火墙

Istio在服务网格方面有很大的领先优势，但只在早期采用者中如此。根据云计算基金会（CNCF）的调查，在已经在生产中使用服务网格的用户中，63%的用户已经采用了Istio，这是linker的两倍多。其他的选择中，除了HashiCorp的Consul之外，占比都不超过10%。 如果考虑到它通常与Envoy一起部署的事实，Istio的优势就没有那么吓人了。Envoy最近无可否认做得很好。CNCF社区中Envoy项目的生产使用率从2019年的17%上升到2020年的24%。但评估该项目的人从35%下降到21%，这可能意味着许多组织考虑并拒绝了Envoy，这可能会对未来服务网格的采用产生影响。并不是每个人都将Envoy与服务代理或入口控制联系起来。当筛选掉这一功能时，只有18%的用户在生产或评估情况下使用了Envoy。 超过一半（55%）的为Ingress使用Envoy的受访者在生产中有服务网格。另有26%的人正在积极测试服务网格，9%的人计划在未来12个月内开始。其中大部分都倾向于Istio，以及基于项目技术的解决方案，例如F5 Networks的Aspen Mesh和Tetrate。 另一个调查则显示，并非所有的服务网格采用都将来自CNCF社区（那里充斥着供应商和大公司）。NGINX在2020年6月调查了近500人，调查结果显示，16%使用NGINX入口控制器（NIC），其中19