计算机网络 之 运输层 考前复习详细总结
- 第五章 运输层
-
- 5.1 运输层概述
-
- 复用 和 分用
- 端口
- UDP和TCP的对比
- 5.2 用户数据报协议UDP
-
- UDP 的特点
- UDP首部
- 5.3 可靠传输的工作原理
-
- 停止等待协议
-
- 无差错情况
- 出现差错
- 确认丢失和确认迟到
- 信道利用率
- 连续ARQ协议 和 滑动窗口协议
- 5.4 传输控制协议TCP
-
- 概述
- TCP报文段的首部格式
- TCP可靠传输的实现
-
- 滑动窗口
- 超时重传时间的选择
- 5.6 TCP的流量控制
- 5.7 TCP的拥塞控制
-
- 慢开始 和 拥塞避免
- 快重传和快恢复
- 总体（重要的两个图）
- 5.8 TCP的运输连接管理
-
- 建立连接
- 释放连接
第五章 运输层
本章重点：
- 运输层为相互通信的应用进程提供逻辑通信
- 端口和套接字的意义
- 无连接的UPD的特点
- 面向连接的TCP的特点
- 在不可靠的网络上实现可靠传输的工作原理，停止等待协议和ARQ协议。
- TCP的滑动窗口、流量控制、拥塞控制和连接管理。
5.1 运输层概述
-
计算机网络体系结构中的物理层、数据链路层以及网络层 共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信。
-
实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程。
如何为运行在不同主机 上的应用进程提供直接的通信服务是运输层的任务，运输层协议又称为端到端协议。 -
运输层向高层用户屏蔽了下面网络核心的细节(如网络拓扑、所采用的路由选择协议等)，它使应用进程看见的就好像是在两个运输层实体之间有一条端到端的逻辑通信信道。
根据应用需求的不同， 因特网的运输层为应用层提供了两种不同的运输协议，即 面向连接的TCP 和 无连接的UDP，这两种协议是重点。
复用 和 分用
复用：
- 发送方 不同的应用进程 都可以使用 同一个运输层协议 传送数据。
- 应用层的应用进程都可以通过运输层再传送到IP层（网络层）
分用：
- 接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。
- 运输层从IP层收到发送给各应用进程的数据后，必须分别交付指明的各应用进程。
端口
■ 运行在计算机上的进程使用进程标识符PID来标志。
■ 因特网上的计算机并不是使用统一的操作系统，不同的操作系统(windows, Linux, Mac OS)又使用不同格式的进程标识符。为了使运行不同操作系统的计算机的应用进程之间能够进行网络通信，就必须使用统一的方法对TCP/IP体系的应用进程进行标识。
■ TCP/IP体系的运输层使用端口号来区分应用层的不同应用进程。
- 端口号使用16比特表示，取值范围0~65535；
- 端口号分两类：服务器端使用的端口号、客户端使用的端口号
服务器端使用的端口号：熟知端口号（全球通用端口号）、登记端口号
客户端使用的端口号：短暂端口号
- 熟知端口号: 0~1023，IANA把这些端口号指派给了TCP/IP体系中最重要的一 些应用协议,例如: FTP 使用21/20，HTTP使用80，DNS使用53。
- 登记端口号: 1024~49151, 为没有熟知端口号的应用程序使用。 使用这类端口号必须在IANA按照规定的手续登记，以防止重复。例如: Microsoft RDP微软远程桌面使用的端口是3389。
- 短暂端口号: 49152~65535, 留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用。
- 端口号只具有本地意义，即端口号只是为了标识本计算机应用层中的各进程，在因特网中，不同计算机中的相同端口号是没有联系的。
| 应用程序 | FTP | TELNET | SMTP | DNS | TFTP | HTTP | SNMP | SNMP（trap） | HTTPS |
|---|---|---|---|---|---|---|---|---|---|
| 熟知端口号 | 21 | 23 | 25 | 53 | 69 | 80 | 161 | 162 | 443 |
UDP和TCP的对比
用户数据报协议UDP:
(User Datagram Protocol)
- 无连接
- 支持一对一，一对多，多对一和多对多交互通信。
- 对应用层交付的报文直接打包，面向报文
- 尽最大努力交付，也就是不可靠;
- 不使用流量控制和拥塞控制。
- 首部开销小，仅8字节
传输控制协议TCP：
(Transmission Control Protocol)
- 面向连接
- 每一条TCP连接只能有两个端点EP， 只能是一对一通信。
- 面向字节流
- 可靠传输，使用流量控制和拥塞控制。
- 首部最小20字节，最大60字节
5.2 用户数据报协议UDP
UDP 的特点
同 UDP和TCP的对比
UDP首部
用户数据报有两个字段：数据字段和首部字段。首部字段只有 8 个字节，并由 4 个字段组成，每个字段的长度都是 2 个字节。
- 源端口：源端口号，在对方回应时使用，不需要时可用 0 表示。
- 目的端口：目的端口号，在终点交付报文时使用。
- 长度：UDP 数据报的长度，最小值为 8 （只有首部）。
- 检验和：检测 UDP 用户数据报在传输过程中是否有错。有错就丢弃。
5.3 可靠传输的工作原理
理想的传输条件：
- 传输信道不产生差错
- 不管发送方以多快的速度发送数据，接收方总是来得及处理接收到的数据。
停止等待协议
“ 停止等待 ”：每发送完一个分组就停止发送，等待对方确认。确认收到后再发送下一个分组。
无差错情况
出现差错
出现差错，B没有给A反馈，所以需要A设置一个超时重传计时器，进行超时重传。
三点注意：
1.A必须暂时保留已发送分组的副本
2.分组和确认分组都必须进行编号
3.超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些。
确认丢失和确认迟到
使用上述的确认和重传机制，可以在不可靠的传输网络上实现可靠的通信。
这种可靠传输协议称为自动重传请求ARQ。
信道利用率
ARQ的优点是简单，但信道利用率太低。
信道利用率U = TD / （TD + RTT + TA）
TD ： A发送分组的时间
TA： B发送确认分组需要的时间
连续ARQ协议 和 滑动窗口协议
连续ARQ协议：发送方每收到一个确认，就把发送窗口向前滑动一个分组。
接收方采用累积确认的方式，对按序到达的最后一个分组发送确认。
优点：容易实现，即使确认丢失也不必重传
缺点：不能向发送方及时反应接收方已经正确收到所有分组的信息。
所以当通信线路质量不好时，连续ARQ协议会带来负面的影响。
滑动窗口协议是TCP的精髓，当然是放到TCP的可靠传输那里啦。
5.4 传输控制协议TCP
概述
同 UDP和TCP的对比
TCP报文段的首部格式
为了实现可靠传输，TCP采用了面向字节流的方式。
但TCP在发送数据时，是从发送缓存取出一部分或全部字节并给其添加一个首部使之成为TCP报文段后进行发送。
-
一个TCP报文段由首部和数据载荷两部分构成;
-
TCP的全部功能都体现在它首部中各字段的作用。
-
源端口：占16比特，写入源端口号，用来标识发送该TCP报文段的应用进程。
-
目的端口：占16比特,写入目的端口号，用来标识接收该TCP报文段的应用进程。
-
序号：占32比特，取值范围[0, 232 -1]，序号增加到最后一个后，下一个序号就又回到0。
指本TCP报文段数据载荷的第一个字节的序号。 -
确认号：占32比特,取值范围[0, 232 -1]，确认号增加到最后一个后，下一个确认号就又回到0。
指期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号， 同时也是对之前收到的所有数据的确认。
若确认号=n，则表明到序号n-1为止的所有数据都已正确接收，期望接收序号为n的数据。 -
数据偏移：占4比特，并以4字节为单位。
指TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远。
这个字段实际上是指出了TCP报文段的首部长度。
首部固定长度为20字节，因此数据偏移字段的最小值为(0101)2
首部最大长度为60字节，因此数据偏移字段的最大值为(1111)2 -
保留：占6比特，保留为今后使用，但目前应置为0。
-
确认标志位ACK：取值为1时确认号字段才有效；取值为0时确认号字段无效。
TCP规定，在连接建立后所有传送的TCP报文段都必须把ACK置1。 -
同步标志位SYN：在TCP连接建立时用来同步序号。
SYN = 1 且 ACK = 0：连接请求报文段
SYN = 1 且 ACK = 1：同意建立连接，响应报文段
-
终止标志位FIN：用来释放TCP连接。
-
复位标志位RST：用来复位TCP连接。
当RST=1时，表明TCP连接出现了异常，必须释放连接，然后再重新建立连接。
RST置1还用来拒绝一个非法的报文段或拒绝打开一个TCP连接。 -
复位标志位RST：用来复位TCP连接。
当RST=1时，表明TCP连接出现了异常，必须释放连接，然后再重新建立连接。
RST置1还用来拒绝一个非法的报文段或拒绝打开-一个TCP连接。 -
紧急标志位URG：取值为1时紧急指针字段有效;取值为0时紧急指针字段无效。
-
紧急指针：占16比特,以字节为单位，用来指明紧急数据的长度。
当发送方有紧急数据时，可将紧急数据插队到发送缓存的最前面，并立刻封装到一个TCP报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据，紧急数据之后是普通数据。 -
窗口：占16比特，以字节为单位。指出发送本报文段的一方的接收窗口。
窗口值作为接收方让发送方设置其发送窗口的依据。
窗口字段明确指出了现在允许对方发送的数据量，窗口值经常在动态的变化着
这是以接收方的接收能力来控制发送方的发送能力，称为流量控制。 -
校验和：占16比特，检查范围包括TCP报文段的首部和数据载荷两部分。
在计算校验和时，要在TCP报文段的前面加上12字节的伪首部。 -
选项：
- 最大报文段长度MSS选项: TCP报文段数据载荷部分的最大长度。
- 窗口扩大选项: 为了扩大窗口(提高吞吐率) 。
- 时间戳选项:
1)用来计算往返时间RTT
2)用于处理序号超范围的情况，又称为防止序号绕回PAWS. - 选择确认选项
TCP可靠传输的实现
滑动窗口
■ TCP基于以字节为单位的滑动窗口来实现可靠传输。
- 发送方在未收到接收方的确认时，可将发送窗口内还未发送的数据全部发送出去;
- 接收方只接收序号落入发送窗口内的数据
■ 虽然发送方的发送窗口是根据接收方的接收窗口设置的，但在同一时刻，发送方的发送窗口并不总是和接收方的接收窗口一样大。
- 网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的。
- 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。
■ 对于不按序到达的数据应如何处理，TCP并无明确规定。
- 如果接收方把不按序到达的数据一律丢弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利，因为发送方会重复传送较多的数据。
- TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后再按序交付上层的应用进程。
■ TCP要求接收方必须有累积确认和捎带确认机制，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。
- 接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传，这反而浪费了网络的资源。
TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认[RFC 1122]. - 捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。
■ TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，一定要弄清楚是哪一方的窗口。
超时重传时间的选择
TCP 使用超时重传来实现可靠传输：如果一个已经发送的报文段在超时时间内没有收到确认，那么就重传这个报文段。
一个报文段从发送再到接收到确认所经过的时间称为往返时间 RTT，加权平均往返时间 RTTs 计算如下：
其中，0 ≤ a ＜ 1，RTTs 随着 a 的增加更容易受到 RTT 的影响。
超时时间 RTO 应该略大于 RTTs，TCP 使用的超时时间计算如下：
其中 RTTd 为偏差的加权平均值。
5.6 TCP的流量控制
一般来说， 我们总是希望数据传输得更快一些。
但如果发送方把数据发送得过快，接收方就可能来不及接收,这就会造成数据的丢失。
流量控制(flow control)：让发送方的发送速率不要太快，要让接收方来得及接收。
利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
- TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小。
- TCP发送方收到接收方的零窗口通知后， 应启动持续计时器。持续计时器超时后，向接收方发送零窗口探测报文。
5.7 TCP的拥塞控制
做拥塞(congestion)：对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏。
在计算机网络中的链路容量（即带宽)、交换结点中的缓存和处理机等，都是网络的资源。
若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。
假定如下条件:
- 数据是单方向传送， 而另- 一个方向只传送确认。
- 接收方总是有足够大的缓存空间，因而发送方发送窗口的大小由网络的拥塞程度来决定。
- 以最大报文段MSS的个数为讨论问题的单位， 而不是以字节为单位。
TCP 主要通过四个算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。
■ 发送方维护一个叫做拥塞窗口cwnd的状态变量,其值取决于网络的拥塞程度，并且动态变化。
- 拥塞窗口cwnd的维护原则：只要网络没有出现拥塞，拥塞窗口就再增大一些；但只要网络出现拥塞， 拥塞窗口就减少一些。
- 判断出现网络拥塞的依据：没有按时收到应当到达的确认报文(即发生超时重传)。
■ 发送方将拥塞窗口作为发送窗口swnd，即swnd = cwnd。
■ 维护一个慢开始门限ssthresh状态变量:
- 当cwnd < ssthresh时，使用慢开始算法;
- 当cwnd > ssthresh时， 停止使用慢开始算法而改用拥塞避免算法;
- 当cwnd = ssthresh时，既可使用慢开始算法,也可使用拥塞避免算法。
慢开始 和 拥塞避免
慢开始：是指一开始向网络注入的报文段少,并不是指拥塞窗口cwnd增长速度慢;
拥塞避免：并非指完全能够避免拥塞，而是指在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞;
快重传和快恢复
下图是快重传
快重传：使发送方尽快进行重传，而不是等超时重传计时器超时再重传。
- 要求接收方不要等待自己发送数据时才进行捎带确认,而是要立即发送确认;
- 即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
- 发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。
- 对于个别丢失的报文段，发送方不会出现超时重传，也就不会误认为出现了拥塞(进而降低拥塞窗口cwnd为1)。使用快重传可以使整个网络的吞吐量提高约20%。
快恢复：发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段。于是不启动慢开始算法，而执行快恢复算法。 - 发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半;开始执行拥塞避免算法。
- 也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些，即等于新的ssthresh + 3。
1> 既然发送方收到3个重复的确认，就表明有3个数据报文段已经离开了网络;
2> 这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中;
3> 可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口扩大些。
总体（重要的两个图）
5.8 TCP的运输连接管理
TCP的运输连接管理就是使运输连接的建立和释放都能正常地进行。
建立连接
释放连接
建议再做下计网第五章作业最后一题