提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

提示：这里可以添加本文要记录的大概内容：

传输层协议是计算机网络体系中的核心协议之一，位于OSI模型的第四层，主要负责端到端的数据传输控制。其核心功能包括数据分段、流量控制、差错校验和连接管理。常见的传输层协议主要有TCP和UDP，两者在可靠性、效率和适用场景上存在显著差异。

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、TCP协议介绍

TCP/IP协议族的传输层协议

1. TCP（可靠的老大哥）

特点：

面向连接：必须先“握手”建立连接（类似打电话要先拨通）。

可靠传输：数据丢了会重传（类似快递丢了会补发）。

流量控制：根据接收方的能力调整发送速度（类似快递站根据仓库容量调整收件量）。

2. UDP（随性的小弟）

特点：

无连接：直接发数据，不握手（类似发短信，不用等对方接电话）。

不可靠：数据可能丢失（类似明信片，丢了不补发）。

速度快：适合实时应用（视频、语音、游戏）。

二、TCP报文格式

可以把TCP报文段想象成一封快递包裹，里面装着你要传输的数据。这个包裹有详细的“快递单”（TCP头部），确保数据能准确、可靠地送到对方手里。以下是关键字段的通俗解释：

1.快递收发人信息（端口号）

源端口号（16位）：

→ 你的“发货人编号”（比如你的电脑上微信用的端口号是54321）。

目标端口号（16位）：

→ 对方的“收货人编号”（比如微信服务器的端口号是80或443）。

类比：就像快递单上写的“寄件人电话”和“收件人电话”。

2.包裹编号与签收确认（序号和确认号）

序号（32位）：

→ 给数据字节编号，比如发送的第1个字节编号是100，第二个是101，依此类推。

→ 作用：防止数据乱序或丢失（类似给书页标页码）。

确认号（32位）：

→ 告诉对方“我已经收到第N号之前的数据，下次请发第N号开始的”。

→ 比如：确认号=150表示“我已收到1~149，请发150开始的”。

类比：快递员送货时，你检查包裹编号并签字确认：“包裹1、2已收到，请送包裹3”。

3.控制标志位（包裹的特殊要求）

URG：紧急数据（比如快递包裹上贴“加急”标签）。

ACK：确认有效（相当于“我已收到你的消息”）。

PSH：催促对方立刻处理（类似“尽快拆包”）。

RST：强制断开连接（突然拒收包裹，终止交易）。

SYN：发起连接请求（“你好，我要寄快递”）。

FIN：礼貌结束连接（“我的包裹发完了，再见”）。

记忆口诀：

URGENT加急，ACK要确认，PSH快处理，RST断连接，SYN打招呼，FIN说再见。

4.流量控制与纠错（窗口和校验和）

窗口大小（16位）：

→ 告诉对方“我的仓库还能放多少包裹”（接收缓冲区剩余空间）。

→ 比如：窗口=5000表示“你最多再发5000字节给我”。

校验和（16位）：

→ 检查包裹是否损坏（计算数据完整性，发现错误就丢弃）。

类比：仓库管理员说：“我这还能放5箱货，发多了放不下！”（流量控制），同时检查包裹是否破损（校验和）。

5.其他字段

紧急指针（16位）：

→ 配合URG标志，标记紧急数据的位置（比如“包裹里第50字节是重要文件”）。

选项（可变长度）：

→ 特殊需求（比如协商最大报文段长度MSS）。

6.总结：TCP报文段像一份智能快递

端口号：告诉快递员送给谁。

序号/确认号：确保所有包裹按顺序签收。

控制标志：处理加急、签收、终止等操作。

窗口大小：防止对方“爆仓”。

校验和：防止包裹损坏。

关键点：TCP通过这种精细设计，实现了可靠传输——数据不乱、不丢、不重复，适合重要文件传输（如网页、邮件）。而UDP则像“扔明信片”，不管对方收没收到，适合直播、游戏等实时场景。

官方

源端口号:发送方进程的端口号。

目标端口号:接收端进程的端口号。接收端收到数据段后，根据这个端口号来确定把数据送给哪个应用程序的进程。

序号:发送端为每个字节进行编号，便于接收端正确重组。

当TCP从进程接收数据字节时，把它们分片成数据段存储在发送缓存中，并对每一个字节进行编号。当数据到达目的地后，接收端会按照这个序号把数据重新排列，保证数据的正确性。

确认号:对发送端的确认信息。

接收端响应消息时将会用它来告诉发送端这个序号之前的数据段都已经收到，如确认号是x，就是表示前X-1个数据段都已经收到。

首部长度:用它可以确定TCP首部数据结构的字节长度。一般情况下TCP首部是20字节，但首部长度最大可以扩展为60字节。

控制位:

URG:紧急位。紧急指针有效位。

ACK: 确认位。只有当ACK=1时，确认序列号字段才有效:当ACK=0时，确认号字段无效。

PSH:急迫位。标志位为1时，要求接收方尽快将数据段送达应用层。

RST:重置位。当RST值为1时，通知重新建立TCP连接。

SYN: 同步(连接)位。同步序号位，TCP需要建立连接时将这个值设为1。

FIN: 断开位。当TCP完成数据传输需要断开连接时，提出断开连接的一方将这个值设为1.

窗口大小:说明本地可接收数据段的数目。这个值的大小是可变的，当网络通畅时接收端响应消息会将这个窗口值变大以加快传输速度，当网络不稳定时减小这个值可保证网络数据的可靠传输，TCP中的流量控制机制就是依靠变化窗口的大小实现的。

比如下载速度从一开始的几KB逐渐提升到几MB的过程。

校验和:用来做差错控制。字段检验的范围包括首部和数据这两部分。数据段在发送时和到达目的地时会进行校验和计算，若这两次的校验和一致，则说明数据基本是正确的，否则将认为该数据已被破坏，接收端将丢弃该数据。

紧急指针:和URG配合使用，当URG=1时有效。

选项:在TCP首部可以有多达40字节的可选信息。例如，最大报文段长度MSS (Maximum Segment Size)。

MSS告诉对方

TCP:“我的缓存所能接收的报文段的数据字段的最大长度是MSS个字节。”

三、TCP 三次握手（建立连接）

1. 客户端 → 服务器：“我要连接！”（SYN=1）

2. 服务器 → 客户端：“好的，你准备好了吗？”（SYN=1, ACK=1）

3. 客户端 → 服务器：“准备好了，开始传数据！”（ACK=1）

讲解三次握手的过程

tcp是面向连接的，就是说每次发送数据之前都要和对方建立一条可靠的连接，这个建立连接的过程分为3个步骤，就叫做三次握手。

① 当客户端向服务器发送请求连接的报文时：

Seq序列号=x（x为随机）

SYN=1（表示发送连接请求）

② 服务器端收到客户端发来的请求报文后，同意建立连接，则向客户端发送确认报文：

Seq序列号=y（这时服务器也会产生一个序列号y，和客户端的序号不相关）

Ack确认号=x+1（Seq序列号x+1，表示确认收到了客户端的请求）

ACK=1（表示这是条确认请求）

SYN=1（同时也发送一个建立连接的请求）

③ 客户端进程收到服务端进程的确认后，还要向服务端给出确认，然后连接成功建立：

Seq序列号=x+1（这时客户端的序号为1）

Ack确认号=y+1（表示确认收到了服务器的连接请求）

ACK=1（表示这是确认报文）

打开wireshark，本机连接虚拟机，选择捕获vmnet1网卡否则消息太多，选择tcp协议，观察tcp三次握手的报文。

四、TCP 四次挥手（断开连接）

1. A → B：“我说完了”（FIN=1）

2. B → A：“好的，等我发完剩下的”（ACK=1）

3. B → A：“我也说完了”（FIN=1）

4. A → B：“拜拜！”（ACK=1）

讲解四次挥手的过程（可以用客户端向服务器端请求一个网页举例）

某个应用进程首先调用close，称该端执行“主动关闭”（active close）。该端的TCP于是发送一个FIN分节，表示数据发送完毕。

接收到这个FIN的对端执行 “被动关闭”（passive close），这个FIN由TCP确认。

一段时间后，接收到这个文件结束符的应用进程将调用close关闭它的套接字。这导致它的TCP也发送一个FIN。

接收这个最终FIN的原发送端TCP（即执行主动关闭的那一端）确认这个FIN。

1.第一次挥手：

Client发送Fin + Acknowledgement 给Server端，表示自己要断开连接，这个时候

Client端已经没有数据要发送了。

2.第二次挥手：

Server接收到Client发送的断开请求连接，那么这个时候Server需要发送一个Acknowledgement=1用于确定客户请求断开的信息成功接收了；有时候这个过程也会和第三次握手进行合并，就像上面展示的一样。

3.第三次挥手：

Server如果所有的数据已经接收完毕，这个时候就会发送一个Fin=1，而Acknowledgement=0用于表示Server端已经没有数据要发送了，需要关闭连接。

4.第四次挥手：

Client端需要发送一个Acknowledgement = 1表示这个Client接收到了Server的关闭请求信息，这样一来双方的就都关闭了。

在四次挥手中有一个半关闭的概念，我们如何理解在 TCP 断开连接过程中，有一个半关闭的概念。TCP 一方（通常是客户端）可以终止发送数据，但仍然可以接收数据，称为半关闭

当仅完成两次挥手之后，服务端能否给客户端发送数据呢？

答案是可以。从两个方向去理解

思考：

1、为什么是四次挥手不是三次挥手？

因为当服务端还有数据没有传完的情况

2、谁可以中断连接？客户端还是服务端还是都可以？

都可以中断连接

其实在最后一步客户端收到服务端的ACK之后实际上是不会立马关闭连接的，它进入了TIME_WAIT状态，为什么不立即关闭？

为了这种情况： B向A发送 FIN = 1 的释放连接请求，但这个报文丢失了， A没有接到不会发送确认信息，B 超时会重传，这时A在 WAIT_TIME 还能够接收到这个请求，这时再回复一个确认就行了。（A收到 FIN =1 的请求后 WAIT_TIME会重新记时）

另外服务器B存在一个保活状态，即如果A突然故障死机了，那B那边的连接资源什么时候能释放呢？  就是保活时间到了后，B会发送探测信息， 以决定是否释放连接。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假想网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

5.常见 TCP 应用

网页（HTTP/HTTPS，端口 80/443）

文件传输（FTP，端口 21 ）

邮件（SMTP，端口 25）

远程登录（TELNET，23）

邮件的接收（POP3 110）

dns–域名服务 （53）

mysql数据库 （3306）

五、UDP协议介绍（随性的小弟）

1.无连接：

直接发数据，不握手（类似发短信，不用等对方接电话）。

2.不可靠：

数据可能丢失（类似明信片，丢了不补发）。

3.速度快：

适合实时应用（视频、语音、游戏）。

4.常见 UDP 应用

DNS 查询（端口 53）

视频通话（Zoom、微信通话）

在线游戏（王者荣耀、吃鸡）

六、常见的udp协议端口号

NTP--网络时间协议 123

DHCP--动态主机配置协议 67

SNMP--简单网络管理协议161

TFTP--简单文件传输协议 69

RPC--远程调用协议 111

七、TCP与UDP的不同

1. 连接方式

TCP：像打电话

→ 先拨号（三次握手），确认对方在线才开始聊，挂断时还要说再见（四次挥手）。

UDP：像发微信消息

→ 直接发，不管对方收没收到，也不等回复。

2. 可靠性

TCP：强迫症快递员

→ 必须签收确认，丢件必重发，包裹按顺序送到。

UDP：随性派送员

→ 包裹扔门口就走，丢了不管，顺序乱了不整理。

3. 速度与效率

TCP：稳但慢

→ 因为要确认、排队、重发，像高铁安检——安全但耗时。

UDP：快但可能丢

→ 像外卖小哥跑着送餐，快但汤可能洒。

4. 适用场景

用TCP：

✅ 重要文件传输（如合同、软件安装包）

✅ 需要长连接的服务（如网页、远程登录）

用UDP：

✅ 实时性优先（如视频通话、吃鸡游戏）

✅ 少量数据查询（如DNS解析）

一句话总结

TCP：可靠的老管家，适合细心活。

UDP：麻利的小哥，适合急活儿。

附：日常类比

官方总结

UDP和TCP协议的主要区别是两者在如何实现信息的可靠传递方面不同：

TCP 是面向连接的传输控制协议；而UDP 提供了无连接的数据报服务。

TCP 具有高可靠性，确保传输数据的正确性，不出现丢失或乱序；UDP 在传输数据前不建立连接，不对数据报进行检查与修改，无须等待对方的应答，所以会出现分组丢失、重复、乱序，应用程序需要负责传输可靠性方面的所有工作。

UDP 具有较好的实时性，工作效率较 TCP 协议高。UDP 段结构比 TCP 的段结构简单，因此网络开销也小。

TCP 协议可以保证接收端毫无差错地接收到发送端发出的字节流，为应用程序提供可靠的通信服务。对可靠性要求高的通信系统往往使用 TCP 传输数据。

TCP 协议传输更加稳定可靠，UDP 协议传输效率更高。这两个协议各有特点，在实际应用 中，根据实际应用的需要，选择不同的传输层协议。

---

总结

提示：这里对文章进行总结：

实际例子：

访问百度：

1. DNS（UDP） 查询 “www.baidu.com” 的 IP。

2. TCP 三次握手 建立连接。

3. HTTP（TCP） 请求网页数据。

4. TCP 四次挥手 断开连接。