传输层协议——TCP
TCP协议
TCP全称为“传输控制协议”,要对数据的传输进行一个详细的控制。
特点
- 面向连接的
- 可靠性
- 字节流
TCP的协议段格式
- 源/目的端口:表示数据从哪个进程来,到哪个进程
- 4位首部长度:表示该TCP头部有多少字节(注意它的单位是4字节),因为TCP报头的范围为[20,60],所以4位首部长度范围就是[5,15]
- 16位校验和:校验报文是否符合要求,不符合直接丢弃
6位标记位
- URG:紧急指针是否有效
- ACK:确认号是否有效
- PSH:提示服务端立刻将TCP缓冲区的数据读走
- RST:对方要求重新建立链接
- SYN:请求建立连接,我们携带SYN标识的称为同步报文段
- FIN:通知对方,本端将断开连接。
我将从下面的几个场景中来阐述一下TCP中协议段格式的每个含义。
ACK确认应答机制
当我们主机A发送数据的时候,主机B需要给主机A发送“已收到”(ACK),这时主机A开知道数据已经发送到了主机B。但如果主机B想要发数据给主机A,那么就又要需要一次write了,所以效率其实是不高的,所以有了后面的捎带应答。
捎带应答
我们发现,很多情况下,客户端服务器在应用层也是 "一发一收"的.意味着客户端给服务器说了 “How are you”,服务器也会给客户端回一个 “Fine,thank you”;那么这个时候 ACK就可以搭顺风车,和服务器回应的 "Fine, thank you"一起回给客户端
32位序号和32位确认序号
32位序号:在建立连接的时候,计算机会随机生成一个随机数作为初始值,当传送一次数据的时候,会累加上数据的大小。 用来解决网络中乱序的问题
32位确认序号:发送端接受到确认应答后,可以认为这个序号之前的序号全部被收到了。用来解决网络中丢包的问题
三次握手与四次挥手
TCP建立连接
- 一开始的时候,客户端和服务端都是CLOSED状态,然后服务端去监听某个端口,然后处于LISTEN状态
- 客户端就会去建立连接,然后会先初始化序号(clinet_isn),将SYN标记位置为1,然后将整个报头发送过去,之后客户端除以SYN_SENT状态
- 服务端收到了来自客户端携带的SYN报头后,也会先初始化自己的序(server_isn)号,然后将确认应答设置为clinet_isn+1,,将TCP报头中ACK和SYN设置为1,然后将报文发送给客户端。之后状态为SYN_REVD
- 最后客户端收到了来自服务端的数据,将TCP中ACK置为1,将确认序号设置为server_isn+1,然后将报文发送给服务端(这次可以携带数据),之后客户端状态为ESTABLISHED。
从上面的三次握手中可以看到,第二次服务端返回ACK和SYN的时候,其实就用到了捎带应答。 而且注意 前两次握手是不能发送数据的,而第三次是可以的。
四次挥手
- 客户端首先会先发送携带FIN的报文给服务端,表示要断开连接。之后状态设置为FIN_WAIT_1
- 服务端收到该报文后,就向客户端发送 ACK 应答报文,接着服务端进入 CLOSE_WAIT 状态。
- 客户端收到服务端的 ACK 应答报文后,之后进入 FIN_WAIT_2 状态。
- 这时,服务端可能需要处理数据。之后会发送FIN报文,之后状态为LAST_ACK
- 客户端收到服务端的 FIN 报文后,回一个 ACK 应答报文,之后进入 TIME_WAIT 状态
- 服务端收到了 ACK 应答报文后,就进入了 CLOSE 状态,至此服务端已经完成连接的关闭。
- 客户端在经过 2MSL 一段时间后,自动进入 CLOSE 状态,至此客户端也完成连接的关闭。
2MSL:刚好是客户端发送数据到服务端的时间 + 服务端发送数据回到客户端的时间(这样就确保再2MSL之后,再无数据处理了)
其实你看,三次握手因为捎带应答,合并成了一次,而四次挥手中,不合并是因为,服务端可能还会发送数据给客户端。
之所以被称为四次挥手,你看图中,是不是客户端和服务端都会发送FIN和ACK来表示自己要断开连接,一来一回刚好4次。
为什么是三次握手?1次可以吗?2次可以吗?4次可以吗?
先来回答一下为什么是三次握手
- 需要确保通信是正常的。3次刚好可以验证TCP全双工
- 确保双方OS是健康的,且愿意通信(各自发送ACK)
再聊一聊如果TCP1次和2次握手会发生什么事
- 我们要知道建立连接是需要消耗资源的,所以如果有人恶意的发送大量SYN报文呢,并且不想接受数据,这样看,1次和2次握手是不是很不合理呢?
4次握手可以吗?
- 当然可以,但是没必要,因为3次握手已经是最少可靠的连接建立了,并且保证了全双工。
超时重传机制
TCP要保证所有的数据包可以达到对方,就必须要有超时重传的机制。
- 主机A发送数据给主机B,但由于网络的原因,数据没有到达主机B
- 主机A在一个特定的时间间隔(这个时间间隔在不同的内核版本中是不同的)内没有收到主机B的数据,就会重新发送(注意重新传的SYN报文是一样的)。
但是,主机 A未收到 B发来的确认应答,也可能是因为 ACK丢失了
因此主机 B会收到很多重复数据.那么 TCP协议需要能够识别出那些包是重复的包,并且把重复的丢弃掉.
所以就有了序号,可以做到去重的效果。
那么最后一个问题来了??
超时的时间怎么确定呢??
- 最理想的情况下,找到一个最小的时间,保证 “确认应答一定能在这个时间内返回”.
- 但是这个时间的长短,随着网络环境的不同,是有差异的
- 如果超时时间设的太长,会影响整体的重传效率
- 如果超时时间设的太短,有可能会频繁发送重复的包
所以TCP为了保证无论在任何环境下都能比较高性能的通信,因此会动态计算这个最大超时时间.
- Linux中(BSD Unix和 Windows也是如此),超时以 500ms为一个单位进行控制,每次判定超时重发的超时时间都是500ms的整数倍.
- 如果重发一次之后,仍然得不到应答,等待 2*500ms后再进行重传.
- 如果仍然得不到应答,等待 4*500ms进行重传.依次类推,以指数形式递增.
重发的次数和操作系统有关。
在ubuntu20.04下是6次
原文地址:https://blog.csdn.net/m0_72165281/article/details/140671524
免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!