Android 网络基础之 HTTP

摘要：对于传输内容的完整性没有确认的办法，往往容易在传输过程中被劫持篡改。目前的做法是使用由数字证书认证机构颁发的公开秘钥证书。

学习一门技术或者看一篇文章最好的方式就是带着问题去学习，这样才能在过程中有茅塞顿开、灯火阑珊的感觉，记忆也会更深刻。

了解哪些响应状态码？

get 和 post 的区别？

HTTP 和 HTTPS 的区别);

HTTP 全称是 HyperText Transfer Protocal ，即：超文本传输协议，从 1990 年开始就在 WWW 上广泛应用，是现今在 WWW 上应用最多的协议，HTTP 是应用层协议，当你上网浏览网页的时候，浏览器和 web 服务器之间就会通过 HTTP 在 Internet 上进行数据的发送和接收。HTTP 是一个基于请求/响应模式的、无状态的协议。即我们通常所说的 Request/Response。

首先看一张图

如果对网络协议还不太熟悉的同学，建议看一下上一篇文章 Android 网络基础之网络协议篇

请求报文

请求行     
请求头   
请求体   

响应报文

响应状态行   
响应头     
响应体     

解释一下各个标签：

 指请求方法，常用的主要是 Get、 Post、Head 还有其他一些我们这里就不说了，有兴趣的可以自己查阅一下

 指协议版本，现在通常都是Http/1.1了

 请求地址

 指响应状态码， 我们熟悉的200、404等等

 原因短语，200 OK 、404 Not Found 这种后面的描述就是原因短语，通常不必太关注。

请求方法（method）

列举几个比较常用的

Post 和 Get 的区别

Post 一般用于数据传递，Get 一般用于数据查询

Post 相对 Get 安全一点点，因为 Get 请求都包含在 URL 里

Post 支持更多的编码类型且不对数据类型限制

常见状态码

2XX 成功

200 OK，表示从客户端发来的请求在服务器端被正确处理

204 No content，表示请求成功，但响应报文不含实体的主体部分

206 Partial Content，进行范围请求

3XX 重定向

301 moved permanently，永久性重定向，表示资源已被分配了新的 URL

302 found，临时性重定向，表示资源临时被分配了新的 URL

303 see other，表示资源存在着另一个 URL，应使用 GET 方法丁香获取资源

304 not modified，表示服务器允许访问资源，但因发生请求未满足条件的情况

307 temporary redirect，临时重定向，和302含义相同

4XX 客户端错误

400 bad request，请求报文存在语法错误

401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息

403 forbidden，表示对请求资源的访问被服务器拒绝

404 not found，表示在服务器上没有找到请求的资源

5XX 服务器错误

500 internal sever error，表示服务器端在执行请求时发生了错误

503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求

请求和响应常见通用的 Header

指请求报文和响应报文都可以使用的字段

Cache-Control

no-cache 指客户端不缓存过期资源

no-store 指不进行缓存

max-age 指缓存资源的缓存时间比指定的值小，那么客户端就接受缓存资源，且缓存服务器不对资源有效性进行再次确认

Connection

指控制不再转发给代理的首部字段（Hop-by-hop），管理持久连接

close 指服务器像明确断开连接

Keep-Alive 指保存持久连接，HTTP/1.1前默认连接是非持久性的，如需要保存持久连接，需要增加此字段

Upgrade
可以用来指定一个完全不同的通信协议，对于这个字段，服务器可以返回101状态码

常见的请求 Header

Accept 指用户代理能够处理的媒体类型及媒体类型的相对优先级

Accept-Encoding 指用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序

Authorization 指用来告知服务器，用户代理的认证信息

Host 当一个 IP 下存在多个域名时，帮助服务器知道要请求的具体主机

User-Agent 会讲创建请求的浏览器和用户代理名称等信息传达给服务器

Http 与 Https 的区别

Http + 加密 + 认证 + 完整性保护 = Https

传统的 Http 协议是一种应用层的传输协议，Http 直接与 TCP 协议通信。其本身存在一些缺点：

Http 协议使用明文传输，容易遭到窃听。

Http 对于通信双方都没有进行身份验证，通信的双方无法确认对方是否是伪装的客户端或者服务端。

Http 对于传输内容的完整性没有确认的办法，往往容易在传输过程中被劫持篡改。

因此，在一些需要保证安全性的场景下，比如涉及到银行账户的请求时，Http 无法抵御这些攻击。

Https 则可以通过增加的 SSLTLS，支持对于通信内容的加密，以及对通信双方的身份进行验证。

Https 的加密

近代密码学中加密的方式主要有两类：

对称秘钥加密

非对称秘钥加密

对称秘钥加密是指加密与解密过程使用同一把秘钥。这种方式的优点是处理速度快，但是如何安全的从一方将秘钥传递到通信的另一方是一个问题。

非对称秘钥加密是指加密与解密使用两把不同的秘钥。这两把秘钥，一把叫公开秘钥，可以随意对外公开。一把叫私有秘钥，只用于本身持有。得到公开秘钥的客户端可以使用公开秘钥对传输内容进行加密，而只有私有秘钥持有者本身可以对公开秘钥加密的内容进行解密。这种方式克服了秘钥交换的问题，但是相对于对称秘钥加密的方式，处理速度较慢。

SSLTLS 的加密方式则是结合了两种加密方式的优点。首先采用非对称秘钥加密，将一个对称秘钥使用公开秘钥加密后传输到对方。对方使用私有秘钥解密，得到传输的对称秘钥。之后双方再使用对称秘钥进行通信。这样即解决了对称秘钥加密的秘钥传输问题，又利用了对称秘钥的高效率来进行通信内容的加密与解密。

Https的认证

SSLTLS 采用的混合加密的方式还是存在一个问题，即怎么样确保用于加密的公开秘钥确实是所期望的服务器所分发的呢？也许在收到公开秘钥时，这个公开秘钥已经被别人篡改了。因此，我们还需要对这个秘钥进行认证的能力，以确保我们通信的对方是我们所期望的对象。

目前的做法是使用由数字证书认证机构颁发的公开秘钥证书。服务器的运营人员可以向认证机构提出公开秘钥申请。认证机构在审核之后，会将公开秘钥与共钥证书绑定。服务器就可以将这个共钥证书下发给客户端，客户端在收到证书后，使用认证机构的公开秘钥进行验证。一旦验证成功，即可知道这个秘钥是可以信任的秘钥。