网络模型

仅作学习使用 Fashion MNIST 数据集，其中包含 70,000 张灰阶图像。 我们使用了其中的 60,000 张图像训练网络，并使用剩余的 10,000 张测试网络效果。 为了将这些图像提供给神经网络，我们需要将 28 × 28 图像扁平化为有 784 个元素的一维向量。 我们的网络包括一个全连接层，其中有 128 个单元（神经元）；以及一个输出层，其中有 10 个单元，对应于 10 个输出标签。这 10 个输出表示每个类别的概率。我们使用 softmax 激活函数计算概率分布。 来源： https://www.cnblogs.com/xuehuiping/p/11636474.html

OSI七层模型介绍 ： OSI参考模型其实就是讨论通信问题，所不同其针对的是计算机通过网线或无线网去通信。为了容易理解，首先用一个例子来形容： 我写一封信给朋友，首先，是我写信，讲往事如风，说我们两个人之间的老故事，这些东西只要我两之间懂就OK了。好写完后，我就寄信去了。。具体的寄信跑腿等工作，则属于下一层了。那么下一层是谁呢？对，邮政局。邮政局把信纸装进固定格式的信封中，信封上有固定格式的要求。那么邮政局不需要知道信到底写了什么，他们不关心，只管捯饬信封就可以，让对方拿到信封后知道那是给我朋友的就OK了。好，这个层次结束。。那么是不是没其他层次了呢？？错，还有一个层次，那就是最底层。邮递员层。。他们负责跑腿，例如骑马，骑车或者开火车开飞机，随便，反正是具体的跑腿工作。。。好，回过头来看，写一封信进行通信，分了三个层次：我和朋友，属于用户层，负责信内容的书写和阅读；邮政局，属于类似于OSI的运输层，负责信封的格式书写和阅读。。邮递员，最底层，类似于OSI的物理层，负责具体的传输方式。 好，回到OSI，这个以计算机为原始设备的通信模型，考虑的要复杂一些而已，分成了7个层次。最底层，物理层:负责具体的传输媒介以及其对应的传输方式，解决的问题是实现比特流的传输。数据链路层：负责相邻两个节点间比特流的识别，即以字节为单位去找出“每页信纸”。网络层：实现网络中任意两个节点间的连通和数据转发。

OSI七层模型图 从图中我们已经了解到OSI七层分为：物理层；数据连接层；网络层；传输层；会话层；表示层；应用层。 OSI七层各层的讲解： 1.物理层： 在OSI参考模型中，物理层（Physical Layer）是参考模型的最低层，也是OSI模型的第一层。 物理层的主要功能是：利用传输介质为数据链路层提供物理连接，实现比特流的透明传输。 物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。使其上面的数据链路层不必考虑网络的具体传输介质是什么。“透明传送比特流”表示经实际电路传送后的比特流没有发生变化，对传送的比特流来说，这个电路好像是看不见的。 设备：网卡，网线，集线器，中继器，调制解调器 2.数据链路层： 数据链路层（Data Link Layer）是OSI模型的第二层，负责建立和管理节点间的链路。该层的主要功能是：通过各种控制协议，将有差错的物理信道变为无差错的、能可靠传输数据帧的数据链路。 在计算机网络中由于各种干扰的存在，物理链路是不可靠的。因此，这一层的主要功能是在物理层提供的比特流的基础上，通过差错控制、流量控制方法，使有差错的物理线路变为无差错的数据链路，即提供可靠的通过物理介质传输数据的方法。 该层通常又被分为介质访问控制（MAC）和逻辑链路控制（LLC）两个子层。

1. C/C++ 与 Go语言的“价值观”对照 之前看过 白明老师 在GopherChina2017的一篇演讲文章 《Go coding in go way》 ，里面提到C/C++/Go三门语言价值观，感觉很有意思，分享给大家感受一下： C的价值观摘录 相信程序员：提供指针和指针运算，让C程序员天马行空的发挥 自己动手，丰衣足食：提供一个很小的标准库，其余的让程序员自造 保持语言的短小和简单 性能优先 C++价值观摘录 支持多范式，不强迫程序员使用某个特定的范式 不求完美，但求实用（并且立即可用） Go价值观 Overall Simplicity 全面的简单 Orthogonal Composition 正交组合 Preference in Concurrency 偏好并发 用一句话概括Go的价值观： Go is about orthogonal composition of simple concepts with preference in concurrency(Go是在偏好并发的环境下的简单概念/事物的正交组合). 从Go的价值观介绍可以看出 Go很适合并发编程，可以说其是为并发而生的一门语言，那它的并发机制如何？这正是这篇文章想要介绍的。 2. 从线程实现模型说起 线程的实现模型主要有3种： 内核级线程模型、用户级线程模型和混合型线程模型

论文标题：Siamese Neural Networks for One-shot Image Recognition 论文作者： Gregory Koch Richard Zemel Ruslan Salakhutdinov 论文地址： https://www.cs.cmu.edu/~rsalakhu/papers/oneshot1.pdf 声明：小编翻译论文仅为学习，如有侵权请联系小编删除博文，谢谢！ 小编是一个机器学习初学者，打算认真研究论文，但是英文水平有限，所以论文翻译中用到了Google，并自己逐句检查过，但还是会有显得晦涩的地方，如有语法/专业名词翻译错误，还请见谅，并欢迎及时指出。 摘要 　　为机器学习应用程序学习一个好的特征的过程可能在计算上非常昂贵，并且在数据很少的情况下可能会变得困难。一个典型的例子就是一次学习设置，在这种情况下，我们必须仅给出每个新类的一个示例，就可以正确的做出预测。在本文中，我们探索了一种学习孪生神经网络的方法，该方法采用独特的结构自然对输入之间的相似性进行排名。一旦网络被调整好，我们就可以利用强大的判别功能，将网络的预测能力不仅用于新数据，而且适用于未知分布中的全新类别。使用卷积架构，我们可以在单次分类任务上获得近乎最先进的性能，从而超过其他深度学习模型的强大结果。 　　人类展现出强大的获取和识别新模式的能力。特别是，我们观察到

指针生成网络(Pointer-Generator-Network)原理与实战 阅读目录 0 前言 1 Baseline sequence-to-sequence 2 Pointer-Generator-Network 3 Coverage mechanism 4 实战部分 4.1 DataSet 4.2 Experiments 4.3 Evaluation 4.4 Results 5 References 回到顶部 0 前言 本文主要内容：介绍 Pointer-Generator-Network在文本摘要任务中的背景 ， 模型架构与原理 、 在中英文数据集上实战效果与评估， 最后得出结论 。参考的 《Get To The Point: Summarization with Pointer-Generator Networks》 以及多篇博客均在文末给出连接，文中 使用数据集已上传百度网盘 ， 代码已传至 GitHub ，读者可以在 文中找到相应连接 ，实际操作过程中确实遇到很多坑，并未在文中一一指明，有兴趣的读者可以留言一起交流。由于水平有限，请读者多多指正。 　　随着互联网飞速发展，产生了越来越多的文本数据，文本信息过载问题日益严重，对各类文本进行一个“降 维”处理显得非常必要，文本摘要便是其中一个重要的手段。文本摘要旨在将文本或文本集合转换为包含关键信息的简短摘要

摘要：很多人喜欢把RocketMQ与 Kafka 做对比，其实这两款消息队列的网络通信层还是比较相似的，本文就为大家简要地介绍下Kafka的NIO网络通信模型，通过对Kafka源码的分析来简述其Reactor的多线程网络通信模型和总体框架结构，同时简要介绍Kafka网络通信层的设计与具体实现。 一、Kafka网络通信模型的整体框架概述 Kafka的网络通信模型是基于NIO的Reactor多线程模型来设计的。这里先引用Kafka源码中注释的一段话： 相信大家看了上面的这段引文注释后，大致可以了解到Kafka的网络通信层模型，主要采用了 1（1个Acceptor线程）+N（N个Processor线程）+M（M个业务处理线程） 。下面的表格简要的列举了下（这里先简单的看下后面还会详细说明）： 线程数线程名线程具体说明1kafka-socket-acceptor_%xAcceptor线程，负责监听Client端发起的请求Nkafka-network-thread_%dProcessor线程，负责对Socket进行读写Mkafka-request-handler-_%dWorker线程，处理具体的业务逻辑并生成Response返回 Kafka网络通信层的完整框架图如下图所示： Kafka消息队列的通信层模型—1+N+M模型.png 刚开始看到上面的这个框架图可能会有一些不太理解，并不要紧

目录 写在前面 背景 现有的问题 定义 优势 挑战 可编程性 命名规则 数据抽象 服务管理 数据隐私保护及安全 理论基础 商业模型 相关研究 总结 参考 写在前面 本文是阅读论文《边缘计算：万物互联时代新型计算模型》的笔记。 背景 目前，大数据处理已经从以云计算为中心的集中式处理时代（把2005-2015年称之为集中式大数据处理时代）正在跨入以万物互联为核心的边缘计算时代（称之为边缘式大数据处理时代）。集中式大数据处理时代，更多的是集中式存储和处理大数据，其采取的方式是建造云计算中心，并利用云计算中心超强的计算能力来集中式解决计算和存储问题。相比而言，在边缘式大数据处理时代，网络边缘设备会产生海量实时数据；并且，这些边缘设备将部署支持实时数据处理的边缘计算平台为用户提供大量服务或功能接口，用户可通过调用这些接口来获取所需的边缘计算服务。 现有的问题 随着 物联网（Internet of things, IoT） 的快速发展和4G/5G无线网络的普及， 万物互联(Internet of everything, IoE) 的时代已经到来，网络边缘设备数量的迅速增加，使得该类设备所产生的数据已达到泽字节（ZB）级别。以云计算模型为核心的集中式大数据处理时代，其关键技术已经不能高效处理边缘设备所产生的数据。主要存在以下四个问题： 线性增长的集中云计算能力无法匹配爆炸式增长的海量边缘数据；

Docker容器技术基于Linux Container实现的。在Linux Container中，包含用于隔离进程的Namespaces。在众多Namespace技术里，存在一个Network Namespace，每个被Network Namespace隔离的空间都拥有自己的网络设备、IP地址、路由表、防火墙、网络配置、端口表等，Docker正是借助这个东西实现了对容器网络的隔离。 那么具体实现呢： Namespace仅仅实现了网络的隔离，然而我们容器是需要与外界进行信息交流的。那么就由此出现了 虚拟网卡 veth-pair设备，这个设备是个虚拟网络通道，并且是成对出现的，用于连接两个网络终端： 但是我们宿主机运行的不止一个容器，要实现众多容器之间的通信，就要利用Bridge，网桥。Docker利用Bridge把veth-pair设备的一端全部连接在Bridge所构成的交换机中，把容器连接不同外部网络的任务通过veth-pair转移到了Bridge上。 默认Docker会创建一个docker0的虚拟网桥，连接在同一个网桥上的容器可以互相通信。通过ifconfig命令查看 当启动容器，宿主机执行ifconfig会成对出现veth*： 总结一下： Network Namespace ：实现了网络资源的隔离。 Veth Pair ：打通了网络隔离环境的数据传输通道。在Docker中

最近略有闲暇时间，于是对Redis进行了一些学习，学习途径除了官方文档还有Redis源代码，我看的版本是2.8.13，Redis源码总行数不到5W行，不同组件拆分非常细致，阅读起来也很清晰。这篇博客主要介绍我对Redis网络层架构以及线程模型的一些了解，希望能对大家有所帮助。 Redis网络基础架构 网络编程离不开Socket，网络I/O模型最常用的无非是同步阻塞、同步非阻塞、异步阻塞、异步非阻塞，高性能网络服务器最常见的线程模型也就是基于EventLoop模式的单线程模型。我们看看Redis的网络架构是怎么样的： Redis基础组建结构 这里解释下上图涉及的组件，Redis网络层基础组件主要包括四个部分： EventLoop事件轮训器，这部分实现在AE里面。 提供Socket句柄事件的多路复用器，这部分分别对于不同平台提供了不同的实现，比如epoll和select可以用于linux平台、kqueue可以用于苹果平台、evpoll可以用于Solaris平台，这里并没有看到iocp，也就是Redis对于Windows支持并不是很好。 包括网络事件处理器实现的networking，这部分主要包括两个重要的今天要讲的事件处理器：acceptTcpHandler和acceptCommonHandler。 处理网络比较底层的部分，比如网络句柄创建、网络的读写等。 Redis单线程模型