前言
大家好啊，我是汤小圆。
明天给大家举荐的经典面试知识点总结，心愿对大家有帮忙，谢谢。
简介
咱们平时常常听到的 TCP/IP 协定，其实是一个 协定族；
只不过因为 TCP、IP 是其中最外围的协定，所以平时统称为TCP/IP 协定；
这个协定族外面还有其余协定，比方 HTTP、FTP、SMTP 等；
TCP 分层框架
下图是 TCP/IP 协定族的一个分层框架图，从上往下顺次是 应用层、传输层、网络层、链路层、物理层
如果我想在机器 A 上，发送一条 ”Hello World” 到机器 B，这个通信过程是个什么样子呢？
首先机器 A 的应用层将音讯内容 ”Hello World” 打包，而后经由传输层加上单方的端口号，网络层加上单方的 IP 地址，链路层加上单方的 Mac 地址，通过多个路由器和网关，最终达到机器 B，而后机器 B 再反过来解析出音讯内容 ”Hello World”
简化之后的门路就是：音讯实体 + 端口号 +IP 地址 +Mac 地址，封装发送，收到音讯后，再反过来解包操作
上面咱们从上往下，顺次介绍各个分层的作用
应用层
依照固定的协定格局打包、解包数据。
比方 SMTP 协定，尽管不同公司的邮箱格局不尽相同，然而都能够解析对方发来的邮件内容，就是因为他们都遵循 SMTP 协定
传输层
决定数据要传输到近程机器的哪个程序（端口），同时要表明数据来自源机器的哪个程序（端口），实现端口之间的通信。
比方本地跑一个测试程序 A，监听的是 8080 端口；近程跑的测试程序 B，监听的是 8080 端口；
那么传输层就会把本机的 8080 端口和近程的 8080 端口都加到数据包上；
这样近程机器解析数据时，就晓得要把数据传给哪个程序。
网络层
指定单方的 IP 地址，并进行路由的寻址和转发
这里要明确一点就是，近程机器的 IP 地址不是一次跳转就能够达到的，要通过路由器和网关的屡次跳转，才会达到
这个能够参考视频《TCP/IP 协定 – B 站 – 马士兵》
链路层
指定近程机器的 Mac 地址（确保不会发错中央），以及本机的 Mac 地址
既然有了 Mac 地址来作为机器的惟一 ID，为啥还要有网络层的 IP 地址呢？
起因有两个
- IP 是会变动的，有可能明天你跟机器 A 在聊天，今天就变成机器 B 了，当然会乱掉了
- 当初的电脑太多了，数以千万计，从这么多电脑中找出某一个 Mac 地址，效率很低；然而 IP 不一样，IP 是由网段划分的，有点相似于邮编，这样就能够分段寻址，效率高很多
TCP 的三次握手，四次挥手
三次握手
三次握手就是建设连贯的过程，示意图如下所示
咱们来再把流程简化一点，就是：机器 A 发送 连贯申请 到机器 B -> 机器 B 收到后，确认并发送同步信号 -> 机器 A 收到确认信号后，再次发送确认信号到机器 B
这外面波及到几个关键词，上面列出一一阐明下
标记关键词
- SYN（Synchronize Sequence Numbers），同步信号，示意打算建设连贯时的一个信号
- ACK（Acknowledgement），数据确认信号，示意是否确认收到数据
状态关键词
- LISTENING，监听状态，示意还没开始建设连贯，正在监听期待连贯的到来
- SYN_SENT，SYN 已发送，示意 SYN 曾经发送，然而胜利不胜利还不晓得
- SYN_RCVD，SYN 已收到，示意收到 SYN 信号，也曾经给了应答，然而连贯还没建设
- ESTABLISHED，连贯建设，示意单方曾经建设了连贯，能够开始互相通信了
上面具体说下三次握手的连贯过程
- 机器 A 发送同步信号 SYN=1，申请建设连贯，并附带序列号 seq=x（机器 A 定义）
- 机器 B 收到连贯申请(SYN=1)，返回 同步信号 SYN=1 和 数据确认信号 ACK=1，并附带序列号 seq = y（机器 B 本人定义），确认序列号 ack = x + 1（不便机器 A 校验）
- 机器 A 收到机器 B 的反馈后，持续发送 确认信号 ACK=1，并附带序列号 seq = x + 1，确认序列号 ack = y + 1
为什么要三次？两次行不行？
两次也能够，就是会呈现 脏连贯 和信息不对等 问题。（开玩笑的，两次当然不行了，呈现这么多问题，大家都不必通信了，每天光顾着建设连贯了）
什么是信息不对等？它是怎么产生的呢？
信息不对等 说的是，单方对于对方的信息处理能力理解的不统一
对于机器 A 来说，它外部有四个跟报文收发能力无关的标记（我发送胜利了吗，我接管胜利了吗，对方发送胜利了吗，对方接管胜利了吗）
那么对于机器 B 来说，也应有这四个标记
当初假如只有两次握手，那么当两次握手实现后，机器 A 的四个标记是都确认胜利了，然而机器 B 心里却会有个两个疑难？？？
疑难 1：我发送胜利了吗？
疑难 2：对方接管胜利了吗？
这时就会产生信息的不对等。
就好比两个人用对讲机交换，我听到你的讲话了，我也回应了，然而你忽然不理我了。那我就对本人的表达能力产生疑难了。。。
上面这个表格很形象的阐明了 两次握手导致信息不对等的问题
什么是脏连贯？它又是怎么产生的呢？
理解脏读之前要先明确一个知识点，就是报文存活的工夫 > 申请连贯的超时工夫（个别状况下）
当初假如咱们用的是两次握手，那么 脏连贯 就是 机器 A 有一次申请连贯超时，而后申请重连，等到重连胜利后，上一次超时的申请又来，此时这个申请对于机器 B 来说就是脏连贯
上面是产生两次握手产生脏连贯的示意图
从图中能够看到，从新发送的连贯申请，两次握手胜利并断开连接后，之前超时的申请又来了，此时机器 B 发送第二次握手，连贯建设；
然而因为此时客户端的状态是 ESTABLISHED（已建设连贯），而不是 SYN_SENT（同步信号已发送），所以机器 A 不认这个连贯，无奈通信，也就成了脏连贯。
四次挥手
四次挥手就是断开连接的过程，示意图如下所示
这外面波及到几个下面没提到的关键词，上面列出一一阐明下
标记关键词
- FIN（Finish），实现信号，示意通信曾经实现，接下来打算敞开连贯了
状态关键词
- FIN_WAIT_1，发送断开连接后的期待状态阶段 1，示意曾经发送了 FIN 申请，然而对方还没确认
- FIN_WAIT_2，发送断开连接后的期待状态阶段 2，示意对方 ACK 确认了，然而对方还没发送 FIN 申请
- TIME_WAIT，固定工夫期待期，示意对方曾经发送了 FIN 申请 和 ACK 确认信号，我也发送了确认信号 ACK，过一会就能够敞开连贯了
- CLOSE_WAIT，敞开期待期，示意接管到 FIN 申请，并发送了 ACK 确认信号，这边开始筹备断开连接的收尾工作
- LAST_ACK，最初确认，示意曾经发送了 FIN 申请和 ACK 确认信号，期待对方 ACK 确认就能够敞开了
- CLOSED，敞开状态，示意曾经敞开连贯
上面具体说下四次挥手的断开连接过程
- 机器 A 发送 FIN 信号，申请敞开连贯，并附带序列号 seq = u
- 机器 B 收到 FIN 信号，返回 ACK 确认信号，并开始筹备断开连接的收尾工作
- 等到收尾实现，机器 B 再发送 FIN 信号 和 ACK 确认信号，并附带序列号 seq = v, 确认序列号 ack = u + 1
- 机器 A 收到后，进入 TIME_WAIT 期，并发送 ACK 确认信号，附带序列号 seq = u + 1，确认序列号 ack = v + 1
- 机器 B 收到后，敞开连贯
- 机器 A 期待固定工夫（2MSL，上面会介绍这个参数）后，也敞开连贯
为什么握手是三次，挥手却要四次呢？
因为挥手多了一个清理现场的局部，就是发送残余的数据，解决现场，敞开相干资源
其实如果没有什么能够清理的，机器 B 也可能省略这个阶段，而后在收到机器 A 的 FIN 信号时，间接返回 FIN 和 ACK 信号，这样就会变成三次挥手
2MSL 是什么参数？
这个 2MSL 就是报文在网络上的生存时长，意思就是报文如果在网络上存在的工夫超过这个参数，那么报文就会主动抛弃
这个数值如果过大，会造成资源的节约
因为如果数值过大，好多连贯就会卡在 TIME_WAIT 这里，还占着端口，那么这个端口就啥也不干了
所以个别倡议这个数值调小一点（倡议小于 30S），尤其是在服务器端
那 TIME_WAIT 这个阶段能够跳过吗？为什么要在这里期待一段时间呢？
不能够，起因有二
- 有可能机器 A 最初发完 ACK 确认信号后，对方没收到，此时机器 A 如果立马断开连接，就会导致报文失落；
相同的，正因为有了这个阶段，所以当对方没收到 ACK 信号时，对方过段时间会重发 FIN+ACK 信号，此时机器 A 会从新发送 ACK 信号，并从新计时
- 避免生效申请，避免已生效连贯的申请数据包和失常连贯的申请数据包混同而产生异样
已生效的连贯，指的是握手过程中因为某些起因没有胜利，然而也没断开的连贯
当初有了这个 TIME_WAIT 阶段，那么后面已生效的连贯就会因为超时而被抛弃，从而不会烦扰到失常的连贯
总结
以上只是对于 TCP/IP 协定的简略介绍，次要为了小白入门；
想深刻细节的能够参考《TCP/IP 核心技术卷一》和马士兵老师的 B 站视频
参考资料：
- 《码出高效：Java 开发手册》
- 《TCP/IP 核心技术卷一》
- B 站马士兵视频：https://www.bilibili.com/vide…
图片起源：以上所有图片均来自《码出高效 Java 开发手册》
后记
最初，感激大家的观看，谢谢。