为什么说 TCP 协议是可靠的?

题图:by thefolkpr0ject from Instagram

本文共计 3201 字,阅读文本大概需要 9 分钟。

TCP 协议是 TCP/IP 协议栈中的传输层的协议,TCP协议又叫传输控制协议(Transport Control Protocal)。众所周知,它是一个可靠协议。因为它能保证接收端完整地接受到发送端发送的数据包,即保证不丢包。

那 TCP 协议如何保证不丢包呢?这个是本文重点讲述的内容。

1 TCP 协议的作用

ISO(国际标准化组织)曾提出一个 OSI 七层模型。将网络的协议划分为 7 个层,从低到高排序是:物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。但是这个模型仅停留在理论阶段。因为该模型过于庞大、复杂,以至于无法被广泛应用。

后来技术人员在 TCP/IP 等协议集问世之后,提出 TCP/IP 协议栈。该模型很贴近实际场景,所以被广泛的应用。TCP/IP 协议栈一共分为 4 个层次。从低到高依次排序是:数据链路层(有书籍称之为网络接口层)、网络层、传输层、应用层。

  • 网络接口层:针对不同物理网络的连接形式的协议:以太网、FDDI 光纤分布式数据接口。其中协议有 ARP 协议(地址解析协议)、RARP 协议(反向地址转换协议)
  • 网际层:负责数据的传输,路由以及地址选择。最主要的协议是 IP 协议。
  • 传输层:确认数据传输以及进行纠错处理。传输层中中有两个非常重要的协议,即 TCP 协议和 UDP 协议。
  • 应用层:各种服务以及应用程序。常见的应用层协议有 HTTP 协议、FTP 协议(文件传输协议)、SMTP 协议(简单邮件传输协议)等

2 TCP 协议通信特点

TCP 协议是实现端口到端口的通信。它虚拟了本文流(byte stream)的通信。我们知道,计算机数据的本质是有序的 0/1 序列(如果以byte为单位,就叫做文本流)。计算机的功能就是储存和处理文本流。所以TCP是采用“流”通信

但是传输层的下一层是网络层。即 TCP 协议的下一层协议是 IP 层。这就意味着 TCP 协议最终还是由 IP 协议规定的形式传输数据。而IP 协议是以数据包方式传送。同时,IP 数据包的 MTU 也有长度限制。所以TCP 协议会将数据切割为一个个片段,然后丢给网络层,接着打包成一个个数据包进行传输

但是这样,流数据变成了一个个片段数据,这会无法保证数据到达的次序。因为 IP 协议在传输过程中,不会按顺序进行发送和接受数据包。针对这问题,TCP 协议为了确保数据到达的顺序与文本流顺序相同。TCP 协议将每个 TCP 片段中分为头部(header)和数据(payload)两部分。每个头部中带有一个序号。这相当于给每个片段增加一个序号标记,方便后续排序。

3 TCP 实现可靠通信的两种方式

我们都知道 IP 协议是“不太靠谱”。因为 IP 协议是不可靠的,所以 IP 数据包可能在传输过程中发生错误或者丢失。这就意味着,TCP 协议不得不面对以下三个问题。1)每个数据包有可能发送不成功 2)数据包在传输过程中有可能被丢弃 3)接收端有可能接受不到数据包

TCP 为了解决这丢包问题,提出两个补救措施。

  • 1 ACK 回复

在每收到一个正确的、符合次序的片段之后,就向发送方(也就是连接的另一段)发送一个特殊的 TCP 片段,用来知会(ACK,acknowledge)发送方:我已经收到那个片段了。这个特殊的 TCP片段 叫做 ACK 回复。如果一个片段序号为 L,对应ACK 回复有回复号 L+1,也就是接收方期待接收的下一个发送片段的序号。

  • 2 重新发送机制

如果发送方在一定时间等待之后,还是没有收到 ACK 回复,那么它推断之前发送的片段一定发生了异常。发送方会重复发送(retransmit)那个出现异常的片段,等待 ACK 回复,如果还没有收到,那么再重复发送原片段… 直到收到该片段对应的 ACK 回复(回复号为 L+1 的 ACK)。

4 TCP 的滑动窗口

虽然采用 “ACK 回复” + “重新发送机制” 方式能实现不丢包,但是会存在两个问题。

1.效率低的问题。 发送方保持发送 -> 等待ACK -> 发送 -> 等待ACK…的单线工作方式,这样的工作方式叫做 stop-and-wait。stop-and-wait 虽然实现了 TCP 通信的可靠性,但同时牺牲了网络通信的效率。同时,在等待ACK的时间段内,我们的网络都处于闲置(idle)状态

2.有点小缺陷 如果片段一直没有被确认,会导致后续的片段无法发送出去。

TCP 为了进一步优化解决这两个问题,提出滑动窗口(sliding window)的概念。滑动窗口被同时应用于接收方和发送方, 发送方和接收方各有一个滑窗。当片段位于滑窗中时,表示 TCP 正在处理该片段。此外,如果滑窗中可以有多个片段,也就是可以同时处理多个片段。

我们借助一些图片来进一步了解下滑动窗口内部机制。

黄色框框表示可以容纳三个片段的固定大小的滑窗。在图中,并假设片段从左向右排列。实际运用中,滑动窗口是可变的,窗口大小是字节(byte)来计算的。

对于发送方来说,滑窗的左侧为已发送并已 ACK 过的片段序列,滑窗右侧是尚未发送的片段序列。如果滑动窗口第一个片段一直没有收到 ACK 回复,窗口不会向右滑动。但是发送方还是可以继续发送后面两个片段数据包。

对于接受方来说,滑窗的左侧是已经正确收到并 ACK 回复过的片段,也就是正确接收到的文本流。滑窗中的片段是期望接收的片段。如果滑窗中第一个片段先收到, 滑窗会向右移动。如果滑窗中后面两个片段先收到,但是第一个片段没有收到。窗口不会向右滑动。

发送端已经发送三个数据包(1、2、3),在等待每个数据包的 ACK 回复

接收端成功收到两个数据包,回复两个 ACK。还有一个数据包没有收到。当收到 数据包 1 时,接收端会回复一个 ACK 1,然后将窗口向有滑动一个位置。

发送端成功接收到 ACK 1 回复

发送端的窗口向右滑动一个位置

在没有收到 ACK 2 和 3 的回复,还能继续发送数据包 4

之前数据包 4 已经发送了。在之后成功收到 ACK 2 和 3 的回复,窗口向右滑动两个位置,现在又能继续发送数据包 5,6

通过上面一系列图片,我们可以大致知道滑动窗口的机制。我们来做下小总结:

  • 对于发送端

如果滑动窗口第一个片段一直没有收到 ACK 回复,窗口不会向右滑动。但是发送方还是可以继续发送后面两个片段数据包。

  • 对于接受端

如果滑窗中第一个片段先收到,滑窗会向右移动。如果滑窗中后面两个片段先收到,但是第一个片段没有收到。窗口不会向右滑动

那么实际应用中确实是这样吗?如果接收方每接受一个片段,就回复一个 ACK。这种效率有点低。所以实际应用中, TCP 协议为了减少了 ACK 回复所消耗的流量,采用的是累计 ACK 回复。 接收方往往利用一个 ACK 回复来知会连续多个片段的成功接收。通过累计 ACK,所需要的 ACK 回复通常可以降到 50%。

我们同样通过图片的形式来了解累计 ACK 回复的原理。

在图中,橙色为已经接收的片段。方框为滑窗,滑窗可容纳3个片段。

情况1:滑窗还没接收到片段 7 时,已接收到片段 8,9。这样就在滑窗中制造了一个“空穴”(hole)。

情况2:当滑窗最终接收到片段7时,滑窗送出一个回复号为 10 的 ACK 回复。发送方收到该回复,会意识到,片段 10 之前的片段已经按照次序被成功接收。整个过程中节约了片段 7 和片段 8 所需的两个 ACK 回复。

文章参考内容:

1) Vamei 大神的《协议森林08 不放弃 (TCP协议与流通信)》 http://www.cnblogs.com/vamei/archive/2012/12/08/2805252.html 2) Vamei 大神的《协议森林10 魔鬼细节 (TCP滑窗管理)》 http://www.cnblogs.com/vamei/archive/2012/12/18/2822739.html

原文发布于微信公众号 - 极客猴(Geek_monkey)

原文发表时间:2018-07-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏高性能服务器开发

从零学习开源项目系列(二) 最后一战概况

这份代码我也是无意中来自一个朋友,据他说也是来源于互联网,服务器端代码原来是linux版本的,但被厉害的大神修改成可以在Windows上运行。(如果不小心侵犯了...

18520
来自专栏老安的博客

vmware api开发之快照管理

21140
来自专栏黑白安全

WEB访问日志自动化分析浅谈

最近经常需要分析WEB访问日志,从中发现非法请求,然后做相应安全检查,为了方便,所以写了一个日志分析平台,支持提交iis,apapche,tomcat,ngni...

17720
来自专栏张戈的专栏

Nginx发布1.9.0版本,新增支持TCP代理和负载均衡的stream模块

昨天在公司微信群,CTO 分享了这个消息,对运维来说以后基于 TCP 协议的后端业务的高可用又多了一个新的选择,实在是棒极了! 一直以来,Nginx 并不支持 ...

31350
来自专栏FreeBuf

DNS Tunneling及相关实现

*本文原创作者:novsec,本文属FreeBuf原创奖励计划,未经许可禁止转载 ? DNS Tunneling,是隐蔽信道的一种,通过将其他协议封装在DNS协...

77970
来自专栏Vamei实验室

协议森林10 魔鬼细节 (TCP滑窗管理)

在TCP协议与"流"通信中,我们建立了滑窗(sliding window)的基本概念。通过滑窗与ACK的配合,我们一方面实现了TCP传输的可靠性,另一方面也一定...

211100
来自专栏HappenLee的技术杂谈

LVS-NAT模式的配置详解

由于实验室拟态存储的项目需要通过NAT模式来映射NFS服务器已实现负载均衡的目的,通过调研了多种负载均衡机制,笔者最终选择了LVS的NAT模式来实现需求,接下来...

13830
来自专栏图像识别与深度学习

Arduino+w5100使用1:WebServer操作步骤所用硬件

47980
来自专栏黑白安全

Nmap的使用

精细扫描,可以查看更详细的信息,如包含服务版本,操作系统类型,甚至还有traceroute..

20130
来自专栏HappenLee的技术杂谈

数据分区------《Designing Data-Intensive Applications》读书笔记9

分区与副本是很容易混淆的概念,我们这里离清一下两者。 数据分区的每个副本可以存储在多个节点上。这意味着,即使每个记录恰好属于一个分区,它仍然可以存储在几个不同...

9730

扫码关注云+社区

领取腾讯云代金券