计算机网络之HTTP和HTTPS

应用层其他协议

应用层中我们介绍了DNS和DHCP,在应用层中还有一个非常常用也是几乎会被我们每一个网络用户用到的协议,它就是HTTP

HTTP(HyperText Transfer Protocol)

HTTP Request部分

HTTP有不同的版本,这里详细介绍目前使用最多的版本HTTP1.1。http请求数据格式分为三部分:

  • 请求行:Request Line
  • 头信息:Header
  • 数据:Body

Request Line

请求行的结构为:

Method SP Request-URI SP HTTP-Version CRLF

其中SP为分隔符0x20,CRLF为回车换行符,因此可以上面的格式可以变为

Method Request-URI HTTP-Version

Method

便是请求的方式,有以下的参数

  • GET 从指定的url上获取内容
  • POST 提交body中的内容给服务器中指定的url中
  • HEAD 从指定的url上获取header内容(类似Get方式)
  • PUT 将body上传至服务器指定url处
  • DELETE 在指定url处删除资源
  • OPTIONS 返回服务器针对特定资源所支持的HTTP请求方法
  • CONNECT 连接指定频段,当客户端需要通过代理服务器连接HTTPS服务器是用到
  • TRACE 回显服务器收到的请求

Request-URI

Request-URI = "*" | absoluteURI | abs_path | authority

  • 一把和OPTIONS一起使用:OPTIONS * HTTP/1.1
  • 绝对路径:GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
  • 路径信息:GET /pub/WWW/TheProject.html HTTP/1.1,HOST在Header中
  • 权限:权限只能和CONNECT Method一起使用

HTTP-Version

HTTP版本号,这里为HTTP/1.1

Header为键值对形式,键和值用冒号隔开,如Accept:text/html,多个值用分号隔开如Accept:text/html;text/plain,每一个键值对单独一行。这里介绍常见的几种键值对信息

Accept

请求端可以接收的数据格式,常见的有:

  • text/plain
  • text/html
  • text/css
  • image/jpeg
  • image/png
  • image/svg+xml
  • audio/mp4
  • video/mp4
  • application/javascript
  • application/pdf
  • application/zip
  • application/atom+xml

Accept-Charset

请求端可以接收的编码

  • iso-8859-5

Accept-Encoding

请求端可以接收压缩方式

  • gzip
  • compress
  • deflate

另外的一些大家可以参考Header Field Definitions

Body

body里面包含请求的实际数据,对于Method=GET,body为空。如果Method=POST,那么body内的信息就比较重要了

HTTP Response部分

http回复数据格式也分为三部分:

  • 状态行:Status Line
  • 头信息:Header
  • 数据:Body

Status Line

状态行的结构为:

HTTP-Version Status-Code Reason-Phrase

HTTP-Version

HTTP版本,这里为HTTP/1.1

Status-Code和Reason-Phrase

状态码和原因

Status-Code    =
      "100"  ; Section 10.1.1: Continue
    | "101"  ; Section 10.1.2: Switching Protocols
    | "200"  ; Section 10.2.1: OK
    | "201"  ; Section 10.2.2: Created
    | "202"  ; Section 10.2.3: Accepted
    | "203"  ; Section 10.2.4: Non-Authoritative Information
    | "204"  ; Section 10.2.5: No Content
    | "205"  ; Section 10.2.6: Reset Content
    | "206"  ; Section 10.2.7: Partial Content
    | "300"  ; Section 10.3.1: Multiple Choices
    | "301"  ; Section 10.3.2: Moved Permanently
    | "302"  ; Section 10.3.3: Found
    | "303"  ; Section 10.3.4: See Other
    | "304"  ; Section 10.3.5: Not Modified
    | "305"  ; Section 10.3.6: Use Proxy
    | "307"  ; Section 10.3.8: Temporary Redirect
    | "400"  ; Section 10.4.1: Bad Request
    | "401"  ; Section 10.4.2: Unauthorized
    | "402"  ; Section 10.4.3: Payment Required
    | "403"  ; Section 10.4.4: Forbidden
    | "404"  ; Section 10.4.5: Not Found
    | "405"  ; Section 10.4.6: Method Not Allowed
    | "406"  ; Section 10.4.7: Not Acceptable
    | "407"  ; Section 10.4.8: Proxy Authentication Required
    | "408"  ; Section 10.4.9: Request Time-out
    | "409"  ; Section 10.4.10: Conflict
    | "410"  ; Section 10.4.11: Gone
    | "411"  ; Section 10.4.12: Length Required
    | "412"  ; Section 10.4.13: Precondition Failed
    | "413"  ; Section 10.4.14: Request Entity Too Large
    | "414"  ; Section 10.4.15: Request-URI Too Large
    | "415"  ; Section 10.4.16: Unsupported Media Type
    | "416"  ; Section 10.4.17: Requested range not satisfiable
    | "417"  ; Section 10.4.18: Expectation Failed
    | "500"  ; Section 10.5.1: Internal Server Error
    | "501"  ; Section 10.5.2: Not Implemented
    | "502"  ; Section 10.5.3: Bad Gateway
    | "503"  ; Section 10.5.4: Service Unavailable
    | "504"  ; Section 10.5.5: Gateway Time-out
    | "505"  ; Section 10.5.6: HTTP Version not supported
    | extension-code

Header

头信息的格式和请求的头信息格式一样,常见的回复Header有:

Content-Type

返回数据的编码方式

Content-Encoding

返回数据的压缩方式

Body

服务端返回的数据

HTTP其他版本

以上是HTTP1.1的简单介绍,关于不同版本的HTTP,可以查阅这篇文章:

HTTP 协议入门

特别感谢大神阮一峰

你可以了解到HTTP的发展和各个版本HTTP之间的差别:

HTTP/0.9

命令简单GET /index.html,回复数据也只能是HTML格式,服务器发送完毕,就关闭TCP连接

HTTP/1.0

除了GET,新增POST和HEAD请求方式,数据的格式也更丰富了,有图像、视频、二进制文件,请求和回复的数据和我们的1.1版本相差不大

HTTP/1.1

新增内容

  • 持久连接
  • 管道机制
  • Content-Length字段
  • 分块传输编码
  • 新增PUT、PATCH、HEAD、 OPTIONS、DELETE
  • 头信息中增加Host键

1.1的虽然可以在同一次连接的TCP发送多次请求,但是服务器还是要一个一个的处理以后再回复客户端,因此会引起队头堵塞

HTTP/2

没有.0是因为不会再发2.几的版本了。新增内容和功能:

  • 二进制协议
  • 多工:避免队头堵塞
  • 数据流
  • 头信息压缩
  • 服务器推送

URI和URL

URI为统一资源标志符,URL为统一资源定位符,在范围上URL属于URI,因为URI还包括了URN:统一资源名称,URL用位置定位,URN用名称定位,更形象一点的解释就是URI为玫瑰花,URL是在你办公桌上的那一朵玫瑰花,URN是一朵出厂编号为520的玫瑰花

数据加密

在了解HTTPS之前,我们需要先了解一下加密的方式。数据加密是指将一个信息(或称明文)经过密钥及加密函数转换,变成无意义的密文,而接收方则将此密文经过解密函数、密钥还原成明文的过程

对称加密

对称加密的特点就是加密方和解密方用同样的密钥、同样的方法去加密和解密一个数据,因此加密和解密算法都是公开的,重点保证密钥安全性,一旦密钥泄露,那么可能就会造成信息泄露。对称加密常用的两种方式为分组密码和和序列密码

分组密码

将明文分割成固定长度的数据段,然后单独对每一段数据进行加密运算,产生和数据段长度相同的密文,密文序列和明文分组产生的数据段序列一一对应。分组密码的两种常用方式为:

序列密码

序列密码(也称流密码)体制就是一次一密钥的加密运算过程,这种方式的限制很多:

  1. 密钥集总是有限的
  2. 密钥集中的密钥是用算法产生的,密钥之间无法做到没有任何相关性
  3. 发送端和接收端每次数据传输过程都必须同步密钥

不对称加密

不对称加密的加密和解密使用不同的密钥,加密的密钥是公开的,因此不需要每次或者提前获取密钥,加密算法的原则有:

  • 容易成对生成密钥PK和SK,且PK和SK一一对应
  • 加密和解密算法是公开的,而且可以对调:DSK(EPK(P))= EPK(DSK(P))=P
  • 加密和解密过程容易实现
  • 从计算可行性讲,无法根据PK推导出SK
  • 从计算可行性讲,如果Y=EPK(P),无法根据PK和密文Y推导出明文P

RSA(Rivest-Shamir-Adelman)是目前最常用的公开密钥加密算法

  1. 对称密钥加密算法的计算复杂度远小于不对称密钥加密算法的计算复杂度
  2. 通常用对称密钥加密算法加密数据,不对称密钥加密算法加密对称密钥加密算法所使用的密钥

报文摘要和数字签名

数据除了它的私密性,我们还需要保证它的完整性和行为的不可抵赖性

报文摘要

报文摘要(MD)技术是一种检查发送的报文是否被篡改的方法,给定某个任意报文,通过一种特定的算法对报文进行计算,产生有限位数信息,即报文摘要,报文摘要就像报文的指纹一样,报文摘要具有确认性和唯一性。3种常用的报文摘要算法:


HMAC报文摘要同时有加密的功能。报文摘要的两种用途就是:消息完整性检测

和验证秘密信息:

数字签名

数字签名就是只有信息发送者才能产生的、别人无法伪造的一段数字串,这段数字串同时也是对信息发送者发送信息真实性的一个有效证明,它具有如下特征:

  • 接收者能够核实发送者对报文的数字签名
  • 发送者事后无法否认对报文的数字签名
  • 接收者无法伪造发送者对报文的数字签名

因此数字签名必须保证

  1. 唯一性:只有特定发送者能生成数字签名
  2. 关联性:对特定报文的数字签名
  3. 可证明性:该数字签名的唯一性和与特定报文的关联性可以得到证明

基于RSA数字签名原理

我们可以用私钥还原某个报文的报文摘要形成数字签名,如果要验证这个数字签名,只需要将它用公钥加密,如果加密后和原始报文摘要相同,则可以证明该数字签名是正确的,一个报文被私密还原以后可以作为数字签名的依据是:

数字签名的过程:

HTTPS

HTTP是采用明文的方式进行数据的通信,这就有一些问题,第一数据时完全公开的,第二,即便是我们的数据在传输过程当中被篡改,我们接收的一方也是对此一无所知的。那大家觉得可以用加密的方式啊,对称加密不能防止信息被篡改,而非对称加密不能防止信息泄露,所以我们必须使用数字签名,如果我们直接使用上面的数字签名过程,还是有漏洞,我们直接将明文和数字签名改成自己的,用户还是不知道信息被篡改了,那有什么方法呢,方法就是对公钥进行数字签名,而对它签名的机构是权威机构,是被权威认证的,那么我们就可以对传过来PK进行验证,如果不能通过,则发送方可能存在风险,例如下面的例子:

用权威机构的PK可以验证用户的证书,也就是用户的PK,然后通过用户的PK可以验证用户对合同的数字签名,如果数字签名不对则说明这个合同不是通过用户SK签名的。我们的HTTPS就是采用这种方式,所以我们要使用HTTPS时,必须向权威机构申请证书和私钥,这个权威结构是被网络应用软件认可的权威结构,它首先判断证书是否权威,如果不权威,就会提示你使用的HTTPS是不被认证的,如果是权威的证书,它用里面的PK将数字签名加密得到报文摘要,然后将网页信息在进行报文摘要计算,如果两个摘要相同,则说明信息是被信任的一方发过来的,而且信息是未被篡改的

SSL协议

在HTTPS中,不得不提到SSL,它是一种协议,运行在TCP/IP层之上、应用层之下,HTTPS实际上就是SSL over HTTP,在发送方,数据经过数字签名,然后发送给请求方,同时还有一个证书,接收方使用SSL来检验证书和内容,整个过程就如上面的内容,因此,这个过程较之HTTP协议会增加很多额外的过程,所以性能方面也比HTTP差一些,不过相应的安全性增加了

坚持原创分享,您的支持将鼓励我不断前行!