ch05 Transport Layer-01.md

目录

• ch05 Transport Layer-01
  • 运输层在协议栈中的地位和作用
  • 运输层的通信和网络层的通信的区别
  • SCTP
  • 运输层的功能
    • 一，运输层的主要功能
    • 二，运输层协议和网络层协议的主要区别
  • 运输层协议UDP和TCP
    • 一，运输层的两个主要协议 TCP&UDP
      • 1. 运输协议数据单元 TPDU
      • 2. TCP/UDP协议传输的特性
      • 3. UDP是面向报文,TCP是面向字节流
        • UDP面向报文
        • TCP面向字节流
    • 二，软件端口与硬件端口
      • 1. 端口简介
      • 2. 传输层的三类端口
  • 用户数据报协议 UDP【User Datagram Protocol】
    • 一，简介：
    • 二，UDP 的首部格式
    • 三，UDP的主要特点
    • 四，UDP基于端口的分用
  • 传输控制协议TCP概述【Transmission Control Protocol 】
    • 一，Transmission Control Protocol概述
    • 二，TCP的连接
      • 1. 概述
      • 2. 套接字socket
    • 三，TCP的可靠传输
      • 1. 停止等待协议
      • 2. 连续ARQ协议
      • 3. TCP报文段的首部格式
      • 4. 基于滑动窗口的TCP可靠传输
    • 四，TCP的流量控制(利用滑动窗口实现)
    • 五，TCP的拥塞控制
      • 1. 拥塞控制的一般原理
      • 2. 拥塞控制算法
        • • 2.1 慢开始和拥塞避免
          • 慢开始算法的原理
          • 慢开始和拥塞避免的结合使用
          • 例子
          • 2.2 快重传和快恢复
      • 3. 慢开始，拥塞避免&快重传，快恢复总结
        • 慢开始：
        • 拥塞避免：
        • 快重传：
        • 快恢复：
        • 遇到网络拥塞(超时)
    • 六，发送窗口的实际上限值
    • 七，流量控制和拥塞控制的区别
  • TCP的运输连接管理
    • 一，概述
    • 二，连接的建立(三次握手)
      • 客户端服务器端的状态
    • 三，连接的释放(四次挥手)
    • 四，例子

ch05 Transport Layer-01

运输层在协议栈中的地位和作用

网络层：主机与主机间的通信

传输层：主机中的进程与主机中的进程间的通信

从通信和信息处理的角度看,运输层向它上面的应用层提供通信服务,它属于面向通信部分的最高层,同时也是用户功能中的最低层。

当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时,只有主机的协议栈オ有运输层,而网络核心部分中的路由器在转发分组时都只用到下三层的功能从网络层来说,通信的两端是两个主机。IP数据报的首部明确地标志了这两个主机的IP 地址。但“两个主机之间的通信”这种说法还不够清楚。

这是因为,真正进行通信的实体是在主机中的进程,是这个主机中的一个进程和另ー个主机中的一个进程在交换数据(即通信)。
因此严格地讲,两个主机进行通信就是两个主机中的应用进程互相通信。IP协议虽然能把分组送到目的主机,但是这个分组还停留在主机的网络层而没有交付主机中的应用进程。从运输层的角度看,通信的真正端点并不是主机而是主机中的进程。也就是说,端到端的通信是应用进程之间的通信（如下图）因此,运输层是不可缺少的。

所以运输层的通信和网络层的通信有很大的区别。网络层提供主机之间的逻辑通信,而运输层则提供应用进程之间的逻辑通信运输层还有复用、分用的功能,还要对收到的报文进行差错检测。

运输层的通信和网络层的通信的区别

SCTP

流控制传输协议

Stream Control Transmission Protocol，
SCTP是一个面向连接的流传输协议，它可以在两个端点之间提供稳定、有序 的数据传递服务

SCTP协议的特点

1. 处于TCP/IP协议的传输层
2. 是面向连接的协议
3. 能有效抵御SYN Flooding攻击
4. 具有多宿和多流的特性
5. 能更好的满足应用层的需求

运输层的功能

一，运输层的主要功能

运输层为应用进程之间提供端到端的逻辑通信（但网络层是为主机之间提供逻辑通信）

运输层还要对收到的报文进行差错检测。

运输层提供面向连接和无连接的服务。

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

IP 协议( 网络层协议 )的作用范围：提供主机之间的逻辑通信

TCP 和 UDP 协议( 运输层协议 )的作用范围： 提供进程之间的逻辑通信

运输层协议UDP和TCP

一，运输层的两个主要协议 TCP&UDP

用户数据报协议 UDP (User Datagram Protocol)

接收方收到有差错的UDP用户数据报时应如何处理? 解答:简单地丢弃。

传输控制协议 TCP (Transmission Control Protocol)

1. 运输协议数据单元 TPDU

两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元 TPDU (Transport Protocol Data Unit)。

TCP 传送的协议数据单元是 TCP 报文段(segment)

UDP 传送的协议数据单元是 UDP 报文或用户数据报

2. TCP/UDP协议传输的特性

TCP 和UDP最大的区别就是：TCP/IP是面向连接的，UDP是无连接的。

简单些说就是：

TCP：

A发消息给B，B有没有收到，A是清楚的

UDP：
A发消息给B，B有没有收到，A是无从得知的

	TCP	UDP
是否连接	面向连接	无连接
传输可靠性	可靠的	不可靠的
应用场景	传输少量数据	大量数据
速度	慢	快

在实际的使用中:

TCP主要应用于文件传输精确性相对要求较高且不是很紧急的情景，比如电子邮件、远程登录等。有时在这些应用场景下即使丢失一两个字节也会造成不可挽回的错误，所以这些场景中一般都使用TCP传输协议。

由于UDP可以提高传输效率，所以UDP被广泛应用于数据量大且精确性要求不高的数据传输，比如我们平常在网站上观看视频或者听音乐的时候应用的基本上都是UDP传输协议。

需要对传输效率和传输质量做一个权衡

3. UDP是面向报文,TCP是面向字节流

UDP面向报文

发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付IP层。

UDP 对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。这就是说,应用层交给UDP多长的报文,UDP就照样发送,即一次发送一个报文,如上图所示。
在接收方的UDP,对IP层交上来的UDP用户数据报,在去除首部后就原封不动地交付上层的应用进程。也就是说,UDP一次交付一个完整的报文。因此,应用程序必须选择合适大小的报文。若报文太长,UDP把它交给IP层后,IP层在传送时可能要进行分片,这会降低IP 层的效率。反之,若报文太短,UDP把它交给IP层后,会使IP数据报的首部的相对长度太大,这也降低了IP层的效率。

TCP面向字节流

TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流，应用层进程给了多少不代表TCP就要发多少

TCP发送的报文大小根据对方给出的接受窗口值(rwnd)和当前网络拥塞(cwnd)的程度来决定

• 如果应用进程传送到TCP缓存的数据块太长,TCP就可以把它划分短一些分多次传送。

• 如果应用进程一次只发来一个字节,TCP也可以等待积累有足够多的字节后再构成报文段发送出

TCP中的“流”(stream)指的是流入到进程或从进程流出的字节序列。
“面向字节流”的含义是:

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

TCP并不知道所传送的字节流的含义。

TCP不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系(例如,发送方应用程序交给发送方的TCP共10个数据块,但接收方的TCP可能只用了4个数据块就把收到的字节流交付上层的应用程序)。但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。

当然,接收方的应用程序必须有能力识别收到的字节流,把它还原成有意义的应用层数据。为了突出示意图的要点,我们只画出了一个方向的数据流。

但请注意,在实际的网络中,一个TCP报文段包含上干个字节是很常见的,而图中的各部分都只画出了几个字节, 这仅仅是为了更方便地说明“面向字节流”的概念。

另一点很重要的是上图中的TCP 连接是一条虚连接(也就是逻辑连接),而不是一条真正的物理连接。TCP报文段先要传送到P层,加上IP首部后,再传送到数据链路层。再加上数据链路层的首部和尾部后,才离开主机发送到物理链路。
由上述分析概括易知,TCP和UDP在发送报文时所采用的方式完全不同。TCP并不关心应用进程一次把多长的报文发送到TCP的缓存中,而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节(UDP发送的报文长度是应用进程给出的)。

如果应用进程传送到TCP缓存的数据块太长,TCP就可以把它划分短一些再传送。如果应用进程一次只发来一个字节,TCP也可以等待积累有足够多的字节后再构成报文段发送出去

关于TCP报文段的长度问题,在后面还要进行讨论。

二，软件端口与硬件端口

1. 端口简介

软件端口：

在协议栈层间的抽象的协议端口

硬件端口：

路由器或交换机上的端口

传输层端口：

传输层端口用一个 16 位端口号进行标志

此端口号只具有本地意义，端口号用来区分某台计算机的应用层中的不同进程，在因特网中不同计算机的相同端口号是没有联系的

MAC地址： 48位

IPv4地址： 32位

IPv6地址： 128位

传输层端口：16位

2. 传输层的三类端口

1. 熟知端口，数值一般为 0～1023。

FTP:21

TELNET:23

SMTP:25

DNS:53

HTTP:80

2. 登记端口号，数值为1024～49151

3. 客户端口号，数值为49152～65535

• 熟知端口和登记端口一般作为服务器端，客户端口号一般作为客户端

• 对于本地客户端而言端口号无所谓，但对于服务器而言端口号是不可以乱用的

graph LR A[Client IP:Port] --- B[Server IP:Port]

不同应用层协议选择TCP或者UDP的理由

凡是使用TCP的应用层协议,都是需要可靠传送应用层协议的数据。但为什么不是所有的应用层协议都使用TCP呢?

这是因为TCP的开销太大,而有的数据并不一定要使用TCP来传送。

用UDP传送数据的开销很小。

例如RIP路由选择协议,在和相邻的路由器交换路由信息时,如果丢失了,则下一次还会再发送(每隔一定的时间发送一次)。这样就比使用TCP更加有利。

注：

RIP协议使用运输层的用户数据报UDP进行传送(使用UDP的端口520)

因此RIP 的位置应当在应用层,在UDP的上面

用户数据报协议 UDP【User Datagram Protocol】

一，简介：

中文：

用户数据报协议

英文：

User Datagram Protocol

含义：

UDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据包的方法。应用场景是传输大量数据，传输速度快

	TCP	UDP
是否连接	面向连接	无连接
传输可靠性	可靠的	不可靠的
应用场景	传输少量数据	大量数据
速度	慢	快

二，UDP 的首部格式

UDP 两个字段：数据字段和首部字段:

首部字段有 8 个字节，由 4 个字段组成，每个字段都是两个字节。

长度：整个UDP数据报的长度在计算检验和时，临时把“伪首部”和 UDP 用户数据报连接在一起。伪首部仅仅是为了计算检验和。

三，UDP的主要特点

UDP 是无连接的，即发送数据之前不需要建立连接。

UDP 使用尽最大努力交付，即不保证可靠交付，同时也不使用拥塞控制。

UDP 是面向报文的。UDP 没有拥塞控制，很适合多媒体通信的要求。

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

UDP 的首部开销小，只有 8 个字节。

	TCP	UDP
是否连接	面向连接	无连接
传输可靠性	可靠的	不可靠的
应用场景	传输少量数据	大量数据
速度	慢	快

四，UDP基于端口的分用

当运输层从 IP 层收到 UDP 数据报时，就根据首部中的目的端口，把 UDP 数据报通过相应的端口，上交给最后的终点——应用进程。

传输控制协议TCP概述【Transmission Control Protocol 】

一，Transmission Control Protocol概述

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

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

TCP 提供可靠交付的服务

TCP 提供全双工通信

二，TCP的连接

1. 概述

正如之前所讲的:

TCP 和 UDP 协议( 运输层协议 )的作用范围： 提供进程之间的逻辑通信

TCP 把连接作为最基本的抽象,每一条 TCP 连接有两个端点。

TCP 连接的端点不是主机，不是主机的IP 地址，不是应用进程，也不是运输层的协议端口。

TCP 连接的端点叫做套接字(socket)或插口

2. 套接字socket

\[socket =(IP地址: 端口号) \]

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

\[\large TCP 连接 ::= \{socket1, socket2\} = \{(IP1: port1), (IP2: port2)\} \]

三，TCP的可靠传输

1. 停止等待协议

无差错情况，超时重传

在发送完一个分组后，必须暂时保留已发送的分组的副本。

分组和确认分组都必须进行编号。

超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。

确认丢失和确认迟到

使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。

这种可靠传输协议常称为自动重传请求ARQ (Automatic Repeat reQuest)。

ARQ 表明重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组 。

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

流水线传输

发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。

由于信道上一直有数据不间断地传送，这种传输方式可获得很高的信道利用率。

2. 连续ARQ协议

1. 位于窗口内的分组都可以连续的发送出去，无需等待接受窗口的确认，这样的话信道的利用率就提高了

2. 接收方采用累积确认的方式，也就是接收方在收到几个分组后，对按序到达的最后一个分组发送确认，用以表示到这个分组为止的所有分组都已经正确收到了

   累积确认：

   优点：容易实现，即使确认丢失也不需要重传

   缺点：不能像发送方反映出接收方已经正确收到的所有分组信息

   比如如果发送方发送了前五个分组，而中间的第三个分组丢失了。这时接收方只能对前两个分组发出确认

   发送方无法知道后面的三个分组的下落，而只好把后面的三个分组再重传一次，所以当通信质量不好时，连续ARQ协议会带来负面 影响

3. TCP报文段的首部格式

源端口和目的端口字段

各占 2 字节

端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。

序号字段 seq

占 4 字节

TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。

确认号字段 ack

占 4 字节

是期望收到对方的下一个报文段的数据的第一个字节的序号。

确认 ACK

只有当 ACK = 1 时确认号字段(ack)才有效。当 ACK = 0 时，确认号无效

同步 SYN

同步 SYN = 1 表示这是一个连接请求或连接接受报文

终止 FIN (FINish)

用来释放一个连接。FIN = 1 表明此报文段的发送端的数据已发送完毕，并要求释放运输连接

4. 基于滑动窗口的TCP可靠传输

四，TCP的流量控制(利用滑动窗口实现)

流量控制(flow control)就是让发送方的发送速率不要太快:

既要让接收方来得及接收，也不要使网络发生拥塞

利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制

接收方来得及接收：发送方的发送某种意义上是由接收方控制的

发送方发慢了网络也就不堵塞了

注意rwnd

例子：

五，TCP的拥塞控制

1. 拥塞控制的一般原理

出现资源拥塞的条件：

\[\LARGE对资源需求的总和 > 可用资源 \]

拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素

2. 拥塞控制算法

发送方维持拥塞窗口 cwnd (congestion window)

2.1 慢开始和拥塞避免

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

• 只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。

• 只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。

慢开始算法的原理

一个轮次就是一个来回,每过一个轮次发送的数目*2

1 2 4 8 9 10 11

1 2 4 8 16 慢开始门限状态变量ssthresh

慢开始门限 ssthresh 的用法如下：

1. 当 cwnd < ssthresh 时，使用慢开始算法

2. 当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法

3. 当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法

拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，使拥塞窗口 cwnd 按线性规律缓慢增长

慢开始和拥塞避免的结合使用

无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（没有按时收到确认），就要把慢开始门限设置为出现拥塞时的发送方窗口值的一半（但不能小于2）

即：

\[ssthresh = \frac{出现拥塞时的发送窗口}{2} \]

然后把拥塞窗口 cwnd 重新设置为 1，执行慢开始算法

这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕

例子

看ppt（具体流程）

2.2 快重传和快恢复

XXXXXXXXXXXXXXXXXXXXXXXXXX

问题！！！

3. 慢开始，拥塞避免&快重传，快恢复总结

慢开始：

到达门限之前每一轮拥塞窗口cwnd翻倍

拥塞避免：

当cwnd达到慢开始门限时，执行拥塞避免算法每次拥塞窗口cwnd+1

快重传：

是一个内部机制，无法直接体现在图里具体情况如下

(收到便立刻进行确认)

快恢复：

1. 慢开始门限=cwnd/2
2. cwnd=慢开始门限

遇到网络拥塞(超时)

1. 慢开始门限=cwnd/2

2. 拥塞窗口cwnd=1

3. 从慢开始执行(从头再来)

六，发送窗口的实际上限值

发送方的发送窗口的上限值应当取为接收方窗口 和拥塞窗口 这两个变量中较小的一个，即应按以下公式确定：

\[\Large发送窗口的上限值 = Min [rwnd, cwnd] \]

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

流量控制

在一条TCP连接中的接收端采用的措施,用来限制对方(发送端)发送报文段的速率,以免在接收端来不及接收。

流量控制只控制一个发送端

拥塞控制

用来控制TCP连接中发送端发送报文段的速率,以免使互联网中的某处产生过载。

拥塞控制可能会同时控制许多个发送端,限制它们的发送速率。

不过每一个发送端只知道自己应当怎样调整发送速率,而不知道在互联网中还有哪些主机被限制了发送速率

\[\large发送窗口的上限值 = Min [rwnd, cwnd] \]

我们知道,发送窗口的上限值是Min[rwnd,cwnd],即发送窗口的数值不能超过接收窗口和拥塞窗口中的较小的一个。

接收窗口的大小体现了接收端对发送端施加的流量控制

拥塞窗口的大小则是整个互联网的负载情况对发送端施加的拥塞控制。

因此,当接收窗口小于拥塞窗口时,发送窗口的大小取决于流量控制,即取决于接收端的接收能力。但当拥塞窗口小于接收窗口时,则发送窗口的大小取决于拥塞控制,即取决于整个网络的拥塞状况

TCP的运输连接管理

试用具体例子说明为什么在运输连接建立时要使用三报文握手。说明如不这样做可能会出现什么情况？

滞留在网络中某处的陈旧的SYN报文段消耗服务器的资源

一，概述

运输连接有三个阶段，即：

1. 连接建立

2. 数据传送

3. 连接释放

TCP 连接的建立都是采用客户服务器方式

主动发起连接建立的应用进程叫做客户(client)

被动等待连接建立的应用进程叫做服务器(server)

二，连接的建立(三次握手)

序号字段 seq

占 4 字节，TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。

确认号字段 ack

占 4 字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。

确认 ACK

只有当 ACK = 1 时确认号字段(ack)才有效。当 ACK = 0 时，确认号无效

同步 SYN

同步 SYN = 1 表示这是一个连接请求或连接接受报文

过程描述：

1. A 的 TCP 向 B 发出连接请求报文段，其首部中的同步位 SYN = 1，并选择序号 seq = x，表明传送数据时的第一个数据字节的序号是 x

2. B 的 TCP 收到连接请求报文段后，如同意，则发回确认。

   B 在确认报文段中应使 SYN = 1，使 ACK = 1，其确认号ack = x + 1，自己选择的序号 seq = y

3. A 收到此报文段后向 B 给出确认，其 ACK = 1，确认号 ack = y + 1

   A 的 TCP 通知上层应用进程，连接已经建立

4. B 的 TCP 收到主机 A 的确认后，也通知其上层

   应用进程：TCP 连接已经建立。

客户端服务器端的状态

1. 最初两端的TCP进程都处于CLOSED(关闭)状态

   此例中

   A（client）主动打开连接

   B（server）被动打开连接

2. B的TCP服务器进程处于LISTEN（收听）状态，等待客户连接请求，如果出现客户连接请求则立即做出响应

3. A向B发送第一个TCP报文段（第一次握手），A进入SYN-SENT（同步已发送）状态

4. B收到A的请求报文后，如果同意建立连接，则向A发送确认报文（第二次握手），此时TCP服务器进程进入SYN-RCVD（同步收到）状态

5. A收到B的确认后会再向B给出确认（第三次握手），此时TCP连接已建立，A进入ESTABLISH状态

6. B收到A的确认后也进入ESTABLISH状态

三，连接的释放(四次挥手)

终止 FIN (FINish)

用来释放一个连接。FIN = 1 表明此报文段的发送端的数据已发送完毕，并要求释放运输连接

数据传输结束后，通信的双方都可释放连接。

上图中A，B均处于ESTABLISH状态。

1. A的应用进程先向TCP发出释放连接报文段（第一次挥手），并停止再发数据，主动关闭TCP连接，此时A进入FIN-WAIT-1状态

   • 第一次挥手的seq=u中的u为前面已经传送过的数据的最后一个字节的序号+1

   • 此报文段即使不携带数据，也会消耗掉一个序号

2. B收到A发送的连接释放报文段后即发出确认（第二次挥手），然后进入CLOSE-WAIT状态。

   TCP服务器（B）通知高层应用进程，此时从A到B这个方向的连接就释放了，此时的TCP便处于半关闭(half-close)状态

   就是A，B都知道A没有数据要发送了，TCP的A的这一端"已经关闭了"

   但是，如果B发送数据A仍然要接收，也就是说，从B到A这个方向的连接并未关闭，这个状态可能会持续一段时间

3. A收到来自B的确认后就进入FIN-WAIT-2状态，等待B发出的连接释放报文段

4. 若B此时已经没有要向A发送的数据，服务器（B）中的进程就通知TCP释放连接（第三次挥手）。B进入LAST-ACK阶段

5. A收到B的连接释放报文段后必须对此发出确认（第四次握手），然后进入到TIME-WAIT状态经过2MSL后进入CLOSED状态。

四，例子