浏览器地址栏输入地址到页面渲染完成发生了什么?

  1. 浏览器进行地址解析，获取该地址的端口号、域名、协议、路径等信息。
  2. 将解析的域名进行DNS解析。
  3. 通过ip地址寻找服务器地址
  4. 与服务器进行三次握手建立连接
  5. 浏览器发送数据，等待服务器的响应
  6. 服务器响应并返回数据
  7. 浏览器接收到数据
  8. 浏览器开始渲染页面

URI与URL

  • URI，是uniform resource identifier，统一资源标识符，用来唯一的标识一个资源。
  • URL是uniform resource locator，统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。

HTTP1.0和HTTP1.1的区别

  1. 长连接 – HTTP1.1支持长连接和请求的流水线处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。HTTP1.0每次请求都要创建连接。
  2. 节约带宽 – HTTP1.1支持只发送header信息（不带任何body信息），如果服务器认为客户端有权限请求服务器，则返回100，客户端接收到100才开始把请求body发送到服务器；如果返回401，客户端就可以不用发送请求body了节约了带宽。
  3. HOST域 – 在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名，HTTP1.0没有host域。HTTP1.1的请求消息和响应消息都支持host域，且请求消息中如果没有host域会报告一个错误（400 Bad Request）。
  4. 缓存处理 – 在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
  5. 错误通知的管理 – 在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

HTTP1.1和HTTP2.0的区别

  1. 多路复用 –HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。
  2. 头部数据压缩 – HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。
  3. 服务器推送 – 服务端推送是一种在客户端请求之前发送数据的机制。网页使用了许多资源：HTML、样式表、脚本、图片等等。在HTTP1.1中这些资源每一个都必须明确地请求。服务器必须等待浏览器做每一个请求，网络经常是空闲的和未充分使用的。为了改善延迟，HTTP2.0引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前，免得客户端再次创建连接发送请求到服务器端获取。这样客户端可以直接从本地加载这些资源，不用再通过网络。

    五层体系结构包括：应用层、运输层、网络层、数据链路层和物理层

    osi七层模型： 应用层 表示层 会话层 传输层 网络层 链路层 物理层
  4. 应用层：直接为用户的应用进程（例如电子邮件、文件传输和终端仿真）提供服务。
    相关协议：HTTP、FTP、DNS、SMTP、Telnet等
  5. 运输层：负责向两个主机中进程之间的通信提供服务。由于一个主机可同时运行多个进程，因此运输层有复用和分用的功能
    相关协议：TCP、UDP等
  6. 网络层：在位于不同地理位置的网络中的两个主机系统之间提供连接和路径选择
    相关协议：IP、ICMP等
  7. 数据链路层：定义了如何让格式化数据以进行传输，以及如何让控制对物理介质的访问。这一层通常还提供错误检测和纠正，以确保数据的可靠传输。
    相关协议：ARP、RARP等
  8. 物理层：主要定义物理设备标准，如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的主要作用是传输比特流。

    三次握手：

    1、第一次握手：客户端给服务器发送一个 SYN 报文。
    2、第二次握手：服务器收到 SYN 报文之后，会应答一个 SYN+ACK 报文。
    3、第三次握手：客户端收到 SYN+ACK 报文之后，会回应一个 ACK 报文。
    4、服务器收到 ACK 报文之后，三次握手建立完成。

四次挥手：

  1. 第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。
  2. 第二次握手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态。
  3. 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
  4. 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态
  5. 服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

DNS域名解析过程：

  1. 在浏览器中输入域名，操作系统会先检查自己本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
  2. 如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。
  3. 如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/IP参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析。
  4. 如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析。
  5. 如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。
  6. 如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。

http协议格式

请求报文：请求报头+空行+实体
响应报文：响应报头+空行+实体
请求报头：请求行+报头（请求首部+通用首部+实体首部）
响应报头：响应状态行+报头（响应首部+通用首部+实体首部）
报头首部类型：请求首部、响应首部、通用首部、实体首部

资源表述性状态转移

根据数据抽象出来的资源，以某种表现形式，通过某种手段，在网络中发生状态转移，以此来间接实现操作资源的目的。 如果一个架构符合REST原则，就称它为RESTful架构。

  1. 每一个URI代表一种资源；
  2. 客户端和服务器之间，传递这种资源的某种表现层；
  3. 客户端通过四个HTTP动词，对服务器端资源进行操作，实现”表现层状态转化”。
  1. 因为存储在客户端，容易被客户端篡改，使用前需要验证合法性
  2. 不要存储敏感数据，比如用户密码，账户余额
  3. 使用 httpOnly 在一定程度上提高安全性
  4. 尽量减少 cookie 的体积，能存储的数据量不能超过 4kb
  5. 设置正确的 domain 和 path，减少数据传输
  6. cookie 无法跨域
  7. 一个浏览器针对一个网站最多存 20 个Cookie，浏览器一般只允许存放 300 个Cookie
  8. 移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

使用 session 时需要考虑的问题:

  1. 将 session 存储在服务器里面，当用户同时在线量比较多时，这些 session 会占据较多的内存，需要在服务端定期的去清理过期的 session
  2. session 是由单个服务器创建的,当网站采用集群部署的时候，会遇到多台 web 服务器之间如何做 session 共享的问题。
  3. 当多个应用要共享 session 时，除了以上问题，还会遇到跨域问题，因为不同的应用可能部署的主机不一样，需要在各个应用做好 cookie 跨域的处理。
  4. sessionId 是存储在 cookie 中的，假如浏览器禁止 cookie 或不支持 cookie,一般会把 sessionId 跟在 url 参数后面即重写 url，所以 session 不一定非得需要靠 cookie 实现
  5. 移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

使用 token 时需要考虑的问题:

  1. 如果你认为用数据库来存储 token 会导致查询时间太长，可以选择放在内存当中。比如 redis 很适合你对 token 查询的需求。
  2. token 完全由应用管理，所以它可以避开同源策略
  3. token 可以避免 CSRF 攻击
  4. 移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

HTTP/1.1首部字段

  1. 首部字段Upgrade用于检测HTTP协议及其他协议是否可使用更高的版本进行通信，其参数值可以用来指定一个完全不同的通信协议。
  2. 使用首部字段Via是为了追踪客户端与服务器之间的请求和响应报文的传输路径。报文经过代理或网关时，会先在首部字段Via中附加该服务器的信息，然后再进行转发。Via首部是为了追踪传输路径，所以经常会和TRACE方法一起使用。
  3. Accept首部字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级
  4. Accept-Charset首部字段可用来通知服务器用户代理支持的字符集及字符集的相对优先顺序。
  5. Accept-Encoding首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序
  6. Accept-Language用来告知服务器用户代理能够处理的自然语言集（指中文或英文等），以及自然语言集的相对优先级
  7. Authorization是用来告知服务器，用户代理的认证信息（证书值）
  8. Expect来告知服务器，期望出现的某种特定行为。因服务器无法理解客户端的期望作出回应而发生错误时，会返回状态码417 Expectation Failed。
  9. From用来告知服务器使用用户代理的用户的电子邮件地址。通常，其使用目的就是为了显示搜索引擎等用户代理的负责人的电子邮件联系方式
  10. Host会告知服务器，请求的资源所处的互联网主机名和端口号。Host首部字段在HTTP/1.1规范内是唯一一个必须被包含在请求内的首部字段。
  11. Referer会告知服务器请求的原始资源的URI。
  12. User-Agent会将创建请求的浏览器和用户代理名称等信息传达给服务器。
  13. Content-Type说明了实体主体内对象的媒体类型