TCP
基本概念
TCP协议全称: 传输控制协议, 顾名思义, 就是要对数据的传输进行一定的控制。
是一种面向连接的，可靠的传输层层协议。可以这么理解面向连接，就是创建连接之前，首先要握手创建连接，关闭连接是需要挥手确认的，这也是保证其可靠的原因之一。
三次握手和四次挥手
第一次:
客户端 - - > 服务器 此时服务器知道了客户端要建立连接了。
第二次:
客户端 < - - 服务器 此时客户端知道服务器收到连接请求了。
第三次:
客户端 - - > 服务器 此时服务器知道客户端收到了自己的回应。
如图所示：
通俗说就是，A想与B进行通信，A首先会对B大喊：“我要和你开始对话了，你准备好了吗？”，B听到A的喊话，会做出反应，也对B大喊：“好的，我已经准备好了，随时可以接收，你确定开始说了吗？” A听到后说，“ok！我要开始说了。”此时，A与B的对话就会balabala…开始了。
也许有人会说，没必要第三次握手，两次就好了呀，就B而言，直接听到后，发出确认消息后，A就可以发出数据了呀。。。哈哈，那你就太天真了，这里我们就来讲讲为什么会有第三次握手。
第三次握手为什么必要？
其中最主要的原因是为了防止已经失效的连接请求报文突然又传送到了服务器，从而出现资源浪费和一系列错误。
若客户端在发出请求链接信息后，其中这个消息因为网络问题“开了个小差”，客户端由于迟迟没有收到服务端的确认，会重发请求，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。这之后，那个之前发送的请求传到了服务器，这时候，服务器会建立连接，等待客户端数据传输，白白浪费大量资源，也会出现一些错误。所以，需要第三次握手，让客户端对该请求再度确认，是否真的需要建立连接。-----这也是我们平时和别人沟通时需要注意的一个很重要的point，我们要及时给他人反馈，不论是积极的还是有待提高的。
对了，会不会有人提出，我们服务端还要对客户端的第二次发送进行确认，这样更加保险。。恩，怎么说呢，也不是不可以，但是，我们三次就能做完的事，为什么要多做几次呢。三次已经足够对该次连接起到可靠保障了。没必要循环了。。。
挥手是逆向的，为什么是四次，而不是三次呢？
有逆向的思维很不错，但是我们不能忘了，挥手的时候，要确保双方都把“话”说完了，才能挥手结束。我们还把A和B做例子，A此时已经把话说完了。就对B说，“恩，今天就到这儿吧，我说完了。”B听到后，会说“好的，我知道你说完了。”
按照三次握手的原理，A听到后，会给予反馈，“再见”。挥手结束。大家有没有觉得哪里怪怪的。。。。对了，A还不知道B是不是说完了呢，B只是说，“恩，我知道你说完了。”其实B后面还想说“恩，我还有一些话要说呢，在耽误个五分钟。”
所以，我们可以了解到，挥手是要双方都确认消息数据都发送完毕后，再关闭连接。
这里说下，客户端和服务端双方都是可以发起关闭的。
- 客户端进程发出连接释放报文，并且停止发送数据。
释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。 - 服务器收到连接释放报文，发出确认报文，ACK=1，确认序号为 u+1，并且带上自己的序列号seq=v，此时服务端就进入了CLOSE-WAIT（关闭等待）状态。
TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。 - 客户端收到服务器的确认请求后，此时客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最终数据）
- 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，确认序号为v+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
- 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，确认序号为w+1，而自己的序列号是u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
- 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
----图中可以看出只有四次挥手。。
再说下四次的原理：建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。
最后客户端等待 2*MSL的时间有什么意义？
简单说下，MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。
-
保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
-
防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。
客户端在连接时由故障失联了，怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。