HTTP与HTTPS简介

面试中问到了HTTP的请求头响应头,状态码代表的含义,之前没有汇总很容易就忘记了。顺带复习一下Https的原理和通信过程。


HTTP

HTTP请求报文和响应报文格式

  • HTTP报文分请求报文和响应报文两种,它们都由三个部分组成:
    • 起始行:对报文进行描述。起始行分为请求行和响应行
    • 首部:包含属性
    • 主体:可选的,包含数据。

HTTP请求报文

  • 一个HTTP请求报文由请求行(request line)、请求头部(header)、空行和请求数据4个部分组成。
1
2
3
4
5
6
7
8
9
10
11
12
<method> <request-URL> <version> # 请求方法,请求URL, 协议版本
<headers>

<entity-body>

# 例子:
POST /myblog/addPosts HTTP/1.1
Host: xxx
Content-type: xxx
Content-length:18

item=xxx

HTTP响应报文

  • HTTP响应报文也由状态行、消息报头、空行,响应正文四个部分组成。
1
2
3
4
5
6
7
8
9
10
11
<version> <status> <reason-phrase> # HTTP协议版本、数字状态码和原因短语
<headers>

<entity-body>

# 例子:
HTTP/1.1 200 OK
Content-type:text/plain
Content-length:37

xxxjavaxxxgo

方法字段

方法 描述 是否包含主体 解释
GET 从服务器中获取文档 常用方法,用于请求服务器发送某个资源,在HTTP/1.1中,要求服务器实现该方法。
HEAD 从服务器获取文档首部 类似GET方法,但是响应只返回首部。目的是允许客户端对资源的首部进行检查。该方法有以下作用:不获取资源的前提下了解资源情况;查看对象是否存在;测试资源是否被修改。规范要求其返回的首部于GET方法获得的相同。
POST 向服务器发送需要处理的数据 起初用来输入数据,现多用来支持HTTP表单。表单体拿到的数据发送给服务器,再由服务器决定去向。该方法不需要存储资源。
PUT 将请求的主体存储在服务器上  向服务器写入文档,其方法的语义即让服务器用请求的主体部分(body)创建或者覆盖所请求的URL命名的新文档。由于其允许用户修改文件,通常要求进行密码认证。该方法需要存储资源。
TRACE 对可能经过代理服务传送到服务器上的报文进行追踪 TRACE方法允许客户端最后将请求发送给服务器。该请求会进行“环回”诊断,即在服务器弹回一条携带收到的报文的TRACE响应,使得客户端能查看原始报文的修改情况。
OPTIONS 查询服务器支持的方法 请求Web服务器告知其支持的所有方法,这些方法是通用于服务器上所有资源的。这使得客户端可以判定请求资源的最优方法。(就是优化)
DELETE 从服务器上删除文档 否  请求服务器删除请求URL指定的资源,但是客户端程序不保证删除操作被执行。

状态码

  • 服务器对客户端操作结果的回应。状态码有五种分类,而当前HTTP版本只规定了其中一部分。如果接收到拓展的状态码,则会按照其所属范围进行分类,而后按照该分类中的普通成员处理。状态码分类如下:
整体范围 已定义范围 分类
100~199 100、101 信息提示
200~299 200~206 请求成功
300~399 300~305 重定向
400~499 400~415 客户端错误
500~599 500~505 服务器错误

状态码详细解释

信息性状态码100~199

状态码 原因短语 含义
100  Continue 说明收到请求的初始部分,请客户端继续。发送了这个状态码以后,服务器在收到请求之后必须响应。
101 Switching Protocol 说明服务器正在根据客户端的指定,将协议切换成Update首部所列的协议

成功状态码200~299

状态码 原因短语 含义
200 OK 请求没问题,实体的主体部分包含请求的资源。
201 Created 对用于创建服务器对象的请求的响应。其实体的主体部分应该包含各种引用了已创建资源的URL,Location首部包含的是最具体的引用。
202 Accepeted 请求已被接受,但是未执行并不保证执行请求。服务器应该在实体的主体部分包含对请求状态的描述,以及完成请求的时间的估算(或者可以获得此信息位置的指针)。
203 Non-authoritative Information 实体首部包含的信息来自资源的副本(而非服务器)。在中间节点有资源副本,但是无法或者没有对它发送的与资源有关的首部进行验证时,出现的情况。
 204 Not Content 响应报文包含首部和状态行,但是没有实体的主体部分。用于在浏览器不转为显示新文档的情况下,对其进行更新。
 205 Reset Content 用于浏览器,告知浏览器清楚当前页面中所有HTML表单元素。
 206 Partial Content 成功执行一个部分或者Range请求。其必须包含Content-Range\Date或者Content-Location首部。

重定向状态码300~399

  • 告知用户使用替代位置来访问资源,或者提供一个替代的响应而不是资源内容。如果资源已移动,则可以发送重定向状态码以及一个可选的Location首部来告知客户端资源已被移动,以及当前位置。这浏览器可以透明转入新的位置。也可以通过重定向状态码验证本地资源与服务器资源,用于查看服务器资源的修改,以及保持本地副本的及时性。对包含了重定向状态码的非HEAD请求进行响应,则包含一个实体,并在实体中描述信息和指向(多个)重定向URL的连接。
状态码 原因短语 含义
300 Multiple Choices 客户端请求一个实际上指向多个资源的URL时返回。服务器在返回时,可以在Location首部包含首选URL
301 Moved Permanently 在请求的URL已经移除时使用。响应的Location首部则包含资源的现URL
302 Found 类似301,但是Location首部给出的URL只能临时定位资源,之后的请求应使用旧URL
303 See Other 告知客户端应使用另一个URL获取资源。新URL位于Location首部,目的是允许POST请求的响应将客户端重定向到某个资源上
304 Not Modified 客户端可以通过包含的请求首部,使其变为有条件的。条件首部的内容可以在后面看到。带有该状态码的响应不包含实体的主体部分。
305 Use Proxy 说明该资源必须通过代理访问。代理位置由Location首部指出。客户端是相对某个特定资源解析该响应,而不是指定所有资源通过该代理进行。
307 Temporary Redirect 类似301。但是Location首部给出的URL只能临时定位资源,之后的请求应使用旧URL

客户端错误状态码400~499

状态码 原因短语 含义
401 Bad Request 告知客户端发送了一个错误请求。
402 Unauthorized 与适当的首部一同返回,请求客户端在获取资源的访问权以前,对自己进行认证。
403 Payment Required 未使用,但是保留到未来使用。
404 Not Found 服务器无法找到请求的URl,通常包含一个实体,显示给客户端。
405 Method Not Allowed 发送的请求中带有URl不支持的方法。其在响应中应该包含Allow首部,告知该资源可以使用的方法。
406 Not Acceptable 在没有客户端可接受的URL相匹配的资源时使用,客户端可以指定参数来说明它们愿意接受的实体类型。
407 Proxy Authentication Required 类似401,但是用于对要求对资源进行认证的代理服务器。
408 Request Timeout 客户端完成请求的时间超时,服务器发送此状态码并关闭连接。
409 Conflict 说明请求可能在资源上引发的冲突。在服务器担心请求可能会引发冲突时,发送此状态码。响应中应包含描述冲突的主体。
410 Gone 类似404,只是服务器曾经拥有该资源,用于站点的维护,可以在服务器的资源被移除时通知客户端。
411 Length Required 服务器的要求
412 Precondition Failed 发起条件请求,但是其中一个条件失败时使用。
413 Request Entity Too Large 客户端发送的实体主体部分大于服务器能处理的内容。
414 Request URI Too Long URL实在太长。
415 Unsupported Media Type 服务器无法理解或者无法支持客户端所发送的实体的内容类型时使用。
416 Requested Range Not Satisfiable 请求报文请求的是指定资源的某个范围,但是该范围无效或者无法满足。
417 Expectation Failed 包含期望的请求无法由服务器满足。如果代理或者中间程序有确切证据说明服务器必然会产生一个失败的期望,则可以发送这个响应状态码。

服务器错误状态码500~599

  • 客户端的请求有效,但是服务器出错时,可以使用,这是通常是代理与服务器交流的结果。
状态码 原因短语 含义
500 Internal Server Error 服务器遇到一个妨碍它为请求提供服务的时候使用。
501 Not Implemented 客户端发起的请求超过服务器能力时使用
502 Bad Gateway 作为代理或者网关使用的服务器从请求响应链的下一条链路上收到了一条伪响应时使用
503 Sevice Unavailable 用来说明服务器现在无法为请求提供服务
504 Gateway Timeout 类似408,但是该响应来自一个网关或者代理
505 HTTP Version Not Supported 收到的请求的版本不符。

首部

通用首部

  • 提供与报文相关的最基本的信息,可以由两种报文使用。信息性首部有:
首部 描述
Connection 允许客户端和服务器指定与请求/响应连接相关的选项
Date 提供日期和时间标志,说明报文创建的时间
MIME-Version 给出发送端使用的MIME版本
Trailer 报文采用了分块传输编码时,使用该首部列出位于报文拖挂(trailer)部分的首部集合。
Transfer-Encoding 告知报文采用的编码方式
Update 给出发送端可能想要“升级”使用的新版本或者协议
Via 显示报文经过的中间节点

通用缓存首部

首部 描述
Cache-Control 用于随报文传送缓存指令
Pragma 另一种随报文传送指令的方式,但是非专门用于缓存

请求首部

  • 在请求报文中特有的内容。对服务器提供更详细的有关客户端的信息。其信息性首部有:
首部 描述
Client-IP 运行客户端的机器的IP
From 客户端用户的邮箱地址
Host 请求的服务器主机名和端口号
Referer 包含当前请求URL的文档的URL
UA-Color 提供了与客户端显示器对颜色的支持的有关信息
UA-CPU 提供了客户端的CPU类型或制造商
UA-Disp 提供客户端显示器能力相关信息
UA-OS 提供客户端操作系统信息——名称及其版本
UA-Pixels 提供客户端显示器像素
User-Agent 将发起请求的应用程序名告知服务器

Accept首部

  • 为客户端提供将器喜好和能力告知服务器的方式,从而使得连接的两端都得益。主要的Accept首部如下
首部 描述
Accept 告诉服务器能够发送那些媒体类型
Accept-Charset 能够发送的字符集
Accept-Encoding 能够接受的编码方式
Accept-Language 能够发送的语言
TE 能使用那些扩展传输编码

安全请求首部

  • 对请求进行质询后者响应认证。要求客户端在获取特定资源之前,对自身进行认证,从而提高事务安全性。
首部 描述
Authorization 包含客户端提供给服务器,以便对其自身进行认证的数据
Cookie 传递给服务器的一个令牌,隐含安全功能
Cookie2 用来说明请求端支持的Cookie版本

代理请求首部

  • 由于代理的普遍应用而来。
首部 描述
Max-Forward 在通往源服务器的路径上,将请求转发给其他代理(网关)的最大次数,与TRACE一同使用
Proxy-Authorization 与同名首部功能相同,但是用于代理
Proxy-Connection 与同名首部功能相同,但是用于代理

响应首部

  • 由响应报文使用,为客户端提供额外的信息,包括信息性首部、协商首部和安全响应首部。信息性首部如下:
首部 描述
Age 响应持续时间
Public 服务器为资源提供的方法列表
Retry-After 资源不可用则在该日期或者时间重试
Server 服务器应用的名称和版本
Title HTML源端给定的标题
Warning 比原因短语详细的警告报文

协商首部

  • 传递与可协商资源有关的信息。
首部 描述
Accept-Range 对该资源来说,服务器可以接受的范围类型
Vary 服务器查看的其他首部的列表,可能使响应变化。即由服务器决定最适合的资源版本发送给客户端

安全响应首部

  • HTTP的质询/响应认证机制的响应侧
首部 描述
Procy-Authenticate 来自代理对客户端的质询列表
Set-Cookie 在客户端设置令牌,标识客户端
Set-Cookie2 类似上面
WWW-Authenticate 来自服务器的对客户端的质询列表

实体首部

  • 可以出现在两种报文中,提供有关实体及其内容的大量信息,其信息性首部有:
首部 描述
Allow 列出对该实体可以执行的请求方法
Location 告知客户端实体的位置,用于定向到资源的位置

内容首部

  • 包含的是与实体内容有关的特定信息。 |
首部 描述
Content-Base 解析主体中相对URL时使用的基础URL
Content-Encoding 对主体执行的编码方式
Content-Language 理解主体适合的自然语言
Content-Length 长度
Content-Location 位置
Content-MD5 MD5校验码
Content-Range 该实体表示的字节范围
Content-Type 对象类型

缓存首部

  • 说明了被缓存的主体的信息。
首部 描述
ETag 与实体相关的实体标记
Expires 实体不再有效,要从原始的源端中再次获取该实体的日期和时间
Last-Modified 实体最后一次被修改的日期和时间

HTTPS

  • 超文本传输安全协议(英语:Hypertext Transfer Protocol Secure,缩写:HTTPS,常称为HTTP over TLSHTTP over SSLHTTP Secure)是一种通过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信,但利用SSL/TLS来加密数据包。HTTPS开发的主要目的,是提供对网站服务器的身份认证,保护交换数据的隐私与完整性。这个协议由网景公司(Netscape)在1994年首次提出,随后扩展到互联网上。
  • HTTPS的主要思想是在不安全的网络上创建一安全信道,并可在使用适当的加密包和服务器证书可被验证且可被信任时,对窃听和中间人攻击提供合理的防护。
  • 与HTTP的差异
    • 与HTTP的URL由http://起始且默认使用端口80不同,HTTPS的URL由https://起始且默认使用端口443
    • HTTP是不安全的,且攻击者通过监听和中间人攻击等手段,可以获取网站帐户和敏感信息等。HTTPS被设计为可防止前述攻击,并在正确配置时被认为是安全的。
  • 协议层
    • HTTP协议和安全协议同属于应用层(OSI模型的最高层),具体来讲,安全协议工作在HTTP之下,运输层之上:安全协议向运行HTTP的进程提供一个类似于TCP的套接字,供进程向其中注入报文,安全协议将报文加密并注入运输层套接字;或是从运输层获取加密报文,解密后交给对应的进程。严格地讲,HTTPS并不是一个单独的协议,而是对工作在一加密连接(TLS或SSL)上的常规HTTP协议的称呼
    • HTTPS报文中的任何东西都被加密,包括所有报头和荷载。除了可能的选择密文攻击(参见限制小节)之外,一个攻击者所能知道的只有在两者之间有一连接这一事实。
  • 局限
    • TLS有两种策略:简单策略和交互策略。交互策略更为安全,但需要用户在他们的浏览器中安装个人的证书来进行认证。不管使用了哪种策略,协议所能提供的保护总强烈地依赖于浏览器的实现和服务器软件所支持的加密算法。
    • HTTPS并不能防止站点被网络蜘蛛抓取。在某些情形中,被加密资源的URL可仅通过截获请求和响应的大小推得,这就可使攻击者同时知道明文(公开的静态内容)和密文(被加密过的明文),从而使选择密文攻击成为可能。
    • 因为HTTPS连接所用的公钥以明文传输,因此GFW可以对特定网站按照匹配的黑名单证书,通过伪装成对方向连接两端的计算机发送RST包干扰两台计算机间正常的TCP通讯,以打断与特定IP地址之间的443端口握手,或者直接使握手的数据包丢弃,导致握手失败,从而导致TLS连接失败。

HTTPS的工作原理

HTTPS 是怎么实现安全通信的?

  • 加密传输确实安全,但是客户端把数据加密后,服务器怎么解密呢?又怎样保证中间人窃听到密文后无法解密呢?
  • 解决方案:对称加密

怎样在通信之前,给双方分配两把一样的钥匙呢?

  • 两个问题:
    • 实际通信往往是一个服务器和成千上万的客户端之间的通信。
    • 即使使用了对称加密技术,如果一方保管不善的话,也有可能钥匙被人偷了去复制一个,这样就存在很大的安全隐患,最好是每个客户端每次和服务器通信都用不同的密钥。
  • 解决方案: 密钥交换(Key Exchange):
    • Deffie-Hellman 密钥交换算法
    • RSA 密钥交换算法
  • RSA 密钥交换算法需要客户端向服务器提供一个Pre-Master-Key,然后通信双方再生成Master-Key,最后根据 Master-Key 产生后续一系列所需要的密钥,包括传输数据的时候使用的对称密钥。

客户端怎么把 Pre-Master-Key 告诉服务器呢?直接明文传输么?

  • 悖论在于:为了加密通信,需要先把Pre-Master-Key传送给服务器,但是这个传送又必须要加密!!!
  • 解决方案:非对称加密。服务器可以生成一对不同的密钥(所谓非对称),一把私自保存,称为私钥;一把向所有人公开,称为公钥。
  • 具体的交互过程:
    • 客户端向服务器索取公钥 PublicKey;
    • 服务器将公钥发给客户端(这里没有保密需求,因为公钥是向所有人公开的);
    • 客户端使用服务器的公钥 PublicKey 把 Pre-Master-Key 加密成密文,传送给服务器;
    • 服务器用私钥 PrivateKey 解密密文,获取到客户端发送的 Pre-Master-Key;
  • 但是上面的第二个过程会发生中间人攻击(MITM: Man-in-the-middle-attack)
    • 中间人也可以生成一对非对称密钥,它会截获服务器发送的公钥,然后把它自己的公钥 MiddleMan-PublicKey 发送给客户端,进行欺骗。
    • 而客户端,竟然信以为真!然后傻乎乎的把自己的 Pre-Master-Key 用 MiddleMan-PublicKey 加密后,发给中间人。

Man-in-the-middle-attack.png-38.2kB

如何解决中间人攻击?

  • 客户端怎么确定收到的公钥,真的就是服务器的公钥?
  • 解决方案:证书
    • 乘高铁、坐飞机的时候,怎么向工作人员证明你是你。答案很简单,到公安局(权威机构 英文名:Authority)出个身份证明(Certificate)身份证上记载了你的号码、姓名、年龄、照片、住址,还有签发机关、有效期等。
    • 所以,服务器也想办法到权威机构 (Authority) 办一张证书Certificate,上面记载了服务器的域名、公钥、所属单位,还有签发机关、有效期等。
    • 当客户端收到服务器发过来的证书后,只要证书不是伪造的,那么上面记载的公钥肯定也就是真的!(证书上记录了公钥)

怎么证明证书不是伪造的?

  • 解决方案:签名
    • 只要服务器发送的证书上有权威机构Authority的签名,就可以确信证书是颁发给服务器的,而不是谁伪造的。

计算机的数字化签名怎么实现呢?

  • 解决方案:非对称加密技术
    • 数字证书认证机构(Certificate Authority,简称 CA)生成一对公/私钥;
    • 服务器将自己的域名、公钥等信息提交给 CA 审查;
    • CA 审查无误,使用私钥把服务器信息的摘要加密,生成的密文就是所谓签名(Signature);
    • CA 把服务器的信息、签名、有效期等信息集合到一张证书上,颁发给服务器;
    • 客户端收到服务器发送的证书后,使用CA的公钥解密签名,获得服务器信息的摘要,如果和证书上记录的服务器信息的摘要一致,说明服务器信息是经过 CA 认可的。

客户端怎么知道 CA 的公钥?

  • 世界上的根 CA 就那么几家,浏览器或者操作系统在出厂的时候,已经内置了这些机构的自签名证书,上面记录他们的公钥信息,你也可以在需要的时候手动安装 CA 证书。Chrome浏览器查看证书步骤如下: F12–>Security选项卡(找不到的点右箭头>>),然后点击View certificate

ca-chrome.png-118.4kB

所以,HTTPS的基本通信过程如下

  • 操作系统/浏览器 自带了 CA 根证书;
  • 客户端因此可以验证服务器发送的证书真实性,从而获取到服务器的公钥;
  • 有了服务器的公钥,客户端就可以把 Pre-Master-Key 传送给服务器;
  • 服务器获取到 Pre-Master-Key 后,通过后续产生的对称密钥,就可以和客户端加密通信了

HTTPS 通讯过程的基本原理,涉及到了对称加密、非对称加密、信息摘要、签名、密钥交换等技术基础,以及发行机构、数字证书等概念。


引用