Su的技术博客

  • 首页
  • 原创
  • 视频
  • Java
  • MySQL
  • DDD
  • 事故复盘
  • 架构方案
  • AI
  • Other
  • 工具
    • AI工具集
    • 工具清单
    • JSON在线格式化
    • JSON在线比较
    • SQL在线格式化
  • 打赏
  • 关于
路很长,又很短
  1. 首页
  2. Java
  3. 正文
                           

【原创】笔记 | 面试又挂了,只因问了:TCP三次握手和四次挥手

2020-06-12 1795点热度 0人点赞 0条评论
面试官:跟我讲讲TCP的三次握手和四次挥手流程,为什么是三次握手或四次挥手?

面试者:额......不太记得了.....gg..

 

在前面的文章知道,《TCP与UDP的区别》,到《TCP是如何保证可靠性》。那么接下来就是TCP的核心了,即TCP的可靠性依赖其:三次握手和四次挥手。

 

先思考下这三个面试题:

1、TCP 为什么三次握手而不是两次握手?

2、为什么连接的时候是三次握手,关闭的时候却是四次握手?

3、为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

 

在TCP/IP协议中,TCP协议提供可靠的连接服务,连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号并交换 TCP窗口大小信息。

 

tcp三次握手和四次挥手交互图:

笔记 | 面试又挂了,只因问了:TCP三次握手和四次挥手

三次握手:

  1. 第一次握手:建立连接。客户端发送连接请求报文段,将SYN位置为1,Sequence Number为x;然后,客户端进入SYN_SEND状态,等待服务器的确认;
  2. 第二次握手:服务器收到SYN报文段。服务器收到客户端的SYN报文段,需要对这个SYN报文段进行确认,设置Acknowledgment Number为x+1(Sequence Number+1);同时,自己自己还要发送SYN请求信息,将SYN位置为1,Sequence Number为y;服务器端将上述所有信息放到一个报文段(即SYN+ACK报文段)中,一并发送给客户端,此时服务器进入SYN_RECV状态;
  3. 第三次握手:客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1,向服务器发送ACK报文段,这个报文段发送完毕以后,客户端和服务器端都进入ESTABLISHED状态,完成TCP三次握手。

四次挥手:

  1. 第一次挥手:主机1(可以使客户端,也可以是服务器端),设置Sequence Number和Acknowledgment Number,向主机2发送一个FIN报文段;此时,主机1进入FIN_WAIT_1状态;这表示主机1没有数据要发送给主机2了;
  2. 第二次挥手:主机2收到了主机1发送的FIN报文段,向主机1回一个ACK报文段,Acknowledgment Number为Sequence Number加1;主机1进入FIN_WAIT_2状态;主机2告诉主机1,我“同意”你的关闭请求;
  3. 第三次挥手:主机2向主机1发送FIN报文段,请求关闭连接,同时主机2进入LAST_ACK状态;
  4. 第四次挥手:主机1收到主机2发送的FIN报文段,向主机2发送ACK报文段,然后主机1进入TIME_WAIT状态;主机2收到主机1的ACK报文段以后,就关闭连接;此时,主机1等待2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,主机1也可以关闭连接了。 
三次握手可以简单通俗理解为:
    1)A要跟B聊天,问B在吗(收到了吗)?(SYN)
    2)B收到A,B回复A说收到了,那我们开始吧。(ACK+SYN)
    3)A收到B的回复,A:那我们开始聊天(数据传输)。(ACK)
四次挥手可以简答理解为:
    1)A跟B说,我要停止聊天了,你(B)还在吗?准备中断聊天了(FIN)
    2)B收到A的消息,B回复A说:我在。(ACK)
    3)B再发一条消息给A说,A你可以停止了。(FIN)
    4)A收到B说可以停止发消息了,A回复B说:收到!(ACK)
 

1、TCP 为什么三次握手而不是两次握手?

为了实现可靠数据传输,TCP 协议的通信双方,都必须维护一个序列号,以标识发送出去的数据包中,哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知序列号起始值, 并确认对方已经收到了序列号起始值的必经步骤。如果只是两次握手,至多只有连接发起方的起始序列号能被确认,另一方选择的序列号则得不到确认。

 

2、为什么连接的时候是三次握手,关闭的时候却是四次握手?

答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。

 

3、为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

文章关联→→:

一份Netty最全面试题!让面试官难不倒你!

抓包神器:Wireshark 实例分析TCP三次握手过程

 

笔记系列↓↓↓:

笔记 | Java对象探秘

笔记 | JVM内存区域结构:一计两栈一堆一区

笔记 | 并发编程的三大挑战

笔记 | TCP与UDP的区别

笔记 | TCP如何保证可靠性
参考:http://www.jellythink.com/archives/705
    回复公众号【资料】获得干货资料集锦:技术ppt、IT大会资料、架构、分布式资料等。
推荐好文

1、互联网Code Review最佳实践分享

2、dubbo面试题!会这些,说明你看懂了dubbo源码

3、Kafka面试题!掌握它才说明你真正懂Kafka
4、
Netty 5.0为啥被舍弃?原因竟然是...
5、
中台之上——业务架构系列【汇总】

6、必备瑞士军刀IDEA插件,你使用了哪些

7、线上热更新代码只需3步 Arthas实战

8、Eureka源码剖析之七:架构&面试题【总结】

9、互联网工程师应该用这种姿势打印日志

10、加入:互联网基础/架构交流群

笔记 | 面试又挂了,只因问了:TCP三次握手和四次挥手

-关注搬运工来架构,与优秀的你一同进步-

如果喜欢这篇文章可以点在看哦↘

本文仅供学习!所有权归属原作者。侵删!文章来源: 搬运工来架构

更多文章:

  1. 为什么 TCP 建立连接需要三次握手
  2. 记一次网络请求连接超时的事故
  3. 笔记 | 5种网络IO模型
  4. 笔记 | 网络编程基础:TCP如何保证可靠性
  5. 系统设计 | 业务编号生成
  6. 分布式唯一 ID 生成方案浅谈
  7. 笔记08 | 搜狗面试题:IO多路复用之select、poll、epoll的区别
  8. 笔记 | 面试官问我:TCP与UDP的区别
  9. 笔记 | 面试官问我高并发的问题:并发编程的三大挑战
  10. 腾讯的这道面试题,我懵了... —— Redis的hashtable是如何扩容的
标签: 原创 面试题 网络 网络编程 TCP
最后更新:2023-12-20

Cocodroid

专注Java后端,分享技术。

打赏 点赞
< 上一篇
下一篇 >

文章评论

razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
取消回复

广告
文章目录
  • 笔记 | 并发编程的三大挑战
最新 热点 推荐
最新 热点 推荐
干货 | 论Elasticsearch数据建模的重要性 马蜂窝消息总线——面向业务的消息服务设计 基于 MySQL Binlog 实现可配置的异构数据同步 视频笔记:Google发布Agent2Agent协议 视频笔记:什么是微服务,为什么是微服务? 视频笔记:什么是AI 智能体? 视频笔记:什么是Flink? 如何秒级实现接口间“幂等”补偿:一款轻量级仿幂等数据校正处理辅助工具
Elasticsearch 使用误区之六——富文本内容写入前不清洗基于 MySQL Binlog 实现可配置的异构数据同步马蜂窝消息总线——面向业务的消息服务设计干货 | 论Elasticsearch数据建模的重要性你可以不用RxJava,但必须得领悟它的思想!如何秒级实现接口间“幂等”补偿:一款轻量级仿幂等数据校正处理辅助工具视频笔记:什么是Flink?视频笔记:什么是AI 智能体?
云音乐贵州机房迁移总体方案回顾 系统设计 | 高精度计算 大家一直在谈的领域驱动设计(DDD),我们在互联网业务系统是这么实践的 7张架构图掌握后端服务重构技巧 京东购物车如何提升30%性能 做好技术负责人的4个关键特质 生产环境JVM崩溃问题排查解决 全链路压测之影子库及ShardingSphere实现影子库源码剖析

CRUD (1) Event Sourcing (1) graphql (1) id (1) NoSQL (1) quarkus (1) rest (1) RocketMQ (2) Spring Boot (1) zk (1) zookeeper (1) 上下文 (1) 事务消息 (1) 二级缓存 (1) 值对象 (1) 关系数据库 (1) 分布式缓存 (1) 原子性 (1) 唯一ID (1) 商品 (1) 多对多 (1) 子域 (1) 字符集 (1) 客户端心跳 (1) 幂等 (2) 干货 (1) 并发 (1) 应用场景 (1) 应用架构图 (1) 康威定律 (2) 异步复制 (1) 微服务架构 (2) 总体方案 (1) 技术方案 (2) 技术架构 (2) 技术架构图 (1) 技能 (1) 持续集成 (1) 支撑域 (1) 故障恢复 (1) 数据架构图 (1) 方案选型 (1) 日记 (1) 服务发现 (1) 服务治理 (1) 服务注册 (2) 机房 (1) 核心域 (1) 泄漏 (1) 洋葱架构 (1) 消息队列 (5) 源码剖析 (1) 灰度发布 (1) 熔断 (1) 生态 (1) 画图工具 (1) 研发团队 (1) 线程 (2) 组织架构 (1) 缓存架构 (1) 编码 (1) 视频 (18) 读写分离 (1) 贵州 (1) 软件设计 (1) 迁移 (1) 通用域 (1) 集群化 (1) 雪花算法 (1) 顺序消息 (1)

推荐链接🔗
  • AI工具集
  • 工具箱🛠️

COPYRIGHT © 2014-2025 verysu.com . ALL RIGHTS RESERVED.

Theme Kratos Made By Seaton Jiang

粤ICP备15033072号-2

x