写年度总结这件事的仪式感越来越强，原想今年要么不写了，但是这几天看了不少大佬的年度总结后想着还是该总结总结。
之所以不大想写年度总结主要还是因为觉得 2020 年的成长和收获不符合预期，总结只会让焦虑感倍增。但是想想在这不平凡的一年，且不说成长和收获，能好好的活着不出幺蛾子已经比很多人幸运了。
在全中国都挺过疫情的高峰期后，听闻故友 @司徒正美 病逝，唏嘘不已，司徒正美的技术热情和勤奋程度都是我早期入行前端时的榜样，说他去世意味着前端届又少了一个难得的人才毫不为过。希望所有仍在前行的技术人善待自己，保持健康的身体是取得更大进步和成功的必要条件。
在上一篇 Nginx 反向代理的优化点一 中简单介绍了反向代理服务与上游服务通信时开启 HTTP/1.1，看似一个简单的指令却能优化服务间网络传输的性能。本篇继续介绍另一个容易被忽视的优化点：buffer 缓冲区。
Nginx 与上游服务通信时可以把返回的响应内容（包含响应头 header 和响应体 body ）存入到缓冲区，当缓冲区的数据积累到一定的体积再一并发送给客户端。
缓冲区的开关通过 proxy_buffing 指令来配置，默认是开启的。如果 Nginx 代理的只是常规 API 服务时，默认的配置可以很好的工作，但是当上游服务返回的响应内容的体积较大时，此时默认的内存缓冲区容易被存满，内存缓冲区存满后则会将响应体作为临时文件写入到磁盘，在请求完成后再删除临时文件。
使用 Java / Node.js / Go 等语言开发的 Web 服务通常会使用 Nginx 作为反向代理服务来实现负载均衡等功能，此时的 Web 服务相对于 Nginx 来说就是上游服务（upstream）。
一般在优化 Web 服务的性能时都会聚焦在 Web 服务本身，而容易忽视 Nginx 和上游服务之间的连接。Nginx 有很多带 proxy 前缀的指令，通常在配置反向代理时往往以为配置一个 proxy_pass 就完事了，但是在追求 Web 服务的极致性能时还有一些反向代理的配置能起到事半功倍的效果。本文将简单介绍 Nginx 作为反向代理时选择 HTTP 协议的版本。
作为一名电影爱好者，虽然在直播、在线视频点播等技术这么发达的今天仍然喜欢从网络下载电影资源观看。
有了群晖 NAS 后就一直尝试捣鼓各种下载套件，分别尝试过 Download Station、Aria2、Transmission、玩物下载等，都不尽如人意。群晖自带的 Download Station 还是比较鸡肋，BT 下载的 DIY 的空间虽然比较大，但是速度上始终不如迅雷，玩物下载的速度比较勉强，但在得知玩物下载在群晖后台搞小动作时也就果断卸载了，归根结底主要还是以前使用迅雷时已经习惯了迅雷的下载速度，尽管迅雷的广告多体验渣。
捣鼓了一圈后又回到了原点，于是尝试另一种曲线救国的路线，就是在群晖上安装 Windows 7 的虚拟机，然后在虚拟机中使用迅雷来下载，这样速度上能保证。不过新的问题是，在群晖中打开虚拟机然后再操作迅雷，操作流程比较繁琐。
那么有没有可能把在虚拟机中使用迅雷的下载流程自动化呢？既然都打算做自动化了，那么干脆做得更彻底些，将其他环节也尽量自动化，于是就有了本文。
最近在家搭建家庭私有云，在搭建之前，高速稳定的网络传输速度是必备的基础能力之一，这里说的并不是我们家里安装的电信、联通等宽带或光纤，而是家庭内部局域网。
虽然当前在商用网络环境中已经有很多万兆网络的应用，但是家用局域网由于经费和设备的限制目前普遍只能达到千兆的网络环境标准，组建不了万兆网络，但是至少也得保证是千兆的网络环境。不过实际情况是由于个别网络设备或系统设置的影响，还存在百兆网络的传输速度。为了确保整个家庭局域网都是千兆网络，需要一一对所有网络设备进行测试，避免某些设备跑在百兆网络环境下而拖慢了整个局域网的速度。
