服务器面试必备-网络知识点整理
在面试中，无论是从事服务器开发还是运维工作的人几乎都无法回避会被问及与网络相关的问题。由于网络是实现客户端与服务器之间通信、数据传输、分布式计算以及安全性和访问控制的关键工具，在这一领域掌握基本知识对于所有开发者来说都是必要的基础。因此我整理了一些常见于 server 面试中的问题并进行了系统的分享。如果感兴趣的话，可以通过订阅专栏获取更多学习资源和实践机会。
1、什么是IO多路复用
该机制允许一个线程或进程同时监听多个I/O流，在传统的I/O模型中，则要求每个I/O流独立处理。相比之下，在采用该机制时，系统能够实现对多个I/O流的同步监听，从而显著提升了系统的并发处理能力和整体性能水平。
通常采用的IO多路复用机制包括select、poll和epoll三种类型。这些机制主要依赖于操作系统提供的特定函数，并通过将多个输入输出（IO）流注册到一个专用事件循环中来实现功能。随后系统会定期检查这些输入输出（IO）流的状态变化情况，并根据检测结果进行相应的处理操作。
在输入输出（IO）多路复用机制中运行时，在检测到一个或多个输入输出（IO）变为可用状态后，系统会响应应用程序。相应的应用程序能够即时处理这些可用的输入输出（IO），执行读取和写入操作。这将有效降低系统的阻塞时间，并显著提升系统的并发处理能力和整体性能水平。
2.HTTP 的特点？HTTP 有哪些缺点？
HTTP 的特点概括灵活可扩展 主
该协议主要体现在两个主要方面：一是它仅规定了基本格式要求,如空格分隔单词、换行分隔字段等,并未对其他各部分设定严格的语法限制；二是它提供了高度灵活的数据传输能力,能够支持文本、图片、视频等多种数据形式,极大地方便了数据交换与管理。这些特性都源自可靠传输技术的基础之上——即基于HTTP协议实现了可靠的数据传输功能。而HTTP又是基于TCP/IP协议实现网络层功能的基础之一,因此该协议在这一层面上也继承了下来。对于请求-应答机制而言,即采用一发一收、有来有往的方式进行通信,其中发送方与接收方不仅限于客户端与服务器之间,而且允许某台服务器作为代理角色连接到后端服务端,从而实现了多对多的通信模式。此外,该协议还具备无状态特点:这里的"状态"特指通信过程中的上下文信息内容,而每次HTTP请求都是独立完成的任务，默认情况下不会保留任何状态信息
HTTP 缺点
无状态 评估优缺点需根据不同场景进行判断，在此情况下对于HTTP而言存在争议性问题即其无状态特性。
当处理长连接请求时系统必须存储大量上下文信息以防止传输冗余数据从而使得无状态成为HTTP的劣势。
然而在某些应用中仅需获取数据而不必维护复杂的上下文管理此时无状态反而减少了网络开销从而成为优势。
在协议设计中明文传输指的是将协议中的头部字段以纯文本形式进行发送这无疑简化了调试过程但也暴露了HTTP的信息流使得攻击者能够轻易获取敏感信息其中WIFI陷阱便是利用这一缺陷诱导用户接入热点从而窃取流量并窃取敏感数据。
当HTTP采用长连接模式时会共享一个TCP连接同一时刻仅能处理一个请求因此当前请求耗时过久会导致后续请求处于等待状态这就是著名的队头阻塞问题。
3、epool中et和lt的区别与实现原理
LT采用水平触发策略，在这种模式下运行效率略低于基于边缘触发设计的服务架构（Es），尤其是在面对高并发场景或大规模数据流时表现更为明显。然而在这种架构下对代码实现的要求相对较低且更加易于维护与调试 LT架构的核心优势在于其提供的稳定性与可靠性 LT服务架构的关键特性即一旦存在未被完全获取的数据就会不断向客户端发送通知从而有效防止了事件丢失问题。
Es采用基于边缘化的同步机制能够在高并发环境下展现出极高的性能优势，在这种架构下运行效率显著高于基于层次化架构设计的服务系统（Hs）尤其是在极端负载条件下 Es能够在保证服务质量的同时最大限度减少网络开销 Es架构的核心优势在于其提供的高性能特性 Es服务架构通过将同步操作集中于单个节点上实现了高效的异步通信机制从而显著提升了整体系统的吞吐量与响应速度。
4、tcp连接建立的时候3次握手，断开连接的4次握手的具体过程
该技术过程可被详细描述为如下三步完成：
- 客户端发起操作：通过发送connect请求至服务器端。
- 服务器响应：当服务器接收到客户端的请求后响应。
- 客户端确认：在此基础上, 客户端随后发送确认应答给服务器端。
- 建立连接：经过上述三个阶段, 客户端与服务器之间即可展开正常的通信流程。
通过断开连接的一方发送close请求完成第一次握手。当另一方接收到该请求数字后会立即返回确认信息。完成确认后会向另一方发出close命令完成第二次握手。随后向另一方发出close命令关闭双方的连接完成第三次握手。最初一方接收到对方断开请求时会进入time_wait状态这个状态也是面试官经常考察的问题。
5、connect方法会阻塞，请问有什么方法可以避免其长时间阻塞？
常用方法具有较高的效率，并非最优选择；另一种方案是采用无阻塞模式。或者考虑采用异步传输机制，在这种情况下程序能够立即返回并继续执行后续操作；两者的区别主要体现在当使用recvfrom时会出现一致阻塞（导致调用所在的线程被暂停执行），而异步传输机制则不会出现这种情况，在这种情况下程序能够立即返回并继续执行后续操作。
6.如何理解 HTTP 的请求方法？
http/1.1 规定了以下请求方法(注意，都是大写):
- GET方法常用于获取资源信息
- HEAD方法主要用于获取资源的元信息
- POST方法用于提交数据包（即上传数据）
- PUT方法用于更新或修改资源数据
- DELETE方法用于删除资源（此功能较为少见）
- CONNECT方法用于建立连接隧道（主要用于代理服务器）
- OPTIONS方法列出可对资源适用的所有请求方式，并可预检请求合法性（常用在跨域场景）
- TRACE方法用于跟踪请求-响应传输路径
7.HTTPS 是如何建立连接的？其间交互了什么？
基于SSL/TLS协议的通信过程如下：
- 采用TCP协议进行三次握手过程
- 客户端主动获取并验证服务器的公钥信息
- 双方共同协商生成会话密钥
- 建立安全的通信隧道后完成协商过程
- 通过协商产生的会话密钥对通信双方进行加密交流。
其中第2、3步构成了SSL/TLS体系的关键建立环节即所谓的握手阶段整个握手过程共包含了四次通信交互环节。
8.对于定长和不定长的数据，HTTP 是怎么传输的？
定长包体
对于定长包体而言，在传输过程中发送端通常会携带Content-Length字段以指示包体的长度。我们可以采用一个Node.js服务器来演示这一过程：
const http = require('http');
const server = http.createServer();
server.on('request', (req, res) => {
if(req.url === '/') {
res.setHeader('Content-Type', 'text/plain');
res.setHeader('Content-Length', 10);
res.write("helloworld");
}
})
server.listen(8081, () => {
console.log("成功启动");
})
AI助手启动后访问: localhost:8081。浏览器中显示如下:
helloworld
AI助手在长度正确的情况下，在符合要求的情形下进行处理时，请问我们该如何操作？为了优化性能效果，请问我们将该参数设置为较小值是否可行？
res.setHeader('Content-Length', 8);
AI助手重启服务，再次访问，现在浏览器中内容如下:
hellowor
AI助手为何后端的ld信息不见了？这实际上是HTTP响应体中的内容。然后试着将其优化到更大范围。
res.setHeader('Content-Length', 12);
AI助手此时浏览器显示如下:
[
该链接提供了一种高效的代码覆盖测试方案，在GitHub上广泛使用
内容无法正确显示。观察到Content-Length在HTTP传输过程中扮演着至关重要的角色，在配置错误的情况下可能导致传输中断。
不定长包体
上述是针对于定长包体的情况进行说明。那么，在处理不定长包体时会采用什么样的传输方式呢？这里就需要介绍另一个 HTTP 头部字段。
Transfer-Encoding: chunked
// Transfer-Encoding: chunked
// Transfer-Encoding: compress
// Transfer-Encoding: deflate
// Transfer-Encoding: gzip
// Transfer-Encoding: identity
// Several values can be listed, separated by a comma
// Transfer-Encoding: gzip, chunked
AI助手表示分块传输数据，设置这个字段后会自动产生两个效果:
- Content-Length 字段会被忽略
- 基于长连接持续推送动态内容 我们依然以一个实际的例子来模拟分块传输，nodejs 程序如下:
const http = require('http');
const server = http.createServer();
server.on('request', (req, res) => {
if(req.url === '/') {
res.setHeader('Content-Type', 'text/html; charset=utf8');
res.setHeader('Content-Length', 10);
res.setHeader('Transfer-Encoding', 'chunked');
res.write("<p>来啦</p>");
setTimeout(() => {
res.write("第一次传输<br/>");
}, 1000);
setTimeout(() => {
res.write("第二次传输");
res.end()
}, 2000);
}
})
server.listen(8009, () => {
console.log("成功启动");
})
AI助手[
用 telnet 抓到的响应如下:
[
该方法能够达成矩阵的特征值分解。
该方法同样可以执行奇异值分解。
数值实验表明，在特定条件下该算法具有显著的计算效率提升效果。
其中一些特殊情况下的计算结果与现有文献中的结果相符。
注意，在Connection: keep-alive字段及其之前的部分构成了响应头信息（Header Information），而其后的内容则属于响应体部分（Response Body）。这些两部分内容通过换行符分隔开来（separated by newline characters）。而Response body structure is quite intriguing（response body's structure is quite intriguing）是一个值得深入探讨的部分（a topic worth exploring in depth）。
chunk长度(16进制的数)
第一个chunk的内容
chunk长度(16进制的数)
第二个chunk的内容
......
0
AI助手最后留有一个空行，请各位注意。
以上即为 HTTP 对其定长与不定长数据传输的方式说明。
9.TCP协议如何保证可靠传输
- 应用数据按照 TCP 规则被分割成最适合传输的数据块。
- TCP 为发送的每一个包分配编号，在接收方完成排序后将有序数据传递给应用层。
- 校验和：TCP 会保留其首部信息以及与数据相关的检验和。这一机制旨在检测数据传输过程中的任何变化。若接收到的数据段检验和出现错误，则该报文段将被丢弃并通知接收方未成功接收此段。
- 流量控制：TCP 连接双方均设有固定容量的缓冲区，在接收端仅允许处理能容纳的数据量。当接方无法及时处理发方数据时，则会指示发方减缓发送速率以防止数据丢失。TCP 使用滑动窗口协议来实现流量控制。
- 拥塞控制：当网络出现拥塞情况时，则减少当前的数据传输速率。
- ARQ 协议同样是用于可靠传输设计的，在完成一个分组后立即停止发送，并等待对方确认后再继续下一个分组。
- 超时重传机制是这样工作的：当 TCP 发送一个报文段后会启动计时器等待对方确认响应。若未能及时得到确认响应，则会重新发送该报文段。
8.TCP 接收端会对重复的数据进行过滤并丢弃
10.HTTP长连接,短连接
在HTTP/1.0协议中，默认采用短连接机制。即每当客户端与服务器之间发起一次完整的HTTP操作流程时，在完成任务后立即断开该会话。然而，在实际应用中发现这一机制存在一定的局限性：每当客户端打开包含JavaScript、图像或CSS等其他Web资源的HTML页面时（即每次遇到此类网页内容时），浏览器都会启动一个新的网络会话来处理这些外部资源的需求。自HTTP/1.1协议发布以来，默认采用了长连接技术（即通过增强可靠性和数据完整性来提升用户体验），这种机制旨在维持长时间的数据传输需求，并通过改进数据传输效率来优化网络性能。
Connection:keep-alive
AI助手在采用长链接模式时，在网页完成加载后的一段时间内，客户端与服务器之间的TCP通道用于传输HTTP数据将始终保持开启状态；当客户端再次登录该网站时，则会持续利用这条已建立的通道进行通信。Keep-Alive功能其特性在于并非永久保留通道状态而是附带了一个保持时间参数；在Apache等不同服务器软件中可以配置该值以调节保活期；实现这一通信模式的前提条件是客户端与服务端均需支持相关功能；从整体来看HTTP协议中的长链接与短链接实质上是基于TCP协议的不同类型
11、网络中，如果客户端突然掉线或者重启，服务器端怎么样才能立刻知道？
当客户端发生断联或重启时，服务器端将接收到重置指令。值得注意的是，在不同版本的TCP/IP协议下其实现方式各有差异相应的控制策略也存在差异
12.HTTP 如何处理大文件的传输？
对于几个G甚至更大的文件而言，在一次性传输所有内容上必定会面临诸多延迟问题，在用户体验方面造成显著影响。鉴于此，在处理此类大规模数据传输需求时HTTP系统采用了范围请求的技术方案以实现对数据传输过程的有效管理使得客户端只需提交所需资源的部分内容
如何支持
在服务器能够处理范围请求的前提下，在实现这一特定功能的需求下，则必须添加相应的响应头字段。
$ curl -I https://www.yuque.com/
HTTP/1.1 200 OK
...
Accept-Ranges: bytes
Content-Length: 146515
$ curl -I http://download.dcloud.net.cn/HBuilder.9.0.2.macosx_64.dmg
$ curl -H "Range: bytes=0-10" http://download.dcloud.net.cn/HBuilder.9.0.2.macosx_64.dmg -v
//省略
HTTP/1.1 200 OK
...
Accept-Ranges: none
//详细的
HTTP/1.1 200 OK
Server: Tengine
Content-Type: application/octet-stream
Content-Length: 233295878
Connection: keep-alive
Date: Mon, 26 Apr 2021 13:12:46 GMT
x-oss-request-id: 6086BC4E66D721363972F4A8
x-oss-cdn-auth: success
Accept-Ranges: bytes
ETag: "6D932737FD8C6058D6AE93BCC4C74AA7-45"
Last-Modified: Tue, 06 Mar 2018 13:20:31 GMT
x-oss-object-type: Multipart
x-oss-hash-crc64ecma: 7369427768111114923
x-oss-storage-class: Standard
x-oss-server-time: 156
Ali-Swift-Global-Savetime: 1617704046
Via: cache15.l2cn1809[0,200-0,H], cache2.l2cn1809[1,0], cache7.cn682[39,39,200-0,M], cache2.cn682[44,0]
Age: 778
X-Cache: MISS TCP_MISS dirn:-2:-2
X-Swift-SaveTime: Mon, 26 Apr 2021 13:25:44 GMT
X-Swift-CacheTime: 3600
Timing-Allow-Origin: *
EagleId: af062a4216194435440612604e
AI助手若响应中出现Accept-Ranges首部且其值非none，则表示该服务器支持范围请求。在上述响应中，Accept-Ranges: bytes表明界定范围的单位是bytes。此处Content-Length同样具有重要信息价值，并包含所需检索图片的完整大小数据。
当某个网站未传递Accept-Ranges头信息时
curl -I https://www.youtube.com/watch?v=EwTZ2xpQwpA
HTTP/1.1 200 OK
...
Accept-Ranges: none
AI助手Range 字段拆解
而从客户端的角度来看，在提交请求时它需要指示哪些部分被处理，请利用 Range 作为请求头字段进行标识，并采用 bytes=x-y 格式进行表示。下面将详细探讨 Range 的书写规范：
0-499 表示从开始到第 499 个字节。
500- 表示从第 500 字节到文件终点。
-100 表示文件的最后100个字节。
当服务器接收到一个请求时
// 单段数据
curl http://i.imgur.com/z4d4kWk.jpg -i -H "Range: bytes=0-1023"
Range: bytes=0-9
// 多段数据
curl http://www.example.com -i -H "Range: bytes=0-50, 100-150"
Range: bytes=0-9, 30-39
AI助手接下来就分别来讨论着两种情况
单段数据
对于单段数据的请求，返回的响应如下:
HTTP/1.1 206 Partial Content
Content-Length: 10
Accept-Ranges: bytes
Content-Range: bytes 0-9/100
i am xxxxx
AI助手在评估网络资源时需要注意的是Content-Range字段。其中数值范围为0到9时代表客户端对资源的响应情况；而当数值为100时则表示该资源的整体规模这一规定易于掌握。
多段数据
接下来看看多段请求的情况。得到的响应会是下面这个形式:
HTTP/1.1 206 Partial Content
Content-Type: multipart/byteranges; boundary=00000010101
Content-Length: 189
Connection: keep-alive
Accept-Ranges: bytes
--00000010101
Content-Type: text/plain
Content-Range: bytes 0-9/96
i am xxxxx
--00000010101
Content-Type: text/plain
Content-Range: bytes 20-29/96
eex jspy e
--00000010101--
AI助手此时出现了极为重要的一项关键信息描述：其中包含的关键字段名称为Content-Type: multipart/byteranges;boundary=???
请求一定是多段数据请求
响应体中的分隔符是 00000010101
由此可见，在响应体中各段数据之间会被指定为分隔符使用，并且会在最后一个分隔符后附加--以示结束。综上所述，在处理大文件传输时，我们采用了该方式作为核心手段。
与分块传输编码的对比
Transfer-Encoding 头部支持分块编码，在处理海量数据且无法预知完整响应体积的情况下尤其实用。服务器将直接发送数据给客户端而无需缓存或计算精确响应大小（这会导致延迟增加）。范围查询与分块传输兼容，在单独使用或组合使用时均可灵活应用
TTL是什么？它有哪些应用场景？它的实际作用是什么？哪些常见的工具会使用TTL功能？
简
详
14.说说 HTTP1.1 相比 HTTP1.0 提高了什么性能？
HTTP1.1 相比 HTTP1.0 性能上的改进：
通过采用 TCP 长连接技术来优化 HTTP/1.0 中短连接带来的通信开销。该系统支持管道（pipeline）网络传输机制，在实际运行中一旦第一个请求发送成功后即可立即发起第二个请求，并通过并行处理有效降低了整体的数据传输时延。
但 HTTP1.1 还是有性能瓶颈：
- 未压缩传输的头部（Header）会导致延迟增加；而只有在Body部分进行数据压缩时才能有效减少带宽消耗。
- 传输冗长的头部信息不仅会增加不必要的开销,还会导致通信过程中的资源浪费.
- 服务器通常按照接收到的请求顺序依次处理;当服务器处理速度较慢时,在等待数据返回的过程中可能导致客户端处于等待状态而无法获取新数据(队列阻塞现象).此外,在缺乏基于请求优先级的支持下,
- 这种架构设计使得数据流必须自客户端发起,并在接收端仅限于被动地进行响应.
15.HTTP 与 HTTPS 有哪些区别？
超文本传输协议（HTTP）以明文字面形式传输信息，在安全性上存在显著缺陷。而 HTTPS 则通过在 TCP 和 HTTP 网络层间引入 SSL/TLS 协议机制，在数据报文中实现了加密传输。
在连接建立方面, HTTP 过程较为直接, 在完成 TCP 三次握手后即可开始执行报文传输操作. 而相比之下, HTTPS 则需在 TCP 三次握手的基础上, 进行SSL/TLS 协议的协商流程. 才能进入加密数据传输阶段.
通常情况下, HTTP 协议采用端口号 80 进行通信；而 HTTPS 则采用了端口号 443 来实现数据传输.
为了确保服务提供商的身份认证无误, HTTPS 协议要求相关服务提供者通过CA（证书权威机构）获取数字证书认证.
16、网络编程中设计并发服务器，使用多进程 与 多线程 ，请问有什么区别？
答案一:
1）进程：子进程作为父进程中内存空间、堆栈等资源的复制体存在。它通过复制父进程的空间布局来模拟父进程中各对象的行为模式。
2）线程：相较于进程而言，线程是一个更为接近于执行体的概念。每个线程能够共享与同进程的数据资源但独立运行于自己的栈空间中，并按照自身定义的顺序执行指令。
两者均能显著提升程序处理多任务的能力。然而，在实际应用中两者各有优劣：从资源利用的角度来看，线程在开销方面具有较高的效率；但这也带来了管理上的复杂性问题；相比之下，在系统稳定性与安全性方面具有明显优势的是进程机制。
在线程的设计特性上具有明显的优势：适合在单核或多核处理器上高效运行；而对系统架构有更高适应性的特点则是其采用进程模型作为基础设计。
答案二:
核心区别在于：多线程进程各自拥有独立的地址空间（address space），而线程仅共享一个地址空间（address space）。这一差异衍生出一系列其他特性：
1）速度方面：由于它们在同一个（shared）内存环境中运行，在生成速度、通信效率和切换频率上均表现出色。
2）性能方面：得益于共享内存机制的应用，在资源利用效率上表现更为突出。
3）同步需求：在线程操作公共资源时是否需要采用同步机制这一问题是值得探讨的关键点。
17、网络编程的一般步骤
对于TCP连接：
1.服务器端1）创建套接字create；2）绑定端口号bind；3）监听连接listen；4）接受连接请求accept，并返回新的套接字；5）用新返回的套接字recv/send；6）关闭套接字。
2.客户端1）创建套接字create; 2）发起建立连接请求connect; 3）发送/接收数据send/recv；4）关闭套接字。
TCP总结：
Server端：启动服务器并进行绑定、监听、接受请求，并执行接收和发送操作后关闭连接；Client端：启动客户端并进行连接操作，并执行发送和接收操作后关闭连接。
对于UDP连接：
服务器端:1) 建立套接字；2) 调整端口绑定；3) 实现实收或发送消息；4) 断开连接。
客户端:1) 建立套接字；2) 实现实发或接收消息；3) 断开连接。
UDP总结:
Server端：创建并绑定后，在接收来自客户端的数据时发送消息并关闭连接。
Client端：创建后发送消息并在接收到来自客户端的数据时关闭连接。
18、TCP的重发机制是怎么实现的？
1）滑动窗口机制确定了接收方的数据接收范围，并提供了三个关键数据：已成功接收的数据量、未被接收的数据量以及等待发送的数据量；同时让接收方了解已经成功接收的具体数据总量。
2）采用重传策略，在传输过程中出现错误时会重新发送相关数据序列。
19、TCP为什么不是两次连接？而是三次握手？
如果A和B两个进程之间通信时仅发生两次连接。可能出现的一种情况是：A发送完通知报文后因网络状况不佳导致出现网络拥塞现象即B会在较长时间后收到该报文。此时A会将此报文视为无效报文。B接收到报文后会向A发起连接请求此时双方握手完成B会认为已经建立好了连接而开始持续等待A的连接请求消息但由于A接收到失效的报文后不会进行响应从而导致B陷入持续等待的状态造成资源浪费。
20、socket编程，如果client断电了，服务器如何快速知道？
采用定时器机制（适用于存在数据传输的情形）； 配置socket的SO_KEEPALIVE选项（适用于无数据传输的场景）;
21、fork()一子进程程后 父进程癿全局变量能不能使用？
fork后子进程会继承父进程的大部分类资源（除一些专有资源外）。父子进程中端与后台进程中端各自拥有独立的全局变量。不支持共享，在多线程环境中无法直接使用这种机制（类似于文件系统中的目录结构）。多线程之间可以通过特定机制实现对这些私有资源的部分或全部共享。
22、4G的long型整数中找到一个最大的，如何做？
想要找出最大的数值必须遍历所有数据，并且为了避免一次性加载过多数据到内存中导致资源不足的情况。该算法的时间复杂度最低只能达到O（n），因此在处理大数据量时可能会遇到性能瓶颈。这样的思路虽然简单直接但可能存在效率上的提升空间。那么我们该如何进一步优化呢？
为了提高算法的整体效率我们可以尝试优化每次从磁盘读取数据到内存中的过程这一操作可能对性能提升产生直接影响。优化的一个关键点在于提高每次从磁盘读取数据到内存中的效率。
另一个值得探讨的方向是如何合理安排各批数据之间的处理顺序以减少整体运算时间具体来说可以通过动态调整缓存区的大小来平衡当前缓存区内的最大值与后续批次的数据结合从而实现更优的整体结果。
对于此题的一个变种情况，则是需要找出K个最大的数值或最小的数值。具体实现时可采用以下方法：基于容量为K的最大堆或最小堆（当数据量较大时通常优先选择该方法）。若所有N个待处理数据均小于MAX值，则建议采用类似计数排序的方式进行优化处理（若所有N个待处理数据均小于MAX值，则建议采用类似计数排序的方式进行优化处理）。
23、tcp三次握手的过程，accept发生在三次握手哪个阶段？
该客户端发起connect操作将导致三次握手流程的启动。在服务器端完成绑定并监听配置后，该过程会阻塞于accept阶段。经过三次握手建立完成后，在accept阶段会返回一个可连接的文件描述符；这个过程表明accept动作发生在三连 handshake之后。
24、tcp流， udp的数据报，之间有什么区别，为什么TCP要叫做数据流？
基于会话设计的应用程序S和C之间若采用TCP通信则需先建立会话 这些信息通过该会话传输通常双向流通且无网络层分段标记 我们称这种信息流为数据报 通常占有较高的资源占用率 UDP则不具备这种特性 不基于会话设计 不需要建立或释放网络层分段标记 每个信息块都是单独封装 独立传输于网络中 TCP确保了通信过程中的可靠性和有序性 而UDP则可能出现报错 或丢失部分报元体 但无法保证整体消息顺序
25、socket在什么情况下可读?
- 接收端存在数据，则必能读取
- 当客户端正常关闭socket时也会被接收到
- 当检测到新的连接到来时亦会被接收到
- 该socket出现故障且处于等待状态
26、TCP通讯中，select到读事件，但是读到的数据量是0，为什么，如何解决?
select操作若返回0则表示超时状态；若出现错误则返回-1。
在读事件触发后若接收到的数据量为零，则表明对方端已关闭其读端口。
当遇到select操作失败时，则需将该接口设置为可读且可写状态。
此时可通过检查select函数的返回值是否为-1来实现区分。
27、说说IO多路复用优缺点？
IO多路复用优点：
- 相较基于进程模型而言，在新的架构中程序员能够获得更灵活的程序行为控制。
- 仅需一个进程中就可以同时处理多个IO事件，并且单个进程中数据共享更加便捷的同时，调试操作也会更加简便。
- 由于在单一进程中不存在多线程或多进程切换开销的原因，则无需担心相关的性能损耗。
IO多路复用缺点：
- 业务流程难以顺利处理, 编程思路违背常规的思维方式。
- 未能有效发挥多核处理器的优势。
28、说说select机制的缺点
在每次select函数被调用时，必须将被监听的文件描述符集合fd_set从用户态复制到内核态状态。就其算法复杂度而言，该操作的时间开销为O(n)。
每次触发select后都需要扫描所有文件描述符，并分析这些文件描述符的读写状态。这一过程具有计算复杂度呈线性增长的特性。
内核对被监控的文件描述符集合大小进行了约束，并采用基于宏配置的方式实现该设置（具体最大值设定为1024）。
29、说一下epoll的好处
epoll成功克服了select和poll在文件描述符集合操作方面的局限性，并且支持一个进程中同时监听多个文件描述符，并且具有较高的性能优势。
30、你知道epoll是如何实现的吗？在内核中使用了什么样的数据结构进行存储，并且每个操作的时间复杂度具体是多少呢？其中涉及到的关键操作包括O(1)级别的算法。
epoll是一种支持高效I/O多路复用机制的Linux系统组件。该模型遵循事件驱动的方法，并能良好地处理众多并行连接。
在内核中，epoll采用一个红黑树（RB Tree）来管理所有的事件。该红黑树基于特定数据结构epoll_event进行表示，在此架构下，每个epoll_event则关联于一个文件描述符及其相关关注的事件。
每当调用epoll_wait函数时，在每次执行过程中, 内核都会对红黑树中的所有事件进行检查, 并返回满足特定条件的事件集合. 当没有符合条件的事件等待时, 该函数将会持续阻塞, 直到出现可处理的事件为止.
对于epoll的操作时间复杂度如下：
- 建立红黑树所需的时间复杂度指标值最低；
- 进行事件添加或修改操作所需的时间复杂度指标值均为O(log n)，其中n代表红黑树中存储的独立事件数量；
- 处理单个事件删除操作所需的时间复杂度指标值为O(k log n)，其中k表示待删除的具体独立事件数量；
- 获取所有已就绪的独立事件所需的总时间复杂度指标值等于O(log n + m)，此处n是系统中红黑树所包含的独立事件总数目而m则代表当前系统中存在的独立待查询数量。
总的来说，epoll支持了一种高效的I/O多路复用机制。这种机制能够使得开发者能够有效地管理大量并发连接，并在事件就绪后迅速执行相应的操作步骤。