0

对于国内访问 nginx.org 源的速度忍无可忍，于是摸了个 apt-mirror做了个镜像，方法参照 https://raymii.org/s/tutorials/Set_up_a_local_Ubuntu_debian_apt_mirror.html （想了一下似乎小流量访问搭反代是更好的办法，但是这种跨境反代总是有不可描述的敏感性，所以还是算了）

 

每天6点更新，unit 是 nginx unit（对应官方源的 packages.nginx.org/unit/），nginx 只有 mainline 版本（对应官方源的 nginx.org/packages/mainline/ ），暂时做了 Debian8、Debian9、Ubuntu16.04 （别的我自己不用），使用此镜像即等于接受以下 TOS：

  1. 软件及源码皆“按原样”分发，一切权利归 nginx.org 所有
  2. 该服务无任何可用性、实时性保证且服[……]

Read more

基于 OpenSSL 1.1.1 构建支持 TLS 1.3 的 Nginx 1.15 安装包

0

前言

注意：TLS 1.3 目前虽已定稿，但仍处于未被正式确立为 Internet standard 的草案标准阶段，其周边软件的支持可能发生快速的改变，本文所描述内容截止至2018年6月7日。

3月21日，TLS 1.3 草案正式定稿，最终版本为 draft28，详情见 Protocol Action: ‘The Transport Layer Security (TLS) Protocol Version 1.3’ to Proposed Standard (draft-ietf-tls-tls13-28.txt)
6月5日，nginx 发布新的主线版本1.15（其实和1.13.12相比几乎没有功能变化，修了一堆 bug）。
吃饱没事想试试 TLS 1.3 加上组内 keyless 项目的后续开发设计工作需要对 TLS 1.3 有一点了解，于是有了本文。

本文的描述基于 Ubuntu 16.04 和 Debian 8，至于 CentOS 可以参照一下去年 nginx 在1.13.0正式引入 TLS 1.3 draft18 支持时的文章 试玩 nginx mainline 1.[……]

Read more

从 E5-2690v4 的 NUMA 数量说起，浅谈 Broadwell 到 Skylake 的改进

1

TL,DR:

Broadwell 的 Cluster on die 和 Skylake 的 sub-NUMA cluster 设置会导致高核心 CPU 显示为两个 NUMA 节点，相关设置会影响缓存命中、延迟和内存访问延迟

Index

0，起因
1，简述架构的改进
2，Broadwell 上的 Snooping 和 COD
3，Skylake 和 SNC
4，其他的一些改进

起因：

某台机器（已知是双路）发现了四个 NUMA 节点： numastat 也显示出了程序的不同亲和性，

然而根据 Intel Ark ，2690 v4 最大支持两路，且每路为 35M L3，核心数和 L3 cache 显示的数量都恰好是 ark 的一半，因此对这个问题进行了一点调研，发现 Xeon Scalable 相比 Xeon E5v4 确实有比较大的改变不是挤牙膏，借此机会顺便深入了解了一些服务器 CPU 的架构，故有本文。

文中可能用到的几个缩写：Ivy Bridge 缩写为 IVB，Haswell 缩写为 HSW，Broadwell[……]

Read more

1

TL; DR：对软链进行 sed 请使用 sed -i --follow-symlinks ，否则软链会变成常规文件。

本来我已经很久不拿这种非常零散的点水一篇文章了但是由于这个坑我觉得无比愚蠢我决定上来吐槽一下

你们 Debian 特色的 nginx 配置文件分为 sites-available 和 sites-enabled，某次我对着 sites-enabled 来了一次 sed -i 之后又愉快的改配置文件然而 reload 谜之不生效，然后就发现软链都变常规文件了。

原因大致是 sed 会在内存里完成替换然后整个往文件里写进去，这个操作会改变文件的 inode 号，也默认没有判断软链。

RIP 纪念我被愚蠢的自己坑掉的一个小时。

EOF.

11

老鼠就不要对一只猫的仁慈抱有希望，尤其是那只猫曾经是老鼠 ——题记

写在前面

阅读本文可能需要关于 DNS 的基本知识，权威 DNS 和递归解析过程等参见先前的文章：浅谈 DNS 的解析

9月18日上午，各大社交网络开始盛传著名二次元同人画作社区 黄图网站 PIXIV 在大陆无法访问，各种说法甚嚣尘上，有说 P 站自主规制的，有说 P 站被墙的，也有认为是网络抽风的，实际上这个问题要判断到底是哪边的问题是比较简单的，所谓实践出真知，让我们来试着判断一下 P 站为什么会无法访问

关于 P 站情况的分析

首先来看看国内访问是什么情况：

这个响应有哪里不对呢？

  1. 向根服务器查询响应时间只有 23ms，你信吗（ dig @ 会直接向指定 name server 查询，不受本地 DNS 设置影响，大陆往返根域名服务器是不可能在 23ms 内完成的）
  2. 对一个域名的根域（没有前缀的裸域名）查询 A 记录，如果所查 server 是对应域的权限，则[……]

Read more