深入理解HTTP协议

相关文章:https://blog.csdn.net/u010710458/article/details/79636625

http1.1管线话 vs htttp2.0 多路复用 https://www.cnblogs.com/shangyueyue/p/11041998.html

服务器申请证书和客户端验证证书 https://mp.weixin.qq.com/s/WWd7Ooe1FNxB2DbKW9Kj9w

抓包的方式理解https的交互过程:https://www.jianshu.com/p/cf8c2f2cd18a

https://blog.csdn.net/kunyus/article/details/98754475

https://www.cnblogs.com/xiaxveliang/p/13183175.html

ECDHE_RSA验证 https://blog.csdn.net/s493197604/article/details/104698063

简介

HTTP协议(超文本传输协议HyperText Transfer Protocol),它是基于TCP协议的应用层传输协议,简单来说就是客户端和服务端进行数据传输的一种规则。

注意:客户端与服务器的角色不是固定的,一端充当客户端,也可能在某次请求中充当服务器。这取决与请求的发起端。HTTP协议属于应用层,建立在传输层协议TCP之上。客户端通过与服务器建立TCP连接,之后发送HTTP请求与接收HTTP响应都是通过访问Socket接口来调用TCP协议实现。

HTTP 是一种无状态 (stateless) 协议, HTTP协议本身不会对发送过的请求和相应的通信状态进行持久化处理。这样做的目的是为了保持HTTP协议的简单性,从而能够快速处理大量的事务, 提高效率。

然而,在许多应用场景中,我们需要保持用户登录的状态或记录用户购物车中的商品。由于HTTP是无状态协议,所以必须引入一些技术来记录管理状态,例如Cookie

主要特点

http1.0的主要特点:
简单快速:当客户端向服务器端发送请求时,只是简单的填写请求路径和请求方法即可,然后就可以通过浏览器或其他方式将该请求发送就行了 。
灵活: HTTP 协议允许客户端和服务器端传输任意类型任意格式的数据对象
无连接:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接,采用这种方式可以节省传输时间。(当今多数服务器支持Keep-Alive功能,使用服务器支持长连接,解决无连接的问题)
无状态:无状态是指协议对于事务处理没有记忆能力,服务器不知道客户端是什么状态。即客户端发送HTTP请求后,服务器根据请求,会给我们发送数据,发送完后,不会记录信息。(使用 cookie 机制可以保持 session,解决无状态的问题)

http1.1的特点
a、默认持久连接节省通信量,只要客户端服务端任意一端没有明确提出断开TCP连接,就一直保持连接,可以发送多次HTTP请求 。
b、管线化,客户端可以同时发出多个HTTP请求,而不用一个个等待响应 。
c、断点续传,就是可以将一个大数据,分段传输,客户端可以慢慢显示。

http2.0的特点
a、HTTP/2采用二进制格式而非文本格式
b、HTTP/2是完全多路复用的,而非有序并阻塞的——只需一个HTTP连接就可以实现多个请求响应
c、使用报头压缩,HTTP/2降低了开销
d、HTTP/2让服务器可以将响应主动“推送”到客户端缓存中

正文

HTTP URL

HTTP URL 包含了用于查找某个资源的详细信息, 格式如下:

http://host[":"port][abs_path]

HTTP请求

下图是在网上找的一张图,觉得能很好的表达HTTP请求的所发送的数据格式。

 

由上图可以看到,http请求由请求行,消息报头,请求正文三部分构成。

HTTP请求状态行

请求行由请求MethodURL 字段和HTTP Version三部分构成, 总的来说请求行就是定义了本次请求的请求方式, 请求的地址, 以及所遵循的HTTP协议版本例如:

GET /example.html HTTP/1.1 (CRLF)

HTTP协议的方法有: 

GET: 请求获取Request-URI所标识的资源 

POST: 在Request-URI所标识的资源后增加新的数据 

HEAD: 请求获取由Request-URI所标识的资源的响应消息报头 

PUT: 请求服务器存储或修改一个资源,并用Request-URI作为其标识 

DELETE: 请求服务器删除Request-URI所标识的资源 

TRACE: 请求服务器回送收到的请求信息,主要用于测试或诊断 

CONNECT: 保留将来使用 

OPTIONS: 请求查询服务器的性能,或者查询与资源相关的选项和需求

HTTP请求头

消息报头由一系列的键值对组成,允许客户端向服务器端发送一些附加信息或者客户端自身的信息,主要包括:

HTTP请求正文

只有在发送POST请求时才会有请求正文,GET方法并没有请求正文。

HTTP请求报文

HTTP响应

与HTTP请求类似,先上一张图:

HTTP响应也由三部分组成,包括状态行,消息报头,响应正文。

HTTP响应状态行

状态行也由三部分组成,包括HTTP协议的版本,状态码,以及对状态码的文本描述。例如:

HTTP/1.1 200 OK (CRLF)

HTTP响应状态码

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

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 - 服务器当前不能处理客户端的请求,一段时间后,可能恢复正常

HTTP响应状态码说明

HTTP响应报文

HTTP协议详解

HTTP的五大特点

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

非持久连接和持久连接

在实际的应用中,客户端往往会发出一系列请求,接着服务器端对每个请求进行响应。对于这些请求|响应,如果每次都经过一个单独的TCP连接发送,称为非持久连接。反之,如果每次都经过相同的TCP连接进行发送,称为持久连接。

非持久连接在每次请求|响应之后都要断开连接,下次再建立新的TCP连接,这样就造成了大量的通信开销。例如前面提到的往返时间(RTT) 就是在建立TCP连接的过程中的代价。

非持久连接给服务器带来了沉重的负担,每台服务器可能同时面对数以百计甚至更多的请求。持久连接就是为了解决这些问题,其特点是一直保持TCP连接状态,直到遇到明确的中断要求之后再中断连接。持久连接减少了通信开销,节省了通信量。

HTTP和HTTPS

HTTP的不足

  • 通信使用明文(不加密),内容可能会被窃听
  • 不验证通信方的身份,因此有可能遭遇伪装
  • 无法证明报文的完整性,所以有可能已遭篡改

HTTPS介绍

HTTP 协议中没有加密机制,但可以通 过和 SSL(Secure Socket Layer, 安全套接层 )或 TLS(Transport Layer Security, 安全层传输协议)的组合使用,加密 HTTP 的通信内容。属于通信加密,即在整个通信线路中加密。

HTTP + 加密 + 认证 + 完整性保护 = HTTPS(HTTP Secure )

HTTPS 采用共享密钥加密(对称)和公开密钥加密(非对称)两者并用的混合加密机制。若密钥能够实现安全交换,那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密与共享密钥加密相比,其处理速度要慢。

所以应充分利用两者各自的优势, 将多种方法组合起来用于通信。 在交换密钥阶段使用公开密钥加密方式,之后的建立通信交换报文阶段 则使用共享密钥加密方式。

 

CA证书流程

1.数字证书的申请

在现实中,有一些专门的权威机构用来颁发数字证书,我们称这些机构为认证中心(CA Certificate Authority)。

我们(服务器)可以向这些CA来申请数字证书。

申请的过程大致是:

自己本地先生成一对密匙,然后拿着自己的公匙以及其他信息(比如说企业名称啊什么的)去CA申请数字证书。

CA在拿到这些信息后,会选择一种单向Hash算法(比如说常见的MD5)对这些信息进行加密,加密之后的东西我们称之为摘要。

单向Hash算法有一种特点就是单向不可逆的,只要原始内容有一点变化,加密后的数据都将会是千差万别(当然也有很小的可能性会重复,有兴趣的小伙伴鸽巢原理了解一下),这样就防止了信息被篡改。

生成摘要后还不算完,CA还会用自己的私匙对摘要进行加密,摘要加密后的数据我们称之为数字签名。

最后,CA将会把我们的申请信息(包含服务器的公匙)和数字签名整合在一起,由此而生成数字证书。然后CA将数字证书传递给我们。

2.数字证书怎么起作用

服务器在获取到数字证书后,服务器会将数字证书发送给客户端,客户端就需要用CA的公匙解密数字证书并验证数字证书的合法性。那我们如何能拿到CA的公匙呢?

我们的电脑和浏览器中已经内置了一部分权威机构的根证书,这些根证书中包含了CA的公匙。

一篇文章读懂HTTPS及其背后的加密原理

 

之所以是根证书,是因为现实生活中,认证中心是分层级的,也就是说有顶级认证中心,也有下面的各个子级的认证中心,是一个树状结构,计算机中内置的是最顶级机构的根证书,不过不用担心,根证书的公匙在子级也是适用的。

客户端用CA的公匙解密数字证书,如果解密成功则说明证书来源于合法的认证机构。解密成功后,客户端就拿到了摘要。

此时,客户端会按照和CA一样的Hash算法将申请信息生成一份摘要,并和解密出来的那份做对比,如果相同则说明内容完整,没有被篡改。最后,客户端安全的从证书中拿到服务器的公匙就可以和服务器进行安全的非对称加密通信了。服务器想获得客户端的公匙也可以通过相同方式。

下图用图解的方式说明一般的证书申请及其使用过程。

一篇文章读懂HTTPS及其背后的加密原理

————————————————

在https请求中,我

HTTPS握手过程的简单描述如下:

 

开始加密通信之前,客户端和服务器首先必须建立连接和交换参数,这个过程叫做握手(handshake)。

(1)client_hello

客户端发起请求,以明文传输请求信息,包含版本信息,加密套件候选列表,压缩算法候选列表,随机数,扩展字段等信息,相关信息如下:

  • 支持的最高TSL协议版本version,从低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2,当前基本不再使用低于 TLSv1 的版本;

  • 客户端支持的加密套件 cipher suites 列表, 每个加密套件对应前面 TLS 原理中的四个功能的组合:认证算法 Au (身份验证)、密钥交换算法 KeyExchange(密钥协商)、对称加密算法 Enc (信息加密)和信息摘要 Mac(完整性校验);

  • 支持的压缩算法 compression methods 列表,用于后续的信息压缩传输;

  • 随机数 random_C,用于后续的密钥的生成;

  • 扩展字段 extensions,支持协议与算法的相关参数以及其它辅助信息等,常见的 SNI 就属于扩展字段,后续单独讨论该字段作用。

加密套件

加密套件(CipherList)是指在ssl/tls通信中,服务器和客户端所使用的加密算法的组合。

  • 密钥交换:用于决定客户端与服务器之间在握手的过程中如何认证。使用非对称加密算法来生成会话密钥,因为非对称算法不会将重要数据在通信中传输用到的算法包括RSA,Diffie-Hellman,ECDH,PSK等

  • 加密算法:主要是对传输的数据进行加密传输用的。一般有对称加和非对称加密;所以真正要传输的数据会使用对称加密来进行加密。算法名称后通常会带有两个数字,分别表示密钥的长度和初始向量的长度,比如DES 56/56, RC2 56/128, RC4 128/128, AES 128/128, AES 256/256;

  • 会话校验(MAC)算法,为了防止握手本身被窜改(这里极容易和证书签名算法混淆)。算法包括MD5,SHA等

  • PRF(伪随机数函数),用于生成“master secret”

加密套件格式示例:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

从其名字可知,它是:

  • 基于TLS协议的;
  • 使用ECDHE、RSA作为密钥交换算法;
  • 加密算法是AES(密钥和初始向量的长度都是256);
  • MAC算法(这里就是哈希算法)是SHA。

(2)server_hello+server_certificate+sever_hello_done

(a) server_hello, 服务端返回协商的信息结果,包括选择使用的协议版本 version,选择的加密套件 cipher suite,选择的压缩算法 compression method、随机数 random_S 等,其中随机数用于后续的密钥协商;

(b)server_certificates, 服务器端配置对应的证书链,用于身份验证与密钥交换;

© server_hello_done,通知客户端 server_hello 信息发送结束;

(3)证书校验

客户端验证证书的合法性,如果验证通过才会进行后续通信,否则根据错误情况不同做出提示和操作,合法性验证包括如下:

  • 证书链的可信性 trusted certificate path,方法如前文所述;

  • 证书是否吊销 revocation,有两类方式离线 CRL 与在线 OCSP,不同的客户端行为会不同;

  • 有效期 expiry date,证书是否在有效时间范围;

  • 域名 domain,核查证书域名是否与当前的访问域名匹配,匹配规则后续分析;

(4)client_key_exchange+change_cipher_spec+encrypted_handshake_message

(a) client_key_exchange,合法性验证通过之后,客户端计算产生随机数字 Pre-master,并用证书公钥加密,发送给服务器;

(b) 此时客户端已经获取全部的计算协商密钥需要的信息:两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master,计算得到协商密钥;

enc_key=Fuc(random_C, random_S, Pre-Master)

© change_cipher_spec,客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信;

(d) encrypted_handshake_message,结合之前所有通信参数的 hash 值与其它相关信息生成一段数据,采用协商密钥 session secret 与算法进行加密,然后发送给服务器用于数据与握手验证;

(5)change_cipher_spec+encrypted_handshake_message

(a) 服务器用私钥解密加密的 Pre-master 数据,基于之前交换的两个明文随机数 random_C 和 random_S,计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);

(b) 计算之前所有接收信息的 hash 值,然后解密客户端发送的 encrypted_handshake_message,验证数据和密钥正确性;

© change_cipher_spec, 验证通过之后,服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;

(d) encrypted_handshake_message, 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 session secret 与算法加密并发送到客户端;

(6)握手结束

客户端计算所有接收信息的 hash 值,并采用协商密钥解密 encrypted_handshake_message,验证服务器发送的数据和密钥,验证通过则握手完成;

(7)加密通信

开始使用协商密钥与算法进行加密通信。

注意:

(a) 服务器也可以要求验证客户端,即双向认证,可以在过程2要发送 client_certificate_request 信息,客户端在过程4中先发送 client_certificate与certificate_verify_message 信息,证书的验证方式基本相同,certificate_verify_message 是采用client的私钥加密的一段基于已经协商的通信信息得到数据,服务器可以采用对应的公钥解密并验证;

(b) 根据使用的密钥交换算法的不同,如 ECC 等,协商细节略有不同,总体相似;

© sever key exchange 的作用是 server certificate 没有携带足够的信息时,发送给客户端以计算 pre-master,如基于 DH 的证书,公钥不被证书中包含,需要单独发送;

(d) change cipher spec 实际可用于通知对端改版当前使用的加密通信方式,当前没有深入解析;

(e) alter message 用于指明在握手或通信过程中的状态改变或错误信息,一般告警信息触发条件是连接关闭,收到不合法的信息,信息解密失败,用户取消操作等,收到告警信息之后,通信会被断开或者由接收方决定是否断开连接。

总结:

SSL客户端(也是TCP的客户端)在TCP连接建立之后,发出一个ClientHello来发起握手,这个消息里面包含了自己可实现的算法列表和其它一些需要的消息,SSL的服务器端会回应一个ServerHello,这里面确定了这次通信所需要的算法,然后发过去自己的证书(里面包含了身份和自己的公钥)。Client在收到这个消息后会生成一个秘密消息,用SSL服务器的公钥加密后传过去,SSL服务器端用自己的私钥解密后,会话密钥协商成功,双方可以用同一份会话密钥来通信了。

原文地址:https://www.cnblogs.com/xiangshihua/p/14949654.html