资讯专栏INFORMATION COLUMN

网络协议 8 - TCP(上)

zhangwang / 1876人阅读

摘要:包头格式老规矩,咱们先来看看头的格式。给的确认信息发出后,遇到网络不好的情况,也会出现丢包的情况。这是因为包头里的生存时间。它是任何报文再网络上存在的最长时间,超过这个时间的报文就会被丢弃。协议规定为分钟,实际应用中常用的是秒分钟和分钟等。

网络协议 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

相关文章

  • 网络协议 8 - TCP

    摘要:包头格式老规矩,咱们先来看看头的格式。给的确认信息发出后,遇到网络不好的情况,也会出现丢包的情况。这是因为包头里的生存时间。它是任何报文再网络上存在的最长时间,超过这个时间的报文就会被丢弃。协议规定为分钟,实际应用中常用的是秒分钟和分钟等。 网络协议 1 - 概述 网络协议 2 - IP 是怎么来,又是怎么没的? 网络协议 3 - 从物理层到 MAC 层 网络协议 4 - 交换机与 ...

    joywek 评论0 收藏0
  • 网络协议 9 - TCP(下)

    摘要:收到了,发送,要求下一个是,不幸又丢了。在对于包的确认中,会同时携带一个窗口大小的字段。前面的滑动窗口是怕发送方把接收方缓存塞满,而拥塞窗口,是怕把网络塞满。这里有一个公式可以看出,是拥塞窗口和滑动窗口共同控制发送的速度。 网络协议 1 - 概述 网络协议 2 - IP 是怎么来,又是怎么没的? 网络协议 3 - 从物理层到 MAC 层 网络协议 4 - 交换机与 VLAN:办公室太...

    Noodles 评论0 收藏0
  • 网络协议 9 - TCP(下)

    摘要:收到了,发送,要求下一个是,不幸又丢了。在对于包的确认中,会同时携带一个窗口大小的字段。前面的滑动窗口是怕发送方把接收方缓存塞满,而拥塞窗口,是怕把网络塞满。这里有一个公式可以看出,是拥塞窗口和滑动窗口共同控制发送的速度。 网络协议 1 - 概述 网络协议 2 - IP 是怎么来,又是怎么没的? 网络协议 3 - 从物理层到 MAC 层 网络协议 4 - 交换机与 VLAN:办公室太...

    Carbs 评论0 收藏0

发表评论

0条评论

zhangwang

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<