【计算机网络】运输层

最新推荐文章于 2023-12-23 09:00:00 发布

Shad0w-2023

最新推荐文章于 2023-12-23 09:00:00 发布

阅读量508

点赞数 1

分类专栏：计算机网络（自顶向下法）文章标签：计算机网络

本文链接：https://blog.csdn.net/qq_73985089/article/details/134183947

版权

计算机网络（自顶向下法）专栏收录该内容

5 篇文章 0 订阅

订阅专栏

概述运输层服务

运输层协议为运行在不同主机上的应用程序提供了逻辑通信功能。
运输层协议是在端系统中而不是在路由器中实现的。

运输层和网络层的关系：
网络层提供主机之间的逻辑通信，而运输层为**运行在不同主机上的应用程序（进程）**提供逻辑通信。
运输层协议只工作在端系统中！

因特网运输层概述：
因特网为应用层提供了两种截然不同的运输层协议：UDP和TCP

UDP（用户数据报协议：
提供不可靠，无连接的服务。
TCP（传输控制协议）：
提供可靠，面向连接的服务。
多路复用和多路分解：
简单来说，将由网络层提供的主机到主机交付服务延伸到为运行在主机上的应用程序提供进程到进程的交付服务就是运输层的多路复用和多路分解。
将运输层报文段中的数据交付到正确的套接字的工作称为多路分解。
从源主机中接收来自不同进程的数据块，并将报文段传递到网络层，所有这些工作被称为多路复用。

无连接运输：UDP

DUP报文结构：
DUP检验和：
UDP检验和提供了差错检测功能，发送方的UDP对报文段zh给的所有16比特子的和进行反码运算，求和是遇到的任何溢出都被回卷。
虽然UDP提供了差错检测，但它对差错回复无能为力！

可靠数据传输原理：

rdt1.0：
rdt1只考虑最简单的情况，即认为底层信道是完全可靠的，发送方发送，接收方接收就完事了
rdt2.0：
底层信道更为实际的模型是分组中的比特可能受损。rdt2.0使用了肯定确认（ACK）和否定确认（NAK），使用了这种机制之后，发送方能够得知那些报文被正确接收，那些没有被正确接收，因此需要重传，基于这样的可可奥数据传输协议称为自动重传请求协议（ARQ）。
注意在rdt2.0中，当发送方处于等待接收方的ACK或者NAK确认报文的时候，不能从上层获得更多的数据，由于这种行为，rdt2.0被称为停等协议。
rdt3.0：
rdt3.0对报文段上附加了序号，并且在发送方发送数据时，启动了一个定时器，如果定时器超时，则将重传该报文，注意这里由于使用了序号，所以发送方知道它因该发送那个报文段，这就解决了冗余数据分组的问题。由于rdt3.0的序号是0和1交替的，因此rdt3.0有时被称为比特交替协议。
流水线可靠数据传输协议：
这种协议呢，实际上就是在发送方的排队序列中，可以一次性发送不止一个分组（但这个分组是固定的），当接收到该分段所有的确认报文后，窗口向后移动，发送未发送的分组。
回退N步（GBN）协议：
回退N步协议也常被称为滑动窗口协议。
就是说，在一个窗口内，接收方必须按序接收分组，如果说，本来应该接收n分组，但是n+1分组到达，接收方则丢弃n+1分组（实际上可能缓存），在发送方回退，从n分组开始重新发送，这就是回退N步协议。
选择重传：
选择重传优化了回退N步协议，即接收方缺少哪个，发送方就发送哪个，那是怎么实现的呢？
发送方在每个报文发送时都启动一个定时器，在接收方，按序应该接收n，但是收到了n+1，那么接收方就缓存这个分组，直到n分组在发送方的定时器到时，发送方重新发送n分组，接收方接收到n+1之前的所有分组之后，才向上传输。

面向连接的传输：TCP

MSS：最大报文段长度，注意到MSS是指在报文段里应用层数据的最大长度，而不是只包括首部的TCP报文段的最大长度。
MTU：最大链路层帧长度

TCP报文结构：
- 源端口号和目的端口号用于多路复用/多路分解
- 序号和确认号：用于可靠传输
- 首部长度（数据偏移）：TCP首部长度，由于选项字段的原因，TCP首部长度可变
- 选项
- 标志字段：ACK用于指示确认，RST,SYN,FIN用于连接建立和拆除，PSH只是接收方应将数据交给上层，URG用来指示报文段里存在着被发送端的上层实体指示为“紧急”的数据。
序号和确认号
往返时间估计与超时：
往返时间估计是实时的，并且与上一个时间相关联，但是当前的更能反应链路中的拥塞情况，所以当前的占更大的权重。
可靠数据传输：
超时时间加倍：就是说在传输过程中，发送端不是要等待接收端的确认报文嘛，如果说其中有个确认报文没有收到，这可能是因为链路中拥塞而导致的，如果说发送端很快的又发送了一个报文，那将会加重链路上的负担，所以，当没有收到确认报文的时候，发送端重新发送报文，并且将超时时间间隔设置为之前的双倍。
流量控制：
在TCP连接的两端，都会存在缓存，在接收端，接收到的报文首先存放到缓存中，应用程序按需从缓存中拿数据，而这个速度可快可慢，如果说应用程序从缓存中拿数据的速度很慢，而发送端发送数据的速度很快，那么导致接收端缓存溢出，导致丢弃报文。
解决：在进行数据传输和发送确认报文的时候，接收端会告知发送端缓存情况，发送端根据这个缓存情况来发送报文。
那么如果说，接收端的缓存满了，发送端收到这个消息，那么发送端就会停止发送，那何时开始继续发送？实际上，当接收端告知发送端缓存已满时，发送端还会发送一字节的报文，以用来确认缓存区清零，并且开始发送报文。
TCP连接管理：

我们来看客户端想要和服务器建立TCP连接的情况：

首先，客户端发送一个SYS字段设置为1，并且随机序号（x）的SYS报文
服务器收到该报文后，为该连接分配内存，并且也设置一个序号，然后也设置SYS字段为1，的ACK报文，注意这里ACK序号为x+1，告诉客户端已经收到序号为x的数据
客户端发送一个确认报文，ACK字段为1，seq = y+1
由于收到连接请求报文的时候，服务器会分配缓存，这就为攻击者提供了便利，攻击者发送很多请求连接报文，而服务器一直保持这种半连接状态，服务器上的内存总会被分配完的，那么如何有效的避免这种攻击呢？就是服务器生成一个SYS cookie，这个cookie由源地址IP和端口号生成。

TCP拥塞控制

首先，我们来讨论三个问题：

一个TCP如何限制它向其连接发送流量？
TCP如何知道链路上发生了拥塞？
如果发生了拥塞，TCP如何降低发送速率？

我们来逐个解决这三个问题：

TCP如何限制它向其连接发送流量？
发送方的TCP拥塞控制机制追踪一个额外的变量：即拥塞窗口，还记得我们之前讲到过的窗口吗？在一个发送方中，未被确认的数据量不会超过cwnd和rwnd中的最小值，以此限制了发送量。
TCP如何知道其链路上出现了拥塞？
当出现拥塞的时候，在沿着这条路径上的一台（或多台）路由器的缓存就会溢出，引起一个数据报被丢弃，丢弃的数据报会引起发送方的丢包事件（要么超时要么收到三个冗余ACK，发送方就认为在发送方到接收方的路径上出现了拥塞指示。
如果发生了拥塞，TCP如何降低其发送速率？
TCP使用下列指导性的原则回答这个问题：
- 一个丢失的报文段表意味着拥塞
- 一个确认报文段指示该网络正在向接收方交付发送方的报文段
- 带宽检测

TCP拥塞控制算法：
1. 慢启动
  当一条TCP开始连接时，cwnd的只通常初始置为一个MSS的较小值，在慢启动状态，cwnd的值以一个较小的MSS开始并且每当传输的报文段首次被确认，就增加一个MSS，那么慢启动状态何时停止？第一种情况就是：如果存在一个由超时指示的丢包事件（即拥塞），TCP发送方将cwnd设置为1并重新开始慢启动过程。它还将第二个状态变量ssthresh（“慢启动阈值”的速记）设置为cwnd/2，即当检测到拥塞时，将ssthresh置为拥塞窗口值的一半。第二种方式是直接与ssthresh的值相关联，即当cwnd==ssthresh时，慢启动过程结束并且TCP转移到拥塞避免模式。第三种结束慢启动的方式是，如果检测到3个冗余ACK这时TCPzhi’xing’yi’zh给快速重传并进入快速恢复状态。
2. 拥塞避免
3. 快速恢复