1.1. 基础

1.1.1. 转发与重定向

转发是服务器行为,重定向是客户端行为。

  • 转发:你先去了A局,A局看了以后,知道这个事情其实应该B局来管,但是他没有把你退回来,而是让你坐一会儿,自己到后面办公室联系了B的人,让他们办好后,送了过来。
  • 重定向:你先去了A局,A局的人说:“这个事情不归我们管,去B局”,然后,你就从A退了出来,自己乘车去了B局。

  • 转发过程:客户浏览器发送http请求>>web服务器接受此请求>>调用内部的一个方法在容器内部完成请求处理和转发动作>>将目标资源发送给客户;

    • 转发的路径必须是同一个web容器下的url,其不能转向到其他的web路径上去,中间传递的是自己的容器内的request。
    • 在客户浏览器路径栏显示的仍然是其第一次访问的路径,也就是说客户是感觉不到服务器做了转发的。转发行为是浏览器只做了一次访问请求。
  • 重定向过程:客户浏览器发送http请求>>web服务器接受后发送302状态码响应及对应新的location给客户浏览器>>客户浏览器发现是302响应,则自动再发送一个新的http请求,请求url是新的location地址>>服务器根据此请求寻找资源并发送给客户。

    • location可以重定向到任意URL,既然是浏览器重新发出了请求,则就没有什么request传递的概念了。
    • 在客户浏览器路径栏显示的是其重定向的路径,客户可以观察到地址的变化的。重定向行为是浏览器做了至少两次的访问请求

1.1.2. GET与POST请求

常规回答:

  • GET在浏览器回退时是无害的,而POST会再次提交请求。
  • GET产生的URL地址可以被Bookmark,而POST不可以。
  • GET请求会被浏览器主动cache,而POST不会,除非手动设置。
  • GET请求只能进行url编码,而POST支持多种编码方式。
  • GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。
  • GET请求在URL中传送的参数是有长度限制的,而POST么有。
  • 对参数的数据类型,GET只接受ASCII字符,而POST没有限制。
  • GET比POST更不安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息。
  • GET参数通过URL传递,POST放在Request body中。

深入回答:

  • GET:浏览器会把http header和data一并发送出去,服务器响应200(返回数据);
  • POST:浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)。
  • GET与POST都有自己的语义,不能随便混用。
  • 在网络环境好的情况下,发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下,两次包的TCP在验证数据包完整性上,有非常大的优点。
  • 并不是所有浏览器都会在POST中发送两次包,Firefox就只发送一次。

1.1.3. parameter 形式传参

如何在POST请求中使用parameter 传递参数?

  1. 第一种parameter形式的传参和一般get请求一样,参数会带在请求路径尾部,即?a=1&b=2&c=3...,对于这种形式的参数,在控制台可以看到参数形式是“Query String Parameter”,后端用req.query进行处理。
  2. 第二种parameter形式的传参,被他们叫做“parameter”,但是它在请求时不会跟随到请求路径的尾部,即对外是不能直观看到的。对于这种形式的参数,在控制台可以看到参数形式是“Form Data”,它对应的Request Headers是: Content-Type:application/x-www-form-urlencoded。后端也用req.query进行处理这类型参数。

1.1.4. POST请求方式:

  • application/x-www-form-urlencoded: 这应该是最常见的 POST 提交数据的方式了。浏览器的原生
    表单,如果不设置 enctype 属性, 那么最终就会以这种方式提交数据。
  • multipart/form-data: 我们使用表单上传文件时,必须让
    表单的 enctype 等于 multipart/form-data
  • application/json: 可以方便的提交复杂的结构化数据,特别适合 RESTful 的接口。
  • text/xml: 臃肿

1.2. Session

1.2.1. Session与Cookie

服务器通过Cookie知道你是谁,通过Session知道你干了什么。

  • Session是在服务端保存的一个数据结构,用来跟踪用户的状态,这个数据可以保存在集群、数据库、文件中;
  • Cookie是客户端保存用户信息的一种机制,用来记录用户的一些信息,也是实现Session的一种方式。

一般的请求流程:

  1. 用户向服务器发送用户名和密码。
  2. 服务器验证通过后,在当前对话(session)里面保存相关数据,比如用户角色、登录时间等等。
  3. 服务器向用户返回一个 session_id,写入用户的 Cookie。
  4. 用户随后的每一次请求,都会通过 Cookie,将 session_id 传回服务器。
  5. 服务器收到 session_id,找到前期保存的数据,由此得知用户的身份。

1.2.2. Session与Token

为了解决Session扩展性不好的问题。假如A与B两家公司是关联服务,现在要求登录一个网站即可访问另一个,处理方法有两个,第一,将Session数据持久化;第二,服务器将Session数据存在客户端(Token就是代表)。

token流程:

  1. 注册登录
  2. 服务端将生成一个token,并将token与user加密生成一个密文;
  3. 将token+user+密文数据 返回给浏览器
  4. 客户端再次访问时传递token+user+密文数据;
  5. 后台会再次使用token+user生成新密文,与传递过来的密文比较,一致则正确。

参考Json Web Token入门。

results matching ""

    No results matching ""