厚积薄发打卡Day74 ：【MSUP】操作系统与计算机基础（下）

最新推荐文章于 2024-11-05 18:00:59 发布

coolgwayne

最新推荐文章于 2024-11-05 18:00:59 发布

阅读量190

点赞数

分类专栏：面试题计算机网络 MSUP 文章标签：面试计算机网络 tcpip udp

本文链接：https://blog.csdn.net/qq_42191980/article/details/119090153

版权

面试题同时被 3 个专栏收录

12 篇文章 0 订阅

订阅专栏

MSUP

11 篇文章 0 订阅

订阅专栏

计算机网络

1 篇文章 0 订阅

订阅专栏

前言

在看狂神频道的时候偶然发现下图，感触颇深。特别在当今【程序 = 业务 + 框架】思想盛行的开发者中，夯实基础基础显得格外重要，因此开此专栏总结记录。

计算机网络：

计算机的基础知识是工程师基本能力的体现，也是面试前必须要牢牢掌握的部分。

在这里插入图片描述

计算机网络也是非常重要的基础知识，服务之间通过不同的网络协议进行交互，例如http 协议、rpc 协议等。在java 面试中，网络支持被考到的几率非常大。
首先你应该深刻理解网络的四七层模型，这是网络知识的基础。

4/7网络模型

另外两个非常重要的网络协议，就是 http 和tcp 的这两个协议也是服务交互中使用最多的协议。

七层模型：

第一层：物理层（Physical）
1. 主要定义了物理设备标准，如网线的接口类型、光纤的接口类型、传输介质的传输速率等；负责将数据以比特流的方式发送、接收。
第二层：数据链路层（Data-Link）
1. 负责准备物理传输，CRC校验，错误通知，网络拓扑，流控等。
第三层：网络层（NetWork）
1. 负责管理网络地址，定位设备，决定路由；IPv4 IPv6
第四层：传输层（Transport）
1. 负责分割、组合数据，实现端到端的逻辑连接三次握手，面向连接和非面向连接的服务，流控等（主机到主机的层次）
第五层：会话层（Session）
1. 负责建立、维护、控制会话工单、半双工、全双工三种通信模式的服务。
第六层：表示层（Presentation）
1. 负责数据的编码、转换数据压缩、解压，加密、解密。
第七层：应用层（Application）
1. 确定通信对象，提供访问网络服务的接口。

一句话：Please Do Not Tell Stupid People Anything.

在这里插入图片描述

四层模型：

图源：4/7层网络模型

在这里插入图片描述

TCP/IP协议

建立连接三次握手
关闭连接四次挥手
- tcp 协议中的三次握手建连与四次挥手断连是一个高频考点。
报文状态标志与连接状态
nagel算法与ack延迟
- 另一个知识点是nagel 算法和ACK延迟需要了解，产生的背景是要解决小包问题，提高数据载荷比知道对于延迟比较敏感，且发送数据频率较低的场景可以关闭那种算法。
KeepAlive
- 关于tcp 的keep alive 是一种长时间没有数据发送的场景下，tcp 保持连接可用的机制，需要知道tcp keep alive 的开启和设置方式。
滑动窗口与流量控制
- 最后一点需要明白tcp 是如何通过滑动窗口机制来实现流量控制的。

UDP

除了HTTP和TCP 外UDP也是一个比较常见的传输层协议，UDP的特点是非连接，非可靠传输，但是效率非常高。

非连接
非可靠传输
效率高

HTTP

这里需要掌握http 协议的规范，知道协议中的method header cookies 需要了解常见的状态码含义，例如404 503 302等，另外还有https 的交互流程也需要了解，

http2协议目前还比较新，对于http2协议的了解，可以在一定程度上体现对新技术的关注程度，可以关注。http2 多路复用 stream 流式交互流量控制、服务端推送同步压缩等新特性。

协议
- Method
  
  图源：HTTP协议的几种请求方式method
- Header
  - Http 协议Header
- Cookies
  - HTTP协议-Cookie和Session详解
    
    例如用户A在超市购买的任何商品都应该放在A购物车内，不论用户A是什么时间购买的，这都是属于同一个会话，不能放入用户B或用户C的购物车里面，这不属于同一个会话。
    
    而Web应用程序是使用HTTP协议传输数据的，HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务端的链接就会关闭，再次交换数据需要建立新的链接。这就意味着服务器无法从链接上面跟踪会话。
    
    即用户A购买了一件商品放入购物车内，当再次购买商品时服务器已经无法判断该购买行为是属于用户A的还是用户B的会话了。要跟踪该会话，必须引入一种机制。
    
    Cookie就是这样的一种机制，它可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都是采用Cookie来跟踪会话。
UrlEncode
状态码
- HTTP常见状态码（14种）
  
  各类别常见状态码：
  
  2xx （3种）：
  - 200 OK：表示从客户端发送给服务器的请求被正常处理并返回；
  - 204 No Content：表示客户端发送给客户端的请求得到了成功处理，但在返回的响应报文中不含实体的主体部分（没有资源可以返回）；
  - 206 Patial Content：表示客户端进行了范围请求，并且服务器成功执行了这部分的GET请求，响应报文中包含由Content-Range指定范围的实体内容。
  3xx （5种）：
  - 301 Moved Permanently：永久性重定向，表示请求的资源被分配了新的URL，之后应使用更改的URL；
  - 302 Found：临时性重定向，表示请求的资源被分配了新的URL，希望本次访问使用新的URL；
  - 303 See Other：表示请求的资源被分配了新的URL，应使用GET方法定向获取请求的资源；
    - 302与303的区别：后者明确表示客户端应当采用GET方式获取资源
  - 304 Not Modified：表示客户端发送附带条件（是指采用GET方法的请求报文中包含if-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since中任一首部）的请求时，服务器端允许访问资源，但是请求为满足条件的情况下返回改状态码；
  - 307 Temporary Redirect：临时重定向，与303有着相同的含义，307会遵照浏览器标准不会从POST变成GET；（不同浏览器可能会出现不同的情况）；
  4xx （4种）：
  - 400 Bad Request：表示请求报文中存在语法错误；
  - 401 Unauthorized：未经许可，需要通过HTTP认证；
  - 403 Forbidden：服务器拒绝该次访问（访问权限出现问题）
  - 404 Not Found：表示服务器上无法找到请求的资源，除此之外，也可以在服务器拒绝请求但不想给拒绝原因时使用；
  5xx （2种）：
  - 500 Inter Server Error：表示服务器在执行请求时发生了错误，也有可能是web应用存在的bug或某些临时的错误时；
  - 503 Server Unavailable：表示服务器暂时处于超负载或正在进行停机维护，无法处理请求；
  ————————————————
  版权声明：本文为CSDN博主「Running_96」的原创文章
  原文连接：https://blog.csdn.net/banana960531/article/details/85621865
Https
- HTTPS是一种通过计算机网络进行安全通信的传输协议，经由HTTP进行通信，利用SSL/TLS建立全信道，加密数据包。
- HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。
Http2
- 多路复用
- Stream
- 流量控制
- 服务端推送
- 头部压缩

QUIC

最后可以对QUIC协议进行一些了解。QUIC协议已经被标准化为HTTP3协议。

一泡尿的时间，快速读懂QUIC协议

从表面上看：QUIC 非常类似于在 UDP 上实现的 TCP + TLS + HTTP/2。由于 TCP 是在操作系统内核和中间件固件中实现的，因此对 TCP 进行重大更改几乎是不可能的（TCP 协议栈通常由操作系统实现，如 Linux、Windows 内核或者其他移动设备操作系统。修改 TCP 协议是一项浩大的工程，因为每种设备、系统的实现都需要更新）。但是，由于 QUIC 建立在 UDP 之上，因此没有这种限制。QUIC 可以实现可靠传输，而且相比于 TCP，它的流控功能在用户空间而不在内核空间，那么使用者就不受限于 CUBIC 或是 BBR，而是可以自由选择，甚至根据应用场景自由调整优化。

QUIC 与现有 TCP + TLS + HTTP/2 方案相比，有以下几点主要特征：

1）利用缓存，显著减少连接建立时间；

2）改善拥塞控制，拥塞控制从内核空间到用户空间；

3）没有 head of line 阻塞的多路复用；

4）前向纠错，减少重传；

5）连接平滑迁移，网络状态的变更不会影响连接断线。

QUIC是基于UDP协议的，但QUIC提供了类似tcp 的可靠性保障和流量控制。QUIC可以有效避免http2协议的前序包阻塞问题，能实现零RTT建连提供FEC前向纠错能力。

避免前序包阻塞（HOL阻塞）
零RTT连接
FEC前向纠错

TCP详解.

TCP特点

基于连接
可靠传输
双工通信
基于字节流而非报文

TCP实现细节

8种报文状态
滑动窗口机制
KeepAlive
Nagel算法

我们来看一下TCP协议的知识点。

tcp 是传输层协议，对应OSI网络模型的第四层传输层
TCP协议的特点是基于连接，也就是传输数据前需要先建立好连接。然后再进行传输TCP连接，一旦建立就可以在连接上进行双向的通信。
tcp 的传输是基于字节流，而不是报文将数据按字节大小进行编号。接收端通过ACK来确认收到的数据编号。通过这种机制，TCP协议能够保证接收数据的有序性和完整性。因此tcp 能够提供可靠性传输。
tcp 还能提供流量控制能力，通过滑动窗口来控制数据的发送速率。
滑动窗口的本质是动态缓冲区，接收端根据自己的处理能力在tcp 的header 中动态调整窗口大小，通过ACK硬拿包通知给发送端。发送端根据窗口的大小调整发送的速度。仅仅有了流量控制能力还不够。tcp 协议还考虑到了网络问题，可能会导致大量重传，进而导致网络情况进一步恶化。
因此，tcp 协议还提供了拥塞控制。tcb 处理拥塞控制主要是用到了慢启动拥塞，避免拥塞发生，快速恢复。这个算法感兴趣的同学，可以做进一步的了解。
除了TCP协议的特点，还可以进一步了解tcp 协议的报文状态。
滑动窗口的工作流程。keep alive的参数设置。和negal算法的规则等一些细节。
另外还有典型的TCP协议问题，例如特定场景下NB和ACK延迟机制配合使用可能会出现延迟40毫秒，超时后才能回复ACK包的问题。

三次握手：

接下来我们来看看tcp 建连的三次握手。TCP是基于连接的，所以在传输数据前需要先建立连接。tcb 在传输上是双工传输，不区分client 端与server 端。为了便于理解，我们把主动发起建连请求的一端称作client 端。
把被动建立连接的一端称作server 端。看下面这张图，建连的时序是从上到下左右两边的绿色字，分别代表client 端与server 端当时的连接状态。
首先建立连接前需要server 端，先监听端口。因此，server 端建立连接前的初始状态就是listen 状态，这时可耐的端准备建立连接，先发送一个syn 同步包。发送完同步包后，client 端的连接状态就变成了syn send 状态。server 端收到syn 后，同意建立连接，会向client 端回复一个ACK。
由于tcp 是双控传输，server 端，也会同时向client 端发送一个同步请求syn 申请server 向client 方向建立连接。发送完ACK和SYN后，server 端的连接状态就Bean成了syn received。
client 收到server 的ACK后client端的连接状态就变成了establish 的状态。
同时，client 端向server 端发送ACK响应回复server 端的syn 请求，所有端收到client 端的ACK后，server 端的连接状态。就变成了establish 的状态。此时连接完成，双方随时可以进行数据传输。
在面试时需要明白，三次握手是为了建立双向的连接，需要记住client 端和server 端的连接状态变化。
另外回答建连的问题时。可以提到syn 洪水攻击发生的原因就是server 端收到client 端的syn 请求后发送了ACK和SYN，但是client 端不进行回复。导致server 端大量的连接处在syn receive 状态，进而影响其他正常请求的连接。
可以通过设置linux 的tcp 参数， tries 等于零来加快半连接的回收速度，或者调大max syn backlog。来应对少量的syn 洪水攻击。

四次挥手：

tcp 连接的关闭通信，双方都可以先发起，我们暂且把先发起的一方看作client。从图中可以看出，通信中的client 和server 两端的连接状态都是establish 的状态。
然后client 端先发起了关闭连接，请求client 向server 发送了一个FIN包，表示client 端已经没有数据要发送的，然后client 端就进入了FINwait 一状态。
server 端收到FIN后返回ACK，然后进入close wait 状态，此时server 属于半关闭状态，因为此时client 向server 方向。已经不会再发送数据了，可是server 向client 端可能还有数据要发送。
当server 端数据发送完毕后，设备端会向client 端发送FIN表示server 端也没有数据要发送的。
这时server 进入last ACK状态。就等待client的应答，就可以关闭连接了。
client 端收到server 端的FIN后回复ACK然后进入time_wait 状态，time_wait 的状态下需要等待2倍的msl 就是最大报文段生存时间。
来保证连接的可靠，关闭之后才会进入close 状态，而server 端收到ACK后直接就可以进入close 状态。
- 这里面试官可能会问，为什么需要等待两倍的msl 之后才能关闭连接？
  - 原因有两个，第一要保证TCP协议的全双工连接。能够可靠关闭。
  - 第二，要保证这次连接中重复的数据段能够从网络中消失，防止端口被重用的时候，可能会产生数据混淆了。
从这个交互流程上可以看出，无论是间联还是断连，都是需要在两个方向上进行。只不过建连时server 端的syn 和ACK。两个包合并为一次发送而断开连接时，两个方向的数据发送的停止时间可能是不同的，所以无法合并FIN和ACK发送。

这就是建连的时候必须要三次握手，而断连的时候呢，必须要4次的原因。

另外，在回答断连的问题时，可以提到，实际应用中有可能会遇到大量socket 处在time wait 或者close wait 状态的问题。
，可能会产生数据混淆了。
从这个交互流程上可以看出，无论是间联还是断连，都是需要在两个方向上进行。只不过建连时server 端的syn 和ACK。两个包合并为一次发送而断开连接时，两个方向的数据发送的停止时间可能是不同的，所以无法合并FIN和ACK发送。

这就是建连的时候必须要三次握手，而断连的时候呢，必须要4次的原因。

另外，在回答断连的问题时，可以提到，实际应用中有可能会遇到大量socket 处在time wait 或者close wait 状态的问题。
一般开启linux 的tcp 参数，tw reviews 和tw recycle 能够加快time_wait的状态的回收，而出现大量的close wait 状态，一般是被动关闭的一方可能存在代码的bug，没有正确关闭连接导致的