1. 先搞清楚一件事：TCP/UDP到底在传输层的哪个位置很多刚复习到这一章的朋友，容易把TCP和UDP孤立地拿出来背，一会儿记TCP头部字段，一会儿记UDP特点，背完就乱。我建议你先退一步，把自己放到一个完整数据包的视角里看问题。假设你在用浏览器访问一个网页，数据从你的电脑出发，依次要过应用层（HTTP）、传输层（TCP）、网络层（IP）、链路层（以太网），每一层都会往原始数据上套一个头部（或尾部）。传输层要干的活，本质上就是解决“数据到了主机之后，交给哪个应用”和“两个应用之间怎么把数据可靠地传给对方”这两个问题。前者靠端口号解决，后者靠TCP的一系列机制解决，而UDP的选择是“不解决”。这个定位很重要。因为HCIA考试里关于TCP/IP的考点，从来不是单考某一段，而是把“分层→封装→传输→解封装”串起来考。你把TCP/UDP放进七层模型（实际考试以TCP/IP五层模型为主）里再看，很多知识点会自然连起来，比如四层交换、端口号的作用、NAPT转换时为什么只看传输层头。说回两个协议本身。TCP是面向连接的、可靠的字节流传输协议，UDP是无连接的、不可靠的数据报传输协议。这句话是考点，而且几乎每年都考，但不少人只是背下来，并没有理解“面向连接”四个字带来的连锁影响——它意味着TCP要先建立会话，再传输数据，传完还要拆会话；它意味着TCP要为每个字节编号；它意味着TCP要确认、重传、排序、流量控制、拥塞控制。这些都是UDP压根不需要做的事。UDP只做一件事：把数据丢到底层IP，然后祈祷对方能收到。所以在复习策略上，我给你的第一个建议是：**别按协议背，按“机制”背。**TCP的知识点本质上就是一组机制的叠加，你只要把每个机制解决的问题、用的字段、触发的条件搞清楚，考场上不管题目怎么绕，你都能拆出来。2. 头部格式对比：20字节与8字节背后的设计取舍TCP和UDP的头部格式，是HCIA考试第一个高频考点区域。两边的字段数量、长度、含义都不能记混，尤其是TCP那一堆标志位，考试极爱出“某个标志位置1，表示什么”的题。先说UDP头部，8个字节，四个字段：源端口（16bit）、目的端口（16bit）、UDP长度（16bit）、UDP校验和（16bit）。UDP长度这个字段有点意思，它表示的是“UDP头部+数据”的总长度，不是只算数据，也不是只算头部。最小长度是8，也就是空数据的时候。这个考点很细，很多人会背错，我提醒你特别注意一下。TCP头部就不一样了，固定部分20个字节，后面还可以接选项，最长能到60字节。固定部分有这些字段：源端口（16bit）、目的端口（16bit）、序列号（32bit）、确认号（32bit）、数据偏移（4bit）、保留位（6bit）、标志位（6bit）、窗口大小（16bit）、校验和（16bit）、紧急指针（16bit）。到了选项部分，最常见的选项就是MSS（最大报文段大小）、SACK（选择性确认）、窗口比例因子这些，考试不会深入考选项细节，但MSS和MTU的关系要搞清楚。很多初学者一开始会被“序列号/确认号各32bit”搞晕，这里我给你一个最直白的理解办法：序列号（Seq）：我这个包里，第一个数据字节的编号是多少。确认号（Ack）：我期望对端下一个数据字节的编号是多少，同时隐含“编号比这个小的，我都收到了”。这个理解方式对后面讲三次握手和重传机制非常重要。你只要清楚这两个号是针对“字节”编号，而不是针对“报文”编号，基本就拿下了一半。再来看TCP的标志位，6个bit，这是大热门：标志位名称置1时的含义SYN同步请求建立连接ACK确认确认号字段有效FIN结束请求断开连接RST重置异常中断连接PSH推送尽快交付应用层URG紧急紧急指针字段有效考试常考的组合：SYN置1表示发起连接，SYN+ACK同时置1表示对连接请求的应答，FIN置1表示主动断开，RST置1马上断。还有一个容易忽略的点是PSH，它跟TCP缓冲区相关——TCP是流式协议，数据会先在缓冲区攒着，PSH置1相当于让接收方别等了，赶紧把缓冲区里的数据交给应用进程。这个概念在讲交互式应用时有用，但考试更多是考名称含义本身。TCP窗口大小这个字段，是滑动窗口机制的直接体现，16bit的上限是65535字节，但因为用窗口比例因子选项可以把窗口放大到1GB级别，所以实际场景里窗口远不止64KB。这个知识点在考试里会结合“流量控制”出现，你要理解的是：窗口值由接收端通告，表示“我还能收多少”，发送端不能超过这个值。对比下来你就能感受到设计哲学上的差异：UDP头部极度精简，8个字节里根本没有序号、确认号、窗口这些东西，所以它头部开销小、传输时延低、没有重传机制。TCP则用20+字节的头部换来了可靠性、有序性、流量控制能力。没有谁好谁坏，使用场景决定选谁。3. 三次握手：不止是“问一下答一下”而是状态机的迁移三次握手是TCP/UDP复习里最核心的考点，没有之一。至少一半的基础题从这里面出，而且出题方式五花八门：有考标志位组合的，有考状态名的，有考ack数值的，有给个抓包文件让你判断第几次握手的。三次握手的标准流程：客户端发送SYN报文，Seq为随机初始值x（我们叫ISN），此时客户端状态变为SYN_SENT。服务器收到SYN，回复SYN+ACK，Seq为自己的初始值y，Ack=x+1，服务器状态变为SYN_RCVD。客户端收到SYN+ACK，发送ACK报文，Ack=y+1，此时客户端进入ESTABLISHED，服务器收到后也进入ESTABLISHED。最容易出错的地方有两个。第一个是“初始化序列号到底是多少”。因为安全原因，现代系统基本都启用随机化初始序列号，所以不要再死记x=1、y=1这种老黄历，考试如果给序列号数值，要看它是“随机生成的初始值”，而不是固定值。第二个是“Ack数值为什么会比序列号大1”。确认号等于对方的序列号加1，是因为SYN和FIN报文本身要占一个序列号。虽然它们不携带用户数据，但控制信息也要被确认，所以这三段握手的关键规律是：凡是要被确认的报文，占一个序号；有效载荷为0，但序号要消耗。三次握手里的SYN各占一个号，纯粹的ACK不占号。这个规律在做抓包分析题时特别实用。再往深一层，三次握手本身就是一次“双向收发能力验证”的过程：第一次SYN：客户端验证自己的发送能力、服务器的接收能力。第二次SYN+ACK：服务器验证自己的发送能力、客户端的接收能力，同时告诉客户端“我收到你了”。第三次ACK：客户端告诉服务器“我也收到你了”。当双方都知道“我能发出去，你能收到；你能发出来，我能收到”，连接才算建立。这个逻辑在考试中直接表现为“缺了第三次握手行不行”——不行，因为服务器不知道客户端是否收到了自己的SYN+ACK，它自己单方面认为能发不可靠。三次握手的状态迁移也是考点密集区。客户端侧的状态链比较简单：CLOSED（无连接状态）→ SYN_SENT（已发送SYN）→ ESTABLISHED（已建立）。服务器侧更常考：LISTEN（监听）→ SYN_RCVD（收到SYN）→ ESTABLISHED。这里有个细节，SYN_RCVD是服务器收到SYN但还没有收到最终ACK时的状态，如果此时服务器一直等不到客户端的ACK，会重传SYN+ACK，直到超时。题外话：很多初学者会把SYN_RCVD和SYN_SENT弄反，记一个办法——发是主动，收是被动，状态名描述的是“自己当前处在哪一步”。客户端发出SYN，所以是SYN_SENT；服务器收到了SYN，还没确认对方收到自己回复，所以是SYN_RCVD。这样理解就不容易混了。4. 四次挥手：TIME_WAIT为什么存在，是HCIA最爱挖的坑挥手部分比握手难理解了不止一个台阶。原因在于TCP的连接是“全双工”的，也就是说数据允许同时双向流动，断开不能一方说断就全断。四次挥手本质上是“两条单向通道分别拆除”的过程。标准流程：主动方发送FIN，Seq=m，进入FIN_WAIT_1。被动方收到FIN，回复ACK，Ack=m+1，进入CLOSE_WAIT；主动方收到ACK后进入FIN_WAIT_2。被动方在自己没有更多数据要发时，发送FIN，Seq=n，进入LAST_ACK。主动方收到FIN，回复ACK，Ack=n+1，进入TIME_WAIT；被动方收到ACK后进入CLOSED。这里有两个非常经典的考点。第一，为什么是四次而不是三次？因为FIN和ACK的语义是分开的。被动方收到主动方的FIN时，只是表示“主动方不再发了”，但不代表被动方立刻没有数据要发。被动方的ACK只是应答“我收到你的FIN”，而它自己的FIN要等数据发完后再单独发。所以第二次和第三次之间可能隔着很长时间，而不是像握手那样能合并。只有一种情况下挥手能缩成三次：被动方在收到FIN时恰好也没有数据要发了，那么ACK和FIN可以合在一个报文里同时发，但这只是合并，不包括数据时方向性差异的语义变化。第二，TIME_WAIT为什么存在？这个被问到的频率极高。答案有两条：保证最后一个ACK能到达被动方。如果这个ACK丢了，被动方会重发FIN，而主动方如果没有TIME_WAIT，一收完ACK就直接关掉，那重发的FIN谁来应答？网络就直接卡住。保留TIME_WAIT状态，就是为了让主动方在2MSL时间内能重新响应重发的FIN。让旧报文段在网络中自然消失。一个TCP连接关闭后，可能会出现“迟到的历史数据包”还在网络中游荡，如果立刻用相同IP和端口建立新连接，旧包可能被误认为是新连接的数据。TIME_WAIT保留2MSL，足以让网络中所有属于旧连接的数据包消失。MSL是报文最大生存时间，RFC建议值是2分钟，实际Windows/Unix常用30秒或者60秒，所以TIME_WAIT通常是2MSL即60~120秒。考试不一定考具体数值，但你要知道TIME_WAIT这个状态只会出现在主动关闭的一方。被动方永远不会进入TIME_WAIT，这是很多人忽略的。还有CLOSE_WAIT这个状态，值得单独说一句。CLOSE_WAIT是被动方在回复ACK之后、发送自己的FIN之前的状态，它代表“连接对方已挂断，但我这边应用还没调用close”。如果线上排查时发现一堆CLOSE_WAIT，大概率是应用程序没正确关闭socket，这时候TCP层面已经没救了，要去看代码层面的资源释放。这个问题HCIA不会考太深，但对考完试真正去搞运维的人来说，是迟早要面对的经验。四次挥手另一个常考的点是状态链。主动关闭方：ESTABLISHED→FIN_WAIT_1→FIN_WAIT_2→TIME_WAIT→CLOSED。被动方：ESTABLISHED→CLOSE_WAIT→LAST_ACK→CLOSED。你在做题时看到“服务器出现了大量FIN_WAIT_2”，要能推理出是“服务器主动断开的连接多，而且对方的FIN迟迟没回来”——通常是对端应用卡死了。这种题不是直接背状态名，而是给你一个现象让你反推原因，这也是HCIA如今的出题趋势。5. 端口号的记忆方法，以及那些年年都考的默认端口TCP和UDP都用端口号来区分不同的应用进程。端口号范围0~65535，考试常考的分类是：0~1023：知名端口号，由IANA统一分配，给常见服务使用。1024~49151：注册端口号，给用户或应用程序使用（有些资料也说是记录端口）。49152~65535：动态/私有端口号，客户端临时使用。有些老教材还会写“保留端口号”一说，但HCIA考试更认上面这个三段划分。你要特别注意：客户端发起连接时用的源端口通常是1024以上的临时端口，这点在NAT相关的题目里尤其重要。知名端口的记忆量比较大，我挑HCIA最常考的列个表，考场上撞到概率极高：端口协议服务传输层协议21TCPFTP控制TCP20TCPFTP数据TCP22TCPSSHTCP23TCPTelnetTCP25TCPSMTPTCP53TCP/UDPDNS两者都有67/68UDPDHCP服务端/客户端UDP69UDPTFTPUDP80TCPHTTPTCP443TCPHTTPSTCP161UDPSNMPUDP最容易踩坑的两个：一个是DNS，它既可以用TCP也可以用UDP，平时查询用UDP（为了快，一次请求一次应答就够了），但区域传送和当响应数据超过512字节无法通过单UDP报文承载时，会切换到TCP。考试题干如果说“DNS一定用UDP”，那肯定是错的。另一个是TFTP，很多人看到FTP就写21，但TFTP默认端口是69，而且是UDP上跑的简单文件传输协议。出现“TFTP+UDP+69”这种组合时，你要能反应过来。关于端口号在TCP和UDP中的地位差异，也值得理解：TCP端口是全球唯一的会话标识的一部分（四元组：源IP、源端口、目的IP、目的端口），而UDP端口也一样承担多路复用作用，但因为没有连接概念，它的端口更像“投递地址”。头部格式里两边都有源目端口，就是为了一来一回能对上号。如果只有目的端口没有源端口，接收方回复时就没法知道该发给谁了。6. 可靠的真相：确认、重传、滑动窗口、拥塞控制，一个都不能少TCP的“可靠传输”不是靠某一个机制单独撑起来的，而是确认应答机制、超时重传机制、滑动窗口机制、流量控制机制、拥塞控制机制五者协同的结果。HCIA对这块考得比CCNA略浅，但两者之间没有绝对隔断，你按五层模型复习时不可跳过其中任何一个。先讲确认应答和超时重传。TCP发送方发一个报文后，会启动一个重传计时器；如果在规定时间内没收到确认，就重新发送。超时时间的设定通常比RTT（往返时间）稍微大一点，用来避免因为正常网络延迟而误触发重传。确认应答不是发一个确认一个，TCP允许累积确认——接收方收到连续的几个报文后，只需确认“最后一个连续的字节的序号”，因为确认号已经隐含了更早的数据都收到了。这里有一个让很多人困惑的考点：重传时是重传“一个报文”还是“从丢失的那个及之后所有报文”？经典的Go-Back-N策略是回退重传，丢了一个后面的全重传，效率低；实际TCP用了很多优化，包括选择重传，配合SACK选项只重传丢失的那段。考试如果问你“TCP如何保证可靠性”，你答出“序列号、确认号、重传机制、滑动窗口”就已经够用了，细到SACK一般不深究。再说滑动窗口和流量控制。先理解滑动窗口解决了什么问题：如果发方一股脑把数据全丢出去，接收方处理不过来，只能丢包，丢包又引发重传，效率反而更低。所以TCP里，接收方会告诉发送方“我的接收窗口（rwnd）还有多大”，发送方只能在窗口大小范围内发送数据。数据发出去后，收到确认，窗口就向前滑动。这就是流量控制，目的是“让发送方的速率匹配接收方的接收能力”。值得注意的细节是，窗口值在TCP头部的Window字段里每次握手和数据传输阶段都会更新，如果接收方应用程序没来得及读取数据，接收缓冲区满了，窗口会变成0。发送方收到窗口为0的公告后就会停止发送，并启动持续计时器周期性地探测接收窗口何时恢复。这个机制在考试里出题不多，但你会看到题干中“接收方处理不过来导致丢包”“发送方周期性探测窗口”这类描述，要能落到“流量控制”这个结论上。拥塞控制跟流量控制最大的区别是：流量控制管“对端能收多少”，拥塞控制管“网络能承载多少”。TCP有四个常考的算法阶段：慢启动（Slow Start）：拥塞窗口从1个MSS开始，每收到一个确认就翻倍，指数增长，直到达到慢启动阈值ssthresh。拥塞避免（Congestion Avoidance）：达到ssthresh后，每经过一个RTT拥塞窗口加1，线性增长。快重传（Fast Retransmit）：收到3个重复ACK就立即重传丢失报文，不傻等超时。快恢复（Fast Recovery）：发生丢包后，ssthresh减为当前窗口一半，拥塞窗口从新ssthresh开始执行拥塞避免，而不是回到慢启动的1。HCIA不要求你把每个算法细节写得跟研究论文一样，但你要能描绘一条经典的“拥塞窗口变化曲线”：先指数上升，到阈值后线性上升，丢包时砍半，然后继续线性上升。考试如果考“某个TCP连接发生拥塞避免”，它给RT和ssthresh让你算吞吐变化也是可能的，公式基本就是“超过阈值后每个RTT窗口+1”。这里有个比较容易吃透但很多人却忽略掉的点：拥塞窗口（cwnd）和接收窗口（rwnd）是两回事，发送方实际能发的数据量是两者的最小值。很多资料只画了拥塞窗口曲线，没提接收窗口，导致做题时看到“接收窗口比拥塞窗口小很多”的场景就懵。记住这个min关系，快速定位窗口计算类题目。7. 这些细节看起来冷门，但HCIA偏偏爱出复习到这个程度，TCP/UDP的大部分主干内容你已经过了一遍。接下来我要把“容易漏掉、但实际考试命中率不低”的边角知识点单拎出来说。这些点单看不难，难在它们分散在各种填空题、判断题、选择题的犄角旮旯里。第一个是MSS与MTU。MSS（最大报文段大小）是TCP数据部分能承载的最大长度，MTU（最大传输单元）是链路层能承载的最大数据帧大小。它们之间的关系是：MSS = MTU - IP首部（20字节一般）- TCP首部（20字节）。以传统以太网MTU=1500为例，MSS=1460。TCP在建立连接时，双方会在SYN报文里协商MSS，取较小值使用。考试里常见的干扰项是“MSS越大越好”——并不是，MSS太大导致IP分片，反而增加重传开销和网络负担。第二个是TCP校验和。TCP头部和UDP头部都有校验和字段，覆盖的范围不只是头部，而是“伪头部+TCP/UDP头部+数据”。伪头部包括源IP、目的IP、协议号、TCP/UDP长度。也就是说，传输层校验和会把IP层的一些关键信息一起校验，防止错误投递。UDP的校验和在IPv4下是可选的，但IPv6下是必选的。这个考点如果出现在判断题里，往往是“UDP没有校验和”——严格说UDP有校验和字段，只是在IPv4里可以不启用，考试题如果描述得含糊，你要留个心眼。第三个是TCP紧急指针和URG。紧急指针配合URG标志位使用，表示当前报文中有“必须尽快处理的数据”，这些数据会跳过缓冲区排队逻辑，直接交给应用层。但这种用法在当今实际网络中非常罕见，考试主要是考概念对应关系，别跟PSH弄混就行。第四个是“半关闭（half-close）”。四次挥手并不是要求双方同时各发一个FIN，而是允许一端先关闭发送方向，另一端仍然继续发送数据。这个在文件传输结束后特别常见：客户端发完请求后关闭写方向（发FIN），但还能持续接收服务端推送过来的数据。TCP支持半关闭状态，也就是FIN_WAIT_2之后还能等对端数据。搞懂这个，你才能理解为什么FIN_WAIT_2状态可以长时间存在。第五个是TCPKeepalive。TCP连接建立后，如果长时间没有数据传输，中间路由器或防火墙可能把会话老化删除，从而导致“假连接”。TCP的Keepalive机制会周期性发送探测报文来确认连接是否存活。它跟应用层的心跳是两个概念，但经常会组合考：不是每台设备都默认开启TCP Keepalive，所以在真实项目中，很多应用会在应用层自己做心跳，以此弥补TCP层不可控的Keepalive参数。HCIA对这块要求不高，但如果你未来的职业方向是数通，这点会在面试或证书之后的技术沟通里反复碰到。8. 从复习到实战：实验环境里验证TCP/UDP，胜过背十遍书复习到最后一个环节，我强烈建议你打开模拟器（eNSP之类的虚拟化平台，或者本机装Wireshark抓两个真实包），把前三章的内容自己验证一遍。“看得见”的状态迁移比死记硬背扎实得多。最简单的验证实验是抓三次握手。随便装个Wireshark，在电脑上访问一个HTTP网站，然后在抓包列表里找第一条TCP流，你就能看到：第一个包：Flags=S，Seq=x，源端口是本地临时端口（通常是49152以上的动态端口），目的端口80。第二个包：Flags=S+ACK，Seq=y，Ack=x+1。第三个包：Flags=ACK，Seq=x+1，Ack=y+1。看一次这个表，你就再也不会弄错“Ack等于对方的Seq加1”这件事。顺便你可以在统计菜单里看到整条TCP连接的时间、吞吐、重传次数。如果看到重传次数不是0，你可以把它关联到“超时重传”知识点，比单纯概念复述有效得多。再做一个UDP的验证实验：打开任意一个局域网聊天工具或直播/语音类的应用（如某视频会议软件、某个游戏），看抓包结果，你会发现UDP报文的源目端口跟TCP一样存在，但并没有Seq/Ack字段，后面紧跟着的就是应用层数据。9个字段变成4个字段，直观理解了“UDP头部8字节”。想验证状态迁移，可以起一个本地HTTP服务，用telnet或者netcat测试连接，在Windows上用netstat -ano实时观察连接状态从SYN_SENT到ESTABLISHED再到FIN_WAIT_2/TIME_WAIT的切换。对着netstat的状态变化，心里默算当前处于四次挥手的哪一阶段，训练两三遍后，这部分知识基本就焊死在脑子里了。实验里还有一个容易踩的坑是：如果你用虚拟机做的实验，要注意虚拟网卡的TCP校验和卸载（checksum offload）可能导致Wireshark显示checksum错误。这不是你的实验出问题了，而是网卡把校验和计算放到了硬件层面，抓包软件看不到正确的值。遇到这种情况，去网卡属性里关掉TCP/IP校验和卸载，再重新抓包，显示就正常了。这个坑如果不提前知道，你会怀疑自己配置错了，浪费半小时。9. 考试答题时的几个“保命”判断技巧最后分享几个我在刷题和实际考试里总结出来的答题技巧。HCIA的题库风格总体偏基础，但陷阱也不少，掌握下面几个判断路径，能帮你更稳定地拿分。第一，看到“可靠性”三个字，优先联想到TCP、确认机制、序列号、重传、窗口。看到“实时性”“低延迟”“开销小”这些词，优先想到UDP。题目如果做对比选择题，基本跑不出这个套路。第二，任何牵涉到“端口号范围”的题，先分清题干问的是源端口还是目的端口。目的端口通常是知名端口，源端口往往是随机的高位端口。NAT相关的题尤其容易在这里设坑。第三，状态迁移题，从题干的关键字判断方向。题目出现“服务器”“被动”“不知道客户端的接收能力”“未收到ACK”，你优先想到的是握手第二步或挥手第二步。题目出现“客户端”或“主动方”并且问“此后还能接收数据吗”，想到半关闭。出现“旧的网络报文消失”“保证最后的ACK到达”这种表述，直接定位TIME_WAIT。第四，关于“为什么选择UDP”的场景题，别只答“快”，要答出“无连接、无状态、开销小、时延低、不保证可靠、但适合实时传输”。而且要学会反面验证：“这个场景能不能用TCP？”——如果视频直播的拥塞控制放在TCP里，任何一次丢包都会造成卡顿和重传，体验远不如UDP。所以像视频会议、VoIP、域名查询、DHCP这类场景，用UDP居多。第五，遇到抓包报文分析题，先数两列：Flags列和长度列。Flags里有S就是握手，有F就是挥手，有R就是异常中断。报文长度小于20字节的一定不是TCP，因为TCP头部最少20字节。这个快速过滤法在考场时间紧张时非常管用。复习TCP/UDP这件事，本质上是把“传输层的设计者为什么要这么做”想明白。你想明白了，不是背明白了，考场上就不会慌。这个专题在HCIA里面分量不轻，但远没有到需要发怵的程度，按照上面的思路梳理一遍，配合实验抓包看一看，基本就可以去换下一章了。
1. 先搞清楚一件事：TCP/UDP到底在传输层的哪个位置很多刚复习到这一章的朋友，容易把TCP和UDP孤立地拿出来背，一会儿记TCP头部字段，一会儿记UDP特点，背完就乱。我建议你先退一步，把自己放到一个完整数据包的视角里看问题。假设你在用浏览器访问一个网页，数据从你的电脑出发，依次要过应用层（HTTP）、传输层（TCP）、网络层（IP）、链路层（以太网），每一层都会往原始数据上套一个头部（或尾部）。传输层要干的活，本质上就是解决“数据到了主机之后，交给哪个应用”和“两个应用之间怎么把数据可靠地传给对方”这两个问题。前者靠端口号解决，后者靠TCP的一系列机制解决，而UDP的选择是“不解决”。这个定位很重要。因为HCIA考试里关于TCP/IP的考点，从来不是单考某一段，而是把“分层→封装→传输→解封装”串起来考。你把TCP/UDP放进七层模型（实际考试以TCP/IP五层模型为主）里再看，很多知识点会自然连起来，比如四层交换、端口号的作用、NAPT转换时为什么只看传输层头。说回两个协议本身。TCP是面向连接的、可靠的字节流传输协议，UDP是无连接的、不可靠的数据报传输协议。这句话是考点，而且几乎每年都考，但不少人只是背下来，并没有理解“面向连接”四个字带来的连锁影响——它意味着TCP要先建立会话，再传输数据，传完还要拆会话；它意味着TCP要为每个字节编号；它意味着TCP要确认、重传、排序、流量控制、拥塞控制。这些都是UDP压根不需要做的事。UDP只做一件事：把数据丢到底层IP，然后祈祷对方能收到。所以在复习策略上，我给你的第一个建议是：**别按协议背，按“机制”背。**TCP的知识点本质上就是一组机制的叠加，你只要把每个机制解决的问题、用的字段、触发的条件搞清楚，考场上不管题目怎么绕，你都能拆出来。2. 头部格式对比：20字节与8字节背后的设计取舍TCP和UDP的头部格式，是HCIA考试第一个高频考点区域。两边的字段数量、长度、含义都不能记混，尤其是TCP那一堆标志位，考试极爱出“某个标志位置1，表示什么”的题。先说UDP头部，8个字节，四个字段：源端口（16bit）、目的端口（16bit）、UDP长度（16bit）、UDP校验和（16bit）。UDP长度这个字段有点意思，它表示的是“UDP头部+数据”的总长度，不是只算数据，也不是只算头部。最小长度是8，也就是空数据的时候。这个考点很细，很多人会背错，我提醒你特别注意一下。TCP头部就不一样了，固定部分20个字节，后面还可以接选项，最长能到60字节。固定部分有这些字段：源端口（16bit）、目的端口（16bit）、序列号（32bit）、确认号（32bit）、数据偏移（4bit）、保留位（6bit）、标志位（6bit）、窗口大小（16bit）、校验和（16bit）、紧急指针（16bit）。到了选项部分，最常见的选项就是MSS（最大报文段大小）、SACK（选择性确认）、窗口比例因子这些，考试不会深入考选项细节，但MSS和MTU的关系要搞清楚。很多初学者一开始会被“序列号/确认号各32bit”搞晕，这里我给你一个最直白的理解办法：序列号（Seq）：我这个包里，第一个数据字节的编号是多少。确认号（Ack）：我期望对端下一个数据字节的编号是多少，同时隐含“编号比这个小的，我都收到了”。这个理解方式对后面讲三次握手和重传机制非常重要。你只要清楚这两个号是针对“字节”编号，而不是针对“报文”编号，基本就拿下了一半。再来看TCP的标志位，6个bit，这是大热门：标志位名称置1时的含义SYN同步请求建立连接ACK确认确认号字段有效FIN结束请求断开连接RST重置异常中断连接PSH推送尽快交付应用层URG紧急紧急指针字段有效考试常考的组合：SYN置1表示发起连接，SYN+ACK同时置1表示对连接请求的应答，FIN置1表示主动断开，RST置1马上断。还有一个容易忽略的点是PSH，它跟TCP缓冲区相关——TCP是流式协议，数据会先在缓冲区攒着，PSH置1相当于让接收方别等了，赶紧把缓冲区里的数据交给应用进程。这个概念在讲交互式应用时有用，但考试更多是考名称含义本身。TCP窗口大小这个字段，是滑动窗口机制的直接体现，16bit的上限是65535字节，但因为用窗口比例因子选项可以把窗口放大到1GB级别，所以实际场景里窗口远不止64KB。这个知识点在考试里会结合“流量控制”出现，你要理解的是：窗口值由接收端通告，表示“我还能收多少”，发送端不能超过这个值。对比下来你就能感受到设计哲学上的差异：UDP头部极度精简，8个字节里根本没有序号、确认号、窗口这些东西，所以它头部开销小、传输时延低、没有重传机制。TCP则用20+字节的头部换来了可靠性、有序性、流量控制能力。没有谁好谁坏，使用场景决定选谁。3. 三次握手：不止是“问一下答一下”而是状态机的迁移三次握手是TCP/UDP复习里最核心的考点，没有之一。至少一半的基础题从这里面出，而且出题方式五花八门：有考标志位组合的，有考状态名的，有考ack数值的，有给个抓包文件让你判断第几次握手的。三次握手的标准流程：客户端发送SYN报文，Seq为随机初始值x（我们叫ISN），此时客户端状态变为SYN_SENT。服务器收到SYN，回复SYN+ACK，Seq为自己的初始值y，Ack=x+1，服务器状态变为SYN_RCVD。客户端收到SYN+ACK，发送ACK报文，Ack=y+1，此时客户端进入ESTABLISHED，服务器收到后也进入ESTABLISHED。最容易出错的地方有两个。第一个是“初始化序列号到底是多少”。因为安全原因，现代系统基本都启用随机化初始序列号，所以不要再死记x=1、y=1这种老黄历，考试如果给序列号数值，要看它是“随机生成的初始值”，而不是固定值。第二个是“Ack数值为什么会比序列号大1”。确认号等于对方的序列号加1，是因为SYN和FIN报文本身要占一个序列号。虽然它们不携带用户数据，但控制信息也要被确认，所以这三段握手的关键规律是：凡是要被确认的报文，占一个序号；有效载荷为0，但序号要消耗。三次握手里的SYN各占一个号，纯粹的ACK不占号。这个规律在做抓包分析题时特别实用。再往深一层，三次握手本身就是一次“双向收发能力验证”的过程：第一次SYN：客户端验证自己的发送能力、服务器的接收能力。第二次SYN+ACK：服务器验证自己的发送能力、客户端的接收能力，同时告诉客户端“我收到你了”。第三次ACK：客户端告诉服务器“我也收到你了”。当双方都知道“我能发出去，你能收到；你能发出来，我能收到”，连接才算建立。这个逻辑在考试中直接表现为“缺了第三次握手行不行”——不行，因为服务器不知道客户端是否收到了自己的SYN+ACK，它自己单方面认为能发不可靠。三次握手的状态迁移也是考点密集区。客户端侧的状态链比较简单：CLOSED（无连接状态）→ SYN_SENT（已发送SYN）→ ESTABLISHED（已建立）。服务器侧更常考：LISTEN（监听）→ SYN_RCVD（收到SYN）→ ESTABLISHED。这里有个细节，SYN_RCVD是服务器收到SYN但还没有收到最终ACK时的状态，如果此时服务器一直等不到客户端的ACK，会重传SYN+ACK，直到超时。题外话：很多初学者会把SYN_RCVD和SYN_SENT弄反，记一个办法——发是主动，收是被动，状态名描述的是“自己当前处在哪一步”。客户端发出SYN，所以是SYN_SENT；服务器收到了SYN，还没确认对方收到自己回复，所以是SYN_RCVD。这样理解就不容易混了。4. 四次挥手：TIME_WAIT为什么存在，是HCIA最爱挖的坑挥手部分比握手难理解了不止一个台阶。原因在于TCP的连接是“全双工”的，也就是说数据允许同时双向流动，断开不能一方说断就全断。四次挥手本质上是“两条单向通道分别拆除”的过程。标准流程：主动方发送FIN，Seq=m，进入FIN_WAIT_1。被动方收到FIN，回复ACK，Ack=m+1，进入CLOSE_WAIT；主动方收到ACK后进入FIN_WAIT_2。被动方在自己没有更多数据要发时，发送FIN，Seq=n，进入LAST_ACK。主动方收到FIN，回复ACK，Ack=n+1，进入TIME_WAIT；被动方收到ACK后进入CLOSED。这里有两个非常经典的考点。第一，为什么是四次而不是三次？因为FIN和ACK的语义是分开的。被动方收到主动方的FIN时，只是表示“主动方不再发了”，但不代表被动方立刻没有数据要发。被动方的ACK只是应答“我收到你的FIN”，而它自己的FIN要等数据发完后再单独发。所以第二次和第三次之间可能隔着很长时间，而不是像握手那样能合并。只有一种情况下挥手能缩成三次：被动方在收到FIN时恰好也没有数据要发了，那么ACK和FIN可以合在一个报文里同时发，但这只是合并，不包括数据时方向性差异的语义变化。第二，TIME_WAIT为什么存在？这个被问到的频率极高。答案有两条：保证最后一个ACK能到达被动方。如果这个ACK丢了，被动方会重发FIN，而主动方如果没有TIME_WAIT，一收完ACK就直接关掉，那重发的FIN谁来应答？网络就直接卡住。保留TIME_WAIT状态，就是为了让主动方在2MSL时间内能重新响应重发的FIN。让旧报文段在网络中自然消失。一个TCP连接关闭后，可能会出现“迟到的历史数据包”还在网络中游荡，如果立刻用相同IP和端口建立新连接，旧包可能被误认为是新连接的数据。TIME_WAIT保留2MSL，足以让网络中所有属于旧连接的数据包消失。MSL是报文最大生存时间，RFC建议值是2分钟，实际Windows/Unix常用30秒或者60秒，所以TIME_WAIT通常是2MSL即60~120秒。考试不一定考具体数值，但你要知道TIME_WAIT这个状态只会出现在主动关闭的一方。被动方永远不会进入TIME_WAIT，这是很多人忽略的。还有CLOSE_WAIT这个状态，值得单独说一句。CLOSE_WAIT是被动方在回复ACK之后、发送自己的FIN之前的状态，它代表“连接对方已挂断，但我这边应用还没调用close”。如果线上排查时发现一堆CLOSE_WAIT，大概率是应用程序没正确关闭socket，这时候TCP层面已经没救了，要去看代码层面的资源释放。这个问题HCIA不会考太深，但对考完试真正去搞运维的人来说，是迟早要面对的经验。四次挥手另一个常考的点是状态链。主动关闭方：ESTABLISHED→FIN_WAIT_1→FIN_WAIT_2→TIME_WAIT→CLOSED。被动方：ESTABLISHED→CLOSE_WAIT→LAST_ACK→CLOSED。你在做题时看到“服务器出现了大量FIN_WAIT_2”，要能推理出是“服务器主动断开的连接多，而且对方的FIN迟迟没回来”——通常是对端应用卡死了。这种题不是直接背状态名，而是给你一个现象让你反推原因，这也是HCIA如今的出题趋势。5. 端口号的记忆方法，以及那些年年都考的默认端口TCP和UDP都用端口号来区分不同的应用进程。端口号范围0~65535，考试常考的分类是：0~1023：知名端口号，由IANA统一分配，给常见服务使用。1024~49151：注册端口号，给用户或应用程序使用（有些资料也说是记录端口）。49152~65535：动态/私有端口号，客户端临时使用。有些老教材还会写“保留端口号”一说，但HCIA考试更认上面这个三段划分。你要特别注意：客户端发起连接时用的源端口通常是1024以上的临时端口，这点在NAT相关的题目里尤其重要。知名端口的记忆量比较大，我挑HCIA最常考的列个表，考场上撞到概率极高：端口协议服务传输层协议21TCPFTP控制TCP20TCPFTP数据TCP22TCPSSHTCP23TCPTelnetTCP25TCPSMTPTCP53TCP/UDPDNS两者都有67/68UDPDHCP服务端/客户端UDP69UDPTFTPUDP80TCPHTTPTCP443TCPHTTPSTCP161UDPSNMPUDP最容易踩坑的两个：一个是DNS，它既可以用TCP也可以用UDP，平时查询用UDP（为了快，一次请求一次应答就够了），但区域传送和当响应数据超过512字节无法通过单UDP报文承载时，会切换到TCP。考试题干如果说“DNS一定用UDP”，那肯定是错的。另一个是TFTP，很多人看到FTP就写21，但TFTP默认端口是69，而且是UDP上跑的简单文件传输协议。出现“TFTP+UDP+69”这种组合时，你要能反应过来。关于端口号在TCP和UDP中的地位差异，也值得理解：TCP端口是全球唯一的会话标识的一部分（四元组：源IP、源端口、目的IP、目的端口），而UDP端口也一样承担多路复用作用，但因为没有连接概念，它的端口更像“投递地址”。头部格式里两边都有源目端口，就是为了一来一回能对上号。如果只有目的端口没有源端口，接收方回复时就没法知道该发给谁了。6. 可靠的真相：确认、重传、滑动窗口、拥塞控制，一个都不能少TCP的“可靠传输”不是靠某一个机制单独撑起来的，而是确认应答机制、超时重传机制、滑动窗口机制、流量控制机制、拥塞控制机制五者协同的结果。HCIA对这块考得比CCNA略浅，但两者之间没有绝对隔断，你按五层模型复习时不可跳过其中任何一个。先讲确认应答和超时重传。TCP发送方发一个报文后，会启动一个重传计时器；如果在规定时间内没收到确认，就重新发送。超时时间的设定通常比RTT（往返时间）稍微大一点，用来避免因为正常网络延迟而误触发重传。确认应答不是发一个确认一个，TCP允许累积确认——接收方收到连续的几个报文后，只需确认“最后一个连续的字节的序号”，因为确认号已经隐含了更早的数据都收到了。这里有一个让很多人困惑的考点：重传时是重传“一个报文”还是“从丢失的那个及之后所有报文”？经典的Go-Back-N策略是回退重传，丢了一个后面的全重传，效率低；实际TCP用了很多优化，包括选择重传，配合SACK选项只重传丢失的那段。考试如果问你“TCP如何保证可靠性”，你答出“序列号、确认号、重传机制、滑动窗口”就已经够用了，细到SACK一般不深究。再说滑动窗口和流量控制。先理解滑动窗口解决了什么问题：如果发方一股脑把数据全丢出去，接收方处理不过来，只能丢包，丢包又引发重传，效率反而更低。所以TCP里，接收方会告诉发送方“我的接收窗口（rwnd）还有多大”，发送方只能在窗口大小范围内发送数据。数据发出去后，收到确认，窗口就向前滑动。这就是流量控制，目的是“让发送方的速率匹配接收方的接收能力”。值得注意的细节是，窗口值在TCP头部的Window字段里每次握手和数据传输阶段都会更新，如果接收方应用程序没来得及读取数据，接收缓冲区满了，窗口会变成0。发送方收到窗口为0的公告后就会停止发送，并启动持续计时器周期性地探测接收窗口何时恢复。这个机制在考试里出题不多，但你会看到题干中“接收方处理不过来导致丢包”“发送方周期性探测窗口”这类描述，要能落到“流量控制”这个结论上。拥塞控制跟流量控制最大的区别是：流量控制管“对端能收多少”，拥塞控制管“网络能承载多少”。TCP有四个常考的算法阶段：慢启动（Slow Start）：拥塞窗口从1个MSS开始，每收到一个确认就翻倍，指数增长，直到达到慢启动阈值ssthresh。拥塞避免（Congestion Avoidance）：达到ssthresh后，每经过一个RTT拥塞窗口加1，线性增长。快重传（Fast Retransmit）：收到3个重复ACK就立即重传丢失报文，不傻等超时。快恢复（Fast Recovery）：发生丢包后，ssthresh减为当前窗口一半，拥塞窗口从新ssthresh开始执行拥塞避免，而不是回到慢启动的1。HCIA不要求你把每个算法细节写得跟研究论文一样，但你要能描绘一条经典的“拥塞窗口变化曲线”：先指数上升，到阈值后线性上升，丢包时砍半，然后继续线性上升。考试如果考“某个TCP连接发生拥塞避免”，它给RT和ssthresh让你算吞吐变化也是可能的，公式基本就是“超过阈值后每个RTT窗口+1”。这里有个比较容易吃透但很多人却忽略掉的点：拥塞窗口（cwnd）和接收窗口（rwnd）是两回事，发送方实际能发的数据量是两者的最小值。很多资料只画了拥塞窗口曲线，没提接收窗口，导致做题时看到“接收窗口比拥塞窗口小很多”的场景就懵。记住这个min关系，快速定位窗口计算类题目。7. 这些细节看起来冷门，但HCIA偏偏爱出复习到这个程度，TCP/UDP的大部分主干内容你已经过了一遍。接下来我要把“容易漏掉、但实际考试命中率不低”的边角知识点单拎出来说。这些点单看不难，难在它们分散在各种填空题、判断题、选择题的犄角旮旯里。第一个是MSS与MTU。MSS（最大报文段大小）是TCP数据部分能承载的最大长度，MTU（最大传输单元）是链路层能承载的最大数据帧大小。它们之间的关系是：MSS = MTU - IP首部（20字节一般）- TCP首部（20字节）。以传统以太网MTU=1500为例，MSS=1460。TCP在建立连接时，双方会在SYN报文里协商MSS，取较小值使用。考试里常见的干扰项是“MSS越大越好”——并不是，MSS太大导致IP分片，反而增加重传开销和网络负担。第二个是TCP校验和。TCP头部和UDP头部都有校验和字段，覆盖的范围不只是头部，而是“伪头部+TCP/UDP头部+数据”。伪头部包括源IP、目的IP、协议号、TCP/UDP长度。也就是说，传输层校验和会把IP层的一些关键信息一起校验，防止错误投递。UDP的校验和在IPv4下是可选的，但IPv6下是必选的。这个考点如果出现在判断题里，往往是“UDP没有校验和”——严格说UDP有校验和字段，只是在IPv4里可以不启用，考试题如果描述得含糊，你要留个心眼。第三个是TCP紧急指针和URG。紧急指针配合URG标志位使用，表示当前报文中有“必须尽快处理的数据”，这些数据会跳过缓冲区排队逻辑，直接交给应用层。但这种用法在当今实际网络中非常罕见，考试主要是考概念对应关系，别跟PSH弄混就行。第四个是“半关闭（half-close）”。四次挥手并不是要求双方同时各发一个FIN，而是允许一端先关闭发送方向，另一端仍然继续发送数据。这个在文件传输结束后特别常见：客户端发完请求后关闭写方向（发FIN），但还能持续接收服务端推送过来的数据。TCP支持半关闭状态，也就是FIN_WAIT_2之后还能等对端数据。搞懂这个，你才能理解为什么FIN_WAIT_2状态可以长时间存在。第五个是TCPKeepalive。TCP连接建立后，如果长时间没有数据传输，中间路由器或防火墙可能把会话老化删除，从而导致“假连接”。TCP的Keepalive机制会周期性发送探测报文来确认连接是否存活。它跟应用层的心跳是两个概念，但经常会组合考：不是每台设备都默认开启TCP Keepalive，所以在真实项目中，很多应用会在应用层自己做心跳，以此弥补TCP层不可控的Keepalive参数。HCIA对这块要求不高，但如果你未来的职业方向是数通，这点会在面试或证书之后的技术沟通里反复碰到。8. 从复习到实战：实验环境里验证TCP/UDP，胜过背十遍书复习到最后一个环节，我强烈建议你打开模拟器（eNSP之类的虚拟化平台，或者本机装Wireshark抓两个真实包），把前三章的内容自己验证一遍。“看得见”的状态迁移比死记硬背扎实得多。最简单的验证实验是抓三次握手。随便装个Wireshark，在电脑上访问一个HTTP网站，然后在抓包列表里找第一条TCP流，你就能看到：第一个包：Flags=S，Seq=x，源端口是本地临时端口（通常是49152以上的动态端口），目的端口80。第二个包：Flags=S+ACK，Seq=y，Ack=x+1。第三个包：Flags=ACK，Seq=x+1，Ack=y+1。看一次这个表，你就再也不会弄错“Ack等于对方的Seq加1”这件事。顺便你可以在统计菜单里看到整条TCP连接的时间、吞吐、重传次数。如果看到重传次数不是0，你可以把它关联到“超时重传”知识点，比单纯概念复述有效得多。再做一个UDP的验证实验：打开任意一个局域网聊天工具或直播/语音类的应用（如某视频会议软件、某个游戏），看抓包结果，你会发现UDP报文的源目端口跟TCP一样存在，但并没有Seq/Ack字段，后面紧跟着的就是应用层数据。9个字段变成4个字段，直观理解了“UDP头部8字节”。想验证状态迁移，可以起一个本地HTTP服务，用telnet或者netcat测试连接，在Windows上用netstat -ano实时观察连接状态从SYN_SENT到ESTABLISHED再到FIN_WAIT_2/TIME_WAIT的切换。对着netstat的状态变化，心里默算当前处于四次挥手的哪一阶段，训练两三遍后，这部分知识基本就焊死在脑子里了。实验里还有一个容易踩的坑是：如果你用虚拟机做的实验，要注意虚拟网卡的TCP校验和卸载（checksum offload）可能导致Wireshark显示checksum错误。这不是你的实验出问题了，而是网卡把校验和计算放到了硬件层面，抓包软件看不到正确的值。遇到这种情况，去网卡属性里关掉TCP/IP校验和卸载，再重新抓包，显示就正常了。这个坑如果不提前知道，你会怀疑自己配置错了，浪费半小时。9. 考试答题时的几个“保命”判断技巧最后分享几个我在刷题和实际考试里总结出来的答题技巧。HCIA的题库风格总体偏基础，但陷阱也不少，掌握下面几个判断路径，能帮你更稳定地拿分。第一，看到“可靠性”三个字，优先联想到TCP、确认机制、序列号、重传、窗口。看到“实时性”“低延迟”“开销小”这些词，优先想到UDP。题目如果做对比选择题，基本跑不出这个套路。第二，任何牵涉到“端口号范围”的题，先分清题干问的是源端口还是目的端口。目的端口通常是知名端口，源端口往往是随机的高位端口。NAT相关的题尤其容易在这里设坑。第三，状态迁移题，从题干的关键字判断方向。题目出现“服务器”“被动”“不知道客户端的接收能力”“未收到ACK”，你优先想到的是握手第二步或挥手第二步。题目出现“客户端”或“主动方”并且问“此后还能接收数据吗”，想到半关闭。出现“旧的网络报文消失”“保证最后的ACK到达”这种表述，直接定位TIME_WAIT。第四，关于“为什么选择UDP”的场景题，别只答“快”，要答出“无连接、无状态、开销小、时延低、不保证可靠、但适合实时传输”。而且要学会反面验证：“这个场景能不能用TCP？”——如果视频直播的拥塞控制放在TCP里，任何一次丢包都会造成卡顿和重传，体验远不如UDP。所以像视频会议、VoIP、域名查询、DHCP这类场景，用UDP居多。第五，遇到抓包报文分析题，先数两列：Flags列和长度列。Flags里有S就是握手，有F就是挥手，有R就是异常中断。报文长度小于20字节的一定不是TCP，因为TCP头部最少20字节。这个快速过滤法在考场时间紧张时非常管用。复习TCP/UDP这件事，本质上是把“传输层的设计者为什么要这么做”想明白。你想明白了，不是背明白了，考场上就不会慌。这个专题在HCIA里面分量不轻，但远没有到需要发怵的程度，按照上面的思路梳理一遍，配合实验抓包看一看，基本就可以去换下一章了。