媒体服务器下载分流的问题

夏天的枫 2017-09-04 11:24:53
现在有个媒体服务器 主要存贮数据供用户现在,单个文件都特别大,在500M左右,但是服务器带宽又只有20M,现在的情况就是如果一个用户开始下载了,就把媒体服务器的带宽占完了,第二个用户就无法下载甚至于无法浏览网站。理想情况下应该是2个用户同时下载就应该平分这20M,让每个用户都能下,这个有没有具体的解决方案呢?(我一个写应用的没有这方面的处理经验呀
服务器是腾讯云。
...全文
184 6 打赏 收藏 转发到动态 举报
写回复
用AI写文章
6 条回复
切换为时间正序
请发表友善的回复…
发表回复
夏天的枫 2017-09-05
  • 打赏
  • 举报
回复
引用 5 楼 sp1234 的回复:
要降低带宽就要人为地加入 Thread.Sleep,故意拖延下载速度。
这个文件相当于直接部署在tomcat的webapps的,然后在前端直接就href=地址了。 因为又想充分的利用带宽,所以感觉从代码层面入手好像不怎么好做到
  • 打赏
  • 举报
回复
要降低带宽就要人为地加入 Thread.Sleep,故意拖延下载速度。
夏天的枫 2017-09-05
  • 打赏
  • 举报
回复
求大佬帮助。。。
夏天的枫 2017-09-04
  • 打赏
  • 举报
回复
夏天的枫 2017-09-04
  • 打赏
  • 举报
回复
引用 1 楼 cyg17173 的回复:
哇 80分啊, 转帖 http://blog.csdn.net/lisky119/article/details/8111743
不是这个意思哦。。。。这样可能会导致无法完全的使用带宽
cyg17173 2017-09-04
  • 打赏
  • 举报
回复
哇 80分啊, 转帖 http://blog.csdn.net/lisky119/article/details/8111743
媒体行业服务器解决方案 OSM(Oversea Streaming Media) 版本:V1.0.0 流媒体行业服务器解决方案 OSM(Oversea Streaming Media) 随着 Web2.0 技术的普及,使得网络上传输的资料不仅仅限于文字和图形。有许多的视频 应用需要在 Internet 网络上点播,它们都要求最大范围的让观众观看到高质量的节目,像电 视一样达到宣传、广告或满足观众需求的目的。这就要求系统具备高传输率、数据同步、数 据流的分流、高稳定等性能。实现网络的视频、音频传输最好的解决方案就是流式媒体的传 输方式。 一、行业需求 在流媒体系统中数据流量是非常巨大的,对于视频点播并发流的负载要求非常强大,单 一服务器无法承担大量并发数据流的负载。这给部署运营跨境流媒体服务器网络带来了严峻 的技术考验。 通常有三种方式来改善这种状况:升级网络带宽,升级服务器配置或增加服务器,用最 大的压缩技术来压缩视频文件。但这三种方式有各自的局限性。网络带宽和服务器的升级一 般是同时进行,在短时间内虽能解一时之需,但将来还是会面临的升级需求,同时会造成资 源浪费,甚至会出现性能卓越的硬件也满足不了业务发展需求的状况。通过压缩视频文件, 可以相应地减轻服务器的负担,然而当今的视频压缩技术都会面临视频文件压缩的同时视频 效果受损的问题。此方法势必会影响用户的视觉体验,服务质量变低。 1、 单一服务器无法承担大量并发数据流的负载。流媒体是一个特殊的网络应用系统,它与 一般 Web 应用不同,其最大特点就是需要高速处理并发视频流数据。流媒体系统对服务器 I/O 通道吞吐率要求是极为严格的,其数据流量是非常巨大的。流媒体系统对于视频点播 并发流的负载要求非常强大,单一服务器无法承担大量并发数据流的负载。 2、 备份服务器资源未能充分利用,导致浪费。与传统的文件数据不同,媒体数据流一旦开 始传输,就必须以稳定的速率传送到客户端,以保证其平滑地回放,视频、音频数据流都 不能有停滞和间断。鉴于流媒体服务以上特性,服务器稳定性尤为重要。单台服务器的设 置,不可避免会出现"单点故障" ,需要进行服务器"容错" 。为实现容错,往往在主服务 器旁安置一台或多台备份服务器。但这样做,平时只有一台服务器工作,其他服务器处于 空闲状态,无法利用所有服务器的处理资源,投资得不到充分利用。 3、 扩容性低,系统性能无法保障。随着业务的发展,服务器上所要处理的数据量不断增大, 同时并发连接数量会越来越多。若处理资源不够,在未超出系统容量时,往往是客户的请 求回应越来越慢,可容纳的同时连接数量逐渐减小,系统性能严重下降。当超出系统容量 后,系统出现故障导致服务中断。为应对日益增多的业务量,系统的可扩展性尤为重要。 二、解决方案 三、解决方案优势说明 1、高速高效:负载均衡使用特有的负载均衡算法,能够保证大量的流媒体连接请求负载实时 高效均衡。 2、实时在线:负载均衡服务器采用高可用冗余设计,而且对后端每台流媒体服务器的服务端 口进行健康检查。 3、可扩展性强:基于应用的结构,便于以后业务系统无缝拓展 4、多重保障:OSM 实施后,可以有效解决流媒体服务器负载高,容易出现故障,无法实时扩 展等问题服务器报价: 硬件名称 产品名称 详细配置 地区 数量 网站服务器 深圳服务器 E5 处理器:双至强 E5 内存: 32GB 硬盘: 3*2TB SATA 流量: 不限流量 IP 数: 1 个可用 IP 深圳 5 BGP 带宽 BGP 带宽 BGP 多线路接入 深圳 20M 服务器 5 台:79300 元/年 BGP 带宽:20M 年付:34000 元/年 总价:113300 元/年
联想企业级产品拆解分析 联想服务器拆解分析全文共12页,当前为第1页。 联想企业级产品--市场分析 联想企业级产品--拆解分析 联想服务器拆解分析全文共12页,当前为第2页。 企业级整体业务回顾-出货量 友商一 友商一% 友商二 友商二% 友商三 友商三% 友商四 友商四% 友商五 友商五% 联想服务器拆解分析全文共12页,当前为第3页。 企业级整体业务回顾-营业额 友商一 友商一% 友商二 友商二% 友商三 友商三% 友商四 友商四% 友商五 友商五% 联想服务器拆解分析全文共12页,当前为第4页。 企业级市场预测 中国未来 3-5年GDP 增长率目前看不会保持在高位,我们发现未来的增长趋势将呈现出典型的"L"状,不会出现增长的高峰但是会比较平稳,这意味着市场已经十分成熟并进入稳定增长的阶段,不会大起大落。 政府部门将会在未来10年的发展中扮演更重要的角色,IT必然是未来发展的主要领域之一。 本土品牌获得极大收益,尤其是在新兴行业(IPDC),并且他们也在很多成熟行业与国际厂商展开正面竞争。 超大型的人口和更多的工作负载整合需求(如电子政务,一站式办公,智慧城市)为高端x86服务器带来更多机会。 第三平台(云计算, 社交媒体, 大数据和移动互联) 的普及将会推动中国IT市场未来3-5年的高速增长。 互联网+(传统市场向第三平台转换) 在某一时间点爆发后会快速的改变现有市场格局并带来很多新的市场机会。 数据源:IDC 2015Q2 X86 Server Market Review 联想服务器拆解分析全文共12页,当前为第5页。 联想企业级产品--市场分析 联想企业级产品--拆解分析 联想服务器拆解分析全文共12页,当前为第6页。 1 总体设计 2 4 3 短路无烟设计 30u镀金 12层电路板 System x秉承优质工艺,包括使用增厚电路板,短路无烟安全设计,两倍于业界标准的镀金厚度等。从选料就保证系统未来的稳定性 System x无工具硬盘背板 竞品固定式背板 无工具背板使用户可以很短的时间内将背板更换或升级,减少用户的下线维护时间 易用性 易用性 System x遍布服务器的标识,可以给客户清晰的展示。包括易插拔(蓝色)和热插 (橘红色),各种文字标签等 通过这些标签,用户可进行准确操作,防止意外宕机和触电等危险 System x清晰的标识,防止用户误操作 易用性 无工具CPU拆装设计使用户可以很短的时间内将背板更换或升级,减少用户的下线维护时间 优质合金材质的CPU散热设计,提高散热的效率 System x无工具处理器套件 竞品固定式处理器 x3650 M5对比HP DL380 Gen9 联想服务器拆解分析全文共12页,当前为第7页。 5 易用扩展 6 System x 无工具后置托架 竞品固定后置位,不可利用 无工具后置托架位可以使用户迅速灵活的在PCIe扩展口、后置硬盘等方面进行切换 System x后置槽位的排布科学,最大可以扩展到9个PCIe的卡,或者安置2个后置硬盘笼组,最大可放置 4个硬盘 丰富的前面板功能设计 竞品极简的前面板 前面板提供VGA,USB和光通路诊断面板灯功能,使用户可以在前面板轻松维护机器,而不需要从高温的服务器后部去操作 易用性 易用性 System x新一代光通路诊断面板,每屏可以显示多达竞品3倍的内容 覆盖各主要部件故障定位和预分析系统,可以使用户迅速定位故障和隐患,配合前述无工具设计,可以在短短几分钟内完成故障的排除和部件更换工作。 散热设计 六边形散热孔提供最大的有效散热面积和坚固的机械结构。既保证有效的散热,又防止面板被破坏 此处无法利用 此处可灵活配置 光通路诊断面板 USB和VGA 指示灯 8 System x 六边形散热孔 System x覆盖各主要部件的故障预测和定位系统 7 竞品四方形散热孔 x3650 M5对比HP DL380 Gen9 联想服务器拆解分析全文共12页,当前为第8页。 9 散热设计 System x双马达高效对转风扇 竞品普通风扇 双马达高效对转风扇提供至少10%的额外风量,是保证系统温度的重要保障 每一个双马达对转风扇都有两组独立的马达和叶片,实现风扇层面的冗余 System x导风板 竞品导风板 System x采用厚实的导风板,帮助将服务器划分为双风区,每一个风区都是冗余的 配合前述风扇方面的冗余,System x实现了服务器的双重冗余 高能效 主备模式电源可以使用户选择能效比最高的运行模式,节约能源 主备模式可以使输入的电源性质不同,实现电路层面的冗余 高性能 System x3650 M5最大同时支持4块12Gbps阵列卡,面对日益普及的固态硬盘阵列,可以有效的分流数据带宽,避免吞吐瓶颈出现 竞品普遍只支持1个阵列卡通道,极易形成数据拥塞
我们今天以企业用户常用的CRM系统,来看一看标准的SaaSCRM应该是一个什么样子。   实际上,很多用户对于CRM并不陌生,早在2000年的时候,有一些企业就已经开始尝试CRM系统。在很多人眼中,CRM就是一套C/S或者B/S的应用系统。   而当CRM进入了SaaS,他在架构上会是一个什么样子呢?我们以361CRM为例,来看一下SaaSCRM的架构。   361CRM系统采用分布式架构。采用企业级的多层次、多应用的系统结构的SaaS在线CRM平台平台架构从大的层次上来分主要为四层,根据调用关系依次为应用层、缓冲层、服务层以及存储层,如下图所示:   应用层   从浏览器发送过来的请求,直接由应用层来进行直接响应;   平台是多租赁用户的在线多应用来实现的,由于每个用户的具体业务需求不同,因此每个租赁用户的应用是相互隔离的,但应用层的结构却都是相同,从上到下主要分为业务展现层、业务逻辑层、业务模型层、实体访问层;   业务展现层主要为用户数据的不同视图表现,为用户呈现各种易于浏览、便于理解的各种数据表现方式,如表单、表格、报表、图表等;   业务逻辑层主要是业务逻辑的具体实现层,对于用户动作、触发事件以及工作流程等由业务逻辑层来实现业务的处理以及响应,通过业务逻辑层对下层业务模型的访问来实现具体的逻辑处理;   业务模型层主要是业务对象的具体定义与封装,是对于现实中业务在平台中的最直接的映射;   实体访问层是对于业务逻辑层对于业务模型操作的封装,业务模型的实体状态的更新、删除、查询等都是通过实体访问层来实现。   缓冲层   缓冲层主要对于静态资源以及动态数据的缓存。静态资源主要是指应用层中展现层中所要使用到的静态资源文件,以及由用户在业务操作中产生的文件等,如图片、上传的文件等;   而动态数据是指用户在使用平台的过程中所产生的业务数据,在实现业务中,这部分数据大部分都是读操作比较多,而写操作比较少,因此可以针对这部分数据根据特定的缓存失效策略机制来进行相应的缓存;   缓冲层的缓存针对应用层是透明的,而且针对多应用也是透明的,因此缓冲层具有更大的弹性与灵活性。   服务层   服务主要是指平台的核心服务,核心服务分为业务共通服务以及平台共通服务,平台共通服务是指与业务无关且是平台最基础的服务,如任务调度、消息队列、邮件服务、图片处   理、工作流引擎等;而业务共通服务指基于平台共通服务,而对于所有业务具有共通性的服务,如日志审核、操作回滚、数据安全、全文检索、权限角色等;   服务层是对于平台运营、维护最核心的服务实现,是平台正常运行的基础。   存储层   存储主要分为两部分:分布式文件存储以及分布式的数据存储;   由于是多应用的平台,因此随着平台的运营,会产生海量的业务数据以及资源文件,因此伴随着海量的数据而来的问题就是存储、检索、分析以及统计等问题;   针对上述问题,361CRM平台采用了分布式的存储系统,基于Map-Reduce来进行相应的检索、分析以及统计,实现了对于海量数据的统一操作。   这种结构能做到真正的分布式网络计算,有效降低网络流量,减轻客户端负担,还能安全、方便地与互联网接口。另外公司员工或客户分布或行走于全国各地,通常都有移动办公需求。   REST 架构   REST是基于HTTP的,因此天生就有在互联网上穿透防火墙的能力,REST可以简单地认为它是轻量级的WebService,但是它具有自己的一些显著特点:   所有的资源通过统一的接口访问(HTTP/HTTPSGET、POST、PUT、ELETE),而且接口比较统一,便于与第三方的集成;   因为是基于HTTP/HTTPS的,因此可以将资源(响应)分为可缓存的和不可缓存的,以及采用浏览器的标准压缩方式,有效地提升网络效能。也可以在客户和资源之间插入不同的中间组件来提升性能和安全等,如,代理服务,缓存服务,网关服务等;   因为是基于HTTP/HTTPS的资源请求,因此本次连接和下一次到服务器的连接之间没有状态。由于361CRM平台采用了REST架构,因此也就决定了361CRM平台天然就具备以下几方面的优势:   由于REST本身无状态的特性,361CRM平台天然就是分布式的,决定了后台通过根据业务量而弹性地增加服务器就可以实现平台计算能力的线性增加;   所有的请求都是统一通过RESTAPI进行相应的资源与服务的请求,这样就能够保证系统提供的服务都是解耦的,极大的简化了系统,从而改善了系统的交互性和可重用性,同时也能够根据业务进行相应统一且透明的内存缓存   客户端浏览器能够轻松通过Ajax实现REST资源的异步调用处理,同时也可以有效地减少应用服务器地压力   通过提供开放的RESTAPI,能够轻松实现与第三方的集成   平台服务   平台服务层的调用是通过RESTAPI进行的,由于REST的特点,通过在URI中添加资源路径以及版本信息,很方便地能够实现平台的平滑升级以及数据兼容性问题。   平台服务层实现的都是共通的服务,服务之间是独立的,而且是插件式的方式来实现的,平台选用了面向分布式计算的Erlang语言来实现的,因此保证了这些插件式的服务能够热拔插地部署,实现真正地不宕机地部署与更新。   平台服务层的插件式架构,决定了平台的无限扩展能力,能够根据不断变化地用户需求而进行平台的不断地在线迭代与更新,与用户的需求形成一个良性的循环。配置定制平台通过服务器(Apache)的自定义开发,实现了企业用户应用的透明隔离,因此平台具有面向不同企业用户根据不同需求进行个性化定制的能力。不同的企业用户,一般主要有几方面的自定义需求:业务对象、工作流程、报表、布局等,而361CRM平台的平台框架就决定着能够很好地满足用户的自定义需求,主要分为以下几个方面:   由于用户使用的是文档数据库,有着松散的数据结构,因此用户根据需求,而可以随意自定义自己的业务对象;   361CRM平台后台的平台服务层,有相应的实时的工作流引擎,提供给用户强大的自定义工作流程功能;   361CRM平台有业内是丰富的报表模板,用户只需要根据自己的需要来选择即可,针对一些自定义的动态数据,还提供模板的再定义功能,能够很好地满足用户的报表需求;   由于平台是应用隔离的,因此针对着页面的布局,可以很容易地实现个性化地定制;   361CRM平台的配置功能的强大,并不以损失平台应用的易用性为基础,361CRM平台在操作上采用引导式操作,以及提供方便易用的在线帮助,大大地降低了系统使用的复杂度,使系统更加地人性化、简易化。   实时即时   361CRM平台的平台服务层与通常的应用服务不同,它是实时运行的服务,平台服务层有相应的任务调度机制,邮件服务、消息队列以及实时的工作流引擎等,这些服务都是实时运行的,因此当企业用户的业务对象或者业务流程发生变化时,通过这些平台服务就可以把即时的状态消息(通过邮件、短信或者其它的IM工具)推送给用户,让用户真正了解到业务的即时与实时的状态信息。   而通常的应用服务是静态的,只有当用户登录时,才会进行相应的业务状态的检查,这样就严重影响了业务处理的速度,对于即时性业务,就会带来很大的损失。   多级负载   平台是一个多租赁用户的在线SaaS系统,因此会给平台带来大量的高并发的请求,361CRM平台是一个多层次的结构,而且采用了REST架构,REST天生就是分布式,因此通过物理部署就可以实现高并发带的负载均衡。   四层负载在链路层解决来自互联网的并发请求压力,使用LVS+Heartbeat的主从双备的架构,保证不会出现单点故障;   Web应用的大部分压力都来自于资源的请求,如图片,静态文件,样式表等文件的请求,服务器压力的70%都来自于这些资源的请求,因此对于这些静态资源的请求,通过静态资源缓冲层就能够很好解决这些请求对于后台造成的压力;   经过实测,经过一段时间稳定运行之后,静态资源缓冲层能够命中前台请求的80%以上,有效地缓解了应用服务器的压力;   七层负载层主要是做业务、以及资源的请求分流,把负载均衡到多台文件服务器以及应用服务器上;   文件服务器与应用服务器是分布式的,通过Map-Reduce进行任务的拆分与结果的合并,充分利用多台服务器的并行计算能力,提升整体平台的运行性能;   文件缓存采用多级缓存策略,解决命中率高的文件的频繁请求。而数据缓存则通过业务标签以及时效性策略进行数据的缓存,并且进行缓存的增量更新,有效地解决了对于后台的   数据读写压力;   分布式的存储系统有效地解决了海量数据的存储、检索、分析以及统计等问题。   可见,当传统的CRM系统转换为SaaS服务后,其架构方面还是发生了不少的变动的,也只有这样的变动,才使得CRM能够在SaaS平台上更好的为客户所服务。   附:什么是REST架构   REST软件架构是当今世界上最成功的互联网的超媒体分布式系统。它让人们真正理解我们的网络协议HTTP本来面貌。它正在成为网络服务的主流技术,同时也正在改变互联网的网络软件开发的全新思维方式。AJAX技术和Rails框架把REST软件架构思想真正地在实际中很好表现出来。今天微软也已经应用REST并且提出把我们现有的网络变成为一个语义网,这种网络将会使得搜索更加智能化。   REST与HTTP协议   REST软件架构是由RoyThomasFielding博士在2000年首次提出的。他为我们描绘了开发基于互联网的网络软件的蓝图。REST软件架构是一个抽象的概念,是一种为了实现这一互联网的超媒体分布式系统的行动指南。利用任何的技术都可以实现这种理念。而实现这一软件架构最著名的就是HTTP协议。通常我们把REST也写作为REST/HTTP,在实际中往往把REST理解为基于HTTP的REST软件架构,或者更进一步把REST和HTTP看作为等同的概念。   今天,HTTP是互联网上应用最广泛的计算机协议。HTTP不是一个简单的运载数据的协议,而是一个具有丰富内涵的网络软件的协议。它不仅仅能够对于互联网资源进行唯一定位,而且还能告诉我们对于该资源进行怎样运作。这也是REST软件架构当中最重要的两个理念。而REST软件架构理念是真正理解HTTP协议而形成的。有了REST软件架构理念出现,才使得软件业避免了对HTTP协议的片面理解。只有正确的理论指导,才能避免在软件开发的实际工作过程中少走弯路。   REST与URI(资源定位)   REST软件架构之所以是一个超媒体系统,是因为它可以把网络上所有资源进行唯一的定位,不管你的文件是图片、文件Word还是视频文件,也不管你的文件是txt文件格式、xml文件格式还是其它文本文件格式。它利用支持HTTP的TCP/IP协议来确定互联网上的资源。   REST与CRUD原则   REST软件架构遵循了CRUD原则,该原则告诉我们对于资源(包括网络资源)只需要四种行为:创建、获取(Read)、更新和销毁就可以完成对其操作和处理了。其实世界万物都是遵循这一规律:生、变、见、灭。所以计算机世界也不例外。这个原则是源自于我们对于数据库表的数据操作:(生)、select(见)、(变)和(灭),所以有时候CRUD也写作为RUDI,其中的I就是,这四个操作是一种原子操作,即一种无法再分的操作,通过它们可以构造复杂的操作过程,正如数学上四则运算是数字的最基本的运算一样。   REST与网络服务   尽管在Java语言世界中网络服务目前是以SOAP技术为主,但是REST将是是网络服务的另一选择,并且是真正意义上的网络服务。基于REST思想的网络服务不久的将来也会成为是网络服务的主流技术。REST不仅仅把HTTP作为自己的数据运输协议,而且也作为直接进行数据处理的工具。而当前的网络服务技术都需要使用其它手段来完成数据处理工作,它们完全独立于HTTP协议来进行的,这样增加了大量的复杂软件架构设计工作。REST的思想充分利用了现有的HTTP技术的网络能力。在德国电视台上曾经出现过一个这样的五十万欧元智力题:如何实现网络服务才能充分利用现有的HTTP协议?该问题给出了四个答案:去问微软;WSDL2.0/SOAP1.2;WS-Transfer;根本没有。这个问题告诉我们HTTP并不是一个简单的数据传来传去的协议,而是一个聪明的会表现自己的协议,这也许是REST=RepresentationalStateTransfer的真正含义。   实际上目前很多大公司已经采用了REST技术作为网络服务,如Google、Amazon等。在Java语言中重要的两个以SOAP技术开始的网络服务框架XFire和Axis也把REST作为自己的另一种选择。它们的新的项目分别是ApacheCXF和Axis2.Java语言也制定关于REST网络服务规范:JAX-RS:JavaAPIforRESTfulWebServices(JSR311)。相信还会出现更多与REST相关的激动人心的信息。   REST与AJAX技术   尽管AJAX技术的出现才不到两年时间,但是AJAX技术遵循了REST的一些重要原则。AJAX技术充分利用了HTTP来获取网络资源并且实现了HTTP没有的对于异步数据进行传输的功能。AJAX技术还使得软件更好地实现分布性功能,在一个企业内只要一个人下载了AJAX引擎,其它企业内部的人员,就可以共享该资源了。AJAX技术遵守REST准则的应用程序中简单和可伸缩的架构,凡是采用AJAX技术的页面简洁而又丰富,一个页面表现了丰富多彩的形态。   AJAX技术还使用了一种不同于XML格式的JSON文件格式,这个意义在哪里呢?在REST软件架构下我们不能对于XML文件进行序列化处理,这样程序员必须要使用自己的XML绑定框架。而以序列化的JavaScript对象为基础的JSON已经获得了广泛认可,它被认为能以远比XML更好的方式来序列化和传输简单数据结构,而且它更简洁。这对REST是一个极大贡献和补充。   当前的网络应用软件还违背了REST的“无状态服务器”约束。REST服务器只知道自己的状态。REST不关心客户端的状态,客户端的状态自己来管理,这是AJAX技术的应用之地。通过AJAX技术,可以发挥有状态网络客户机的优势。而REST的服务器关心的是从所有网络客户端发送到服务器操作的顺序。这样使得互联网这样一个巨大的网络得到有序的管理。   REST与Rails框架   RubyonRails框架(简称Rails或者Rails框架)是一个基于Ruby语言的越来越流行的网络应用软件开发框架。它提供了关于REST最好的支持,也是当今应用REST最成功的一个软件开发框架。Rails框架(从版本1.2.x起)成为了第一个引入REST作为核心思想的主流网络软件开发框架。在Rails框架的充分利用了REST软件架构之后,人们更加坚信REST的重要性和必要性。Rails利用REST软件架构思想对网络服务也提供了一流的支持。从最直观的角度看待REST,它是网络服务最理想的手段,但是Rails框架把REST带到了网络应用软件开发框架。这是一次飞跃,让REST的思想从网络服务的应用提升到了网络应用软件开发。利用REST思想的simply_restful插件已经成为了Rails框架的核心内容。   REST安全性   我们把现有基于SOAP的网络服务和基于REST/HTTP网络服务作个比喻,前者是一种传统的寄信方式,而后者是现代网络的电子邮件方式。要是是寄信和电子邮件都有病毒存在的话,传统的寄信被送到对方就很危险,而电子邮件是开发的,电子邮件供应商比如Google为我们检查了电子邮件是否有病毒。这里并不是说明SOAP网络服务消息包含义病毒,而是说明HTTP是无法处理SOAP信息包究竟好不好,需要额外的软件工具解决这一问题,包括防火墙也用不上和管不了。   REST/HTTP网络服务的信息包可以被防火墙理解和控制。你可以按照操作和链接进行过滤信息包,如你可以规定从外部来的只能读取(GET操作)自己服务器的资源。这样对于系统管理员而言使得软件管理更为简单。REST的安全性还可以利用传输安全协议SSL/TLS、基本和摘要式认证(BasicundDigestAuthentication)。除了这些REST自身的安全性功能外,还可以利用像基于信息的WebServicesSecurity(JSR155)作为REST不错的补充。   我曾经遇到一个求职者,他的简历看起来不错,基本上没有大问题,但他就是没有收到任何回复。一天我半开玩笑似的问他是不是电话写错了,我一检查,果不其然。他改正后,立即收到了他所期望去的公司的面试电话。从这个故事中我们得到一点教训:哪怕只剩最后一秒钟,也要检查你的联系方式两遍。这是理所当然应该做到的细节,早做比晚做好。

110,535

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 C#
社区管理员
  • C#
  • Web++
  • by_封爱
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

让您成为最强悍的C#开发者

试试用AI创作助手写篇文章吧