阿里云 网站接入方式,国外网站建设素材库,英语培训机构网站建设策划书,网站建设需要在网络上如何实现1. Http
1.1 Http的定义
超文本传输协议#xff08;Hypertext Transfer Protocol#xff0c;HTTP#xff09;是用于分布式、协作式和超媒体信息系统的应用层协议。它是互联网上最广泛应用的数据通信协议之一#xff0c;尤其对于万维网#xff08;WWW#xff09;服务而言…1. Http
1.1 Http的定义
超文本传输协议Hypertext Transfer ProtocolHTTP是用于分布式、协作式和超媒体信息系统的应用层协议。它是互联网上最广泛应用的数据通信协议之一尤其对于万维网WWW服务而言是至关重要的基础。HTTP协议定义了客户端如网页浏览器和服务器之间的通信格式和交互方式。
1.2 Http协议的特点
请求/响应模型 HTTP采用客户端发起请求服务器返回响应的模式进行工作。客户端通过发送一个HTTP请求来获取或提交网页资源服务器根据请求内容生成相应的HTTP响应并回送给客户端。 无状态性 HTTP协议本身是无状态的这意味着每次请求都是独立处理服务器不保留客户端请求之间的任何上下文信息。后来引入的Cookie和Session机制弥补了这一特性带来的问题允许在多次请求间维持状态信息。 基于TCP/IP HTTP通常运行在TCP/IP协议栈的应用层之上默认使用TCP端口80进行通信。HTTPS安全HTTP则使用SSL/TLS加密在默认情况下运行在TCP端口443上。 消息结构 HTTP消息包括请求消息和响应消息它们由起始行、头部headers、空行和可选的消息主体组成。起始行定义了操作方法GET、POST等和目标资源的URI头部包含了若干属性值对描述了请求或响应的附加信息消息主体承载了实际要传输的数据内容如HTML文档、图片或其他类型的数据。 版本演化 HTTP协议经历了多个版本的发展例如HTTP/1.0、HTTP/1.1、HTTP/2和HTTP/3每个新版本都在性能、效率、安全性等方面有所改进。
1.3 Http协议的缺点
明文运输 导致可能会被窃听 不验证报文的完整性 导致可能会被篡改 无法验证上方的身份 可能会出现伪装攻击
1.3.1 如何解决“明文传输”
可以使用对称加密即加密和解密使用的是同一密钥S。但是如何把密钥交到对方手上就是一个很大的问题。
为了解决对称加密中的密钥分发难题数学家们设计出了非对称加密体系。非对称加密算法的核心特点是采用一对密钥一个是公开的公钥另一个是私密的私钥。这两把密钥不是互相解密的关系而是具有特定的匹配性用公钥加密的数据只能通过对应的私钥解密私钥加密的可以用公钥进行解密。 设想场景是这样的假设A作为客户端B作为服务端。首先A和B各自生成一对非对称密钥即公钥和私钥并将各自的公钥安全地发布在网络上使得任何人都能获取到A的公钥A_pub和B的公钥B_pub。
当A需要向B发送加密信息时A会使用从网络上获取到的B的公钥B_pub来加密要发送的信息。这样一来即便信息在互联网上传输的过程中被第三方截获由于只有B持有的私钥B_priv能够解密这条信息所以他人无法解读和篡改其中的内容。
最后当B接收到经由其公钥加密的密文后只需使用自己的私钥B_priv对其进行解密从而确保了通信的保密性和完整性。通过这种方法非对称加密算法有效地解决了在开放网络环境下安全传输密钥的问题保障了数据在传输过程中的安全。
存在的问题
如果有一个中间人M在客户端和服务端获取对方公钥的时候用自己的公钥M进行了替换。那么中间人不仅可以解析消息还可以篡改消息。因为客户端A所认为的公钥B其实是公钥M服务端认为的公钥A其实也是公钥M。这就涉及到了一个问题如何验证接收到的公钥是你要的公钥。
1.3.2 利用数字证书
因为服务端的公钥无法在客户端证明确实是来自于服务端的所以需要找一个第三方机构来做公证证明这个公钥确实是来自于服务端的。那怎么做公证呢 服务端去证书授权中心申请证书服务端会把自己的网站信息以及服务端公钥给到证书授权中心那边而证书授权中心会根据这些生成一张由网站信息、证书信息、证书授权中心的数字签名以及服务端公钥等组成的证书。这里需要注意的是网站信息、证书信息、服务端公钥等信息在证书中都是以明文形式保存的。
新的问题来了
如何保证这些明文没有被篡改过 我们可以计算一个对应的消息摘要值当明文被修改后消息摘要值就对不上了 又有小朋友会问那我如果修改明文后重新计算了消息摘要值并替换呢 那这个时候就需要对这个摘要利用CA的私钥进行数字签名如果想要生成一个对应的数字签名就需要CA的私钥很明显中间者无法获得。当客户端收到后就可以利用消息摘要数字签名CA的公钥进行验证中间值修改消息后即使生成新的消息摘要和数字签名也无法和CA的公钥进行匹配 新的问题又出现了CA的公钥如何获得呢 CA机构的公钥是预装在操作系统中的就这解决了公钥的来源问题。
代码如下
# 导入rsa库
import rsa
# RSA密钥对生成
(public_key, private_key) rsa.newkeys(2048) # 生成2048位密钥对
# RSA加密
message bThis is a secret message
cipher_text rsa.encrypt(message, public_key)
# RSA解密
decrypted_message rsa.decrypt(cipher_text, private_key)
# RSA数字签名
message_hash rsa.compute_hash(message, SHA-256) # 计算消息摘要
signature rsa.sign(message_hash, private_key, SHA-256)
# 验证签名
is_signature_valid rsa.verify(message_hash, signature, public_key)
if is_signature_valid:print(验证签名有效)
else:print(中途被修改啦)2.Https
HTTPS全称为Hypertext Transfer Protocol Secure是一种网络安全协议设计用于在互联网上提供安全的通信和数据传输。它是在标准HTTP协议的基础上添加了一层安全措施具体来说就是整合了SSLSecure Sockets Layer或其后续版本TLSTransport Layer Security协议以实现数据加密、服务器身份验证以及消息完整性校验等功能。
当浏览器和服务器通过HTTPS连接时它们会先执行握手过程来协商加密算法和交换公钥等信息从而建立一个安全的连接通道。所有在HTTPS连接上传输的数据都会经过加密处理这确保了敏感信息如密码、信用卡号和个人信息在网络中传输时不会被窃听或篡改。
此外HTTPS还提供了服务器身份认证功能通过证书颁发机构签发的SSL证书客户端如浏览器可以验证服务器的真实身份防止中间人攻击和仿冒网站。
总结来说HTTPS的主要特点包括
数据加密使用对称加密和非对称加密相结合的方式来加密客户端和服务端之间的通信内容。 身份验证服务器通过SSL/TLS证书向客户端证明其真实身份。 保证数据完整性通过消息认证码MAC来防止数据在传输过程中被篡改。 默认使用端口号443而非HTTP的80端口。
2.1 为什么Https还有对称加密
因为非对称加密需要对信息进行加解密这其中是非常耗时的对称加密算法比非对称加密算法快大约1500倍所以HTTPS在通过非对称加密进行身份验证完毕后后续通信会通过对称加密来进行我们来看看是怎么实现的。
2.2 Https单向认证 客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。服务端给客户端返回服务端申请的证书包含服务端公钥B、数字签名、SSL协议版本号、加密算法种类、随机数等信息。客户端拿到服务端返回的证书验证服务端的合法性包括 证书是否过期该CA机构是否可靠返回的公钥是否能正确解开返回证书中的数字签名服务器证书上的域名是否和服务器的实际域名相匹配 验证通过后将继续进行通信否则终止通信 客户端向服务端发送自己所能支持的对称加密方案供服务端进行选择。服务端在客户端提供的加密方案中选择加密程度最高的加密方式。服务端将选择好的加密方案通过明文方式返回给客户端。客户端接收到服务端返回的加密方式后使用该加密方式生成产生随机码用作通信过程中对称加密密钥使用服务端返回的公钥B进行加密将加密后的随机码发送至服务端。服务端收到客户端返回的加密信息后使用自己的私钥B进行解密获取对称加密密钥。 在接下来的会话中服务端和客户端将会使用该对称加密密钥进行对称加密保证通信过程中信息的安全。
2.3 Https双向认证 客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。服务端给客户端返回服务端申请的证书包含服务端公钥B、数字签名、SSL协议版本号、加密算法种类、随机数等信息。客户端拿到服务端返回的证书验证服务端的合法性包括 证书是否过期该CA机构是否可靠返回的公钥是否能正确解开返回证书中的数字签名服务器证书上的域名是否和服务器的实际域名相匹配 验证通过后将继续进行通信否则终止通信 服务端要求客户端发送客户端的证书客户端会将自己的证书发送至服务端。服务端验证客户端的证书通过验证后获得客户端公钥A。客户端向服务端发送自己所能支持的对称加密方案供服务端进行选择。服务端在客户端提供的加密方案中选择加密程度最高的加密方式。服务端将选择好的加密方案通过客户端公钥A加密后返回给客户端。客户端接收到服务端返回的信息后通过客户端私钥A解密获取到对称加密方式后使用该加密方式生成产生随机码用作通信过程中对称加密密钥使用服务端返回的公钥B进行加密将加密后的随机码发送至服务端。服务端收到客户端返回的加密信息后使用自己的私钥B进行解密获取对称加密密钥。 在接下来的会话中服务端和客户端将会使用该对称加密密钥进行对称加密保证通信过程中信息的安全。 使用单向认证还是双向认证是由服务端来决定的默认单向
3.Http各个版本
3.1 Http/0.9
HTTP/0.9 是超文本传输协议Hypertext Transfer ProtocolHTTP的第一个正式版本。这个早期版本于1991年随着万维网World Wide Web的诞生而出现由蒂姆·伯纳斯-李Tim Berners-Lee设计。 特点
请求方式简单 只支持GET请求方法。请求行中只包含要获取的资源文件名不包含版本号、主机名或任何其他HTTP头信息。 响应格式简单 服务器回应的内容直接跟在换行符后面没有状态行、响应头或者空行只有纯文本或HTML内容 无错误代码反馈 如果请求失败服务器无法通过HTTP协议返回特定的错误代码只能关闭连接 不支持持久连接 每个请求与响应都对应一个新的TCP连接连接在每次传输完成后立即关闭
3.2 Http/1.0
HTTP/1.0 是超文本传输协议Hypertext Transfer ProtocolHTTP的第二个正式版本发布于1996年是对早期HTTP/0.9的重大改进。相比于HTTP/0.9HTTP/1.0引入了许多关键特性和增强功能使其更适合大规模的Web服务 特点
请求方法多样化 除了基本的GET方法之外新增了POST方法允许客户端向服务器发送数据。 状态码系统 在HTTP响应中加入了状态码比如常见的200成功、404未找到、500服务器内部错误等 头部信息 HTTP/1.0支持在请求和响应中携带头部信息比如User-Agent、Content-Type、Connection等 持续连接选项 尽管默认情况下HTTP/1.0仍采用“每个请求-响应后关闭连接”的模式但该版本首次引入了Connection: keep-alive头部字段允许客户端和服务器协商保持TCP连接打开以便复用连接处理多个请求从而提高性能。 多部分数据 HTTP/1.0支持多部分编码multipart encoding允许在一个HTTP消息体中发送多个不同类型的实体这一特性在文件上传等场景下尤为重要
3.3 Http/1.1
HTTP/1.1 是超文本传输协议Hypertext Transfer ProtocolHTTP的第三个主要版本发布于1999年相较于HTTP/1.0做出了许多重要的改进和优化旨在提高网络应用的性能和功能性。 特点
持久连接Persistent Connections HTTP/1.1默认启用持久连接即TCP连接在处理完一个请求之后并不会立即关闭而是保持一段时间内的开放状态以便处理更多的请求大大减少了建立连接的开销提升了整体性能。 管道化Pipelining 在同一TCP连接上客户端可以连续发送多个请求而不需等待前一个请求的响应服务器则按照请求到达的顺序依次响应。虽然管道化理论上可以进一步提升性能但由于队头阻塞Head of Line Blocking的问题在实际应用中效果有限。 缓存控制Cache Control HTTP/1.1增强了缓存机制引入了新的头部字段如Cache-Control、Expires、ETag等使缓存管理更加灵活和精细。 分块传输编码Chunked Transfer Encoding 允许动态生成内容的长度未知时服务器将响应内容分成若干个块进行传输每一块都有自己的大小标识这样客户端可以在接收到部分数据后就开始处理无需预先知道整个响应的大小。 Host头域 强制要求客户端在请求中指定Host头域使得一台服务器可以托管多个域名和站点为虚拟主机技术提供了基础。简单来说就上在一个ipport上可以部署多个网站使用Host头域进行区分 请求方法扩展 HTTP/1.1定义了更多的请求方法如PUT、DELETE、OPTIONS、HEAD等增加了HTTP协议的交互能力。 错误通知更完善 HTTP/1.1提供了更为丰富的状态码和错误信息帮助开发者更好地理解和调试应用程序。 带宽优化 通过gzip压缩等方式HTTP/1.1支持内容压缩传输降低网络带宽消耗。
3.4 Http/2.0
HTTP/2.0 是 HTTP 协议的继 HTTP/1.1 后的重要升级版本于2015年5月正式发布。HTTP/2.0 的核心目标是改善网页性能特别是在高并发场景下减少延迟提高网络资源利用率。主要的新特性包括 特点
多路复用Multiplexing 这是HTTP/2最显著的改进之一。在HTTP/1.x中一次TCP连接在同一时刻只能处理一个请求而在HTTP/2中一个TCP连接上可以并发处理多个请求和响应消除了HTTP/1.x中的“队头阻塞”问题大幅提高了页面加载速度。 二进制分帧Binary Framing HTTP/2将所有传输的信息分割成多个帧这些帧可以交错、乱序发送然后在另一端再重新组装。每个帧都有专门的目的如HEADERS帧用于传输HTTP首部DATA帧用于传输请求/响应主体。 头部压缩Header Compression HTTP/2使用HPACK算法对请求和响应的头部信息进行压缩因为HTTP头部信息往往有很多重复内容压缩头部信息可以显著减少数据传输量。 服务器推送Server Push 服务器在客户端请求一个资源的同时可以预测客户端可能还需要哪些资源并主动把这些资源推送给客户端减少了客户端发起请求的延迟和往返时间。 优先级和流控制 HTTP/2允许为每个流设置优先级以便服务器合理安排资源发送顺序。另外通过流控制机制两端可以协调数据发送速度防止拥塞和数据丢失。 单一连接 鼓励客户端和服务器维持一个长连接以供多个请求/响应交换减少建立新连接的开销
重要概念
HTTP2.0中有两个概念非常重要帧frame和流stream。 帧是最小的数据单位每个帧会标识出该帧属于哪个流流是多个帧组成的数据流。 所谓多路复用即在一个TCP连接中存在多个流即可以同时发送多个请求对端可以通过帧中的表示知道该帧属于哪个请求。在客户端这些帧乱序发送到对端后再根据每个帧首部的流标识符重新组装。通过该技术可以避免HTTP旧版本的队头阻塞问题极大提高传输性能。
3.5 Http/3.0
HTTP/3.0 是超文本传输协议HTTP的最新版本旨在进一步改进网络应用的性能和效率。作为HTTP/2.0的继承者HTTP/3.0 最显著的变化是放弃了对TCP的依赖转而采用基于UDP的QUIC协议作为传输层。
QUICQuick UDP Internet Connections最初由Google提出并开发现在已经成为IETF标准。QUIC的设计目标在于解决TCP存在的延迟和性能问题特别是队头阻塞Head-of-line blocking问题同时提供类似TCP的可靠传输保证包括流量控制、错误检测和纠正、连接迁移等功能。
特点
多路复用和低延迟 每个HTTP请求/响应在QUIC协议中映射为一个独立的数据流即使网络中某数据包丢失也不会阻塞其它数据流从而减少了延迟。 快速连接建立 QUIC使用了基于TLS 1.3的快速握手机制可以实现0-RTTZero Round Trip Time的连接建立也就是说在某些情况下客户端可以在第一个数据包就发送请求数据而无需等待握手完成。 连接迁移 QUIC支持在IP地址改变如Wi-Fi切换到蜂窝网络时保持连接这有助于移动设备在网络条件改变时保持活跃连接和流畅体验。 安全集成 QUIC内建了TLS加密确保数据在传输过程中受到保护同时也简化了安全传输的实现。 错误恢复和重传机制 QUIC拥有更好的丢包检测和重传策略可以更快速地识别和补偿丢包从而提高传输效率。
