计算机网络作业合辑
2016-07-08 22:14
253 查看
1.Drawspace-time diagram for the previous HTTP request scenario assuming persistentconnections and pipelining
为之前持久性、流水线型的HTTP请求画时空图。
2. Impact ofusing local web cache
web缓存的影响
一个对象大小为100K bits, 每秒发送15个对象,那么每秒发送1.5M的数据。
有40%由缓存器接收,60%由接入链路接收,接收链路的使用速率为1.5M*60% = 0.9M
使用率为0.9/1.54 = 0.58.
总的延迟为 0.6*(2.0+~msecs) + 0.4*~msecs = 1.2sec
3.Q: what relationship between seq # size and window size to avoid problem in (b)?
为了避免图b所示的问题,序列号大小和窗口大小应该满足什么关系?
问题在于,接收方不知道对方是因为(应答丢失而)没有收到应答且超时而重传某个序列号,而是下几个窗口发送过程中因为丢失又正好轮到了同一个序列号。
在后面的情况中,接收方会把重复的分组当作新的分组,这样就出现了错误。
在这个例子中,我们认为是窗口太小,或者说序列号太大导致不能分辨新旧帧。我们假设两者窗口大小不变,而尽可能增大序列号(先认为无穷大)如果出现了ACK全部丢失的极端情况,重传时发送编号0,而此时窗口将会滑动到 3 4 5的位置,接收方得到0后,并不会认为这是新的分组,而导致重复接收。我们必须保证这个窗口不会出现0,所以至少需要序列空间大小为6(3位)
#seq size >= window size*2 (如果发送方和接收方windowsize相等的话,最终接收窗口终止的位置就是两倍window size,在ACK全部丢失情况下,要保证不产生歧义,序列号必须在终止位置时保证不回到新的序列),广义上,如果发送方和接收方windowsize不相等,那么size1
+ size2 <=seq size
4.TCP中,为什么三次收到相同序列就认为丢包
收到相同的ACK,可能是数据丢失,也可能是返回的ACK延迟或者丢失。但是,三次收到连续相同的ACK并且都不是丢包的概率非常低,所以我们一般收到三次连续相同ACK时,我们就认为数据丢失了。
5.两次握手会出现怎样的问题?
响应后无法得知对方的状态,起码三次才能保障这一点,可能导致的具体问题有:
①一方发送请求,一方发送应答,如果应答延迟,客户端将重发请求,而服务器已经建立连接,出现错误。
②一方发送请求,一方发送应答,然后客户端不再有反应,而服务端认为连接建立,一直等待。
③一方发送请求而延迟,进而重新发送请求,等到连接关闭后,第一次的失效请求达到服务器,建立了第二次不需要存在的连接。
……
6.吞吐量相关计算
已知1500字节的段,100ms的rtt,需要10Gbps的吞吐量。
(10Gbps = 10^4Mbps = 10^10 bps 1500byte = 12 000 bit,100ms = 0.1s)
单位时间内流通的段数为(10^10bit/s)/(1.2*10^4bit * 0.1s)= 83 333
已知平均吞吐量计算公式:
TCP throughput = 1.22*MSS/(RTT*sqrt(L));
计算丢包率:
L = (1.22*MSS/(RTT*throughtput))^2 =(1.22*12 000/0.1*10^10)^2 = 2.143*10^-10
7.交换机自学习:C到I数据交换经历过程,一开始表为空
1.交换表为空,S1泛洪,把数据交给S4。
2.S4泛洪,数据交给S3
3.S3泛洪,数据交给I
4.数据通过交换表找到传输链路,从L到C回应
为之前持久性、流水线型的HTTP请求画时空图。
2. Impact ofusing local web cache
web缓存的影响
一个对象大小为100K bits, 每秒发送15个对象,那么每秒发送1.5M的数据。
有40%由缓存器接收,60%由接入链路接收,接收链路的使用速率为1.5M*60% = 0.9M
使用率为0.9/1.54 = 0.58.
总的延迟为 0.6*(2.0+~msecs) + 0.4*~msecs = 1.2sec
3.Q: what relationship between seq # size and window size to avoid problem in (b)?
为了避免图b所示的问题,序列号大小和窗口大小应该满足什么关系?
问题在于,接收方不知道对方是因为(应答丢失而)没有收到应答且超时而重传某个序列号,而是下几个窗口发送过程中因为丢失又正好轮到了同一个序列号。
在后面的情况中,接收方会把重复的分组当作新的分组,这样就出现了错误。
在这个例子中,我们认为是窗口太小,或者说序列号太大导致不能分辨新旧帧。我们假设两者窗口大小不变,而尽可能增大序列号(先认为无穷大)如果出现了ACK全部丢失的极端情况,重传时发送编号0,而此时窗口将会滑动到 3 4 5的位置,接收方得到0后,并不会认为这是新的分组,而导致重复接收。我们必须保证这个窗口不会出现0,所以至少需要序列空间大小为6(3位)
#seq size >= window size*2 (如果发送方和接收方windowsize相等的话,最终接收窗口终止的位置就是两倍window size,在ACK全部丢失情况下,要保证不产生歧义,序列号必须在终止位置时保证不回到新的序列),广义上,如果发送方和接收方windowsize不相等,那么size1
+ size2 <=seq size
4.TCP中,为什么三次收到相同序列就认为丢包
收到相同的ACK,可能是数据丢失,也可能是返回的ACK延迟或者丢失。但是,三次收到连续相同的ACK并且都不是丢包的概率非常低,所以我们一般收到三次连续相同ACK时,我们就认为数据丢失了。
5.两次握手会出现怎样的问题?
响应后无法得知对方的状态,起码三次才能保障这一点,可能导致的具体问题有:
①一方发送请求,一方发送应答,如果应答延迟,客户端将重发请求,而服务器已经建立连接,出现错误。
②一方发送请求,一方发送应答,然后客户端不再有反应,而服务端认为连接建立,一直等待。
③一方发送请求而延迟,进而重新发送请求,等到连接关闭后,第一次的失效请求达到服务器,建立了第二次不需要存在的连接。
……
6.吞吐量相关计算
已知1500字节的段,100ms的rtt,需要10Gbps的吞吐量。
(10Gbps = 10^4Mbps = 10^10 bps 1500byte = 12 000 bit,100ms = 0.1s)
单位时间内流通的段数为(10^10bit/s)/(1.2*10^4bit * 0.1s)= 83 333
已知平均吞吐量计算公式:
TCP throughput = 1.22*MSS/(RTT*sqrt(L));
计算丢包率:
L = (1.22*MSS/(RTT*throughtput))^2 =(1.22*12 000/0.1*10^10)^2 = 2.143*10^-10
7.交换机自学习:C到I数据交换经历过程,一开始表为空
1.交换表为空,S1泛洪,把数据交给S4。
2.S4泛洪,数据交给S3
3.S3泛洪,数据交给I
4.数据通过交换表找到传输链路,从L到C回应
相关文章推荐
- AsyncHttp+gson解析
- HttpClient+Gson解析中国天气网的天气预报信息
- CNN 卷积神经网络--kernel、偏置值导数
- TCP超时与重传
- Windows Server 2012 R2在桌面上显示计算机/网络图标
- 浅谈TCP/IP协议栈(五)路由分类和路由优先级
- 网络爬虫之投票
- Android Volley框架整合升级OkHttp3.3问题
- 关于OkHttp3的学习
- httpclient获取状态码(4.5.2版本)
- HttpClient和HttpURLConnection的区别
- 神经网络
- 关于HTTP协议的笔记
- HTTP
- 使用java代码模拟HTTP请求
- Python网络编程——学习笔记
- uses-permission权限列表
- 基于Scrapy框架的python网络爬虫(1)
- 用tcpdump抓取Android的网络数据包
- HTTP协议的响应头,请求头详解