计算机网络-运输层

重点内容：

一.运输层协议概述

1.1进程间的通行

1.3运输层端口

复用：应用层所有的应用进程都可以通过运输层再传送到 IP 层（网络层） 。

分用：运输层从 IP 层收到发送给各应用进程的数据后，必须分别交付指明的各应用进程 。

那么我们已经知道运输层需要将数据交付至应用进程，怎么做呢？

1.使用PID计算机操作系统所指派的这种进程标识符来标志 X

——互联网上使用的计算机的操作系统种类很多，而不同的操作系统又使用不同格式的进程标识符。（不同操作系统格式不同）

2.把一个特定机器上运行的特定进程，指明为互联网上通信的最后终点 X

——这是因为进程的创建和撤销都是动态的，通信的一方几乎无法识别对方机器上的进程。

最终解决方案：在运输层使用协议端口号(protocol port number)，或通常简称为端口(port)。

硬件端口和软件端口的区别：

硬件端口是 不同硬件设备 进行交互的接口，而 软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。

端口号分类

二.用户数据报协议UDP 

2.1UDP的特点

(4) UDP 没有拥塞控制（相对于TCP来说），因此网络出现的拥塞不会使源主机的发送速率降低。 

        伪首部——只是在计算检验和时，临时添加，伪首部既不向下传送，也不向上递交，而仅仅是为了计算检验和。

        UDP计算检验和的方法和计算 IP 数据报首部检验和的方法相似（都是用二进制反码计算求和）。但是IP 数据报的检验和只检验 IP 数据报的首部，但 UDP 的检验和是把首部和数据部分一起都检验。

UDP校验和计算：

若 UDP 用户数据报的数据部分不是偶数个字节，则要填入一个全零字节（但此字节不发送）。

伪首部的第 3 字段是全零；第 4 字段是 IP 首部中的协议字段的值。对于 UDP ，此协议字段值为 17 ；第 5 字段是 UDP 用户数据报的长度。因此，这样的检验和，既检查了 UDP 用户数据报的源端口号和目的端口号以及 UDP 用户数据报的数据部分，又检查了 IP 数据报的源 IP 地址和目的地址。

三.传输控制协议TCP

3.1TCP的特点

TCP 并不关心应用进程一次把多长的报文发送到 TCP 的缓存中，而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP 发送的报文长度是应用进程给出的）。【 流量控制、拥塞控制 】

套接字

3.2TCP首部格式

(1) 源端口和目的端口，各2B，分用的实现

(2) 序号，4B，序号使用 mod 运算。在一个 TCP 连接中传送的字节流中的每一个字节都按顺序编号。首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号。

若确认号 = N，则表明：到序号 N – 1 为止的所有数据都已正确收到。

 (4) 数据偏移，4bit， 指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。所以首部最长为60B

当 URG 置 1 时，TCP 就把紧急数据插入到本报文段数据的 最前面。

(7) 紧急指针，2B，紧急指针仅在 URG = 1 时才有意义。指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据）

3.3可靠传输的工作原理

但是实际网络无法满足以上两个条件，这样一来我们就需要。

3.3.1停止等待协议

即收到接收方确认后才继续发送下一个分组。

 那么要是没有收到确认，则超时重传

如果接收方的确认丢失或是延迟了，导致超时重传

则接收方在接受到重复分组的时候将其丢弃，并再次发送确认

从信道利用率角度来说， 

3.3.2连续ARQ协议

维护一个发送窗口，采用累计确认的方式

3.4可靠传输的实现

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

~凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。 

~发送方的发送窗口大小还要受到当时网络拥塞程度的制约

~发送窗口后沿不可能向后移动，因为不能撤销掉已收到的确认。但是发送窗口前沿也有可能向后收缩。

举例说明

假定 A 发送了序号为 31 ~ 41 的数据，

要描述一个发送窗口的状态需要三个指针：P1，P2 和 P3

3.4.2超时重传时间的选择

1.确定RTT（round trip time）

TCP 保留了 RTT 的一个 加权平均往返时间 RTT S （这又称为 平滑的往返时间 ， S 表示 Smoothed 。

显然，超时计时器设置的 超时重传时间 RTO (RetransmissionTime-Out) 应略大于上面得

出的加权平均往返时间 RTT S 。

2.计算RTO(RetransmissionTime-Out)

是 RTT 的偏差的加权平均值, 它与 RTT S 和新的 RTT 样本之差有关。

那么 如何计算呢？

当第一次测量时， 值取为测量到的 RTT 样本值的一半。

在以后的测量中，则使用下式计算加权平均的 ：

现在我们已经知道了RTO的计算方法，但是这是在一切正常情况下（不出现确认丢失...）的理想方法 ，但如果出现超时重传的情况——如何判定此确认报文段是对先发送的报文段的确认，还是对后来重传的报文段的确认？

        

        由于重传的报文段和原来的报文段完全一样，因此源主机在收到确认后，就无法做出正确的判断，而正确的判断对确定加权平均 RTTS的值关系很大。

        若收到的确认是对重传报文段的确认，但却被源主机当成是对原来的报文段的确认，则这样计算出的 RTTS 和超时重传时间 RTO 就会偏大。若后面再发送的报文段又是经过重传后才收到确认报文段，则按此方法得出的超时重传时间 RTO 就越来越长。

        

        同样，若收到的确认是对原来的报文段的确认，但被当成是对重传报文段的确认，则

由此计算出的 RTT S 和 RTO 都会偏小。这就必然导致报文段过多地重传。这样就有可能使

RTO 越来越短。

3.4.3选择确认SACK

TCP 的接收方在接收对方发送过来的数据字节流的序号不连续，结果就形成了一些不连续的字节块（如图 5-21 所示）。

        但是，TCP 的首部没有哪个字段能够提供上述这些字节块的边界信息。所以只能够在首部的扩展选项中指明。但是首部最长60B，固定20B，剩下40B可用。

        

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

        

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

3.5流量控制

3.5.1利用滑动窗口实现流量控制

实例：

rwnd是接收窗口，假设初始状态rwnd=400

        我们应注意到，接收方的主机 B 进行了三次流量控制。第一次把窗口减小到 rwnd = 300 ，第二次又减到 rwnd = 100 ，最后减到 rwnd = 0 ，即不允许发送方再发送数据了。

        现在我们考虑一种情况。在图 5-22 中， B 向 A 发送了零窗口的报文段后不久， B 的接收缓存又有了一些存储空间。于是 B 向 A 发送了 rwnd = 400 的报文段。然而这个报文段在 传送过程中丢失了。A 一直等待收到 B 发送的非零窗口的通知，而 B 也一直等待 A 发送的 数据。如果没有其他措施，这种互相等待的 死锁 局面将一直延续下去。

3.5.2TCP传输效率

3.6拥塞控制

3.6.1拥塞控制基础概念和对比了解

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

1. 作用目标不同

• 流量控制
  流量控制的目标是解决发送方与接收方之间的速率匹配问题，防止发送方以过快的速度发送数据，从而超出接收方的处理能力。
  对象：发送方与接收方之间的通信。

• 拥塞控制
  拥塞控制的目标是解决网络中整体资源的合理分配问题，防止网络中的路由器或链路发生拥塞（数据流量超过网络承载能力）。
  对象：整个网络环境中的流量调节。

---

2. 发生的原因不同

• 流量控制的主要原因是：

  • 接收方的缓存容量有限，无法处理过多的接收数据。
  • 接收方处理数据的速度较慢，可能出现数据丢失或丢弃。

• 拥塞控制的主要原因是：

  • 网络中链路带宽或路由器缓存不足，导致拥塞。
  • 多条数据流同时通过同一段链路，造成资源争夺和延迟增加。

---

3. 解决机制不同

流量控制机制（点对点）

流量控制通常通过协议来调节发送方的发送速率，使其适应接收方的处理能力。常见的流量控制方法有：

1. 停止-等待协议

   • 发送方每次发送一个数据段，等待接收方确认，只有收到确认后才能继续发送。

2. 滑动窗口协议

   • 接收方会通知发送方一个窗口大小，表示当前能接收的数据量。发送方只能在窗口范围内发送数据，超过窗口大小的发送会被暂停。

3. 显式反馈

   • 接收方主动向发送方发送控制信息，告知其当前的缓冲区状态和接受能力。

---

拥塞控制机制（全局范围）

拥塞控制的重点是调节整个网络中的流量，以防止链路和路由器拥塞。常见的拥塞控制方法有：

1. TCP 拥塞窗口

   • TCP 使用一个**拥塞窗口（cwnd）**来限制发送方可以发送的数据量。
   • 拥塞窗口的大小动态调整，主要算法包括：
     • 慢启动：初始阶段窗口指数增长。
     • 拥塞避免：窗口线性增长，逐步探测网络容量。
     • 快速重传和快速恢复：丢包时快速减小窗口，避免严重拥塞。

2. 主动队列管理（AQM）

   • 在路由器中，通过主动丢弃分组（如 RED 算法）来警告发送方减小发送速率。

3. 显式拥塞通知（ECN）

   • 路由器检测到拥塞时，在数据包头中设置标志位，通知发送方减少流量。

---

4. 影响范围不同

• 流量控制

  • 只在发送方和接收方之间起作用，属于点对点的局部控制。

• 拥塞控制

  • 作用于整个网络，调整网络中所有流量发送方的速率，属于全局控制。

下面详细介绍如何进行拥塞控制：

 3.6.2拥塞控制算法

1.慢开始和拥塞避免

发送方控制拥塞窗口的原则是：

        只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，这样就可以提高网络的利用率。但只要网络出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，以便缓解网络出现的拥塞。

慢开始

由小到大逐渐增大拥塞窗口数值。

1.初始拥塞窗口设置

2.增加规则

实例：

但是现在又出现了一个问题，cwnd的过量增长导致网络拥塞。所以我们设置一个慢开始门限 ssthresh，并且结合拥塞避免算法。

拥塞避免算法

实例：

 初始阶段我们设置慢门限=16

并且在经过4号状态的时候，拥塞窗口并没有回到慢开始的初始状态，而是大于慢开始的初始窗口，这就涉及到了我们的快重传算法

快重传

采用快重传算法可以让发送方 尽早知道发生了个别报文段的丢失 。

        现假定接收方没有收到 M 3 但却收到了 M 4 。本来接收方可以什么都不做。但按照快重传算法，接收方必须立即发送对 M 2 的重复确认 ，以便让发送方及早知道接收方没有收到报文段 M 3 。发送方接着发送 M 5 和 M 6 。接收方收到后也仍要再次分别发出对 M 2 的重复确认。

        

        快重传算法规定， 发送方只要一连收到 3 个重复确认 ， 就知道接收方确实没有收到报文段 M 3 ， 因而应当立即进行重传（即“快重传”） ，这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。

 3.6.3主动队列管理AQM

上一节讨论的 TCP 拥塞控制并没有和网络层采取的策略联系起来。网络层的策略对 TCP 拥塞控制影响最大的就是路由器的分组丢弃策略。

尾部丢弃策略——由于队列长度总是有限的，因此当队列已满时，以后再到达的所有分组（如果能够继续排队，这些分组都将排在队列的尾部）将都被丢弃。

那么在这种策略下，当队列满的时候，如果有多个不同TCP连接的分组发送将会被丢弃，结果是分组没有发送导致确认超时，而超时后默认发生网络拥塞，调整慢开始门限，使这许多 TCP 连接在同一时间 突然都进入到慢开始状态。全局同步使得全网的通信量突然下降了很多（全局同步）

“主动”就是不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组。即主动丢弃分组，不多条让TCP线路同时降速。缓解总流量，但又不浪费总流量。

采用RED算法

3.7TCP运输连接管理

3.7.1TCP连接建立

简单来说，没有第三次握手可能会导致服务器资源被浪费，因为不知道客户端是否正常。

3.7.2TCP连接释放

B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。（四次握手的第三个报文） 。

A 在收到 B 的连接释放报文段后，必须对此发出确认。

并且A必须经过时间等待计时器(TIME-WAIT timer)设置的时间 2MSL 后，A 才进入到 CLOSED 状态。