续篇（一） TCP 为什么是三次握手，四次挥手？

前两天在知乎上看到一个关于TCP协议的博文，没想到评论区竟然是华山论剑、高手论道，所以就悄悄的码住，吸取他们当中的精华，组合一下打狗棒法为我所用，哈哈~~~真的好贱，阿嚏，竟然有人骂我？废话不多说，上菜！！！

东邪-黄药师率先出招

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

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

TCP连接握手，握的是啥?

毫无疑问，两者握的是序列号
以此核心思想我们来分析三、四次握手的过程。

四次握手的过程:

1.1 A 发送同步信号    SYN+ A’s Initial sequence number
1.2  B 确认收到A的同步信号，并记录A’s ISN 到本地，命名B’s ACK sequence number
1.3  B发送同步信号SYN + B’s Initial sequence number
1.4  A确认收到B的同步信号，并记录B’s ISN到本地，命名A’s ACK sequence number

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

北丐-洪七公降龙十八掌

谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”这个例子很清晰的阐释了“三次握手”对于建立可靠连接的意义。
有一条回复写道：“这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的.

举例：

第一次：客户端发起连接请求：
     客户端验证：什么也不能验证，无法知道自己是否能够成功发送和接收
     服务端验证：能够验证自己能够成功接收，但不能验证能否发出
第二次：服务端返回响应：
     客户端验证：客户端能够验证自己成功发出和接收
     服务端验证：还是只能够验证自己能够成功接收，但不能验证能否发出
第三次：客户端返回响应：
     客户端验证：客户端能够验证自己成功发出和接收
     服务端验证：服务端能够验证自己能够成功发出和接收

西毒-欧阳锋紧随其后

特别声明：此人招数皆是阴招不可学
第一个3.6K 次赞同的类比就是错误的：三次握手：

“喂，你听得到吗？”
“我听得到呀，你听得到我吗？”
“我能听到你，今天 balabala……”

-同样这个107次赞同的类比也是错误的：握手和敬军礼一样，源自「敌我双方互相确认对方手里没有武器、无恶意」的仪式。（虽然双方互相请求确认需要四步，但由于中间的确认和请求是由同一个人执行的，所以合并成了一步）

正恩伸出手说：你看，我手里没有武器。（SYN）
朗普看了看说：嗯，确实没有。（ACK）
于是也伸出手说：你看，我手里也没有武器。（SYN）
正恩看了看说：嗯，看来你确实有诚意。（ACK）

南帝-段智兴亮招

三次握手（A three way handshake）是必须的，因为 sequence numbers（序列号）没有绑定到整个网络的全局时钟（全部统一使用一个时钟，就可以确定这个包是不是延迟到的）以及 TCPs 可能有不同的机制来选择 ISN（初始序列号）。接收方接收到第一个 SYN 时，没有办法知道这个 SYN 是是否延迟了很久了，除非他有办法记住在这条连接中，最后接收到的那个sequence numbers（然而这不总是可行的）。这句话的意思是：一个 seq 过来了，跟现在记住的 seq 不一样，我怎么知道他是上条延迟的，还是上上条延迟的呢？所以，接收方一定需要跟发送方确认 SYN。

吾乃搏为赞同!!!!!!