{T}

网络相关的面试题

HTTP 和 UDP 的区别

  • HTTP 在应用层，而 UDP 和 TCP 在传输层
  • HTTP 是有连接的、可靠的，UDP 是无连接的、不可靠的

img

  • HTTP 在应用层，直接被程序使用
  • TCP 和 UDP 在传输层，底层

UDP 的特点

UDP 是一种无连接的、不可靠的传输层协议，不需要连接，所以 UDP 的效率比 TCP 高

而 TCP 需要连接、断开连接，参考“三次握手、四次挥手”

虽然 UDP 从协议层是不稳定的，但随着现代网络硬件环境的提升，也能保证绝大部分情况下的稳定性。所以，UDP 一直处于被发展的趋势

例如视频会议、语音通话这些允许中段、不完全保证持续连接的场景，又需要较高的传输效率，就很适合 UDP 协议

http 1.0、 1.1、 2.0 区别

http 1.0 最基础的 http 协议

  • 支持基本的 GET POST的方法

http 1.1

  • 引入更多的缓存策略，如 cache-control E-tag
  • 长链接，默认开启 Connection: keep-alive ，多次 http 请求减少了 TCP 连接次数
  • 断点续传，状态码 206
  • 增加新的 method PUT DELETE 等，可以设计 Restful API

http 2.0

  • header 压缩，以减少体积
  • 多路复用，一个 TCP 连接中可以多个 http 并行请求。拼接资源（如雪碧图、多 js 拼接一个）将变的多余
  • 服务器端推送

https 中间人攻击

什么是 https 中间人攻击，如何预防？

http 是明文传输，传输的所有内容（如登录的用户名和密码），都会被中间的代理商（无论合法还是非法）获取到

http + TLS/SSL = https ，即加密传输信息。只有客户端和服务端可以解密为明文，中间的过程无法解密

img

中间人攻击，就是黑客劫持网络请求，伪造 CA 证书

img

解决方案：使用浏览器可识别的，正规厂商的证书（如阿里云），慎用免费证书。

img

TCP 连接 三次握手 四次挥手

请描述 TCP 连接的 三次握手(连接) 和 四次挥手(断开)

建立连接

客户端和服务端通过 HTTP 协议发送请求，并获取内容

在发送请求之前，需要先建立连接，确定目标机器处于可接受请求的状态

HTTP 协议是一个应用层的协议，它只规定了 req 和 res 的数据格式，如状态码、header、body 等。 而建立网络连接需要更加底层的 TCP 协议。

  • 先建立连接(确保双方都有收发消息的能力)
  • 再传输内容(如发送一个get请求)
  • 网络连接是TCP，传输内容是HTTP协议

三次握手

三次握手，即建立一次 TCP 连接时，客户端和服务端总共需要发送 3 个包。

先举一个例子。还是你要派人去张三家取一个东西，现在你要发短信（不是打电话）“建立连接”，至少需要 3 个步骤，缺一不可。

  • 你：在家吗？
  • 张三：在家
  • 你：好，这就过去（然后你指派人上门，张三准备迎接）

过程(前两次是确定收发的能力，第三次是通知要发送)

  • 客户端发包，服务端收到。服务端确认：客户端的发送能力是正常的。
  • 服务端发包，客户端收到。客户端确认：服务端的接收能力是正常的。
  • 客户端发包，服务端收到。服务端确认：客户端即将给我发送数据，我要准备接收。

建立连接完成，然后就开始发送数据，通讯。

四次挥手

挥手，就是告别，就是关闭连接。

还是之前的例子。取东西，不一定一次就取完，可能要来回很多次。而且，也不一定全部由你主动发起，过程中张三也可能会主动派人给你发送。

即，你在 chrome 中看到的是一次 http 请求，其实背后可能需要好几次网络传输，只不过浏览器给合并起来了。

好了，取东西完毕了，你要发短信“关闭连接”，告诉张三可以关门了，需要 4 个步骤。 【注意】这里你需要等着确认张三关门，才算是完全关闭连接，不能你说一声就不管了。跟日常生活不一样

  • 你：完事儿了
  • 张三：好的 （此时可能还要继续给你发送，你也得继续接收。直到张三发送完）
  • 张三：我发送完毕，准备关门了
  • 你：好，关门吧 （然后你可以走了，张三可以关门了，连接结束）

过程

  • 客户端发包，服务端接收。服务端确认：客户端已经请求结束
  • 服务端发包，客户端接收。客户端确认：服务端已经收到，我等待它关闭
  • 服务端发包：客户端接受。客户端确认：服务端已经发送完成，可以关闭
  • 客户端发包，服务端接收。服务端确认：可以关闭了

img

跨域为何需要 options 请求

同源策略一般限制 Ajax 网络请求，不会限制<link>、<img>、<script>、<iframe>

浏览器同源策略，默认限制跨域请求。跨域的解决方案

  • jsonp
  • CORS
javascript
// CORS 配置允许跨域（服务端）
response.setHeader("Access-Control-Allow-Origin", "http://localhost:8011") // 或者 '*'
response.setHeader("Access-Control-Allow-Headers", "X-Requested-With")
response.setHeader("Access-Control-Allow-Methods", "PUT,POST,GET,DELETE,OPTIONS")
response.setHeader("Access-Control-Allow-Credentials", "true") // 允许跨域接收 cookie

使用 CORS 跨域请求时，经常会看到一个“多余”的 options 请求，之后才发送了实际的请求

img

规范要求，对那些可能对服务器数据产生副作用的 HTTP 请求方法（特别是 GET 以外的 HTTP 请求，或者搭配某些 MIME 类型的 POST 请求），浏览器必须首先使用 OPTIONS 方法发起一个预检请求（preflight request），从而获知服务端是否允许该跨域请求。—— MDN

options 请求就是对 CORS 跨域请求之间的一次预检查，主要是检查服务端的 headers 信息，是否符合客户端的预期（所以没有 body 返回） 检查成功再发起正式请求，是浏览器自行处理的

Restful API 常用的方法

以一个博客项目为例，实现“增删改查”功能，使用 Restful API 的接口设计如下

  • 新增博客

  • url http://xxx.com/api/blog

  • method POST （request body 中有博客的内容）

  • 删除博客

  • url http://xxx.com/api/blog/100 （ 100 为博客的 id）

  • method DELETE

  • 修改博客内容

  • url http://xxx.com/api/blog/100 （ 100 为博客的 id）

  • method PATCH （request body 中有博客的内容）

  • 跟 PATCH 很像的还有 PUT 方法，两者有差别

  • PUT 更新全部内容，即替换

  • PATCH 更新部分内容 —— 更加常用

  • 查询单个博客

  • url http://xxx.com/api/blog/100 （100 为博客的 id）

  • method GET

  • 查询博客列表

  • url http://xxx.com/api/blog

  • method GET