运输层（一）

博主： Xherlock
发布时间：2022 年 04 月 16 日
457 次浏览
暂无评论
6715字数
分类：计算机网络

# 运输层（一）

> 运输层	|	为运行在不同主机上的应用进程提供了逻辑通信功能

## 运输层服务

运输层协议在端系统中实现（不是路由器），

* 发送端：将从发送应用程序进程接收到的报文转换成运输层分组（**报文段**，segment），实现方法是将报文划分成较小的块，为每个块加上一个运输层首部以生成运输层报文段
* 接收端：网络层从数据报中提取运输层报文段，并向上交给运输层

运输层和网络层间区别：

**网络层是主机间通信，运输层是主机进程间通信**

类比案例：

![image-20220407105707573.png](http://xherlock.top/usr/uploads/2022/04/2722776710.png)

**运输层协议能够提供的服务受制于底层网络层协议的服务模型**

### 因特网运输层

网络协议IP为主机间提供逻辑通信，服务模型是**尽力而为交付服务**（best-effort delivery service），不确保**报文段的顺序交付和完整性**。因此被称为**不可靠服务**

TCP（传输控制协议）：可靠的、面向连接

UDP（用户数据报协议）：不可靠的、无连接

## 多路复用（multiplexing）和多路分解（de~）

多路复用：在源主机从不同套接字中收集数据块，并为每个数据块封装上首部信息从而生成报文段

多路分解：将运输层报文段中的数据交付到正确的套接字

![image-20220413223606259.png](http://xherlock.top/usr/uploads/2022/04/803361699.png)

**多路复用：**

![image-20220413233211509.png](http://xherlock.top/usr/uploads/2022/04/2205812705.png)

主机接收IP数据报，每个数据报携带一个传输层的报文段；主机使用IP+port传送报文段到正确套接字

port：16bits，0-65535（0-1023：周知well-known；1024-49151：registered；49152-65535：dynamic or private）

### 无连接的

UDP套接字：二元组（目的IP，目的端口号）

![image-20220413234533831.png](http://xherlock.top/usr/uploads/2022/04/2807226690.png)

### 面向连接的

TCP套接字：四元组（源IP地址，源端口号，目的IP地址，目的端口号）

![image-20220413235630796.png](http://xherlock.top/usr/uploads/2022/04/2645702163.png)

现在P4、P5、P6都合并为一个进程，每新建一个连接就创建一个新的线程

## UDP(User Datagram Protocol)

无连接的：发送报文段前，发送方和接收方的运输层实体之间没有握手

**应用：**

* 流媒体应用程序
* DNS：避免了TCP的连接创建时延
* SNMP（Simple Network Management Protocol）
* RIP（Routing Information Protocol）

**为什么用UDP**

* 没有拥塞控制：如果用TCP，信息传输链路如果拥堵会继续重新发送直到得到接收方收到确认，不管可靠交付多长时间；而UDP不用这样，可以满足实时应用的特点
* 无需建立连接：TCP传输数据前还需要经过三次握手，UDP不需任何准备即可开始传输数据，减少了延迟
* 无连接状态：UDP不维护连接状态，支持更多的活跃用户
* 分组首部开销少：TCP 20 bytes，UDP 8 bytes

### UDP报文段结构

![image-20220414085033998.png](http://xherlock.top/usr/uploads/2022/04/4164000939.png)

### UDP检验和（checksum）

检验UDP报文段传输过程中其中的比特是否发生改变

**发送方**：对所有16比特字的和进行反码运算&rightarrow;循环进位累加（最高位溢出右移与最低位相加）再求反码，得到的结果放入UDP检验和字段中

**接收方**：全部的16比特字进行相加（包括检验和），如果和=1111111111111111，可能无错误；否则出错

eg：![image-20220414091025404.png](http://xherlock.top/usr/uploads/2022/04/1842678503.png)

**为什么使用检验和**

* 不能保证源和目的之间的所有链路都提供差错检测
* 报文段存储时可能引入比特差错
* 差错检测作为一种保险措施（提供检测，但是对差错无能为力：丢弃受损报文段 或 交给应用程序并给出警告）

## 可靠数据传输原理

![image-20220414095016293.png](http://xherlock.top/usr/uploads/2022/04/375138417.png)

考虑**单向数据传输**，FSM：finite state machines有限状态机

### rdt1.0：经完全可靠信道的可靠数据传输

底层信道完全可靠：没有比特差错、没有分组损失，接收端不需要提供反馈信息给发送方

![image-20220414095851722.png](http://xherlock.top/usr/uploads/2022/04/4257342694.png)

### rdt2.0：经具有比特差错信道的可靠数据传输

底层信道发生比特错误，仍假设分组会按顺序接收，检验和来检查比特错误

此时需要**自动重传请求协议**（ARQ，Automatic Repeat reQuest）：有误的内容重传

* 差错检测
* 接收方反馈：ACK（acknowledgement）、NAK（negative acknowledgement），若收到接收方返回的NAK，发送方重传
* 重传

![image-20220414102540741.png](http://xherlock.top/usr/uploads/2022/04/2888990652.png)

![image-20220414102638775.png](http://xherlock.top/usr/uploads/2022/04/1407169464.png)

在等待ACK、NAK时，不能发送新的数据分组：**停等协议**（stop-and-wait），如图红线所示

![image-20220414103245396.png](http://xherlock.top/usr/uploads/2022/04/3214999741.png)

发送出错

![image-20220414103322594.png](http://xherlock.top/usr/uploads/2022/04/2894787961.png)

rdt2.0存在致命性缺陷：**ACK、NAK有可能损坏**

**方案**：正确收到ACK则发新数据，正确收到NAK或者无法确认收到的ACK、NAK则重发老数据

如果在发送方收到不清楚的ACK或NAK时，这种方法在发送方到接收方的信道中引入了冗余分组（duplicate packet），困难在于接收方不知道发送方是否正确收到上次所发的ACK或NAK

**解决**：在数据分组中添加新字段，让发送方对数据分组编号

#### rdt2.1

sender：

![image-20220414110713854.png](http://xherlock.top/usr/uploads/2022/04/3782307336.png)

receiver：

![image-20220414111046406.png](http://xherlock.top/usr/uploads/2022/04/2396666993.png)

#### rdt2.2

无NAK可靠数据传输协议，此时两次接收到相同的ACK相当于最后一次没有接收到正确分组（NAK）

当发送方收到接收方反馈的ACK中出现冗余情况（即接收方并未收到预期编号的正确数据包，isACK()），发送方认为刚才发送的数据存在错误，则重发该数据。

sender：

![image-20220414111556932.png](http://xherlock.top/usr/uploads/2022/04/1548158595.png)

receiver：

![image-20220414111629460.png](http://xherlock.top/usr/uploads/2022/04/1880044179.png)

### rdt3.0：经有比特差错的丢包信道的可靠数据传输

假定除了比特受损外，底层信道还会丢包，需要关注怎么检测丢包以及发生丢包后该做什么

**方案**：发送方传输一个数据分组，该分组或接收方对该分组的ACK发生了丢失，此时发送方都收不到接收方的响应，如果发送方愿意等待足够长时间以便确定分组已丢失，只需重传数据分组即可

为了实现基于时间的重传机制，需要一个倒计时定时器（countdown timer）

![image-20220414172612665.png](http://xherlock.top/usr/uploads/2022/04/2045634828.png)

**比特交替协议** alternating-bit

![image-20220416165138733.png](http://xherlock.top/usr/uploads/2022/04/3330780090.png)

![image-20220416165155798.png](http://xherlock.top/usr/uploads/2022/04/2007282803.png)

![image-20220416165211645.png](http://xherlock.top/usr/uploads/2022/04/203617219.png)

![image-20220416165231197.png](http://xherlock.top/usr/uploads/2022/04/932096405.png)

### 流水线可靠数据传输协议

rdt3.0仍是一个停等协议，发送利用率很低

方案：不以停等方式运行，允许发送方发送多个分组而无需等待确认&rightarrow;流水线（pipelining）技术

![image-20220416165758384.png](http://xherlock.top/usr/uploads/2022/04/2059387486.png)

（停等发送）

![image-20220416165839679.png](http://xherlock.top/usr/uploads/2022/04/887542153.png)

（流水线发送）

**流水线技术的影响**

* 必须增加序号范围（每个输送中的分组【不重传的】必须有一个唯一的序号）
* 协议的发送方和接收方都需要缓存多个分组（发送方最低限度应当能够缓冲那些已发送但没有确认的分组）

#### GBN：回退N步

Go-back-N：

* 发送方发送多个分组而不需等待确认，流水线中可存在N个未被确认的数据包
* 接收方需发送累计确认（cumulative ack）：如果出现间断就不发ack
* 发送方为最早未被确认数据包维护一个定时器

**发送方**

![image-20220416170518181.png](http://xherlock.top/usr/uploads/2022/04/3027358464.png)

N被称为窗口长度（window size），GBN协议也被称为滑动窗口协议（sliding-window protocol），存在限制是为了进行流量限制

**NOTE**：TCP序号是按字节流中的字节进行计数的，不是按分组计数

**扩展的FSM**

发送方：

* 上层的调用（invocation from above）：发送方首先查看窗口是否已满
  * 不满：创建分组并发送
  * 已满：只需将数据返回给上层
* 收到ACK：累计确认，必须正确接收序号
* 超时事件：超时则重传所有未被确认的分组

![image-20220416171542506.png](http://xherlock.top/usr/uploads/2022/04/2584424556.png)

接收方：

![image-20220416171614910.png](http://xherlock.top/usr/uploads/2022/04/2833220410.png)

* 丢弃所有失序分组，只需维护下一个按序节后的分组的序号

eg：

![image-20220416174007207.png](http://xherlock.top/usr/uploads/2022/04/2768422090.png)

#### SR：选择重传

GBN一个问题是需要重传大量分组，如果窗口长度和带宽时延很大

Selective repeat：

* 发送方只需重传没有收到ACK的分组（使用计时器限时）
* 也使用和GBN相同的窗口限制未完成、未被确认的分组
* 接收方确认一个正确接收的分组而不管其是否按序（缓存失序的分组）

![image-20220416175328075.png](http://xherlock.top/usr/uploads/2022/04/2238006872.png)

发送方：

* 从上层收到数据：同GBN
* 超时
* 收到ACK：若分组序号在窗口内，则发送方标记为已接收；若分组序号等于send_base，则窗口序号前移到具有最小序号的未确认分组处，窗口移动后有序号落在窗口内且未发送，则发送这些分组

接收方：

* 序号在[rcvbase, rcvbase+N-1]被正确接收：发送ACK回发送方；若该分组以前没收到过，缓存该分组；若该分组序号等于接收窗口的基序号，则该分组以及以前缓存的序号连续的分组交付给上层。然后接收窗口向前移动分组的编号向上交付这些分组
* 序号在[rcvbase-N, rcvbase-1]被正确接收：必须产生一个ACK，即使该分组是接收方以前已确认过的分组
* 其他：忽略

eg：

![image-20220416182551695.png](http://xherlock.top/usr/uploads/2022/04/1478734627.png)

### 小结：

**发展顺序**：

检验和：rdt2.0

确认（ACK）：rdt2.0

否认确认：rdt2.0

序号：rdt2.1

定时器：rdt3.0

窗口、流水线：rdt3.0+

最后修改：2022 年 06 月 15 日

如果觉得我的文章对你有用，请随意赞赏

发表评论取消回复

评论 *

私密评论

名称 *

🎲

邮箱 *

地址

Reverse（十一）
浏览次数: 2629
Win11新机鼓捣记录
浏览次数: 2382
栈~数制转换
浏览次数: 1604
C++学习
浏览次数: 1603
Python实现文件管理系统（重命名和删除）
浏览次数: 1575

顶点软件
你写得非常清晰明了，让我很容易理解你的观点。
mars
博主你好，请问怎么知道的alloc函数属于Buffer下的方法...
lj
该评论仅登录用户及评论双方可见
Mr.Guan
:@(赞一个)
Typecho
欢迎加入 Typecho 大家族

Vue（一）
浏览次数: 485
CH2 虚拟机中分析恶意代码
浏览次数: 395
Vue（二）
浏览次数: 843
Python爬取网页防盗链视频
浏览次数: 1013
《加密与解密》-逆向分析技术
浏览次数: 432

运输层（一）

Xherlock • 2022 年 04 月 16 日

# 运输层（一）

> 运输层	|	为运行在不同主机上的应用进程提供了逻辑通信功能

## 运输层服务

运输层协议在端系统中实现（不是路由器），

运输层和网络层间区别：

**网络层是主机间通信，运输层是主机进程间通信**

类比案例：

![image-20220407105707573.png](http://xherlock.top/usr/uploads/2022/04/2722776710.png)

**运输层协议能够提供的服务受制于底层网络层协议的服务模型**

### 因特网运输层

TCP（传输控制协议）：可靠的、面向连接

UDP（用户数据报协议）：不可靠的、无连接

## 多路复用（multiplexing）和多路分解（de~）

多路复用：在源主机从不同套接字中收集数据块，并为每个数据块封装上首部信息从而生成报文段

多路分解：将运输层报文段中的数据交付到正确的套接字

![image-20220413223606259.png](http://xherlock.top/usr/uploads/2022/04/803361699.png)

**多路复用：**

![image-20220413233211509.png](http://xherlock.top/usr/uploads/2022/04/2205812705.png)

主机接收IP数据报，每个数据报携带一个传输层的报文段；主机使用IP+port传送报文段到正确套接字

port：16bits，0-65535（0-1023：周知well-known；1024-49151：registered；49152-65535：dynamic or private）

### 无连接的

UDP套接字：二元组（目的IP，目的端口号）

![image-20220413234533831.png](http://xherlock.top/usr/uploads/2022/04/2807226690.png)

### 面向连接的

TCP套接字：四元组（源IP地址，源端口号，目的IP地址，目的端口号）

![image-20220413235630796.png](http://xherlock.top/usr/uploads/2022/04/2645702163.png)

现在P4、P5、P6都合并为一个进程，每新建一个连接就创建一个新的线程

## UDP(User Datagram Protocol)

无连接的：发送报文段前，发送方和接收方的运输层实体之间没有握手

**应用：**

* 流媒体应用程序
* DNS：避免了TCP的连接创建时延
* SNMP（Simple Network Management Protocol）
* RIP（Routing Information Protocol）

**为什么用UDP**

### UDP报文段结构

![image-20220414085033998.png](http://xherlock.top/usr/uploads/2022/04/4164000939.png)

### UDP检验和（checksum）

检验UDP报文段传输过程中其中的比特是否发生改变

**发送方**：对所有16比特字的和进行反码运算&rightarrow;循环进位累加（最高位溢出右移与最低位相加）再求反码，得到的结果放入UDP检验和字段中

**接收方**：全部的16比特字进行相加（包括检验和），如果和=1111111111111111，可能无错误；否则出错

eg：![image-20220414091025404.png](http://xherlock.top/usr/uploads/2022/04/1842678503.png)

**为什么使用检验和**

## 可靠数据传输原理

![image-20220414095016293.png](http://xherlock.top/usr/uploads/2022/04/375138417.png)

考虑**单向数据传输**，FSM：finite state machines有限状态机

### rdt1.0：经完全可靠信道的可靠数据传输

底层信道完全可靠：没有比特差错、没有分组损失，接收端不需要提供反馈信息给发送方

![image-20220414095851722.png](http://xherlock.top/usr/uploads/2022/04/4257342694.png)

### rdt2.0：经具有比特差错信道的可靠数据传输

底层信道发生比特错误，仍假设分组会按顺序接收，检验和来检查比特错误

此时需要**自动重传请求协议**（ARQ，Automatic Repeat reQuest）：有误的内容重传

* 差错检测
* 接收方反馈：ACK（acknowledgement）、NAK（negative acknowledgement），若收到接收方返回的NAK，发送方重传
* 重传

![image-20220414102540741.png](http://xherlock.top/usr/uploads/2022/04/2888990652.png)

![image-20220414102638775.png](http://xherlock.top/usr/uploads/2022/04/1407169464.png)

在等待ACK、NAK时，不能发送新的数据分组：**停等协议**（stop-and-wait），如图红线所示

![image-20220414103245396.png](http://xherlock.top/usr/uploads/2022/04/3214999741.png)

发送出错

![image-20220414103322594.png](http://xherlock.top/usr/uploads/2022/04/2894787961.png)

rdt2.0存在致命性缺陷：**ACK、NAK有可能损坏**

**方案**：正确收到ACK则发新数据，正确收到NAK或者无法确认收到的ACK、NAK则重发老数据

**解决**：在数据分组中添加新字段，让发送方对数据分组编号

#### rdt2.1

sender：

![image-20220414110713854.png](http://xherlock.top/usr/uploads/2022/04/3782307336.png)

receiver：

![image-20220414111046406.png](http://xherlock.top/usr/uploads/2022/04/2396666993.png)

#### rdt2.2

无NAK可靠数据传输协议，此时两次接收到相同的ACK相当于最后一次没有接收到正确分组（NAK）

sender：

![image-20220414111556932.png](http://xherlock.top/usr/uploads/2022/04/1548158595.png)

receiver：

![image-20220414111629460.png](http://xherlock.top/usr/uploads/2022/04/1880044179.png)

### rdt3.0：经有比特差错的丢包信道的可靠数据传输

假定除了比特受损外，底层信道还会丢包，需要关注怎么检测丢包以及发生丢包后该做什么

为了实现基于时间的重传机制，需要一个倒计时定时器（countdown timer）

![image-20220414172612665.png](http://xherlock.top/usr/uploads/2022/04/2045634828.png)

**比特交替协议** alternating-bit

![image-20220416165138733.png](http://xherlock.top/usr/uploads/2022/04/3330780090.png)

![image-20220416165155798.png](http://xherlock.top/usr/uploads/2022/04/2007282803.png)

![image-20220416165211645.png](http://xherlock.top/usr/uploads/2022/04/203617219.png)

![image-20220416165231197.png](http://xherlock.top/usr/uploads/2022/04/932096405.png)

### 流水线可靠数据传输协议

rdt3.0仍是一个停等协议，发送利用率很低

方案：不以停等方式运行，允许发送方发送多个分组而无需等待确认&rightarrow;流水线（pipelining）技术

![image-20220416165758384.png](http://xherlock.top/usr/uploads/2022/04/2059387486.png)

（停等发送）

![image-20220416165839679.png](http://xherlock.top/usr/uploads/2022/04/887542153.png)

（流水线发送）

**流水线技术的影响**

#### GBN：回退N步

Go-back-N：

**发送方**

![image-20220416170518181.png](http://xherlock.top/usr/uploads/2022/04/3027358464.png)

N被称为窗口长度（window size），GBN协议也被称为滑动窗口协议（sliding-window protocol），存在限制是为了进行流量限制

**NOTE**：TCP序号是按字节流中的字节进行计数的，不是按分组计数

**扩展的FSM**

发送方：

![image-20220416171542506.png](http://xherlock.top/usr/uploads/2022/04/2584424556.png)

接收方：

![image-20220416171614910.png](http://xherlock.top/usr/uploads/2022/04/2833220410.png)

* 丢弃所有失序分组，只需维护下一个按序节后的分组的序号

eg：

![image-20220416174007207.png](http://xherlock.top/usr/uploads/2022/04/2768422090.png)

#### SR：选择重传

GBN一个问题是需要重传大量分组，如果窗口长度和带宽时延很大

Selective repeat：

![image-20220416175328075.png](http://xherlock.top/usr/uploads/2022/04/2238006872.png)

发送方：

接收方：

eg：

![image-20220416182551695.png](http://xherlock.top/usr/uploads/2022/04/1478734627.png)

### 小结：

**发展顺序**：

检验和：rdt2.0

确认（ACK）：rdt2.0

否认确认：rdt2.0

序号：rdt2.1

定时器：rdt3.0

窗口、流水线：rdt3.0+

发表评论 取消回复

运输层（一）

发表评论取消回复