今天我们将 从稳定性角度深挖 TCP 协议的运作机制 。
如今,大半个互联网都建立在 TCP 协议之上,我们使用的 HTTP 协议、消息队列、存储、缓存,都需要用到 TCP 协议—— 这是因为 TCP 协议提供了可靠性 。
简单来说,可靠性就是让数据无损送达。但若是考虑到成本,就会变得非常复杂——因为还需要尽可能地提升吞吐量、降低延迟、减少丢包率。
TCP 协议具有很强的实用性,而可靠性又是 TCP 最核心的能力 。具体来说,从一个终端有序地发出多个数据包,经过一个复杂的网络环境,到达目的地的时候会变得无序,而可靠性要求数据恢复到原始的顺序。这里先提出两个问题:
那么带着这两个问题开始今天的学习。
TCP 是一个传输层协议
TCP 发送数据的时候,往往不会将数据一次性发送
而是将数据拆分成很多个部分,然后再逐个发送。像下图这样:
同样的,在目的地,TCP 协议又需要逐个接收数据。
请 思考,TCP 为什么不一次发送完所有的数据?比如我们要传一个大小为 10M 的文件,对于应用层而言,就是一次传送完成的。而传输层的协议为什么不选择将这个文件一次发送完呢?
这里有很多原因,
缓冲区是在内存中开辟的一块区域,目的是缓冲。因为大量的应用频繁地通过网卡收发数据,这个时候,网卡只能一个一个处理应用的请求。当网卡忙不过来的时候,数据就需要排队,也就是将数据放入缓冲区 。如果每个应用都随意发送很大的数据,可能导致其他应用实时性遭到破坏。
还有一些原因 比如内存的最小分配单位是页表,如果数据的大小超过一个页表,可能会存在页面置换问题,造成性能的损失。
总之,方方面面的原因: 在传输层封包不能太大 。
这种限制,往往是以缓冲区大小为单位的。也就是 TCP 协议,会将数据拆分成不超过缓冲区大小的一个个部分 。每个部分有一个独特的名词,叫作 TCP 段(TCP Segment) 。
在接收数据的时候,一个个 TCP 段又被重组成原来的数据。
像这样, 数据经过拆分,然后传输,然后在目的地重组,俗称拆包 。所以拆包是将数据拆分成多个 TCP 段传输。
那么粘包是什么呢?有时候, 如果发往一个目的地的多个数据太小了,为了防止多次发送占用资源,TCP 协议有可能将它们合并成一个 TCP 段发送,在目的地再还原成多个数据,这个过程俗称粘包。所以粘包是将多个数据合并成一个 TCP 段发送 。
那么一个 TCP 段长什么样子呢?下图是一个 TCP 段的格式:
我们可以看到,TCP 的很多配置选项和数据粘在了一起,作为一个 TCP 段。
显然, 把每一部分都记住似乎不太现实,先把其中最主要的部分理解。
TCP 协议就是依靠每一个 TCP 段工作的,所以你每认识一个 TCP 的能力,几乎都会找到在 TCP Segment 中与之对应的字段 。接下来 认识它们。
1)URG 代表这是一个紧急数据,比如远程操作的时候,用户按下了 Ctrl+C,要求终止程序,这种请求需要紧急处理。
2)ACK 代表响应, 所有的消息都必须有 ACK,这是 TCP 协议确保稳定性的一环。
3)PSH 代表数据推送,也就是在传输数据的意思。
4)SYN 同步请求,也就是申请握手。
5)FIN 终止请求,也就是挥手。
特别说明一下:以上这 5 个标志位,每个占了一个比特,可以混合使用。比如 ACK 和 SYN 同时为 1,代表同步请求和响应被合并了。这也是 TCP 协议,为什么是三次握手的原因之一 。
其实这个问题的本质就好像两个人在说话一样,我们要确保他们说出去的话,和回答之间的顺序。因为 TCP 是一个双工的协议,两边可能会同时说话。所以聪明的 科学家想到了确定一句话的顺序,需要两个值去描述——也就是发送的字节数和接收的字节数 。
我们重新定义一下 Seq(如上图所示),对于任何一个接收方,如果知道了发送者发送某个 TCP 段时,已经发送了多少字节的数据,那么就可以确定发送者发送数据的顺序。
但是这里有一个问题。如果接收方也向发送者发送了数据请求(或者说双方在对话),接收方就不知道发送者发送的数据到底对应哪一条自己发送的数据了。
举个例子:下面 A 和 B 的对话中,我们可以确定他们彼此之间接收数据的顺序。但是无法确定数据之间的关联关系,所以只有 Sequence Number 是不够的。
A:今天天气好吗?
A:今天你开心吗?
B:开心
B:天气不好
人类很容易理解这几句话的顺序,但是对于机器来说就需要特别的标注。因此我们还需要另一个数据,就是每个 TCP 段发送时,发送方已经接收了多少数据。用 Acknowledgement Number 表示,下面简写为 ACK。
下图中,终端发送了三条数据,并且接收到四条数据,通过观察,根据接收到的数据中的 Seq 和 ACK,将发送和接收的数据进行排序。
例如上图中, **发送方发送了 100 字节的数据,而接收到的(Seq = 0 和 Seq =100)的两个封包,都是针对发送方(Seq = 0)这个封包的。发送 100 个字节,所以接收到的 ACK 刚好是 100。说明(Seq= 0 和 Seq= 100)这两个封包是针对接收到第 100 个字节数据后,发送回来的。这样就确定了整体的顺序** 。
注意,无论 Seq 还是 ACK,都是针对“对方”而言的。是对方发送的数据和对方接收到的数据 。我们在实际的工作当中,可以通过 Whireshark 调试工具观察两个 TCP 连接的 Seq和 ACK。
接下来,我们讨论下 MSS,它也是面试经常会问到的一个 TCP Header 中的可选项(Options), 这个可选项控制了 TCP 段的大小,它是一个协商字段(Negotiate) 。协议是双方都要遵循的标准,因此配置往往不能由单方决定,需要双方协商。
TCP 段的大小(MSS)涉及发送、接收缓冲区的大小设置,双方实际发送接收封包的大小,对拆包和粘包的过程有指导作用,因此需要双方去协商 。
如果这个字段设置得非常大,就会带来一些影响。
TCP 协议不肯拆包,IP 协议就需要拆出大量的包。那么 IP 协议为什么需要拆包呢?这是因为在网络中,每次能够传输的数据不可能太大,这受限于具体的网络传输设备,也就是物理特性。但是 IP 协议,拆分太多的封包并没有意义。因为可能会导致属于同个 TCP 段的封包被不同的网络路线传输,这会加大延迟。同时,拆包,还需要消耗硬件和计算资源。
那是不是 MSS 越小越好呢? MSS 太小的情况下,会浪费传输资源(降低吞吐量)。因为数据被拆分之后,每一份数据都要增加一个头部。如果 MSS 太小,那头部的数据占比会上升,这让吞吐量成为一个灾难。所以在使用的过程当中,MSS 的配置,往往都是一个折中的方案 。
不要去猜想什么样的方案是最合理的,而是要尝试去用实验证明它,一切都要用实验依据说话。
Answer:
TCP 拆包的作用是将任务拆分处理,降低整体任务出错的概率,以及减小底层网络处理的压力。拆包过程需要保证数据经过网络的传输,又能恢复到原始的顺序。这中间,需要数学提供保证顺序的理论依据。 TCP 利用(发送字节数、接收字节数)的唯一性来确定封包之间的顺序关系 。
粘包是为了防止数据量过小,导致大量的传输,而将多个 TCP 段合并成一个发送。
全部0条评论
快来发表一下你的评论吧 !