Welcome to天萌论坛(ノ≧∇≦)ノ
返回主页内容

信息

This section allows you to view all 信息 made by this member. Note that you can only see 信息 made in areas you currently have access to.

信息 - neko酱

1
水区 / 回复:最近的武汉肺炎有点可怕啊!
世卫组织更正报告:新冠肺炎疫情对全球构成高风险
2020-01-28 10:03:27 来源: 界面新闻

新冠状病毒疫情发生后,带着防护口罩的人们在中国深圳宝安机场接机。图片来源:联合国新闻/张静
世界卫生组织(WHO)在其发布的新型冠状病毒疫情报告中表示,在中国武汉爆发的疫情,对全球构成了“高风险”,并承认该组织此前指风险“中等”的说法不正确。
世卫组织在1月26日的新型冠状病毒疫情报告中指出,“中国面对的疫情风险非常高,而在区域与全球的风险水平属高。”
世卫组织在报告脚注中表示,该组织于本月23日、24日及25日发布的报告中称疫情风险“中等”是不正确的。

世卫组织报告脚注截图
26日、27日的报告中,对全球风险的措辞均已使用“高”。世卫组织发言人沙伊布(Fadela Chaib)表示,此前是“用词上的错误”。
世卫组织在27日的报告中称,截至当天共收到37例中国以外11国的确诊病例,据不完全统计,患者年龄在2岁到74岁之间,中位数为45岁,71%的患者为男性。

北京时间28日,德国和斯里兰卡也分别出现了该国的首个确诊病例。美国疾病控制与预防中心(CDC)当地时间27日也把针对中国的旅行预防措施提升至“警告”的最高级别。
据联合国新闻,世卫组织总干事谭德塞与该组织西太平洋区域主任葛西健27日抵达北京,与中国政府相关部门及卫生专家讨论新型冠状病毒疫情。
谭德塞表示,他希望能够了解疫情的最新进展,并加强与中国的合作,以继续为此次疫情提供支持和防护。世卫组织强调,如果齐心协力,我们就有机会战胜病毒。
3
水区 / 回复:最近的武汉肺炎有点可怕啊!


有个问题,如果自己身体不适,那么是否该去医院呢?
肯定有人会担心戴了不符合标准的口罩或忘记洗手,造成了交叉感染。
我觉得呢,如果是生病的话,那当然是要去的啦!
不过最好的解决方法是增强免疫力和抵抗力,保持良好的作息和饮食习惯,不要让自己生病!
2020年,希望大家都健健康康的!(*˘︶˘*).。*♡
6
水区 / 回复:最近的武汉肺炎有点可怕啊!
原来18年也有新型冠状病毒啊!

原视频链接 http://tv.cctv.com/2018/04/06/VIDEqHGaS6gzKEdORECZ5AVy180406.shtml
进度条拉到20分。
蝙蝠是多种冠状病毒的自然储存宿主,SADS冠状病毒的发现与溯源研究证实,蝙蝠携带的某些冠状病毒可跨种传播至家畜并造成严重疾病。不过,SADS冠状病毒当时还只限定在猪致病,并没有证据显示SADS冠状病毒可进一步跨种感染人。
本次的"2019-nCoV病毒"和此前的“SADS冠状病毒”,在分类学上不是一个“种”。
香港大学公共卫生学院副教授朱华晨称:“本次的武汉肺炎病毒属于β里的B小组,而此前在猪场爆发的新型冠状病毒属于α组,它们可以感染的宿主是不一样的。”
中科院武汉病毒所研究员石正丽说:“从中国疾病预防控制中心病毒病预防控制所分离的电镜照片来看,‘2019-nCoV’和2018年发现的新型冠状病毒‘SADS冠状病毒’大概长得一样,但里面的遗传物质和遗传信息不同。”

【中国乃至全亚洲首个P4实验室就在武汉,大家要相信专家们有能力应对这次病毒危机】
什么是P4实验室?
据传染病原的传染性和危害性,国际上将生物安全实验室分为P1、P2、P3和P4四个生物安全等级。P4实验室是专用于烈性传染病研究与利用的大型装置,是人类迄今为止能建造的生物安全防护等级最高的实验室。如埃博拉病毒等对人体具有高度危险性、但尚无预防和治疗方法的病毒必须在P4实验室中进行研究。此前全球只有少数发达国家拥有这类装置。
在03年SARS爆发后,我国政府战略性启动P4实验室的建设。武汉P4实验室由中国科学院和湖北省人民政府、国家卫生健康委员会共同建设,中科院武汉病毒所承建,参照国际上高等级生物安全实验室的建设要求和中国相关的建设标准,在引进法国里昂P4实验室技术和装备基础上,中法双方设计单位合作完成了实验室的设计,中国建设单位完成了实验室的建设和主要设施设备的安装,历经逾十年建造完成。
7
水区 / 最近的武汉肺炎有点可怕啊!
最可怕的地方在于截止2020年1月27号,还没有特效药可以医治。
据说用那种抗艾滋病的药物,会有很大的后遗症,具体我也不是很清楚。
另一个可怕的地方在于潜伏时期长,潜伏期间仍具有传染性。也就是说在你面前一个活蹦乱跳的人,他可能就是行走的病原体。
不要看它表面上死亡率很低就掉以轻心,它的传染力真的是太强了。
有些人是无辜被感染上的,就因为坐的高铁在武汉站停留了数分钟,结果被传染了。

还有"超级传播者"的存在,我之前就看新闻说,武汉有一个"超级传播者",仅一人就感染了十多名医护人员。
除了感染性外,还有破坏性和不确定性。
听说发病后只要几天时间,肺部就全变白了,太可怕了。
我们目前面对的这个新型冠状病毒就已经很棘手,要是病毒再发生变异就更棘手了。

由于RNA复制时极易出错,复制过程中参与的酶不能进行校正,因此RNA病毒有很高的突变概率。

十多年前的时候,国内也爆发了一场令人闻风丧胆的灾难---"非典型性肺炎",也就是我们熟知的"SARS",又名“非典”。

我是广东人,03年的时候,我真的是太小了,完全没有当时的记忆。
问了下爷爷奶奶,他们都说当年的非典没有现在这么厉害。

我又查了下百科,大概了解到了非典时期的情况。
非典最初是在广东爆发,最终结果却是北京比广东更加严重,原因可能是北京市市长隐瞒了患病的真实情况。
虽然现在也有可能存在瞒报的情况,但是起码能让民众唤起防范意识。
前几天,汕头市还准备要封城。
我也是不是很懂为什么广州、深圳这么多例不封,汕头才两例就要封城,真相是。。。你自己去猜吧!
结果不到一天,就又决定取消掉。

这事是真的,不是谣言,是那些看起来很可靠的媒体发布的。

前不久,广东省卫健委还出台相关规定,在公众场所不戴口罩会被处罚。😷
我不知道是罚的钱比较多,还是口罩比较贵。。。。
更不用说现在根本买不到口罩!!!!ಠ﹏ಠ


2020鼠年,祝大家双肺纹理分布和走形正常,肺内未见实质性病灶,肺门不大,纵膈居中,心影不大,膈面光整肋膈角锐利。血尿常规正常,CRP正常,核酸检测阴性,鼠年吉祥,数一数二,心有所属,属你最棒!
新年快乐!(≧▽≦)
13
水区 / 回复:🤣现在这年头也只剩机器人肯访问本论坛了
    HTTP / 3:从头到脚的介绍
以下科普内容转自https://blog.cloudflare.com/zh/http-3-from-root-to-tip-zh/
HTTP是支持Web的应用程序协议。在1991年,它以所谓的HTTP/0.9协议开始,到1999年发展为HTTP/1.1,并在IETF (Internet Engineering Task Force)中标准化。HTTP/1.1在很长一段时间内已经表现得足够好了,但是Web上不断变化的需求使得我们需要一个更适合的协议,于是HTTP/2在2015年出现了。最近又有新闻宣称IETF打算提供一个新版本——HTTP/3。对一些人来说,这是一个惊喜,同时也带来了一些困惑。如果您不密切关注IETF的工作,那么对你来说HTTP/3可能会看起来像是突然出现的。然而,我们可以通过一系列实验和Web协议的发展来追溯它的起源;特别是QUIC传输协议。
如果你不熟悉QUIC,那么请允许我介绍我的同事们,他们在处理不同角度的QUIC问题方面做得很好。John的博客描述了当今HTTP的一些现实世界的烦恼,Alessandro的博客解决了传输层的一些细节问题,而Nick的博客讨论了如何开展一些测试。我们已经在https://cloudflare-quic.com收集了这些信息以及更多内容。如果你喜欢的话,一定要看看quiche,它是我们用Rust编写的QUIC协议的开源实现。
HTTP / 3是映射到QUIC传输层的HTTP应用程序。这个名称是在最近的草案版本17(draft-ietf-quic-http-17)中正式定义的,该草案于2018年10月底提出,于11月在曼谷举行的IETF 103会议期间得到了讨论并形成初步共识。HTTP / 3被称为HTTP over QUIC,再这之前又被称为QoS / 2 over QUIC。在那些之前,我们已经有了HTTP/2 over gQUIC,其根源是SPDY over gQUIC。然而事实上,HTTP / 3只是一种新的HTTP语法,适用于IETF QUIC——一种基于UDP的多路复用安全传输。
在这篇博文中,我们将探讨一些HTTP / 3以前的名字背后的历史,并介绍其最近更改名称背后的动机。我们将回到HTTP的早期,并讨论此过程中所有的出色工作。如果您希望获得完整的信息,可以跳到文章末尾或点开这个非常详细的SVG版本

一个HTTP / 3层蛋糕

设置场景
在我们关注HTTP之前,有必要提醒一下自己,有两个协议是共享QUIC的名称。如之前所述,gQUIC通常用于标识谷歌QUIC(原始协议),而QUIC通常用于表示与gQUIC不同的IETF正在开发的标准版本。
从90年代初期开始,网络的需求就发生了变化。我们已经有了新版本的HTTP,并以安全传输层协议(TLS)的形式增加了用户安全性。我们只会这篇文章中讨论TLS,如果您想更详细地探索该领域,可以阅读我们的其他博客文章,这些都是很好的资源。
为了让我能更好的解释HTTP和TLS的历史,我开始整理协议规范和日期的细节。这些信息内容通常是文本形式的,例如按日期排序的说明文档标题的项目符号点列表。然而,还有一些分支标准,各个标准在时间上重叠,简单的列表无法表达其中关系的真实复杂性。在HTTP中,已经有了一些并行工作,这些工作重构核心协议定义,以便更容易地使用,扩展协议的新用途,并重新定义协议如何在Internet上交换数据以提高性能。当你试图跨越近30年的互联网历史,跨越不同分支的工作流程,将这些点连接起来时,你就需要一个可视化的界面。所以我制作了一个 – Cloudflare安全网络时间线。(注意:从技术上讲,它是一个分段图,但术语时间线更广为人知。)
我在创建这个应用程序时使用了一些创作者授权,选择将目光放在IETF空间中成功的分支上。还有一些内容没有显示出来,包括W3联合HTTP-NG工作组的努力成果,以及他们的作者热衷于解释如何发音的一些奇特的想法:  HMURR(发音为'hammer')WAKA(发音为“wah-kah”) )
在接下来的几节中,我将沿着这个时间线来解释HTTP历史上的关键章节。如果你想要从这篇文章中有所收获,那么了解标准化为什么是有益的以及IETF如何实现标准化将会对你有所帮助。因此,在回到时间线本身之前,我们将从该主题的一个非常简短的概述开始。如果您已经熟悉IETF,请跳过下一节。
互联网标准的类型
通常,标准定义了共同的参考术语,范围,约束,适用性和其他考虑因素。标准以多种形式和大小存在,可以是非正式的(也就是事实上的)或正式的(由标准定义组织(例如IETF,ISO或MPEG)商定/发布)。许多领域都有标准存在,甚至还有正式的英国制茶标准 - BS 6008。
早期的Web使用发布在IETF之外的HTTP和SSL协议定义,这些定义被标记为安全Web时间线上的红线。客户端和服务器对这些协议的采用使它们成为事实上的标准。
到了一定程度以后,人们决定正式化这些协议(一些激励原因将在后面的部分中描述)。互联网标准通常在IETF中定义,它遵循“粗略共识和运行代码”的非正式原则。这是基于在Internet上开发和部署内容的经验。这与尝试在真空中开发完美协议的“洁净室”方法有所差异。
IETF Internet标准通常称为RFC。这是一个很难解释的复杂区域,因此我建议您阅读由QUIC工作组联合主席Mark Nottingham撰写的博客文章“ 如何阅读RFC ”。工作组或多或少只是一个邮件列表。
ETF每年举行三次会议,为所有工作组提供时间和设施,以便他们按意愿亲自见面。这几周的议程可能会变得非常拥挤,人们只有有限的时间深入讨论高度技术性的领域问题。为了解决这个问题,一些工作组选择在IETF会议之间的几个月内举行临时会议。这有助于保持规范开发的势头。自2017年以来,QUIC WG已举行了几次临时会议,这里的会议页面上展示了完整的会议列表。
这些IETF会议同样为其他与IETF相关的人员提供了见面的机会,例如互联网架构委员会互联网研究工作组。近年来,在IETF会议之前的周末举行了一场IETF 黑客马拉松。这为社区提供了开发运行代码的机会,更重要的是,人们可以在同一房间与其他人员进行互操作性测试。这有助于发现规范中的问题,这些问题可以在接下来的几天中讨论。
出于本博客的目的,需要理解的重要一点是rfc并不是凭空出现的。相反,它们要经历一个过程,通常从提交考虑采用的IETF Internet Draft (I-D)格式开始。在已经发布了规范的情况下,I-D的准备可能只是一个简单的重新格式化练习。I-D从发布之日起有6个月的有效期。要使它们保持活动状态,则需要发布新的版本。在实践中,让I-D消失并没有太大的后果,而且这种事情经常发生。这些文档一直放在IETF文档的网站上,供任何想要阅读它们的人使用。
I-D在安全Web时间线上以紫线表示。每一个都有其唯一的名称,其形式为draft-{author name}-{working group}-{topic}-{version}。工作组字段是可选的,它可能会预测IETF WG将在该文件上工作,以及有时预测即将发生的变化。如果IETF采用了I-D,或者I-D是直接在IETF内启动的,则名称为draft-ietf- {working group} - {topic} - {version}。I-Ds可能会中途产生分支,合并或失效。从版本00开始,每次发布新草稿时版本号增加1。例如,I-D的第4稿将具有版本03。只要I-D更改名称,其版本将重置为00。
值得注意的是,任何人都可以向IETF提交I-D; 你不应该把它们当作标准。但是,如果I-D的IETF标准化过程确实达成共识,并且最终文件通过了审核,我们最终会获得RFC。在此阶段,名称再次发生变化。每个RFC都有一个唯一的编号,例如RFC 7230。这些在安全Web时间线上以蓝线表示。
RFC是不可变的文档。这意味着对RFC的更改需要一个全新的编号。更改可能是为了包含对错误(发现并报告的编辑或技术错误)的修复,或者只是重构规范以改进布局。RFC可能会淘汰旧版本(完全替换),或者只更新它们(实质性更改)。
所有IETF文档均可在http://tools.ietf.org上公开获取。就个人而言,我发现IETF Datatracker对用户更友好,因为它提供了从I-D到RFC的文档进度的可视化进程。
下面是一个显示RFC 1945 - HTTP / 1.0 开发的示例,它是安全 Web时间线的灵感来源。

RFC 1945的IETF Datatracker视图

有趣的是,在我的工作过程中,我发现上面的视图是不正确的。由于某种原因,它缺少了draft-ietf-http-v10-spec-05。由于I-D的有效期为6个月,因此在其成为RFC之前似乎有一段空白,而实际上草案05直到1996年8月仍保持有效。
探索安全Web时间线
只要稍微了解一下Internet标准文档是如何实现的,我们就可以开始了解安全Web时间线了。在本节中,有一些摘录图表显示了时间线的重要部分。每个点都代表文档或功能可用的日期。对于IETF文档,为清楚起见,这里省略了草稿编号。但是,如果您想查看所有详细信息,请查看完整的时间线
HTTP在1991年开始被使用,称为HTTP / 0.9协议,并且在1994年I-D draft-fielding-http-spec-00也正式面世。这一ID很快被IETF采用,更名为draft-ietf-http-v10-spec-00。 在1996年该I-D作为RFC 1945 - HTTP / 1.0 发布之前已经经历了6个草案版本。



然而,即使在HTTP / 1.0工作完成之前,也已经有在HTTP / 1.1上启动的单独活动了。I-D draft-ietf-http-v11-spec-00于1995年11月发布,并于1997 年正式发布为RFC 2068.敏锐的人就会发现安全Web时间线并不能完全捕获该事件序列,这是用于生成视图的工具的一个不幸的副作用。我会尽量使这些问题最小化。
HTTP / 1.1的修订工作在1997年中期以draft-ietf-http-v11-spec-rev-00的形式正式开始。在1999年,随着RFC 2616的出版,这项工作才完成。直到2007年,IETF HTTP世界才结束了频繁的修订。我们很快就会讲到这一点。
SSL和TLS的历史



让我们把话题切换到SSL。我们看到SSL 2.0规范是在1995年左右发布的,SSL 3.0于1996年11月发布。有趣的是,据RFC 6101描述,SSL 3.0是于2011年8月发布的。根据IETF的说法,这属于历史范畴,“通常用来记录被考虑和抛弃的想法,或者在决定记录它们时已经具有历史意义的协议。”在这种情况下,拥有一个描述SSL 3.0的IETF专属文档是有利的,因为它可以用在其他地方的规范引用。
我们更感兴趣的是SSL如何启发了TLS的开发,TLS 于1996年11月以draft-ietf-tls-protocol-00的形式出现。它经历了6个草案版本,并在1999年初发布为RFC 2246 -TLS 1.0 。
1995年至1999年间,SSL和TLS协议被用于保护Internet上的HTTP通信。从事实上的标准来看,它运行的很好。直到1998年1月,随着I-D draft-ietf-tls-https-00的发布,HTTPS的正式标准化过程才开始。该工作于2000年5月结束,发表了RFC 2616-HTTP over TLS。
随着TLS 1.1和1.2的标准化,TLS在2000年至2007年间继续发展。间隔7年后TLS的下一版本工作才开始,该版本在2014年4月被采纳为draft-ietf-tls-tls13-00,并且在28次草案之后,在2018年8月作为RFC 8446 -TLS 1.3完成。
互联网标准化进程
在仔细观察时间线后,我希望您能够了解IETF的工作原理。互联网标准形成方式的一个概括是,研究人员或工程师设计适合其特定用例的实验协议。他们在不同规模的公共或私人场合试验协议。这些数据有助于识别改进或问题。这项工作可能被发布出来用以解释实验,从而收集更广泛的意见或帮助找到其他实施者。其他人从事这项早期工作可能会使其成为行业标准; 最终可能有足够的动力使正式标准化。
对于正在考虑实施,部署或以某种方式使用协议的组织而言,协议的状态可能是一个重要的考虑因素。一个正式的标准化过程可以使事实标准更具吸引力,因为它往往具有稳定性。管理和指导的过程由IETF等组织进行,这背后是更广泛的经验支撑。但是,值得强调的是,并非所有正式标准都能成功。
创建最终标准的过程几乎与标准本身一样重要。从具有更广泛的知识、经验和用例的人那里获取最初的想法并邀请他们做出贡献,可以帮助产生对更广泛的人群更有用的东西。然而,标准化过程并不总是那么容易。这其中存在陷阱与障碍。有时,该过程花费了太多的时间以至于产出与目的不再相关。
每个标准定义组织都倾向于拥有自己的流程,该流程针对其领域和参与者。解释有关IETF如何工作的所有细节远远超出了本博客的范围。如果你想了解这些细节,那么IETF的“ 我们如何工作 ”页面会是一个很好的着手点,其中涵盖了许多方面的内容。像往常一样,形成理解的最佳方法就是参与其中。这可以像加入电子邮件列表或在相关GitHub存储库中添加讨论一样简单。
Cloudflare的运行代码
Cloudflare很自豪能够成为新的和不断发展的协议的早期采用者。我们有一个早期采用新标准的很长的记录,例如HTTP / 2。我们还测试了一些尚处于试验阶段的或尚未完成的功能特性,如TLS 1.3SPDY
在IETF标准化过程中,将这些运行中的代码部署到不同站点的真实网络上,可以帮助我们了解协议在实践中的运作情况。我们将现有的专业知识与实验信息相结合,以帮助改进运行代码,并在有意义的情况下,对正在进行标准化协议的工作组进行反馈和改进。
测试新事物不是唯一的优先事项。 成为创新者的一部分要领是知道什么时候该向前推进并将老的创新放在身后。这有时会涉及面向安全的协议,例如,由于POODLE漏洞,Cloudflare 默认禁用SSLv3。在其他情况下,协议会被技术更先进的协议取代; Cloudflare 不赞成使用SPDY支持HTTP / 2。
相关协议的引入和弃用在Secure Web时间线上表示为橙线。垂直虚线线有助于将Cloudflare事件与相关的IETF文档相关联。例如,Cloudflare在2016年9月引入了TLS 1.3支持,在两年后的2018年8月发布了最终文档RFC 8446



在HTTPbis中重构
HTTP / 1.1是一个非常成功的协议,时间线显示1999年之后IETF没有太多活动。然而,真实的反映是多年的积极使用提供了实施经验,让人们发现了RFC 2616的潜在问题,并引发了一些互操作性问题。此外,该协议还被其他RFC(如2817和2818)扩展。2007年,一项新活动被决定启动,用以改进HTTP协议规范。这被称为HTTPbis(其中“bis”源于拉丁语意为“两个”,“两次”或“重复”), 并以新的工作组的形式出现。这里的原始章程很好地描述了人们试图解决这个问题的过程。
简而言之,HTTPbis决定重构RFC 2616。它将包含勘误修复,并补进在此期间发布的其他规范的某些方面。文档被分成了几部分。这是2007年12月发布的6个I-D的来源:[/font][/size][/color]
  • draft-ietf-httpbis-p1-messaging
  • draft-ietf-httpbis-p2-semantics
  • draft-ietf-httpbis-p4-conditional
  • draft-ietf-httpbis-p5-range
  • draft-ietf-httpbis-p6-cache
  • draft-ietf-httpbis-p7-auth



该图显示了这项工作是如何通过长达7年的起草过程进行的,在最终标准化之前有27个草案版本被发布。2014年6月,所谓的RFC 723x系列(其中x的范围从0到5)发布。HTTPbis 工作组的主席用“ RFC2616已死 ”来庆祝这一成就。如果还不清楚,可以看下这些废弃旧的RFC 2616的新文件。
这与HTTP / 3有什么关系?
虽然IETF正忙着研究RFC 723x系列,但世界并未停止。人们继续在互联网上增强,扩展和试验HTTP。其中包括谷歌,谷歌已经开始试验一种名为SPDY(发音为speedy)的协议。该协议被吹捧可以提高Web浏览的性能,这是HTTP的一个主要用例。在2009年底,SPDY v1被宣布,紧接着2010年SPDY v2又很快被推出。
我想避免讨论SPDY的技术细节。这是另一个很大的话题。重要的是,要了解SPDY采用HTTP的核心范例并稍微修改交换格式以获得改进。事后看来,我们可以看到HTTP已经明确划分了语义和语法。语义描述了请求和响应交换的概念,包括:方法,状态代码,头字段(元数据)和主体(有效负载)。语法描述了如何将语义映射到线路上的字节。
HTTP / 0.9,1.0和1.1共享许多语义。它们还共享通过TCP连接发送的字符串形式的语法。SPDY采用HTTP / 1.1语义并将语法从字符串更改为二进制。这是一个非常有趣的话题,但我们今天不会深入讨论这个问题。
Google对SPDY的实验表明,改变HTTP语法是有希望的,并且保留现有HTTP语义是有价值的。例如,保持URL的格式来使用https://可以避免许多可能影响采用的问题。
看到一些积极的结果后,IETF决定是时候考虑HTTP / 2.0的样子了。2012年3月IETF 83期间举行的HTTPbis会议的幻灯片显示了展示了制定的需求、目标和成功的度量。它还明确指出“HTTP / 2.0仅意味着连接格式与HTTP / 1.x的格式不兼容”。



在那次会议期间,社区被邀请分享提案。提交审议的I-D包括draft-mbelshe-httpbis-spdy-00draft-montenegro-httpbis-speed-mobility-00draft-tarreau-httpbis-network-friendly-00。最终,SPDY草案获得通过,并且人们从2012年11月起开始草案-ietf-httpbis-http2-00的工作。在短短两年多的时间内,RFC 7540 -HTTP / 2经过了18次草案,最终于2015年发布。在此规范期间,HTTP / 2的精确语法分歧,足以使HTTP / 2和SPDY不兼容。
这些年来,IETF的HTTP相关工作非常繁忙,HTTP/1.1重构和HTTP/2标准化同时进行。这与21世纪初多年的平静形成鲜明对比。请务必查看完整的时间线,以真正欣赏人们在其中所做的工作。
尽管HTTP / 2正处于标准化阶段,但使用和试验SPDY仍然有好处。Cloudflare 在2012年8月引入了对SPDY的支持,并且仅在2018年2月弃用它,因为当时我们的统计数据显示不到4%的Web客户继续想要SPDY。同时,我们在2015年12月推出HTTP / 2支持,就在RFC发布后不久,我们的分析表明,相当一部分Web客户端可以利用它。
支持SPDY和HTTP/2协议的Web客户端首选使用TLS的安全选项。2014年9月通用SSL的引入有助于确保所有在Cloudflare注册的网站都能够在我们引入这些新协议时利用它们。
gQUIC
谷歌在2012年至2015年期间继续进行实验,他们发布了SPDY v3和v3.1。他们也开始研究gQUIC(当时读作quick),并于2012年初发布了最初的公开规范。
gQUIC的早期版本使用了SPDY v3形式的HTTP语法。这个选择很有意义,因为HTTP / 2还没有完成。SPDY二进制语法被打包成可以在UDP数据报中发送的QUIC数据包。这与HTTP传统上依赖的TCP传输有所不同。当把所有这些放在一起,这看起来就像是:

SPDY over gQUIC层蛋糕

gQUIC使用巧妙的技巧来达到一定的性能。其中之一是打破应用程序和传输之间的明确分层。这在实际中意味着gQUIC只支持HTTP。因此,当时被称为“QUIC”的gQUIC成为了HTTP的下一个候选版本的同义词。尽管QUIC在过去几年中不断发生变化,我们稍后会讲到,直到今天,人们仍然将QUIC这个术语视为最初的HTTP-only变体。不幸的是,这在讨论协议时经常会引起混淆。
gQUIC继续进行实验并最终切换到更接近HTTP / 2的语法。事实上这是如此接近以至于大多数人简称它为“HTTP / 2 over QUIC”。然而,由于技术限制,它们之间还存在一些非常微妙的差异。其中一个例子便是与HTTP头文件的序列化和交换有关的。虽然是一个微小的差异,但这实际上意味着gQUIC上的HTTP / 2与IETF的HTTP / 2不兼容。
最后但同样重要的是,我们总是要考虑互联网协议的安全性方面。gQUIC选择不使用TLS来提供安全性。相反,Google开发了一种名为QUIC Crypto(QUIC加密)的不同方法。其中一个有趣的方面是它加速了安全握手。先前与服务器建立安全会话的客户端可以重用信息来执行“零往返时间”或0-RTT握手。0-RTT后来被合并到TLS 1.3中。
我们现在可以说出HTTP / 3是什么了吗?
几乎可以了。
到目前为止,您应该熟悉标准化的工作原理,而gQUIC并没有太大的不同。人们有足够的兴趣将Google规范编写成I-D格式。2015年6月,题为“QUIC:基于UDP的HTTP / 2安全可靠传输”的draft-tsvwg-quic-protocol-00被呈报出来。请记住我之前的声明的语法几乎是HTTP / 2。
谷歌宣布将在布拉格的IETF 93举行Bar BoF。对于那些好奇“Bar BoF”是什么的人,请参阅RFC 6771。提示:BoF代表同一类人(Birds of a Feather,俗语:物以类聚)。



简而言之,与IETF合作的结果是,QUIC似乎在传输层提供了许多优势,并且它应该与HTTP分离。应该重新引入层之间的明确分离。此外,有人倾向于返回基于TLS的握手(由于TLS 1.3正在此阶段中进行,并且包含了0-RTT握手,因此这并没有那么糟糕)。
大约一年后,在2016年,一套新的I-D被呈交:[/font][/size][/color]
这里是关于HTTP和QUIC的另一个困惑之处。draft-shade-quic-http2-mapping-00的标题是“使用QUIC传输协议的HTTP / 2语义”,它将自己描述为“HTTP / 2语义在QUIC上的映射”。然而,这样的用词是不恰当的。HTTP / 2是关于在保持语义的同时改变语法的。此外,由于我之前概述的原因,“HTTP / 2 over gQUIC”从未对语法进行准确描述。对此保留个人意见吧。
这个IETF版本的QUIC是一个全新的传输协议。这是一项艰巨的任务,在一头栽进此类任务之前,IETF喜欢评估其成员的实际兴趣。为此,2016年在柏林举行的IETF 96会议上,IETF举行了正式的Birds of a Feather(同类之人)会议。我很幸运能够亲自参加会议但幻灯片不能说明问题。如Adam Roach的照片所示,数百人参加了会议。在会议结束时我们达成了共识; QUIC将被IETF采用并标准化。
第一个用于将HTTP映射到QUIC的IETF QUIC I-D,draft-ietf-quic-http-00,采用Ronseal方法并将其名称简化为“HTTP over QUIC”。不幸的是,它没有完全完成这项工作,而且在整个主体中有许多HTTP/2术语的实例。I-Ds新编辑Mike Bishop发现了这一点并开始修复HTTP / 2的错误名称。在01草案中,前面的描述改为“基于QUIC的HTTP语义映射”。
随着时间推移和版本增加,术语“HTTP / 2”的使用逐渐减少了,实例仅仅是对RFC 7540部分的引用。时间推移两年到2018年10月,I-D现在是第16版。虽然QUIC上的HTTP与HTTP / 2相似,但它终究是一个独立的,非向后兼容的HTTP语法。然而,对于那些没有非常密切关注IETF发展的人(地球人口的很大一部分),文档名称并没有捕捉到这种差异。标准化的一个要点是帮助沟通和互操作。然而,命名这种简单的事情是造成社区混乱的主要原因。
回想一下在2012年的内容里所说的,“HTTP / 2.0仅表示连接格式与HTTP / 1.x不兼容”。IETF遵循现有的提示。在经过IETF 103之前和期间进行了大量的讨论后,人们一致同意将“HTTP over QUIC”重命名为HTTP / 3。世界现在变得更好了,我们可以继续进行更重要的讨论。
但RFC 7230和7231不同意您对语义和语法的定义!
有时文档标题可能会令人困惑。当前描述语法和语义的HTTP文档是:

  • RFC 7230 - 超文本传输协议(HTTP / 1.1):消息语法和路由
  • RFC 7231 - 超文本传输协议(HTTP / 1.1):语义和内容
人们有可能对这些名称进行过度的解读,并认为基本HTTP语义是特定于HTTP版本的,即HTTP / 1.1。但是,这是HTTP家族树的意外副作用。好消息是HTTPbis工作组正在努力解决这个问题。
一些勇敢的成员正在进行另一轮文件的修订,正如Roy Fielding所说,“再来一次!”。这项工作正在进行中,被称为HTTP核心活动(您可能也听说过HTTPtre或HTTPter这个名称;命名事物是困难的)。这将把六个草案缩减为三个:

  • HTTP语义(draft-ietf-httpbis-semantics)
  • HTTP缓存(draft-ietf-httpbis-caching)
  • HTTP / 1.1消息语法和路由(draft-ietf-httpbis-messaging)
在这种新结构下,HTTP / 2和HTTP / 3显然是通用HTTP语义的语法定义。这并不意味着它们除了语法之外没有自己的特性,但它应该有助于构建讨论的框架。
把它们放到一起
本文简要介绍了过去三十年IETF中HTTP的标准化过程。在没有触及很多技术细节的情况下,我试图解释我们今天是如何使用HTTP/3的。如果您跳过中间的好位并且正在寻找一句概括性的话,那么它是:HTTP / 3只是一种新的HTTP语法,适用于IETF QUIC,这是一种基于UDP的多路复用和安全传输。有许多有趣的技术领域需要我们进一步去探索,但这不是一天就能完成的。
在这篇文章中,我们探讨了HTTP和TLS开发中的重要章节,但这些章节是独立的。我们通过将它们全部整合到下面提供的完整安全Web时间线中来作为这篇博客的结尾。您可以使用它来自行调查详细的历史记录。对于超级侦探们,请务必查看完整版本,包括草案编号



14
水区 / 🤣现在这年头也只剩机器人肯访问本论坛了
上周,我发现r.tmoe.me有好几条wp_login以及其它wp相关的错误域名访问记录。
看了一下nginx访问日志,发现是一个伪装成win7 UA的用户所为。
可能是黑客,也可能是自动化扫描程序。
最大的可能性是他想利用wordpress漏洞来获取管理员权限。
拜托,我从来不用wordpress啊!  :evil:
而且他才试了十几次就放弃了,怎么就轻言放弃了呢?
rsshub的监控界面是长这样的,具体的参数配置需要到后端去调整,他应该是没那么容易就能入侵的。

而且rsshub有啥好入侵的?既没有权限,也没有重要数据,入侵前至少要做好准备功课啊!
比如说用nmap扫描一下端口号什么的。

现在只剩机器人愿意访问本论坛了,比如下面那位广告机器人。

现在的机器人都喜欢伪装成windows系统吗?
而且现在的机器人也太鸡精了吧,能轻易突破Google reCAPTCHA人机身份验证,成功点击了图片上所有交通灯、汽车、公交车、自行车、人行道和消防栓。
哎!

关于本域名HTTP/3访问数据的解析。

如上图所示,本域名(*.tmoe.me)HTTP/3访问率高达37%。
这年头有多少网站会部署HTTP/3?
给你个网站,你自己去测试https://http3check.net/
服务端方面:nginx官方去年就说即将支持HTTP/3,结果到现在才还没支持。
虽说可以在nginx上加cloudflare quiche模块https://github.com/cloudflare/quiche
或者直接直接套Cloudflare CDN,但这也掩盖不了HTTP/3没有普及的现实。
又有多少人会用HTTP/3去访问网站?

客户端方面:chrome79~82还要加http/3的启动参数才能支持。
哎,不用想也知道HTTP/3的访问量来自于谁?
至于HTTP/2,绝大多数都是我的rss机器人,只有极少部分是访客。
还有HTTP/1.1,可能是其它机器人。
:chart_with_downwards_trend: