- 主题:请教两个二级指针的问题
分片和滑动
都是tcp自己决定的
用户调用send和网卡发数据包出去这中间隔着tcpip和网卡驱动两个大模块
中间差老远呢
【 在 ylh0315 的大作中提到: 】
: 那你说说怎么分片，怎么滑动吧。
: 我学的就是前面这些。
: 报文分片，滑动窗口，到达组装。
: ...................
--
FROM 39.144.251.*
8k的包和滑动窗口多大一点关系没有
【 在 ylh0315 的大作中提到: 】
: 是TCP分片，我也没说是别人。可是TCP分片的对象是什么？
: 面对报文分片。你8k的报文，分几片？窗口有多大？滑得起来吗？
--
FROM 39.144.251.*
你这都哪看来的
你发送和tcp发送不是一一对应的，可以说没什么关系
【 在 ylh0315 的大作中提到: 】
: 滑动窗口缺省8个报片，每个报片MTU/MSS。1460×8，你一个报文装不满一个窗口。
: 我问你怎么滑动。
:
--
FROM 39.144.251.*
tcp是双工系统
你发包，看的是对方的窗口，他滑不滑，你怎么管
【 在 ylh0315 的大作中提到: 】
: TCPIP技术说明书呀。
: 我没说一一对应，但绝对有关系。
: 绝对不可能比你发的电文大。你发的小电文，窗口绝对滑动不起来。
--
FROM 39.144.251.*
tcp和应用层的分包没有任何关系
目的完全不同
并且应用层完全不用考虑tcp怎么发
任何控制频率控制包大小，试图影响tcp行为的做法
都是多余的
只需要尽快把包扔给tcp就行了
【 在 ylh0315 的大作中提到: 】
: 哦，你说的是做手动分包，8k8k的？
: 多麻烦呀。别分了，让TCP去自动分包，自动合并，多省事。
--
FROM 39.144.251.*
你自己的窗口开多大，表示飘在网络上没ack的数据有多少
飘了多少受制于对方的收包速度和网络速度
这东西和你一次写多少数据进去有什么关系
内存的操作速度一定是远远大于网速的
不会出现tcp想发，而缓冲区没数据的情况
tcp已经满负荷工作了，他的速度就是网络的速度
和你调用send一次放多少根本没关系的
【 在 ylh0315 的大作中提到: 】
: 报文大了就滑，小了就不滑，有什么怀疑吗？
--
FROM 39.144.251.*
应用层分包不是为了tcp
本来这事和tcp一毛钱关系也没有
也不存在什么8k的包会比100k慢的事
【 在 ylh0315 的大作中提到: 】
: 就是。用户给我多大，我就扔给TCP多大。大小的事，不归我管，让TCP去分吧。
--
FROM 39.144.251.*
网络能不能跑满，
看你单位时间给了多少数据
而不是看你调用了多少次每次多少
这是很简单的逻辑
【 在 ylh0315 的大作中提到: 】
: 每次send的数据太少，根本就占不满网络，你测一下吧。
: 我做的是交易中间件，基本一问一答，一个远过程调用完成一个交易，一个交易会产生大量数据。这跟你的应用场景不同，进一步争论没有太大意义。
--
FROM 39.144.251.*
因为你怎么发，他都能过去
你画蛇添足搞个mtu的判断，他当然能过去了
【 在 ylh0315 的大作中提到: 】
: 查了下，MTU自己处理的，自动分片。试验过，有效。能够通过糟糕的路由器。
: int SendNet(int socket,char *buf,int n,int MTU)
: {
: ...................
--
FROM 39.144.251.*
你说的mtu到底是什么，你自己都倒腾不清楚
有什么可讨论的
【 在 ylh0315 的大作中提到: 】
: 没有这个MTU，当年真过不去，要么凭啥画蛇添足。
: 不过此MTU非彼MTU，它恰恰破坏了滑动窗口，造成慢。
: 假如MTU设成8k，就成了你的。就可以见证用你的限制传输得多慢。
: ...................
--
FROM 39.144.251.*