学习TCP协议的流量控制(flow control)小结
2014-02-19 22:47
465 查看
TCP协议当中最重要的部分就是流量控制(flow control)和拥塞控制(congestion control)了。
TCP协议的流量控制是通过窗口机制实现的,:-)。只听这些概念很抽象,扭头就忘了,我们用个实例来看看。
使用的工具是 tcpdump。使用这个工具获取一下访问本机的web服务器所产生的数据如下:
22:14:27.757059 IP ubuntu-xingwang.39585 > ubuntu-xingwang.http: Flags [S], seq 779326623, win 43690, options [mss 65495,sackOK,TS val 1423721 ecr 0,nop,wscale 7], length 0
22:14:27.757093 IP ubuntu-xingwang.http > ubuntu-xingwang.39585: Flags [S.], seq 283855395, ack 779326624, win 43690, options [mss 65495,sackOK,TS val 1423721 ecr 1423721,nop,wscale 7], length 0
22:14:27.757121 IP ubuntu-xingwang.39585 > ubuntu-xingwang.http: Flags [.], ack 1, win342, options [nop,nop,TS val 1423721 ecr 1423721], length 0
22:14:27.757375 IP ubuntu-xingwang.39585 > ubuntu-xingwang.http: Flags [P.], seq 1:372, ack 1, win 342, options [nop,nop,TS val 1423721 ecr 1423721], length371
22:14:27.757421 IP ubuntu-xingwang.http > ubuntu-xingwang.39585: Flags [.], ack 372, win 350, options [nop,nop,TS val 1423721 ecr 1423721], length 0
22:14:27.759204 IP ubuntu-xingwang.http > ubuntu-xingwang.39585: Flags [P.], seq 1:380, ack 372, win 350, options [nop,nop,TS val 1423722 ecr 1423721], length 379
22:14:27.759236 IP ubuntu-xingwang.39585 > ubuntu-xingwang.http: Flags [.], ack 380, win 350, options [nop,nop,TS val 1423722 ecr 1423722], length 0
22:14:32.667501 IP ubuntu-xingwang.http > ubuntu-xingwang.39585: Flags [F.], seq 380, ack 372, win 350, options [nop,nop,TS val 1424949 ecr 1423722], length 0
22:14:32.667748 IP ubuntu-xingwang.39585 > ubuntu-xingwang.http: Flags [F.], seq 372, ack 381, win 350, options [nop,nop,TS val 1424949 ecr 1424949], length 0
22:14:32.667801 IP ubuntu-xingwang.http > ubuntu-xingwang.39585: Flags [.], ack 373, win 350, options [nop,nop,TS val 1424949 ecr 1424949], length 0
可以说是教科书般的流量啊,三次握手建立链接(蓝色流量)和四次握手断开链接(红色流量)一清二楚。
我们要注意的就是每条数据中的 win 字段数据,这就是传说中的窗口(window)了。这个值就是告诉链接中的另一方,我端的缓存空间现在是这么大,下次发送数据的时候别发太多,要不就会有数据无法保存下来,发生丢失。这就是TCP的流量控制方法。
我们来看具体的数据,第三条数据中,本地端口告知服务器,本地的缓存空间暂时只有 342 字节了。按说服务器再次发送数据的时候不会超过这个数的。可是实际上,第四条服务器发送了长度为372字节的数据。这是为什么呢?
原来TCP协议刚制定的时候,只给win字段分配了两个字节的空间,那么他的最大数就是65536字节,64K。但是为了更高效地使用带宽很高的网络,科学家们就增加了一个 窗口扩大因子(window scale factor)选项来增加窗口的值。在第一次syn发出的时候,客户端的选项数据里的wscale字段值设置为了7。就是说今后这个端所有的窗口数据都要左移7位,也就是342乘以128,那就是43776字节了。所以服务器发送了372个字节,太小意思了,远远没有超过本地缓存能力呢,呵呵
窗口扩大因子可以是0-14中间的任意一个值。
TCP协议的流量控制是通过窗口机制实现的,:-)。只听这些概念很抽象,扭头就忘了,我们用个实例来看看。
使用的工具是 tcpdump。使用这个工具获取一下访问本机的web服务器所产生的数据如下:
22:14:27.757059 IP ubuntu-xingwang.39585 > ubuntu-xingwang.http: Flags [S], seq 779326623, win 43690, options [mss 65495,sackOK,TS val 1423721 ecr 0,nop,wscale 7], length 0
22:14:27.757093 IP ubuntu-xingwang.http > ubuntu-xingwang.39585: Flags [S.], seq 283855395, ack 779326624, win 43690, options [mss 65495,sackOK,TS val 1423721 ecr 1423721,nop,wscale 7], length 0
22:14:27.757121 IP ubuntu-xingwang.39585 > ubuntu-xingwang.http: Flags [.], ack 1, win342, options [nop,nop,TS val 1423721 ecr 1423721], length 0
22:14:27.757375 IP ubuntu-xingwang.39585 > ubuntu-xingwang.http: Flags [P.], seq 1:372, ack 1, win 342, options [nop,nop,TS val 1423721 ecr 1423721], length371
22:14:27.757421 IP ubuntu-xingwang.http > ubuntu-xingwang.39585: Flags [.], ack 372, win 350, options [nop,nop,TS val 1423721 ecr 1423721], length 0
22:14:27.759204 IP ubuntu-xingwang.http > ubuntu-xingwang.39585: Flags [P.], seq 1:380, ack 372, win 350, options [nop,nop,TS val 1423722 ecr 1423721], length 379
22:14:27.759236 IP ubuntu-xingwang.39585 > ubuntu-xingwang.http: Flags [.], ack 380, win 350, options [nop,nop,TS val 1423722 ecr 1423722], length 0
22:14:32.667501 IP ubuntu-xingwang.http > ubuntu-xingwang.39585: Flags [F.], seq 380, ack 372, win 350, options [nop,nop,TS val 1424949 ecr 1423722], length 0
22:14:32.667748 IP ubuntu-xingwang.39585 > ubuntu-xingwang.http: Flags [F.], seq 372, ack 381, win 350, options [nop,nop,TS val 1424949 ecr 1424949], length 0
22:14:32.667801 IP ubuntu-xingwang.http > ubuntu-xingwang.39585: Flags [.], ack 373, win 350, options [nop,nop,TS val 1424949 ecr 1424949], length 0
可以说是教科书般的流量啊,三次握手建立链接(蓝色流量)和四次握手断开链接(红色流量)一清二楚。
我们要注意的就是每条数据中的 win 字段数据,这就是传说中的窗口(window)了。这个值就是告诉链接中的另一方,我端的缓存空间现在是这么大,下次发送数据的时候别发太多,要不就会有数据无法保存下来,发生丢失。这就是TCP的流量控制方法。
我们来看具体的数据,第三条数据中,本地端口告知服务器,本地的缓存空间暂时只有 342 字节了。按说服务器再次发送数据的时候不会超过这个数的。可是实际上,第四条服务器发送了长度为372字节的数据。这是为什么呢?
原来TCP协议刚制定的时候,只给win字段分配了两个字节的空间,那么他的最大数就是65536字节,64K。但是为了更高效地使用带宽很高的网络,科学家们就增加了一个 窗口扩大因子(window scale factor)选项来增加窗口的值。在第一次syn发出的时候,客户端的选项数据里的wscale字段值设置为了7。就是说今后这个端所有的窗口数据都要左移7位,也就是342乘以128,那就是43776字节了。所以服务器发送了372个字节,太小意思了,远远没有超过本地缓存能力呢,呵呵
窗口扩大因子可以是0-14中间的任意一个值。
相关文章推荐
- TCP/IP:拥塞算法与流量控制算法 学习小结
- 流量控制与拥塞控制学习小结
- TCP可靠传输、流量控制、拥塞控制小结
- 分布式服务框架-原理与实践:14---流量控制-学习笔记(实际篇)
- 分布式服务框架-原理与实践:14---流量控制-学习笔记(理论篇)
- TCP的流量控制与拥塞控制小结
- 坚持学习WF(7):流程控制(Flow Control)
- 【java面试系列之网络编程】TCP和UDP的区别、TCP协议的三次握手和四次挥手、TCP协议的通信状态、网络编程时的同步、异步、阻塞、非阻塞、进程间的通信方式、TCP的流量控制和拥塞控制
- python学习小结1:for循环控制语句
- python学习小结2:if和while控制语句
- python学习小结2:if和while控制语句
- 坚持学习WF(7):流程控制(Flow Control)
- TCP协议详解(慢启动,流量控制,阻塞控制之类)
- 关于学习进程控制和线程控制的小结
- python学习小结1:for循环控制语句
- 会话控制学习小结
- ACL流量控制工具-- 王贝的学习笔记
- 深入浅出之 TCP协议(三次握手与四次挥手、超时重发、流量控制、拥塞控制、与UDP区别)
- 网卡的流量控制flow control
- 基本概念学习(7002)---网络流量控制