前端面试之吊打面试官 网络篇

用户4657561481858
187 阅读22分钟

GET和POST的请求的区别

  • 传递的参数不同，POST传递的参数在request body中，GET传递的参数在url后拼接
  • GET请求一般用于查询，POST一般用于提交某种信息进行某些修改操作
  • POST相对GET请求安全
  • GET请求会被浏览器主动缓存，POST不会，要手动设置
  • GET请求长度有限制，POST没有

POST和PUT请求的区别

  • PUT请求为更新数据
  • POST为创建数据

HTTP 1.1 和 HTTP 2.0 的区别

  • 二进制协议：HTTP1.1的解析是基于文本，而HTTP2使用二进制，将请求和响应分割为更小的帧，从而实现多路复用。
  • 多路复用：在一个连接里，客户端和服务器都可以同时发送多个请求或回应，而且不用按照顺序一一发送，这样避免了HTTP队头阻塞，但是TCP的队头阻塞依旧存在。
    • HTTP队头阻塞
    • TCP队头阻塞
  • 头部信息压缩：由于HTTP1.1每次请求都会带上所有信息，比如Cookie，这样会很浪费性能，HTTP2引入头部压缩，一方面将头部信息使用gzip压缩后再发送，另一方面客户端和服务器同时维护一张头部信息表，所有字段都会存入这张表，生成索引，只发送索引就可以。
  • 服务器推送：HTTP2允许服务器向客户端主动发送资源，只限于静态资源如css，img等

http2.0比1.1慢的情况

网络差，因为http2.0是采用多路复用，所以当网络环境差的时候就会让连接多次重传，浪费时间。还有头堵塞的情况见下面。

http1.1和http1.1

http1.1比http1多出来持久化连接也就是connection：keep-alive，允许客户端和服务器在同一 TCP 连接上进行多个请求/响应交换，减少了建立新连接的开销。

http2.0与http3.0

  • 协议基础
    • http2：基于传统的tcp协议连接，依赖于tcp来传递数据
    • http3：基于QUIC（Quick UDP Internet Connections）协议，它是由 Google 开发的一种基于 UDP 的协议。QUIC 协议在 HTTP/3 中取代了传统的 TCP 协议。
  • 建立连接
    • http2：tcp建立连接的时候每次都会进行三次握手，导致连接时间变长
    • http3：基于quic协议，采用0-RTT连接建立，能够在首次连接时就传输数据，显著减少延迟
  • 加密：
    • http2：http2协议没有强制使用tls加密
    • http3：强制使用tls加密
  • 总结
    • http2：适用于网络连接稳定，延迟低的网络环境下
    • http3：适用于高延迟、高丢包的网络环境（如移动网络、Wi-Fi 网络）以及需要快速响应的应用场景（如视频流媒体、实时通信等）。

HTTP队头堵塞

在HTTP/1.1中，默认情况下，浏览器对同一域名下的并发连接数有限制（通常为6-8个），这意味着浏览器同一时间最多只能与服务器建立6-8个连接。同时，在同一连接中，请求和响应是按照顺序处理的，也就是说，一个请求需要等待前面的请求响应完成后才能开始处理。如果前面的请求处理时间较长，后续请求就必须等待，从而导致队头阻塞。

总结：HTTP队头堵塞是指在同一域名下浏览器的连接数有限制，并且请求要在连接内按顺序处理，这样就会导致某个请求的延迟或阻塞会影响后续请求的处理。

TCP队头阻塞

在一个TCP连接中，如果某个数据包在传输过程中失误或者丢失，那么在这个数据包后发送的所有数据都需要等待，直到该数据被重新传输。这种情况会导致接收方在TCP缓冲区中，后续的数据包被阻塞在错误数据包之后，无法继续处理，即被堵塞在队头

总结：TCP协议为了保证数据包的有序传输，如果一个数据包在丢失损坏后，TCP接受端会要求重新发送该数据包，直到被正确接收为止。

HTTP和HTTPS协议的区别

  • HTTPS需要CA证书，HTTP不需要
  • HTTP是明文传输，不安全。而HTTPS基于SSL进行加密，相对安全。
  • HTTP端口为80，HTTPS端口443

对HTTP请求中的keep-alive有了解吗

在HTTP协议中keep-valie是一种长连接。

在HTTP1.0中默认是每次请求/应答，客户端和服务器都会建立一次连接，请求完成后立即断开，这种是短连接。当使用keep-alive后，客户端和服务端的连接持续有效，后续的请求就会避免重复建立连接，减少服务器负担降低延迟，这种就是长连接。

使用方式就是通过在HTTP请求头中添加Connection: keep-alive字段，服务端会在响应头中添加Connection: keep-alive字段通知客户端长连接已经建立。

在HTTP1.1默认开启了长连接，除非在请求或响应头中明确关闭它。在HTTP2中使用了多路复用，允许在同一个连接上处理多个请求和相应，取代了keep-alive机制。

三次握手和四次挥手

字段理解

  • seq 序列号 随机数 seq = x 每次连接都会携带一个自己的随机序列号
  • ack 确认号 ack = seq + 1 确认上一次收到了序列号 除了第一次连接都会携带
  • ACK 确认收到序列号 ACK = 1 除了第一次连接都会携带
  • SYN 发起一个新连接 SYN = 1
  • FIN 释放一个连接 FIN = 1

三次握手

指建立一个TCP连接时，需要客户端和服务器总共发送3个包，主要作用是为了确认双方接受和发放能力是否正常。

初始化 客户端处于Closed状态，服务端处于 Listen 状态

  • 第一次握手 客户端给服务器发送一个TCP报文【向服务器请求连接】
    • SYN = 1 建立一个新链接
    • seq = x 随机序列号
    • 此时客户端处理SYN-SEND状态
  • 第二次握手 服务器接收到 SYN 报文后，回复浏览器 【同意连接】
    • SYN = 1 同意建立一个新链接
    • ACK = 1 确认收到序列号
    • seq = y 随机序列号
    • ack = x + 1 确认收到序列号是x
    • 服务端进入 SYN-REVD阶段
  • 第三次握手 浏览器收到报文后回复服务器 【收到回复】
    • ACK = 1 确认收到序列号
    • seq = x + 1 上一次浏览器发送的 seq = x 基础上 + 1
    • ack = y + 1 确认收到的序列号是服务器回复的 y
    • 服务器和浏览器同时进入 ESTABLISHED 状态
    • 此时双方连接已建立，开始传送数据

​

编辑

那为什么要三次握手呢？两次不行吗？ 为了确认双方的接收能力和发送能力都正常。服务端在发送完SYN报文后，客户端需要回复一个ACK告诉服务的确认有效。

四次挥手

刚开始双方都处于 ESTABLISHED 状态

  • 第一次挥手 向服务器发送报文
    • FIN = 1 关闭连接
    • seq = u 随机序列号
    • 浏览器进入 FIN-WAIT-1 半关闭阶段
  • 第二次挥手 服务器收到报文后，知道浏览器要断开链接，开始处理内部操作
    • ACK = 1 确认收到序列号
    • ack = u + 1 确认收到序列号为 u
    • seq = v 随机序列号
    • 服务器进入 COLSE-WAIT 处理阶段
    • 浏览器进入 FIN-WAIT-2 阶段 等待服务器处理
  • 第三次挥手 服务器处理完毕 回复浏览器
    • FIN = 1 关闭连接
    • ACK = 1 确认收到序列号
    • ack = u + 1 确认收到序列号为u
    • seq = w 随机序列号
    • 服务器进入 LAST-ACK 阶段 等待浏览器确认收到
  • 第四次挥手 浏览器收到服务器报文 回复服务器
    • ACK = 1
    • seq = u + 1
    • acl = w + 1
    • 浏览器进入 TIME-WAIT 阶段，此时TCP未释放掉，等待 2MSL(毫秒)，等待服务器收到自己的报文，然后进入 COLSE 阶段

​

编辑

为什么是四次 客户端发送FIN报文后，表示客户端当前没有数据需要处理，而不代表服务端没有数据需要处理。此时需要服务端回复ACK确认收到报文后，开始处理内部数据。当内部数据处理完后，再回复FIN可以关闭连接

数据粘包

在计算机网络中，数据粘包（Data Packet Fusion）是指在基于流的协议（如TCP）传输过程中，多个数据包在接收端被合并成一个包的现象。这个问题通常发生在发送端发送的数据量较小，但由于网络传输或TCP协议的特性，接收端会将这些小的数据包合并成一个大的数据包进行处理。

粘包的原因通常包括以下几个方面：

1. TCP协议的特性：

TCP协议是一种面向流的协议，数据在发送过程中并不会固定成包的形式，而是按数据流的方式进行传输。也就是说，发送的数据并不是以“包”的形式严格界定，而是一个个字节流。这意味着，接收方可能会把几个小包的数据合并成一个较大的包，或者将一个大包分成多个小包。

2. 发送方与接收方的处理方式不同：

  • 发送方：发送方可能以较小的数据量逐个发送消息（例如，按业务需求一次发送很小的数据块）。
  • 接收方：接收方每次调用recv()方法时，可能一次性读取到多个发送方的数据段，导致数据被合并为一个粘包。

3. 网络延迟与缓冲区大小：

由于TCP协议是可靠的，发送端会根据接收端的确认消息来决定何时发送下一个数据包。在这种机制下，多个小数据包可能会因为网络延迟、TCP缓冲区大小等因素被合并发送，最终接收端读取时可能就出现了粘包现象。

粘包的解决方法

  1. 固定长度的消息： 通过规定每个消息的固定长度，接收方每次都按照固定的长度来接收数据，从而避免了粘包问题。不过这种方式会导致一些资源浪费，因为每个数据包的长度必须满足规定大小。
  2. 特殊分隔符： 在每个消息的结尾添加一个特定的分隔符，接收方可以根据这个分隔符来确定消息的边界。例如，在文本协议中常见的\n（换行符）或\r\n（回车换行符）作为消息的结束标志。
  3. 消息头携带长度信息： 在消息的头部添加一个字段，记录消息的长度。这样接收方就可以根据长度信息，准确地知道每条消息的结束位置。比如，协议中规定前4个字节表示消息的长度，接收方根据前4个字节的值来读取具体的消息内容。
  4. TCP协议自带的流控制机制： 在应用层使用某些协议，设计协议时使用一定的机制来避免粘包和拆包问题。例如，HTTP、WebSocket等协议都在设计时考虑了消息的分界和数据包的完整性问题。

当在浏览器中输入 URL 并且按下回车之后发生了什么？

当我们在浏览器中输入一个 URL（例如 https://www.example.com）并按下回车后，浏览器会经过一系列复杂的过程来展示网页。这些过程包括 DNS 解析、建立连接、发送请求、处理响应，以及最终渲染页面。整个过程可以分为几个主要的步骤：

强缓存、协商缓存

​

编辑

1. DNS解析 (Domain Name System Resolution)

  • 浏览器首先需要将用户输入的域名（如 www.example.com）转换为对应的 IP 地址，因为计算机和服务器使用 IP 地址进行通信。
  • 过程包括：
    1. 浏览器检查本地缓存中是否已有对应的 IP 地址。
    2. 如果没有，浏览器会向本地 DNS 服务器发起请求。
    3. 本地 DNS 服务器会通过一系列递归查询找到该域名的权威 DNS 服务器，并获取对应的 IP 地址。
  • 最终，浏览器获得域名对应的 IP 地址。

2. 建立 TCP 连接

  • 浏览器获得 IP 地址后，会通过网络与该 IP 对应的服务器建立连接，通常通过 TCP 协议（传输控制协议）。
  • 如果使用的是 HTTPS 协议，浏览器还会建立一个加密的 TLS/SSL 连接，确保数据传输安全。
  • 连接的过程通常包括“三次握手”：
    1. 浏览器发送一个 SYN 请求包给服务器。
    2. 服务器收到后返回一个 SYN-ACK 包。
    3. 浏览器回应一个 ACK 包，连接建立。

3. 发送HTTP请求

  • 建立连接后，浏览器会向服务器发送一个 HTTP 或 HTTPS 请求。请求包括：
    • 请求方法（如 GET、POST 等）
    • 请求 URL（浏览器要获取的资源路径）
    • 请求头（包含一些额外的信息，如用户代理、Cookies 等）
    • 如果是 POST 请求，还会包含请求体数据。

4. 服务器处理请求并返回响应

  • 服务器接收到请求后，处理请求并返回相应的数据。这通常包括：
    1. 服务器从数据库或文件系统中获取所请求的资源（例如 HTML 文件、图片、CSS、JavaScript 等）。
    2. 服务器生成响应报文，报文中包括状态码（如 200 表示成功，404 表示资源未找到等）、响应头、以及响应体（即实际的 HTML 文本或其他资源）。
    3. 服务器将响应发送回浏览器。

5. 浏览器接收并处理响应

  • 浏览器接收到服务器返回的 HTTP 响应报文后，开始处理响应。通常包含以下步骤：
    1. 解析 HTML 文档：浏览器解析 HTML，生成 DOM 树（文档对象模型）。
    2. 加载外部资源：在解析 HTML 时，如果遇到 <link>、<script>、<img> 等标签，浏览器会发起额外的请求来获取 CSS、JavaScript、图片等资源。
    3. 解析 CSS：浏览器会解析所有的 CSS 文件，并将样式应用到对应的 DOM 元素上，生成 渲染树。
    4. 执行 JavaScript：如果 HTML 文件中包含 <script> 标签，浏览器会加载并执行其中的 JavaScript 代码，这可能会对 DOM 进行操作或发起新的网络请求。
    5. 构建渲染树：浏览器结合 DOM 树和样式信息（CSS 规则）构建渲染树，描述每个元素应该如何显示在页面上。

6. 页面布局（Layout）

  • 浏览器根据渲染树计算每个元素的几何位置和尺寸。这一过程称为“布局”或“回流（reflow）”。

7. 页面绘制（Painting）

  • 在布局完成后，浏览器会根据渲染树的布局信息和样式信息将每个元素绘制到屏幕上，呈现最终的页面。

8. 持续渲染与交互

  • 页面加载完成后，浏览器继续保持与用户的交互，并在需要时重新渲染部分页面（例如当用户点击按钮或滚动页面时，或者当 JavaScript 脚本动态修改了 DOM 树）。
  • 现代浏览器中，页面的渲染过程是持续的，JavaScript 代码或用户操作可能引发局部重新绘制（repaint）或回流（reflow）。

总结

整个过程大致可以分为 DNS 解析 → 建立连接 → 发送请求 → 服务器响应 → 页面渲染。

什么是HTTPS协议？如何加密的？

超文本传输安全协议（Hypertext Transfer Protocol Secure，简称：HTTPS） HTTPS在HTTP层和tcp层中间加了一个SSL/TLS安全层，进行加密，避免了HTTP协议存在的信息窃听，信息劫持等风险。

​

编辑

由于HTTP协议采用明文传输信息，很容易被窃听、篡改、劫持。而HTTPS增加的TLS/SSL层可以对身份进行验证、信息加密解密功能，避免这种问题发生。安全层的主要职责就是对发起的HTTP的数据进行加密解密操作。

安全层依赖于三个算法：

  1. 对称加密： 用一个密钥加密数据，加密后也可以对其解密。存在安全风险，容易被劫持
  2. 非对称加密：一个公钥一个私，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。
    • 如果公钥是一开始通过明文传输给浏览器的，也会造成劫持，用公钥解密数据。
  1. CA证书：向机构申请一份CA证书，里面包含网站信息和公钥A，服务端吧证书传给浏览器，浏览器验证证书，拿到公钥A

加密过程： 安全层采用混合加密（对称加密 + 非对称加密）

​

编辑

  • 服务端传递CA证书给浏览器
  • 客户端通过CA证书验证网站，拿到公钥A。
  • 客户端对称加密生产密钥X，用公钥A加密后返回服务端
  • 服务端用私钥A解密公钥A，拿到客户端的密钥X
  • 后续通信就使用密钥X进行加密

TLS/SSL的工作原理

LS/SSL的功能实现主要依赖三类基本算法：散列函数hash、对称加密、非对称加密

客户端使用非对称加密与服务器进行通信，实现身份的验证并协商对称加密使用的秘钥。

HTTP请求头

  1. Host：指定请求目标服务器的域名和端口。
  2. User-Agent：标识发送请求的客户端软件（浏览器、操作系统、设备等）。
  3. Connection：控制当前连接的管理方式。常见的值有 keep-alive（保持连接）或 close（关闭连接）。
  4. Authorization ：用于提供认证信息（如基本认证、Bearer Token 等）。
  5. Cookie：包含由服务器设置并存储在客户端的 Cookie 数据。
  6. Origin：指定请求发起的原始域，用于跨域请求（CORS）时进行安全验证。
  7. If-None-Match ：用于条件请求，当客户端的缓存与服务器资源的 ETag 值匹配时，表示资源未变化，返回 304 Not Modified 响应。
  8. Cache-Control：指示请求或响应如何缓存。

HTTP状态码

  • 1XX: 请求正在处理
  • 2XX：正常状态码
    • 200 ：请求处理成功
    • 201 ： 请求成功并且服务器创建了新资源
    • 202 ：服务器已经接收请求，但尚未处理
  • 3XXX：重定向状态
    • 301 ： 永久重定向，原请求方法保持不变，未来的请求应该直接访问新的 URL
    • 302: 临时重定向，原请求方法通常保持不变（浏览器可能使用原请求方法访问新的 URL）。
    • 303: 临时重定向，但强制使用 GET 请求访问新的 URL，无论原请求方法是什么。
    • 304：浏览器缓存相关
  • 4XX：错误状态码
    • 400: 服务器无法理解请求格式，需要修改请求内容后再次发起请求
    • 401: 请求未授权
    • 403: 禁止访问
    • 404: 服务器上无法找到请求资源
  • 5XX：服务器错误
    • 500: 服务端错误
    • 503: 服务器暂时无法处理请求

DNS完整的查询过程

DNS服务器域名解析过程：

  • 查看浏览器缓存是否有对应IP，如果找到直接返回，没有找到继续下一步。
  • 发送请求到本地DNS服务器，本地域名服务器缓存中如果有，直接返回，没有就向上级服务器迭代查询。
  • 本地DNS服务器向根域名服务器发送请求，根域名服务器会返回一个顶级域名服务器地址。
  • 本地DNS服务器向顶级域名服务器发送请求，顶级域名服务器查询自己的缓存，如果就返回，如果没有返回下一级权威域名服务器地址。
  • 本地DNS服务器向权威域名服务器发送请求，服务器返回域名对应的ip
  • 本地DNS服务器将返回结果保存，方便下次查询。
  • 本地DNS服务器将IP返回给浏览器

​

编辑

OSI七层模型

  1. 物理层（Physical Layer）：负责传输原始的比特流（0和1），通过物理媒介（如光纤、电缆、无线等）将数据从一个节点传输到另一个节点。
  2. 数据链路层（Data Link Layer）：在物理连接上传输数据帧，并处理帧的传输错误。它还负责物理地址（MAC地址）的寻址和数据帧的识别。
  3. 网络层（Network Layer）：处理数据包的路由和转发，负责将数据从源主机发送到目标主机，包括寻找最佳路径和实现路由选择。
  4. 传输层（Transport Layer）：提供端到端的数据传输服务，包括数据的分段、重组和错误恢复，确保数据可靠地传输。
  5. 会话层（Session Layer）：负责建立、管理和终止会话（会话是两个应用程序之间的通信会话），并提供会话恢复功能。
  6. 表示层（Presentation Layer）：处理数据的表示和编码，确保数据格式在不同系统之间的交换和解释。
  7. 应用层（Application Layer）：为用户提供应用服务，包括网络服务和应用程序之间的交互，例如电子邮件、文件传输、远程登录等。

​

编辑

TCP/IP五层协议

  • 应用层HTTP协议 FTP协议 DNS查询
  • 传输层提供通信
    • UPD无连接 最大努力传输服务 不安全
    • TCP 面向连接 数据可靠

  • 网络层 路由器 交换机

  • 数据链条层 IP数据封装成帧 在两个相邻节点间传送

  • 物理层 确保数据在物理媒介上传输

    ​

    编辑

TCP和UDP的区别

TCP 和 UDP都是传输层协议，他们都属于TCP/IP协议族：

TCP

  • 面向连接
  • 一对一，不支持广播和多播
  • 面向字节流
  • 可靠传输
  • 提供拥塞控制
  • 提供全双工通信

UDP

  • 面向无连接，不需要建立三次握手
  • 支持一对一、一对多、多对多方式
  • 面向报文
  • 不可靠

UDP协议为什么不可靠？

  • 传输数据之前不需要先建立连接
  • 不需要确认
  • 不跟踪连接

对 WebSocket 的理解

WebSocket 是一种在单个TCP 连接上实现全双工通信的网络协议，与传统的 HTTP 协议不同，HTTP是基于请求-响应模式，即客户端发送请求，服务器返回响应，然后连接关闭。而 WebSocket 允许客户端和服务器之间保持持久性的连接，双方可以随时互相发送数据，而不需要每次通信都建立新的连接。

服务器可以向客户端主动推送消息，客户端也可以主动向服务器推送消息。

TCP和UDP的应用

TCP应用层协议

  • HTTP：用于在Web浏览器和Web服务器之间传输超文本数据。大多数网站使用TCP上的HTTP来传输网页内容，图像，视频等。
  • SMTP：用于电子邮件的发送。它确保电子邮件消息以可靠的方式传递到电子邮件服务器。
  • POP3 和 IMAP：这两种协议用于从电子邮件服务器接收邮件。它们使用TCP确保邮件的完整传递。
  • FTP：用于在客户端和服务器之间传输文件。TCP确保文件以可靠的方式传输。
  • SSH：用于远程登录和安全传输数据。SSH使用TCP来保证安全的数据传输。
  • HTTPS：是安全的HTTP，使用SSL/TLS进行加密。它在TCP上运行，用于安全的网页浏览。

UPD应用层协议

  • DNS：用于将域名映射到IP地址。DNS使用UDP进行快速的查询和响应，尽管它不提供数据可靠性。
  • DHCP：用于为设备分配IP地址和其他网络配置。DHCP使用UDP来请求和分配IP地址。
  • SNMP：用于网络设备的监控和管理。它使用UDP在网络设备之间传输监控信息。
  • TFTP：类似于FTP，但更简单，用于快速传输文件。TFTP使用UDP来传输数据。
  • VoIP：用于实时语音通话。VoIP应用程序使用UDP来传输音频数据，因为它对延迟比数据丢失更敏感。
  • NTP：用于同步计算机的时间。NTP使用UDP来获取时间信息。

​

avatar
文章
阅读
粉丝