温故而知新—HTTP

Posted 2021-04-26 小脑门

HTTP

---

了解web及网络基础

1、HTTP发展史

HTTP（HyperText Transfer Protocol）：超文本传输协议，是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。是互联网上应用最为广泛的一种网络协议。所有的 WWW 文件都必须遵守这个标准。1989年3月，互联网还只属于少数人。在这一互联网的黎明期，Http诞生。HTTP于1990年问世(同龄人啊)，那是的http并没有作为正式的标准被建立，因此被称为HTTP/0.9。

HTTP作为标准正式被公布是在1996年的5月，版本被命名为HTTP/1.0，并记载于RFC1945。1997年1月份公的HTTP/1.1是目前主流的HTTP协议版本。最终的修订版本RFC2616就是当前的最新版本。HTTP/2标准于2015年5月以RFC7540正式发表。

2、TCP/IP协议族

互联网协议套件（英语：Internet Protocol Suite，缩写IPS）[1]是一个网络通信模型，以及一整个网络传输协议家族，为网际网络的基础通信架构。它常被通称为TCP/IP协议族（英语：TCP/IP Protocol Suite，或TCP/IP Protocols），简称TCP/IP**[2]。

简单理解概念就是计算机与网络设备要相互通信，双方就必须基于相同的方法。比如，如何探测到通信目标、由哪一边发起通信、使用哪种语言进行通信、怎样结束通信等规则都需要事先确认。不同的硬件、操作系统之间的通信，所有的这一切都需要一种规则，我们把这种规则称之为协议(protocol)。

2.1、分层管理

TCP/IP协议族按层次分别分为应用层、传输层、网络层和数据链路层4层。把TCP/IP层次化是有好处的，方便针对某一层进行迭代更改，把各层之间的接口部分规划好之后，每个层次内部的设计也就能够自由改动了。

• 应用层：应用层决定了向用户提供应用服务室通信的活动。http协议也处于该层。

• 传输层：传输层对上层应用层提供处于网络连接中的两台计算机之间的数据传输。主要包括TCP和UDP两种协议。

• 网络层：又叫网络互联层，主要用来处理在网络上流动的数据包。

• 链路层：又叫数据链路层，用来处理连接网络的硬件部分。

利用TCP/IP协议族进行网络通信时，会通过分层顺序与对方进行通讯。发送端从应用层往下走，接收端则往上向应用层走。

发送端在层与层之间传输数据时，每经过一层时必定会被打上一个该层所属的首部信息。反之，接收端在层与层之间传输数据时，每经过一层时会把对应的首部信息去掉。这种把数据信息包装起来的做法称为封装（encapsulate）。

着重理解些TCP协议，按照层次分TCP位于传输层，提供可靠的字节流服务。所谓的字节流服务(Byte Stream Service)是指，为了方便传输，将大块数据分割成以报文段(segment)为单位的数据包进行管理。而可靠的传输服务是指，能够确保把数据准确可靠的传递给对方。为了准确无误地将数据送达目标处，TCP协议采用了三次握手(three-way handshaking)策略。

完整的HTTP通讯过程

2.2、请求方法

常用请求方法如下列表：

方法	说明	支持的HTTP协议版本
GET	获取资源	1.0、1.1
POST	提交谁提主题	1.0、1.1
PUT	传输文件	1.0、1.1
HEAD	获取报文首部	1.0、1.1
DELETE	删除文件	1.0、1.1
OPTIONS	访问支持的方法	1.1
TRACE	追踪路径	1.1
CONNECT	要求用隧道协议连接代理	1.1
LINK	建立和资源之间的联系	1.0
UNLINK	断开连接关系	1.0

• GET：get方法用来请求访问已被URI识别的资源。指定的资源经服务端解析后返回响应内容。

• POST：post方法用来传输实体的主题，也就是常用于表单提交场景。get方法也可以用于传输主题，但是post主要的目的不是为了获取返回结果，重点在于提交实体。

restful是一种软件架构风格、设计风格，而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。RESTful的关键是定义可表示流程元素/资源的对象。在REST中，每一个对象都是通过URL来表示的，对象用户负责将状态信息打包进每一条消息内，以便对象的处理总是无状态的。

restful具有以下几个特点：

1. 每一个URI代表1种资源，也就是一个个可以认知的资源，比如文档，音乐，视频等信息，都可以通过唯一的URI确定。

2. 客户端使用GET、POST、PUT、DELETE4个表示操作方式的动词对服务端资源进行操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。

3. 通过操作资源的表现形式来操作资源。

4. 资源的表现形式是XML或者html。

5. 客户端与服务端之间的交互在请求之间是无状态的，从客户端到服务端的每个请求都必须包含理解请求所必需的信息。

2.3、连接方式

HTTP协议的初始版本中，每进行一次通信就要断开一次TCP连接。这种情况也就是我们通常所说的短连接。

未解决通信过程中频繁创建连接的性能消耗问题，从HTTP1.1和部分的HTTP1.0想出了持久连接(keep-alive)的方法。持久连接的特点就是，只要任意一端没有明确的提出断开连接，则一直保持TCP的连接装填。也就是我们通常所说的长连接。HTTP1.1默认都是长连接。

长连接使得多数请求以管线化(pipelining)成为可能。从前发送请求后需等待并受到响应，才能发送下一次请求，管线化技术出现后，不用等待响应亦可发送下一个请求，真正意义上实现了并发请求。

3、报文信息

用于HTTP协议交互的信息被称为HTTP报文。通常客户端的http报文被叫做请求报文，服务端的被叫做响应报文或应答报文。HTTP报文本身由多行(用CR+LF作为换行符)数据构成的字符串文本。HTTP报文大致可分为报文首部和报文主题两块，通常，并不一定要有报文主题。

• 请求报文

• 响应报文

完成的请求报文和响应报文案例：

4、状态码

HTTP状态码负责表示客户端HTTP请求的返回结果、标记服务端的处理是否正常、通知出现的错误等工作。借助状态码，用户可以知道服务端是正常处理了请求，还是出现了错误。

状态码是以3位数字和原因短语组成。数字中的第一位指定了响应类别，后两位无分类。响应类别有以下5种：

	类别	原因短语
1XX	informational（信息性状态码）	接收的请求正在处理
2XX	Success（成功状态码）	请求正常处理完毕
3XX	Redirection（重定向状态码）	需要进行附加操作以完成请求
4XX	Client Error（客户端错误状态码）	服务器无法处理请求
5XX	Server Error（服务端错误状态码）	服务器处理请求出错

仅记录在RFC2616上的HTTP状态码就有41种其他扩展的数量共计60多种，常用的状态码有以下14种：

• 200 OK：表示服务端正常受理了客户端发送的请求。

• 204 No Content：该状态码表示服务器接收的请求已经受理成功，但在返回的响应报文中不含实体的报文主体部分。适用于客户端向服务端发送请求信息，而对客户端不需要发送新信息内容的情况下使用。

• 206 Partial Content：该状态码表示客户端暖进行了范围请求，而服务端成功执行了这部分的get请求。响应报文中包含由Content-Range指定范围的实体内容。

• 301 Moved Permanently：永久性重定向。该状态码表示请求的资源已被分配新的URI，以后应使用资源现在所指的URI。

• 302 Found：临时性重定向，希望客户端使用新URI访问资源。与301相比资源不是永久移动，只是临时性质的。

• 303 See Other：该状态码表示由于请求对应的资源存在另一个URI，应使用GET方法定向获取请求资源。

• 304 Not Modified：该状态码表示客户端发送附带条件的请求时，服务端允许请求访问资源，但因发生请求未满足条件的情况后，直接返回304.

• 307 Temporary Redirect：临时重定向。该状态与302 found有着相同的含义，尽管302标准禁止post变换成get，但实际使用时大家并不遵循。307会遵照浏览器的标准，不会从post变成get。

• 400 Bad Request：请求报文中存在语法错误。

• 401 Unauthorized：该状态码表示发送的请求需要有通过HTTP认证的认证信息。

• 403 Forbidden：服务器拒绝客户端访问资源。服务端没有必要给出拒绝原因，但如果想要做出解释说明的话，可在报文主体部分进行描述。

• 500 Internal Server Error：该状态码标识服务器在执行请求时发生了错误。也有可能是web服务存在的bug或某些临时的故障。

• 503 Service Unavailable：该状态表示服务器目前处于超负载或正在停机维护，现在无法处理请求。

5、HTTPS

在HTTP协议中有可能存在信息窃听或身份伪装等安全问题。HTTP主要有以下几点不足之处：

1. 通信使用明文（内容不加密），内容可能被窃听

2. 不验证通信方的身份，因此有可能遭遇伪装

3. 无法证明报文的完成性，因此存在被篡改的风险

HTTP协议中没有加密机制，但可以通过和SSL（Secure Socket Layer,安全套接层）或TLS（Transport Layer Security，安全层传输协议）组合使用，加密HTTP的通信内容。用SSL建立安全通信线路之后，就可以在这条线路上进行http通信了。与SSL组合使用的HTTP被称为HTTPS（HTTP Secure）。

HTTPS = HTTP + 加密 + 认证 + 完整性保护。解决通信过程中的安全问题，无非从三个层面入手，第一要解决信道的安全性；第二是要确保报文传输过程中支持密文传输，避免敏感字段泄露；第三要能够验证通信双方的身份。在采用SSL之后，HTTP就有了HTTPS的加密、证书和完整性保护这些功能。HTTPS并非是一种新的协议，它只不过是披着SSL外壳的HTTP协议。

通常HTTP直接和TCP通信,当使用SSL后则演变成先和SSL通信再由SSL和TCP通信.

证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。另外，伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认通信方（服务器或客户端）持有的证书，即可判断通信方的真实意图。SSL是独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL协议使用。可以说 SSL是当今世界上应用最为广泛的网络安全技术。

交互秘钥的公开加密算法

SSL采用一种叫做公开秘钥加密（Public-key cryptography）的加密处理机制。也就是我们常说的公钥加密。加密和解密都会用到密钥。没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了。如果密钥被攻击者获得，那加密也就失去了意义。

• 共享秘钥加密

  加密和解密公用一个秘钥的方式被称为共享秘钥加密（Common key crypto system），也被叫做对称秘钥加密。

   

• 使用两把秘钥的公开秘钥加密

公开密钥加密使用一对非对称的密钥。一把叫做私有密钥 （private key），另一把叫做公开密钥（public key）。顾名思 义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。两把秘钥的主要用途：

• 公钥：用来加密信息和验签。

• 私钥：用来解密信息和加签

那些加密消息或验证签名的秘钥不能解密消息或创建签名。另外，要想根据密文和公开密钥，恢复到信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能办到。退一步讲，如果能对一个非常大的整数做到快速地因式分解，那么密码破解还是存在希望的。但就目前的技术来看是不太现实的。

使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密与共享密钥加密相比，其处理速度要慢。所以应充分利用两者各自的优势，将多种方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

6、安全算法

加密具体的操作：计算机会用由0和1两个数字表示的二进制来管理所有数据，无论是文本、音频、图像等不同形式，在计算中都是二进制表示的。对计算机来说数据就是一串有意义的数字罗列。密文也是数字罗列，只不过它是计算机无法理解的无规律的数字罗列。也就是说，密文就是数据经过某种运算后，变成计算机无法理解的数字的过程。在加密运算中会用到秘钥，所以加密就是用秘钥对数据进行述职运算，把数据变成第三者无法理解的数据过程。反之，则是解密过程。

要找到公开秘钥加密的算法并不容易，考录到加密所需的计算流程，算法必须满足如下几个条件：

1. 可以使用某个数值对数据进行加密计算

2. 使用另一个数值对加密数据进行计算，可以让数据恢复到原样

3. 无法从一种秘钥推算出另一种秘钥

稍微思考下就可以知道，想要找到满足以上条件的算法难度有多大。所以，RSA等可以实现公开秘钥加密的算法的提出，对当今互联网社会的安全有着重要的意义。

对称加密存在秘钥传递问题，非对称加密存在公钥被替换，身份无法验证问题，通过非对称加密性能要差，加解密比较耗时。结合这两种方法以实现互补的一种加密方法就是混合加密。

混合加密：在混合加密中，要用处理速度较快的对称秘钥（共享秘钥）对数据进行加密。不过加密时使用的秘钥，则需要用没有秘钥分配问题的非对称秘钥（公开秘钥）进行加密处理。

6.1、消息认证码

消息认证码可以实现“认证”和“监测篡改”两个功能。密文的内容在传输的工程中可能被篡改，这会导致解密后的内容发生变化，从而产生误会。消息认证码就是可以预防这种情况发生的机制。

消息认证码的实现过程的前置条件是通信双方都要有一个共用的秘钥，用于制作消息认证码。发送方使用密文和秘钥生成一个值，这个值就是消息认证码，简称Mac(Message Authentication Code)。发送方将密文和Mac发送给接收方，接收方和发送方一样也用密文和秘钥生成一个消息认证码，然后比对两个Mac是否一致，如果一致即可认为密文没有被篡改。这里可以把Mac看成是一个hash值，由于它不可逆，所以我们认为它是可信的。

然而，这种方法也有缺点。在使用消息认证过程中，发送和接收双方都可以对消息进行加密并且算出Mac。也就是说，我们无法证明原本的消息是哪方生成的。通信双方存在安全隐患，针对这种情况可以使用数字签名来解决。

6.2、数字签名

数字签名不仅可以实现消息认证码的认证和检测篡改功能，还可以预防事后否认问题的发生。数字签名只有发信人才能生产，因此使用它就可以确认谁是消息的发送者。

 

与公钥加密相反，发送方需要使用自己的私钥对发送数据进行加密，加密后生产的密文就是数字签名，发送方将明文消息和数字签名发送给接收方。接收方使用发送方的公钥对数字签名进行解密，解密成功后的明文和发送过来的明文消息比对，如果一致则认为验签成功。

能工使用发送方的公钥解密的密文，必定是有发送方生成的。因此我们可以用这个结论来确认消息的发送者身份，判断消息是否被篡改。由于接收方只有公钥没有发送方的私钥，也就代表接收方无法生成发送方的数字签名，所以也预防了事后否认的情况。

公钥加密和解密都比较耗时，为了节约运算时间，实际上不会对消息主体直接进行加密，而是先求得消息的哈希值，再对哈希值进行加密，然后再将其作为数字签名来使用。

虽然数字签名可以实现”认证“、”检测篡改“、”预防事后否认“三个功能，但它也有一个缺陷。那就是，虽然使用数字签名后，接收方会相信发送方的身份，但实际上发送方有可能是被冒名顶替的。其根本原因在于，接收方验签时所使用的公钥，无法确认就是发送方的公钥，收到的公钥上面没有任何制作者的信息。使用数字证书则可以解决这一问题

6.3、数字证书

数字证书多为权威的认证中心(Certification Authority, CA)颁布。假设有一家机构A需要向认证中心申请证书，首先A要把公开秘钥和包含邮箱信息的个人资料发送给认证中心，认证中心对收到的资料进行确认，判断其是否为A本人的资料。确认完毕后，认证中心使用自己的私有秘钥，根据A的资料生成数字签名，认证中心将生成的数字签名和资料放进同一个文件中，这个文件就是A的数字证书。

7、金融信息安全传输实例