《计算机网络》第五章运输层读书笔记

最新推荐文章于 2024-09-29 09:40:23 发布

老老路

最新推荐文章于 2024-09-29 09:40:23 发布

阅读量151

点赞数 1

文章标签：网络协议

本文链接：https://blog.csdn.net/weixin_42372407/article/details/132943552

版权

第五章运输层

运输层通信的对象是主机中的进程，而运输层下的网络层通信的对象是主机。

在这里插入图片描述

运输层有两个主要协议

TCP 传送数据前必须先建立连接，由于需要可靠，所以不可避免地增加了确认、流量控制、计时器、连接管理等，增大了首部，占用了处理器资源，所以较慢
UDP 传送数据前不需要先建立连接

在这里插入图片描述

传输层为了连接进程，使用了端口协议号（PORT）来区分进程，为何不通过主机的进程号来区分呢？因为不同操作系统的进程号格式是不同的，而且进程在不断地动态变化，所以使用一个“逻辑进程号”即端口协议号就很重要。也就事说，IP地址是IP层（网络层）实现的。而端口是传输层实现的

在这里插入图片描述

UDP

udp只在ip数据报上增加了很少的功能，就是复用、分用、差错检测，UDP的主要特点：

无连接：发送数据前不需要连接，发送数据结束时不需要释放，减少了开始前的开销
尽最大努力交付：不需要维持复杂的链接状态表
面向报文：应用层给UDP多长报文，UDP加上首部就原封不同给IP层，如果太长，IP层回分片，降低了效率，如果太短，则IP首部占用数据包相对长度太高，也降低效率。
无拥塞控制：出现拥塞不会主动降低发送速率，但是这也提高了实时性。
支持一对多，多对一，多对多通信
首部开销小，仅8字节，而TCP有20字节

UDP首部格式

共4字段，每字段长度都为2字节：

源端口，不需要时为0
目的端口
长度，最小值是8，也就是用户数据长度可为0。
校验和，检验用户数据报是否有错，有就丢弃

在这里插入图片描述

校验和的计算需要在UDP用户数据报前加入伪首部，伪首部只参与UDP校验和的计算，不会被发送给IP层。UDP的校验是把首部和数据部分一起都校验。

校验流程：

在这里插入图片描述

可见，这样校验就可以既把UDP数据报校验，又把IP头部也校验了。

在这里插入图片描述

如果接收方收到报文后发现目的端口没有程序在用，就丢弃报文，并由ICMP发送”端口不可达“给发送方。

TCP

面向连接
只能一对一服务
全双工通信：TCP允许通信双方在任何时候发送数据，TCP两端都有发送缓存和接收缓存，临时存放双向通信的数据。应用程序把数据放到发送缓存后，就可以做自己的事，TCP会在合适的时机把数据发送出去。接受时TCP则会把数据放入缓存，上层应用在合适的时候读取缓存。
面向字节流：收发都像在读写FIFO，TCP并不关心应用一次写多少到缓存中，只是根据拥塞程度来决定一个报文段包含多少字节，而UDP则是应用程序来指定报文长度，这里只需要记住，应用就像写fifo一样写入tcp的缓存，它一次发多少会智能地根据网络环境来判断。如果fifo里的数据太少，TCP也可以等待积累足够多的数据后再构成报文发送这会导致延迟，所以UDP的低延迟就是这么来的，UDP是直接交付给IP层

TCP的连接

TCP把连接作为最基本的抽象。TCP的端点不是进程，也不是端口，而是套接字（socket）（端口号拼接到IP地址即构成套接字），也就是说TCP的端点其实间接地也是IP地址和端口，例如IP是192.168.137.10，端口是80，则套接字就是192.168.137.10：80，通信的两个端点各自又一个套接字。

在这里插入图片描述

可靠传输的工作原理：

1.停止等待协议（只是最简单的举例，实际网络传输不使用此协议）

在这里插入图片描述

不论A2B还是B2A出现问题，A都会进行超时重传，但是必须要有一个编号，否则如果B2A出了错，但其实B收到了，此时A重传，B则会重复接受数据，所以必须有数据编号，这样B才知道该不该接收数据。超时计时器的设置很困难，因为网络环境多变，可能导致网络延迟提高，重传的概率也会提高。这样会导致网络资源浪费，而且当网络延迟较大时，重传定时器必须设置较长，那数据发送之间的气泡就太大，严重降低发送速率。

在这里插入图片描述

这是另外的错误情况，分别为确认丢失（重复传送）和确认迟到（重复确认）。

通过以上的停止等待协议，就可以在不可靠的网络上实现可靠传输。这种思想将来可以用在一些不太需要速度的通信总线上，这种协议的重传是基于发送方自己的定时器，而不需要接收方请求，所以称为自动重传请求（ARQ Auto Repeat reQuest）。

在这里插入图片描述

从上图可看出，真正用于传输的黑色部分占总传输时间比例太少，所以该方式效率太低。信道利用率计算：

在这里插入图片描述

其中，TD为发送分组所需时间，等于分组长度/数据率，RTT为往返时间，TA为B从收到数据到发出确认的时间，一般很短，忽略不计。

在这里插入图片描述

RTT时间远长于TD，这就是导致低效的原因，这还没考虑差错重传，如果出差错则效率会进一步降低。为了提高效率，就不能用停止等待协议，而是应该用流水线传输。流水线传输可以连续发送多个分组而不停下来等确认，这可以使TD提高，又不至于让确认太稀疏使差错重传的负担太重。

2.连续ARQ协议

发送方不再停止等待，而是维持一个发送窗口。

在这里插入图片描述

改窗口内的数据分组会被连续依次发送出去，当每收到一个ack，就把发送窗口向前滑动一个分组的位置。接收方一般采用累计确认而不必每个分组都确认，如果收到几个分组后，发现这几个分组都没错，则发送最后一个分组的确认。这时发送方的窗口就会向前滑动多个分组。

优点：易实现
缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。例如发送方发送了5个分组，第3个丢失了。接收方对前两个进行了确认，发送方无法知道后面三个的下落，只好把后面三个都重传，这样使得重传的信息比停止等待协议还多，所以此时会导致效率降低。这叫做Go -Back-N(回退N)，所以通信链路质量不好时连续ARQ会带来负面影响。

3.TCP报文首部格式

在这里插入图片描述

源、目的端口
序号：4字节，共2^{32个序号，增加到2}32-1后变为0。TCP面向字节流，TCP的序号是对字节流中的每一个字节进行编号，整个字节流起始序号在连接建立时设置。序号字段指的是本报文段发送的数据的第一个字节的序号。
确认号：4字节，期望收到对方下一个报文段的第一个数据字节的序号，这个是接收方给发送方用的（由此可见TCP发送方和接收方采用同一套首部），代表下一次希望收到的数据的序号，总之应当记住若确认号=N，则：到序号N-1为止的所有数据已经正确收到，由于序号字段有32位长，可对4GBytes数据进行编号，所以可保证序号重复使用时旧序号的数据早已通过网络到达终点，不会导致混乱。
数据偏移：4位，用来指出tcp数据段的偏移地址，有这个字段的原因是因为TCP首部含有长度不确定的字段。数据偏移的单位是4字节，也就是说这4位最大能编码60字节的偏移，也即TCP首部最长60字节（选项字段长度不超过40字节）
保留：6位，0
控制位：
- 紧急URG（URGent）：当此字段为1，则表明该报文紧急，会被紧急传送不用排队（不用被扔进缓冲区等待），而且接收方也优先将该报文呈递给应用层，而不需要在缓冲区排队。发送方TCP会把紧急字段排在本报文最前段，而在紧急数据后面的数据仍然是普通数据，所以要配合紧急指针（Urgent Pointer）字段使用。
- 确认ACK：当为1，确认号才有效，否则确认号无效，TCP规定了连接建立后所有传送的报文段都必须把ACK置1.
- 推送PSH：有时应用希望将一个报文立即发送而不是扔进缓冲区等待，且接收方尽快的交付给应用而不需要等到缓冲区被填满再交付。（不太懂这个和紧急URG的区别）
- 复位RST：为1则表明TCP连接出现严重差错，例如主机崩溃，必须释放连接，然后重新连接。
- 同步SYN：连接建立时用来同步需要，当SYN=1，ACK=0时，表明这是一个连接请求报文段，若对方统一，则在响应报文段中使SYN=1，ACK=1，因此SYN为1表示请求连接或者接收连接。
- 终止FIN：释放连接，为1时表示此报文段的发送方数据已发送完毕，要求释放连接。
窗口：2字节，[0，2^16-1]，之间的整数，窗口指的是发送本报文段的一方的接收窗口而不是自己的发送窗口，窗口告诉对方，从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量（字节为单位），这表示了接收方缓存的健康程度。窗口值作为发送方设置其发送窗口大小的依据。所以说TCP就是利用了窗口这个参数来进行流量控制，控制双方发送数据的速度。例如发送一个报文段其确认号是701，窗口字段是1000，这就是告诉对方“从701开始算起，我接收缓存还可以接收1000个字节数据，你在发送时要考虑好”。总之，窗口字段明确指出允许发送方发送的数据量，窗口值根据接收缓冲区动态变化。所以lwip中只要把最大接收窗口和接收缓存开大，就能实现更高速的数据传输？
检验和：2字节。计算时要算上放在TCP报文段前面的12字节伪首部，与UDP不同的是，要把伪首部的第4个字段中的17改为6，把第5字段中的UDP长度改为TCP长度，接收方收到TCP报文段后，也要加上同样的伪首部来计算校验和。若使用IPV6，则响应伪首部也要改变。
紧急指针：2字节，URG=1时有意义。
选项：长度可变最长40字节，当没有“选项”时，TCP首部为固定20字节。TCP只规定了一种选项。即
- 最大报文段长度MSS Max Segment Size，MSS是每个TCP报文段中数据字段最大长度，MSS与接收窗口没关系，而与IP分片有关系，IP层会根据以太网MTU对数据报进行分片，接收方又需要进行合成，降低了效率，所以传输层给IP层的数据包不应使得IP分片产生，这便是MSS代表的作用，即告知对方我这边MSS最大多大，这样发送方就可以根据MSS来确定一次传多大数据包给IP层，从而不引发IP分片的产生，走每条网络路径可能有不同的MTU大小，所以MSS也会发生变化。如果不填写这一项，则默认MSS=536字节，所以所有在互联网上的主机都应该支持这一MSS，此时TCP报文段长度为536+20=556字节。
- 随着互联网发展，又加入了其他几个选项，例如“窗口扩大”，“时间戳”，“选择确认SACK”。
  - 窗口扩大：3字节，窗口字段本身为2字节，最大窗口为64K，对于RTT极高的大延迟网络，例如卫星通信，大窗口才能提高信道利用率。三个字节中一个表示位移值S，新的窗口位数从16增加到（16+S），移位值允许最大值是14，所以最大窗口是2^30-1即1GBytes。窗口扩大选项可以在双方初始建立TCP时进行协商，所以翻*墙时如果测速，速度会缓慢上升是因为延迟太高，为了提高效率，窗口在协商中慢慢扩大？
  - 时间戳：10字节，主要字段为时间戳字段和时间戳回送回答字段，各4字节，功能：
    - 用来计算RTT。
    - 处理TCP需要超过2^32情况（防止序号绕回）。高速网络中序号有可能绕回，为了使接收方把新的报文段和旧的报文段分开，可以加时间戳。
  - 确认选择SACK，若为1，则允许选择性的确认，一般不用

TCP可靠传输实现

为了讨论方便，假定数据单向通信。

1.以字节为单位的滑动窗口

TCP的滑动窗口以字节为单位，例如A收到B发来的确认报文段，其中窗口为20字节，确认号时31，则A构造的发送窗口如下图：

在这里插入图片描述

这时候A会把窗口内的数据连续依次传出去，凡是已经发送过的数据，未收到确认前都暂时保留，以便超时重传。A的发送窗口不能超过B的接收窗口。发送窗口后沿的后面表示已经收到确认的数据，不用再保留。前沿表示还未发送的。后沿变化情况有两种，不动和前移。后沿不可能后移。前沿有两种变化情况分别为不动和前移。当收到新确认且窗口缩小了，那可能会导致前沿正好不动。发送窗口也有小概率可能向后收缩，但是TCP标准强烈不赞成这样做，因为可能导致发送方收到这个通知前就已经发送了很多数据，然后又要收缩窗口不让发，就会导致很多错误。

在这里插入图片描述

上图表示了发送窗口的工作状态，假设A发送可31-41的数据，此时还没收到响应，所以窗口位置不变，而窗口靠前的42-50字节是允许发但是还没发的。所以可以看出，描述一个发送窗口需要三个指针：P1，P2和P3，指针指向字节序号。

P3-P1=发送窗口
P2-P1=已发送但尚未收到确认的字节数
P3-P2=允许发送但尚未发送的字节数

再看B接收窗口。B接收窗口大小为20，左侧到30为止是发送过确认的，并且已经交付给应用层了，因此B可以不再保留这些数据。接收窗口内的序号（31-50）是允许接收的，B收到了序号为32和33的数据，这些数据没有按序到达，因为31每收到，（可能丢了）。所以发送确认号仍是31.而不是32或33.

假设B收到了31，并把序号为31-33的数据交付主机，然后B删除了这些数据，接着把接收窗口向前移动过了三个序号。同时给A发确认，其中窗口值仍为20，但确认号是34.B还收到了些零三数据，但是没连续到达，只能暂存。A收到B确认后，就把发送窗口滑动3字节，但是指针P2不动，即指针P2是确认号的位置。

在这里插入图片描述

A继续发完42-53后，指针P2向前移动和P3重合。发送窗口内的序号都已用完，但还没再收到确认。由于A的发送窗口满，可用窗口减小到0，因此必须停止发送。

可能存在以下可能性：A发送完窗口内所有可发送的数据，但是B没收到。或者B的确认A一直每收到，那A在超时定时器超时后就会重新发送窗口内的数据，直到A收到确认，才向前滑动窗口。

2.超时重传时间选择

太短或者太长都会导致效率下降，那该如何选择？TCP的解决办法是自适应算法。它记录一个报文段发出的时间和收到确认的时间，时间差就是RTT，TCP保留RTT的一个加权平均往返时间RTTs，即平滑过的RTT，每当重新测量RTT，就重新计算。RFC6298推荐α值为1/8

在这里插入图片描述

超时重传时间（RTO）应该略大于RTTs，推荐算式：

在这里插入图片描述

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

在这里插入图片描述

测量RTT的办法：

测量RTT不能受到重传影响，如果B确认的是重传后的A的数据，那就会导致RTT偏大，则计算出的RTTs和RTO偏大，若后面数据又经过重传后才收到确认报文段，则按照此方法得出的RTO就会越来越长。所以Karn提出，计算RTTS时，如果A重传了，就不用这包数据来算。但是这样也引起新问题：若链路时延突然增大，因此在原来得出的重传时间内不会受到确认报文段。这样超时重传时间就无法更新。修正办法是每重传一次就把重传时间RTO增大一些，典型值为2倍，当不再发生重传时才根据上式继续计算。

3.确认选择SACK

若收到报文无差错，只是未按序号，中间缺少一些序号的数据，如何只传缺少数据？

在这里插入图片描述

如上图，1-1000收到了，1001-1500没收到等，要把这些信息告诉发送方，需要4个指针来指向边界，让发送方不要重复发送已收到的数据。

SACK没啥用，文档中也没指明发送方如何响应SACK，因此大多数重传还是重传所有未被确认的数据块，具体看如下截图：

在这里插入图片描述

TCP流量控制

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

在这里插入图片描述

考虑一种情况，B向A发送0窗口报文段不久，B的接收缓存又有了一些存储空间，于是B向A发送rwnd=400，然而这个报文段丢失了，A一直等待B发送非0窗口，B也一直等待A发送数据，如果没有其它措施，则会持续死锁。

为了解决这个问题，TCP有一个持续计时器，只要TCP连接一方收到对面0窗口通知，就启动计时器，若持续计时器设置的时间到期，就发送一个零窗口探测报文段，其仅携带1字节数据，该报文仅用来触发收方发送窗口大小报文。如果最终收到非0窗口报文，那就扩大窗口继续发送。

2.TCP的传输效率

理论上在MTU支持的情况下，MSS越长传输效率就越高。TCP的发送时机有以下三种方式确定：

缓存中数据达到MSS字节，就发出
应用程序指明要PSH，直接发出
开个定时器，时间到了就发出

糊涂窗口综合征：TCP接收方数据缓存满了，但是应用程序一词只读一个字节，导致发送窗口只有1字节，但是TCP+IP报文头就有40字节，所以一次就发送41字节数据，导致效率很低。解决这个问题可以让接收方慢点确认，比如在接收缓存有足够空间后再确认，以提高信道利用率。

拥塞控制

在这里插入图片描述

TCP拥塞控制算法有4种

慢开始
拥塞避免
快重传
快恢复

在继续讨论拥塞控制前，先假定

数据单向传输，对方只发送确认报文
接收方有足够大的缓存，发送窗口大小只由网络拥塞程度决定

1.慢开始和拥塞避免

基于窗口的拥塞控制：发送方维护一个拥塞窗口，发送方让自己的发送窗口等于拥塞窗口，最大不超过接收方接收窗口。发送窗口变化原则：拥塞了就减小，没拥塞就增大。如何知道拥塞？只要没按时收到确认报文，就算拥塞了。下面讨论拥塞窗口具体如何变化：

1.慢开始算法：

主机开始发时，不清楚网络情况，如果一下发太多，就可能引起拥塞，所以由小到大增大发送窗口，也就是由小到大增大拥塞窗口值。慢开始规定，每收到一个新的报文段的确认后，可以把拥塞窗口增加一个SMSS（发送方MSS）的大小。

例如一开始cwnd=1，于是发送M1，收到M1的确认后，cwnd=2，发送M2，M3。收到确认后，cwnd=4…循环往复。即每经过一次传输，拥塞窗口就加倍。

实际运行中，发送方只要收到一个确认（不必收到上次传输的所有确认），就会把拥塞窗口+1，发送窗口前的数据

为了防止cwnd过大引起拥塞，需要设置一个慢开始门限状态变量（ssthresh）。

cwnd<ssthresh 用慢开始算法
cwnd>ssthresh 用拥塞避免算法
cwnd=ssthresh 都可以

在这里插入图片描述

可见，拥塞避免就是把慢开始的指数增长变成了线性增长。来防止一次增长过快而造成拥塞。2时发生拥塞，会自动调整门限ssthresh=cwnd/2=12，同时让cwnd=1，重新进入慢开始。4点又出现了一连收到3个同一报文段的确认。这其实是网络没拥塞，只是丢包了，导致超时。让发送方误以为拥塞。如果这时候把cwnd设置为1，那效率就降低了。

采用快速重传算法可以让发送方尽可能早知道发生个别报文段丢失。快速重传要求接收方不可以捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。本来接收方发出M2确认后可以什么都不做，但是快速重传要求要重复发送M2确认，当发送方一连收到3个M2确认，就知道了接收方是丢包没收到。进行快重传，这样可以防止等待超时定时器。发送方也不会误以为出现网络拥塞（其实只是偶尔丢包）。使用快重传可以让整个网络吞吐量提高约20%。

在这里插入图片描述

4点中收到3-ack后，发送方就不会启动慢开始，而是直接启动快恢复。ssthresh=cwnd/2=8，且让拥塞窗口cwnd=8，直接开始执行拥塞避免算法。

在这里插入图片描述

2.主动队列管理AQM

在网络层也有拥塞控制，路由器缓存满了之后，会丢弃FIFO末端要进来的数据，导致连续有数据不被转发，这就很可能导致连续的分组丢失，从而导致发送方超时重传。而丢弃的是IP数据报，这些IP数据报可能包含很多个TCP连接，这就导致网络中大量的TCP连接都超时了，然后同时进入了慢开始，然后整个网络占用就会突然减少，又因为慢开始，网络占用又开始激增（这种现象叫全局同步）。解决办法是不要等队列满了再扔，而且要做一个早期的检测，早点主动丢弃分组。

TCP连接管理

TCP连接建立

在这里插入图片描述

A开始建立连接时，A发送的SYN包不包含数据，但是要消耗掉一个序号，此时发送端进入SYN-SENT（同步已发送）状态，B收到后，发送SYN和ACK，也不携带数据，但是消耗一个序号，此时接收端（服务器）进入,SYN-RCVD（同步收到），TCP客户端收到B确认后，发送ACK，这时可以携带数据，如果携带，那seq就要+1，如果不携带，那seq不变。此时A进入ESTABLISHED（已建立连接）状态

采用三次握手是为了防止因为网络原因B收到已经失效的报文而建立连接，这时候A可能已经不想连接了，而B会接受连接，浪费了B的主机资源