本篇博客是考研期间学习王道课程传送门的笔记，以及一整年里对 计算机网络 知识点的理解的总结。希望对新一届的计算机考研人提供帮助！！！
关于对 “传输层” 章节知识点总结的十分全面，涵括了《计算机网络》课程里的全部要点（本人来来回回过了三遍视频），其中还陆陆续续补充了许多内容，所以读者可以相信本篇博客对于考研计算机网络 “传输层” 章节知识点的正确性与全面性；但如果还有自主命题的学校，还需额外读者自行再观看对应学校的自主命题材料。

食用说明书：
第一遍学习王道课程时，我的笔记只有标题和截图，后来复习发现看只看图片，并不能很快的了解截图中要重点表达的知识点。
在第二遍复习中，我给每一张截图中标记了重点，以及每张图片上方总结了该图片 对应的知识点 以及自己的思考。
最后第三遍，查漏补缺。
所以，我把目录放在博客的前面，就是希望读者可以结合目录结构去更好的学习知识点，之后冲刺复习阶段脑海里可以浮现出该知识结构，做到对每一个知识点熟稔于心！
请读者放心！目录展示的知识点结构是十分合理的，可以放心使用该结构去记忆学习！
注意(⊙o⊙)！，每张图片上面的文字，都是该图对应的知识点总结，方便读者更快理解图片内容。

《计算机网络》第5章传输层

【考纲内容】

(一) 传输层提供的服务

网课耗时：0.5 h

传输层的功能
传输层寻址与端口
无连接服务和面向连接服务

(二) UDP

网课耗时：0.5 h

UDP数据报
UDP校验

(三) TCP

网课耗时：1.5 h

TCP段
TCP连接管理
TCP可靠传输
TCP流量控制与拥塞控制

【复习提示】

传输层是整个网络体系结构中的关键层次；

要求掌握传输层在计算机网络中的地位、功能、工作方式及原理等，掌握UDP 及 TCP(如首部格式、可靠传输、流量控制、拥塞控制、连接管理等)；

其中，TCP 报文分析、流量控制与拥塞控制机制，出选择题、综合题的概率均较大，因此要将其工作原理透彻掌握，以便能在具体的题目中灵活运用；

5.1 传输层提供的服务

5.1.1 传输层的功能

传输层的地位：为应用层提高通信服务，使用网络层的服务（面向通信的最高处，用户功能的最底层）；

传输层的功能：

传输层提供进程和进程之间的逻辑通信；
逻辑通信的意思是传输层之间的通信好像是水平的传输数据，但实际上传输层之间没有直接的物理连接；

复用和分用
复用：发送方不同的应用进程都可以使用同一个传输层的协议传输数据；
网络层的复用是指发送方不同协议的数据都可以封装成IP数据报发送出去；
网络层的分用是指接收方的网络层在剥夺首部后把数据交付给相应的协议；

分用：接受方传输层在剥除报文的首部后，能够把数据分别交给对应目的进程；

传输层对收到的报文（首部和数据部分）进行差错检测（网络层只对首部进行检查）；
传输层的两种协议 (TCP 和 UDP) （网络层无法同时实现两种协议）；

在这里插入图片描述

5.1.2 传输层的寻址与端口

端口的作用：

对于应用层，让其应用进程能够通过端口把数据向下交付给传输层；
对于传输层，让其将报文段的数据通过端口向上交付给应用层的对应进程；

两种端口：

软件端口：应用层的各种协议进程于传输实体进行层间交互的一种地址；
硬件端口：不同硬件设备进行交互的接口；

在这里插入图片描述

网络层的 IP 分组中包含 IP地址，用来找到目的主机。传输层的 UDP/TCP，借助端口号进一步找到目的主机的进程；

IP地址来区分主机，端口号来区分进程。

将 IP地址 + 端口号就构成 ==套接字，==用来唯一地标识网络中的一台主机及其上的一个应用进程；

在这里插入图片描述

5.1.3 无连接服务和面向连接服务

在这里插入图片描述

5.2 UDP协议

5.2.1 UDP 数据报

在这里插入图片描述

UDP协议出错情况：

UDP数据报出错（首部或数据部分任何一个出错，直接丢弃）；
UDP数据报找不到目的端口号（丢弃 + 打小报告 ICMP）；

由于 UDP 的功能较少，对应的首部字段也较短；

UDP = 首部字段 (8B) + 数据字段 (可以为0) ；

在这里插入图片描述

5.2.1 UDP 校验

伪首部，模仿IP数据报首部；

举例说明 UDP校验过程

在这里插入图片描述

5.3 TCP协议 ⭐

5.3.1 TCP 协议的特点

在这里插入图片描述

举例说明无结构的字节流的含义

在这里插入图片描述

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AQCmimYR-1677589193976)(《计算机网络》第5章传输层.assets/image-20220902202120655.png)]

5.3.2 TCP 报文段

在这里插入图片描述

下图中的 6个控制位，图中标红的为重点；

紧急位 URG 是针对发送方，让其优先发送；

推送位 PSH 是针对接收方，让其快点向上交付；

同步位 SYN 建立连接时发送的请求/连接接收报文中使用；

终止位 FIN 发送完毕，要求释放连接；

在这里插入图片描述

5.3.3 TCP 连接管理

TCP的连接传输很像打电话的过程，可以细细体会；

建立连接的 ==三次握手：==我要来了 - 你来吧 - 我来了

在这里插入图片描述

	SYN	seq	ACK	ack
ROUND 1	1	x (随机)
ROUND 2	1	y (随机)	1	x+1
ROUND 3	0	x+1	1	y+1

在这里插入图片描述

【课外小知识】

黑客攻击问题 - SYN洪泛攻击

黑客：我要来了

服务器：好的，你来吧……

服务器：好的，你来吧……

……服务器死机

解决办法：设置 SYN cookie，具体自信了解

在这里插入图片描述

TCP的连接释放 - 四次握手

男：我要回去了；

女：好的，你记得……；

女：欧克，你走吧；

男：好的；

在这里插入图片描述

为什么要等待 2MSL 时间？

答：若第四次握手发送的确认报文段没有传输到服务器B，B就会自动重发第三次握手的确认释放报文，来回占用2MSL；

在这里插入图片描述

	FIN	seq	ACK	ack
ROUND 1	1	u
ROUND 2		v	1	u+1
ROUND 3	1	w	1	u+1
ROUND 4		u+1	1	w+1

在这里插入图片描述

5.3.4 TCP 可靠传输

在这里插入图片描述

1.校验

参考UDP小节内容；

2. 序号机制

要传输的文件会被排序编号，一个字节占一个序号；

TCP在传输时以报文段为单位，报文段占几个字节不一；

在这里插入图片描述

3. 确认机制

TCP发送的报文段也许会丢失，所以发送方的TCP缓存还会留有已发送的报文段数据，直到收到接收方的确认报文段；

接收方采用累积确认/捎带确认的方式发出确认信息；

发送方收到确认信息，会将已经确认的报文段删除；

在这里插入图片描述

4. 重传机制

确认机制和重传机制是密切相关的，规定时间未确认就需要重传；

TCP采用自适应算法，动态改变重传时间RTTs；

在这里插入图片描述

冗余 ACK

多次收到同一个确认号的报文段；

在这里插入图片描述

5.3.5 TCP 流量控制 ⭐

在OSI参考模型中，数据链路层、网络层、传输层都具有流量控制功能，

数据链路层是相邻结点之间的流量控制，
网络层是整个网络中的流量控制，
传输层是端到端的流量控制。

流量控制：采用滑动窗口来控制发送方的传输速度；

两个重要窗口：接收窗口rwnd 和拥塞窗口cwnd ；

发送窗口 = Min {接收窗口 rwnd，拥塞窗口 cwnd}；

在这里插入图片描述

举例说明 TCP 流量控制过程

发送窗口只有收到确认才能删除旧数据，添加新数据发送；

在这里插入图片描述

5.3.6 TCP 拥塞控制 ⭐

1. 拥塞控制的概念

拥塞就是马桶堵了，需求太多，资源不足；

在这里插入图片描述

2. 拥塞控制四种算法

在这里插入图片描述

慢开始组合拥塞避免

cwnd默认为1

在这里插入图片描述

快重传组合快恢复

在这里插入图片描述

5.4 常见问题和易混淆知识点

1. MSS设置得太大或太小会有什么影响？

规定最大报文段MSS的大小并不是考虑到接收方的缓存可能放不下TCP报文段。

实际上，MSS 与接收窗口没有关系。

TCP 的报文段的数据部分，至少要加上40B的首部（TCP首部至少20B和IP首部至少20B)，才能组装成一个IP数据报。

若选择较小的MSS值，网络的利用率就很低。

设想在极端情况下，当TCP报文段中只含有1B的数据时，在P层传输的数据报的开销至少有40B。

这样，网络的利用率就不会超过1/41。到了数据链路层还要加上一些开销，网络的利用率进一步降低。

但反过来，若TCP报文段很长，那么在IP层传输时有可能要分解成多个短数据报片，在终端还要把收到的各数据报片装配成原来的TCP 报文段。传输有差错时，还要进行重传。这些都会使开销增大。

因此，MSS应尽量大一些，只要在IP层传输时不要再分片就行。

由于P数据报所经历的路径是动态变化的，在一条路径上确定的不需要分片的MSS，如果改走另一条路径，就可能需要进行分片。

因此，最佳的MSS是很难确定的。

MSS 的默认值为536B，因此在因特网上的所有主机都能接收的报文段长度是 536+20（xTCP固定首部长度）= 556B。

2. 为何不采用“三次握手"释放连接，且发送最后一次握手报文后要务待2MSE的时间呢？

原因有两个：

1）保证A发送的最后一个确认报文段能够到达B。

如果A不等待2MSL，若A返回的最后确认报文段丢失，则B不能进入正常关闭状态，而A此时已经关闭，也不可能再重传。

2）防止出现 “已失效的连接请求报文段”。

A在发送最后一个确认报文段后，再经过2MSL可保证本连接持续的时间内所产生的所有报文段从网络中消失。造成错误的情形与下文（疑难点6）不采用 “两次握手” 建立连接所述的情形相同。

注意：服务器结束TCP连接的时间要比客户机早一些，因为客户机最后要等待2MSL后才可进入CLOSED状态。

3. 如何判定此确认报文段是对原来的报文段的确认，还是对重传的报文段的确认？

由于对于一个重传报文的确认来说，很难分辨它是原报文的确认还是重传报文的确认，

使用修正的Karn 算法作为规则：

在计算平均往返时间RTT时，只要报文段重传了，就不采用其往返时间样本，且报文段每重传一次，就把 RTO增大一些。

4. TCP使用的是GBN 还是选择重传？

这是一个有必要弄清的问题。

前面讲过，TCP使用累积确认，这看起来像是GBN 的风格。

但是，正确收到但失序的报文并不会丢弃，而是缓存起来，并且发送冗余 ACK指明期望收到的下一个报文段，这是TCP方式和GBN 的显著区别。

例如，A发送了N个报文段，其中第 k（k < N）个报文段丢失，其余 N - 1 个报文段正确地按序到达接收方B。

使用GBN时，A需要重传分组 k，及所有后继分组 k+1，k+2，…，N。

相反，TCP却至多重传一个报文段，即报文段k。

另外，TCP中提供一个SACK（Selective ACK）选项，即选择确认选项。

使用选择确认选项时，TCP看起来就和SR非常相似。因此，TCP 的差错恢复机制可视为 GBN 和 SR 协议的混合体。

5. 为什么超时时间发生时cwnd被置为1，而收到3个冗余ACK时cwnd减半？

大家可以从如下角度考虑：

超时事件发生和收到3个冗余ACK，哪个意味着网络拥塞程度更严重？

通过分析不难发现，在收到3个冗余ACK 的情况下，网络虽然拥塞，但至少还有ACK报文段能被正确交付。

而当超时发生时，说明网络可能已经拥塞得连ACK报文段都传输不了，发送方只能等待超时后重传数据。

因此，超时事件发生时，网络拥塞更严重，那么发送方就应该最大限度地抑制数据发送量，所以cwnd置为1；

收到3个冗余ACK时，网络拥塞不是很严重，发送方稍微抑制一下发送的数据量即可，所以 cwnd减半。

6. 为什么不采用“两次握手”建立连接呢？

这主要是为了防止两次握手情况下已失效的连接请求报文段突然又传送到服务器而产生错误。

考虑下面这种情况：

客户A向服务器B发出TCP 连接请求，第一个连接请求报文在网络的某个结点长时间滞留，A超时后认为报文丢失，于是再重传一次连接请求，B收到后建立连接。

数据传输完毕后双方断开连接。

而此时，前一个滞留在网络中的连接请求到达服务器B，而B认为A又发来连接请求，此时若使用 “三次握手”，则B向A返回确认报文段，由于是一个失效的请求，因此A不予理睬，建立连接失败。

若采用的是 “两次握手”，则这种情况下B认为传输连接已经建立，并一直等待A传输数据，而A此时并无连接请求，因此不予理睬，这样就造成了B的资源白白浪费。

7. 是否 TCP和UDP都需要计算往返时间RTT ？

往返时间RTT仅对传输层TCP协议才很重要，因为TCP·要根据RTT的值来设置超时计时器的超时时间。

UDP没有确认和重传机制，因此RTT对UDP没有什么意义。

因此，不能笼统地说 “往返时间RTT对传输层来说很重要”，因为只有TCP才需要计算RTT，而UDP不需要计算RTT。

8. 为什么TCP在建立连接时不能每次都选择相同的、固定的初始序号？

1）假定主机A和B频繁地建立连接，传送一些TCP报文段后，再释放连接，然后又不断地建立新的连接、传送报文段和释放连接。

2）假定每次建立连接时，主机A都选择相同的、固定的初始序号，如选择1。

3）假定主机A发出的某些TCP报文段在网络中会滞留较长时间，以致主机A超时重传这些TCP报文段。

4）假定有一些在网络中滞留时间较长的TCP报文段最后终于到达主机B，但这时传送该报文段的那个连接早已释放，而在到达主机B时的TCP连接是一条新的TCP连接。

这样，工作在新的TCP连接的主机B就有可能会接收在旧的连接传送的、已无意义的、过时的TCP报文段（因为这个TCP报文段的序号有可能正好处在当前新连接所用的序号范围之中），结果产生错误。

因此，必须使得迟到的TCP报文段的序号不处在新连接所用的序号范围之中。

这样，TCP在建立新的连接时所选择的初始序号一定要和前面的一些连接所用过的序号不同。

因此，不同的TCP连接不能使用相同的初始序号。

9. 假定在一个互联网中，所有链路的传输都不出现差错，所有结点也都不会发生故障。
试问在这种情况下，TCP的“可靠交付”的功能是否就是多余的？

答：不是多余的。TCP的 “可靠交付” 功能在互联网中起着至关重要的作用。

至少在以下的情况下，TCP的 “可靠交付” 功能是必不可少的。

1）每个IP数据报独立地选择路由，因此在到达目的主机时有可能出现失序。

2）由于路由选择的计算出现错误，导致IP数据报在互联网中转圈。

最后数据报首部中的生存时间（TTL）的数值下降到零。这个数据报在中途就被丢失。

3）某个路由器突然出现很大的通信量，以致路由器来不及处理到达的数据报。因此有的数据报被丢弃。

以上列举的问题表明：必须依靠TCP的 “可靠交付” 功能才能保证在目的主机的目的进程中接收到正确的报文。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aBF2W8mq-1677589193988)(《计算机网络》第5章传输层.assets/《计算机网络》第5章传输层.png)]