一个工匠

DNS 协议的用途和解析方式是什么样的？

所有应用层层面的数据，如果需要进行网络传输，必定需要 ip 地址这个核心参数。没有 ip 地址的包，是不可能发出去的，都过不了网卡。因为网卡不知道要把这个包传到哪里去。
而 ip 地址人类很难记忆，所以很多服务都是通过域名进行访问。域名是比较方便记忆，但是网络又不认，因为网络无法根据域名进行数据传输，即域名没有定位功能。
所以所有的应用层的域名访问，都需要 DNS 协议解析成 ip 地址后才能够封包发送，ip 有定位功能。如果一个应用层服务直接通过 ip 地址访问另一个服务，那么是完全不用 DNS 做一次 ip 地址解析的。
我们的域名是需要从特定的服务商进行购买，在服务商处会进行 ip 地址的配置。而 DNS 协议的根据就是层层服务商解析，问根域，返回顶级域，问顶级域，返回权威域，这样通过.com、.cn 等不同服务商的判断，最终落实并返回一个确定的 ip 地址。
DNS 协议是系统层级的操作，应用层无需关心，系统通过 DNS 协议拿到 ip 地址后会给到应用层，然后应用层将 ip 地址传递到传输层进行网络数据封包。
为了效率问题，系统会进行 DNS 的缓存以加快解析速度，并且还会设置有效期以较少误差。
比较例外的是 hosts 文件。在这里配置的信息具有第一优先级，系统如果在 hosts 中找到了对应的域名和 ip 地址的映射，则不再进行 DNS 请求而直接返回映射数据。
DNS 会有劫持问题，在移动端会使用 HTTPDNS 技术。DNS 有一个非常重要的大杀器，就是做负载均衡。

对 CPU 的一点简要说明。
如果你是对 CPU 的制作有一些模糊，或者希望通过其他博文来验证你的想法，那么下面一些认知或许对你有一些帮助。
大到宇宙飞船，小到 PC、手机、冰箱，无一没有芯片的影子。
各位一定都对芯片有很多认知了，我们不需要多做说明，没有芯片，就没有新时代。从真空三极管到锗晶体管到硅晶体管，每一步都是一次跃迁。

集成电路的制作

硅 => 晶圆

原材料首当其冲的是高纯度硅。通过把高纯度的硅融化，用一个引子伸入容器，不断的让硅附着生长在引子上面。我们可以想象明矾的制作过程。
引子不断的往上提，最后一个很重的圆柱形硅淀就形成了。
这个圆柱形直径有 10 厘米 +。
然后通过机器切割，从上往下，切割一个豁口或者一个边，这个豁口或者边，是为了客户进行晶圆制作的时候辨认方向用的。因为最终晶圆不是 100% 利用的，这个豁口或者边，是肯定不会用到的。
然后，对整个圆柱形硅切割成晶圆。每个晶圆对直径也还是 10 厘米 +，但是厚度只有 3 毫米左右。这样的一片片晶圆，就是后面集成电路的原材料了。
所以，晶圆其实是很大的一个圆盘，比普通人的一张脸，还是要大一些的。

我有一个梦想，因为这个梦想，我也产生过心里的孤独。
今天我索性大胆的把自己的念想写出来，也把自己孤独的过程表达出来。
如果屏幕前的你看完心里也会产生一些奇思妙想，那我们或许可能很好的沟通下去。如果有共鸣，如果旅途方向再一直，陌生人我也愿意为你背负行囊。

互联网规则

1. 互联网本质，就是数据在一定的协议基础上，在多台主机之间，进行数据的流动共享。
2. 网络传输协议非常多，不是简简单单的 HTTP/HTTPS 协议，我们 App 看的直播就有 RTMP、私有 UDP 协议、DNS (+CDN 加速) 等等。
3. 数据在网络上基于二进制包进行传输，传输规则基于 7 层网络协议，4/5 层网络协议便于理解
4. 数据包在传输过程中几个关键不可缺少的字段：端口、MAC 地址、IP 地址。可以没有应用层的 HTTP 等协议，但是绝对不可能没有网络层、Mac 层和物理层。没有这三层，数据是不可能找到对应接收方的，甚至这个数据包都出不了你的电脑端口。可以没有应用层等，如 ping 一个主机使用的 ICMP 就是网络层协议，就没有应用层。

HTTP/HTTPS 规则

1. HTTP 协议是无状态的协议，所以需要 Session、Cookie
2. HTTP 没有三次握手，握手的是 TCP。应用层只要通过 TCP 必定会有三次握手。握手并不是 C-S 之间有一条网络管道进行连接，而是两端各自维护相应的状态，当双方状态都处于 runing 的时候 (双方套接字处于完成状态，本质是 Socket 套接字，UDP 也适用该规则)，代表双方连接建立
3. HTTPS 的公私钥认证，很多情况下只发生一次，公私钥认证的用途仅仅是为 C-S 之间的后续通讯建立对称密钥。后续的网络请求不出问题是不会重新公私钥认证的。因为服务器会在第一次公私钥认证的时候，生成 Session ID，该 Session ID 指向对称密钥并保存。客户端一般也会保存这个 Session ID 和对称密钥，后面客户端提交 Session ID 到服务器就可以建立起来安全通信。HTTP1.0 就可以支持 keep alive，多个网络请求可以复用建立的连接，这个时候更加不需要公私钥认证了。
4. HTTPS 的公私钥认证，生成的对称密钥是由 C 生成一个随机数、S 生成一个随机数、C 再生成一个随机数这三个数完成的。公私钥认证的开始，是没有加密的，因为客户端还没有拿到公钥。所以前两个随机数是可以抓包拿到的，但是第三个随机数是 C 通过公钥加密传输的，所以第三个随机数的安全传输才是整个安全机制的重点。（前两个随机数被串改了也没关系，因为 C 和 S 的随机数不一样了，生成的对称密钥也不一样，后面的数据传输加解密过程中，就无法完成校验了）有个重点是，为什么需要 3 个随机数？而不能直接传输上面的第三次随机数？因为随机数为了确保随机性，而随机性不能完全依靠一方来确定，因为很可能不随机。而 3 个随机数，已经可以很好的保障最后生成的对称密钥的随机性了。

字节与比特

比特是计算机存储的最小存储单元。我们认知到的数字 3，在计算机的存储里（硬盘或者内存）的结构是这样的：00000011，也就是我们理解的二进制。
所以这个数字 3 是由 8 位组成的。每位有 0 和 1 两种变化。
比特存储，是计算机的基石。我们在互联网上通行的一切，如图片、音视频、文字，甚至各位的博客、App、电子书等等，能想到的能通过互联网传输的一切，都是比特存储。
举个例子，我们看的一张图片，在磁盘上的存储，或许就是这样子：0101011101010101010111101011110101010101100***(省略100000000个)***1010100111010101。

1 字节 (byte)=8 比特 (bit)
我们刚才说到的数字 3，就是一个字节，在磁盘上就是 00000011。（为了便于理解，实际可能是 00000000 00000011，或者 00000000 00000000 00000000 00000011）。

1KB = 1024B（2 的 10 次方）
1MB = 1024KB（2 的 10 次方）
1GB = 1024MB（2 的 10 次方）
这些大小的计算都是定死的规则。规则很重要，有了规则才能合作。

今天，在公司卫生间里面，看到了这个 “每天努力 0.01” 和 “每天懈怠 0.01” 一年后的差距，颇为感触。
不过我不是因为这两个差距的比较产生心里的鸡汤，而是引发了一些关于努力的思考。
什么算是努力？好人一定要好报吗？

1
2
3
4
5
6

update 2023.09.21
近一年没有洗牙了，几天前再次去洗了一次。
现在我学的聪明了，不去医院洗了，去诊所，价格便宜很多。两个人 100 元左右。
这几年牙齿护理的比较好，牙结石比较少，也没有什么烟渍。出了一些血，问题不大。
老婆发现有 4 颗蛀牙，打算本周去补牙。
洗完牙后，很舒服的。值得推荐。

今天去社区一个牙科诊所洗牙了。

现在已经洗牙归来，本来不是什么天大的个人事情需要在博客里面说一遍。
但是我忍不住自己的喜悦，所以一定想要推荐没有洗牙习惯的朋友，一定要去一次。
这是脱胎换骨的体验。

From Internet. 方便自己查阅使用，侵权删。

一、常见类

1、RACSiganl 信号类。

RACEmptySignal ：空信号，用来实现 RACSignal 的 +empty 方法；

RACReturnSignal ：一元信号，用来实现 RACSignal 的 +return: 方法；

RACDynamicSignal ：动态信号，使用一个 block - 来实现订阅行为，我们在使用 RACSignal 的 +createSignal: 方法时创建的就是该类的实例；

RACErrorSignal ：错误信号，用来实现 RACSignal 的 +error: 方法；

RACChannelTerminal ：通道终端，代表 RACChannel 的一个终端，用来实现双向绑定。

2023.02.18 更
引用计数是 iOS 内存管理的核心，strong 是对其直接应用，weak / 自动释放池 是对其间接应用。要理解 weak 和自动释放池，最有效的办法就是看 runtime 源码，理解 hashTable 和 hashMap 这两张数据结构表。其中 自动释放池 还和 runtime 有很大关系，这点需要串联下知识点。

没有经历过 MRC 年代，对 iOS 的内存管理的理解就不会那么顺畅。
MRC 年代的内存总是不好管理，所以 ARC 帮我们做了很多事情。ARC 做了很多事情让内存管理更加精准优秀外，也隐藏了很多内存管理的细节，也让这块知识点不容易啃食。
真正的内存管理，一定需要回到 MRC 下面去理解，根本思想是：谁创建、谁释放、谁引用、谁管理。
内存释放的唯一途径是：引用计数 = 0
其中自动释放池做了 “谁创建谁释放” 里面的一部分。
ARC 帮我们做了 “谁创建、谁释放、谁引用、谁管理” 四个部分。
ARC 帮我们写了很多管理内存的代码，包括 autolease、retain、release 等。如果不理解 MRC 下面他们的含义，是不可能理解 iOS 内存管理的。
对于 autolease、autoleasepool、autoleasepoolpage 这些，是自动释放池部分，是 iOS 内存管理的一个面。

在 ARC 下，我们虽然不需要写 retain 和 release，不代表他们不存在了。只是编译器帮我们自动添加了，并且在合适的时间添加的。只有编译器也不行，在运行时也会进行内存的控制。在编译和运行时两方的协调控制下，才做到了引用计数及时 = 0，也只有计数 = 0，内存才正确释放。

ARC 内存不是绝对安全释放的，还牵涉到内存区，如果字符串定义到了堆区，释放是及时的，定义到了栈区和常量区，就不那么及时了（虽然引用计数 = 0，代码也不能在调用，但是真实内存还在）。
而且很可能还会因为代码原因导致引用计数永远不可能为 0，常见的就是循环引用，如 Block 的双向强引用，NSTimer 的双向强引用等等，这里都需要特别的破环。解决双向引用的问题，核心在于破环，只要有一个缺口，内存不可能不释放。
其中循环引用的环的查找，也有不少技巧。核心还是在于通过 runtime 来判断是否是强引用，然后通过广度遍历，来确定环的存在。

深入理解自己生成的对象，自己持有、非自己生成的对象，自己也能持有、不再需要自己持有的对象需要释放、非自己持有的对象无法释放，就能深入理解 iOS 的内存管理。
推荐《Objective-C 高级编程》，更推荐苹果开源的 runtime 源码。

最近一年，试玩了不少几款游戏。
有下载需要付费的，有内购的，也有免费的。有本机的，也有联网的。有养成类的，也有公平平台的。
游戏过程是下载了，试玩了，玩了，卸载了。最后连游戏名字也忘了。
今天，也是在 2018 年的最后一天，开始卸载最后一批游戏。游戏这段旅程，在我的生命里，初步结束了。
昨晚，我刚在一个游戏里面付费了 30 元。接着，我杀死了应用，想着这段时间我的游戏生涯。
我对于游戏，始终有一条清晰的线，沿着这条线，不迷失。也是这条线，让我知道游戏的本质，看清很 low 的游戏也日流水过百万的简单操作下的华丽外衣。