临安网站开发,长安做网站,昆山网站建设网站,企业网站营销如何建设密码学基础
在正式讲解HTTPS协议之前#xff0c;我们首先要知道一些密码学的知识。
明文#xff1a; 明文指的是未被加密过的原始数据。
密文#xff1a;明文被某种加密算法加密之后#xff0c;会变成密文#xff0c;从而确保原始数据的安全。密文也可以被解密#xf…密码学基础
在正式讲解HTTPS协议之前我们首先要知道一些密码学的知识。
明文 明文指的是未被加密过的原始数据。
密文明文被某种加密算法加密之后会变成密文从而确保原始数据的安全。密文也可以被解密得到原始的明文。
密钥密钥是一种参数它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥分别应用在对称加密和非对称加密上。
对称加密对称加密又叫做私钥加密即信息的发送方和接收方使用同一个密钥去加密和解密数据。对称加密的特点是算法公开、加密和解密速度快适合于对大数据量进行加密常见的对称加密算法有DES、3DES、TDEA、Blowfish、RC5和IDEA。
加密过程如下明文 加密算法 私钥 密文
解密过程如下密文 解密算法 私钥 明文
对称加密中用到的密钥叫做私钥私钥表示个人私有的密钥即该密钥不能被泄露。 其加密过程中的私钥与解密过程中用到的私钥是同一个密钥这也是称加密之所以称之为“对称”的原因。由于对称加密的算法是公开的所以一旦私钥被泄露那么密文就很容易被破解所以对称加密的缺点是密钥安全管理困难。
非对称加密非对称加密也叫做公钥加密。非对称加密与对称加密相比其安全性更好。对称加密的通信双方使用相同的密钥如果一方的密钥遭泄露那么整个通信就会被破解。而非对称加密使用一对密钥即公钥和私钥且二者成对出现。私钥被自己保存不能对外泄露。公钥指的是公共的密钥任何人都可以获得该密钥。用公钥或私钥中的任何一个进行加密用另一个进行解密。 被公钥加密过的密文只能被私钥解密
加密过程如下明文 加密算法 公钥 密文
解密过程如下密文 解密算法 私钥 明文
由于加密和解密使用了两个不同的密钥这就是非对称加密“非对称”的原因。 非对称加密的缺点是加密和解密花费时间长、速度慢只适合对少量数据进行加密。 在非对称加密中使用的主要算法有RSA、Elgamal、Rabin、D-H、ECC椭圆曲线加密算法等。
Hash算法是把任意长度的输入信息通过散列算法变换成固定长度的输出该输出就是散列值。这种转换是一种压缩映射也就是散列值的空间通常远小于输入的空间不同的输入可能会散列成相同的输出所以不可能从散列值来确定唯一的输入值。常见算法有MD5、SHA-1、SHA-2、SHA-256等
简介
HTTP 协议HyperText Transfer Protocol超文本传输协议是客户端浏览器或其他程序与Web服务器之间的应用层通信协议 。HTTPS全称HyperText Transfer Protocol over Secure Socket Layer相比HTTP多了一层“SSL/TLS”SSL/TLS层负责客户端和服务器之间的加解密算法协商、密钥交换、通信连接的建立使用了以下三种算法
非对称加密用于HTTPS握手阶段的身份认证和密钥协商对称加密双方使用协商的密钥加解密传输数据Hash算法用于确保通信过程的信息完整 SSL的全称是Secure Sockets Layer即安全套接层协议是为网络通信提供安全及数据完整性的一种安全协议。SSL协议在1994年被Netscape发明后来各个浏览器均支持SSL其最新的版本是3.0
TLS的全称是Transport Layer Security即安全传输层协议是IETFInternet Engineering Task ForceInternet工程任务组制定的一种新的协议它建立在SSL 3.0协议规范之上是SSL 3.0的后续版本。在TLS与SSL3.0之间存在着显著的差别主要是它们所支持的加密算法不同所以TLS与SSL3.0不能互操作。虽然TLS与SSL3.0在加密算法上不同但是在我们理解HTTPS的过程中我们可以把SSL和TLS看做是同一个协议。
SSL/TLS安全套接层的发展历程 其中SSL1.0未发布SSL2.0存在严重漏洞现在主流HTTPS使用TLSv1.2基本不再使用低于 TLSv1 的版本
不使用SSL/TLS的HTTP通信所有信息明文传播会带来三大风险
窃听风险第三方可以获取通信内容篡改风险第三方可以修改通信内容冒充风险第三方可以冒充他人进行通信。
SSL/TLS协议是为了解决这三大风险而设计的以期达到
信息加密传输第三方无法窃听校验机制一旦被篡改通信双方会立刻发现身份证书防止身份被冒充。
虽然HTTPS显著提高了数据传输的安全性但其通信效率是一个不可忽视的问题HTTP通信时只需要经理TCP的三次握手即可建立连接HTTPS除了TCP的三次握手外还需要SSL的握手而SSL握手耗时大约是TCP握手的三倍左右
HTTPS在传输数据之前需要客户端与服务端之间进行一次握手两次完整的HTTP请求非TCP握手在握手过程中通过非对称加密确立双方加密传输数据的密码信息握手完成后双方使用协商好的会话密钥通过对称加密进行数据传输
发展历程
HTTP/0.91991年发布极其简单只有一个get命令HTTP/1.01996年5月发布增加了大量内容HTTP/1.11997年1月发布进一步完善HTTP协议是目前最流行的版本SPDY2009年谷歌发布SPDY协议主要解决HTTP/1.1效率不高的问题HTTP/22015年借鉴SPDY的HTTP/2发布HTTP/32022年6月正式发布标准文档为RFC 9114 HTTP/0.9
HTTP 0.9的核心作用是传输超文本内容 HTML。
只定义了一种方法GET 请求的文件路径服务端收到请求后返回一个以 ASCII 字符流编码的 HTML 文档。 HTTP/1.0
HTTP 1.0的核心改变是引入头部字段不仅用于解决不同类型文件传输的问题也可以实现其他很多功能如缓存、认证信息等。
HTTP 1.0 相对于 HTTP 0.9 的改进如下
每个请求都附加了 HTTP 版本。在响应开始时发送状态代码。请求和响应都包含 HTTP 报文头。报文头中的元数据使协议具有灵活性和可扩展性。内容类型能够传输 HTML 文件以外的文档。
但是HTTP 1.0 不是官方标准。
HTTP/1.1
HTTP 1.1作为HTTP 的第一个标准化版本核心改变是解决HTTP1.0的短连接问题建立了长连接进行复用。
缓存处理HTTP/1.0 使用 Pragma:no-cache Last-Modified/If-Modified-Since来作为缓存判断的标准HTTP/1.1 引入了更多的缓存控制策略Cache-Control、Etag/If-None-Match等错误状态管理HTTP/1.1新增了24个错误状态响应码如409Conflict表示请求的资源与资源的当前状态发生冲突410Gone表示服务器上的某个资源被永久性的删除。范围请求HTTP/1.1在请求头引入了range头域它允许只请求资源的某个部分也就是断点续传如碰到网络故障可以从已经上传/下载的部分开始继续上传/下载未完成的部分返回码是206Partial Content这样就方便了开发者自由的选择以便于充分利用带宽和连接Host头HTTP1.0中认为每台服务器都绑定一个唯一的IP地址因此请求消息中的URL并没有传递主机名hostname。但随着虚拟主机技术的发展在一台物理服务器上可以存在多个虚拟主机Multi-homed Web Servers并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域且请求消息中如果没有Host头域会报告一个错误400 Bad Request。有了Host字段就可以将请求发往同一台服务器上的不同网站为虚拟主机的兴起打下了基础比如一台IP为10.8.56.13的服务器上部署这很多个服务或网站。Host 请求头能够决定访问哪个网站或者服务。持久连接HTTP/1.1 最大的变化就是引入了持久连接persistent connection在HTTP/1.1中默认开启 Connection: keep-alive即TCP连接默认不关闭可以被多个请求复用 客户端和服务器发现对方一段时间没有活动就可以主动关闭连接。不过规范的做法是客户端在最后一个请求时发送Connection: close明确要求服务器关闭TCP连接。
管道机制HTTP/1.1中引入了管道机制pipelining,即在同一个TCP连接中客户端可以同时发送多个请求
HTTP/1.1对头阻塞
HTTP/1.1 的持久连接和管道机制允许复用TCP连接在一个TCP连接中也可以同时发送多个请求但是所有的数据通信都是按次序完成的服务器只有处理完一个回应才会处理下一个回应。比如客户端需要A、B两个资源管道机制允许浏览器同时发出A请求和B请求但服务器还是按照顺序先回应A请求完成后再回应B请求这样如果前面的回应特别慢后面就会有很多请求排队等着这称为队头阻塞(Head-of-line blocking)
HTTP/2
HTTP/2以Google发布的SPDY协议为基础于2015年发布。它不叫HTTP/2.0因为标准委员会不打算再发布子版本了下一个新版本将是HTTP/3。HTTP/2协议只在HTTPS环境下才有效升级到HTTP/2必须先启用HTTPS。HTTP 2.0的核心改变是默认不再使用 ASCII 编码传输而是改为二进制数据来提升传输效率。有了二进制分帧后对于同一个域客户端只需要与服务端建立一个连接即可完成通信需求这种利用一个连接来发送多个请求的方式称为「多路复用」。实现多路复用技术解决对头阻塞问题。主要特点如下
二进制分帧HTTP/1.1的头信息是文本ASCII编码数据体可以是文本也可以是二进制HTTP/2 头信息和数据体都是二进制统称为“帧”头信息帧和数据帧多路复用双工通信通过单一的 HTTP/2 连接发起多重的请求-响应消息即在一个连接里客户端和浏览器都可以同时发送多个请求和响应而不用按照顺序一一对应这样避免了“队头堵塞”。HTTP/2 把 HTTP 协议通信的基本单位缩小为一个一个的帧这些帧对应着逻辑流中的消息。并行地在同一个 TCP 连接上双向交换消息。数据流因为 HTTP/2 的数据包是不按顺序发送的同一个连接里面连续的数据包可能属于不同的回应。因此必须要对数据包做标记指出它属于哪个回应。HTTP/2 将每个请求或回应的所有数据包称为一个数据流stream。每个数据流都有一个独一无二的编号。数据包发送的时候都必须标记数据流ID用来区分它属于哪个数据流。另外还规定客户端发出的数据流ID一律为奇数服务器发出的ID为偶数。数据流发送到一半的时候客户端和服务器都可以发送信号RST_STREAM帧取消这个数据流。HTTP/1.1取消数据流的唯一方法就是关闭TCP连接。这就是说HTTP/2 可以取消某一次请求同时保证TCP连接还打开着可以被其他请求使用。客户端还可以指定数据流的优先级。优先级越高服务器就会越早回应。首部压缩HTTP 协议不带有状态每次请求都必须附上所有信息。所以请求的很多字段都是重复的一模一样的内容每次请求都必须附带这会浪费很多带宽也影响速度。HTTP/2 对这一点做了优化引入了头信息压缩机制header compression。一方面头信息压缩后再发送SPDY 使用的是通用的DEFLATE 算法而 HTTP/2 则使用了专门为首部压缩而设计的 HPACK 算法。另一方面客户端和服务器同时维护一张头信息表所有字段都会存入这个表生成一个索引号以后就不发送同样字段了只发送索引号这样就提高速度了。服务端推送HTTP/2 允许服务器未经请求主动向客户端发送资源这叫做服务器推送server push。常见场景是客户端请求一个网页这个网页里面包含很多静态资源。正常情况下客户端必须收到网页后解析HTML源码发现有静态资源再发出静态资源请求。其实服务器可以预期到客户端请求网页后很可能会再请求静态资源所以就主动把这些静态资源随着网页一起发给客户端了。
HTTP/3
QUICQuick UDP Internet Connection是谷歌制定的一种基于UDP的低时延的互联网传输层协议在新正在制定的HTTP/3协议标准中传输层协议由TCP替换为基于UDP的QUIC协议解决TCP连接慢、对头拥塞等问题。与TCP协议相比UDP更为轻量错误校验也要少得多因此UDP往往效率更高但可靠性较差。
QUIC很好的解决了当今传输层和应用层面临的各种需求包括处理更多的连接、安全性和低延迟。QUIC融合了包括TCPTLS、HTTP/2等协议的特性但基于UDP传输。
HTTP3是在保持QUIC稳定性的同时使用UDP来实现高速度选择QUIC就是选择UDP, 同时又不会牺牲TLS的安全性. HTTP2协议虽然大幅提升了HTTP/1.1的性能然而基于TCP实现的HTTP2遗留下3个问题
有序字节流引出的队头阻塞Head-of-line blocking使得HTTP2的多路复用能力大打折扣TCP与TLS叠加了握手时延建链时长还有1倍的下降空间基于TCP四元组确定一个连接这种诞生于有线网络的设计并不适合移动状态下的无线网络这意味着IP地址的频繁变动会导致TCP连接、TLS会话反复握手成本高昂。
HTTP3协议解决了这些问题
HTTP3基于UDP协议重新定义了连接在QUIC层实现了无序、并发字节流的传输解决了队头阻塞问题包括基于QPACK解决了动态表的队头阻塞HTTP3重新定义了TLS协议加密QUIC头部的方式既提高了网络攻击成本又降低了建立连接的速度仅需1个RTT就可以同时完成建链与密钥协商HTTP3 将Packet、QUIC Frame、HTTP3 Frame分离实现了连接迁移功能降低了5G环境下高速移动设备的连接维护成本。
总结 协议版本 解决的核心问题 解决方式 0.9 HTML 文件传输 确立了客户端请求、服务端响应的通信流程 1 不同类型文件传输 设立头部字段 1.1 创建/断开 TCP 连接开销大 建立长连接进行复用 2 并发数有限 二进制分帧、多路复用 3 TCP对头阻塞、网络延时 基于UDP的QUIC协议代替TCP协议
数字证书
证书 公钥服务方生成密码对中的公钥 申请者与颁发者信息 签名用CA机构生成的密码对的私钥进行签名
CA证书
CA是Certificate Authority的缩写也叫证书颁发机构即颁发数字证书的机构是公钥基础设施Public Key InfrastructurePKI的核心也是受信任的第三方机构是负责签发证书、认证证书、管理已颁发证书的机关目的就是为了让企业组织和用户的信息数据等能够在互联网环境下更加安全。
第三方认证机构完整的签发管理流程及行业认可度包括签发递送等过程加密且可追溯泄露事故保障等等一种除己以外的第三方信任原则即在认证方与被认证方中间加入一个公正可信任的独立第三方的签发中心把认证方与被认证方隔离开来可以将安全风险降到最低
证书颁发机构也称为CA机构是受信任的组织要成为CA机构需要得到行业认可同时更需要具备相关的技术服务标准才能保证签发的SSL证书真实可信如果一旦发生SSL证书安全问题还需要具备高额的赔付保障。这些条件使得成为CA机构门槛较高所以也具备了权威性。
CA机构与浏览器厂家都会接受 CA/浏览器论坛 来确定CA机构与浏览器信任体CA机构用于验证网站实名及实体认证这样才可以知道您在和谁进行互联网通信。他们的目标是使互联网成为组织和用户都更安全的场所。
受信任的CA也称商业CA据统计全球有数百个公共CA通常它们是按国家地区进行划分的。但是实际上排名靠前的也有大约数十个比如 DigicertSectigoGlobalSignEntrust 等等。
CA 拥有一个证书内含公钥和私钥。网上的公众用户通过验证 CA 的签字从而信任 CA 任何人都可以得到 CA 的证书含公钥用以验证它所签发的证书。如果用户想得到一份属于自己的证书他应先向 CA 提出申请。在 CA 判明申请者的身份后便为他分配一个公钥并且 CA 将该公钥与申请者的身份信息绑在一起并为之签字后便形成证书发给申请者。
CA证书的功能
颁发证书颁发证书其实就是使用CA的私钥对证书请求签名文件CSR进行签名颁发的证书浏览器要信任浏览器只需要用CA的公钥进行验签成功就表示这个证书是合法可信的这就需要浏览器内置CA的公钥也就是内置CA的证书。一般来说操作系统都会内置权威CA的证书有的浏览器会使用操作系统内置的CA证书列表有的浏览器则自己维护的CA证书列表比如Firefox。
内置 CA 对应的证书称为根证书颁发者和使用者相同自己为自己签名即自签名证书
SSL证书
SSL证书和CA证书是从属关系因为SSL是众多CA证书中的一种。CA是数字证书管理机构SSL证书一种数字证书SSL证书由CA机构签发的。
实际上我们使用的证书分很多种类型SSL证书只是其中的一种。证书的格式是由X.509标准定义。SSL证书负责传输公钥是一种PKIPublic Key Infrastructure公钥基础结构证书。
我们常见的证书根据用途不同大致有以下几种
SSL证书用于加密HTTP协议也就是HTTPS。代码签名证书用于签名二进制文件比如Windows内核驱动Firefox插件Java代码签名等等。客户端证书用于加密邮件。双因素证书网银专业版使用的USB Key里面用的就是这种类型的证书。
这些证书都是由受认证的证书颁发机构——我们称之为CACertificate Authority机构来颁发针对企业与个人的不同可申请的证书的类型也不同价格也不同。CA机构颁发的证书都是受信任的证书对于SSL证书来说如果访问的网站与证书绑定的网站一致就可以通过浏览器的验证而不会提示错误。
一般的数字证书包含的内容
申请者公钥申请者的组织信息和个人信息签发机构 CA的信息有效时间证书序列号等信息的明文域名CN签名 使用散列函数计算公开的明文信息的信息摘要然后采用 CA的私钥对信息摘要进行加密加密后形成的密文即签名。
验证证书时客户端读取证书中的相关的明文信息采用相同的散列函数计算得到信息摘要然后利用对应CA的公钥解密签名数据对比证书的信息摘要如果一致则可以确认证书的合法性即公钥合法;
客户端验证证书的合法性如果验证通过才会进行后续通信否则根据错误情况不同做出提示和操作合法性验证包括如下
证书链的可信性Trusted Certificate Path;证书是否吊销 Revocation有两类方式离线 CRL 与在线 OCSP不同的客户端行为会不同;有效期Expiry Date证书是否在有效时间范围;域名Domain核查证书域名是否与当前的访问域名匹配匹配规则后续分析;
SSL证书验证失败有以下三点原因
SSL证书不是由受信任的CA机构颁发的证书过期访问的网站域名与证书绑定的域名不一致
证书申请验证流程 服务方S向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;不交私钥CA通过线上、线下等多种手段验证申请者提供信息的真实性如组织是否存在、企业是否合法是否拥有域名的所有权等;如信息审核通过CA会向申请者签发认证文件-证书。
HTTPS通信过程 一个HTTPS请求实际上包含了两次HTTP传输可以细分为8步。
客户端向服务器发起HTTPS请求连接到服务器的HTTPS端口 以明文传输请求信息包含版本信息加密套件候选列表压缩算法候选列表随机数扩展字段等信息支持的最高 TLS 协议版本 version;客户端支持的加密套件 cipher suites 列表 每个加密套件对应前面TLS原理中的四个功能的组合认证算法 Au (身份验证)、密钥交换算法 KeyExchange(密钥协商)、对称加密算法 Enc (信息加密)和信息摘要 Mac(完整性校验);支持的压缩算法 compression methods 列表用于后续的信息压缩传输;随机数 random_C用于后续的密钥的生成;扩展字段 extensions支持协议与算法的相关参数以及其它辅助信息等常见的 SNI 就属于扩展字段后续单独讨论该字段作用
服务器端有一个密钥对即公钥和私钥是用来进行非对称加密使用的服务器端保存着私钥不能将其泄露公钥可以发送给任何人。服务器返回协商的信息结果包括选择使用的协议版本 version选择的加密套件 cipher suite选择的压缩算法 compression method、随机数 random_S 等其中随机数用于后续的密钥协商并将自己的公钥发送给客户端。客户端收到服务器端的证书公钥之后会验证其合法性如果发现发现证书有问题会中断HTTPS连接或者提示https warning。如果公钥合格客户端会生成一个随机数字 Pre-master计算得到会话密钥enc_keyFuc(random_C, random_S, Pre-Master)至此HTTPS中的第一次HTTP请求结束。客户端会发起HTTPS中的第二个HTTP请求将使用服务端公钥加密之后的Pre-master和一段用enc_key加密过后的encrypted_handshake_message发送给服务器。服务器接收到客户端发来的密文之后会用自己的私钥对其进行非对称解密解密出Pre-Master通过Fuc(random_C, random_S, Pre-Master)计算出会话密钥enc_key并用enc_key对发送过来的encrypted_handshake_message数据进行解密验证数据和密钥的正确性。服务端同样使用enc_key加密encrypted_handshake_message发送给客户端客户端收到服务器发送来的密文用enc_key对其进行对称解密验证通过后标识HTTPS中的第二个HTTP请求结束整个HTTPS握手阶段完成。之后客户端和服务端可以使用enc_key进行数据加密传输
部分情况下客户端也会要求服务端进行客户端证书认证如下图所示双向认证时在原有流程上增加服务端对客户端证书的验证以及使用公钥和私钥对服务端选择的加密方案的加解密过程验证通过后再进行密钥协商等流程 单向认证所需证书的标准要求server.crt、server.key、ca.crt、ca.key
不标准要求server.crt、server.key
curl提供了-k/--insecure选项该选项可以忽略根证书验证另外浏览器访问HTTPS网址时一般都支持跳过根证书的验证因此HTTPS单向认证使用的证书只适用于数据传输加密没有认证鉴权功能Kubernetes通过验证证书的CN和O参数来验证证书的用户名和组并不是通用的做法。
双向认证所需的证书要求client.crt client.key ca.crt ca.key server.crt、server.key 共六个
REST与HTTP
REST
REST(Resource Representational State Transfer)翻译是”表现层状态转化”是Roy Thomas Fielding在他2000年的博士论文中提出的是所有Web应用都应该遵守的架构设计指导原则用于描述API接口本质是一种软件架构风格。HTTP接口按照REST风格设计就是Restful HTTPWebService接口按照REST风格设计 就是Restful WebSerivce。
面向资源是REST最明显的特征对于同一个资源的一组不同的操作。资源是服务器上一个可命名的抽象概念资源是以名词为核心来组织的首先关注的是名词。REST要求必须通过统一的接口来对资源执行各种操作GET/PUT/PATCH等。
Restful主要解决的问题
降低开发的复杂性提高系统的可伸缩性
Restful资源层Resource文本、图片、服务、音频等等。
Restful表现层Representational
文本txt、html、xml、json、二进制图片jpg、pngCasebook是一个资源获取不同的格式http协议的content-type和accept
Restful状态转化State Transfer
幂等性每次HTTP请求相同的参数相同的URI产生的结果是相同的GETPOSTPUTDELETE
对于Restful风格的API需要遵循以下原则
C/S模型,通过统一接口通讯层次化,可与多个服务器通讯无状态,服务器不保存客户状态,发送请求时需包含足够信息Cache,C/S之间可使用缓存唯一资源标识来标识资源对资源操作不会改变这些标识传递消息的自身描述返回资源的自身描述可选的超媒体即应用状态引擎HATEOAS
示例
使用传统方法进行请求等操作
http://127.0.0.1/item/queryItem?id1 查询,GET
http://127.0.0.1/item/saveItem 新增,POST
http://127.0.0.1/item/updateItem 更新,POST
http://127.0.0.1/item/deleteItem?id1 删除,GET或POST
改用RESTful风格后
http://127.0.0.1/item/1 查询,GET
http://127.0.0.1/item 新增,POST
http://127.0.0.1/item 更新,PUT
http://127.0.0.1/item/1 删除,DELETE
可以对item一个接口进行增、删、改、查四种操作。请求地址一样但是功能可以不同。是通过用HTTP协议里的动词来实现资源的添加修改删除等操作即通过HTTP动词来实现资源的状态扭转。
URI
网络上的所有事物都可以被抽象为资源REST资源代表网络上的一个实体或者说是网络上的一个具体信息
schema://host[:port]/path [?query-string][#anchor]
schema指定底层使用的协议例如httphttpsftphost服务器的IP地址或者域名port服务器端口默认为80path访问资源的路径query-string发送给http服务器的数据anchor锚
URL(Uniform Resource Locator): 统一资源定位符偏重定位说明了通过哪种协议来访问一个资源。
URN(Uniform Resource Name): 统一资源名称
URI统一资源标识符偏重标识一个字符串格式规范URL和。
URL和URN是URI的子集因为URI是资源标识URL是指定用哪种协议访问该资源
Web上地址的基本形式是URI,它有两种形式
一种是URL这是目前URI的最普遍形式。另一种就是URN这是URL的一种更新形式URN不依赖于位置并且有可能减少失效连接的个数。但是其流行还需假以时日因为它需要更精密软件的支持。 URL URI 具体名称 Uniform Resource Lacator 统一资源定位符 Uniform Resource Identifier 统一资源标识符 含义 在WWW上每一信息资源都有统一的且唯一的地址 该地址就是URL 广义上的资源标识既包括网络也可涵盖本地等 凡是标识资源的均可称为URI 组成 三部分: 【协议/服务方式】 【该资源的主机IP地址时含端口号】 【主机资源的具体地址】 e.g. [协议]://[主机地址]:(端口)/[路径] 两段 【特定协议】 及【协议内容的语法和语义】 e.g. [协议名]://[用户名]:[密码][服务器地址]:[服务器端口号]/[路径]?[查询字符串]#[片段ID]
设计Restful API应该考虑以下信息
资源路径URIHTTP动词
GET请求获取Request-URI所标识的资源POST新创建资源在Request-URI所标识的资源后附加新的数据PUT请求服务器存储一个资源并用Request-URI作为其标识。向指定资源位置上传最新的完整资源DELETE请求服务器删除Request-URI所标识的资源HEAD请求获取由Request-URI所表示的资源的响应消息报头可以不用传入全部内容PATCH在服务器更新资源客户端提供改变的属性OPTIONS请求查询服务器的性能或者查询与资源相关的选项和需求
过滤信息 如果记录数量很多服务器不可能都将它们返回给用户。API应该提供参数过滤返回结果。例如 ?offset10指定返回记录的开始位置 ?page2per_page100指定第几页以及每页的记录数 ?sortbynameorderasc指定返回结果排序以及排序顺序 ?animal_type_id1指定筛选条件
状态码 其所有操作可能返回的状态码信息如下 1xx信息响应类表示接收到请求并且继续处理 2xx处理成功响应类表示动作被成功接收、理解和接受 3xx重定向响应类为了完成指定的动作必须接受进一步处理 4xx客户端错误客户请求包含语法错误或者是不能正确执行 5xx服务器端错误服务器不能正确执行一个正确的请求 其常见返回状态码如下所示 200 OK 客户端请求成功 400 Bad Request 客户端请求有语法错误不能被服务器所理解 401 Unauthorized 服务器收到请求但是拒绝提供服务 404 Not Found 请求资源不存在 500 Internal Server Error 服务器发生不可预期的错误 503 Server Unavailable 服务器当前不能处理客户端的请求
HTTP协议
工作流程
HTTP是以TCP作为底层协议默认端口号为80.通信过程
客户机与服务器建立连接。服务端在80端口等待客户的请求。客户端发送一个请求到服务器。
请求报文中会包含以下几个东西请求行、请求头、请求空行、请求体
POST /user HTTP/1.1 # 请求行用来说明请求类型,要访问的资源以及所使用的 HTTP 版本
Host: www.user.com
Content-Type: application/x-www-form-urlencoded
accept: application/json
User-agent: Mozilla/5.0. # 以上是首部
#此处必须有一空行 # 空行分割header和请求内容
nameworld # 请求体
常见的请求头
Host主机名一般是域名 Connection连接类型如Keep-Alivehttp1.1默认长连接 Origin用来说明请求从哪里发起的 USer-Agent用户代理浏览器类型操作系统信息 Accept能接收的数据类型如text/html、image/jpeg Accept-Encoding:接受的压缩格式如gzip Accept-Language接收的语言如zh-CNzh表示中文CN表示中国 Cookie表示服务器端为本次访问分配了一个Session ID每次发送请求时都会主动将该Session ID通过Cookie字段又发送回服务器用于验证身份和保持状态。
服务器接收来自客户端的请求并给出响应
服务端进行对应的处理会给我们返回一个响应每一个响应都会有一个响应报文在响应报文中会包含我们所有的响应信息也就是服务端在接受到客户端请求以后给我们的回信 响应报文中会包含几个信息
状态行
HTTP/1.1 200 OK
HTTP/1.1 服务器使用的 HTTP 协议版本
# 200 响应状态码
# OK 对响应状态码的简单解释
响应头常见
Date: Jan, 14 Aug 2019 12:42:30 GMT # 服务器时间
Server: Apache/2.4.23 (Win32) OpenSSL/1.0.2j PHP/5.4.45 # 服务器类型
Content-Type: text/html # 服务端给客户端的数据类型
Content-Length: 11 # 服务端给客户端的数据长度
响应体
hello world
服务端给客户端的响应数据
关闭TCP连接
HTTP请求方法
HTTP1.0 定义了三种请求方法: GET、POST 和 HEAD 方法。
HTTP1.1 新增了六种请求方法: OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。 序号 方法 描述 1 GET 请求指定的页面信息并返回实体主体 2 HEAD 类似于 GET 请求只不过返回的响应中没有具体的内容用于获取报头 3 POST 向指定资源提交数据进行处理请求数据被包含在请求体中。POST 请求可能会导致新的资源的建立/或已有资源的修改 4 PUT 从客户端向服务器传送的数据取代指定的文档的内容 5 DELETE 请求服务器删除指定的资源 6 PATCH 是对 PUT 方法的补充用来对已知资源进行局部更新 7 TRACE 回显服务器收到的请求主要用于测试或诊断 8 OPTIONS 允许客户端查看服务器的性能 9 CONNECT HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器
URL
URL全称Uniform Resource Locator 译名统一资源定位符用于准确描述Internet上某一资源的地址
通常我们访问的网页都是有一个URL地址或称Web地址俗称网址。
URL格式以http://test.com:8080/example/index.html为例进行说明。
URL的格式由下列三部分组成
第一部分是协议或称为服务方式本例中为HTTP 协议。第二部分是存有该资源的主机IP地址或域名有时也包括端口号本例中为 test.com:8080。平时看到的都是域名之后客户端会通过DNS域名系统 查询域名对应的 IP然后根据IP和端口号进行服务器的连接。稍后会对此进行详细说明。第三部分是主机资源的具体地址如目录和文件名等本例中为 /example/index.html。
URL通用语法
scheme://user:passwordhost:port/path;params?query#frag
scheme: 协议常见的有 http80https443ftp21file。user用户名。password 密码。 如使用ftp协议传输时需要输入用户名和密码但是我们的http协议中如果把用户名和密码就放在url里那很不安全所以一般不这样用 host主机。port 端口。path路径。params: 参数。通常为 keyvalue。 参数一般使用“”与路径分开如果有多个参数也使用“”分隔开我们访问一些资源只有路径端口是不够的有时候需要向解析url的应用程序提供参数才能去访问资源如参数可能会定义传输格式等等 query查询参数或查询字符串。 查询参数使用“”与前边的东西分开如果有多个查询的问题需要使用“”连接。访问一些资源时有些需要查询数据库进行搜索来缩小请求资源范围就像我们查东西时指定关键字一样如namebobid123意思是在该路径下查询namebobid123的资源 frag: 片段。 我们访问资源时可以不直接访问该资源而是访问资源的一部分。片段用“#”与其它东西分开后边写指定部分的名字。如#main表示访问资源/index.html 中的名字叫做main的部分。其实http服务器仍然是把整个对象资源发给你的浏览器浏览器获得整个资源后根据片段显示你要的资源。 这只是通用语法并不是每种URL都会有上面的所有信息其中最重要的 3 个部分是协议scheme、主机host和路径path。
示例
基于对HTTP协议的学习在url中?之后以key1value1key2value2格式编辑的内容是url上的参数这里以一个简单的api中的获取图片接口进行请求
接口说明文档https://api.apiopen.top/swagger/index.html#
获取图片的接口url地址https://api.apiopen.top/api/getImages?page15size2
在url中可以修改page和size的值所代表含义分别是页码和查询数量比如将size值改为1就会看到返回体中只有一条查询结果记录。 总结
一般的HTTP接口只有POST和GET方法其所有请求参数都填在Body中参数类型是由服务端固定的但Restful API让我们设计接口时一定要适当使用PUT和DELETE方法其参数可以填在URL中每个URL都对应服务端的一个资源URL中的命名都是名词通过不同的操作GET、POST等实现不同的动作另外请求中传输的参数类型是可变的通过HTTP Header中的Accept和Content-Type参数指定传输内容的数据格式。
虽然Restful风格的API能帮助我们设计出更规范的API接口降低开发的复杂性和提高系统的可伸缩性但如果我们仅仅只是为了实现某个功能而不用考虑对外暴露自己的API完全可以忽略Restful风格的设计
常用开源项目与HTTP关系 HTTP1.0 HTTP1.1 HTTP2.0 HTTP HTTP HTTPS HTTP HTTPS Grafana(Prometheus) √ Kibana(EFK) √ Dashboard √ Harbor √ API Server √双向认证 Etcd √双向认证
【资料】
CA证书签发及使用过程https://www.cnblogs.com/xdyixia/p/11610102.html
HTTPS通信原理https://www.xinnet.com/xinzhi/63/318224.html
HTTP幂等性概念与应用https://coolshell.cn/articles/4787.html
Restful与HTTPhttps://www.jianshu.com/p/21622d81ab26
HTTP(S)协议概述https://www.cnblogs.com/zOxygeNz/p/13401497.html
