TCP的状态转换
java TCP的状态转换
我只是一java开发小白，目前正好在研究tcp的相关问题，于是写了研究了一下tcp的相关转换，第一篇博客，各位大牛请轻喷。
首先我们都知道，在java网络变成模式中,主要有TCP和UDP两种模式，我们首先要知道这两种模式的区别。
TCP与UDP的区别：
1.TCP是面向字节流的，实际上TCP是吧数据当作一连串无结构的字节流，而UDP则是面向报文的
2.TCP是需要连接的，举个简单的例子，比如打电话就需要先拨号建立连接；而UDP则是五连接的，即发送数据之前是不需要建立连接的
3.TCP是属于及时通信，点对点进行通信，且只能是点到点。而UDP支持一对一，多对一，甚至多对多的交互通信
4.UDP是没有拥塞机制的，所以当网络出现堵塞的时候，并不会使原数据的发送速率降低，这点其实对一些应用很有用,比如实时会议，比如ip电话
5.TCP是需要三次握手的，可以确认建立起一个可靠安全的连接之后，才会传输数据，而UDP不会。 这就导致了，数据完整和安全性方面，TCP比UDP好得多，但是从网络负担层次来说，UDP则比TCP的开销少了很多。 简单来说，tcp连接传送的数据，无差错，不丢失，不重复，且按序到达，UDP则尽最大的努力交付，也不保证可靠交付
TCP状态流程：
首先，我们来看一张图
1.CLOSED: 起始点，在超时或者关闭连接的时候会进入此状态
2.LISTEN :Server端在等待连接时的状态，Server为此要调用Socket、bin、listen函数，就能进入此状态。这称为应有程序被动打开，也就是等待客户端来连接。
3.SYN_SENT:客户端发起了连接，发送SYN给服务器端。如果服务器不能连接，则直接进入CLOSED状态
4.SYN-RCVD:与3对应，服务器端接受客户端的SYN请求，服务器端由LISTEN状态进入SYN-RCVD状态。同事服务器端要回应一个ACK，发送一个SYN给客户端；还有一种情况是：客户端在发起SYN的同时接收到服务器的SYN请求，客户端就会由SYN-SENT转换到了SYN-RCVD状态
5.ESTABLISHED:服务端和客户端在完成三次握手后进入来该状态，说明已经可以开始传输数据了
6.FIN-WAIT-1：主动关闭的一方，由状态5进入该状态，具体动作是发送FIN给对方。
7.FIN-WAIT-2:主动关闭的一方，接收到对方的FIN ACK，进入此状态。由此不能再接受到对方的数据，但是还能够向对方发送数据
8.CLOSE—WAIT：接收到FIN以后，被动关闭的一方进入此状态。具体动作是接受到FIN的同时发送ACK
9：LAST_ACK:被动关闭的一方，发起关闭请求，由状态8进入此状态。具体动作是发送FIN给对方，同时在接收到ACK时会进入CLOSED状态
10：CLOSING：两边同时发起关闭请求时，会由FIN-WAIT-1进入此状态。具体动作是接收到FIN请求，同时响应一个ACK
11.TIME-WAIT:这个状态比较复杂，笔者也还没有弄清，有时间再补充吧
名词解释：
在TCP层，有个FLAGS字段，这个字段有以下几个标识：SYN, FIN, ACK, PSH, RST, URG.
其中，对于我们日常的分析有用的就是前面的五个字段。
它们的含义是：
SYN表示建立连接，
FIN表示关闭连接，
ACK表示响应，
PSH表示有 DATA数据传输，
RST表示连接重置。
其中，ACK是可能与SYN，FIN等同时使用的，比如SYN和ACK可能同时为1，它表示的就是建立连接之后的响应，
如果只是单个的一个SYN，它表示的只是建立连接。
TCP的几次握手就是通过这样的ACK表现出来的。
但SYN与FIN是不会同时为1的，因为前者表示的是建立连接，而后者表示的是断开连接。
RST一般是在FIN之后才会出现为1的情况，表示的是连接重置。
一般地，当出现FIN包或RST包时，我们便认为客户端与服务器端断开了连接；而当出现SYN和SYN＋ACK包时，我们认为客户端与服务器建立了一个连接。
PSH为1的情况，一般只出现在 DATA内容不为0的包中，也就是说PSH为1表示的是有真正的TCP数据包内容被传递。
TCP的连接建立和连接关闭，都是通过请求－响应的模式完成的。
概念补充-TCP三次握手：
位码即tcp标志位，有6种标示：SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)Sequence number(顺序号码) Acknowledge number(确认号码)
第一次握手：主机A发送位码为syn＝1，随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；
第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1)，syn=1，ack=1，随机产生seq=7654321的包；
第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1，以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1)，ack=1，主机B收到后确认seq值与ack=1则连接建立成功。
完成三次握手，主机A与主机B开始传送数据。
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据.
问题：为什么TCP需要三次握手，而不是两次，一次：
问题的本质是，信道是不可靠的，但是我们要建立可靠的连接发送可靠的数据，也就是数据传输是需要可靠的。在这个时候三次握手是一个理论上的最小值，并不是说是tcp协议要求的，而是为了满足在不可靠的信道上传输可靠的数据所要求的。
假设有A和B两端要进行通信，
1, 第一次：首先A发送一个(SYN)到B，意思是A要和B建立连接进行通信；
如果是只有一次握手的话，这样肯定是不行的，A压根都不知道B是不是收到了这个请求。
2, 第二次：B收到A要建立连接的请求之后，发送一个确认(SYN+ACK)给A，意思是收到A的消息了，B这里也是通的，表示可以建立连接；
如果只有两次通信的话，这时候B不确定A是否收到了确认消息，有可能这个确认消息由于某些原因丢了。
3, 第三次：A如果收到了B的确认消息之后，再发出一个确认(ACK)消息，意思是告诉B，这边是通的，然后A和B就可以建立连接相互通信了；
这个时候经过了三次握手，A和B双方确认了两边都是通的，可以相互通信了，已经可以建立一个可靠的连接，并且可以相互发送数据。
4, 第四次：这个时候已经不需要B再发送一个确认消息了，两边已经通过前三次建立了一个可靠的连接，如果再发送第四次确认消息的话，就浪费资源了。
如果第二个报文段B发出的(SYN+ACK)分别发送的话，也是可以理解为四次，但是被优化了，一起发送了。
四次挥手
说完TCP建立连接的时候为什么是三次，相对的就会想到为什么断开连接的时候是需要四次呢，而不是三次，五次等等呢；
本质的原因是tcp是全双公的，要实现可靠的连接关闭，A发出结束报文FIN，收到B确认后A知道自己没有数据需要发送了，B知道A不再发送数据了，自己也不会接收数据了，但是此时A还是可以接收数据，B也可以发送数据；当B发出FIN报文的时候此时两边才会真正的断开连接，读写分开。
四次挥手牵扯到的状态装换
* FIN_WAIT_1 * 表示在等待另一方的FIN报文，和FIN_WAIT_2的区别是，FIN_WAIT_1表示socket现在要主动关闭连接，在发送完FIN报文后socket进入FIN_WAIT_1状态，当收到另一方发送FIN的ACK之后立即进入FIN_WAIT_2状态；
* FIN_WAIT_2 * 同上，此时需要做的事情是可能还会接收数据，然后等待另一方的FIN；
* TIME_WAIT * 存在主动关闭的一方，表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL(Max Segment Lifetime))后即可回到CLOSED可用状态了，需要等一段时间时原因是网络是不可靠的，不能保证这个ACK发送成功了，如果失败了，对端会超时重传FIN；
* CLOSING * 表示在发送FIN之后，没有收到对方的ACK，而是收到了对方的FIN，这中情况很少见，只有在两端几乎同时关闭同一个socket的时候才会出现CLOSING状态；
* CLOSE_WAIT * 表示收到对方的FIN之后，回给对方ACK，此时处于CLOSE_WAIT状态，等待关闭，要看自己是否还有数据要发送；
* LAST_ACK * 表示收到对方的FIN之后，回给对方ACK，然后自己也要关闭发送FIN，等待另一方的ACK时候的状态；
* CLOSED * 这个状态表示连接已经断开。
借鉴链接：
https://www.jianshu.com/p/e7f45779008a
https://blog.csdn.net/li_ning_/article/details/52117463