山东建设发展研究院网站,wordpress托管是什么,网络营销推广方法范文,wordpress api 自定义http 是我们几乎天天都要打交道的东西#xff0c;相关知识点有点多#xff0c;所以也有不少面试必问的点#xff0c;这里做了一些整理#xff0c;帮且大家树立完整的 http 知识体系#xff0c;对面试官说 so easy
HTTP 的特点和缺点
特点#xff1a;无连接、无状态、灵…http 是我们几乎天天都要打交道的东西相关知识点有点多所以也有不少面试必问的点这里做了一些整理帮且大家树立完整的 http 知识体系对面试官说 so easy
HTTP 的特点和缺点
特点无连接、无状态、灵活、简单快速
无连接每一次请求都要连接一次请求结束就会断掉不会保持连接无状态每一次请求都是独立的请求结束不会记录连接的任何信息(提起裤子就不认人的意思)减少了网络开销这是优点也是缺点灵活通过http协议中头部的Content-Type标记可以传输任意数据类型的数据对象(文本、图片、视频等等)非常灵活简单快速发送请求访问某个资源时只需传送请求方法和URL就可以了使用简单正由于http协议简单使得http服务器的程序规模小因而通信速度很快
缺点无状态、不安全、明文传输、队头阻塞
无状态请求不会记录任何连接信息没有记忆就无法区分多个请求发起者身份是不是同一个客户端的意味着如果后续处理需要前面的信息则它必须重传这样可能导致每次连接传送的数据量增大不安全明文传输可能被窃听不安全缺少身份认证也可能遭遇伪装还有缺少报文完整性验证可能遭到篡改明文传输报文(header部分)使用的是明文直接将信息暴露给了外界WIFI陷阱就是复用明文传输的特点诱导你连上热点然后疯狂抓取你的流量从而拿到你的敏感信息队头阻塞开启长连接(下面有讲)时只建立一个TCP连接同一时刻只能处理一个请求那么当请求耗时过长时其他请求就只能阻塞状态(如何解决下面有讲)
HTTP 报文组成部分
http报文由请求报文和响应报文组成
请求报文由请求行、请求头、空行、请求体四部分组成
响应报文由状态行、响应头、空行、响应体四部分组成
请求行包含http方法请求地址http协议以及版本请求头/响应头就是一些key:value来告诉服务端我要哪些内容要注意什么类型等请求头/响应头每一个字段详解空行用来区分首部与实体因为请求头都是key:value的格式当解析遇到空行时服务端就知道下一个不再是请求头部分就该当作请求体来解析了请求体请求的参数状态行包含http协议及版本、数字状态码、状态码英文名称响应体服务端返回的数据
HTTP 请求方法(9种)
HTTP1.0 GET、POST、HEAD
HTTP1.1 PUT、PATCH、DELETE、OPTIONS、TRACE、CONNECT
方法描述GET获取资源POST传输资源通常会造成服务器资源的修改HEAD获得报文首部PUT更新资源PATCH对PUT的补充对已知资源部分更新 菜鸟DELETE删除资源OPTIONS列出请求资源支持的请求方法用来跨域请求TRACE追踪请求/响应路径用于测试或诊断CONNECT将连接改为管道方式用于代理服务器(隧道代理下面有讲)
GET 和 POST 的区别
GET在浏览器回退时是无害的而POST会再次发起请求GET请求会被浏览器主动缓存而POST不会除非手动设置GET请求参数会被安逗保留在浏览器历史记录里而POST中的参数不会被保留GET请求在URL中传递的参数有长度限制(浏览器限制大小不同)而POST没有限制GET参数通过URL传递POST放在Request body中GET产生的URL地址可以被收藏而POST不可以GET没有POST安全因为GET请求参数直接暴露在URL上所以不能用来传递敏感信息GET请求只能进行URL编码而POST支持多种编码方式对参数的数据类型GET只接受ASCII字符而POST没有限制GET产生一个TCP数据包POST产生两个数据包(Firefox只发一次)。GET浏览器把 http header和data一起发出去响应成功200POST先发送header响应100 continue再发送data响应成功200
常见 HTTP 状态码
1xx: 指示信息——表示请求已接收继续处理
2xx: 成功——表示请求已被成功接收
3xx: 重定向——表示要完成请求必须进行进一步操作
4xx: 客户端错误——表示请求有语法错误或请求无法实现
5xx: 服务端错误——表示服务器未能实现合法的请求
常见状态码
状态码描述200请求成功206已完成指定范围的请求(带Range头的GET请求),场景如video,audio播放文件较大,文件分片时301永久重定向302临时重定向304请求资源未修改可以使用缓存的资源不用在服务器取400请求有语法错误401没有权限访问403服务器拒绝执行请求场景如不允许直接访问只能通过服务器访问时404请求资源不存在500服务器内部错误无法完成请求503请求未完成因服务器过载、宕机或维护等
什么是持久连接/长连接
http1.0协议采用的是请求-应答模式当使用普通模式每个请求/应答客户与服务器都要新建一个连接完成之后立即断开连接(http协议为无连接的协议)
http1.1版本支持长连接即请求头添加Connection: Keep-Alive使用Keep-Alive模式(又称持久连接连接复用)建立一个TCP连接后使客户端到服务端的连接持续有效可以发送/接受多个http请求/响应当出现对服务器的后续请求时Keep-Alive功能避免了建立或者重新建立连接 如图短连接极大的降低了传输效率
长连接优缺点
优点
减少CPU及内存的使用因为不需要经常建立和关闭连接支持管道化的请求及响应模式减少网络堵塞因为减少了TCP请求减少了后续请求的响应时间因为不需要等待建立TCP、握手、挥手、关闭TCP的过程发生错误时也可在不关闭连接的情况下进行错误提示
缺点
一个长连接建立后如果一直保持连接对服务器来说是多么的浪费资源呀而且长连接时间的长短直接影响到服务器的并发数
还有就是可能造成队头堵塞(下面有讲)造成信息延迟
如何避免长连接资源浪费
客户端请求头声明Connection: close本次通信后就关闭连接服务端配置如Nginx设置keepalive_timeout设置长连接超时时间keepalive_requests设置长连接请求次数上限系统内核参数设置 net.ipv4.tcp_keepalive_time 60连接闲置60秒后服务端尝试向客户端发送侦测包判断TCP连接状态如果没有收到ack反馈就在net.ipv4.tcp_keepalive_intvl 10就在10秒后再次尝试发送侦测包直到收到ack反馈一共会net.ipv4.tcp_keepalive_probes 5一共会尝试5次要是都没有收到就关闭这个TCP连接了
什么是管线化(管道化)
http1.1在使用长连接的情况下建立一个连接通道后连接上消息的传递类似于 请求1 - 响应1 - 请求2 - 响应2 - 请求3 - 响应3 管理化连接的消息就变成了类似这样 请求1 - 请求2 - 请求3 - 响应1 - 响应2 - 响应3 管线化是在同一个TCP连接里发一个请求后不必等其回来就可以继续发请求出去这可以减少整体的响应时间但是服务器还是会按照请求的顺序响应请求所以如果有许多请求而前面的请求响应很慢就产生一个著名的问题队头堵塞(下面有讲解决方法)
管线化的特点
管线化机制通过持久连接完成在http1.1版本才支持只有GET请求和HEAD请求才可以进行管线化而POST有所限制初次创建连接时不应启动管线化机制因为服务器不一定支持http1.1版本的协议管线化不会影响响应到来的顺序如上面的例子所示响应返回的顺序就是请求的顺序要求客户端和服务端都支持管线化但并不要求服务端也对响应进行管线化处理只是要求对于管线化的请求不失败即可由于上面提到的服务端问题开户管线化很可能并不会带来大幅度的性能提升而且很多服务端和代理程序对管线化的支持并不好因为浏览器(Chrome/Firefox)默认并未开启管线化支持
如何解决 HTTP 的队头阻塞问题
http1.0协议采用的是请求-应答模式报文必须是一发一收就形成了一个先进先出的串行队列没有轻重缓急的优先级只有入队的先后顺序排在最前面的请求最先处理就导致如果队首的请求耗时过长后面的请求就只能处于阻塞状态这就是著名的队头阻塞问题。解决如下
并发连接
因为一个域名允许分配多个长连接就相当于增加了任务队列不至于一个队列里的任务阻塞了其他全部任务。以前在RFC2616中规定过客户端最多只能并发2个连接但是现实是很多浏览器不按套路出牌就是遵守这个标准T_T所以在RFC7230把这个规定取消掉了现在的浏览器标准中一个域名并发连接可以有6~8个记住是6~8个不是6个(Chrome6个/Firefox8个)
如果这个还不能满足你
继续不要停...
域名分片
一个域名最多可以并发6~8个那咱就多来几个域名
比如a.baidu.comb.baidu.comc.baidu.com多准备几个二级域名当我们访问baidu.com时可以让不同的资源从不同的二域名中获取而它们都指向同一台服务器这样能够并发更多的长连接了
而在HTTP2.0下可以一瞬间加载出来很多资源因为支持多路复用可以在一个TCP连接中发送多个请求
说一下 HTTP 代理
常见的代理有两种普通代理(中间人代理)隧道代理
普通代理(中间人代理) 如图代理服务器相当于一个中间人一直帮两边传递东西好可怜~~
不过它可以在中间可以帮我们过滤、缓存、负载均衡(多台服务器共用一台代理情况下)等一些处理
注意实际场景中客户端和服务器之间可能有多个代理服务器
隧道代理
客户端通过CONNECT方法请求隧道代理创建一个可以到任意目标服务器和端口号的TCP连接创建成功之后隧道代理只做请求和响应数据的转发中间它不会做任何处理 为什么需要隧道代理呢
我们都知道https服务是需要网站有证书的而代理服务器显然没有所以浏览器和代理之间无法创建TLS所以就有了隧道代理它把浏览器的数据原样透传这样就实现了通过中间代理和服务端进行TLS握手然后进行加密传输
可能有人会问那还要代理干嘛直接请求服务器不是更好吗
代理服务器到底有什么好处呢
突破访问限制如访问一些单位或集团内部资源或用国外代理服务器(翻墙)就可以上国外网站看片等安全性更高上网者可以通过这种方式隐藏自己的IP免受攻击。还可以对数据过滤对非法IP限流等负载均衡客户端请求先到代理服务器而代理服务器后面有多少源服务器IP是多少客户端是不知道的。因此代理服务器收到请求后通过特定的算法(随机算法、轮询、一致性hash、LUR(最近最少使用) 算法这里不细说了)把请求分发给不同的源服务器让各个源服务器负载尽量均衡缓存代理将内容缓存到代理服务器(这个下面一节详细说)
代理最常见的请求头
Via
是一个能用首部由代理服务器添加适用于正向和反向代理在请求和响应首部均可出现这个消息首部可以用来追踪消息转发情况防止循环请求还可以识别在请求或响应传递链中消息发送者对于协议的支持能力详情请看MDN
Via: 1.1 vegur
Via: HTTP/1.1 GWA
Via: 1.0 fred, 1.1 p.example.netX-Forwarded-For
记录客户端请求的来源IP每经过一级代理(匿名代理除外)代理服务器都会把这次请求的来源IP追加进去
X-Forwarded-For: client,proxy1,proxy2注意与服务器直连的代理服务器的IP不会被追加进去该代理可能过TCP连接的Remote Address字段获取到与服务器直连的代理服务器IP
X-Real-IP
一般记录真实发出请求的客户端的IP还有X-Forwarded-Host和X-Forwarded-Proto分别记录真实发出请求的客户端的域名和协议名
代理中客户端IP伪造问题以及如何预防
X-Forwarded-For是可以伪造的比如一些通过X-Forwarded-For获取到客户端IP来限制刷票的系统就可以通过伪造该请求头达到刷票的目的如果客户端请求显示指定了 X-Forwarded-For192.168.1.108那么服务端收到的这个请求头第一个IP就是伪造的
预防
在对外Nginx服务器上配置 location / { proxy_set_header X-Forwarded-For $remote_addr } 这样第一个IP就是从TCP连接客户端的IP不会读取伪造的
从右到左遍历X-Forwarded-For的IP排除已知代理服务器IP和内网IP获取到第一个符合条件的IP就可以了
正向代理和反向代理
正向代理
工作在客户端的代理为正向代理。使用正向代理的时候需要在客户端配置需要使用的代理服务器正向代理对服务端透明。比如抓包工具Fiddler、Charles以及访问一些外网网站的代理工具都是正向代理 正向代理通常用于
缓存屏蔽某些不健康的网站通过代理访问原本无法访问的网站上网认证对用户访问进行授权
反向代理
工作在服务端的代理称为反向代理。使用反向代理的时候不需要在客户端进行设置反向代理对客户端透明。如Nginx就是反向代理 反向代理通常用于负载均衡、服务端缓存、流量隔离、日志、金丝雀发布
代理中的长连接
在各个代理和服务器、客户端节点之间是一段一段的TCP连接客户端通过代理访问目标服务器也叫逐段传输用于逐段传输的请求头叫逐段传输头。
逐段传输头会在每一段传输的中间代理中处理掉不会传给下一个代理
标准的逐段传输头有Keep-Alive、Transfer-Encoding、TE、Connection、Trailer、Upgrade、Proxy-Authorization、Proxy-Authenticate。
Connection头决定当前事务完成后是否关闭连接如果该值为keep-alive则连接是持久连接不会关闭使得对同一服务器的请求可以继续在该连接上完成
说一下 HTTP 缓存及缓存代理
关于http缓存在上一篇文章里有了详细介绍 (建议收藏)为什么第二次打开页面快五步吃透前端缓存让页面飞起
缓存代理就是让代理服务器接管一部分的服务端的http缓存客户端缓存过期之后就近到代理服务器的缓存中获取代理缓存过期了才请求源服务器这样流量大的时候能明显降低源服务器的压力
注意响应头字段
Cache-Control 值有public时表示可以被所有终端缓存包括代理服务器、CDN。值有private时只能被终端浏览器缓存CDN、代理等中继服务器都不可以缓存。
HTTPS
HTTPS 是超文本传输安全协议即HTTP SSL/TLS。说白了就是一个加强版的HTTP HTTP本文开始讲了所以我们要理解HTTPS的精华就要先弄清楚这个SSL/TLS了
SSL/TLS
一张图让你理解SSL和TLS的关系 如图TLS是SSL的升级版而且TLS1.2版本以下都已废弃目前主要用的是TLS 1.2和TLS 1.3。而OpenSSL则是开源版本的
那么它到底是个啥呢
浏览器和服务器通信之前会先协商选出它们都支持的加密套件用来实现安全的通信。常见加密套件
随便拿出一个加密套件举例如RSA-PSK-AES128-GCM-SHA256就是长这样代表什么意思呢我们看图 RSA表示握手时用RSA算法交换密钥PSK表示使用PSK算法签名AES128-GCM表示使用AES256对称加密算法通信密钥长度128分组模式GCM。TLS 1.3中只剩下称加密算法有AES和CHACHA20分组模式只剩下GCM和POLY1305SHA256表示使用SHA256算法验证信息完整性并生成随机数。TLS 1.3中哈希摘要算法只剩下SHA256和SHA384了
为什么需要用到这么多算法呢
为了保证安全TLS需要保证信息的机密性、可用性、完整性、认证性、不可否认性每一种算法都有其特定的用处
HTTPS 中 TLS 的加密算法
为什么说https是安全的 https一定是安全的吗考察https中间人劫持我另一篇有关于详细介绍网络安全 有什么解决办法 https的证书校验过程是怎么样的 证书校验用到了哪些算法
对称加密算法
就是加密和解密使用同一个密钥。如AES、DES。加解密过程
浏览器给服务器发送一个随机数client-random和一个支持的加密方法列表服务器给浏览器返回另一个随机数server-random和双方都支持的加密方法然后两者用加密方法将两个随机数混合生成密钥这就是通信双上加解密的密钥
问题是双方如何安全的传递两个随机数和加密方法直接传给客户端那过程中就很可能被窃取别人就能成功解密拿到数据往下看
不对称加密算法
就是一对密钥有公钥(public key)和私钥(private key)其中一个密钥加密后的数据只能让另一个密钥进行解密。如RSA、ECDHE。加解密过程
浏览器给服务器发送一个随机数client-random和一个支持的加密方法列表服务器把另一个随机数server-random、加密方法、公钥传给浏览器然后浏览器用公钥将两个随机数加密生成密钥这个密钥只能用私钥解密
使用公钥反推出私钥是非常困难但不是做不到随着计算机运算能力提高非对称密钥至少要2048位才能保证安全性这就导致性能上要比对称加密要差很多
所以
TLS实际用的是两种算法的混合加密。通过 非对称加密算法 交换 对称加密算法 的密钥交换完成后再使用对称加密进行加解密传输数据。这样就保证了会话的机密性。过程如下
浏览器给服务器发送一个随机数client-random和一个支持的加密方法列表服务器把另一个随机数server-random、加密方法、公钥传给浏览器浏览器又生成另一个随机数pre-random并用公钥加密后传给服务器服务器再用私钥解密得到pre-random浏览器和服务器都将三个随机数用加密方法混合生成最终密钥
这样即便被截持中间人没有私钥就拿不到pre-random就无法生成最终密钥。
可又有问题来了如果一开始就被DNS截持我们拿到的公钥是中间人的而不是服务器的数据还是会被窃取所以数字证书来了往下看先简单说一下摘要算法
摘要算法
主要用于保证信息的完整性。常见的MD5算法、散列函数、哈希函数都属于这类算法其特点就是单向性、无法反推原文
假如信息被截取并重新生成了摘要这时候就判断不出来是否被篡改了所以需要给摘要也通过会话密钥进行加密这样就看不到明文信息保证了安全性同时也保证了完整性
如何保证数据不被篡改签名原理和证书?
数字证书(数字签名)
它可以帮我们验证服务器身份。因为如果没有验证的话就可能被中间人劫持假如请求被中间人截获中间人把他自己的公钥给了客户端客户端收到公钥就把信息发给中间人了中间人解密拿到数据后再请求实际服务器拿到服务器公钥再把信息发给服务器
这样不知不觉间信息就被人窃取了所以在结合对称和非对称加密的基础上又添加了数字证书认证的步骤让服务器证明自己的身份
数字证书需要向有权威的认证机构(CA)获取授权给服务器。首先服务器和CA机构分别有一对密钥(公钥和私钥)然后是如何生成数字证书的呢
CA机构通过摘要算法生成服务器公钥的摘要(哈希摘要)CA机构通过CA私钥及特定的签名算法加密摘要生成签名把签名、服务器公钥等信息打包放入数字证书并返回给服务器
服务器配置好证书以后客户端连接服务器都先把证书发给客户端验证并获取服务器的公钥。
证书验证流程
使用CA公钥和声明的签名算法对CA中的签名进行解密得到服务器公钥的摘要内容再用摘要算法对证书里的服务器公钥生成摘要再把这个摘要和上一步得到的摘要对比如果一致说明证书合法里面的公钥也是正确的否则就是非法的
证书认证又分为单向认证和双向认证
单向认证服务器发送证书客户端验证证书双向认证服务器和客户端分别提供证书给对方并互相验证对方的证书
不过大多数https服务器都是单向认证如果服务器需要验证客户端的身份一般通过用户名、密码、手机验证码等之类的凭证来验证。只有更高级别的要求的系统比如大额网银转账等就会提供双向认证的场景来确保对客户身份提供认证性
HTTPS 连接过程和优化
我们知道了https就只是比http多了一步TLS连接
TLS连接是怎么回事呢根据TLS版本和密钥交换法不同过程也不一样有三种方式
RSA握手
早期的TLS密钥交换法都是使用RSA算法它的握手流程是这样子的
浏览器给服务器发送一个随机数client-random和一个支持的加密方法列表服务器把另一个随机数server-random、加密方法、公钥传给浏览器浏览器又生成另一个随机数pre-random并用公钥加密后传给服务器服务器再用私钥解密得到pre-random此时浏览器和服务器都得到三个随机数了各自将三个随机数用加密方法混合生成最终密钥
然后开始通信
TLS 1.2 版
TLS 1.2版的用的是ECDHE密钥交换法看图 浏览器给服务器发送一个随机数client-random、TLS版本和一个支持的加密方法列表服务器生成一个椭圆曲线参数server-params、随机数server-random、加密方法、证书等传给浏览器浏览器又生成椭圆曲线参数client-params握手数据摘要等信息传给服务器服务器再返回摘要给浏览器确认应答
这个版本不再生成椭圆曲线参数cliend-params和server-params而是在服务器和浏览器两边都得到server-params和client-params之后就用ECDHE算法直接算出pre-random这就两边都有了三个随机数然后各自再将三个随机加密混合生成最终密钥
TLS 1.3版
在TLS1.3版本中废弃了RSA算法因为RSA算法可能泄露私钥导致历史报文全部被破解而ECDHE算法每次握手都会生成临时的密钥所以就算私钥被破解也只能破解一条报文而不会对之前的历史信息产生影响所以在TLS 1.3中彻底取代了RSA。目前主流都是用ECDHE算法来做密钥交换的
TLS1.3版本中握手过程是这样子的 浏览器生成client-params、和client-random、TLS版本和加密方法列表发送给服务器服务器返回server-params、server-random、加密方法、证书、摘要等传给浏览器浏览器确认应答返回握手数据摘要等信息传给服务器
简单说就是简化了握手过程只有三步把原来的两个RTT打包成一个发送了所以减少了传输次数。这种握手方式也叫1-RTT握手
这种握手方还有优化空间吗
有的用会话复用
会话复用
会话复用有两种方式Session ID 和 Session Ticket
Session ID就是客户端和服务器首次连接手各自保存会话ID并存储会话密钥下次再连接时客户端发送ID过来服务器这边再查找ID如果找到了就直接复用会话密钥也不用重新生成
可是这样的话在客户端数量庞大的时候对服务器的存储压力可就大了
所以出来了第二种方式 Session Ticket就是双方连接成功后服务器加密会话信息用Session Ticket消息发给客户端存储起来下次再连接时就把这个Session Ticket解密验证有没有过期如果没有过期就复用会话。原理就是把存储压力分给客户端。
这样就万无一失了吗
No这样也存在安全问题。因为每次要用一个固定的密钥来解密Session Ticket一旦密钥被窃取那所有历史记录也就被破解了所以只能尽量避免这种问题定期更换密钥。毕竟节省了不少生成会话密钥和这些算法的耗时性能还是提升了嘛
那刚说了1-RTT那能不能优化到0-RTT呢
还真可以做法就是发送Session Ticket的时候带上应用数据不用等服务端确认。这种方式被称为PSK(Pre-Shared Key)
这样万无一失了吗
尴了个尬还是不行。这PSK要是被窃取人家不断向服务器重发就直接增加了服务器被攻击的风险
虽然不是绝对安全但是现行架构下最安全的解决文案了大大增加了中间人的攻击成本
HTTPS优缺点
优点
内容加密中间无法查看原始内容身份认证保证用户访问正确。如访问百度即使DNS被劫持到第三方站点也会提醒用户没有访问百度服务可能被劫持数据完整性防止内容被第三方冒充或篡改虽然不是绝对安全但是现行架构下最安全的解决文案了大大增加了中间人的攻击成本
缺点
要钱功能越强大的证书费用越贵证书需要绑定IP不能在同一个IP上绑定多个域名https双方加解密耗费更多服务器资源https握手更耗时降低一定用户访问速度(优化好就不是缺点了)
HTTP 和 HTTPS 的区别
HTTP是明文传输不安全的HTTPS是加密传输安全的多HTTP标准端口是80HTTPS标准端口是443HTTP不用认证证书免费HTTPS需要认证证书要钱连接方式不同HTTP三次握手HTTPS中TLS1.2版本7次TLS1.3版本6次HTTP在OSI网络模型中是在应用层而HTTPS的TLS是在传输层HTTP是无状态的HTTPS是有状态的
HTTPS 的性能优化
访问速度优化
会话复用上面说了复用session可以减少 CPU 消耗因为不需要进行非对称密钥交换的计算。可以提升访问速度不需要进行完全握手阶段二节省了一个 RTT 和计算耗时。使用 SPDY 或者 HTTP2。SPDY 最大的特性就是多路复用能将多个 HTTP 请求在同一个连接上一起发出去不像目前的 HTTP 协议一样只能串行地逐个发送请求。Pipeline 虽然支持多个请求一起发送但是接收时依然得按照顺序接收本质上无法解决并发的问题。HTTP2支持多路复用有同样的效果。设置HSTS服务端返回一个 HSTS 的 http header浏览器获取到 HSTS 头部之后在一段时间内不管用户输入www.baidu.com还是http://www.baidu.com 都会默认将请求内部跳转成https://www.baidu.com。Chrome, firefox, ie 都支持了 HSTS。Nginx设置Ocsp stapling。Ocsp 全称在线证书状态检查协议 (rfc6960)用来向 CA 站点查询证书状态比如是否撤销。通常情况下浏览器使用 OCSP 协议发起查询请求CA 返回证书状态内容然后浏览器接受证书是否可信的状态。这个过程非常消耗时间因为 CA 站点有可能在国外网络不稳定RTT 也比较大。如果不需要查询则可节约时间。False start。简单概括 False start 的原理就是在 clientkeyexchange 发出时将应用层数据一起发出来能够节省一个 RTT。
计算性能优化
优先使用 ECC椭圆加密算术使用最新版的 OpenSSLTLS 远程代理计算硬件加速方案
HTTP 版本
1991年HTTP 0.9版只有一个GET而且只支持纯文本内容早已过时就不讲了
HTTP 1.0(1996年)
任意数据类型都可以发送有GET、POST、HEAD三种方法无法复用TCP连接(长连接)有丰富的请求响应头信息。以header中的Last-Modified/If-Modified-Since和Expires作为缓存标识
HTTP 1.1(1997年)
引入更多的请求方法类型PUT、PATCH、DELETE、OPTIONS、TRACE、CONNECT引入长连接就是TCP连接默认不关闭可以被多个请求复用通过请求头connection:keep-alive设置引入管道连接机制可以在同一TCP连接里同时发送多个请求强化了缓存管理和控制Cache-Control、ETag/If-None-Match支持分块响应断点续传利于大文件传输能过请求头中的Range实现使用了虚拟网络在一台物理服务器上可以存在多个虚拟主机并且共享一个IP地址
缺点主要是连接缓慢服务器只能按顺序响应如果某个请求花了很长时间就会出现请求队头阻塞
虽然出了很多优化技巧为了增加并发请求做域名拆分、资源合并、精灵图、资源预取...等等
最终为了推进从协议上进行优化Google跳出来推出SPDY协议
SPDY(2009年)
SPDY读作“SPeeDY”是Google开发的基于TCP的会话层协议
主要通过帧、多路复用、请求优先级、HTTP报头压缩、服务器推送以最小化网络延迟提升网络速度优化用户的网络使用体验
原理是在SSL层上增加一个SPDY会话层以在一个TCP连接中实现并发流。通常的HTTP GET和POST格式仍然是一样的然而SPDY为编码和传输数据设计了一个新的帧格式。因为流是双向的所以可以在客户端和服务端启动
虽然诞生后很快被所有主流浏览器所采用并且服务器和代理也提供了支持但是SPDY核心人员后来都参加到HTTP 2.0开发中去了自HTTP2.0开发完成就不再支持SPDY协议了并在Chrome 51中删掉了SPDY的支持
HTTP 2.0(2015年)
说出http2中至少三个新特性
使用新的二进制协议不再是纯文本避免文本歧义缩小了请求体积多路复用同域名下所有通信都是在单链接(双向数据流)完成提高连接的复用率在拥塞控制方面有更好的能力提升使用HPACK算法将头部压缩用哈夫曼编码建立索表传送索引大大节约了带宽允许服务端主动推送数据给客户端增加了安全性使用HTTP 2.0要求必须至少TLS 1.2使用虚拟的流传输消息解决了应用层的队头阻塞问题
缺点
TCP以及TCPTLS建立连接的延时HTTP2使用TCP协议来传输的而如果使用HTTPS的话还需要TLS协议进行安全传输而使用TLS也需要一个握手过程在传输数据之前导致我们花掉3~4个RTTTCP的队头阻塞并没有彻底解决。在HTTP2中多个请求跑在一个TCP管道中但当HTTP2出现丢包时整个TCP都要开始等待重传那么就会阻塞该TCP连接中的所有请求
SPDY 和 HTTP2 的区别
头部压缩算法SPDY是通用的deflate算法HTTP2是专门为压缩头部设计的HPACK算法SPDY必须在TLS上运行HTTP2可在TCP上直接使用因为增加了HTTP1.1的Upgrade机制SPDY更加完善的协议商讨和确认流程SPDY更加完善的Server Push流程SPDY增加控制帧的种类并对帧的格式考虑的更细致
HTTP1 和 HTTP2
HTTP2是一个二进制协议HTTP1是超文本协议传输的内容都不是一样的HTTP2报头压缩可以使用HPACK进行头部压缩HTTP1则不论什么请求都会发送HTTP2服务端推送(Server push)允许服务器预先将网页所需要的资源push到浏览器的内存当中HTTP2遵循多路复用代替同一域名下的内容只建立一次连接HTTP1.x不是对域名有6~8个连接限制HTTP2引入二进制数据帧和流的概念其中帧对数据进行顺序标识这样浏览器收到数据之后就可以按照序列对数据进行合并而不会出现合并后数据错乱的情况同样是因为有了序列服务器就可以并行的传输数据这就是流所做的事情。HTTP2对同一域名下所有请求都是基于流的也就是说同一域名下不管访问多少文件只建立一次连接
HTTP 3.0/QUIC
由于HTTP 2.0依赖于TCPTCP有什么问题那HTTP2就会有什么问题。最主要的还是队头阻塞在应用层的问题解决了可是在TCP协议层的队头阻塞还没有解决。
TCP在丢包的时候会进行重传前面有一个包没收到就只能把后面的包放到缓冲区应用层是无法取数据的也就是说HTTP2的多路复用并行性对于TCP的丢失恢复机制不管用因此丢失或重新排序的数据都会导致交互挂掉
为了解决这个问题Google又发明了QUIC协议
并在2018年11月将QUIC正式改名为HTTP 3.0
特点
在传输层直接干掉TCP用UDP替代实现了一套新的拥塞控制算法彻底解决TCP中队头阻塞的问题实现了类似TCP的流量控制、传输可靠性的功能。虽然UDP不提供可靠性的传输但QUIC在UDP的基础之上增加了一层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其他一些TCP中存在的特性实现了快速握手功能。由于QUIC是基于UDP的所以QUIC可以实现使用0-RTT或者1-RTT来建立连接这意味着QUIC可以用最快的速度来发送和接收数据。集成了TLS加密功能。目前QUIC使用的是TLS1.3
结语
整理不易点赞支持
感谢你能看到这里希望对大家有用加油哦
