网络基础相关

1. 简述一下http1 1.1 2 3的区别


http://www.ruanyifeng.com/blog/2016/08/http.html

http1
支持get，post，head请求
缺点：

  1. 每个tcp连接只能发送一个请求，发送完毕后，连接就关闭了，要想发送其他请求，需要再开一个tcp连接（解决方法是加一个Connection: keep-alive字段，但这不是标准字段，不同的实现行为可能不一致）

http1.1

  1. 引入持久连接，不用声明Connection: keep-alive，在客户端或者服务器一段时间发现对方没有活动，就可以主动关闭连接，不过规范做法是在最后一个请求发送Connection: close，明确要求关闭tcp连接
  2. 引入管道机制，即同一个tcp里面，客户端可以同时发送多个请求，这样进一步改进了http的效率（举例来说，客户端需要请求两个资源。以前的做法是，在同一个TCP连接里面，先发送A请求，然后等待服务器做出回应，收到后再发出B请求。管道机制则是允许浏览器同时发出A请求和B请求，但是服务器还是按照顺序，先回应A请求，完成后再回应B请求。）
  3. 新增了很多动词方法，例如put，delete，head，options，patch
  4. 客户端新增了host字段，用来指定服务器域名

但是这样做仍然有缺点

  1. 虽然是并发请求，但是响应却是要按照顺序接收，所以服务器只能处理完一个回应，才能处理下一个回应，如果当中一个回应特别慢，就会造成后面有许多回应要排队。
  2. 不会压缩请求和响应首部，从而导致不必要的网络流量

http2

  1. 二进制分帧，每个桢包括一个帧头，里面有个很小标志，来区别是属于哪个流（减少服务端的链接压力,内存占用更少,连接吞吐量更大；而且由于 TCP 连接的减少而使网络拥塞状况得以改善，同时慢启动时间的减少,使拥塞和丢包恢复速度更快。）
  2. 多路复用 （）
  3. 首部压缩（使用 HPACK 算法）
  4. 服务端推送 （服务器推送还有一个很大的优势：可以缓存！也让在遵循同源的情况下，不同页面之间可以共享缓存资源成为可能。）
    1）推送的资源可以由客户端缓存
    2）推送的资源可以在不同的页面上重复使用
    3）推送的资源可以与其他资源一起复用
    4）推送的资源可以由服务器优先
    5）推送的资源可以被客户拒绝

http3
使用QUIC代替TCP
（1）对移动端切换网络体验更好
（2）解决了tcp的队头拥塞问题
（3）缩短连接建立时间

2. tcp三次握手，四次挥手

TCP 头部协议：

| Flags:TCP 首部中有 6 个标志比特，它们中的多个可同时被设置为 1，主要是用于操控 TCP 的状态（URG，ACK，PSH，RST，SYN，FIN）

  • ACK ： TCP 协议规定，只有 ACK=1 时有效，也规定连接建立后所有发送的报文的 ACK 必须为 1
  • SYN(SYNchronization) ： 在连接建立时用来同步序号。当 SYN=1 而 ACK=0 时，表明这是一个连接请求报文。对方若同意建立连接，则应在响应报文中使 SYN=1 和 ACK=1. 因此, SYN 置 1 就表示这是一个连接请求或连接接受报文。
  • FIN （finis）即完，终结的意思， 用来释放一个连接。当 FIN = 1 时，表明此报文段的发送方的数据已经发送完毕，并要求释放连接。
三次握手
  • 第一次握手：建立连接。客户端发送连接请求报文段，将 SYN 位置为 1，Sequence Number 为 x；然后，客户端进入 SYN_SEND 状态，等待服务器的确认；
  • 第二次握手：服务器收到 SYN 报文段。服务器收到客户端的 SYN 报文段，需要对这个 SYN 报文段进行确认，设置 Acknowledgment Number 为 x+1(Sequence Number+1)；同时，自己自己还要发送 SYN 请求信息，将 SYN 位置为 1，Sequence Number 为 y；服务器端将上述所有信息放到一个报文段（即 SYN+ACK 报文段）中，一并发送给客户端，此时服务器进入 SYN_RECV 状态；
  • 第三次握手：客户端收到服务器的 SYN+ACK 报文段。然后将 Acknowledgment Number 设置为 y+1，向服务器发送 ACK 报文段，这个报文段发送完毕以后，客户端和服务器端都进入 ESTABLISHED 状态，完成 TCP 三次握手。
  • 完成了三次握手，客户端和服务器端就可以开始传送数据。以上就是 TCP 三次握手的总体介绍。
四次分手

当客户端和服务器通过三次握手建立了 TCP 连接以后，当数据传送完毕，肯定是要断开 TCP 连接的啊。那对于 TCP 的断开连接，这里就有了神秘的“四次分手”。

  • 第一次分手：主机 1（可以使客户端，也可以是服务器端），设置 Sequence Number 和 Acknowledgment Number，向主机 2 发送一个 FIN 报文段；此时，主机 1 进入 FIN_WAIT_1 状态；这表示主机 1 没有数据要发送给主机 2 了；
  • 第二次分手：主机 2 收到了主机 1 发送的 FIN 报文段，向主机 1 回一个 ACK 报文段，Acknowledgment Number 为 Sequence Number 加 1；主机 1 进入 FIN_WAIT_2 状态；主机 2 告诉主机 1，我“同意”你的关闭请求；
  • 第三次分手：主机 2 向主机 1 发送 FIN 报文段，请求关闭连接，同时主机 2 进入 LAST_ACK 状态；
  • 第四次分手：主机 1 收到主机 2 发送的 FIN 报文段，向主机 2 发送 ACK 报文段，然后主机 1 进入 TIME_WAIT 状态；主机 2 收到主机 1 的 ACK 报文段以后，就关闭连接；此时，主机 1 等待 2MSL 后依然没有收到回复，则证明 Server 端已正常关闭，那好，主机 1 也可以关闭连接了。

3. https的实现方式（详细过程）,里面涉及到的加密算法都有哪些

HTTP传输协议的缺点

（1） 窃听风险（eavesdropping）：第三方可以获知通信内容。
（2） 篡改风险（tampering）：第三方可以修改通信内容。
（3） 冒充风险（pretending）：第三方可以冒充他人身份参与通信。
因此需要加密传输避免以上缺点

https使用SSL/TLS

目前，应用最广泛的是TLS 1.0，接下来是SSL 3.0。但是，主流浏览器都已经实现了TLS 1.2的支持。
TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。

HTTP协议和SLL/TLS协议是如何结合使用的

4. OSI七层模型

  • 应用层(Application) 提供网络与用户应用软件之间的接口服务
  • 表示层(Presentation) 提供格式化的表示和转换数据服务，如加密和压缩
  • 会话层(Session) 提供包括访问验证和会话管理在内的建立和维护应用之间通信的机制
  • 传输层(Transimission) 提供建立、维护和取消传输连接功能，负责可靠地传输数据(PC)
  • 网络层(Network) 处理网络间路由，确保数据及时传送(路由器)
  • 数据链路层(DataLink) 负责无错传输数据，确认帧、发错重传等(交换机)
  • 物理层(Physics) 提供机械、电气、功能和过程特性(网卡、网线、双绞线、同轴电缆、中继器)

5. DNS请求路径

6. TCP/UDP的区别，怎么实现可靠UDP

  • TCP 是面向连接(Connection oriented)的协议，UDP 是无连接(Connection less)协议；TCP 用三次握手建立连接：1) Client 向 server 发送 SYN；2) Server 接收到 SYN，回复 Client 一个 SYN-ACK；3) Client 接收到 SYN_ACK，回复 Server 一个 ACK。到此，连接建成。UDP 发送数据前不需要建立连接。
  • TCP 可靠，UDP 不可靠；TCP 丢包会自动重传，UDP 不会。
  • TCP 有序，UDP 无序；消息在传输过程中可能会乱序，后发送的消息可能会先到达，TCP 会对其进行重排序，UDP 不会。
  • TCP 无界，UDP 有界；TCP 通过字节流传输，UDP 中每一个包都是单独的。
  • TCP 有流量控制（拥塞控制），UDP 没有；主要靠三次握手实现。
  • TCP 传输慢，UDP 传输快；因为 TCP 需要建立连接、保证可靠性和有序性，所以比较耗时。这就是为什么视频流、广播电视、在线多媒体游戏等选择使用 UDP。
  • TCP 是重量级的，UDP 是轻量级的；TCP 要建立连接、保证可靠性和有序性，就会传输更多的信息，如 TCP 的包头比较大。
  • TCP 的头部比 UDP 大；TCP 头部需要 20 字节，UDP 头部只要 8 个字节

7. web开发中会话的跟踪方法有哪些

当用户发出请求时，服务器就会做出响应，客户端与服务器之间的联系是离散的、非连续的。当用户在同一网站的多个页面之间转换时，根本无法确定是否是同一个客户，会话跟踪技术就可以解决这个问题。当一个客户在多个页面间切换时，服务器会保存该用户的信息。

1.Cookie：
可以使用 cookie 存储购物会话的 ID；在后续连接中，取出当前的会话 ID，并使用这个 ID 从服务器上的查找表（lookup table）中提取出会话的相关信息。 以这种方式使用 cookie 是一种绝佳的解决方案，也是在处理会话时最常使用的方式。但是，sevlet 中最好有一种高级的 API 来处理所有这些任务，以及下面这些冗长乏味的任务：从众多的其他cookie中（毕竟可能会存在许多cookie）提取出存储会话标识符的 cookie；确定空闲会话什么时候过期，并回收它们；将散列表与每个请求关联起来；生成惟一的会话标识符.

2.URL 重写：
采用这种方式时，客户程序在每个URL的尾部添加一些额外数据。这些数据标识当前的会话，服务器将这个标识符与它存储的用户相关数据关联起来。 URL重写是比较不错的会话跟踪解决方案，即使浏览器不支持 cookie 或在用户禁用 cookie 的情况下，这种方案也能够工作。
URL 重写具有 cookie 所具有的同样缺点，也就是说，服务器端程序要做许多简单但是冗长乏味的处理任务。即使有高层的 API 可以处理大部分的细节，仍须十分小心每个引用你的站点的 URL ，以及那些返回给用户的 URL。即使通过间接手段，比如服务器重定向中的 Location 字段，都要添加额外的信息。这种限制意味着，在你的站点上不能有任何静态 HTML 页面（至少静态页面中不能有任何链接到站点动态页面的链接）。因此，每个页面都必须使用 servlet 或 JSP 动态生成。即使所有的页面都动态生成，如果用户离开了会话并通过书签或链接再次回来，会话的信息也会丢失，因为存储下来的链接含有错误的标识信息。

3.隐藏的表单域：
HTML 表单中可以含有如下的条目：
这个条目的意思是：在提交表单时，要将指定的名称和值自动包括在 GET 或 POST 数据中。这个隐藏域可以用来存储有关会话的信息，但它的主要缺点是：仅当每个页面都是由表单提交而动态生成时，才能使用这种方法。单击常规的超文本链接并不产生表单提交，因此隐藏的表单域不能支持通常的会话跟踪，只能用于一系列特定的操作中，比如在线商店的结账过程。

4.session:
信息保存在服务器端
使用 setAttribute(String str,Object obj)方法将对象捆绑到一个会话

8. http method

1 GET 请求指定的页面信息，并返回实体主体。
2 HEAD 类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头
3 POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。
4 PUT 从客户端向服务器传送的数据取代指定的文档的内容。
5 DELETE 请求服务器删除指定的页面。
6 CONNECT HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。
7 OPTIONS 允许客户端查看服务器的性能。
8 TRACE 回显服务器收到的请求，主要用于测试或诊断。
9 PATCH 是对 PUT 方法的补充，用来对已知资源进行局部更新 。

9. js跨域通信（跨域产生的原因，常见解决方法及原理，手动实现个jsonp）

function jsonp(options) {
  // 设置默认初始值
  var defaultObj = {
      url: '',
      jsonpCallback: 'jsonpCallback',
      data: {},
      success: function (data) { }
  }
  // 传入参数的拼接
  var dataStr = '';
  // 合并传入新值
  for (var attr in options) {
      defaultObj[attr] = options[attr];
  }
  // 拼接传入的参数
  for (var key in defaultObj.data) {
      dataStr += `key=${defaultObj.data[key]}&`
  }
  window[defaultObj.jsonpCallback] = function (data) {
      defaultObj.success(data);
  }
  // 生成script，回调执行callback
  var script = document.createElement('script');
  script.src = `${defaultObj.url}?${dataStr}&${defaultObj.jsonpCallback}=${defaultObj.jsonpCallback}`;
  // 获取head元素，把生成的script标签放到script后面
  var head = document.getElementsByTagName('head')[0];
  head.appendChild(script);

}

jsonp({
url: ‘http://libpre.cnsuning.com/api/jsonp/snjw.jsonp‘,
jsonpCallback: ‘cmsCallback’,
data: {
a: 1,
b: 2
},
success: function (data) {
console.log(112233, data);
}
})

10. http常用状态码 101，200，301，302，304，401，403，404，500，502等

  • 1xx Informational(信息性状态码) 接受的请求正在处理
  • 2xx Success(成功状态码) 请求正常处理完毕
  • 3xx Redirection(重定向状态码) 需要进行附加操作一完成请求
  • 4xx Client Error (客户端错误状态码) 服务器无法处理请求
  • 5xx Server Error(服务器错误状态码) 服务器处理请求出错

200 OK，表示从客户端发来的请求在服务器端被正确处理
301 moved permanently，永久性重定向，表示资源已被分配了新的 URL
302 found，临时性重定向，表示资源临时被分配了新的 URL
304 not modified，表示服务器允许访问资源，但因发生请求未满足条件的情况
401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息
403 forbidden，表示对请求资源的访问被服务器拒绝
404 not found，表示在服务器上没有找到请求的资源
500 internal sever error，表示服务器端在执行请求时发生了错误

11. restful是什么，怎么使用

Restful是一种架构设计风格，提供了设计原则和约束条件，而不是架构，而满足这些约束条件和原则的应用程序或设计就是 Restful架构或服务。
主要的设计原则：
资源与URI：网络上所有的资源都有一个资源标志符（URI）。URI的设计应该遵循可寻址性原则，具有自描述性，需要在形式上给人以直觉上的关联
统一资源接口(HTTP方法如GET，PUT和POST)：不论什么样的资源，都是通过使用相同的接口进行资源的访问
资源的表述：通过HTTP内容协商，客户端可以通过Accept头请求一种特定格式的表述，服务端则通过Content-Type告诉客户端资源的表述形式。
资源的链接：
状态的转移：
RESTful的核心就是后端将资源发布为URI，前端通过URI访问资源，并通过HTTP动词表示要对资源进行的操作

12. 从浏览器输入一个url，到页面完成的加载的过程（尽可能详细的描述）

  • 首先做 DNS 查询，如果这一步做了智能 DNS 解析的话，会提供访问速度最快的 IP 地址回来
  • 接下来是 TCP 握手，应用层会下发数据给传输层，这里 TCP 协议会指明两端的端口号，然后下发给网络层。网络层中的 IP 协议会确定 IP 地址，并且指示了数据传输中如何跳转路由器。然后包会再被封装到数据链路层的数据帧结构中，最后就是物理层面的传输了
  • TCP 握手结束后会进行 TLS 握手，然后就开始正式的传输数据
  • 数据在进入服务端之前，可能还会先经过负责负载均衡的服务器，它的作用就是将请求合理的分发到多台服务器上，这时假设服务端会响应一个 HTML 文件
  • 首先浏览器会判断状态码是什么，如果是 200 那就继续解析，如果 400 或 500 的话就会报错，如果 300 的话会进行重定向，这里会有个重定向计数器，避免过多次的重定向，超过次数也会报错
  • 浏览器开始解析文件，如果是 gzip 格式的话会先解压一下，然后通过文件的编码格式知道该如何去解码文件
  • 文件解码成功后会正式开始渲染流程，先会根据 HTML 构建 DOM 树，有 CSS 的话会去构建 CSSOM 树。如果遇到 script 标签的话，会判断是否存在 async 或者 defer ，前者会并行进行下载并执行 JS，后者会先下载文件，然后等待 HTML 解析完成后顺序执行，如果以上都没有，就会阻塞住渲染流程直到 JS 执行完毕。遇到文件下载的会去下载文件，这里如果使用 HTTP 2.0 协议的话会极大的提高多图的下载效率。
  • 初始的 HTML 被完全加载和解析后会触发 DOMContentLoaded 事件
  • CSSOM 树和 DOM 树构建完成后会开始生成 Render 树，这一步就是确定页面元素的布局、样式等等诸多方面的东西
  • 在生成 Render 树的过程中，浏览器就开始调用 GPU 绘制，合成图层，将内容显示在屏幕上了

13. 正向代理，反向代理，透明代理

14. 请求时浏览器缓存 from memory cache 和 from disk cache 的依据是什么，哪些数据什么时候存放在 Memory Cache 和 Disk Cache中

  • 200 form memory cache 不访问服务器，一般已经加载过该资源且缓存在了内存当中，直接从内存中读取缓存。浏览器关闭后，数据将不存在（资源被释放掉了），再次打开相同的页面时，不会出现from memory cache。（脚本、字体、图片）
  • 200 from disk cache 不访问服务器，已经在之前的某个时间加载过该资源，直接从硬盘中读取缓存，关闭浏览器后，数据依然存在，此资源不会随着该页面的关闭而释放掉下次打开仍然会是from disk cache。（非脚本，如css）

一般样式表会缓存在磁盘中，不会缓存到内存中，因为css样式加载一次即可渲染出页面。但是脚本可能会随时执行，如果把脚本存在磁盘中，在执行时会把该脚本从磁盘中提取到缓存中来，这样的IO开销比较大，有可能会导致浏览器失去响应。

例如：图片
访问-> 200 -> 退出浏览器
再进来-> 200(from disk cache) -> 刷新 -> 200(from memory cache)

深入理解浏览器的缓存机制