ShowDocs
搜索文章Ctrl K

外观

← 返回计算机网络原理列表
层次与端到端机制

TCP字节流、可靠传输与网络排错 ​

协议分层、寻址与TCP字节流 ​

前置：理解字节流、字节序、客户端与服务端；Python 3.10+ 用于四字节长度前缀解码模型，不要求真实网络。教学范围为TCP RFC9293；分层与字节流；Python 3.10+。核对日期2026-10-17。示例未执行，本轮没有安装依赖、生成协议代码、启动服务或浏览器预览。完整文件与输入见长度前缀解码器与拆包练习；推演结论只适用于写明的模型。

协议分层与封装 ​

把订单消息放入TCP字节流，再装入IP包与链路帧，是概念上的封装关系；实际分段大小不必等于应用消息大小。路由器取出IP层信息决定下一跳，并重新封装本跳链路帧。

查看图表代码

协议分层与封装应区分对等实体的逻辑协议和本机层间服务。应用报文交给传输层，再封装进IP与链路帧；路由器通常转发IP分组，不会替应用解释订单。上层可依赖下层提供的能力，但不能把链路校验当端到端业务正确性。

地址端口与路由 ​

地址端口与路由分别回答到哪台主机、哪个通信端点和下一跳。最长前缀匹配选择路由，端口由传输协议参与分用；同一个数字端口的TCP和UDP是不同空间。DNS解析成功不能证明端口可连，端口可连也不能证明认证通过。

TCP为何没有消息边界 ​

发送两条消息abc和de，接收方可能先读到a，再读到bcde。TCP只保证字节顺序；长度前缀解码器必须先凑齐头部，再按字节数等待负载，而非把每次recv当成一条消息。

查看图表代码

TCP为何没有消息边界：它向应用提供有序字节流，发送一次的数据可能分多次读取，多次发送也可能一次读到。分帧由应用完成；本文以四字节大端长度前缀表示UTF-8消息，前缀长度指字节数，不能用字符数替代。

来源与适用边界 ​

TCP可靠传输、流控与连接关闭 ​

TCP重传与确认含义 ​

假定首个数据字节序号为100，发出3个字节后接收端期待103，因此ACK为103。如果确认丢失，发送端可能重发相同字节范围，接收端通过序号去重；应用业务提交是此后另一个层次的事件。

查看图表代码

TCP重传与确认含义针对序号空间中的字节交付，不证明业务提交。响应丢失时服务可能已扣款，客户端只能知道没有拿到结果，不能因超时就认定未执行。应用需要请求标识与结果查询来处理不确定性。

流量控制与拥塞控制 ​

简化为以字节计的两个窗口时，允许在途量上限近似取min(rwnd,cwnd)。例如rwnd=64KiB、cwnd=16KiB且已有12KiB未确认，新发送空间最多约4KiB；实际还受发送缓冲、算法和协议细节约束。

查看图表代码

流量控制与拥塞控制保护不同对象。接收窗口表达接收方缓存能力，拥塞窗口限制在途数据对路径的压力，发送受两者共同限制。增加接收缓存不能必然修复拥塞；公平和吞吐还受RTT、丢包及算法影响。

连接关闭与半关闭 ​

请求方可以结束自己的发送方向后继续读取响应。收到FIN意味着该方向字节结束，接收端还可以发送自己的剩余数据；如果长度头声明10字节却只收8字节就EOF，应判为应用消息截断。

查看图表代码

连接关闭与半关闭按方向考虑：一方结束发送，不代表不能继续接收。收到EOF表示字节流该方向结束，若应用帧还剩半个头部或半个负载，应报告截断。连接超时与收到显式关闭也不是相同证据。

来源与适用边界 ​

网络超时、带宽时延积与排错 ​

网络超时证据边界 ​

下面的提交已经发生，但客户端只看到超时。安全恢复通常使用同一请求标识查询结果或执行幂等重试；换一个新标识再次提交，可能把一次业务变成两次。仅靠客户端超时日志无法排除另一种情况：原请求根本没到服务端。

查看图表代码

网络超时证据边界是未在期限内观测到结果，可能是请求丢失、处理慢或响应丢失。不能把未知状态替换成失败后直接重试有副作用操作。画出发送、提交、响应三事件，指出哪一步有证据，才能讨论恢复。

带宽时延积与队列 ​

100Mbit/s与100ms RTT的乘积为10Mbit，约1.25MB。若在途窗口仅125KB，忽略其他限制时吞吐上限约10Mbit/s；但无界增大缓冲会增加排队，并不能无限提升瓶颈带宽。

查看图表代码

带宽时延积与队列刻画不同成本：链路带宽乘RTT近似填满路径所需在途数据量，过大缓存可能增加排队时延。吞吐高不意味着交互延迟低；应写明测量窗口、负载与分位数，本轮没有网络实测。

网络规范与旧笔记 ​

网络规范与旧笔记以RFC9293约束TCP语义，中文MDN帮助理解应用交互。历史自考网络笔记仍可查分层与交换；本课程不把五层教学模型说成每个实际实现都严格对应五个独立模块。

来源与适用边界 ​

继续阅读