目录
-
典型问题：
- 请简述TCP协议三次握手的过程
- 三次握手可以简化成两次握手吗？为什么？
-
TCP协议三次握手的过程
- 大致：
- 最开始时客户端和服务端都处于 CLOSED 状态，然后服务端先主动监听某个端口，此时服务器端就变成了 LISTEN（监听）状态
- 然后客户端主动发起连接，发送 SYN（同步序列编号），此时客户端就变成了 SYN-SENT 状态
- 服务端接收到信息之后返回 SYN 和 ACK 至客户端，此时服务器端就变成了 SYN-REVD 状态
- 客户端接收到消息之后，再发送 ACK 至服务器端，此时客户端就变成了 ESTABLISHED（已确认）状态，服务端收到 ACK 之后，也变成了 ESTABLISHED 状态，此时连接工作就执行完了
- 细化：
- 刚开始客户端处于 Closed 的状态
- 服务端处于 Listen 状态
- 进行三次握手：
- 第一次握手：
- 客户端给服务端发一个 SYN 报文
- 并指明客户端的初始化序列号 ISN
- 此时客户端处于 SYN_SENT(同步已发生) 状态
- 首部的同步位SYN=1，初始序号seq=x
- SYN=1的报文段不能携带数据，但要消耗掉一个序号
- 第二次握手：
- 服务器收到客户端的 SYN 报文之后
- 会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)
- 同时会把客户端的 ISN + 1 作为ACK 的值
- 表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_RCVD(同步已接收) 的状态
- 在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y
- 第三次握手：
- 客户端收到 SYN 报文之后，会发送一个 ACK 报文
- 当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED(建立连接) 状态
- 服务器收到 ACK 报文之后，也处于 ESTABLISHED(建立连接) 状态
- 此时，双方已建立起了连接
- 确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1）
- ACK报文段可以携带数据，不携带数据则不消耗序号
- 发送第一个SYN的一端将执行主动打开（active open）
- 接收这个SYN并发回下一个SYN的另一端执行被动打开（passive open）
- 在socket编程中，客户端执行connect()时，将触发三次握手
-
为什么 TCP 需要三次握手？
- 原因一：防止重复连接
- 三次握手的主要原因是为了防止旧的重复连接引起连接混乱问题
- 比如在网络状况比较复杂或者网络状况比较差的情况下，发送方可能会连续发送多次建立连接的请求
- 如果 TCP 握手的次数只有两次，那么接收方只能选择接受请求或者拒绝接受请求，但它并不清楚这次的请求是正常的请求，还是由于网络环境问题而导致的过期请求，如果是过期请求的话就会造成错误的连接
- 所以如果 TCP 是三次握手的话，那么客户端在接收到服务器端 SEQ+1 的消息之后，就可以判断当前的连接是否为历史连接，如果判断为历史连接的话就会发送终止报文（RST）给服务器端终止连接；如果判断当前连接不是历史连接的话就会发送指令给服务器端来建立连接
- 原因二：同步初始化序列化
- TCP 为了保证在不稳定的网络环境中构建一个稳定的数据连接，它就需要一个“序列号”字段来保证自己的稳定性
- 而这个序列号的作用就是防止数据包重复发送，以及有效的解决数据包接收时顺序颠倒的问题
- 那么在建立 TCP 连接时就需要同步初始化一个序列号来保证 TCP 的稳定性，因此它需要执行以下过程：
- 首先客户端发送一个携带了初始序列号的 SYN 报文给服务器端
- 服务端接收到消息之后会回复一个 ACK 的应答报文，表示客户端的 SYN 报文已被服务端成功接收了
- 而客户端收到消息之后也会发送一个 ACK 给服务端，服务器端拿到这个消息之后，我们就可以得到一个可靠的初始化序列号了
- 而如果是两次握手的话，就无法进行序列号的确认工作了，因此也就无法得到一个可靠的序列号了，所以 TCP 连接至少需要三次握手
- 以上两种原因就是 TCP 连接为什么需要三次握手的主要原因，当然 TCP 连接还可以四次握手，甚至是五次握手，也能实现 TCP 连接的稳定性，但三次握手是最节省资源的连接方式，因此 TCP 连接应该为三次握手