计算机网络微课堂——第五章—运输层

第五章 运输层

1、概述

2、运输层端口号、复用与分用的概念

• 2.1 端口号

• 2.2 发送方的复用和接收方的分用

复用：从上往下封装

分用：从下往上交付

• 2.3 TCP/IP体系的应用层常用协议所使用的运输层数值==熟知端口号

运输层的端口号区分 应用层 具体是哪个应用程序。
网络层的协议字段区分 运输层具体是哪个协议。

• 2.4 通过实例更清晰的理解运输层端口号的作用

这个太麻烦了，不好叙述，你自己脑海里想一遍过程，忘记了就去看这个视频，从6分钟开始。

3、UDP和TCP的对比

• 3.1 通信方式

• 3.2 对应用报文的处理不同

上图中UDP和TCP各只画了一个传输方向，实际上他们是全双工的。

UDP：

• 给应用程序发下来的报文加上首部就可以直接发送，既不合并也不拆分，完全保留报文的边界

• 不使用流量控制和拥塞控制，尽最大努力转发

TCP：

• 使用流量控制

• 发送时：

• 应用进程发下来的数据仅看成字节流

• 然后给字节流编号，并存入发送缓存 等待转发

• 根据一定策略提取字节构成TCP报文段发送

• 接收时：

• 从报文段取出数据载荷部分存入接收缓存中

• 按照策略提取部分字节向上交付

• 不保证发送和接收方的数据块相同，只保证总量一样，也就是说会自行拆分或合并

• 3.3 TCP向上层提供可靠的服务

• 3.4 数据报 和 报文段 的首部

简要总结：

4、TCP的流量控制

一句话概括：接收方根据自己的缓存大小，告诉发送方自己接收窗口的大小，从而限制发送流量。
过程太长，不好描述，直接看视频。视频里还讲了TCP报文段的传输过程。

不过可以给几个关键词：

rwnd字段，持续计时器，零窗口探测报文

5、TCP的拥塞控制

• 5.1 引入

什么是拥塞？

四种拥塞控制算法：

学习拥塞控制算法的基础知识：

注意：拥塞窗口=发送窗口，拥塞窗口多大，每次就能发多少报文段。

所谓拥塞控制算法，就是要围绕拥塞窗口展开，是一个维护拥塞窗口大小的过程。什么情况下，拥塞窗口该怎么改变。

绘制下图所示图像，更直观反应在饮食控制算法下，拥塞窗口的变化：

对于横坐标，发送方发一个报文段 and 接收方发一个确认 算一个传输轮次。

• 5.2 慢开始（slow-start）

慢开始，顾名思义，开始发送的报文段很少，拥塞窗口从1开始，每收到一个确认就+1。（相当于y=2^x）
所以，随着报文段成功发送，拥塞窗口增长是很快的。（拥塞程度也在增加）如下图所示：

指数增长，非常快，不过很正常，既然还有资源就要充分利用。
但是，当 拥塞窗口的值=快开始门限时，就切换拥塞避免算法。
慢开始门限：顾名思义，慢开始算法到了阈值了，该换算法了。
不过，慢开始门限是我们人为规定的。本例中就是16。

• 5.3 拥塞避免（congestion avoidance）

哪里能一直快速增长？该收敛点了。这下，每过一个轮次 拥塞窗口 才能+1。（相当于y=x函数）
但终归还是增长，只是增长变慢了。拥塞程度还在增加。
直到实际发生了拥塞，接收方收不到你的报文段了。发送方发生超时重传。这该怎么办？
如下图红色部分处理：

重新进行慢开始算法，如下图所示：

• 5.4 快重传（fast restransmit）

• 引入：
• 万一报文段不是因为拥塞丢失的呢？
  
  上述情景发生就得不偿失了，所以引入了快重传算法：
  
  引用实例，如下图所示：
  
  使用了快重传算法：
  

你有没有发现，快重传貌似根本和 拥塞窗口 这个本节的关键字段没有关系？
是的，确实没关系，因为他要和下面的 快恢复 算法配合才能发挥作用。

而且，快重传：顾名思义，只是加快重传罢了。

你有没有想过，快重传之后要该怎么做？
没错，就是执行快恢复算法，这是引入快恢复算法的第二个理由。

• 5.5 快恢复（fast recovery）

实际例子如下图：（这里面包含了本节所有4种算法，快重传+快恢复 在最后的部分，也就是传输轮次21往后）

6、TCP超时重传时间的选择

超时重传时间RTO应略大于往返时间RTT。
RTO的选取原则很简单，困难的是怎么求出这个时间，这就是本节所要解决的问题。
从上图不难看出，不能直接用某次测量得到的RTT计算RTO，因为网络状况时刻在改变，所以我们采用加权的策略。
如下图所示：
使用上述的公式，就可以很简单的计算出RTO了。
但是，RTT_S和RTT_D都是基于最新一次测得得RTT样本计算，但RTT的测量也会出现很多问题，如下图所示：
所以要想办法解决超时重传对RTT测量产生的影响，如下图所示：
综上所述，得到了最终RTO的测量原则：
每次都要计算出三个值，其中两个只需要用于下一次RTO的计算。

7、TCP可靠传输的实现

• 7.1 实现的关键

实现可靠传输的关键是，重传计时器 和 按序确认：

• 按序确认：只对按序收到的最大数据序号发送确认。
• 重传即使：超过倒计时就重传未收到的数据。
       若收到多次（应该是3次）同一确认报文段，则立即重传该序号的数据。

可靠传输的详细过程不好叙述，你直接去看视频。

下面介绍一下几个细节。

• 7.2 发送窗口 和 接收窗口的移动情况

对于发送窗口：

说明：

• 发送窗口变化说明：先前移，再根据rwnd改变大小
• 前沿后缩：可能里面有部分数据已经发送出去了，你缩完了，他们到了发送窗口外面，就乱套了

对于接收窗口：
从第一个起的连续数据都交付给了上层应用，就能前移了，否则不动，如下图所示：

• 7.3 如何编程 维护 和 标记 发送窗口的状态？

三指针，如下图所示：

• 7.4 补充说明

8、TCP的运输连接管理

• 8.1 引入

前面的小节提到过，TCP相比于UDP的一个特点就是，TCP是面向连接的，提供可靠服务，其代价就是每次传输时必须建立连接，然后通信双方之间就仿佛有一条传输链路一样，可以准确地收发数据。

• 8.2 TCP连接建立要解决的问题

• 8.3 三报文握手——建立连接

下面，把请求TCP连接的应用进程称为“客户”，被动等待TCP连接建立的应用进程称为“服务器”。
注意：这里要区分一下 应用进程 和 TCP进程，应用进程 通过TCP进程 来实现数据传输。
所以连接建立实际上和应用进程没有太大关系，是由TCP进程来完成的。

下面正式开始讲解，TCP进程如何建立连接。
（为使叙述简介，下面的：客户=客户TCP进程；服务器=服务器TCP进程）
最初 两端的TCP进程都 处于关闭状态，如下图所示：

然后，TCP服务器进程首先创建传输控制快，如下图所示：

之后，服务器就准备接收TCP客户进程的连接请求。
也就是 服务器 进入监听状态，等待TCP客户进程的连接请求，如下图所示：

好的，服务器这边的准备工作都做好了。我们来看客户这边。
客户TCP进程也要 先创建传输模块，如图所示：

然后，就可以向服务器发送连接请求了。
客户进程向服务器发送 TCP连接请求报文段，并进入同步已发送状态。如下图所示：

• SYN 是一个单词，意为：同步。
• SYN=1，表明这是一个TCP连接请求报文段
• seq是序号字段，表示报文的序号，初值可任意选取，他作为客户TCP进程选择的初始数据序号
• TCP协议规定：SYN=1的报文段不能携带数据，但必须消耗掉一个序号，也就是 x

服务器收到客户的TCP连接请求报文段后，若同意建立连接，就向客户TCP进程发送TCP连接请求确认报文段。
同时服务器TCP进程进入 同步已接收状态，如下图所示：

• RCVD 是单词‘received’的缩写
• SYN 与 ACK 都=1，表明这是TCP连接请求确认报文段
• seq初值任意，这里=y，是服务器TCP进程选择的初始序号
• ack是确认号字段，ack=x+1，是对客户TCP进程选择的 初始序号的确认
• 这个报文段也不能携带数据，应为SYN=1，他也必须消耗掉一个序号，也就是 y

客户收到TCP连接请求确认报文段后，还要向服务器发送一个普通的TCP确认报文段，并进入连接已建立状态。
如下图所示：

• ACK=1，表示这是一个普通TCP确认报文段
• TCP协议规定，普通的TCP确认报文段可以携带数据，但如果不携带数据则不消耗序号，也就是说客户发送的下一个TCP报文段序号还是 x+1
• ack=y+1，是对服务器TCP进程所选择的 初始序号的确认

服务器收到该确认报文段后，也进入连接已建立状态。此时，双方就可以进行通信了，如下图所示：

那…你有没有想过最后客户发送的普通TCP确认报文段是否多余？
当然不多余，看下面的例子：

上图中的红线为最开始客户发出的TCP连接请求报文段，由于部分原因在网络中滞留了很长时间，于是引发客户的超时重传，这次客户 和服务器顺利建立连接完成了通信，并释放连接。刚好，之前在网络中滞留的TCP连接请求到达了服务器，由于没有第三次 “ 握手 ”，所以服务器直接进入了连接状态，但客户并没有发送连接请求，不理会服务器的连接请求确认，服务器一直等待客户给他发送报文段，白白浪费了资源。

综上所述，第三次 “ 握手 ”（客户发送普通确认报文段）是必须的，它能防止已失效的连接请求报文段突然又传到服务器而造成的资源浪费。

• 8.4 四报文挥手——连接释放

最初客户与服务器处于连接状态，如下图所示：

突然，客户TCP进程要主动释放连接，则客户发送TCP连接释放报文段，并进入终止等待1状态，如下图所示：

• FIN=1，表示这是TCP连接释放报文段
• TCP规定，FIN=1的报文段即使不携带数据，也必须要消耗一个序号

服务器收到TCP释放报文段后，发送一个普通的TCP确认报文段，并进入关闭等待状态，如下图所示：

然后服务器TCP进程会通知上层的应用程序，客户要断开TCP连接，此时，客户到服务器方向的连接就释放了。
此时的TCP连接属于半关闭状态，服务器到客户方向的连接并未释放，服务器还是能给客户发送报文段的。

客户收到服务器的普通确认报文段后，进入终止等待2状态，等待服务器发送TCP连接释放报文段。
若服务器此时已无数据发送，则上层应用进程通知TCP进程释放连接。
服务器发送TCP连接释放报文段，并进入最后确认状态，如下图所示：

• 因为TCP连接释放是客户发起的，所以服务器是被动关闭。
• seq从v变成了w是因为中间，服务器可能还向客户发送了报文段

客户收到服务器的TCP确认报文段后，必须向服务器发送TCP普通确认报文段，之后进入时间等待状态。
服务器收到该TCP普通报文段后直接进入关闭状态，而刚刚进入时间等待状态的客户还需要等待两倍MSL时间后才能关闭。如下图所示：
客户为什么要进入时间等待状态等2×MSL才关闭呢？直接关闭不好吗？
必不好，如下图所示：

假设不等待2×MSL：
客户收到TCP连接释放报文段，给服务器发送完普通确认后直接关闭。
此时，若该确认报文段丢失，服务器就收不到最后确认，他的超时计时器反复触发，服务器反复发送连接释放报文段，但客户已经关闭，无法做出回应，这样浪费了大量资源，而且服务器还一直无法关闭。

如果有2×MSL：
即使客户的普通确认报文段丢失了，服务器也会超时重传TCP连接释放报文段，客户接收到后，可以再发一个普通确认报文段。

综上所述：时间等待状态可以确保服务器能收到最后一个TCP确认报文段而进入关闭状态。

• 8.5 保活计时器

TCP双方建立连接后，突然客户出了故障，显然客户收不到服务器的任何信息了，所以应该有措施避免服务器白白等下去。
使用保活计时器就能让服务器发现客户发生了故障。如下图所示：

• 8.6 总结TCP建立连接和释放

三握手：

• 一请求，两确认
• 确认两方一人一次，发起方是普通确认，监听方式连接请求确认
• 发起方要发送两次报文段

四挥手：

• 两释放，两确认
• 主动关闭方被动关闭方，各一 释放和确认
• 先释放者 后确认

• 特殊报文段都有特殊字段（SYN，FIN等）

9、TCP报文段首部格式

下面正式介绍TCP首部格式：

• 既然以4字节为单位，那整个首部的长度必需是4的整数倍

窗口就是接收窗口。