TCP协议总结--停止等待协议,连续ARQ协议,滑动窗口协议
来源:互联网 发布:lytro illum 软件 编辑:程序博客网 时间:2024/05/17 09:15
前言:在学习tcp三次握手的过程之中,由于一直无法解释tcpdump命令抓的包中seq和ack的含义,就将tcp协议往深入的了解了一下,了解到了几个协议,做一个小结.
先来看看我的问题:
这是用tcpdump命令抓的三次握手的包,可以看到seq和ack都比较大,我自己也无法解释原因.
第二张是在同一过程中用Wireshark抓的包,其中seq和ack还比较正常,难道原因就是我不懂tcpdump命令中的数据?我的解释是Wireshark和tcpdump中抓的包,数据的显示方式可能不同,最后学长说可以用 -S 将tcp的序列号以绝对值形式输出,而不是相对值。转化了一下,第三次的ack就正常了.主要还是得知道seq和ack一样,都是字节序列号,一共4个字节,范围都是从[0,2^32 - 1].$ tcpdump -S port 80
一:停止等待协议
停止等待协议是tcp保证传输可靠的重要途径,”停止等待”就是指发送完一个分组就停止发送,等待对方的确认,只有对方确认过,才发送下一个分组.
1:无差错情况:发送方发送分组,接收方在规定时间内收到,并且回复确认.发送方再次发送……
2:超时重传有以下三种情况:
(1)分组丢失:发送方发送分组,接收方没有收到分组,那么接收方不会发出确认,只要发送方过一段时间没有收到确认,就认为刚才的分组丢了,那么发送方就会再次发送.
(2):确认丢失:发送方发送成功,接收方接收成功,确认分组也被发送,但是分组丢失,那么到了等待时间,发送方没有收到确认,又会发送分组过去,此时接收方前面已经收到了分组,那么此时接收方要做的事就是:丢弃分组,重新发送确认.
(3):传送延迟:发送方发送成功,接收方接收成功,确认分组也被发送,没有丢失,但是由于传输太慢,等到了发送方设置的时间,发送方又会重新发送分组,此时接收方要做的事情:丢弃分组,重新发送确认. 发送方如果收到两个或者多个确认,就停止发送,丢弃其他确认.
停止等待协议的优点是简单,但是缺点是信道的利用率太低,一次发送一条消息,使得信道的大部分时间内都是空闲的,为了提高效率,我们采用流水线传输,这就与下面两个协议有关系了.
二:连续ARQ协议和滑动窗口协议
这两个协议主要解决的问题信道效率低和增大了吞吐量,以及控制流量的作用.
- 连续ARQ协议:它是指发送方维护着一个窗口,这个窗口中不止一个分组,有好几个分组,窗口的大小是由接收方返回的win值决定的,所以窗口的大小是动态变化的,只要在窗口中的分组都可以被发送,这就使得TCP一次不是只发送一个分组了,从而大大提高了信道的利用率.并且它采用累积确认的方式,对于按序到达的最后一个分组发送确认.
- 滑动窗口协议:之所以叫滑动窗口协议,是因为窗口是不断向前走的,该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认,因此该协议可以加速数据的传输,还可以控制流量的问题.
- 累积确认:如果发送方发送了5个分组,接收方只收到了1,2,4,5,没有收到3分组,那么我的确认信息只会说我期望下一个收到的分组是第三个,此时发送方会将3,4,5,全部重发一次,当通信质量不是很好的时候,连续ARQ还是会带来负面影响.
- TCP协议总结--停止等待协议,连续ARQ协议,滑动窗口协议
- 停止等待协议和连续ARQ协议
- 停止等待协议和连续ARQ协议
- TCP连续ARQ协议和滑动窗口协议
- (运输层)TCP可靠传输原理之停止等待协议(ARQ)/连续ARQ协议
- ARQ与滑动窗口协议
- ARQ与滑动窗口协议
- ARQ与滑动窗口协议
- arq与滑动窗口协议
- 连续ARQ协议
- 连续ARQ协议
- 连续ARQ协议
- 连续ARQ协议
- 26.滑动窗口协议 与停止等待协议的区别
- 计网--ARQ与滑动窗口协议
- TCP 滑动窗口协议
- TCP滑动窗口协议
- TCP 滑动窗口协议
- 子控件在父控件上的显示问题
- Delphi 6Bit 编码
- 【软工再复习】——为什么要有软件工程?
- DASI_1_IntroToData
- 多线程的几种方法
- TCP协议总结--停止等待协议,连续ARQ协议,滑动窗口协议
- fragment与Activity的生命周期
- 记录一些UIScrollView的使用方法
- 台大机器学习第一讲
- ASCII码表
- 关于Android4.4以上版本的外置存储器路径问题
- 安卓中实现Activity向Fragment传值
- 拯救懒癌、码农、减肥人士的代餐,有多大的掘金前景
- C#调用C回调函数后,程序奔溃问题