博学笃行·盛德日新

永福的博客

最后更新:

永福的2019

2019是逝去的一年,又是孕育的一年。 计划完成情况汇报 2019年的原计划如下: 1. 添丁 1. 还清所有欠款(房贷除外) 1. 注册公司,做一个属于自己的项目 1. 看书(12本),做笔记和总结。练字,至少做到字迹清晰。 1. 全家平安健康,北京之旅。 添丁这块已经安排上了,现在有17周+了 刚刚清点了一下,还是个负数😂 注册公司没有,做了一个宝宝认知卡的项目 认真数了一下,只有10本书,2020还得加油呀。练字,买了字帖,也看了些视频,英语字迹有些进步了。 父亲去世,愿天堂没有病痛。 工作 工作上整个一年没有大的故障也没有大的变更,服务器总体运行比较平稳,和我自己一样能更加沉静的去处理一些事情。因为一些各自的原因,方哥和刘文都离职了,像是失去左膀右臂一样,现在2个人干着4个人的活,压力要大很多了,还好的是,新项目没有像去年那样多。找了一个一直说想学运维的人过来,想着边学边带着搞,说实在的很不满意。 算是明白了一个道理,优秀的人在哪里都会发光的,不优秀的人,肯定是有不优秀的原因。以前总是觉得信息的不透明导致人们的贫富和智商差距,其实不然。现在几乎所有的技术资料和信息,都是可以在网络上学习到的,只是有些人肯去学习,真的去实践了,才掌握了对应的技术。所以说到底,还是人的问题,人的思想里有没有真正的想要得到某个东西或技术。 生活 3月,璐之生日旅行,山东(泰山、趵突泉、大明湖、青岛、崂山) 4月,父亲过世,结束病痛磨难的一生,也许对您是解脱,可是还没能好好的报答您的养育之恩,深感愧疚。我和哥哥一定会好好照顾好母亲,您在天上一定要看着我们哦。哎,想起了高中的时候,下大雨,你把身上的衣服脱下来给我穿,大冬天的穿着单薄的衣服和雨衣就回家。哎,再不能给你买你想吃的馄饨,无论多远我都愿意走,可是买了再也送不到您身边了。 5月,带母亲去植物园和动物园散心。 6月,带母亲、璐、乐崽一起去桂林。 7月,买车 8月,和璐、小欣一起去黑麋峰 9月,确认有二宝了 12月,和璐一起去了靖港古镇 2020年计划 迎接二宝出生 存款需大于7万(每月至少需结余7000) url监控项目需要完成(5月前) 看书(技术书12本+其他类型12本),背完《唐诗三百首》 暂时没有旅行计划,给璐换一个最新款的苹果手机咯,其实还想换个苹果电脑。

这是一篇转载加一些修改,原文地址 https://blog.csdn.net/xuejinliang/article/details/52847506 rewrite指令可以出现在server, location, if 下。这里主要讨论rewrite和location{}的匹配及匹配顺序问题。 对于出现在server{}下的rewrite指令,它会执行在location{}匹配之前,不管顺序如何。 对于出现在location{}下的 rewrite 指令,它的执行当然是在当前 location 匹配之后,但是由于 rewrite 导致 HTTP 请求的 URI 发生了变化,所以在执行完location{}下的 rewrite 后的 URI 又需要重新匹配 location{},就好比一个新的 HTTP 请求一样(注意由 location{} 内的 rewrite 导致的这样的循环匹配最多不超过 10 次,否则 nginx 会报 500 错误)。 总的来说,如果 server{} 和 location{} 下都有 rewrite ,依然是先执行 server{} ,然后进行 location{} 匹配,如果被匹配的 location{} 之内还有 rewrite 指令,那么继续执行 rewrite ,同时因为 location{} 内的 rewrite 改变了 URI ,那么重写后的结果 URI 需要当做一个新的请求,重新进行location{}的匹配,不会再对server{}段的rewrite进行匹配了,但是在新匹配的的location{}段内的rewrite还是会匹配的。 last 和 break 的区别 关于 last flag 和 break flag 的区别,官方文档的描述是:

上周五在公司内部分享了HTTP相关的内容 本来是有准备分享HTTPS相关的内容,后面想想HTTP和各技术工种人员可能关系更密切一些,如前端、后端、测试、运维等等。 了解整个的HTTP的工作原理,在我们现实的工作中也会有很大的帮助,去理解每个请求的过程,可以更好的去优化代码和架构。 另外一个方面,就是HTTPS也是工作在HTTP之上的,首先需要对HTTP要有一个了解。 具体的ppt如下: https://pic.liaoyongfu.com/2019/1028/图解HTTP-21张图把HTTP安排得明明白白.pdf 视频地址: https://h5.dingtalk.com/group-live-share/index.htm?encCid=32786029c9ef8b414d8400ad6ae5bf07&liveUuid=f9626a1e-5db6-4b77-8fc2-738f7d7ecb1a

整个故事从400年前的一次广场绞刑开始,说一个人试图炸毁议会大厦而被抓住而被执行绞刑,和后面的主体故事不相关而又相呼应。 故事开始于一个集权政府晚上实行宵禁,而一个女孩Eve准备去赴约,半路被秘密警察拦住准备猥亵,面具男V杀死了秘密警察,拯救了女孩。V带着女孩一起参观了他策划的11月5日的炸毁一座建筑的过程。集权政府开始在电视台及广播等平台掩饰这次炸毁建筑的事件,并让警察尽快抓住这个神秘的人。V带着事先录制好的光盘到电视台,威胁强迫电视台的工作人员播放炸毁建筑的真相,并邀请大家等一年后的11月5日一起去观看炸毁议会大厦。在V逃出电视台的过程中,Eve救了V,因为Eve晕倒了,所以V把Eve带回了自己的住处,避免Eve被政府抓住而受折磨。 V使用Eve的身份证件,进入一个电视台主持人的家里,并杀死了这个主持人。Eve开始怀疑V的动机。为骗取了V的信任,逃出V的控制,说可以帮助V实现他的计划。V让Eve配合一起去刺杀一个牧师,这个牧师实际上是个恋童癖。Eve告诉了这个牧师关于V的计划,但是牧师并不相信,反而更想强暴Eve,此时V破门而入,杀死了牧师。Eve趁机逃走到一个朋友家,这个朋友也接纳了她,并带她参观了自己的收藏违禁品。Eve在这个朋友家生活了一段时间后,这个朋友邀请Eve看自己录制的一档节目,节目中有贬低和讽刺最高领导人的内容,最后这位朋友被抓了(他自己本来估计是不会被抓的)。Eve逃到楼下,也被抓住了,进入一个黑暗的房子,进行审判,让她交代V的下落。 Eve在狱中经受住了长时间的折磨,在狱中,她发现了一封信,信中说的是一位女同性恋相爱但是不为当时的社会所容,最后在狱中被折磨而死,而不失去自己的信念,依然爱着这个世界。Eve深受鼓舞,坚定了自己的信念,愿以生命的代价,来保守关于V的秘密。此时,这个审判者释放了她,并告诉她,当她。。。。世界就是自由的。。。。。。Eve走出了牢房,发现,这一切都是V策划的,极度的失望。V向她解释,Eve所有的折磨都是他曾经受过的磨难,他希望Eve能振作起来,认清自己的内心,勇敢的面对这个世界,获得真正的自由。 V成功的策反了二号人物,并把他们两个都消灭了,但还是因身负重伤,自己也牺牲了。他把是否炸毁议会大厦的最后决定交给Eve,Eve犹豫了很久,但是看到因此牺牲的V,下定了决心,启动列车前往议会大厦的地下。 整个电影的隐喻是很丰富的,可以看到《1984》的影子,有关仇恨、爱、集权政府、恐怖、监控、自由、反抗、信念。

1. 缘起 座位左边的小伙伴,遇到一台服务器负载彪高,top一下看mysql的cpu占用超过100%。嘿,那应该就是mysql的问题啦,比较武断,但这个判断99%的情况下,应该没有错。 进入mysql,然后进行show full processlist查看数据库的当前进程。 MariaDB [xxx]> show full processlist; +------+----------+-----------------+------+---------+------+----------------------+----------------------------------------------------------------------+----------+ | Id | User | Host | db | Command | Time | State | Info | Progress | +------+----------+-----------------+------+---------+------+----------------------+----------------------------------------------------------------------+----------+ | 2886 | root | localhost | xxx | Query | 0 | init | show full processlist | 0.000 | | 3154 | secret | 127.0.0.1:44104 | xxx | Query | 0 | Copying to tmp table | select id,name from books where status = 1 order by rand() limit 10 | 0.

搭建keepalived+MySQL双主的数据库高可用方案 一、环境 1.1 机器环境 主机1:192.168.25.56 主机2:192.168.25.57 VIP:192.168.25.53 1.2 软件环境 CentOS Linux release 7.6.1810 mysql-community-server-5.6.43 keepalived-1.3.5 二、搭建mysql双主 2.1 mysql安装 mysql的安装本身没什么好讲的,默认情况下,CentOS没有自带mysql了,而是安装的mysql的分支版本mariadb,我们先把mariadb进行卸载,然后安装mysql。 # 卸载mariadb rpm -e --nodeps MariaDB-shared MariaDB-common # 安装mysql的官方repo yum install http://repo.mysql.com/yum/mysql-5.6-community/el/7/x86_64/mysql-community-release-el7-5.noarch.rpm # 安装mysql yum install mysql-community-server.x86_64 mysql-community-client.x86_64 mysql-community-common.x86_64 mysql-community-devel.x86_64 mysql-community-embedded.x86_64 mysql-community-embedded-devel.x86_64 mysql-community-libs.x86_64 # 进行配置(后面专门讲配置) # 创建目录 mkdir /data/mydata chown mysql.mysql /data/mydata # 初始化 mysql_install_db --defaults-file=/etc/my.cnf --user=mysql # 启动及开机启动 systemctl start mysqld systemctl enable mysqld 2.2 mysql的主主配置 配置文件/etc/my.

1. HTTPS性能损耗 前文讨论了HTTPS原理与优势:身份验证、信息加密与完整性校验等,且未对TCP和HTTP协议做任何修改。但通过增加新协议以实现更安全的通信必然需要付出代价,HTTPS协议的性能损耗主要体现如下: 增加延时 分析前面的握手过程,一次完整的握手至少需要两端依次来回两次通信,至少增加延时2*RTT,利用会话缓存从而复用连接,延时也至少1*RTT。 消耗较多的CPU资源 除数据传输之外,HTTPS通信主要包括对对称加解密、非对称加解密(服务器主要采用私钥解密数据);压测 TS8 机型的单核 CPU:对称加密算法AES-CBC-256 吞吐量 600Mbps,非对称 RSA 私钥解密200次/s。不考虑其它软件层面的开销,10G 网卡为对称加密需要消耗 CPU 约17核,24核CPU最多接入 HTTPS 连接 4800;静态节点当前10G 网卡的 TS8 机型的 HTTP 单机接入能力约为10w/s,如果将所有的HTTP连接变为HTTPS连接,则明显RSA的解密最先成为瓶颈。因此,RSA的解密能力是当前困扰HTTPS接入的主要难题。 2. HTTPS接入优化 2.1 CDN接入 HTTPS 增加的延时主要是传输延时 RTT,RTT 的特点是节点越近延时越小,CDN 天然离用户最近,因此选择使用 CDN 作为 HTTPS 接入的入口,将能够极大减少接入延时。CDN 节点通过和业务服务器维持长连接、会话复用和链路质量优化等可控方法,极大减少 HTTPS 带来的延时。同时,CDN会有多个节点分布在不同的地方,相当于把请求进行了分散在不同的节点上,减轻了源服务器的压力。 2.2 会话缓存 虽然前文提到 HTTPS 即使采用会话缓存也要至少1*RTT的延时,但是至少延时已经减少为原来的一半,明显的延时优化;同时,基于会话缓存建立的 HTTPS 连接不需要服务器使用RSA私钥解密获取 Pre-master 信息,可以省去CPU 的消耗。如果业务访问连接集中,缓存命中率高,则HTTPS的接入能力讲明显提升。当前TRP平台的缓存命中率高峰时期大于30%,10k/s的接入资源实际可以承载13k/的接入,收效非常可观。 2.3 硬件加速 为接入服务器安装专用的SSL硬件加速卡,作用类似 GPU,释放 CPU,能够具有更高的 HTTPS 接入能力且不影响业务程序的。测试某硬件加速卡单卡可以提供35k的解密能力,相当于175核 CPU,至少相当于7台24核的服务器,考虑到接入服务器其它程序的开销,一张硬件卡可以实现接近10台服务器的接入能力。 2.4 远程解密 本地接入消耗过多的 CPU 资源,浪费了网卡和硬盘等资源,考虑将最消耗 CPU 资源的RSA解密计算任务转移到其它服务器,如此则可以充分发挥服务器的接入能力,充分利用带宽与网卡资源。远程解密服务器可以选择 CPU 负载较低的机器充当,实现机器资源复用,也可以是专门优化的高计算性能的服务器。当前也是 CDN 用于大规模HTTPS接入的解决方案之一。

一、握手与密钥协商过程 基于RSA握手和密钥交换的客户端验证服务器为示例详解TLS/SSL握手过程。 1. client_hello 客户端发起请求,以明文传输请求信息,包含版本信息,加密套件候选列表,压缩算法候选列表,随机数,扩展字段等信息,相关信息如下: - 支持的最高TSL协议版本version,从低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3,当前基本不再使用低于 TLSv1 的版本; - 客户端支持的加密套件 cipher suites 列表, 每个加密套件对应前面 TLS 原理中的四个功能的组合: - 认证算法 Au (身份验证) - 密钥交换算法 KeyExchange(密钥协商) - 对称加密算法 Enc (信息加密) - 信息摘要 Mac(完整性校验) - 支持的压缩算法 compression methods 列表,用于后续的信息压缩传输; - 随机数 random_C,用于后续的密钥的生成; - 扩展字段 extensions,支持协议与算法的相关参数以及其它辅助信息等,常见的 SNI 就属于扩展字段,后续单独讨论该字段作用。 2. server_hello+server_certificate+sever_hello_done server_hello, 服务端返回协商的信息结果,包括选择使用的协议版本 version,选择的加密套件 cipher suite,选择的压缩算法 compression method、随机数 random_S 等,其中随机数用于后续的密钥协商; server_certificates, 服务器端配置对应的证书链,用于身份验证与密钥交换; server_hello_done,通知客户端 server_hello 信息发送结束; 3. 证书校验 客户端验证证书的合法性,如果验证通过才会进行后续通信,否则根据错误情况不同做出提示和操作,合法性验证包括如下: - 证书链的可信性 trusted certificate path,方法如前文所述; - 证书是否吊销 revocation,有两类方式离线 CRL 与在线 OCSP,不同的客户端行为会不同; - 有效期 expire date,证书是否在有效时间范围; - 域名 domain,核查证书域名是否与当前的访问域名匹配,匹配规则后续分析;

一、RSA身份验证的隐患 身份验证和密钥协商是TLS的基础功能,要求的前提是合法的服务器掌握着对应的私钥。但RSA算法无法确保服务器身份的合法性,因为公钥并不包含服务器的信息,存在至少存在两类安全问题:中间人攻击和信息抵赖 中间人攻击 客户端C和服务器S进行通信,中间节点M截获了二者的通信; 节点M自己计算产生一对公钥pub_M和私钥pri_M; C向S请求公钥时,M把自己的公钥pub_M发给了C; C使用公钥 pub_M加密的数据能够被M解密,因为M掌握对应的私钥pri_M,而C无法根据公钥信息判断服务器的身份,从而C和M之间建立了»可信»加密连接; 中间节点M和服务器S之间再建立合法的连接,因此C和S之间通信被M完全掌握,M可以进行信息的窃听、篡改等操作。 信息抵赖 服务器也可以对自己的发出的信息进行否认,不承认相关信息是自己发出。因为作为客户端,只有公钥信息,但是公钥信息里不包括服务端的信息。比如当C同时拥有A_S和B_S的公钥时,此时,A_S说:“我是A_S,C是大傻瓜!”。此时C就去问A_S:“你为什么骂我?”。A_S说:“不是我说的”。 A_S为什么可以抵赖?因为C同时拥有A_S和B_S的公钥,可以对信息进行解密,这个信息也完全是有可能是B_S说的,也就是上面的中间人攻击类似。 二、身份验证CA和证书 解决上述身份验证问题的关键是确保获取的公钥途径是合法的,能够验证服务器的身份信息,为此需要引入权威的第三方机构CA(如Globalsign,DigiCert等)。CA负责核实公钥的拥有者的信息,并颁发认证»证书»,同时能够为使用者提供证书验证服务,即PKI体系(Public Key Infrastructure,简称PKI)。 PKI采用证书进行公钥管理,通过第三方的可信任机构(认证中心,即CA),把用户的公钥和用户的其他标识信息捆绑在一起,其中包括用户名和电子邮件地址等信息,以在Internet网上验证用户的身份。PKI把公钥密码和对称密码结合起来,在Internet网上实现密钥的自动管理,保证网上数据的安全传输。 基本的原理为,CA负责审核信息,然后对关键信息利用私钥进行»签名»,公开对应的公钥,客户端可以利用公钥验证签名。CA也可以吊销已经签发的证书,基本的方式包括两类CRL文件和OCSP。CA使用具体的流程如下: 服务方S向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证; CA通过线上、线下等多种手段验证申请者提供信息的真实性,如组织是否存在、企业是否合法,是否拥有域名的所有权等; 如信息审核通过,CA会向申请者签发认证文件-证书。 证书包含以下信息:申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文,同时包含一个签名; 签名的产生算法:首先,使用散列函数计算公开的明文信息的信息摘要,然后,采用 CA的私钥对信息摘要进行加密,密文即签名; 客户端C向服务器S发出请求时,S返回证书文件; 客户端C读取证书中的相关的明文信息,采用相同的散列函数计算得到信息摘要,然后,利用对应CA的公钥解密签名数据,对比证书的信息摘要,如果一致,则可以确认证书的合法性,即公钥合法; 客户端然后验证证书相关的域名信息、有效时间等信息; 客户端会内置信任CA的证书信息(包含公钥),如果CA不被信任,则找不到对应CA的证书,证书也会被判定非法。 在这个过程注意几点: 申请证书不需要提供私钥,确保私钥永远只能服务器掌握; 证书的合法性仍然依赖于非对称加密算法,证书主要是增加了服务器信息以及签名; 内置CA对应的证书称为根证书 证书=公钥+申请者与颁发者信息+签名; 三、证书链 如CA根证书和服务器证书中间增加一级证书机构,即中间证书,证书的产生和验证原理不变,只是增加一层验证,只要最后能够被任何信任的CA根证书验证合法即可。 1. 服务器证书 server.pem 的签发者为中间证书机构inter,inter根据证书inter.pem验证server.pem确实为自己签发的有效证书; 1. 中间证书inter.pem的签发CA为root,root根据证书root.pem验证inter.pem为自己签发的合法证书; 1. 客户端内置信任CA的root.pem证书,因此服务器证书server.pem的被信任。 服务器证书、中间证书与根证书在一起组合成一条合法的证书链,证书链的验证是自下而上的信任传递的过程。 中间证书的签发机构可能是根证书机构也可能是另一个中间证书机构,所以证书链层级不一定相同。 证书链有以下特点: 同一本服务器证书可能存在多条合法的证书链。 因为证书的生成和验证基础是公钥和私钥对,如果采用相同的公钥和私钥生成不同的中间证书,针对被签发者而言,该签发机构都是合法的 CA,不同的是中间证书的签发机构不同; 不同证书链的层级不一定相同,可能二级、三级或四级证书链。 也就是说,同一个域名或服务器,可以有多个CA机构颁发的证书,只要证书没有到期或者被吊销,都是有效的证书。 证书吊销 CA 机构能够签发证书,同样也存在机制宣布以往签发的证书无效。证书使用者不合法,CA 需要废弃该证书;或者私钥丢失,使用者申请让证书无效。主要存在两类机制:CRL 与 OCSP。

HTTPS协议的主要功能基本都依赖于TLS/SSL协议,本节分析TLS/SSL协议工作原理。 TLS/SSL的功能实现主要依赖于三类基本算法:散列函数 Hash、对称加密和非对称加密,其利用非对称加密实现身份认证和密钥协商,对称加密算法采用协商的密钥对数据加密,基于散列函数验证信息的完整性。 散列函数Hash 常见的有 MD5、SHA1、SHA256,该类函数特点是函数单向不可逆、对输入非常敏感、输出长度固定,针对数据的任何修改都会改变散列函数的结果,用于防止信息篡改并验证数据的完整性; 在信息传输过程中,散列函数不能单独实现信息防篡改,因为明文传输,中间人可以修改信息之后重新计算信息摘要,因此需要对传输的信息以及信息摘要进行加密; 当前(2019年)实际应用的是sha256算法,md5算法和sha1算法经验证,不再是安全的算法,可以伪造出不同文件有相同的md5值或sha1值,所以在2016年1月1日后,微软不再接受根证书CA机构颁发sha1证书。 对称加密 常见的有 AES-CBC、DES、3DES、AES-GCM等,相同的密钥可以用于信息的加密和解密,掌握密钥才能获取信息,能够防止信息窃听,通信方式是1对1; 对称加密的优势是信息传输1对1,需要共享相同的密码,密码的安全是保证信息安全的基础,服务器和 N 个客户端通信,需要维持 N 个密码记录,且缺少修改密码的机制; 非对称加密 即常见的 RSA 算法,还包括 ECC、DH 等算法,算法特点是,密钥成对出现,一般称为公钥(公开)和私钥(保密),公钥加密的信息只能私钥解开,私钥加密的信息只能公钥解开。因此掌握公钥的不同客户端之间不能互相解密信息,只能和掌握私钥的服务器进行加密通信,服务器可以实现1对多的通信,客户端也可以用来验证掌握私钥的服务器身份。 非对称加密的特点是信息传输1对多,服务器只需要维持一个私钥就能够和多个客户端进行加密通信,但服务器发出的信息能够被所有的客户端解密,且该算法的计算复杂,加密速度慢。 结合三类算法的特点,TLS的基本工作方式是,客户端使用非对称加密与服务器进行通信,实现身份验证并协商对称加密使用的密钥,然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信,不同的节点之间采用的对称密钥不同,从而可以保证信息只能通信双方获取。 什么是加密套件(Cipher Suites) 加密套件是用于在TSL/SSL握手期间协商安全设置的算法的组合。在ClientHello和ServerHello消息交换之后,客户端发送优先级列表的密码支持套件。然后,服务器使用从列表中选择的密码套件进行响应。 加密套件为以下组合: 密钥交换算法(RSA,DH,ECDH,PSK) 认证算法(RSA,DSA) 批量加密算法(AES,Camellia,ARIA) 消息摘要算法(SHA-256) 这里是一个加密套件的例子: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS是协议。从ECDHE开始,在握手期间,密钥将通过临时ECDHE进行交换。RSA是认证算法。AES_128_GCM是批量加密算法。SHA-256是散列算法。 大多数浏览器和服务器都有各自支持的密码套件列表,两者将在握手过程中进行优先顺序比较,以确定使用的安全设置。 最后作为TLS 1.3最终版本,这一切都会改变。虽然以前TSL/SSL直到TLS 1.2版本都是是使用上诉描述的加密套件模板,但1.3版本的加密套件将会有所改变,因为它们仅用于协商加密和HMAC算法。 因为1.3加密套件的结构与之前的版本不同,所以它们与旧的TLS版本不能进行互换。 参考 HTTPS加密协议详解(二):TLS/SSL工作原理 http://www.wosign.com/faq/faq2016-0309-02.htm 加密套件:密码,算法以及安全设置 https://www.trustauth.cn/news/security-news/21583.html