TCP 为什么是三次握手，而不是两次或四次？

TCP 为什么是三次握手，而不是两次或四次？

TCP作为一种可靠传输控制协议,其核心思想:既要保证数据可靠传输，又要提高传输的效率,而用三次恰恰可以满足以上两方面的需求!

TCP可靠传输的精髓: TCP连接的一方A,由操作系统动态随机选取一个32位长的序列号(InitialSequence Number) ,假设A的初始序列号为1000，以该序列号为原点，对自2将要发送的每个字节的数据进行编号，1001, 1002, 100… 并把自己的初始序列号ISN告诉B,让B有一个思想准备,什么样编号的数据是合法的,什么编号是非法的，比如编号900就是非法的,同时B还可以对A每- -个编号的字节数据进行确认。如果A收到B确认编号为2001,则意味着字节编号为1001-2000，共1000个字节已经安全到达。

同理B也是类似的操作，假设B的初始序列号ISN为2000,以该序列号为原点,对自己将要发送的每个字节的数据进行编号，2001, 2002, 200…并把自己的初始序列号ISN告诉A,以便A可以确.认B发送的每一个字节。 如果B收到A确认编号为4001,则意味着字节编号为2001- -4000,共2000个字节已经安全到达。

一话概括，TCP连接握手,握的是啥?

通信双方数据原点的序列号!

以此核心思想我们来分析二、三、四次握手的过程。

A <-------> B

四次握手的过程:

1. A发送同步信号SYN + A’s Initial sequence number

2. B确认收到A的同步信号，并记录A’s ISN到本地，发送B’s ACK sequence number

3. B发送同步信号SYN + B’s Initial sequence number

4. A确认收到B的同步信号,并记录B’s ISN到本地，命名A’s ACK sequence number

很显然2和3这两个步骤可以合并，只需要三次握手，可以提高连接的速度与效率。

二次握手的过程:

1. A发送同步信号SYN + A’s Initial sequence number

2. B发送同步信号SYN + B’s Initial sequence number + B’s ACK sequence number

这里有一个问题，A与B就A的初始序例号达成了一致,这里是1000。但是B无法知道A是否已经接收到自己的同步信号，如果这个同步信丢失了，A和B就B的初始序列号将无法达成一致。

于是TCP的设计者将SYN这个同步标志位SYN设计成占用一个字节的编号(FIN标志位也是)，既然是一个字节的数据，按照TCP对有数据的TCP segment必须确认的原则，所以在这里A必须给B一个确认，以确认A已经接收到B的同步信号。

有人会说，如果A发给B的确认丢了，该如何?

A会超时重传这个ACK吗?不会! TCP不会为没有数据的ACK超时重传。

那该如何是好?

B如果没有收到A的ACK,会超时重传自己的SYN同步信号，一直到收到A的ACK为止。

---

第一个包，即A发给B的SYN中途被丢，没有到达B

A会周期性超时重传，直到收到B的确认

第二个包，即B发给A的SYN + ACK中途被丢，没有到达A

B会周期性超时重传，直到收到A的确认

第三个包，即A发给B的ACK中途被丢,没有到达B

A发完ACK，方面认为TCP为Established状态,而B显然认为TCP为Active状态:

• 假定此时双方都没有数据发送，B会周期性超时重传，直到收到A的确认,收到之后B的TCP连接也伪Established状态,双向可以发包。

• 假定此时A有数据发送，B收到A的Data + ACK,自然会切换为established 状态，接受A的Data。

• 假定B有数据发送，数据发送不了,会直周期性超时重传SYN + ACK,直到收到A的确认可以发送数据。

说来说去对于SYN和FIN必须做出回应,使双方的序列号都做出回应,ACK不用做出回应,不然会进入死循环.