- 主题:为啥TCP协议不增加一种“稳定包”传输的模式？
你增加 websocket 的功能，以后写操作系统的就更麻烦了啊。我自己也实现了 websocket 的客户端与服务端，这个协议倒不复杂，但是真正要使用的话，得配合 HTTP 和 SSL 跑在 https 上面才有实用性可言。你说 TCP 做不做？
大家已经不用裸的 TCP，现在大多数在互联网上面跑的都是跑在 SSL 上面了。互联网上面各种对 TCP 进行拦截、监控的。太不安全了。天天被发 RST 包，早晚大家都会迁移到 QUIC 这一类协议上。
【 在 wjhtingerx 的大作中提到: 】
: 不需要的不用就行了呗，增加一种模式方便需要的人用，或者增加一个融合了TCP和UDP的协议。其实就是在内部集成个websocket的功能？
: 你说的TCP离死不远，是因为啥？
: 在 hgoldfish 的大作中提到: 】
: ...................
--
修改:hgoldfish FROM 110.84.122.*
FROM 110.84.122.*
你是不是想说websocket
【 在 wjhtingerx 的大作中提到: 】
: 当然说的是tcp传输的“包”（就是一次send()调用），跟下面MTU啥的没啥关系，要分开要组装都行，只要TCP接收还是一个包就行。
--
FROM 139.227.18.*
SSL就是稳定的，因为是加密的，一点都不能错，否则解不开。
--
FROM 171.213.211.*
你基于UDP自己封装一个呗，为啥非要抱着TCP不放呢
【 在 wjhtingerx 的大作中提到: 】
: 首先强调一下，我懂TCP是“流”，是没有包的概念的，所以回帖不要抓着这个来教育了。
: 我的意思是这种模式，发送端一次发送多大的包，接收端就一次接收多大包。这样就免去了应用需要组数剧、解析协议了，易用很多啊。也不会出现“黏包”这种伪科学了。
--
FROM 120.244.15.18
TCP也可以认为是“稳定”的，因为有校验值，当然不排除恰好传输出错了然后校验值也跟着出错负负得正的情况；
但是如果这样去抠的话，SSL/TLS也存在这种概率，底层 TCP 传输出错，然后恰好解密能继续解出去，虽然概率可能只有亿亿亿分之一
【 在 poocp 的大作中提到: 】
: SSL就是稳定的，因为是加密的，一点都不能错，否则解不开。
--
FROM 114.251.196.*
传输效率的考量吧，包 太大 太小都有对应的问题
【 在 wjhtingerx 的大作中提到: 】
:首先强调一下，我懂TCP是“流”，是没有包的概念的，所以回帖不要抓着这个来教育了。:我的意思是这种模式，发送端一次发送多
- 来自 水木社区APP v3.5.7
--
FROM 101.230.181.*
你自己在tcp上封装不就得了，搞不来还有大把的现成的实现随便挑
--
FROM 111.198.57.*
IPX 比 IP 多了什么？
IP协议没法实现内网互联啊。
不能实现无线到光纤的无缝互联
还是太糙了
【 在 DreamDreams 的大作中提到: 】
: IP 协议长命的 很
: 即使 如你所说离死不远了，那也得 20年起
: 参考IPv4
: ...................
--
FROM 112.66.19.*
KCP了解一下
【 在 wjhtingerx 的大作中提到: 】
: 首先强调一下，我懂TCP是“流”，是没有包的概念的，所以回帖不要抓着这个来教育了。
: 我的意思是这种模式，发送端一次发送多大的包，接收端就一次接收多大包。这样就免去了应用需要组数剧、解析协议了，易用很多啊。也不会出现“黏包”这种伪科学了。
--
FROM 223.70.159.*
协议分层，一个层干一个层的事，你为啥不要求链路层去做你的这个需求，
你这个要求适合会话层，应用层去做，传输层只提供两种通道
【 在 wjhtingerx 的大作中提到: 】
:
: 首先强调一下，我懂TCP是“流”，是没有包的概念的，所以回帖不要抓着这个来教育了。
:
: 我的意思是这种模式，发送端一次发送多大的包，接收端就一次接收多大包。这样就免去了应用需要组数剧、解析协议了，易用很多啊。也不会出现“黏包”这种伪科学了。
#发自zSMTH@XT2153-1
--
FROM 36.21.195.*