2024年物联网嵌入式最新网络原理(小结)_网络的原理是什么(1)，2024年最新阿里P7手把手教你

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上物联网嵌入式知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、电子书籍、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

Session和Cookie

Session是指Web系统的会话，指用户登录以后，在退出之前都是一个会话

Session的作用：用户登录时，服务端保存用户身份信息(Map<value,session>)，在之后访问的敏感资源的时候，通过请求key = value，服务端通过key对应到value，然后在map中获取到用户的身份信息

Cookie实际上就是一小段文本信息，原理是：客户端本地保存用户的身份信息，然后每次发送HTTP请求时携带该Cookie，用于登录验证
使用场景：登录页面 多少天内免登录 和 记住密码等

• Cookie
  HTTP协议是无状态协议，一旦数据交换结束，客户端和服务器的连接就会关闭，HTTP协议对之前处理的事务没有记忆，但访问有些资源时又需要认证用户才能访问，这个过程要一直保持在线状态，而cookie就是一种在浏览器端解决的方案，将登陆认证之后的用户信息保存在本地浏览器中，后面每次发起http请求，都自动携带上该信息，就能达到认证用户，保持用户在线的作用

Cookie本质就是一小段文本信息，客户端请求服务器的时候，如果服务器需要记录该用户，就用response向客户端颁发一个Cookie。客户端会把Cookie保存起来，当再次访问请求这个服务器时，客户端就会把Cookie与URI一起发送给服务器，服务器检查Cookie，以此辨别用户

• Session

Session是服务器使用的一种记录客户端状态的机制，在客户端访问服务器的时候，服务器会开辟一块内存空间，把客户端信息以某种形式(Session对象)记录在服务器上使用，存储结构ConcurrentHashMap，再次访问的时候只需要从该Session中查找用户信息就行

Session实现登录：用户登录时，服务器保存用户的身份信息(Map<value,session>)，在之后访问敏感资源时，通过请求 key
= value，服务端通过key对应到value，然后在map中获取用户信息

• Session与Cookie的联合使用
  服务器第一次收到请求后，开辟一块Session空间(创建Session对象)，同时生成一个Session id，并通过Set-Cookie中的JSESSIONID=xxxxxxx命令，向客户端响应含SessionID的Cookie，客户端收到响应后将其保存到本地，接下来每次想服务器发送请求时，请求头中都会携带Cookie信息，服务器接收到Cookie后解析获取到JSESSIONID的值，得到本次请求的Session id，以此达到认证身份的效果
  

HTTP协议的特点

1. 支持服务器/客户端模式
2. 传输较快速，客户端向服务器发送请求，只需要传输请求方法和路径
3. 灵活，HTTP允许传输任意类型的数据对象
4. 无连接，每次连接只能处理一个请求，服务器处理完客户端请求，客户端收到响应后就断开了连接
5. 无状态，协议本身对事务处理没有记忆能力，如果后序连接需要之前发送的信息时就需要重传

HTTPS

• HTTP协议运行在TCP上，使用明文传输，很容易被窃听或侦听，安全性很差
• 而HTTPS协议在HTTP的基础上加了一个SSL的外壳，运行于SSL上，SSL运行于TCP上，信息的加密过程就是在SSL中完成的

HTTPS很大程度上改善了HTTP协议不安全的问题，其保证安全性的方法是传输时通过证书、混合加密等方法来保证安全

• 对内容采用混合加密方法，不在对数据明文传输
• 传输时通过证书来认证对方身份

混合加密技术：使用对称加密与非对称加密技术，
1、服务端先生成私钥然后通过私钥再生成公钥，将公钥放在证书中颁发给客户端
2、使用公钥和私钥以非对称方式生成秘钥
3、客户端使用对称加密，用秘钥对传输数据进行加密
所以网络上传输的数据是被秘钥加密的密文和用公钥加密后的秘钥，以此来保证安全性

HTTPS会先使用公钥和私钥以非对称加密方式生成秘钥，再通过秘钥以对称加密 加密数据进行传输

HTTP与HTTPS的区别

• HTTP是以http://开头的；而HTTPS是以https://开头的
• HTTP是不安全的，信息是明文传输的；HTTPS是安全的，具有安全性的SSL加密传输
• HTTP标准端口为80；HTTPS标准端口为443
• 在OSI模型中，HTTP工作在应用层，HTTPS工作在传输层
• HTTP无需加密，无需证书；HTTPS会先使用公钥和私钥以非对称加密方式生成秘钥，在用秘钥以对称加密方式加密传输数据，也需要证书，这就意味着会消耗更多的CPU资源

传输层

网络传输的五元组

源IP —— 源端口号 —— 目的IP —— 目标端口号 —— 协议号

端口号

端口号标识了一个主机上进行通信的不同应用程序

网络传输时，知道发送端的IP地址后，还需要知道具体由哪个端口(哪个应用程序)发出
接受时同样，通过目的 IP 将数据发送到指定的主机上后，需要在通过指定的目的端口号发送到该主机指定的应用上，最终才算数据传输完成

在TCP/IP协议中, 用 “源IP”, “源端口号”, “目的IP”, “目的端口号”, “协议号” 这样一个五元组来标识一个通信

使用命令查看某个端口
Windows中：netstat - ano | findstr “查看的端口号”
Linux中：netstat - anp | grep “查看的端口号”

传输层中最常见的协议为UDP/TCP协议

UDP协议

特点：

• 无连接：知道对应的IP和端口号就可以直接传输数据，无需建立连接
• 不可靠：没有TCP的确认应答，超时重传等机制，UDP无法得知数据传输是否成功
• 面向数据报发送：应用层交给UDP多长的数据报文，UDP就原样发送，即不会拆分也不会合并，不够灵活
• UDP一次能够传输数据最大长度有限制，不能超过64k

TCP协议

为了解决UDP以上的缺点，因此引入一个更加完善的TCP协议

• 源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去
• 4位TCP报头长度: 表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP头部最大长度是15 * 4 = 60
• 6位标志位:
  URG：紧急指针是否有效
  ACK：确认号是否有效
  PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走
  RST：对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
  SYN：请求建立连接; 我们把携带SYN标识的称为同步报文段
  FIN：通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段
• 16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分

TCP如何保证数据传输的可靠性

• 通过协议中的校验和序列号
• 确认应答机制：发送数据报携带序号，响应的数据报携带确认序列号，发送端通过响应回的序列号就能得知，上一次数据报是否成功发送
• 超时重传机制：如果主机A在一定时间内(单次传输的最大时间*2)，没有收到主机B发来的确认数据报，就会触发超时重传，重新发送数据报
• 连接管理机制：正常情况下，TCP经过三次握手才能建立连接，建立连接后才能发送数据，通过四次挥手才能断开连接
• 流量控制：数据的发送较数据的接收来说非常快，当数据过多，接收端缓存区已满时，就会产生丢包，因此接收端在每次确定应答时，会将自己缓冲区的接收能力放在"窗口大小"中，由发送端控制发送数据的速度
• 阻塞控制：发送端在首次不清楚网络情况等影响数据接收速度时，不会之间将一个很大的数据发给接收端，而是先发送一小块数据，通过响应回的ACK确定传输情况，再决定传输的速度

TCP如何提高数据传输的性能

• 滑动窗口：上面说确认应答时讲到，每一个发送的数据报，都要响应回一个ACK确认应答，发送端收到后再发送下一个数据报，这种机制性能就会很差，而滑动窗口就是无需等待应答可以一次发送多条数据

接收端响应 ：响应回ACK的下一个序号是多少，取决于成功接收到的连续数据报的最大序号，也决定了发送端下次数据报要发送的内容，正因为这种确认应答机制，保证了多条数据传输时的安全性
发送端 ：滑动窗口下滑传输下一份数据的依赖条件是接收到的ACK数据报，ACK数据报中下一个序号的最大值作为下一个窗口的起始位置
滑动窗口也是一种实现流量控制的机制 ：滑动窗口的大小(即每次发送数据的多少)由接收端的缓冲区决定，由此实现流量控制

• 延迟应答：接收端收到数据报后，不用马上返回ACK，而是等待一段时间，让进程有一段时间可以处理缓冲区中的数据，如此一来，响应回的ACK数据报中窗口大小就可以设置更大，从而通过流量控制让发送端的滑动窗口大小设置的更大
• 捎带应答：有些数据报是可以合并的，如响应返回ACK时可以将要发送的数据报，多次网络传输数据合并在一起发送，从而提高效率

详解三次握手和四次挥手

三次握手

1. 主机A发送SYN到主机B，请求建立A和B的连接，主机A状态设为syn_sent
2. 主机B回复ACK+SYN，响应A的数据报 以及 qinq请求建立B到A的连接，主机B的状态设为syn_rcvd
3. 主机A回复ACK，主机A状态设为established，建立A到B的连接
   主机B收到主机A回复的ACK，主机B状态设为established，建立B到A的连接

为什么SYN要发送两次？
=> 因为连接是有方向的，需要双方都建立连接

为什么第二步主机B发送数据报时，可以发送ACK+SYN？
=> 本质上时发送两次数据报，但因为发送方向相同且合并无影响，所以可以合并

四次挥手：

1. 主机A发送FIN到主机B，请求关闭A到B的连接
2. 主机B回复ACK，主机B状态设置为close_wait
3. 主机B发送FIN到主机A，请求关闭B到A的连接
4. 主机A回复ACK(B向A发送的断开请求)，状态设置为time_wait
   主机B接收A发送的ACK，状态设置为closed
   主机A经过2msl(最长传输时间，超时重传机制)后，状态设为closed

为什么挥手阶段，主机B发送数据报不能合并？
=> 因为第二步回复ACK是TCP在系统内核实现的，自动响应ACK，第三步请求关闭连接是应用程序手动，调用close发送数据报，故两个数据报不能合并
=> TCP这么实现的原因是因为，在程序关闭之前，有时还需要进行释放资源等前置操作，所以不能直接合并发送立即关闭连接

为什么主机A在收到B响应回的数据报后，没有立即关闭？
=> 因为在第三步主机A接收到B的响应后，主机A还需要响应B发送的SYN，而如果A发送完响应直接关闭，第四步的响应如果出现丢包，此时A将无法再次重传

当服务器出现大量close_wait状态，可能是什么原因？
=> 可能是四次挥手阶段出现问题，服务器无法正常关闭连接，检查程序的close方法是否被正常调用

详谈阻塞控制

发送端在不清楚网络状况下，不会贸然的发送大量数据给接收端，因为这有可能导致网络阻塞，TCP引出了慢启动等机制来处理这种情况：

• 慢启动：一开始只发送少量数据，用于检测此时的网络情况，然后逐渐增大每次传输的数据，期初以指数增长
• 阻塞避免：当阻塞窗口达到慢启动的阈值时，传输数据的大小不再时指数增加，而换成线性增加，直到达到窗口最大值触发网络阻塞
• 在每次超时重传后, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1

当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降
拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案

TCP的粘包问题

基于传输层TCP来实现应用层协议时，因为TCP传输数据都是字节流，读取时需要考虑格式，以及读取的长度，如果长度没有设置好，可能造成粘包问题，原本下一个的数据，被其他地方读取到

解决办法：明确到每个包之间的边界

TCP的长连接与短连接

HTTP的长连接与短连接实质上就是TCP的长连接与短连接

• HTTP/1.0中默认使用短连接：客户端与服务器每进行一次HTTP操作，就建立一个连接，结束后连接断开
• HTTP/1.1起默认使用长连接：就是当一个网页打开以后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，当客户端再次发送HTTP请求时，会继续使用这一条已经建立的连接，长连接也不能永久保持连接，他有一个保持时间
• 在使用长连接时，会在响应头加入 Connection:keep-alive

TCP与UDP的区别？

• TCP有连接，UDP无连接
• TCP传输信息较为可靠，UDP不可靠
• TCP支持一对一通信；UDP支持一对一、一对多、多对一、多对多通信
• TCP面向字节流；UDP是面数据包的
• TCP首部开销大，20个字节，UDP只有8个字节
• TCP可以保证传输的数据顺序，UDP不能

UDP如何实现可靠？

UDP实现可靠就需要解决两个最基本的问题：丢包和包的顺序，这两个可以在应用层实现

1、给数据包进行编号，按照包的顺序进行接收并存储
2、仿照TCP的确认应答机制，在接收端接收到数据包后，向发送端发送确认信息，当发送端收到确认信息后继续发送下一个数据包，否则重传

在浏览器地址输入URL后，按下回车会发生什么？

1. 浏览器向DNS服务器请求解释URL中的域名和对应IP
2. 根据 IP 和 端口号 ，向服务器发起请求建立TCP连接，发起三次握手

客户端向服务器发送SYN数据报，请求建立连接
服务端接收到后，向客户单发送ACK+SYN数据报
客户端接收到后，向服务端响应ACK数据报
连接连接

3. 连接建立后，浏览器向服务器发送HTTP请求
4. 服务器解析请求并作出响应，将对应的响应返回给浏览器
5. 完成通信后，发起四次挥手，释放TCP连接

客户端向服务端发送FIN数据报，请求关闭连接
服务端向客户端响应ACK
服务端向客户端发送FIN数据报，请求关闭连接
客户端向服务端响应ACK
连接关闭

收集整理了一份《2024年最新物联网嵌入式全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升的朋友。

如果你需要这些资料，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人

都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

端发送FIN数据报，请求关闭连接

客户端向服务端响应ACK
连接关闭

收集整理了一份《2024年最新物联网嵌入式全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升的朋友。
[外链图片转存中…(img-0K1QLZ6t-1715665306946)]
[外链图片转存中…(img-TQzpadmS-1715665306947)]

如果你需要这些资料，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人

都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！