想要不粘，就要一次read能“恰好”读到一整个高层协议的请求/应答
用UDP可以做到啊，但是一个请求不能超过一个UDP报的大小，不能超过一个以太网帧的大
小
那能不能扩大帧的尺寸限制呢，扩到无限大不就可以支持无限大的单个请求了吗？
扩到无限大那怎么进行交换呢，难道全球所有电脑都连接到同一个传输介质上？

二层解决了传输介质的管理，
三层解决了跨网段路由、和二层帧尺寸对应的传输功能，
四层区分了不同服务并提供和三层包尺寸对应的传输管理

在此之上，才存在应用层。先来后到啊，先来的协议自带的限制当然要约束后来的协议，
而不能反过来
--
修改:JulyClyde FROM 222.71.112.*
FROM 222.71.112.*

为啥要啰嗦这么多基础知识？

从某种角度看，协议设计水平是可以分成如下几层：
1.没入门。应届生水平，书上说的分层等都知道怎么用。一聊都是书上说什么什么。
2.刚入门。书上说的东西不但知道怎么样，还知道什么情况不用，比如知道什么时候不分层。熟悉一些书上没有的。常见协议rfc都读过
3.熟手。各种东西差不多都熟悉了，各种协议优缺点抓的准，能做出合格的设计了。
之后还有两层，和现有讨论关系不大不说了

对tcp的批评讨论的参与者，应该至少都是2-3层的水平，一层的知识就没有必要说了。原帖上来和我讨论1层内容的我不回复的

【 在 JulyClyde 的大作中提到: 】
: 想要不粘，就要一次read能“恰好”读到一整个高层协议的请求/应答
: 用UDP可以做到啊，但是一个请求不能超过一个UDP报的大小，不能超过一个以太网帧的大
: 小
: ...................
--
FROM 123.116.207.*

是的，“不粘”这一层应该是tcp上面一层来解决。和tcp无关，让tcp来解决这个问题，是层次没分清楚。

然而这一层很薄，人们懒得写一个通用的，所以大都由应用层实现的人自己去实现。

然而又有很多应用层的实现人员不太懂，没意识到需要自己实现一个包装。所以就“发现”了tcp的这个问题。

【 在 JulyClyde 的大作中提到: 】
: 想要不粘，就要一次read能“恰好”读到一整个高层协议的请求/应答
: 用UDP可以做到啊，但是一个请求不能超过一个UDP报的大小，不能超过一个以太网帧的大
: 小
: ...................
--
FROM 124.64.22.*