首先要先了解TCP数据包的一些字段的作用： 这里只列出了用到的几个重要的。
- 序号(seq)：占4个字节，32位。 发送端告诉接收端这组的首部第一个是第多少个字节。
一整个数据包要放到缓冲区中分组传输，分组之后的每个数据包都要加上TCP首部，这里表明发送方发送该组的第一个字节是一整个大数据包(没有放缓冲区的分组之前的整个数据包)的第多少个字节。
- 确认号(ack)：占4个字节，32位。接收端告诉发送端我已经收到了多少字节，该发下一个字节了(该位为，收到的字节数+1)。
- ACK：占1位。如果该位为0，表示确认号无效，如果是1表示确认号有效。
- SYN：占1位。请求建立会话连接。当SYN=1时表示同意建立会话。
SYN=1,ACK=0 ：表示请求连接的的数据包。其实ACK是没有。
SYN=1,ACK=1 ：表示响应同意建立连接的数据包。
1.三次握手：
就是在进行可靠传输发送数据之前，要连续三次打招呼建立连接的过程。
- 三次握手的过程：
第一次握手：在每次发送之前客户端都会向服务端发送SYN(seq=x)数据包请求建立连接，客户端进入SYN_SENT状态。
第二次握手：服务器收到SYN包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（seq=y），即SYN+ACK包，此时服务器进入SYN_RECV状态
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED(TCP连接成功)状态，完成三次握手。
简单理解三次握手：
TCP的三次握手还是挺有意思的，基本思想就是“让我知道你已经知道”了。
服务器监听请求，客户端发起连接请求（第一次握手：客户端->服务端：客户端请求建立连接）。请求在路上可能存在丢失的风险， 所以当请求到了服务器后如果服务器同意建立连接会给客户端一个回信（第二次握手：服务端->客户端：服务端同意建立连接），告诉它：我已经收到请求，可以连接。 但是回信也存在一个问题，那就是回信能不能到客户端？它需要客户端给他一个回信说我已经收到批准通知了， 如果客户端一直不回复的话意味着客户端没有收到批准通知。 因此客户端一收到批准通知就立马回复（第三次握手：客户端->服务端：客户端收到了服务端的同意连接的数据包）：OK老铁我收到你的批准通知了。
三次握手结束，服务端开始进行可靠传输发送数据。
- 三次握手的作用：
为了防止服务器端开启一些无用的连接增加服务器的开销，以及防已经失效的连接请求突然又传到了服务端，从而产生错误。
2.四次挥手：
就是连续四次告别。即终止TCP连接的过程。
- 四次挥手的过程：
由于TCP连接是全双工的，所以两端都可以先挥手，并且每个方向都必须单独进行关闭。
原则是：当任意一方完成它的数据发送任务后，就能发送一个FIN的数据包来终止这个方向的连接。收到一个FIN只意味着这一方向上没有数据流动，另一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
 |
FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。 |
|
TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带 FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
|
|
| CLOSING: 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的 ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什 么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报 文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。 | |
|
FIN_WAIT_1: 其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别 是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即 进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马 上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。
|
CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对 方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。 |
| LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。 |
第一次挥手：客户端发送一个FIN=M，来关闭客户端到服务器端的数据传送，客户端进入FIN_WAIT_1状态。 意思是说"我客户端没有数据要发给你了，准备要关闭连接了"，但是如果你服务器端没有准备好的话，则不必急着关闭连接，可以先准备准备。
第二次挥手：服务器端收到FIN后，向客户端发送ack=M+1，回复确认收到了客户端的FIN的数据包，但是服务端要准备一下。 意思是告诉客户端，你的请求我收到了，但是我还没准备好，请继续你等我的消息。这个时候客户端就进入FIN_WAIT_2状态，客户端继续等待服务器端的FIN报文。
第三次挥手：当服务器端准备已经完成，准备关闭连接，则向客户端发送FIN=N报文。告诉客户端，我这边准备好了，要关闭连接了。服务器端进入LAST_ACK状态。
第四次挥手：客户端收到FIN=N报文后，就知道可以关闭连接了，但是他还是不相信网络，怕服务器端不知道要关闭，所以客户端向服务器端发送ack=N+1后进入TIME_WAIT状态，如果服务器端没有收到ACK则可以重传。服务器端收到ACK后，就知道可以断开连接了。客户端等待了2MSL(MSL：报文最大生存时间。RFC 793中规定了MSL为2分钟，实际应用中常用的是30秒，1分钟和2分钟等)后依然没有收到回复，则证明服务器端已正常关闭，那好，我客户端也可以关闭连接了。最终完成了四次握手。
简单理解四次挥手：
1、女的跟男的说：对不起，我不喜欢你了，分手吧。
2、男的跟女的说：嗯，但是我还没准备好，让我准备准备。
3、男的跟女的说：我准备好了，分手吧，再见。
4、女的跟男的说：好的，再见。
3.三次握手和四次挥手中的常见问题：
1.为什么连接的时候是三次握手，关闭的时候却是四次握手？
答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
2.为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。
3.为什么不能用两次握手进行连接？
答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
4.如果已经建立了连接，但是客户端突然出现故障了怎么办？
答：TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。