计算机网络之HTTP/HTTPS
一、HTTP
1. 基础知识
- 概念:超文本传输协议(HyperText Transfer Protocol)是一种用于分布式、协作式和超媒体信息系统的应用层协议,是因特网上应用最为广泛的一种网络传输协议,所有的WWW文件都必须遵守这个标准。HTTP是为Web浏览器与Web服务器之间的通信而设计的,偶尔也可以用作他用。
- 特点:
- HTTP是无状态的,无状态是指协议对于事务处理没有记忆能力,这意味着如果后续处理需要前面的信息,则它必须重传。
- 默认的访问端口号为80。
- 基于TCP/IP通信协议来传递数据。
2. 请求方法
HTTP请求方法表明了要对给定资源执行的操作,每一个请求方法都实现了不同的语义。包括:GET、HEAD、POST、PUT、PATCH、DELETE、OPTIONS,以及不常用的 CONNECT、TRACE。在此,我们只介绍最常用的GET和POST。
方面 | GET | POST |
---|---|---|
功能 | 获取服务器的指定数据 | 添加或者修改服务器的指定数据 |
幂等性 | 幂等,不会改变服务器上的资源 | 非幂等,会改变服务上的资源 |
参数位置 | 通产暴露在明文连接中 | 通常放在请求体中 |
参数大小 | 2KB以内 | 无限制 |
3. 报文格式
3.1 请求报文
基本格式:
- 请求行:格式为==>请求方式 请求URI 请求协议/版本,比如:POST /day07/login.html HTTP/1.1
- 请求头:格式为==>请求头名称:请求信息,包含了客户端需要告诉服务端的信息,常用的请求头如下
- User-Agent:浏览器告诉服务器,我访问你使用的浏览器版本信息。
- Referer:告诉服务器当前请求的来源,常用做防盗链和统计工作。
- 请求空行:格式就是一个空行,用于分隔POST请求的请求头和请求体。
- 请求体(正文):封装POST请求消息的请求参数。
举例
POST /day07/login.html HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36 Edg/92.0.902.55
Referer: http://localhost:8080/day07/login.html
Connection: keep-alive
Upgrade-Insecure-Requests: 1
username=zhangsan
3.2 响应报文
基本格式
- 响应行:格式==>协议/版本 响应状态码 状态码描述
- 响应头:格式==>响应头名称:响应头值,包含了服务端需要告诉客户端的信息,常用的响应头如下
- Content-Type:服务器告诉客户端本次响应体数据格式以及编码格式。
- Content-disposition:服务器告诉客户端以什么格式打开响应体数据。
- 响应空行:格式就是空行,用于分隔响应头和响应体。
- 响应体(正文):用于存放需要响应给客户端的数据。
举例
HTTP/1.1 200 OK
Content-Length: 101
Content-Type: text/html;charset=UTF-8
Date: Wed, 28 Jul 2021 07:05:37 GMT
<html>
<head>
<title>$Title$</title>
</head>
<body>
hello,response
</body>
</html>
3.3 附加:常用状态码
- 1xx:服务器接收客户端消息,但没有接收完成,等待一段时间后,发送1xx状态码
- 2xx:成功,代表:200
- 3xx:重定向,代表:301(永久重定向)、302(临时重定向)、304(访问缓存)
- 4xx:客户端错误,代表:400(请求报文中出现语法或参数错误)、401(未认证即未登录)、402(无权限)、404(请求路径没有对应的资源)、405(请求方式没有对应的doXxx方法)
- 5xx:服务器端错误,代表:500(服务器内部出现异常)、502(网关错误)、503(服务器无法处理请求)
3.4 不同版本HTTP的区别
3.4.1 HTTP1.0
- 默认使用短连接,即浏览器每请求一个静态资源,就建立一次连接,任务结束就中断连接。
3.4.2 HTTP1.1
- 默认使用长连接,即在一个网页打开期间,多条网络请求都复用同一条已经建立的连接。
- 注意:HTTP1.x存在顺序约束即服务端必须按照客户端请求到来的顺序,串行返回数据;HTTP1.x存在阻塞约束,即浏览器会限制每个域名下最多同时发起的 6 个连接,超过该数量的连接会被阻塞。
3.4.3 HTTP2.0
- Header压缩:HTTP/1.1每次通信都会携带Header信息用于描述资源属性。但Headers在一系列请求中常常是相似的。HTTP/2.0中,对于Header中相同的数据,不会在每次通信中重新发送,而是采用追加或替换的方式。具体实现上,HTTP/2.0在客户端和服务端之间共同维护一个Header表,存储之前发送的key-value对。Header表在HTTP/2.0 的连接期间始终存在。Header压缩可以减少每次通信的数据量,提高传输速度。
- 服务端推送:服务器可以对一个客户端请求发送多个响应。服务器向客户端推送资源无需客户端明确的请求。服务端根据客户端的请求,提前推送额外的资源给客户端。比如在发送页面HTML时主动推送其它CSS/JS资源,而不用等到浏览器解析到相应位置,发起请求再响应。服务端推送可以减轻数据传输的冗余步骤,同时加快页面响应速度,提升用户体验。
- 多路复用:HTTP/2.0将所有传输信息分割为若干个帧,采用二进制格式进行编码。通过同一个连接发起多个请求,可以并行地传输数据。它基于二进制分帧层,同时交错发送多个消息中的帧,接收端可以根据帧中的流标识符和顺序标识,重新组装数据。多路复用代替了HTTP/1.x中的顺序和阻塞机制,实现了真正的并行传输,可以避免 HTTP/1.x中的队头阻塞问题,极大的提高传输效率。
3.5 Cookie和Session
3.5.1 Cookie
基本概念
- Cookie是客户端会话技术,将数据保存到客户端。
特点
- Cookie将数据存储在客户端浏览器,不太安全,容易丢失。
- 浏览器对于单个Cookie的大小(一般是4kb)和同一域名下的总Cookie数量也有限制(一般是20个)。
如何实现数据共享?
- 首先,浏览器客户端向服务器发送请求时,服务器创建了响应的Cookie对象并绑定数据。
- 随后,在服务器响应客户端时,将此Cookie对象返回给浏览器客户端。
- 之后,在下次浏览器向服务器发送请求时,携带此Cookie对象去请求服务器,服务器接收Cookie对象即可,如此往复循环。
实现原理
- 根据Http协议,如果客户端收到的响应头中包含set-cookie,那么,客户端会自动地将set-cookie携带的数据保存到客户端。
- 当再次发送请求时,客户端会在请求头中加一个cookie请求头,将上次保存的数据携带过去,一起传递给服务端。
3.5.2 Session
基本概念
- Session是服务器端会话技术,将数据保存在服务器端的对象HttpSession中。
特点
- Session用于存储一次会话的多次请求的数据,存在服务器端。
- Session可以存储任意类型,任意大小的数据。
如何实现数据共享?
- 当客户端第一次发送请求,我们在服务端创建了一个HttpSession,此时如果没有Cookie,服务器会自动创建一个Cookie,以键值对
JSESSIONID=id
的形式存储了代表此HttpSession的唯一id。 - 当客户端再次访问服务器时,会携带着带有HttpSession的id的Cookie一起访问,此时服务器就可以通过Cookie来确定同一个HttpSession进行数据共享。
实现原理
- Session是依赖于Cookie的。
3.6 转发和重定向
3.6.1 转发
基本概念
- 转发是一种服务器内部的资源跳转方式。
特点
- 浏览器地址栏路径不发生变化
- 只能转发到当前服务器内部资源中
- 只有一次请求,可以使用request域对象来共享数据
步骤
3.6.2 重定向
基本概念
- 重定向是实现资源跳转的一种方式,要跳转的资源可以在服务器的内部,也可以在服务器的外部。
特点
- 地址栏发生变化。
- 重定向可以访问其他站点(服务器)的资源。
- 有两次请求,不可以使用request域对象来共享数据。
步骤
二、HTTPS
1. 基础知识
- 基本概念:HTTPS协议(Hyper Text Transfer Protocol Secure),是HTTP的加强安全版本。HTTPS是基于HTTP的,并额外使用SSL/TLS协议用作加密和安全认证。
- 特点
- 默认端口号为443。
- 使用TCP/IP作为底层协议。
2. SSL的工作原理
2.1 非对称加密
- 非对称加密采用两个密钥:一个公钥,一个私钥。在通信时,私钥仅由解密者保存,公钥由任何一个想与解密者通信的发送者(加密者)所知。
- 非对称加密的公钥和私钥的生成算法采用的是单向陷门函数。
2.2 对称加密
- 使用SSL/TLS进行通信的双方需要使用非对称加密方案来通信,但是非对称加密设计了较为复杂的数学算法,在实际通信过程中,计算的代价较高,效率太低,因此,SSL/TLS实际对消息的加密使用的是对称加密。
- 对称加密就是通信双方共享唯一密钥k,加解密算法已知,加密方利用密钥k加密,解密方利用密钥k解密。对称加密的密钥生成代价比公私钥对的生成代价低得多,但是对称加密的保密性完全依赖于密钥的保密性。
2.3 对对称加密的密钥进行非对称加密
- 在双方通信之前,需要商量一个用于对称加密的密钥。我们知道网络通信的信道是不安全的,传输报文对任何人是可见的,密钥的交换肯定不能直接在网络信道中传输。因此,使用非对称加密,对对称加密的密钥进行加密,保护该密钥不在网络信道中被窃听。这样,通信双方只需要一次非对称加密,交换对称加密的密钥,在之后的信息通信中,使用绝对安全的密钥,对信息进行对称加密,即可保证传输消息的保密性。
2.4 CA证书认证
- 如果有一个黑客C也给客户端A发送了一个自己的公钥,而客户端A不知道公钥的正确性,用了C的公钥加密发送,这样一来,信息被C截取的话,信息就会泄露,所以我们需要一个数字证书,来验明服务器的身份。
- CA默认是受信任的第三方。CA会给各个服务器颁发证书,证书存储在服务器上,并附有CA的电子签名。当客户端(浏览器)向服务器发送HTTPS请求时,一定要先获取目标服务器的证书,并根据证书上的信息,检验证书的合法性。一旦客户端检测到证书非法,就会发生错误。客户端获取了服务器的证书后,由于证书的信任性是由第三方信赖机构认证的,而证书上又包含着服务器的公钥信息,客户端就可以放心的信任证书上的公钥就是目标服务器的公钥。
3. SSL的工作流程
首先是使用非对称加密来传输在这次会话过程中生成的用于生成对称加密的密钥(pre-master key),结合明文传输的随机数和算法生成对称加密的密钥之后再使用对称加密进行通信。
3.1 简化版
- 客户端发送的hello包中会告诉服务端自己的一些当前信息。
- 服务端响应hello包,告诉客户端服务端选中的加密算法,同时,服务端还会客户端发送证书(证书中包含非对称密钥的公钥,私钥在服务器手中)。
- 客户端对证书进行验证。
- 验证通过后,浏览器和服务端通过密钥交换算法产生共享的对称密钥。
- 开始传输数据,使用同一个对称密钥来加解密。
3.2 详细版
- 首先由客户端发送Client Hello消息到服务器,消息中主要包含了客户端支持的加密算法,TLS版本信息和客户端随机数,注意此时是明文传输。
- 服务器接收到消息后,返回自己支持的加密算法,TLS 版本,自己的数字证书和服务器端生成的随机数,注意此时是明文传输。
- 客户端开始验证数字证书,验证完证书之后生成一个新的
pre-master key
,再使用证书中的公钥来对pre-master key
进行加密,然后发送给服务器,注意此时是非对称加密传输。 - 服务器接收到客户端发送过来的非对称加密的密文,使用自己的私钥进行解密,获得了
pre-master key
,注意此时是非对称加密传输。 - 到这里为止,服务器和客户端都有三组数字,分别是客户端的随机数、服务器的随机数和
pre-master key
。其中由于客户端的随机数和服务器的随机数都是使用明文传输,所以这两个数字是有被暴露的风险的,但是由于pre-master key是使用非对称加密传输,十分安全,所以将这三者结合,使用之前协商好的特定的算法就可以生成一个密钥,这个密钥称为shared secert
,也就是之后用来对称加密的密钥。 - 客户端在计算出对称加密的密钥之后,使用该密钥进行对称加密通信,告知服务器之后都使用该密钥进行对称加密,注意此时是对称加密传输。
- 服务器接收到密文后,使用之前计算出的密钥来进行对称解密,解密成功之后,再使用该密钥进行对称加密通信,告知客户端密钥确认无误,可以使用该密钥进行通信,注意此时是对称加密传输。
- 至此,整个TLS的握手过程完整,之后就可以开始对称加密的通信了。
三、总结:HTTP和HTTPS的区别
- HTTP是明文传输容易被黑客窃听或篡改,不安全。HTTPS主要解决了HTTP明文协议的缺陷,在HTTP的基础上加上了SSL/TSL协议,依靠SSL证书来验证服务器的身份,为客户端和服务器之间建立SSL通道,确保数据传输安全。
- HTTP使用端口80,HTTPS使用端口443
- HTTPS协议需要到CA机构申请证书,一般需要一定的费用
- HTTP运行在TCP协议之上,HTTPS运行在SSL协议之上,SSL运行在TCP协议之上