标签：ACK 握手 报文 server 三次 服务器 问答 连接
三次握手的细节问答
三次握手
- 客户端向服务端发送SYN （SYN=1 seq=J）
- 服务端返回SYN,ACK（SYN=1 ACK=1 ack=J+1，seq=K）
- 客户端发送ACK（ACK=1 ack=K+1）
建立连接可以两次握手吗?为什么?
不可以。
因为可能会出现已失效的连接请求报文段又传到了服务器端。
client 发出的第一个连接请求报文 段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 server。
本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后，就误认为 是 client 再次发出的一个新的连接请求。于是就向 client 发出确认报文段，同意建立连接。假设 不采用 “三次握手”，那么只要 server 发出确认，新的连接就建立了。由于现在 client 并没有发出 建立连接的请求，因此不会理睬 server 的确认，也不会向 server 发送数据。但 server 却以为新 的运输连接已经建立，并一直等待 client 发来数据。这样，server 的很多资源就白白浪费掉了。 采用 “三次握手” 的办法可以防止上述现象发生。例如刚才那种情况，client 不会向 server 的确认 发出确认。server 由于收不到确认，就知道 client 并没有要求建立连接。 而且，两次握手无法保证Client正确接收第二次握手的报文(Server无法确认Client是否收到)， 也无法保证Client和Server之间成功互换初始序列号。
可以采用四次握手吗?为什么?
这个肯定可以。三次握手都可以保证连接成功了，何况是四次，但是会降低传输的效率。
第三次握手中，如果客户端的ACK未送达服务器，会怎样
服务器什么时候进入ESTABLISHED状态
第三次握手:客户端检查acknowledge number是否为序列号+1，ACK是否为1，检查正确之后将 自己的ACK置为1，产生一个acknowledge number=服务器发的序列号+1，发送给服务器;进入 ESTABLISHED状态;服务器检查ACK为1和acknowledge number为序列号+1之后，也进入 ESTABLISHED状态;完成三次握手，连接建立。
Server端:
由于Server没有收到ACK确认，因此会每隔 3秒 重发之前的SYN+ACK(默认重发五次，之后自动关闭连接进入CLOSED状态)，Client收到后会重新传ACK给Server。
Client端，会出现两种情况:
- 在Server进行超时重发的过程中，如果Client向服务器发送数据，数据头部的ACK是为1的， 所以服务器收到数据之后会读取 ACK number，进入 establish 状态
- 在Server进入CLOSED状态之后，如果Client向服务器发送数据，服务器会以RST包应答。
如果已经建立了连接，但客户端出现了故障怎么办?
服务器每收到一次客户端的请求后都会重新复位一个计时器，时间通常是设置为2小时，若两小时 还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若 一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
标签：ACK,握手,报文,server,三次,服务器,问答,连接 来源： https://blog.csdn.net/weixin_44153921/article/details/123234766
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。