关于java:计算机网络面试题第二期2021最新版

30次阅读

共计 8092 个字符，预计需要花费 21 分钟才能阅读完成。

附一份干货！一份 700 多页的后端面试笔记，涵盖了后端开发常考知识点。

链接：https://pan.baidu.com/s/1dsDm…

提取码：0das

计算机网络面试题第二期来了，话不多说，先珍藏再看吧~

看下本期的目录：

1. HTTP 常见的状态码有哪些？

常见状态码：

  • 200：服务器已胜利解决了申请。通常，这示意服务器提供了申请的网页。
  • 301：(永恒挪动) 申请的网页已永恒挪动到新地位。服务器返回此响应 (对 GET 或 HEAD 申请的响应) 时，会主动将请求者转到新地位。
  • 302：(长期挪动) 服务器目前从不同地位的网页响应申请，但请求者应持续应用原有地位来进行当前的申请。
  • 400：客户端申请有语法错误，不能被服务器所了解。
  • 403：服务器收到申请，然而回绝提供服务。
  • 404：(未找到) 服务器找不到申请的网页。
  • 500：(服务器外部谬误) 服务器遇到谬误，无奈实现申请。

状态码结尾代表类型：

2. 状态码 301 和 302 的区别是什么？

共同点 ：301 和 302 状态码都示意重定向，就是说浏览器在拿到服务器返回的这个状态码后会主动跳转到一个新的 URL 地址，这个地址能够从响应的 Location 首部中获取（ 用户看到的成果就是他输出的地址 A 霎时变成了另一个地址 B ）。
不同点：301 示意旧地址 A 的资源曾经被永恒地移除了(这个资源不可拜访了)，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址；302 示意旧地址 A 的资源还在（依然能够拜访），这个重定向只是长期地从旧地址 A 跳转到地址 B，搜索引擎会抓取新的内容而保留旧的网址。SEO 中 302 好于 301。

补充，重定向起因：

  1. 网站调整（如扭转网页目录构造）；
  2. 网页被移到一个新地址；
  3. 网页扩展名扭转(如利用须要把.php 改成.Html 或.shtml)。

3. HTTP 罕用的申请形式？

办法 作用
GET 获取资源
POST 传输实体主体
PUT 上传文件
DELETE 删除文件
HEAD 和 GET 办法相似，但只返回报文首部，不返回报文实体主体局部
PATCH 对资源进行局部批改
OPTIONS 查问指定的 URL 反对的办法
CONNECT 要求用隧道协定连贯代理
TRACE 服务器会将通信门路返回给客户端

为了不便记忆，能够将 PUT、DELETE、POST、GET 了解为客户端对服务端的增删改查。

  • PUT：上传文件，向服务器增加数据，能够看作增
  • DELETE：删除文件
  • POST：传输数据，向服务器提交数据，对服务器数据进行更新。
  • GET：获取资源，查问服务器资源

4. GET 申请和 POST 申请的区别？

应用上的区别：

  • GET 应用 URL 或 Cookie 传参，而 POST 将数据放在 BODY 中”，这个是因为 HTTP 协定用法的约定。
  • GET 形式提交的数据有长度限度，则 POST 的数据则能够十分大”，这个是因为它们应用的操作系统和浏览器设置的不同引起的区别。
  • POST 比 GET 平安，因为数据在地址栏上不可见”，这个说法没故障，但仍然不是 GET 和 POST 自身的区别。

本质区别

GET 和 POST 最大的区别次要是 GET 申请是幂等性的，POST 申请不是。这个是它们本质区别。

幂等性是指一次和屡次申请某一个资源应该具备同样的副作用。简略来说意味着对同一 URL 的多个申请应该返回同样的后果。

5. 解释一下 HTTP 长连贯和短连贯？

在 HTTP/1.0 中，默认应用的是短连贯。也就是说，浏览器和服务器每进行一次 HTTP 操作，就建设一次连贯，但工作完结就中断连贯。如果客户端浏览器拜访的某个 HTML 或其余类型的 Web 页中蕴含有其余的 Web 资源，如 JavaScript 文件、图像文件、CSS 文件等；当浏览器每遇到这样一个 Web 资源，就会建设一个 HTTP 会话。

但从 HTTP/1.1 起，默认应用长连贯，用以放弃连贯个性。应用长连贯的 HTTP 协定，会在响应头有退出这行代码：Connection:keep-alive

在应用长连贯的状况下，当一个网页关上实现后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连贯不会敞开，如果客户端再次拜访这个服务器上的网页，会持续应用这一条曾经建设的连贯。Keep-Alive 不会永恒放弃连贯，它有一个放弃工夫，能够在不同的服务器软件（如 Apache）中设定这个工夫。实现长连贯要客户端和服务端都反对长连贯。

HTTP 协定的长连贯和短连贯，本质上是 TCP 协定的长连贯和短连贯。

6. HTTP 申请报文和响应报文的格局？

申请报文格式：

  1. 申请行（申请办法 +URI 协定 + 版本）
  2. 申请头部
  3. 空行
  4. 申请主体
GET/sample.jspHTTP/1.1 申请行
Accept:image/gif.image/jpeg, 申请头部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=jinqiao&password=1234 申请主体

响应报文：

  1. 状态行（版本 + 状态码 + 起因短语）
  2. 响应首部
  3. 空行
  4. 响应主体
HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>
    <head>
        <title>HTTP 响应示例 <title>
    </head>
    <body>
        Hello HTTP!
    </body>
</html>

7. HTTP1.0 和 HTTP1.1 的区别?

  • 长连贯：HTTP 1.1 反对长连贯（Persistent Connection）和申请的流水线（Pipelining）解决，在一个 TCP 连贯上能够传送多个 HTTP 申请和响应，缩小了建设和敞开连贯的耗费和提早，在 HTTP1.1 中默认开启Connection：keep-alive，肯定水平上补救了 HTTP1.0 每次申请都要创立连贯的毛病。
  • 缓存解决：在 HTTP1.0 中次要应用 header 里的 If-Modified-Since,Expires 来做为缓存判断的规范，HTTP1.1 则引入了更多的缓存控制策略，可供选择的缓存头来管制缓存策略。
  • 带宽优化及网络连接的应用：HTTP1.0 中，存在一些节约带宽的景象，例如客户端只是须要某个对象的一部分，而服务器却将整个对象送过来了，并且不反对断点续传性能，HTTP1.1 则在申请头引入了 range 头域，它容许只申请资源的某个局部，即返回码是 206（Partial Content），这样就不便了开发者自在的抉择以便于充分利用带宽和连贯。
  • 谬误告诉的治理：在 HTTP1.1 中新增了 24 个谬误状态响应码，如 409（Conflict）示意申请的资源与资源的以后状态发生冲突；410（Gone）示意服务器上的某个资源被永久性的删除。
  • Host 头解决：在 HTTP1.0 中认为每台服务器都绑定一个惟一的 IP 地址，因而，申请音讯中的 URL 并没有传递主机名（hostname）。但随着虚拟主机技术的倒退，在一台物理服务器上能够存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个 IP 地址。HTTP1.1 的申请音讯和响应音讯都应反对 Host 头域，且申请音讯中如果没有 Host 头域会报告一个谬误（400 Bad Request）。

8. HTTP1.1 和 HTTP2.0 的区别？

HTTP2.0 相比 HTTP1.1 反对的个性：

  • 新的二进制格局：HTTP1.1 的解析是基于文本。基于文本协定的格局解析存在人造缺点，文本的表现形式有多样性，要做到健壮性思考的场景必然很多，二进制则不同，只认 0 和 1 的组合。基于这种思考 HTTP2.0 的协定解析决定采纳二进制格局，实现不便且强壮。
  • 多路复用，即连贯共享，即每一个 request 都是用作连贯共享机制的。一个 request 对应一个 id，这样一个连贯上能够有多个 request，每个连贯的 request 能够随机的混淆在一起，接管方能够依据 request 的 id 将 request 再归属到各自不同的服务端申请外面。
  • 头部压缩，HTTP1.1 的头部（header）带有大量信息，而且每次都要反复发送；HTTP2.0 应用 encoder 来缩小须要传输的 header 大小，通信单方各自 cache 一份 header fields 表，既防止了反复 header 的传输，又减小了须要传输的大小。
  • 服务端推送：服务器除了对最后申请的响应外，服务器还能够额定的向客户端推送资源，而无需客户端明确的申请。

9. HTTP 与 HTTPS 的区别？

HTTP HTTPS
端口 80 443
安全性 无加密，安全性较差 有加密机制，安全性较高
资源耗费 较少 因为加密解决，资源耗费更多
是否须要证书 不须要 须要
协定 运行在 TCP 协定之上 运行在 SSL 协定之上，SSL 运行在 TCP 协定之上

10. HTTPS 的优缺点?

长处：

  • 安全性：

    • 应用 HTTPS 协定可认证用户和服务器，确保数据发送到正确的客户机和服务器；
    • HTTPS 协定是由 SSL+HTTP 协定构建的可进行加密传输、身份认证的网络协议，要比 http 协定平安，可避免数据在传输过程中不被窃取、扭转，确保数据的完整性。
    • HTTPS 是现行架构下最平安的解决方案，尽管不是相对平安，但它大幅减少了中间人攻打的老本。
  • SEO 方面：谷歌曾在 2014 年 8 月份调整搜索引擎算法，并称“比起等同 HTTP 网站，采纳 HTTPS 加密的网站在搜寻后果中的排名将会更高”。

毛病：

  • 在雷同网络环境中，HTTPS 相比 HTTP 无论是响应工夫还是耗电量都有大幅度回升。
  • HTTPS 的平安是有范畴的，在黑客攻击、服务器劫持等状况下简直起不到作用。
  • 在现有的证书机制下，中间人攻打仍然有可能产生。
  • HTTPS 须要更多的服务器资源，也会导致老本的升高。

11. 讲一讲 HTTPS 的原理？

图片起源：https://segmentfault.com/a/11…

加密流程按图中的序号分为：

  1. 客户端申请 HTTPS 网址，而后连贯到 server 的 443 端口 (HTTPS 默认端口，相似于 HTTP 的 80 端口)。
  2. 采纳 HTTPS 协定的服务器必须要有一套数字 CA (Certification Authority)证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端本人保留，不可透露。公钥则是附带在证书的信息中，能够公开的。证书自身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，能够避免证书被篡改。
  3. 服务器响应客户端申请，将证书传递给客户端，证书蕴含公钥和大量其余信息，比方证书颁发机构信息，公司信息和证书有效期等。

  4. 客户端解析证书并对其进行验证。如果证书不是可信机构颁布，或者证书中的域名与理论域名不统一，或者证书曾经过期，就会向访问者显示一个正告，由其抉择是否还要持续通信。

    如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥 A。而后客户端还会生成一个随机码 KEY，并应用公钥 A 将其加密。

  5. 客户端把加密后的随机码 KEY 发送给服务器，作为前面对称加密的密钥。
  6. 服务器在收到随机码 KEY 之后会应用私钥 B 将其解密。通过以上这些步骤，客户端和服务器终于建设了平安连贯，完满解决了对称加密的密钥泄露问题，接下来就能够用对称加密欢快地进行通信了。
  7. 服务器应用密钥 (随机码 KEY)对数据进行对称加密并发送给客户端，客户端应用雷同的密钥 (随机码 KEY)解密数据。
  8. 单方应用对称加密欢快地传输所有数据。

12. 在浏览器中输出 www.baidu.com 后执行的全副过程？

  1. 域名解析（域名 www.baidu.com 变为 ip 地址）。

    浏览器搜寻本人的 DNS 缓存 （保护一张域名与 IP 的对应表）；若没有，则搜寻 操作系统的 DNS 缓存（保护一张域名与 IP 的对应表）；若没有，则搜寻操作系统的hosts 文件（保护一张域名与 IP 的对应表）。

    若都没有，则找 tcp/ip 参数中设置的首选 dns 服务器，即 本地 dns 服务器 （递归查问）， 本地域名服务器查问本人的 dns 缓存，如果没有，则进行迭代查问。将本地 dns 服务器将 IP 返回给操作系统，同时缓存 IP。

  2. 发动 tcp 的三次握手，建设 tcp 连贯。浏览器会以一个随机端口（1024-65535）向服务端的 web 程序 80 端口发动 tcp 的连贯。
  3. 建设 tcp 连贯后发动 http 申请。
  4. 服务器响应 http 申请，客户端失去 html 代码。服务器 web 应用程序收到 http 申请后，就开始解决申请，解决之后就返回给浏览器 html 文件。
  5. 浏览器解析 html 代码，并申请 html 中的资源。
  6. 浏览器对页面进行渲染，并出现给用户。

附一张形象的图片：

13. 什么是 Cookie 和 Session ?

什么是 Cookie

HTTP Cookie（也叫 Web Cookie 或浏览器 Cookie）是服务器发送到用户浏览器并保留在本地的一小块数据，它会在浏览器下次向同一服务器再发动申请时被携带并发送到服务器上。通常，它用于告知服务端两个申请是否来自同一浏览器，如放弃用户的登录状态。Cookie 使基于无状态的 HTTP 协定记录稳固的状态信息成为了可能。

Cookie 次要用于以下三个方面：

  • 会话状态治理（如用户登录状态、购物车、游戏分数或其它须要记录的信息）
  • 个性化设置（如用户自定义设置、主题等）
  • 浏览器行为跟踪（如跟踪剖析用户行为等）

什么是 Session

Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会失落，而是在整个用户会话中始终存在上来。当客户端敞开会话，或者 Session 超时生效时会话完结。

14. Cookie 和 Session 是如何配合的呢？

用户第一次申请服务器的时候，服务器依据用户提交的相干信息，创立对应的 Session，申请返回时将此 Session 的惟一标识信息 SessionID 返回给浏览器，浏览器接管到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名。

当用户第二次拜访服务器的时候，申请会主动判断此域名下是否存在 Cookie 信息，如果存在主动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再依据 SessionID 查找对应的 Session 信息，如果没有找到阐明用户没有登录或者登录生效，如果找到 Session 证实用户曾经登录可执行前面操作。

依据以上流程可知，SessionID 是连贯 Cookie 和 Session 的一道桥梁，大部分零碎也是依据此原理来验证用户登录状态。

15. Cookie 和 Session 的区别？

  • 作用范畴不同，Cookie 保留在客户端（浏览器），Session 保留在服务器端。
  • 存取形式的不同，Cookie 只能保留 ASCII，Session 能够存任意数据类型，个别状况下咱们能够在 Session 中放弃一些罕用变量信息，比如说 UserId 等。
  • 有效期不同，Cookie 可设置为长时间放弃，比方咱们常常应用的默认登录性能，Session 个别生效工夫较短，客户端敞开或者 Session 超时都会生效。
  • 隐衷策略不同，Cookie 存储在客户端，比拟容易受到不法获取，晚期有人将用户的登录名和明码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性绝对 Cookie 要好一些。
  • 存储大小不同，单个 Cookie 保留的数据不能超过 4K，Session 可存储数据远高于 Cookie。

16. 如何思考分布式 Session 问题？

在互联网公司为了能够撑持更大的流量，后端往往须要多台服务器独特来撑持前端用户申请，那如果用户在 A 服务器登录了，第二次申请跑到服务 B 就会呈现登录生效问题。

分布式 Session 个别会有以下几种解决方案：

  • 客户端存储：间接将信息存储在 cookie 中，cookie 是存储在客户端上的一小段数据，客户端通过 http 协定和服务器进行 cookie 交互，通常用来存储一些不敏感信息
  • Nginx ip_hash 策略：服务端应用 Nginx 代理，每个申请按拜访 IP 的 hash 调配，这样来自同一 IP 固定拜访一个后盾服务器，防止了在服务器 A 创立 Session，第二次散发到服务器 B 的景象。
  • Session 复制：任何一个服务器上的 Session 产生扭转（增删改），该节点会把这个 Session 的所有内容序列化，而后播送给所有其它节点。
  • 共享 Session：服务端无状态话，将用户的 Session 等信息应用缓存中间件（如 Redis）来对立治理，保障散发到每一个服务器的响应后果都统一。

倡议采纳共享 Session 的计划。

17. 什么是 DDos 攻打？

DDos 全称 Distributed Denial of Service，分布式拒绝服务攻打。最根本的 DOS 攻打过程如下：

  1. 客户端向服务端发送申请链接数据包。
  2. 服务端向客户端发送确认数据包。
  3. 客户端不向服务端发送确认数据包，服务器始终期待来自客户端的确认

DDoS 则是采纳分布式的办法，通过在网络上霸占多台“肉鸡”，用多台计算机发动攻打。

DOS 攻打当初根本没啥作用了，因为服务器的性能都很好，而且是多台服务器独特作用，1V1 的模式黑客无奈占上风。对于 DDOS 攻打，预防办法有：

  • 缩小 SYN timeout 工夫。在握手的第三步，服务器会期待 30 秒 -120 秒的工夫，缩小这个等待时间就能开释更多的资源。
  • 限度同时关上的 SYN 半连贯数目。

18. 什么是 XSS 攻打？

XSS 也称 cross-site scripting，跨站脚本 。这种攻打是 因为服务器将攻击者存储的数据原原本本地显示给其余用户所致的 。比方一个存在 XSS 破绽的论坛，用户发帖时就能够引入 带有