TCP报文段格式与三次握手和四次挥手的协议
一、TCP传送的数据单元是报文段
二、TCP报文段的首部格式
- 源端口：占16比特，写入源端口号，用来标识发送该TCP报文段的应用进程。
- 目的端口：占16比特，写入目的端口号，用来标识接收该TCP报文段的应用进程。
- 序号：占32比特，取值范围[0，2^32-1]，序号增加到最后一个后，下一个序号就又回到0。
指出本TCP报文段数据载荷的第一个字节的序号。
4.确认号：占32比特，取值范围[0，2^32-1]，确认号增加到最后一个后，下一个确认号就又回到0。指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认。（若确认号=n，则表明,到序号n-1为止的所有数据都已正确接收,期望接收序号为n的数据。）
5.数据偏移:占4比特，并以4字节为单位。
用来指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远。
这个字段实际上是指出了TCP报文段的首部长度。
首部固定长度为20字节，因此数据偏移字段的最小值为(0101)2，加上最大40字节扩展首部，首部最大长度60字节，数据偏移字段应取最大值(1111)2。
6.保留：占6比特，保留为今后使用，但目前应置为0。
7.窗口:占16比特，以字节为单位。指出发送本报文段的一方的接收窗口。窗口值作为接收方让发送方设置其发送窗口的依据。这是以接收方的接收能力来控制发送方的发送能力,称为流量控制。
8.校验和:占16比特，检查范围包括TCP报文段的首部和数据载荷两部分。在计算校验和时，要在TCP报文段的前面加上12字节的伪首部。
9.紧急指针:占16比特，以字节为单位，用来指明紧急数据的长度。
当发送方有紧急数据时，可将紧急数据插队到发送缓存的最前面,并立刻封装到一个TCP报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据,紧急数据之后是普通数据。
10.选项部分：其最大长度可根据TCP首部长度进行推算。TCP首部长度用4位表示，字节长度为0-40B（字节）（(2^4-1)*4-20=40），必须以4B为单位变化，必要时可以填充0。
11.控制位
URG（紧急位）：表示本报文段中发送的数据是否包含紧急数据。后面的紧急指针字段（urgent pointer）只有当URG=1时才有效
ACK（确认位）：表示是否前面确认号字段是否有效。只有当ACK=1时，前面的确认号字段才有效。TCP规定，连接建立后，ACK必须为1,带ACK标志的TCP报文段称为确认报文段
PSH（急切位）：提示接收端应用程序应该立即从TCP接收缓冲区中读走数据，为接收后续数据腾出空间。如果为1，则表示对方应当立即把数据提交给上层应用，而不是缓存起来，如果应用程序不将接收到的数据读走，就会一直停留在TCP接收缓冲区中
RST（重置位）：如果收到一个RST=1的报文，说明与主机的连接出现了严重错误（如主机崩溃），必须释放连接，然后再重新建立连接。或者说明上次发送给主机的数据有问题，主机拒绝响应，带RST标志的TCP报文段称为复位报文段
SYN（同步位）：在建立连接时使用，用来同步序号。当SYN=1，ACK=0时，表示这是一个请求建立连接的报文段；当SYN=1，ACK=1时，表示对方同意建立连接。SYN=1，说明这是一个请求建立连接或同意建立连接的报文。只有在前两次握手中SYN才置为1，带SYN标志的TCP报文段称为同步报文段
FIN（断开位）：表示通知对方本端要关闭连接了，标记数据是否发送完毕。如果FIN=1，即告诉对方：“我的数据已经发送完毕，你可以释放连接了”，带FIN标志的TCP报文段称为结束报文段
三、三次握手建立连接
（1）首先客户端向服务器端发送一段TCP报文，其中：
- 标记位为SYN，表示“请求建立新连接”;
- 序号为Seq=X（X一般为1）；
- 随后客户端进入SYN-SENT阶段。
（2）服务器端接收到来自客户端的TCP报文之后，结束LISTEN阶段。并返回一段TCP报文，其中：
- 标志位为SYN和ACK，表示“确认客户端的报文Seq序号有效，服务器能正常接收客户端发送的数据，并同意创建新连接”（即告诉客户端，服务器收到了你的数据）；
- 序号为Seq=y；
- 确认号为Ack=x+1，表示收到客户端的序号Seq并将其值加1作为自己确认号Ack的值；随后服务器端- 进入SYN-RCVD阶段。
（3）客户端接收到来自服务器端的确认收到数据的TCP报文之后，明确了从客户端到服务器的数据传输是正常的，结束SYN-SENT阶段。并返回最后一段TCP报文。其中：
-
标志位为ACK，表示“确认收到服务器端同意连接的信号”（即告诉服务器，我知道你收到我发的数据了）；
-
序号为Seq=x+1，表示收到服务器端的确认号Ack，并将其值作为自己的序号值；
-
确认号为Ack=y+1，表示收到服务器端序号Seq，并将其值加1作为自己的确认号Ack的值；
-
随后客户端进入ESTABLISHED阶段。
服务器收到来自客户端的“确认收到服务器数据”的TCP报文之后，明确了从服务器到客户端的数据传输是正常的。结束SYN-SENT阶段，进入ESTABLISHED阶段。
即：
- 发送方向接收方发送SYN请求
- 接收方接收到此请求后会主动回复一个ACK，并且同时也发送一个SYN请求
- 发送方接收到接收方发来的SYN请求后，给出一个ACK确认。
通俗的说法
- Client：我所有东西都说完了
- Server：我已经全部听到了，但是等等我，我还没说完
- Server：好了，我已经说完了
- Client：好的，那我们的通信结束
四、四次挥手释放连接
（1）首先客户端想要释放连接，向服务器端发送一段TCP报文，其中：
-
标记位为FIN，表示“请求释放连接“；
-
序号为seq=u；
-
标记位ACK表示对最近接收数据的确认
-
确认号ack表示对最近接收数据最后一个序号+1，即期待下一次发送的序号。
-
随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在客户端到服务器端方向上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。
注意：这里不发送的是正常连接时传输的数据(非确认报文)，而不是一切数据，所以客户端仍然能发送ACK确认报文。
（2）服务器端接收到从客户端发出的TCP报文之后，确认了客户端想要释放连接，随后服务器端结束ESTABLISHED阶段，进入CLOSE-WAIT阶段（半关闭状态）并返回一段TCP报文，其中：
-
标记位为ACK，表示“接收到客户端发送的释放连接的请求”；
-
序号为seq=v；
-
确认号为ack=u+1，表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值；
-
随后服务器端开始准备释放服务器端到客户端方向上的连接。
客户端收到从服务器端发出的TCP报文之后，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段前"两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。于是，可以确认关闭客户端到服务器端方向上的连接了。
（3）服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报文，其中：
- 标记位为FIN，ACK，表示“已经准备好释放连接了”。注意：这里的ACK并不是确认收到服务器端报文的确认报文。
- 序号为seq=w；
- 确认号为ack=u+1；表示是在收到客户端报文的基础上，将其序号seq值加1作为本段报文确认号ack的值。
- 随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数 据，但是服务器端仍然能够接收从客户端传输过来的数据。
（4）客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文，其中：
- 标记位为ACK，表示“接收到服务器准备好释放连接的信号”。
- 序号为seq=u+1；表示是在收到了服务器端报文的基础上，将其确认号Ack值作为本段报文序号的值。
- 确认号为ack=w+1；表示是在收到了服务器端报文的基础上，将其序号Seq值作为本段报文确认号的值。
- 随后客户端开始在TIME-WAIT阶段等待2MSL
服务器端收到从客户端发出的TCP报文之后结束LAST-ACK阶段，进入CLOSED阶段。由此正式确认关闭服务器端到客户端方向上的连接。客户端等待完2MSL之后，结束TIME-WAIT阶段，进入CLOSED阶段，由此完成“四次挥手”。
即：
- 发送方向接收方发送一个FIN请求
- 接收方收到此请求后给出一个ACK确认（半关闭状态）
- 接收方发送一个FIN请求给发送方
- 发送方收到接收方的FIN请求后，回复一个ACK
五、为什么“握手”是三次，“挥手”却要四次
TCP建立连接时之所以只需要"三次握手"，是因为在第二次"握手"过程中，服务器端发送给客户端的TCP报文是以SYN与ACK作为标志位的。SYN是请求连接标志，表示服务器端同意建立连接；ACK是确认报文，表示告诉客户端，服务器端收到了它的请求报文。
即：SYN建立连接报文与ACK确认接收报文是在同一次"握手"当中传输的，所以"三次握手"不多也不少，正好让双方明确彼此信息互通。
TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是分别由第二次和第三次"握手"传输的。建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。
所以是“三次握手”，“四次挥手”。
六、 为什么客户端在TIME-WAIT阶段要等2MSL
为的是确认服务器端是否收到客户端发出的ACK确认报文。
当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器。MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。
服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；
如果客户端在2MSL内，再次收到了来自服务器端的FIN报文，说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时；否则客户端在2MSL内没有再次收到来自服务器端的FIN报文，说明服务器端正常接收了ACK确认报文，客户端可以进入CLOSED阶段，完成“四次挥手”。
所以，客户端要经历时长为2SML的TIME-WAIT阶段；这也是为什么客户端比服务器端晚进入CLOSED阶段的原因。
七、如果已经建立了连接，但是客户端突然出现故障了怎么办?
TCP设有一个保活计时器，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会币新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文股，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接若就关闭连接。
