1. 传输层在协议栈中的位置与核心价值
1.1 为什么有了IP地址还不够
很多同学学到这周，心里都会有个疑问：IP协议已经能把数据包从一台机器送到另一台机器了，为什么还需要传输层？这个疑问其实问到了点子上，也恰恰是理解传输层价值的钥匙。
IP层解决的是“如何到达目的主机”的问题，它把数据包当作一个个独立的个体，只管把这些包从源地址送到目标地址。但送到之后呢？数据包到了服务器上，操作系统怎么知道该交给哪个应用？你在电脑上同时挂着微信、浏览器、邮件客户端，一个数据包飘过来，是微信的消息还是网页的内容？这就是传输层要解决的第一个问题——多路复用与分用。打个比方，IP层像是快递公司，只负责把包裹送到小区门口；传输层则是小区的分拣中心，要弄清楚每个包裹该送到哪一户、哪个人手上。而那一户一人的标识，就是端口号。
端口号是16位整数，范围是0到65535，其中0到1023是知名端口，比如HTTP用80、HTTPS用443、DNS用53；1024到49151是注册端口；49152到65535是动态或私有端口。而标识“哪台机器”的IP地址加上“哪个应用”的端口号，就构成了套接字（Socket），这才是网络编程里真正建立连接的端点。
如果你只用IP做通信，就好比寄快递只写到城市，不写具体地址，后果可想而知。所以传输层是应用数据进入网络的最后一层关卡，它不是可选项，而是必选项。
1.2 传输层解决的两类核心问题
传输层这一层，本质上只干两件事：一是上面说的端口寻址与分用，二是为应用提供不同的传输质量保证。
这里涉及两个核心协议——UDP和TCP，它们分别代表了两种极端策略。UDP（用户数据报协议）追求简单高效：不建立连接、不确认、不重传、不保证顺序，想发就发，发完拉倒。TCP（传输控制协议）则极度谨慎：先建立连接、逐包确认、丢了重传、乱序整理、流量控制、拥塞控制，全都要管。
这两兄弟的差异，说白了就是对“快”和“稳”的权衡取舍。UDP像发短信，发送完就结束，对方收没收到你不关心，但速度快、开销小；TCP像寄挂号信，每封信都有回执，没收到的会重新再寄，保证对方一定能收到，但过程繁琐、时间更长。
这一周讲“传输层（上）”，核心任务就是先把传输层的定位搞清楚，再深入理解TCP和UDP的设计哲学，然后把TCP的连接管理机制——三次握手、四次挥手，以及保证可靠传输的原理吃透。这些内容不光是考试重点，更是排查网络故障、设计高性能网络应用的底层功。
2. UDP与TCP的选型逻辑：没有好坏，只有合不合适
2.1 UDP：看似简陋，却是低延时的极致
很多人一说到UDP，总觉得它是个“低配版TCP”，什么都没有。这种看法其实低估了UDP。UDP的头部只有8个字节：源端口（2字节）、目的端口（2字节）、长度（2字节）、校验和（2字节）。相比之下，TCP头部最少也有20字节，带选项时甚至能到60字节。每多一字节的头部开销，在千万级并发的服务里，都是不可忽视的带宽消耗。
更重要的是，UDP没有连接建立和断开的流程。这意味着它没有三次握手的延迟，也没有四次挥手的等待时间。对于对延迟极度敏感的场景，UDP几乎是不二选择。举个例子，视频通话、在线直播、竞技类游戏，这类应用最怕的不是丢几个包，而是延迟太高。语音或画面卡顿半秒，体验就会大打折扣，而偶尔丢一个音视频帧，人眼和人耳几乎感知不到。再比如DNS查询，一个域名解析请求，全世界都用UDP发到53端口，响应速度极快，如果改用TCP做DNS，每次查询都要先握手，查询延迟至少增加一个RTT（往返时间）。
我们还可以做个简单的实验来感受UDP的轻量。用Python写一个最小的UDP服务端和客户端，整个过程不到二十行代码：
# udp_server.py import socket server = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) server.bind(('0.0.0.0', 9999)) print('UDP server listening on 9999') while True: data, addr = server.recvfrom(1024) print(f'received from {addr}: {data.decode()}') server.sendto(b'pong', addr)# udp_client.py import socket client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) client.sendto(b'ping', ('127.0.0.1', 9999)) data, _ = client.recvfrom(1024) print(f'received: {data.decode()}')注意UDP的Socket，用SOCK_DGRAM（数据报）类型，和TCP的SOCK_STREAM（字节流）类型完全不同。UDP保留消息边界，sendto一次发送的内容，recvfrom一次就能完整收回来，不会拆散。这是面向报文的特性。
2.2 TCP：复杂但可靠，用连接换取信任
TCP和UDP相反，它把可靠性放在第一位。TCP通过三次握手建立连接，通过序号和确认号保证数据按序到达，通过超时重传机制处理丢包，通过滑动窗口实现流量控制，通过拥塞控制算法避免网络过载。这一整套机制，都是在IP层这个“尽力而为”的网络上，硬生生搭建出一个可靠的传输通道。
这就好比在一条坑坑洼洼的土路上，TCP是那辆底盘高、带减震、每开一段就检查车轮的越野车，速度起不来，但车上货物一定安全。UDP则是那辆轻便的摩托车，路好路坏都敢冲，但货掉了它不管。
TCP的可靠性具体怎么体现？它给每个字节都编号。发送方每发一段数据，都知道这段数据是几号到几号；接收方每收到一段数据，都回一个确认号，告诉对方“我期望收到哪个号”。如果发送方等了一段时间没收到确认，就认为数据丢了（或确认丢了），于是重传。这种机制叫自动重传请求（ARQ），一个听着很学术的名词，思想却朴素到极点：没收到回执就再发一遍。
在实际应用选型时，绝大多数需要可靠传输的应用都跑在TCP上。HTTP/HTTPS、FTP、SMTP、SSH，无一例外。这些协议承载的是文字、文件、命令等绝对不容丢失的数据。你发一封邮件，如果中间丢了一个字变成病句，带来的后果可能远比延迟高严重，所以必须用TCP。
2.3 如何判断一个应用该选UDP还是TCP
我经常看到开发者在这个选择上犯难，其实判断标准可以归纳成三个问题。
第一个问题：数据丢了会影响用户体验吗？如果影响严重，比如文件传输、支付指令、数据库事务，选TCP；如果影响轻微甚至无感，比如语音帧、视频帧、游戏位置状态，可以考虑UDP。
第二个问题：延迟和可靠性，哪个更重要？这是核心矛盾。实时交互类场景，如在线会议、远程驾驶，延迟一旦过高，整个操作就会失控，优先考虑UDP；而离线或异步场景，比如日志上报、邮件投递，晚几秒甚至几十秒都能接受，那当然要TCP保底。
第三个问题：你能接受应用层自己去处理乱序和丢包吗？如果选UDP，那就意味着可靠性要自己在应用层实现：自己设计确认机制、自己管理重传、自己处理乱序。QUIC协议就是UDP之上做了这一整套可靠传输工作，效果很好，但工程量巨大。没有这个开发实力和需求，老老实实用TCP是更明智的选择。
下面的对比表把两者的关键差异列清楚，方便参考：
| 对比项 | UDP | TCP |
|---|---|---|
| 连接状态 | 无连接 | 面向连接 |
| 头部大小 | 8字节 | 最少20字节 |
| 可靠性 | 不可靠，不确认不重传 | 可靠，确认与重传 |
| 有序性 | 不保证 | 保证 |
| 传输模式 | 面向报文 | 面向字节流 |
| 速度 | 快，低延迟 | 相对慢，开销大 |
| 典型场景 | 直播、游戏、DNS、VoIP | HTTP、FTP、SMTP、SSH |
3. 三次握手并不是聊天的客套：TCP连接建立的真相
3.1 为什么恰好是三次而不是两次或四次
TCP三次握手可能是整个计算机网络课程里知名度最高的知识点，但很多同学只知道“客户端发SYN、服务器回SYN+ACK、客户端回ACK”这个流程，却不知道每一手背后到底解决什么问题，更不知道为什么必须是三次。
先说结论：三次握手的核心目的，是让双方确认彼此的收发能力都正常，并同步初始序号。为什么需要确认收发能力？因为TCP建立在不可靠的IP网络上，数据包可能延迟、丢失、重复。如果连接建立阶段不确认彼此的收发能力，通信开始后就会乱套。
拿为什么不能两次来举例。假设只有两次握手：客户端发SYN，服务器回SYN+ACK，连接就算建立。这时候，如果客户端发出的SYN因为网络延迟，没有第一时间到达服务器，而是在网络中“漂”了一段时间后重试，再次发送SYN并完成两次握手，建立了一个连接。通信结束后，第一条迟到的SYN才被服务器收到，服务器又回了SYN+ACK，认为新连接建立了。但此时客户端根本不在等待，这个由服务器单方面确认的连接，就成了一个挂在服务器上的僵尸连接，白白占着资源。
三次握手就不会出现这个问题，因为连接建立的最终确认权在客户端。客户端收到服务器回的SYN+ACK，再回一个ACK，连接才真正建立。如果客户端没有发起新的连接请求，它就不会回应迟到的SYN+ACK，服务器自然也不会建立这个连接。
3.2 从状态变化看不为人知的细节
三次握手的完整过程，从状态机角度看会更加直观。我用简化伪代码来描述客户端和服务器各自的运行过程：
客户端： 1. 发送 SYN (seq=x)，状态置为 SYN_SENT 2. 收到 SYN+ACK (seq=y, ack=x+1)， 状态置为 ESTABLISHED 3. 发送 ACK (ack=y+1)， 完成握手，进入数据通信阶段 服务器： 1. 监听端口，状态为 LISTEN 2. 收到 SYN，发送 SYN+ACK (seq=y, ack=x+1)， 状态置为 SYN_RCVD 3. 收到 ACK (ack=y+1)， 状态置为 ESTABLISHED 连接建立，放入全连接队列这段话里的seq和ack是最容易被忽略但最能考察理解深度的点。客户端发送SYN时携带初始序号x，服务器收到这个SYN，向客户端回SYN+ACK时，ack=x+1意味着“我已经收到你序号为x的包，下一个该发x+1了”。而服务器自己的初始序号是y，客户端回ACK时，ack=y+1就是告诉服务器“你那个y序号的我收到了，下一个该是y+1”。
这个序号机制决定了，TCP里的每个包都不是孤立存在的，它们都是有编号的连续序列。网络中常见的乱序、重复、丢包，都是通过序号体系判断和修正的。
实际排查中，我们要留意半连接队列和全连接队列的概念。服务器收到SYN后处于SYN_RCVD状态，此时连接是在半连接队列里的；收到客户端的ACK后，连接移入全连接队列（accept队列），等待应用调用accept()。如果应用处理慢，全连接队列满了，新的连接就可能被丢弃，表现为客户端能收到SYN+ACK，但发完最后的ACK后迟迟等不到数据。这个坑我在线上排查过不止一次，后面会单独展开。
3.3 用抓包工具亲眼看看握手过程
再多的文字描述，不如用抓包工具亲眼看一遍TCP握手来得直观。强烈建议在学习这一阶段时，打开Wireshark做一次真实的抓包观察。
先用nginx或Python搭一个最简单的HTTP服务，然后在客户端用curl访问一下，抓包命令大致如下：
# 在服务器上启动一个临时HTTP服务，监听8080端口 python3 -m http.server 8080 # 在客户端发起请求 curl http://<服务器IP>:8080Wireshark过滤表达式用tcp.port == 8080，然后就能看到三条连接包。第一次抓包的人往往会惊讶：原来一条HTTP请求，在传输层真的会先走一遍完整的SYN、SYN+ACK、ACK。这几个包的间隔通常只有零点几毫秒，几乎感知不到，但确实存在。
这个案例特别适合和浏览器“开发者工具”里的网络面板对照来看。你在浏览器里发出的每个请求，背后都有若干条TCP连接在支撑。HTTP/1.1时代浏览器会建立多个连接并行下载资源，HTTP/2利用一条TCP连接上的多路复用减少连接次数。这些上层表现，在传输层都有对应变化。
4. 四次挥手与TIME_WAIT：连接关闭才是重灾区
4.1 为什么关闭连接需要四次
如果说三次握手是TCP里的明星知识点，四次挥手就是真正的“实践重灾区”。原因很简单：握手是单向确认，挥手却涉及双向的数据关闭，且最后还要留一个长达2MSL的时间段给操作系统收尾。
先说为什么是四次。TCP是全双工通信，数据的收发是两条独立的通道。连接关闭时，双方都必须各自关闭自己的发送方向，所以完整过程是：主动关闭方先发FIN，表示“我这边数据已经发完了，但我还能收”；被动关闭方收到FIN后，如果自己还有数据要发，就先只回ACK，表示“我收到了，但我还有数据，等我发完”；被动方发完数据，再发自己的FIN，表示“我也发完了，现在可以关了”；主动方最后回一个ACK，完成关闭。这个过程中的四次报文，前两次关闭主动方的发送通道，后两次关闭被动方的发送通道，各有各的职责，缺一不可。
还有一个经常出现的问题：FIN和ACK能不能合并？三次挥手行不行？答案是如果被动方在收到FIN时确实没有数据要发了，它可以把ACK和FIN合并在同一个包里发出去，这时从报文数量上看是三次挥手。这并不违规，TCP是允许这种合并的。所以判断挥手是不是完整，不要死记包的数量，要看四个标志位和状态变化是否完整走完。
4.2 TIME_WAIT的真正作用与隐患
四次挥手里最值得拿出单独一段讲的状态是TIME_WAIT。主动关闭方在发出最后一个ACK之后，会进入TIME_WAIT状态，保持2MSL（报文最大生存时间）后才彻底关闭。2MSL在Linux上默认是60秒。
TIME_WAIT的意义有两个，一个是要确保最后一个ACK能到达对方。如果这最后一个ACK丢了，被动方会重发FIN，主动方在TIME_WAIT期间还能回应。如果直接关闭了，被动方重发的FIN就无人接应，被动方认为连接没关干净，可能导致端口被占用或者连接状态异常。
另一个意义是为了让旧连接的延迟报文在网络中自然消失。假设某个端口立马被复用，旧连接里延迟到达的包，可能被新连接误认为是自己的数据，造成数据错乱。2MSL这个时间窗口，足以保证一个报文发出后经过最长时间仍能被确认或消散，避免新旧连接串包。
TIME_WAIT多了好不好？分情况。服务器主动关闭连接时，会产生大量TIME_WAIT。这些连接占据着本地端口，短时间内无法复用。如果连接数是百万级，TIME_WAIT数量爆炸，新的连接就无法分配端口，表现为连接建立失败。解决思路有几种：开启net.ipv4.tcp_tw_reuse允许复用TIME_WAIT状态的连接（需要配合时间戳选项）；调整tcp_max_tw_buckets上限；更根本的是从业务层规避服务器主动关闭，比如让客户端来关闭连接。但tcp_tw_recycle这个选项在NAT环境下会有严重副作用，不建议开启，这也是很多老调优文章没提到的坑。
4.3 挥手过程中常见的异常场景
实际运维中，四次挥手出问题的场景远比握手多。最常见的是半关闭状态：一方发了FIN，另一方不回应，或者回应了ACK但不发FIN。这种状态常见于客户端崩溃或网络闪断后。如果程序里没有做超时探测，连接会一直挂着，占用服务器文件描述符和内存，日积月累就是连接泄漏。
另一种是拒绝关闭。很多服务端框架默认开启了TCP的SO_LINGER选项，或者因为业务原因，收到客户端的FIN后不想继续维护这个连接，直接发送RST（重置连接）。这时客户端会看到“Connection reset by peer”的错误。这个现象我们在排查线上接口异常时经常碰到，通常并不是网络问题，而是服务端应用层在主动断开连接。
排查挥手问题的方法，同样可以通过抓包来实现。如果看到FIN发出去后只有回包ACK，没有对方FIN，重点查看服务端是否还有未处理完的业务数据；如果出现RST，则优先检查应用层是否主动重置了连接。
5. 可靠传输与滑动窗口：TCP性能的底层密码
5.1 从停止等待到连续ARQ
在理解TCP的可靠传输机制时，我建议先从一个最简单的模型看起：停止等待协议。发送方发一个包，等收到确认后再发下一个。简单可靠，但效率极低。假设网络往返时延是100毫秒，每一个包的传输，都要等待这100毫秒，一个链路实际利用率可能连1%都不到。相当于快递每次只送一件货，送到之后还要空车回来再拉下一件，效率可想而知。
所以TCP用了流水线式的处理方式，在同一时间发送多个包，然后就等着接收方的确认。这种方式叫连续ARQ协议。发送方不需要每发一个包就停下来等待，可以连续发多个包，接收方也不需要一个一个回确认，可以累积确认。比如接收方按顺序收到了第1、2、3、4号包，它不需要给每个包单独回一个ACK，只需要在收到第4号包时回一个“期望收到第5号包”的ACK，发送方就知道前4个包全部安全抵达了。
这种累积确认极大减少了确认包的数量，但代价是排查问题的粒度变粗了。如果第2号包丢了，接收方连续收到第3、4、5号包，它会不停重复回“期望收到第2号包”的ACK。发送方收到三个重复ACK，就知道第2号包丢了，触发快速重传，不等超时计时器到期就重新发送第2号包。这个机制在实际中非常有用，因为它能把恢复时间从一个RTT压缩到几乎瞬间完成。
5.2 滑动窗口是如何提升吞吐量的
滑动窗口是TCP性能的核心机制，它是发送方在不等待确认的前提下，允许发送的未确认字节数上限。窗口越大，发送方就能在等待一个确认的时间里发出更多数据，链路利用率越高。
这里有一个关键公式需要理解：吞吐量 ≈ 窗口大小 / RTT。假如窗口是64KB，RTT是100毫秒，那么理论吞吐量就是640KB/秒，大约5Mbps。你明明有100Mbps的带宽，但就是因为窗口太小，实际吞吐量被卡在5Mbps，这就能解释为什么TCP窗口调优对性能影响如此巨大。
窗口大小不是静态的。接收方会在自己的ACK里携带窗口通告字段，告诉发送方“我的接收缓冲区还剩多少空间”。如果接收方的应用读数据的速度慢了，接收缓冲区快满了，它就在窗口通告里写个小数值，发送方看到后就会主动放慢节奏。这个机制叫流量控制。它防止的是发送方把接收方的缓冲区撑爆，保护的是接收端，属于端到端的范畴。
而TCP的拥塞控制是另一套机制，它不是保护接收方，而是保护整个网络。拥塞控制的判断依据是网络中是否发生了丢包或延迟增加。经典算法包括慢启动、拥塞避免、快重传、快恢复。慢启动是指连接刚建立时，拥塞窗口从一个很小的值开始指数增长；到阈值后转为线性增长，这就是拥塞避免；发生丢包则把窗口砍下来，然后重新增长。这个机制的背后逻辑很简单：TCP没法直接探测网络容量，只能通过丢包这个信号来“试错”，缓慢试探网络的极限。
5.3 带宽延迟积：高性能TCP调优的必修概念
说到窗口大小，就不能不提带宽延迟积（BDP）。这个概念很多初学者会忽略，但做网络性能调优时至关重要。
带宽延迟积 = 带宽 × RTT。它的含义是：在数据刚从发送端出发到确认返回发送端的这段时间里，网络管道里能够容纳的最大数据量。要让TCP跑满带宽，窗口大小至少不能小于带宽延迟积，否则发送方总是处于“发出去的数据还没攒够一批确认，就得等”的空闲状态。
举个例子。假设带宽是10Mbps，RTT是200毫秒，BDP = 10Mbps × 0.2秒 = 2Mb = 250KB。如果TCP窗口只有64KB，链路最多只能利用25%左右。这就是很多高带宽远距离传输业务中，即使带宽充裕、延迟不高，吞吐量却上不去的根本原因。
解决这个问题，在Linux上可以通过调整内核参数来增大TCP接收/发送缓冲区上限，应用里再配合setsockopt调整SO_RCVBUF、SO_SNDBUF。但注意，盲目调大窗口也可能加剧网络拥塞，所以需要结合带宽延迟积和实际拥塞状况来权衡。
6. line协议传输层的另一个视角：本地总线中的“传输层”
6.1 LIN总线与计算机网络传输层的类比
有同学可能会好奇，热搜词里的“lin总线协议传输层”是什么东西。LIN（Local Interconnect Network）总线是汽车电子里的一种低成本串行通信协议，广泛用在天窗、车窗、座椅调节、雨刮器等对带宽要求不高的车身控制模块上。它有自己的分层结构，其中也有类似于“传输层”的机制，负责数据的分包和重组。
这和本文讨论的TCP/IP传输层有异曲同工之妙。LIN的传输层主要用于传输超过单帧承载能力的数据，比如诊断报文、软件升级数据包。它会把长数据拆成多个帧发送，接收端再重新组装。这不就是TCP里的分段与重组吗？
在TCP/IP里，如果应用层的数据块太大，TCP会自动将其切分成适合网络传输的报文段；接收端再根据序号重组成完整数据。LIN的传输层做的也是这个事情，只是它面对的总线速率很低，通常是20kbps，数据帧也很短，必须靠传输层做好分包调度。底层原理互通，换一个物理介质，逻辑完全复用，这也是学习网络协议时要有的迁移能力。
6.2 不同“传输层”之间的设计取舍启示
如果把LIN总线的传输层和TCP放在一起比较，会发现两者的设计取舍完全不同。LIN追求极致的简单和低成本，它的传输层只用在一小类特殊场景（主要是诊断和升级），日常控制报文根本不需要分包，所以传输层的实现极其精简。而TCP则把所有能做的可靠性机制都做齐了，因为它面对的是不可预测的广域网环境，任何丢失、乱序、拥塞都可能发生。
这让我们有两点启示。第一，协议设计没有绝对的标准答案，一切选择都取决于对场景需求的理解。低速车载总线要控制成本，就不必照搬互联网整套拥塞控制；互联网要应对复杂网络环境，就不可能学LIN那样简单粗暴发完就算。第二，理解“传输层”的本质，比死记协议名称重要得多。只要存在“发送端拆分、接收端重组、保证按序交付”的需求，就会有传输层的影子。在学完TCP/UDP之后，你会发现自己能更快读懂各类协议文档，因为协议栈分层的顶层逻辑是共通的。
7. 学到这里，值得动手验证的几个小实验
7.1 用Python观察TCP半包与粘包
前面讲TCP是面向字节流的协议，这意味着它没有消息边界。应用层发送两次独立的send，接收方可能会在同一个recv里收到两段数据，也可能只受到其中一段，这个现象被称为粘包/半包问题。很多Java、Go的开发者写网络服务时都踩过这个坑。
用Python做一个演示实验，代码很简单：
# tcp_server.py import socket server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind(('0.0.0.0', 8888)) server.listen(5) print('TCP server listening on 8888') conn, addr = server.accept() print(f'connection from {addr}') # 尝试一次接收两块应用消息 data = conn.recv(2048) print(f'received once, {len(data)} bytes') print(data)# tcp_client.py import socket import time client = socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.connect(('127.0.0.1', 8888)) # 连续发送两条应用消息，中间不延迟 client.send(b'hello ') client.send(b'world') time.sleep(1) client.close()运行之后，服务端很可能在两个send都到达之后才打印出一整条b'hello world'，这正是字节流协议下最常见的现象。处理思路是在应用层自行定义消息边界，比如固定消息长度、以特殊分隔符切割，或者采用TLV（Type-Length-Value）格式。这个实验做一次，比看十遍概念都管用。
7.2 用Wireshark验证流量控制与窗口变化
如果你想亲眼看到流量控制是如何起作用的，可以做一个更进阶的实验。在本地局域网内搭一个简单的TCP文件传输服务，然后在对端用tc命令模拟网络延迟和带宽限制。比如：
# 在服务端添加100ms延迟和5Mbps带宽限制 tc qdisc add dev eth0 root netem delay 100ms tc qdisc add dev eth0 root tbf rate 5mbit burst 32kbit latency 400ms然后启动一个大文件传输，在Wireshark中观察TCP段的窗口字段和吞吐量变化。你会看到在带宽受限的情况下，发送窗口会逐渐调整，吞吐量向理论值靠拢。如果把接收端的应用暂停不读数据，抓包时还会看到接收方通告的窗口值逐步下降，最终变为0。这一瞬间，发送方会停止发包，等窗口重新打开。这就是流量控制的完整闭环，用抓包软件能看到最直观的现象。
7.3 一个建议的学习路径
这周的内容只覆盖了传输层的上半部分，重点在定位、协议选型、连接管理与可靠传输。下一周通常会进入拥塞控制的进阶细节，还会讲到QUIC这类基于UDP的现代传输协议。我的建议是，学习时不要只盯课本概念，每一个机制都尽量做一次小实验去验证。验证三次握手用Wireshark抓一次包；验证粘包问题用Python跑一个mini服务；验证流量控制就模拟延迟和限速。把这些实验做下来，传输层就不再是抽象的卷面知识，而会成为你排查问题时脑海里能直接浮现出来的“图像”。
我个人在实际操作中深有体会的一点是：传输层知识在应用层编码时未必直观可见，但当线上出现超时、连接被重置、吞吐量上不去的故障时，脑子里有这套协议知识的人，和没有的人，排查速度完全不是一个量级。网络问题很少是表面那一层代码的问题，往往隐藏在传输层的状态和参数里。把这周的知识啃扎实，后续的学习和实战都会顺畅很多。
