原文链接： http://www.cnblogs.com/lianquan/p/9048233.html 侧链（sidechains）实质上不是特指某个区块链，而是指遵守侧链协议的所有区块链，该词是相对于比特币主链来说的。侧链协议是指可以让比特币安全地从比特币主链转移到其他区块链，又可以从其他区块链安全地返回比特币主链的一种协议。 显然，只需符合侧链协议，所有现存的区块链，如以太坊、莱特币、暗网币等竞争区块链都可以成为侧链。元素链（Elements）就是这样一种侧链。所不同的是，它是由BlockStream公司，即提出侧链协议的公司开发的一个侧链的参考实现。 侧链协议具有重大意义。它意味着比特币不仅可以在比特币区块链上流通，还可以在其他区块链上流通，其应用范围和应用前景会更加广泛；有创意的人们会研发出各种各样的应用以侧链协议与比特币主链对接，使得比特币这种基准自由货币的地位更加牢固。 侧链协议的产生有以下几个原因。 1.应对其他区块链的创新威胁 以太坊（Ethereum）区块链、比特股（Bitshares）区块链后来居上，对比特币区块链产生相当大的威胁。智能合约和各种去中心化应用在以上两个区块链上兴起，受到人们的欢迎。而基于比特币的应用则因为开发难度大，项目不多。 2.比特币核心开发组不欢迎附生链 比特币区块链也有合约币（Counterparty）、万事达币（Mastercoin）和彩色币（ColoredCoin）等附生链，但是比特币核心开发组并不欢迎它们，觉得它们降低了比特币区块链的安全性。他们曾经一度把OP_RETURN的数据区减少到40字节，逼迫合约币开发团队改用其他方式在比特币交易中附带数据。 3.BlockStream商业化考虑 2014年7月以太坊众筹时，获得了价值1.4亿元人民币的比特币，还有20%的以太币，开发团队获得了巨大的回报。但是比特币核心开发组并没有因为他们的辛勤工作获得可观回报，因而他们成立了BlockStream，拟实现商业化价值。 基于以上三个原因，提出侧链协议、把比特币转出比特币区块链、另行开发二代区块链，这样的选择既能保证比特币区块链的安全，又能应对二代币的冲击，还能针对不同应用场景实现商业化，因而成了BlockStream的必然选择。 你或许喜欢这篇文章：区块链工作流程 转载于:https://www.cnblogs.com/lianquan/p/9048233.html

公开密钥体系： 1.确认服务器的身份? 客户机请求通信并传送一明文让服务器加密，服务器用私钥加密后将密文传输给客户机，客户机用公钥对密文进行解密，如解密后的密文和明文不等，则确认不是服务器。（实际上服务器并不对客户机的明文直接加密，因为攻击者可以将有规律的字符串发送给服务器，如服务器对其直接加密返回，会威胁私钥安全，所以服务器在加密时是对明文进行hash计算得出一hash值，将该hash值加密后发送给客户机，客户机用公钥解密得出hash值，再比较是否和自己字符串的hash值相等） 2. 确认客户机的身份? 因为公钥是公开的，任何人都可以对私钥加密后的密文解密，所以不能保证只有授信客户机才能对密文进行解密。 解决方法：1后采用对称密钥体系 客户机传输一加密算法和密钥给服务器，此后双方通信采用对称密钥体系。 3.服务器如何将自己的公钥传递给客户机? 客户机在和服务器通信时，通信内容被截获，由攻击者生成一对公钥和密钥，并将公钥发送给客户机，进而达到伪造服务器的目的。 解决方法：数字证书（CA发布；组织申请；用户安装） 数字证书中有指纹及指纹算法，用以确保数字证书未被篡改。指纹和指纹算法采用CA私钥进行加密，安装在用户电脑中的CA数字证书用公钥进行解密，用解密出的指纹算法计算出数字证书的指纹，比较两指纹是否相等。 4.传输过程中确保密文未被修改? 攻击者无法解密密文，但可以进行篡改，客户和服务器通信需防篡改机制。 解决方法：数字签名 将明文经过hash计算得到一hash值，用私钥将该hash值加密即数字签名，任何数据和私钥组合产生相同数字签名的可能性为0。

路由信息 获取网络路由信息的工具各种各样，本章将介绍几种常见的工具。网络路由信息可以帮助测试人员料及自己的主机到目标主机之间的网络通信路径，进而理解目标主机的网络情况。保护目标主机的防火墙信息，往往也暗藏与路由信息里。 traceroute 通过traceroute我们可以知道信息从你的计算机到互联网另外一端的主机是走什么路径。当然每次数据包由某一同一的出发点（source）到达某一同一的目的地（destination）走的路径可能会不一样，但基本上来说大部分时候所走的路由是相同的。Linux中，我们称之为traceroute，在MS Windows中我们称之为tracert。 Traceroute通过发送小的数据包到目的设备直到其返回，来测量其需要多长的时间。一条路径上的每个设备traceroute要测3次。输出结果中包括每次测试的时间（ms）和设备的名称（如果有的话0）及其IP地址。 Traceroute命令让你追踪网络数据包的路由途径，预设数据包大小是40Byte，用户可以另行设置。。 具体参数格式为： 使用traceroute测试一下Baidu 记录按序列号从1开始，每个纪录就是一跳 ，每跳表示一个网关，我们看到每行有三个时间，单位是 ms，其实就是-q的默认参数。探测数据包向每个网关发送三个数据包后，网关响应后返回的时间；如果您用 traceroute -q 4 www.58.com ，表示向每个网关发送4个数据包。 有时我们traceroute 一台主机时，会看到有一些行是以星号表示的。出现这样的情况，可能是防火墙封掉了ICMP的返回信息，所以我们得不到什么相关的数据包返回数据。 有时我们在某一网关处延时比较长，有可能是某台网关比较阻塞，也可能是物理设备本身的原因。当然如果某台DNS出现问题时，不能解析主机名、域名时，也会 有延时长的现象；您可以加-n 参数来避免DNS解析，以IP格式输出数据。 如果在局域网中的不同网段之间，我们可以通过traceroute 来排查问题所在，是主机的问题还是网关的问题。如果我们通过远程来访问某台服务器遇到问题时，我们用到traceroute 追踪数据包所经过的网关，提交IDC服务商，也有助于解决问题；但目前看来在国内解决这样的问题是比较困难的，就是我们发现问题所在，IDC服务商也不可能帮助我们解决。 跳数设置 格式： traceroute -m 跳数 域名 例如： traceroute其余的参数还是非常多的，作用也较为强大，有兴趣可以自我进行测试学习！ tctrace tctrace也是一个路由信息分析工具，这个程序通过向目标主机发送TCP/SYN数据包来获取相应的信息。 如需要使用tctrace程序，可以在终端使用下述命令： tctrace -i device -d targethost 参数中的device指的是网络接口，targethost指的是被测试的目标主机。 例如测试一下Baidu

2018 Scrapy Environment Enhance(4)Docker Service for Scrapyd and Tor Network Docker Service for Scrapyd http://sillycat.iteye.com/blog/2422861 Docker Service for Tor Network There are 3 ports and 3 different function services. Tor 9051 Port reset IP Tor 9050 Port to proxy Privoxy 8118 to proxy to 9050 I put them into one Docker App, but we should be able to split them into 2 apps. Dockerfile #Run a Tor Network Server

反卷积是指：通过测量输出和已经输入重构未知输入的过程。在神经网络中，反卷积过程并不具备学习的能力，仅仅是用于可视化一个已经训练好的卷积网络模型，没有学习训练的过程。 下图所示为VGG 16反卷积神经网络的结构，展示了一个卷积网络和反卷积网络结合的过程。VGG 16是一个深度神经网络模型。它的反卷积就是将中间的数据，按照前面卷积、池化等变化的过程，完全相反地做一遍，从而得到类似原始输入的数据。 反卷积神经网络的应用场景 由于反卷积网络的特性，导致它有许多特别的应用，一般可以用于信道均衡、图像恢复、语音识别、地震学、无损探伤等未知输入估计和过程辨识方便的问题。 在神经网络的研究中，反卷积更多的是充当可视化作用。对于一个复杂的深度卷积网络，通过每层若干个卷积核的变换，我们无法知道每个卷积核关注的是什么，变换后的特征是什么样子。通过反卷积的还原，可以对这些问题有个清晰的可视化，以各层得到的特征图作为输入，进行反卷积，得到反卷积结果，用以验证显示各层提取到的特征图。 参考： https://www.cnblogs.com/zyly/p/8991412.html

注册CSDN博客已有很长一段时间了,在当初注册的时候就信誓旦旦的想:以后要经常在这上面记录自己学到的新知识,就当是自己是日记本,但事实却是与之相反,以后过了很长时间了,但什么记录都没有,心里有股莫名的烦躁…. 有时候初期的想法很美好,但是到了实施的时候却与之违背,也许这就是一个人的定力和执行力的表现吧. 所以,今天强行给自己定一个目标,保持每周都来写一遍文章,至于文章的类型就随机吧. 虽然说我是一个码农,但大部分时候我又觉得自己不属于一名合格的码农.我上班的性质是一名运维工作者,所以大部分的工作都是跟运维有关,这也是变相的说明了我没写文章的原因吧(这就是阿Q精神吧,或者是给自己找一个借口而已). 有时候也很想给自己定一个目标,然后会沿着这个目标坚持走下去,但每次定了好目标又很难坚持走下去,唉…..这就是一个人不能成功的重要原因之一:没有恒心和执行力. 虽然有很多次的失败,但人都是被逼出来的,到了一定的年纪就会有不同的想法,或许到了我在这个年纪了,就会逼自己了吧. 所以还是跟自己定了一个目标:学习JAVA框架!!!! 希望自己可以持之以恒,坚持下去. 加油,自己鼓励下自己.

前几年360百度腾讯等大佬把用户都养成了使用云盘下载的习惯，但是后期都改为收费服务。 免费的基本也都限速了，弄得大家分享下载一些资源很麻烦。一个VS神马动辄几个GB，百度100k的龟速。 好吧，感谢伟大的github，感谢monkeyWie,为我们提供了proxyee-down。 github地址：https://github.com/monkeyWie/proxyee-down 具体怎么用混CSDN的就不用我教了吧，自己看吧。

电脑配置：i7-8700K 16G 256GSSD＋2T GTX1080Ti 由于要用tf==0.12.1，所以配置的深度学习环境并不是最新的。想安装最新的ＴＦ可以参考此教程 1、win10+Ubuntu16.04双系统，安装教程、补充教程。 2、cuda8.0+cudnn5.1+anaconda 安装教程，建议从作者提供的百度云链接下载，英伟达官网链接有点慢。 注：安装英伟达的驱动，桌面>>系统设置>>软件和更新>>附加驱动>>选择英伟达的驱动。 注：ｃｕｄａ的例子没有下载，所以教程中没有ｍａｋｅ例子。 3、用anaconda安装TF，参照tensorflow官网 conda create -n tensorflow ##后面加 pip python=2.7 (or 3.X) #Activate the conda environment by issuing the following command: source activate tensorflow (tensorflow)$ # Your prompt should change (tensorflow)$ pip install --ignore-installed --upgrade \ tfBinaryURL ##轮子地址 也可以直接 pip install tensorflow-gpu==0.12.1 激活conda环境后，进入python 检验TF和cuda是否安装成功 # Python import tensorflow as tf hello = tf.constant('Hello, TensorFlow!') sess = tf.Session() print(sess.run(hello)) 我的一开始报错， I tensorflow/stream_executor/dso_loader.cc:119]Could’t open CUDA library libcudnn.

原文链接： http://www.cnblogs.com/Anker/p/8998904.html 1、前言 最近在看《云数据中心网络技术》，学习了企业数据中心网络建设过程，看到有ToR和EoR两种布线方式，之前没有接触过，今天总结一下。 2、布线方式 ToR：（Top of Rack）接入方式就是在服务器机柜的最上面安装接入交换机。 EoR：（End of Row）接入交换机集中安装在一列机柜端部的机柜内，通过水平缆线以永久链路方式连接设备柜内的主机/服务器/小型机设备。EoR 对设备机柜需要敷设大量的水平缆线连接到交换机。 3、对比 EOR布线方式的缺点：从服务器机柜到网络机柜的铜缆多(约有20-40根铜缆)，且距网络机柜越远的服务器机柜的铜缆，在机房中的布线距离越长，由此导致线缆管理维护工作量大、灵活性差。 TOR布线的缺点：每个服务器机柜受电源输出功率限制，可部署的服务器数量有限，由此导致机柜内交换机的接入端口利用率不足。在几个服务器机柜间共用1-2台接入交换机，可解决交换机端口利用率不足的问题，但这种方式增加了线缆管理工作量。 从网络设计考虑，TOR布线方式的每台接入交换机上的VLAN量不会很多，在网络规划的时候也要尽量避免使一个VLAN通过汇聚交换机跨多台接入交换机，因此采用TOR布线方式的网络拓扑中，每个VLAN的范围不会太大，包含的端口数量不会太多。但对于EOR布线方式来说，接入交换机的端口密度高，在网路最初设计时，就可能存在包含较多端口数的VLAN。 TOR方式的接入交换机数量多，EOR方式的接入交换机数量少，所以TOR方式的网络设备管理维护工作量大 随着用户数据业务需求的猛增，数据中心机房服务器密度越来越高，虚拟化和云计算等新技术趋势日益流行，使得服务器对应的网络端口大大增加，并且增加了管理的复杂性，另外以太网（LAN）与光纤存储区域网络（SAN）的融合也越来越常见，这就必然要求一种新的网络拓扑结构与之相对应。在云计算的大潮下，这种分布式架构的业务扩展性极强，要求的服务器数量也越来越多。例如新的Apache Hadoop 0.23支持6000~10000台服务器在一个集群内，海量的服务器数量要求充分利用数据中心机柜空间的同时，海量的业务数据也需要更快更直接的高性能链路把数据传送到网络核心。在这样的趋势下，显然ToR更加适用，在业务迅速扩展的压力下，ToR的方式可以更好的实现网络的更快速扩展。 4、参考资料 http://blog.51cto.com/dannyswallow/1731777 http://www.excitingip.com/2802/data-center-network-top-of-rack-tor-vs-end-of-row-eor-design/ http://blog.51cto.com/cteam/674194 转载于:https://www.cnblogs.com/Anker/p/8998904.html