[TL]TCP建立连接为什么是三次握手？{技术}{网络通信}
up duan
为什么链接建立阶段采用三次握手机制？
先约定两个名字。A代表链接建立的发起方，B代表链接建立的接受方。
三次握手是指A向B发送一个Sync，B向A回送Ack+Sync，A再向B发送Ack，这样一个过程。
通过这个过程，TCP的全双工的虚电路服务就建立起来了。
为什么是三次握手？
我认为原因是TCP链接逻辑上区分成两个通道，一个通道用于A-》B，另一个通道用于B-》A。这一点从链接建立阶段看不明晰，但是链接拆除阶段非常清楚。我们知道TCP链接的拆除是所谓的优雅拆除，任何一方都可以拆除自己发往对方数据的那个通道，而同时还要保证对方发往自己的数据能被正常处理。所以TCP链接拆除就要经历一个半链接的阶段。用四个协议数据包进行拆除。
再回过头看看链接建立阶段，就非常明确的看出来，这三次握手确实是用于建立这个链路上的两个通道的。
那么为什么要三次握手？最近看到弯曲评论上有一篇文章，说TCP链接甚至可以建立半链接，也就是只建立一个通道，数据只能单向流动。这时候的三次握手就退化成两次握手，一次Sync以及一个对应的Ack。［同时文章指出，Socket API并没有提供建立半链接的能力，但是下层的协议确实具有］
所以说三次握手也不是必需的。
我们暂且不关心建立半链接。
究竟为什么需要三次握手？
从逻辑上讲，三次握手是最省的建立TCP链路［两个通道］规程机制了，所以就应该三次握手。
但是，实际上我们必须进行三次握手么？我们知道UDP是数据报服务，也就是无连接的服务。其实无连接的服务也可以看作某种连接服务，比如：看做链接建立、数据传输、链接拆除在一个协议数据包中完成的快速短暂链接服务。这就是说，我们可以复用数据包。有了这个启示，我们就可能对三次握手进行更进一步的优化，实际上，可以优化到没有任何纯协议数据包，只有业务数据包，只要把这几个协议数据包复用于初始数据传输包即可。
但是为什么TCP链接要三次握手进行建立？
我个人认为其实没有理由非得如此。不过我们可以通过TCP的拥塞控制机制得到一些启示。TCP的拥塞控制由“慢启动(Slow start)”和“拥塞避免(Congestion avoidance)”，“快速重传(Fast retransmit)”、“快速恢复(Fast Recovery)”，选 择性应答( selective acknowledgement,SACK)等一系列机制组成的。其中慢启动是TCP链接建立以后，开始发送数据时的策略。为了避免TCP拥塞，采用缓慢提高TCP数据传输速率的办法。所以三次握手我猜想也是为了减缓TCP链接的建立，就如同古代的击鼓伸冤，你可以击鼓伸冤，但在此之前你得过好几关，比如跪带刺的铁板凳等等……，这样的目的是为了提高击鼓伸冤的门槛，免的有人恶意的利用这种机制——除非你愿意为你的冤情付出相应的代价［这也说明冤情沉重］，否则你的冤屈不必申述。
当然，有人说三次握手是为了约定初始序号（ISN，Initial Sequence Number，这儿的序号并不是按照数据包自然数序排列的，其实叫成偏移Offset更合理，因为它其实是指出这个包携带的数据在整个TCP数据流中的偏移量的，也就是说，如果一个包序号为x，而携带的数据长度为y，那么下一个包的序号为x + y，如果达到了最大值，就绕到0那儿开始回环。顺便说一句，最初序号是32bit的，现在提升到64bit了，因为要保证协议栈能识别出相同序号的不同的包，不能溢出回环的太快，否则ack的语义不清晰），这当然是对的，三次握手确实约定了初始序号，但是约定初始序号不是为什么是三次握手的原因。实际上正如我前面所说的，没有握手也可以约定初始序号。［在网上找到这样一篇论文，内容看不了，但应该大致跟我的复用数据包的设想差不多，地址：http://d.wanfangdata.com.cn/Periodical_czsfgdzkxxxb200902019.aspx］
归根结底，TCP链接的建立、使用、拆除三阶段是清晰的分离的，链接建立阶段是独立的，也不能用于传递数据，当然，数据传递阶段也没有建立链接的功能。
那么现在还是那个问题：为什么需要三次握手？
Yang Chi
On Mar 10, 5:15 pm, up duan <fixo...@gmail.com> wrote:
> TCP是基于IP的虚电路可靠的全双工通信服务，基本上可以分为链接建立，数据传输，链接拆除三个阶段。
>
> 为什么链接建立阶段采用三次握手机制？
>
> 先约定两个名字。A代表链接建立的发起方，B代表链接建立的接受方。
>
> 三次握手是指A向B发送一个Sync，B向A回送Ack+Sync，A再向B发送Ack，这样一个过程。
> 通过这个过程，TCP的全双工的虚电路服务就建立起来了。
> 为什么是三次握手？
> 我认为原因是TCP链接逻辑上区分成两个通道，一个通道用于A-》B，另一个通道用于B-》A。这一点从链接建立阶段看不明晰，但是链接拆除阶段非常清楚。我们知道TCP链接的拆除是所谓的优雅拆除，任何一方都可以拆除自己发往对方数据的那个通道，而同时还要保证对方发往自己的数据能被正常处理。所以TCP链接拆除就要经历一个半链接的阶段。用四个协议数据包进行拆除。
> 再回过头看看链接建立阶段，就非常明确的看出来，这三次握手确实是用于建立这个链路上的两个通道的。
> 那么为什么要三次握手？最近看到弯曲评论上有一篇文章，说TCP链接甚至可以建立半链接，也就是只建立一个通道，数据只能单向流动。这时候的三次握手就退化成两次握手，一次Sync以及一个对应的Ack。［同时文章指出，Socket
> API并没有提供建立半链接的能力，但是下层的协议确实具有］
> 所以说三次握手也不是必需的。
> 我们暂且不关心建立半链接。
> 究竟为什么需要三次握手？
> 从逻辑上讲，三次握手是最省的建立TCP链路［两个通道］规程机制了，所以就应该三次握手。
> 但是，实际上我们必须进行三次握手么？我们知道UDP是数据报服务，也就是无连接的服务。其实无连接的服务也可以看作某种连接服务，比如：看做链接建立、数据传输、链接拆除在一个协议数据包中完成的快速短暂链接服务。这就是说，我们可以复用数据包。有了这个启示，我们就可能对三次握手进行更进一步的优化，实际上，可以优化到没有任何纯协议数据包，只有业务数据包，只要把这几个协议数据包复用于初始数据传输包即可。
> 但是为什么TCP链接要三次握手进行建立？
> 我个人认为其实没有理由非得如此。不过我们可以通过TCP的拥塞控制机制得到一些启示。TCP的拥塞控制由"慢启动(Slow
> start)"和"拥塞避免(Congestion avoidance)"，"快速重传(Fast retransmit)"、"快速恢复(Fast
> Recovery)"，选 择性应答( selective
> acknowledgement,SACK)等一系列机制组成的。其中慢启动是TCP链接建立以后，开始发送数据时的策略。为了避免TCP拥塞，采用缓慢提高TCP数据传输速率的办法。所以三次握手我猜想也是为了减缓TCP链接的建立，就如同古代的击鼓伸冤，你可以击鼓伸冤，但在此之前你得过好几关，比如跪带刺的铁板凳等等......，这样的目的是为了提高击鼓伸冤的门槛，免的有人恶意的利用这种机制----除非你愿意为你的冤情付出相应的代价［这也说明冤情沉重］，否则你的冤屈不必申述。
YunjingXu
http://en.wikipedia.org/wiki/Two_Generals'_Problem
就很容易明白为什么三次握手是必须的了.
这个问题的本质是, 通过一个不完全可靠的信道, 最少需要几次消息传输, 信道两边的人能够对一个问题达成一致. 对于TCP来说, 无论有没有初始
序号的要求, 想要两边都同意开始传出数据, 就至少需要3次消息的交换:
0次: 显然不行
1次: A->B, A不知道B是否同意
2次: A->B, B->A. B不知道A是否收到自己的消息, 因为信道不完全可靠
3次: A->B, B->A, A->B. 两边都收到了对方的ACK, 意味着各自都了解了对方的意图, 从而可以对是否开始通信这个最简单的问题
达成一致.
On Mar 10, 5:15 pm, up duan <fixo...@gmail.com> wrote:
> TCP是基于IP的虚电路可靠的全双工通信服务，基本上可以分为链接建立，数据传输，链接拆除三个阶段。
>
> 为什么链接建立阶段采用三次握手机制？
>
> 先约定两个名字。A代表链接建立的发起方，B代表链接建立的接受方。
>
> 三次握手是指A向B发送一个Sync，B向A回送Ack+Sync，A再向B发送Ack，这样一个过程。
> 通过这个过程，TCP的全双工的虚电路服务就建立起来了。
> 为什么是三次握手？
> 我认为原因是TCP链接逻辑上区分成两个通道，一个通道用于A-》B，另一个通道用于B-》A。这一点从链接建立阶段看不明晰，但是链接拆除阶段非常清楚。我们 知道TCP链接的拆除是所谓的优雅拆除，任何一方都可以拆除自己发往对方数据的那个通道，而同时还要保证对方发往自己的数据能被正常处理。所以TCP链接拆除就 要经历一个半链接的阶段。用四个协议数据包进行拆除。
> 再回过头看看链接建立阶段，就非常明确的看出来，这三次握手确实是用于建立这个链路上的两个通道的。
> 那么为什么要三次握手？最近看到弯曲评论上有一篇文章，说TCP链接甚至可以建立半链接，也就是只建立一个通道，数据只能单向流动。这时候的三次握手就退化成两 次握手，一次Sync以及一个对应的Ack。［同时文章指出，Socket
> API并没有提供建立半链接的能力，但是下层的协议确实具有］
> 所以说三次握手也不是必需的。
> 我们暂且不关心建立半链接。
> 究竟为什么需要三次握手？
> 从逻辑上讲，三次握手是最省的建立TCP链路［两个通道］规程机制了，所以就应该三次握手。
> 但是，实际上我们必须进行三次握手么？我们知道UDP是数据报服务，也就是无连接的服务。其实无连接的服务也可以看作某种连接服务，比如：看做链接建立、数据传 输、链接拆除在一个协议数据包中完成的快速短暂链接服务。这就是说，我们可以复用数据包。有了这个启示，我们就可能对三次握手进行更进一步的优化，实际上，可以 优化到没有任何纯协议数据包，只有业务数据包，只要把这几个协议数据包复用于初始数据传输包即可。
> 但是为什么TCP链接要三次握手进行建立？
> 我个人认为其实没有理由非得如此。不过我们可以通过TCP的拥塞控制机制得到一些启示。TCP的拥塞控制由"慢启动(Slow
> start)"和"拥塞避免(Congestion avoidance)"，"快速重传(Fast retransmit)"、"快速恢复(Fast
> Recovery)"，选 择性应答( selective
> acknowledgement,SACK)等一系列机制组成的。其中慢启动是TCP链接建立以后，开始发送数据时的策略。为了避免TCP拥塞，采用缓慢提高T CP数据传输速率的办法。所以三次握手我猜想也是为了减缓TCP链接的建立，就如同古代的击鼓伸冤，你可以击鼓伸冤，但在此之前你得过好几关，比如跪带刺的铁板 凳等等......，这样的目的是为了提高击鼓伸冤的门槛，免的有人恶意的利用这种机制----除非你愿意为你的冤情付出相应的代价［这也说明冤情沉重］，否则你的冤屈不必 申述。
> 当然，有人说三次握手是为了约定初始序号（ISN，Initial Sequence
> Number，这儿的序号并不是按照数据包自然数序排列的，其实叫成偏移Offset更合理，因为它其实是指出这个包携带的数据在整个TCP数据流中的偏移量的 ，也就是说，如果一个包序号为x，而携带的数据长度为y，那么下一个包的序号为x
> +
> y，如果达到了最大值，就绕到0那儿开始回环。顺便说一句，最初序号是32bit的，现在提升到64bit了，因为要保证协议栈能识别出相同序号的不同的包，不 能溢出回环的太快，否则ack的语义不清晰），这当然是对的，三次握手确实约定了初始序号，但是约定初始序号不是为什么是三次握手的原因。实际上正如我前面所说 的，没有握手也可以约定初始序号。［在网上找到这样一篇论文，内容看不了，但应该大致跟我的复用数据包的设想差不多，地址：http://d.wanfangdata.com.cn/Periodical_czsfgdzkxxxb200902019.aspx］
郑培祥
此致
敬礼！
郑培祥
--
Zheng PeiXiang
C++, JAVA, PYTHON, NLP, Semantic Role Labeling
Blog :zheng-peixiang.appspot.com
Twitter: http://twitter.com/zhpx
up duan
这是通信当中的基本问题, 看明白Two Generals' Problem:
http://en.wikipedia.org/wiki/Two_Generals'_Problem
就很容易明白为什么三次握手是必须的了.
这个问题的本质是, 通过一个不完全可靠的信道, 最少需要几次消息传输, 信道两边的人能够对一个问题达成一致. 对于TCP来说, 无论有没有初始
序号的要求, 想要两边都同意开始传出数据, 就至少需要3次消息的交换:
0次: 显然不行
1次: A->B, A不知道B是否同意
2次: A->B, B->A. B不知道A是否收到自己的消息, 因为信道不完全可靠［这儿A已经可以确信信道是可靠的了，只是B不能确信而已，这儿你要是把信道当成TCP链接本身，也就是全双工，自然如此，但是像我这样把链路分成两个方向上的信道的人来说，却不是如此。并且TCP确实可以建立半链接］
3次: A->B, B->A, A->B. 两边都收到了对方的ACK, 意味着各自都了解了对方的意图, 从而可以对是否开始通信这个最简单的问题
达成一致.
实际上，四次握手也可以。比如A---Sync--->B, B---Ack--->A, B---Sync--->A, A----Ack--->B。这初看起来似乎比三次握手傻，但是提供了更强的灵活性，因为可以异步的建立起两个通道，而且按照我上一篇的分析，这些握手的纯协议包可以并入到第一个数据包中以降低消耗，反而更有优势。
所以，我还是没有搞清楚为什么TCP这个特定的实现为什么非得要三次握手？因为实际上当时就问我：它［TCP］不能像UDP那样么？
上篇中我也说逻辑上需要三次握手，但实现上可以不需要。如果问到TCP这个特定的通信实现为什么是三次握手，我还是回答不上来。
soulmachine
http://www.verycd.com/topics/2778762/
On Mar 11, 9:51 am, up duan <fixo...@gmail.com> wrote:
> 2010/3/11 YunjingXu <yunjin...@gmail.com>
>
> > 这是通信当中的基本问题, 看明白Two Generals' Problem:
> >http://en.wikipedia.org/wiki/Two_Generals'_Problem<http://en.wikipedia.org/wiki/Two_Generals%27_Problem>
YunjingXu
三次握手的要求不是源于两边同时传输数据, 你看过Two Generals' Problem就能明白, 三次握手作为一个协议, 并不特定于
TCP, 跟两边同时传输数据也没有关系. 请不要纠缠于什么全双工, 半连接, syn/ack这些东西上. 至于你说的把握手协议并在第一个数据包
里发送之类的, 那只是实现时的优化, 跟"三次"问题的核心没有关系. 实现是实现, 协议是协议, 这是两个东西. 你单独有个握手协议也好, 握
手包含在真正的数据包里也行, 但无论如何, 没有至少三次握手, 任何的数据交换都是不可靠的.
所以, 这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是
理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,
信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可
靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了.
On Mar 10, 8:51 pm, up duan <fixo...@gmail.com> wrote:
> 2010/3/11 YunjingXu <yunjin...@gmail.com>
>
> > 这是通信当中的基本问题, 看明白Two Generals' Problem:
> >http://en.wikipedia.org/wiki/Two_Generals'_Problem<http://en.wikipedia.org/wiki/Two_Generals%27_Problem>
> > 就很容易明白为什么三次握手是必须的了.
>
> > 这个问题的本质是, 通过一个不完全可靠的信道, 最少需要几次消息传输, 信道两边的人能够对一个问题达成一致. 对于TCP来说, 无论有没有初始
> > 序号的要求, 想要两边都同意开始传出数据, 就至少需要3次消息的交换:
> > 0次: 显然不行
> > 1次: A->B, A不知道B是否同意
> > 2次: A->B, B->A. B不知道A是否收到自己的消息, 因为信道不完全可靠
> > ［这儿A已经可以确信信道是可靠的了，只是B不能确信而已，这儿你要是把信道当成TCP链接本身，也就是全双工，自然如此，但是像我这样把链路分成两个方向上的 信道的人来说，却不是如此。并且TCP确实可以建立半链接］
> > 3次: A->B, B->A, A->B. 两边都收到了对方的ACK, 意味着各自都了解了对方的意图, 从而可以对是否开始通信这个最简单的问题
> > 达成一致.
>
> > 三次握手的原理是确保："两边都同意开始传出数据,"
>
> ，TCP可以是这样的，也可以是半链接的。所以，三次握手是两边都同时传输数据的要求但是不是TCP强制要求的。
>
> 实际上，四次握手也可以。比如A---Sync--->B, B---Ack--->A, B---Sync--->A,
> A----Ack--->B。这初看起来似乎比三次握手傻，但是提供了更强的灵活性，因为可以异步的建立起两个通道，而且按照我上一篇的分析，这些握手的纯协议 包可以并入到第一个数据包中以降低消耗，反而更有优势。
Hongzhang Liu
up duan
No...
三次握手的要求不是源于两边同时传输数据, 你看过Two Generals' Problem就能明白, 三次握手作为一个协议, 并不特定于
TCP, 跟两边同时传输数据也没有关系. 请不要纠缠于什么全双工, 半连接, syn/ack这些东西上. 至于你说的把握手协议并在第一个数据包
里发送之类的, 那只是实现时的优化, 跟"三次"问题的核心没有关系. 实现是实现, 协议是协议, 这是两个东西. 你单独有个握手协议也好, 握
手包含在真正的数据包里也行, 但无论如何, 没有至少三次握手, 任何的数据交换都是不可靠的.
所以, 这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是
理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,
信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可
靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了.
YunjingXu
On Mar 11, 12:53 am, up duan <fixo...@gmail.com> wrote:
> 2010/3/11 YunjingXu <yunjin...@gmail.com>
>
up duan
jinhu wang
孙朝阳
---------------------------------------
绝圣弃知，大盗乃止；擿玉毁珠，小盗不起；
孙朝阳
---------------------------------------
绝圣弃知，大盗乃止；擿玉毁珠，小盗不起；
两军问题根本不能解释为什么要三次握手。两军问题的一个结论就是，在不可信的信道上，不可能实现完全可信的通信。事实上，握手的次数只是增加可信程度，三次握手后，再增加握手次数已经不能再增加可信度了。
在一个高可靠信道，例如局域网，第三次ack就很多余了。如果你原始信道的可靠性更高，完全可以连握手都不要，用错误回复的办法来解决问题。
Hongzhang Liu
石奇偲
为什么不是2次也不是4次？是在 连接的可靠性和性能 上的平衡。握手次数本来就是比较灵活的问题，但是作为协议必须确定。并不会适合所有的情况。
另外，觉得楼主的因果关系比较模糊。
现行的tcp协议每次握手的时候具体的通信协议细节，是为三次握手特别设定的。
假如当时设定的是四次握手，它的第三次握手的内容就不会和现在三次握手的时候第三次的内容一样了。
所以楼主没有必要从第一，第二，第三次握手的具体细节来思考为什么偏偏是三这个数字。
up duan
这篇文章没看出啥新的东西来，原文描述的在TCP/IP详解卷一中有很清楚的论述，即TCP的同时打开。
同时打开是指通信双方同时发送Sync到对方么？
那么同时打开只是一个概率事件啊，怎么能作为一种机制增加链接建立的稳定度呢?
up duan
是啊，感觉三次握手有制定协议的时候网络实际状况的原因在里面。
为什么不是2次也不是4次？是在 连接的可靠性和性能 上的平衡。握手次数本来就是比较灵活的问题，但是作为协议必须确定。并不会适合所有的情况。
另外，觉得楼主的因果关系比较模糊。
现行的tcp协议每次握手的时候具体的通信协议细节，是为三次握手特别设定的。
假如当时设定的是四次握手，它的第三次握手的内容就不会和现在三次握手的时候第三次的内容一样了。
所以楼主没有必要从第一，第二，第三次握手的具体细节来思考为什么偏偏是三这个数字。
在 2010年3月11日 下午3:10，孙朝阳 <wing...@gmail.com>写道：这个在工程中有例证，有些跑在互联网上的UDP协议，握手就很简单（没有独立的握手过程，直接send+ack。逻辑上最多也就分为两次），照样工作的很好。
孙朝阳
---------------------------------------
绝圣弃知，大盗乃止；擿玉毁珠，小盗不起；
2010/3/11 石奇偲 <shiq...@gmail.com>是啊，感觉三次握手有制定协议的时候网络实际状况的原因在里面。
为什么不是2次也不是4次？是在 连接的可靠性和性能 上的平衡。握手次数本来就是比较灵活的问题，但是作为协议必须确定。并不会适合所有的情况。协议说可以三个或者四个协议包建立TCP链接。另外，觉得楼主的因果关系比较模糊。
现行的tcp协议每次握手的时候具体的通信协议细节，是为三次握手特别设定的。
假如当时设定的是四次握手，它的第三次握手的内容就不会和现在三次握手的时候第三次的内容一样了。
所以楼主没有必要从第一，第二，第三次握手的具体细节来思考为什么偏偏是三这个数字。其实确实如此，我只是是在不知道为什么非得是三次握手才能建立TCP链接而已。大家的分析都很到位，但是其实很难去应付一个有特定答案的主考官：）
Hongzhang Liu
2010/3/11 Hongzhang Liu <hongzh...@gmail.com>这篇文章没看出啥新的东西来，原文描述的在TCP/IP详解卷一中有很清楚的论述，即TCP的同时打开。我没有看到原文，我原猜想他可能采用把建立链接的协议包合并进数据包了呢。
同时打开是指通信双方同时发送Sync到对方么？
那么同时打开只是一个概率事件啊，怎么能作为一种机制增加链接建立的稳定度呢?
Hongzhang Liu
up duan
我觉得你搞错了我说的文章。
up duan
哦？敢问更高效的建立连接的方式？另外，TCP的效率难道是由三次握手决定的么？
说的是TCP链接建立的效率，不是TCP数据传输的效率。谁也没有说TCP的效率是由三次握手决定的。
Hongzhang Liu
Hongzhang Liu
RuiFeng Shan
我觉得在目前的网络框架下，三次握手没有落伍。它仍不失为一个好方法。
孙朝阳
---------------------------------------
绝圣弃知，大盗乃止；擿玉毁珠，小盗不起；
哦？敢问更高效的建立连接的方式？另外，TCP的效率难道是由三次握手决定的么？
张慧聪
其实无论几次握手都不能保证绝对可靠，就选个不多不少的三好了。
假定A和B通信，第一次握手由B发给A，B不知道A有没收到，要等A回复，可是A回复了又不知道B有没收到，要等B回复，B回复了又不知道A收没收到，……所以无论几次都不能绝对OK的。
实验证明三次已经够了，多了没必要，少了，成功率会降低。没记错的话就是这样
--
----一定要精彩
Yongwei Wu
>
> ---------------------------------------
> 绝圣弃知，大盗乃止；擿玉毁珠，小盗不起；
>
>
> 在 2010年3月12日 上午10:54，Hongzhang Liu <hongzh...@gmail.com>写道：
>>
>> 哦？敢问更高效的建立连接的方式？另外，TCP的效率难道是由三次握手决定的么？
>>
> 你认为TCP的效率由什么决定呢？我认为讲效率是要结合环境的，泛泛地讲TCP的效率无意义。
> 传输效率方面的改进就不说了，google 拥塞控制结果就一大把。
> 握手效率重要，也很好理解。请考虑小数据报，高频率通信的情况.
> T/TCP是一个改进的例子，可以以此为线索google各种TCP替代协议。这个情况不是我捏造的，依稀记得在网络文件存储方面，TCP握手延时很致命。
>
> 那个第三路的ack，并不是不可少的。一个sync，一个ack就可以了。而且，两次握手可大幅度优化延迟，一旦存在第三路ack，优化延迟都更困难。省掉第三路ack，不算更高效吗？
随第三个包发送数据的技术早就有了。Google "tcp piggyback"。
但用的人并不多。我想，毕竟大部分情况下连接时的这一点点延迟并不会造成什么问题。
--
Wu Yongwei
URL: http://wyw.dcweb.cn/
孙朝阳
---------------------------------------
绝圣弃知，大盗乃止；擿玉毁珠，小盗不起；
2010/3/12 孙朝阳 <wing...@gmail.com>:随第三个包发送数据的技术早就有了。Google "tcp piggyback"。
>
> ---------------------------------------
> 绝圣弃知，大盗乃止；擿玉毁珠，小盗不起；
>
>
> 在 2010年3月12日 上午10:54，Hongzhang Liu <hongzh...@gmail.com>写道：
>>
>> 哦？敢问更高效的建立连接的方式？另外，TCP的效率难道是由三次握手决定的么？
>>
> 你认为TCP的效率由什么决定呢？我认为讲效率是要结合环境的，泛泛地讲TCP的效率无意义。
> 传输效率方面的改进就不说了，google 拥塞控制结果就一大把。
> 握手效率重要，也很好理解。请考虑小数据报，高频率通信的情况.
> T/TCP是一个改进的例子，可以以此为线索google各种TCP替代协议。这个情况不是我捏造的，依稀记得在网络文件存储方面，TCP握手延时很致命。
>
> 那个第三路的ack，并不是不可少的。一个sync，一个ack就可以了。而且，两次握手可大幅度优化延迟，一旦存在第三路ack，优化延迟都更困难。省掉第三路ack，不算更高效吗？
|
|
显示详细信息 3月12日 (1 天前)
|
其实无论几次握手都不能保证绝对可靠，就选个不多不少的三好了。
假定A和B通信，第一次握手由B发给A，B不知道A有没收到，要等A回复，可是A回复了又不知道B有没收到，要等B回复，B回复了又不知道A收没收到，……所以无论几次都不能绝对OK的。
朱晋玄
Hongzhang Liu
---------------------------------------
绝圣弃知，大盗乃止；擿玉毁珠，小盗不起；
在 2010年3月12日 上午10:54，Hongzhang Liu <hongzh...@gmail.com>写道：哦？敢问更高效的建立连接的方式？另外，TCP的效率难道是由三次握手决定的么？你认为TCP的效率由什么决定呢？我认为讲效率是要结合环境的，泛泛地讲TCP的效率无意义。
传输效率方面的改进就不说了，google 拥塞控制结果就一大把。握手效率重要，也很好理解。请考虑小数据报，高频率通信的情况. T/TCP是一个改进的例子，可以以此为线索google各种TCP替代协议。这个情况不是我捏造的，依稀记得在网络文件存储方面，TCP握手延时很致命。
那个第三路的ack，并不是不可少的。一个sync，一个ack就可以了。而且，两次握手可大幅度优化延迟，一旦存在第三路ack，优化延迟都更困难。省掉第三路ack，不算更高效吗？
孙朝阳
---------------------------------------
绝圣弃知，大盗乃止；擿玉毁珠，小盗不起；
机械唯物主义 : linjunhalida
RuiFeng Shan
这种问题不是典型的教科书问题吗？直接看书找答案吧。
大家讨论讨论也没什么。不能被教材限定思维。。。或许，会有人有因此有创造性的发现也不说不定。
