WIN2000分布式服务笔记

数据完整性:不可修改       数据私有性:不可阅读

数据变换形式需要密钥(key)

私钥(对称、单、共享)       公钥(非对称、双)

分布式服务必然要有分布式安全

WIN2000内置有NTLM、SSL、Kerberos三种,其中Kerberos是核心

NTLM(NT LAN Manager) WIN NT时代使用

SSL(Secure Sockets Layer),由Netscape创建的Internet标准协议

TLS(Transport Layer Security)是SSL的一个版本,被IETF标准化

Kerberos是MIT创建的,一般使用私钥,它提供了认证、数据完整性、数据私有性的保证。但是Win2000提供了更新版本,让用户可以使用公钥登录系统。为了提供这些服务,它一定要用到Active Directory数据库,和AD紧密结合

KDC(Key Distribution Center)分发特定服务器应用的ticket(有效期只有几小时)

SSL用私钥提供数据完整性、数据私有性,但是必需通过公钥来提供认证服务,具体就是证书+数字签名

PKI(Public Key Infrastructure)公钥基础设施

COM(Component Object Model)组件对象模型 DCOM

时间: 2024-08-29 07:42:56

WIN2000分布式服务笔记的相关文章

WIN2000分布式服务(第二章)

目录服务:数据库+如何访问数据的协议 WIN2000包含两个不同的目录服务:DNS和LDAP DNS(Domain Name System)域名系统,基本功能就是把域名映射为机器的IP地址 A记录 MX记录 LDAP(Lightweight Diretctory Acess Protocol)轻型目录访问协议,来自IETF的X.500,只能建立在TCP/IP协议上 DNS和LDAP是互补的作用 而WIN2000中对原来的DNS协议做了一些改变或改良,增加了SRV记录.动态DNS等. 动态DNS扩

分布式服务框架学习笔记1 应用架构演进

传统垂直应用架构 业界曾比较流行的有: LAMP架构:Linux+Apache+PHP(前后端分离)+MySQL(读写分离) MVC架构:Spring+Struts+iBatis/Hibernate+Tomcat 在高并发.大流量的应用场景中,需要做集群,通常的组网方案是前端通过F5等负载均衡器做七层负载均衡(或者使用SLB等软负载),后端做对等集群部署. 随着业务的不断发展,应用规模日趋庞大,传统垂直架构开发模式的弊端变得越来越突出.这就需要将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服

<分布式服务框架原理与实践>读书笔记1

花了一段时间通读了<分布式服务框架原理与实践>.个人感触,所讲内容虽然不是实战级别,但可以从侧面领略"分布式服务"的魅力和要点. 1.<第一章 应用架构演进> 主要介绍了4个应用架构,这也基本上算是一个企业场景的严谨模式. 重要的是要理解SOA的设计原则.其中服务治理内容,可以作为研究DUBBO的理论储备. 2.第二章 分布式服务框架入门 实现思路上,课采用责任链,实现功能的动态扩展.该思想和Tomcat pipline,spring aop,intercept

&lt;分布式服务框架原理与实践&gt;读书笔记2

继续阅读<分布式服务框架原理与实践> 第六章 服务路由 6.1 透明化路由 路由,可以联想下路由器,比如通过浏览器要访问某个网站,中间会经过很多路由器,但这些信息对用户来说,没有实际意义,我们只关注"是否可以上网"即可. 透明化路由的实现一般采用[注册中心] 6.2 负载均衡 消费者调用服务者提供的服务,规则包括: 随机:2.轮询:3.服务调用时延(权重):4.一致性哈希:5.粘滞连接. 熟悉nginx的,基本也是包括这些规则,原理都是相通的. 6.3 本地路由优先,可以降

【转】Dubbo是Alibaba开源的分布式服务框架

Dubbo是Alibaba开源的分布式服务框架,它最大的特点是按照分层的方式来架构,使用这种方式可以使各个层之间解耦合(或者最大限度地松耦合).从服务模型的角度来看,Dubbo采用的是一种非常简单的模型,要么是提供方提供服务,要么是消费方消费服务,所以基于这一点可以抽象出服务提供方(Provider)和服务消费方(Consumer)两个角色.关于注册中心.协议支持.服务监控等内容,详见后面描述. 总体架构 Dubbo的总体架构,如图所示: Dubbo框架设计一共划分了10个层,而最上面的Serv

浅谈分布式服务协调技术 Zookeeper

Google的三篇论文影响了很多很多人,也影响了很多很多系统.这三篇论文一直是分布式领域传阅的经典.根据MapReduce,于是我们有了Hadoop:根据GFS,于是我们有了HDFS:根据BigTable,于是我们有了HBase.而在这三篇论文里都提及Google的一个Lock Service -- Chubby,哦,于是我们有了Zookeeper. 随着大数据的火热,Hxx们已经变得耳熟能详,现在作为一个开发人员如果都不知道这几个名词出门都好像不好意思跟人打招呼.但实际上对我们这些非大数据开发

分布式服务框架Dubbo

随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进. 单一应用架构 当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本. 此时,用于简化增删改查工作量的 数据访问框架(ORM) 是关键. 垂直应用架构  当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率. 此时,用于加速前端页面开发的 Web框架(MVC) 是关键. 分布式服

分布式服务框架 Zookeeper -- 管理分布式环境中的数据

安装和配置详解 Zookeeper 分布式服务框架是 Apache Hadoop 的一个子项目,它主要是用来解决分布式应用中经常遇到的一些数据管理问题,如:统一命名服务.状态同步服务.集群管理.分布式应用配置项的管理等.本文将 从使用者角度详细介绍 Zookeeper 的安装和配置文件中各个配置项的意义,以及分析 Zookeeper 的典型的应用场景(配置文件的管理.集群管理.同步锁.Leader 选举.队列管理等),用 Java 实现它们并给出示例代码. 单机模式 单 机安装非常简单,只要获取

分布式服务框架下,如何做到服务化最佳实践?

“升级服务框架后,性能.可靠性等问题日益明显.服务化之后面临的诸多挑战,怎样分析才能给出实践最优解? 在服务化之前,业务通常都是本地API调用,本地方法调用性能损耗较小.服务化之后,服务提供者和消费者之间采用远程网络通信,增加了额外的性能损耗,业务调用的时延将增大,同时由于网络闪断等原因,分布式调用失败的风险也增大.如果服务框架没有足够的容错能力,业务失败率将会大幅提升. 除了性能.可靠性等问题,跨节点的事务一致性问题.分布式调用带来的故障定界困难.海量微服务运维成本增加等也是分布式服务框架必须