Web 应用通常借助 Cookie 保存会话信息，这些信息一般并不敏感，但必须防止用户伪造。 我们先来考察一个应用场景：用户登录，后端将登录用户账号保存在 Cookie 中；后续访问是，浏览器会带上该 Cookie ，后端据此检查登录是否合法。 这个场景存在一个非常严重的安全漏洞，用户可以伪造 Cookie ！举个例子，他只要将 Cookie 改成我的账号 fasionchan ，就可以用我的账号来操作！那么，我们应该如何应对伪造数据呢？ 您可能想到对数据进行加密，离开密钥就无法解读数据，更何况伪造？加密适用保护敏感数据，它可以同时实现 保密 和 防伪 两个目的。换句话讲，如果数据是不能被第三方获悉的，那就必须加密。 如果数据无须保密，而只想防伪，则可以为其计算 签名（ signature ）。例子中用 Cookie 保存的登录账号就是一个典型的例子，让第三方知道了也没什么影响，关键是要防止别人伪造。 那么，怎么对数据计算签名呢？ 哈希 众所周知，对一段文本进行哈希，得到的哈希值可以作为文本的摘要，或者叫做信息指纹。哈希算法分很多种，常用的有 MD5 ，SHA 等等。同样的文本，用同样的的哈希算法，算出来的哈希值一定是一样的。以 MD5 为例： 1 2 3 import hashlib text = 'fasionchan' hashlib.md5(text.encode('utf8')).hexdigest() # a5ff4dddf920a287e1a3559836675e15 签名密钥 您可能会说，哈希计算得到摘要也没啥用呀，别人照样可以这样做。没错，但我们再引入一个密钥，情况就不同了： 1 2 3 4 5 import hashlib secret = '123456' user = 'fasionchan' signature = hashlib.md5((user+secret).encode('utf8')).hexdigest() print('{}-{}'.format(user, signature)) # fasionchan-65cd2de0af7cc1f5f765df7bdabd1e49 注意，这里密钥 secret 我随便用 123456 。密钥通常不能是简单的弱密码，不然很容易被破解。

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 地址和端口号呢？要知道，人类记忆数字型信息，比如电话号码等，并不擅长。

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

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

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

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

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

Web 应用采用 HTTP 协议进行通信：客户端向服务器发送 HTTP 请求，服务器对请求进行处理后，向客户端回复 HTTP 响应。换句话讲，HTTP 协议只能客户端主动发起请求，服务器被动进行响应。 不少应用场景要求服务主动向客户端进行推送，这时 HTTP 协议就有点捉襟见肘了。举个例子，为实现 Web 聊天室功能，当新消息到达时，服务器必须向客户端推送通知。只用 HTTP 协议来实现，我们必须在客户端做轮询。 轮询有个致命的缺陷——性能比较差：如果轮询频率很高，服务器要消耗很多资源；但如果控制轮询频率，应用消息通知的实时性又大打折扣。 很显然，服务器主动向客户端推送数据，也是一个非常常见的应用场景，最好能从网络协议层面进行支持。为此，计算机网络先驱们设计了 WebSocket 协议。 WebSocket 协议，顾名思义为 Web 应用引入了 套接字（ socket ）通信能力。Websocket 是一种应用层协议，以 TCP 为底层传输协议，为通信双方提供了一个 全双工 的信道。 为了兼容 Web 主流应用协议 HTTP ，WeSocket 复用 80 和 443 端口，并使用 HTTP 请求来建立连接（配合 Upgrade 头部）。因此，WebSocket 可以兼容现有的 HTTP代理 和中间件，例如 Nginx 。 URL 和 HTTP 协议一样，WebSocket 服务器地址也用 URL 表示，只是协议部分为 ws 或 wss 。例如： 1 2 3 4 5 # ws代表WebSocket协议，端口为80 ws://api.

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

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

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

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

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

大端（ Big endian ）和 小端（ Little Endian ）是计算机存储 多字节 数据的两种不同方式。

定义

在 大端 系统，多字节数据类型 起始字节先存储 ；相反，在 小端 系统，多字节数据类型 末尾字节先存储 。

假设有一个 4 字节长整数变量 y ，值为 0x01234567 (十六进制表示法) 。在 大端 系统上，该变量保存为以下 4 个字节： 0x01 、 0x23 、 0x45 、以及 0x67 ；在 小端 系统上，存储顺序刚好相反：