运输层

运输层位于应用层和网络层之间,是分层的网络体系结构的重要部分。
TCP和UDP运输层协议。

1. 概述

运输层协议为运行在不同主机上的应用进程之间提供了逻辑通信功能。

从应用程序的角度看,通过逻辑通信,运行不同进程的主机好像直接相连一样。应用进程使用运输层提供的逻辑通信功能彼此发送报文,而无需考虑承载这些报文的物理基础设施的细节。

运输层协议是在端系统中而不是在网络路由器中实现的。

运输层将接收到的来自发送应用进程的报文转换为运输层分组,称为运输层报文段

1.1 运输层和网络层的关系

运输层为运行在不同主机上的进程之间提供了逻辑通信,而网络层则提供了主机之间的逻辑通信。

比方:有两个家庭,分别位于东方和西方,每家有 12 个孩子。孩子间的关系为堂兄弟姐妹,每个人每周要给堂兄弟姐妹写一封信。每个家庭有一个孩子负责收发邮件,西方是Ann,而东方是Bill。每周Ann取她的兄弟姐妹那里收集信件,并将这些信件交给门口的邮政运输车。当信件达到西方时,Ann也负责将信件分发到她的兄弟姐妹手上。Bill的工作类似。

在这个例子中,邮政服务为两个家庭间提供逻辑通信,Ann和Bill为堂兄弟姐妹之间提供了逻辑通信。
应用层报文 = 信封上的字
进程 = 堂兄弟姐妹
主机(端系统) = 家庭
运输层协议 = Ann和Bill
网络层协议 = 邮政服务

运输层协议只工作在端系统,在端系统中,运输层协议将来自应用进程的报文移动到网络边缘(即网络层)。

1.2 因特网运输层概述

UDP(用户数据报协议):提供不可靠的、无连接的服务。
TCP(传输控制协议):提供可靠的、面向连接的服务。
将运输层报文段称为报文段

因特网网络层协议叫IP(网际协议)。IP为主机之间提供了逻辑通信。Ip服务模型是尽力而为交付服务。

2. 多路复用与多路分解

UDP和TCP的基本任务是,将两个端系统间IP的交付服务扩展为运行在两个端系统上的进程之间的交付服务。将主机交付扩展到进程间交付,称为运输层的多路复用多路分解

进程有一个或多个套接字,它相当于从网络向进程传递数据和从进程向网络传递数据的门户。接收主机中的运输层实际上并没有直接将数据交付给进程,而是通过一个中间的套接字来传递。

为了将主机接收到的运输层报文段定向到合适的套接字,在每个运输层报文段中设置了几个字段。
在接收端,运输层检查这些字段并标识出接收套接字,然后将报文段定向到该套接字。将运输层报文段中的数据交付到正确的套接字的工作称为多路分解

从源主机的不同套接字中收集数据块,并未每个数据块封装上首部信息从而生成报文段,然后将报文段传递到网络层的工作称为多路复用

比方:Bill从邮政员那里收到信件,分发给兄弟姐妹的操作就是多路分解。Ann从兄弟姐妹那里收集信件并交给邮政员就是多路复用。

3. UDP

运输层必须提供一个多路复用/多路分解服务,以便在网络层与正确的应用级进程间传递数据。

由RFC 768定义的UDP只是做了运输协议能够做的最少工作。UDP从应用进程得到数据,附加上多路复用/多路分解服务所需的源端口号和目的端口号字段,及两个其他小字段,然后将形成的报文段交给网络层。

使用UDP时,在发送报文段之前,发送方和接收方的运输层实体之间没有进行握手。因此,被称为无连接的。

3.1 UDP报文段结构

运输层

UDP首部只有4个字段,每个字段由两个字节组成。
通过端口号可以使目的主机将应用数据交给运行在目的端系统中的相应进程(多路分解)。接收机使用检验和来检查报文段中是否存在差错。

3.2 UDP检验和

UDP将所有的16比特字相加,在相加过程中如有溢出,要被回卷,最后得到检验和。

在接收方,将所有的16比特字与检验和一起相加,如无差错,得到的将是1111111111111111。

4. 可靠数据传输的原理

TCP是在不可靠的端到端网络层协议(IP)之上实现的可靠数据传输协议。
双向数据传输 = 全双工数据传输

4.1 流水线可靠数据传输协议

允许发送方发送多个分组而无需等待确认,这种技术称为流水线
解决流水线的差错恢复有两种基本方法:回退 N 步(Go-Back-N,GBN)和选择重传

回退 N 步

N:在流水线中未确认的分组数不能超过的最大允许数N。

基序号(base):最早的未确认分组的序号。
下一个序号(nextseqnum):最小的未使用序号(即下一个待发送分组的序号)。

则可将序号范围分为4部分:
[0, base - 1]:已经发送并确认过的分组。
[base, nexrseqnum - 1]:已经发送但未被确认的分组。
[nextseqnum, base + N -1]:要被立即发送的分组,其数据来自上层。
大于等于 base + N 的序号是不能使用的。

运输层

那些已被发送但还未被确认的分组的许可序号范围可以被看成是一个在序号范围内长度为 N 的窗口。随着协议的运行,该窗口在序号空间内向前滑动。

N 常被称为窗口长度(window size),GBN协议常被称为滑动窗口协议

一个分组的序号承载在分组首部的一个固定长度的字段中。如果分组序号字段的比特数是 k,则该序号范围是0~2k - 1.

GBN发送方必须响应以下三种类型的事件:
上层的调用
收到ACK。对序号为n的分组的确认采取累积确认的方式,表明接收方已正确接收到序号n以前的所有分组。
超时事件。如果出现超时,发送方将重传所有已发送但还未被确认的分组。

接收方的动作也很简单。如果一个序号为n的分组被正确接收到,并且按序(即上次交付给上册的数据是序号为n-1的分组),则接收方为分组n发送一个ACK,并将该分组中的数据交付到上层。在所有其他情况下,接收方都丢弃该分组,并为最近按序接收的分组重传ACK。

选择重传(SR)

一个单个分组的差错就可能引起GBN重传大量分组,许多分组根本没有必要重传。

选择重传协议通过让发送方仅重传那些它怀疑在接收方出错的分组而避免了不必要的重传。

失序的分组将被缓存直到所有丢失分组(即序号更小的分组)都被收到,这时才可以将一批分组按序交付给上层。

对于SR协议而言,窗口长度必须小于等于序号空间大小的一半。

5. 面向连接的运输:TCP

5.1 TCP连接

TCP是面向连接的,在一个应用进程可以开始向另一个应用进程发送数据之前,这两个进程必须先相互“握手”,即它们必须相互发送某些预备报文段,以建立确保数据传输所需的参数。

TCP提供的是全双工服务

客户机进程通过套接字传递数据流。数据一旦通过该门户,它就由客户机中运行的TCP控制了。TCP将这些数据引导到该连接的发送缓存里,发送缓存是在三次握手初期设置的缓存之一。

TCP可从缓存中取出并放入报文段中的数据量受限于最大报文段长(maximum segment size, MSS)。MSS通常根据最初确定的最大链路层帧长度来设置,本地发送主机发送长度是这样的帧,即所谓最大传输单元(maximum transmission unit, MTU)。

TCP组成包括:一台主机上的缓存、变量和与一个进程连接的套接字,以及另一台主机上的一套缓存、变量和与一个进程连接的套接字。

5.2 TCP 报文段结构

运输层

32比特的序号字段和32比特的确认号字段。

16比特的接收窗口字段,用于流量控制。用于指示接收方愿意接收的字节数量。

4比特的首部长度字段,该字段指示了以32比特的字为单位的TCP首部长度。

可选与变长的选项字段,用于当发送方与接收方协商最大报文段长度(MSS)。

6比特的标志字段。ACK比特用于指示确认字段中的值是有效的,即该报文段包括一个堆已被成功接收的报文段的确认。RST、SYN、FIN比特用于连接建立和拆除。

序号和确认号

TCP把数据看成一个无结构的但是有序的字节流。序号是建立在传送的字节流之上,而不是建立在传送的报文段的序列之上。

一个报文段的序号是该报文段首字节的字节流的编号。假定数据流由一个包含500 000个字节的文件组成,MSS为 1000 字节,手续的首字节编号为 0 。则TCP将为该数据流构建 500 个报文段,第一个报文段被赋为 0,第二个报文段的序号被赋为 1000 ,以此类推。

主机 A 填充进报文段的确认号是主机 A 期望从主机 B 收到的下一个字节的序号。

TCP是提供累积确认。

5.3 可靠数据传输

TCP是在IP的不可靠的尽力而为服务的基础上建立了一种可靠数据传输服务

如果TCP发送方接收到对相同数据的3个冗余ACK,它就人为跟在这个已被确认过3次的报文段之后的报文段已经丢失。一旦收到3个冗余ACK,TCP就执行快速重传。

5.4 流量控制

当TCP连接接收到正确按序的字节后,它就将数据放入接收缓存。

TCP为应用程序提供了流量控制服务,以消除发送方使接收方缓存溢出的可能性。
TCP发送方页可能因为IP网络的拥塞而被遏制,这种形式的发送方的控制就被称为拥塞控制

TCP通过让发送方维护一个称为接收窗口的变量来提供流量控制。接收窗口用于告诉发送方,该接收方还有多少可用的缓存空间。因为TCP是全双工通信,在连接两端的发送方都各自维护一个接收窗口。

例如:
主机A通过一条TCP连接向主机B发送一个大文件。主机B为该连接分配一个接收缓存,大小为 RcvBuffer。主机B上的应用进程不时地从该缓存中读取数据。
- LastByteRead:主机B上的应用进程从缓存读出的数据流最后一个字节的编号。
- LastByteRcvd:从网络中到达的并且已放入主机B接收缓存中的数据流最后一个字节的编号。

由于TCP不允许已分配的缓存溢出,所以下式必须成立:
LastByteRcvd - LastByteRead <= RcvBuffer

接收窗口 RcvWindow:
RcvWindow = RcvBuffer - [LastByteRcvd - LastByteRead]

运输层

UDP并不提供流量控制。

5.5 TCP连接管理

建立连接

运行在一台主机(客户机)上的一个进程想与另一台主机(服务器)上的一个进程建立一条连接。客户机进程首先会通知客户机TCP,它想建立一个与服务器上某个进程之间的连接。客户机中的TCP会用以下方式与服务器中的TCP建立一条TCP连接:

  • 第一步:客户机端的TCP首先向服务器端的TCP发送一个特殊的TCP报文段。

该报文段不包含应用层数据,但是报文段的首部中的一个标志位(即SYN比特)被置为1。这个特殊的报文段称为SYN报文段。客户机会选择一个起始序号(client_isn),并放置到该起始的TCP SYN报文段的序号字段中。

  • 第二步:SYN报文段的IP数据报到达服务器主机,服务器会从该数据报中提取出TCP SYN报文段,为该TCP连接分配TCP缓存和变量,并向客户机TCP发送允许连接的报文段。

这个允许连接的报文段页不包含应用层数据。在报文段的首部却包含3个重要的信息,首先,SYN比特被置为 1;其次,在报文段的首部的确认号字段被置为client_isn + 1;最后服务器选择自己的初始序号(server_isn)。该报文段有时也被称为SYNACK报文段

  • 第三步:在收到SYNACK报文段后,客户机也要给该连接分配缓存和变量。客户机主机还会向服务器发送另一个报文段。

该报文段对服务器的允许连接的报文段进行了确认,通过将值 server_isn + 1放置到TCP报文段的首部的确认字段中来完成此项工作。因为连接已经建立,所以该SYN比特被置为 0。

在以后的每一个报文段中,SYN比特都将被置为 0 。两台主机之间发送了3个分组,所以被称为三次握手

运输层

断开连接

客户机应用进程发出一个关闭连接命令:

  • 客户机TCP向服务器进程发送一个特殊的TCP报文段。这个特殊的报文段首部中的一个标志比特,即FIN 比特将被置为1.
  • 服务器接收到该报文段后,向客户机回送一个确认报文段。
  • 服务器发送终止报文段,其FIN比特被置为 1 。
  • 客户机对这个服务器的终止报文段进行确认。

运输层


建立连接:
客户机中的TCP向服务器中的TCP发送一个SYN报文段,发送过后,进入SYN_SENT(同步发送状态)。
当客户机TCP处在SYN_SENT状态时,等待来自服务器TCP对客户机所发报文段进行确认的且SYN比特被置为1的一个报文段。
收到确认报文段后,客户机TCP进入ESTABLISHED(已建立)状态。

断开连接:
客户机TCP发送一个FIN比特被置为 1 的TCP报文段,并进入FIN_WAIT_1状态。
当处在 FIN_WAIT_1 状态时,客户机TCP等待一个来自服务器的带有确认信息的TCP报文段。
收到该报文段后,客户机进入 FIN_WAIT_2 状态。
当处在 FIN_WAIT_2 状态时,客户机等待来自服务器的 FIN 比特被置为 1 的另一个报文段。
收到该报文段后,客户机TCP对服务器的报文段进行确认,并进入 TIME_WAIT 状态。
TIME_WAIT 状态使得 TCP 客户机重传最终确认报文,以防该 ACK 丢失。一般是30秒、1分钟或2分钟。

6. 拥塞控制原理

在实际中,丢失一般是在网络变得拥塞时由于路由器缓存溢出引起的。分组重传作为网络拥塞的征兆。

网络拥塞开销:
当分组到达速率接近链路容量时,分组经历的巨大排队时延。
发送方必须执行重传以补偿因为缓存溢出而丢失的分组。
发送方在遇到大时延时所引起的不必要重传会引起路由器利用其链路带宽来转发不必要的分组拷贝。
当一个分组沿一条路径被丢弃时,每个上游路由器用于转发该分组到丢弃该分组而使用的传输容量最终被浪费掉了。

6.1 拥塞控制方法

端到端拥塞控制。在这种方法中,网络层并没有为运输层拥塞控制提供显式支持。即使网络中存在拥塞,端系统也必须通过对网络行为的观察(如分组丢失与时延)来推断。

网络辅助的拥塞控制。网络层组件(即路由器)向发送方提供关于网络中拥塞状态的显式反馈信息。

7. TCP拥塞控制

TCP必须使用端到端拥塞控制而不是网络辅助的拥塞控制,因为IP层不向端系统提供显式的网络拥塞反馈。

TCP采用的方法时让每一个发送方根据所感知到的网络拥塞的程度,来限制其能向连接发送流量的速率。

TCP拥塞控制机制让连接的每一段都记录一个额外的变量,即拥塞窗口。拥塞窗口表示为 CongWin ,它对一个TCP发送方能向网络中发送流量的速率进行了限制。
在一个发送方中未被确认的数据量不会超过 CongWin 与 RcvWindow 中的最小值。

RTT(往返时延)

TCP丢包事件:出现超时;收到来自接收方的3个冗余ACK。

UDP没有内置的拥塞控制。

相关文章:

猜你喜欢
相关资源
相似解决方案