前言
大家好啊，我是汤小圆。
今天给大家推荐的是，TCP/IP协议的经典面试知识点总结，希望对大家有帮助，谢谢。
简介
我们平时经常听到的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的三次握手，四次挥手
三次握手
三次握手就是建立连接的过程，示意图如下所示
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不认这个连接，无法通讯，也就成了脏连接。
四次挥手
四次挥手就是断开连接的过程，示意图如下所示
TCP四次挥手
这里面涉及到几个上面没提到的关键词，下面列出一一说明下
标志关键词
- 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站视频
参考资料：
1. 《码出高效：Java开发手册》
2. 《TCP/IP 核心技术卷一》
3. B站马士兵视频：https://www.bilibili.com/video/BV1mA411q7Ry?p=7</pre>
图片来源：以上所有图片均来自《码出高效 Java开发手册》
后记
最后，感谢大家的观看，谢谢。
网友评论