Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

如何在局域网内抢带宽

Posted on 10/06/201206/23/2019 by 四火

3 事情的起因是最近家里买了一台 60 寸的智能电视,支持点播(VOD)功能,家里的网络带宽理论上只有 4M,在播放的时候,就会占用大量网络带宽,导致我同时上网浏览网页都很困难。

有没有办法给限制局域网内某台主机的流量?首先,还是得从 TCP 的原理说起。

TCP 拥塞控制

TCP 是个君子协议,在拥塞控制的设计(RFC 2851)中包括慢开始、拥塞避免、快重传和快恢复 4 种算法。

c

拥塞窗口(cwnd)和接收端窗口(rwnd)二者的最小值确定了发送窗口的上限值,而实际上对于现今的网卡,接收端窗口的大小是可以很大的,也就是说,拥塞主要寄希望于拥塞窗口来控制,拥塞窗口直接决定了传输的速率。从上面这张图可以看到:

  1. 慢开始增加到门限初始值的这段过程中,拥塞窗口的增长是比较快的。
  2. 之后的增长由指数式变成了保持线性缓慢增长,直到出现网络拥塞超时。
  3. 超时以后重新慢开始的过程,但是门限值发生了改变,变成了拥塞发生值的一半大小。

为了改进上述拥塞控制算法的弊端,又加入了快重传和快恢复算法。快重传指的是:

  1. 对于 msg1 和 msg2,接收端收到以后,就分别回复 ack2 和 ack3,但是这时候 msg3 丢失了(或者由于网络原因很久还未到达);
  2. 接收端又收到了 msg4,那就可以接收下 msg4,但是依然回复 ack3(ack3 依旧是意味着告诉发送端只收到了 msg1 和 msg2);
  3. 发送端继续发送 msg5 和 msg6,可是接收端依然回复 ack3;
  4. 但是发送端只要发现一连 3 个重复的 ack3,就知道估计 msg3 丢失了,得重传 msg3 了。

而快恢复算法是为了解决在发生网络拥塞时,拥塞窗口一下子跌到谷底(为 1),导致不能很快恢复网络正常通信流量状态,所以做了一个改进——

  1. 在拥塞发生的时候,只是把拥塞窗口置为 ssthresh+n×MSS(其中 n 表示收到重复的 ack 报文的个数,MSS 指的是最长报文段);
  2. 同时,这以后当收到新的 ack 报文时,就将拥塞窗口置为 ssthresh 的值。

TCP 协议在这样的拥塞控制机制下保证了对质量较差的网络也有较好的适应性,但是 UDP 协议就不具备这种拥塞控制机制(除非你在协议之上的应用中自己设计),而流媒体往往是基于 UDP 来实现的,因为它更快、无连接,而且偶尔丢帧也可以接受。在这种争夺带宽的场景下,君子 TCP 就没有办法争夺到较好的流量了。

多端口多连接

这是迅雷的主要做法之一,开启多个端口,建立多个连接,靠这种简单粗暴的方式来占取带宽。

ARP 欺骗

Google 搜索局域网抢带宽以后,映入眼帘的是 P2P 终结者这样的“ 杀器”,它的原理就是基于 ARP 欺骗,即是说,通过 ARP 攻击等使局域网内其它机器产生大量本地盲包,减少对公用网络资源的占用。

 

ARP(Address Resolution Protocol,地址解析协议)是获取物理地址的一个 TCP/IP 协议。某节点的 IP 地址的 ARP 请求被广播到网络上后,这个节点会收到确认其物理地址的应答,这样的数据包才能被传送出去。也就是说,在这个过程中,发送方用目标 IP 地址去换取了接收方的 MAC 地址,之后 MAC 地址存放到本地的缓存中(在一定的生存期时间内)。

由于在局域网中是使用 MAC 地址进行传输的,因此 P2P 终结者就伪造这样的一个 ARP 应答,把 P2P 终结者所在的机器 A 的 MAC 地址告诉目标机 B(目标机 B 在任意时候都可以接收 ARP 请求的应答),让目标机以为本机才是网关,这样 B 接收后就会更新本地缓存,以后所有本该走到网关去的包都会从机器 A 走,这就是一个简单的 ARP 欺骗的原理。

ARP 欺骗是黑客常用的攻击手段之一,ARP 欺骗分为二种,一种是对路由器 ARP 表的欺骗;另一种是对内网 PC 的网关欺骗。

2

MSS

在 TCP 的选项字段中,有一个是最大报文长度(MSS),在 TCP 建立连接的时候,双方就要约定好这个数值,每一个报文段都希望尽可能大,这样在带宽有限的情况下,相同数量的报文段可以承载更多的信息,但是 MSS 是有限制的,限制的值=MTU-IP 头长度-TCP 头长度,所以对于以太网来说就是 1500-20-20=1460。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 朴素贝叶斯分类
  2. Trie 树和其它数据结构的比较
  3. 对几个软件开发传统观点的质疑和反驳
  4. 数据库范式总结
  5. 谈谈微信的信息流

3 thoughts on “如何在局域网内抢带宽”

  1. 兵临城下 says:
    01/08/2013 at 6:16 PM

    快重传对于 msg3 的丢失应该是 3 个 ack2

    Reply
  2. Theresa says:
    10/29/2012 at 10:22 PM

    强大!

    Reply
  3. ayanamist says:
    10/10/2012 at 7:50 PM

    为什么写个抢带宽能写出后面这么多矫情的东西。弄个带 QoS 服务的路由器,把 DNS 协议优先级调高,其余所有 UDP 协议优先级最低就好了。再弄个根据流量增加自动降低优先级的规则,屁事都没有了。

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 亚马逊 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 问题 面向对象 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 聊一聊分布式系统中的时间
  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • Ticket: TRANSACTION 1.922915 BTC. Go to withdrawal >> https://yandex.com/poll/enter/BXidu5Ewa8hnAFoFznqSi9?hs=20bd550f65c6e03103876b28cabc4da6& on 倔强的程序员
  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme