计算机网络传输层核心：TCP/UDP、可靠传输与拥塞控制全解析

啃《计算机网络：自顶向下方法（第七版）》第三章的过程，比我预想中漫长得多。读第一遍的时候，我一度觉得这章全是概念：UDP、TCP、可靠数据传输、拥塞控制……名词一个接一个。但真正做题、抓包、回头重读之后才意识到，前两章你还在"看地图"，第三章才是真正"上路"——你要理解数据从进程的套接字出发，经过网络到底经历了什么，以及在丢失、出错、乱序这一堆烂摊子面前，协议是怎么一件件收拾干净的。

这篇是系列学习分享的第二篇，默认你至少翻过前两章，知道套接字和分组大概是什么。如果你连网络分层都还没概念，建议先回去扫一遍第一章，否则多路复用那关容易卡住。不过别怕，我会尽量把每个机制背后的"为什么"讲透，而不是只给你一堆要背的结论。这篇内容主要面向三类人：准备408考研的自学者、正在期末复习的计算机专业学生，以及想把TCP/IP原理理顺的初学者。读完之后，你至少能自己做出一道带序号计算的三次握手题目，能说清GBN和SR的根本区别，也能看懂教材里那张著名的TCP状态转换图。

1. 第三章到底在讲什么：一张全局地图

1.1 传输层的定位：两端进程之间的"端到端承诺"

从分层模型来看，网络层负责把分组从一台主机送到另一台主机，它解决的是"主机到主机"的连通性。但真正收发数据的不是主机，而是主机里一个个进程。传输层就是在这条主机之间的管道上，再开一扇门，把数据交付给正确的进程。这个"多了一层身份识别"的过程，就是多路复用与多路分解。

说的直白一点：网络层是快递干线，传输层是最后一公里的门牌号投递。快递到了小区（主机），还得知道是哪一户（进程）的包裹。门牌号就是端口号。教材用"四元组"标识一条TCP连接：源IP、源端口、目的IP、目的端口。写代码时候你跟某台服务器的某个端口建立连接，这四元组就唯一确定了一条连接。这也是为什么同一台服务器上的同一个端口可以同时服务成千上万个客户端——每个客户端的四元组不同，连接就不会串。

很多人会在这里犯迷糊：UDP的套接字用的是二元组（目的IP、目的端口），也就是说只要目的IP和端口一样，不管源是谁，都会送到同一个进程。这对DNS这类"一问一答"的场景没有问题；但TCP必须用四元组，因为TCP连接是有状态的，服务器需要区分不同客户端的报文段，才能维护各自的发送缓冲区、接收缓冲区和序号。理解了这一点，后面看TCP连接管理就不会晕。

1.2 第三章的章节地图：一条从理论到工程的主线

教材第三章的编排顺序挺有意思，不是直接上来讲TCP，而是先从"当一个网络什么都不可靠时，怎么设计一个可靠传输协议"这个纯理论问题入手。这就是rdt（可靠数据传输协议）那一大节——1.0版完全可靠，2.0版考虑比特差错，2.1版增加序号，2.2版用冗余ACK替代NAK，3.0版再考虑丢包，引入定时器。

为什么教材要花这么大力气讲这些看起来"不实用"的协议？因为TCP本质上就是这些理论的工程实现。你搞懂了rdt为什么需要序号、为什么需要定时器、为什么需要流水线，TCP头部的那些字段就不再是死记硬背的字母了，而是你带着问题去验证的答案。我身边很多同学直接跳着看TCP，结果seq和ack怎么用、为什么有快速重传、为什么接收窗口和拥塞窗口是两个窗口，全都一团浆糊。真正把rdt这节啃下来的人，后面三节基本一路畅通。

这一章的后半部分分别是UDP、TCP报文段结构、可靠数据传输、流量控制、连接管理，最后是拥塞控制。拥塞控制单独讲，是因为它和流量控制解决的问题完全不同，一个是"接收方吃不消"，一个是"网络中间设备顶不住"。这两个概念是考研和期末的高频考点，也最容易混淆，后面我会专门展开。

2. 多路复用、多路分解与UDP：那些看着简单暗藏杀机的点

2.1 多路复用与多路分解：端口号和套接字的关系

传输层把各进程的数据块加上首部封装成报文段，这一操作叫多路复用；接收端检查首部的端口号，把报文段交付给对应套接字，叫多路分解。端口号是16比特的，范围0到65535，其中0到1023是周知端口，各种标准服务都占用这里，比如HTTP用的80、HTTPS用的443，DNS用的53。

有个细节经常被忽略：UDP的套接字标识是二元组，而TCP是四元组。这就带来一个实际后果——UDP服务器如果收到两个不同IP发来的数据，因为目的IP和目的端口相同，它们会进入同一个套接字；TCP服务器则必须为每个新的客户端连接建立新的套接字，区分依据就是四元组。面试题里喜欢问"一个TCP连接占用一个socket吗"，答案其实没那么简单，但如果你从四元组的角度去理解，就会清楚很多：每个独特的四元组对应一个连接套接字，而服务器还有一个"欢迎套接字"专门监听新连接。

做题的时候常会遇到"某个UDP服务器端口被两个客户端同时访问会怎样"之类的题目。按照二元组的规则，这两个客户端的数据会先由操作系统根据目的端口号分解到同一个UDP套接字，套接字再从缓冲区里读数据，至于这是一次recvfrom收一个还是多个客户端的数据，就要看具体的并发模型了。教材在这块多停了一两页，别看它简略，考点密度不低。

2.2 UDP首部与校验和：怎么用二进制反码求和

UDP首部固定8个字节：源端口2字节、目的端口2字节、长度2字节、校验和2字节。这里的"长度"是指UDP首部加数据的总长度，所以最小值是8，表示只有首部没有数据。校验和的算法是：把UDP首部、数据部分、还有伪首部一起按16比特的字段切分，每位做二进制反码求和，最后结果取反写入校验和字段。接收方收到后重新做一遍同样的计算，如果整个结果的二进制反码和是全1（实际判断是求和结果取反后为0），就认为没有出错。

讲个具体的简化例子。假设你要校验三个16比特的字段：1000000100000101、0000010100000110、初始校验和为0。两两相加时如果最高位有进位，要回卷加到最低位（这是"反码和"的要点），最终得到的和取反码就是校验和。教材里头有个生动比喻：校验和检测的是比特翻转，它不像加密散列那样能防恶意篡改，只能提供"尽力而为"的差错检测。所以UDP虽然叫不可靠传输，但它也能发现数据被改坏了，然后把坏包扔掉——请注意，丢弃不等于可靠传输，可靠传输要求的是"确认、重传、保证有序交付"，UDP统统没有。

几乎所有考试都会问"UDP能保证无差错吗"。答案是：它只能检测部分差错，不能修复、不能重传，所以谈不上保证。另外还有一个常见陷阱：校验和的计算部分包括伪首部，它包含源IP、目的IP、UDP长度和协议号，这样做的目的是防止IP层把一个本来发给A主机的段误送到B主机。这个设计初看奇怪，实际上非常精巧。

2.3 UDP的应用场景与常见误区

我经常跟人讲，不要把UDP当成一个"减肥版TCP"。UDP的价值恰恰在于它的"极简"——没有连接建立，也就没有握手延迟；没有拥塞控制，也就不会因为网络拥塞而自动降速；首部开销小，应用层可以自己控制数据发送速率。流媒体直播、实时语音、游戏同步、DNS查询，这类场景要么对时延敏感，要么允许丢包后由应用层自己做补偿，UDP反而比TCP更合适。

很多计算机网络期末题会拿"UDP比TCP安全吗"来设坑。老实的答案是：UDP没有状态伪装、握手序列可预测之类的攻击面，但也因为无连接，更容易被伪造源地址。教材不会讨论这么深，考研一般也不会追问到安全层面，但你心里要有个数，免得面试被问住。

还要注意一个很容易看错的地方：UDP的"无拥塞控制"不等于"网络不会拥塞"。恰恰是因为UDP不感知拥塞，如果大量UDP流量涌进网络，反而会把TCP流量挤垮。这就是拥塞控制和多路分解在现实中交织的案例。这个话题在后面第四章也会有呼应。

3. 可靠数据传输原理：从零推导一个TCP

3.1 rdt家族进化史：为什么每一步都"不得不"这么做

rdt这一节，教材用了大量状态图，很多初学者看着看着就弃了。我建议换个方式：假装你自己是设计者，就站在发送方的位置上，被人要求"把一段数据可靠地送到对面"，你会怎么做？

一开始假设链路是完全可靠的，不用做任何应对差错的动作——这就是rdt1.0，在教材里只是热身。接着，冒出第一个问题：数据可能在传输中翻转比特，你怎么知道对面收到了什么？最简单的办法是让对方回一个明确表示"我收到的是对还是错"的消息，这就是ACK和NAK，于是rdt2.0出现了。但2.0有个致命伤：ACK和NAK本身也可能损坏。这就逼着你给数据分组加序号——只有0和1就够了，因为停等协议里同一时刻最多只有一个未确认分组——这就是rdt2.1。再往前走一步，既然序号能解决ACK损坏，那NAK其实也可以不要：收到损坏的包，就回一个"上一个正确分组的ACK"（冗余ACK），让发送方自己去琢磨怎么重传。这就是rdt2.2，为后面TCP的快速重传埋下了伏笔。

这一路推下来，你会发现每一个状态都是被前一个漏洞逼出来的。读教材的时候如果哪一步看不懂，就回头看上一步"到底哪里出了问题"。

3.2 rdt3.0与效率困境：停等协议的致命伤

rdt3.0解决的最后一个理论问题是丢包。数据在传输途中可能彻底消失，既没有出错反馈，也没有任何提示。解决方式是用定时器：发送方发出数据后启动计时，超过一定时间没收到ACK就重传。这样做看似简单，却带出了两个新问题：第一，超时时间设多少？太短会狂重传，太长会白白等待。教材说这个时间必须大于RTT，但RTT是会波动的，所以到了TCP章节才用EstimatedRTT和DevRTT来动态估算，这是上下两节呼应的重点。第二，如果只是偶尔超时还好，但rdt3.0是停等协议，意味着每发一个包都要等ACK回来才发下一个，信道利用率低得吓人。

教材给了个经典计算：设链路速率R=1Gbps，分组长度L=1000字节，也就是8000比特，那么一个分组的传输时延L/R=8微秒；若RTT=30毫秒，停等协议的利用率就是传输时延除以传输时延加RTT，算出来约0.027%。换句话说，这条链路绝大部分时间都在等，数据根本没跑起来。看到这个数字你就明白，为什么必须引入流水线，也就是"不用停等，让多个分组同时在途"。

3.3 流水线协议：GBN与SR的核心差异

流水线协议把发送窗口从1扩大到N，于是分组可以在未被确认的情况下连续发出去。接下来要处理一个棘手问题：发送窗口里的某个分组丢了，接收方可能已经收到它后面的分组了。这时候怎么重传？

回退N步（GBN）的思路是：接收方只按序交付数据，任何乱序到达的分组都一律丢弃，然后给发送方回一个预期的下一序号作为累积ACK。发送方一旦超时，就把当前发送窗口里所有未确认的分组全部重传。这逻辑很粗暴，但好处是接收方不需要任何缓存，简单可靠。代价也明显：如果窗口很大，一个分组丢失会引发大量无谓重传。

选择重传（SR）的思路是：接收方把乱序到达的分组先缓存起来，逐段确认，发送方只重传真正丢失的那个分组。听着完美，但要理解它的复杂之处：发送方和接收方窗口位置可能不同步，所以教材里画的那张"诡异情况"图，讨论的就是窗口重叠导致的分组重复问题。若是你做题遇到SR，最核心的考点就是确认号怎么回、窗口什么时候滑动、以及重传时到底重发哪个序号。

用一个生活类比：GBN像在餐厅后厨，传菜员把一批菜端出去，如果有一道菜洒了（丢了），他会从第一道没被确认的菜开始重新出一道完整的席（全部重传）；SR则更像外卖平台，哪单丢了补哪单，其余照常送达。现实中TCP用的是个混合体：它的确认方式接近累积确认，但乱序数据会缓存，重传机制既有超时重传又有快速重传，严格讲既不是纯GBN也不是纯SR。教材到了TCP章节才点透这层关系。

4. TCP核心机制拆解：从三次握手到拥塞控制

4.1 TCP报文段结构：为什么seq是字节号而不是包号

TCP报文段首部默认20字节，比UDP的8字节复杂太多。源端口、目的端口、序号、确认号、首部长度、标志位、接收窗口、校验和、紧急指针……每个字段都有来历。最容易被新手误解的就是序号（seq）。在TCP里，序号不是"我发的是第几个包"，而是"本报文段数据部分第一个字节在发送字节流中的编号"。比如你要发送一个1000字节的流，MSS是500字节，那么第一个段的seq是某个初始值x，第二个段的seq就是x+500，依次类推。

理解了这个，三次握手中的seq和ack就很容易算。假设客户端初始序号client_isn=1000，服务器初始序号server_isn=5000。第一步客户端发送SYN=1、seq=1000的段；第二步服务器回SYN=1、ACK=1、seq=5000、ack=1001（表示"我期待下一个字节序号是1001"，同时确认收到SYN）；第三步客户端发ACK=1、seq=1001、ack=5001。很多人记不住ack为什么是+1，原因就在于SYN标志本身消耗了一个字节的序号。同样的道理适用于FIN标志——挥手时FIN也占一个字节序号，所以最后的ack也要再加1。

TCP里的MSS边界值是1460字节，这是由以太网MTU（1500字节）减去IP首部20字节再减去TCP首部20字节得到的。考试偶尔会给MTU让你算MSS，记住MSS指的是TCP层数据部分的最大长度，绝不是TCP首部的长度。

4.2 三次握手与四次挥手：到底在防什么

三次握手的核心目的不是"开始传数据"，而是"双方同步初始序号并协商参数"。如果只有两次握手，一个最大问题就是历史遗留的SYN报文段可能乱入建立出一条无用连接。举例说，客户端曾经发过一个SYN因为网络延迟才到达服务器，服务器以为这是新连接，就分配资源并回SYN+ACK，等待客户端确认——如果没有第三次握手，服务器就一直傻等，白白耗尽资源。第三次握手的ACK让服务器可以确认"客户端当前确实在发起连接"，而不是一个被延迟的旧SYN。

四次挥手的四个动作则是：客户端主动关闭调用close后发出FIN，状态变成FIN_WAIT_1；服务器收到FIN后回ACK，自己进入CLOSE_WAIT；此时连接处于半关闭状态，客户端不能再发数据，但服务器仍然可以继续发；等服务器也没有数据要发时，再发FIN，进入LAST_ACK；客户端收到后回最后一个ACK，然后进入TIME_WAIT。

TIME_WAIT为什么要等2MSL（最大报文段生存时间）？两个原因：一是确保自己最后的ACK如果丢了，服务器会重发FIN，客户端还能再补一个ACK；二是让残留在这个连接上的旧分组在网络中自然消亡，免得影响新连接。很多人调代码时会遇到"端口被占用"的问题，查看netstat看到一堆TIME_WAIT连接，其实这就是正常现象，操作系统会在时间到了之后回收。

4.3 流量控制与拥塞控制：两个窗口千万别混

流量控制和拥塞控制是考研里最经典的"兄弟陷阱"。流量控制是端到端之间的：TCP报文段首部的接收窗口字段（rwnd），告诉对方"我的接收缓冲区还有多大空间"，发送方据此调节发送速度，防止接收方应付不过来。拥塞控制是全网视角的：网络里有路由器在排队，链路可能拥塞，发送方要探测网络状况，用一个拥塞窗口（cwnd）来控制速度，避免把网络塞爆。

发送方的实际发送窗口大小，取的是min(cwnd, rwnd)。收到一个ACK时，cwnd的变化规律由拥塞控制算法决定，而rwnd是动态反映在报文段里的。如果你在任何一道题里看到"接收窗口为0，但发送方还发数据"或"拥塞窗口为零"之类的说法，先别急着算，想想它们的物理意义，多半题目就在考你概念区不区分。

流量控制的机制本身并不复杂：接收方告诉发送方当前剩余缓存大小。教材有个细节值得注意——当接收方通告rwnd=0时，发送方会停止发送，但为了防止接收方的rwnd更新报文丢失导致死锁，TCP要求发送方在rwnd=0时仍周期性发送一个1字节的探测段。这个细节虽然是扩展内容，但面试时说出来会很加分。

4.4 拥塞控制的状态机：慢启动、拥塞避免、快速恢复

教材图3-52那张状态转换图，是很多人的心理阴影，但拿下来之后你会发现它其实是一条"如何试探网络容量并安全兜底"的策略。先看慢启动：cwnd从1MSS开始，每收到一个ACK就加1MSS，所以每个RTT内cwnd翻倍，指数增长。这样做的理由是TCP不知道网络容量有多大，只能一点点快速试探，直到撞上ssthresh（慢启动阈值）再切换策略。

达到ssthresh后进入拥塞避免阶段，每个RTT只把cwnd增加1MSS，线性增长。为什么从指数变成线性？因为过了阈值说明已经接近瓶颈，再指数涨下去大概率引发大量丢包。一旦出现超时（推断拥塞很严重），TCP Reno的做法是：ssthresh = cwnd/2，cwnd=1MSS，重新进入慢启动。这里有个细节，超时后的ssthresh变成原来窗口的一半，是为了留下的"记忆"，让下次慢启动不用从零开始猜。

如果出现的是3个冗余ACK而不是超时，TCP走的是快速恢复路径：ssthresh被设置为当前cwnd的一半，cwnd减半再加3MSS（相当于是进入了拥塞避免），然后每个RTT线性增长。这样做的逻辑是，3个冗余ACK说明后续的分组还能到达对端，网络的拥塞程度比完全超时温和，所以不需要撤回到cwnd=1的慢启动。教材里"为什么是3个ACK而不是2个"是因为1到2个冗余ACK可能是乱序导致的，不能贸然重传，3个是一个经过权衡的经验值。做题时看到三个7、三个丢包的关键词，第一反应就往快速重传上靠。

5. 学习资源、复习策略与避坑指南

5.1 配合视频课和实训平台的高效刷法

我完全理解啃第七版原版教材的吃力。英文术语多，句子绕，状态图密集。如果你和我一样基础一般，建议搭配湖科大教书匠的计算机网络视频课，他把自顶向下的思路拆得非常细，第三章的可靠数据传输讲得尤其好，比很多讲授课更贴近"理解"而不是"背诵"。至于头歌平台的计算机网络实训，适合用来刷验证性题目，但注意一定自己先算再做，要的是训练过程而不是到处找答案，那样期末和考研的时候你会发现自己连原题换个数字都不会。

我的个人刷题顺序是这样的：先把教材三遍精读——第一遍通读划重点，第二遍把课后习题做一遍，第三遍对着自己错的题重看对应小节；然后同步看视频课，每看完一节做该节的头歌题；最后一周集中刷408真题和期末真题里与传输层相关的题目，尤其是带时序、窗口、吞吐量计算的题型。这一套流程下来，至少比直接背别人笔记牢固得多。

5.2 用抓包工具验证三次握手与拥塞控制

纸上谈兵终觉浅。我用Wireshark抓过一次访问网站的全过程，效果非常直观：能清楚看到TCP三次握手的第一、第二、第三个报文段，以及它们的seq和ack数值变化。如果你也在学这一章，我建议你做一个实验：开一个浏览器访问任意HTTP网页，同时开Wireshark抓本机网卡，过滤器写tcp.port == 80或tcp.port == 443。你能看到客户端发出的SYN报文seq是一个随机整数，服务器回的SYN+ACK自成一个initial ISN，第三次握手的ack正是服务器ISN加1。把这组数和你按教材公式推出来的对上，会特别有成就感。

想观察拥塞控制的话，可以在局域网里用iperf3做流量压测，同时Wire shark看连续的ACK流速；也可以编写一个简单的TCP传输脚本，人为再叠加一个丢包率很高的链路环境（Linux上可以用netem模拟），观察cwnd的锯齿形变化。教材不会给你这些操作步骤，但对理解"为什么拥塞控制要这么设计"帮助很大。

5.3 第三章常见误区与易错点速查表

这一章我踩过不少坑，整理了一份表格，考前扫一眼特别管用。

这个表我没有列全，但它基本覆盖了考研和期末最常考的理解型陷阱。你复习的时候也可以自己做一张，把课后习题里错两次以上的概念都塞进去，效果比对着书抄笔记好。

5.4 408真题与期末题的针对性训练方向

如果你准备408，第三章的选择题比重不低，尤其喜欢考UDP校验和计算、TCP序号与确认号推导、拥塞窗口变化图、流量控制与拥塞控制的区别。这几种题型我都建议你各找十道真题练手，做到能在草稿纸上不翻书演算。还有一类综合大题会给出窗口大小和RTT让你算吞吐率，公式就是窗口大小除以RTT，但前提是你得区分题目给的是接收窗口还是拥塞窗口。至于期末复习，很多学校喜欢出判断题和简答题，简答题最常出现"为什么需要三次握手""TCP和UDP的区别""拥塞控制的目的是什么"，把这三个题准备成小作文一样的三段，稳妥过关问题不大。

6. 常见问题与排查技巧实录

6.1 做题时最容易翻车的三类错误

第一类是序号计算。"服务器收到客户端的SYN之后，返回的ack到底是client_isn还是client_isn+1"，我敢说至少一半初学者会写错。正确永远是+1，因为SYN标志消耗了一个字节序号。同理，进入建立连接后的第一个数据段seq是client_isn+1，不是新随机数。

第二类是校验和的手算。很多人在反码求和过程中忘了回卷进位。记住规则：任何一位相加的结果如果超出16位，就要把进位移回最低位再相加，最后对所有位取反。做题时可以先算一个16位字段两两相加的用例，再对照教材第229页的示例，愿意动手写上两三遍就会了。

第三类是拥塞控制窗口序列的推演。教材给了一串cwnd和ssthresh的变化过程，考试喜欢让你推算"第几轮RTT之后cwnd降到多少"。这里最容易错的是你忘了超时或冗余ACK之后ssthresh会更新。看题的时候先用笔划出来：什么时候发生超时，什么时候检测到3个冗余ACK，然后按"超时→重设为ssthresh/2且cwnd=1，冗余ACK→cwnd减半再+3"两条规则分别推进。

6.2 用Linux命令观察TCP状态

光读书不做实验，很多状态等同于白背。在Linux终端里执行netstat -tunap，可以看到当前系统的TCP连接状态。主动连一个外网网站时，你会看到连接从SYN_SENT变成ESTABLISHED；如果服务端没有响应，则可能停留在SYN_SENT直到超时。主动关闭一条连接后用netstat观察TCP连接状态，能抓到FIN_WAIT_2、CLOSE_WAIT、TIME_WAIT等状态。这一通操作下来，你就不需要死记这些状态名了，它们的含义会跟你见过的现象绑定在一起。

再做一个小实验：开一个是TCP服务器监听在某个端口，用另一个终端不停连接又断开，观察服务器的进程连接数，你会发现即使客户端断开，服务器的TIME_WAIT连接也会累积一段时间。这就是很多人写高并发服务器时遇到"大量TIME_WAIT"的根源。明白了2MSL机制，你会更有底气去搜索和尝试tcp_tw_reuse这类参数——当然这是工程层面的内容，考研不会考，但对后续工作面试特别加分。

6.3 面试里被追问的TCP细节怎么应付

如果是为了面试准备，我觉得第三章给的三板斧是：RTT估算、超时重传、快速重传。面试官特别喜欢问"TCP怎么设置超时时间"，标准答案就是EstimatedRTT是平滑加权平均，DevRTT衡量抖动，超时时间等于EstimatedRTT加上4倍DevRTT。你可以补充说：当EstimatedRTT变小时，超时时间也会跟着变小，但如果RTT波动大，DevRTT会让超时时间适当地宽松，以免误判丢包。这样答，既有公式又有直觉，比干背表达式强得多。

另一个高频追问是"快速重传的原理"。标准答案是发送方连续收到3个对同一序号的冗余ACK之后，不等超时就立即重传该分组。你还可以深化一句：这等价于"接收方在委婉地告诉发送方：我下一个想要的字节序号还是x，你缺的那块数据赶紧补上"。这种解释能让面试官知道你理解了“冗余ACK”的含义，而不是只会背数字。

写在最后的一点个人体会

第三章是我在这本书里复习用时最长的一章，经验就一条：别急着背，先顺着rdt的推演把整条逻辑链走一遍；然后打开Wireshark，亲眼看一下三次握手和挥手的序号变化；最后再回到题目里去检验自己理解得准不准。我现在做题会习惯性地把书翻到图3-52的TCP状态转换图，用手在桌上比划状态是怎么迁移的——SYN、ESTABLISHED、FIN_WAIT、TIME_WAIT，一气呵成。希望这篇分享也能帮你少走一点弯路，尤其是别再把流量控制和拥塞控制当成同一个东西了。祝复习顺利。