第三章运输层读书笔记

最新推荐文章于 2022-05-12 14:45:24 发布

刷闲书的莉莉

最新推荐文章于 2022-05-12 14:45:24 发布

阅读量483

点赞数

分类专栏：计算机网络-自顶向下方法文章标签：读书笔记网络

本文链接：https://blog.csdn.net/qq_33716964/article/details/79656090

版权

计算机网络-自顶向下方法专栏收录该内容

1 篇文章 0 订阅

订阅专栏

第3章运输层

3.1 概述和运输层服务

运输层协议为运行在不同主机上的应用进程之间提供了逻辑通信。运输层协议是在端系统中而不是在路由器中实现的。网络路由器仅作用于该数据报的网络层字段，它们不检查封装在该数据报的运输层报文段的字段。

3.1.1 运输层和网络层的关系

网络层提供了主机之间的逻辑通信，而运输层为运行在不同主机上的进程之间提供了逻辑通信。运输协议能提供的服务往往受制于底层网络层协议的服务模型。

3.1.2 因特网运输层概述

UDP（用户数据报协议），它为调用它的应用程序提供了一种不可靠的、无连接的服务。另一种是TCP（传输控制协议），它为调用它的应用程序提供了一种可靠的、面向连接的服务。

3.2 多路复用和多路分解

我们讨论运输层的多路复用与多路分解，也就是将由网络层提供的主机到主机交付服务延伸到为运行在主机上的应用程序提供进程到进程的交付服务。

套接字是从网络向进程传递数据和从进程向网络传递数据的门户。在接收主机中的运输层实际上并没有直接将数据交付给进程，而是将数据交给了一个中间套接字。通过套接字将数据交付给对应进程。

将运输层报文段中的数据交付到正确的套接字的工作称为多路分解。在源主机从不同套接字中收集数据块，并为每个数据块封装上首部信息从而生成报文段，然后将报文段传递到网络层，所有这些工作成为多路复用。

1.无连接的多路复用和多路分解

一个UDP套接字是由一个二元组来全面标识的，该二元组包含一个目的IP地址和一个目的端口号。如果两个UDP报文段有不同的源IP地址和/或源端口号，但具有相同的目的IP地址和目的端口号，那么这两个报文段将通过相同的目的套接字被定向到相同的目的进程。

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

TCP套接字是由一个四元组（源IP地址，源端口号，目的IP地址，目的端口号）来标识的。当一个TCP报文段从网络到达一台主机时，该主机使用全部四个值来将报文段定向到相应的套接字。与UDP不同的是，即使两个报文具有相同的目的IP和目的端口号，两个具有不同源IP地址或源端口号的到达TCP报文段将被定向到两个不同的套接字，除非TCP报文段懈怠了初始创建连接的请求。

3.Web服务器和TCP

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

3.3 无连接运输：UDP

使用UDP差不多就是直接和IP打交道。

UDP的特点：
1. 没有阻塞控制、不保证可靠数据传输
2. 无需建立连接
3. 无连接状态
4. 分组首部开销小

3.3.1 UDP报文段结构

UDP首部有4个字段，每个字段由两个字节组成。长度字段指示了在UDP报文段中的字节数（首部加数据）。接收方使用检验和来检查在该报文段中是否出现了差错。

3.3.2 UDP校验和

发送方的UDP对报文段中的所有16比特字的和进行反码运算，求和时遇到任何溢出都要被回卷。

在接收方，全部的4个16比特字加在一起，如果该分组中没有引入差错，则将所有数据段的16比特字加上校验和，结果应为1111111111111111。

3.4 可靠数据传输原理

3.4.1 构造可靠数据传输协议

rdt 3.0发送方状态图：

校验码：验证报文段在发送过程中是否受损。

肯定确认、否定确认：当发送方将报文段发送给接收方时，接收方发送一个肯定确认或者否定确认到发送方以通知发送方发送报文数据是否正确。

序号：肯定确认或者否定确认在发送过程中可能会受损，为了处理这种错误，在数据分组中添加一段字段，让发送方对其数据分组编号，将发送数据分组的序号放在该字段。接收方只要检查序号即可确定到的分组是否一次重传。

倒计数定时器：肯定确认、否定确认丢失，或者过度延时，用于重传的计时器。

当发送方从上层接收到报文，将报文打包添加序号、校验码等信息，然后发送报文段并启动计时器，当接收到与打包序号相同的否定确认就重传报文段，当计时器超时了，同样执行重传操作，如果接收到与打包序号相同的肯定确认就继续发送报文，并重启计时器。如果接收到的确认与发送报文中的序号不同，则继续等待。

接收方FSM：

接收方相对发送方就很容易理解了，这里不多赘述。

流水线：然而现在的rdt算法在发送报文后要一直等待确认报文，否则将无法继续发送其他报文。这使性能大大降低。为了不使用停等的方式运行，允许发送方发送多个分组而无需确认等待。

3.4.3 回退N步（GBN）

GBN协议中发送方看到的序号：

[0 , base - 1]段内的序号对应于已经发送并被确认的分组。
[base , nextseqnum - 1]段内对应已被发送而没被确认的分组。
[nextsequm , base + N - 1]段内的序号能对于那些要被立即发送的分组。
[base + N , 无穷大)表示当前不可用的部分。

N称为窗口长度，GBN协议也常被称为滑动窗口协议。

如果分组序号字段的比特数是k，那么该序号的范围是[0,2^k - 1]。

GBN具有一个计数器，用于计数最近要接收的确认报文的是否超时。

GBN发送方描述：当上层调用rdt_send()时，检查是否发送窗口已满，如果未满则产生一个分组将其发送，将nextseqnum+1，当base和nextseqnum时相同时打开计时器。如果发送窗口已满，则将数据返回给上层，指示该窗口已满。当超时时，则重传所有现在已经发送但没有收到确认的分组，即绿色表示的分组。当收到一个ACK，如果ACK为base指向的分组的确认ACK则，base前移。

GBN接收方描述：当接收到顺序的分组，则base右移，然后发送肯定报文。如果接收到的分组是乱序的，那么丢弃该分组，返回最后一个已经接收到的报文的肯定确认。

发送方、接收方窗口大小比：2^k-1:1。

3.4.4 选择重传（SR）

选择重传协议中发送方看到的序号：

选择重传协议中接收方看到的序号：

发送方描述：
1. 从上层收到数据。从上层收到数据后，SR发送方检查下一个可用于该分组的序号。如果序号位于发送方的窗口内，则将数据打包并发送；否则通知上层。
2. 超时。每个分组都具有一个定时器，当定时器超时时，只用发送自己代表的那个分组就行。
3. 收到ACK。若收到的ACK在窗口内，则标记窗口内的分组，如果接收到的ACK是base分组的ACK，则移动窗口到最近的未接收到ACK的地方。

接收方描述：
1. 序号在[rcv_base , rcv_base + N - 1]内的分组被正确接收，返回一个ACK给发送方，如果没接收到过则缓存该分组，如果该分组为rcv_base，移动窗口。
2. 序号在[rcv_base - N , rcv_base - 1]内的分组被正确收到，产生一个ACK，即使该分组是接收方以前接收过并确认的分组。
3. 其他情况。忽略该分组。

发送方、接收方窗口大小比：2:1或者大于2/1。

3.5 面向连接的运输：TCP

3.5.1 TCP连接

面向连接的：在进程传输数据之前必须先互相“握手”，建立连接。

全双工服务：一台主机上的进程A与另一台主机上的进程B，在进程A发送数据流向进程B的同时，进程B可以发送数据流向进程A。

点对点的：单个发送方和单个接收方之间的连接。

TCP发送缓存和接收缓存：

TCP从上层获取数据放到发送缓存中，然后在3次握手后，TCP从缓存中取出数据包装发送到接收方缓存中，上层根据自己的情况从缓存中获取数据。TCP从缓存中取出并放入报文段的输入数量受限于最大报文段长度(Maximum Segment Size , MSS)。MSS通常根据最初确定的由本地发送主机发送的最大链路层帧长度来设置。

3.5.2 TCP报文段结构

TCP报文结构：

TCP报文包含如下字段：
- 源端口号、目的端口号
- 检验和字段
- 32比特的序号字段和32位确认号字段。两者用于提供可靠数据传输服务。
- 16比特的接收窗口字段。用于流量控制。
- 4比特的首部长度字段。该字段指示了以32比特的字为单位的TCP首部长度。由于TCP选项的原因，TCP首部长度是可变的。
- 可选和变长的选项字段。该字段用于发送方和接收方协商最大报文字段长度，或在告诉网络环境下用作窗口调节因子时使用。
- 6比特的标志字段。ACK用于指示确认字段总的值是有效的。RST、SYN、FIN用于连接建立和拆除。PSH比特被设置时，就指示接收方应立即将数据交给上层。URG比特用来指示报文段里存在着被发送端的上层设置为紧急的数据。PSH、URG以及紧急数据指针没有启用。

1.序号和确认号

序号：TCP将数据看成一个无结构、有序的字节流，序号用于标记分组顺序。吖

确认号：由于TCP是全双工的，发送方传输分组到接收方后，接收方需通知发送方数据得到，确认号用于标记接收方等待的下一个分组的序号。

TCP采用累计确认，并未规定接收到失序报文段如何处理，而是交给编程者处理。处理方法一般有如下两种：
1. 接收方立即丢弃失序报文；
2. 接收方保留失序字节，并等待缺少的字节以填补该间隔。

下面给出一个例子，用于演示序号和确认号的用法：

考虑Telnet协议的一个场景，即用户输入字符发送到远程服务器回显的情况。

TCP握手期间确定，发送方第一个报文序号为42，接收方第一个报文序号97。当用户键入第一个字符“C”，发送方发送第一个报文，然后序号和确认号不变，当主机接收到报文后，更新需要的下一个报文序号，然后返回回显数据，发送方收到回显数据后，更新需要发送的序号。

3.5.3 往返时间的估计与超时

1.估计往返时间

TCP估计发送方和接收方之间往返时间是通过如下方法完成的。

报文段的样本RTT（SimpleRTT）就是从某报文段被发出到对该报文的确认被收到之间的时间量。大多数TCP仅在某个时刻做一次SimpleRTT的测量，而不是Wie某个发送的报文段都测量SimpleRTT。

由于路由器的阻塞和端系统负载的变化，SimpleRTT总随之波动，TCP维持一个SampleRTT的均值，公式如下：

EstimatedRTT = (1-a)*EstimatedRTT + a*SampleRTT

RFC 6298给出的a的参考值为0.125。

定义RTT偏差为DevRTT，用于估算SampleRTT一般会偏离EstimatedRTT的程度：

DevRTT = (1 - b) * DevRTT + b * |SampleRTT - EstimatedRTT|

b的推荐值为 0.25。

2.设置和管理重传超时间隔

TCP确定重传和超时间隔公式如下：

TimeoutInterval = EstimatedRTT + 4 * DevRTT

3.5.4 可靠数据传输

TCP发送方有3个与发送和重传有关的主要事件：从上层应用程序接收数据；定时器超时；收到ACK。

从上层应用程序接收数据；TCP将数据封装在一个报文段，然后把报文段交给IP。如果定时器还未为某些报文段开启，则开启定时器。定时器设置时间是TimeoutInterval。
超时；TCP通过重传引起超时的报文段来响应超时事件。每次超时都会讲TimeoutInterval设置为原来的2倍，直至本报文段传输成功。
收到ACK；当该事件发生时，TCP将ACK的值y与它的变量SendBase进行比较。TCP状态变量SendBase是最早未被确认的序号。如果y>SendBase，则该ACK是在确认一个或多个现钱未被确认的报文段。因此更新它的SendBase变量。当接收到3个相同数据的冗余ACK，证明发生了数据丢失，立即重传冗余ACK指出的报文段，即快速重传。

TCP接收方事件：
1. 接收到顺序报文，发送ACK，请求下一序号报文
2. 丢失报文导致接收到乱序报文，发送ACK，请求原本要求序号报文。正因如此才能使用快速重传。

TCP的差错恢复机制是一种GBN和SR的混合体。

5.流量控制

流量控制是消除发送方使接收方缓存溢出的可能性。

拥塞控制是因为IP网络的拥塞而被遏制。

TCP通过让发送方维护一个称为接受窗口的变量来提供流量控制服务。主机A通过一条TCP连接连接向主机B。主机B为连接分配缓存RcvBuffer。同时考虑如下两个变量：
1. LastByteRead:主机B上的应用进程从缓存中读出的数据流的最后一个字节的编号。
2. LastByteRcvd:从网络中到达的并且已放入主机B接收缓存中的数据的最后字节的编号。

由于TCP不允许已经分配的缓存溢出，因此

LastByteRcvd - LastByteRead <= RcvBuffer

接收窗口采用rwnd表示，则是

rwnd = RcvBuffer - [LastByteRcvd - LastByteRead ]

主机B通过把当前的rwnd值放入它发给主机A的报文段的接收窗口字段中，通知主机A该连接的缓存中还有多少可用空间。

于此同时，主机A也必须跟踪两个变量，LastByteSent和LastByteAcked，即最后发送的变量序号和最后确认的变量序号，两者之差便是发送但未确认的数据量。而我们要做的就是将这个值控制在小于等于接收方rwnd的范围内。即

LastBySent - LastByteAcked <= rwnd

但不得不提的是，一旦rwnd变为0后，将不会产生交互，即使rwnd更改后发送方也得不到信息，因此，当rwnd为0时，主机A会继续发送只有一个字节的报文段。这些报文会被接收方确认，因此rwnd不为0时，发送方能得到通知。

至于UDP嘛，当产生缓存溢出时，UDP直接将报文丢掉，所以不存在流量控制。

3.5.6 TCP连接管理