你是一台电脑,你的名字叫 A

经过《图解 | 原来这就是网络》这篇文章中的一番折腾,只要你知道另一位伙伴 B 的 IP 地址,且你们之间的网络是通的,无论多远,你都可以将一个数据包发送给你的伙伴 B

这就是物理层、数据链路层、网络层这三层所做的事情。站在第四层的你,就可以不要脸地利用下三层所做的铺垫,随心所欲地发送数据,而不必担心找不到对方了。

虽然你此时还什么都没干,但你还是给自己这一层起了个响亮的名字,叫做传输层。你本以为自己所在的第四层万事大吉,啥事没有,但很快问题就接踵而至。

问题来了

前三层协议只能把数据包从一个主机搬到另外一台主机,但是,到了目的地以后,数据包具体交给哪个程序(进程)呢?

所以,你需要把通信的进程区分开来,于是就给每个进程分配一个数字编号,你给它起了一个响亮的名字:端口号。

然后你在要发送的数据包上,增加了传输层的头部,源端口号与目标端口号。

OK,这样你将原本主机到主机的通信,升级为了进程和进程之间的通信。你没有意识到,你不知不觉实现了 UDP 协议!(当然 UDP 协议中不光有源端口和目标端口,还有数据包长度和校验值,我们暂且略过)就这样,你用 UDP 协议无忧无虑地同 B 进行着通信,一直没发生什么问题。

但很快,你发现事情变得非常复杂......

丢包问题

由于网络的不可靠,数据包可能在半路丢失,而 A 和 B 却无法察觉。

对于丢包问题,只要解决两个事就好了。第一个,A 怎么知道包丢了?答案:让 B 告诉 A第二个,丢了的包怎么办?答案:重传于是你设计了如下方案,A 每发一个包,都必须收到来自 B 的确认(ACK),再发下一个,否则在一定时间内没有收到确认,就重传这个包。

你管它叫停止等待协议。只要按照这个协议来,虽然 A 无法保证 B 一定能收到包,但 A 能够确认 B 是否收到了包,收不到就重试,尽最大努力让这个通信过程变得可靠,于是你们现在的通信过程又有了一个新的特征,可靠交付。

效率问题

停止等待虽然能解决问题,但是效率太低了,A 原本可以在发完第一个数据包之后立刻开始发第二个数据包,但由于停止等待协议,A 必须等数据包到达了 B ,且 B 的 ACK 包又回到了 A,才可以继续发第二个数据包,这效率慢得可不是一点两点。于是你对这个过程进行了改进,采用流水线的方式,不再傻傻地等。

顺序问题

但是网路是复杂的、不可靠的。有的时候 A 发出去的数据包,分别走了不同的路由到达 B,可能无法保证和发送数据包时一样的顺序。

在流水线中有多个数据包和ACK包在乱序流动,他们之间对应关系就乱掉了。难道还回到停止等待协议?A 每收到一个包的确认(ACK)再发下一个包,那就根本不存在顺序问题。应该有更好的办法!A 在发送的数据包中增加一个序号(seq),同时 B 要在 ACK 包上增加一个确认号(ack),这样不但解决了停止等待协议的效率问题,也通过这样标序号的方式解决了顺序问题。

而 B 这个确认号意味深长:比如 B 发了一个确认号为 ack = 3,它不仅仅表示 A 发送的序号为 2 的包收到了,还表示 2 之前的数据包都收到了。这种方式叫累计确认或累计应答。

注意,实际上 ack 的号是收到的最后一个数据包的序号 seq + 1,也就是告诉对方下一个应该发的序号是多少。但图中为了便于理解,ack 就表示收到的那个序号,不必纠结。

流量问题

有的时候,A 发送数据包的速度太快,而 B 的接收能力不够,但 B 却没有告知 A 这个情况。

怎么解决呢?很简单,B 告诉 A 自己的接收能力,A 根据 B 的接收能力,相应控制自己的发送速率,就好了。B 怎么告诉 A 呢?B 跟 A 说"我很强"这三个字么?那肯定不行,得有一个严谨的规范。于是 B 决定,每次发送数据包给 A 时,顺带传过来一个值,叫窗口大小(win),这个值就表示 B 的接收能力。同理,每次 A 给 B 发包时也带上自己的窗口大小,表示 A 的接收能力。

B 告诉了 A 自己的窗口大小值,A 怎么利用它去做 A 这边发包的流量控制呢?很简单,假如 B 给 A 传过来的窗口大小 win = 5,那 A 根据这个值,把自己要发送的数据分成这么几类。

图片过于清晰,就不再文字解释了。当 A 不断发送数据包时,已发送的最后一个序号就往右移动,直到碰到了窗口的上边界,此时 A 就无法继续发包,达到了流量控制。

但是当 A 不断发包的同时,A 也会收到来自 B 的确认包,此时整个窗口会往右移动,因此上边界也往右移动,A 就能发更多的数据包了。

以上都是在窗口大小不变的情况下,而 B 在发给 A 的 ACK 包中,每一个都可以重新设置一个新的窗口大小,如果 A 收到了一个新的窗口大小值,A 会随之调整。如果 A 收到了比原窗口值更大的窗口大小,比如 win = 6,则 A 会直接将窗口上边界向右移动 1 个单位。

如果 A 收到了比原窗口值小的窗口大小,比如 win = 4,则 A 暂时不会改变窗口大小,更不会将窗口上边界向左移动,而是等着 ACK 的到来,不断将左边界向右移动,直到窗口大小值收缩到新大小为止。

OK,终于将流量控制问题解决得差不多了,你看着上面一个个小动图,给这个窗口起了一个更生动的名字,滑动窗口。

拥塞问题

但有的时候,不是 B 的接受能力不够,而是网络不太好,造成了网络拥塞。

拥塞控制与流量控制有些像,但流量控制是受 B 的接收能力影响,而拥塞控制是受网络环境的影响。拥塞控制的解决办法依然是通过设置一定的窗口大小,只不过,流量控制的窗口大小是 B 直接告诉 A 的,而拥塞控制的窗口大小按理说就应该是网络环境主动告诉 A。但网络环境怎么可能主动告诉 A 呢?只能 A 单方面通过试探,不断感知网络环境的好坏,进而确定自己的拥塞窗口的大小。

拥塞窗口大小的计算有很多复杂的算法,就不在本文中展开了,假如拥塞窗口的大小为  cwnd,上一部分流量控制的滑动窗口的大小为 rwnd,那么窗口的右边界受这两个值共同的影响,需要取它俩的最小值。窗口大小 = min(cwnd, rwnd)含义很容易理解,当 B 的接受能力比较差时,即使网络非常通畅,A 也需要根据 B 的接收能力限制自己的发送窗口。当网络环境比较差时,即使 B 有很强的接收能力,A 也要根据网络的拥塞情况来限制自己的发送窗口。正所谓受其短板的影响嘛~

连接问题

有的时候,B 主机的相应进程还没有准备好或是挂掉了,A 就开始发送数据包,导致了浪费。

这个问题在于,A 在跟 B 通信之前,没有事先确认 B 是否已经准备好,就开始发了一连串的信息。就好比你和另一个人打电话,你还没有"喂"一下确认对方有没有在听,你就巴拉巴拉说了一堆。这个问题该怎么解决呢?地球人都知道,三次握手嘛!

A:我准备好了(SYN)

B:我知道了(ACK),我也准备好了(SYN)

A:我知道了(ACK)

A 与 B 各自在内存中维护着自己的状态变量,三次握手之后,双方的状态都变成了连接已建立(ESTABLISHED)。虽然就只是发了三次数据包,并且在各自的内存中维护了状态变量,但这么说总觉得太 low,你看这个过程相当于双方建立连接的过程,于是你灵机一动,就叫它面向连接吧。注意:这个连接是虚拟的,是由 A 和 B 这两个终端共同维护的,在网络中的设备根本就不知道连接这回事儿!但凡事有始就有终,有了建立连接的过程,就要考虑释放连接的过程,又是地球人都知道,四次挥手嘛!

A:再见,我要关闭了(FIN)

B:我知道了(ACK)

给 B 一段时间把自己的事情处理完...

B:再见,我要关闭了(FIN)

A:我知道了(ACK)

总结

以上讲述的,就是 TCP 协议的核心思想,上面过程中需要传输的信息,就体现在 TCP 协议的头部,这里放上最常见的 TCP 协议头解读的图。

不知道你现在再看下面这句话,是否能理解:

TCP 是面向连接的、可靠的、基于字节流的传输层通信协议

面向连接、可靠,这两个词通过上面的讲述很容易理解,那什么叫做基于字节流呢?很简单,TCP 在建立连接时,需要告诉对方 MSS(最大报文段大小)。也就是说,如果要发送的数据很大,在 TCP 层是需要按照 MSS 来切割成一个个的 TCP 报文段 的。切割的时候我才不管你原来的数据表示什么意思,需要在哪里断句啥的,我就把它当成一串毫无意义的字节,在我想要切割的地方咔嚓就来一刀,标上序号,只要接收方再根据这个序号拼成最终想要的完整数据就行了。在我 TCP 传输这里,我就把它当做一个个的字节,也就是基于字节流的含义了。

最后留给大家一个作业,模拟 A 与 B 建立一个 TCP 连接。

第一题:A 给 B 发送 "aaa" ,然后 B 给 A 回复一个简单的字符串 "success",并将此过程抓包。

第二题:A 给 B 发送 "aaaaaa ... a" 超过最大报文段大小,然后 B 给 A 回复一个简单的字符串 "success",并将此过程抓包。

下面是我抓的包(第二题)

三次握手阶段

A -> B [SYN] Seq=0 Win=64240 Len=0

MSS=1460 WS=256

B - >A [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0

MSS=1424 WS=512

A -> B [ACK] Seq=1 Ack=1 Win=132352 Len=0

数据发送阶段

A -> B [ACK] Seq=1 Ack=1 Win=132352 Len=1424

A -> B [ACK] Seq=1425 Ack=1 Win=132352 Len=1424

A -> B [PSH, ACK] Seq=2849 Ack=1 Win=132352 Len=1247

B -> A [ACK] Seq=1 Ack=1425 Win=32256 Len=0

B -> A [ACK] Seq=1 Ack=2849 Win=35328 Len=0

B -> A [ACK] Seq=1 Ack=4096 Win=37888 Len=0

B -> A [PSH, ACK] Seq=1 Ack=4096 Win=37888 Len=7

四次挥手阶段

B -> A [FIN, ACK] Seq=8 Ack=4096 Win=37888 Len=0

A -> B [ACK] Seq=4096 Ack=9 Win=132352 Len=0

A -> B [FIN, ACK] Seq=4096 Ack=9 Win=132352 Len=0

A -> B [ACK]

详细的抓包数据与分析整理,就不在文章里展示了,可以在公众号 低并发编程 后台回复 TCP 获取。

后记

一提到 TCP,可能很多人都想起被三次握手和四次挥手所支配的恐惧。但其实你跟着文中的思路你就会发现,三次握手与四次挥手只占 TCP 所解决的核心问题中很小的一部分,只是因为它在面试中很适合作为知识点进行考察,所以在很多人的印象中就好像 TCP 的核心就是握手和挥手似的。
本文希望你能从问题出发,真正理解 TCP 所想要解决的问题,你会发现很多原理就好像生活常识一样顺其自然,并不复杂,希望你有收获~

图解 | 原来这就是TCP的更多相关文章

  1. 图解HTTP,TCP,IP,MAC的关系

    入门 用户发了一个HTTP的请求,想要访问我们网站的首页,这个HTTP请求被放在一个TCP报文中,再被放到一个IP数据报中,最终的目的地就是我们的115.39.19.22. 进阶 IP数据报其实是通过 ...

  2. 图解 | 原来这就是 IO 多路复用

    为了讲多路复用,当然还是要跟风,采用鞭尸的思路,先讲讲传统的网络 IO 的弊端,用拉踩的方式捧起多路复用 IO 的优势. 为了方便理解,以下所有代码都是伪代码,知道其表达的意思即可. Let's go ...

  3. 图解 | 原来这就是 class

    我是一个 .java 文件,名叫 FlashObject.java,叫我小渣就行. public class FlashObject {    private String name;    priv ...

  4. 《java入门第一季》之Socket编程通信和TCP协议通信图解

    Socket编程通信图解原理: TCP协议通信图解

  5. TCP/UDP详解

    转载:http://www.cnblogs.com/visily/archive/2013/03/15/2961190.html, 作者:望梅止渴 相关: HTTP协议详解  深入理解HTTP协议 T ...

  6. 在深谈TCP/IP三步握手&四步挥手原理及衍生问题—长文解剖IP

    如果对网络工程基础不牢,建议通读<细说OSI七层协议模型及OSI参考模型中的数据封装过程?> 下面就是TCP/IP(Transmission Control Protoco/Interne ...

  7. TCP、UDP详解与抓包工具使用

    参考:https://www.cnblogs.com/HPAHPA/p/7737641.html TCP.UDP详解 1.传输层存在的必要性 由于网络层的分组传输是不可靠的,无法了解数据到达终点的时间 ...

  8. Java网络编程基础之TCP粘包拆包

    TCP是个"流"协议,所谓流,就是没有界限的一串数据.大家可以想象河里的流水,他们是连成一片的,其间并没有分界线.TCP底层并不了解上层业务数据的具体含义,他会根据TCP缓冲区的实 ...

  9. Http权威指南(TCP连接)

    1.HTTP请求的过程 世界上几乎所有的HTTP通信都是由TCP/IP承载的,当发生HTTP请求时,实际上经过了以下几个步骤: ①浏览器从请求的URL中解析主机名 ②浏览器查询这个主机名的IP地址 ③ ...

随机推荐

  1. react第十四单元(react路由-react路由的跳转以及路由信息)

    第十四单元(react路由-react路由的跳转以及路由信息) #课程目标 理解前端单页面应用与多页面应用的优缺点 理解react路由是前端单页面应用的核心 会使用react路由配置前端单页面应用框架 ...

  2. js下 Day05、DOM案例

    一.简易购物车 效果图: 功能思路分析: 功能一:数量加减 \1. 找到所有的加号按钮,循环绑定点击事件.点击加号时让对应的数量+1 (找清楚加号和数量的关系,让数量标签的内容++) \2. 找到所有 ...

  3. Python高级语法-私有属性-with上下文管理器(4.7.3)

    @ 目录 1.说明 2.代码 关于作者 1.说明 上下文管理器 这里使用with open操作文件,让文件对象实现了自动释放资源.我们也能自定义上下文管理器,通过__enter__()和__exit_ ...

  4. C4 模型 - 可视化架构设计

    前言 世界上最难的两件事是: 1. 把我的思想放进你的脑袋 2. 把你的钱放进我的口袋 第二点我们不探讨,因为这是众所周知的,不信?过来试试:) 对于第一点,对我们程序员来说,其实也是我个人一直强调的 ...

  5. day020|python之面向对象基础2

    面向对象基础2 目录 面向对象基础2 7 对象与类型 7.1 类即类型 7.1.1 变量的三个指标 7.1.2 变量类型 7.2 list.append()方法原理 8 对象的高度整合 8.1 通过面 ...

  6. Python(循环语句与数据类型)

    循环语句 对于python来说 基本上循环用的两个 wile 跟静态语言相似 下来是for循环 这个就跟静态语言大大不同了 wile 条件:–>while 循环也就是 当条件为真的时候会一直循环 ...

  7. python解压可迭代对象赋值给多个变量

    如果一个可迭代对象的元素个数超过了变量的个数,会出现"解压值太多"的异常,python提供*号表达式(码夫破石的理解)来解决. 1,求一组平均值,就以类似学生成绩为例,要求是去掉第 ...

  8. 论文阅读: A Review of Robot Learning for Manipulation: Challenges, Representations, and Algorithms

    机器人学习操纵综述:挑战,表示形式和算法 1.介绍 因此,研究人员专注于机器人应如何学习操纵周围世界的问题. 这项研究的范围很广,从学习个人操作技巧到人类演示,再到学习适用于高级计划的操作任务的抽象描 ...

  9. 扫描条形码获取商品信息(iOS 开发)

    一.导入ZBarSDK及其依赖库(这不是本文侧重点)     1.下载地址 https://github.com/bmorton/ZBarSDK     2.导入头文件 #import "Z ...

  10. CentOs8安装redis与Linux安装GDI+图形

    1.安装 yum install redis 2.编辑配置文件 vim /etc/redis.conf #requirepass那行并打开注释,在后面写自己的密码,如下 requirepass you ...