前言

大家好啊，我是汤小圆。

明天给大家举荐的经典面试知识点总结，心愿对大家有帮忙，谢谢。

简介

咱们平时常常听到的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地址呢？

起因有两个

  1. IP是会变动的，有可能明天你跟机器A在聊天，今天就变成机器B了，当然会乱掉了
  2. 当初的电脑太多了，数以千万计，从这么多电脑中找出某一个Mac地址，效率很低；然而IP不一样，IP是由网段划分的，有点相似于邮编，这样就能够分段寻址，效率高很多

TCP的三次握手，四次挥手

三次握手

三次握手就是建设连贯的过程，示意图如下所示

咱们来再把流程简化一点，就是：机器A发送连贯申请到机器B -> 机器B收到后，确认并发送同步信号 -> 机器A收到确认信号后，再次发送确认信号到机器B

这外面波及到几个关键词，上面列出一一阐明下

标记关键词

  1. SYN（Synchronize Sequence Numbers），同步信号，示意打算建设连贯时的一个信号
  2. ACK（Acknowledgement），数据确认信号，示意是否确认收到数据

状态关键词

  1. LISTENING，监听状态，示意还没开始建设连贯，正在监听期待连贯的到来
  2. SYN_SENT，SYN已发送，示意SYN曾经发送，然而胜利不胜利还不晓得
  3. SYN_RCVD，SYN已收到，示意收到SYN信号，也曾经给了应答，然而连贯还没建设
  4. ESTABLISHED，连贯建设，示意单方曾经建设了连贯，能够开始互相通信了

上面具体说下三次握手的连贯过程

  1. 机器A发送同步信号SYN=1，申请建设连贯，并附带序列号seq=x （机器A定义）
  2. 机器B收到连贯申请(SYN=1)，返回 同步信号SYN=1 和 数据确认信号ACK=1，并附带序列号 seq = y（机器B本人定义），确认序列号 ack = x + 1（不便机器A校验）
  3. 机器A收到机器B的反馈后，持续发送 确认信号 ACK=1，并附带序列号 seq = x + 1，确认序列号 ack = y + 1
为什么要三次？两次行不行？

两次也能够，就是会呈现脏连贯和信息不对等问题。（开玩笑的，两次当然不行了，呈现这么多问题，大家都不必通信了，每天光顾着建设连贯了）

什么是信息不对等？它是怎么产生的呢？

信息不对等说的是，单方对于对方的信息处理能力理解的不统一

对于机器A来说，它外部有四个跟报文收发能力无关的标记（我发送胜利了吗，我接管胜利了吗，对方发送胜利了吗，对方接管胜利了吗）

那么对于机器B来说，也应有这四个标记

当初假如只有两次握手，那么当两次握手实现后，机器A的四个标记是都确认胜利了，然而机器B心里却会有个两个疑难？？？

疑难1：我发送胜利了吗？

疑难2：对方接管胜利了吗？

这时就会产生信息的不对等。

就好比两个人用对讲机交换，我听到你的讲话了，我也回应了，然而你忽然不理我了。那我就对本人的表达能力产生疑难了。。。

上面这个表格很形象的阐明了 两次握手导致信息不对等的问题

什么是脏连贯？它又是怎么产生的呢？

理解脏读之前要先明确一个知识点，就是报文存活的工夫 > 申请连贯的超时工夫（个别状况下）

当初假如咱们用的是两次握手，那么脏连贯就是机器A有一次申请连贯超时，而后申请重连，等到重连胜利后，上一次超时的申请又来，此时这个申请对于机器B来说就是脏连贯

上面是产生两次握手产生脏连贯的示意图

从图中能够看到，从新发送的连贯申请，两次握手胜利并断开连接后，之前超时的申请又来了，此时机器B发送第二次握手，连贯建设；

然而因为此时客户端的状态是ESTABLISHED（已建设连贯），而不是SYN_SENT（同步信号已发送），所以机器A不认这个连贯，无奈通信，也就成了脏连贯。

四次挥手

四次挥手就是断开连接的过程，示意图如下所示

这外面波及到几个下面没提到的关键词，上面列出一一阐明下

标记关键词

  1. FIN（Finish），实现信号，示意通信曾经实现，接下来打算敞开连贯了

状态关键词

  1. FIN_WAIT_1，发送断开连接后的期待状态阶段1，示意曾经发送了 FIN 申请，然而对方还没确认
  2. FIN_WAIT_2，发送断开连接后的期待状态阶段2，示意对方 ACK 确认了，然而对方还没发送 FIN 申请
  3. TIME_WAIT，固定工夫期待期，示意对方曾经发送了 FIN 申请 和 ACK 确认信号，我也发送了确认信号 ACK ，过一会就能够敞开连贯了
  4. CLOSE_WAIT，敞开期待期，示意接管到 FIN 申请，并发送了 ACK 确认信号，这边开始筹备断开连接的收尾工作
  5. LAST_ACK，最初确认，示意曾经发送了 FIN 申请和 ACK 确认信号，期待对方 ACK 确认就能够敞开了
  6. CLOSED，敞开状态，示意曾经敞开连贯

上面具体说下四次挥手的断开连接过程

  1. 机器A发送 FIN 信号，申请敞开连贯，并附带序列号 seq = u
  2. 机器B收到 FIN 信号，返回 ACK 确认信号，并开始筹备断开连接的收尾工作
  3. 等到收尾实现，机器B再发送 FIN 信号 和 ACK 确认信号，并附带序列号 seq = v, 确认序列号 ack = u + 1
  4. 机器A收到后，进入 TIME_WAIT 期，并发送 ACK 确认信号，附带序列号 seq = u + 1，确认序列号 ack = v + 1
  5. 机器B收到后，敞开连贯
  6. 机器A期待固定工夫（2MSL，上面会介绍这个参数）后，也敞开连贯
为什么握手是三次，挥手却要四次呢？

因为挥手多了一个清理现场的局部，就是发送残余的数据，解决现场，敞开相干资源

其实如果没有什么能够清理的，机器B也可能省略这个阶段，而后在收到机器A的 FIN 信号时，间接返回 FIN 和 ACK 信号，这样就会变成三次挥手

2MSL是什么参数？

这个 2MSL 就是报文在网络上的生存时长，意思就是报文如果在网络上存在的工夫超过这个参数，那么报文就会主动抛弃

这个数值如果过大，会造成资源的节约

因为如果数值过大，好多连贯就会卡在TIME_WAIT这里，还占着端口，那么这个端口就啥也不干了

所以个别倡议这个数值调小一点（倡议小于30S），尤其是在服务器端

那TIME_WAIT 这个阶段能够跳过吗？为什么要在这里期待一段时间呢？

不能够，起因有二

  1. 有可能机器A最初发完 ACK 确认信号后，对方没收到，此时机器A如果立马断开连接，就会导致报文失落；

相同的，正因为有了这个阶段，所以当对方没收到ACK信号时，对方过段时间会重发FIN+ACK信号，此时机器A会从新发送ACK信号，并从新计时

  1. 避免生效申请，避免已生效连贯的申请数据包和失常连贯的申请数据包混同而产生异样

已生效的连贯，指的是握手过程中因为某些起因没有胜利，然而也没断开的连贯

当初有了这个TIME_WAIT阶段，那么后面已生效的连贯就会因为超时而被抛弃，从而不会烦扰到失常的连贯

总结

以上只是对于TCP/IP协定的简略介绍，次要为了小白入门；

想深刻细节的能够参考《TCP/IP 核心技术卷一》和马士兵老师的B站视频

参考资料：

  1. 《码出高效：Java开发手册》
  2. 《TCP/IP 核心技术卷一》
  3. B站马士兵视频：https://www.bilibili.com/vide...

图片起源：以上所有图片均来自《码出高效 Java开发手册》

后记

最初，感激大家的观看，谢谢。