初识Http

1，简介

作为一个安卓开发者，从安卓开发的角度学习下HTTP。先来对HTTP有个大概的印象吧，一步一步慢慢了解。

Http：HyperText Transfer Protocol，即是超文本传输协议，是一个基于TCP/IP通信协议来传递数据。最新版本 HTTP/2 更是让它成为技术热点。

• 支持客户/服务器模式。支持基本认证和安全认证。
• 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
• 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
• HTTP 1.1使用持续连接：不必为每个web对象创建一个新的连接，一个连接可以传送多个对象。
• 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

2，工作流程

简单介绍下工作流程，下面一章开始简单介绍，每个点都能详细说上一本书了，下面的介绍并不钻入细节研究。

1. 首先客户机与服务器需要建立连接。只要单击某个超级链接，HTTP的工作开始。
2. 建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。
3. 服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。
4. 客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户机与服务器断开连接。如果在以上过程中的某一步出现错误，那么产生错误的信息将返回到客户端，有显示屏输出。

3，详解

一，URL

Http请求第一步肯定是要知道请求地址啊，地址都错了还玩蛋啊！404什么的多蛋疼。

URL是寻找信息时所需要的资源位置。通过URL客户端才能找到网络中的大量数据资源。

URL语法：<方案>://<用户名>:<密码>@主机:端口/路径;参数?查询#片段，几乎没有几个URL包含了所有这些组件。如：https://www.qycloud.com.cn/notice/index

• 第一部分http是URL的方案，方案告诉客户端使用什么样的协议去访问服务器了，也可以是fpt或https等。
• 第二部分 www.qycloud.com.cn ，localhost：8080，指服务器的位置。端口号默认80
• 第三部分 /notice/index是资源路径，说明了请求的是服务器上哪个特定的本地资源。

二. 发送请求：

HTTP在开始传输之前，首先需要建立TCP连接，而TCP连接的过程需要所谓的“三次握手”。——>请求 <——确认 连接——>。一个重要的概念是面向连接，既HTTP在传输完成之间并不断开TCP连接，默认都开启了Keep-Alive。

http请求由三部分组成，分别是：请求行、消息报头、请求正文。
请求报文的格式：

<方法><资源路径><协议版本>
<报文头信息>
<报文体信息>

如：

GET /notice/index  HTTP/1.1 
Host:www.qycloud.com.cn

1. 请求行

请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：Method Request-URI HTTP-Version CRLF 。

看上面那个请求报文，表示从/notice目录下请求index这个文件，这个请求行和消息报头的可以看出请求的URL：https://www.qycloud.com.cn/notice/index。

其中 Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。

2. 消息报头

请求报头允许客户端向服务器端传递请求的附加信息以及客户端自身的信息。
在HTTP/1.1 协议中，所有的请求头，除Host外，都是可选的。上面那个例子中的Host就是。

简单介绍几个请求报头：

• Accept：浏览器端可以接受的MIME类型。例如：Accept: text/html 代表浏览器可以接受服务器回发的类型为 text/html 也就是我们常说的html文档。Accept: / 代表浏览器可以处理所有类型，(一般浏览器发给服务器都是发这个)。
• Accept-Charset：浏览器可接受的字符集。如果在请求消息中没有设置这个域，缺省表示任何字符集都可以接受。
• Content-Type：例如：Content-Type: application/x-www-form-urlencoded,application/json。
• Host：（发送请求时，该报头域是必需的）
  Host请求报头域主要用于指定被请求资源的Internet主机和端口号，它通常从HTTP URL中提取出来的。
• Connection：例如：Connection: keep-alive 当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭。Connection: close 代表一个Request完成后，客户端和服务器之间用于传输HTTP数据的TCP连接会关闭。
• Cookie：最重要的请求头之一, 将cookie的值发送给HTTP服务器。
• Authorization：授权信息，通常出现在对服务器发送的WWW-Authenticate头的应答中。主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时，如果收到服务器的响应代码为401（未授权），可以发送一个包含Authorization请求报头域的请求，要求服务器对其进行验证。

3. 请求正文

就是我们Post请求传递的请求内容放在报文体信息中。

三. 返回响应信息

响应报文会将请求的结果返回给客户端。请求报文和响应报文的结构基本相同。
响应报文格式：

<协议版本><状态码><原因短语>
<报文头信息>
<报文体信息>

如：

HTTP/1.1 200 OK
Content-Type:image/gif
Conetnt-Length4567

可以看出请求报文和响应报文只有起始行的语法不同。

1. 状态行

格式如下：
HTTP-Version Status-Code Reason-Phrase CRLF

其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。
状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值.

状态码取值：

• 100~199 信息，服务器收到请求，需要请求者继续执行操作
• 200~299 成功，操作被成功接收并处理
• 300~399 重定向，需要进一步的操作以完成请求
• 400~499 客户端错误，请求包含语法错误或无法完成请求
• 500~599 服务器错误，服务器在处理请求的过程中发生了错误
  常用的有：
• 200-请求成功
• 404-请求的资源不存在
• 500-内部服务器错误

2. 响应报头：

响应报头允许服务器传递不能放在状态行中的附加响应信息，以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息。

• Date：表示消息发送的时间，时间的描述格式由rfc822定义。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。
• Content-Type：告诉客户端自己响应的对象的类型和字符集。
• Content-Length：指明实体正文的长度，以字节方式存储的十进制数字来表示。只有当浏览器使用持久HTTP连接时才需要这个数据。
• Connection：例如：Connection: keep-alive 当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。
• Connection: close 代表一个Request完成后，客户端和服务器之间用于传输HTTP数据的TCP连接会关闭，当客户端再次发送Request，需要重新建立TCP连接。
• Location：响应报头域用于重定向接受者到一个新的位置。Location响应报头域常用在更换域名的时候。

4. HTTPS

HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。可以说HTTPS = HTTP + SSL。

1. HTTPS通信过程

(来源)

image

2. HTTP 和 HTTPS 的不同之处

HTTPS 和 HTTP 唯一不同的只是一个协议头(https)的说明，其他都是一样的。

• HTTP 的 URL 以 http:// 开头，而 HTTPS 的 URL 以 https:// 开头
• HTTP 标准端口是 80 ，而 HTTPS 的标准端口是 443
• 在 OSI 网络模型中，HTTP 工作于应用层，而 HTTPS 工作在传输层
• HTTP 无需加密，而 HTTPS 对传输的数据进行加密
• HTTP 无需证书，而 HTTPS 需要认证证书

HTTPS 跟 HTTP 一样，只不过增加了 SSL。

HTTP 包含如下动作：

• 浏览器打开一个 TCP 连接
• 浏览器发送 HTTP 请求到服务器端
• 服务器发送 HTTP 回应信息到浏览器
• TCP 连接关闭

SSL 包含如下动作：

• 验证服务器端
• 允许客户端和服务器端选择加密算法和密码，确保双方都支持
• 验证客户端(可选)
• 使用公钥加密技术来生成共享加密数据
• 创建一个加密的 SSL 连接
• 基于该 SSL 连接传递 HTTP 请求

3. Https解决的问题

• 信任主机的问题
• 通讯过程中的数据的泄密和被篡改

4. SSL协议的握手协议

结合前面那张通信图看，这里只是详细解释。

• 1,客户端的浏览器向服务器传送客户端SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。
• 2,服务器向客户端传送SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。
• 3,客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步。
• 4,用户端随机产生一个用于后面通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤2中的服务器的证书中获得）对其加密，然后将加密后的“预主密码”传给服务器。
• 5,如果服务器要求客户的身份认证（在握手过程中为可选），用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的“预主密码”一起传给服务器。
• 6,如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA 是否可靠，发行CA 的公钥能否正确解开客户证书的发行CA 的数字签名，检查客户的证书是否在证书废止列表（CRL）中。检验如果没有通过，通讯立刻中断；如果验证通过，服务器将用自己的私钥解开加密的“预主密码”，然后执行一系列步骤来产生主通讯密码（客户端也将通过同样的方法产生相同的主通讯密码）。
• 7,服务器和客户端用相同的主密码即“通话密码”，一个对称密钥用于SSL 协议的安全数据通讯的加解密通讯。同时在SSL 通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。
• 8,客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤7中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。
• 9,服务器向客户端发出信息，指明后面的数据通讯将使用的步骤7中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。
• 10,SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。

参考：
Http协议
HTTP协议详解（真的很经典）
HTTP协议详解