- 浏览: 1841220 次
- 性别:
- 来自: 深圳
文章分类
- 全部博客 (665)
- 闲话 (17)
- ruby (1)
- javascript (40)
- linux (7)
- android (22)
- 开发过程 (11)
- 哥也读读源代码 (13)
- JVM (1)
- ant (2)
- Hibernate (3)
- jboss (3)
- web service (17)
- https (4)
- java基础 (17)
- spring (7)
- servlet (3)
- 杂记 (39)
- struts2 (10)
- logback (4)
- 多线程 (2)
- 系统诊断 (9)
- UI (4)
- json (2)
- Java EE (7)
- eclipse相关 (4)
- JMS (1)
- maven (19)
- 版本管理 (7)
- sso (1)
- ci (1)
- 设计 (18)
- 戒烟 (4)
- http (9)
- 计划 (4)
- HTML5 (3)
- chrome extensions (5)
- tomcat源码阅读 (4)
- httpd (5)
- MongoDB (3)
- node (2)
最新评论
-
levin_china:
勾选了,还是找不到
用spring annotation声明的bean,当打包在jar中时,无法被扫描到 -
GGGGeek:
我用的maven-3.5.0,还没有遇到这种情况,使用jar ...
用spring annotation声明的bean,当打包在jar中时,无法被扫描到 -
GGGGeek:
受益匪浅,从组织项目结构,到技术细节,讲的很到位,只是博主不再 ...
一个多maven项目聚合的实例 -
Aaron-Joe-William:
<?xml version="1.0" ...
hibernate逆向工程 -
li272355201:
http://archive.apache.org/dist/ ...
tomcat源码阅读(一)——环境搭建
最近半个月,把《计算机网络》看完了
看完主要有一个疑问,就是发现TCP/IP模型中,各层的职责虽然划分得很明确,但是实际的实现中(各种协议),其实存在垮层依赖的现象。比如说,在应用层为了与另一台主机中的进程通信,既需要了解传输层的端口号(TCP),又需要了解网络层的主机地址(IP)
这个疑问也不知道该去问谁,所以就到stackoverflow上发帖问了国际友人。问答的原文贴下:http://stackoverflow.com/questions/18002775/layer-dependence-about-network
i have a question about network layer, that is:
as we all know, in layer architecture, the N+2 layer should only depends on the N+1 layer, while knows nothing about N layer. for example, in a typical application, the web layer should only depends on the business logic layer, but not the data access layer
when it comes to computer network, things seem to be different. In application layer, program has to know not only transmition layer(TCP port), but also network layer(IP address)
this confuse me, what do you think about this?
thanks for your help.
generally you are right. Unfortunately borders between layers in networks are kinda blurry, not just because we have a standard which is not used (OSI) and de facto standard which does not enforce the idea you mentioned, but also because the protocols are often not strictly bound to one layer but can do stuff on more then one of them. Good amount of protocols is developed before the OSI model and before they were standardized and then it was already too late to make some radical changes. So there are protocols that are considered to be between two layers (or on both layers) like MPLS, ARP etc. And protocols that are based on another protocol which is on the same layer, like OSPF that runs on top of IP even if they are considered to be on L3.
What you mentioned is another example. The reason for that is that addressing is not done on the most-upper layer (application layer) but on network layer (for host/network adapter) and transport layer (for process/application). So you need to know the IP address and port number (and actually a protocol) to be able to address the remote application. That's where the network sockets come in as an gateway (or API) between application and the network. So, even if you are technically correct about defying the principle of layered model, you are not really doing anything on L3 or L4 (but you can;) ). You don't need to fragment packets, handle retransmissions or worry about error corrections etc., you are just passing down the required addressing information when creating a socket.
TCP/IP is more oriented towards the feasibility of implementation, where OSI is more concerned about the standard then the implementation of that standard. This has it's bad and good sides. The ability to freely implement the protocol can be an advantage if you use that power well and since you are not strictly bound to some specification you can do some things more efficiently... or fail epically. The drawbacks of mixing 'responsibilities' are obvious and great example are protocols like H.323 which embed the IP addresses inside user's payload so if you want to do NAT for example you need to inspect the payload, change IP addresses, recalculate checksums, and stuff like that instead of just handling the translation on network layer.
Why are stuff still like this? Probably because there is no easy way to change any of that because of sheer number of devices and protocols, applications, etc that needs to be updated and this takes a lot of time. Just look at the speed of adopting IPv6 which has been around for more then 15 years.
最主要的原因是,如今用到的大部分的实现,都是在标准制定之前开发的。在标准制定之后,这些协议已经被广泛地应用了,仅仅为了符合标准,而去做大面积的修改,实际上是非常困难的
联想到应用开发,一般也有明确的分层。包括几个原则:
1、依赖接口,不依赖实现
2、下层不可依赖上层
3、N+1层仅依赖N层,不跨层依赖
现在感觉,真正重要的其实是划分每层的职责,以及确定服务的接口。然后第一个和第二个原则是必须遵守的。而是否允许跨层依赖,以及是否允许同一层依赖,要看具体的情况,不需要太纠结
比如在business logic这层,可能存在很多业务逻辑组件,是否应该允许它们之间互相调用呢?理论上说,不互相调用当然是最好的,但是实践中会发现保持这个约束很难。在必要的时候,互相调用也没关系,但是同样应该依赖接口,而不能依赖具体的实现。分层不是根据调用的次数来划分的,并不是说存在3次接口调用,就一定代表架构里有4层。分层本身就是逻辑上的,所以应该看提供的服务是否是在一个层面上
另外在网络安全那一章,谈到了authentication(认证)和authorization(授权)的区别
一般的权限控制这2个部分都会涉及。简言之,校验用户身份是否正确,是authentication,而判断用户能做什么事,则是authorization
比如一个进程声称来自用户alice,要删除文件xxx.old。那么对于文件服务器来说,判断该进程是否属于alice属于认证,判断是否有权限删除文件属于授权
对于加密算法,有一个Kerckhoff原则。即算法本身必须是公开的,加密的只是密钥。如果算法和密钥都是公开的,那就不能算加密(ciper)了,只能算编码(encode),比如Base64算法,就不能算一种加密算法
另外看到一种典型的组网模式,在内网和DMZ区域之间,用防火墙隔离。外部用户可以直接访问到DMZ区域中的服务器,但是不能直接访问内网。联系我们的系统,反向代理是放在DMZ区域的,而应用和数据库服务器,都在内网里,中间用防火墙隔离
看完主要有一个疑问,就是发现TCP/IP模型中,各层的职责虽然划分得很明确,但是实际的实现中(各种协议),其实存在垮层依赖的现象。比如说,在应用层为了与另一台主机中的进程通信,既需要了解传输层的端口号(TCP),又需要了解网络层的主机地址(IP)
这个疑问也不知道该去问谁,所以就到stackoverflow上发帖问了国际友人。问答的原文贴下:http://stackoverflow.com/questions/18002775/layer-dependence-about-network
引用
i have a question about network layer, that is:
as we all know, in layer architecture, the N+2 layer should only depends on the N+1 layer, while knows nothing about N layer. for example, in a typical application, the web layer should only depends on the business logic layer, but not the data access layer
when it comes to computer network, things seem to be different. In application layer, program has to know not only transmition layer(TCP port), but also network layer(IP address)
this confuse me, what do you think about this?
thanks for your help.
引用
generally you are right. Unfortunately borders between layers in networks are kinda blurry, not just because we have a standard which is not used (OSI) and de facto standard which does not enforce the idea you mentioned, but also because the protocols are often not strictly bound to one layer but can do stuff on more then one of them. Good amount of protocols is developed before the OSI model and before they were standardized and then it was already too late to make some radical changes. So there are protocols that are considered to be between two layers (or on both layers) like MPLS, ARP etc. And protocols that are based on another protocol which is on the same layer, like OSPF that runs on top of IP even if they are considered to be on L3.
What you mentioned is another example. The reason for that is that addressing is not done on the most-upper layer (application layer) but on network layer (for host/network adapter) and transport layer (for process/application). So you need to know the IP address and port number (and actually a protocol) to be able to address the remote application. That's where the network sockets come in as an gateway (or API) between application and the network. So, even if you are technically correct about defying the principle of layered model, you are not really doing anything on L3 or L4 (but you can;) ). You don't need to fragment packets, handle retransmissions or worry about error corrections etc., you are just passing down the required addressing information when creating a socket.
TCP/IP is more oriented towards the feasibility of implementation, where OSI is more concerned about the standard then the implementation of that standard. This has it's bad and good sides. The ability to freely implement the protocol can be an advantage if you use that power well and since you are not strictly bound to some specification you can do some things more efficiently... or fail epically. The drawbacks of mixing 'responsibilities' are obvious and great example are protocols like H.323 which embed the IP addresses inside user's payload so if you want to do NAT for example you need to inspect the payload, change IP addresses, recalculate checksums, and stuff like that instead of just handling the translation on network layer.
Why are stuff still like this? Probably because there is no easy way to change any of that because of sheer number of devices and protocols, applications, etc that needs to be updated and this takes a lot of time. Just look at the speed of adopting IPv6 which has been around for more then 15 years.
最主要的原因是,如今用到的大部分的实现,都是在标准制定之前开发的。在标准制定之后,这些协议已经被广泛地应用了,仅仅为了符合标准,而去做大面积的修改,实际上是非常困难的
联想到应用开发,一般也有明确的分层。包括几个原则:
1、依赖接口,不依赖实现
2、下层不可依赖上层
3、N+1层仅依赖N层,不跨层依赖
现在感觉,真正重要的其实是划分每层的职责,以及确定服务的接口。然后第一个和第二个原则是必须遵守的。而是否允许跨层依赖,以及是否允许同一层依赖,要看具体的情况,不需要太纠结
比如在business logic这层,可能存在很多业务逻辑组件,是否应该允许它们之间互相调用呢?理论上说,不互相调用当然是最好的,但是实践中会发现保持这个约束很难。在必要的时候,互相调用也没关系,但是同样应该依赖接口,而不能依赖具体的实现。分层不是根据调用的次数来划分的,并不是说存在3次接口调用,就一定代表架构里有4层。分层本身就是逻辑上的,所以应该看提供的服务是否是在一个层面上
另外在网络安全那一章,谈到了authentication(认证)和authorization(授权)的区别
一般的权限控制这2个部分都会涉及。简言之,校验用户身份是否正确,是authentication,而判断用户能做什么事,则是authorization
比如一个进程声称来自用户alice,要删除文件xxx.old。那么对于文件服务器来说,判断该进程是否属于alice属于认证,判断是否有权限删除文件属于授权
对于加密算法,有一个Kerckhoff原则。即算法本身必须是公开的,加密的只是密钥。如果算法和密钥都是公开的,那就不能算加密(ciper)了,只能算编码(encode),比如Base64算法,就不能算一种加密算法
另外看到一种典型的组网模式,在内网和DMZ区域之间,用防火墙隔离。外部用户可以直接访问到DMZ区域中的服务器,但是不能直接访问内网。联系我们的系统,反向代理是放在DMZ区域的,而应用和数据库服务器,都在内网里,中间用防火墙隔离
发表评论
-
classloader举个例子
2013-09-23 22:13 1209今天下午被一个同事问起,什么情况下需要用到ContextCla ... -
存储配置
2013-09-05 03:31 1752以前主要都在搞应用开 ... -
虚拟化的价值
2013-07-26 02:53 1131虚拟化技术的萌芽非常早。在大型机时代,一台硬件只能同时运行一个 ... -
Base64
2013-07-16 00:07 1640Base64是一种编码的算法 ... -
域名与主机名
2013-07-08 00:55 1308域名是domain name 主机名是hostname qq ... -
oracle实例、schema,以及多租户方案
2013-06-28 22:15 5258写这篇博客的起源,是 ... -
好帖转载
2013-06-27 14:37 1067公式引擎重写:http://damienkatz.net/20 ... -
关于分布式和集群,再补充2句
2013-06-18 00:31 1453一、分布式定义 今晚翻论坛,想看看别人是怎么说的,一路把20 ... -
为什么要用多线程
2013-06-17 22:01 6674以前我认为多线程的作 ... -
集群、分布式、性能
2013-06-15 14:41 1278性能是一个多方面综合的结果,遵循短板理论。系统中任何一个部分成 ... -
在浏览器里启动本地应用
2013-03-04 17:15 3231受限于javascript的安全问题,一般来说在浏览器里是不允 ... -
什么是SPI
2013-02-02 06:39 1615我理解SPI就是一种“服务发现机制” 很多规范里,都既包括A ... -
设置与查询事务隔离级别
2013-01-23 23:46 1554详情见:http://xm-king.iteye.com/bl ... -
事务小结
2013-01-23 22:01 1209最近在看jdbc specification,昨天刚看到cha ... -
api和spi,oracle的jdbc驱动为什么不开源
2013-01-22 06:03 2187今天下班后在看jdbc的规范,一不小心又走神,胡思乱想起来 ... -
系统集成的2种方式
2013-01-22 05:44 1458我以前是不是写过一篇类似的东西,说系统集成的 今天做一个别的 ... -
关于JCP
2013-01-22 05:04 1378今天上JCP去下载jdbc的规 ... -
JAVA平台几个主要的开源组织
2012-12-29 08:03 1336apache基金会,这个最有名,应该谁都知道了 eclips ... -
我对协议的理解
2012-12-05 07:12 1158今天工作进展不佳~~回来路上还在胡思乱想,突然想到一个对“协议 ... -
下载tomcat时的一个细节问题
2012-10-30 16:07 1255在apache的tomcat下载页面上,可以看到有2个不同的链 ...
相关推荐
在网络安全分层评价体系模型设计中,分层评价的意义在于通过精细化的分析和评估,来找出网络安全的薄弱环节,并允许用户根据自己的具体需求针对性地加强安全措施,以最小的资源代价实现最大程度的安全保障。...
网络安全分层防护思路浅解.pdf
网络安全的主要威胁; 安全分层控制方案,我们采用分层控制方案,将整个网络分为外部网络传输控制层、内外网间访问控制层、内部网络访问控制层、操作系统及应用软件层和数据存储层,进而对各层的安全采取不同的技术...
信息安全分层逻辑模型信息安全分层逻辑模型信息安全分层逻辑模型信息安全分层逻辑模型信息安全分层逻辑模型信息安全分层逻辑模型信息安全分层逻辑模型信息安全分层逻辑模型信息安全分层逻辑模型信息安全分层逻辑模型...
分层描述网络安全 还有防御网络安全 下吧哈
综合来看,Avaya网络分层方法和Polycom的视频协作解决方案,分别从网络安全和协作工具两个方面,展示了如何应对现代企业面对的网络挑战和办公需求。这两个领域的技术进步不仅为专业人士提供了更高效的工具,也为企业...
通信网络安全分层及关键技术 通信网络安全是当前信息技术中最重要的方面之一。随着网络技术的发展,通信网络安全问题变得越来越复杂和严峻。为此,本文主要探讨通信网络安全分层及关键技术,以便更好地解决网络安全...
总之,文章《社会分层视野下网络安全立法体系的构建》深入剖析了网络安全立法的必要性和方法,强调了社会分层理论在构建网络法治体系中的应用价值,为我国网络安全法制建设提供了理论支持和实践指导。
总结来说,计算机网络安全分层评价防护体系是一种科学的网络安全管理方式,它将网络安全管理分为多个层面,每一个层面都有明确的目标和任务。通过这种分层的防护体系,可以更有针对性地发现和解决问题,从而更有效地...
然而,二代防护体系在实际应用中仍然存在着一些漏洞和不足,因此有必要对网络安全防护体系进行深入分析,从而为计算机网络安全防护体系的构建提供理论依据和技术支持。 网络安全是计算机网络中十分重要的组成部分,...
通过以上知识点梳理,我们可以看到计算机网络安全分层评价体系构建的重要性,以及在实际应用中需要关注和改进的方面。同时,电力企业信息运维故障诊断模型的研究也是保障关键基础设施网络安全的重要组成部分。这两...
随着网络应用的普及和技术的进步,保障通信网络安全已成为确保用户信息安全、维护网络秩序和意识形态安全的重要基础。本文对通信网络安全进行了分层管理研究,并探讨了关键技术,为互联网通信网络安全管理技术的发展...
其次,网络安全分层评价防护体系由若干部分组成,主要包括服务层、管理评估层和应急服务层。服务层是网络用户直接接触的层面,它要求提供稳定的网络服务,同时需要通过一些安全措施来保障服务的可用性。管理评估层则...
【标题】与【描述】提到了“广播电视网络安全防护中的分层式防护研究”,这是一个关于如何保护广播电视网络免受网络安全威胁的专业话题。分层式防护是一种网络安全策略,它通过在不同层次实施不同的防护措施来增强...
综上所述,构建和完善计算机网络安全分层评价防护体系是一项系统工程,涉及到管理、人员、物质和环境等多个层面。只有全面考虑并解决这些层面的问题,才能构建出有效、稳固的防护体系,为我国的计算机网络保驾护航,...
计算机网络安全分层评价防护体系的思考.pdf
构建计算机网络安全分层评价防护体系旨在更好地理解和抵御这些威胁。 **一、开发环境与开发工具** 1. **开发环境**:本研究基于Windows操作系统,选择了Eclipse作为开发平台,配合Tomcat 6.0服务器,并利用SQL ...
新一代网络安全框架强调了分层解耦、异构兼容的设计理念,它要求安全能力资源化、目录化、云化,通过网络调度来增减安全措施。这要求安全框架必须具备灵活的适应性,能够应对快速变化的网络环境和威胁。同时,新一代...
【网络安全专业分层模块化教学模式】 随着全球信息化的快速发展,网络技术和计算机网络的应用日益广泛,网络安全成为了至关重要的话题。为了应对日益复杂的网络信息安全威胁,我国的网络安全人才培养面临着巨大挑战...