如果你读到这篇博客，这个绝对是最容易懂的TCP三次握手和四次挥手，今天面试被问到了TCP三次握手和四次挥手，没有回答上来，回来查了很多资料，现在总算有点眉目，将自己对TCP的理解写下来。
一.TCP数据结构介绍
原端口号：表示客户端发送这个tcp报文程序的通信端口号。
目的端口：表示服务端接受这个tcp报文程序的通信端口号。
序号：可以看作是这个tcp报文的唯一id。
确认序号：可以看作是接收方接受下一个tcp报文的序列号。发送方发送一个确认编码给接收方，接收方收到这个确认编码后会验证这个报文是不是我想要的，如果是就接受，不是就丢弃。所以这个确认编码是给接收方使用的。
ACK：确认标志，如果是1的话，表示你上次发给我的报文我已经接收到了。
SYN：建立连接的标志，如果是1的话，表示我想和你建立连接。
FIN：关闭连接的标志，如果是1的话，表示我想和你断开连接。
二.三次握手
1.客户端发送第一次请求，SYN=1，seq=J，seq表示这个报文的id=J，SYN=1就是告诉服务端我想和你建立连接。
2.服务端接收到请求后发送SYN=1，ACK=1，ack=J+1，seq=K，seq=K表示服务端发送的这个报文id是K，ACK=1表示你上次发给我的报文我已经确认接受了，ack=J+1表示我接受到你上一个报文的证据，确认号表示接受端向发送端确实接收到你发的报文了。
3.客户端收到服务端的请求后，要表示我已经知道你答应和我建立连接了，所以会发送一个报文，发送的seq=J+1，ACK=1，ack=K+1，表示这个报文的id是seq=J+1，ACK表示我确认接受到你答应接受连接的消息，ack=K+1表示这就是我接受到的证据，这一步没有SYN=1，因为到这里不再是发起连接了，而只是表示确认连接了。
这里的确认号的编码为什么都是加一，那是因为连接报文和确认报文的所占的大小都是1。
如果没有第三步，客户端不给服务端发知道服务端答应接受连接的消息会怎么样，假设客户端第一次发送的请求由于网络延迟，很晚才被服务端接收到，服务端收到消息后表示自己愿意接受你的请求，这个时候由于中间时间过得太久了，所以客户端已经放弃这次连接了，客户端在接受到服务端发来的请求的时候，但是客户端这个时候没有发送给服务端的连接请求所以不予理睬，这个时候服务端就一直等待着客户端发消息过来，这样会浪费大量的服务端资源。
三.四次挥手
第一步：客户端向服务端发送断开连接的请求，这个请求是客户端不再向服务端发送消息了，seq=u，FIN=1，ACK=1，seq是u表示这次报文的编码，ACK=1表示你服务端上次发送给我客户端的数据我已经接收到了，FIN=1，表示这次我要和你断开连接。
第二步：服务端接收到客户端发过来断开连接的消息后，断开客户端和服务端的连接，然后告诉客户端，客户端到服务端的连接已经断开了，怎么告诉呢，ACK=1，FIN=0，ack=u+1，ACK=1表示你发送断开连接的消息我已经接受到了，FIN=0表示我现在还不想和你断开，只是你和我断开了，但是我和你还没有断开，我还可以继续给你发消息，ack=u+1表示我接收到你断开消息的证据。
第三步：服务器向客户端发送断开的消息，这个请求是服务端不再向客户端发送消息了，seq=w，FIN=1，ACK=1，seq是w表示这次报文的编码，ACK=1表示你客户端上次发送给我服务端的数据我已经接收到了（感觉这里不需要了，因为上次服务端确认断开的时候，已经发送了），FIN=1，表示这次服务端要和客户端断开连接。
第四步：客户端ACK=1，FIN=0，ack=w+1，客户端接受到服务端发过来要求断开服务端和客户端连接的请求后，已经断开，然后发送消息给服务端，你和我之间的连接已经断开了，ACK=1表示确认，ack=w+1表示我接受到你请求确认的证据。
这里可能有点绕，客户端和服务端是双向连接的，客户端连接服务端，服务端连接客户端，如果只有客户端连接服务端这一条线的话，客户端可以发送消息给服务端，但是客户端收不到消息被接受的确认消息了。