三次握手
客户端与服务端通过三次握手，建立起可靠的双工的连接，开始传送数据。 三次握手的最主要目的是保证连接是双工的，可靠更多的是通过重传机制来保证的。
第一次握手：
客户端A主动发起 建立连接，发送SYN(syn:seq=n)包到服务器，其中序列值是随机的，之后进入SYN_SEND状态，等待服务器的回复包。
第二次握手：
服务器B确认，在服务器B收到客户端A的syn包之后，恢复客户端A一个SYN_ACK包,ACK(=n+1)必须是A发送的序列加1，这样才能A才能知道恢复的是哪一个请求，SYN的的序列值是随机的m。之后服务端进入SYN_RECV状态。
第三次握手：
客户端A收到服务端B的SYN_ACK回复之后，需要向服务端发送ACK(ACK=m+1),表示已收到确认。这样三次握手结束，客户端A进入ESTABLISHED状态，在服务端B收到回复之后直接进入ESTABLISHED状态。
SYN,ACK：标志位；ack：确认序号；seq：发送序号
四次握手
TCP 连接是全双工的，因此每个方向都必须单独进行关闭。相当于挂电话时，双方都要告诉对方自己挂电话了，自己再挂电话。
第一次握手：
客户端A进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=x（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
第二次握手:
服务器B收到连接释放报文，发出确认报文，ACK=1，ack=x+1，并且带上自己的序列号seq=y，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
第三次握手：
服务器B将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=x+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=n，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
第四次握手：
客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=n+1，而自己的序列号是seq=x+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2??MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
数据传输过程
如图所示，客户端在发送数据请求之后，服务端会返回一次ack表示已经收到请求了， 之后服务端B就开始发送数据。可以在看出，客户端一共分了十一次发送数据，加上最后一次通知客户端已经发送结束就总共十二次。
TCP提供的确认机制，可以在通信过程中可以不对每一个TCP数据包发出单独的确认包（Delayed ACK机制），而是在传送数据时，顺便把确认信息传出， 这样可以大大提高网络的利用率和传输效率。同时，TCP的确认机制，也可以一次确认多个数据报，例如，接收方收到了201，301，401的数据报，则只 需要对401的数据包进行确认即可，对401的数据包的确认也意味着401之前的所有数据包都已经确认，这样也可以提高系统的效率。
在客户端请求与服务端确认阶段。
服务端的seq=客户端请求的ack
服务端的ack=客户端请求的seq+客户端请求的len
服务端的len为0
服务端确认结束之后，开始发数据：
1.服务端的seq=客户端请求(接口请求)的ack，服务端的ack=客户端请求(接口请求)的seq+客户端请求(接口请求)的len。 服务端len=本次发送的数据长度x。为p1包。
2.服务端的seq=客户端请求(接口请求)的ack+x，服务端的ack=客户端请求(接口请求)的seq+客户端请求(接口请求)的len。 服务端len=本次发送的数据长度x。为p2包。
...(客户端会一直发数据包，直到数据被全部发送完毕。)
n.服务端的seq=客户端请求(接口请求)的ack+(n-1)x，服务端的ack=客户端请求(接口请求)的seq+客户端请求(接口请求)的len。 服务端len=本次发送的数据长度y。为pn包。
n+1.服务端的seq=客户端请求(接口请求)的ack+(n-1)x，服务端的ack=客户端请求(接口请求)的seq+客户端请求(接口请求)的len。 服务端len=本次发送的数据长度y。为pn+1包。这个包是返回接口状态码等信息，表示已经传输完毕。
在服务端传输的过程会不定期的收到客户端的返回对的ACK确认包，表示已经收到某个包。还有最后的第n次数据最后一次传输的确认包，第n+1次的确认包。
TCP—重新传输数据
无论网络设计得如何完美，都可能发生数据丢失现象。因此，TCP 提供了管理数据段丢失的方法，其中一个方法就是数据重传机制。
TCP 的客户端通常只确认相邻序列的数据。如果一个或多个数据段丢失，只确认已完成数据流中的数据段。例如，如果接收到序列号为 1500 到 3000 以及 3400 到 3500 的数据段，那么确认号应为 3001。这是因为未收到序列号为 3001 到 3399 之间的数据段。如果服务端的 TCP 未在规定时间内收到确认消息，它将根据收到的最后一个确认号重新发送数据。RFC 中未对重新发送过程进行说明，这属于 TCP 的特殊实施过程。
TCP 的标准实施流程是：主机传输数据段，并将数据段的副本列入重新发送队列，然后启动计时器。当接收到数据确认信息时，主机将从队列中删除对应数据段；如果到计时器超时还没有收到确认信息，将重新传输数据段。
现在，服务端还拥有一项备选功能：选择性确认. 如果两台主机都支持选择性确认功能，客户端便可以确认间断数据段中的数据，那么服务端就只需要重新传输丢失的数据。