大话http协议

Posted 2023-05-02

参考技术A

  http协议是超文本传输协议（HTTP，HyperText Transfer Protocol)的简称。http协议是互联网中使用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。
  http协议是一个客户端和服务器端请求和应答的标准（TCP）。客服端和服务端相互通信，必须要一种双方都能明白的语言。就好比两个人讲话，你说英语，我说汉语，肯定是谁都听不懂，瞎耽误工夫。咱俩交流就必须有互相能懂的语言。http协议就是定义了一种信息组合的标准，客户端和服务器都根据这个标准来通信。客户端想要从服务器那里获得资源，首先得需要服务器的地址，这决定了去哪个服务器请求资源。接着得需要资源路径，因为服务器肯定需要存有很多资源。有时候还需要向服务器传一些信息，比如用户名，密码等。http协议的请求标准就是定义了客户端应该怎样把这些信息组合，服务器才能正确解析。服务器接收到客服端的请求，要把服务端需要的数据传给客户端，http协议的响应标准就是定义了服务端向客户端传输数据的标准。

  为什么要从URL开始说起呢？因为我们发起一个http请求，只需要两个东西URL和参数，有时候还没有参数。所以URL对于http请求是不可获取的。为什么URL这么重要？下面我们就认识一下URL。
  URL是统一资源定位符，对可以从互联网上得到的资源的位置和访问方法的一种简洁的表示，是互联网上标准资源的地址（ 摘自百度百科 ）。通俗点讲，就是一个URL包括了服务器的地址，资源的位置，有时候还有参数。
  举个例子： https://www.jianshu.com/u/f499dc93facb （我的地址，会定期更新一些技术博客，欢迎关注。）,这就是一个URL地址。
​​http ： 表示这个URL是遵守http协议。其实还有很多其他的协议。
www.jianshu.com ：域名。域名要解析成IP地址，系统就是通过这个找到服务器的。

  有了URL之后，我们就可以构建一个HTTP请求了。一个NSMutableURLRequet对象就代表一个HTTP请求。

  这样就可以发起http请求了。此时默认请求方法（HTTPMethod）为 GET ，实体头部（Content-Type）为 application/x-www-form-urlencoded 。
  请求方法一共有8种，GET, POST ， HEAD，OPTIONS，PUT， DELETE，TRACE 和 CONNECT 方法，最常用的GET和POST。GET和POST的区别就是参数的位置。GET把参数放在?后面，上面的例子就是。POST把参数放在请求体里面。我们也可以修改请求方法。

  实体头部（Content-Type）是参数的组合方式，常见的有application/x-www-form-urlencoded和application/json。默认为application/x-www-form-urlencoded，参数这样组合：key1=value1&key2=value2。如果是application/json，参数就要先变成JSON字符串，然后转化成Data，放在HTTPBody里面。

  除此之外，如果我们还想往服务器传一些其他的信息怎么办？http还定义了其他参数，设置方式和实体头部（Content-Type）的设置方式一样。
Accept-Language ：客户端的语言环境。eg：zh-Hans-CN;q=1。表示汉语。
User-Agent ：客户端软硬件环境。eg：Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0。Mozilla：项目名称；
5.0：项目版本号；Macintosh：硬件名称（Macintosh简称Mac）；Intel Mac OS X 10.11：Mac系统的名字以及版本号。
Accept-Encoding ：客户端支持的数据压缩格式。eg：gzip
  HTTP协议规定，一个完整的由客户端发给服务器的HTTP请求包括请求头，请求行，请求体。那这么多信息，HTTP协议是怎么分配的呢？
​1. 请求头 ：包含了对客户端的软硬件环境描述、客户端请求的主机地址等信息。
（1）客户端想访问的主机地址和端口
​Host：218.30.115.123:8080
​（2）客户端的软硬件环境
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0
（3）客户端所能接收的数据类型
Accept：text/html , / ​
（4）客户端的语言环境
Accept-Language：zh-cn
（5）客户端支持的编码格式
Accept-Encoding：gzip
2. 请求行 ：包含了请求方法、请求资源路径、HTTP协议版本；
GET /u/2552663324 HTTP/1.1
3. 请求体 ：GET、HEAD和DELETE请求方法没有，其他的方法才有。是客户端发给服务器的请求参数。

  客户端向服务器发送请求，服务器做出响应，及返回数据给客户端。那服务器都返回了写什么数据呢？HTTP协议规定：1个完整的HTTP响应中包换以下内容：状态行，响应头，实体内容，和HTTP请求相对。
1. 状态行 ：包含了HTTP协议版本、状态码、状态英文名称。
（1）HTTP/1.1 200 OK
状态码：
1 (信息类)：表示接收到请求并且继续处理
2 (响应成功)：表示动作被成功接收、理解和接受
3 (重定向类)：为了完成指定的动作，必须接受进一步处理
4 (客户端错误类)：请求包含错误语法或不能正确执行
5 (服务端错误类)：服务器不能正确执行一个正确的请求
​​2. 响应头 ：包含了对服务器的描述、对返回数据的描述。
（1）服务器的环境
Server：Apache-Coyote/1.1
（2）返回的数据类型
Content-Type：text/html;charset=UTF-8​
（3）返回的数据长度
Content-Length：3012
（4）​​响应的时间
Date：Wed, 28 Sep 2016 06:38:08 GMT
3. 实体内容**：服务器返回给客户端的具体数据。

大话Oauth2.0，从概念到实践

Oauth2.0本身：

Oauth2.0是一种授权协议，当然也归属为安全协议的范畴，在实际执行的时候就是保护互联网中不断增长的大量WEB API的安全访问。OAuth2.0共包含四种角色，分别是资源所有者、第三方应用（也称为客户端client）、授权服务器和资源服务器。如下图所示，某公司A开发了一个微信小程序（第三方应用）可以帮助我（资源所有者）美化微信服务器（资源服务器）上面的头像，我在用这个微信小程序开发的美化头像功能的时候，首先要给微信小程序授权（授权服务器），这个微信小程序才能访问我的头像，实际上访问的时候微信小程序就是通过WEB API来调用的。授权的过程中我是不可能把我的账号密码给它的，这样的前提下就会有另外方式的授权，也就是上面介绍的现在国际通用的标准OAuth2.0。

OAuth2.0协议流程描述了四种角色之间的交互过程，如下图所示。

上面的序列图一共分为以下6个步骤：

（1）第三方应用请求资源所有者授权。

（2）资源所有者同意给第三方应用授权。

（3）第三方应用使用步骤2中获得的授权，向授权服务器申请令牌。

（4）授权服务器对第三方应用进行认证并确认无误后，同意发放令牌。

（5）第三方应用使用步骤4中发放的令牌向资源服务器申请获取资源。

（6）资源服务器确认令牌无误后，向第三方应用开放资源访问。

关于更详细的Oauth2.0流程介绍，也可以参考《架构修炼之道》第2章 "开放之道" 内容。

第三方开发者ISV的实践：

如果按照开发语言类型来区分可以有JAVA、.net、PHP等不同的ISV应用类型，但语言分类对于授权的场景意义不大，因为虽然是不同的语言但大家都是遵守Oauth2.0协议。在授权上区分ISV接入流程我们则需要按照ISV应用有无Web Server来区分。有Web Server的归为一类，走Server-side flow；没有Web Serve的归为另外一类，走Client-side flow流程。

本文先介绍Server-side flow流程，共包含3个步骤。

步骤一：拼接授权URL

以京东宙斯开放平台为例

https://open-oauth.jd.com/oauth2/to_login?app_key=XXXXX&response_type=code&redirect_uri=XXXXX

有三个必填参数，分别是app_key，response_type，redirect_uri，下面是该三个参数的具体含义。

名称	是否必填	参数值
app_key	是	ISV在宙斯开放平台创建应用的时候由系统分配
response_type	是	固定值code，默认采用code换取token的方式
redirect_uri	是	ISV的应用访问地址，创建应用的时候由ISV配置

PS:左右滑动查看完整列表

步骤二：引导用户登录授权

引导用户登录，并为ISV应用进行授权。

步骤三：获取CODE

ISV获取到CODE之后就可以执行步骤四。

步骤四：用CODE换取ACCESSTOKEN

https://open-oauth.jd.com/oauth2/access_token?app_key=XXXXX&app_secret=XXXXX&grant_type=authorization_code&code=XXXXX，这里的code是通过步骤三获取到的。

名称	是否必填	参数值
app_key	是	ISV在宙斯开放平台创建应用的时候由系统分配
app_secret	是	宙斯开放平台分配给当前app_key对应的应用的秘钥
grant_type	是	固定为authorization_code
code	是	步骤三中获取到的值

PS:左右滑动查看完整列表

返回值示例：

{

access_token: "a3207b6b5ad04249ad1dbf6a98248bea",//所需要的access_token

expires_in: 3600000,//单位ms，该access_token的过期时间

refresh_token: "4ecbbab0e9e443159c518da1d10741ad"//再不需要用户重新授权的情况下，用于获取新的access_token

}

access_token是有有效期的，这一点是从安全角度来考虑的，因为如果access_token没有时效性，一旦泄露则会被攻击者长期使用。好比我们的个人密码需要定期修改一样。比如笔者跟公司签订了五年期的合同，在这个五年时间内公司要求我们的内部ERP系统的密码需要三个月更新一次，这样避免了密码一旦泄露造成了长期的安全风险。在订购类型的第三方IT工具类应用中access_token是用户授权之后ISV的应用才能获取到的，比如用户购买了该ISV的一款SASS软件为期6个月。如果这6个月时间内出于安全考虑需要更新access_token的值，肯定不能让用户再授权一次，这样体验非常不友好。此时refresh_token就派上了用场，ISV可以利用refresh_token去请求开放平台获取新的access_token的值。

当用户授权ISV之后会获取到一个accestoken，对于ISV来讲accestoken相当于登录成功了ISV软件之后的PIN。此时ISV需要将这个用户的accestoken会话保存下来，可以加密存储到cookie中，也可以放到ISV软件服务端的session中。ISV软件后续访问平台的接口要求必须都要有该accestoken，这样会话状态被保存下来之后则会使得ISV应用调用平台接口更加的便利，实际上相当于用户登录了一个普通的WEB应用之后，每次这个WEB应用服务端程序都能获取到该用户的会话信息一样。

平台一方的实践：

我作为一个用户需要授权给我当前将要使用的软件服务商，这样软件服务商才可以被允许去访问我的数据。理论上我是需要每次都进行授权动作才能完成软件的使用，那么我们平时会发现比如在微信中使用第三方小程序的时候我只在第一次访问的时候进行了授权动作，以后使用的时候并没有要求我再次进行授权，这是如何实现的呢。再比如下图所示，在用户点击立即使用的时候也会遇到同样的场景：初次使用和再次使用。

总结

本文先后从概念到开发者实践以及平台一方的实践去介绍了Oauth2.0。它是一个基于HTTP的协议，如果采用授权码类型比如本文中所述的Server-side flow则要求必须有Web Server，我们也正是按照该流程去介绍如何实践的。

想了解Oauth2.0的同学请持续关注，未完待续...

我的新书正在京东热售中，点击 阅读原文 可直接下单