网络协议 8 - TCP协议(上)
上次说了“性本善”的 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 个问题。顺序问题、丢包问题、连接维护、流量控制、拥塞控制;
- 建立连接三次握手,断开连接四次挥手,状态图要牢记。
欢迎添加个人微信号:Like若所思。
欢迎关注我的公众号,不仅为你推荐最新的博文,还有更多惊喜和资源在等着你!一起学习共同进步!
网络协议 8 - TCP协议(上)的更多相关文章
- C#网络编程之---TCP协议的同步通信(二)
上一篇学习日记C#网络编程之--TCP协议(一)中以服务端接受客户端的请求连接结尾既然服务端已经与客户端建立了连接,那么沟通通道已经打通,载满数据的小火车就可以彼此传送和接收了.现在让我们来看看数据的 ...
- 网络协议 9 - TCP协议(下):聪明反被聪明误
网络协议 1 - 概述 网络协议 2 - IP 是怎么来,又是怎么没的? 网络协议 3 - 从物理层到 MAC 层 网络协议 4 - 交换机与 VLAN:办公室太复杂,我要回学校 网络协议 5 - I ...
- 卫星网络中使用TCP协议的劣势(所以才有TCP优化版用来卫星通信啊,比如TCP-Peach和ADolar)
卫星网络中使用TCP协议的劣势 为了避免产生网络拥塞,原TCP协议综合采用了慢启动.拥塞避免.快速重传以及快速恢复等算法.但这些算法应用的前提是网络发生拥塞造成丢包,然而在误码率相对较高的卫星通信系统 ...
- http协议,tcp协议,ip协议,dns服务之前的关系和区别
长期以来都有一个问题,大家都在说http协议,tcp协议,ip协议,他们之间到底什么区别,有什么用,没人告诉我,最近看了这本<图解http>明白了一些,以下图片摘自这本书 一.理解一个传输 ...
- Http协议与TCP协议简单理解(转)
在C#编写代码,很多时候会遇到Http协议或者TCP协议,这里做一个简单的理解.TCP协议对应于传输层,而HTTP协议对应于应用层,从本质上来说,二者没有可比性.Http协议是建立在TCP协议基础之上 ...
- 【转载】Http协议与TCP协议简单理解
在C#编写代码,很多时候会遇到Http协议或者TCP协议,这里做一个简单的理解.TCP协议对应于传输层,而HTTP协议对应于应用层,从本质上来说,二者没有可比性.Http协议是建立在TCP协议基础之上 ...
- Http协议与TCP协议
背景 在日常工作中,经常会遇到某某框架是基于Http协议或者TCP协议,今天,就针对于该协议,整理下 从本质上来说,Http协议与TCP协议是应用在不同网络层,Http协议处于应用层,TCP处于传输层 ...
- 网络协议 8 - TCP协议(上):性恶就要套路深
系列文章: 网络协议 1 - 概述 网络协议 2 - IP 是怎么来,又是怎么没的? 网络协议 3 - 从物理层到 MAC 层 网络协议 4 - 交换机与 VLAN:办公室太复杂,我要回学校 网络协议 ...
- 网络编程——基于TCP协议的Socket编程,基于UDP协议的Socket编程
Socket编程 目前较为流行的网络编程模型是客户机/服务器通信模式 客户进程向服务器进程发出要求某种服务的请求,服务器进程响应该请求.如图所示,通常,一个服务器进程会同时为多个客户端进程服务,图中服 ...
随机推荐
- 小程序1px边框在苹果机上变粗问题
在ios系统上1px的边框会变成2px,ui会感觉很粗 列表间隔,只需要一条边框 .border:after { position: absolute; content: ''; width: 100 ...
- 仓库服务端软件artifactory
https://blog.csdn.net/ZYC88888/article/details/88298904 https://www.jianshu.com/p/a0f55548fddd
- luogu P2495 [SDOI2011]消耗战 |虚树+LCA+dp
题目描述 在一场战争中,战场由n个岛屿和n-1个桥梁组成,保证每两个岛屿间有且仅有一条路径可达.现在,我军已经侦查到敌军的总部在编号为1的岛屿,而且他们已经没有足够多的能源维系战斗,我军胜利在望.已知 ...
- 明解C语言 入门篇 第九章答案
练习9-1 /* 将字符串存储在数组中并显示(其2:初始化) */ #include <stdio.h> int main(void) { char str[] = "ABC\0 ...
- PHP服务端优化全面总结
一.优化PHP原则 1.1PHP代码的优化 (1)升级最新的PHP版本 鸟哥PPT里的对比数据,就是WordPress在PHP5.6执行100次会产生70亿次的CPU指令执行数目,而在PHP7中只需要 ...
- java中 Math和StrictMath
今天无意中看到java api中有StrictMath 这个工具类,发现它部分调用实现是用了Math中的实现.Math 这个类API 1.0版本就有了,StrictMath API是1.3版本才出来的 ...
- Sitecore性化 - 您需要了解的4件事
Sitecore非常强大,是一个数字体验平台.它可以帮助您取悦并留住客户.它可以帮助您衡量和评估广告系列.它使你成为一个更好的营销人员.它可以帮助您获得结果! 它结合了易于使用的网站内容管理系统和数字 ...
- Kafka学习笔记3--Kafka的生产者和消费者配置
下载解压 kafka 后,在 kafka/config 下有 3 个配置文件与主题及其生产.消费相关. server.properties--服务端配置 producer.properties--生产 ...
- WPF 精修篇 非UI进程后台更新UI进程
原文:WPF 精修篇 非UI进程后台更新UI进程 <Grid> <Grid.RowDefinitions> <RowDefinition Height="11* ...
- .NET MVC 序列化与反序列化
using System.Runtime.Serialization.Json; using System.IO; using System.Text; //序列化 public str ...