Legendary

k8s学习(二) 基于《Kubernetes in Action》 源码仓库 服务(service): 为一组功能相同的pod提供单一不变的接入点，即服务存在时，它的IP地址和端口不会改变。 一般我们还是采用yaml文件来创建服务，eg: 123456789101112apiVersion: v1kind: Servicemetadata: name: kubiaspec: ports: - port: 80 # 服务的端口 targetPort: 8080 # 转发到容器的端口 selector: app: kubia 可以通过在一个已存在的pod中执行命令来进行测试 kubectl exec [pod_name] -- curl -s ip 指定节点执行curl命令 – ：表示kubectl命令项的结束 -s : 表示需连接不同的API服务器而不是默认的 在spec字段中指定 sessionAffinity: ClientIP 则所有请求会转化到同一个(即一开始确定的那个) 一个服务可以暴露多个端口，但必须给每个端口指定名字。 服 ...

k8s学习(一) 基于《Kubernetes in Action》 源码仓库 集群架构： 控制面板(master) kubernetes API 服务器：负责通信 Scheculer : 调度应用 Controller Manager etcd : 分布式键值数据库 工作节点 容器类型 Kubelet : 与API服务器进行通信，并管理所在节点的容器 kube-proxy : 组件之间的负载均衡网络流量 pods基本操作 创建节点 `kubectl run [name] –image=[容器名] –port=[端口号] 显示信息 kubectl get pods (-o wide) --show-labels : 显示标签 -L [列名1, 列名2...] : 你想看的属性以列展开 kubectl describe pod [pods_name] : 详细信息 端口转发： kubectl port-forward kubia-manual 8888:8080 将机器的本地端口8888转发到kubia-manual pod的端 ...

《比特币：一种点对点的电子现金系统》论文阅读比特币的转移规则： 比如说一笔交易记录：张三发给李四5个比特币。 发送者（张三）要做的事情是：把这条交易信息和目标地址（李四的公钥）做个HSAH，然后用自己的私钥进行数字签名（即用张三的私钥加密这个哈希值），同时将这个数字签名附到这笔Tx（交易）里，然后通过p2p技术发送给李四。 李四收到这条消息后怎么做：拿着这笔交易里公布的张三的公钥来验证数据（公钥解密）得到哈希值x，同时，用自己的公钥和交易信息做哈希得到hash(data)，然后对比x=hash(data)，则可以判断出这笔交易来自于张三。因为公钥验证出的哈希值只有私钥才能生成，而拿张三的公钥验证的，必然是张三的私钥，私钥只会存在张三那里，抵赖是抵赖不掉的。这里就用到来非对称加密，私钥数字签名，公钥验证数据。公钥确定钱包地址，私钥确定所有权。

HTTPS 超文本传输安全协议(HTTP OVER SSL)，HTTPS经由超文本传输协议（HTTP）进行通信，但利用SSL/TLS来加密数据包。占用443端口通讯 握手过程： 浏览器为client, 网站为server。 浏览器发送自己支持的算法列表和加密规则 网站从算法加密规则中选取一个，将身份信息以证书(CA)形式发回，证书包含网站地址，加密公钥，证书颁发机构，同时自身生成私钥 浏览器获得网站的证书，要做以下操作： 验证证书合法性，从根CA一直验证到具体颁发的SSL证书，即类似于自顶向下遍历一条路径，如果受信任，则浏览器栏会显示一个锁头，否则提示不信任 浏览器生成随机密钥(用于之后的对称加密)，用网站发来的公钥加密 用约定好的hash算法计算握手消息，然后用对称密钥对消息进行加密，再将所有的信息发送 网站接收到后，用私钥解密出对称密钥，然后用密钥解密出握手消息，比于浏览器端发来的hash值进行比对。之后再用密钥加密握手消息发回 浏览器解密该握手消息，并判断是否与网站发来的hash值一致，如果是，则握手结束，对称密钥通过非对称加密传输完毕，之后所以的通信都 ...

区块链基础概念–比特币运行机制基于《区块链-技术驱动金融》一书 比特币交易： 地址转换：一个交易中输出的币，要么在另一个交易中被完全消费掉，要么就一个都不被消费。所以需要自身将剩余的币转给自己所有的另一个地址 有效验证： 从所引用的交易开始验证到最新一次的交易，而不需要从头开始 资金合并： 发起一个交易，交易里有两个输入和一个输出，输出的地址是自己的地址 共同支付：交易中同样包含两个输入和一个输出，两个输入的hash指针不同，因此这笔交易需要支付者两人的签名 ScriptSig(输入脚本): 指定了对应公钥的签名 ScriptPubkey(输出脚本): 指定了公钥或是公钥哈希值的地址 交易输出： 凭借哈希值为X的公钥，以及这个公钥所有者的签名，才可以获得这笔资金。 判断一个交易是否有效，需要我们把输入、输出脚本串联起来形成串联脚本： 比特币的脚本语言不是图灵完备的，而是堆栈式的。 数据指令：把数据推到堆栈的最上面 工作码指令：用堆栈顶部的数据作为输入值，用来计算一个函数 从指定公钥到指定脚本(方式) 第三方交易： 指定 MULTISI ...

Docker入门基于docker中文文档 Docker是一个开源的引擎，可以轻松的为任何应用创建一个轻量级的、可移植的、自给自足的容器。Docker 项目的目标是实现轻量级的操作系统虚拟化解决方案。容器是在操作系统层面上实现虚拟化，直接复用本地主机的操作系统，而传统方式则是在硬件层面实现。 docker的整个生命周期有三部分组成：镜像（image）+容器（container）+仓库（repository）。容器是由镜像实例化而来。镜像是文件，容器是进程。容器是基于镜像创建的，即容器中的进程依赖于镜像中的文件。 Docker进程认为整个文件系统是以读写方式挂载的。 但是所有的变更都发生顶层的可写层，而下层的原始的只读镜像文件并未变化。由于镜像不 可写，所以镜像是无状态的。 父镜像：一个镜像可能会依赖于一个或多个下层的镜像，则此时下层镜像为上面的父镜像。 镜像ID: 64位16进制值(256位)标识，前12个字符为简化使用的短标识。 *注意一个镜像不能超过 127 层 Docker 操作 获取镜像： sudo docker pull xxx 可 ...

区块链基础概念–去中心化基于《区块链-技术驱动金融》一书 首先是几个问题： 1.谁在维护交易账本？2.谁有权利批准哪个交易是正当有效的？3.谁在制造新的比特币？4.谁在制定系统变化规则？5.比特币是如何取得交易价值的？ 分布式共识(distributed consensus) 在一个有n个节点的系统中，每一个节点都有一个输入值，其中一些节点具有故障，甚至是恶意的。一个分布式共识协议有以下两个属性： 输入值的中止须经所有诚实节点来确定。 这个输入值必须由诚实节点来生成。 比特币协议达成共识的两大障碍： 信息延迟和节点死机 恶意节点 隐形共识： 共识算法(PoW)： 新的交易被广播到所有节点上。 每个节点都将新的交易放进一个区块。 在每个回合，一个随机的节点可以广播它的区块。 其他节点可以选择接受这个区块，前提是如果区块里的交易都是正当的（有真的签名）。 节点们可以把以上区块的哈希值放进自己的区块里，以此来表示它们对那个新区块的认可。 基于该共识算法被认为是安全的。 窃取攻击：基于签名算法的安全性 拒绝服务攻击：攻击者不把被攻击者的任何交易放进其提议的区块中 ...

区块链基础概念–加密货币基于《区块链-技术驱动金融》一书 看到一个为什么会出现“挖矿”的概述： 要想创造一种自由浮动并且具有真实价值的虚拟货币，必须要设计出某种具有稀缺性的东西。其实，正是因为黄金和钻石的稀缺性，它们才会成为货币的储备。在虚拟世界，你可以这样设计你的系统，即虚拟货币只有在需要花一段时间解决了一定的数学计算（或“谜题”）之后方可生成，这样就保证了稀缺性。比特币体系中的“挖矿”就是这样的 密码学hash函数 总体需要满足的三个特性是： 输入长度不限 输出长度固定 有效时间计算，即对n长字符串，hash函数计算的复杂度为O(n) 而要使加密的hash函数足够安全，则有需要满足以下要求： 碰撞阻力 即无法找到x,y,其中x≠y,但H(x)=H(y)。注意的无法找到，并不意味着不存在，有鸽巢原理易得。还比如生日悖论，对于完全随机的个体，只需23个人，则至少有1/2的概率会出现生日在同一天的情况。 “我们实践中依赖的加密的哈希函数仅仅是人们经过不懈努力之后暂未成功找到碰撞的函数” 应用：信息摘要 message digest 隐秘性 在 ...

DNS主机名到IP地址(路由器偏好)转换的目录服务。 用户主机发送HTTP请求到Web服务器 www.example.com ，需要知道其对应的IP地址，具体操作为： 该主机为DNS应用客户端 浏览器从url中抽取主机名，返回给客户端 客户端向DNS服务器发送一个包含主机名的请求 客户端收到响应报文(包含对应主机名的IP地址) 浏览器接受到DNS的IP地址后，可以向该IP地址80端口的HTTP进程发起TCP连接 ## 分布式，层次数据库 具有DNS缓存机制 从上至下依次分为： 根DNS服务器 顶级域服务器 TLD (eg: com edu org net) 权威DNS服务器 (本地DNS服务器 ## 资源记录- RR 格式为4元组：(Name, Value, Type, TTL)其中TTL表示记录的生存时间，同时决定了资源记录应当从缓存中删除的时间。Type决定Name和Value，具体含义可以查。 报文 图示： head (前12字节): 标识符（报文id） 标志字段。 问题计数：DNS 查询请求的数目。 回答资源记录数：DNS 响应的数目。 权威名称服务 ...

GRPC首先摘抄一下对rpc(远程过程调用)协议实现的思考，从下面这段话也可以看出，为什么要用ProtoBuf编码了。 首先，要解决通讯的问题，主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。 第二，要解决寻址的问题，也就是说，A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称名称是什么，这样才能完成调用。比如基于Web服务协议栈的RPC，就要提供一个endpoint URI，或者是从UDDI服务上查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。 第三，当A服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如TCP传递到B服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组（marshal），通过寻址和传输将序列化的二进制发送给B服务器。 第四，B服务器收到请求后，需要对参数进行反序 ...