Summary 前面几篇我们一直在讲"怎么把一堆字节可靠地送到对面"。TCP 把这件事做完了,但它送过去的只是一串没有含义的字节流，至于这些字节怎么表示,TCP 完全不关心。 应用层协议要补的就是这个:给字节流赋予含义。HTTP 定义了一套双方都认的规矩——请求长什么样、响应长什么样、哪些字段表示什么意思。 HTTP...

Summary 在网络中发送消息又一个前提:需要知道对方的 IP 地址。TCP 要 IP 才能握手,TLS 要 IP 才能连接。 可你在浏览器里敲的是 github.com,在代码里写的是 https://eth-mainnet.g.alchemy.com——这些名字对网络层毫无意义,IP 包的头部里只有...

Summary 前面几篇,我们看着 TCP 一层层往上搭:序号、确认、重传、排序、去重、流量控制、拥塞控制。每一样都是为了同一个目标——让应用拿到一段完美的字节流。 现在换个角度问:这些保障,是不是每个应用都想要? 答案是否定的,而且否定得很彻底。看几个场景: 视频通话丢了一帧,你希望它重传吗?不。等重传的那...

Summary 上一篇讲清了 TCP 怎么保证"不丢不乱",但留了个关键的空:发送方一次能往外扔多少数据? 这个数字定小了,带宽白白浪费;定大了,轻则把接收方撑爆,重则把整个网络堵死。而且它还不能是个固定值——网络状况和对方的处理能力时时刻刻都在变。 TCP 的答案是同时受两个"刹车"约束: 流量控制(flow...

上一篇我们提到,网络层的IP协议是"尽力而为"的——它会丢包、乱序、重复、损坏,却什么都不保证。而你用 Go 写 conn.Read,拿到的却是一段完整、有序、正确的字节流。这中间的落差,全靠 TCP 的一套可靠传输机制填平。这套机制的思想(编号、确认、超时重传、去重),不只是网络知识,更是一切"在不可靠信道上做可靠通...