TCP（Transmission Control Portocol）。传输控制协议。属于OSI里面的传输层。作用：让服务端和客户端产生连接。强制规定，接收端必须发回确认，告诉发送方自己收到消息。
三次握手涉及的值，syn（连接标识），seq（序列号，随机数，每个包都有。），ack（确认号）。
三次握手示意：
【1】客户端一个syn包，去和服务端建立连接。包里有两个值，syn和seq。syn是告诉服务端我要和你ack建立连接。seq是一个随机数，供第二次握手用。
【2】服务端收到客户端的请求。服务端看到syn，就知道客户端想要建立连接。于是返回一个syn-ack包。告诉客户端，我也要和你搞。ack是seq+1。同时这个包也会有一个随机数seq。最后，syn-ack包有3个信息，syn，ack，seq。
【3】客户端收到后，最后发送一个ack包。包里有一个ack，ack=seq+1。还有一个seq。（好多情况下。seq的作用就是为了ack赋值用的。）
为什么要3次操作？两次之后双向连接不是已经建立了？
我们知道，3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
言而总之，如果没有第三次，服务端并不知道客户端是否已经收到自己的ack-syn包，更不知道客户端是否做好准备了。第三次的目的就是告诉服务器，来吧，我准备好了。
以下，可以清除看到 握手过程中操作。
最后，上一张示意图。
四次挥手示意：
涉及的，fin（告诉对方我要中断连接），seq（同上，随机，序列号，每个包都有） ack（确认值）
挥手的过程，两端都可以主动关闭。
【 1 】 主动方发送一个 fin-ack的包。告诉被动方我要关闭了。
【 2 】 被动房收到消息，先发送一个ack包，继续传递消息。
【 3 】 被动方发送fin-ack包，告诉主动方，我也要关闭了。
【 4 】 主动方发送ack包。告诉被动方。收到。
A&Q
1 。 为什么 握手三次，而挥手却要四次？
因为，你发送fin给 被动方后。被动方知道的仅仅是你不再发数据给主动方了。然后被动方可能还有数据主动方。所以要再发一次 ack 过去。（当没有数据发给主动方时，其实挥手也可以看座3次），不过按照一个标准流程来说，挥手 是4次。
我试了确实有3次包传递。等于 被动方 将 2，3步合一块了。
