计算机网络基础知识总结（五）运输层

服务器端使用的端口号
- 熟知端口号（well-known port number）：或系统端口号，数值为0～1023。IANA把这些端口号指派给了TCP/IP最重要的一些应用程序，让所有的用户都知道。
- 登记端口号：数值为1024～49151。这类端口号是为没有熟知端口号的应用程序使用的。使用这类端口号必须在IANA按照规定的手续登记，以防止重复。
客户端使用的端口号：数值为49152～65535。由于这类端口号仅在客户进程运行时才动态选择，因此又叫做短暂端口号。

5.2 用户数据报协议UDP

5.2.1 UDP的特点

1）UDP是无连接的。

2）UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表。

3）UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。

4）UDP没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。（适用于一些实时应用）

5）UDP支持一对一、一对多、多对一和多对多的交互通信。

6）UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短。

5.2.2 UDP的首部格式

Snipaste_2020-01-27_16-24-40

源端口：源端口号。在需要对方回信时选用。不需要时可用全0。
目的端口：目的端口号。这在终点交付报文时必须使用。
长度：UDP用户数据报的长度，其最小值是8（仅有首部）。
检验和：检测UDP用户数据报在传输中是否有错。有错就丢弃。（检验UDP用户数据报的首部和数据部分，计算方法和计算IP数据报首部检验和的方法相似。） 在计算检验和时，要在UDP用户数据报之前增加12个字节的伪首部。伪首部既不向下传送也不向上递交，而仅仅是为了计算检验和。

5.3 传输控制协议TCP

5.3.1 TCP的特点

1）TCP是面向连接的运输层协议。

2）每一条TCP连接只能有两个端点（endpoint），每一条TCP连接只能是点对点的（一对一）。

3）TCP提供可靠交付的服务。通过TCP连接传送的数据，无差错、不丢失、不重复，并且按序到达。

4）TCP提供全双工通信。

5）面向字节流。虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。

5.3.2 TCP报文段的格式

Snipaste_2020-01-27_16-34-26

源端口和目的端口：各占2个字节，分别写入源端口号和目的端口号。
序号：占4字节。序号范围是［0， $2^{32} –1$ ］，共 $2^{32}$ （即4 294 967 296）个序号。在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号。
确认号（ack）：占4字节，是期望收到对方下一个报文段的第一个数据字节的序号。
数据偏移：占4位，它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。这个字段实际上是指出TCP报文段的首部长度。（首部长度范围：20~60字节）
保留：占6位，保留为今后使用，但目前应置为0。
紧急URG（URGent）：当URG＝1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的数据），而不要按原来的排队顺序来传送。与首部中紧急指针（Urgent Pointer）字段配合使用。
确认ACK（ACKnowledgment）：仅当ACK＝1时确认号字段才有效。TCP规定，在连接建立后所有传送的报文段都必须把ACK置1。
推送PSH（PuSH）：当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应。在这种情况下，TCP就可以使用推送（push）操作。
复位RST（ReSeT）：当RST＝1时，表明TCP连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。
同步SYN（SYNchronization）：在连接建立时用来同步序号。当SYN＝1而ACK＝0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN＝1和ACK＝1。因此，SYN置为1就表示这是一个连接请求或连接接受报文。
终止FIN（FINis）：用来释放一个连接。当FIN＝1时，表明此报文段的发送方的数据已发送完毕，并要求释放运输连接。
窗口：占2字节。窗口值是［0， $2^{16} –1$ ］之间的整数。窗口指的是发送本报文段的一方的接收窗口（而不是自己的发送窗口）。窗口值作为接收方让发送方设置其发送窗口的依据。
检验和：占2字节。检验和字段检验的范围包括首部和数据这两部分。和UDP用户数据报一样，在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。
紧急指针：占2字节。紧急指针仅在URG＝1时才有意义，它指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据）。
选项：长度可变，最长可达40字节。当没有使用“选项”时，TCP的首部长度是20字节。
- TCP最初只规定了一种选项，最大报文段长度MSS（Maximum Segment Size），即每一个TCP报文段中的数据字段的最大长度。
- 窗口扩大选项是为了扩大窗口。
- 时间戳选项占10字节，其中最主要的字段是时间戳值字段（4字节）和时间戳回送回答字段（4字节）。一方面用来计算往返时间RTT，另一方面用于处理TCP序号超过 $2^{32}$ 的情况，这又称为防止序号绕回PAWS（Protect Against Wrapped Sequence numbers）。
- 选择确认选项。

5.3.3 TCP的连接

1）TCP连接的端点叫做套接字（socket）或插口。套接字 socket=（IP地址：端口号）。

2）每一条TCP连接唯一地被通信两端的两个端点（即两个套接字）所确定。

3）同一个IP地址可以有多个不同的TCP连接，而同一个端口号也可以出现在多个不同的TCP连接中。

5.4 可靠传输的工作原理

5.4.1 停止等待协议

1）停止等待协议是数据链路层协议，具有差错检测和流量控制功能。

2）“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

3）超时重传：发送方只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。

发送方在发送完一个分组后，必须暂时保留已发送的分组的副本（在发生超时重传时使用）。只有在收到相应的确认后才能清除暂时保留的分组副本。
分组和确认分组都必须进行编号。这样才能明确是哪一个发送出去的分组收到了确认，而哪一个分组还没有收到确认。
超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些。

4）接收方接收重复分组的处理

第一步，丢弃这个重复的分组，不向上层交付。
第二步，向发送方发送确认。不能认为已经发送过确认就不再发送，因为发送方之所以重传就表示发送方没有收到对该分组的确认。

5）停止等待协议的优点是简单，但缺点是信道利用率太低。

5.4.2 连续ARQ协议

Snipaste_2020-01-27_17-04-25
1）发送方：发送方维持的发送窗口，它的意义是：位于发送窗口内的5个分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。

2）接收方：一般都是采用累积确认的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认。
累积确认优点是容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方已经正确收到的所有分组的信息。

5.5 TCP可靠传输的实现

5.5.1 以字节为单位的滑动窗口

1）TCP的滑动窗口是以字节为单位的。

2）接收方只能对按序收到的数据中的最高序号给出确认。

3）发送方和接收方都维护有发送缓存、发送窗口和接收缓存和接收窗口。发送方的应用进程把字节流写入TCP的发送缓存，接收方的应用进程从TCP的接收缓存中读取字节流。
Snipaste_2020-01-27_17-16-10

发送缓存用来暂时存放：（1）发送应用程序传送给发送方TCP准备发送的数据；（2）TCP已发送出但尚未收到确认的数据。
接收缓存用来暂时存放：（1）按序到达的、但尚未被接收应用程序读取的数据；（2）未按序到达的数据。

5.5.2 超时重传时间的选择

1）一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返时间RTTs（这又称为平滑的往返时间）。每当第一次测量到RTT样本时，RTTs值就取为所测量到的RTT样本值。但以后每测量到一个新的RTT样本，就按下式重新计算一次RTTs：

新的RTTs = (1 - α) x (旧的RTTs) + α x (新的RTT样本)。 已成为建议标准的RFC 6298推荐的α值为1/8，即0.125。

2）超时计时器设置的超时重传时间RTO（RetransmissionTime-Out）应略大于上面得出的加权平均往返时间RTTs。RFC 6298建议使用下式计算RTO：

RTO = RTTs + 4 x $RTT_D$ 。 而 $RTT_D$ 是RTT的偏差的加权平均值，它与RTTs和新的RTT样本之差有关。

3）RFC6298建议这样计算 $RTT_D$ 。当第一次测量时， $RTT_D$ 值取为测量到的RTT样本值的一半。在以后的测量中，则使用下式计算加权平均的 $RTT_D$ ：

新的 $RTT_D$ = （1 - β) x (旧的 $RTT_D$ ) + β x |RTTs - 新的RTT样本|。 这里β是个小于1的系数，它的推荐值是1/4，即0.25。

5.5.3 选择确认SACK

若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么可以设法只传送缺少的数据而不重传已经正确到达接收方的数据。选择确认就是一种可行的处理方法。
Snipaste_2020-01-27_18-49-51
上面接收到的字节流序号不连续，接收的字节流左边界指出字节块的第一个字节的序号，但右边界减1才是字节块中的最后一个序号。

RFC2018规定，如果要使用选择确认SACK，那么在建立TCP连接时，就要在TCP首部的选项中加上“允许SACK”的选项，而双方必须都事先商定好。

由于首部选项的长度最多只有40字节，而指明一个边界就要用掉4字节（因为序号有32位，需要使用4个字节表示），因此在选项中最多只能指明4个字节块的边界信息。这是因为4个字节块共有8个边界，因而需要用32个字节来描述。另外还需要两个字节。一个字节用来指明是SACK选项，另一个字节是指明这个选项要占用多少字节。

然而，SACK文档并没有指明发送方应当怎样响应SACK。因此大多数的实现还是重传所有未被确认的数据块。

5.6 TCP的流量控制和拥塞控制

5.6.1 TCP的流量控制

1）流量控制（flow control）：就是让发送方的发送速率不要太快，要让接收方来得及接收。发送方根据接收方的接受能力（接收方窗口）来发送数据。即发送方的发送窗口不能超过接收方给出的接收窗口的数值

5.6.2 TCP的拥塞控制

1）拥塞控制：就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。

2）流量控制和拥塞控制的区别

某些拥塞控制算法是向发送端发送控制报文，并告诉发送端，网络已出现麻烦，必须放慢发送速率。
流量控制往往是指点对点通信量的控制，是个端到端的问题（接收端控制发送端）。流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

5.6.3 TCP的拥塞控制方法

1）拥塞窗口cwnd（congestion window）：发送方维持一个叫做拥塞窗口的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。

2）判断网络拥塞的依据就是出现了超时。

3）拥塞控制方法
Snipaste_2020-01-27_19-23-28

慢开始算法：初始化拥塞窗口cwnd为1个最大报文段SMSS，慢开始规定，在每收到一个对新的报文段的确认后，把拥塞窗口增加一个SMSS的数值。

使用慢开始算法后，每经过一个传输轮次（transmission round），拥塞窗口cwnd就加倍。一个传输轮次所经历的时间其实就是往返时间RTT。如图中的开始到点1。

为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量。慢开始门限ssthresh的用法如下：
当cwnd < ssthresh时，使用上述的慢开始算法。
当cwnd > ssthresh时，停止使用慢开始算法而改用拥塞避免算法。
当cwnd＝ssthresh时，既可使用慢开始算法，也可使用拥塞避免算法。
拥塞避免算法：拥塞避免算法的思路是让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1 ，而不是像慢开始阶段那样加倍增长。如图中的点1到点2。
当网络出现超时，发送方判断为网络拥塞，于是调整门限值ssthresh=当前拥塞窗口cwnd/2，同时设置拥塞窗口cwnd=1，然后开始执行慢开始算法及拥塞避免算法。如图中的点2到点4。
快重传算法：发送方只要一连收到3个重复确认，就知道接收方确实没有收到报文段，因而应当立即进行重传（即“快重传”），这样就不会出现网络超时，发送方也不就会误认为出现了网络拥塞。
快恢复算法：在完成快重传后，发送方调整门限值ssthresh＝cwnd/2，同时设置拥塞窗口cwnd＝ssthresh，并开始执行拥塞避免算法，如图中的点4之后。

4）发送方窗口的设置

发送方的窗口的上限值应当取为接收方窗口rwnd和拥塞窗口cwnd这两个变量中较小的一个，也就是说：发送方窗口的上限值 = Min[rwnd, cwnd]。

5）全局同步（global syncronization）：许多TCP连接在同一时间突然都进入到慢开始状态。全局同步使得全网的通信量突然下降了很多，而在网络恢复正常后，其通信量又突然增大很多。解决方法：随机早期检测RED（Random Early Detection）。

5.7 TCP的运输连接管理

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

TCP建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个TCP报文段。
Snipaste_2020-01-27_19-48-29
1）一开始，B的TCP服务器进程先创建传输控制块TCB ，准备接受客户进程的连接请求。然后服务器进程就处于LISTEN（收听）状态，等待客户的连接请求。

2）A的TCP客户进程也是首先创建传输控制模块TCB。然后，在打算建立TCP连接时，向B发出连接请求报文段，这时首部中的同步位SYN＝1，同时选择一个初始序号seq＝x。TCP规定，SYN报文段（即SYN＝1的报文段）不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN-SENT（同步已发送）状态。

3）B收到连接请求报文段后，如同意建立连接，则向A发送确认。在确认报文段中应把SYN位和ACK位都置1，确认号是ack＝x＋1，同时也为自己选择一个初始序号seq＝y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时TCP服务器进程进入SYN-RCVD（同步收到）状态。

4）TCP客户进程收到B的确认后，还要向B给出确认。确认报文段的ACK置1，确认号ack＝y＋1，而自己的序号seq＝x＋1。TCP的标准规定，ACK报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是seq＝x＋1。这时，TCP连接已经建立，A进入ESTABLISHED（已建立连接）状态。

5）当B收到A的确认后，也进入ESTABLISHED状态。

为什么有前两次握手建立了连接，还要第三次握手？

答：这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。

假设只用前两次握手建立TCP连接。A发出第一次连接请求，但是这个连接请求报文段在某些网络结点长时间滞留了（并没有丢失）。一段时间后，A因为超时未收到B的确认，于是发出第二次连接请求。第二次连接A收到了B的确认，建立了连接。数据传输完毕后，就释放了连接。

如果B紧接着收到了第一个失效的连接请求报文段，就误认为是A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。因为没有第三次握手，那么只要B发出确认，新的连接就建立了。

由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。

采用三报文握手的办法，可以防止上述现象的发生。例如在刚才的异常情况下，A不会向B的确认发出确认。B由于收不到确认，就知道A并没有要求建立连接。

5.7.2 TCP的连接释放

Snipaste_2020-01-27_20-05-35
1）A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。A把连接释放报文段首部的终止控制位FIN置1，其序号seq＝u，它等于前面已传送过的数据的最后一个字节的序号加1。这时A进入FIN-WAIT-1（终止等待1）状态，等待B的确认。请注意，TCP规定，FIN报文段即使不携带数据，它也消耗掉一个序号。

2）B收到连接释放报文段后即发出确认，确认号是ack＝u＋1，而这个报文段自己的序号是v，等于B前面已传送过的数据的最后一个字节的序号加1。然后B就进入CLOSE-WAIT（关闭等待）状态。

3）从A到B这个方向的连接就释放了，这时的TCP连接处于半关闭（half-close）状态，即A已经没有数据要发送了，但B若发送数据，A仍要接收。也就是说，从B到A这个方向的连接并未关闭，这个状态可能会持续一段时间。

4）A收到来自B的确认后，就进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。

5）若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使FIN＝1。现假定B的序号为w（在半关闭状态B可能又发送了一些数据）。B还必须重复上次已发送过的确认号ack＝u＋1。这时B就进入LAST-ACK（最后确认）状态，等待A的确认。

6）A在收到B的连接释放报文段后，必须对此发出确认。在确认报文段中把ACK置1，确认号ack＝w＋1，而自己的序号是seq＝u＋1（根据TCP标准，前面发送过的FIN报文段要消耗一个序号）。然后进入到TIME-WAIT（时间等待）状态。

7）请注意，现在A的TCP连接还没有释放掉。必须经过时间等待计时器（TIME-WAIT timer）设置的时间2MSL后，A才进入到CLOSED状态。时间MSL叫做最长报文段寿命（MaximumSegment Lifetime），RFC 793建议设为2分钟。但这完全是从工程上来考虑的，对于现在的网络，MSL＝2分钟可能太长了一些。因此TCP允许不同的实现可根据具体情况使用更小的MSL值。因此，从A进入到TIME-WAIT状态后，要经过4分钟才能进入到CLOSED状态，才能开始建立下一个新的连接。当A撤销相应的传输控制块TCB后，就结束了这次的TCP连接。

第一，为了保证A发送的最后一个ACK报文段能够到达B。
第二，防止上一节提到的“已失效的连接请求报文段”出现在本连接中。

8）B只要收到了A发出的确认，就进入CLOSED状态。同样，B在撤销相应的传输控制块TCB后，就结束了这次的TCP连接。我们注意到，B结束TCP连接的时间要比A早一些。

Samven_7

发布了108 篇原创文章 · 获赞 69 · 访问量 7万+

私信关注