Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

大致的原理是什么呢? #3

Closed
huskyii opened this issue Dec 28, 2015 · 12 comments
Closed

大致的原理是什么呢? #3

huskyii opened this issue Dec 28, 2015 · 12 comments

Comments

@huskyii
Copy link

huskyii commented Dec 28, 2015

No description provided.

@d1sm
Copy link
Owner

d1sm commented Dec 30, 2015

以后会出说明文档.

@d1sm d1sm closed this as completed Dec 30, 2015
@d1sm d1sm reopened this Jan 12, 2016
@d1sm d1sm closed this as completed Jan 12, 2016
@pexcn
Copy link

pexcn commented Feb 16, 2016

能否简述一下原理?

@kennylam777
Copy link

草草看過源碼後, 用猜的答

  1. 要求精準填寫上下行頻寬, 是因為要在接收端用作計算中間線路的掉包率, 來調整發射端暴力發包的程度, 最大發包量是雙倍。而伺服器及客戶端同時有以上發射端/接收端的調整機制。
  2. 接上, 因為發射端能得知接收端的頻寬及實際送達率, 故此在得知中間線路的掉包率下, 能控制不會盲目雙發令接收端的頻寬被有效傳達的封包塞滿, 盲目雙發最壞的情況是線路良好時, 因封包雙倍塞滿線路令有效頻寬減半
  3. 計算ACK時間以控制Window size, 有可能是雙重ACK以保障送達, 不因掉失ACK而降速, 反正ACK封包多發的成本不高
  4. 有可能有快速重傳補回buffer的機制, 但不確定

@d1sm
Copy link
Owner

d1sm commented May 24, 2016

楼上确实只是猜测,也是很多人的猜测,和fs真正原理不搭边,fs不存在暴力多倍发包,大多数网络环境重发率在0.3%以下,高丢包延迟下不超过3%,欢迎对fs流量进行统计分析,而不是猜测.

@d1sm d1sm reopened this May 24, 2016
@nxtreaming
Copy link

nxtreaming commented May 28, 2016

FS的工作方式不能大规模部署,其本质是个调整了发包的速度和ACK确认机制,理论上完全合法,但在公网上存在很多不确定性因素会导致UDP包被强制丢包,会使得某些运行商主动屏蔽FS的流量。

说的通俗一点: FS的工作方式是损人利己,国际出口带宽本身就那么多,那么拥挤,某些人占用多了,必然导致更多的人更拥堵。

个人不建议大规模使用。

@ragnaroks
Copy link

我的VPS是双向计算流量的,测试一个1G文件的传输,理论上应该消耗2G或更多的VPS流量,实际上仅消耗1.8G,原因不明.
对楼上所述的"损人利己"既赞同也反对,在总带宽一定的情况下,确实损人利己,但是我既然开通了这个大小的带宽,我就应该享受这个服务.

@StephenPCG
Copy link

但是我既然开通了这个大小的带宽,我就应该享受这个服务.

这个想法不健康。购买了带宽却无法足量使用,你应该去找运营商,向运营商维权,而不是损害其他消费者的利益。就好比买菜时短斤少两,你应该投诉商家,而不是从身边的其他顾客那里抢一把过来。楼上的意思很明确,如果大批量部署(也就是大多数人都有这样的想法),那么结果会比现在更恶劣,链路上更多的资源浪费在恶性竞争导致的丢包上,到时候,网络只会变得更差。

@ragnaroks
Copy link

说的很有道理,但是你自己也清楚在资源有限的情况下,正常手段是得不到资源的.

举个栗子,购买一个虚拟主机,100G流量不限带宽,这台服务器上有100个用户,正常情况下,每个用户仅消耗20G/月.我购买10个订单,同时做下载用,几乎实时占用全部带宽.一个虚拟主机的流量完了马上换下一个.

对于这台机器上的其他用户来说,这主机就是垃圾,卡出翔,破网络.
而对于主机卖家来说,他巴不得你用更多的流量交更多的钱.

联通电信的出口带宽对于现在的网络需求来说就是超售,并且他们和我上面提到的主机卖家一样,你出钱(专线)就能获得更好的服务,而不用关心其他用户是能正常使用.
而最重要的,投诉是无效的,所以我先买了2个3年授权压压惊.

@nxtreaming
Copy link

所以我先买了2个3年授权压压惊.

什么授权?

你举得虚拟主机的例子不对,你可以通过多买VPS 来消耗掉所有可用带宽, 因为其他用户可以更换VPS,不会造成严重影响,如果大规模部署FS,导致网络恶化,你是没有办法避免此类情况的,因为你没有选择(国际出口就那么点带宽)。

@ragnaroks
Copy link

xsokcs的授权,finalspeed虽然还保留着同时也能正常部署,但是这个东西上面我是支持作者的,毕竟比锐速便宜的多.
所以我才举例虚拟主机,因为你(用户)在这台虚拟主机上(宽带运营商)没得选择,除非加钱(而且是很多的钱).
那么如何花较少的钱获得较好的效果?
当足够多的人都使用xsocks导致出口不稳定时,联通电信才会去加出口.

有人曾经问过,CN2什么时候每个人都能用?
我说,跟CN1一样烂的时候.

@d1sm
Copy link
Owner

d1sm commented Jun 7, 2016

其实这个多线程下载,p2p下载加速造成的影响差不多,但是现在应该很少人去争论p2p抢带宽了,因为国内带宽充足,为什么国际出口慢,根源在哪里都懂得,除了不愿投入,提高出口容量,还有故意劣化线路,丢包,增加延迟,就不是带宽不够的问题了.

@StephenPCG
Copy link

联通电信的出口带宽对于现在的网络需求来说就是超售,并且他们和我上面提到的主机卖家一样,你出钱(专线)就能获得更好的服务,而不用关心其他用户是能正常使用.
而最重要的,投诉是无效的,所以我先买了2个3年授权压压惊.

对于一般商业服务,如果有超售,你可以投诉,也可以选择用脚投票不用它,比如你举的VPS的例子,共享的VPS,厂商应该做好相应的资源限制策略,并且合理分配资源,以保障客户的利益,如果有许多客户觉得利益受损(比如你说的100个客户里99个都觉得不好),那么大家就不用了这家VPS了。

那么如何花较少的钱获得较好的效果?
所以你只关心你能怎样付出尽可能少的成本,而不在乎是否损害其他人的利益,也不在乎这个举止将来也会反过来损害自己的利益?你今天抢了别人的菜,付出了比“投诉商家维权”低很多很多的成本,但是你损害了别人的利益,同样,你也要承担将来可能会被别人抢菜的风险,如果这种思想被大多数人认可,那么有一天,大街上大家都忙着互相抢菜了,最后的结果,菜都烂了,大家什么都没得到。

是的,运营商超售的问题,作为用户我们很无奈,投诉也不可能立刻见效。但是,对于因此而无耻的伤害其他用户利益的、也不关心自己将来利益的人,我一定会谴责、鄙视。

当足够多的人都使用xsocks导致出口不稳定时,联通电信才会去加出口.
我不为运营商洗地,但是也请你不要恶意的揣测他人(包括运营商)的行为。

CNNIC每半年会发布一次《中国互联网络发展状况统计报告》,在这里可以找到:http://www.cnnic.net.cn/hlwfzyj/hlwxzbg/
根据最近一次的报告(2016年1月22日,第37次),2015年中国国际出口带宽增长率30.9%,增加了1T多,我觉得这已经不小了。我觉得这两年国际出口越来越饱和,根本原因是互联网内容发展的速度过快,远高于运营商的估计。一方面,中国的互联网普及度越来越高,网名越来越多,另一方面,互联网内容越来越大,现在随便一个网站的首页打开都要十来兆,更不用说各种富媒体资源了。而国际出口的带宽建设,运营商也不是想多大就能多大。海底光缆硬件的铺设是有专门的公司干的,跨国的流量管理更是麻烦,涉及到许多政治、经济、宗教等各方面的因素。这里有一张2013年底中国的国际出口带宽,虽然有些过时,但是你可以看一下,感受一下增大国际带宽的难度。

2013年中国互联网络连接带宽图

大图:http://www.cnnic.net.cn/hlwfzyj/hlwfzzx/qwfb/201406/W020140710350330761331.jpg

@d1sm d1sm closed this as completed Jun 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants