zoukankan      html  css  js  c++  java
  • TCP可靠传输的保证

    我们知道传输层提供最主要的两种协议,TCP和UDP,其中TCP是保证可靠传输,为什么他要保证可靠传输呢,IP说:当然是我不能,我只提供尽力而为的服务,不保证你能不能交付,不保证能不能正确的交付,不保证能不能按顺序交付。要不然干嘛要你保证呢。说的好有道理,我呵呵一笑。

    那么可靠数据传输到底能保证什么呢?

    1.不错:就是传输的数据包没有错误

    2.不丢:传输的数据包不丢失

    3.不乱:传输的数据包顺序要保持正确的交付。

     

    可靠传输协议凭什么能做出这样的保证呢?

    1.差错检测:TCP将保持它首部和数据的检验和。这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP将丢弃这个报文段和不确认收到此报文段(希望发端超时并重发)。

    2.超时重发和确认机制:当TCP发出一个报文段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段。当TCP收到发自TCP连接另一端的数据,它将发送一个确认。

    3.缓存机制:每个分组都会有一个序列号,对于后一个序列号分组先到的情况,接收端会先进行缓存,等待前一个序列号到达,然后一起交付上层。

     

    重点讲一下流水线可靠传输协议,其实也就是滑动窗问题。

    对于使用流水线可靠传输协议,如果出现丢包,损坏或超时会有哪些方法来解决呢?两种方法:回退N步(Go-Back-N,GBN)和选择重传(Selective Repeat,SR)

     

    GBN协议

    发送端维持这一个长度为N的滑动窗口,你也可以理解为一个数组。

    1.窗口里含有发送但是没收到确认的分组,以及剩下可用的坑位,如果有可用的坑位,上层需要发送数据,则直接发送,否者缓存或返回给上层。

    2.接收端实行累积确认,也就是说当接收端传送的确认号为100,也就是前面的序号都是收到了,

    3.如果超时未收到确认,发送端会重传所有发送但未确认的分组。只有一个定时器,用来记录窗口的最前端,也就是最早发送的分组。

    4.因为此协议是使用的累积确认,所以所有为按序到达的分组都会被丢弃。

    选择重传

    1.发送端和接收端都会维持一个窗口,大小为N。

    2.接收端每收到一个分组就会发送一个确认,并且会缓存不是按序到达的分组

    3.发送端会标记已经被确认的分组,当窗口第一个值被确认后,窗口向后滑动。每一个分组为此自己的定时器。

    4.当一个分组超时了,只会重传超时的分组。

    窗口长度必须小于或等于序号空间大小的一半。

    TCP的可靠传输协议是GBN和SR的混合的

    1.他是基于累积确认的,

    2.但是他是可以缓存的,不会丢弃乱序的分组,

    3.只有一个定时器,记录发送端窗口的第一个未确认的分组的时间,超时发送第一个分组。



  • 相关阅读:
    maven springMVC SSM框架中 出现的406 (Not Acceptable)
    eclipse中maven项目部署到tomcat
    @RequestParam @RequestBody @PathVariable 等参数绑定注解详解
    springMvc注解之@ResponseBody和@RequestBody
    springmvc后台接前端的参数,数组,集合,复杂对象等
    Spring项目JUnit测试报错ClassNotFoundException解决
    后台给前端返回图片
    前端js实现 blob转base64位 和 base64位转blob
    tomcat中实现特定路径下的图片的url访问Tomcat配置图片保存路径,图片不保存在项目路径下
    data:image/png;base64 上传图像将图片转换成base64格式
  • 原文地址:https://www.cnblogs.com/loren-Yang/p/7499523.html
Copyright © 2011-2022 走看看