Fastsoft:单边广域网加速

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




Fastsoft公司在2006年成立于美国加州。公司通过销售FastSof t E Series™产品使在加州理工学院2004年研发出的突破性网络优化技术FastTCP™ 能成功商业化。该技术项目由加州理工学院、美国国家科学基金会,美国国防部高级研究计划署及CISCO资助。

FastSof t E Series™产品使用了该公司获得专利的3项算法,分别是
FastTCP®——–根据网络拥塞程度动态调整传输率
FastStart™——-根据网络连接的时延抖动性智能快速达到最佳吞吐率,从而解决标准TCP的慢启动缺点
HyperBurst™——动态调整接收窗口大小以便吞吐最大化

目前Web加速通常采用网站用户访问最近距离的CDN静态缓存内容来实现,这对因客户端与网站主SERVER端物理距离遥远而造成的网络延迟带来的负面影响是个不错的解决方案。但随着用户对个性化网页、点播视频等动态内容的的要求不断提高,WEB发布方需要找到一种方式来加速此类动态内容,以增加浏览量,提高网站停留的平均时间,以及客户重访率,这是CDN及负载均衡所不能单独解决的,而这正是Fastsoft的长处。

FastSoft独特的单边部署方式意味着在客户端无需新增软件或浏览器插件,且在服务器端也无需修改配置或重写代码即可实现单边加速功能,也就是说:只要在服务器端简单串联一个标准1U服务器大小FastSof t E Series™设备,在全球的任一地点访问该服务器均可享受到动态页面、文件传输的30% 到500%加速。

应用领域:
1 – SaaS ( Software as a service – part of Cloud computing)
2 – Video/Gaming Acceleration
3 – File Transfer
4 – CDN ( Content Delivery Network)

PS:鄙人准备负责该产品在国内的推广,因在技术上非常地不专业(据我初步了解,WAN加速市场国内有深信服、华夏创新,Quick B的单边加速方案;国外有Riverbed,Signiant,Akamai,Sohonet,BlueCoat,juniper,F5等成熟双边/单边加速产品,且观各产品介绍,就算是华夏创新、Quick B的产品都有单边500倍的加速效果,Fastsoft的区区5倍加速效果何以竞争?),因疑问太多,所特借弯曲评论将该产品简单介绍一下,望弯曲评论上诸位仁兄不吝给出中肯的意见及建议,看该产品在国内市场前景如何,谢谢诸位。       
2010.Jul.14,感谢诸位仁兄的中肯意见,所有留言均让我受益匪浅,谢谢大家。
shark   http://www.zyang.net/fastsy.html

(5个打分, 平均:4.60 / 5)

雁过留声

“Fastsoft:单边广域网加速”有111个回复

  1. 理客 于 2010-06-24 12:54 下午

    TCP因为效率问题,大量数据传输用的主要是UDP,比如FTP,视频等。
    WEB如果是以TCP为主,海量TCP的效率如果有需要优化的地方,倒是有意义

  2. limbo 于 2010-06-24 1:18 下午

    不知道有没有FastSof较为细节的技术资料。他是如何能实现500倍加速的?

  3. mpc8240 于 2010-06-24 1:43 下午

    谁给讲讲,为啥客户端TCP不需要改动?

  4. iWalle 于 2010-06-24 4:39 下午

    FastSoft能同时支持FastTCP和TCP Reno就行。客户端用TCP Reno发起连接,服务端用FastTCP来传数据。

  5. 追逐好梦 于 2010-06-24 5:15 下午

    (据我初步了解,……,华夏创新、Quick B的产品都有单边500倍的加速效果,Fastsoft的区区5倍加速效果何以竞争?)

    500倍的加速效果是有条件的,实验环境不一样,效果差别很大。

  6. 大桥 于 2010-06-24 5:23 下午

    反对广告…

    要说就说说具体的原理嘛…

  7. fastcache 于 2010-06-24 5:30 下午

    老实说,fastsoft和华夏创新我以前都试用过了,感觉都差不多,(gzbj:2M)双边的比较明显,单边加速好像没什么效果…

  8. Vipper 于 2010-06-24 5:39 下午

    没明白是什么原理,即时他这个设备支持FastTCP,但客户端慢启动和快速重传还是遵循以前的处理逻辑,恢复比较慢,如何实现如图所展示的快速启动和恢复呢?求解答

  9. droplet 于 2010-06-24 6:05 下午

    单边加速,顾名思义,就是改动了一边的tcp的行为,web访问里面,c2s的流量远远小于s2c的流量。把s2c的slow start这些加速了,应该有实际的意义。但问题是会不会造成网络拥堵?client这边的buffer没有问题,但是gateway就没办法预测了。

  10. 于 2010-06-24 6:18 下午

    感觉单边加速,都是适用于高延时网络中。不过,在我们大中华局域网中,网络延时有那么大么?如果延时不大,加速效果能明显展现出来么?

    ps:有篇论文估计就是说的这个:
    FAST TCP:Motivation, Architecture, Algorithms, Performance

    06年IEEE transaction的。

  11. shark 于 2010-06-24 6:34 下午

    果然都是神人,感谢“辉”提供的信息,Fastsoft的原理论文链接为:http://www.ieee-infocom.org/2004/Papers/52_2.PDF。请问哪位高人可以将此原理深入浅出告知小弟一下,多谢。

  12. 免费小说阅读网 于 2010-06-24 6:41 下午

    深奥的道理,学习了

  13. 于 2010-06-24 7:26 下午

    顺便说一句,我说shark ,你代理国外的单边加速,价格估计得10w+ rmb了吧。如果无法在客户的环境演示出好的效果,那客户可能会选择把这笔钱拿去买带宽了吧,毕竟国内广域网带宽还是很便宜的。

    加速这玩意,我感觉主要还是用在昂贵的专线用户那里,双边加速效果会好些。

  14. 老韩 于 2010-06-24 8:03 下午

    shark你可以联系我,说不定能给你一些宣传推广上的意见。

    hanxu0514( at )gmail.com

  15. IE 于 2010-06-24 11:43 下午

    说实话,在国内没多大市场,大陆的带宽成本比国外低多了。你看看其他同类品牌在全球的营业额就知道了

  16. hritian 于 2010-06-24 11:52 下午

    实际上在高带宽时延积网络里面双边的配置才是有必要的。
    在中国这种网络环境下,时延超过100ms的链路已经是不多了。单边(发送端)的加速就已经够了。

    tcp拥塞控制,其本质就是拥塞窗口的调整,学术界出于整个网络的考虑,对于拥塞控制算法的评价标准是效率,公平性和收敛性。
    当然实际上现在的所有算法都存在着所谓的RTT不公平性。

    从我们自私的端到端来说,其评价标准就不一样了,在这个评价标准下是终端带宽的利用率。

    so so。。。。。。。

  17. hritian 于 2010-06-24 11:54 下午

    shark ,你们的产品可以拿来测试吗?
    可以的话,邮件联系一下我。
    邮箱名是我的昵称,后缀是163.com

  18. 删吧 于 2010-06-25 12:23 上午

    wrong problem.
    Pls not wasting your time on this, try something else.

  19. phd 于 2010-06-25 1:50 上午

    soso

  20. 于 2010-06-25 2:01 上午

    我不是很理解hritian 兄的说法。
    双边部署主要是为了利用字节缓存,剔除冗余流量来进行加速。

    FAST TCP应该就是类似于HSTCP之类,更好地维护拥塞窗口的算法吧。本质上,是在网络带宽充足的情况下,提高网络利用率。HSTCP适用条件是长肥管道,大带宽高延时网络。和hritian 兄描述的延时低于100ms的网络情况貌似有点相反,不知道是不是我弄错了。

    双边部署的字节缓存技术,硬生生的减少了网络流量,发送的数据少了,自然速度快了。

  21. 理客 于 2010-06-25 2:58 上午

    我理解这里的优化的核心是拥塞的时候窗口减到多少能一次最接近最大出口带宽,不拥塞后增大窗口的也是一样的,如果独立的解决,算法的优化空间是有限的,所以需要监控拥塞时候,所有TCP准备发送的超额流量,然后计算所有TCP要减小的窗口,同样,拥塞消失的时候好办,监控剩余带宽,然后计算要增加的窗口,这里还可以考虑QOS和优先级。拥塞和不拥塞就在最大带宽上下波动,这个振幅越小,平均带宽利用率越高,但这个考虑在最大带宽比较固定下比较有效,实际上,大部分供应商的带宽利用率是不可能100%的,也就是说商业用户和电信运营商之间的带宽租用是有SLA保证的,也就是企业网用户应该更容易使用这个算法,当然此时拥塞管理也要考虑企业分支拥塞的情况,也就是整个系统应该把和分支机构之间的带宽都监控起来统一考虑TCP的拥塞管理。但是operator和个人用户之间对internet是从来不保证SLA的,所以如果是个人用户端发生拥塞,而不是在服务端,那么这些用户的处理就不适合按照服务端的带宽拥塞程度处理,他们要优先被缩小,靠后被扩大。重传最小情况下的最大带宽利用率,TCP无论怎么优化,对于通用的情况,很难有50%的优化,否则之前的TCP协议就是个失败的协议,而这种情况发生的可能性很小

  22. hritian 于 2010-06-25 11:44 上午

    既然谈到了HSTCP,可以多说两句,HSTCP的一个核心思路是在高带宽时延积网络的情况下,即使网络不因为拥塞丢包也无法达到网络带宽的高利用率。原因是由于物理错误的丢包,它基于物理错的的丢包率公式提出了一个算法,使得我们在high BDP网络下仍然能够取的高利用率。
    HSTCP最大的贡献不是它的算法有多牛而是在于自她开始出现了高速网络拥塞控制的研究高潮,现在这一块比较公认的主要是BIC/CUBIC HTCP(LINUX) CTCP(WIN7)和FAST
    从文献来看FAST和HSTCP一样,只是通过拥塞窗口的调整来增加带宽利用率。
    关于协议优化,我的观点是:不是更快,而是更稳定。尤其是在国内这种环境下,往往终端的带宽有限,还到不了high BDP网络的环境,我们往往要面对的高丢包、中时延和小带宽这样一个局面。这种状态下如何充分利用终端带宽是现在协议优化的主要目标。
    我前面讨论的单单是协议优化,不考虑别的因素,所以我说单边加速就可以充分利用终端带宽了。

  23. hritian 于 2010-06-25 11:59 上午

    to理客兄:我非常赞同你那个思路,在HSTCP提出的同时,拥塞控制领域还有个方向叫做explicit congestion control(XCP),他的核心思想就是利用路由的信息来决定发送速率。
    现在的协议优化其实最有吸引力的就是在没有SLA保证的情况下保证网络的服务质量。
    我一直在推崇所谓的四层qos的思路,就是在网络质量无法保证的情况下,通过四层的算法来保证网络服务质量。
    协议优化应该是对整个tcp协议栈的改造,而不仅仅是一个拥塞控制算法,不知道fast soft现在做成什么样了。如果仅仅是拥塞窗口的调整,那我认为将会非常没有竞争力。

  24. 理客 于 2010-06-25 2:34 下午

    IP网络本质之初是没有IP层的QOS的,L4 QOS是本质,但是纯L4 QOS可能也会有一些难以解决的问题,如何能用尽量简单有效的和L2/L3 QOS结合的L4QOS的模型和算法,应该在以后的internet应用中有不错的前景,比如skype对internet IP voice的处理。

  25. 理客 于 2010-06-25 2:57 下午

    又看了一下三个专利的名字简介,从字面看其内容就是这个意思,原理可能不复杂,但完成经过实际网络检测的商用算法模型就不容易了,当然我是TCP的门外汉,只了解一点基本的皮毛

  26. 于 2010-06-25 4:17 下午

    2位是专门研究tcp的博士吧?分析很深刻啊!学习了。
    理客兄,是否能指条tcp优化的方向?或者好的论文。

  27. 理客 于 2010-06-25 7:03 下午

    to辉:很抱歉,我不是,还是请hritian指点一下

  28. fll 于 2010-06-26 4:20 上午

    针对于FastTCP来说,FastTCP宣称的是基于时延的拥塞控制算法,相对BICTCP和CUBIC的依旧基于丢包的优化来说,在整体上有一定的优势。但一直没有弄明白的就是如何保持和普通TCP的竞争关系,例如Vegas一样。但是在中国的网络里面,仅靠这一个单边想做到很大的效果个人觉得不太可能,这是中国企业和国外的区别,国外可能觉得5倍的效果是很不错的,但是在国内内部各种应用的复杂性,信息化建设方面远比不过,对他们来说很有可能解决的问题不大。
    至于单边优化来说,既然有很好的双边部署方案,我相信企业不会再吝啬一点而只想购买一台设备,双边达到的效果远远比单边要多得多,这个可以从Riverbed,甚至国内的厂商所占有的市场和FastSoft类似的单边技术所占有的对比可以看出来。

  29. EFG 于 2010-06-26 9:13 下午

    楼上的兄弟已经分析得很清楚了,技术我不再多说。其实在中国解决带宽至少不是5年内的事情,很多用户其实带宽足够了,特别是在我们政府行业。最主要是解决应用问题,因此应用加速和优化才是主要矛盾。

  30. limbo 于 2010-06-26 10:24 下午

    to EFG: 基于应用的加速难道是QOS要做到应用层吗? 比如说,BT是不是也可以算一种?

  31. fll 于 2010-06-27 3:53 上午

    to limbo:双边部署来说应用加速是必不可少的手段,可以看下Riverbed和深信服能够支持的应用种类就知道了。

  32. hritian 于 2010-06-27 5:20 上午

    我一直都没有完全理解,所谓的应用交付是个什么概念。不知道哪位大侠可以解释一下。
    我从传输层的角度来说,下载型,其实单边(发送端)是能够做很多事情的(从1kB提升到100KB是完全可以做到的),如果是交互型,双边还是必要的,而且交互型应用的tcp优化要难做的多的多。窗口调整几乎毫无价值。
    个人认为现在需要用双边主要是三个问题,一个是压根就不用tcp了,走的是类FEC编码的udp包,需要双边来编解码;另一个是终端带宽是瓶颈的时候,压缩和缓存节省带宽;最后是交互型应用,双方既是发送方,又是接收方。

  33. 于 2010-06-27 6:15 上午

    to hritian
    类FEC编码的udp包,如果丢包个数超过解码最少数目,该怎么解决么?使用重传机制,或者认为这种概率极低,无视之?有相应的论文,给小弟指点下么?

  34. limbo 于 2010-06-27 6:02 下午

    我看了深信服的网站,他们自称能做到关键业务的加速,他们是双边加速吗?那应该两边的部署同样的产品吧?

    还有就是TCP如何能实现关键业务的识别的?是基于端口,或者是更加高级的技术:比如说模式匹配?

    Riverbed似乎总是集中在Tcp connections 的加速上,没有深信服说得详细。

  35. silenthunter 于 2010-06-27 9:48 下午

    To hritian
    应用交付一个新的网络名词,可能会是继路由交换、网络安全之后的下一项网络基础设施。这个概念最早应该是F5提出来的吧,现在国内外厂商都在炒这个概念。
    应用交付可以说一系列的解决方案,这个方案的目的是提高用户关键业务的交付质量。这里的质量只要是交付的效率、可靠性的提高和数据传输的安全性。
    应用交付用到的技术主要包括:流量控制、广域网加速、负载均衡(链路和服务器)、应用虚拟化等。
    这些是我的个人理解,仅供参考。

  36. silenthunter 于 2010-06-27 9:54 下午

    To limbo
    深信服的加速到目前为止应该是必须双边部署的,因为它是将TCP转换成自己的私有协议来做的协议优化。
    关键业务的识别,我了解华夏创新是通过IP+端口+协议来区分的。

  37. Forfor 于 2010-06-27 10:39 下午

    to silenthunter
    如果深信服的加速技术方案是双边部署的,在推广时应该有很大的客户压力吧?如华夏的LAN加速仅通过IP+端口+协议来区分的话,那一般的FW的QoS和Policy结合都能实现了啊,这样分析的话,这两款产品的竞争力都会很容易受到外界打压啊。

    F5在美国的几十篇专利中均声明了其是单边加速并提到了一些智能算法,当然都是一带而过。我司在测试F5的产品时,其部署确实是可以采用单边加速,且是有加速效果的,具体统计数字我不记得了。个人认为现有LAN加速产品中应该还是有更为深厚的技术,silenthunter在此方面有否进一步的深入分析?

  38. silenthunter 于 2010-06-27 10:43 下午

    http://www.njeit.cn/show.aspx?id=915&cid=82
    这篇文章是介绍华夏创新的TCP加速技术的(zetatcp的TCP单边加速技术)

  39. Forfor 于 2010-06-27 10:50 下午

    to silenthunter
    拜读中,谢谢。

  40. fll 于 2010-06-27 11:05 下午

    to Forfor:那一般的FW的QoS和Policy结合都能实现了啊,这样分析的话,这两款产品的竞争力都会很容易受到外界打压啊。

    防火墙的QoS功能算是比较简单的,光QoS就有Packeteer这种专业的设备,一个QoS是解决不了问题的。

  41. 于 2010-06-27 11:05 下午

    深信服的加速主要是靠缓存,减少传输的流量实现的,他的私有协议,就是那个基于UDP的可靠传输,我估计是用的开源udt协议改的(或者根本没改)。自己实现个传输协议还是蛮难的吧。
    单边加速的前提是带宽充足,包延时和丢包明显的网络。可我国的网络环境是这样么?

  42. silenthunter 于 2010-06-27 11:08 下午

    To Forfor
    是wan加速哦,TCP在设计之初就是没有考虑到在Wan环境的高延迟和高丢包率,所以才有了加速厂商的市场。
    双边加速只能针对特定用户群进行加速,单边加速可以对非特定用户和特定用户都可以加速,单边加速适用环境更广泛。但是单边部署的时候只能用到协议优化,并不能使用压缩和缓存,因此对于总部和分支机构之间还是推荐双边部署。据我了解目前就华夏创新和FastSoft有单边加速的技术。至于F5提到的单边加速我不确定,因为F5是做服务器负载均衡起家的厂商,它利用SSL卸载和连接复用技术可以减轻服务器的负担,来到加速的效果。但是这个加速不是加速的网络而是加速的服务器,虽然最终结果都是加速。
    通过IP+端口+协议来区分其实是完全可以满足用户对关键应用加速的需求的。因为企业的关键应用都是由固定的服务器来提供服务器的,也不需要DPI技术来深度识别。你提到的用户压力我不太理解,是不是要求做7层的应用识别?

  43. silenthunter 于 2010-06-27 11:22 下午

    To 辉
    很赞同你的观点(单边加速的前提是带宽充足,包延时和丢包明显的网络),跨运营商的环境应该接近这种情况。还有就是多高的延迟才算是高延迟?多高的丢包率才是高丢包?其实这个也是延迟、丢包与TCP传输效率之间的影响密切相关的。
    我测试过在联通IDC机房的单边加速,带宽利用率从20%提升到100%。相当于每个连接平均加速5倍。

  44. 于 2010-06-28 12:46 上午

    我觉的单边加速,走低端,嵌入式小盒子,降低单个价格,走销量路线比较合适些,个人感觉。呵呵

  45. shark 于 2010-06-28 2:17 上午

    to “辉” 您所说的“顺便说一句,我说shark ,你代理国外的单边加速,价格估计得10w+ rmb了吧。如果无法在客户的环境演示出好的效果,那客户可能会选择把这笔钱拿去买带宽了吧,毕竟国内广域网带宽还是很便宜的。加速这玩意,我感觉主要还是用在昂贵的专线用户那里,双边加速效果会好些。” 正是我所困惑的地方,您说的不错,fastsoft东西够贵,我们也在评估fastsoft是否适应国内市场。请问辉兄,在国内增加带宽是否能成比例提速,特别是比如PLM/ERP等一对多的应用加速?OMG,国内的带宽便宜啊。

  46. 理客 于 2010-06-28 2:53 上午

    这种有innovation的公开内容涉及技术实现的内容是不会透露一点核心的。实际上大家的实现算法模型各有差异,但大体idea类似,两个核心
    1、如何精确的检查到丢包及其在哪里:服务端、网络、客户端,实际实现中这种检查应该更多的在服务端(ICP类的时候),即使这样,单端如何精确检测?如果运营商能配合是最好的,比如可以用Y.1731协议提供更精确的以太链路的质量监控,对于企业网,可以提供更多的E2E的检查,如果运营商能提供这种服务,对TCP加速应该是非常有益的,当然,没有运营商,其业务也可以自己做,同时还可以随时监控和运营商的SLA,这对企业网使用ETH专线情况下,还是很有意义的(SDH专线是硬管道,没有收敛问题)。对于普通个人用户,只能在服务端租用链路上了。在实际应用中,企业网应用(除了internet,是不需要)的带宽是可预测的,对这个技术的需求渴望不好说。网站类应用是非常希望TCP加速的,因为可以在同样的带宽下接入更多的用户,这是很有意义的,但此类用户的优化效果很难超过企业网应用
    2、检测到丢包后进行TCP窗口缩小处理,这里也许不单单是对已经TCP丢包的session处理,关键的是在快丢包前就开始处理,要计算TCP准备扩张的幅度,这个幅度如果不在真正丢包前开始缩小,那么下面立即就开始丢包,所以必须让其涨幅超过丢包带宽前控制,但不能控制合适,否则低于可用带宽过度,就矫枉过正了。增加窗口的时候类似,不要超了可用带宽或这超得很小
    总之,这个实现有多好决定于丢包检查/带宽监控的精确度和TCP窗口缩放模型算法两个关键因素的无缝配合,无缝配合意味这要从所有丢包位置有相应调整算法,当然十全十美是目标,但实际上只要能适应网络中80%的情况就可以算好了

  47. 于 2010-06-28 5:15 上午

    to shark
    国内环境下,一般同一个运营商的网络,包延时不大,丢包也不严重,不过跨运营商,网络就会恶劣很多,单边加速效果会明显些。
    之前silenthunter说的,一般来说,单边加速在跨运营商网络测试,效果可能会比较明显。
    不过现在不少单位都是两条线,一条电信一条网通啥的,深信服的设备可以根据访问者的ip判断它是那个运营商的,那么应答流量就走对应的运营商。
    从商业的角度来说,我感觉,可能用fast的设备,给客户测试,可能会有的效果明显有的不明显。买你们的设备是否划算那就得好好演示了。
    华夏创新的我没用过,不过我相信价格会比fast便宜不少,国内的一般都能做到国外领先产品的70%,但是价格可以做到国外产品的一半以下。你可以找silenthunter,测试下华夏创新的试试撒,看看性价比哪个高些。呵呵。

  48. hritian 于 2010-06-28 5:50 下午

    to shark:ERP这类的应用是最难做的tcp加速,增加带宽和提高服务质量关系很小。
    to理客:网站的tcp优化主要目的还是提高网络服务质量,和节省带宽无关。而且网站的评测方法不能用提高几倍了,而是“达标率”更为合适。

  49. Forfor 于 2010-06-28 7:51 下午

    # silenthunter 于 2010-06-27 11:08 pm
    >>>你提到的用户压力我不太理解,是不是要求做7层的应用识别?

    我指的是双边加速需要在企业总部出口部署设备,分部也部署设备或者客户端,这种情况下,有些用户会不太乐意,会遭遇推广的难度。:-)

  50. silenthunter 于 2010-06-28 9:38 下午

    49.Forfor
    双边部署的成本肯定会更高,管理、维护难度也增大。但是在某些应用场景,双边部署的价值是可以得到比单边部署更好的加速效果。
    其实我认为在具体的环境中,单边加速比较适合用在(TCP的应用)视频直播、卫星线路、跨运营商线路、文件分发网络、3G加速、IDC加速。

  51. shark 于 2010-06-29 2:07 上午

    to silenthunter:
    您对APPEX及双边/单边加速有深刻的见解,不介意的话,是否可给我联系方式,谢谢。 我的邮箱地址为hippo at 189.cn

    to hritian:“ERP这类的应用是最难做的tcp加速,增加带宽和提高服务质量关系很小。”愿闻其详,多谢。

  52. yhb 于 2010-06-29 10:51 下午

    高兴地看到大家对广域网加速做了如此多的探讨,我想提出几个观点。
    1、解决应用在广域网传输的性能的技术(可以叫应用交付),应该包括三部分。一是负载均衡,它是基础,是保障;二是流量控制,没有好的流量控制技术(控制非关键应用流量),广域网加速很难实现预期的效果;三是广域网加速技术,包括协议优化、对象缓存、字节缓存、数据压缩等。
    2、TCP单边加速技术具有创新性。而且在高延迟、丢包、长距离传输环境会有非常好的效果。特别是跨运营商的环境、无线网络等。单边TCP加速并非万能的。
    3、FASTSOFT公司主要从“延迟”入手解决TCP效能问题,华夏创新主要从“丢包”入手。可以说是目标一致,路线不同而已。但华夏创新的优势之处在于:可以实现流量的双向加速,而FASTSOFT只能实现上传流量加速。
    4、还有华夏创新已经实现了负载均衡、流量控制、广域网加速技术的融合,这样的“统一流量管理”或者“统一应用交付”在中国将具有更加广泛的市场前景。

  53. droplet 于 2010-06-30 2:13 上午

    >3、FASTSOFT公司主要从“延迟”入手解决TCP效>能问题,华夏创新主要从“丢包”入手。可以说是>目标一致,路线不同而已。但华夏创新的优势之处>在于:可以实现流量的双向加速,而FASTSOFT只
    >能实现上传流量加速。
    这是什么意思?你说说重传的原因吗?如果重传发生,不抑制窗口,会不会导致网关的压力增大?
    负载均衡是服务器端用的技术;流量控制是客户端的技术,这两个有同时使用的需求吗?

  54. Libo 于 2010-06-30 7:33 上午

    老大现身了,热闹啊!

  55. 小说下载 于 2010-06-30 8:40 上午

    (⊙v⊙)嗯 不错 \(^o^)/~

  56. gh 于 2010-07-01 4:26 上午

    RiverBed我们在用,不过我不在网络部门,所以只能说一下我了解到情况:
    主要做了以下几个方面的工作吧
    1.数据压缩和数据缓存
    2.Dedup(重复数据删除),这东西主要在存储方面使用,但是你想要是没有这么一个东西,总部给每个分公司都发一个10M的email,那早上大家一起打开就别想干活了。
    3.协议方面的一些调整

    这种产品,我认为用于国外跟国内有内部vpn连接的市场比较好。有些地方网络,比如非洲到中国,会非常差。

  57. shark 于 2010-07-01 7:54 下午

    感谢”gh“兄给出RiverBed的主要应用实例,有一点我一直不理解,即:
    “这种产品(注:Fastsoft),我认为用于国外跟国内有内部vpn连接的市场比较好。有些地方网络,比如非洲到中国,会非常差。”
    VPN提供商,在其VPN解决方案里是包含有VPN加速方案的(如国内VPN领袖深信服)。而且据深信服案例所称,其VPN加速效果卓越。

    我的困惑就在于:VPN/虚拟桌面等应用既然已有成熟配套的加速方案,为何”gh”兄认为象Fastsoft这样的单边加速产品比较适合此类市场?

    盼”gh”兄及高人指点。

  58. yhb 于 2010-07-02 4:05 上午

    回复“DROPLET”
    1、数据在网络中传输有”上行”、“下行”之分,FASTSOFT相对其设备部署位置,只能对“上行”TCP流量加速,对远端发送过来的“下行”TCP流量不能够加速。
    2、其实华夏创新技术的本质之一,是可以“遥控”远端主机的发送行为,实现“下行”流量加速,并实现对“下行”带宽的精确管理(包括对下行TCP流量的加速与减速、对下行UDP应用流量的减速)。
    3、至于单边TCP加速的原理,如果较为理解TCP/IP协议,不复杂。但知道原理用处不大,因为要真正实现加速效果并实现大流量支持,那是个“实践”活,是千百次的锤炼。

  59. hritian 于 2010-07-02 7:17 上午

    至于单边TCP加速的原理,如果较为理解TCP/IP协议,不复杂。但知道原理用处不大,因为要真正实现加速效果并实现大流量支持,那是个“实践”活,是千百次的锤炼。

    确实是如此,很多时候一句话就能说清楚的idea,要真的做到位往往需要很长时间的磨砺。

    tcp协议优化,上传加速、下载流量控制,其实难度都不大。
    下载加速、交互型应用的加速相对来说要困难一些,尤其是下载加速。

  60. fly 于 2010-07-07 1:34 上午

    其实,加速产品在国内的市场还相对较小,根据我了解到的数据,排在前面的厂商为:cisco、riverbed、sinfor(深信服),华夏做的相对短一些,还没形成积累,做得好的厂商一般都是讲某个行业完全吃透,使得全系统部署才能形成业绩积累,如水电工程局下属,通过内部招标就备选了三个供应商,貌似是H3C、sinfor(深信服)还有一个厂商,但整体加速在小企业端明显都不成功,这一个是由于带宽便宜的客观现状决定的,另一个就是加速的效果在实测中与实际情况有很大关系,提速的效果也从几倍到几十倍不等,如果是测试效果不佳,用户上这套设备的说服力就不够了,而从技术来看,riverbed的技术无疑是代表了最主流的,cisco的牛B之处在于人家是一个高端路由加多块板卡即可,深信服已经基本把riverbed的技术学的差不多了,现在就看后续有没创新,华夏创新等厂商的单边加速听一线的同事说测试很容易显示效果不佳,但是也不能一竿子否定,说白了还是跟现实的环境有很大关系的,单边现阶段来说还是有点非主流。

  61. 比蒙传奇 于 2010-07-07 3:35 上午

    牛。。。。看不懂。。。

  62. 小说下载 于 2010-07-12 6:38 上午

    这是什么学。。。

  63. veteran 于 2010-07-13 12:37 上午

    应用交付用到的技术主要包括:流量控制、广域网加速、负载均衡(链路和服务器)、应用虚拟化等。(很赞同silenthunter的观点。)

    一,市场前景
    个人认为应用交付是个大市场,目前处于萌芽发展阶段,而现阶段应用交付产品会在新兴经济体(金砖四国)会有很大的市场。因为电信基础设施网络增长的速度和IT应用发展的速度的矛盾长期存。这就意味着未来的网络世界,各种应用层出不穷,而带宽资源会成为应用发展的瓶颈。所以说,这是一个特别大的市场。

    二,竞争格局
    鄙人认为这个市场一旦被传统提供网络基础设施解决方案的厂商(华为,思科等)重视。F5,Citrix,Array,深信服,华夏创新,云速网络等很有可能会成为网络设备巨头门收购或蚕食的对象。

    三,技术趋势
    中国改革开放时期流行一句话:“要想富,先修路”。这个路就好比带宽,在路上跑的所有介质(人,车,轮船,飞机。。。鱼虫鸟兽等等)就好比为各种IT应用(路延伸下,可以是陆地上的路,空中的路,水中的路)。未来的应用交付产品应该偏向于统一架构。其产品有流控的功能,有上网行为管理的功能,有WAN优化(应用加速)的功能,最好能把负载均衡技术和安全网关技术以及SBC技术整合在一起。因为帮企业构建一个快速、安全、高可用、可视、可控的网络正是应用交付的终极目标。

  64. veteran 于 2010-07-13 8:21 上午

    应用交付用到的技术主要包括:流量控制、广域网加速、负载均衡(链路和服务器)、应用虚拟化等。(很赞同silenthunter的观点。)
    一,市场前景
    个人认为应用交付是个大市场,目前处于萌芽发展阶段,而现阶段应用交付产品会在新兴经济体(金砖四国)会有很大的市场。因为电信基础设施网络增长的速度和IT应用发展的速度的矛盾长期存。这就意味着未来的网络世界,各种应用层出不穷,而带宽资源会成为应用发展的瓶颈。所以说,这是一个特别大的市场。
    二,竞争格局
    鄙人认为这个市场一旦被传统提供网络基础设施解决方案的厂商(华为,思科等)重视。F5,Citrix,Array,深信服,华夏创新,云速网络等很有可能会成为网络设备巨头门收购或蚕食的对象。
    三,技术趋势
    中国改革开放时期流行一句话:“要想富,先修路”。这个路就好比带宽,在路上跑的所有介质(人,车,轮船,飞机。。。鱼虫鸟兽等等)就好比为各种IT应用(路延伸下,可以是陆地上的路,空中的路,水中的路)。未来的应用交付产品应该偏向于统一架构。其产品有流控的功能,有上网行为管理的功能,有WAN优化(应用加速)的功能,最好能把负载均衡技术和安全网关技术以及SBC技术整合在一起。因为帮企业构建一个快速、安全、高可用、可视、可控的网络正是应用交付的终极目标。

  65. zeroflag 于 2010-07-13 10:12 下午

    记得几年前,关于WAN加速在公司内部做了一个讨论。得出的结论是,只在有瞬时突发大流量环境下有用,否则从成本角度考虑,扩带宽更加便宜。
    瞬时突发大流量的环境包括:定期远距离备份(比如每个月备份一次数据到远端,如果每天那还是扩带宽好了)、税务的集中保税(每个月就3天流量巨大,平时都闲着)、公务员报考(每年一次)等等……

  66. TimYG 于 2010-07-14 2:08 上午

    to zeroflag
    WAN加速只是应用交付产品提升用户体验的其中一个功能,拿出来做独立产品感觉意义不大,除了扔在服务器前端类似fastsoft这样的部署方式,不过这个市场能有多大呢?
    如果部署在企事业单位网络前端,则WAN加速必然和流控,链路负载均衡和优化等组和成一个产品,通过集合体综合提升用户体验,还是很有意义的,感觉市场前景也要好一些。

  67. Ryan Ge 于 2010-07-20 1:02 上午

    shark: It looks good product for Carriers without the client software, how about the real performance for web acceleration? Do you have a success case in China?

    Thanks,

    Ryan

  68. shark 于 2010-07-20 2:15 上午

    Dear Ryan,
    We have success case in China.Sorry,we sign NDA with Fastsoft,so if you want to know more info pls Email to hippo.shark@gmail.com.

    Rgds

    Shark

  69. xubuyu 于 2010-07-22 9:30 下午

    各位大侠,技术上的讨论不如实际测试,我有Fastsoft国内测试样机,WAN口50M,需要的朋友可以写邮件给我,我公司在上海。

  70. xubuyu 于 2010-07-22 9:55 下午
  71. TcpOutDoorMan 于 2010-07-27 1:36 上午

    59楼hiritian大人,
    您说单边TCP加速的原理不复杂,能否简单的给俺这个门外汉描述一下?
    (话题范围就限定在单边TCP加速,不涉及非关键应用例如P2P的控制以及应用协议的冗余优化)

    看了前面38楼介绍的zetatcp,不过它的描述太笼统了,第一/第二/第三都语焉不详:(

    有几个问题吧:(假设拓扑为: 客户端–>内网–>加速设备–>广域网–>服务器)

    a. 单边加速的设备一般采用什么样的软件架构?TCP代理(把连接一分为二)?有非代理的实现吗?

    b. 精确的丢包判断是为了解决什么问题?需要哪些信息才能做到精确的丢包判断?中间设备(非终端)有可能做到精确判断吗?

    c. 如何加速本地(内网)的上传行为?向客户端屏蔽丢包(避免用户拥塞窗口缩小)?如果替客户端重传的话岂不是得缓存所有的数据报文?

    d. 如何加速远端的下载行为?感觉中间设备只能抑制远端的的发送(通过修改/减少TCP报文的WINDOW大小),又如何能加速远端的发送呢(广域网一侧的丢包/延迟是单边加速设备控制不到的范围啊)?

  72. OLDSTONE 于 2010-07-27 4:08 上午

    我感觉所谓修正WINDOWSIZE的概念,其实在现实网络中确实有用处,其主要原因是我们很多做资源的人没有真正理解网络传输的实现。但这个网络加速,不仅仅是调整WINDOWSIZE就能解决的一个问题。
    如果你经常玩游戏和QQ传输,你可以用软件抓一下看看都是什么样子的包大小,同时你可以看看视频的包会是什么样子,其实你如果你几年前就开始注意会发现如果不考虑带宽增长,这个包的大小是有讲究的。这就是为什么以前有批人喧嚣所谓小包优先的概念,虽然是个不正确的说法,但确实有效在当时。
    网络单边加速,如果只通过WINDOWSIZE调整是解决不了多少问题的,而且这个单边加速不是用于城域网或者广域网的,而真正的价值是在于手机上网,其核心思想是对可进行文本页面和静态内容进行压缩,对动态视频编码进行优化减少带宽消耗,我指的是在同样QOS等级的情况下,如果你应用QOS,那是另外一个问题,但不影响在一个等级下,这些仍然有效。目前这种压缩主流浏览器都可以接收。
    目前在手机上网领域可实现单双边加速的厂商国外有BYTEMOBILE他们做的不错,他们有个核心专利就是视频优化压缩的技术,国内没有明显竞争对手目前,但从整体测试来看,其对浏览类加速非常明显,对视频效果明显,但对实时交互游戏效果不是很明显。
    TO 71楼,你问的ABCD问题,其实目前应用软件都解决,不需要在网络折腾什么,除非是做资源的服务商太业余,那我只能做QOS保障他,但也不会在网络侧通过WINDOWS去调整什么,ALLIP的承载网WINDOWS值都设置最高的,不动态调整,把压力都传递给应用实现。记住网络不是万能的,能用应用实现的,不要用网络实现。

  73. hritian 于 2010-07-27 7:39 下午

    congestion windows 的调整确实仅仅是优化的很小的一部分,tcp协议优化本质上应该是何时何地发送什么包。
    压缩对于流媒体和网页加速有用,是因为在相同连接速率下,需要发送的带宽少了,所以下载时间肯定减少,这个是需要双边部署的。如果不需要双边部署,那肯定是用了更高压缩率的视频编码和文本压缩,那就没什么意思了。
    对于游戏加速肯定是没有价值的,游戏加速是交互性应用,是时延和丢包敏感型应用,对带宽不敏感,而无线网络又是物理丢包率很高的网络,tcp协议现在的算法在面对这种交互型应用上是有非常大的问题的,尤其是丢包情况下,效率极为低下。
    我不太明白72楼最后的观点,做资源的服务商能控制一个连接所有经过路由的网络?如果可以,那这样的成本和报价会比通常的高上很多倍吧。

  74. TcpOutDoorMan 于 2010-07-28 2:06 上午

    To 69楼(xubuyu )
    请问单边加速设备一般怎么部署?放在企业出口?对内网用户透明吗?

  75. TcpOutDoorMan 于 2010-07-28 2:39 上午

    to all:
    单边加速的英文该怎么说?one side or one way?学术界有专门的术语吗?

  76. xubuyu 于 2010-07-28 8:29 下午

    单边加速,也可称为非对称方案(部署)
    “Asymmetric Solutions”
    但是FastSoft在部署上算是,在总体上超越了单边加速,因为完全透明化,没有客户端。

    国外称3种类型:
    1.Symmetric Solutions
    代表厂商有Aspera,Signiant,其都有完整的企业版套件(软件结合硬件方式)

    2.Asymmetirc Solutions
    代表厂商有F5 Big-IP,Citrix NetScaler,Cisco’s ACE,Juniper’s DX

    3.Outsourced Solutions在线业务外包
    CDN厂商基本都是这个类型,代表厂商有Akamai,LimeLight Networks,Panther Express,Level 3,Internap
    全球最大的数字交付巨头之一LimeLight在全球已经部署了FastSoft。

    FastSoft称其为一个创新的方案:无客户端互联网加速。
    其特点简称:
    No caching.No compressin.No client.

    部署非常简单-部署在信息数据的源头,即服务器端,路由器或防火墙内,加速数据向客户端发送的速度,提高已有网络带宽的访问传输效率,而客户端发回的数据不会被加速(除非双端部署)。

  77. xubuyu 于 2010-07-29 6:59 下午

    我们准备建立国内技术服务及进口渠道,欢迎各位有志向推广此产品的朋友建立合作伙伴!

  78. xubuyu 于 2010-09-02 8:37 上午

    FastSoft首部中文版资料推出,需要的朋友请邮件给我。

  79. 吴剑 于 2010-09-07 7:16 下午

    这个不稀奇啊,华夏创新08年也出了单边广域网加速的产品(有需要资料的发我邮件),好像是全国第一款能够单边加速的广域网加速产品,据说老总是联想网御的某位领导跳出来开得一个公司,而且我到客户真实环境下测试过,基本上对一般TCP的应用能够加速的2~5倍,最高能到10倍。还是挺不错的一个产品。

  80. TcpOutDoorMan 于 2010-09-08 3:06 上午

    to 78楼,

    能不能给我发一份FastSoft的资料啊,邮件tcp_newbie@126.com

    to 79楼,

    能不能给我发一份华夏创新的资料啊,邮件tcp_newbie@126.com

  81. xubuyu 于 2010-09-08 8:57 下午

    FastSoft目前已在国内部分地区的商业客户进行测试,为了帮助用户了解此产品,我们如实地评估客户自身广域网和局域网的实际情况,分析是否有性能瓶颈,以及消除的可行性,目的就是为了让客户真实地感受Fastsoft为其带来加速的优势所在。
    同时,我们也对FastSoft在面临各种复杂问题网络的客户时,对其分析是否适用于他们的业务,并且提出改善其网络架构的方案,以便于IT经理了解我们不仅是做产品,我们更是在做一个Solution.

  82. xubuyu 于 2010-09-08 9:01 下午

    各位朋友,如果需要FastSoft的中文资料,请发邮件到我的信箱,写明贵公司的地址和收件人姓名,我们会在第一时间送达您的手上。
    目前我们只提供中文/英文印刷品,谢谢各位的关注。

  83. xubuyu 于 2010-09-08 9:03 下午

    我的邮箱:
    xu.buyu@trustfuture.com

  84. space 于 2010-09-17 7:51 下午

    这种产品有市场吗?

  85. space 于 2010-09-17 7:52 下午

    我以前在深信服, 我感觉其实就是内部压缩后进行传输而已。不知道现在搞的咋样了。

  86. xubuyu 于 2010-09-18 7:48 上午

    FastSoft:
    No caching. No compression. No client.

  87. silenthunter102 于 2010-09-19 1:18 上午

    这种产品主要针对非特定用户进行加速,比如:大型网站、saas、CDN、ICP等用户。在跨运营商和无线链路环境有不错效果。
    目前有两家厂商AppEx和FastSoft可以实现单边加速(非对称加速)。

  88. xubuyu 于 2010-09-29 9:15 下午

    青岛测试某企业,连接至加拿大,国内链路为100M共享带宽,向国外传输效率比较低,数据量为实时小数据包,我们测试下来,加速效果最高达到40倍,但是因为其本身数据量较小及网络瓶颈原因,我们不建议其使用FastSoft,希望各位有兴趣的朋友能够知道我们的实际测试情况及建议。

  89. silenthunter102 于 2010-10-12 10:45 下午

    To:xubuyu
    “加速效果最高达到40倍,但是因为其本身数据量较小及网络瓶颈原因,我们不建议其使用FastSoft”这里没有搞懂。这么好的效果为什么不用呢?是因为价格还是其他因素?

  90. xubuyu 于 2010-10-13 7:45 下午

    我会另外开贴,把客户的数据图表贴上去,以便于讨论,谢谢关注!

  91. xubuyu 于 2010-10-16 1:30 上午
  92. 陈怀临 于 2011-04-14 5:43 下午

    最近, RiverBed的RVBD股价暴跌。。。首席受伤很严重。。。问了几个内鬼。似乎是Data Center或者云加速的泡泡还没有开始落地。。。

    有兴趣的读者或者知情人给弟兄们讲讲课。

  93. michael xu 于 2011-04-15 12:50 上午

    其实RiverBed等双端加速和FastSoft的市场并不矛盾,甚至可以说FS能够是所有互联网WAN优化的互补。
    很想了解陈总的新闻内幕,呵呵。

  94. ballack 于 2011-04-15 1:13 上午

    rvbd也在搞云存储,首席知道那么多内鬼,嘿嘿,求转转他们技术内幕消息

  95. 理客 于 2011-04-15 1:39 上午

    网络加速在无线宽带从smart terminal到mobile backhaul大有市场

  96. 二大妈 于 2011-04-15 11:54 下午

    二大妈不太看好单独TCP加速产品,500倍只是宣传工具,如果是100Mbps的带宽,loss=%36, rtt = 1s, 根据TCP计算公式 rate = mss /(rtt *sqrt(loss)), 用户最多只能达到 ~ 1.5KB / (1 * 0.6) = 20kbps, 但是如果loss是%36,理论上讲带宽应该也能有64Mbps,所以差别是3200倍!! 所以500倍实在糊弄外行的,不用严肃对待。更重要的是上面比较的是一个TCP的情况,如果是多个TCP,比如有3200 TCP连接,那么加速效果就一点都没有了。都能用到64Mbps。

    此外还有很多因素会制约TCP优化产品的市场。比如新的操作系统都在不断改进TCP性能,使得优化空间变小。比如vista就做了一些接受窗口自适应的改进。还有selective ACK很好的解决了TCP loss的问题。还有很多protocol比如说SMB,有很多request和response protocol本身的dependence,如果只是加速数据传输,也未必有很大的效果。

    二大妈自认对TCP加速颇有些研究,如果有人有兴趣,俺有时间也贡献一个“二大妈谈TCP优化”,详细地谈谈有哪些手段来提高TCP的性能。

  97. Panabit 于 2011-04-16 12:09 上午

    欢迎楼上在弯曲开坛!

  98. kevin 于 2011-04-16 1:34 上午

    我有一个问题。在下载的时候经常会遇到这种情况:比如一开始下载头一秒显示的速率是800kB/s,然后下降到500。最终稳定在200多kB/b。普遍现象,但是不知道答案。

    我想到可能的几个原因

    1.被car了。但是不像,因为200多k离我的car还很远
    2.windows/下载工具统计问题。
    3.TCP拥塞机制开工了。window变小,最终稳定在某一值。如果是这种情况,假如我强制我的TCP窗保持很大且不变,这样我的网络能加速吗。因为这个时刻我不需要“拥塞控制”,我希望自私的榨取更大带宽哪怕网络拥塞

    请教下高人

  99. 理客 于 2011-04-16 6:33 上午

    欢迎二大妈大作揭密TCP/UDP加速在各种场景下的真实表现到底如何?之前也有不少关于加速的分析和测试在弯曲里,质疑的不多,但个人一直心存怀疑,但仅此而已,无知者无言

  100. xiudong 于 2011-04-16 8:57 上午

    回复下kevin:我觉得是第三点起到了作用,其实fastsoft只是解决了广域网上传输性能慢的一部分问题,riverbed和sangfor才是解决了一整套问题:1、数据冗余;2、TCP链接;3、应用协议交互过多;4、规律性丢包;5、应用流量带宽保障;等等,不过fastsoft的方案在对外进行应用发布的情况下比较适用,毕竟不可能在每个外部零散客户那装客户端或者部署硬件设备,但是实际效果来看对于企业来说对端部署的效果才好,TCP的优化只是其中一部分,冗余数据削减和带宽保障往往在用户的网络中表现得效果更为明显,就好比你脚痛的原因可能会有三个:1、鞋小了;2、走路过多;3、里面有个小石子;你只解决鞋小了在客户那边cover的问题太窄,效果难以保障。

  101. 理客 于 2011-04-16 11:06 上午

    如果装在samrt phone上,能有多大效果?
    甚至运营商也可以提供服务端,做双向加速

  102. xiudong 于 2011-04-17 7:05 上午

    回复楼上理客同学:smart phone上的客户端比较难说,笔记本上到是经常部署,在smart phone上深信服是在SSL VPN里面集成了一部分的加速技术,HTP技术之类,但相对支持的少,感觉可能会是个机会哈,毕竟3G网之类的应用越来越多。

  103. 理客 于 2011-04-17 8:51 上午

    如果真能有效果,并且有know how,搞一个免费的把用户粘住粘多,然后再把各种应用滚上去赚钱,这是WEB2.0常用的基本手法

  104. hritian 于 2011-04-19 5:07 上午

    TCP 协议优化,解决的最重要的不是更快的问题,而是更稳定的问题。
    优化的很多算法是要给予QoS的特性和网络环境来设计的(至少我们是这么做的),很难有一套鲁棒的算法。(交互型应用我们平均能减少接近20%的访问时间,高点率大幅降低;点播我们能把失败率减少一半;这种优化不会让人没价值吧)

    TCP协议优化,去抢企业市场肯定是抢不过RVBD和深信服了。但是网站市场就不一样了,双边的非TCP协议那一套根本就没用。而且我敢肯定,就算是深信服、RVBD有TCP协议优化的技术,如果没有跑网站的经验,所谓的提升多少都是扯淡;
    我看fastsoft的网站,他们的主要客户好像也是网站用户;

    ps:我和fastsoft没有任何关系。

  105. hritian 于 2011-04-19 5:14 上午

    回复理客:
    协议优化完全是可以解决smart phone的问题的,技术不是问题,关键是软件安装和引导流量的问题;

  106. hritian 于 2011-04-19 5:16 上午

    回复kevin:

    你说的那个问题,应该是慢启动阶段速率上去以后丢包,你又出在大时延网络下,sososo速率上不去;
    你发送端用的是哪个操作系统?

  107. kernelchina 于 2011-04-19 5:42 上午

    网站加一个前端优化?如果不是proxy或者load balancer,那会是什么东东?对任何操作系统都有效?

  108. kevin 于 2011-04-19 9:25 上午

    @106
    windows+ie。普遍情况

  109. billy 于 2011-05-17 1:12 上午

    貌似对网站提速很有吸引力,就不知效果如何了。

  110. Justin 于 2011-11-06 7:28 下午

    现在提到的优化好像都是基于high-speed long-latency networks。我实测过UDT,100Mb/S的网络环境,在高延迟的情况下,表现是非常完美,但是在其他环境都表现欠佳,在6.144Mb/S的环境下表现还不如TCP Reno。所以是否在低带宽的专线网络中TCP优化的效果是有限的,也没有看到说专门针对此环境的优化技术,在这种环境是否必须要双边部署,通过压缩和字节缓存提升速度。请大家指教

  111. Derek 于 2013-12-15 7:33 下午

    TCP CA这块的东东还有多大的潜力呢(^-^)

发表评论