连接管理机制
在正常情况下, TCP要经过三次握手建立连接, 四次挥手断开连接
三次握手
三次握手是为了建立连接
1.验证通信双方发送能力和接收能力是否正常.
2.通信双方要协商一些重要参数.
第一次:
客户端 - - > 服务器 此时服务器知道了客户端要建立连接了
第二次:
客户端 < - - 服务器 此时客户端知道服务器收到连接请求了
第三次:
客户端 - - > 服务器 此时服务器知道客户端收到了自己的回应
到这里, 就可以认为客户端与服务器已经建立了连接.
下面就还是用之前的例子进行解释
下面展示主机中真实的三次握手的详情
为什么不用两次?
不行.如果没有最后一个ACK,此时主机B是无法知道自己的发送能力和对方的接受能力是否正常.
主要是为了防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。
如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送的第一个请求连接并且没有丢失，只是因为在网络中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时之前滞留的那一次请求连接，因为网络通畅了, 到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。
为什么不用四次?
因为三次已经可以满足需要了, 四次就多余了，四次可以建立连接但是没必要，就是将三次的第二次分成两步就会需要传输两个包，这样效率就会低下。
四次挥手
四次挥手其实跟我们日常的情侣分手一样
四次挥手只有在“延时应答”这种特殊情况的时候才会有合并。
FIN是内核的事情.内核收到FIN就知道对方不会再继续发送数据了.
主机B的应用程序就会继续读取接受缓冲区中积压的数据，如果数据读完了,继续再读,就会触发异常. (异常相当于是从一个已经关闭连接的连接中读取数据,数据读完了才触发的)
丢包分析
