软件工程师需要了解的网络知识：从铜线到HTTP（五）—— HTTP 和 HTTPS

会员服务 ·

软件工程师需要了解的网络知识：从铜线到HTTP（五）—— HTTP 和 HTTPS

2018 年 3 月 22 日 前端黑板报 JohnLui

JohnLui：程序员，Swift Contributor，正在写《iOS 可视化编程与 Auto Layout》

HTTP

在以前的文章中，我大力推荐过《图解 HTTP》这本书。这是一本好书，但是 HTTP 协议本身是一个静态协议：跟 HTML 一样是一堆标记的集合，十分简单。

我们首先明确一个简单的事实：TCP 首部后面的部分，依然是一堆二进制数据，但是此时，采用 HTTP 协议解析这堆数据之后，其内容终于可读了。

HTTP 是什么

HTTP 是 WWW（万维网）拥有的标准协议，用于在客户端和服务器之间传递信息：服务器给客户端传递网页，客户端给服务端传递需要的页面的 URL，上传文件等。

前提

在讨论 HTTP 协议之前，我们必须首先认识到 HTTP 协议是站在巨人的肩膀上的：

HTTP 往下看，是 TCP 协议保证了可靠传输，再往下是 IP 协议保证了 Internet 的大和谐，再往下是以太网协议在局域网内传递信息，再向底层追究，是双绞线中的电压变化将 0、1 一步步向下传递的。
HTTP 协议很简单，但却提供一个体验良好的应用标准，到今天依然生命力旺盛。为什么？因为 TCP/IP 协议簇将复杂度消化了。

一个普通的 GET 例子

我们使用 Charles 反向代理软件可以轻易地得到 HTTP 协议的细节。下面我们展示一个普通的 GET 例子。使用浏览器访问 http://killtyz.com （自己尝试的时候不要选择 HTTPS 网站）：

请求内容

GET / HTTP/1.1
Host: killtyz.com
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9

解释：

第一行有三个元素：HTTP 方法、uri、HTTP 版本
之后的每一行均以 : 作为间隔符，左边是 key，右边是 value（当然都是在 trim 之后）
HTTP 协议中，换行采用 \r\n，不是 Linux 系统文本编码采用的 \n，而是跟 Windows 一样的。

响应内容

HTTP/1.1 200 OK
Date: Thu, 25 Jan 2018 10:36:10 GMT
Server: Apache
Content-Length: 1321
Content-Type: text/html; charset=UTF-8
Proxy-Connection: Close

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>KillTYZ 干掉拖延症</title>
  <link href="http://libs.baidu.com/bootstrap/3.2.0/css/bootstrap.min.css" rel="stylesheet">
  <link rel="stylesheet" href="/css/main.css">

  <script src="http://libs.baidu.com/jquery/1.11.1/jquery.min.js"></script>
  <script src="http://libs.baidu.com/bootstrap/3.2.0/js/bootstrap.min.js"></script>
  <script src="/js/main.js"></script>
</head>
<body>
  <div id="wrap">
    <div id="head">
      <div class="logo">
        <img id="logo" src="/images/logo.png" alt="logo">
      </div>
      <div class="title">
        <h2>干掉拖延症</h2>
      </div>
    </div>
    <div class="content">
      <div id="box">
        <div id="add">
          <input id="add-input" type="text" class="form-control" placeholder="添加任务">
        </div>
        <div id="list" class="list-group">
        </div>
      </div>
    </div>
    <div id="foot">
      &copy;2018 <a href="http://killtyz.com">KillTYZ</a> | <a href="https://github.com/johnlui/KillTYZ">Github Repo</a>
      <br>Powered by <a href="http://tinylara.com">TinyLara</a>
    </div>
  </div>
</body>
</html>

响应的基本套路和请求一样，第一行的三个元素分别是协议版本、状态码、状态码的简短解释。需要注意的只有一点：

HTTP header 和 HTTP body

两个换行即 \r\n\r\n 之前的内容成为 HTTP header
两个换行之后的内容称为 HTTP body
HTTP body 就是你在浏览器查看源代码看到的内容

POST 例子

一下均为 Request 的 HTTP 内容。

Content-Type: application/x-www-form-urlencoded

POST /api/app HTTP/1.1
Host: killtyz.com
Content-Length: 18
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9

post=man&key=value

Content-Type: multipart/form-data

POST /api/app HTTP/1.1
Host: killtyz.com
Content-Length: 5195
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36
Cache-Control: no-cache
Origin: chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop
Postman-Token: 45479b21-15fa-9232-ab8b-52c7dde8523d
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary1s68Wb5ccTHj384y
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9

------WebKitFormBoundary1s68Wb5ccTHj384y
Content-Disposition: form-data; name="image"; filename="QQ20141011-2.jpg"
Content-Type: image/jpeg

***二进制文件内容***
------WebKitFormBoundary1s68Wb5ccTHj384y
Content-Disposition: form-data; name="post"

man
------WebKitFormBoundary1s68Wb5ccTHj384y
Content-Disposition: form-data; name="oo"

xx
------WebKitFormBoundary1s68Wb5ccTHj384y--

Cookie 相关 Header

Set-Cookie：响应的 HTTP header 中如果有这个字段，那么浏览器会把这个字段的 value 设定到本地的 Cookie 里，配合服务端的 Session 可以实现登录状态临时记录的功能。
Cookie：会出现在请求的 HTTP header 中。Set-Cookie 设置的 Cookie 会有一个作用域名，一般为 www.baidu.com 或者 .baidu.com，在浏览器本地记录的众多 Cookie 中，只要有满足这个作用域名要求的，下一次 HTTP 请求发出的时候会把这些条 Cookie 全部带上。

更多详细解释需要的时候可以自己查，都是明码实价，童叟无欺的。

HTTPS

HTTPS 这个名字取得不好，让很多人都误解了，以为他是和 HTTP 类似的协议，这是不对的。

HTTPS 全称为 HTTP Over TLS。（SSL/TLS 是一系列承前启后的加密协议族，此处统称为 TLS。）

什么是 TLS

TLS 中文名称为安全传输层协议，其目的是在客户端与服务端之间建立一个防窃听、防篡改的可信信息传递通道。

技术细节不再阐述

TLS 真正的组成非常的复杂，本文不想讨论那些技术细节，更不想讨论客户联和服务端建立连接的繁琐方式，什么先非对称加密再对称加密，一概不讨论；本文只进行概述、阐述特点。

技术特点

TLS 采用非对称加密和对称加密结合的方式，在客户端和服务器之间建立起一个防窃听、防篡改的通信通道。TLS 具有以下特点：

基于 TCP 协议，不需要再苦苦解决网络可靠性问题
采用服务端部署证书的形式提供对称加密基础
TLS 连接首次建立的过程十分消耗资源，不仅费 CPU 还非常耗时（和简单不可靠的 HTTP比）
TLS 没有完美实现防窃听、防篡改功能：中间人攻击依然存在相当大的可能性

TLS 实现原理

我从证书的两种签名方式来讲解 TLS 实现原理的简单描述，并分别阐述当前 HTTPS 证书的两大层面的功能。

自签名 TLS 证书

任何一台安装了 OpenSSL 开源软件的计算机均可以生成 TLS 证书并签名。制造自签名证书分为以下几步：

使用 RSA 算法生成私钥。私钥为绝密，由于证书公开，所以拥有私钥的人将实质上拥有证书的所有权。
生成与私钥一对一的根证书，并填入 TLS 证书需要的必要信息（common name 等）。
采用严格配对的私钥+证书部署 Apache 或 Nginx。

第三方签名的 TLS 证书

分为以下几步：

使用 RSA 算法生成私钥。私钥为绝密，由于证书公开，所以拥有私钥的人将实质上拥有证书的所有权。
生成与私钥一对一的 csr 文件。
将此文件上传到证书颁发商的网站，他们将用他们的根证书或者从根证书派发出的二级证书为我们的 csr 文件签名，得到 TLS 证书。期间会填入经过他们实际验证的必要信息，如 common name 和公司名称。
采用严格配对的私钥+证书部署 Apache 或 Nginx。

最重要的一点

RSA 公钥加密算法从数学上决定了无法从公开的信息（证书）反推出私钥。所以说，只要私钥不泄露，哪怕有人自己写代码强制使用公开的 TLS 证书和他自己伪造的私钥也是不可能的：数学上无法成立，根本就没法和客户端正常交互建立 TLS 连接。

防窃听、防篡改

防窃听：TLS 内部携带的数据就是完整的 HTTP 协议，request 和 response 都会被加密，完全无法破解，除非 RSA 算法被破解。TLS 还会在表面上加上少许 HTTP header，只有极少数必要信息如域名等。所以，就算 Twitter 用了 HTTPS，功夫网还是能够侦测出你在访问 Twitter。

防篡改：TLS 会对每一次数据交互进行严格的校验。HTTP 时代大家饱受运营商劫持的困扰，本质就是对 HTTP 数据的篡改，明文的嘛，正常。TLS 层中的数据被修改一位，这个 TLS 连接就会崩塌，两边瞬间就都知道了。

当前 HTTPS 技术的两层功能

加密。无论证书是自签名还是服务商签名，只要证书没有过期，就可以实现加密，保证信息传递的防窃听、防篡改。
可信。全球数十家服务商的根证书是预置在操作系统内部的：iOS、macOS、Windows 都是这样。因为我们的计算机信任根证书，所以才信任由其派生出的二级及三级证书。可信虽然会在 Chrome 上被标红，但却可以“仍然继续”跳过；而证书过期则不行：TLS 连接都无法建立，Chrome 想继续都继续不了呀。

TLS 的局限

TLS 虽然很强大，还是有一些问题。我们先说小问题，再说大问题。

安全要求不完善

TLS 证书是标准证书，和 HTTP 业务无关，这就导致我们必须采用现成的字段来保存这个证书可以用于那些域名：common name 字段。

我们知道，协议 + 域名 + 端口组成了一个“域”，域是浏览器中的基本安全单位，用在很多地方。TLS 证书等于说放开了端口这个要求，这样一来一个证书就可以被部署到任意的 N 个端口上。

中间人攻击风险依旧

中间人攻击指的是中间有一个人伪造是你想连接的那台服务器，窃取你的信息：在咖啡厅开一个假 wifi，就可以通过修改 DNS 的方式假装你的笔记本是百度的服务器，这样就可以获取想要的信息了。TLS 防止的是传输过程中的防窃听、防篡改，无法解决服务端伪造问题。

中间人攻击分为三个方式：

HTTP 转 HTTPS。早期网银攻击经常采用这种方式：用户访问网银网站，浏览器默认发出的是 HTTP 请求，本来该网站会将用户跳转到 HTTPS，但是中间人从中作梗：跟客户交流时采用 HTTP，跟银行交流时采用 HTTPS，这样你的银行卡和密码就全暴露了。
合法证书方式。采用特殊手段签出一张合法的证书，正大光明地做中间人。
终端自残式。破坏自己的终端，强制让自己的操作系统信任一张全域名证书：这样任何网络请求都是明文了。所以 HTTPS 防不了 APP 破解者。

除非客户端和服务端预先进行信息约定，不然从理论上讲是不可能建立一个完全可信的加密数据通道的。

防止中间人攻击的方法

只有一个：在 APP 中内置证书，每次建立连接时都进行比对。感兴趣的可以到我的网站搜 SSL，我专门阐述了如何设置 SSL pinning（钢钉）。

总结

HTTP 真的是一种十分简单的协议，HTTPS 只要了解了 TLS 的基本概念也不复杂，复杂度都在 TCP/IP 那里被消化了。

目前5000+人已关注加入我们