关于TCP三次握手问题的深究

Question

三次握手的流程和基础我都知道，各位不用跟我讲解基础概念

---

问题在于为什么不能进行二次握手的问题

1.从客户端传送到服务器的信息在网络中延迟了很久才传到，服务器接受到消息后，返回确认信息，但是此时客户端的连接已近关闭，但服务器还是一直等待，这样会造成服务器资源的浪费

这种能理解

2.从客户端传送到服务器的信息在网络中延迟了很久才传到，服务器接受到消息后，返回确认信息，但是客户端已经放弃了第一次的连接，发送了第二次连接的请求，当客户端收到请求后会认为这是第二次请求的确认，从而建立连接。

好，问题就在这，在发送连接请求和确认连接请求的时候，我们都会发送序号和确认号，假设第一次客户端发送请求时的序号为x,那么服务器返回确认信息的包中的确认号就应该是x+1,那客户端发送的第二次连接请求的序号显然不会为x，假设为y，那么当客户端收到服务器返回的确认信息中确认号为x+1，就应该不会建立连接，因为他需要等待是一个确认号为y+1的。
那么这第二种问题就不应该存在。
本人对tcp的理解只停留在概念上，没有做过实际上对于tcp的研究，所以可能有某些地方理解上出现了问题，希望大家能指出。
我觉得可能的答案：
1.客户端不会对确认号进行确认，但是为什么？
2.两次发送请求的序号相同（应该不可能，随机生成的）
3.这种问题不存在

//2019.9.16 还是没有搞清楚第二种情况
还是没有搞清楚

Answer 1

https://102.alibaba.com/detai... 你可以去看看，希望能帮到你1

Answer 2

1 TCP提供可靠的链接，两次握手，客户端能够确认自己发给服务器的数据服务器能收到，自己也能收到服务器的数据，但是服务器并不知道自己发给客户端的数据客户端是否能收到，。所以需要三次握手

2、“网络中延迟了很久才传到” ，说明的你的网络太烂，TCP握手失败。需要改进网络

Answer 3

TCP 基础待加强。

一般而言，有两个地方可区别不同的 TCP 会话

1. 序列号
   通常连接双方的初始序列号是个随机数，而且是不可预测的。
   例外：在受到 SYN 洪水攻击时，服务器可能使用特别数作为序列号，详情 https://en.wikipedia.org/wiki...
2. 客户端的连接端口
   绝大部分的客户端使用操作系统分配的动态（本地）端口，理论上每次连接都不一样。