-
第一次握手：客户端向服务端发送连接请求报文段，TCP报文段首部同步位SYN=1，初始序号seq=x。客户端进程进入同步发送状态。
-
第二次握手：服务端收到连接请求报文段后，向客户端发送确认报文段。把TCP报文段首部SYN位和ACK位置为1，初始序号seq=y，确认号ack=x+1。服务端进入同步接收状态。
-
第三次握手：客户端接收到确认报文段后，向服务端发送ACK报文段，ACK位置为1，初始序号seq=x+1，确认号ack=y+1。TCP连接建立。
为什么是三次握手而不是两次？
为了防止已失效的连接请求报文段又传送到服务端导致产生错误。例如：
有一种情况，客户端发送的连接请求报文段丢失了，进行超时重传，建立TCP连接，数据传输，然后TCP连接释放。但如果第一次发送的请求报文段没有丢失。只是在网络中滞留，延误到上次连接释放了才到达服务端。若是只有两次握手，服务端接受到连接请求报文段，返回确认报文段，由于现在客户端并没有发送连接请求报文段，所以不理睬确认报文段。服务端以为连接建立，一直等待客户端发送数据，服务端的资源被白白浪费。三次握手时，只有服务端接收到客户端的ACK报文段才会认为TCP连接建立了。 -
第一次挥手：客户端向服务端发送连接释放报文段，报文段首部FIN位设为1，序号seq=u，等于已经上传数据的最后一个字节序号加1.
-
第二次挥手：服务端收到连接释放报文段后，发出确认报文段，报文段首部ACK位设为1，序号seq=v，位服务端最后发送数据的最后一个字节序号加1，确认号ack=u+1.这是TCP连接处于半关闭状态，客户端不能发送数据，服务端还可以发送数据给客户端。
-
第三次挥手：服务端没有数据需要发送给客户端时，服务端发送链接释放报文段，报文段首部FIN位设为1，ACK位设为1，序号seq=w，确认号ack=u+1。服务端进入最后确认状态，等待客户端的确认。
-
第四次挥手，客户端收到连接释放报文段后，发送确认报文段，ACK位设为1，序号seq=u+1，确认号ack=w+1。
客户端经过设置的一段时间才释放TCP连接。服务段收到确认报文后立即释放TCP连接。
TCP如何保证数据的可靠传输：
TCP是面向字节流的，将TCP报文段看成一连串无结构的字节流。要保证数据传输的可靠性无非就是从两个角度保护数据：
-
当传输的数据丢失了或网络滞留过长也就是超时了，让发送发重传出现差错的数据。
-
当接收方来不及处理收到的数据，能够即使通知发送方适当地降低发送数据的速度。
TCP为了保证数据的可靠性传输，使用了一些可靠传输协议。 -
最简单的是停止等待协议（超时重传）：
假如将A叫做发送方，B叫做接收方的话。停止等待协议就是每发送完一个分组就停止发送，等待对方的确认，在收到确认后再发送下一个分组。假设A发送M1分组后一直未收到确认，可能是M1分组丢失或是B的确认丢失。所以A使用超时重传机制，每发送完一个分组后设置一个计时器，若计时器到期之前还未收到对方确认则认为刚刚发送的分组丢失，重传发送过的分组。收到确认则撤销超时计时器。停止等待协议简单但信道利用率过低，通信效率太差！ -
滑动窗口协议：
TCP报文段以字节位单位进行编号。发送方维护一个发送窗口，发送窗口里的分组可以连续发送出去，不需要等待对方确认，提高了信道利用率。发送窗口的大小及位置是由接收方返回的确认报文段中窗口值和ack确认号决定。假设窗口值为20，ack=100，那么发送窗口为100-120.
接收方同样维护一个接受窗口，大小和发送窗口一样，起始字节为确认号。接受方采用累计确认的方式，对按序到达的最后一个分组发送确认，加入收到31，32分组，但是没收到30分组，则不会发送32分组的确认，而是29分组的确认。
发送窗口通过收到接收方发送的确认里的确认来***向前滑动窗口到达确认号加一的位置***。接受窗口向前滑动到已发送确认的最后一个字节加一处。 -
回退N帧协议：
运用滑动窗口协议实现，发送方可以连续发送分组。若有一个分组在超时一段时间后未收到确认，发送方不知道该分组及该分组之后所有分组的下落。则重新发送该出错分组之后的所有已发送分组。这样可以提高传输效率，但是如果网络通信差，分组总丢失导致总需要重传使得传输效率进一步下降。 -
选择性重传协议：
接收方需要缓存所有接收到的分组，不管是否按序到达。当某个分组出现错误时，只会要求重传出错分组。这样提高了传输效率，减少通信量，但是需要占用接受方过多的缓存。 -
TCP流量控制： TCP利用滑动窗口协议实现流量控制。流量控制就是让发送方的发送速率不要太快，接收方来得及接收。
发送方通过接收方确认报文段首部里的窗口值和确认号ack来确定发送窗口大小和位置，同样窗口值也确定了接收窗口的大小。通过窗口值来协调发送窗口和接受窗口的大小，实现流量控制。
有可能B向A发送0窗口的确认报文段之后，B又有了存储空间，发送非零窗口的报文段。但该报文段丢失了，导致A，B互相等待的死锁现象。为了解决这个问题，TCP为每个连接设置了持续计时器，发送方收到0窗口报文段时，开启持续计时器，等时间到期后发送一个0窗口的探测报文段，接收端确认时给出当前窗口值。若还未0则发送端重置计时器，不为0则死锁局面打破了。
TCP拥塞控制：
网络中链路容量，交换节点缓存等都是网络资源，如果通信过程中对网络中某一资源需求超过了该资源所能提供的可用部分，网络出现拥塞。拥塞控制就是防止过多的数据注入网络中，使网络中的路由器和链路不至于过载。当网络负载到一定程度网络吞吐量不升反而下降则表示进入拥塞状态。流量控制是对点对点通信量的控制，而拥塞控制是一个全局性的过程，涉及到所有主机，路由器和降低吞吐量的所有因素。
四种进行拥塞控制的方法
慢开始算法：发送方维持一个拥塞窗口cwnd的状态变量，大小取决于网络的拥塞程度，让自己的发送窗口大小等于拥塞窗口变量。主机刚刚开始发送数据时，先探测一下，然后从小到大逐渐增大拥塞窗口变量。每次收到一个新的确认报文段把拥塞窗口变量增加至多一倍数值。这样使分组注入到网络的速率合理。
拥塞避免算法：也是让cwnd拥塞窗口逐渐加大，不过每次加一而不是加倍。拥塞窗口值是线性增长而不是指数增长。
慢开始算法和拥塞避免算法合作使用。一开始使用慢开始算法，拥塞窗口值指数增长，达到慢开始阈值时，使用拥塞避免算法，线性增长。当发送端没有按时收到确认表示网络拥塞，将慢开始阈值减半，拥塞窗口值重置为1.让发送方注入的分组迅速减少。
快重传和快恢复：
要求接收方每次收到一个失序的报文段就立即重新发送上一个收到报文段的确认，让发送方及早直到有报文段没有到达接收方，发送方只要一连收到三个重复确认就立即重传对方尚未收到的报文段。采用快重传和快恢复使整个网络吞吐量增大。