【计算机网络】三运输层

运输层为运行在不同主机上的应用进程提供直接的通信服务起着至关重要的作用。
将网络层的在两个端系统之间的交付服务扩展到运行在两个不同端系统上的应用层进程之间的交付服务。

1、概述和运输层服务

运输层协议为运行在不同主机上的应用进程之间提供了逻辑通信功能。
运输层协议是在端系统而不是路由器中实现的：
在发送端，发送应用程序收到的报文会在运输层分成多个小的运输层报文段，然后加上运输层头部，传给网络层，由网络层封装成数据包进行传送，接收端网络层收到之后，将其中的运输层报文段传给运输层，然后运输层就可以进行处理，把里面的数据给接收端应用程序使用。

1.1运输层和网络层的关系

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

• 两个家庭里面的孩子进行邮件通信，在这个过程中，应用层报文就是信封的内容，家庭里面的孩子就是进程，这样这些孩子就相当于运行在不同主机或者端系统（家庭）上的进程，两个家庭里面负责收信的两个老大，就相当于运输层协议，他们只负责收信封，而不参与信封传送过程中的任何一个环节，同样的，运输层协议只负责将报文推到网络边缘，之在端系统上运行，而不考虑在网络核心中式如何移动的。那么邮政服务就类似网络层协议了，与上面类似的是，网络层协议也不会去处理运输层的头部。

• 不同的运输层协议提供的服务也是不一样的。

• 运输层提供的协议往往会受到网络层协议的服务模型的限制。

• 但是运输层协议会提供在不可靠网络层协议上实现可靠数据传输服务。

1.2因特网运输层概述

因特网所提供的两种截然不同的协议：UDP（用户数据报协议）和TCP（传输控制协议）。UDP为调用它的应用程序提供了一种不可靠的、无连接的服务；而TCP为调用它的应用程序提供了一种可靠的、面向连接的服务。

• 运输层的分组称为报文段segment
• UDP和TCP的最基本的任务是将两个端系统间的IP的交付服务扩展到运行在端系统上的进程间的交付服务。将这个过程称为运输层的多路复用和多路分解。下面我们会了解到这主要是使用端口号实现的。
• UDP所能提供的两种服务是数据交付和差错检查，这也是运输层服务的最低限度。UDP也是一种不可靠的协议，和IP一样。
• TCP所提供的额外服务有
  1）可靠数据传输，也就是可以保证数据的按时交付和完整性，通过一些流量控制、序号和定时器来实现。
  2）TCP还提供拥塞服务，力求为每一个通过拥塞网络链路的连接平等地共享网络链接带宽。

2、多路复用和多路分解

如上文所说，这也就是将由网络层提供的主机到主机交付服务延伸为运行在主机上的应用程序提供进程到进程的交付服务。多路复用和多路分解是所有计算机网络都需要的。

• 一个进程由一个或者多个套接字。运输层实际上不是将获得的报文段直接给进程，而是给进程对应的套接字，所以套接字是需要由标识符的。
• 将运输层报文段中的数据交付到正确的套接字的工作称为多路分解；在源主机从不同套接字中收集数据块，并为每个数据块封装上首部信息从而生成报文段，然后传递给网络层的工作称为多路复用。跟上文类似的是，家庭里面的老大收信封的过程就是多路复用，发信封的过程就是多路分解。
• 根据上文可知，要实现这样的多路复用功能，我们需要满足1）套接字有唯一标识2）每个报文段有特殊字符来指示该报文段所要交付的套接字。这些特殊字段，就是端口号字段。
• 端口号是一个16比特的数，大小在0-65535之间。0-1023是周知端口号，是受限制的。当我们开发一个新的应用程序的时候，我们需要为他分配一个端口号。

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

clientSocket=socket(socket.AF_INET,socket.SOCK_DGRAM)创建一个UDP套接字的时候，运输层会自动为它分配一个端口号。也可以通过clientSocket.bind((’’,19157))来进行绑定套接字和端口号的绑定。通常情况下，服务器端的端口号是特定的，比如HTTP是80，FTP是21。

• UDP套接字是一个二元组（目的IP，目的端口号），所以即使源IP或者源端口号不一样，但是只要目的IP和目的端口号一样，就会被同一个目的套接字定位到同一个目的进程。

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

与UDP套接字不同的是，TCP套接字是一个四元组（源IP，源端口号，目的IP，目的端口号）。所以需要四个值来定位到同一个套接字。

2.3Web服务器与TCP

连接套接字和进程之间不一定都是一一对应的，在当今的高性能Web服务器通常只使用一个进程，但是为每个新的客户连接创建一个具有新连接套接字的新线程。

3、无连接运输UDP

• UDP并不是什么都不做，只是做了运输层协议能够做的最少的工作。
• DNS是一个通常使用UDP的应用层协议的例子。
• UDP的优点：
  1）关于何时、发送什么数据的应用层控制更加精细。TCP会有一些拥塞控制，会在一些情况下控制运输层TCP发送发，而且TCP发送发会一直重传知道被目的主机确认接收。那么，对于一些实时应用来说，不希望过分的延迟报文段的传送，并且可以容忍一些数据丢失，所以TCP模型并不是特别适合这样的应用。
  2）无需建立连接。UDP因为不需要进行握手阶段，所以会减少很多握手时延
  3）无连接状态。TCP需要在端系统中维护连接状态，包括接收和发送缓存、拥塞控制参数以及序号与确认号的参数等等来实现可靠数据传输等服务。但是UDP不需要追踪这些参数。
  4）分组首部开销小。UDP的首部只有8字节，但是TCP的首部由20字节。
• 在应用方面，如电子邮件、远程终端访问、Web以及文件传输都运行在TCP之上，因为它们需要TCP提供的可靠数据传输服务。但是类似RIP路由选择表的更新等等，反而是使用UDP而不是TCP。多媒体应用的容错率较高，但是对于实时性的要求比较高，所以多媒体应用大部分都是运行在UDP之上。但是对于流式应用来说，TCP反而更受欢迎。
• UDP的缺点：
  1）没有拥塞控制，可能会导致拥塞状态的出现，这样的话，使用UDP就无法完成传输工作。
  2）不可靠，就会由很高的丢包率，这样的话，就会影响TCP发送发的速率。
• 但是实际上，使用UDP的应用也是可以依赖开发人员来实现可靠传输的。

3.1UDP报文段结构

UDP首部只有4个字段，8字节，每个字段2字节。通过源端口号和目的端口号可以执行分解功能，长度是首部和数据的总长度，校验和是用来实现基本的差错检查功能的。

3.2UDP校验和

校验进行加法运算的时候，溢出要进行回卷，最后再反码，就得到了校验和。在接收方，将所有的数据（也就是源端口号、目的端口号、长度和校验和）相加，如果结果全1，就是正确没有引入差错的。只要有一个比特结果是0，那么就说明在传输过程中出现了差错。
但是UDP只是检测出来有差错，并不能进行恢复。

5、面向连接的运输：TCP

TCP是因特网运输层的面向连接的可靠的运输协议。

5.1TCP链接

TCP是面向连接的，是需要有握手阶段的。
TCP只在端系统中运行，不会在中间的网络元素中运行，所以中间的网络元素是不会维持TCP连接状态。
TCP提供的是全双工服务：发送和接收可以同时进行。
TCP连接是点对点的，是在单个发送方和单个接收方之间的连接。多播就是指一次发送操作中，一个发送方可以将数据传送给多个接收方。
TCP连接包括：发送方和接收方的缓存、变量和与进程连接的套接字。
发送方TCP在合适时间将从缓存里面取数据进行发送，而接收方应用程序也是从缓存里面获取数据的。其中，在发送方从缓存里面取数据的时候受到MSS（最大报文段长度）的限制，通常是1460字节（不包括首部）。

5.2TCP报文段结构

由首部字段和数据字段组成。
①首部字段包括源端口号、目的端口号，用于多路复用和多路分解。以及检验和字段。这些和UDP里面的都一样。
②首部字段还包括32比特的序号字段和32比特的确认好字段。这些是用来实现可靠数据传输的。
③16比特的接收窗口字段，用于流量控制，表示接收方愿意接受的字节数量。
④4比特的首部长度字段
⑤可选与变长的选项字段，用于发送方和接收方协调的最大报文段长度MSS。
⑥6比特的标志字段：ACK用于 指示确认字段中的值是有效的额。还有URG紧急数据和紧急指针。RST、SYN和FIN用于连接建立和拆除。

数据字段往往会根据MSS来确定，所以在发送大文件的时候，会将数据分成大小为MSS的分组进行传输。

5.2.1序号和确认号

因为序号是建立在传输的字节流之上，而不是建立在传送的报文段的序列之上。一个报文段的序号因此是该报文段首字节的字节流编号。也就是TCP会隐含对字节流的字节进行编号。
确认号就是期望收到对方的下一个报文段的数据的第一个字节的序号。（TCP是使用累计确认的）。
如果先收到报文段3，再收到报文段2的话，接收方可以立即丢弃失序报文段，也可以进行缓存，这是由编程人员实现的。

如图的流程中，主机A是客户，且初始序号是42，主机B是服务器且初始序号是79。图中显示了3个报文段
①因为一开始都没有接收到任何数据，所以在客户发给服务器的报文段中，序号是客户的初始序号42，ACK代表期望收到的服务器传送的下一条数据的序号，也就是79，因为这个时候服务器还没有发过任何数据，所以是初始序号。
②在服务器收到报文段之后，会向客户进行发送。因为这是服务器发送的第一条数据，所以是初始序号79。并且ACK是期望收到的客户的下一条的数据序号，也就是43，这也表示服务器已经确认收到了42（及其之前）分组。
③客户对服务器的反馈，代表对79数据已经确认收到了。但是此时没有捎带任何数据。唯一目的就是确认已从服务器收到的数据。

5.3往返时间的估计与超时

TCP采用了超时/重传机制来处理报文段的丢失问题。那么确定时间间隔的大小（肯定要大于一个RTT）就是一个问题了。

5.3.1估计往返时间

用样本RTT来进行估计：被发送到对该报文段确认被收到之间的时间。在任意时刻，仅为一个已发送的但目前尚未被确认的报文段估计样本RTT。并且，TCP不会为已重传的报文段计算样本RTT。
因为SampleRTT是动态的，所以我们可以均值（EstimatedRTT）。

每次获取到新的样本RTT之后，就采用如图公式进行计算。其中a的参考值是0.125。EstimatedRTT是SampleRTT的加权平均值。
同时，对RTT差错的检测也是有意义的——RTT偏差DevRTT

如果样本RTT波动较小，那么DevRTT值就会很小；否则就会很大。

5.3.2设置和管理重传时间

时间首先需要大于等于EstimatedRTT的值，但是又不能相差很大，不然不能及时找到丢包数据，所以需要额外加上的余量就和DevRTT有关，DevRTT较大，那么余量就要大一些。
采用如下公式进行计算。

5.4可靠数据传输

5.4.1超时重传的情况

1）主机A向主机B发送一个序号为92的报文段，并且超时了，那么主机A会重传这个92报文段。
2）主机A向主机B发送两个报文段，序号分别是92和100。假设两个报文段确认都没有在超时之前到达，那么超时事件之后，主机A会重传92报文段，并且重启定时器。只要100报文段到达了，那么第二个报文段就不会进行重传。
3）同样地发送两个报文段，92报文段超时了，但是100没有，并且在92超时范围内到达了，也就是说现在主机A获得了100报文段的确认，那么就会认为之前的都已经接受的到了，所以不会进行重传任何报文段。

5.4.2超时间隔加倍

TCP重传具有最小序号的还未被确认的报文段。并且TCP每次重传都会将下一次的超时间隔设置为原来的两倍。
否则，因为定时器过期很可能是因为拥塞导致的，如果源主机持续发送重传，那么很可能会加剧网路的拥塞。而TCP的超时间隔加倍就很好的考虑到这一点。

5.4.3快速重传

因为TCP是累积确认的，为了避免因为一个报文段的丢失而导致整体的停滞，我们会引入一个冗余ACK。当TCP接收方收到一个具有这样序号的报文段的时候，也就是序号大于下一个所期望的、按序的报文段，它检测到了数据流中的一个间隔，这就是说有报文段丢失。又因为TCP不使用否定确认，所以接收方不能向发送方发挥一个显式的否定确认。相反，它只是对已经接收到的最后一个按序字节数据进行重复确认。
如果接收方发送了3个冗余ACK，那么就是一种否认确认的标志，这也是概率各种计算出来的。

5.4.4回退N步or选择重传

TCP是累积确认的，和GBN很相似，但是TCP中的接收方是可以进行缓存的，也就是可以缓存已经收到的但是不是按序到达的报文段。
所以，在这方面，GBN显得有点多余了，有些报文段已经收到了，就没有必要再进行重传了。但是同样的，在上文中提到的，TCP里面会存在一种情况：
也就是第二个报文段确认在第一个报文段超时时间间隔内到达了，但是第一个报文段却没有，但是在这种情况下，都不会进行重传。
这样的话，对于TCP就需要 进行改善。也就是用选择重传机制，可以跳过重传那些已经被接收方选择性地确认过的报文段。
所以，TCP的差错恢复机制可以说是GBN和SR的混合体。

5.5流量控制

TCP为它的应用程序提供了流量控制服务以消除发送方和接收方缓存溢出的可能性。就是一个速度匹配机制（发送方发送速率与接收方应用程序的读取速率）。
接收方需要有两个变量（接收方缓存总大小是RcvBuffer）：
1）LastByteRcvd：表示从网络中到达的并且已经放入接收方缓存中的数据流的最后一个字节的编号
2）LastByteRead：表示应用程序从缓存中读取的数据流的最后一个字节的编号
3）rwnd：表示接收方缓存可用的空间大小
所以LastByteRcvd-LastByteRead<=RcvBuffer
并且rwnd=RcvBuffer-[LastByteRcvd-LastByteRead]
接收方每次发送报文段的时候，将这个rwnd放入窗口字段一起发过去。这样的话，发送方就也需要一些对应的变量：
1）LastByteSent：发送方发往网络中的数据流的最后一个字节的编号。
2）LastByteAcked：发送方已经收到的确认的最后一个编号
所以在发送方中必须保证，发送方发过去的但是还没有收到确认的数量是接收方还可以接受的，也就是LastByteSent-LastByteAcked<=rwnd
存在的问题：
接收方满了之后就会将rwnd=0发送给发送方，假设此时之后发送方不会再发送数据，那么接收方就没有办法进行确认，那么如果接收方在一段时间之后rwnd不是0了，但是却没有机会告诉发送方。
这样就需要解决这个问题：当接收方接收窗口时0的时候，发送方会发送只有一个字节的数据，这样会等接收方的缓存清空之后，进行确认，就可以继续传送了。

6、拥塞控制原理

过多源发送了过多数据，超出网络处理能力，不同于流量控制。分组重传往往是网络拥塞的征兆。

6.1拥塞原因和代价

1）拥塞网络的一种代价就是即当分组的到达速率接近链路容量时，分组经历巨大的排队时延。
2）发送方在遇到大时延时所进行的不必要重传会引起路由器利用其链路带宽来转发不必要的分组副本。
3）当一个分组沿一条路径被丢弃时，每个上游路由器用于转发该分组到丢弃该分组而使用的传输容量最终被浪费掉了。

6.2拥塞控制方法

端到端拥塞控制和网络辅助的拥塞控制。

• 在端到端拥塞控制方法中，网络层没有为运输层拥塞控制提供显式支持。即使网络中存在拥塞，端系统也必须通过对网络行为的观察来推断。
• 在网络辅助的拥塞控制中，路由器向发送方提供关于网络中拥塞状态的显式反馈信息。比如可以用简单的一个比特来指示链路中的拥塞情况。拥塞信息从网络反馈到发送方通常使用的方式：经由接收方的网络反馈（路由器标记或者更新从发送方流向接收方的分组中的某个字段来指示拥塞的产生，至少需要一个完整的往返时间）和直接网络反馈（可以由网络路由器发送给发送方）。

7、TCP拥塞控制

TCP为运行在不同主机上的两个进程之间提供了可靠传输服务。
TCP必须使用端到端拥塞控制，因为IP层不向端系统提供显式的网络拥塞反馈。
让每一个发送方根据所感知到的网络拥塞程度来限制其能向连接发送流量的速率。

• ①发送方限制其向连接发送流量：
  每一端都由一个发送缓存、一个接收缓存和几个变量组成。发送方跟踪的变量除了前文中提到的之外，还有一个cwnd，对TCP发送方能向网络中发送流量的速率进行了限制。
  在一个发送方中未被确认的数据量不会超过cwnd和rwnd中的最小值
  LastByteSent-LastByteAcked<=min{cwnd,rwnd}
  所以就可以通过cwnd来限制发送方的发送流量

• ②发送方感知与目的地之间的路径上出现了拥塞：
  如果出现过度拥塞，那么对应路由器缓存就会溢出，引起数据报的丢弃，则合约就会引起丢包事件，发送方就认为在发送方到接收方的路径上出现了拥塞的指示。
  TCP是自计时的：TCP使用确认来触发增大它的拥塞窗口长度。如果确认一高速率到达，那么拥塞窗口将会更为迅速地增大。

• ③确定发送速率：
  需要使得网络不会拥塞，同时又能充分利用所有可用的宽带。
  1）当丢失报文段时应该降低TCP发送速率
  2）当对先前未确认报文段的确认到达时，要增加发送方的速率。
  3）带宽测探。
  TCP拥塞控制算法
  ①慢启动
  ②拥塞避免
  ③快速恢复

• 慢启动和拥塞避免是TCP的强制部分，二者区别在于收到ACK做出反应时对cwnd增加长度的方式。慢启动比拥塞避免能更快地增加cwnd的长度。
  慢启动就是每当收到一个ACK的时候，拥塞窗口会加一：cwnd的值易1个MSS开始并且每当传输报文首次被确认就增加一个MSS（发送速率会进行翻倍），所以TCP发送速率起始慢，但在慢启动阶段以指数增长。

• 结束事件：
  1）一个超时指示的丢包事件：发送方将cwnd设置为1并重新开始慢启动过程，并且ssthresh设置为cwnd/2。
  2）当cwnd的值等于ssthresh的时候，会结束慢启动并且进入拥塞避免模式：cwnd变成一半，并且之后每次加一个MSS。
  3）三个冗余ACK：执行快速重传并进入快速恢复：丢包之后，cwnd变成一半，ssthresh是cwnd的一半。

• 拥塞避免
  超时情况：cwnd的值设置为1个MSS，ssthresh值为cwnd的一半
  3个冗余ACK：cwnd的值减半，ssthresh变成cwnd的一半，并且进入快速恢复状态。

7.1公平性

在UDP方面的公平性，UDP不会有拥塞控制，所以不会因为拥塞而限制自己的速率，UDP源很有可能压制TCP流量；
在TCP并行方面，两个应用平分链路带宽，但是如果其中一个应用所并行的连接较多，这个时候就会显得不太公平。

7.2明确拥塞通告：网络辅助拥塞控制

虽然TCP是端到端拥塞控制，但是现在有如利用TCP、IP来允许从网络直接反馈给TCP发送方和接收方拥塞信号的方案。
在网络层，IP数据报首部的服务类型字段中的两个比特被用于ECN。接收方收到数据报中的拥塞指示之后，接收主机中的TCP通过在接收方到发送方的TCP ACK报文段中设置ECE （明确拥塞通告回显）比特，通知发送主机中的TCP收到拥塞指示。