坚持苦学 TCP ，终于把 TCP 协议给学明白了，坚持看完你会收获很大

最新推荐文章于 2022-10-20 18:15:46 发布

程序员蛋蛋

最新推荐文章于 2022-10-20 18:15:46 发布

阅读量3.4k

点赞数 13

分类专栏：网络文章标签： tcp/ip 网络网络协议

本文链接：https://blog.csdn.net/qq_34375473/article/details/122766413

版权

网络专栏收录该内容

12 篇文章 4 订阅

订阅专栏

TCP 是面向连接的、可靠的流协议。流就相当于不间断的数据结构。

TCP 之所以能够提供可靠传输就在于通过校验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制去实现的。

下面会通过介绍 TCP 的首部格式进行展开，一一阐述 TCP 三次握手、四次挥手、滑动窗口、拥塞控制、流量控制和 UDP 协议。

TCP首部格式

源端口号：表示发送端的端口号，字段长 16 位。
目标端口号：表示接收端端口号，字段长度 16 位。
序列号：字段长 32 位。序列号是指发送数据的位置。每发送一次数据，就累加一次该数据字节数的大小。

序列号不会从0开始，是在建立连接的时候由计算机随机生成一个数作为初始值，通过 SYN 包传给接收端主机。
确认应答号：长度是 32 位。是指下一次应该收到的数据的序列号。发送端收到这个确认应答以后可以认定这个序号之前的数据都已经被正常接收。
数据偏移：表示数据开始的地方离 TCP 起始处有多远。实际上也就是表示 TCP 首部的长度。
保留：该字段是为了以后扩展时使用，长度是 4 位。
控制位：长度为 8 位。每一位从左到右分别是 CWR、ECE、URG、ACK、PSH、RST、SYN、FIN。具体我会在讲解 TCP 三次握手和四次挥手再重点说明。
窗口大小：该字段用于通知相同 TCP 首部的确认应答所指位置开始能接受的数据大小。TCP不允许发送超过该大小的数据。
校验和：由发送端填充，接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。注意，这个校验不仅包括TCP头部，也包括数据部分。这也是TCP可靠传输的一个重要保障。
紧急指针：该字段表示本报文中紧急数据的指针。从数据部分的首位到紧急指针所指位置为止为紧急数据。
选项：用于提高 TCP 的传输性能，是可变长的可选信息。最多包含 40 字节。

TCP 三次握手

三次握手

三次握手说明：

由客户端发送建立 TCP 连接的请求报文，报文中包含 seq 序列号，是由发送端随机生成的，并且将报文中的 SYN 字段设置为 1，表示需要建立 TCP 连接，客户端进入 SYN_SEND 状态。(SYN=1.seq=x,x代表随机生成的数值)
由服务器端回复客户端发送的 TCP 连接请求报文，其中包含 seq 序列号，是由回复端随机生成的，并且将 SYN 设置为 1,也会产生一个 ACK 字段，字段值是在客户端发送过来的序列号 seq 基础上加 1,以便客户端收到信息时，知道自己的 TCP 建立请求已经得到验证,服务端进行 SYN_SEND 状态。(SYN =1,ACK = x+1,seq=y,y为随机生成数值)
客户端收到服务端发送的 TCP 建立验证请求后，会使自己的序列号加 1 表示，并且再次回复 ACK 验证请求，在服务端发过来的 seq 上加 1 进行回复，客户端进入 ESTABLISHED 状态，当服务端接收到请求，也进入 ESTABLISHED 状态，TCP 握手结束。(SYN = 1,ACK = y+1,seq = x+1)

为什么三次握手？

1. 检查双方是否都具备发送和接收数据的能力

TCP 是基于全双工的可信传输协议，也就意味着数据可以同时在两个方向上传输。在建立三次握手的过程中也就是在检验双方发送和接收数据的能力是否具备。

第一次握手，这时候客户端知道自己具备了发送数据的能力，但还不知道服务端是否有接收和发送数据的能力。

第二次握手，当服务端接收到报文后，回复确认报文，此时服务端知道客户端具有发送报文的能力，并且知道自己具有接收和发送数据的能力，但还不知道客户端是否具有接收数据的能力。

第三次握手，当客户端收到服务端的确认报文后，知道服务端具备接收和发送数据的能力，因为服务端还不知道客户端具备接收数据的能力，所以还需要发送一个确认报文，告知服务端自己是具有接收能力的。

2.防止重复连接

在网络状况比较复杂或比较差的情况下，发送方可能会连续发送多次建立连接的请求。如果 TCP 握手的次数只有两次，那么接收方只能选择接受请求或者拒绝连接请求，但并不清楚这次的请求是否是正常的请求。

如果是三次握手的话，客户端在接收到服务端 seq+1 的消息之后，通过对比，就可以判断当前连接是否是历史连接，如果是的话就会发送终止报文给服务端终止连接。如果不是历史连接就发送确认报文建立连接。

四次挥手

建立一个 TCP 连接需要三次握手，而终止一个 TCP 连接需要经过四次挥手，这是由于 TCP 的半关闭特性造成的，TCP 提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。

四次挥手

第一次挥手：客户端发送一个 FIN 报文(请求连接终止：FIN = 1)，报文中会指定一个序列号 seq = u。并停止再发送数据，但依然能够接收数据，主动关闭 TCP 连接。此时客户端处于 FIN_WAIT-1 状态，等待服务端确认。

第二次挥手：服务端收到 FIN 之后，会发送一个 ACK 报文，且把客户端的序号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。客户端收到服务端的确认后，进入 FIN-WAIT-2 状态，等待服务端发出的连接释放报文段。

前两次挥手既让服务端知道了客户端想释放连接，也让客户端知道了服务端了解了自己想要释放连接的请求。于是，可以确认关闭客户端到服务端方向上的连接的。

第三次挥手：如果服务端也想断开连接，会发送 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 状态，等待客户端的确认，并停止向客户端发送数据，但服务端仍能够接收从客户端传输过来的数据。

第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答(ack = w+1)，且把服务端的序列值 +1 作为自己 ACK 报文的序号值(seq=u+1)，此时客户端处于 TIME_WAIT 状态，并在这个状态等待 2MSL。服务端收到从客户端发出的 TCP 报文之后结束 LAST-ACK 阶段，进入 CLOSED 阶段。

客户端等待完 2MSL 之后，结束 TIME-WAIT 阶段，进入 CLOSED 阶段，由此完成四次挥手。

为什么客户端在 TIME-WAIT 阶段要等 2MSL？

为的是确认服务端是否收到客户端发出的 ACK 确认报文。

当客户端发出最后的 ACK 确认报文后，并不能确定服务端能够接收到，所以在发完之后，等待 2MSL，服务端在 1MSL 内没有收到客户端发出的 ACK 确认报文，就会再次向客户端发出 FIN 报文。