一个工匠

杭州的云服务建设的非常快。
下图中白云的后面就有非常强大的软硬件储备，撑起了几乎整个中国互联网的基础建设。

与微软亚马逊等科技公司不同，国外巨头一般把服务器存放在大海里，方便散热降低能耗。

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 有一个非常重要的大杀器，就是做负载均衡。

1.开发同学一定要了解字符集和编码。
2.没有 “Unicode 编码” 一说， Unicode 不是编码，是标准。
3.认识字符、字节、字符集、编码的区别，如果不理解，不要胡诌乱造以讹传讹，对别人影响很大。

假设你已经查阅了很多关于 Unicode 、UTF8 等之间的关系，并且有了很好的认知。毕竟这博客太低微了，能找到并打开这个链接，那肯定都是看过十几个其他博文的解读了。
本篇博文重点描述编码认知过程中的几个坑点，这个很重要。

对 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 的一个终端，用来实现双向绑定。