TCP 三次握手
A：你能听到吗？
B：我能听到，你能听到吗？
A：我能听到，开始吧
A 和 B 两方都要能确保：我说的话，你能听到；你说的话，我能听到。所以需要三次握手
为什么必须是三次握手？
大家都知道传输层（点击这里去传输层）中的TCP协议是面向连接的，提供可靠的连接服务，其中最出名的就是三次握手和四次挥手，今天先讲解三次握手（四次挥手点这里），如下图
1、第⼀个SYN报⽂
在打算建立TCP连接时，客户端向服务端发出请求报文段，这时首部中的同步位SYN=1，同时选择一个初始序号 seq = x 。TCP规定，SYN报文段（即SYN = 1的报文段）不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN—SENT（同步已发送）状态
2、第⼆个报⽂SYN+ACK报⽂
服务端收到客户端的SYN报⽂后，向客户端发送确认。在确认报文段中把SYN位和ACK位都置1，确认号是 ack = x + 1，同时也为自己选择一个初始序号 seq = y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时TCP服务器进程进入SYN-RCVD（同步收到）状态。
3、第三个报⽂ACK
TCP客户进程收到服务端的确认后，还要向服务端给出确认。确认报文段的ACK置1，确认号 ack = y + 1，而自己的序号 seq = x + 1.TCP的标准规定，ACK报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是 seq = x + 1。这时，TCP连接已经建立，客户端进入ESTABLISHED（已建立连接）状态。
当服务端收到客户端的确认后，也进入ESTABLISHED状态
上面给出的连接建立过程又叫做三报文握手。请注意,SYN+ACK也可拆成两个报文段。可以先发送一个确认报文段(ACK=1,ack=x+1),然后再发送一个同步报文段(SYN)。这样的过程就变成了四报文握手,但效果是样的。
- 小写的ack代表的是头部的确认号Acknowledge number， 缩写ack，是对上一个包的序号进行确认的号，ack=seq+1。
- 大写的ACK，则是我们上面说的TCP首部的标志位，用于标志的TCP包是否对上一个包进行了确认操作，如果确认了，则把ACK标志位设置成1。
在三次握手过程中,序号字段Sequence Number(简称SN)的消耗规则如下:
- 第一次握手(C->S):客户端向服务器发送一个连接请求报文,请求报文中包含的SN值记为SN1。
- 第二次握手(S->C):服务器收到连接请求后,会回复一个SYN-ACK报文给客户端。报文中的ACK字段值表示对方报文的SN值加1,此处ACK值为SN1+1。
- 第三次握手(C->S):客户端收到服务器回复后,会再发送一个ACK报文给服务器确认。报文中的ACK字段值>也表示对方报文SN值加1,此处ACK值为SN1+1。 所以:
- 客户端第一次握手的SN1被服务器第二次握手的ACK值SN1+1消耗。
- 客户端第二次握手的ACK值SN1+1又被服务器第三次握手的ACK值消耗。
- 三次握手结束后,序列号SN将增加2。 所以在三次握手中,序列号SN的消耗规则就是按顺序将对方报文的SN值加1来表示ACK。这保证了TCP连接的可靠性传输。 喜欢钻牛角尖的我在学习三次握手的时候就想到了几个问题：为什么三次握手是三次？不是一次、两次或者更多？如果是两次或者是一次会出现什么情况？带着这个问题我找了好多资料，发现了其中的奥秘。
一次握手的情况：
由于TCP是面向连接的，一次很明显时不可能的，因为客户端发出连接消息后，却没有接收到来自服务端的回应，客户端就无法确定服务端接是否收到了连接请求，当然也就不能确定是否连接成功。
两次握手的情况：
既然一次客户端接收不到服务端的回应，那就连接两次，接收到回应就说明服务端接收到了连接请求，可以连理连接了。结果并不是这样。
如果客户端想建立连接，给服务端发了一个连接请求（SYN）），但是由于网络中种种情况，导致没有及时到达服务端，这就导致客户端在很长一段时间中没有收到回复消息（ACK），这时客户端又给服务端发送一个SYN，这次的发送和接收的很顺利，很快就收到了ACK，但是这时之前的SYN终于到了服务端，服务端规规矩矩的为这个SYN申请资源，然后返回ACK。由于之前的SYN已经失效了，所以客户端也不会去理会这个ACK，但是傻乎乎的服务端并不知道这个SYN已经失效了，一直为他委会着资源，这就造成了资源的浪费。
三次握手的情况：
一发一收的两次握手既然不行，那么三次握手就可以了吗？接着往下看。
在两次握手中服务端不知道当前这个SYN是不是有效的，三次握手就很好的解决了这个问题，第三次握手就是客户端给服务端回复第二次握手，这也就是说服务端会等第三次握手的到来，如果第三次握手迟迟不来，服务端就可以识别这个SYN是无效的，就会将他的资源释放了。还有一种情况就是第三次握手由于网络中的种种原因失败了，这时候客户端认为自己已经连接好了，就会给服务端发送数据，服务端由于没有收到第三次握手，就会以RST包对客户端响应，收到RST的的客户端就知道第三次握手没有成功，就会重新连接。在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。
四次握手和两次握手的情况一样，五次握手和三次握手的情况一样，以此类推，奇数次握手的情况与三次握手相同，同理偶数次握手与两次握手一样，所以为了更快的连接，就使用三次握手最合适。
每次握手失败对应的措施：
第一次握手失败：
如果第一次的SYN传输失败，两端都不会申请资源。如果一段时间后之前的SYN发送成功了，这时客户端只会接收他最后发送的SYN的SYN+ACK回应，其他的一概忽略，服务端也是如此，会将之前多申请的资源释放了。
第二次握手失败：
如果服务端发送的SYN+ACK传输失败，客户端由于没有收到这条响应，不会申请资源，虽然服务端申请了资源，但是迟迟收不到来自客户端的ACK，也会将该资源释放。
第三次握手失败:
如果第三次握手的ACK传输失败，导致服务端迟迟没有收到ACK，就会释放资源，这时候客户端认为自己已经连接好了，就会给服务端发送数据，服务端由于没有收到第三次握手，就会以RST包对客户端响应。但是实际上服务端会因为没有收到客户端的ACK多次发送SYN+ACK，次数是可以设置的，如果最后还是没有收到客户端的ACK，则释放资源。
关于三次握手名词的注释
在谢希仁的《计算机网络》（第7版）一书中有说“三报文握手是本教材首次采用的译名。在RFC973(TCP标准的文档)中使用的名称是 three way handshake个名称很难译为准确的中文,例如,以前本教材曾采用“三次手”这个广为流行的译名。其实这是在一次握手过程中交換了三个报文,而并不是进行了三次手(这有点像两个人见面进行一次手时,他们的手上下据了三次,但这井非进行了三次手),最近再次重新阅读了RFC973文档,发现有这样的表述:“ three way( three message) handshake”。可见采用“三报文手这样的译名,在意思的表达上应当是比较准确的。请注意, handshake使用的是单数而不是复数,表明只是一次握手”
TCP 四次挥手关闭连接
四次挥手即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发。由于TCP连接是全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。
四次挥手过程的示意图如下：
挥手请求可以是Client端，也可以是Server端发起的，我们假设是Client端发起：
- 第一次挥手： Client端发起挥手请求，向Server端发送标志位是FIN报文段，设置序列号seq，此时，Client端进入
FIN_WAIT_1状态，这表示Client端没有数据要发送给Server端了。 - 第二次分手：Server端收到了Client端发送的FIN报文段，向Client端返回一个标志位是ACK的报文段，ack设为seq加1，Client端进入
FIN_WAIT_2状态，Server端告诉Client端，我确认并同意你的关闭请求。 - 第三次分手： Server端向Client端发送标志位是FIN的报文段，请求关闭连接，同时Client端进入
LAST_ACK状态。 - 第四次分手 ： Client端收到Server端发送的FIN报文段，向Server端发送标志位是ACK的报文段，然后Client端进入
TIME_WAIT状态。Server端收到Client端的ACK报文段以后，就关闭连接。此时，Client端等待2MSL的时间后依然没有收到回复，则证明Server端已正常关闭，那好，Client端也可以关闭连接了。
为什么连接的时候是三次握手，关闭的时候却是四次握手？
建立连接时因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。所以建立连接只需要三次握手。
由于TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议，TCP是全双工模式。这就意味着，关闭连接时，当Client端发出FIN报文段时，只是表示Client端告诉Server端数据已经发送完毕了。当Server端收到FIN报文并返回ACK报文段，表示它已经知道Client端没有数据发送了，但是Server端还是可以发送数据到Client端的，所以Server很可能并不会立即关闭SOCKET，直到Server端把数据也发送完毕。当Server端也发送了FIN报文段时，这个时候就表示Server端也没有数据要发送了，就会告诉Client端，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。
