北航计网课程笔记-五、传输层
第五章 传输层
传输层概述
传输层是只有主机才有的层次。
功能:
-
提供进程和进程之间的逻辑通信。
网络层提供主机之间的逻辑通信。
-
复用和分用。
- 复用:发送方不同的应用进程都可以使用同一个传输层协议传送数据
- 分用:传输层在剥去报文的首部后能把这些数据正确交付到目的应用进程
-
传输层对收到的报文进行差错检测。
- TCP发现报文段出错,则要求重发
- UDP发现报文段出错,则直接丢弃
网络层中IP数据报首部的检验字段只检验首部是否出错,不检查数据部分。
-
提供面向连接和无连接的传输协议
网络层无法同时实现两种协议,要么只提供面向连接服务(虚电路),要么只提供无连接服务(数据报)。
端口
端口是传输层的SAP,标识主机中的应用进程。
端口号长度为16bit,能表示65536个不同的端口号。
需要记下来的:(?
在网络中采用发送方和接受方的套接字组合来识别端点。
套接字
端口号拼接到IP地址即构成套接字。
套接字唯一标识了网络中的一个主机和它上面的一个进程。
在网络中使用发送方和接收方的套接字来识别端点。

无连接服务和面向连接服务
TCP协议
主要特点
- 传送数据之前必须建立连接,数据传送结束后要释放连接。
- 可靠,面向连接(虚连接),时延大,适用于大文件。
- 提供可靠交付的服务,无差错、不丢失、不重复、按序到达
- 不提供广播或多播服务
- TCP提供全双工通信。
TCP报文段首部格式

-
序号seq:在一个TCP连接中传送的字节流中的每一个字节都按顺序编号,本字段表示本报文段所发送数据的第一个字节的序号
-
确认号ack:期望收到对方下一个报文段的第一个数据字节的序号。
若确认号为N,则证明到字节序号为N-1为止的所有数据都已经正确收到。
比如已经收到了1 2 3,接收方发送给发送方的报文中,确认号是4,表示期待下一个收到序号为4的字节。
-
数据偏移:TCP报文段的数据起始处距离TCP报文段的长度。
以4B为单位。
实际上就是TCP首部的长度/4B。
-
6个控制位:
- 紧急位URG:URG = 1时表示报文段中有高优先级的数据,可以插队发送。
- 确认位ACK:ACK=1时确认号字段ack才有效;在连接建立后所有传送的报文段都必须把ACK置为1。
- 推送位PSH:PSH =1时接收方尽快交付接受进程,不用等到缓存填满。
- 复位RST:RST=1时表示TCP连接中出现严重差错,必须释放、重新建立传输链接。
- 同步位SYN:SYN = 1时,表示是一个连接请求/请求接受报文。
- 终止位FIN:FIN = 1时,表示此报文段发送方数据已经发完,要求释放连接。
-
窗口:发送本报文段一方的接受窗口,即现在允许对方发送的数据量
-
检验和:检验首部+数据,检验时要加上12B伪首部,第四个字段为6。
-
紧急指针:URG=1时才有意义,指出本报文段中紧急数据的字节数(长度)。
-
选项:最大报文长度MSS、窗口扩大、时间戳等等。
-
填充:保证长度为4B的整数倍。
TCP的连接管理
TCP连接的建立采用客户服务器方式:主动发起连接建立的应用进程叫客户,被动等待连接建立的叫服务器。
连接建立:三次握手
TCP规定,SYN报文段不能携带数据,但是要消耗掉一个序号。
不同的TCP连接不能使用相同的初始序号:避免新的连接中传送旧链接中滞留的部分。
如果第三个阶段不携带数据,则不消耗序号,下一个数据报文段的序号仍然是

连接释放:四次挥手
TCP规定,FIN报文段即使不携带数据,也要消耗掉一个序号。
释放连接的请求两边都可以发出。
释放连接的最短时间:

TCP的可靠传输
可靠:保证接收方进程从缓存区读出的字节流和发送方发出的字节流是完全一样的。
实现可靠传输的机制:
-
校验:同UDP校验
-
序号:给每个字节编上序号
-
确认:发送方发送一个报文后,缓存中的报文段不会马上消失(避免传输时丢失);
直到接收方返回一个确认报文段时,发送方才删除缓存中的报文段。
接收方可能传输数据,同时捎带确认。
确认报文段有确认号字段ack。
TCP的确认是对报文段的,不是对字节/分组的。
TCP默认使用累计确认:
例如收到1,2,3,7,8;4,5,6丢失,则返回的确认报文段中,确认号字段仍然为4。
-
重传:TCP的发送方在规定时间内没有收到确认,就要重传已经发送的报文段。
重传时间的规定:TCP采用自适应算法,动态改变重传时间RTTs(加权平均往返时间)。
-
冗余ACK:冗余确认
每当比期望序号大的失序报文段到达时,发送一个冗余ACK,指明下一个期待字节的序号。
发送方已发送1,2,3,4,5;2丢失;
接收方收到1,返回给1的确认(ack=2)
接收方收到3,返回给1的确认(ack=2)
接收方收到4,仍然返回给1的确认(ack=2)
接收方收到5,仍然返回给1的确认(ack=2)
发送方收到3个对于报文段1的冗余ACK:认为报文段2丢失,重传2号报文段。
-
TCP的流量控制
流量控制:让发送方慢点,让接收方来得及接受。
TCP使用滑动窗口机制实现流量控制。
接收方根据自己接受缓存的大小,动态调整发送方发送窗口的大小。
发送方的发送窗口 =
传输层的窗口大小以字节为单位,而不是报文段。
TCP的拥塞控制
出现拥塞:对资源需求的总和>可用资源
拥塞控制:防止过多的数据注入网络之中。(全局性)
这里假设接收方总有足够大的缓存空间,发送窗口大小取决于拥塞程度。
慢开始和拥塞避免
- 前期:指数规律增长(收到之前报文的确认,马上翻倍)
- 达到ssthresh的初始值(慢开始门限):从慢开始进入拥塞避免,线性增长。
- 出现网络拥塞:把ssthresh设为当前cwnd的一半。拥塞窗口降为1。
- cwnd单位:MSS,一个最大报文段长度
- 注意:在慢开始阶段,如果当前2cwnd>ssthresh,则下一个RTT后的cwnd等于ssthresh,而不是2cwnd,如图中第16~第17轮次。
快重传和快恢复
- 让发送方尽早开始重传,而不是等到计时器超时再重传
- 接收方不是在自己发送数据时才捎带确认,而是立即发送确认
- 即使收到了失序报文段也对已收到报文段进行重复确认
- 发送方连续收到3个冗余ACK时,执行“乘法减小”
例题–TCP
注意报文段均得到确认后

第13次传输时:第12次确认之后

?这对吗
冗余ACK:快重传、快恢复。


发送窗口要看拥塞窗口&接收窗口。

UDP协议
主要特点
-
在IP层数据报服务上仅增加:复用和分用,差错检测。
实现分用时依据的首部字段是
目的端口号
-
不需要建立连接,收到UDP报文后也不需要给出任何确认。
-
不可靠,无连接,时延小,适用于小文件。
使用UDP的网络应用,其数据可靠性由应用层负责。
-
面向报文,适合一次性传输少量数据的网络应用。
-
无拥塞控制,适合实时应用。
-
首部开销小,只有8B(TCP有20B)
UDP首部格式:

应用层给UDP多长的报文,UDP就照样发送,即一次发一个完整报文。
UDP校验
伪首部:模仿IP首部,只在计算校验和时出现。

在发送端:
- 填上伪首部
- 全0填充检验和字段
- 全0填充数据部分
- 伪首部+首部+数据部分采用二进制反码求和
- 把和求反码填入检验和字段
- 去掉伪首部,发送
在接收端:
- 填上伪首部
- 为首部+首部+数据部分采用二进制反码求和
- 结果全为1则没有差错,否则丢弃数据报/交给应用层并附上差错警告。
-
如果检验处UDP数据报是错误的,则可以丢弃,也可以交付给上层,但是需要附上凑无报告
-
通过伪首部,可以检查源端口号、目的端口号、UDP、数据报的数据部分,还可以检查IP数据报的源IP地址和目的IP地址。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
· 上周热点回顾(2.17-2.23)