HTTP通讯

HTTP通讯过程包括从客户端发往服务器端的请求以及从服务器端返回客户端的响应.

1. HTTP报文结构

用于HTTP协议交互的信息成为HTTP报文. 请求端发送的HTTP报文成为请求报文，响应端的叫作响应报文. HTTP报文分为报文首部+空行+报文主体,一般并不必定有报文主体.

请求报文首部的结构以下:

1. 请求行:包含用于请求的方法,请求URI和HTTP版本。
2. 请求首部字段:客户端发往服务端请求报文中使用的字段，用来补充请求的附加信息、客户端信息、对响应呢日用相关的优先级能内容。
3. 通用首部字段:请求报文和响应报文都会用到的首部。
4. 实体首部字段:包含在请求报文和响应报文中的实体部分所使用的首部，用来补充内容的更新时间和实体相关的信息。
5. 其余:自行扩展的。

响应报文首部的结构以下:

1. 状态行:包含代表响应结果的状态码,缘由短语和HTTP版本。
2. 响应首部字段:由服务器端向客户端返回响应报文中所使用的字段，用来补充响应附信息、服务器信息，以及对客户端的附加要求等信息。
3. 通用首部字段:请求报文和响应报文都会用到的首部。
4. 实体首部字段:包含在请求报文和响应报文中的实体部分所使用的首部，用来补充内容的更新时间和实体相关的信息。
5. 其余:自行扩展的。

2. HTTP编码

HTTP在传输数据时能够按照数据的原貌传输, 也能够在传输过程当中编码提高传输速率. 经过在传输时编码, 能有效地处理大量的访问请求. 可是编码是计算机来完成的, 所以会须要消耗更多的CPU等资源.

报文(message):是HTTP通讯的基本单位，由8位组字节流组成，经过HTTP通讯传输. 实体(entity):做为请求和响应的有效载荷数据(补充项)被传输，其内容由实体首部和实体主体组成. HTTP报文的主体用于传输请求和响应的实体主体. 一般，报文主体等因而实体主体，只有当传输中进行编码操做时，实体主体的内容发生变化，才致使它和报文主体产生差别. 我的理解为实体主体是编码之后的报文主体.

2.1 压缩传输的内容编码

HTTP协议中有一种被称为内容编码的功能能够实现压缩内容的效果,内容编码是在实体内容上的编码格式,并保持实体信息原样压缩,内容编码后的实体由客户端接收并负责解码.

内容编码的常见几种方式:

• gzip (GUN zip)
• compress (UNIX系统的压缩标准)
• deflate (zlib)
• identity (不进行编码)

2.2 分割发送的分块传输编码

分块传输编码是将实体主体分割成多个部分(块), 每一块都会用十六进制来标记块的大小,而实体主体的最后一块会用"0"来标记.客户端负责解码,恢复到编码前的实体主体.

3. 发送多种数据格式的多部分对象集合

MIME(Multipurpose Internet Mail Extensions, 多用途因特网邮件扩展)机制, 容许邮件处理文本, 图片, 视频等各个不一样类型的数据. 能够发送文本,图片,视屏等不一样类型的数据. HTTP协议中也采纳了多部分对象集合,发送的一份报文主体内能够包含多类型实体,一般在图片或文本上传时使用.

多部分对象集合	做用
multipart/form-data	表单文件上传时使用
multipart/byteranges	状态码206(Partial Content, 部份内容)响应报文包含了多个范围的内容时使用

在HTTP报文中使用多部分对象集合时, 须要在首部字段中加上Content-type字段, Content-type字段说明了实体主体内对象的媒体类型. 使用boundary字段来划分多部分对象集合指明的各种实体, 在boundary字符串指定的各个实体的起始行以前插入"--"标记作为开始, 在多部分对象集合对应的字符串的最后插入"--"标记作为结束. 如上以"--AbB03x"作为开始, 以"--AbB03x--"作为结束.

4. HTTP状态码

状态码的职责是当客户端想服务器端发送请求时, 描述返回的请求结果. 借助状态码, 用户能够知道服务器端是正常的处理了请求仍是出现了错误.

4.1 2xx成功

200:OK, 请求成功 204:No Content, 服务端接收的请求已经成功处理,可是返回的响应报文中不包含实体的主体部分, 另外也不容许返回任何实体的主体. 206:Partial Content, 客户端进行了范围请求,而服务器成功执行了这部分的GET请求.

4.2 3xx重定向

3xx的响应代表客户端须要执行某些特殊的处理才能正确请求.

301:Moved Permanently, 永久性重定向, 表示请求的资源已经被分配到了新的URI, 之后请求都是用如今所指的URI. 302:Found, 临时性重定向, 表示请求的资源已被分配到新的URI, 但愿用户(本次)能使用新的URI访问.和301状态相似，可是302状态码表明的资源不是被永久移动，只是临时性质的。 303:See Other，该状态码表示因为请求对应的资源存在着另外一个URI，应使用GET方法定向获取请求的资源。303状态码和302状态码有着相同的功能，可是303状态码代表客户端应采用GET方法获取资源，这点与302状态码有区别。 304:Not Modified，改状态表示客户端发送附带条件的请求时，服务端容许请求访问资源，但未知足条件的状况。304状态码返回时不包含响应的主体部分。304虽然被划分在3XX，可是与重定向无关。 307:Temporary Redirect，临时重定向，与302有相同的含义，可是307不会将POST改成GET。

4.3 4xx客户端错误

4xx的响应结果代表客户端是发送错误的缘由所在.

400:Bad Request, 请求报文中存在语法错误. 401:Unauthorized, 请求须要有经过HTTP认证(BASIC认证,DIGEST认证)的信息. 403:Forbidden, 代表对请求资源的访问被服务器拒绝了. 404:Not Found, 代表服务器上没法找到请求的资源.

4.4 5xx服务器错误

5xx的响应结果代表服务器自己发送错误.

501:Internal Server Error, 代表服务器端在执行请求时发生了错误. 503:Service Unavailable, 代表服务器暂时处在超负荷或者正在进行停机维护,如今没法请求.若是事先得知解除以上情况须要的时间, 最好写入Retry-After首部字段返回给客户端.

5. HTTP首部

HTTP协议的请求和响应报文中一定包含HTTP首部, 咱们来看一下HTTP首部的结构以及各字段的用法.

5.1 HTTP首部结构

请求报文首部:请求行+请求首部字段+通用首部字段+实体首部字段+其余. 请求行包括方法(GET POST), URI, HTTP版本.

响应报文首部:状态行+响应首部字段+通用首部字段+实体首部字段+其余. 状态行包括HTTP版本, 状态码.

5.2 HTTP首部字段

HTTP首部字段是构成HTTP报文的要素之一, 在客户端和服务端之间以HTTP协议通讯的过程当中, 首部字段起到传递额外重要信息的做用. 首部字段能够提供报文主体大小, 所使用的语言, 认证信息等内容. HTTP首部字段的结构为首部字段名: 字段值, 指令的参数是可选的, 多个指令之间用","分隔, 例如首部字段'Cache-Control'的指令用于请求以及响应时:

Cache-Control: private, max-age=0, no-cache
复制代码

HTTP首部字段分为: 通用首部字段, 请求首部字段, 响应首部字段, 实体首部字段.

5.2.1 通用首部字段表

通用首部字段是请求报文和响应报文都会用到的首部.

5.2.2 请求首部字段

从客户端发送请求到服务端使用的首部.补充了请求的附加内容,客户端信息,响应内容优先级等信息.

5.2.3 响应首部字段

从服务端向客户端返回响应报文时使用的首部.补充了相应的附加内容.

5.2.4 实体首部字段

针对请求报文和响应报文的实体部分使用的首部.

6. 确保安全的HTTPS

HTTP协议中可能存在信息窃听或身份假装等安全问题, 使用HTTPS通讯机制能够有效地防止这些问题.

6.1 HTTP存在的问题

HTTP协议存在一下不足之处:

1. 通讯使用明文, 内容可能被窃听
2. 不验证通讯方的身份, 所以可能遭遇假装
3. 没法验证报文的完整性, 因此有可能已遭篡改

6.1.1 通讯使用明文, 内容可能被窃听

HTTP自己不具有加密的功能, 没法对通讯总体进行加密, HTTP报文使用明文的方式进行传输.

互联网中都是相通的, 在通讯线路上的某些网络设备, 光缆, 计算机均可能遭到恶意窥视, 窃取通讯数据, 为了防止信息被恶意窃听, 可使用加密技术.

通讯的加密: 将通讯进行加密, HTTP经过和SSL或TLS的组合使用, 加密HTTP的通讯, 使用SSL创建安全通讯线路以后, 就能够在安全的通讯线路上进行通讯, 与SSL组合使用的HTTP称为HTTPS.

内容的加密: 将通讯的内容进行加密, 把HTTP报文里所包含的内容进行加密处理. 这种状况, 客户端须要将HTTP报文进行加密之后再发送请求, 这就要求客户端和服务端具有相同的加密和解密机制.须要注意的是, 通过加密以后的内容仍是能够被篡改的. 只对HTTP报文主体进行加密, 不加密报文头部.

6.1.2 不验证通讯方的身份, 所以可能遭遇假装

在HTTP通讯时, HTTP协议中的请求和响应不会对通讯方进行确认, 任何人均可以发起请求, 服务器接收到请求之后就会返回响应, 这里就存在安全问题, 客户端多是冒充的客户端, 服务器多是冒充的服务器. 使用SSL能够解决这个问题, SSL不只提供加密处理, 还使用了一种被称为证书的手段. 证书是值得信任的第三方机构颁发, 用来证明服务器和客户端的身份, 证书伪造在技术上是异常困难的一件事, 因此只要可以确认通讯方持有的证书, 就能够判断通讯方的身份.

6.1.3 没法验证报文的完整性, 因此有可能已遭篡改

HTTP协议没法证实通讯的报文完整性, 不能保证发送请求之后, 接收到的响应就是对应客户端的响应, 中间可能被拦截篡改.

6.2 HTTPS

添加了加密和认证机制的HTTP称为HTTPS.

HTTPS并不是一种新协议, 只是在HTTP通讯接口部分用SSL和TLS协议替换, 一般HTTP直接和TCP通讯, 当使用SSL时, HTTP先和SSL通讯, SSL再和TCP通讯, HTTP就拥有了HTTPS的加密, 证书和完整性保护功能.

6.2.1 SSL中的加密

SSL采用一种叫作公开秘钥加密的加密方式, 加密算法是公开的, 秘钥是保密的. 加密和解密都用到秘钥, 若是秘钥被其余人窃取, 那么加密就无心义了.

加密和解密使用同一个秘钥的方式成为共享密钥加密, 也成为对称密钥加密. 以共享密钥方式加密时必须将密钥发送给对方, 问题来了, 怎么讲共享密钥安全发送给对方呢? 若是共享密钥在发送的过程当中被拦截, 那么加密还有什么意义..

为了解决这个问题, 咱们来引入公开密钥的概念, 公开密钥加密使用一对非对称的密钥, 一把是私有密钥一把是公开秘钥, 私有密钥只有本身知道, 公开密钥能够任意公开. 客户端和服务端各有一对密钥, 客户端发送请求的时候使用服务端的公开密钥对内容进行加密, 服务端接收到客户端的请求, 使用本身的私有密钥对内容进行解密, 而后使用客户端的公开密钥对响应进行加密, 客户端接收到响应之后使用本身的密钥对响应进行解密.

HTTPS采用共享密钥加密和公开密钥二者并用的混合加密机制, 公开密钥加密相比共享密钥加密, 公开密钥加密的处理速度相对较慢, 因此咱们来考虑共享密钥的加密处理, 共享密钥的加密处理的问题在于咱们如何将密钥安全的传达给对方. 咱们能够考虑使用公开密钥的加密方式将共享密钥做为内容传递给对方, 对方使用本身的密钥将内容解密以获取到共享密钥, 这样共享密钥就被安全传达, 之后的通讯就使用共享密钥加密的方式进行通讯.

至此, 还有一个问题须要考虑, 咱们在使用公开密钥进行加密时, 如何保证公开密钥的正确性? 好比咱们在和某台服务器在公开密钥加密的方式下通讯时, 如何确保咱们收到的公开密钥就是咱们要通讯的那台服务器的公开密钥呢? 极可能在公开密钥传输的过程当中, 公开密钥已经被篡改了. 为了解决这个问题, 咱们要让公开密钥和咱们所说的这台服务器最对应, 可使用由数字证书认证机构(CA, Certificate Authority)和其相关机关颁发的公开密钥证书.

数字证书认证机构是在客户端和服务器都信赖的第三方认证机构的立场上. 服务器的运营认证人员向数字证书认证机构提出公开密钥的申请, 数字证书认证机构在肯定申请者的身份后对公开密钥进行签名, 生成数字证书, 或者叫作证书. 而后分配这个已签名的公开密钥. 在通讯的时候, 服务器会将这个证书发送给客户端, 客户端接收到这个证书, 使用服务器的公开密钥对证书进行验证, 若是验证经过, 客户端能够确认服务器的公开密钥是值得信赖的, 此处服务器的公开密钥必须安全的转交给客户端, 如何安全的将公开密钥转交是一件很困难的事情, 所以, 不少浏览器开发商发布版本时, 会事先在内部植入常见认证机构的公开密钥, 那么上边咱们所说的保证公开密钥正确性的问题就解决了.

客户端已经完成了对服务端身份的验证, 那么服务端是否能够对客户端的身份作验证呢? HTTPS中可使用客户端证书, 使用客户端证书能够对客户端进行认证, 其做用和服务器证书相似. 可是这里存在一个问题, 就是客户端证书的获取以及证书的发布. 因为客户端证书是收费的, 也就是有多少用户就要购买多少客户端证书, 这个在大天朝来讲是不太现实的. 并且购买完证书之后, 客户端须要手动安装, 这个对不一样的用户来讲也是不太容易实现的. 可是对于一些安全性要求很高的业务来讲, 客户端认证仍是有必要的, 好比银行的网上银行就采用了客户端证书.

6.2.2 HTTPS通讯过程

这部分的内容理解之后再整理