八股文学习笔记---计算机网络+操作系统篇

写在前面

首先感谢哔哩哔哩大学赞助提供的丰富自学资源✿✿ヽ(°▽°)ノ✿
计算机网络网课推荐：湖科大教书匠、王道四大件

本篇笔记主要包含计算机网络和操作系统两个栏目：

• 计网栏目结合GitHub分享者提供的内容和公众号小黛的求职笔记(主攻银行方向的讲解，强推！☺)分享的内容进行整理，作为自己八股文问答的面试笔记，方便随时随地查看，避免自己间接性失忆☹
• 下文的整理仅仅是分点罗列一些关键性的内容，在面试回答时候最好能够明白前因后果，串成逻辑性的回答，体现你的专业性。例如：计算机网络中关于TCP重传机制的具体过程、三次握手四次挥手的具体过程和一些反思等等，这些都需要对网络中实际的传输过程有清晰的理解才能从容面对面试官。具体详细的内容推荐看小林coding(公众号或维护的个人网站)，通过画面加深记忆
• 面试官可能也会问到一些发散思维没有固定答案的问题。此时，我们需要对已经掌握的内容进行加工。比如处理重传问题，添加SACK标记内容进行解决；处理报文确认问题往往给定一个定时器加以限制，并根据不同的情况设计可能的解决办法。对于计网中，可能出现的不同问题给出的解决办法，我们可以记忆其效用并模拟，面试官可能并不期待你给出多么完整的答案，但是期待你对已有的知识加以理解并加工，最终能够在现实突发问题中进行活用。切忌担心自己回答的不够完美，即便是在实际工作中，处理问题也讲究轻重缓急、经验积累，用实际行动解决比等待找到完美方案更重要。
• 实际问题的举例应用，对于计算机网络和操作系统中的具体实现，面试官往往会从普通用户的实际使用案例开始发问，这可以考察你对整体知识联通状态学习得如何。如果没有对理论知识没有实感，那么只能我找找例子多想想了，踩踩经验，后面的问答就从善如流了。

计算机网络

0.计算机网络的分层架构

1.DNS: 域名解析系统

是一个将域名和IP地址相互映射的分布式数据库。

解析过程（分级解析）：
根域名 – 顶级域名 – 二级域名

步骤（递归查询本地服务器，迭代查询其他远程服务器）：

• 看看DNS缓存里有没有，有的话直接返回；
• 使用UDP向DNS服务器发送查询消息；
• 接收返回的响应消息；

详细流程：

1. 客户机向本地域名服务器发送DNS请求报文。

2. 当本地域名服务器收到请求后，先查询本地缓存，如果存在该纪录项，则本地域名服务器直接把查询结果返回。

3. 如果本地缓存中不存在该纪录，则本地域名服务器就把请求发给根域名服务器，然后根域名服务器会告诉本地域名服务器，下一次应该查询的顶级域名服务器的IP地址。

4. 本地域名服务器向顶级域名服务器进行查询。顶级域名服务器告诉本地域名服务器，下一步查询的权限服务器的IP地址。

5. 本地域名服务器向权限服务器进行查询。权限服务器告诉本地域名服务器所需要查询的主机的IP地址。

6. 本地域名服务器最后把查询结果告诉主机。

在解析的过程中，主机向本地域名服务器进行的是递归查询，而本地域名服务器采用迭代查询。

传输协议：
除超过512字节和主从DNS服务器的区域传送外，都是用UDP协议。

• 为什么使用UDP：快。只需要一个请求一个应答就够了，而TCP需要三次握手，请求与应答、四次挥手。如果多几次查询，每次都要握手挥手的时间开销太大了。并且DNS查询的数据都很小。
• 为什么区域传送使用TCP：因为可靠啊！从主DNS服务器上复制内容需要可靠，并且同步的数据可能超过512字节。

1. 2 DNS用的什么传输层协议，为什么用这个 ⭐⭐⭐

DNS在区域传送的时候，使用的是TCP协议；
在域名解析和其他的时候，使用的是UDP协议。
区域传送，使用TCP的原因：
因为，区域传送是在辅助DNS服务器向主DNS服务器中读取数据信息的，这个过程需要可靠的进行，并且需要传输更大的数据量的数据。

总结：
1.区域传送的数据量较大，UDP包只能传512字节，因此采用TCP进行传输
2.区域传送要求数据传输的可靠性，因此需要TCP协议

而为什么其他情况用UDP，就很简单了，就是不需要三次握手四次挥手，速度快，效率高，而且域名解析的时候，传输的内容比较小，不会超过512个字节。

2. 浏览器输入URL（域名）到返回页面的全过程：

1. DNS域名解析，得到IP地址；
2. 拿到解析的IP地址进行TCP连接；
3. 向服务器发送HTTP请求；
4. 服务器处理请求；
5. 服务器返回响应结果；
6. 关闭TCP连接；
7. 解析HTML；
8. 渲染页面。

3. TCP连接的三次握手，四次挥手

3次握手：
三次握手的详细说明，包括基本流程、标志位含义、C/S方的状态以及反问为什么不能是两次或四次的具体原因https://mp.weixin.qq.com/s/Se36CMOxO15upc9TqAqr5g

• 双方都确认自己和对方的收发能力是正常的，需要的最少握手次数。用不着4次，3次就够了。
• 此外，若使用2次握手，当客户端的失效连接请求到达服务器，服务器会误打开连接，浪费资源。
• 若第三次握手失败，服务器会关闭连接，防止SYN洪泛攻击。
  三次握手四次挥手的图解过程

3.1 TCP 和 UDP 的区别？

1. TCP面向连接，UDP无连接；
2. TCP基于字节流，UDP基于报文；
3. TCP有流控制和拥塞控制，UDP的吞吐量只取决于数据生成速率、传输带宽；
4. TCP可靠按序交付，UDP尽可能最大交付且乱序；
5. TCP全双工点对点通信，UDP可以一对一、一对多、多对一、多对多。

3.2 简要介绍三次握手和四次挥手

TCP通过三次握手来建立连接，通过四次挥手来断开连接。

• 为什么是3次握手？

  • 3次握手是连接双方都确认自己和对方有收发能力的最少握手次数；
  • 若只握手2次，服务器端在接收到客户端的请求就打开连接，可能收到网络中的失效请求而误打开连接，造成资源浪费；
  • 若第3次失败，服务器端会关闭连接，防止SYN洪泛攻击。

• 为什么是4次挥手？改成三次挥手可以吗？

  • 当服务器端收到客户端的关闭请求时，先响应ACK信号表示自己收到了客户端的请求，再将自己需要发给客户端的数据发完，最后再发送FIN信号表示自己的数据传输完毕。ACK与FIN分开响应使得挥手比握手（服务器的ACK和SYN同时发送回客户端）多了一次。
  • 首先，tcp是全双工的，也就是双方都可以发送数据和接收数据。四次挥手，前两次保证客户端不再发送数据，后两次保证服务器端不再发送数据。可以将服务器端对客户端第一次挥手的确认（第二次挥手）与服务器端发送不再发送数据的报文段（第三次挥手）合二为一，这样第一次和第二次可以保证客户端不再发送数据，第二次和第三次可以保证服务器端不再发送数据，但是这样的前提是：在第二次挥手的时候，必须服务器端也不再发送数据，并且，开启延迟应答。

• 为什么客户端要等待2MSL再关闭连接：

  • 为了防止客户端的最后一个ACK没有到达服务器，使得服务器端一直未关闭连接。此时客户端还能重新发送ACK给服务器，并重启2MSL计时器；
  • 为了让这次连接中的所有消息都消失在网络中，防止新的连接收到旧的失效请求。
    为什么建立连接是三次握手，关闭连接确是四次挥手:

• 建立连接时，服务器处于listen状态，当收到客户端的SYN请求时，会将响应的SYN、ACK放在同一个响应报文里发送给客户端。
• 关闭连接时，服务器收到客户端的FIN请求，表示客户端不再发送数据，但此时还可以接收数据。因此，服务器可以先响应ACK给客户端，表示收到了请求，然后将服务器端还没发送完的数据全部发送给客户端之后再发送FIN表示不再发送数据。服务器将ACK和FIN分开发送，导致多了一次数据传输。

为什么客户端最后在TIME_WAIT还要等待2MSL（最大报文存活时间）：

• 保证服务器收到客户端的最后一个ACK，若这个ACK丢失，服务器会重发一次FIN+ACK，这时客户端还没有关闭连接，就能收到重发的请求并给出响应。同时重启2MSL计时器。
• 客户端发送完最后一个ACK后，本连接持续时间内的所有报文段都会从网络中消失，新的连接中就不会收到已经关闭的旧连接中的报文。

哪些场景要缩小TIME_WAIT的时间长度？ ⭐⭐⭐
问题产生：

高并发下，会因为短连接过多等情况，产生大量的tcp连接处于TIME_WAIT状态（由服务器端主动断开连接）
由于每个连接占用一个端口号，导致端口号大量被占用，还会导致新的tcp连接无法正常连接。

总结起来，即：
1.存在大量短连接
2.由服务器端主动断开连接
3.主动断连方，有2MSL时间的等待
4.连接占用大量端口号

解决办法：
可以从两个角度进行方案解决：
（1）客户端
将HTTP的connection设置为keep-alive，让连接存活一段时间，减少短连接的产生。
（2）服务器端
允许在TIME_WAIT状态下的Socket重用，并且，缩短TIME_WAIT的时间，比如可以把2MSL减少为1MSL。

3.3 粘包和拆包问题 ⭐⭐⭐⭐

定义：
多个数据包被存储于连续内存中，在对数据包进行读取时无法确定数据包的边界，而采用一个估测值来进行数据读出。此时若双方的size不一致则会导致发送方的若干数据包到接收方粘成一团，从缓冲区看，数据包头尾紧相连，形成粘包。相对的，如果一次性发送的数据体量过大，TCP就会将数据拆分成多个包分开发送，于是就成了拆包。

原因：
* TCP是面向连接的，用流的方式进行数据传输，并且有缓冲区，而字节流或者字符流，是没有明确的开始边界和结束边界的，会导致一个包和另一个包粘到了一起，或者一个包，很大，分成两次传输，这就导致了粘包和拆包问题
* 发送方粘包是由TCP协议引起的，若连续几次的数据都很少，TCP会合并发送，此时接收方就收到了粘包数据。
* 接收方粘包是由于接收进程不及时取走数据包。接收方将接收到的数据包放入缓存，若新数据包到来时旧数据包尚未取走，则此时进程按预先设定的大小取走包就会取到粘包数据。

处理：

1. 可以将包规定为固定长度，如果不足进行补齐
2. 通过自定义协议，处理粘包和拆包问题
3. 在包中，采用分隔符进行处理，拆包的时候可以根据设定好的分隔符进行拆解和合并

4.0 TCP的重传机制 ⭐⭐⭐⭐

一般回答超时重传和快重传两种方式即可。
转载自此处
（1）超时重传
发送方在发送数据时设置一个定时器，当超过指定时间后如果还没有收到接收方的ACK响应，就会重发数据包。
（2）快速重传
与超时重传不同，快速重传不再以时间作为重传的标准，而是以数据作为重传的标准。
主要有以下三个特点：

1. 确认报文段不再顺带发送，而是立刻发送；
2. 当接收到不同顺序的报文段的时候，也会立刻发送对之前按照顺序接收的报文段的确认报文段；
3. 当发送端收到三次同样的确认报文段之后，会确定该报文段没有接收成功，触发快重传。

扩展：基于SACK实现的选择性确认重传
通过在TCP报文的头部里添加SACK信息，让接收端知道哪些数据已经被接收方成功收到了，没有被成功接收的数据是发送端发送数据在网络中丢失了，还是网络延迟导致数据尚未被传到接收端，还是数据被成功接收只是接收端的ACK没有成功传达过来。

虽然SACK对于已经重复传递到的数据没有直接的事先预防功能，但是可以通过SACK调整后面网络的传递状态：

-1) 重传控制：通过 SACK，发送方可以了解到对方已经收到了哪些数据，从而可以针对未收到的数据进行重传。即使某些数据由于网络延迟或其他原因导致重复发送，发送方仍然可以根据 SACK 信息进行适当的重传控制，以确保数据的可靠传输。
-2) 拥塞控制：SACK 可以提供更准确的拥塞控制信息。通过了解对方已经成功接收到的数据，发送方可以更好地评估网络的拥塞状况，并根据需要调整发送速率、拥塞窗口大小等参数。这有助于避免网络拥塞或减轻拥塞状况，提高网络的整体性能和吞吐量。
-3) 故障诊断和网络优化：SACK 可以提供对网络性能和链路质量的有用信息。通过分析 SACK 报文，可以检测到数据包丢失、乱序、重复等问题，并通过诊断和优化网络来改善传输质量和性能。
-4）改进流量控制：SACK 可以帮助发送方更好地了解接收方的处理能力和接收窗口大小。通过根据 SACK 信息调整发送速率和发送窗口大小，可以更有效地管理数据流量，避免数据的过度发送和网络的拥塞。

4. TCP流量控制：

流量控制是为了调整发送方的发送速率，使得接收方来得及接收。
接收方的确认报文中有一个窗口字段，用来控制发送方的窗口大小，从而控制发送速率。
小林coding详解

5. TCP拥塞控制：

拥塞控制是为了降低整个网络的拥塞程度。当网络出现拥塞时，分组丢失引发重传，继而加重拥塞程度，因此需要控制。发送方维护一个叫做拥塞窗口的状态变量cwnd，实际决定发送数据量的还是发送窗口。

• 慢启动 & 拥塞避免：
  • 发送最初执行慢启动，cwnd = 1，发送方只能发送一个报文段。发送方每次收到ACK后将cwnd加倍。
  • 为避免成倍增加的cwnd使得网络拥塞的可能增加，设置慢启动阈值ssthreash。当cwnd >= ssthresh的时候，进入拥塞避免，每次只能将cwnd的值加一。
  • 若出现超时，则将 ssthresh减半，cwnd=1，重新开始慢启动。
• 快速重传 & 快速恢复：
  • 在接受方，每次只确认收到的最后一个有序报文段；
  • 在发送方，若收到m2的3次重复ACK，则可以确认m3丢失，此时执行快速重传，即立即重传m3；同时，由于只是丢包而不是网络拥塞，执行快速恢复：ssthresh = cwnd / 2 ，cwnd = ssthresh

对比流量控制和拥塞控制的具体介绍，我们很容易看出，流量控制是为了调节发送方发送数据的节奏，保证收发双方的相互协作，而拥塞控制是为了调节传输过程中的网络状态。
调节流量控制主要通过滑动窗口实现数据量的调节，滑动窗口的实际运行与操作系统中的缓冲区运行状态相关联，而拥塞控制主要通过拥塞窗口进行维护，拥塞窗口会根据网络的拥塞状态进行动态调整。需要注意的是，滑动窗口也是动态可调节的。

6. TCP与UDP区别：

1. 连接：TCP面向连接（传输前需要在双方建立可靠连接）；UDP非面向连接（不需要在传输前建立连接），直接往对面发送就行了；
2. TCP可靠交付，有序交付；UDP尽可能最大交付，不保证有序；
3. TCP面向字节流（TCP把上层到达的数据看作字节流，太大会划分，太小可累积）；UDP面向报文(应用层交给UDP多大的报文他就直接转发这个报文)；
4. TCP有流量控制和拥塞控制，UDP的吞吐量只受数据生成速率、收发性能、带宽等影响；
5. TCP需要维护连接，需要的资源更多；
6. TCP全双工点对点通信，UDP可以一对一、一对多、多对一、多对多通信。

7. TCP如何实现可靠交付：

1. 序列号：只确认最后一个有序到达的数据包，保证有序；
2. 校验和：每个数据包保持一个端到端的校验和，接收方收到之后检查数据在传输过程中有没有改变，若发生了改变则丢弃；
3. 流量控制：保证接收方缓冲区足够接收数据，防止丢失；
4. 拥塞控制：降低网络拥塞程度，防止数据包丢失；
5. 停止等待：发送一个数据包之后暂停发送，等到接收到对方的确认后在发送下一个数据包；若接收方接收到重复数据包则丢弃，但仍需返回确认；
6. 超时重传：若超时未接受到对方的确认，立即重传数据包。

8. 如何让UDP实现可靠传输：

RUDP、RTP、UDT
首先udp是一个不可靠的传输层协议，要让他实现可靠传输，必须在应用层上进行一些处理，也就是模仿tcp协议的可靠传输方式。
提出思路：
原理上，可以模仿tcp协议，tcp实现可靠传输主要是靠三个：确认机制、重传机制、滑动窗口机制。因此，可以模仿tcp，比如在数据包头部添加序号，设置一个超时计时器触发超时重传，并且设置缓冲区等等进行改进。

目前比较成熟的方式是RUDP、QUIC。
RUDP提供一组数据服务质量增强机制，如拥塞控制的改进、重发机制及淡化服务器算法等。
QUIC就是http3.0中使用的方式，因为http3.0之前都是用tcp的，tcp本身有一些缺点，比如发生阻塞会影响全部http的连接，而udp可以防止这一点，所以http3.0就在传输层用了udp协议，然后QUIC协议也是有三次握手的连接过程的，可以保证了数据包的可靠传输。

9. TCP/UDP使用场景：

TCP（质量高）：

• HTTP、HTTPS、FTP、邮件传输协议等需要可靠交付的协议；

UDP（速度快）：

• 音频、视频等对实时性要求较高的多媒体通信；
• 数据包传输量较少的协议：如DNS；
• 广播、多播通信

10. HTTP常见状态码

1XX：信息状态码

• 100 Continue，到目前为止都很正常

2XX：成功状态码

• 200 OK：成功处理请求
• 204 No Content：成功处理请求，但响应报文的数据主体为空，一般用在客户端不需要服务器返回数据时；
• 206 Partial Content：成功处理请求，但客户端进行了范围请求，响应报文只包含Content-Range范围内的数据。

3XX：重定向

• 301 Moved Permanently：永久重定向，资源永久地移动到了另外一个URI，服务器一般会返回这个URI；
• 302 Found：暂时重定向，其他同上；
• 303 See Other：同302，但明确客户端需要用GET；
• 304 Not Modified：客户端发送附带条件的请求时，不满足条件，返回时无响应主体；
• 307 Temporary Redirect：同302，但明确客户端不使用GET。

4XX：客户端错误

• 400 Bad Request：请求报文中有语法或参数错误，服务器无法理解导致无法处理；
• 401 Unauthorized：需要认证或认证失败；
• 403 Forbidden：对请求资源的访问被拒绝；
• 404 Not Found： 服务器找不到对应资源。

5XX：服务器错误

• 501 Internal Server Error：服务器出错；
• 503 Service Unavailable：服务器忙或服务器正在维护，无法请求。

11. HTTP请求报文：

• HTTP请求行：请求方法(GET\POST\HEAD)、URL、协议版本
• HTTP请求头：user-agent、accept、host
• 空行
• 请求数据主体：POST传输表单等数据时使用

12. HTTP 2.0与HTTP 1.1的区别：

HTTP 1.1新特性：

• 默认长连接
• 支持流水线
• 支持同时打开多个TCP连接
• 支持虚拟主机
• 增加状态码100
• 支持分块传输编码
• 新增缓存处理置零max-age

HTTP 1.X缺点：实现简单但性能低

• 需要打开多个连接才能实现并发和缩短延迟；
• 不压缩请求和响应首部，增加不必要的流量；
• 不支持有效的资源优先级，导致底层TCP连接利用率不高。

HTTP 2.0 与HTTP 1.X：

1. 服务器端推送：客户端在请求一个资源时，服务器会将相关资源一同返回，客户端不需要再次发送请求；比如客户端请求main.html时，服务器见script.js与style.css一同发送给客户端；
2. 请求和响应首部压缩：HTTP 1.1首部含有大量信息，每次都要重复发送。HTTP 2.0的客户端和服务器共同维护一个出现过的首部字段表，避免重复传输。此外，2.0还会使用Huffman编码对首部字段进行压缩。
3. 新的二进制形式：HTTP 1.X是基于文本的，文本形式多样，而二进制只有01组合，因此使用二进制形式更加健壮；
4. 多路复用：即连接共享，每个request对应一个id，一个连接中可以有多个request，接收端再根据id将每个request归属到不同的请求中。

13. Cookie Session区别：

Cookie和Session都是浏览器请求服务器时候，保存的用户会话信息。
(1) Cookie

1. 它是服务器发送到用户浏览器并保存在本地的一小块数据，浏览器下一次向同一个服务器发送请求时，会携带该部分数据发送给服务器，主要用途包括：会话状态管理、用户浏览器行为追踪等。很多公司喜欢根据cookie数据捕捉用户的喜好，一次推荐更精准的信息，但同时也会有隐私安全隐患，所以浏览器上通常会经过用户允许才会添加cookie记录。
2. 执行流程：
   用户第一次访问服务器，服务器创建cookie；
   服务器返回时携带该cookie并保存在本地；
   下次浏览器再次发起请求时携带该cookie。

(2) Session

1. Session会根据浏览器与服务器的一次完整会话记录所需的属性和配置，并保存在服务器端。
2. 执行流程：
   浏览器首次访问服务器时，服务器创建Session对象，并创建cookie，将cookie的值保存在Sessionid当中；
   cookie按照上一小节的内容进行传递；
   再次访问服务器时会根据cookie的值判断是否需要创建Session。

(3) 两者的区别
1. session在服务器，cookie在客户端（浏览器）。因此，cookie的存储容量较小，而对于服务器而言，session会消耗一定的内存资源，session的大小取决于服务器端提供的存储能力。于是，cookie是一种可以长期存储的数据信息，存储时间与设置的过期时间有关，而session存储时间较短，一般是30分钟；
2. session存放在服务器端，数据安全性较高；cookie存放在本地，容易被篡改，安全性较低。
3. cookie支持跨域名访问，session不支持。
4. cookie只能采用ASCII字符串，session能够存储任何类型的数据。
5. session默认放置在服务器的一个文件里，但其实还可以放在数据库或内存中；
6. session的实现依赖session_id，一般需要使用cookie来获取session_id，但也可以在URL中传递session_id;
7. 用户验证这种场合一般使用session；
8. 维持一个会话（广义session）的核心就是客户端的唯一标识：session_id。

14. WebSocket:

HTTP的缺陷：单向通信，当客户端想知道服务器的状态时需要轮询，轮询效率低；

WebSocket：

• 实现了服务器端推送，真正平等的双向通讯；
• 没有同源限制，客户端可以与任意服务器通信；
• 可以传输文本或二进制数据；
• 数据格式轻量，性能开销小，通信高效。

15. POST与GET的区别：

GET：

• ‘读取’一个资源。
• 反复读取不应该有副作用，也即‘幂等’的。
• 因为是读取，就可以将请求的数据缓存，降低开销；

POST：

• ‘提交’一些信息让服务器执行一定的操作；
• 这往往会产生一些结果，也即‘不幂等’的。
• 不幂等就表示不能随意执行多次，因此不能缓存，也不能保存书签。

• 数据：GET只能由输入或点击一个URL触发，要携带数据只能下载URL附带的questionstring里。
  POST一般由提交表单触发，提交时将表单编码在HTTP请求body里。
• 安全性：不管GET还是POST，只要是携带在URL里的参数都是明文的，因此从攻击的角度来说一样的不安全。只不过GET携带的数据都在URL上，相较于请求体中的数据更容易泄漏。唯一的安全手段就是HTTPS。
• 长度：有个说法是GET有长度限制，其实这个URL的长度限制，并且不同浏览器的限制不太一样。
• TCP次数：GET请求体中的内容是空的，只需要一次连接，服务器就能取出请求头里的信息并返回相应资源。而优化的POST第一次发送请求头，服务器进行验证返回100 continue，这时候再发送数据，避免无法处理的请求也传输了数据浪费带宽。

16. IPv4和IPv6的区别：

(1) IPv4与IPv6是什么
IPv4：IPv4是计算机网络使用的数据报传输机制，是第一个被广泛部署的IP协议，使用32位（4字节*8）地址，每一个连接Internet的设备，都会为其分配一个唯一的IP地址。IPv4地址以点分十进制表示，如192.168.0.1。

IPv6：IPv6是用来替代IPv4的下一代协议，解决了网络地址资源匮乏问题，地址长度为128位，使用以冒号分隔的十六进制数字表示，如3ffe:1900:fe21:4545:0000:0000:0000:0000。

(2) IPv4与IPv6的区别

1. 安全性
   IPv6中，集成了Internet协议安全标准，加入了关于身份验证、数据一致性和保密性的内容。比IPv4更加安全。且，IPv6的网络安全不像IPv4是可选项，IPv6里的网络安全项是强制性的。
2. 地址空间范围不同
   IPv4使用32位地址，IPv6使用128位地址，网络地址空间范围更大。
3. 首部长度不同
   IPv6的首部长度是40个字节。IPv4的首部长度是24字节。但是，IPv6首部结构比IPv4简单。
4. 地址类型不同
   IPv4具有三种不同类型的地址：多播，广播和单播。IPv6还具有三种不同类型的地址：任意广播，单播和多播。
5. 可选字段不同
   IPv4具有可选字段。而，IPv6的可选项不放入报头，而是放在一个个独立的扩展头部中。
6. 配置
   在IPv4中，新装的系统必须配置好才能与其他系统通信。
   在IPv6中，配置是可选的，且IPv6协议支持地址自动配置，即插即用。
7. 数据包大小
   IPv6，最小数据包大小为1208字节，比IPv4大。

17.TCP的长连接与HTTP的长连接有什么区别

（1）HTTP长连接

HTTP长连接是由应用层实现的，可以让同一个TCP连接来发送和接收多个HTTP请求与响应，也就是复用了TCP连接，就可以大胆的告诉面试官，HTTP长连接过程中，TCP连接没有挥手断开连接！

这样的好处就是减少了HTTP短连接造成的多次握手挥手建立和销毁TCP连接，所带来的开销，节约资源，提高效率。

在HTTP 1.0中默认是关闭的，如果要打开，需要把Connection变成Keep-Alive，在HTTP 1.1和以后的版本，一般默认开启Keep-Alive。

（2）TCP长连接

TCP的长连接与HTTP的不同，是由内核来实现的，其实就是TCP的保活机制，其可以在双方没有数据交互的情况，通过探测报文，来确定对方的TCP连接是否存活。

如果7200秒内双方都没有数据交互，此时服务器端会向客户端发送一个心跳探测报文。客户端收到后立即回复对该报文的ACK确认报文，如果客户端没有回复，服务器端会根据保活机制的默认设置，每隔一段时间，发一次心跳探测报文，若到达了最大重发次数后，仍然没有得到回复，会认为客户端已经宕机，此时服务端会断开连接。如果收到了回复，就会重置保活时间。

18. 什么是MSS和MTU

1）MTU：最大传输单元（Maximum Transmission Unit）

一个网络包的最大长度。

MTU是数据链路层，提供给上层（IP层）的，最大的一次传输数据大小。

所谓ip层的分片，就是当ip数据报大于MTU的时候，进行的分片操作，用片偏移这个字段来记录数据报在原数据中的相对位置。

（2）MSS：TCP最大报文段长度（Maximum Segment Size）

除去IP和TCP头部之后，一个网络包所能容纳的TCP数据的最大长度。

TCP提交给网络层的最大报文段长度，在MTU的基础上，减去IP首部和TCP首部，就是MSS的长度，MSS是TCP用来限制应用层最大的发送字节数。

19. 优化 HTTP/1.1 协议的思路

摘自小林coding
1.通过缓存技术来避免发送 HTTP 请求。客户端收到第一个请求的响应后，可以将其缓存在本地磁盘，下次请求的时候，如果缓存没过期，就直接读取本地缓存的响应数据。如果缓存过期，客户端发送请求的时候带上响应数据的摘要，服务器比对后发现资源没有变化，就发出不带包体的 304 响应，告诉客户端缓存的响应仍然有效。
2.减少 HTTP 请求的次数，有以下的方法：
将原本由客户端处理的重定向请求，交给代理服务器处理，这样可以减少重定向请求的次数；
将多个小资源合并成一个大资源再传输，能够减少 HTTP 请求次数以及 头部的重复传输，再来减少 TCP 连接数量，进而省去 TCP 握手和慢启动的网络消耗；
按需访问资源，只访问当前用户看得到/用得到的资源，当客户往下滑动，再访问接下来的资源，以此达到延迟请求，也就减少了同一时间的 HTTP 请求次数。
3.通过压缩响应资源，降低传输资源的大小，从而提高传输效率，所以应当选择更优秀的压缩算法。

操作系统

1.举例说明 conccurent.future 的中线程池的用法

concurrent.futures提供了使用线程或进程工作池（pools of workers）来运行任务的接口。这个API使得多线程和多进程并发变得非常类似。它是在threading和multiprocessing接口上的封装。

Executors被用来管理工作池；futures被用来管理workers运行的结果。
————————————————
原文链接：https://blog.csdn.net/qq_16912257/article/details/79661863

2.说一说多线程，多进程和协程的区别。

补充：
关于进程和线程等计算机系统内部运行与调度的形象解释：
进程与线程的

• 多进程：进程是拥有资源的基本单位，其拥有独立的堆空间和栈空间。由操作系统调用。
• 多线程：线程是独立调度的基本单位，线程不拥有资源，但可以访问其隶属进程的资源。线程共享堆空间，拥有独立的栈空间。由操作系统调用。
• 协程：协程又叫微线程，是将线程切割成多段执行，可以随时暂停，由程序员控制。协程的效率比多线程高，因为其不需要进行竞争和切换，同时使用多路复用来同时管理多个接口的请求。

3.简述 GIL

GIL(全局解释器锁)：是只有CPython解释器中才有的线程锁。一个进程中只有一个GIL，一个线程只有获取了GIL才能执行，GIL释放后需要线程间的竞争和切换，使得Python的多线程反而耗时。

4.进程之间如何通信

• 管道：管道是半双工的，要双向通信必须建立两个管道；
• 消息队列：进程同时维护消息队列，通过写消息和读消息进行通信；
• 共享内存：进程间共享内存，类似于线程共享进程的堆空间，可以直接通过数据的读写进行通信。

5.IO 多路复用的作用？

多路：多个连接，复用：一个或少量线程，即利用一个或少量的线程来同时管理多个连接。在一个或少量的线程中不停查看多个接口的状态，其中任何一个任务完成IO就去执行它。

6.select、poll、epoll 模型的区别？

• select：轮询多个任务，任何一个完成了IO就去执行后续操作。限制最多同时监视1024个接口；
• poll：同select，但是取消了1024的限制；
• epoll：不再轮询，而是使用回调来通知状态。

7.什么是并发和并行？

• 并发：在一段宏观的时间上多个任务同时执行，实际上是分时间片轮转执行。
• 并行：多核的条件下，同一时刻两个及以上进程同时执行，进程间互不抢占资源。
  详细内容补充
  
  这张图最直接了当，图片来源自 小林coding

8.一个线程 1 让线程 2 去调用一个函数怎么实现？

将线程2作为参数传递到线程1并调用。

import threading

def fun1(t2):
	print('running fun1')
	t2.start()

def fun2():
	print('running fun2')

if __name__ == '__main__':
	t2 = threading.Thread(target=fun2)
	t1 = threading.Thread(target=fun1, args=(t2,))
	t1.start()

9.将TCP传输中的滑动窗口概念与死锁概念相结合进行简要阐述

窗口关闭不当存在的潜在风险
计算机网络中面对长期等待陷入僵局的状况往往都是通过增加一个计时器，如果等待的期限到了，那么相应的接收方就会采取主动措施。

10.解释什么是异步非阻塞？

同步与异步：主要关注消息通信机制。
• 同步就是在发出一个调用之后，调用没有得到结果之前该调用不返回。即同步是主动等待消息。
• 异步调用不会等待结果而是立即返回，然后等待被调用者使用消息、通知或者回调函数来通知调用者。即异步是被动接收消息。

阻塞与非阻塞：主要关注程序在等待时的状态。
• 阻塞是指程序在等待结果的时候被挂起，不能去完成别的任务【浪费时间】；
• 非阻塞是指程序在等待的过程中可以做别的事情【需要切换开销】。

因此，异步非阻塞是当进程提交一个请求，不需要等到返回结果，可以直接回去干别的事情。也不需要时不时来轮询一下完成了没有，只需要好好做自己的事等着回调来告诉他任务完成了。

11.threading.local 的作用？

• 问题：python多线程中，每个线程使用局部变量时，局部变量不会相互影响。但当多个线程处理全局变量时，这个全局变量是共享资源，线程之间相互干扰导致结果错误。
• 解决：Python提供了 threading.local 类，将这个类实例化得到一个全局对象，但是不同的线程使用这个对象存储的数据其它线程不可见(本质上就是不同的线程使用这个对象时为其创建一个独立的字典)。