物理层：主要定义物理设备标准，如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的主要作用是传输比特流（就是由1、0转化为电流强弱来进行传输，到达目的地后再转化为1、0，也就是我们常说的数模转换与模数转换）。这一层的数据叫做比特。
数据链路层：定义数据的基本格式,如何让格式化数据以帧为单位进行传输，以及如何让控制对物理介质的访问。这一层通常还提供错误检测和纠正，以确保数据的可靠传输。如：串口通信中使用到的115200、8、N、1
网络层：定义IP编址，定义路由功能；如位于不同地理位置的网络中的两个主机系统之间提供连接和路径选择。Internet的发展使得从世界各站点访问信息的用户数大大增加，而网络层正是管理这种连接的层。
传输层：定义了一些传输数据的协议和端口号（WWW端口80等），如：TCP（传输控制协议，传输效率低，可靠性强，用于传输可靠性要求高，数据量大的数据），UDP（用户数据报协议，与TCP特性恰恰相反，用于传输可靠性要求不高，数据量小的数据，如QQ聊天数据就是通过这种方式传输的）。主要是将从下层接收的数据进行分段和传输，到达目的地址后再进行重组。常常把这一层数据叫做段。
会话层：控制应用程序之间会话能力；通过传输层 (端口号：传输端口与接收端口) 建立数据传输的通路。主要在你的系统之间发起会话或者接受会话请求（设备之间需要互相认识可以是IP也可以是MAC或者是主机名）。
表示层：可确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。例如，PC程序与另一台计算机进行通信，其中一台计算机使用扩展二一十进制交换码(EBCDIC)，而另一台则使用美国信息交换标准码（ASCII）来表示相同的字符。如有必要，表示层会通过使用一种通格式来实现多种数据格式之间的转换。
应用层：是最靠近用户的OSI层。这一层为用户的应用程序（例如电子邮件、文件传输和终端仿真）提供网络服务。

TCP/IP四层模型

OSI七层协议分别为物理层，数据链路层，网络层，传输层，会话层，表示层，应用层；TCP/IP四层协议分别为网络接口层，网际层IP，运输层，应用层
OSI是一种理论模型，而TCI/IP已经被广泛使用，成为网络互连实际上的标准。

2、TCP协议(顶级重点！！)

2.1 三次握手和四次挥手过程

2.2 描述三次握手的过程

TCP三次握手是建立一个TCP连接时，需要客户端和服务器总共发送3个报文的过程。具体过程如下：

第一次握手：客户端发送一个SYN包（seq=x）到服务器，并进入SYN_SEND状态，等待服务器确认。
第二次握手：服务器收到SYN包后，返回一个SYN+ACK包，其中SYN和ACK标志位都被设置为，表示确认客户端的SYN有效并同意建立新连接。同时，服务器生成一个序列号（seq=y），并将确认号（ack）设置为x+1。
第三次握手：客户端收到SYN+ACK包后，向服务器发送一个ACK包（ack=y+1），此时客户端和服务器都进入ESTABLISHED状态，完成三次握手，可以开始传输数据。

这个过程的目的是同步双方的序列号和确认号，以及交换TCP窗口大小信息。这样，客户端和服务器就可以确保数据能够正确、有序地在两者之间传输

2.3 描述四次挥手的过程

TCP四次挥手是断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。具体过程如下：

第一次挥手：客户端向服务器发送一个FIN包（FIN=1，seq=u），主动断开连接，报文中会指定一个序列号。此时客户端进入FIN_WAIT1状态。
第二次挥手：服务器收到FIN包后，向客户端发送确认包（ACK=1, ack=u+1），确认收到了客户端的断开连接请求，此时服务器进入CLOSE_WAIT状态。
第三次挥手：服务器向客户端发送一个FIN包（FIN=1，seq=v），请求断开连接。同时，服务器将确认号（ack）设置为u+1，此时服务器进入LAST_ACK状态。
第四次挥手：客户端收到FIN包后，向服务器发送一个ACK包（ACK=1，ack=v+1），确认收到了服务器的断开连接请求，此时客户端进入TIME_WAIT状态。等待一段时间后，如果没有收到服务器的再次请求，客户端进入CLOSED状态，完成四次挥手。

2.4 为什么需要三次握手，两次不行吗？

TCP之所以需要三次握手，主要有以下几个原因：

防止历史连接的初始化：三次握手可以防止旧的重复连接初始化造成混乱。例如，如果客户端的SYN请求连接在网络中阻塞，客户端没有接收到ACK报文，就会重新发送SYN。由于没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的ACK确认信号，所以每收到一个SYN就只能先主动建立一个连接。这可能会导致服务器建立多个冗余的无效链接，造成不必要的资源开销。
同步双方初始序列号：TCP协议的通信双方，都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤。如果只是两次握手，至多只有连接发起方的起始序列号能被确认，另一方选择的序列号则得不到确认。
避免资源浪费：如果只有两次握手，当客户端的SYN请求连接在网络中阻塞，客户端没有接收到ACK报文，就会重新发送SYN。由于没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的ACK确认信号，所以每收到一个SYN就只能先主动建立一个连接。这可能会导致服务器建立多个冗余的无效链接，造成不必要的资源开销。

因此，TCP采用三次握手的原因其实非常简单，远没有大部分博客所描述的那样云山雾绕。这里先给出结论：为了实现可靠数据传输，TCP协议的通信双方，都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤。

2.5 三次握手过程中可以携带数据吗？

在TCP三次握手过程中，第三次握手是可以携带数据的。这是因为在第三次握手时，客户端已经处于ESTABLISHED状态，已经确认了服务器的接收、发送能力是正常的，所以可以携带数据。然而，第一次和第二次握手不可以携带数据。这是为了防止在第一次握手中的SYN报文中放大量的数据，造成服务器消耗大量的时间和内存空间，从而增大服务器受到攻击的风险。这些规定都是为了确保TCP连接的安全和效率。

2.6 SYN攻击是什么(这个文章讲个的仔细)

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。

检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。在 Linux/Unix 上可以使用系统自带的 netstats 命令来检测 SYN 攻击。

2.7 如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

2.8 为什么握手需要三次，挥手为什么需要四次？

因为服务端在收到客户端的FIN报文，即客户端请求断开连接后，可能还有数据需要发送。所以服务端需要先发送ACK报文同意客户端的断开请求，然后等待所有数据发送完毕后再发送FIN报文请求断开连接。这样就保证了在断开连接前，所有的数据都能被正确且完整地传输。

2.9 2MSL等待状态是什么？

MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

在TCP四次挥手过程中，主动关闭连接的一方在发送完最后一个ACK报文后会进入一个叫做TIME_WAIT的状态，这个状态会持续2MSL（Maximum Segment Lifetime，报文最大生存时间）。

这个2MSL等待状态有两个主要目的：

优雅地关闭TCP连接：确保被动关闭的一方收到它自己发出去的FIN报文的ACK确认报文。
处理延迟的重复报文：避免前后两个使用相同四元组的连接中的前一个连接的报文干扰后一个连接。

这个2MSL的时间是从客户端接收到FIN后发送ACK开始计时的。如果在TIME-WAIT时间内，因为客户端的ACK没有传输到服务端，客户端又接收到了服务端重发的FIN报文，那么2MSL时间将重新计时。

这2个MSL中的第一个MSL是为了等自己发出去的最后一个ACK从网络中消失，而第二MSL是为了等在对端收到ACK之前的一刹那可能重传的FIN报文从网络中消失。这样就可以确保当我们成功建立一个新的TCP连接时，所有旧的重复报文从前一个连接已经在网络中过期。

2.10 TCP 协议如何保证可靠传输？

TCP协议通过以下几种机制来保证数据的可靠传输：

检验和：通过检验和的方式，接收端可以检测出来数据是否有差错和异常，假如有差错就会直接丢弃TCP段，重新发送。
序列号/确认应答：发送端发送信息给接收端，接收端会回应一个包，这个包就是应答包。只要发送端有一个包传输，接收端没有回应确认包（ACK包），都会重发。或者接收端的应答包，发送端没有收到也会重发数据。这就可以保证数据的完整性。
超时重传：如果发送一直收不到应答，可能是发送数据丢失，也可能是应答丢失，发送方再等待一段时间之后都会进行重传。
最大消息长度：在建立TCP连接的时候，双方约定一个最大的长度（MSS）作为发送的单位，重传的时候也是以这个单位来进行重传。
滑动窗口控制：发送端在无需等待确认包的情况下，还能发送的最大数据量。这个机制的实现就是使用了大量的缓冲区，通过对多个段进行确认应答的功能。
拥塞控制：网络层拥堵造成的拥塞，包括慢启动，拥塞避免，快速重传三种机制。

2.11 什么是TCP粘包/拆包？发生的原因？

TCP粘包和拆包是网络编程中常见的问题，主要发生在基于TCP协议的通信中。

粘包是指发送方发送的若干包数据到达接收方时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。这是因为TCP协议是基于字节流的，它不包含消息、数据包等概念，需要应用层协议自己设计消息边界。如果待发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据包合并为一次发送，就会发生粘包。
拆包是指要发送的数据大于TCP发送缓冲区剩余空间大小或者待发送数据大于MSS（TCP报文长度 - TCP头部长度 > MSS最大报文长度），TCP在传输前将根据MSS大小进行拆包分段发送。

解决粘包/拆包问题的关键在于如何给每个数据包添加边界信息用于区分不同数据包。常见的解决方案有：

发送端将每个包都封装成固定的长度，比如100字节大小。如果不足100字节可通过补0或空等进行填充到指定长度。
发送端在每个包的末尾使用固定的分隔符，例如\r\n。如果发生拆包需等待多个包发送过来之后再找到其中的\r\n进行合并
将消息分为头部和消息体，头部中保存整个消息的长度，只有读取到足够长度的消息之后才算是读到了一个完整的消息。

2.12 粘包发生的原因有哪些？

网络延迟：由于网络延迟，数据包可能会在传输过程中被粘在一起。
网络拥塞：当网络拥塞时，数据包可能会被卡在发送方和接收方之间，无法正确地被接收方解析。
数据包大小：如果数据包过大，它们可能会在传输过程中被粘在一起。

2.13 为什么UDP没有粘包？

UDP协议不会出现粘包问题，主要有以下几个原因：

面向消息：UDP是面向消息的协议，每个UDP段都是一条消息，应用程序必须以消息为单位提取数据，不能一次提取任意字节的数据。这与TCP协议不同，TCP协议是面向流的，应用程序所看到的数据是一个整体，或说是一个流（stream），一条消息有多少字节对应用程序是不可见的。
消息边界：UDP具有保护消息边界，在每个UDP包中就有了消息头（消息来源地址，端口等信息），这样对于接收端来说就容易进行区分处理了。
无Nagle算法：UDP发送的时候，没有经过Nagle算法优化，不会将多个小包合并一次发送出去。Nagle算法是TCP协议中的一种优化算法，它会将多次间隔较小且数据量小的数据，合并成一个大的数据块，然后进行封包。

2.14 常见TCP的连接状态有哪些？

TCP协议中常见的连接状态有以下几种：

CLOSED：初始状态，表示没有任何连接状态。
LISTEN：服务器处于监听状态，可以接受客户端的连接。
SYN-SENT：客户端发送连接请求后等待匹配的连接请求。
SYN-RECEIVED：服务器在收到和发送一个连接请求后等待对方对连接请求的确认。
ESTABLISHED：代表一个打开的连接，数据可以传送给用户。
FIN-WAIT-1：等待远程TCP连接中断请求，或先前的连接中断请求的确认。
FIN-WAIT-2：从远程TCP等待连接中断请求。
CLOSE-WAIT：等待从本地用户发来的连接中断请求。
CLOSING：等待远程TCP对连接中断的确认。
LAST-ACK：等待原来发向远程TCP的连接中断请求的确认。
TIME-WAIT：等待足够的时间以确保远程TCP接收到连接中断请求的确认。

2.15 流量控制原理了解吗？

流量控制是网络通信中的一种重要机制，它的主要目的是防止发送方发送数据过快，导致接收方处理不过来，从而避免数据包的丢失。以下是流量控制的一些主要原理和方法：

滑动窗口：TCP协议中的滑动窗口机制是实现流量控制的一种重要方法。发送方和接收方各自维护一个窗口，窗口的大小表示了对方还能接收的数据量。发送方根据接收方的窗口大小来控制发送的数据量，从而避免接收方的缓冲区溢出。
接收方通知窗口大小：在TCP首部中，有一个字段用于通知窗口大小，接收方将自己可以接收的缓冲区大小放在该字段中通知发送方。当接收方的缓冲区面临数据溢出时，窗口大小的值也会随之改变，设置为一个更小的值通知发送方，从而控制数据的发送量。
限流：在某些情况下，例如微服务架构中，可能需要对某个服务的流量进行限制。这通常通过一些限流算法来实现，例如计数器、滑动窗口、漏桶、令牌桶等。这些算法可以精确地控制在单位时间内的处理量，从而保证系统不被冲垮，同时尽可能提升系统的吞吐量。

3、UDP协议(同样重要)

3.1 TCP和UDP的区别？

TCP（Transmission Control Protocol，传输控制协议）和UDP（User Datagram Protocol，用户数据报协议）是两种常见的传输层协议，它们在数据传输方式、可靠性、连接性等方面有着显著的区别：

连接性：TCP是面向连接的协议，数据传输前需要与对方建立连接。而UDP是无连接的协议，发送数据前不需要建立连接。
可靠性：TCP提供可靠的数据传输，能保证数据无差错、不丢失、不重复、且按序到达。而UDP尽最大努力交付，不保证可靠交付。
传输方式：TCP是面向字节流的，数据传输时没有明显的边界。而UDP是面向报文的，每个UDP包都是独立的，具有明显的边界。
服务对象：TCP是一对一的服务，而UDP支持一对一、一对多、多对一、多对多的交互通信。
首部开销：TCP的首部长度较长，至少20字节，而UDP的首部固定为8字节。
拥塞控制：TCP有拥塞控制机制，可以防止数据传输过快导致网络拥塞。而UDP没有拥塞控制，即使网络非常拥堵，也不会影响UDP的发送速率。
系统资源需求：TCP需要更多的系统资源，而UDP较少。

这些区别使得TCP和UDP各自适用于不同的网络环境和应用场景。例如，TCP常用于需要高可靠性的应用，如Web服务器、邮件服务器等。而UDP常用于对实时性要求较高的应用，如视频会议、网络游戏等。

3.2 UDP的特点有哪些？

UDP（User Datagram Protocol，用户数据报协议）是一种常见的传输层协议，它的主要特点包括：

无连接：UDP是无连接的协议，即在数据传输时，发送端和接收端不需要建立连接。
尽最大努力交付：UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态。
面向报文：UDP是面向报文的协议，每个UDP包都是独立的，具有明显的边界。
无拥塞控制：UDP没有拥塞控制，即使网络非常拥堵，也不会影响UDP的发送速率。
支持多种交互通信：UDP支持一对一、一对多、多对一和多对多的交互通信。
首部开销小：UDP的首部固定为8字节，相比于TCP的20字节的首部要短。
高效性：由于UDP没有TCP的连接建立和断开的开销，传输速度较快。

4、HTTP（超文本传输）协议

4.1 完整的HTTP请求过程包括哪些内容？

一次完整的HTTP请求过程包括以下几个步骤：

DNS解析：浏览器首先会进行DNS解析，获取服务器的IP地址。
TCP三次握手：浏览器与服务器建立TCP连接，进行三次握手。三次握手的目的是同步连接双方的序列号和确认号并交换TCP窗口大小信息。
发起HTTP请求：建立TCP连接后，浏览器会向服务器发起HTTP请求。一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成。
服务器响应HTTP请求：服务器接收到HTTP请求后，会返回一个响应，该响应包含状态行、响应头部、空行以及响应数据。
浏览器解析HTML代码：浏览器接收到服务器返回的HTML代码后，开始解析代码，并请求HTML代码中的资源（如js、css、图片等）。
浏览器进行页面渲染：浏览器解析完HTML代码和相关资源后，会对页面进行渲染，呈现给用户。
服务器关闭TCP连接：最后，服务器会关闭TCP连接。

4.2 HTTP请求方法POST和GET区别是什么？

HTTP请求方法中的GET和POST有以下几个主要区别：

数据传输方式：GET方法将请求的数据显示在URL中，而POST方法通过HTTP消息主体传递数据。
数据安全性：POST方法比GET方法更安全，因为数据不会保存在浏览器历史或Web服务器日志中。GET方法将请求的数据作为URL的一部分，可能会被第三方看到。
数据大小：GET方法受URL长度限制，而POST方法可以传输大量数据。
数据类型：GET方法只允许ASCII字符，而POST方法没有限制，也允许二进制数据。
缓存：GET请求可以被缓存，而POST请求不会被缓存。
历史记录：GET请求保留在浏览器历史记录中，而POST请求不会保留在浏览器历史记录中。
书签：GET请求可以被收藏为书签，而POST请求不能被收藏为书签。
服务器影响：GET方法只是获取信息，不会修改信息，而POST方法可能会修改服务器上的资源。

4.3 POST 方法比 GET 方法安全？

从某种程度上来说，POST方法比GET方法更安全。这是因为：

数据暴露：GET方法将请求的数据显示在URL中，而POST方法通过HTTP消息主体传递数据。因此，使用GET方法的请求，数据会被保存在浏览器历史或Web服务器日志中，可能会被第三方看到。
数据类型和大小：GET方法只允许ASCII字符，而POST方法没有限制，也允许二进制数据。此外，GET方法受URL长度限制，而POST方法可以传输大量数据。

需要注意的是，虽然POST方法在这些方面比GET方法更安全，但这并不意味着POST方法是完全安全的。无论使用哪种方法，都需要采取适当的安全措施，如使用HTTPS来加密数据，防止数据在传输过程中被窃取或篡改。

4.4 HTTPS和HTTP的区别

HTTP和HTTPS的主要区别如下：

协议安全性：HTTP是超文本传输协议，信息是明文传输，存在安全风险。HTTPS则是具有安全性的SSL/TLS加密传输协议，信息传输过程是加密的，提供了对网站服务器的身份认证，保护交换数据的隐私与完整性。
证书：HTTPS协议需要到CA（Certificate Authority，数字证书认证机构）申请证书，一般免费证书较少，因而需要一定费用。
连接方式和端口：HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，HTTP是80，HTTPS是443。
性能：由于HTTPS需要进行加密和解密操作，因此会消耗更多的CPU和内存资源，相比HTTP，HTTPS的连接速度会稍慢一些。

4.5 HTTPS是如何保证数据传输的安全?

HTTPS通过以下几种方式来保证数据传输的安全：

SSL/TLS协议：HTTPS是在HTTP上建立SSL加密层，并对传输数据进行加密，是HTTP协议的安全版。SSL（Secure Sockets Layer）译为「安全套接字协议」，TLS（Transport Layer Security）译为「传输层安全性协议」。SSL/TLS协议处于「传输层」和「应用层」之间，主要作用是对网络连接进行加解密。

对称加密：HTTPS使用对称加密算法提供高效的数据加密传输。对称加密即使用同一个密钥对数据进行加密解密，算法速度快，常用来加密大量内容。

非对称加密：非对称加密即：解密和加密用不同的密钥。使用非对称加密时用户拥有两个密钥：公开密钥（publickey:简称公钥）和私有密钥（privatekey:简称私钥）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密。

数字证书与认证中心：HTTPS使用数字证书和认证中心来保证公钥的传输安全。一个证书上包含一些公开的明文信息以及证书颁发者对该信息的签名（私钥加密）。任何人想验证证书信息的真伪，只需要证书颁发者的公钥对签名进行解密，在和证书上的明文信息做对比即可。

消息认证码：消息认证码是带密钥的散列函数，它具备以下特点：大量信息经过处理变成短小固定长度值；消息不同或者密钥不同会导致结果不同；无法从结果“解密”解密出原始信息。

#C++##网络编程##校招##八股##嵌入式#

嵌入式软件校招笔记文章被收录于专栏

记录本人校招过程中遇到的问题及笔记整理！后续会持续更新