## 后台和前台的http交互 前后端交互时，http报文作为信息的载体 所以http是一块很重要的内容，这一部分重点介绍它 ### http报文结构 报文一般包括了：`通用头部`，`请求/响应头部`，`请求/响应体` **通用头部** 这也是开发人员见过的最多的信息，包括如下： ``` Request Url: 请求的web服务器地址 Request Method: 请求方式 （Get、POST、OPTIONS、PUT、HEAD、DELETE、CONNECT、TRACE） Status Code: 请求的返回状态码，如200代表成功 Remote Address: 请求的远程服务器地址（会转为IP） ``` 譬如，在跨域拒绝时，可能是method为`options`，状态码为`404/405`等（当然，实际上可能的组合有很多） 其中，Method的话一般分为两批次： ``` HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。 以及几种Additional Request Methods：PUT、DELETE、LINK、UNLINK HTTP1.1定义了八种请求方法：GET、POST、HEAD、OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。 ``` `HTTP 1.0`定义参考：[https://tools.ietf.org/html/rfc1945](https://tools.ietf.org/html/rfc1945) `HTTP 1.1`定义参考：[https://tools.ietf.org/html/rfc2616](https://tools.ietf.org/html/rfc2616) 这里面最常用到的就是状态码，很多时候都是通过状态码来判断，如（列举几个最常见的）： ``` 200——表明该请求被成功地完成，所请求的资源发送回客户端 304——自从上次请求后，请求的网页未修改过，请客户端使用本地缓存 400——客户端请求有错（譬如可以是安全模块拦截） 401——请求未经授权 403——禁止访问（譬如可以是未登录时禁止） 404——资源未找到 500——服务器内部错误 503——服务不可用 ... ``` 再列举下大致不同范围状态的意义 ``` 1xx——指示信息，表示请求已接收，继续处理 2xx——成功，表示请求已被成功接收、理解、接受 3xx——重定向，要完成请求必须进行更进一步的操作 4xx——客户端错误，请求有语法错误或请求无法实现 5xx——服务器端错误，服务器未能实现合法的请求 ```  总之，当请求出错时，状态码能帮助快速定位问题，完整版本的状态可以自行去互联网搜索 **请求/响应头部** 请求和响应头部也是分析时常用到的 常用的请求头部（部分）： ``` Accept: 接收类型，表示浏览器支持的MIME类型 （对标服务端返回的Content-Type） Accept-Encoding：浏览器支持的压缩类型,如gzip等,超出类型不能接收 Content-Type：客户端发送出去实体内容的类型 Cache-Control: 指定请求和响应遵循的缓存机制，如no-cache If-Modified-Since：对应服务端的Last-Modified，用来匹配看文件是否变动，只能精确到1s之内，http1.0中 Expires：缓存控制，在这个时间内不会请求，直接使用缓存，http1.0，而且是服务端时间 Max-age：代表资源在本地缓存多少秒，有效时间内不会请求，而是使用缓存，http1.1中 If-None-Match：对应服务端的ETag，用来匹配文件内容是否改变（非常精确），http1.1中 Cookie: 有cookie并且同域访问时会自动带上 Connection: 当浏览器与服务器通信时对于长连接如何进行处理,如keep-alive Host：请求的服务器URL Origin：最初的请求是从哪里发起的（只会精确到端口）,Origin比Referer更尊重隐私 Referer：该页面的来源URL(适用于所有类型的请求，会精确到详细页面地址，csrf拦截常用到这个字段) User-Agent：用户客户端的一些必要信息，如UA头部等 ``` 常用的响应头部（部分）： ``` Access-Control-Allow-Headers: 服务器端允许的请求Headers Access-Control-Allow-Methods: 服务器端允许的请求方法 Access-Control-Allow-Origin: 服务器端允许的请求Origin头部（譬如为*） Content-Type：服务端返回的实体内容的类型 Date：数据从服务器发送的时间 Cache-Control：告诉浏览器或其他客户，什么环境可以安全的缓存文档 Last-Modified：请求资源的最后修改时间 Expires：应该在什么时候认为文档已经过期,从而不再缓存它 Max-age：客户端的本地资源应该缓存多少秒，开启了Cache-Control后有效 ETag：请求变量的实体标签的当前值 Set-Cookie：设置和页面关联的cookie，服务器通过这个头部把cookie传给客户端 Keep-Alive：如果客户端有keep-alive，服务端也会有响应（如timeout=38） Server：服务器的一些相关信息 ``` 一般来说，请求头部和响应头部是匹配分析的。 譬如，请求头部的`Accept`要和响应头部的`Content-Type`匹配，否则会报错 譬如，跨域请求时，请求头部的`Origin`要匹配响应头部的`Access-Control-Allow-Origin`，否则会报跨域错误 譬如，在使用缓存时，请求头部的`If-Modified-Since`、`If-None-Match`分别和响应头部的`Last-Modified`、`ETag`对应 还有很多的分析方法，这里不一一赘述 **请求/响应实体** http请求时，除了头部，还有消息实体，一般来说 请求实体中会将一些需要的参数都放入进入（用于post请求）。 譬如实体中可以放参数的序列化形式（`a=1&b=2`这种），或者直接放表单对象（`Form Data`对象，上传时可以夹杂参数以及文件），等等 而一般响应实体中，就是放服务端需要传给客户端的内容 一般现在的接口请求时，实体中就是对于的信息的json格式，而像页面请求这种，里面就是直接放了一个html字符串，然后浏览器自己解析并渲染。 **CRLF** CRLF（Carriage-Return Line-Feed），意思是回车换行，一般作为分隔符存在 请求头和实体消息之间有一个CRLF分隔，响应头部和响应实体之间用一个CRLF分隔 一般来说（分隔符类别）： ``` CRLF->Windows-style LF->Unix Style CR->Mac Style ``` 如下图是对某请求的http报文结构的简要分析  ### cookie以及优化 cookie是浏览器的一种本地存储方式，一般用来帮助客户端和服务端通信的，常用来进行身份校验，结合服务端的session使用。 场景如下（简述）： ``` 在登陆页面，用户登陆了 此时，服务端会生成一个session，session中有对于用户的信息（如用户名、密码等） 然后会有一个sessionid（相当于是服务端的这个session对应的key） 然后服务端在登录页面中写入cookie，值就是:jsessionid=xxx 然后浏览器本地就有这个cookie了，以后访问同域名下的页面时，自动带上cookie，自动检验，在有效时间内无需二次登陆。 ``` 上述就是cookie的常用场景简述（当然了，实际情况下得考虑更多因素） 一般来说，cookie是不允许存放敏感信息的（千万不要明文存储用户名、密码），因为非常不安全，如果一定要强行存储，首先，一定要在cookie中设置`httponly`（这样就无法通过js操作了），另外可以考虑rsa等非对称加密（因为实际上，浏览器本地也是容易被攻克的，并不安全） 另外，由于在同域名的资源请求时，浏览器会默认带上本地的cookie，针对这种情况，在某些场景下是需要优化的。 譬如以下场景： ``` 客户端在域名A下有cookie（这个可以是登陆时由服务端写入的） 然后在域名A下有一个页面，页面中有很多依赖的静态资源（都是域名A的，譬如有20个静态资源） 此时就有一个问题，页面加载，请求这些静态资源时，浏览器会默认带上cookie 也就是说，这20个静态资源的http请求，每一个都得带上cookie，而实际上静态资源并不需要cookie验证 此时就造成了较为严重的浪费，而且也降低了访问速度（因为内容更多了） ``` 当然了，针对这种场景，是有优化方案的（多域名拆分）。具体做法就是： - 将静态资源分组，分别放到不同的域名下（如`static.base.com`） - 而`page.base.com`（页面所在域名）下请求时，是不会带上`static.base.com`域名的cookie的，所以就避免了浪费 说到了多域名拆分，这里再提一个问题，那就是： - 在移动端，如果请求的域名数过多，会降低请求速度（因为域名整套解析流程是很耗费时间的，而且移动端一般带宽都比不上pc） - 此时就需要用到一种优化方案：`dns-prefetch`（让浏览器空闲时提前解析dns域名，不过也请合理使用，勿滥用） 关于cookie的交互，可以看下图总结  ### gzip压缩 首先，明确`gzip`是一种压缩格式，需要浏览器支持才有效（不过一般现在浏览器都支持）， 而且gzip压缩效率很好（高达70%左右） 然后gzip一般是由`apache`、`tomcat`等web服务器开启 当然服务器除了gzip外，也还会有其它压缩格式（如deflate，没有gzip高效，且不流行） 所以一般只需要在服务器上开启了gzip压缩，然后之后的请求就都是基于gzip压缩格式的， 非常方便。 ### 长连接与短连接 首先看`tcp/ip`层面的定义： - 长连接：一个tcp/ip连接上可以连续发送多个数据包，在tcp连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接，一般需要自己做在线维持（类似于心跳包） - 短连接：通信双方有数据交互时，就建立一个tcp连接，数据发送完成后，则断开此tcp连接 然后在http层面： - `http1.0`中，默认使用的是短连接，也就是说，浏览器没进行一次http操作，就建立一次连接，任务结束就中断连接，譬如每一个静态资源请求时都是一个单独的连接 - http1.1起，默认使用长连接，使用长连接会有这一行`Connection: keep-alive`，在长连接的情况下，当一个网页打开完成后，客户端和服务端之间用于传输http的tcp连接不会关闭，如果客户端再次访问这个服务器的页面，会继续使用这一条已经建立的连接 注意： **keep-alive不会永远保持，它有一个持续时间，一般在服务器中配置（如apache），另外长连接需要客户端和服务器都支持时才有效** ### http 2.0 http2.0不是https，它相当于是http的下一代规范（譬如https的请求可以是http2.0规范的） 然后简述下http2.0与http1.1的显著不同点： - http1.1中，每请求一个资源，都是需要开启一个tcp/ip连接的，所以对应的结果是，每一个资源对应一个tcp/ip请求，由于tcp/ip本身有并发数限制，所以当资源一多，速度就显著慢下来 - http2.0中，一个tcp/ip请求可以请求多个资源，也就是说，只要一次tcp/ip请求，就可以请求若干个资源，分割成更小的帧请求，速度明显提升。 所以，如果http2.0全面应用，很多http1.1中的优化方案就无需用到了（譬如打包成精灵图，静态资源多域名拆分等） 然后简述下http2.0的一些特性： - 多路复用（即一个tcp/ip连接可以请求多个资源） - 首部压缩（http头部压缩，减少体积） - 二进制分帧（在应用层跟传送层之间增加了一个二进制分帧层，改进传输性能，实现低延迟和高吞吐量） - 服务器端推送（服务端可以对客户端的一个请求发出多个响应，可以主动通知客户端） - 请求优先级（如果流被赋予了优先级，它就会基于这个优先级来处理，由服务器决定需要多少资源来处理该请求。） ### https https就是安全版本的http，譬如一些支付等操作基本都是基于https的，因为http请求的安全系数太低了。 简单来看，https与http的区别就是： **在请求前，会建立ssl链接，确保接下来的通信都是加密的，无法被轻易截取分析** 一般来说，如果要将网站升级成https，需要后端支持（后端需要申请证书等），然后https的开销也比http要大（因为需要额外建立安全链接以及加密等），所以一般来说http2.0配合https的体验更佳（因为http2.0更快了） 一般来说，主要关注的就是SSL/TLS的握手流程，如下（简述）： ``` 1. 浏览器请求建立SSL链接，并向服务端发送一个随机数–Client random和客户端支持的加密方法，比如RSA加密，此时是明文传输。 2. 服务端从中选出一组加密算法与Hash算法，回复一个随机数–Server random，并将自己的身份信息以证书的形式发回给浏览器 （证书里包含了网站地址，非对称加密的公钥，以及证书颁发机构等信息） 3. 浏览器收到服务端的证书后 - 验证证书的合法性（颁发机构是否合法，证书中包含的网址是否和正在访问的一样），如果证书信任，则浏览器会显示一个小锁头，否则会有提示 - 用户接收证书后（不管信不信任），浏览会生产新的随机数–Premaster secret，然后证书中的公钥以及指定的加密方法加密`Premaster secret`，发送给服务器。 - 利用Client random、Server random和Premaster secret通过一定的算法生成HTTP链接数据传输的对称加密key-`session key` - 使用约定好的HASH算法计算握手消息，并使用生成的`session key`对消息进行加密，最后将之前生成的所有信息发送给服务端。 4. 服务端收到浏览器的回复 - 利用已知的加解密方式与自己的私钥进行解密，获取`Premaster secret` - 和浏览器相同规则生成`session key` - 使用`session key`解密浏览器发来的握手消息，并验证Hash是否与浏览器发来的一致 - 使用`session key`加密一段握手消息，发送给浏览器 5. 浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束， ``` **之后所有的https通信数据将由之前浏览器生成的session key并利用对称加密算法进行加密**