前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >面试官:你真的了解TCP连接吗?

面试官:你真的了解TCP连接吗?

作者头像
make a bug
发布2022-09-20 14:58:18
5510
发布2022-09-20 14:58:18
举报
文章被收录于专栏:我和bug只能活一个

三次握手是 TCP 连接的建立过程。在握手之前,主动打开连接的客户端结束 CLOSE 阶段,被动打开的服务器也结束 CLOSE 阶段,并进入 LISTEN 阶段。随后进入三次握手阶段。

三次握手

TCP

如果三次握手的时候每次握手信息对方没有收到会怎么样

1

第一次握手(syn包)丢失

当客户端发起的 TCP 第一次握手 SYN 包,在超时时间内没收到服务端的 ACK,就会超时重传 SYN 数据包,(每次超时重传的 RTO 是翻倍上涨的,最大次数tcp_syn_retries默认5)。

2

第二次握手(ack+syn包)丢失

当 TCP 第二次握手 SYN、ACK 包丢了后,客户端第一次握手的SYN 包会发生超时重传,服务端第二次握手的SYN、ACK 也会发生超时重传。

客户端 SYN 包超时重传的最大次数,是由 tcp_syn_retries 决定的,默认5;服务端 SYN、ACK 包时重传的最大次数,是由 tcp_synack_retries 决定的,默认5。

3

第三次握手(ack包)丢失

对于服务器:

在建立 TCP 连接时,如果第三次握手的 ACK,服务端无法收到,则服务端就会短暂处于 SYN_RECV 状态,而客户端会处于 ESTABLISHED 状态。

由于服务端一直收不到 TCP 第三次握手的 ACK,则第二次握手会一直重传 SYN、ACK 包,直到重传次数超过 tcp_synack_retries 值(默认5 )后,服务端就会断开 TCP 连接。(这里的断开是服务器单方面主动断开,客户端的状态还是established的)

对于客户端:

情况1:如果客户端没发送数据包,一直处于 ESTABLISHED 状态,触发保活机制检查这个tcp连接是否还存活,如果不存活,则为死亡连接,客户端断开连接。(触发保活机制)

情况2:如果客户端发送了数据包,一直没有收到服务端对该数据包的确认报文,则会一直重传该数据包,直到重传次数超过 tcp_retries2 值(默认15 )后,客户端就会断开 TCP 连接。

为什么是三次握手

核心原因:避免重复链接。

比如在网络环境比较复杂的情况,客户端可能会连续发送多次请求。如果只设计成两次握手的情况,服务端只能一直接收请求,然后返回请求信息,也不知道客户端是否请求成功。这些过期请求的话就会造成网络连接的混乱。

保证双方都是双工通信(客户端和服务器端可以双向通信)。

第一次握手,服务端确定客户端的发送正常。

第二次握手,客户端确认服务端的收发正常。

第三次握手,服务端确定客服端接收正常。

四次挥手即 TCP 连接的释放,这里假设客户端主动释放连接在挥手之前主动释放连接的客户端结束 ESTABLISHED 阶段,随后开始四次挥手。

四次挥手

TCP

为什么四次

因为TCP是全双工的,两个方向的连接需要单独关闭(也可以说是为了支持半关闭状态)。举例:因为B收到A要结束的请求后,还要把没有说完的话发完,等B把要说的话说完后B才发回一个结束FIN数据。

当客户端发出最后的 ACK 确认报文时,并不能确定服务器端能够收到该段报文。所以客户端在发送完 ACK 确认报文之后,会设置一个时长为 2 MSL 的计时器。MSL(Maximum Segment Lifetime),指一段 TCP 报文在传输过程中的最大生命周期。2 MSL 即是服务器端发出 FIN 报文和客户端发出的 ACK 确认报文所能保持有效的最大时长。

补充

TIME-WAIT 为什么是 2MSL

1

若服务器在 1 MSL 内没有收到客户端发出的 ACK 确认报文,会再次向客户端发出 FIN 报文。

如果客户端在 2 MSL 内收到了服务器再次发来的 FIN 报文,说明服务器由于一些原因并没有收到客户端发出的 ACK 确认报文。客户端将再次向服务器发出 ACK 确认报文,并重新开始 2 MSL 的计时。

若客户端在 2MSL 内没有再次收到服务器发送的 FIN 报文,则说明服务器正常接收到客户端 ACK 确认报文,客户端可以进入 CLOSE 阶段,即完成四次挥手。

客户端要经历 2 MSL 时长的 TIME-WAIT 阶段,为的是确认服务器能否接收到客户端发出的 ACK 确认报文。

补充

TCP 是如何保证可靠性的

1

数据分块:应用数据被分割成 TCP 认为最适合发送的数据块。

序列号和确认应答:TCP 给发送的每一个包进行编号,在传输的过程中,每次接收方收到数据后,都会对传输方进行确认应答,即发送 ACK 报文,这个 ACK 报文当中带有对应的确认序列号,告诉发送方成功接收了哪些数据以及下一次的数据从哪里开始发。除此之外,接收方可以根据序列号对数据包进行排序,把有序数据传送给应用层,并丢弃重复的数据。

校验和:TCP 将保持它首部和数据部分的检验和。这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到报文段的检验和有差错,TCP 将丢弃这个报文段并且不确认收到此报文段。

流量控制:TCP 连接的双方都有一个固定大小的缓冲空间,发送方发送的数据量不能超过接收端缓冲区的大小。当接收方来不及处理发送方的数据,会提示发送方降低发送的速率,防止产生丢包。TCP 通过滑动窗口协议来支持流量控制机制。

拥塞控制:当网络某个节点发生拥塞时,减少数据的发送。

ARQ(自动重传)协议:也是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认。在收到确认后再发下一个分组。

超时重传:当 TCP 发出一个报文段后,它启动一个定时器,等待目的端确认收到这个报文段。如果超过某个时间还没有收到确认,将重发这个报文段。

新浪微博|是yancy呀

公众号|我和bug只能活一个

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2022-05-17,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 AI懒人星球 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档