计网_课堂与复习笔记：第五章传输层

第五章 运输层

我们一直没有强调数据的可靠性，只是在链路层的CRC和网络层的数据报首部的校验和两处体现了一点点。通信中，不能指望数据传输的永远准确。严格地说，两台主机进行通信就是两台主机中的应用进程之间进行通信。经常是一台主机多个进程同时分别与另一主机的多个进程间互相通信，这就涉及到了复用和分用的问题。

5.1 运输层的协议概述

运输层向高层屏蔽了下面的细节，用户只能看到一条端到端的逻辑信道。从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。

• 当运输层采用面向连接的TCP协议—>可靠通信
• 。。。采用面向无连接的UDP协议—>不可靠通信

运输层协议和网络层协议的主要区别

• 网络层：IP 协议的作用范围（提供主机之间的逻辑通信）
• 运输层：TCP 和 UDP 协议的作用范围（提供进程之间的逻辑通信）

运输层的 UDP 用户数据报与网际层的IP数据报有很大区别。

• IP 数据报要经过互连网中许多路由器的存储转发。
• UDP 用户数据报是在运输层的端到端抽象的逻辑信道中传送的。
• TCP 报文段是在运输层抽象的端到端逻辑信道中传送，这种信道是可靠的全双工信道。但这样的信道却不知道究竟经过了哪些路由器，而这些路由器也根本不知道上面的运输层是否建立了TCP连接。

TCP 与 UDP

• UDP 不管主机、不管中间、就是发。在传送之前不需要建立连接，收到UDP也不会有所谓的【“我收到了”回执】
• TCP 不提供广播和多播，必须建立可靠连接

这个主机到那个主机称为点到点，这个进程到那个进程称为端到端（端口到端口）。

端口号（16位）–> 只具有本地意义 –> 为标志计算机应用层中各进程 –> 在互联网中，不同计算机的相同端口号是没有联系的。
–> 由此可见，两个计算机中的进程要互相通信，不仅必须知道对方的 IP 地址（为了找到对方的计算机），而且还要知道对方的端口号（为了找到对方计算机中的应用进程）。

两大类端口

• 服务器端使用的端口号

  • 公认（熟知）端口，数值一般为 0~1023。
  • 注册（登记）端口号，数值为 1024~49151，为没有熟知端口号的应用程序使用的。使用这个范围的端口号必须在 IANA 登记，以防止重复。

• 客户端使用的端口号

  • 短暂端口号，数值为 49152~65535，留给客户进程选择暂时使用。

service using UDP

• DNS: 53
• TFTP: 69
• RPC: 111

service using TCP

• FTP: 21(for control) 20
• SSH: 22
• Telnet: 23
• SMTP: 25
• HTTP: 80
• HTTPS: 443

5.2 UDP

(Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)

5.3 TCP

• TCP 是面向连接的运输层协议。
• 每一条 TCP 连接只能有两个端点 (endpoint)，每一条 TCP 连接只能是点对点的（一对一）。
• TCP 提供可靠交付的服务。
• TCP 提供全双工通信。
• 面向字节流
  
  • TCP 中的“流”(stream)指的是流入或流出进程的字节序列。
  • “面向字节流”的含义是：虽然应用程序和 TCP 的交互是一次一个数据块，但 TCP 把应用程序交下来的数据看成仅仅是一连串无结构的字节流。
  • TCP 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系。
  • 但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。
• TCP 对连续的字节流进行分段，形成 TCP 报文段。
• TCP 连接是一条虚连接而不是一条真正的物理连接。
• TCP 对应用进程一次把多长的报文发送到TCP 的缓存中是不关心的。
• TCP 根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP 发送的报文长度是应用进程给出的）。
• TCP 可把太长的数据块划分短一些再传送。
• TCP 也可等待积累有足够多的字节后再构成报文段发送出去。

TCP 的连接

TCP 连接的端点不是主机，不是主机的IP 地址，不是应用进程，也不是运输层的协议端口。TCP 连接的端点叫做套接字 (socket) 或插口。
端口号拼接到 (contatenated with) IP 地址即构成了套接字。

套接字 socket = (IP地址 : 端口号)

每一条 TCP 连接唯一地被通信两端的两个端点（即两个套接字）所确定。即：
TCP 连接 ::= {socket1, socket2} = {(IP1: port1)，(IP2: port2)}

5.4 可靠传输的工作原理

回到可靠传输的问题，什么情况下不需要采取任何措施就能够实现可靠传输：

• (1) 传输信道不产生差错。
• (2) 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。

但是，现实情况下不会出现这种理想的传输条件，所以，我们需要使用一些可靠传输协议，在不可靠的传输信道实现可靠传输。

介绍两种：

1. 停止等待协议

“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。由于全双工通信的双方既是发送方也
是接收方。为了讨论问题的方便，我们仅考虑 A 发送数据而 B 接收数据并发送确认。因此 A 叫做发送方，而 B 叫做接收方。

• 无差错情况
  
  • A 发送分组 M1，发完就暂停发送，等待 B 的确认 (ACK)。B 收到了 M1 向 A 发送 ACK 。A 在收到了对 M1 的确认后，就再发送下一个分组 M2。
• 有差错情况
  
  • 对于差错的解决办法就是设置超时计时器，在 A 发送一个分组后，只要在发送方 A 的超时计时器未超时前 A 收到了 B 的确认回执，那就重置计时器继续发送下一个分组，否则 A 就重新发送分组
• 确认回执丢失或迟到情况
  
  • 确认丢失——B 确实收到了 A 的分组，但 B 发送的给 A 的确认回执丢失了。这种情况下，A 本身在计时器超时后就会重发分组，而接收方 B 则应在收到 A 分组后删除掉这个重复的分组（不向上层交付），并向 A 发送确认回执。
  • 确认迟到——B 确实收到了 A 的分组，但 B 发送的给 A 的确认回执迟到了。这种情况下 A 本身在计时器超时后就会重发分组，并会接收到 B 的确认回执。但之后 A 会收到重复的确认回执。A 对重复的确认的处理很简单：收下后就丢弃。至于 B, 在收到 A 计时器超时后重发的分组后，需要丢弃重复的分组，并重传确认回执。

于是对于停止等待协议就有以下几点：

• 在发送完一个分组后，必须暂时保留已发送的分组的副本，以备重发。
• 分组和确认分组都必须进行编号。
• 超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。

如果 A 不断重传分组但总是收不到确认，就说明通信线路太差，不能进行通信。像上述的这种可靠传输协议常称为自动重传请求 ARQ，意思是重传的请求是自动进行的，接收方不需要请求发送方重传某个出错的分组。

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

信道利用率公式：U = Td/(Td + RTT + Ta) 
// 可以看出，当往返时间 RTT 远大于分组发送时间 Td 时，信道的利用率就会非常低。
// 若出现重传，则对传送有用的数据信息来说，信道的利用率就还要降低。

为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输。就是发送方 A 可连续发送多个分组，不必每发完一个分组就停顿下来等待 B 的确认。这样可使信道上一直有数据不间断地传送。

1. 连续 ARQ 协议（滑动窗口协议，TCP 协议的精髓）

发送方 A 维持的发送窗口，它的意义是：位于发送窗口内的分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。

连续 ARQ 协议规定，发送方 A 每收到一个确认，就把发送窗口向前滑动一个分组的位置。

接收方 B 一般采用累积确认的方式。即不必对收到的分组逐个发送确认，而是对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都已正确收到了，如【ACK 9，表示9之前都接收到了，可以接收9了】。

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

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

TCP 连接的每一端都必须设有两个窗口—— 一个发送窗口和一个接收窗口。

TCP 的可靠传输机制用字节的序号进行控制。TCP 所有的确认都是基于序号而不是基于报文段。

TCP 两端的四个窗口经常处于动态变化之中。

TCP连接的往返时间 RTT 也不是固定不变的。需要使用特定的算法估算较为合理的重传时间。

TCP 虽然是面向字节流的，但 TCP 传送的数据单元却是报文段。

5.5 TCP 报文段的首部格式

一个 TCP 报文段分为首部和数据两部分，而 TCP 的全部功能都体现在它首部中各字段的作用。
TCP 报文段首部的前 20 个字节是固定的，后面有 4n 字节是根据需要而增加的选项 (n 是整数)。因此 TCP 首部的最小长度是 20 字节。

IP数据报首部 | IP数据包数据部分 内容为{TCP首部 | TCP数据部分} |

MSS (Maximum Segment Size)是 TCP 报文段中的数据字段的最大长度。MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”
由于数据字段加上 TCP 首部才等于整个的 TCP 报文段。所以，MSS是“TCP 报文段长度减去 TCP 首部长度”。MSS 与接收窗口值没有关系。

5.6 TCP 可靠传输的实现

TCP 的滑动窗口是以字节为单位的。
现假定 A 收到了 B 发来的确认报文段，其中窗口是 20 字节，而确认号是 31（这表明 B 期望收到的下一个序号是 31，而序号 30 为止的数据已经收到了）。
根据这两个数据，A 就构造出自己的发送窗口，显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率。

加权平均往返时间RTTs

第一次测量到 RTT 样本时，RTTs 值就取为所测量到的 RTT 样本值。以后每测量到一个新的 RTT 样本，就按下式重新计算一次 RTTs：

新的RTTS  =  (1 - α) * (旧的RTTs) + α * (新的RTT样本)                           
RFC 2988 推荐的 α 值为 1/8，即 0.125。 

超时重传时间 RTO (Retransmission Time-Out) 应略大于上面得出的加权平均往返时间 RTTs。

RFC 2988 建议使用下式计算 RTO：

RTO = RTTs + 4 * RTTd                                         

RTTd 是 RTT 的偏差的加权平均值

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

新的 RTTD = (1 - ß) * (旧的RTTD) + ß * |RTTS - 新的 RTT 样本|
ß 是个小于 1 的系数，其推荐值是 1/4，即 0.25

5.7 TCP 的流量控制

流量控制 (flow control) 就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制。

5.8 TCP 的拥塞控制

在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种现象称为拥塞 (congestion)。

增加资源不能解决拥塞。因为网络拥塞是一个非常复杂的问题。简单地采用上述做法，在许多情况下，不但不能解决拥塞问题，而且还可能使网络的性能更坏。
网络拥塞往往是由许多因素引起的。如：

• 增大缓存，但未提高输出链路的容量和处理机的速度，排队等待时间将会大大增加，引起大量超时重传，解决不了网络拥塞；
• 提高处理机处理的速率会会将瓶颈转移到其他地方；

拥塞引起的重传并不会缓解网络的拥塞，反而会加剧网络的拥塞。

拥塞控制与流量控制的区别

• 拥塞控制就是防止过多的数据注入到网络中，使网络中的路由器或链路不致过载。
• 拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。
• 拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。
• 流量控制往往指点对点通信量的控制，是个端到端的问题（接收端控制发送端）。
• 流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

拥塞控制和流量控制之所以常常被弄混，是因为某些拥塞控制算法是向发送端发送控制报文，并告诉发送端，网络已出现麻烦，必须放慢发送速率。这点又和流量控制是很相似的。

TCP 的拥塞控制方法

TCP 采用基于窗口的方法进行拥塞控制。该方法属于闭环控制方法(闭环控制方法是基于反馈环路的概念, 开环控制方法就是在设计网络时事先将有关发生拥塞的因素考虑周到，力求网络在工作时不产生拥塞)。

(Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)

---

visitor tracker

---