1.TCP/IP与OSI模型1TCP/IP模型应用层为程序提供网络服务。协议HTTPDNS与FTP等传输层提供端到端的通信服务确保数据的可靠传输。协议TCP与UDP网络层负责数据包的路由与转发。协议IP数据链路层建立数据链路连接传输以“帧”为单位的数据包。物理层负责比特流的物理传输。2OSI模型将应用层细分为三层应用层提供网络应用服务。表示层处理数据标识与编码。会话层负责两个通信实体间的建立管理与终止会话。2.三次握手与四次挥手三次握手建立TCP连接四次挥手断开TCP连接。1三次握手问三次握手的基本流程答第一次握手客户端向服务器发送SYN包附带随机序列号请求建立连接。第二次握手服务器收到后返回SYN-ACK包确认序列SYN序列号1 与 自身随机序列号作为应答。第三次握手客户端收到后返回ACK包随机序列号1。问为什么一定要三次握手答第一次握手服务器确认客户端可以发第二次握手客户端确认双方收发能力服务器还不知道客户端能不能收到自己的包。举例如果客户端发送SYN连接请求网络拥塞没有到达服务器客户端超时没收到回复重发SYN但是旧的SYN到达服务器会建立连接服务器空等浪费连接资源。2四次挥手问四次挥手的基本流程答第一次挥手客户端发FIN包给服务器表示客户端不再发送数据。第二次挥手服务器收到后发送ACK包给客户端表示已收到请求。此时服务器可能还有数据没有发送所以不能FIN与ACK一起发送与三次握手不同因此需要进行四次而不是三次第三次挥手服务器完成数据传输后发送FIN包给客户端表示服务器不再发送数据。第四次挥手客户端收到服务器的FIN包后发送ACK包给服务器表示收到请求。3.TCP可靠传输的机制1序列号确认应答ACK发送方为每个传输字节分配唯一序列号接收方收到后返回ACK只有收到合法ACK发送方才能确认接收方已经收到了。2超时重传发送方未在规定时间收到ACK超时就重新发送。3滑动窗口一次性批量发送多个包收到连续ACK后窗口向前挪动。4流量控制接收方在ACK中说明自己接收窗口的大小,发送方调整速率,防止接收方缓存区溢出5拥塞控制慢启动刚开始慢发包指数级增长窗口。拥塞避免到达阈值后线性增长。快重传连续收到三个重复ACK立刻重传不等超时。快恢复丢包后不从头开始快速恢复传输速率。6数据校验和发送方计算数据校验和接收方验证发现数据出错直接丢弃要求重传。4.TCP滑动窗口1概念TCP通信中发送方与接收方之间维护各自接收/发送缓冲区窗口。2流程发送方根据接收方通知的窗口大小来确定发送数据的数量一次性批量发送数据后等待接收方累计确认确认后窗口滑动再发送下一批数据未确认的报文会重传。3优点在保证可靠传输的前提下大幅提升传输效率同时实现流量控制。4举例不需要发一个等ACK再发下一个。例如窗口大小4就一次性发4个1234收到两个ACK12将窗口向前滑动发56。5.UDP与TCP/IP协议的区别区别UDP协议TCP/IP协议连接特性无需握手直接打包发送数据必须三次握手建立连接传输完后四次挥手断开连接可靠性不保证数据可靠传输可能导致丢包与乱序等情况通过多种机制确保数据可靠传输传输效率效率高速度快效率低速度慢报文首部开销8 字节源端口目的端口校验和长度20 - 60字节序列号确认号窗口大小标志位等信息传输方式数据报字节流应用场景实时性要求高视频通话/直播可靠性要求高文件传输6.实现UDP的可靠传输1基础可靠性机制序列号机制接收端按序列号排序并检测丢包。struct PacketHeader { uint32_t seq; // 序列号 uint32_t ack; // 已确认的最大序列号 uint16_t flags; // 标志位如 ACK、SYN、FIN };确认应答机制接收方对收到的数据包发送ACK确认。超时重传为每个未确认的包启动重传定时器。滑动窗口控制发送窗口处理未确认的包接收窗口处理乱序到达的包。2高级优化机制快速重传前向纠错拥塞控制路径MTU发现3协议实现步骤连接管理三次握手四次挥手。数据发送发送端 1. 数据分片 → 打序列号 → 加入发送队列 2. 滑动窗口内包发送 → 启动定时器 3. 收到 ACK → 移动窗口 → 释放缓冲区 4. 超时/重复 ACK → 触发重传 接收端 1. 检查序列号 → 丢弃重复包 2. 缓存乱序包 → 发送 SACK 3. 按序提交数据 → 更新 ACK7.Http协议相关内容1基本概念是基于TCP/IP的应用层协议由请求-响应组成采用客户端-服务器模型用于客户端与服务端之间传输超文本网页、图片、接口数据等。注每次请求独立服务器不会保留之前请求。2Http请求方式GET从指定资源请求数据POST与PUT将数据发送到服务器来创建/更新资源DELETE删除指定资源3Http报文结构1请求报文 请求行(请求方法URL协议版本)请求头(键值对)请求体(POST/PUT提交的数据)2响应报文 响应行(状态码状态描述协议版本)响应头响应体(HTML,JSON等实际数据)4POST与GET区别区别GETPOST传输数据量不大于2KB无限制作用从服务器获取数据向服务器传送数据幂等性幂等多次请求返回结果一致非幂等多次提交可能重复创建数据参数位置参数拼接在URL后面可见参数放在请求体中不可见5Http长连接与短连接1短连接客户端与服务器的每一次请求-响应都会打开一个新的连接。注适用于低频请求简单请求-响应交互与负载均匀的场景。2长连接建立一次连接连续多个请求-响应只有一方明确关闭或者空闲超时才会关闭。注适用于高频请求需要快速响应与实时通信的场景。8.粘包与分包网络通讯中粘包和分包是基于 TCP 协议的数据传输时常见的现象。1粘包当发送的数据量小且发送频率高时TCP协议为提升效率会自动将小数据合并发送。而接收方无法将合并的数据分开就导致本该独立的数据包“粘”在一起。2分包当一次要发送数据量过大由于TCP协议对每次传输的数据量有限制数据会分成几部分发送接收方每次只能接收到部分数据。常见解决方案固定长度报文法发送/接收方都会按固定的长度发送/接收。如果发送长度不足就填充如果发送长度超出就拆分多次发送。添加报文长度法在每个报文前添加一个固定长度来表示报文长度。接收方先读头部长度信息据此接收后面相应长度的数据从而准确解析报文。使用分隔符法在不同报文之间添加特定分隔符接收方通过查找分隔符区分不同报文但要求报文内容不能出现相同的分隔符否则会解析错误。9.帧同步与状态同步1.帧同步同步的是玩家输入指令所有端并行执行相同逻辑服务端仅负责输入转发与校验。2.帧同步流程每个逻辑帧周期内客户端手机玩家指令压缩上传服务器。服务端收集所有玩家的当前帧输入打上全局唯一帧号生成全局输入帧广播给所有客户端。客户端收到后才会执行该帧游戏逻辑。优点操作延迟低宽带要求低支持回放/观战只需要保存输入序列。缺点防作弊弱对逻辑要求高(不确定性会导致多端分歧)。优化方案乐观帧同步网络回滚客户端先做执行逻辑在未收到远端输入时预测若预测错误则回滚对应帧快照客户端用远端传来的真实输入重放后续帧。3.状态同步同步的是游戏状态结果服务端负责游戏逻辑计算客户端表现层渲染。4.状态同步流程客户端玩家按下指令本地预表现同时输入指令上传服务端。服务端收到后做合法性校验再在固定帧中执行完整游戏逻辑得到全局游戏状态。服务端将增量状态变化发生变化的数据广播给视野内的客户端。客户端接收权威服务端权威状态优点防作弊强设备帧数不影响逻辑一致性。缺点服务端成本高操作有延迟宽带要求高回放/观战难实现。