TCP/IP三次握手讨论

kkshaq

windoze 发表于 2015-06-11 22:12
回复 12# kkshaq

客户端只是发了一个ACK而已，它也不知道服务器端到底收到没有，想知道结果必需得让服务 ...

”客户端只是发了一个ACK而已，它也不知道服务器端到底收到没有，想知道结果必需得让服务器端再发一个ACK过来“，我觉得这句话有问题，客服端根本不需要等待服务器发来ack报文，因为此前他就认为已经建立了连接。



客户端首先发送syn报文给服务器，服务器收到之后，返回syn+ack，只要收到ack，客户端就可以认为连接建立。

同理，只要服务器收到客户端的ack报文，则服务器端也认为连接成立。

客服端并不需要对自己发送的ack进行等待，因为它之前就认为建立了连接，根本不需要等待服务器发送的ack报文




这个角度，你的说法，我不同意，三次是两方都确认连接的最少次数。

你从防止防SYN flooding角度考虑的说法，我表示赞同，最后再请教你一个问题，我这个帖子最开始 对关于谢希仁关于两次握手的解释的质疑是否正确？多谢

kkshaq

蛮多肉 发表于 2015-06-12 06:16
在多数情况下2次握手够了

极端情况下,N次握手都不够

三次握手的目的是什么？？怎么越讨论越乱 。。。为什么N次握手都不够？？？我认为各自收到一个ack，连接就认为成立了，所以需要三次。两次不行。

kkshaq

回复 16# cokeboL

最后一个ack包丢失，对建立连接又没有影响。。。
只要收到双方都收到ack报文，就认为连接成立。   

cokeboL

回复 23# kkshaq

不要用tcp规则设计的原因来解释tcp相关规则的合理性，那样解释肯定是合理的

跳出来去想想设计的原因的合理性

否则在讨论的就不是一个东西了，我们在说这个东西的原理不合理，你们却在说用这个原理来解释用这个原理设计的东西的规则是合理的

cokeboL

之前发的帖子也不见了

windoze

回复 21# kkshaq

如果服务器端不需要客户端第二次发来的ACK就建立链接，那么第二次ACK就没必要发送。
如果服务器端认为它要收到客户端第二次送来的ACK才算是真正建立了链接，但客户端无法知道自己第二次发送的ACK是否被服务器端收到，所以客户端就不知道服务器端是否认为链接已经建立。
问题的关键就在于双方要达成共识，但已经证明在不可靠的链路上无法保证能建立这种共识。

zhaohongjian000

回复 20# windoze


    收到第一个包后处于半开状态的连接可以加快回收，虽然不是默认情况也不符合TCP的设计但至少有这个选择。
另外，Linux下半连接放在一个单独的队列中，这其实已经体现出差别了。

windoze

回复 27# zhaohongjian000

你说的这些SYN cookie方案已经不是标准TCP了，再说真要flood起来还是飞速就能搞爆掉。

kkshaq

windoze 发表于 2015-06-12 17:25
回复 21# kkshaq

如果服务器端不需要客户端第二次发来的ACK就建立链接，那么第二次ACK就没必要发送。

恩，懂了。三次握手的共识就是，客服端和服务器都要获知对方已经建立连接，这种情况下，才是连接成功。

然而在链路不可靠的时候，最后一次ack总会丢失，导致双方都获知对方已经建立连接的情况，不可能发生。


两次握手本身就不是为了建立可靠连接，所以也就不需要双方都得获知对方已经建立连接（也就是你说的共识），三次握手本意是想双方获知对方已经建立连接（目的是建立可靠连接），但是实际上不可能成功。



不知道，我理解的是否有误？？

windoze

回复 29# kkshaq

没错啊，三次握手基本上是个两头不沾的方案，现在还用纯粹是尾大不掉，要是不考虑兼容性问题造就全升级SCTP了。