TCP/IP三次握手讨论

windoze

回复 10# cokeboL

其实多级次握手也不是完全没用，比如SCTP用4次握手，连接状态在第二个来回才建立，这样可以防止SYN Flooding，因为你得很精确的连续两次伪造源地址发包才能骗过对方，基本上不可行，但像TCP这样的3次握手，既不够简洁又不够安全，还不如不用。

kkshaq

回复 9# windoze

最后一次的客服端的ack报文不是确认吗？怎么会没用啊？求解释清楚一点。只有收到ack应答，才说明服务器端的syn被客户端接受了啊。。。你为什么说无论多次此都没用呢？
我的理解是，客户端开始发送syn连接报文给服务器，服务器收到之后，发送ack+syn报文，然后等待客服端的ack报文，同时采用超时重传的机制。这样就可以防止最后的客服端的ack报文丢失啊。
求指教

kkshaq

回复 5# cokeboL

最后一次的ack确定报文丢失，服务器可以通过超时重传来解决啊。超过时间没有收到ack报文，服务器就重发syn连接报文给客服端，导致客服端重新发送ack报文。问题不就解决了吗？
   

windoze

回复 12# kkshaq

客户端只是发了一个ACK而已，它也不知道服务器端到底收到没有，想知道结果必需得让服务器端再发一个ACK过来。
同理服务器端也不知道自己再发的那个ACK客户端到底收到没有，想知到结果必需得让客户端再发一个ACK过来。
……
……
……
……
……
……
然而无论你重复多少次，都并没有什么卵用。


超时重传也不解决问题，因为有可能是对方的回复你没收到，甚至有可能无论你再催多少遍还是收不到。
不信？想象一下两边在用光纤通信，然后一方的激光二极管烧了……

蛮多肉

在多数情况下2次握手够了

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

这个第三次握手

就如同 switch(){
      case:;
      default:
      break;
       }

是个逻辑握手!

cokeboL

回复 13# kkshaq


    任何一个包都可能丢，包括为了确认发的包，所以并没有什么卵用。透过现象看本质，直接抓住最根本的地方来想就清楚了

zhaohongjian000

楼上几个真能扯，本来不想回，越讨论越扯淡。

假设A向B发起连接，A到B是通的，B到A不通，两次握手的结果是B认为连接成功建立，而A知道连接不成功。
三次握手是让双方确认两边网络都通所需要的最少次数。少于三次，无法确认双方网络都通。

15楼举的例子，恰恰在反驳自己。单向通的网络会卡在前两次握手。如果第三次握手的包丢失，至少证明双方
网络都是通的，只是不稳定。这种情况可以用rst包重新建立连接来解决。

在两次握手就可以建立连接的情况下，意味着服务端收到一个包就要建立一个连接，DoS攻击真是轻松...

windoze

回复 17# zhaohongjian000

那你觉得现在3次握手服务器端是在收到了第几个包的时候建立链接？

zhaohongjian000

回复 18# windoze


    服务端收到第三个包进入ESTABLISHED状态，虽然因为收到第一个包进入SYNRECVD状态还是可以DoS，但是SYNRECVD状态可以加快回收。
数据开始传输后就不能随便回收了，所以一个包就进入ESTABLISHED状态，抗DoS能力只会更低。

windoze

回复 19# zhaohongjian000

刚才回的贴怎么不见了？重发一遍

服务器端虽然在收到第3个包的时候才将链接状态设置为ESTABLISHED，但在收到第一个SYN时就已经分配了链接相关资源，从防SYN flooding这一点而言三次两次没什么差别。
要想防SYN flooding，就得像SCTP那样，第二次收到客户端发来的COOKIE-ECHO包的时候才分配链接相关资源。