简介
今天一直在研究网络协议中的TCP协议,一说到TCP,首先大家会想到的是:安全,可靠,三次握手,TCP慢启动,ACK等巴拉巴拉一大堆.我想抛开这些传统的概念,从现实生活中接触比较多的宽带来理解下我眼中的TCP.
带宽
记得大三的时候,移动推出了100M的宽带包年只要120元/年.当时跟电信的50元/月且只有10M的网,移动明显优势很明显.所以,办理好宽带回到寝室,第一件事情就打开了360软件,我就怕移动忽悠我.所以结果如下图:
那百度到底是怎么实现测速的呢,大家用过应该知道,测试的结果还是挺接近实际的您办理的宽带带宽的.
如何实现测速的呢
软件是这样解释的==360宽带测速器通过HTTP+P2P的方式测试宽带接入网速,模拟浏览器访问常用网站测试看网页,上微博,知乎的速度.==
结果:
更直观的测试宽带的渠道
测速网-您的专属网速测试专家
测试结果分析:
更多测试点
测速网给用户提供了不同的测试地区可以自己选择.测试点不同,测试出的结果也会有所差异.
下载速度和上传速度
运营商在上层接入网设备中做了策略；原则上，普通宽带上下行不对等，专线宽带上下行对等。对应的，设备的接入利用率也是不一样的，专线宽带占用更多的光口资源：假设一个一个OLT下一个PON口最大容量为1GB，能开通满足下行100M的宽带10条（实际不会开满10条）；那么对应上行PON口，同样是1GB容量，专线宽带最多也只能开10条，而普通快带就不一样了，在用户没需求（其实即使你有需求，运营商也不会鸟你，谁叫你是普通宽带呢，要对称，请移步VIP业务受理厅）的情况下，可以使用默认上行速率，一般给个10:1就不错了。
中国的宽带分家庭宽带和企业宽带的；
家庭宽带下载快上传慢，价钱便宜；
企业宽带下载稍慢一点，上传很快，价钱比家庭宽带贵很多
我的截图属于公司网络,上传比较快.当然价格也当然贵很多.
演示三次握手和慢启动对简单HTTP传输的影响
我们假设纽约的客户端需要通过TCP连接向伦敦的服务器请求一个20 KB 的文件（图2-5），下面列出了连接的参数。
- 往返时间：56 ms。
- 客户端到服务器的带宽：5 Mbit/s。
- 客户端和服务器接收窗口：65535 字节。
- 初始的拥塞窗口：4个TCP段
ps: 1个TCP段占多少KB ==>（1×1460 字节 ≈ 1.4 KB）。20KB,总共有15个TCP段 - 服务器生成响应的处理时间：40ms。花费在处理请求的时间
- 没有分组丢失、每个分组都要确认、GET 请求只占 1 段。
- 0 ms：客户端发送 SYN 分组开始TCP握手。
- 28 ms：服务器响应 SYN-ACK 并指定其 rwnd 大小。
- 56 ms：客户端确认 SYN-ACK，指定其 rwnd 大小，并立即发送 HTTP GET 请求。
- 84 ms：服务器收到 HTTP 请求.
- 124 ms：服务器生成 20 KB 的响应，并发送 4 个TCP段（初始 cwnd 大小为 4），然后等待ACK.
- 152 ms：客户端收到 4 个TCP段，并分别发送ACK确认。
- 180 ms：服务器针对每个 ACK 递增 cwnd，然后发送8个TCP(指数增长,TCP慢启动规则)段。
- 208 ms：客户端接收8个段，并分别发送ACK确认。
- 236 ms：服务器针对每个ACK递增cwnd，然后发送剩余的 TCP 段。
- 264 ms：客户端收到剩余的TCP段，并分别发送ACK确认。
两个实例来实现宽带测速
1. 假设TCP一次传输的数据最大为16KB(这个根据网络协议是定死的,[RFC 1323],TCP 接收窗口最大只有64 KB。),你的电脑访问一个网站,假设往返时间为100ms;则这次TCP连接的传输速率不会超过多少?
不管发送端和接收端的实际带宽多大，这个TCP 连接的数据传输速率不会超过1.31
Mbit/s!想提高吞吐量，要么增大最小窗口值,要么减少往返时间。
如果你访问淘宝,页面返回很慢,你需要改变两个值:
- 增大最小窗口值(协议规定,无法改)
- 减少往返时间(CDN服务)
2. 同样,知道往返时间和两端的实际带宽也可以计算最优窗口大小。这一次我们假设往返时间不变（还是100 ms），发送端的可用带宽为10 Mbit/s，接收端则为100 Mbit/s+。还假设两端之间没有网络拥塞，我们的目标就是充分利用客户端的10Mbit/s 带宽：
窗口至少需要122.1 KB 才能充分利用10 Mbit/s 带宽！还记得吗，如果没有“窗口缩放（RFC 1323）”，TCP 接收窗口最大只有64 KB。是不是该好好查查自己的客户端和服务器设置啦？
好在窗口大小的协商与调节由网络栈自动控制，应该会自动调整。但尽管如此，窗
口大小有时候仍然是TCP 性能的限制因素。如果你怎么也想不通在高速连接的客户
端与服务器之间，实际传输速度只有可用带宽的几分之一，那窗口大小很可能就是
罪魁祸首。要么因为某一饱和端通告的接收窗口很小，要么因为网络拥堵和丢包导
致拥塞窗口重置，更可能因为流量增长过快导致对连接吞吐量施加了限制。
