您的位置: 首页  >  文章  >  HTTP与HTTPS协议

HTTP与HTTPS协议

分类: 文章 • 2023-03-21 13:55:39

HTTP协议概述（超文本传输协议）

  1. HTTP协议的主要特点可概括如下：
  1. 客户/服务器模式，基于请求与响应模式；
  2. 简单快速： 客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
  3. 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
  4. 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
(——keep alive产生由来，Keep-Alive 功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive 功能避免了建立或者重新建立连接)
  1. 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。（——cookie与session的产生由来，为了解决此问题）
  1. HTTP协议详解之URL篇
    http（超文本传输协议）是一个基于请求与响应模式的、无连接的、无状态的、应用层的协议，常基于TCP的连接方式，HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。
HTTP URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下：
http://host[":"port][abs_path]
  • http表示要通过HTTP协议来定位网络资源；
  • host表示合法的Internet主机域名或者IP地址；
  • port指定一个端口号，为空则使用缺省端口80；
  • abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI时，必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。
eg:
  1. 输入：www.guet.edu.cn，浏览器自动转换成：http://www.guet.edu.cn/
  2. http:192.168.0.116:8080/index.jsp 
  1. HTTP协议详解之请求篇（request）
http请求由四部分组成，分别是：请求行、请求头部、空行、请求数据
HTTP与HTTPS协议
  1. Get请求例子，使用Charles抓取的request：
GET /562f25980001b1b106000338.jpg HTTP/1.1
Host    img.mukewang.com
User-Agent    Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept    image/webp,image/*,*/*;q=0.8
Referer    http://www.imooc.com/
Accept-Encoding    gzip, deflate, sdch
Accept-Language    zh-CN,zh;q=0.8
  1. 第一部分：请求行，用来说明请求类型,要访问的资源以及所使用的HTTP版本.
请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：
Method Request-URI HTTP-Version CRLF
  • Method表示请求方法；
  • Request-URI是一个统一资源标识符；
  • HTTP-Version表示请求的HTTP协议版本；
  • CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。
上述例子中，GET说明请求类型为GET,[/562f25980001b1b106000338.jpg]为要访问的资源，该行的最后一部分说明使用的是HTTP1.1版本。
  1. 第二部分：请求头部，紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息
从第二行起为请求头部，HOST将指出请求的目的地.User-Agent,服务器端和客户端脚本都能访问它,它是浏览器类型检测逻辑的重要基础.该信息由你的浏览器来定义,并且在每个请求中自动发送等等
  1. 第三部分：空行，请求头部后面的空行是必须的
即使第四部分的请求数据为空，也必须有空行。
  1. 请求数据也叫主体，可以添加任意的其他数据。
这个例子的请求数据为空。
 
  1. POST请求例子，使用Charles抓取的request：
POST / HTTP1.1
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive
name=Professional%20Ajax&publisher=Wiley
第一部分：请求行，第一行明了是post请求，以及http1.1版本。
第二部分：请求头部，第二行至第六行。
第三部分：空行，第七行的空行。
第四部分：请求数据，第八行。
  1. HTTP协议详解之响应篇
在接收和解释请求消息后，服务器返回一个HTTP响应消息。HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文：
HTTP与HTTPS协议
  1. 第一部分：状态行，由HTTP协议版本号， 状态码， 状态消息 三部分组成。
状态行格式如下：
HTTP-Version Status-Code Reason-Phrase CRLF
  • HTTP-Version表示服务器HTTP协议的版本；
  • Status-Code表示服务器发回的响应状态代码；
  • Reason-Phrase表示状态代码的文本描述。
（上述例子中，第一行为状态行，（HTTP/1.1）表明HTTP版本为1.1版本，状态码为200，状态消息为（ok））
补充：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  //服务器当前不能处理客户端的请求，一段时间后可能恢复正常
eg：HTTP/1.1 200 OK （CRLF）
 
  1. 第二部分：消息报头，用来说明客户端要使用的一些附加信息
第二行和第三行为消息报头，
Date:生成响应的日期和时间；
Content-Type:指定了MIME类型的HTML(text/html),编码类型是UTF-8
  1. 第三部分：空行，消息报头后面的空行是必须的
  2. 第四部分：响应正文，服务器返回给客户端的文本信息。
空行后面的html部分为响应正文。
  1. HTTP基本原理与机制
  1. HTTP请求与响应机制
HTTP与HTTPS协议
HTTP协议用于客户端与服务器之间的通信，在通信线路两端，必定一端是客户端，另一端是服务器。客户端与服务器的角色不是固定的，一端充当客户端，也可能在某次请求中充当服务器。这取决与请求的发起端。
HTTP协议属于应用层，建立在传输层协议TCP之上。客户端通过与服务器建立TCP连接，之后发送HTTP请求与接收HTTP响应都是通过访问Socket接口来调用TCP协议实现
HTTP与HTTPS协议
如图，反映了一次HTTP请求并接收一个HTML文件的过程与时间消耗(RTT)。客户端通过TCP连接发送请求报文，服务器收到请求后向其传输文件并返回响应报文。
2.  HTTP 请求/响应的步骤
1） 客户端连接到Web服务器
一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.oakcms.cn。
2） 发送HTTP请求
通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。
3） 服务器接受请求并返回HTTP响应
Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。
4） 释放连接TCP连接
若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;
5） 客户端浏览器解析HTML内容
客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。
例如：在浏览器地址栏键入URL，按下回车之后会经历以下流程：
1、浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;
2、解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接;
3、浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;
4、服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器;
5、释放 TCP连接;
6、浏览器将该 html 文本并显示内容;











HTTPS概述（安全的超文本传输协议）

  1. HTTP的缺点
  1. 通信过程使用明文（不加密），内容可能会被窃听。（使用抓包工具可以抓取到请求和响应数据）
HTTP与HTTPS协议
  1. 无法保证报文的完整性，途中可被攻击者窃取并篡改内容。篡改后，对于客户端和服务器间的通信看上去一切正常。
HTTP与HTTPS协议
  1. 不验证通讯方的身份，可能遭遇伪装。（服务器对请求者来者不拒，任何人都能请求，不管对方是谁都会返回响应）
HTTP与HTTPS协议
  1. 什么是HTTPS
  1. HTTP+加密+数据完整性保护+认证=HTTPS
  2. HTTP+SSL=HTTPS （在TCP与HTTP之间多了一层SSL/TSL协议）
  1. 对称加密&非对称加密
  1. 对称加密
加密和解密使用相同**的加密算法，称为对称加密。
  1. 非对称加密
加密和解密使用不同**的加密算法，称为非对称加密。非对称加密需要2个**（一对）：公钥、私钥（公钥为对外公开的**，所有人都可以获取到；私钥不对外公开，只有持有者知道）。使用公钥加密，只能使用私钥解密，反之亦然。
  1. HTTPS采用混合加密机制（对称+非对称）
HTTPS的通信过程使用对称加密技术（优点：比非对称加密处理速度快），而使用非对称加密技术用于交换通信过程使用的对称**Master secret。
（使用非对称加密技术传输对称**，保证对称**安全，从而保证对称加密通信的安全性）
HTTP与HTTPS协议
  1. 数字签名&数字证书
  1. 数字签名
为了证明发送者的身份，以及确保信息是完整的、未被篡改过的，应用了“数字签名”技术（摘要算法+非对称加密技术）：
它将消息使用hash算法生成一个摘要值A，并用发送者的私钥对摘要值A加密形成发送者的“数字签名”，然后与消息原文一起传送给接收者。接收者只有用发送者的公钥才能解密此“数字签名”，从而验证发送者的身份。接受者将“签名”解密后，获得原文的摘要值A，然后对原文同样使用hash算法生成一个摘要值B，将摘要值B与A进行比对，若相同，则说明收到的信息是完整的，在传输过程中未被篡改过，否则说明信息被篡改过。因此“数字签名”可验证信息的完整性。
  1. “数字签名”过程如下：
发送者：消息明文-->hash运算-->摘要值A-->私钥加密-->数字签名
（数字签名+消息原文-->接受者）
接受者：数字签名-->发送者公钥解密-->摘要值A
              消息原文-->hash运算-->摘要值B
              摘要值A<--对比-->摘要值B
  1. “数字签名”的作用：
  1. 证明发送方的身份，确定是否由发送方签名并发出来的，因为别人假冒不了发送方的签名；
  2. 确保消息的完整性；
  1. 数字证书
  1. 为什么有数字证书？
因为接受者无法确认手上的公钥是否真的是发送者的公钥，如果被人替换为第三者的公钥，则第三者可以冒充发送者与你建立通信，而你不知情。因此，数字证书产生，以第三方认证机构（CA）颁发给发送者的证书，以认证证书来证明发送者的真实身份，只要发送者传输消息时带上证书就好了，别人无法冒充。
  1. 数字证书颁发过程
用户首先产生自己的**对，将公钥及个人信息发送给第三方认证机构（CA），CA经过一些必要操作对用户身份进行核实，核实后将给用户签发数字证书。数字证书组成包括：用户个人信息及用户公钥+CA的数字签名。
  1. 客户端验证服务端证书有效性
客户端拿到服务器的数字证书后，首先使用CA的公钥（浏览器会默认内置CA根证书公钥，可对CA及其子机构颁发的证书签名进行解密）对签名解密，得到以下几种结果：
  1. CA机构名称不存在或伪造：浏览器不认识，直接认为是危险证书；
  2. CA机构名称存在，但无法解密CA签名，认为是危险证书；
  3. 可对CA签名解密，解密后的摘要值A与客户端计算的摘要值B不相等，说明证书信息被篡改，认为是危险证书
  4. 可对CA签名解密，解密后的摘要值A与客户端计算的摘要值B相等，说明证书是有效的且证书信息完整，客户端直接获取证书内服务端的公钥，从而保证公钥确实是服务端的不是别人的，以此来验证服务器身份，确保与服务端的安全通信；
  5. 证书过期失效验证；
  1. HTTPS握手与协商过程（SSL/TSL握手过程）
HTTP与HTTPS协议
  1. 【客户端】client hello
客户端发起请求，以明文传输请求信息，包含信息如下：
  1. 支持的SSL/TSL协议版本：从低到高依次 SSLv2、SSLv3、TLSv1(SSLv3.1)、TLSv1.1(SSLv3.2)、TLSv1.2 (SSLv3.3)
  2. 支持的加密算法列表：客户端支持的加密套件列表，每个套件对应TSL原理中的四个功能：认证算法 Au (身份验证)、**交换算法 KeyExchange(**协商)、对称加密算法 Enc (信息加密)、信息摘要 Mac(完整性校验);
  3. 支持的压缩算法列表：用于后续的信息压缩传输；
  4. 随机数random_C：用于后续的**生成；
  5. 扩展字段：支持协议与算法的相关参数以及其他辅助信息等；
  1. 【服务端】server_hello+server_certificate+server_hello_done
  1. server_hello：服务端返回协商结果，包含选择使用的协议版本、选择的加密算法、选择的压缩算法、随机数random_S等（其中随机数random_S用于后续**的生成）
  2. server_certificate：服务端发送证书，用于身份验证与**交换；
  3. server_hello_done：通知客户端server_hello信息发送结束；
  1. 【客户端】证书校验
客户端校验证书的合法性、有效性，只有验证通过才能进行后续通信；
  1. 【客户端】Client_key_exchange+change_cipher_spec+encrypted_handshake_message
  1. client_key_exchange：服务端证书验证通过后，客户端产生随机数Pre-master，并用证书中的公钥加密，发送给服务器；
此时，客户端已经获取全部的计算协商**需要的信息：random_C、random_S、Pre-master，计算得到协商**Master secret：
Master secret=Fuc(random_C, random_S, Pre-Master)
  1. change_cipher_spec：客户端通知服务器后续的通信采用协商**Master secret和之前协商好的加密算法进行加密通信；
  2. encrypted_handshake_message：结合之前通信参数的hash值与其他相关信息，用协商**Master secret与加密算法进行加密，并发送给服务器，用于数据与握手验证；
  1. 【服务端】change_cipher_spec+encrypted_handshake_message
  1. 服务器用私钥解密加密的Pre-master，基于之前交换的两个明文随机数random_C和random_S（服务器有保留数据），计算得到协商**Master secret：
Master secret=Fuc(random_C, random_S, Pre-Master)
  1. 服务器计算之前所有通信信息的 hash 值，然后用Master secret解密客户端发送的encrypted_handshake_message，验证客户端发送的数据和**正确性;
  2. change_cipher_spec：验证通过后，服务器同样发送change_cipher_spec已告知客户端后续通信都采用协商**与算法进行加密通信；
  3. encrypted_handshake_message：服务器同样结合之前通信参数的hash值与其他相关信息，用协商**Master secret与加密算法进行加密，并发送给客户端；
  4. 握手结束：客户端计算之前所有通信信息的 hash 值，然后用Master secret解密服务器发送的encrypted_handshake_message，验证服务器发送的数据和**，验证通过则握手完成;
  1. 建立加密通信：开始使用协商**Master secret与对称加密算法进行加密通信
  2. HTTP与HTTPS协议
  3. HTTP与HTTPS协议
  4. 其他说明
  1. HTTPS的缺点
HTTPS比HTTP通信速度慢2—100倍，通信慢+资源消耗导致处理速度慢：
  1. 通信慢：和HTTP相比，SSL/TSL通信部分消耗网络资源。而SSL/TSL通信部分，又因为要对通信进行处理，所以时间上又延长了；
  2. 资源消耗导致处理速度慢：由于HTTPS还需要做服务器、客户端双方加密及解密处理，因此会消耗CPU和内存等硬件资源；
  1. Pre-master加密传输的作用
SSL/TSL握手过程中总共会产生3个随机数：random_C、random_S、Pre-master，这3个随机数用于生成今后加密通信的**Master secret；而其中random_C和random_S为明文传输，存在可能被窃取的风险，因此Master secret是否安全取决于Pre-master传输是否安全，这里使用非对称加密传输Pre-master，保证了Pre-master的安全性，从而保证Master secret的安全性，进而保证了HTTPS的通信安全。
  1. Master secret说明
Master secret是由系列的hash值组成的，结构如下：
HTTP与HTTPS协议
其中，Client/Server write MAC key 是用来对数据进行验证的，Client/Server write encryption Key 是用来对数据进行加解密的会话**(session secret)。
应用数据传输：在所有的握手阶段都完成之后，就可以开始传送应用数据了。应用数据在传输之前，首先要附加上MAC secret，然后再对这个数据包使用write encryption key进行加密。在服务端收到密文之后，使用Client write encryption key进行解密，客户端收到服务端的数据之后使用Server write encryption key进行解密，然后使用各自的write MAC key对数据的完整性包括是否被串改进行验证。

相关推荐