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表示发起连接SYNACK同时置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回复SYNACKSeq为自己的初始值yAckx1服务器状态变为SYN_RCVD。客户端收到SYNACK发送ACK报文Acky1此时客户端进入ESTABLISHED服务器收到后也进入ESTABLISHED。最容易出错的地方有两个。第一个是“初始化序列号到底是多少”。因为安全原因现代系统基本都启用随机化初始序列号所以不要再死记x1、y1这种老黄历考试如果给序列号数值要看它是“随机生成的初始值”而不是固定值。第二个是“Ack数值为什么会比序列号大1”。确认号等于对方的序列号加1是因为SYN和FIN报文本身要占一个序列号。虽然它们不携带用户数据但控制信息也要被确认所以这三段握手的关键规律是凡是要被确认的报文占一个序号有效载荷为0但序号要消耗。三次握手里的SYN各占一个号纯粹的ACK不占号。这个规律在做抓包分析题时特别实用。再往深一层三次握手本身就是一次“双向收发能力验证”的过程第一次SYN客户端验证自己的发送能力、服务器的接收能力。第二次SYNACK服务器验证自己的发送能力、客户端的接收能力同时告诉客户端“我收到你了”。第三次ACK客户端告诉服务器“我也收到你了”。当双方都知道“我能发出去你能收到你能发出来我能收到”连接才算建立。这个逻辑在考试中直接表现为“缺了第三次握手行不行”——不行因为服务器不知道客户端是否收到了自己的SYNACK它自己单方面认为能发不可靠。三次握手的状态迁移也是考点密集区。客户端侧的状态链比较简单CLOSED无连接状态→ SYN_SENT已发送SYN→ ESTABLISHED已建立。服务器侧更常考LISTEN监听→ SYN_RCVD收到SYN→ ESTABLISHED。这里有个细节SYN_RCVD是服务器收到SYN但还没有收到最终ACK时的状态如果此时服务器一直等不到客户端的ACK会重传SYNACK直到超时。题外话很多初学者会把SYN_RCVD和SYN_SENT弄反记一个办法——发是主动收是被动状态名描述的是“自己当前处在哪一步”。客户端发出SYN所以是SYN_SENT服务器收到了SYN还没确认对方收到自己回复所以是SYN_RCVD。这样理解就不容易混了。4. 四次挥手TIME_WAIT为什么存在是HCIA最爱挖的坑挥手部分比握手难理解了不止一个台阶。原因在于TCP的连接是“全双工”的也就是说数据允许同时双向流动断开不能一方说断就全断。四次挥手本质上是“两条单向通道分别拆除”的过程。标准流程主动方发送FINSeqm进入FIN_WAIT_1。被动方收到FIN回复ACKAckm1进入CLOSE_WAIT主动方收到ACK后进入FIN_WAIT_2。被动方在自己没有更多数据要发时发送FINSeqn进入LAST_ACK。主动方收到FIN回复ACKAckn1进入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上跑的简单文件传输协议。出现“TFTPUDP69”这种组合时你要能反应过来。关于端口号在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字节。以传统以太网MTU1500为例MSS1460。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流你就能看到第一个包FlagsSSeqx源端口是本地临时端口通常是49152以上的动态端口目的端口80。第二个包FlagsSACKSeqyAckx1。第三个包FlagsACKSeqx1Acky1。看一次这个表你就再也不会弄错“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里面分量不轻但远没有到需要发怵的程度按照上面的思路梳理一遍配合实验抓包看一看基本就可以去换下一章了。