TCP

三次握手流程的本质，可以这么理解：TCP的三次握手其实是双方各一次握手，各一次确认，只是其中一次握手和确认合并在一起。

当然也可以更通俗的去理解：

• “喂，你听得到吗？”
• “我听得到呀，你听得到我吗？”
• “我听得到呀，你听得到我吗？”
• “我能听到你”

三次握手为什么不用两次，或者四次

原因很简单，因为只有三次才是最合适的，三次通信是最小值，两次通信满足不了要求，而四次通信则显得冗余。比如之前的三次改成两次，四次的结果就变味了。

两次握手：

• “喂，你听得到吗？”
• “我听得到呀”
• “喂，你听得到吗？”
• “草，我听得到呀！！！！”
• “你TM能不能听到我讲话啊！！喂！”
• “……”

四次握手：

• “喂，你听得到吗？”
• “我听得到呀，你听得到我吗？”
• “我能听到你，你能听到我吗？”
• “……不想跟傻逼说话”

TCP的三次握手流程

虽然有人说这个是尼玛都看了一千遍的了，但是还是要大致说下。

• 第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。

• 第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。

• 第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

TCP三次握手深入解析

关于三次握手的目的，谢希仁的《计算机网络》中这么说“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。在另一部经典的《计算机网络》一书中讲“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。这两种不用的表述其实阐明的是同一个问题。

谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”

但我之前听过http协议的三次握手，有点懵逼，到底是tcp协议三次握手还是http协议三次握手呢？知乎的答案如下：

http是应用层协议，它的任务是与服务器交换信息。至于怎么连到服务器，怎么保证数据正确，http不管。事实上它总是假设数据是正确地传输的。而tcp的任务是保证连接的可靠，包括防丢、防错。为了做到这些，在初次连接时要进行3次握手，以保证确实连接到了目标机器。而连接上后具体传送什么数据，tcp是不管的。别的应用层协议也能通过tcp进行，那么这种协议在底层也进行3次握手。在某些情况下，http可以不通过tcp实现，那就不需要3次握手。比如，我做了一把遥控咖啡壶，遥控器和壶通过红外直接连接，通过http协议post提交煮咖啡的指令，get获取是否已经煮好。http字符直接调制到红外上，此时http应用层下面直接是物理层，当然不存在3次握手了，连ip地址和mac地址也不存在。

http结构如下：