摘要:包头格式老规矩,咱们先来看看头的格式。给的确认信息发出后,遇到网络不好的情况,也会出现丢包的情况。这是因为包头里的生存时间。它是任何报文再网络上存在的最长时间,超过这个时间的报文就会被丢弃。协议规定为分钟,实际应用中常用的是秒分钟和分钟等。
网络协议 1 - 概述
网络协议 2 - IP 是怎么来,又是怎么没的?
网络协议 3 - 从物理层到 MAC 层
网络协议 4 - 交换机与 VLAN:办公室太复杂,我要回学校
网络协议 5 - ICMP 与 ping:投石问路的侦察兵
网络协议 6 - 路由协议:敢问路在何方?
网络协议 7 - UDP 协议:性善碰到城会玩
上次说了“性本善”的 UDP 协议,这哥们秉承“网之初,性本善,不丢包,不乱序”的原则,徜徉在网络世界中。
与之相对应的,TCP 就像是老大哥一样,了解了社会的残酷,变得复杂而成熟,秉承“性恶论”。它认为网络环境是恶劣的,丢包、乱序、重传、拥塞都是常有的事儿,一言不合可能就会丢包,送达不了,所以从算法层面来保证可靠性。
TCP 包头格式老规矩,咱们先来看看 TCP 头的格式。
从上面这个图可以看出,它比 UDP 要复杂的多。而复杂的地方,也正是它为了解决 UDP 存在的问题所必需的字段。
首先,源端口号和目标端口号是两者都有,不可缺少的字段。
接下来是包的序号。给包编号就是为了解决乱序的问题。老大哥做事,稳重为主,一件件来,面临再复杂的情况,也临危不乱。
除了发送端需要给包编号外,接收方也会回复确认序号。做事靠谱,答应了就要做到,暂时做不到也要给个回复。
这里要注意的是,TCP 是个老大哥没错,但不能说他一定会保证传输准确无误的完成。从 IP 层面来讲,如果网络的确那么差,是没有任何可靠性保证的,即使 TCP 老大哥再稳,他也管不了 IP 层丢包,他只能尽可能的保证在他的层面上的可靠性。
然后是一些状态位。有以下常见状态位:
SYN(Synchronize Sequence Numbers,同步序列编号):发起一个连接
ACK(Acknowledgement,确认字符):回复
RST(Connection reset):重新连接
FIN:结束连接
从这些状态位就可以看出,TCP 基于“性恶论”,警觉性就很高,不像 UDP 和小朋友似的,随便一个不认识的小朋友都能玩到一起,他与别人的信任要经过多次交互才能建立。
还有一个窗口大小。这个是 TCP 用来进行流量控制的。通信双方各声明一个窗口,标识自己当前的处理能力,让发送端别发送的太快,要不然撑死接收端。也不能发送的太慢,要不然就饿死接收端了。
根据上述对 TCP 头的分析,我们知道对于 TCP 协议要重点关注以下几个问题:
顺序问题,稳重不乱;
丢包问题,承诺靠谱;
连接伟豪,有始有终;
流量控制,把握分寸;
拥塞控制,知进知退。
TCP 的三次握手了解完 TCP 头,我们就来看下 TCP 建立连接的过程,这就是著名的“三次握手”。
三次握手,过程是这样子的:
A:你好,我是 A(SYN)。
B:你好 A,我是 B(SYN,ACK)。
A:你好 B(ACK 的 ACK)。
着重记忆上述过程,后续很多分析都是基于这个过程来的。
记得刚接触三次握手的时候,就一直很纳闷,为啥一定要三次?两次不行吗?四次不行吗?然后很多人就解释,如果是两次,就怎样怎样,四次,又怎样怎样?但这其实都是从结果推原因,没有说明本质。
我们应该知道,握手是为了建立稳定的连接,这个是最终目的。而要达到这个目的,就要通信双方的交互形成一个确认的闭环。
拿上述 A、B 通信的例子来看,A 给 B 发信息,B 要告诉 A 他收到信息了。这时候,算是一个确认闭环吗?明显不是,因为 B 没有收到来自 A 的确认信息。
所以,要达到我们上述的目标,还要 A 给 B 一个确认信息,这样就形成了一个确认闭环。
A 给 B 的确认信息发出后,遇到网络不好的情况,也会出现丢包的情况。按理来说,还应该有个回应,但是,我们发现,好像这样下去就没玩没了啦。
所以,我们说,只要通信双方形成一个确认闭环后,就认为连接已建立。一旦连接建立,A 会马上发送数据,而 A 发送数据,后续的很多问题都得到了解决。
例如 A 发给 B 的确认消息丢了,当 A 后续发送的数据到达的时候,B 可以认为这个连接已经建立。如果 B 直接挂了,A 发送的数据就会报错,说 B 不可达,这样,A 也知道 B 出事情了。
三次握手除了通信双方建立连接外,主要还是为了沟通 TCP 包的序号问题。
A 要告诉 B,我发起的包的序号起始是从哪个号开始的,B 也要告诉 A,B 发起的包的序号的起始号。
TCP 包的序号是会随时间变化的,可以看成一个 32 位的计数器,每 4ms 加一。计算一下,这样到出现重复号,需要 4 个多小时。但是,4 个小时后,还没到达目的地的包早就死翘翘了。这是因为 IP 包头里的 TTL(生存时间)。
为什么序号不能从 1 开始呢?因为这样会很容易出现冲突。
例如,A 连上 B 之后,发送了 1、2、3 三个包,但是发送 3 的时候,中间丢了,或者绕路了,于是重新发送,后来 A 掉线了,重新连上 B 后,序号又从 1 开始,然后发送 2,但是压根没想发送 3,而如果上次绕路的那个 3 刚好又回来了,发给了 B ,B 自然就认为,这就是下一包,于是发生了错误。
就这样,双方历经千辛万苦,终于建立了连接。前面也说过,为了维护这个连接,双方都要维护一个状态机,在连接建立的过程中,双方的状态变化时序图就像下面这样:
整体过程是:
客户端和服务端都处于 CLOSED 状态;
服务端主动监听某个端口,处于 LISTEN 状态;
客户端主动发起连接 SYN,处于 SYN-SENT 状态。
服务端收到客户端发起的连接,返回 SYN,并且 ACK 客户端的 SYN,处于 SYN-RCVD 状态;
客户端收到服务端发送的 SYN 和 ACK 之后,发送 ACK 的 ACK,处于 ESTABLISHED 状态;
服务端收到 ACK 的 ACK 之后,处于 ESTABLISHED 状态。
TCP 的四次挥手说完了连接,接下来就来了解下 TCP 的“再见模式”。这也常被称为四次挥手。
还拿 A 和 B 举例,挥手过程:
A:B 啊,我不想和你玩了。
B:哦,你不想玩了啊,我知道了。这个时候,还只是 A 不想玩了,就是说 A 不会再发送数据,但是 B 此时还没做完自己的事情,还是可以发送数据的,所以此时的 B 处于半关闭状态。
B:A啊,好吧,我也不想和你玩了,拜拜。
A:好的,拜拜。
这样这个连接就关闭了。看起来过程很顺利,是的,这是通信双方“和平分手”的场面。
A 开始说“不玩了”,B 说“知道了”,这个回合,是没什么问题的,因为在此之前,双方还处于合作的状态。
如果 A 说“不玩了”,没有收到回复,那么 A 会重新发送“不玩了”。但是这个回合结束之后,就很可能出现异常情况了,因为有一方率先撕破脸。这种撕破脸有两种情况。
一种情况是,A 说完“不玩了”之后,A 直接跑路,这是会有问题的,因为 B 还没有发起结束,而如果 A 直接跑路,B 就算发起结束,也得不到回答,B 就就不知道该怎么办了。
另一种情况是,A 说完“不玩了”,B 直接跑路。这样也是有问题的,因为 A 不知道 B 是还有事情要处理,还是过一会发送结束。
为了解决这些问题,TCP 专门设计了几个状态来处理这些问题。接下来,我们就来看看断开连接时的状态时序图。
整体过程是:
A 说“不玩了”,就进入 FIN_WAIT_1 状态;
B 收到 “A 不玩”的消息后,回复“知道了”,就进入 CLOSE_WAIT 状态;
A 收到“B 说知道了”,进入 FIN_WAIT_2 状态。这时候,如果 B 直接跑路,则 A 将永远在这个状态。TCP 协议里面并没有对这个状态的处理,但是 Linux 有,可以调整 tcp_fin_timeout 这个参数,设置一个超时时间;
B 没有跑路,发送了“B 也不玩了”的消息,处于 LAST_ACK 状态;
A 收到“B 说不玩了”的消息,回复“A 知道 B 也不玩了”的消息后,从 FINE_WAIT_2 状态结束。
最后一个步骤里,如果 A 直接跑路了,也会出现问题。因为 A 的最后一个回复,B 如果没有收到的话就会重复第 4 步,但是因为 A 已经跑路了,所以 B 会一直重复第 4 步。
因此,TCP 协议要求 A 最后要等待一段时间,这个等待时间是 TIME_WAIT,这个时间要足够长,长到如果 B 没收到 A 的回复,B 重发给 A,A 的回复要有足够时间到达 B。
A 直接跑路还有一个问题是,A 的端口就空出来了,但是 B 不知道,B 原来发过的很多包可能还在路上,如果 A 的端口被新的应用占用了,这个新的应用会受到上个连接中 B 发过来的包,虽然序列号是重新生成的,但是这里会有一个双保险,防止产生混乱。因此也需要 A 等待足够长的时间,等到 B 发送的所有未到的包都“死翘翘”,再空出端口。
这个等待的时间设为 2MSL,MSL 是 Maximum Segment Lifetime,即报文最大生存时间。它是任何报文再网络上存在的最长时间,超过这个时间的报文就会被丢弃。
因为 TCP 报文基于 IP 协议,而 IP 头中有一个 TTL 域,是 IP 数据报可以经过的最大路有数,每经过一个处理他的路由器,此值就减 1,当此值为 0 时,数据报就被丢弃,同时发送 ICMP 报文通知源主机。协议规定 MSL 为 2 分钟,实际应用中常用的是 30 秒、1分钟和 2 分钟等。
还有一种异常情况,B 超过了 2MS 的时间,依然没有收到它发的 FIN 的 ACK。按照 TCP 的原理,B 当然还会重发 FIN,这个时候 A 再收到这个包之后,就表示,我已经等你这么久,算是仁至义尽了,再来的数据包我就不认了,于是直接发送 RST,这样 B 就知道 A 跑路了。
TCP 状态机将连接建立和连接断开的两个时序状态图综合起来,就是著名的 TCP 状态机。我们可以将这个状态机和时序状态机对照看,就会更加明了。
图中加黑加粗部分,是上面说到的主要流程,相关说明:
阿拉伯数字序号:建立连接顺序;
大写中文数字序号:断开连接顺序;
加粗实线:客户端 A 的状态变迁;
加粗虚线:服务端 B 的状态变迁;
总结TCP 包头很复杂,主要关注 5 个问题。顺序问题、丢包问题、连接维护、流量控制、拥塞控制;
建立连接三次握手,断开连接四次挥手,状态图要牢记。
参考:
百度百科-TCP 词条;
刘超-趣谈网络协议系列课;
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/29696.html
摘要:包头格式老规矩,咱们先来看看头的格式。给的确认信息发出后,遇到网络不好的情况,也会出现丢包的情况。这是因为包头里的生存时间。它是任何报文再网络上存在的最长时间,超过这个时间的报文就会被丢弃。协议规定为分钟,实际应用中常用的是秒分钟和分钟等。 网络协议 1 - 概述 网络协议 2 - IP 是怎么来,又是怎么没的? 网络协议 3 - 从物理层到 MAC 层 网络协议 4 - 交换机与 ...
摘要:收到了,发送,要求下一个是,不幸又丢了。在对于包的确认中,会同时携带一个窗口大小的字段。前面的滑动窗口是怕发送方把接收方缓存塞满,而拥塞窗口,是怕把网络塞满。这里有一个公式可以看出,是拥塞窗口和滑动窗口共同控制发送的速度。 网络协议 1 - 概述 网络协议 2 - IP 是怎么来,又是怎么没的? 网络协议 3 - 从物理层到 MAC 层 网络协议 4 - 交换机与 VLAN:办公室太...
摘要:收到了,发送,要求下一个是,不幸又丢了。在对于包的确认中,会同时携带一个窗口大小的字段。前面的滑动窗口是怕发送方把接收方缓存塞满,而拥塞窗口,是怕把网络塞满。这里有一个公式可以看出,是拥塞窗口和滑动窗口共同控制发送的速度。 网络协议 1 - 概述 网络协议 2 - IP 是怎么来,又是怎么没的? 网络协议 3 - 从物理层到 MAC 层 网络协议 4 - 交换机与 VLAN:办公室太...
阅读 2007·2021-09-22 15:54
阅读 1800·2021-09-04 16:40
阅读 829·2019-08-30 15:56
阅读 2594·2019-08-30 15:44
阅读 2098·2019-08-30 13:52
阅读 1068·2019-08-29 16:35
阅读 3304·2019-08-29 16:31
阅读 2532·2019-08-29 13:48