TCP报文段的首部
源端口和目的端口: 各占2个字节，分别写入源端口号和目的端口号(TCP报文需要的是端口号，往下封装会在IP报文中添加上源IP和目的IP)
序号: 4个字节，[0-了2^32-1]一共有2^32个序号，因为TCP是面向字节流;在一个TCP连接中传送的字节流中的每一个字节都按顺序编号;整个要传送的字节流的起始序号必须在连接建立的时候设置（也就是一开始三次握手的时候发送的SYN包中的seq字段部分)。TCP报文中的首部的序号字段则是本报文段所发送的数据的第一个字节的序号。
确认号：ack;4个字节，表示的是期望收到对方下一个报文段的第一个数据字节的序号;比如说，B正确的收到了A发送过来的一个报文段，其序号字段值为501，且数据的长度为200字节（501-700），这表明B正确受到了A发送的到序号700为止的数据，因此B希望收到A的下一个数据序号是701;所以ack=701。
总之，若确认号为N，则表明到序号N-1为止的所有数据已经正确接收。
确认ACK：仅当ACK=1时，确认号字段（ack）有效，当ACK=0的时候，确认号字段无效。TCP规定，在连接建立后所有传送的报文段的ACK都置1。
终止FIN：用来释放一个连接，当FIN=1的时候表明此报文段的发送方的数据已经发送完毕，并且要求释放连接。
窗口：占2个字节，值在[0-2^16-1]之间的整数，指的是发送本报文段的一方的接收窗口（而不是自己的发送窗口），窗口值主要是用来告诉对方：从本报文段首部中的确认号算起，我目前的允许对方发送的数据量——主要是用来解决防止发送方发送数据过快而来不及接收，总之窗口值作为接收方让发送方设置其发送窗口大小的依据。
三次握手：
（ps:图片来自https://blog.csdn.net/qzcsu/article/details/72861891这位大佬的博客）
前期准备：
TCP服务器进程先创建传输控制块TCB，准备接受客户端进程的连接请求，然后服务器进程就处于LISTEN（监听）状态，等待客户端的连接请求。
TCP客户端进程也是先创建传输控制块TCB，然后向服务器端发送连接请求报文。
第一次握手：
客户端发送SYN包(SYN=1,seq=x)给服务器端，等待服务器的确认，进入SYN_SEND（同步已发送）状态。
解释：第一次握手客户端发送的SYN包中，SYN是同步序列编号，需要设置为1，seq是用于建立连接之后通信所用的，表示的是建立连接后要传输的数据的起始序号，TCP规定，虽然第一次握手发送的SYN包没有携带数据，但是也要占用一个序号，即客户端发送数据的时候只能用x+1开始发送。
第二次握手：
服务器接收到客户端发送的SYN包，如果同意建立连接，那么就发送了一个确认报文段(ACK=1,ack=x+1，SYN=1,seq=y),进入SYN_RECV（同步收到）状态。
解释：第二次握手中的ACK=1是为了让确认号字段ack有效，而ack=x+1表明的是服务器方已经成功接收到客户端发送的到x为止（包括x）的所有数据；并且希望下一次收到客户端发送过来的数据是从x+1开始；同时由于是全双工的通信，服务器端设置SYN=1,seq=y，用于建立连接后的发送数据的起始序号；TCP规定：虽然这份确认报文段不携带数据，但是也要占用一个序号的位置。
第三次握手：
客户端接收到服务器端发送的确认报文段，并且向服务器发送ACK确认报文段（seq=x+1，ack=y+1，ACK=1），此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。
解释：第三次握手客户端发送了ACK确认报文(ACK=1,ack=y+1，seq=x+1)，ACK=1和ack=y+1表示对服务器发送的确认报文段的一个确认，同时希望下次收到的数据的起始序号从y+1开始，TCP规定：本次的ACK确认报文段可以携带数据，但是如果不携带数据则不消耗序号。
为什么要三次握手？
**为了确保通信双方的发送信息和接收信息的能力没问题。
假设客户端为A,服务器端为B
1.一开始A发送SYN包给B，B收到了A发送的SYN包
---->B自己就会觉得，自己的接收信息能力没问题。
2.B发送确认报文段给A，并且A收到B发送的包
---->A收到了包之后，首先因为B不会无端端发送信息给A，A就会知道刚刚自己成功发送了信息B，说明A自己的发送能力没问题，其次是A现在接收到了B的包，证明A自己的接收能力也没问题。但是这个时候B并不知道自己的发送能力怎么样，所以需要再A发送多一次进行多一次握手才可以。
3.A再发送ACK包给B
---->B目前还不知道自己的发送能力怎么样，直到A发送了确认包回来，那么就说明B自己的发送能力没问题。
好~~开心的通信吧~~
四次挥手：
（ps:图片来自https://blog.csdn.net/qzcsu/article/details/72861891这位大佬的博客）
过程描述：
1.客户端进程发出连接释放报文(FIN包），并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2.服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1（表示对u+1之前的发送的数据进行一个确认），并且带上自己的序列号seq=v（因为由于是客户端提出的关闭连接；但是服务器端可能还有数据没有发送完），此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间
3.客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4.服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认（w-v得到的就是服务器方在这段时间发送的数据的总量。）
5.客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6.服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
为什么客户端最后还要等待2MSL？
MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。
第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。
为什么建立连接是三次握手，关闭连接确是四次挥手呢？
建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。
如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
参考：网上某位大佬的博客，路径为：https://blog.csdn.net/qzcsu/article/details/72861891；侵权请告知删除。