网络原理

介绍TCP/IP协议中每一层里面的核心内容~

• 应用层
• 传输层
• 网络层
• 数据链路层
• 物理层

传输层

传输层主要负责端到端之间的传输,重点关注的是起点和终点

核心的协议有两个:

• UDP: 无连接 ,不可靠传输,面向数据报,全双工
• TCP : 有连接,可靠传输,面向字节流,全双工

TCP 协议

作为传输层协议,协议报头中必须要明确源端口和目的端口

TCP的基本特性

面向字节流,有连接,全双工,代码中都是有所体现的~

但是可靠传输,在代码中体现不出来~

1.确认应答

确认应答机制!!

把这个应答的报文(回复的内容 : 收到)也称为ACK报文,ACK => acknowledge
ACK(acknowledge)和响应(response)是截然不同的!
ACK只是告诉发送方,我收到数据了
response是携带业务上的数据

普通报文,ACK这一位为 0
应答报文,ACK这一位为 1

确认应答机制,就是TCP保证可靠性的最核心机制!!!

🚌但是网络中传输中有可能会出现 后发先至 的情况 !
后发的请求可能会先到达对方这里!!
这样就会导致请求和应答对应错误…
后发先至,这是网络基本结构导致的,难以避免

🍟解决方案 :

针对请求和应答报文,进行编号

这两个数值就是上述的编号:

32位序号 : 针对请求数据进行编号
32位确认序号:只是针对ACK(应答)报文有效

TCP是一个字节流的协议,编号的时候,也是以字节为单位,进行编号的!

TCP将每个字节的数据都进行了编号,即为序列号

报文序号是1001,报文长度是 1000(最后一个字节的数据编号是2000)

TCP将每个字节的数据都进行了编号,即为序列号

❓序号不会溢出吗?

理论上也是会的,但是也不太影响~
TCP 32位序号和确认序号
表示的数据范围是 0- 42亿9千万
4GB,如果确实一个连接传输的数据太多太多了,那大不了序号到头了之后,再重新来算就可以了!

2.超时重传

确认应答描述的是,数据报顺利到达对方,对方给了个响应,但是传输过程中,可能会出现丢包的情况~

❓为什么会丢包?
网络环境是非常复杂的!
我可以上网,是因为接入了运营商的网络
运营商这边就有很多很多的路由器/交换机,共同组建出一个非长庞大复杂的网络
某个交换机上面,不光是传输我的数据报,也在传输别人的数据报
某个时刻,很多很多数据报都经过这个交换机
交换机的转发能力有上限,如果很多数据报都走这里,导致达到交换机的转发上限,就无法快捷的完成转发了,就可能会导致有一部分数据报就超时了~

❓如果丢包要怎么办呢?
如果数据丢包了,此时就需要考虑通过"超时重传"来进行了!

• 如果是发送方发的消息丢了,等一个特定的时间,时间过了就认为丢包了,就重新发一个消息(重传),不会有任何后果~ 这就叫超时重传!

• 如果是ACK丢了,但站在发送者的角度来看,没看到回应,无法区分是我发的数据丢了,还是ACK丢了,所以我就会觉得是我发的数据丢了,还是会进行超时重传!
  ❗ 但如果是ACK丢了,对方已经收到消息了,然后又重传,对方就受到了两个一模一样的消息…
  TCP接收方因为丢失ACK导致收到重复的消息,TCP就会针对相同的消息进行去重(根据序号来进行去重)
  保证了应用层代码通过 socket 读取数据的时候,读到的不是重复数据~

💕超时时间如何确定的?
一般系统里面会有一个配置项,描述超时的时间阈值~

例如:

第一次出现丢包,发送方就会在到达超时时间阈值,之后,进行重传
如果重传的数据仍然无响应~
还会继续超时重传,第二次的超时时间一般要比第一次更长~
(超时时间并非是均等的,而是逐渐变大的)
如果单个数据报丢包概率较小,这个时候,第二次传输,大概率是可以到达的
如果第二次传输也没有达到,说明当前网络环境比较糟糕~ 单个数据报丢包概率就非常大了…(甚至100%,比如断网了)
如果网都断了,再怎么频繁的重传,也没什么用,就不如穿的频率降低一点(时间间隔长一点),至少可以节省点主机的开销~

这样的重传,重试几次之后,仍然无法传输,就像会尝试重置 TCP 连接 (断开重连)
如果还是连不上,此时就直接释放连接(彻底放弃)

描述上述过程,并没有带入具体数字:

比如 基础的重传间隔是多少,每次间隔增加多少,最多重传多少次~
这里的具体参数,不同的系统不一样,并且一般也是可配置的

总结