http和https详解-CSDN博客

引言

1.HTTP

引言

超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息，HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。

　　为了解决HTTP协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议HTTPS，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

1.HTTP

1.支持客户/服务器模式。
2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

1.1请求

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

1.请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：

Method Request-URI HTTP-Version CRLF

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

2.请求方法（所有方法全为大写）有多种，各个方法的解释如下：

GET 请求获取Request-URI所标识的资源
POST 在Request-URI所标识的资源后附加新的数据
HEAD 请求获取由Request-URI所标识的资源的响应消息报头
PUT 请求服务器存储一个资源，并用Request-URI作为其标识
DELETE 请求服务器删除Request-URI所标识的资源
TRACE 请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT 保留将来使用
OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求

3.GET和POST区别

GET是向服务器获取数据（读），POST向服务器传送数据（更新）
GET传送的数据量较小，不能大于2KB（主要是受URL长度限制）；POST传送的数据量较大，一般默认不受限制，但实际上取决于服务器的处理能力
POST的安全性更高。GET在传输过程中，数据被放在请求的URL中，而现今有很多服务器、代理服务器或者用户代理都会将请求URL记录在日志文件中，然后放到某个地方，这样，可能有些隐私信息会被第三方看到。再比如登录的时候，浏览器缓存也可能造成信息泄露。POST请求会将请求的数据放在HTTP请求包的包体中，POST请求的所有操作对用户来说都是不可见的。

1.2响应

HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文

1.状态行格式如下：
HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。

2.状态码

状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：

1xx：指示信息--表示请求已接收，继续处理
2xx：成功--表示请求已被成功接收、理解、接受
3xx：重定向--要完成请求必须进行更进一步的操作
4xx：客户端错误--请求有语法错误或请求无法实现
5xx：服务器端错误--服务器未能实现合法的请求

常见状态代码、状态描述、说明：

200 OK //客户端请求成功
400 Bad Request //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden //服务器收到请求，但是拒绝提供服务
404 Not Found //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

1.3报头

HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。
请求消息和响应消息都是由开始行（对于请求消息，开始行就是请求行，对于响应消息，开始行就是状态行），消息报头（可选），空行（只有CRLF的行），消息正文（可选）组成。
HTTP消息报头包括普通报头、请求报头、响应报头、实体报头。每一个报头域都是由 名字+“：”+空格+值 组成，消息报头域的名字是大小写无关的。

1.普通报头：即可用于请求，也可用于响应，是作为一个整体而不是特定资源与事务相关联。

Cache-Control

用于指定缓存指令，缓存指令是单向的（响应中出现的缓存指令在请求中未必会出现），且是独立的（一个消息的缓存指令不会影响另一个消息处理的缓存机制），HTTP1.0使用的类似的报头域为Pragma。

请求：

no-cache：（不要缓存的实体，要求现在从WEB服务器去取）
max-age：（只接受 Age 值小于 max-age 值，并且没有过期的对象）
max-stale：（可以接受过去的对象，但是过期时间必须小于max-stale 值）
min-fresh：（接受其新鲜生命期大于其当前 Age 跟 min-fresh 值之和的缓存对象）

响应：

public(可以用 Cached 内容回应任何用户)
private（只能用缓存内容回应先前请求该内容的那个用户）
no-cache（可以缓存，但是只有在跟WEB服务器验证了其有效后，才能返回给客户端）
max-age：（本响应包含的对象的过期时间）
ALL: no-store（不允许缓存）

Data

表示消息产生的日期和时间

Connection

请求：

close（告诉WEB服务器或者代理服务器，在完成本次请求的响应后，断开连接，不要等待本次连接的后续请求了）。
keepalive（告诉WEB服务器或者代理服务器，在完成本次请求的响应后，保持连接，等待本次连接的后续请求）。

响应：

close（连接已经关闭）。
keepalive（连接保持着，在等待本次连接的后续请求）。
Keep-Alive：如果浏览器请求保持连接，则该头部表明希望 WEB 服务器保持连接多长时间（秒）。
例如：Keep-Alive：300

2.请求报头：允许客户端传递关于自身的信息和希望的响应形式。

Accept

Accept：告诉WEB服务器自己接受什么介质类型，*/* 表示任何类型，type/* 表示该类型下的所有子类型，type/sub-type。 Accept-Charset：浏览器申明自己接收的字符集
Accept-Encoding：浏览器申明自己接收的编码方法，通常指定压缩方法，是否支持压缩，支持什么压缩方法（gzip，deflate）
Accept-Language：：浏览器申明自己接收的语言语言跟字符集的区别：中文是语言，中文有多种字符集，比如big5，gb2312，gbk等等。

Accept-Ranges：WEB服务器表明自己是否接受获取其某个实体的一部分（比如文件的一部分）的请求。bytes：表示接受，none：表示不接受。

Authorization

当客户端接收到来自WEB服务器的 WWW-Authenticate 响应时，该头部来回应自己的身份验证信息给WEB服务器。

Host（发送请求时，该报头域是必须的）

Host请求报头域主要用于指定被请求资源的Internet主机和端口号，它通常从HTTP URL中提取出来的，

eg：我们在浏览器中输入：http://www.guet.edu.cn/index.html
浏览器发送的请求消息中，就会包含Host请求报头域：Host：www.guet.edu.cn
此处使用缺省端口号80，若指定了端口号，则变成：Host：www.guet.edu.cn:指定端口号

User-Agent

浏览器表明自己的身份（是哪种浏览器）。
eg：User-Agent：Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

3.响应报头：服务器用于传递自身信息和对Request-URI所标识的资源进行下一步访问的信息

Location

WEB服务器告诉浏览器，试图访问的对象已经被移到别的位置了，到该头部指定的位置去取。

eg：Location： http://i0.sinaimg.cn/dy/deco/2008/0528/sinahome_0803_ws_005_text_0.gif

Server

WEB 服务器表明自己是什么软件及版本等信息。与User-Agent请求报头域是相对应的。
eg:Server：Apache/2.0.61 (Unix)

WWW-Authenticate

必须被包含在401（未授权的）响应消息中，客户端收到401响应消息时候，并发送Authorization报头域请求服务器对其进行验证时，服务端响应报头就包含该报头域。
eg：WWW-Authenticate:Basic realm="Basic Auth Test!" //可以看出服务器对请求资源采用的是基本验证机制。

4.实体报头：定义被传送资源的信息。即可用于请求，也可用于响应。

Content

Content-Encoding：WEB服务器表明自己使用了什么压缩方法（gzip，deflate）压缩响应中的对象。 eg：Content-Encoding：gzip
Content-Language：WEB 服务器告诉浏览器自己响应的对象的语言。
Content-Length： WEB 服务器告诉浏览器自己响应的对象的长度。 eg：Content-Length: 26012
Content-Range： WEB 服务器表明该响应包含的部分对象为整个对象的哪个部分。 eg：Content-Range: bytes 21010-47021/47022
Content-Type： WEB 服务器告诉浏览器自己响应的对象的类型。 eg：Content-Type：application/xml

Last-Modified

Last-Modified实体报头域用于指示资源的最后修改日期和时间。eg：Last-Modified：Tue, 06 May 2008 02:42:43 GMT

Expires

WEB服务器表明该实体将在什么时候过期，对于过期了的对象，只有在跟WEB服务器验证了其有效性后，才能用来响应客户请求。是 HTTP/1.0 的头部。eg：Expires：Thu，15 Sep 2006 16:23:12 GMT

---------------------
作者：朱冲
来源：CSDN
原文：https://blog.csdn.net/gueter/article/details/1524447
版权声明：本文为博主原创文章，转载请附上博文链接！

2.HTTPS

HTTPS并非是应用层的一种新协议。只是HTTP通信接口部分用 SSL（SecureSocket Layer）和TLS（Transport Layer Security）协议代替而已。通常，HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信了。简言之，所谓HTTPS,其实就是身披SSL协议这层外壳的HTTP。

2.1对称加密和非对称加密

加密和解密同用一个密钥的方式称为共享密钥加密（Common key crypto system），也就是我们所说的对称加密。

我们如何将对称的密钥安全地传递给通信方呢？假设我使用了一种对称加密算法加密了通信报文，同时我希望将解密的密钥给对方，否则对方就无法解密报文。但是从现在来看我们没有办法保证把密钥传递给对方的通信的安全性。我们在互联网上转发密钥时，如果通信被监听那么密钥就会泄露，同时也就失去了加密的意义。

如果解决上面的问题呢？

答案就是使用两把密钥的公开密钥加密。

公开密钥加密使用一对非对称的密钥。一把叫做私有密钥，另一把叫做公开密钥。顾名思义，私有密钥不能让其他人知道，而公开密钥则可以随意发布。具体非对称密钥是如何操作的呢？

A将公开密钥告诉B，B用公开密钥加密传送给A，A再用私有密钥解密。公开密钥和私有密钥是配对的一套密钥。

这种加密和解密使用不同的密钥的方式就是非对称加密，利用这种方式，不需要发送用来解密的私有密钥，也就不必担心密钥被其他坏人窃听。

2.2HTTPS混合加密

HTTPS使用的是两种加密并用的混合加密机制。你可能会有个疑问，为什么不只使用非对称加密呢？

相比于对称加密，非对称加密处理速度要慢很多，对于网络这种实时性要求高的应用，非对称加密的速度还是不够。

我们知道，对称加密方法（共享密钥加密）速度快，而且简单易行，但就是在交换共享密钥的时候无法保证其安全性。那么，我们可以在交换共享密钥的时候使用非对称加密（公开密钥加密）来保证交换过程的安全性，之后建立通信阶段则使用对称加密方式（共享密钥加密），如图所示。

很遗憾，上述机制仍然不完善，因为我们无法证明公开密钥本身的正确性。比如，我们正准备和某主机服务器通信，我们无法证明得到的公开密钥就是原本预想的那台服务器发行的公开密钥。因为有可能在公开密钥的传输过程中，真正的公开密钥已经被坏人篡改替换掉了，或者你访问的根本就是一台别人伪装的服务器。

这就涉及到在互联网上如何识别一个主机的身份的问题了。在现实生活中，如果有个人说自己是A，你会怎么判断他是不是A？很简单，我们可以看他的身份证。在互联网中，也是这个逻辑，数字证书认证机构（CA，Certificate Authority）就相当于发放身份证的机构。

CA处于客户端与服务器双方都信赖的第三方机构的立场。具体如何运作的呢？

首先，服务器的运营人员向数字证书认证机构提出认证申请。CA在判明了申请者的身份后，会给申请者的公开密钥（与申请者通信要使用的加密密钥）做数字签名，然后将数字签名以及公开密钥做成公钥证书发给申请者。服务器得到公钥证书后，当有客户想要和服务器通信的时候，服务器将公钥证书发给客户。得到公钥证书的客户可以向CA确认证书上数字签名的正确性，从而可以确认服务器的真实身份。