【计算机网络基础 五】运输层

计算机网络 专栏收录该内容
7 篇文章 9 订阅

运输层向它上面的应用层提供通信服务,两个主机进行通信就是两个主机中的应用进程相互通信。通信的真正端点并不是主机而是主机中的进程。端到端的通信是应用进程之间的通信。

引入运输层的原因: 增加复用和分用的功能消除网络层的不可靠性提供从源端主机到目的端主机的可靠的、与实际使用的网络无关的信息传输

运输层的作用:向它上边的应用层提供通信服务,运输层向它上面的应用层提供通信服务,它属于面向通信部分的最高层,同时也是用户功能中的最低层
运输层的协议面向连接的TCP, 无连接的UDP
运输层的设备网关

进程间的通信

真正进行通信的实体是在主机中的进程,是这台主机中的一个进程和另一台主机中的一个进程在交换数据(即通信)。因此严格地讲,两台主机进行通信就是两台主机中的应用进程互相通信。IP协议虽然能把分组送到目的主机,但是这个分组还停留在主机的网络层而没有交付主机中的应用进程。从运输层的角度看,通信的真正端点并不是主机而是主机中的进程

分用和复用

运输层有一个重要功能:复用(multiplexing)和分用(demultiplexing)。

  • 复用指在发送方不同的应用进程都可以使用同一个运输层协议传送数据;
  • 分用指接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。

以下为运输层的传输示意图
在这里插入图片描述

网络层是为主机之间提供逻辑通信,而运输层为应用进程之间提供端到端的逻辑通信 运输层还要对收到的报文进行检测。

运输层的两种协议

根据应用程序的不同需求,运输层需要有两种不同的运输协议,面向连接的TCP和无连接的UDP

  • 当运输层采用面向连接的TCP协议时,尽管下面的网络是不可靠的,但这种逻辑通信信道就相当于一条全双工的可靠信道 。在传送数据之前必须先建立连接,数据传送结束后要释放连接。TCP不提供广播或多播服务。由于TCP要提供可靠的、面向连接的运输服务,因此不可避免地增加了许多的开销,如确认、流量控制、计时器以及连接管理等。这不仅使协议数据单元的首部增大很多,还要占用许多的处理机资源。例如电子邮件,确保文本不出错,可能缓慢,但更安全可靠
  • 当运输层采用无连接UDP协议时,这种逻辑通信信道仍然是一条不可靠信道。UDP在传送数据之前不需要先建立连接。远地主机的运输层在收到UDP报文后,不需要给出任何确认。虽然UDP不提供可靠交付,但在某些情况下UDP却是一种最有效的工作方式。例如通讯类软件,容忍出现一定杂音,但要求实时性

运输层向高层用户屏蔽了下面网络核心的细节(如网络拓扑、所采用的路由选择协议等),它使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道,但这条逻辑信道对上层的变现却因运输层使用的不同协议而又很大的差别。应用层对应的传输层协议如下:
在这里插入图片描述
UDP和TCP的主要区别

  • TCP提供面向连接的、可靠的数据流传输,而UDP提供的是非面向连接的、不可靠的数据流传输。
  • TCP传输单位称为TCP报文段,UDP传输单位称为用户数据报
  • TCP注重数据安全性,UDP数据传输快,因为不需要连接等待,少了许多操作,但是其安全性却一般。

主要就是以上三种区别。

运输层的端口

为了满足分用和复用的条件,给应用层的每个应用进程赋予一个非常明确的标志是至关重要的,在协议栈层间的抽象的协议端口是软件端口,和路由器或交换机上的硬件端口是完全不同的概念。硬件端口是不同硬件设备进行交互的接口,而软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址

  • TCP/IP的运输层用一个16位端口号来标志一个端口。但请注意**,端口号只具有本地意义**,它只是为了标志本计算机应用层中的各个进程在和运输层交互时的层间接口
  • 在互联网不同计算机中,相同的端口号是没有关联的。16位的端口号可允许有65535个不同的端口号,这个数目对一个计算机来说是足够用的

也就是说可以有65535个应用程序用不同的端口,每台电脑都足够了。
在这里插入图片描述

对应关系

分为:运输层TCP对应的应用程序,运输层UDP对应的应用程序。

运输层TCP对应的应用程序

  • FTP:定义了文件传输协议,使用21端口。
  • Telnet:一种用于远程登陆的端口,使用23端口,用户可以以自己的身份远程连接到计算机上,可提供基于DOS模式下的通信服务。
  • SMTP邮件传送协议,用于发送邮件。服务器开放的是25号端口。
  • POP3:它是和SMTP对应,POP3用于接收邮件。POP3协议所用的是110端口。
  • HTTP:是从Web服务器传输超文本到本地浏览器的传送协议

运输层UDP对应的应用程序

  • DNS:用于域名解析服务,将域名地址转换为IP地址。DNS用的是53号端口。
  • SNMP:简单网络管理协议,使用161号端口,是用来管理网络设备的。由于网络设备很多,无连接的服务就体现出其优势。
  • TFTP,简单文件传输协议,该协议在熟知端口69上使用UDP服务。

以上就是熟知的一些传输协议。

UDP协议

UDP用户数据报协议,是面向无连接的通讯协议,UDP数据包括目的端口号和源端口号信息,由于通讯不需要连接,所以可以实现广播发送

UDP协议特点

UDP通讯时不需要接收方确认,属于不可靠的传输,可能会出现丢包现象,实际应用中要求程序员编程验证。

  • UDP是无连接的,即发送数据之前不需要建立连接(当然,发送数据结束时也没有连接可释放),因此减少了开销和发送数据之前的时延。
  • UDP使用尽最大努力交付,即不保证可靠交付,因此主机不需要维持复杂的连接状态表(这里面有许多参数)。
  • UDP是面向报文的。发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付IP层。UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。这就是说,应用层交给UDP多长的报文,UDP就照样发送,即一次发送一个报文
  • UDP没有拥塞控制,因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。它允许在网络发生拥塞时丢失一些数据,但却不允许数据有太大的时延。UDP正好适合这种要求。
  • UDP支持一对一、一对多、多对一和多对多的交互通信
  • UDP的首部开销小,只有8个字节,比TCP的20个字节的首部要短

UDP与TCP位于同一层,但它不管数据包的顺序、错误或重发。因此,UDP不被应用于那些使用虚电路的面向连接的服务,UDP主要用于那些面向查询—应答的服务,例如NFS。相对于FTP或Telnet,这些服务需要交换的信息量较小。

在这里插入图片描述

UDP报文结构

IP数据报的检验和检验IP数据报的首部,UDP检验和是把首部和数据部分一起都检验的
在这里插入图片描述

每个UDP报文分UDP报头和UDP数据区两部分。首部字段很简单,只有8个字节由四个字段组成,每个字段的长度都是两个字节。各字段意义如下:

  • 源端口,在需要对方回信时选用。不需要时可用全。
  • 目的端口,在终点交付报文时必须使用
  • 长度UDP,用户数据报的长度,其最小值是8(仅有首部))。
  • 检验和,检测UDP用户数据报在传输中是否有错,有错就丢弃。

当运输层从IP层收到UDP数据报时,就根据首部中的目的端口,把UDP数据报通过相应的端口,上交最后的终点——应用进程

TCP/IP协议

TCP/IP协议是Internet最基本的协议、Internet国际互联网络的基础,由网络层的IP协议和传输层的TCP协议组成。通俗而言:

  • TCP负责发现传输的问题,一有问题就发出信号,要求重新传输,直到所有数据安全正确地传输到目的地。而IP是给因特网的每一台联网设备规定一个地址
  • IP层接收由更低层(网络接口层例如以太网设备驱动程序)发来的数据包,并把该数据包发送到更高层—TCP或UDP层;相反,IP层也把从TCP或UDP层接收来的数据包传送到更低层。
  • IP数据包是不可靠的,因为IP并没有做任何事情来确认数据包是否按顺序发送的或者有没有被破坏,IP数据包中含有发送它的主机的地址(源地址)和接收它的主机的地址(目的地址)。

TCP是面向连接的通信协议,通过三次握手建立连接,通讯完成时要拆除连接,由于TCP是面向连接的所以只能用于端到端的通讯。TCP提供的是一种可靠的数据流服务,采用“带重传的肯定确认”技术来实现传输的可靠性。TCP还采用一种称为“滑动窗口”的方式进行流量控制,所谓窗口实际表示接收能力,用以限制发送方的发送速度。

TCP报文段的首部格式

TCP虽然是面向字节流的,但TCP传送的数据单元却是报文段。一个TCP报文段分为首部和数据两部分,而TCP的全部功能都体现在它首部中各字段的作用:
在这里插入图片描述
一下是各个属性的含义:

  • 端口号用来标识同一台计算机的不同的应用进程。TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。

    • 源端口:源端口和IP地址的作用是标识报文的返回地址
    • 目的端口:端口指明接收方计算机上的应用程序接口
  • 序号和确认号:是TCP可靠传输的关键部分。

    • 序号是本报文段发送的数据组的第一个字节的序号
      在TCP传送的流中,每一个字节一个序号。e.g.一个报文段的序号为300,此报文段数据部分共有100字节,则下一个报文段的序号为400。所以序号确保了TCP传输的有序性。
    • 确认号,即ACK,指明下一个期待收到的字节序号,表明该序号之前的所有数据已经正确无误的收到。确认号只有当ACK标志为1时才有效。比如建立连接时,SYN报文的ACK标志位为0。
  • 数据偏移/首部长度:4bits。由于首部可能含有可选项内容,因此TCP报头的长度是不确定的,报头不包含任何任选字段则长度为20字节,4位首部长度字段所能表示的最大值为1111,转化为10进制为15,15*32/8 = 60,故报头最大长度为60字节。首部长度也叫数据偏移,是因为首部长度实际上指示了数据区在报文段中的起始偏移值

  • 保留:为将来定义新的用途保留,现在一般置0。

  • 控制位:URG ACK PSH RST SYN FIN,共6个,每一个标志位表示一个控制功能。

    • URG:紧急指针标志,为1时表示紧急指针有效,为0则忽略紧急指针。
    • ACK:确认序号标志,为1时表示确认号有效,为0表示报文中不含确认信息,忽略确认号字段。
    • PSH:push标志,为1表示是带有push标志的数据,指示接收方在接收到该报文段以后,应尽快将这个报文段交给应用程序,而不是在缓冲区排队。
    • RST:重置连接标志,用于重置由于主机崩溃或其他原因而出现错误的连接。或者用于拒绝非法的报文段和拒绝连接请求。
    • SYN:同步序号,用于建立连接过程,在连接请求中,SYN=1和ACK=0表示该数据段没有使用捎带的确认域,而连接应该捎带一个确认,即SYN=1和ACK=1。
    • FIN:finish标志,用于释放连接,为1时表示发送方已经没有数据发送了,即关闭本方数据流。
  • 窗口:滑动窗口大小,用来告知发送方接受端的缓存大小,以此控制发送端发送数据的速率,从而达到流量控制。窗口大小时一个16bit字段,因而窗口大小最大为65535。

  • 校验和:奇偶校验,此校验和是对整个的 TCP 报文段,包括 TCP 头部和 TCP 数据,以 16 位字进行计算所得。由发送端计算和存储,并由接收端进行验证。

  • 紧急指针:只有当 URG 标志置 1 时紧急指针才有效。紧急指针是一个正的偏移量,和顺序号字段中的值相加表示紧急数据最后一个字节的序号**。 TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式**。

  • 选项和填充:最常见的可选字段是最长报文大小,又称为MSS(Maximum Segment Size),每个连接方通常都在通信的第一个报文段(为建立连接而设置SYN标志为1的那个段)中指明这个选项,它表示本端所能接受的最大报文段的长度。选项长度不一定是32位的整数倍,所以要加填充位,即在这个字段中加入额外的零,以保证TCP头是32的整数倍。

  • 数据部分: TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时,双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送,也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中,也会发送不带任何数据的报文段。

理解了TCP数据报的格式后方便深入的进入到TCP的实现原理。

TCP协议特点

TCP是TCP/IP体系中非常复杂的一个协议。下面介绍TCP最主要的特点。

  • TCP是面向连接的运输层协议。这就是说,应用程序在使用TCP协议之前,必须先建立TCP连接。在传送数据完毕后,必须释放己经建立的TCP连接。
  • 每一条TCP连接只能有两个端点(endpoint),每一条TCP连接只能是点对点的(一对一)。这个问题后面还要进一步讨论。
  • TCP提供可靠交付的服务。通过TCP连接传送的数据,无差错、不丢失、不重复,并且按序到达
  • TCP提供全双工通信。TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存,用来临时存放双向通信的数据。在发送时,应用程序在把数据传送给TCP的缓存后,就可以做自己的事,而TCP在合适的时候把数据发送出去。在接收时,TCP把收到的数据放入缓存,上层的应用进程在合适的时候读取缓存中的数据。
  • 面向字节流。TCP 中的**“流”(stream)指的是流入到进程或从进程流出的字节序列**。TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。接收方的应用程序必须有能力识别收到的字节流,把它还原成有意义的应用层数据。

总结成一句话可以是:TCP是面向字节流的,可靠的,点对点的全双工面向连接协议。
在这里插入图片描述

连接的概念

TCP把连接作为最基本的抽象。每一条TCP连接有两个端点。那么,TCP连接的端点是什么呢?不是主机,不是主机的IP地址,不是应用进程,也不是运输层的协议端口。

  • TCP连接的端点叫做套接字(socket)或插口。根据RFC 793的定义:端口号拼接到(concatenated with) IP地址即构成了套接字。因此,套接字的表示方法是在点分十进制的IP地址后面写上端口号,中间用冒号或逗号隔开。例如,若IP地址是192.3.4.5而端口号是80,那么得到的套接字就是192.3.4.5:80

每一条TCP连接唯一地被通信两端的两个端点(即两个套接字)所确定即:

  • TCP连接定义为:{socket1, socket2}={(IP1: port1), (IP2: port2)}这里IP1和IP2分别是两个端点主机的IP地址,而port1和port2分别是两个端点主机中的端口号。TCP连接的两个套接字就是socket1和socket2。可见套接字socket是个很抽象的概念。

一定要记住:TCP连接的端点是个很抽象的套接字,即(IP地址:端口号)。也还应记住:同一个IP地址可以
有多个不同的TCP连接,而同一个端口号也可以出现在多个不同的TCP连接中

可靠传输的原理

TCP发送的报文段是交给IP层传送的。但IP层只能提供尽最大努力服务,也就是说,TCP下面的网络所提供的是不可靠的传输。因此,TCP必须采用适当的措施才能使得两个运输层之间的通信变得可靠。

我们可以使用一些可靠传输协议,当出现差错时让发送方重传出现差错的数据,同时在接收方来不及处理收到的数据时,及时告诉发送方适当降低发送数据的速度。这样一来,本来不可靠的传输信道就能够实现可靠传输了。下面从最简单的停止等待协议讲起

停止等待协议

全双工通信的双方既是发送方也是接收方。下面为了讨论问题的方便,我们仅考虑A发送数据而B接收数据并发送确认。因此A叫做发送方,而B叫做接收方。因为这里是讨论可靠传输的原理,因此把传送的数据单元都称为分组,而并不考虑数据是在哪一个层次上传送的。停止等待就是每发送完一个分组就停止发送,等待对方的确认。在收到确认后再发送下一个分组:

  • 无差错的情况
    在这里插入图片描述
  • 出现差错的情况,超时重传
    在这里插入图片描述
  • 确认丢失和确认迟到
    在这里插入图片描述

以上过程中需要注意:

  • A在发送完一个分组后,必须暂时保留已发送的分组的副本(在发生超时重传时使用).只有在收到相应的确认后才能清除暂时保留的分组副本。
  • 分组和确认分组都必须进行编号。这样才能明确是哪一个发送出去的分组收到了确认,而哪一个分组还没有收到确认。
  • 超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些

当发送方发的报文有差错或者接收方给的确认丢了或来晚了的情况下,通过以上的停止等待协议即可正确处理问题,使用上述的确认和重传机制,我们就可以在不可靠的传输网络上实现可靠的通信

像上述的这种可靠传输协议常称为自动重传请求ARQ (Automatic Repeat reQuest)。意思是重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组,为了提高传输效率,发送方可以不使用低效率的停止等待协议,而是采用流水线传输
在这里插入图片描述

连续ARQ协议

滑动窗口协议比较复杂,是TCP协议的精髓所在。下图是发送方维持的发送窗口,它的意义是:位于发送窗口内的5个分组都可连续发送出去,而不需要等待对方的确认。这样,信道利用率就提高了。分组发送是按照分组序号从小到大发送的
在这里插入图片描述
发送方收到了对第1个分组的确认,于是把发送窗口向前移动一个分组的位置.如果原来已经发送了前5个分组,那么现在就可以发送窗口内的第6个分组了。这种方式有优点也有缺点:

  • 优点:接收方一般都是采用累积确认的方式。这就是说,接收方不必对收到的分组逐个发送确认,而是在收到几个分组后,对按序到达的最后一个分组发送确认,这就表示:到这个分组为止的所有分组都己正确收到了
  • 缺点:如果传输过程中,中间某一分组丢失,那么,丢失分组后面的数据也都需重传

在深入讨论TCP的可靠传输问题之前,必须先了解TCP的报文段首部的格式

TCP的重要特性

这部分讨论TCP的重要特性:可靠传输、拥塞控制以及TCP连接

TCP可靠传输的实现

我们假定数据传输只在一个方向进行,即A发送数据,B给出确认。这样的好处是使讨论限于两个窗口,即发送方A的发送窗口和接收方B的接收窗口

滑动窗口实现方式

滑动串口按照如下的方式步骤实现:

  1. B将确认号31告知A,然后A从该确认号开始,发送后边的窗口大小的数据

这里写图片描述

  1. 如果此时32,33没有按序到达,说明31没有收到,所以B仍然只能给A返回确认号仍然是31
    这里写图片描述
  2. 如果31,32,33都顺利到达,A收到了新的确认号34,则滑动窗口向前移动3

这里写图片描述
4. 如果A在连续发送完42-53之后,P2和P3重合,发送窗口内的序号都已经用完了,但还没有再收到确认,这样A就等待一段时间(重传计时器控制)后就重传这部分数据,重新设置重传计时器,直到收到B的确认为止。
在这里插入图片描述

以上有几个指针标识的区间如下:

  • P3-P1 = A的发送窗口大小
  • P2-P1 = 已发送但还没有收到确认的
  • P3-P2 = 允许发送但还没有发送的

需要注意的是,窗口大小是可变的。发送方的发送窗口不能超过接收方给出的接收窗口的数值

发送缓存和接收缓存

发送缓存用来暂时存放: (1)发送应用程序传送给发送发TCP 准备发送的数据; (2)TCP已发送出但尚未收到的确认的数据。
接受缓存用来暂时存放: (1)按序到达的、但尚未被接受应用程序读取的数据; (2)未按序到达的数据。 在这里插入图片描述
应用进程把数据传送到TCP的发送缓存后,剩下的发送任务就由TCP来控制了。可以用不同的机制来控制TCP报文段的发送时机

  • 第一种机制是TCP维持一个变量,它等于最大报文段长度MSS。只要缓存中存放的数据达到MSS字节时,就组装成一个TCP报文段发送出去。
  • 第二种机制是由发送方的应用进程指明要求发送报文段,即TCP支持的推送(push)操作。
  • 第三种机制是发送方的一个计时器期限到了,这时就把当前已有的终存数据装入报文段(但长度不能韶过MSS)发送出去

以上三种方式对TCP的传输效率至关重要。

超时重传时间的选择

快了,频繁的重传可能是重复工作,无用却挤占信道;慢了,传输已经出了问题,发送方和接收方还在等。超时重传时间或大或小都会影响传输效率。但可以肯定的是:超时重传时间设置要比数据报往返时间(往返时间,简称RTT)长一点

RTTS报文往返时间

TCP采用了一种自适应算法,它记录一个报文段发出的时间,以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返时间RTTs(又称为平滑的往返时间)。

新的RTTs =1-α) * (旧的RTTs)+α * (新的RTT样本)  0≦α<1

RFC推荐的 α 值为1/8,即0.125。通过上面的公式得出的加权平均往返时间RTTS就比直接测量得出的RTT更加平滑,换句话说,新RTTS就是由7/8的旧RTTS和当前1/8的RTT(测量的新RTT样本)相加得出的

值得注意的是,如果 α 的取值越小,那么RTTS更新相对较平稳;反之 α 的值越接近于1,则RTTS更新浮动较大

超时重传时间
RTO = RTTs +4 * RTTd               (RTTd是RTT的偏差的加权平均值)
新的RTTd=1-β)*(旧的RTTd)+β*|RTTs-新的RTT样本|          (β的推荐值是0.25

选择确认SACK

可以看到上图中的重传使用了悲观的方式,如果第一个片段丢失而后面其他片段都接收到了,重传之后所有片段。若收到的报文段无差错,只是未按序号,中间还缺少一些序号的数据,那么能否设法只传送缺少的数据,而不重传已经正确到达接收方的数据? 答案是可以的。选择确认就是一种可行的处理方法,但是并不常用,因此大多数的实现还是重传所有未被确认的数据块

TCP的流量控制

流量控制(flow control)就是让发送方的发送率不要太快,要让接受方来得及接收。利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。发送方的发送窗口不能超过接收方给出的接收窗口的数值TCP的窗口单位是字节,不是报文段。

TCP拥塞控制的实现

拥塞控制就是防止过多的数据注入到网络中,这样可以使网络中的路由器或链路器不致过载。拥塞控制多要做的都有一个前提,就是网络能够承受现有的网络负荷拥塞控制是一个全局性的过程,涉及到所有的主机、多有的路由器,以及与降低网络传输性能有关的所有因素。相反,流量控制往往指点对点通信量的控制,是个端到端的问题。流量控制所要做的就是抑制发送端发送数据的速率,以便使接收端来得及接收。

TCP进行拥塞控制的算法有四种,即慢开始(slow-start)、拥塞避免(congestionavoidance)、快重传(fast retransmit)和快恢复(fast recovery)
在这里插入图片描述

慢开始和拥塞避免

发送方维持一个叫做拥塞窗口(congestion window)的状态变量。拥塞窗口的大小取决于网络的拥塞程度,并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口
在这里插入图片描述

  • 慢开始算法的思路是:先探测一下,由小到大逐渐增大发送窗口,也就是说由小到大逐渐增大拥塞窗口数值。使用慢开始算法后,每经过一个传输轮次(transmission round),拥塞窗口cwnd就加倍
    在这里插入图片描述

  • 拥塞避免算法的思路:是让拥塞窗口cwnd缓慢地增加,即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1,而不是加倍。这样,拥塞窗口cwnd按现行规律缓慢增长,比慢开始算法的拥塞窗口增长速率缓慢得多

慢开始结合拥塞避免算法,ssthresh是算法的切换,窗口大小到达这个值开始从慢开始切换到拥塞避免,到达拥塞上限的时候,将ssthresh减半,窗口设置为1,重新开始。

快重传和快恢复

快重传算法首先要求接受方每收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)而不要等待自己发送数据时才进行确认。

这里写图片描述

  • 当发送方连续收到三个重复确认时,就执行“乘法减小”算法,把慢开始门限ssthresh减半。这是为了预防网络发生拥塞。
  • 由于发送方现在认为网络很可能没有发生拥塞,因此与慢开始不同之处是现在不执行慢开始算法,而是把cwnd值设置为慢开始门限ssthresh减半后的数值,然后开始执行拥塞避免算法(“加法增大”),使拥塞窗口缓慢地线性增大。

在这里插入图片描述

TCP连接管理

TCP是面向连接的协议。运输连接是用来传送TCP报文的。TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。因此,运输连接就有三个阶段,即:连接建立、数据传送连接释放。运输连接的管理就是使运输连接的建立和释放都能正常地进行。

TCP连接的建立采用客户服务器方式。主动发起连接建立的应用进程叫做客户(Client)。而被动等待连接建立的应用进程叫做服务器
在这里插入图片描述

seq:"sequance"序列号;ack:"acknowledge"确认号;SYN:"synchronize"请求同步标志;;ACK:“acknowledge"确认标志”;FIN:"Finally"结束标志

三次握手

开始A和B都处于CLOSED状态然后B先进入LISTEN状态,等待请求

  • 首先Client端发送连接请求报文A发送后A进入SYN-SENT状态
  • Server段接受连接后回复ACK报文,并为这次连接分配资源,B发送后B进入SYN-RCVD状态
  • Client端接收到ACK报文后也向Server段发生ACK报文,并分配资源。A发送后A进入ESTAB-LISHED状态,B收到后也进入该状态,这样TCP连接就建立了。

三次握手的示意图如下:
在这里插入图片描述

为什么不是两次握手

为什么要三次握手防止失效的连接请求报文段突然又传送到主机B
场景:A首先发送一个连接请求,但是该请求在网络节点上滞留了,没有收到确认。于是A重传了一次请求,并且收到了B的确认,于是连接建立,数据传输完成后,释放连接,假定A发出的第一个请求报文段并没有丢失,而是在某些网络节点上滞留,本来是一个失效的请求,但B收到后误认为是A再次发出一个新请求,于是向A发送确认,同意建立连接。

  • 假定采用两次握手,那么只要B发出确认,则新的连接就建立了。由于A并没有发出请求,因此不理会B的确认,也不会向B发送数据,但B却以为新的连接已经建立,并一直等待A的数据,B的许多资源就这样白白浪费了。
  • 假定采用三次握手,则B发出确认,但A因为并没有发请求,所以不理会B的确认,B没有收到A的确认,则连接建立失败,B知道连接建立失败。会回收资源。

极端的情况可能由于Client端多次重新发送请求数据而导致Server端最后建立了N多个响应在等待,因而造成极大的资源浪费!所以,“三次握手”很有必要!

为什么不是四次握手

握手握的是序列号,四次握手的过程是

  1. A发送给B 同步序号SYN+A的seq为x
  2. B收到后确认收到ACK发给A,然后存储该序号SYN为B的ack=x+1,确认A的seq按序到达
  3. B向A发送SYN+自己的序列号seq为y
  4. A收到B的序列号,存储到本地,发送ack=y+1,确认收到了,发送ACK+ack和自己的新序号seq为x+1

由此可以看出,2和3两步可以合成一部,所以没有必要四次握手

四次挥手

TCP连接断开过程开始的时候A和B都处于ESTAB-LISHED状态

  • 假设Client端发起中断连接请求,也就是发送FIN报文。Server端接到FIN报文后,意思是说"我Client端没有数据要发给你了",但是如果你还有数据没有发送完成,则不必急着关闭Socket,可以继续发送数据。A发完后A进入FIN-WAIT-1状态

  • 所以你先发送ACK,“告诉Client端,你的请求我收到了,但是我还没准备好,请继续你等我的消息”。B收到后向A发送ack,B发完后B进入COLSE-WAIT状态

  • A收到B的确认后进入FIN-WAIT-2状态

  • 当B确定数据已发送完成,则向A发送FIN报文,“告诉Client端,好了,我这边数据发完了,准备好关闭连接了”。A收到B的ack就进入Client端收到FIN报文后, "就知道可以关闭连接了。B发完后B进入 LAST-ACK状态

  • 但是他还是不相信网络,怕Server端不知道要关闭,所以发送ACK后进入TIME_WAIT状态,如果Server端没有收到ACK则可以重传。“,Server端收到ACK后,“就知道可以断开连接了”。Client端等待了2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,我Client端也可以关闭连接了。Ok,TCP连接就这样关闭了!

在这里插入图片描述

设置2MSL时间的问题

为什么要设置2MSL的时间:

  • 1,为了保证A发送的最后一个ACK能到达B。因为这个ACK可能丢失,因为使B收不到确认,无法关闭,有个这段时间,B就可以超时重传FIN+ACK,然后A就重传一次ACK,然后重置定时器。最后A,B都能顺利关闭,如果没有这段时间,A发送完ACK就关闭,B不一定能顺利关闭
  • 2,防止“已失效连接请求报文段”出现在本连接中,A在发送完最后一个ACK后,再经过2MSL,就可以使本链接持续的时间内所产生的所有报文段都在网络中消失,这样就可以使下一个连接中不再出现这种旧的请求报文段

这个状态标准的持续时间是4分钟

TCP连接状态机

为了更清晰地看出TCP连接的各种状态之间的关系,下图给出了TCP的有限状态机。图中每一个方框即TCP可能具有的状态。每个方框中的大写英文字符串是TCP标准所使用的TCP连接状态名。状态之间的箭头表示可能发生的状态变迁。箭头旁边的字,表明引起这种变迁的原因,或表明发生状态变迁后又出现什么动作。请注意图中有三种不同的箭头。粗实线箭头表示对客户进程的正常变迁。粗虚线箭头表示对服务器进程的正常变迁。另一种细线箭头表示异常变迁
在这里插入图片描述

  • 0
    点赞
  • 0
    评论
  • 2
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

相关推荐
©️2020 CSDN 皮肤主题: 点我我会动 设计师:白松林 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值