韩淼燃
最近在更新运维专栏。欢迎大家来点赞,关注。
展开
-
40 | HTTP性能优化面面观(下)
今天我们继续上次的话题,看看 HTTP 性能优化有哪些行之有效的手段。上一讲里我说到了,在整个 HTTP 系统里有三个可优化的环节,分别是服务器、客户端和传输链路(“第一公里”和“中间一公里”)。但因为我们是无法完全控制客户端的,所以实际上的优化工作通常是在服务器端。这里又可以细分为后端和前端,后端是指网站的后台服务,而前端就是 HTML、CSS、图片等展现在客户端的代码和数据。知道了大致的方向,HTTP 性能优化具体应该怎么做呢?总的来说,任何计算机系统的优化都可以分成这么几类:硬件软件、内部外部、花钱不原创 2022-07-03 09:59:22 · 134 阅读 · 0 评论 -
39 | HTTP性能优化面面观(上)
“透视 HTTP 协议”这个专栏已经陪伴了你近三个月的时间,在最后的这两讲里,我将把散落在前面各个章节的零散知识点整合起来,做一个总结,和你一起聊聊 HTTP 的性能优化。由于 HTTPS(SSL/TLS)的优化已经介绍的比较详细了,所以这次就暂时略过不谈,你可以课后再找机会复习。既然要做性能优化,那么,我们就需要知道:什么是性能?它都有哪些指标,又应该如何度量,进而采取哪些手段去优化?“性能”其实是一个复杂的概念。不同的人、不同的应用场景都会对它有不同的定义。对于 HTTP 来说,它又是一个非常复杂的系统原创 2022-07-02 21:38:07 · 221 阅读 · 0 评论 -
38 | WebSocket:沙盒里的TCP
在之前讲 TCP/IP 协议栈的时候,我说过有“TCP Socket”,它实际上是一种功能接口,通过这些接口就可以使用 TCP/IP 协议栈在传输层收发数据。那么,你知道还有一种东西叫“WebSocket”吗?单从名字上看,“Web”指的是 HTTP,“Socket”是套接字调用,那么这两个连起来又是什么意思呢?所谓“望文生义”,大概你也能猜出来,“WebSocket”就是运行在“Web”,也就是 HTTP 上的 Socket 通信规范,提供与“TCP Socket”类似的功能,使用它就可以像“TCP So原创 2022-07-02 19:28:58 · 136 阅读 · 0 评论 -
37 | CDN:加速我们的网络服务
在正式开讲前,我们先来看看到现在为止 HTTP 手头都有了哪些“武器”。协议方面,HTTPS 强化通信链路安全、HTTP/2 优化传输效率;应用方面,Nginx/OpenResty 提升网站服务能力,WAF 抵御网站入侵攻击,讲到这里,你是不是感觉还少了点什么?没错,在应用领域,还缺一个在外部加速 HTTP 协议的服务,这个就是我们今天要说的 CDN(Content Delivery Network 或 Content Distribution Network),中文名叫“内容分发网络”。你可能要问了,HT原创 2022-07-02 19:14:44 · 286 阅读 · 0 评论 -
36 | WAF:保护我们的网络服务
在前些天的“安全篇”里,我谈到了 HTTPS,它使用了 SSL/TLS 协议,加密整个通信过程,能够防止恶意窃听和窜改,保护我们的数据安全。但 HTTPS 只是网络安全中很小的一部分,仅仅保证了“通信链路安全”,让第三方无法得知传输的内容。在通信链路的两端,也就是客户端和服务器,它是无法提供保护的。因为 HTTP 是一个开放的协议,Web 服务都运行在公网上,任何人都可以访问,所以天然就会成为黑客的攻击目标。而且黑客的本领比我们想象的还要大得多。虽然不能在传输过程中做手脚,但他们还可以“假扮”成合法的用户访原创 2022-07-02 18:57:20 · 739 阅读 · 0 评论 -
35 | OpenResty:更灵活的Web服务器
在上一讲里,我们看到了高性能的 Web 服务器 Nginx,它资源占用少,处理能力高,是搭建网站的首选。虽然 Nginx 成为了 Web 服务器领域无可争议的“王者”,但它也并不是没有缺点的,毕竟它已经 15 岁了。“一个人很难超越时代,而时代却可以轻易超越所有人”,Nginx 当初设计时针对的应用场景已经发生了变化,它的一些缺点也就暴露出来了。Nginx 的服务管理思路延续了当时的流行做法,使用磁盘上的静态配置文件,所以每次修改后必须重启才能生效。这在业务频繁变动的时候是非常致命的(例如流行的微服务架构)原创 2022-07-01 16:09:49 · 584 阅读 · 0 评论 -
34 | Nginx:高性能的Web服务器
经过前面几大模块的学习,你已经完全掌握了 HTTP 的所有知识,那么接下来请收拾一下行囊,整理一下装备,跟我一起去探索 HTTP 之外的广阔天地。现在的互联网非常发达,用户越来越多,网速越来越快,HTTPS 的安全加密、HTTP/2 的多路复用等特性都对 Web 服务器提出了非常高的要求。一个好的 Web 服务器必须要具备稳定、快速、易扩展、易维护等特性,才能够让网站“立于不败之地”。那么,在搭建网站的时候,应该选择什么样的服务器软件呢?在开头的几讲里我也提到过,Web 服务器就那么几款,目前市面上主流的只原创 2022-07-01 14:47:59 · 133 阅读 · 0 评论 -
33 | 我应该迁移到HTTP/2吗?
这一讲是“飞翔篇”的最后一讲,而 HTTP 的所有知识也差不多快学完了。前面你已经看到了新的 HTTP/2 和 HTTP/3 协议,了解了它们的特点和工作原理,如果再联系上前几天“安全篇”的 HTTPS,你可能又会发出疑问:“刚费了好大的力气升级到 HTTPS,这又出了一个 HTTP/2,还有再次升级的必要吗?”与各大浏览器“强推”HTTPS 的待遇不一样,HTTP/2 的公布可谓是“波澜不惊”。虽然它是 HTTP 协议的一个重大升级,但 Apple、Google 等科技巨头并没有像 HTTPS 那样给予大原创 2022-06-30 20:00:04 · 126 阅读 · 0 评论 -
32 | 未来之路:HTTP/3展望
在前面的两讲里,我们一起学习了 HTTP/2,你也应该看到了 HTTP/2 做出的许多努力,比如头部压缩、二进制分帧、虚拟的“流”与多路复用,性能方面比 HTTP/1 有了很大的提升,“基本上”解决了“队头阻塞”这个“老大难”问题。等等,你可能要发出疑问了:为什么说是“基本上”,而不是“完全”解决了呢?这是因为 HTTP/2 虽然使用“帧”“流”“多路复用”,没有了“队头阻塞”,但这些手段都是在应用层里,而在下层,也就是 TCP 协议里,还是会发生“队头阻塞”。这是怎么回事呢?让我们从协议栈的角度来仔细看一原创 2022-06-30 18:01:44 · 576 阅读 · 0 评论 -
31 | 时代之风(下):HTTP/2内核剖析
今天我们继续上一讲的话题,深入 HTTP/2 协议的内部,看看它的实现细节。这次实验环境的 URI 是“/31-1”,我用 Wireshark 把请求响应的过程抓包存了下来,文件放在 GitHub 的“wireshark”目录。今天我们就对照着抓包来实地讲解 HTTP/2 的头部压缩、二进制帧等特性。由于 HTTP/2“事实上”是基于 TLS,所以在正式收发数据之前,会有 TCP 握手和 TLS 握手,这两个步骤相信你一定已经很熟悉了,所以这里就略过去不再细说。TLS 握手成功之后,客户端必须要发送一个“连原创 2022-06-30 17:46:57 · 140 阅读 · 0 评论 -
30 | 时代之风(上):HTTP/2特性概览
在之前的课程里,我们看到 HTTP 有两个主要的缺点:安全不足和性能不高。刚结束的“安全篇”里的 HTTPS,通过引入 SSL/TLS 在安全上达到了“极致”,但在性能提升方面却是乏善可陈,只优化了握手加密的环节,对于整体的数据传输没有提出更好的改进方案,还只能依赖于“长连接”这种“落后”的技术。所以,在 HTTPS 逐渐成熟之后,HTTP 就向着性能方面开始“发力”,走出了另一条进化的道路。在HTTP 历史中你也看到了,“秦失其鹿,天下共逐之”,Google 率先发明了 SPDY 协议,并应用于自家的浏览原创 2022-06-30 16:58:59 · 69 阅读 · 0 评论 -
29 | 我应该迁移到HTTPS吗?
今天是“安全篇”的最后一讲,我们已经学完了 HTTPS、TLS 相关的大部分知识。不过,或许你心里还会有一些困惑:“HTTPS 这么复杂,我是否应该迁移到 HTTPS 呢?它能带来哪些好处呢?具体又应该怎么实施迁移呢?”这些问题不单是你,也是其他很多人,还有当初的我的真实想法,所以今天我就来跟你聊聊这方面的事情。如果你做移动应用开发的话,那么就一定知道,Apple、Android、某信等开发平台在 2017 年就相继发出通知,要求所有的应用必须使用 HTTPS 连接,禁止不安全的 HTTP。在台式机上,主流原创 2022-06-29 15:35:56 · 73 阅读 · 0 评论 -
28 | 连接太慢该怎么办:HTTPS的优化
你可能或多或少听别人说过,“HTTPS 的连接很慢”。那么“慢”的原因是什么呢?通过前两讲的学习,你可以看到,HTTPS 连接大致上可以划分为两个部分,第一个是建立连接时的非对称加密握手,第二个是握手后的对称加密报文传输。由于目前流行的 AES、ChaCha20 性能都很好,还有硬件优化,报文传输的性能损耗可以说是非常地小,小到几乎可以忽略不计了。所以,通常所说的“HTTPS 连接慢”指的就是刚开始建立连接的那段时间。在 TCP 建连之后,正式数据传输之前,HTTPS 比 HTTP 增加了一个 TLS 握手原创 2022-06-29 15:13:29 · 1337 阅读 · 0 评论 -
27 | 更好更快的握手:TLS1.3特性解析
上一讲中我讲了 TLS1.2 的握手过程,你是不是已经完全掌握了呢?不过 TLS1.2 已经是 10 年前(2008 年)的“老”协议了,虽然历经考验,但毕竟“岁月不饶人”,在安全、性能等方面已经跟不上如今的互联网了。于是经过四年、近 30 个草案的反复打磨,TLS1.3 终于在去年(2018 年)“粉墨登场”,再次确立了信息安全领域的新标准。在抓包分析握手之前,我们先来快速浏览一下 TLS1.3 的三个主要改进目标:兼容、安全与性能。由于 1.1、1.2 等协议已经出现了很多年,很多应用软件、中间代理(官原创 2022-06-29 14:28:57 · 404 阅读 · 0 评论 -
26 | 信任始于握手:TLS1.2连接过程解析
经过前几讲的介绍,你应该已经熟悉了对称加密与非对称加密、数字签名与证书等密码学知识。有了这些知识“打底”,现在我们就可以正式开始研究 HTTPS 和 TLS 协议了。当你在浏览器地址栏里键入“https”开头的 URI,再按下回车,会发生什么呢?回忆一下之前的内容,你应该知道,浏览器首先要从 URI 里提取出协议名和域名。因为协议名是“https”,所以浏览器就知道了端口号是默认的 443,它再用 DNS 解析域名,得到目标的 IP 地址,然后就可以使用三次握手与网站建立 TCP 连接了。在 HTTP 协议原创 2022-06-29 11:34:48 · 318 阅读 · 0 评论 -
25 | 固若金汤的根本(下):数字签名与证书
上一讲中我们学习了对称加密和非对称加密,以及两者结合起来的混合加密,实现了机密性。但仅有机密性,离安全还差的很远。黑客虽然拿不到会话密钥,无法破解密文,但可以通过窃听收集到足够多的密文,再尝试着修改、重组后发给网站。因为没有完整性保证,服务器只能“照单全收”,然后他就可以通过服务器的响应获取进一步的线索,最终就会破解出明文。另外,黑客也可以伪造身份发布公钥。如果你拿到了假的公钥,混合加密就完全失效了。你以为自己是在和“某宝”通信,实际上网线的另一端却是黑客,银行卡号、密码等敏感信息就在“安全”的通信过程中被原创 2022-06-28 20:17:39 · 108 阅读 · 0 评论 -
24 | 固若金汤的根本(上):对称加密与非对称加密
在上一讲中,我们初步学习了 HTTPS,知道 HTTPS 的安全性是由 TLS 来保证的。你一定很好奇,它是怎么为 HTTP 增加了机密性、完整性,身份认证和不可否认等特性的呢?先说说机密性。它是信息安全的基础,缺乏机密性 TLS 就会成为“无水之源”“无根之木”。实现机密性最常用的手段是“加密”(encrypt),就是把消息用某种方式转换成谁也看不懂的乱码,只有掌握特殊“钥匙”的人才能再转换出原始文本。这里的“钥匙”就叫做“密钥”(key),加密前的消息叫“明文”(plain text/clear tex原创 2022-06-28 17:56:40 · 129 阅读 · 0 评论 -
23 | HTTPS是什么?SSL/TLS又是什么?
从今天开始,我们开始进入全新的“安全篇”,聊聊与安全相关的 HTTPS、SSL、TLS。在14中,我曾经谈到过 HTTP 的一些缺点,其中的“无状态”在加入 Cookie 后得到了解决,而另两个缺点——“明文”和“不安全”仅凭 HTTP 自身是无力解决的,需要引入新的 HTTPS 协议。简单的回答是“因为 HTTP 不安全”。由于 HTTP 天生“明文”的特点,整个传输过程完全透明,任何人都能够在链路中截获、修改或者伪造请求 / 响应报文,数据不具有可信性。比如,前几讲中说过的“代理服务”。它作为 HTTP原创 2022-06-28 17:05:06 · 143 阅读 · 0 评论 -
22 | 冷链周转:HTTP的缓存代理
在 20 中,我介绍了 HTTP 的缓存控制,21我介绍了 HTTP 的代理服务。那么,把这两者结合起来就是这节课所要说的“缓存代理”,也就是支持缓存控制的代理服务。之前谈到缓存时,主要讲了客户端(浏览器)上的缓存控制,它能够减少响应时间、节约带宽,提升客户端的用户体验。但 HTTP 传输链路上,不只是客户端有缓存,服务器上的缓存也是非常有价值的,可以让请求不必走完整个后续处理流程,“就近”获得响应结果。特别是对于那些“读多写少”的数据,例如突发热点新闻、爆款商品的详情页,一秒钟内可能有成千上万次的请求。即原创 2022-06-28 15:53:27 · 134 阅读 · 0 评论 -
21 | 良心中间商:HTTP的代理服务
在前面讲 HTTP 协议的时候,我们严格遵循了 HTTP 的“请求 - 应答”模型,协议中只有两个互相通信的角色,分别是“请求方”浏览器(客户端)和“应答方”服务器。今天,我们要在这个模型里引入一个新的角色,那就是HTTP 代理。引入 HTTP 代理后,原来简单的双方通信就变复杂了一些,加入了一个或者多个中间人,但整体上来看,还是一个有顺序关系的链条,而且链条里相邻的两个角色仍然是简单的一对一通信,不会出现越级的情况。链条的起点还是客户端(也就是浏览器),中间的角色被称为代理服务器(proxy server原创 2022-06-28 14:53:54 · 102 阅读 · 0 评论 -
20 | 生鲜速递:HTTP的缓存控制
缓存(Cache)是计算机领域里的一个重要概念,是优化系统性能的利器。由于链路漫长,网络时延不可控,浏览器使用 HTTP 获取资源的成本较高。所以,非常有必要把“来之不易”的数据缓存起来,下次再请求的时候尽可能地复用。这样,就可以避免多次请求 - 应答的通信成本,节约网络带宽,也可以加快响应速度。试想一下,如果有几十 K 甚至几十 M 的数据,不是从网络而是从本地磁盘获取,那将是多么大的一笔节省,免去多少等待的时间。实际上,HTTP 传输的每一个环节基本上都会有缓存,非常复杂。基于“请求 - 应答”模式的特原创 2022-06-28 14:14:50 · 76 阅读 · 0 评论 -
19 | 让我知道你是谁:HTTP的Cookie机制
在之前的第 13、14 讲中,我曾经说过,HTTP 是“无状态”的,这既是优点也是缺点。优点是服务器没有状态差异,可以很容易地组成集群,而缺点就是无法支持需要记录状态的事务操作。好在 HTTP 协议是可扩展的,后来发明的 Cookie 技术,给 HTTP 增加了“记忆能力”。不知道你有没有看过克里斯托弗·诺兰导演的一部经典电影《记忆碎片》(Memento),里面的主角患有短期失忆症,记不住最近发生的事情。 比如,电影里有个场景,某人刚跟主角说完话,大闹了一通,过了几分钟再回来,主角却是一脸茫然,完全不记得这原创 2022-06-28 11:12:59 · 89 阅读 · 0 评论 -
18 | 四通八达:HTTP的重定向和跳转
在之前我曾经说过,为了实现在互联网上构建超链接文档系统的设想,蒂姆·伯纳斯 - 李发明了万维网,使用 HTTP 协议传输“超文本”,让全世界的人都能够自由地共享信息。“超文本”里含有“超链接”,可以从一个“超文本”跳跃到另一个“超文本”,对线性结构的传统文档是一个根本性的变革。能够使用“超链接”在网络上任意地跳转也是万维网的一个关键特性。它把分散在世界各地的文档连接在一起,形成了复杂的网状结构,用户可以在查看时随意点击链接、转换页面。再加上浏览器又提供了“前进”“后退”“书签”等辅助功能,让用户在文档间跳转原创 2022-06-28 10:53:42 · 158 阅读 · 0 评论 -
17 | 排队也要讲效率:HTTP的连接管理
我曾经提到过 HTTP 的性能问题,用了六个字来概括:“不算差,不够好”。同时,我也谈到了“队头阻塞”,但由于时间的限制没有展开来细讲,这次就来好好地看看 HTTP 在连接这方面的表现。HTTP 的连接管理也算得上是个“老生常谈”的话题了,你一定曾经听说过“短连接”“长连接”之类的名词,今天让我们一起来把它们弄清楚。HTTP 协议最初(0.9/1.0)是个非常简单的协议,通信过程也采用了简单的“请求 - 应答”方式。它底层的数据传输基于 TCP/IP,每次发送请求前需要先与服务器建立连接,收到响应报文后会立原创 2022-06-27 17:44:55 · 127 阅读 · 0 评论 -
16 | 把大象装进冰箱:HTTP传输大文件的方法
上次我们谈到了 HTTP 报文里的 body,知道了 HTTP 可以传输很多种类的数据,不仅是文本,也能传输图片、音频和视频。早期互联网上传输的基本上都是只有几 K 大小的文本和小图片,现在的情况则大有不同。网页里包含的信息实在是太多了,随随便便一个主页 HTML 就有可能上百 K,高质量的图片都以 M 论,更不要说那些电影、电视剧了,几 G、几十 G 都有可能。相比之下,100M 的光纤固网或者 4G 移动网络在这些大文件的压力下都变成了“小水管”,无论是上传还是下载,都会把网络传输链路挤的“满满当当”。原创 2022-06-27 17:20:36 · 179 阅读 · 0 评论 -
15 | 海纳百川:HTTP的实体数据
今天我要与你分享的话题是“海纳百川:HTTP 的实体数据”。这一讲是“进阶篇”的第一讲,从今天开始,我会用连续的 8 讲的篇幅来详细解析 HTTP 协议里的各种头字段,包括定义、功能、使用方式、注意事项等等。学完了这些课程,你就可以完全掌握 HTTP 协议。在前面的“基础篇”里我们了解了 HTTP 报文的结构,知道一个 HTTP 报文是由“header+body”组成的。但那时我们主要研究的是 header,没有涉及到 body。所以,“进阶篇”的第一讲就从 HTTP 的 body 谈起。在 TCP/IP原创 2022-06-27 16:09:01 · 84 阅读 · 0 评论 -
14 | HTTP有哪些优点?又有哪些缺点?
上一讲我介绍了 HTTP 的五个基本特点,这一讲要说的则是它的优点和缺点。其实这些也应该算是 HTTP 的特点,但这一讲会更侧重于评价它们的优劣和好坏。不过在正式开讲之前我还要提醒你一下,今天的讨论范围仅限于 HTTP/1.1,所说的优点和缺点也仅针对 HTTP/1.1。实际上,专栏后续要讲的 HTTPS 和 HTTP/2 都是对 HTTP/1.1 优点的发挥和缺点的完善。首先,HTTP 最重要也是最突出的优点是“简单、灵活、易于扩展”。初次接触 HTTP 的人都会认为,HTTP 协议是很“简单”的,基本的原创 2022-06-27 14:12:37 · 139 阅读 · 0 评论 -
13 | HTTP有哪些特点?
通过“基础篇”前几讲的学习,你应该已经知道了 HTTP 协议的基本知识,了解它的报文结构,请求头、响应头以及内部的请求方法、URI 和状态码等细节。你会不会有种疑惑:“HTTP 协议好像也挺简单的啊,凭什么它就能统治互联网这么多年呢?”所以接下来的这两讲,我会跟你聊聊 HTTP 协议的特点、优点和缺点。既要看到它好的一面,也要正视它不好的一面,只有全方位、多角度了解 HTTP,才能实现“扬长避短”,更好地利用 HTTP。今天这节课主要说的是 HTTP 协议的特点,但不会讲它们的好坏,这些特点即有可能是优点,原创 2022-06-27 11:24:35 · 80 阅读 · 0 评论 -
12 | 响应状态码该怎么用?
前两讲中,我们学习了 HTTP 报文里请求行的组成部分,包括请求方法和 URI。有了请求行,加上后面的头字段就形成了请求头,可以通过 TCP/IP 协议发送给服务器。服务器收到请求报文,解析后需要进行处理,具体的业务逻辑多种多样,但最后必定是拼出一个响应报文发回客户端。响应报文由响应头加响应体数据组成,响应头又由状态行和头字段构成。我们先来复习一下状态行的结构,有三部分:开头的 Version 部分是 HTTP 协议的版本号,通常是 HTTP/1.1,用处不是很大。后面的 Reason 部分是原因短语,是状原创 2022-06-24 17:39:13 · 146 阅读 · 0 评论 -
11 | 你能写出正确的网址吗?
上一讲里我们一起学习了 HTTP 协议里的请求方法,其中最常用的一个是 GET,它用来从服务器上某个资源获取数据,另一个是 POST,向某个资源提交数据。那么,应该用什么来标记服务器上的资源呢?怎么区分“这个”资源和“那个”资源呢?经过前几讲的学习,你一定已经知道了,用的是 URI,也就是统一资源标识符(Uniform Resource Identifier)。因为它经常出现在浏览器的地址栏里,所以俗称为“网络地址”,简称“网址”。严格地说,URI 不完全等同于网址,它包含有 URL 和 URN 两个部分,原创 2022-06-24 16:47:28 · 124 阅读 · 0 评论 -
10 | 应该如何理解请求方法?
上一讲我介绍了 HTTP 的报文结构,它是由 header+body 构成,请求头里有请求方法和请求目标,响应头里有状态码和原因短语,今天要说的就是请求头里的请求方法。HTTP 协议里为什么要有“请求方法”这个东西呢?这就要从 HTTP 协议设计时的定位说起了。还记得吗?蒂姆·伯纳斯 - 李最初设想的是要用 HTTP 协议构建一个超链接文档系统,使用 URI 来定位这些文档,也就是资源。那么,该怎么在协议里操作这些资源呢?很显然,需要有某种“动作的指示”,告诉操作这些资源的方式。所以,就这么出现了“请求方法原创 2022-06-24 15:58:23 · 88 阅读 · 0 评论 -
09 | HTTP报文是什么样子的?
在上一讲里,我们在本机的最小化环境了做了两个 HTTP 协议的实验,使用 Wireshark 抓包,弄清楚了 HTTP 协议基本工作流程,也就是“请求 - 应答”“一发一收”的模式。可以看到,HTTP 的工作模式是非常简单的,由于 TCP/IP 协议负责底层的具体传输工作,HTTP 协议基本上不用在这方面操心太多。单从这一点上来看,所谓的“超文本传输协议”其实并不怎么管“传输”的事情,有点“名不副实”。那么 HTTP 协议的核心部分是什么呢?答案就是它传输的报文内容。HTTP 协议在规范文档里详细定义了报文原创 2022-06-22 17:15:25 · 199 阅读 · 0 评论 -
08丨键入网址再按下回车,后面究竟发生了什么?
经过上一讲的学习,你是否已经在自己的电脑上搭建好了“最小化”的 HTTP 实验环境呢?我相信你的答案一定是“Yes”,那么,让我们立刻开始“螺蛳壳里做道场”,在这个实验环境里看一下 HTTP 协议工作的全过程。首先我们运行 www 目录下的“start”批处理程序,启动本机的 OpenResty 服务器,启动后可以用“list”批处理确认服务是否正常运行。然后我们打开 Wireshark,选择“HTTP TCP port(80)”过滤器,再鼠标双击“Npcap loopback Adapter”,开始抓取本原创 2022-06-22 15:53:59 · 143 阅读 · 0 评论 -
07 | 自己动手,搭建HTTP实验环境
这一讲我会先简单地回顾一下之前的内容,然后在 Windows 系统上实际操作,用几个应用软件搭建出一个“最小化”的 HTTP 实验环境,方便后续的“基础篇”“进阶篇”“安全篇”的学习。HTTP 协议诞生于 30 年前,设计之初的目的是用来传输纯文本数据。但由于形式灵活,搭配 URI、HTML 等技术能够把互联网上的资源都联系起来,构成一个复杂的超文本系统,让人们自由地获取信息,所以得到了迅猛发展。HTTP 有多个版本,目前应用的最广泛的是 HTTP/1.1,它几乎可以说是整个互联网的基石。但 HTTP/1.原创 2022-06-22 11:23:10 · 207 阅读 · 0 评论 -
06 | 域名里有哪些门道?
在上一讲里,我们学习了 HTTP 协议使用的 TCP/IP 协议栈,知道了 HTTP 协议是运行在 TCP/IP 上的。IP 协议的职责是“网际互连”,它在 MAC 层之上,使用 IP 地址把 MAC 编号转换成了四位数字,这就对物理网卡的 MAC 地址做了一层抽象,发展出了许多的“新玩法”。例如,分为 A、B、C、D、E 五种类型,公有地址和私有地址,掩码分割子网等。只要每个小网络在 IP 地址这个概念上达成一致,不管它在 MAC 层有多大的差异,都可以接入 TCP/IP 协议栈,最终汇合进整个互联网。但原创 2022-06-22 10:36:50 · 185 阅读 · 0 评论 -
05 | 常说的“四层”和“七层”到底是什么?“五层”“六层”哪去了?
在上一讲中,我简单提到了 TCP/IP 协议,它是 HTTP 协议的下层协议,负责具体的数据传输工作。并且还特别说了,TCP/IP 协议是一个“有层次的协议栈”。在工作中你一定经常听别人谈起什么“四层负载均衡”“七层负载均衡”,什么“二层转发”“三层路由”,那么你真正理解这些层次的含义吗?网络分层的知识教科书上都有,但很多都是“泛泛而谈”,只有“学术价值”,于是就容易和实际应用“脱节”,造成的后果就是“似懂非懂”,真正用的时候往往会“一头雾水”。所以,今天我就从 HTTP 应用的角度,帮你把这些模糊的概念弄原创 2022-06-21 15:03:09 · 189 阅读 · 0 评论 -
04 | HTTP世界全览(下):与HTTP相关的各种协议
今天要讲的则是比较偏向于理论的各种 HTTP 相关协议,重点是 TCP/IP、DNS、URI、HTTPS 等,希望能够帮你理清楚它们与 HTTP 的关系。同样的,我还是画了一张详细的思维导图,你可以点击后仔细查看。TCP/IP 协议是目前网络世界“事实上”的标准通信协议,即使你没有用过也一定听说过,因为它太著名了。TCP/IP 协议实际上是一系列网络通信协议的统称,其中最核心的两个协议是TCP和IP,其他的还有 UDP、ICMP、ARP 等等,共同构成了一个复杂但有层次的协议栈。这个协议栈有四层,最上层是“原创 2022-06-17 14:55:17 · 204 阅读 · 0 评论 -
03 | HTTP世界全览(上):与HTTP相关的各种概念
为了方便你查看,我又把这部分重新画了一下,比那张大图小了一些,更容易地阅读,你可以点击查看。暖场词就到这里,让我们正式开始吧。你一定已经习惯了现在的网络生活,甚至可能会下意识地认为网络世界就应该是这个样子的:“一张平坦而且一望无际的巨大网络,每一台电脑就是网络上的一个节点,均匀地点缀在这张网上”。这样的理解既对,又不对。从抽象的、虚拟的层面来看,网络世界确实是这样的,我们可以从一个节点毫无障碍地访问到另一个节点。但现实世界的网络却远比这个抽象的模型要复杂得多。实际的互联网是由许许多多个规模略小的网络连接而成原创 2022-06-17 14:17:15 · 100 阅读 · 0 评论 -
02 | HTTP是什么?HTTP又不是什么?
首先我来问出这个问题:“你觉得 HTTP 是什么呢?”你可能会不假思索、脱口而出:“HTTP 就是超文本传输协议,也就是HyperText Transfer Protocol。”回答非常正确!我必须由衷地恭喜你:能给出这个答案,就表明你具有至少 50%HTTP 相关的知识储备,应该算得上是“半个专家”了。不过让我们换个对话场景,假设不是我,而是由一位面试官问出刚才的问题呢?显然,这个答案有点过于简单了,不能让他满意,他肯定会再追问你一些问题:几乎所有面试时问到的 HTTP 相关问题,都可以从这个最简单的“H原创 2022-06-17 11:15:38 · 160 阅读 · 0 评论 -
01 | 时势与英雄:HTTP的前世今生
HTTP 协议在我们的生活中随处可见,打开手机或者电脑,只要你上网,不论是用 iPhone、Android、Windows 还是 Mac,不论是用浏览器还是 App,不论是看新闻、短视频还是听音乐、玩游戏,后面总会有 HTTP 在默默为你服务。据 NetCraft 公司统计,目前全球至少有 16 亿个网站、2 亿多个独立域名,而这个庞大网络世界的底层运转机制就是 HTTP。那么,在享受如此便捷舒适的网络生活时,你有没有想过,HTTP 协议是怎么来的?它最开始是什么样子的?又是如何一步一步发展到今天,几乎“统原创 2022-06-16 10:55:25 · 183 阅读 · 0 评论