局部变量全局变量

• 全局变量是定义在函数外部的变量，它可以在函数的内外部的任何地方被访问和使用。全局变量通常定义在程序的开头，在整个程序运行期间都是可用的。
• 局部变量是定义在函数内部的变量，它只能在函数的内部被访问和使用。局部变量只在函数的执行期间有效，函数结束后，它就会被销毁。

局部变量加static

static 修饰的局部变量可以在程序的多次执行过程中保持其值不变，也就是说当一个函数调用结束，其局部变量并不会被释放，而是保留在内存中，供以后使用。而且static修饰的局部变量只能在当前文件中访问，即使在其他文件中也不能访问。

值传递和引用传递

• 值传递：把函数外部的值复制一份传递到函数内部，在函数内部修改，不会影响到函数外部的值。
• 引用传递：把函数外部的变量的地址传递到函数内部，在函数内部修改，会影响到函数外部的值。

OSI七层模型

OSI七层模型分别为：物理层（Physical Layer）、数据链路层（Data Link Layer）、网络层（Network Layer）、传输层（Transport Layer）、会话层（Session Layer）、表示层（Presentation Layer）和应用层（Application Layer）。

1. 物理层（Physical Layer）：负责传输电信号，规定电缆连接、传输模式、数据编码协议和电器设备等。
2. 数据链路层（Data Link Layer）：负责管理物理层的硬件设备，如网卡和无线接口等，局部网络的数据传输，进行错误检测和纠正，以及网络可靠性的提高等。
3. 网络层（Network Layer）：负责数据包在网络中传输，路由选择、网络地址分配等功能，实现网络中主机之间的通信。
4. 传输层（Transport Layer）：负责确保传输数据的正确传递，提供端到端（end-to-end）的可靠性和有序性，以及可靠性确认机制，如TCP协议、UDP协议等。
5. 会话层（Session Layer）：负责维护两台主机之间的会话，比如建立会话、终止会话等。
6. 表示层（Presentation Layer）：负责数据的表示格式，包括数据的编码和加密，提供应用程序之间的数据交换格式，以及压缩和解压缩等功能。
7. 应用层（Application Layer）：负责提供网络应用服务，支持用户与网络进行交互，如FTP、SMTP、HTTP等协议等。

TCP/IP五层网络模型

TCP/IP五层网络模型由应用层、传输层、网络层、数据链路层和物理层组成。

1. 应用层：应用层提供网络应用程序之间的通信接口，如HTTP、FTP、Telnet、SMTP等。它为用户提供了定义特定网络应用服务的协议，比如文件传输协议FTP和网页浏览协议HTTP。
2. 传输层：传输层提供进程间的通信服务，如传输控制协议（TCP）和用户数据报协议（UDP）等。它负责在两个端点之间传输数据，确保数据的可靠传输，并维护数据的流量控制和拥塞控制。
3. 网络层：网络层定义了分组的路由选择，如因特网协议（IP）等。它为数据报文选择最有效的路由，并将数据报文传输到目的网络中。
4. 数据链路层：数据链路层负责在传输媒介上传输数据报文，如以太网、无线局域网等。它负责将网络中的两台主机连接在一起，并在它们之间传送数据帧。
5. 物理层：物理层定义了物理设备的接口，如光纤、双绞线、无线及其他通信信道等。它负责将比特流转换为电信号或光信号，并在物理设备之间传输。

UDP如何实现可靠传输

UDP可以使用超时重传和ACK机制来实现可靠传输。

• 超时重传：发送端会把数据发送出去，并设置一个定时器，如果没有在规定的时间内收到确认信息，则会重新发送这条数据，直到收到确认信息为止。
• ACK机制：接收端收到数据后，会发送一个ACK信息给发送端，告知发送端这条数据已经收到，这样发送端就收到了确认信息，就知道这条数据是可靠地传输到接收端了。

TCP和UDP的区别，应用场景

TCP面向连接的，UDP是无连接的，TCP需要三次握手建立可靠连接，UDP只需要知道地址，不可靠传输

UDP比TCP传输的速度更快

TCP面向字节流，UDP面向报文

TCp只能是一对一通信，UDP可以一对多，也可以多对多传输

UDP可以用于电话，视频，直播等实时应用。TCP可以用于文件传输，消息聊天等有可靠要求的应用

TCP连接三次握手的过程

• 第一次握手：客户端请求建立连接，向服务端发送一个请求报文（SYN=1），同时选择一个随机数seq=x作为初始序列号，并进入等待连接状态，等待服务器的确认
• 第二次握手：服务端收到请求连接报文之后，如果同意连接，就向客户端发送请求确认报文（SYN=1，ACK=1），确认号为ack=x+1，同时选择一个seq=y作为初始序列号，此时服务器进入等待连接状态
• 第三次握手：客户端收到服务端的确认后，向服务端发送一个确认报文（ACK=1），确认号为ack=y+1，序列号为seq=x+1，客户端进入连接状态，服务端收到确认报文之后也进入连接状态，连接建立。

为什么TCP握手三次而不是两次、四次

为什么不是两次

1. 防止已过期的连接请求又传送到服务器，由此产生的错误和资源浪费

如果两次握手就能建立连接，假设客户端发送A报文段请求连接，但是因为网络的原因造成A延迟到达，服务端收不到客户端的请求连接报文就不会反回确认报文。

客户端在长时间没有收到服务端的确认报文，就会触发超时重传机制，重新发送请求连接报文B，刚好这次报文B顺利到达了服务端，服务端也返回了确认连接报文，建立一次连接数据发送完成之后正常四次挥手断开连接

很巧啊，断开之后之前发送的请求连接报文A到达了服务端，服务端看到请求连接之后马上回了一个确认连接报文进入到了连接状态，但是客户端已经关闭了收不到服务端发来的确认连接请求，就造成了服务端单方面等待，浪费资源，如果是三次握手的话，服务端此时只是处于等待连接的状态

1. 三次握手才能让双方都确认自己和对方的发送、接收能力都正常

第一次握手：客户端只是发送请求连接报文，什么都无法确认，而服务端收到客户端的请求连接报文，可以确认客户端的发送能力是正常的

第二次握手：客户端收到服务端的确认连接报文，可以确认服务端的接收和发送能力都是正常的

第三次握手：服务端收到客户端的确认连接报文，可以确认客户端的接收和发送功能都是正常的

如果只有两次握手，那服务端无法确认客户端的接收能力是不是正常的，违背了TCP可靠传输的前提

为什么不是四次

• 因为没有必要，三次握手已经能建立可靠连接了

三次握手连接阶段，最后一次ACK包丢失，会发生什么

服务端：

• 第三次的ACK包丢失之后，服务端此时处于待连接状态，长时间没有收到ACK包会触发超时重传机制，等待一段时间之后服务端重新发送SYN+ACK包，等待客户端的ACK包
• 如果重发次数超过一定限制之后，还没有收到客户端的ACK包，服务端默认此次连接失败，关闭连接

客户端：

• 而客户端已经进入了连接状态，当客户端向服务端发送数据时，服务端将返回RST包表示此次连接异常

TCP关闭连接四次挥手的过程

第一次挥手：客户端向服务端发送请求关闭报文（FIN=1，ACK=1），主动关闭连接，同时等待服务端确认序列号seq=u，即客户端上次发送报文的最后一个字节的序号+1，确认号ack=k，即服务端上次发送报文的最后一个字节的序号+1

第二次挥手：服务端收到关闭连接请求后，立即回复确认报文（ACK=1）序列号seq=k，确认号ack=u+1

第三次挥手：服务端向客户端发送连接释放报文（FIN=1，ACK=1），主动关闭连接，等待客户端确认。序列号seq=w，即服务端上次发送报文的最后一个字节的序列号+1.确认号ack=w+1

第四次挥手：客户端收到服务端的请求关闭连接之后，立即发送确认报文（ACK=1），序列号seq=u+1，确认号ack=w+1。

客户端进入超时等待状态，服务端收到客户端的确认报文之后立即关闭，客户端在超时等待之后也关闭

为什么客户端要有一个超时等待的状态

确保ACK报文能够顺利到达服务端，使服务端正常关闭，第四次挥手时，客户端发送的ACK报文不一定能到达服务端，服务端会超时重传（FIN、ACK）包，如果客户端马上断开了连接，那就无法响应服务端的第二次请求，造成资源浪费。

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

TCP会有一个定时器+超时重传机制，如果服务端发送数据给客户端没有得到任何的反馈，在超时之后服务端会发送一个探测报文，在连续发送十个探测报文都没有得到回应，服务端默认此次连接关闭。

TCP协议如何保证可靠性

滑动窗口：滑动窗口提高了报文传输的效率，也避免了发送方发送过多的数据导致无法处理的现象

超时重传：如果发出去的数据在规定时间内没有得到应答，就会认为发生了丢包，重新发送一次

拥塞控制：传输的过程中，可能会因为网络的原因造成网络拥堵，引入拥塞控制机制，保证TCP传输的可靠性

流量控制：如果主机A一直向主机B发送数据，不考虑主机的接收能力，则很有可能导致主机B的接收缓冲区满了而无法在接收数据，从而导致大量的数据丢包，引发重传机制，流量控制机制，主机B告诉主机A自己的接收缓冲区的大小，来使主机A控制发送的数据量。

详细说一下滑动窗口

接收区大致分为四组，一组是已经发送并被确认的分组，一组是已经发送但还没有被确认的分组，一组是即将要发送的分组，一组是还没轮到要发送的分组，滑动窗口控制已经发送但没被确认和马上要发送的分组，当已经发送的数据被确认，窗口开始滑动，将没轮到的分组纳入滑动窗口。滑动窗口的最大尺寸由发送方设定，接收方收到数据包之后，会发送一个确认报文给发送方，发送方收到确认报文后会将滑动窗口移动

详细说一下拥塞控制

慢开始：不要一开始就发送大量数据，而是由小到大慢慢增加拥塞窗口的大小

拥塞避免：拥塞避免算法让拥塞窗口慢慢增长，每经过一个往返时间就把发送方的拥塞窗口加1而不是加倍

快重传：在收到接收方的一个失序的报文之后就立即发送重复确认，只要收到三个重复确认就立即重传丢失的报文段，而不用等待超时重传的计时器到期

快恢复：

在浏览器输入URL之后执行的过程

域名解析：向DNS服务器查询对应的服务器IP地址

三次握手，建立TCP连接

根据IP地址，向服务器发送HTTP请求

服务器收到请求，生成HTML文档

将HTML文档发送给浏览器

浏览器收到HTML文档，解析HTML文档，并请求HTML中的资源

浏览器对页面进行渲染，呈现给用户