美文网首页
HTTP协议与HTTPS协议

HTTP协议与HTTPS协议

作者: 苏沫离 | 来源:发表于2018-09-19 16:09 被阅读0次
    本文大纲

    协议是指计算机通信网络中两台计算机之间进行通信所必须共同遵守的规定或规则。

    1、HTTP 协议

    1.1、 什么是 HTTP 协议?

    超文本传输协议 HTTP 是一种通信协议: 详细规定了浏览器和万维网(WWW = WorldWideWeb)服务器之间互相通信的规则,用于从WWW服务器传输超文本到本地浏览器的数据传送协议。

    • 它允许将超文本标记语言 HTMLWeb 服务器传送到客户端的浏览器;
    • 它可以使浏览器更加高效,使网络传输减少;
    • 它不仅保证计算机正确快速地传输超文本文档,还确定传输文档中的哪一部分,以及哪部分内容首先显示(如文本先于图形)等。
    1.2、 HTTP 协议的发展
    发展历史 产生时间 内容
    HTTP/0.9 1991年 不涉及数据包传输,规定客户端和服务器之间通信格式,只能GET请求
    HTTP/1.0 1996年 传输内容格式不限制,增加 PUT、PATCH、HEAD、 OPTIONS、DELETE 命令
    HTTP/1.1 1997年 持久连接(长连接)、节约带宽、HOST域、管道机制、分块传输编码
    HTTP/2 2015年 多路复用、服务器推送、头信息压缩、二进制协议等

    HTTP/0.9HTTP/1.0使用非持续连接:限制每次连接只处理一个请求,服务器处理完客户的请求,并收到客户的应答后,即断开连接。HTTP/1.1使用持续连接:不必为每条请求创建一个新的 TCP 连接,一个TCP连接可以传送多个请求,采用这种方式可以节省传输时间。

    HTTP/2 ‘多路复用’的性能优势

    多路复用:通过一个HTTP/2 连接请求可以同时发起多个请求/响应 消息,多个请求流共享一个 TCP 连接,实现多留并行而非建立多个 TCP 连接。

    1.3、 HTTP 协议的特点

    HTTP 协议是一个应用层协议,主要特点可概括如下:

    • 基于请求和响应: HTTP 协议永远都是客户端发起请求,服务器回送响应。这样就限制了 HTTP协议的使用,无法实现在客户端没有发起请求的时候,服务器将消息推送给客户端。
    • 灵活:HTTP 允许传输任意类型的数据;传输的数据类型由 Content-Type 加以标记。
    • 无状态协议:协议对客户端没有状态存储,对事物处理没有“记忆”能力;比如访问一个网站需要反复进行登录操作,这样可能导致每次连接传送的数据量增大。
    • 不安全:通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性。
    无状态协议

    协议的状态是指下一次传输可以“记住”这次传输信息的能力。

    HTTP 协议为了保证服务器内存、提高服务器对并发访问的处理能力;在服务器发送响应报文时,是不会为了下一次连接而维护这次连接所传输的信息。
    这有可能出现一个浏览器在短短几秒之内两次访问同一对象时,服务器进程不会因为已经给它发过响应报文而不接受第二次请求。

    是否进行持久连接?

    HTTPTCP 连接的使用,分为两种方式:短连接长连接

    • HTTP 1.0 版本,使用的是短连接;
    • HTTP/1.1 起,支持 长连接 并默认都开启了 Keep-Alive ,保持连接特性;

    简单地说,HTTP/1.1之后,当一条数据传输完成后,客户端和服务器之间的TCP连接不会关闭,如果客户端再次请求这个服务器上的数据,会继续使用这一条已经建立的连接。
    利用持久连接的优点,当加载多个图片时,显著地减少下载所需要的时间。

    当然,Connection: Keep-Alive 不会永久保持连接,它有一个保持时间,可以在不同的服务器设定这个时间。

    在请求头部设置Connection: close 代表一个请求完成后,客户端和服务器之间用于传输数据的TCP连接关闭,当客户端再次发送请求,需要重新建立TCP连接。

    1.4、 HTTP 协议通信流程
    HTTP通信流程

    一次 HTTP 工作的过程可分为四步:

    • step1:客户端与服务器需要建立 TCP 连接;只要单击某个链接, HTTP 的工作开始;
    • step2:建立 TCP 连接后,客户端发送 请求报文 给服务器;请求报文有四大部分:请求行、请求头、空行、请求数据
    • step3:服务器接到请求后,给予相应的 响应报文;响应报文有三大部分:状态行、消息报头、响应正文 ;
    • step4:客户端接收服务器返回的数据后,根据 Connection 字段信息决定是否断开 TCP 连接。

    如果在以上过程中的某一步出现错误,那么产生错误的信息将返回到客户端。

    1.4.1、建立 TCP 连接,为什么需要三次握手呢?

    为了防止已失效的连接请求报文突然传送到了服务端,因而产生错误。比如:

    • 客户端发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间滞留了,以致延误到TCP 连接释放以后的某个时间才到达服务器。
    • 本来这是一个早已失效的报文段,但是服务器收到此失效的连接请求报文段后,就误认为是客户端再次发出的一个新的连接请求,于是就向客户端发出确认报文段,同意建立连接。
    • 假设不采用“三次握手”,那么只要服务器发出确认,新的连接就建立了,由于客户端并没有发出建立连接的请求,因此不会理睬服务器的确认,也不会向服务器发送请求数据,但服务器却以为新的运输连接已经建立,并一直等待客户端发来数据。
    • 所以没有采用“三次握手”,这种情况下服务器的很多资源就白白浪费掉了。

    2、HTTPS 协议

    HTTPS 协议 = HTTP 协议 + SSL/TLS 协议

    超文本传输安全协议 HTTPS 是一种通过计算机网络进行安全通信的传输协议,经由HTTP 进行通信,利用 SSL/TLS在不安全的网络上创建一个安全通道,加密数据包,对窃听和中间人攻击提供一定程度的合理防护。
    使用HTTPS 的主要目的是提供对网站服务器的身份认证,同时保护交换数据的隐私与完整性。

    HTTPS 协议的特点

    • 兼容性:它基于 HTTP 协议,通过 SSL\TLS 提供加密处理数据、验证对方身份以及数据完整性保护;
    • 保密性:采用混合加密技术,中间者无法直接查看明文内容;
    • 完整性:确保传输的数据不被中间人冒充或者篡改;
    • 真实性:通过证书认证客户端与服务器的身份,辨别中间人,防止“域名劫持”;
    2.1、 SSL/TLS 的一些加密方式

    涉及到的一些密码学名词:

    • 明文:未被加密过的原始数据。
    • 密文:明文被某种加密算法加密之后,会变成密文,从而确保原始数据的安全。密文也可以被解密,得到原始的明文。
    • 密钥:密钥是一种参数,它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥,分别应用在对称加密和非对称加密上。
    2.1.1、 对称加密

    对称加密又叫做私钥加密,即信息的发送方和接收方使用同一个密钥去加密和解密数据。(私钥表示个人私有的密钥,即该密钥不能被泄露。)

    加密过程如下:明文 + 加密算法 + 私钥 -> 密文
    解密过程如下:密文 + 解密算法 + 私钥 -> 明文

    对称加密的特点是算法公开、加密和解密速度快,适合于对大数据量进行加密;但私钥泄露,密文很容易就被破解,所以对称加密的缺点是密钥安全管理困难。

    常见的对称加密算法有 DES、3DES、TDEA、Blowfish、RC5 和 IDEA。

    2.1.2、 非对称加密

    非对称加密也叫做公钥加密:使用公钥和私钥,且二者成对出现。私钥被自己保存,不能对外泄露;公钥指的是公共的密钥,任何人都可以获得该密钥。用公钥或私钥中的任何一个进行加密,用另一个进行解密。

    被公钥加密过的密文只能被私钥解密,过程如下:

    明文 + 加密算法 + 公钥 -> 密文 
    密文 + 解密算法 + 私钥 -> 明文
    

    被私钥加密过的密文只能被公钥解密,过程如下:

    明文 + 加密算法 + 私钥 -> 密文
    密文 + 解密算法 + 公钥 -> 明文
    

    由于加密和解密使用了两个不同的密钥,相对于对称加密,非对称加密安全性更好。但非对称加密的缺点是加密和解密花费时间长、速度慢,只适合对少量数据进行加密。

    在非对称加密中使用的主要算法有:RSA、Elgamal、Rabin、D-H、ECC(椭圆曲线加密算法)等。

    2.1.3、哈希 Hash 算法

    Hash算法能将任意长度的二进制明文串映射为较短的(通常是固定长度的)二进制串( Hash 值),并且不同的明文很难映射为相同的 Hash 值(发生碰撞)。

    这意味着对于某个文件,无需查看其内容,只要对其 Hash 计算后,结果相同,则说明文件内容没有被篡改。

    Hash 算法与加密是不同的

    • Hash是将目标文本转换成具有相同长度的、不可逆的杂凑字符串(或叫做消息摘要)
    • 加密是将目标文本转换成具有不同长度的、可逆的密文。

    常用的Hash 算法有:MD5、SHA1、SHA256 等。

    2.1.4、数字摘要

    数字摘要是对内容进行 Hash 运算,获取唯一的摘要值来指代原始完整的内容。

    利用 Hash函数的抗碰撞性特点,数字摘要可以确保内容未被篡改。

    2.2、 SSL/TLS 协议
    2.2.1、SSL/TLS 协议简介

    安全套接层 SSLSecure Sockets Layer 的缩写,它是在上世纪90 年代中期,由网景公司Netscape设计的。由于原先互联网上使用的 HTTP 协议是明文的,存在很多缺点——比如传输内容会被偷窥(嗅探)和篡改;发明 SSL 协议,就是为了解决这些问题。
    到了1999年,SSL 因为应用广泛,已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 传输层安全协议 TLSTransport Layer Security )。

    2.2.2、SSL/TLS 协议的握手阶段与数据通信阶段

    SSL/TLS 介于传输层和应用层之间:它通过 握手阶段数据通信阶段 来解决传输中数据安全的问题。

    • 握手阶段:建立起连接的过程,这个阶段采用 非对称加密;这个过程完毕后会协商出一个 对称加密 的私钥;
    • 数据通信阶段:使用 对称加密的私钥 加密与解密数据。
    SSL/TLS 握手流程.png

    握手阶段可以分为下述步骤:

    • step1 客户端向服务器发起请求,连接到服务器的443端口;客户端提供自己支持的SSL/TLS协议版本号、加密方法列表、压缩方法列表以及一个生成的随机数;
    • step2 服务器确认双方使用的SSL/TLS协议版本号、加密方法、压缩方法,并给出非对称加密的公匙、以及一个服务器生成的随机数;
    • step3 客户端生成一个新的随机数,并使用服务器的公钥加密这个随机数,发给服务器;
    • step4 服务器使用自己的私钥,解密客户端发来的随机数;
    • step5 客户端和服务器根据约定的加密方法,使用上述的三个随机数,生成 会话密钥 session key ,用来加密接下来的通信过程。

    上述流程需要注意:

    • 生成 会话密钥 session key 需要三个随机数;
    • 服务器非对称加密的公钥和私钥只用于加密和解密 对话密钥,只用到一次,无其他作用;
    2.2.3、被拦截的公钥

    假如有一个中间人,拦截服务器的公匙,并向客户端发送自己伪造的公匙,那么依旧可以获取并篡改通信内容!

    SSL/TLS 握手流程(中间人)

    在上述过程中,客户端与服务端,均不知道他们的通信被中间人拦截了。
    怎么才能避免中间人拦截呢??可以要求客户端对服务端的身份、公匙做合法性的校验,保证客户端收到的公钥是服务端的公钥,而不是中间人伪造的公钥!!

    合法性的校验,也就是客户端和服务器,都需要一个值得信任的公证人!将服务器的公匙交给公证人,由公证人颁布一个证书,证书包含公钥以及身份信息等,客户端通过验证证书的合法性来确保公匙来自于服务端。(所谓的公证人也就是证书颁发机构)

    证书是用来认证公钥持有者身份的电子文档,防止第三方进行冒充。一个证书中包含了公钥、持有者信息、证明证书内容有效的签名以及证书有效期,还有一些其他额外信息。

    2.3、数字证书

    数字证书通常来说是由受信任的数字证书颁发机构CA,在验证服务器身份后颁发。
    证书颁发者在得到服务端的一些必要信息(身份信息,公钥私钥、服务器域名等)之后,使用 Hash 算法得到证书内容的摘要;再用自己的私钥给这份摘要加密,生成数字签名。综合已有的信息,生成分别包含公钥和私钥的两个证书。

    一些名词:

    • CA,CA机构:机构/组织概念;
    • 数字证书,CA证书,HTTPS 证书,SSL/TLS 证书:CA签发的数字证书;
    • 数字签名,证书指纹:CA签发的证书内容,一段加密的密文;
    2.3.1、证书信任链
    证书层级结构

    数字证书的生成是分层级的,下一级的证书需要其上一级证书的私钥签名;也就是证书由颁发者的私钥签名。

    根CA认证中心的证书称为根证书,根证书自己认证自己的有效性,根证书是整个证书体系安全的根本,如果根证书出了问题,它下面所有子证书都不可被信任。
    因为子证书都是依赖根证书证明自己的有效性的,从而形成证书信任链。

    2.3.2、数字证书的合法性

    如何确保证书颁发机构颁布的证书不被拦截篡改呢?我们需要了解证书的签名与认证方式!

    数字签名过程:
    • 1、证书颁发者用数字摘要算法( Hash),将服务器的公钥和身份信息等生成一个 摘要
    • 2、证书颁发者根据非对称加密使用自己的私钥将摘要进行加密,生成 数字签名
    • 3、证书颁发机构将 服务器的公钥和身份信息等数字签名 合并,形成 数字证书
    生成证书
    数字证书验证合法性:

    服务器将数字证书发送给客户端,客户端需要对数字证书的合法性进行校验!!

    • 1、根据证书信任链,找到该证书的上一层CA认证中心的数字证书(内置证书);
    • 2、从上一层数字证书中获取公钥,使用该公钥对收到证书的数字签名进行解密生成摘要信息;
    • 3、使用数字摘要算法将收到的证书中的公钥和身份信息等生成摘要信息;
    • 4、步骤2、3 的摘要信息( Hash值)比对,如果能匹配,就说明数字证书没有被篡改;
    验证证书
    2.3.3、证书颁发机构的信任问题

    根证书是整个证书体系安全的根本。

    采用数字证书方式是为了解决公钥传输的中间人攻击问题,假如证书颁发机构的公钥传输也出现中间人攻击问题,那么问题死循环了?

    可以把证书颁发者的公钥预先加载在操作系统中!如果操作系统和客户端的公钥也被篡改,那就没招了;所以不要轻易信任/安装未知证书。

    苹果、微软等公司会根据一些权威安全机构的评估选取一些信誉很好并且通过一定的安全认证的证书发布机构,把这些证书发布机构的证书默认安装在操作系统中,并且设置为操作系统信任的数字证书。

    2.4、证书认证的HTTPS 协议通信流程

    HTTPS 在传输数据之前需要客户端与服务端之间进行一次握手,在握手过程中将确立双方加密传输数据的密码信息。

    SSL/TLS 证书认证
    HTTPS 的单向验证和双向验证

    HTTPS 的证书认证,大多数也都是采用 单向认证 ,也就是客户端向服务端请求证书、验证服务端身份。
    而像银行等机构,对安全性的要求更高,服务端也要求验证客户端的身份,即 双向认证 的方式。

    Question1、HTTPS 是否需要防域名劫持?

    没必要防域名劫持!客户端除了校验证书的有效性,还会比较证书上的域名是否与自己要访问的域名一致。因此,只要服务器的证书是可信的且客户端不跳过 证书验证 这个步骤,HTTPS 能够防止域名劫持。

    Question2、客户端的证书要提前安装吗?
    • 如果是权威CA机构签发的证书,在系统默认信任证书列表中,则会直接通过验证,一般不需要提前安装;
    • 如果是私人签发的证书,未在系统信任列表中的证书,需要提前安装。
    Question3、HTTPS使用了几套非对称加密?
    • SSL 握手阶段,协商对称加密密钥时使用的非对称加密,服务器生成,私钥在服务端;
    • 数字证书签名加密,CA机构使用的非对称加密,私钥在CA机构那边。
    2.5、session 的恢复

    握手阶段用来建立SSL连接。如果出于某种原因,对话中断,就需要重新握手。

    这时有两种方法可以恢复原来的 session

    • 一种叫做 session ID :每一次对话都有一个编号,如果对话中断,下次重连的时候,只要客户端给出 session ID ,服务器确认该编号存在,双方就不再进行握手阶段剩余的步骤,而直接用已有的对话密钥进行加密通信;
    • 另一种叫做 session ticket:客户端发送服务器在上一次对话中发送过来的 session ticket。这个 session ticket 是加密的,只有服务器才能解密,其中包括本次对话的主要信息,比如对话密钥和加密方法。当服务器收到session ticket以后,解密后就不必重新生成对话密钥了。

    3、请求报文与响应报文

    HTTP有两类报文:

    • 请求报文:由请求行(request line)、请求头部(header)、空行和请求数据4个部分组成。
    • 响应报文:由状态行、消息报头、响应正文三个部分组成。
    3.1、请求报文

    请求报文

    • 请求行:由请求方法、URL 和 HTTP协议版本 3 个字段组成,它们用空格分隔。例如,GET /index.html HTTP/1.1。
    • 请求头:通知服务器有关于客户端请求的信息;由键/值对组成。
    • 空 行:最后一个请求头之后是一个空行,发送回车符和换行符,通知服务器以下不再有请求头。
    • 请求数据:请求数据不在GET方法中使用,而是在POST方法中使用。
    3.1.1、请求方法

    HTTP/1.1 协议中共定义了八种方法来表明 Request-URI 指定的资源的不同操作方式:

    • OPTIONS:返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向服务器发送 * 的请求来测试服务器的功能性。
    • HEAD:向服务器索要与 GET 请求相一致的响应,只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下,就可以获取包含在响应消息头中的元信息。该方法常用于测试超链接的有效性,是否可以访问,以及最近是否更新。
    • GET :向特定的资源发出请求。
    • POST:向指定资源提交表单或者上传文件等;数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。
    • PUT:向指定资源位置上传其最新内容。
    • DELETE:请求服务器删除 Request-URI 所标识的资源。
    • TRACE:回显服务器收到的请求,主要用于测试或诊断。
    • CONNECTHTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。
    • PATCH:用来将局部修改应用于某一资源,添加于规范 RFC5789
    3.1.2、GETPOST的区别
    区别 GET POST
    提交数据 放在URL之后,以?分割 URL 和传输数据,参数之间以& 相连,如 EditPosts.aspx?name=test1&id=123456 把提交的数据放在 HTTP 包的 Body
    大小限制 最多只能有1024字节的数据 没有限制
    获取变量 使用Request.QueryString来取得变量的值 通过Request.Form来获取变量的值
    安全性 比如一个登录页面,用户名和密码将出现在URL上,如果页面可以被缓存或者其他人可以访问这台机器,就可以从历史记录获得该用户的账号和密码 在请求体中,相对安全
    3.2、响应报文

    响应报文

    • 状态行:通过提供一个状态码来说明所请求的资源情况。HTTP-Version Status-Code Reason-Phrase CRLF
    • 消息报头:通知客户端有关于服务器请求的信息;由键/值对组成。
    • 响应正文:
    3.3、常见的请求头
    3.3.1、缓存相关

    If-Modified-Since:把客户端缓存数据页面的最后修改时间发送到服务器去,服务器会把这个时间与服务器上实际文件的最后修改时间进行对比。如果时间一致,那么返回 304 ,客户端就直接使用本地缓存文件。如果时间不一致,就会返回 200 和新的文件内容。客户端接到之后,会丢弃旧文件,把新文件缓存起来。

    If-Modified-Since: Thu, 09 Feb 2012 09:07:57 GMT
    

    If-None-Match:和ETag一起工作,工作原理是在 HTTP Response 中添加 ETag信息。 当用户再次请求该资源时,将在HTTP Request 中加入If-None-Match信息(ETag的值)。如果服务器验证资源的ETag没有改变(该资源没有更新),将返回一个304状态告诉客户端使用本地缓存文件。否则将返回200状态和新的资源和Etag. 使用这样的机制将提高网站的性能。

    If-None-Match: "03f2b33c0bfcc1:0"。
    

    Pragma:指定 no-cache 值表示服务器必须返回一个刷新后的文档,即使它是代理服务器而且已经有了页面的本地拷贝;在HTTP/1.1版本中,它和Cache-Control:no-cache作用一模一样。Pargma只有一个用法, 例如: Pragma: no-cache
    注意: 在HTTP/1.0版本中,只实现了Pragema:no-cache, 没有实现Cache-Control

    Cache-Control:指定请求和响应遵循的缓存机制。缓存指令是单向的(响应中出现的缓存指令在请求中未必会出现),且是独立的(在请求报文或响应报文中设置Cache-Control 并不会修改另一个消息处理过程中的缓存处理过程)。请求报文的缓存指令包括no-cacheno-storemax-agemax-stalemin-freshonly-if-cached,响应报文中的指令包括publicprivateno-cacheno-storeno-transformmust-revalidateproxy-revalidatemax-ages-maxage

    • Cache-Control:no-cache: 所有内容都不会被缓存
    • Cache-Control:no-store: 用于防止重要的信息被无意的发布。在请求报文中发送将使得请求和响应文中都不使用缓存。
    • Cache-Control:Public 可以被任何缓存所缓存
    • Cache-Control:Private 内容只缓存到私有缓存中
    • Cache-Control:max-age 指示客户端可以接收生存期不大于指定时间(以秒为单位)的响应。
    • Cache-Control:min-fresh 指示客户端可以接收响应时间小于当前时间加上指定时间的响应。
    • Cache-Control:max-stale 指示客户端可以接收超出超时期间的响应消息。如果指定max-stale消息的值,那么客户端可以接收超出超时期指定值之内的响应消息。
    3.3.2、接收的数据限制

    Accept:客户端可以接受的MIME类型;例如:Accept: text/html 代表客户端可以接受服务器回发的类型为 text/html 也就是html文档,如果服务器无法返回text/html类型的数据,服务器应该返回一个406错误(non acceptable)。通配符 * 代表任意类型,例如 Accept: */* 代表客户端可以处理所有类型。

    Accept-Encoding:客户端申明自己可接收的编码方法,通常指定压缩方法,是否支持压缩,支持什么压缩方法(gzipdeflate);Servlet 能够向支持gzip 的客户端返回经gzip编码的 HTML 页面。许多情形下这可以减少5到10倍的下载时间。例如: Accept-Encoding: gzip。如果请求消息中没有设置这个域,服务器假定客户端对各种内容编码都可以接受。

    Accept-Language:客户端申明自己接收的语言;例如:Accept-Language: en-us。如果请求消息中没有设置这个报头域,服务器假定客户端对各种语言都可以接受。

    Accept-Charset:客户端可接受的字符集,中文有多种字符集,比如big5、gb2312、gbk等等。如果在请求消息中没有设置这个域,缺省表示任何字符集都可以接受。

    Content-Type:具体请求中的数据类型;例如:Content-Type: application/x-www-form-urlencoded
    Content-Length:表示请求消息正文的长度。例如:Content-Length: 38

    3.3.3、HTTP 1.1之后是否进行持久连接?

    Connection: keep-alive 当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭,如果客户端再次访问这个服务器上的网页,会继续使用这一条已经建立的连接。HTTP 1.1默认进行持久连接。利用持久连接的优点,当加载多个图片时,显著地减少下载所需要的时间。
    Connection: close 代表一个Request 完成后,客户端和服务器之间用于传输HTTP数据的TCP连接会关闭,当客户端再次发送Request,需要重新建立TCP连接。

    3.3.4、分段下载与断点续传

    Range:bytes=start-end:可以请求实体的一个或者多个子范围,用于大文件的分段下载:

    • Range:bytes=0-499:表示前500个字节;
    • Range:bytes=500-999:表示第二个500字节;
    • Range:bytes=-500:表示最后500个字节;
    • Range:bytes=500-:表示500字节以后的范围;
    • Range:bytes=0-0,-1:第一个和最后一个字节;

    同时指定几个范围:Range:bytes=500-600,601-999
    服务器可以忽略此请求头,如果无条件GET包含Range请求头,响应会以状态码206PartialContent)返回而不是以200OK)。

    3.3.5、其它字段

    User-Agent:告诉服务器,客户端使用的操作系统和App的名称和版本。
    例如:User-Agent:objective-c-language/1.0 (iPhone; iOS 10.3.3; Scale/2.00)

    Cookie:最重要的请求头之一, 将客户端的cookie值发送给HTTP服务器。

    Authorization:授权信息,通常出现在对服务器发送的WWW-Authenticate头的应答中,用base64将用户名和密码编码,用于证明客户端是否有权查看某个资源。当客户端发起一个请求时,如果收到服务器的响应代码为401(未授权),可以发送一个包含Authorization请求报头域的请求,要求服务器对其进行验证。
    例如:Authorization:MTM4MDAwMDAwMDA6YTEyMzQ1Njc

    Referer:包含一个URL,用户从该URL代表的页面出发访问当前请求的页面。提供了Request的上下文信息的服务器,告诉服务器我是从哪个链接过来的,比如从我主页上链接到一个朋友那里,他的服务器就能够从HTTP Referer中统计出每天有多少用户点击我主页上的链接访问他的网站。
    例如:Referer:http://translate.google.cn/?hl=zh-cn&tab=wT

    3.4、常见的响应头
    3.4.1、缓存相关

    Expires:缓存文档的有效期;过期文档需要更新。过期之前使用本地缓存;HTTP1.1 的客户端和缓存会将非法的日期格式(包括0)看作已经过期。
    ETag:和If-None-Match 配合使用。
    Last-Modified:用于指示资源的最后修改日期和时间。

    3.4.2、响应的数据

    Content-Type:服务器告诉浏览器自己响应的对象的类型和字符集。

    ///Content-Type:大类/小类
    
    //通常显式指定为 text/html
    Content-Type:text/html;charset=utf-8
    Content-Type:text/html;charset=GB2312
    Content-Type:image/png
    Content-Type:message/http
    Content-Type:audio/mpeg
    Content-Type:video/quicktime
    Content-Type:multipart/form-data
    Content-Type:image/png
    Content-Type:application/vnd.ms-excel
    

    Content-Length:指明实体正文的长度,以字节方式存储的十进制数字来表示。在数据下行的过程中,Content-Length要预先在服务器中缓存所有数据,然后所有数据再一股脑儿地发给客户端。只有当客户端使用持久连接时才需要这个数据。
    例如: Content-Length: 19847

    Content-Encoding:服务器表明自己使用了什么压缩方法(gzip,deflate)压缩响应中的对象。只有在解压之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。
    Content-Language:服务器告诉客户端自己响应的对象所用的语言。例如:Content-Language:da。没有设置该字段则认为实体内容将提供给所有的语言阅读。

    3.4.3、分段下载与断点续传

    Content-Range:响应的资源范围。

    在连接断开重连时,客户端只请求该资源未下载的部分,而不是重新请求整个资源,来实现断点续传。

    3.4.4、其它字段

    Set-Cookie: 用于把cookie发送到客户端浏览器,每一个写入cookie都会生成一个Set-Cookie
    例如:Set-Cookie: sc=4c31523a; path=/; domain=.acookie.taobao.com

    P3P:用于跨域设置 Cookie, 这样可以解决 iframe跨域访问 cookie 的问题;
    Allow:服务器支持哪些请求方法(如GETPOST等);
    Date:表示消息发送的世界标准时间,如 Date:Mon,31Dec200104:25:57GMT
    Location:用于重定向一个新的位置,包含新的URL地址;表示客户应当到哪里去提取文档。Location通常不是直接设置的,而是用在更换域名的时候。
    WWW-Authenticate:该响应报头域必须被包含在401(未授权的)响应消息中,客户端收到401响应消息时候,并发送Authorization报头域请求服务器对其进行验证时,服务端响应报头就包含该报头域。

    //可以看出服务器对请求资源采用的是基本验证机制。
    WWW-Authenticate:Basic MTM4MDAwMDAwMDA6YTEyMzQ1Njc
    

    参考文章:

    HTTP协议详解
    HTTPS 与 SSL 证书概要
    HTTPS协议
    Https原理及流程
    HTTPS安全通信过程
    客户端认证https服务端证书过程:证书链

    相关文章

      网友评论

          本文标题:HTTP协议与HTTPS协议

          本文链接:https://www.haomeiwen.com/subject/oyminftx.html