发信人: ciert()
整理人: williamlong(2001-11-21 20:50:30), 站内信件
|
【 在 ciert (安安) 的大作中提到: 】
: 我对Oicq目前协议的初步看法
:
: 在粗略看了oicq采用的实现方式以后，我感觉非常失望。
: 理由如下，
: OICQ协议完全采用UDP封装，众所周知，UDP是不可靠
: 传输协议，但是效率比较高，同时协议封装和实现都很
: 简单。TCP协议比UDP协议消耗更多的CPU时间，相比而言
: 产生一个TCP连接和发送一个UDP包而言，TCP的开销很大，
: 这在服务器端更加明显。
: 但是，采用UDP包带来的首先是安全性问题。
呵呵，首先感谢这位网友的热心，不过还是想告诉你几点
1)下个版本的OICQ协议将全部采用128位不对称算法加密
2) 如果用TCP连接的话，请你给出一个能同时容纳10000个连接以上的方案
3) 建议你好好看看TCP连接的原理，它为什么能实现可靠连接，TCP并不是
比UDP的线路要高档一些，它也会丢包，但是它是把包重发机制封装了起
来，因此采用TCP连接和采用UDP连接所传输的数据量是差不多的，而且
在线路好的情况下，UDP的数据量要更小一些。
4) 你对重复发UDP包的机制判断有些错误，OICQ并不是拼命向服务器发包
直到有返回，而是间隔5秒，一般来说5秒都没有返回的时候这个包在
去的路上就丢了的可能性为50%，因此这样做带来的额外的开销对于服
务器而言并没有你所描述的那么重，相反，采用udp机制的节约下来的
开销已经远远抵了TCP永久连接的可怕开销
: 目前我对OICQ协议的实现方式的评价是：很差。
所以，在没有经过通盘考虑的情况下，不要妄下结论：）
不过还是非常感谢你对我们的关心和建议。
【 在 ciert (安安) 的大作中提到: 】
:
: 请看任何一个成功的C2C的电子商务站点。:) 或者例如hotmail之类的
: 免费mail站点。并发连接数都不小于5000，同时承担和OICQ相比不可比拟的
: 数据传输量。
喝喝，要知道http连接属于短连接模式，并且非常容易
平行扩展到很多台机器上，可是你见过同时容纳10000个
连接的聊天室吗，用tcp和服务器做通讯的类似的icq产品
也不是没有，可是你可以自己去问问他们服务器的负荷是
怎么样的
:
: 服务器与客户机之间的通讯确实可以部分/全部采用UDP，但是不应该用在
: 客户的互相通讯之中。
:
: 也可以包括著名的download站点，例如ftp.download.com
喝喝，似乎绝大多数ftp站点都不是无限制让用户连入的吧
:
: : 3) 建议你好好看看TCP连接的原理，它为什么能实现可靠连接，TCP并不是
: : 比UDP的线路要高档一些，它也会丢包，但是它是把包重发机制封装了起
: : 来，因此采用TCP连接和采用UDP连接所传输的数据量是差不多的，而且
: : 在线路好的情况下，UDP的数据量要更小一些。
: TCP协议我也学过:), TCP连接重发原理绝对不是靠每若干秒种重发。:)，按照
: 目前的网络状况，TCP包的正常重发率根据 SNIFFER平均小于5% ( LAN里小于
: 1% )，危言耸听的不是我。我只是靠一些事实数据根据。 退一万步而言，即使
: TCP重发率达到100%，发送一个"hi"信息也用不了 2K吧？ 利用TCP原理此信息
: 用OICQ封装后，网络开销不会超过128Byte ，无他，只是16倍的相差而已。如
: 果仅仅从这点上有任何争议，我可以把所有的包的每个byte都写出来。
呵呵，就算你这个2k是你测出来的，那不过是一种最最极端的情况，在网络情况
好的时候一般最多三个包重发即可以到达目的地，这样的通信量也不过60个字节
而已，况且绝大多数情况下每次的通信量不会超过500个字节,而我想目前中国的
网民里似乎绝大多数都不是按流量计费的吧，即使按流量计费，这点通信量也要
远远小于看网页的通信量，因此似乎这个问题并不是OICQ目前的协议模式好坏
的关键。
好，我们再来探讨一下客户机之间采用TCP的问题，没错ICQ的客户机之间采用
的是TCP连接，可是要知道国内的网络情况非常复杂，抛开169不说，还有有非
常多的用户使用的是proxy共享上网,而这些proxy绝大多数是三元素proxy,这样
有一个好处就是在server上记录到的client的udp端口其他客户机也同样能够向
这个端口发包，proxyserver会把这个包转发给client,这样一个客户机就可以
直接向proxy内部的机器主动发送信息而无须通过服务器中转，而且两个同在
proxy后面的客户机也可以相互直接通信而无须通过服务器中转，而如果采用TCP
方式的话这些是不可能做到的，这也是为什么广大用户纷纷觉得OICQ要比ICQ发
信息快得多的原因之一。此外采用TCP连接可能更不安全，一点不懂网络知识的
人用netstat就可以看到对方的IP,这样带来的危险要远远超过upd可以伪装源地
址进行攻击带来的危险（因为即使你知道了源地址，大多数情况下你也无能为力
）
当然，采用tcp不是没有好处，但是作为一个系统来考虑，需要权衡各方面的利弊
来作出一个选择，不可能让你占尽所有的优点，可以这么说，OICQ之所以如此深
受广大用户的喜爱，采用UDP协议功不可没。此外可以告诉你的是OICQ是目前
唯一教育网上能够使用的ICQ，如果采用TCP的话，oh,MY god~~~~
:
: : 4) 你对重复发UDP包的机制判断有些错误，OICQ并不是拼命向服务器发包
: : 直到有返回，而是间隔5秒，一般来说5秒都没有返回的时候这个包在
: : 去的路上就丢了的可能性为50%，因此这样做带来的额外的开销对于服
: : 务器而言并没有你所描述的那么重，相反，采用udp机制的节约下来的
: : 开销已经远远抵了TCP永久连接的可怕开销
: 我举的"hi"的例子是 Sniffer下的原始记录，并非我的判断失误:)
:
: 我的意思是，现在采用的连接方式对服务器负担确实很轻，但是对于网络
: 和用户未免不够负责。
: 分析OICQ协议也并非因为协议本身的好坏，是出于探索的目的:)。
:
: 谢谢您很诚意地纠正我的意见，我相信OICQ的开发者作了相当的权衡，
: 但是只考虑开销（当然，目前开销仍然不是最合理），完全忽略安全性是我
: 作为一个对安全比较关心的“网友”所不愿意看到的。
好了，最后再来探讨你所说的安全性的问题，其实仔细想想，如果不对信息流
加密的话无论是UDP还是TCP都一是一样的，安不安全和协议本身没有多大关系
因此说采用UDP就是对用户不负责任的说法未免有些牵强，难道采用TCP协议就
算是对用户负责了么？
由于开发初期人手的问题造成了明文协议的历史遗留问题，我们也感觉颇为遗憾
但是作为一个聊天系统，我们要做的好，侧重点同电子商务是不同的，否则也许
我们的系统非常安全，可是并不好用，只能说是本末倒置了，相信随着OICQ的不
断完善，在这方面我们会投入更大的精力。
:
: 和我上封帖子里写的那样，OICQ是个好的开端，而且对将来的电子商务等
: 网络市场开发和营销都是个良好基础，如果放眼将来，安全性绝对是很重要
: 的部分。 从这个意义上而言，128bit的加密是个必备的选择。
最后想说的一点就是，不同的系统有不同的侧重点，要想做好一个系统，必须
要权衡到各种利弊进行通盘的考虑，也许我们看问题的出发点不同，我们做的
是一个系统，而你看到的只是这个系统的某一个方面，因此我觉得在没有进行
全面细致地考虑的情况下就作出“很差”评价是不太负责任的。
-------------------------------------------
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.109.32.2]
|
|