运输层

119 阅读12分钟

1.运输层概述

计算机网络体系结构中的物理层、数据链路层以及网络层它们共同解决了将主机通过异构网络互联起来所面临的问题,实现了主机到主机的通信

但实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程

如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务,运输层协议又称为端到端协议

image.png

运输层向高层用户屏蔽了下面网络核心的细节(如网络拓扑、所采用的路由选择协议等),它使应用进程看起来就好像是在两个运输层实体之间有一条端到端的逻辑通信信道

根据应用需求的不同,因特网的运输层为应用层提供了两种不同的运输协议,即面向连接的TCP无连接的UDP,这两种协议就是本章要讨论的主要内容


2.运输层端口号、复用与分用的概念

2.1 端口号

运行在计算机上的进程使用进程标识符PID来标志

因特网上的计算机并不是使用统一的操作系统,不同的操作系统又使用不同格式的进程标识符

为了使运行不同操作系统的计算机的应用进程之间能够进行网络通信,就必须使用统一的方法对TCP/IP体系的应用进程进行标识

TCP/IP体系的运输层使用端口号来区分应用层的不同应用进程

  • 端口号使用16比特表示,取值范围0~65535

image.png

端口号只具有本地意义,即端口号只是为了标识本计算机应用层中的各进程,在因特网中,不同计算机中的相同端口号是没有联系的

2.2 发送方的复用与接收方的分用

image.png

image.png


3.UDP和TCP的对比

image.png

image.png

image.png

image.png

image.png


4. TCP的流量控制

一般来说,我们总是希望数据传输得更快一些

但如果发送方把数据发送得过快,接收方就可能来不及接收,这就会造成数据的丢失

所谓流量控制就是让发送方的发送速率不要太快,要让接收方来得及接收

利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制

  • TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小
  • TCP发送方收到接收方的零窗口通知后,应启动持续计时器。持续计时器超时后,向接收方发送零窗口探测报文

5. TCP的拥塞控制

在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络性能就要变坏。这种情况就叫做拥塞

  • 在计算机网络中的链路容量(即带宽)、交换结点中的缓存和处理机等,都是网络的资源

出现拥塞而不进行控制,整个网络的吞吐量将随输入负荷的增大而下降

四种拥塞控制算法:

  • 慢开始
  • 拥塞避免
  • 快重传
  • 快恢复

假定如下条件:

  1. 数据是单方向传送,而另一个方向只传送确认
  2. 接收方总是有足够大的缓存空间,因而发送方发送窗口的大小由网络的拥塞程度来决定
  3. 以最大报文段MSS的个数为讨论问题的单位,而不是以字节为单位

发送方维护一个叫做拥塞窗口cwnd的状态变量,其值取决于网络的拥塞程度,并且动态变化

  • 拥塞窗口cwnd的维护原则:只要网络没有出现拥塞拥塞窗口就再增大一些;但只要网络出现拥塞拥塞窗口就减少一些
  • 判断出现网络拥塞的依据:没有按时收到应当到达的确认报文(即发生超时重传

发送方将拥塞窗口作为发送窗口swnd,即swnd=cwnd

维护一个慢开始门限ssthresh状态变量

  • 当cwnd<ssthresh时,使用慢开始算法
  • 当cwnd>ssthresh时,使用拥塞避免算法
  • 当cwnd=ssthresh时,既可以使用慢开始算法,也可以使用拥塞避免算法

image.png

“慢开始”是指一开始向网络注入的报文段少,并不是指拥塞窗口cwnd增长速度慢

“拥塞避免”并非指完全能够避免拥塞,而是指在拥塞避免阶段将拥塞窗口控制为按线性规律增长,使网络比较不容易出现拥塞

慢开始和拥塞避免算法是1988年提出的TCP拥塞控制算法

1990年又增加了两个新的拥塞控制算法(改进TCP的性能),这就是快重传和快恢复

  • 有时,个别报文段会在网络中丢失,但实际上网络并未发生拥塞
    • 这将导致发送方超时重传,并误认为网络发生拥塞

采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失

所谓快重传,就是使发送方尽快进行重传,而不是等超时计时器超时再重传

  • 要求接收方不要等待自己发送数据时才进行捎带确认,而是要立即发送确认
  • 即使收到了失序的报文段也要立即发送对已收到的报文段的重复确认
  • 发送方一旦收到3个连续的重复确认,就将相应的报文段立即重传,而不是等该报文段的超时重传计时器超时再重传
  • 对于个别丢失的报文段,发送方不会出现超时重传,也就不会误认为出现了拥塞(进而降低拥塞窗口cwnd为1)。使用快重传可以使整个网络的吞吐量提高约20%

发送方一旦收到3个重复确认,就知道现在只是丢失了个别的报文段。于是不启动慢开始算法,而执行快恢复算法

  • 发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半,开始执行拥塞避免算法
  • 也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些,即等于新的ssthresh+3
    • 既然发送方收到3个重复的确认,就表明有3个数据报文段已经离开了网络
    • 这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中
    • 可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口扩大些

image.png


6.TCP超时重传时间的选择

超时重传时间的选择是TCP最复杂的问题之一

不能直接使用某次测量得到的RTT样本来计算超时重传时间RTO

利用每次测量得到的RTT样本,计算加权平均往返时间RTTs

RTTs1 = RTT1

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

在上式中,0 ≤ α < 1

  • 若α很接近0,则新的RTT样本对RTTs的影响不大
  • 若α很接近1,则新的RTT样本对RTTs的影响较大

已成为建议标准的RFC6298推荐的α值为1/8

用这种方法得出的加权平均往返时间RTTs就比测量出的RTT值更加平滑

显然,超时重传时间RTO应略大于加权平均往返时间RTTs

image.png


7.TCP可靠传输的实现

TCP基于以字节为单位的滑动窗口来实现可靠传输

image.png

image.png

虽然发送方的发送窗口是根据接收方的接收窗口设置的,但在同一时刻,发送方的发送窗口并不总是和接收方的接收窗口一样大

  • 网络传送窗口值需要经理一定的时间滞后,并且这个时间还是不确定的
  • 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸

对于不按序到达的数据应如何处理,TCP并无明确规定

  • 如果接收方把不按序到达的数据一律丢弃,那么接收窗口的管理将会比较简单,但这样做对网络资源的利用不利,因为发送方会重复传送较多的数据
  • TCP通常对不按序到达的数据是先临时存放在接收窗口中,等到字节流中所缺少的字节收到后,再按序交付上层的应用进程

TCP要求接收方必须有累计确认和捎带确认机制,这样可以减小传输开销。接收方可以在合适的时候发送确认,也可以在自己有数据要发送时把确认信息顺便捎带上

  • 接收方不应过分推迟发送确认,否则会导致发送方不必要的超时重传,这反而浪费了网络的资源。TCP标准规定,确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段,则必须每隔一个报文段就发送一个确认
  • 捎带确认实际上并不经常发送,因为大多数应用程序很少同时在两个方向上发送数据

TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此,每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时,一定要弄清楚是哪一方的窗口


8. TCP的运输连接管理

8.1 TCP的连接建立

TCP是面向连接的协议,它基于运输连接来传送TCP报文段

TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程

TCP运输连接有以下三个阶段:

  • 建立TCP连接
  • 数据传送
  • 释放TCP连接

image.png

TCP的连接建立要解决以下三个问题

  • 使TCP双方能够确知对方的存在
  • 使TCP双方能够协商一些参数(如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等)
  • 使TCP双方能够对运输实体资源(如缓存大小、连接表中的项目等)进行分配

TCP使用“三报文握手”建立连接

image.png

  • TCP的标准规定,SYN=1的报文段不能携带数据,但要消耗掉一个序号
  • TCP的标准规定,普通的确认报文段如果不携带数据,则不消耗序号

8.2 TCP的连接释放

TCP通过“四报文挥手”来释放连接

image.png

image.png

TCP服务器进程每收到一次TCP客户进程的数据,就重新设置并启动保活计时器(2小时定时)

若保活计时器定时周期内未收到TCP客户进程发来的数据,则当保活计时器到时后,TCP服务器进程就向TCP客户进程发送一个探测报文段,以后则每隔75秒钟发送一次。若一连发送10个探测报文段仍无TCP客户进程响应,TCP服务器进程就认为TCP客户进程所在主机出了故障,接着就关闭这个连接


9.TCP报文段的首部格式

为了实现可靠传输,TCP采用了面向字节流的方式

但TCP在发送数据时,是从发送缓存取出一部分或全部字节并给其添加一个首部使之称为TCP报文段后进行发送

  • 一个TCP报文段由首部数据载荷两部分构成
  • TCP的全部功能都体现在它首部中各字段的作用

image.png

image.png

  • 源端口:占16比特,写入源端口号,用来标识发送该TCP报文段的应用进程
  • 目的端口:占16比特,写入目的端口号,用来标识接收该TCP报文段的应用进程
  • 序号:占32比特,取值范围[0,2^32-1],序号增加到最后一个后,下一个序号就又回到0。指出本TCP报文段数据载荷的第一个字节的序号
  • 确认号:占32比特,取值范围[0,2^32-1],确认号增加到最后一个后,下一个确认号就又回到0。若确认号=n,则表明到序号n-1为止的所有数据都已正确接收,期望接收序号为n的数据
  • 确认号标志位ACK:取值为1时确认号字段才有效;取值为0时确认号字段无效。TCP规定,在连接建立后所有传送的TCP报文段都必须把ACK置1
  • 数据偏移:占4比特,并以4字节为单位。用来指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远。这个字段实际上是指出了TCP报文段的首部长度
  • 窗口:占16比特,以字节为单位。指出发送本报文段的一方的接收窗口。窗口值作为接收方让发送方设置其发送窗口的依据。这是以接收方的接收能力来控制发送方的发送能力,称为流量控制
  • 校验和:占16比特,检查范围包括TCP报文段的首部和数据载荷两部分
  • 同步标志位SYN:在TCP连接建立时用来同步序号
  • 终止标志位FIN:用来释放TCP连接
  • 复位标志位RST:用来复位TCP连接。当RST=1时,表明TCP连接出现了异常,必须释放连接,然后再重新建立连接
  • 紧急标志位URG:取值为1时紧急指针字段有效
  • 紧急指针:占16比特,以字节为单位,用来指明紧急数据的长度。当发送方有紧急数据时,可将紧急数据插队到发送缓存的最前面,并立刻封装到一个TCP报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据,紧急数据之后是普通数据
  • 填充:确保报文段首部能被4整除