【计算机网络】TCP协议（上）

TCP协议的复杂我们在上层接口已经展现出来了，报文也是相对复杂的

TCP协议

TCP 全称为 “传输控制协议(Transmission Control Protocol”). 人如其名, 要对数据的传输进行一个详细的控制;

TCP 协议段格式

对于上图中的数据不必多说，就是应用层拷贝进去的数据。

我们先进行一下简单的介绍，再解释一下我们现在能理解的位段。

• 源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去;
• 32 位序号/32 位确认号: 后面详细讲;
• 4 位 TCP 报头长度: 表示该 TCP 头部有多少个 32 位 bit(有多少个 4 字节); 所以TCP 头部最大长度是 15 * 4 = 60
• 6 位标志位: ￮ URG: 紧急指针是否有效 ￮ ACK: 确认号是否有效 ￮ PSH: 提示接收端应用程序立刻从 TCP 缓冲区把数据读走 ￮ RST: 对方要求重新建立连接; 我们把携带 RST 标识的称为复位报文段 ￮ SYN: 请求建立连接; 我们把携带 SYN 标识的称为同步报文段 ￮ FIN: 通知对方, 本端要关闭了, 我们称携带 FIN 标识的为结束报文段
• 16 位窗口大小: 后面再说
• 16 位校验和: 发送端填充, CRC 校验. 接收端校验不通过, 则认为数据有问题. 此 处的检验和不光包含 TCP 首部, 也包含 TCP 数据部分.
• 16 位紧急指针: 标识哪部分数据是紧急数据;
• 40 字节头部选项: 暂时忽略;

我们学习每个协议时都需要面对两个问题

1. 如何解包？
2. 如何分用？

对于解包：
我们看到报文中有4位首部长度，同时报头部分为20字节。
4位首部长度的单位是4字节->[0, 15]->[0, 60],也就是说报头部分最多有60字节，剩下的40字节是选项的大小。
如果我们的报文不带选项，首部长度应该是多少呢？

答案就是

0101

。

对于分用：我们有16位目的端口号，故可以直接找到对应的进程。

确认应答(ACK)机制

ACK就是acknowledgement（应答）。

我们先来看具体的一个例子
当A和B距离的很近时，他们之间的交谈很容易

但当距离的很远时，那么通信就不是那么容易了

因为距离的很远，所以当你问问题时不知道对方是否收到，就像A问B吃饭了吗，除非B给你回复，否则你是不清楚B是否收到的。
但只要B给你回复，那么就说明上一句一定被B收到了。

这也就说明最新的一个回复是永远无法确定是否被收到。

此时我们就可以对现实的这个例子下一个结论：

只要收到了应答，就能保证我发的数据一定被对方收到了

我们映射到网络中

我们所谓的ACK就是当其中一端发了一个消息，另一端发一个ACK进行回复，若是没有收到ACK就是代表没有收到消息！
且不用对ACK进行ACK，如果这样那就不成了先鸡还是先蛋的问题？

通信模式

我们常见的通信模式有两种

左侧的效率高，右侧的效率低
所以更常见的是左侧。

但是如果发的这么密集，如果ACK丢了一个会怎么样？
就无法知道那个是缺失的了。

所以我们需要一个唯一标识符。
更细致一点的图
也就是序号。

确认序号原则上就是收到的序号+1，其中若是收到了3001，那么就说明3001之前的报文全部都收到了。

这个定义与滑动窗口有关，我们暂时不关心。

此时我们暂时先稍微看两个特殊情况，具体的会在后边谈。

1. 当1001ACK收到，2001，3001…没收到，我们不会立即重传，会超时重传或者快重传之类的。
2. 当4001收到，1001，2001，3001未收到会影响吗？定义规定了4001收到就代表4001之前的都收到了所以不影响，所以我们也支持少量的弄丢。

问题

问题一： 那么为什么设置为两个序号？

发的时候用一个，ACK的时候也用一个，事实上设置一个序号的话完全可以，但是我们有一个机制叫做捎带应答：

意思就是服务器进行ACK时也正好将自己要发送的数据一起发送了，这就是捎带应答。
可以大大的提高效率，所以需要两个序号。

问题二： 客户端如何知道收到的报文是应答还是携带数据？
同样，请求也有各种各样：请求链接，请求断开…
所以我们需要一个类型进行表示

我们的ACK就在其中，属于其中一种。
捎带的话也不冲突，携带上数据即可。

问题三： 如何理解序号？

逻辑上我们将发送缓冲区当做一个字符数组

所以我们所谓的序号其实就是数组下标，发送1000，其实就意味着将1-1000数组内数据全部发送，发送2000就代表将1001到2000发送，1000的ACK就是1001，2000的ACK就是2001…以此类推。

超时重传机制

• 主机 A 发送数据给 B 之后, 可能因为网络拥堵等原因, 数据无法到达主机B;
• 如果主机 A 在一个特定时间间隔内没有收到 B 发来的确认应答, 就会进行重发;

但是, 主机 A 未收到 B 发来的确认应答, 也可能是因为 ACK 丢失了;

因此主机 B 会收到很多重复数据. 那么 TCP 协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉.

这时候我们可以利用前面提到的序列号, 就可以很容易做到去重的效果.
那么, 如果超时的时间如何确定?

• 最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”.
• 但是这个时间的长短, 随着网络环境的不同, 是有差异的.
• 如果超时时间设的太长, 会影响整体的重传效率;
• 如果超时时间设的太短, 有可能会频繁发送重复的包;

TCP 为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间.

• Linux 中(BSD Unix 和 Windows 也是如此), 超时以 500ms 为一个单位进行控制, 每次判定超时重发的超时时间都是 500ms 的整数倍.
• 如果重发一次之后, 仍然得不到应答, 等待

2*500

ms 后再进行重传.
• 如果仍然得不到应答, 等待

4*500

ms 进行重传. 依次类推, 以指数形式递增.
• 累计到一定的重传次数, TCP 认为网络或者对端主机出现异常, 强制关闭连接.

注意：网络是十分复杂的，先发的不一定先到，但是到达接收缓冲区是肯定按照顺序的，否则接收方read时岂不是错乱了，所以需要序号进行按序到达。
至此我们的序号已经有三个作用了：

1. 用来ACK（报头）
2. 报文去重
3. 按序到达

连接管理机制

初识三握四挥

在正常情况下, TCP 要经过三次握手建立连接, 四次挥手断开连接

我们先看三次握手
其中我们又会学到新的标记位：SYN（Synchronization），这个就是建立连接时报头需要携带的标记位。
我们connect发起了三次挥手，剩下的都是由OS自主完成的。

注意：accept不参与三次挥手

我们感性的理解一下：
第一次握手：做我女朋友吧
第二次握手：好啊，什么时候开始？
第三次握手：现在！

虽然最新一条客户端无法保证服务器能收到，但是一旦发出我们就认为三次握手成功了！

所以本质就是在赌！堵可以建立成功，即最后一个ACK被对方收到了。

看似很牵强，但实际上至少已经能相互验证可以互相发消息没问题的了。

就是因为在堵，所以有特殊情况的出现，也就是最后一个ACK服务器未收到，虽然说会超时重发，但此时客户端认为已经连接完成了。
客户已经发送消息了，问题就出现了，明明连接还没完全建立却发送了消息，此时服务端应答时需要一个新的标志位RST（reset）重置。
收到该标志位的主机要对异常连接进行释放。
所以至此以后，可能由于各种各样复杂的网络情况导致异常链接都重置即可！

接下来看四次挥手
当客户端没有数据需要发送时，就会close。
OS就会进行发送FIN，服务器进行ACK。

但是此时server有可能还要发消息，所以客户端仍然要进行ACK。

最后由服务端发送FIN，再由客户端ACK，至此连接彻底断开。

这么乍一看，没什么问题，但我们仔细看就会发现问题：当客户端close时，触发了两次挥手，但是close后就关闭了文件缓冲区，就不能进行读写了，我们如何读取服务端给我们发送的数据？
实际上我们有一个系统调用叫做shutdown
其中的how我们可以使用相应的选项关闭读端写端或者读写端。

由此我们可见使用了最小的通信成本建立了断开连接的共识！

我们在顺一遍。
由A发送FIN发起两次连接，A进入FIN_WAIT_1，B收到FIN进入CLOSE_WAIT状态并进行ACK，A接受ACK变为FIN_WAIT_2。
再由Bclose发起两次挥手并进入LAST_ACK状态，A接受到后此时会持续一段时间的TIME_WAIT并ACK，B接收后进入CLOSED，最后A也进入CLOSED状态

所以当我们的进程关闭时，我们马上进行bind时会bind err，虽然进程关闭了，但是OS内部还在进行四次挥手，还在占用端口号，所以bind失败。

再识三握四挥

为什么要三次握手？
为什么一次两次不行？
连接有各种各样的，我们也要进行管理，也就是说内部存在数据结构，需要malloc空间，所以维护连接是有成本的！

如果搞一次就行的话，那么客户端发送大量SYN，就会造成洪水攻击，占用服务端大量的资源，同样两次握手也是，对客户端的要求太低了，不消耗客户端的资源。

虽然三次也无法避免，但是可以一定程度减少，至少没有那么明显的漏洞。

这只是很小一部分。
正式理由

1. 验证全双工（客户端可发可收，服务端也可发可收，验证网络连通性）
2. 确认双方的通信意愿

可以看到上图变为四次握手，但是由于服务端是无脑接收，来者不拒。

所以我们直接捎带应答！

重谈四次挥手

实际上当我们双方同时FIN，那么其实也就捎带应答，变为3次挥手。

所以建立与断开本质上没有区别。

为什么教科书上都是3次握手四次挥手？
因为客户端建立连接时，服务器无条件同意，所以直接FIN+ACK。
而断开有可能还有一方没有发完，所以只是一个更常见的是3次握手，一个是四次挥手