计算机网络：传输层

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/weixin_36049506/article/details/90762200

传输层的重要概念

1. 传输层为相互通信的应用进程提供逻辑通信
2. 端口和套接字的意义
3. 无连接的UDP的特点
4. 面向连接的TCP的特点
5. 在不可靠的网络上实现可靠传输的工作原理，停止等待协议和ARQ协议
6. TCP的滑动窗口、流量控制和连接管理

概述

传输层是只有主机（边缘）才有的层次，核心网只有物理层，数据链路层和网络层这三个层次。
下层为上层提供服务，所以传输层为应用层提供通信服务，同时也可以使用网络层的服务。
传输层的数据称之为报文段。

传输层的功能

1. 传输层提供进程和进程之间的逻辑通信。实际上进程和进程之间是没有物理通信的，需要依靠网络层，数据链路层和物理层才能实现物理通信。
2. 复用（multiplexing）和分用（demultiplexing）
   复用指在发送方不同的应用进程（加上适当的首部）都可以使用同一个运输层协议传送数据；分用指接收方的运输层在剥去报文首部后能够把这些数据正确交付目的应用进程。
3. 传输层对收到的报文进行差错检测。在网络层，IP数据报首部中的检验和字段，只检验首部是否出现差错而不检查数据部分。

传输层的两个协议

TCP	UDP
全双工	半双工
传送数据前必须建立连接，数据传送结束后要释放连接。 不提供广播或多播服务。 由于TCP要提供可靠的面向连接的传输服务，因此不可避免的增加了许多开销：确认，流量控制，计时器及连接管理等。	传送数据之前不需要建立连接，收到UDP报文之后也不需要给出任何确认。
可靠，面向连接，时延大，适用于大文件	不可靠，无连接，时延小，适用于小文件

传输层的寻址与端口

和计算机网络的下面三层不同，进程的创建和撤销都是动态的，通信的一方几乎无法识别对方机器上的进程。把进程设为通信的终点是不可行的。

传输层使用协议端口号（简称端口，port）作为传输的终点。这就是说，只要把传送的报文交到目的主机的某个合适的端口，剩下的工作（即最后交付目的进程）由TCP或UDP来完成。

这种在协议栈层间的抽象的协议端口是软件端口，和路由器或交换机上的硬件端口是完全不同的概念。硬件端口是不同硬件设备进行交互的端口，而软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。不同的系统具体实现端口的方法是不同的（取决于系统使用的操作系统）。

端口号只有本地意义，在因特网中不同计算机的相同端口是没有联系的。

端口号长度为16bit，能表示65535个不同的端口号。


在网络中采用发送方和接收方的套接字组合来识别端点。套接字唯一标识了网络中的一个主机和它上面的一个进程。
$套接字Socket=（主机IP地址，端口号）$

UDP协议

用户数据报协议UDP概述

UDP只在IP数据报服务之上增加了很少的功能，即复用功能和差错检测功能。
UDP的主要特点：

1. UDP是无连接的，减少开销和发送数据之前的时延。
2. UDP使用最大努力交付，即不保证可靠交付。
3. UDP是面向报文的，适合一次性传输少量数据的网络应用。
4. UDP无拥塞控制，适合很多实时应用。
5. UDP首部开销小，8B，TCP20B。
   

UDP用户数据报

伪首部只有在计算校验和的时候才出现，不向下发送，也不向上递交。
17：封装UDP报文的IP数据报首部协议字段是17.
UDP长度：UDP首部8B + 数据部分长度（不包括伪首部）。

UDP校验

左上角一横条是4个大B。
伪首部：
源IP地址4个字节，目的IP地址4个字节，全0占1个字节，i个字节的UDP协议字段，2个字节的UDP长度。
UDP的首部：
源端口号和目的端口号各占2个字节，UDP长度2个字节，16位YDP校验和2个字节。
数据部分：
4个字节的倍数，不够的用全0补齐。

在发送端：

1. 填上伪首部
2. 全0填充检验和字段
3. 全0填充数据部分（UDP数据报要看成许多4B的字串接起来）
4. 伪首部 + 首部 + 数据部分采用二进制反码求和
5. 把求和反码填入检验和字段
6. 去掉伪首部，发送

在接收端:

1. 填上伪首部
2. 伪首部 + 首部 + 数据部分采用二进制反码求和
3. 结果全为1则无差错，否则丢弃数据报/交给应用层附上差错警告

TCP协议

TCP协议特点

1. TCP是可靠的面向连接（虚连接）的传输层协议。
2. 每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的。
3. TCP提供可靠交付的服务，无差错、不丢失、不重复、按序到达。 可靠有序，不丢不重
4. TCP提供全双工通信。TCP两端都设置有发送缓存和接收缓存。发送缓存指准备发送的数据&已发送但尚未接到确认的数据。接收缓存指按序到达但尚未被接受应用程序读取的数据&不按序到达的数据。
5. TCP面向字节流。流：流入到进程或从进程流出的字节序列。TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流。
   

TCP报文段首部格式

TCP首部由固定首部+选项构成。
20B的固定首部，5行，每行4B。
最后一行的填充字段是为了保证是4字节的整数倍。

固定首部：
源端口和目的端口各占2个字节。
序号seq：在一个TCP连接中传送的字节流中的每一个字节都按顺序编号，序号字段表示本报文段所发送数据的第一个字节的序号。
确认号ack：期望收到对方下一个报文段的第一个数据字节的序号。若确认号为N，则证明到序号N-1为止的所有数据都已正确收到。
数据偏移（首部长度）：TCP报文段的数据起始处距离TCP报文段的起始处有多远，以4B为单位，即1个数值是4B。

紧急位URG：URG=1时，标明此报文段中有紧急数据，是高优先级的数据，应尽快送达，不用在缓存里排队，配合紧急指针字段使用。
确认位ACK：ACK=1时确认号有效，在连接建立后所有传送的报文段都必须把ACK置为1。
推送位PSH：PSH=1时，接收方尽快交付接收应用进程，不再等到缓存填满再向上交付。
复位RST：RST=1时，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立传输连接。
同步位SYN：SYN=1时，表明是一个连接请求/连接接受报文。
终止位FIN：FIN=1时，表明此报文段发送方数据已发完，要求释放连接。

窗口：指的是发送本报文段的一方的接收窗口（因为是全双工通信，所以两方都可以获得对方的接收窗口），即现在允许对方发送的数据量（可容纳的最大字节流）。
检验和：检验首部 + 数据，检验时要加上12B伪首部，第四个字段为6。
紧急指针：URG=1时才有意义，指出本报文段中紧急数据的字节数。

选项：最大报文段长度MSS、窗口扩大、时间戳、选择确认…

TCP连接管理

TCP连接传输三个阶段：

TCP连接的建立采用客户服务器方式，主动发起连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫服务器。

TCP的连接建立（三次握手）

先上一张图感受一下：

假设运行在一台主机（客户）上的一个进程想与另一台主机（服务器）上的一个进程建立一条连接，客户应用进程首先通知客户TCP，他想建立一个与服务器上某个进程之间的连接，客户中的TCP会用以下步骤与服务器中的TCP建立一条TCP连接：

ROUND 1：
客户端发送连接请求报文段，无应用层数据。
SYN=1，seq=x（随机） seq指序号

ROUND 2：
服务器端为该TCP连接分配缓存和变量，并向客户端返回确认报文段，允许连接，无应用层数据。
SYN=1, ACK=1, seq=y（随机），ack=x+1 ack指确认号字段

ROUND 3：
客户端为该TCP连接分配缓存和变量，并向服务器端返回确认的确认，可以携带数据。
SYN=0, ACK=1, seq=x+1，ack=y+1
只有请求和请求接受时SYN=1，所以SYN置为0，确认位ACK置1，期待y+1，序列号seq=x+1

SYN洪泛攻击

解决办法：设置SYN cookie

TCP的连接释放（四次握手）

参与一条TCP连接的两个进程中的任何一个都能终止该连接，连接结束后，主机中的“资源”*（缓存和变量）将被释放。

ROUND 1：
客户端发送连接释放报文段，停止发送数据，主动关闭TCP连接。
FIN=1, seq=u

ROUND 2：
服务器端回送一个确认报文段，客户到服务器这个方向的连接就释放了–半关闭状态。
ACK=1, seq=v, ack=u+1 半关闭之后ack不再增长，因为客户端不会再发送数据了

ROUND 3：
服务器端发完数据，就发出连接释放报文段，主动关闭TCP连接。
FIN=1, ACK=1, seq=w, ack=u+1

ROUND 4：
客户端回送一个确认报文段，再等到时间等待计时器设置的2MSL（最长报文段寿命）后，连接彻底关闭。

TCP可靠传输

网络层为了提供尽最大努力交付，是一种不可靠传输。在传输层可以使用TCP实现可靠传输。
可靠传输：保证接收方进程从缓存区读出的字节流与发送方发出的字节流时完全一样的。

TCP实现可靠传输的机制：

1. 校验：与UDP校验一样，增加伪首部，二进制反码计算求和。
2. 序号：一个字节占一个序号。序号字段指的是一个报文段第一个字节的序号。
3. 确认
4. 重传

停止等待协议

全双工通信的双方既是发送方，又是接收方。这里仅考虑A发送数据，B接收数据。因此A叫发送方，B叫接收方。
停止等待：每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

1. 无差错情况
   A发送分组M1，发送完就暂停发送，等待B的确认。B收到了M1就向A发送确认。A收到了对M1的确认后，就再发送下一个分组M2。同样，在收到了B对M2的确认后，再发送M3。
   

2. 出现差错
   如图，B在接收M1时检测出差错，丢弃M1，其它什么也不做（不通知A收到有差错的分组）；也可能是M1在传输过程中丢失了，B什么也不知道。这两种情况下，B都不会发送任何信息。
   可靠传输协议是这样设计的：A只要超过一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的数组。这叫做超时重传。要实现超时重传，就要在每发送完一个分组时设置一个超时定时器。如果在超时定时器到期之前收到了对方的确认，就撤销已设置的超时定时器。
   注意：
   a. A在发送完一个分组后，必须暂时保留已发送的分组的副本（发生超时重传时使用）。只有收到相应的确认后才能清楚暂时保留的分组副本。
   b. 分组和确认分组都必须进行编号。这样才能明确是哪一个发送出去的分组收到了确认，而哪一个分组没有收到确认。
   c. 超时定时器设置的重传时间RTTs（加权平均往返时间）应该比数据在分组传输的平均往返时间更长一些。

3. 确认丢失和确认迟到
   
   上图5-10（a）中，B所发送的对M1的确认丢失了。A在设定的超时重传时间内没有确认，并无法知道是自己发送的分组出错、丢失或者是B发送的确认丢失了。因此,A在超时定时器到期后就要重传M1。现在B又收到了重传的分组M1。这是应采取两个行动：
   a. 丢弃这个重复的分组M1，不向上层交付。
   b. 向A发送确认。不能因为发送过确认就不再发送。

5-10（b）中也是一种可能的情况。传输过程中没有出现差错，但B对分组M1的确认迟到了。A会收到重复的确认。对重复的确认的处理很简单；收下后就丢弃。B仍然会收到重复的M1，并且同样要丢弃重复的M1，并重传确认分组。

像上述的这种可靠传输协议常称为自动重传请求ARQ(Automatic Repeat reQuest)。意思是重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。

停止等待协议的优点是简单，但缺点是信道利用率太低，所以停等协议在TCP并不常用。

为了提高传输效率，发送方采用流水线传输。流水线传输就是发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据不间断地在传送。显然，这种传输方式可以获得很高的信道利用率。

当使用流水线传输时，就要使用下面介绍的连续ARQ协议和滑动窗口协议。

连续ARQ协议

这里先给出ARQ最基本的概念，不涉及细节。详细的滑动窗口协议在后面讨论。

上图表示发送方维持的发送窗口，它的意义是：位于发送窗口内的5个分组都可以连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。
图中有一个时间坐标，箭头指向时间增大的方向。分组发送是按照分组序号从小到大发送的。

连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。上图在收到1的确认后，窗口向右滑动一位，现在可以发送第6个分组了。

接收方一般都采用累计确认的方式。也就是说，接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示：到这个分组为止的所有分组都已经正确收到了。

累计确认的优点：容易实现，即使确认丢失也不必重传。
缺点：不能向发送方反映出接收方已经正确收到的所有分组信息。

例如，如果发送方发送了前5个分组，而中间的第3个分组丢失了。这时发送方只能对前两个分组发出确认。发送方无法知道后边三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N(回退N)，表示需要再退回来重传已发送过的N个分组。可见当通信线路质量不好时，连续ARQ协议会带来负面影响。

以字节为单位的滑动窗口

TCP的滑动窗口是以字节为单位的。为了便于说明滑动窗口的工作原理，图中字节编号取的都很小。
现在假定A收到了B发来的确认报文段，其中窗口是20字节，而确认号是31。根据这两个数据，A就构造出自己的发送窗口，如上图。
接收方会把自己的接收窗口数值放在窗口字段中发送给对方。因此，A的发送窗口一定不能超过B的接收窗口数值。
发送窗口的位置由窗口前沿和后沿的位置共同确定。
发送窗口后沿可能不动（没收到确认）或前移（收到确认）。
发送窗口前沿可能不动（收到确认，但对方通知的窗口缩小）或不断前移（没收到确认，对方通知的窗口大小不变）或向后收缩（对方通知的窗口缩小了，这样可能引发错误）。

如上图，假定A发送了序号为31~41的数据。这时，发送窗口的位置并未改变，但发送窗口内靠后面有11个字节（灰色小方框）表示已发送但未收到确认。而发送窗口内靠前面的9个字节（ 42 ~ 50 ）是允许发送但尚未发送的。
可以看出，要描述一个发送窗口的状态需要三个指针p1,p2,p3。指针都指向字节的序号。
指针的意义如下：
小于p1的是已发送并收到确认的部分，大于p3的是不允许发送的部分。
p3-p1是A的发送窗口
p2-p1是已发送但尚未收到确认的字节数
p3-p2是允许发送但当前尚未发送的字节数（又称为可用窗口或有效窗口）

再看一下B的接收窗口。B的接收窗口大小是20.在接收窗口外边，到30号位置的数据是已经发送过确认并交付主机了。因此B可以不再保留这些数据。接收窗口内的序号（ 31 ~ 50 ）是允许接收的。在上图中，B收到了序号32和33的数据，这些数据没有按序到达，因为序号为31的数据没有收到。注意：B只能对按序收到的数据中的最高序号给出确认，因此B发送的确认报文段中的确认号仍然是31。

现在假定B收到了序号为31的数据，并把序号为31~33的数据交付主机，然后B删除这些数据。接着把接收窗口向前移动3个序号，同时给A发送确认，其中窗口值仍为20，但确认号是34，如上图。同时B还收到了37，38和40，但这些数据没有按序到达，只能攒出在接收窗口中。A收到B的确认后，就可以把窗口向前滑动3个序号，但指针p2不动。可以看出，现在A的可用窗口增大了，可发送的序号是42 ~ 53。
A在发送完序号42 ~ 53的数据后，指针p2向前移动和p3重合。发送窗口内的序号都已用完，但还没有再收到确认。由于A的发送窗口已满，可用窗口减小到零，因此必须停止发送。
注意：存在这种可能，发送窗口内所有数据都已正确到达B,B也早已发出确认，但确认丢失。直到超时定时器触发确认重传A将窗口内数据全部重传，并重置超时定时器，直到收到B的确认为止。

窗口与缓存的关系

注意： 缓存空间和序号空间都是有限的，并且循环使用的。

超时重传时间的选择

重传时间的选择是TCP最复杂的问题之一。
TCP发送的报文段可能只经过一个高速率的局域网，也可能经过多个低速率网络，并且每个IP数据报所选择的路由还可能不同。如果把超时重传时间设置的太短，就会引起很多报文段的不必要的重传，使得网络负荷增大。但若把超时重传时间设置的过长，则又使得网络的空闲时间增大，降低了传输效率。

报文段往返时间RTT：对于一个报文段，收到确认的时间减去报文段发出的时间。
TCP保留RTT的加权平均往返时间RTTs（又称平滑往返时间，s指smoothed），每测量到一个RTT样本时，更新下面的公式：

$新的RTT_S=(1-\alpha)\times(旧的RTT_S)+\alpha\times(新的RTT样本)$
RFC 6298推荐 $\alpha=0.125$
显然，超时定时器设置的**超时重传时间RTO（Retransmission Time-Out）**应略大于RTTs。

选择确认SACK

若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那能否设法只传送缺少的数据而不重传已经正确到达接收方的数据。
TCP的接收方再接收对方发送过来的数据字节流的序号不连续，结果就形成了一些不连续的字节块。可以看出，序号1 ~ 1000收到了，但序号1001 ~ 1500没有收到。接下来的字节流又收到了，可是又缺少了3001 ~ 3500。再后面从序号4501起又没有收到。现在接收方要把这些接收到的信息准确的告诉发送方，使发送方不要再重复发送这些已收到的数据。
上图中有两个字节块，每个字节块都有左边界和右边界。因此再图中用四个指针标记这些边界。
L1=1501 R1=3001 L2=3501 R2=4501

TCP的首部没有哪个字段能够提供上述这些字节块的边界信息。 RFC 2018规定，如果要使用选择确认SACK，那么在建立TCP连接时，就要在TCP首部的选项中加上“允许SACK”的选项，而双方必须事先商定好。由于首部选项的长度最多有40个字节，指明一个边界需要用掉4字节（序号32位），所以最多能够指明4个字节块的边界信息。

冗余ACK（冗余确认）

每当比期望序号大的失序报文段到达时，发送一个冗余ACK，指明下一个期待字节的序号。
发送方已发送1，2，3，4，5报文段
接收方收到1，返回1的确认（确认号为2的第一个字节）
接收方收到3，仍返回1的确认（确认号为2的第一个字节）
接收方收到4，仍返回1的确认（确认号为2的第一个字节）
发送方收到3个对于报文段1的冗余ACK，他就会判定2报文段丢失，重传2号报文段。这种技术称为快速重传

TCP的流量控制

流量控制（flow control）：就是让发送方的发送速率不要太快，要让接收方来得及接收。
利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。如下图：

现在我们考虑一种情况，在上图中，B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwnd=400的报文段。然而这个报文段在传送过程中丢失了。A一直等待收到B发送发非零窗口的通知，而B也一直等待A发送的数据。如果没有其它措施，这种互相等待的死锁局面将一直延续下去。
为了解决这一问题，TCP为每一个连接设有一个持续定时器（persistence timer）。只要TCP连接的一方收到对方的零窗口通知，就启动持续定时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出现在的窗口值。如果窗口仍然是零，那么收到这个报文段的一方就重新设置持续计时器。如果窗口不是零，那么死锁的僵局就可以打破了。

TCP拥塞控制