SQL注入（ SQL injection ）是一种将恶意代码插入到程序 SQL 语句中，从而误导数据库执行恶意逻辑的攻击技术。通过 SQL 注入，攻击者可以达到获取敏感信息，窃取访问权限等目的。

因此，在设计数据库应用时，必须警惕 SQL 注入风险，并加以防范。

随着互联网的蓬勃发展，各式各样的网站如雨后春笋般迸发出来，Web 逐渐成为 TCP/IP 协议栈的杀手锏应用。

那么，Web 应用是如何登上武林盟主之位的？它都包含哪些要素？又是如何工作的？本文带领大家，好好捋一捋 Web 应用背后的故事。

万维网

网络技术的发展激起人们对信息的渴望，但早年间信息的获取手段还相对有限，而且很不方便。你得知道自己想要的信息（一般是文件）在什么服务器上，应该使用什么软件来下载，而且信息与信息间缺少关联。

为了解决诸多不便，英国科学家 蒂姆·伯纳斯-李 在 1980 年发明了 万维网（ world wide web ），简称 Web 。这是一个由许多互相链接的超文本 网页 组成的信息系统，可以通过 互联网 来访问。

传输层引入了 端口 （ port ）的概念，很好地实现了进程间通信能力。我们已经学过这一层中的 UDP 协议，它是一种 面向数据报 的传输层协议。

UDP 协议的局限性

UDP 协议非常简单，它只是在 IP 协议的基础之上，加入 端口号 来区分收发进程，因此也有不少局限性。

网络丢包

我们知道，UDP 数据报需要借助 IP 包提供的点对点传输能力，从一台主机发往另一台主机。

前面介绍网络层和 IP 协议时，有个问题被我们束之高阁——如何由 IP 地址找到与之对应的 MAC 地址呢？

在时间查询服务中，客户端需要知道服务端的 IP 地址和端口号，才能发起请求。但我们应该如何记忆 IP 地址和端口号呢？要知道，人类记忆数字型信息，比如电话号码等，并不擅长。

端口其实还好。因为经过多年的发展，常用网络服务形成了一套约定俗成的惯例，这就是所谓的 知名端口 。举个例子， Web 服务一般采用 80 端口。我们用浏览器访问网站，甚至都不需要输入端口号，默认就是 80 端口。

IP 地址就不一样了。 10.35.87.61 这个 IP 地址比 80 端口难记多了。不仅如此，不同的服务可能部署在不同的机器，IP 地址也肯定是不一样的。很显然，百度的服务器，地址肯定跟淘宝的不一样。

我们每天都会访问很多网站，想记住它们的 IP 地址，显然是不可能的！如果能够通过名字来访问，则事半功倍，因为我们记忆文本要比记忆数字更拿手。

为此，网络先驱们发明了域名和域名系统，这就是本文的主角。

网络通信过程中可能出现各种各样的差错，因此需要具备 差错传送 机制。开始介绍解决方案前，我们先考察一下问题的背景：

随着互联网技术的发展和应用，我们的生活方式发生了翻天覆地的变化。我们可以通过互联网：

• 浏览网页
• 收发邮件
• 视频聊天
• 传输文件
• ect

互联网无处不在，因此也成为现代软件开发中绕不开的一环。作为互联网时代的开发人员，对互联网工作原理进行一次全面学习，很有必要。不然，连原理都搞不明白，怎么做好互联网应用开发呢？

那么，互联网是如何工作的呢？我们打开一个浏览器浏览网页时，背后都发送哪些事情呢？

任何系统通常都有用户，数据库因而少不了用户表，少不了要保存用户密码。那么，密码能明文保存吗？肯定不能！ 如果用户密码用明文保存，一旦数据库被拖库，用户密码就全泄露了呀！用户密码泄露可不是件小事，影响的也不仅仅是泄露站点，因为用户通常用同一个密码走天下！ 写到这不禁想起多年前发生的 CSDN 拖库事件，泄露了大量用户的密码，笔者的账号密码也在其中。顺便吐槽一下，CSDN 烂不是一天两天了，一个程序员交流网站竟然明文保存密码！ 当年我还年轻，好多网站的账号密码都是一样的。黑客拖库得到我的账号密码后，可以用它来登录我的 QQ ，我的邮箱，甚至是网银！想想就觉得可怕！ 从此以后，我养成了一个习惯——每个网站都用随机生成的独立的密码。为此，我还自己写了个密码管理器，支持随机生成密码、加密保存密码、按域名等关键字搜索密码。不过，后来懒得自己折腾，直接入了 1Password 。 话说回来，您可能会觉得：只要数据库保护得足够好，不被拖库，明文保存密码似乎也问题不大。其实拖库是无法百分之百避免的，因为系统总有漏洞，比如 SQL注入 漏洞就可以用来拖库。 因此，拖库肯定要防，如何将拖库损失降到最低也必须考虑。况且就算没有拖库，明文保存的密码也有由内部渠道泄露的风险。那么，密码如何加密保存呢？ 哈希 您可能会想到，先选择一个加密密钥，然后对密码进行加密后再保存到数据库；查询时再用密钥对密码进行解密。这看上去是个不错的方案，但事实并非如此，原因有二： 如果数据和密钥同时被泄露，密码就可以被解密出来； 密码仍可能由内部渠道泄露，因为系统管理员可能同时拥有加密密钥和数据库权限； 因此，最理想的做法是：让密码保存后，无法再被复原出来。换句话讲，加密必须是 不可逆 的。这时，您应该会想到 md5 、sha128、 sha256 等哈希算法。是的，用户密码通常都是用哈希算法加密后再保存到数据库的。 保存 用户注册或修改密码时，系统用哈希算法将用户的明文密码转换成一个 哈希值 ，再保存到数据库。以密码 123456 为例，用 md5 将其转换成一个哈希值： 1 2 3 >>> import hashlib >>> hashlib.md5(b'123456').hexdigest() 'e10adc3949ba59abbe56e057f20f883e' 哈希值作为密码的替代品，保存到数据库。这样一来，就算数据库被拖，黑客也无法根据哈希值还原出密码来。 验证 数据库不保存密码，那登录时如何验证用户的密码是否正确呢？ 哈希算法有一个特点，相同的输入产生的输出一定也是相同的。换句话讲，同一个密码算出来的哈希值一定是一样的；不同密码算出来的哈希值通常是不一样的。 由于哈希冲突的存在，两个不同的密码算出来的哈希值也有可能是一样的。但只要哈希值空间足够大，哈希冲突的概率就可以降到极低。以 md5 算法为例，哈希冲突的概率几乎为零。因此，可以认为不同密码算出来的 md5 值是不一样的。 利用这个特性，登录验证时可以用同样的哈希算法将用户提供的密码转换成一个哈希值，再跟数据库中的进行比较。如果两个哈希值相同，说明用户提供的登录密码正确。 1 2 3 4 5 6 7 8 9 10 11 12 13 # 数据库中的哈希值（原密码是：123456） >>> hash_in_db = 'e10adc3949ba59abbe56e057f20f883e' # 用户输入的密码 >>> password_input = b'123456' # 对密码求哈希再跟数据库中的比较，相等表示密码正确！ >>> hashlib.

Web 是互联网上最流行的应用，没有之一。Web 网站由 HTML 网页和相关资源组成，通过 Web 服务器对外服务。用户则通过浏览器连接 Web 服务器，浏览网页。

世界上有成千上万的网站，而浏览器也是五花八门。浏览器 和 Web 服务器必须对如何请求和响应数据达成一致，否则就乱套了。这就是本文要讨论的 超文本传输协议（ hypertext transfer protocol ），即 HTTP 协议负责的范畴。

HTTP 协议是一种应用层协议，它规定了参与 Web 通信的浏览器和 Web 服务器之间的通信细节。HTTP 协议主要用于传输超文本网页及其相关网络资源，其中

• Web 浏览器（ browser ）作为客户端，主动发起 请求（ request ）；
• Web 服务器（ server ）作为服务端，被动回复 响应（ response ）；

上一小节，我们简单介绍了 TCP 协议的基本机制，但很多细节还来不及展开。此时此刻，我们甚至对 TCP 的传输单元长啥样都一无所知。不过没关系，本节我们再接再厉，争取将它一举拿下！

报文结构

由于 TCP 协议位于传输层，它的传输单元一般叫做 TCP段（ segment ），也可译为 TCP分组 。当然了，也有不少文献将它笼统地称为 TCP报文 。

那么，一个 TCP 报文段的格式到底是怎样的呢？它跟 UDP 数据报又有哪些异同呢？

与 UDP 数据报一样，TCP 报文也分为头部和数据两个部分。所不同的是，TCP 报文头部要比 UDP 复杂很多：