吃透 TCP：可靠传输完整原理【上】

[1. TCP协议段格式](#1. TCP协议段格式)

[2. TCP协议特点](#2. TCP协议特点)

[2.1 确认应答](#2.1 确认应答)

[2.2 超时重传](#2.2 超时重传)

[2.3 连接管理](#2.3 连接管理)

[2.3.1 三次握手](#2.3.1 三次握手)

[2.3.1.1 三次握手的意义](#2.3.1.1 三次握手的意义)

[2.3.2 四次挥手](#2.3.2 四次挥手)

TCP（Transmission Control Protocol，传输控制协议），是传输层面向字节流的全双工不可靠传输协议。

1. TCP协议段格式

TCP协议段格式包含首部，选项（可选） 和数据部分。格式如图：

各个字段的含义：

1.**源端口号/目的端口号：**分别表示数据从哪个应用进程（源端口号）来，到哪个应用进程（目的端口）去；

序号/确认号：后文确认应答和超时重传详细介绍。

3.**首部长度：**TCP头部长度，用来表示TCP头部有多少个32位bit（4个字节），所以TCP首部的最大长度是 15*4=60 。

标志位：

URT：表示紧急指针是否有效。

ACK：表示确认号是否有效。

PSH：提醒接收端将接收缓冲区的数据读走。

RST：对方要求重新建立连接。我们把带有RST的报文称为复位报文段。

SYN：要求建立连接。我们把带有SYN的报文称为同步报文段。

FIN：向对方要求断开连接。我们把带有FIN的报文称为结束报文段。

**窗口大小：**后面讲到滑动窗口后再详细介绍。

**校验和：**发送端填充该字段，进行CRC计算校验和。接收端校验不通过，则认为该数据出现错误，直接丢弃。此处的校验和不仅包括首部还包含数据部分。

**紧急指针：**用来指定哪些数据需要紧急传。

8 .**头部选项：**后面详细讲。

2. TCP协议特点

我们都知道UDP是不可靠传输，所以它的传输过程是很简单的。但是TCP是可靠传输，但网络传输的过程中会遇到千奇百怪的问题，为了保证TCP传输的可靠性，TCP协议设置了一系列机制来保证数据传输的可靠性和高效性，以下一系列TCP协议的机制可以让我们更深入地了解TCP协议的传输可靠性。

2.1 确认应答

确认应答是指，发送端向接收端发送数据了之后，接收端在收到并校验成功数据后，向发送端发送确认应答ACK，告知发送端已成功接收到，并发送确认号告知下一次从哪里开始发（TCP将每个字节的数据都进行了编号，即为序列号），如图：

2.2 超时重传

发送方发送完数据后，等待接收方的确认应答，但不会一直等待，TCP设置了最长的等待时间，一旦超过该时间还没有收到应答消息，就会进行重新传输数据给接收方，这就叫超时重传。但发送方没有收到确认应答有几种情况：

数据在发送过程中丢失，产生丢包。
主机B发送的确认报文ACK丢失。

还有一种情况就是由于网络拥堵，导致发送时间超出最长等待时间，触发重传。于是主机B会收到大量重复数据，通过前面提到的序列号就可以区分哪些是重复数据，并将重复数据丢弃。

**❓问题：**那么超时时间是如何确定的呢？

在比较理想的情况下，此时选择一个最短的时间，能够保证 " 确认应答一定能够在这个时间返回 " 。

但是由于网络的不稳定性，超时时间的长短是有差异的；当超时时间太短，会频繁地发送重复包；当超时时间太长，会影响重传机制的。

TCP为了在任何情况下都能够有高效的通信，因此会动态计算超时时间。

Linux中（Windows和BSD Unix）通常以500ms为一个单位控制超时时间，每次设置超时时间都以500ms的整数倍进行控制。

如果重发一次仍然没有收到确认应答，则以2 * 500ms设置超时时间。

如果还是没有反应，则以4 * 500ms设置超时时间，呈指数倍增长。

如果重传次数达到一定限度时，发送方就会认为接收方或者网络出现异常，强制关闭。

2.3 连接管理

连接管理分为建立连接和断开连接管理，TCP使用 " 三次握手 " 使双方建立连接，使用 " 四次挥手 " 使上方断开连接。

2.3.1 三次握手

纯靠文字来描述 " 三次握手 " 机制难以让大家理解，可以先看图：

客户端先向服务器发送syn同步请求，等待服务器发送ack确认应答。【第一次握手】
服务器向客户端发送ack确认应答（客户端→服务器连接成功 ），同时也发送syn同步请求，等待对方ack。【第二次握手】
客户端最后向服务器发送ack确认应答（服务器→客户端连接成功 ）。【第三次握手】

由于步骤②、③都是操作系统内核同时完成的，故这两个步骤可以合并，故整个TCP建立连接的过程就是这三个步骤，称为 " 三次握手 " 。

📝图中的状态表示的解释：

**CLOSED：**不存在的状态，tcp还没有建立连接；

**LISTEN：**服务器监听，准备随时建立连接；

**SYN_SENT：**发送syn同步请求；

**SYN_RCVD：**服务器接收到同步信息，并返回了ack和syn；

**ESTABLISHED：**表示连接已建立，接下来双方可以进行通信。

2.3.1.1 三次握手的意义

首先，看了三次握手的过程，有些小伙伴可能会有些疑惑：

❓ **问题：**为什么一次握手不行？也就是为什么服务器向客户端返回了ack确认消息之后，还要向客户端发送syn同步请求呢？不是已经建立了连接了吗？

**☑️答：**此时的连接成功只是客户端向服务器传输数据，且服务器可以成功接收这个方向的成功，但并不知道服务器是否能够成功向客户端发送响应，所以需要向客户端发送syn同步请求。举个简单的例子：

例如要测试两个正在用耳机语音时的耳机的连通性（耳机A与耳机B），A先向B说一句**"你好"** ，B收到后回答**"嗯呢"** ，但此时B并不知道A是否听到自己的回答，于是A听到B的回答后再说**"OK了"**，此过程也可以视作是"三次握手"。

那么三次握手的意义是什么？总结来讲为以下3点：

✅投石问路，初步验证连接是否通常
✅验证通信双方的收发能力是否匹配
✅协商关键信息（如下一次发送从第几个序号开始？）

2.3.2 四次挥手

TCP使用 " 四次挥手 " 的策略使通信双方断开连接，如图：

设备A向设备B发送FIN断开连接请求，等待设备B返回ACK确认应答。【第一次挥手】
设备B收到FIN后，立即返回ACK确认应答；【第二次挥手】
设备B向设备A发送FIN断开连接请求，等待设备A发送ACK确认应答。【第三次挥手】
设备A收到FIN后，立即返回ACK确认应答；【第四次挥手】

📝图中的状态表示的解释：

FIN_WAIT_1：主动方发完 FIN，等 ACK；

FIN_WAIT_2：主动方收到 ACK，等对方 FIN；

CLOSE_WAIT：被动方收到 FIN，等待应用程序关闭 socket；

LAST_ACK：被动方发完 FIN，等待最后的 ACK；

CLOSED：主动方发完最后 ACK，等待 2MSL。

下一节继续介绍TCP可靠传输的特点，滑动窗口、流量控制、拥塞控制、延迟应答、捎带应答、面向字节流、粘包问题、异常情况等，感兴趣的小伙伴不妨点个关注再走叭~