嵌入式大厂面经TCP、UDP协议面试常考题目(持续更新中!)

这是一个嵌入式大厂面试题专栏,每天更新高频面试题。专栏将包含题目描述、详细解析、相关知识点扩展以及实际代码示例。内容涵盖操作系统、驱动开发、通信协议等核心领域,并结合实际项目经验进行分析。每道题目都会附带面试官可能的追问方向,帮助大家更好地准备面试!

TCP和UDP面试常考题目总结

1. TCP和UDP的基本概念与区别

Q: TCP和UDP的主要区别是什么?

  • 连接性:TCP是面向连接的协议,通信前需要建立连接;UDP是无连接协议,直接发送数据。
  • 可靠性:TCP提供可靠传输,保证数据完整性和顺序性;UDP不保证可靠传输。
  • 传输方式:TCP是面向字节流;UDP是面向报文。
  • 效率:TCP效率相对较低,有连接管理开销;UDP效率高,开销小。
  • 应用场景:TCP适用于对可靠性要求高的场景;UDP适用于实时性要求高的场景。
  • 头部大小:TCP头部20-60字节;UDP头部固定8字节。

Q: TCP为什么要设计成面向连接的?

  • 确保通信双方都准备好进行数据交换
  • 协商通信参数(如窗口大小、序列号等)
  • 为可靠传输建立基础
  • 提供流量控制和拥塞控制机制

Q: UDP适用于哪些应用场景?为什么?

  • 实时音视频传输:允许少量丢包,重视实时性
  • DNS查询:简单请求-响应模式,减少延迟
  • DHCP:广播通信,简化实现
  • 游戏数据传输:追求低延迟,可接受少量丢包
  • 物联网设备通信:资源受限设备减少协议开销

2. TCP的三次握手和四次挥手

Q: 详细描述TCP三次握手的过程及其意义

  1. 第一次握手:客户端发送SYN包(SYN=1, seq=x),进入SYN_SENT状态
  2. 第二次握手:服务器回复SYN+ACK包(SYN=1, ACK=1, seq=y, ack=x+1),进入SYN_RCVD状态
  3. 第三次握手:客户端发送ACK包(ACK=1, seq=x+1, ack=y+1),双方进入ESTABLISHED状态

三次握手的意义

  • 确认双方的发送和接收能力都正常
  • 同步双方的初始序列号
  • 防止历史连接请求突然到达服务器造成错误

Q: 为什么TCP连接需要三次握手,而不是两次或四次?

  • 两次不够:无法确认客户端的接收能力,可能导致服务器资源浪费
  • 四次多余:三次已经能确认双方的收发能力,额外握手增加延迟和开销
  • 安全性考虑:三次握手可以防止历史连接请求导致的错误连接

Q: 详细描述TCP四次挥手的过程及其意义

  1. 第一次挥手:客户端发送FIN包(FIN=1, seq=u),进入FIN_WAIT_1状态
  2. 第二次挥手:服务器回复ACK包(ACK=1, ack=u+1),进入CLOSE_WAIT状态,客户端进入FIN_WAIT_2状态
  3. 第三次挥手:服务器发送FIN包(FIN=1, seq=v),进入LAST_ACK状态
  4. 第四次挥手:客户端回复ACK包(ACK=1, ack=v+1),进入TIME_WAIT状态,等待2MSL后关闭

四次挥手的意义

  • 确保双方都完成数据传输后再关闭连接
  • 实现全双工连接的单独关闭
  • TIME_WAIT状态确保最后的ACK能到达服务器

Q: 为什么TCP连接关闭需要四次挥手?

  • TCP是全双工通信,每个方向需要单独关闭
  • 接收到FIN后,可能还有数据需要发送,所以先回复ACK,等数据发送完再发FIN
  • 保证双方都能完成数据传输,实现优雅关闭

Q: TIME_WAIT状态的作用是什么?为什么需要等待2MSL?

  • 确保最后一个ACK能到达对方(如果ACK丢失,对方会重发FIN)
  • 防止延迟的数据包被新连接接收,造成数据混乱
  • 2MSL是报文最大生存时间的两倍,足以确保网络中的报文都消失

3. TCP的可靠传输机制

Q: TCP如何保证可靠传输?

剩余60%内容,订阅专栏后可继续查看/也可单篇购买

嵌入式面试八股文全集 文章被收录于专栏

这是一个全面的嵌入式面试专栏。主要内容将包括:操作系统(进程管理、内存管理、文件系统等)、嵌入式系统(启动流程、驱动开发、中断管理等)、网络通信(TCP/IP协议栈、Socket编程等)、开发工具(交叉编译、调试工具等)以及实际项目经验分享。专栏将采用理论结合实践的方式,每个知识点都会附带相关的面试真题和答案解析。

全部评论
1 回复 分享
发布于 03-25 09:08 山西
点赞 回复 分享
发布于 05-18 11:25 天津
😱😱😱😱😱😱😱😱
点赞 回复 分享
发布于 03-26 10:13 上海
很好
点赞 回复 分享
发布于 03-25 16:00 黑龙江

相关推荐

1 移动互联网红利消退,增量市场转为存量竞争:过去十年,客户端开发(尤其是移动端)的爆发式增长得益于智能手机普及和移动互联网红利。然而,据工信部数据,2023年中国移动互联网用户规模已超12亿,渗透率接近饱和,新增用户增速降至个位数。市场从“争夺增量”转向“瓜分存量”,头部应用(如微信、抖音、淘宝)垄断绝大多数流量,新App获客成本飙升。中小厂商难以突围,导致纯客户端岗位需求锐减,企业更倾向于优化现有App而非从零开发新产品,甚至直接依托超级App的小程序生态(如微信、支付宝)降低开发成本。  2 跨端技术崛起,原生开发需求被挤压:为降低多端适配成本,企业普遍采用跨平台技术(如Flutter、React Native、小程序)替代传统原生开发。例如,闲鱼、美团等头部App已通过Flutter实现代码复用率超80%,而微信小程序生态容纳了数百万轻应用,进一步减少独立App的需求。原生客户端开发者若仅掌握平台特定技术(如Swift、Kotlin),竞争力将大幅削弱。即便在需要高性能的场景(如游戏、音视频),跨端方案也通过Skia引擎、原生模块混合开发等方式逐步渗透,原生开发的“护城河”日益收窄。  3 大前端融合趋势下,单一客户端技能价值稀释: 企业对开发者的技术要求从“专精单一平台”转向“全端通吃”。招聘需求中,“客户端+前端”“Android/iOS+小程序”的复合技能成为标配。例如,字节跳动等大厂已推行“大前端”团队模式,开发者需同时应对Web、Native、Hybrid等多种场景。纯客户端开发者若无法扩展技术栈(如学习JavaScript、Node.js),不仅晋升机会受限,还可能因团队结构调整被边缘化。这种趋势使得客户端岗位的“纯粹性”逐渐消失,转而成为大前端领域的一个子集。      
投递蚂蚁集团等公司10个岗位
点赞 评论 收藏
分享
05-06 15:29
东华大学 C++
1. ​分布式订单ID生成? 短时间高并发下如何保证唯一性?我先回答了雪花-like, 上段实习中, 我们项目的全局GUID生成器是我写的, 考虑了短时间内大量产生的情况, 向后借用, 未考虑时钟回拨然后想起来当时和leader讨论,  单独的GUID生成中心, 分批向各个ds批发号段.. 或者是用tacplus的自增id, 但是这样效率太低2. ​CPU 性能瓶颈分析使用 prof 工具监视热点函数的性能消耗3. 上段实习工作内容? 难点?    背包/仓库/道具 ​重构模块追问​:    在两周内重构1万行代码,如何保证代码质量?是否引入单元测试或自动化验证?    10天完成15天任务,如何协调开发与测试资源?是否牺牲技术债?4. 问了一点网络: 网络通信与实时系统视频会议与代码共享的链路设计追问​:解释从你的设备到面试官屏幕的完整网络路径(如NAT穿透、协议选择)5. 游戏服务器同步机制? 和互联网开发的区别服务器作为权威状态源,定期向客户端广播游戏世界的完整或增量状态(如玩家位置、血量)电商无状态服务可通过REST API+RPC横向扩展,而游戏服务器需维护长连接和会话状态。6. 系统设计 分布式事务与最终一致性​游戏道具交易涉及多个系统(背包、仓库、邮件),如何设计分布式事务?对比电商订单支付+库存扣减。​回答方向​:​Saga模式​:将事务拆分为多个可补偿步骤(如“扣道具-发邮件-记录日志”,失败则回滚)。对比:电商更倾向异步消息队列​(如Kafka)实现最终一致性。7. 游戏服务器宕机后如何快速恢复玩家状态?电商系统如何设计类似容灾机制?定时落DB+游戏整体运行在共享内存, 方便resume7. 游戏后端请求链路分析采用自定义的可靠UDP协议​(KCP),平衡延迟与可靠性. 玩家操作(如移动、技能释放)需携带时间戳和操作序列号,用于服务端验证顺序, 请求直达, 客户端直接和服务器感觉面试内容很不"八股", 答得稀里糊涂的, 上面的顺序不是面试提问顺序, 想起来什么说什么, 大家做个参考
查看11道真题和解析
点赞 评论 收藏
分享
评论
3
7
分享

创作者周榜

更多
牛客网
牛客企业服务