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 字节头部选项: 暂时忽略;
我们学习每个协议时都需要面对两个问题
- 如何解包?
- 如何分用?
对于解包:
我们看到报文中有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之前的报文全部都收到了。
这个定义与滑动窗口有关,我们暂时不关心。
此时我们暂时先稍微看两个特殊情况,具体的会在后边谈。
- 当1001ACK收到,2001,3001…没收到,我们不会立即重传,会超时重传或者快重传之类的。
- 当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时岂不是错乱了,所以需要序号进行按序到达。
至此我们的序号已经有三个作用了:
- 用来ACK(报头)
- 报文去重
- 按序到达
连接管理机制
初识三握四挥
在正常情况下, 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,就会造成洪水攻击,占用服务端大量的资源,同样两次握手也是,对客户端的要求太低了,不消耗客户端的资源。
虽然三次也无法避免,但是可以一定程度减少,至少没有那么明显的漏洞。
这只是很小一部分。
正式理由
- 验证全双工(客户端可发可收,服务端也可发可收,验证网络连通性)
- 确认双方的通信意愿
可以看到上图变为四次握手,但是由于服务端是无脑接收,来者不拒。
所以我们直接捎带应答!
重谈四次挥手
实际上当我们双方同时FIN,那么其实也就捎带应答,变为3次挥手。
所以建立与断开本质上没有区别。
为什么教科书上都是3次握手四次挥手?
因为客户端建立连接时,服务器无条件同意,所以直接FIN+ACK。
而断开有可能还有一方没有发完,所以只是一个更常见的是3次握手,一个是四次挥手