流行的因特网应用及其下面的运输层协议
应用	应用层协议	下面的运输协议
电子邮件	SMTP	TCP
远程终端访问	Telnet	TCP
Web	HTTP	TCP
文件传输	FTP	TCP
远程文件服务器	NFS	通常UDP
流式多媒体	通常专用	UDP或TCP
因特网电话	通常专用	UDP或TCP
网络管理	SNMP	通常UDP
名字转换	DNS	通常UDP

3.1、UDP报文结构

UDP报文段由4个字段和一个数据字段组成。应用层数据占用UDP报文段的数据字段。首部只有四个字段，每个字段由两个字节组成，分别是：源端口号，目的端口号，长度，检验和。

3.2、UDP检验和

UDP提供检验和的原因是不能保证源和目的之间的所有链路都提供差错检测，但是对差错恢复无能为力，可能会丢掉受损的报文段，也可能将受损的报文段交给应用程序并给出警告。

4、可靠数据传输原理

可靠数据传输的实现问题不仅在运输层出现，也会在链路层以及应用层出现。实现这种服务抽象是可靠数据传输协议的责任。

4.1、构造可带数据传输协议

4.1.1、经完全可靠信道的可靠数据传输：rdt1.0

在这个简单的协议中，一个单元数据与一个分组没差别。而且，所有分组是从发送方流向接收方;有了完全可靠的信道，接收端就不需要提供任何反馈信息给发送方，因为不必担心出现差错。

注意到我们也已经假定了接收方接收数据的速率能够与发送方发送数据的速率一样快。因此，接收方没有必要请求发送方慢一点。

4.1.2、经具有比特差错通信的可靠数据传输：rdt2.0

分组中比特可能受损，此时控制报文有肯定确认和否定确认。这些控制报文使接收方可以让发送方知道那些内容被正确接收，哪些内容接收有误并因此需要重复。基于这样重传机制的可靠数据传输协议称为自动重传请求协议。

ARQ三种协议功能：差错检测，接收方反馈，重传。

由于发送方不会发送一块新数据，除非发送方确信接收方已正确接受当前分组。这样的协议被称为停等协议。
如果一个ACK或者NCK分组受损发送方无法知道接收方是否正确接收了上一块发送的数据。遇到含糊不清的ACK和NCK分组时，一般情况是重传当前的数据分组，但是这种方法会引入冗余分组。
于是就有了rdt2.1中分组的序号（sequence number）来使接收方知道一个数据分组是新的分组还是冗余分组。

4.1.3、经具有比特差错的丢包信道的可靠数据传输：rdt3.0

假定会发生比特受损，而且底层信道会发生丢包，所以需要考虑怎样检测丢包以及发生丢包后该做什么：

可以让发送方负责检测和恢复丢包工作。假定发送方传输一个数据分组，该分组或接收方对该分组的ACK发生了丢失，在这两种情况下，发送方都收不到应当到来的接收方的响应如果发送方愿意等待足够长的时间以便确定分组已丢失，则它只需重传该数据分组即可。

为了实现基于时间的重传机制，需要一个倒计数定时器，在一个给定的时间量过期后，可中断发送方。因此，发送方需要能做到:

每次发送一个分组(包括第一次分组和重传分组)时，便启动一个定时器。
响应定时器中断(采取适当的动作)
终止定时器

因为分组序号在0和1之间交替，因此rdt3.0有时被称为比特交替协议。

4.2、流水线可靠数据传输协议

定义发送方(或信道)的利用率为:发送方实际忙于将发送比特送进信道的那部分时间与发送时间之比，得到停等协议有非常低的发送方利用率。

解决这种特殊的性能问题的一个简单方法是:不使用停等方式运行，允许发送方发送多个分组而无需等待确认。因为许多从发送方向接收方输送的分组可以被看成是填充到一条流水线巾，故这种技术被称为流水线。流水线对可靠数据传输协议带来如下影响：

必须增加序号范围，因为每个输送中的分组(不计算重传的)必须有一个唯一的序号，而且也许有多个在输送中未确认的报文
协议的发送方和接收方两端也许缓存多个分组。发送方最低限度应当能缓冲那些已发送但没有确认的分组，接收方或许也需要缓存那些已正确接收的分组。
所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组。解决流水线的差错恢复有两种基本方法是:回退N步和选择重传。

4.3、回退N步

GBN协议也常被称为滑动窗口协议，其中发送，还未确认的分组以及可用，还未发送的分组的长度N常被称为窗口长度。GBN协议的发送方和接收方的扩展FSM见书中。

GBN发送方必须响应三种类型的事件。

上层的调用：发送方首先检查发送窗口是否已满，即是否有N个已发送但未被确认的分组。
收到一个ACK：对序号为n的分组的确认采取累积确认（cumulative acknowledgement）的方式，表名接收方接收到序号为n的以前且包括n在内的所以分组。
超时事件：如果出现超时，发送方重传所有已发送但还未被确认过的分组。
接收方丢弃所有失序的分组：这种方法的优点是接收缓存简单，即接收方不需要缓存任何失序的分组。丢弃一个正确接收的分组的缺点是随后对该分组的重传也许会丢失或出错，因此甚至需要更多的重传。

4.4、选择重传

GBN存在的问题是，当窗口长度和带宽时延积都很大时，单个分组的差错就能够引起GBN重传大量分组。
选择重传协议通过让发送方仅重传那些它怀疑在接收方出错的分组而避免不必要的重传。SR接收方将确认一个正确接收的分组而不管其是否按序。
选择重传（SR）对窗口长度有一定的要求，窗口长度必须小于或等于序号空间大小的一半。
可靠数据传输机制及其用途的总结见书中表格，包括检验和，定时器，序号，确认，否定确认，窗口，流水线。
在高速网络的TCP扩展中，最长的分组寿命假定为大约3分钟。

无论GBN和SR都是为了在不可靠的传输（不特指UDP）的情况下，通过下层网络的方式来实现一个可靠地传输。GBN传输协议就是流水线传输，但是只要有一个未成功或者出现了乱序，就将目前已经收到的分组（乱序部分）全部丢去，然后重新传输；而SR是为了提高效率，在一个未成功的时候，不会全部丢弃，而是先进行缓存，直到未成功的到达，并形成了有序的队列就进行向上传输，然后才向后移动窗口。

5、面向连接的运输：TCP

5.1、TCP连接

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

中间路由器对TCP连接完全视而不见，他们看到的是数据包，而不是连接。 TCP连接提供的是全双工服务：如果一台主机上的进程A与另一台主机上的进程B存在一条TCP连接，那么应用层数据就可在从进程B流向进程A的同时，也从进程A流向进程B。

：

5.2、TCP报文段结构

TCP 连接的每一端都必须设有两个窗口

一个发送窗口
一个接收窗口

TCP 的可靠传输机制用字节的序号进行控制:所有的确认都是基于序号而不是基于报文段

TCP 两端的四个窗口经常处于动态变化中

TCP 连接的往返时间 RTT 也不是固定不变的:需要使用特定的算法估算较为合理的重传时间

源/目的端口——各占 2 字节
端口是运输层与应用层的服务接口:运输层的复用和分用都要通过端口实现
序号——占 4 字节
传送的数据流中的每一个字节都编上一个序号:序号的值则指的是本报文段所发送数据的第一个字节的序号
确认号——占 4 字节
期望收到对方下一个报文段的数据的第一个字节的序号
数据偏移（首部长度）——占 4 位
指出报文段的数据起始处距离报文段的起始处有多远:“数据偏移”的单位是 32 位字（以 4 字节为计算单位）
保留——占 6 位
为今后使用,但目前应置为 0
紧急 URG
URG = 1:紧急指针字段有效.它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据)
确认 ACK
只有当 ACK = 1 时确认号字段才有效;
当 ACK = 0 时,确认号无效
推送 PSH (PuSH)
接收 TCP 收到 PSH = 1 的报文段，就尽快地交付接收应用进程，而不再等到整个缓存都填满了后再向上交付
复位 RST (ReSeT)
当 RST = 1 时:TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接
同步 SYN
SYN = 1:这是一个连接请求或连接接受报文
终止 FIN (FINis)
用来释放一个连接
FIN = 1:此报文段的发送端的数据已发送完毕,并要求释放运输连接
窗口字段 —— 占 2 字节
用来让对方设置发送窗口的依据,单位为字节（发送方的接收窗口）
检验和 —— 占 2 字节
检验的范围包括首部和数据两部分
在计算检验和时,要在 TCP 报文段的前面加上 12 字节的伪首部
紧急指针字段 —— 占 16 位
指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）
选项 —— 长度可变
TCP 最初只规定了一种选项:最大报文段长度(MSS).
MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。

5.3、往返时间的估计与超时

        TCP采用超时/重传机制来处理报文段的丢失。重点问题就是超时间间隔长度的设置，超时间隔必须大于该连接的往返时间RTT，即从一个报文段发出到他被确认的时间，否则会造成不必要的重传。
        TCP 维持一个SampleRTT均值(称为EstimatedRTT)，即加权平均值。一旦获得一个新 SampleRTT时，TCP 就会根据下列公式来更新。参考值是α=0.125
        EstimatedRTT = (1 -α)xEstimatedRTT +αxSampleRTT

5.4、可靠的数据传输

TCP在lP不可靠的尽力而为服务之上创建了一种可靠数据传输服务。
TCP的可靠数据传输服务确保一个进程从其接收缓存中读出的数据流是无损坏、无间隔、非冗余和按序的数据流;即该字节流与连接的另一方端系统发送出的字节流是完全相同。

TCP发送方有3个与发送和重传有关的主要事件：

①、从上层应用程序接收数据;
②、定时器超时；
③、收到ACK；

5.4.1、超时重传

这是大多数TCP实现之中所做的一些修改。在这种修改中，每当超时事件发生时，TCP重传具有最小序号的还未被确认的报文段。只是每次TCP重传时都会将下一次的超时间隔设为先前值的两倍，而不是用从EstimatedRTT和DevRTT推算出的值。

这种修改提供了一个形式受限的拥塞控制，定时器过期很可能是由网络拥塞引起的，即太多的分组到达源与目的地之间路径上的一台(或多台)路由器的队列中，造成分组丢失或长时间的排队时延。在拥塞的时候，如果源持续重传分组，会使拥塞更加严重。相反，TCP使用更文雅的方式，每个发送方的重传都是经过越来越长的时间间隔后进行的。

5.4.2、快速重传

在重复接收到3个某一个报文段的冗余ACK的时候，就认为他之后的报文段发生了丢失，不管有没有发生超时，立刻进行重传。

产生TCP ACK的建议
事件	TCP接收方动作
具有所期望序号的按序报文段到达。所有在期望序号以及以前的数据都已被确认	延迟的ACK,对另外一个按序报文段的到达最多等待500ms 如果下一个按序报文段在这个时间间隔内没有到达，则发送一个ACK
具有所期望序号的按序报文段到达。另一个按序报文段等待ACK传输	立即发送单个累积ACK,以确认两个按序报文段
比期望序号大的失序报文段到达。检测出间隔	立即发送冗余ACK，指示下一个期待字节的序号（其为间隔的低端的序号）
能部分或者完全填充接收数据间隔的报文段到达	倘若该报文段起始于间隔的低端，则立即发送ACK

5.4.3、是回退N步还是选择重传

TCP确认是累积式的，正确接收但失序的报文段是不会被接收方逐个确认的。所以说有一点像GBN ，但许多TCP实现会将正确接收但失序的报文段缓存起来。所以TCP选择的是一种选择确认的机制。它允许TCP接收方有选择地确认失序报文段，而不是累积地确认最后一个正确接收的有序报文段。当将该机制与选择重传机制结合起来使用时(即跳过重传那些已被接收方选择性地确认过的报文段)，TCP看起来就很像我们通常的SR协议。就是选择性缓存。

5.5、流量控制

TCP通过让发送方维护一个称为接收窗口的变量来提供流量控制。通俗地说，接收窗口用于给发送方一个指示——该接收方还有多少可用的缓存空间。就是把这个变量插入到接收方发送的报文段中，用于告诉发送方还有多少空间可以使用。当主机B的接收窗口为0时（缓存空间为0），主机A继续发送只有一个字节数据的报文段。这些报文段将会被接收方确认，最终缓存将开始清空，并且确认报文里将包含一个非0缓存空间变量rwnd。

流量控制是因为网络太好，导致发送方发送太快，接收方的缓存空间不够而导致出错或者丢失的控制，是一个发送方与接收方的速度匹配问题，是在端上的控制。拥塞控制是因为网络不好，导致路由器发生了排队，导致丢包，是在网络核心上的控制

5.6、TCP连接管理

TCP连接的建立会显著地增加人们感受到的时延。

三次握手：

四次挥手：即TCP连接的释放(解除)。连接的释放必须是一方主动释放，另一方被动释放。

5.7、UDP和TCP的对比

6、拥塞控制原理

6.1、拥塞原因与代价

6.1.1、两个发送方和一台具有无穷大缓存的路由器

假设两个发送端、两个接收端；一个路由器，具备无限大缓冲区；输出链路为R;没有重传。

拥塞原因：

当每个连接的最大吞吐量为R/2（吞吐量=数据量/单位时间，即每个数据耗费的带宽）。
进入的速率接近链路路由带宽时，延迟增大。数量多

6.1.2、两个发送方和一台具有有限缓存的路由器

假设一个路由器，有限的缓冲。
拥塞原因：

分组在路由器滞留，发送方超时定时器触发，重传，造成死锁。
应用层的输入=应用层的输出
传输层的输入和重传>=传输层的输出（原始的数据+重传的数据导致越来越拥堵）

代价：

分组重复，分组可能会丢失，由于缓冲区满而丢失
为达到一个有效的输出，网络可能需要做更多的工作（重传）
没有必要的重传，链路中包括了多个分组的拷贝，降低了“goodput”

6.1.3、4个发送方和具有有限缓存的多台路由器及多跳路径

假设四个发送端，多重路径，超时/重传。

每当有一个分组在第二跳路由器上被丢弃时，第一跳路由器所做的将分组转发到第二跳路由器的工作就是"劳而无功"的。所以，我们在此又看到了由于拥塞而丢弃分组的另一种代价，即当一个分组沿一条路径被丢弃时，每个上游路由器用于转发该分组到丢弃该分组而使用的传输容量最终被浪费掉了。即当一个路由器拥塞导致分组丢失的时候，这个分组传送到该路由器所经历的上游路由器，所占用的链路资源都被浪费了。

查看源图像

6.2、拥塞控制的方法

6.2.1、端到端拥塞控制

在端到端拥塞控制方法中，网络层没有为运输层拥塞控制提供显式支持。
即使网络中存在拥塞，端系统也必须通过对网络行为的观察(如分组丢失与时延)来推断之。
TCP必须通过端到端的方法解决拥塞控制，因为IP层不会向端系统提供有关网络拥塞的反馈信息。

6.2.2、网络辅助的拥塞控制

在网络辅助的拥塞控制中，网络层构件(即路由器)向发送方提供关于网络中拥塞状态的显式反馈信息。
这种反馈可以简单地用一个比特来指示链路中的拥塞情况。

7、TCP拥塞控制

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

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

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

这里写图片描述

7.1、慢启动

发送方维持一个叫做拥塞窗口 cwnd (congestion window)的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。如再考虑到接收方的接收能力，则发送窗口还可能小于拥塞窗口。

慢开始门限 ssthresh 的用法如下：

当 cwnd < ssthresh 时，使用慢开始算法。
当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法。
拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，使拥塞窗口 cwnd 按线性规律缓慢增长。

7.2、拥堵避免

一旦进入拥塞避免状态，cwnd的值大约是上次遇到拥塞时的值的一半，而此时无法在通过对每一个RTT再将cwnd的值翻番，于是选择每个RTT只将cwnd的值增加一个MSS。
一种通用的方法是对于TCP发送方无论何时到达一个新的确认，就将cwnd增加一个MSS字节。
当出现超时时，TCP的拥塞避免算法行为相同与慢启动的情况一样，cwnd 的值被设置为1MSS，当丢包事件出现时，ssthresh的值被更新为cwnd值的一半。即更加精确，更加靠近最大的窗口数。

7.3、快速恢复

先对cwnd进行增加，增加的数值为冗余ACK的数量，然后进入拥塞避免状态。可以看出来，TCP的主要思路是通过“重启”的思路进行控制，通过一次一次的重启，来得到最接近于最大拥塞窗口的一个参数，而这个参数就代表了我们的流水线传输中可以在链路上可以传输的最大分组数目，然后在这个参数下进行传输。

这里写图片描述

总结

运输层——笔记自用。

本文含有隐藏内容，请开通VIP 后查看

【计算机网络——运输层】

1、概述和运输层服务

3.1.1、运输层和网络层的关系

3.1.2、因特网运输层概述

2、多路复用与多路分解

2.1、无连接的多路复用与多路分解

2.2、面向连接的多路复用与多路分解

2.3、web服务器与TCP

3、无连接运输UDP