计算机网络之TCP(一)

TCP的三个特点

  1. TCP是面向连接的运输层协议
    即有了连接才能通信,不能无缘无故就传送数据
  2. TCP连接是端到端
  3. TCP提供可靠交付的服务
  4. TCP提供全双工通信
  5. 面向字节流

可靠传输的的工作原理

在IP层只能提供最大努力服务,TCP必须使用适当的措施才可以两个运输层的传输变得可靠

理想传输有两个条件:
1.传输信道不产生差错
2.不管发送方以多块的速度发送数据,接受方总是来得及接收并处理

但是不存在这样的条件,可以使用一些可靠的传输协议来保证可靠传输

停止等待协议

A是发送方,B是接收方,A要发送数据,B要接收数据并发送确认,停止等待就是发送一个分组就停止等待确认报文,收到了确认报文在发送下一个分组

1.无差错情况

在这里插入图片描述
A发送完B就暂停,等待B的发送确认信息,确认信息来了就发送下一个分组,上图是最简单的无差错情况。

2.出现差错

在这里插入图片描述
B在接收M1的时候检测到了出错,直接丢弃了M1就什么都不做了,因为这个时候B啥也不知道,然后过了一段时间,A没有接收到确认报文就重新发这个M1,需要注意的是,A在发送完一个分组之后必须保留这个分组的副本,只有这个分组收到确认报文,才清除暂时保留的副本。所以还要给分组编号,这样子才知道那些发送了,那些发送了且收到了确认信息。

可靠传输协议规定: A只要超过一定的时间没有收到确认报文,就会认为发送的分组的丢失了,然后重新发送这个分组。

3.确认丢失

在这里插入图片描述
这种情况就是B发给A的确认报文在传输过程中丢失了,但是A不知道是自己的发送的数据丢失了还是确认报文丢失了,在超时计时器到期后就要重新发送M1,这个时候B又收到M1,这时候

  1. 直接将这个M1给丢弃
  2. 然后再发送一个确认报文,不能认为发送过确认就不发了

4.确认迟到

在这里插入图片描述
B发给A的确认报文迟到了,A又发给了B一个数据报文,然后B发送了另一个确认,而且这个确认比第一个确认还早到,此时传输已经完成,但是A有收到了M1的确认报文,A直接收下但是什么都不做,因为传输已经完成了。
可靠传输协议也叫自动重传协议ARQ(Automatic Repeat reQuest)

连续ARQ协议

连续ARQ协议规定: 发送方每收到一个确认,就把发送窗口向前滑动一个分组的位置

接收方一边拿采用累计确认的方式,也就是说,接收方不必对收到的分组逐个发送确认,而是收到几个分组确认之后,对按序到达的最后一个分组发送确认

TCP可靠传输的实现

1.以字节为单位的滑动窗口

TCP的的滑动窗口是以字节为单位的,以下是模型
在这里插入图片描述
A收到B的确认报文,窗口是11,而确认号是29,说明B期望收到的下一个序号是30,而序号29为止的数据已经收到,于是会构造出上图的发送窗口。

后沿不断向前移动也有可能不动,TCP标准不赞成前沿向后移动

在这里插入图片描述
P3 - P1 = A的发送窗口
P2 - P1 = 已发送但尚未收到确认
P3 - P2 = 允许发送当尚未发送

我的理解是
序号为30的分组还没有收到,可能是丢失了或者迟滞了,不管怎么样,接收方发给发送的确认报文的序号还是29,因为我的30还没有收到呢,于是发送方再次发送,终于收到了30,接收窗口就要向前移动4个单位这时确认发送的序号为33,也就是下次请发送方发送34的分组。

  • 2
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值