【嵌入式八股】一、语言篇https://www.nowcoder.com/creation/manager/columnDetail/mwQPeM   【嵌入式八股】二、计算机基础篇（本专栏）https://www.nowcoder.com/creation/manager/columnDetail/Mg5Lym   【嵌入式八股】三、硬件篇https://www.nowcoder.com/creation/manager/columnDetail/MRVDlM   【嵌入式八股】四、嵌入式Linux篇https://www.nowcoder.com/creation/manager/columnDetail/MQ2bb0   传输层TCP/UDP   TCP三次握手四次挥手   66.TCP头部中有哪些信息？   TCP数据报格式（左图） UDP数据报格式也放这（右图），不具体解释了。    结合三次握手四次挥手来看        端口：           区分应用层的不同应用进程      扩展：应用程序的端口号和应用程序所在主机的 IP 地址统称为 socket（套接字），IP:端口号, 在互联网上 socket 唯一标识每一个应用程序，源端口+源IP+目的端口+目的IP称为”套接字对“，一对套接字就是一个连接，一个客户端与服务器之间的连接。           序号seq（32bit）：           传输方向上字节流的字节编号。用于 TCP 通信过程中某一传输方向上字节流的每个字节的编号，为了确保数据通信的有序性，避免网络中乱序的问题。接收端根据这个编号进行确认，保证分割的数据段在原始数据包的位置。初始时序号会被设置一个随机的初始值（ISN），之后每次发送数据时，序号值 = ISN + 数据在整个字节流中的偏移。假设A -> B且ISN = 1024，第一段数据512字节已经到B，则第二段数据发送时序号为1024 + 512。          确认序号ack（32bit）：           确认序列号是接收确认端所期望收到的下一序列号。确认序号应当是上次已成功收到数据字节序号seq加1，只有当标志位中的 ACK 标志为 1 时该确认序列号的字段才有效。主要用来解决不丢包的问题。          首部长（4bit）：           标识首部有多少个4字节 * 首部长，最大为15，即60字节。          标志位（6bit）：                  URG：(urgent紧急) 标志紧急指针是否有效。       ACK：(acknowledgement 确认)标志确认号是否有效（确认报文段）。用于解决丢包问题。       PSH：(push传送) 提示接收端立即从缓冲读走数据。       RST：(reset重置) 表示要求对方重新建立连接（复位报文段）。       SYN：(synchronous同步) 表示请求建立一个连接（连接报文段）。       FIN：(finish结束) 表示关闭连接（断开报文段）。                窗口（16bit）：           接收窗口,滑动窗口大小。用于告知对方（发送方）本方的缓冲还能接收多少字节数据。用于解决流控。          校验和（16bit）：           接收端用CRC检验整个报文段有无损坏。          紧急指针（16bit）:           紧急指针表示紧急数据的末尾位置，用于标识紧急数据的范围。           67.端口有效范围是多少到多少？   端口号的有效范围是从0到65535，其中0被保留，不能用于应用程序端口号。其中，0到1023是系统保留端口，一些常用的端口号也被规定为某些服务的默认端口号。例如，HTTP的默认端口号是80，HTTPS的默认端口号是443，SSH的默认端口号是22等。   1024到49151是注册端口范围，一些应用程序可以使用这些端口号，但并没有被正式分配给任何特定的服务。这些端口号通常被用于客户端程序和服务端程序之间的通信。   49152到65535是动态或私有端口范围，这些端口号可以由应用程序动态分配和使用，但不会被分配给任何特定的服务。这些端口号通常被用于客户端程序和服务端程序之间的通信。   68.一台机器能够使用的端口号上限是否可以修改？如果想要用的端口超过这个限制怎么办？   大多数操作系统默认允许使用的动态端口数量为几千个，但是可以通过修改系统内核参数来增加这个数量。不过，修改这些参数需要管理员权限和谨慎操作，否则可能会导致系统出现问题或安全漏洞。   如果需要使用的端口超过了机器的限制，一种常见的做法是使用负载均衡器或代理服务器。可以将请求发送到负载均衡器或代理服务器，再由它们转发到实际的服务端口，从而实现同时支持多个服务。   69.简述一下TCP建立连接和断开连接的过程。   三次握手   TCP建立连接过程（三次握手）：        客户端向服务端发送SYN包（SYN=1，ACK=0），表示请求建立连接，并指定客户端的初始序列号seq=x。客户端进入 SYN_SENT状态，等待Server确认。     服务端收到客户端的SYN=1知道Client请求建立连接，向客户端发送SYN/ACK包（SYN=1，ACK=1），表示同意建立连接，并指定服务端的初始序列号seq=y，同时确认客户端的序列号ack=x+1。服务端进入 SYN_RCVD状态。     客户端收到服务端的SYN/ACK包后，检查ack是否为x+1，ACK是否为1，如果正确则向服务端发送ACK包（SYN=0，ACK=1），确认建立连接，并指定确认序列号ack=y+1。服务端检查ack是否为y+1，ACK是否为1，如果正确则连接建立成功，客户端和服务端进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。      四次挥手   TCP断开连接过程（四次挥手）：        客户端向服务端发送FIN包（FIN=1，ACK=1），表示请求断开连接，并指定序列号seq=x。客户端进入 FIN_WAIT_1状态，此时客户端依然可以接收服务器发送来的数据。     服务端收到客户端的FIN包后，向客户端发送ACK包（ACK=1），确认接收到了断开连接请求，并指定确认序列号ack=x+1。服务器进入CLOSE_WAIT 状态。客户端收到后进入FIN_WAIT_2状态。     当服务器没有数据要发送时，发送FIN包（FIN=1，ACK=1），请求断开连接，并指定序列号seq=y。此时服务器进入LAST_ACK状态，等待客户端的确认。     客户端收到服务端的FIN包后，向服务端发送ACK包（ACK=1），确认接收到了断开连接请求，并指定确认序列号ack=y+1。此时客户端进入TIME_WAIT状态，等待2MSL（MSL：报文段最大生存时间），然后关闭连接。      完整过程   70.常见TCP的连接状态有哪些？   请你说一说TCP的模型，状态转移。        CLOSED：初始状态。     LISTEN：服务器处于监听状态。     SYN_SEND：客户端socket执行CONNECT连接，发送SYN包，进入此状态。     SYN_RECV：服务端收到SYN包并发送服务端SYN包，进入此状态。     ESTABLISH：表示连接建立。客户端发送了最后一个ACK包后进入此状态，服务端接收到ACK包后进入此状态。     FIN_WAIT_1：终止连接的一方（通常是客户机）发送了FIN报文后进入。等待对方FIN。     CLOSE_WAIT：（假设服务器）接收到客户机FIN包之后等待关闭的阶段。在接收到对方的FIN包之后，自然是需要立即回复ACK包的，表示已经知道断开请求。但是本方是否立即断开连接（发送FIN包）取决于是否还有剩余数据需要发送给客户端，若有，则在发送FIN包之前均为此状态。     FIN_WAIT_2：此时是半连接状态，即有一方要求关闭连接，等待另一方关闭。发送断开请求一方还有接收数据能力，但已经没有发送数据能力。客户端接收到服务器的ACK包，但并没有立即接收到服务端的FIN包，进入FIN_WAIT_2状态。     LAST_ACK：服务端发动最后的FIN包，等待最后的客户端ACK响应，进入此状态。     TIME_WAIT：客户端收到服务端的FIN包，并立即发出ACK包做最后的确认，在此之后的2MSL时间称为TIME_WAIT状态。在2MSL时间内，同一个socket不能再被使用，否则有可能会和旧连接数据混淆（如果新连接和旧连接的socket相同的话）。 如果客户端直接进入CLOSED状态，如果服务端没有接收到最后一次ACK包会在超时之后重新再发FIN包，此时因为客户端已经CLOSED，服务端就不会收到ACK而是收到RST。所以TIME_WAIT状态是防止最后一次握手数据没有到达对方而触发重传FIN准备的。          关发接建，1关2最      71.TCP的三次握手和四次挥手的原因是什么？   为什么TCP建立连接是三次握手，而关闭连接却是四次挥手？   为什么是三次握手？       三次握手才可以阻止重复历史连接的初始化(主因)    三次握手才可以同步双方的初始序列号    三次握手才可以避免资源浪费      解释： 1、阻止重复历史连接的初始化（主因）   为了防止已失效的连接请求报文段突然有送到了B，而产生错误   假设两次握手时，A发出的第一个请求连接报文段在某一网络节点长时间滞留，以致延误到连接释放后才到达B。B收到失效的连接请求报文段后，认为是A又发出一次新的连接请求。于是向A发送确认报文段，同意建立连接，此时在假定两次握手的前提下，连接建立成功。这样会导致B的资源白白浪费。   如果已失效的连接请求报文段突然又送到了服务端        当旧的SYN报文先到达服务端时，服务端回⼀个ACK+SYN报文。     客户端收到后可以根据自身的上下文，判断这是⼀个历史连接（序列号过期或超时），那么客户端就会发送RST 报文给服务端，表示中止这一次连接。 两次握手在收到服务端的响应后开始发生数据，不能判断当前连接是否是历史连接。 三次握手可以在客户端准备发送第三次报文时，客户端因有足够的上下文来判断当前连接是否是历史连接。      2、同步双方的初始序列号 TCP 协议的通信双方， 都必须维护⼀个「序列号」 ， 序列号是可靠传输的⼀个关键因素。        接收端可以去除重复数据。     接收端可以按照序列号顺序接收。     标识发送的数据包，哪些已经被收到。 两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收。 三次握手一来一回，才能确保双方的初始序列号能被可靠的同步。      3、避免资源浪费。        两次握手会造成消息滞留情况下，服务器重复接受无用的连接请求 SYN 报文，而造成重复分配资源。     只有两次握手时，如果客户端的SYN请求连接在网络中阻塞，客户端没有收到服务端的ACK报文，会重新发送SYN。     由于没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的 ACK 确认信号，所以每收到一个 SYN 就只能先主动建立个连接。      为什么是四次挥手？        TCP协议是全双工通信，这意味着客户端和服务器端都可以向彼此发送数据，所以关闭连接是双方都需要确认的共同行为。     服务端通常需要等待完成数据的发送和处理， 所以服务端的ACK和FIN⼀般都会分开发送，从而比三次握手导致多了⼀次。           关闭连接时，客户端发送FIN报文，表示其不再发送数据， 但还可以接收数据。      服务端收到FIN报文，先回一个ACK应答报文，服务端可能还要数据需要处理和发送，等到其不再发送数据时，才发送FIN报文给客户端表示同意关闭连接。          如果采用三次挥手来关闭连接，可能会出现以下问题：           客户端发送FIN报文后，服务端无法确认客户端是否真的已经关闭了连接，因此需要等待一段时间才能确认客户端已经关闭连接。      服务端发送FIN报文后，