什么是HTTP
HyperText Transfer Protocol（超文本传输协议），缩写为HTTP，是互联网上应用最为广泛的一种网络协议。HTTP协议位于TCP/IP协议栈的应用层。
HTTP是一个客户端终端（用户）和服务器端（网站）请求和应答的标准。更直白的说就是提供一种发布和接收HTML页面的方法。通过使用Web浏览器，客户端发起一个HTTP请求到服务器上指定端口（默认端口为80）。我们称这个客户端为用户代理程序（user agent）。应答的服务器上存储着一些资源，比如HTML文件和图像。我们称这个应答服务器为源服务器（origin server）。在用户代理和源服务器中间可能存在多个“中间层”，比如代理服务器、网关或者隧道（tunnel）。
HTTP协议的特点
面向无连接：每次连接只处理一个请求，请求结束立即断开连接。
无状态：请求结束后立即断开连接，不保存本次请求的任何信息
HTTP请求响应机制
客户端向服务器发送请求。一个HTTP请求包括4部分：请求行、请求头、空行和请求数据。
服务器处理请求并响应。一个响应也由4部分组成：状态行、响应头、空行和响应数据。响应数据一般是HTML内容。
Web服务器关闭本次连接，客户端浏览器解析响应数据。
URL（Uniform Resource Locator），统一资源定位符。
通过HTTP协议请求的资源由URI来标识。
我们在浏览器的地址栏里输入的网站地址叫做URL。就像每家每户都有一个门牌地 址一样，每个网页也都有一个Internet地址。当你在浏览器的地址框中输入一个URL或是单击一个超级链接时，确定了要浏览的地址。浏览器通过超文本传输协议(HTTP)，将Web服务器上站点的网页代码提取出来，并呈现出客户端需要的网页
HTTP状态码
- 404：找不到该页面
- 403：禁止访问
- 500：内部服务器错误
- 503：服务器繁忙
- 301：URL发生永久性转移
- 302：URL发生暂时性转移
更多可以参见HTTP状态码-菜鸟教程
HTTP存在安全问题
HTTP协议传输的数据都是未加密的，也就是明文，因此使用HTTP协议传输隐私信息非常不安全。那么是否可以对HTTP传送的数据加密呢？当然可以，这就是HTTPS。
HTTPS
以下内容摘自HTTPS那些事（一）HTTPS原理 和图解HTTPS。
为了保证这些隐私数据能加密传输，可以使用SSL / TLS协议对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。
简单说，HTTPS由两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。
HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。握手过程的简单描述如下：
- 客户端发起HTTPS请求，并将自己支持的一套加密规则发送给网站。
- 网站从中选出一组加密算法与HASH算法，并将自己的身份信息以数字证书的形式发回给浏览器。数字证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是公钥，网站留有与之对应的私钥。
- 获得网站证书之后浏览器要做以下工作：
这部分工作是有客户端的TLS来完成的,要做以下工作
a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，如果发现异常，出一个警告框，提示证书存在问题。
b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。
c) 使用约定好的HASH计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。 - 网站接收浏览器发来的数据之后要做以下的操作：
a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。
b) 使用密码加密一段握手消息，发送给浏览器。 - 浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。
这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。
TLS握手过程中如果有任何错误，都会使加密连接断开，从而阻止了隐私信息的传输。正是由于HTTPS非常的安全，攻击者无法从中找到下手的地方，于是更多的是采用了假证书的手法来欺骗客户端，从而获取明文的信息，但是这些手段都可以被识别出来。
HTTP1.0和HTTP1.1的主要区别 :
- HTTP1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。
- HTTP1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。例如：一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。
在HTTP/1.0中，要建立长连接，可以在请求消息中包含Connection: Keep-Alive头域，如果服务器愿意维持这条连接，在响应消息中也会包含一个Connection: Keep-Alive的头域。同时，可以加入一些指令描述该长连接的属性，如max，timeout等。
KeepAlive的原理
在HTTP1.0和HTTP1.1协议中都有对KeepAlive的支持.HTTP1.0需要在request中增加”Connection:keep-alive“header才能够支持，而HTTP1.1默认支持。
- HTTP1.0 KeepAlive支持的数据交互流程如下：
a) Client发出request，其中该request的HTTP版本号为1.0。同时在request中包含一个header：”Connection： keep-alive“。
b) Web Server收到request中的HTTP协议为1.0及”Connection： keep-alive“就认为是一个长连接请求，其将在response的header中也增加”Connection： keep-alive“。同时不会关闭已建立的tcp连接。
c) Client收到Web Server的response中包含”Connection： keep-alive“，就认为是一个长连接，不close tcp连接。并用该tcp连接再发送request。（跳转到a)）
2.HTTP1.1 KeepAlive支持的数据交互流程如下：
a) Client发出request，其中该request的HTTP版本号为1.1。
b) Web Server收到request中的HTTP协议为1.1就认为是一个长连接请求，其将在response的header中也增加”Connection： keep-alive“。同是不会关闭已建立的tcp连接。
c) Client收到Web Server的response中包含”Connection： keep-alive“，就认为是一个长连接，不close tcp连接。并用该tcp连接再发送request。（跳转到a)）
网友评论