jysf98746的博客

根据你的昵称到 QQ 上面搜索，同一个昵称到处用概率还是很大的，如果有手机号那就更加准确了，紧接着可以根据你的 QQ 空间获取更多你私人的信息。可以根据上面列举的场景自己排查是否存在类似的问题，及时的撤销网上遗留的不安全信息碎片，并在日常中遵守安全的用网行为。信息收集是整个流程的第一步，也是很重要的一步，因为如果直接收集到泄漏的账号密码，那么下面的几个步骤甚至都可以略过了。我们每个人的账号都一大堆，有很大一部分人的账号和密码都是一样的，因为没办法平台太多了，如果设置不同很容易忘记也很不方便。

这么核心的东西在客户都是很容易查看的。虽然 JavaScript 可以混淆加密，但是最终他是需要被浏览器解析的，所以肯定是有一套固定的规范，黑客同样可以轻易解密。安全问题需要经验累积，软件开发作为一个团队协作的工作，大家经验水平不同，所以尽量在团队中分享安全开发的相关知识，技术 Leader 定期 Review 组员代码。黑客大部分利用的是软件的漏洞，所以我们要尽可能在开发的时候切断所有可能被利用的地方。重视安全最好的策略是将风险最大化，开发的时候要换位思考，如果我是黑客我是不是有办法绕过当前的限制。

Session 虽然存储在服务端，但是它的 SessionId 也存了一份在客户端的 Cookies 中的，并且它的生命周期随着浏览器的关闭而消失。用户登录 A 网站，然后又打开了另一个标签页访问 B 网站，如果此时 B 中隐藏了 A 网站某个请求的链接，到用户点击了，就会以当前用户的身份去触发对应的事件。这种威胁可能是物理硬件，操作系统，操作系统上面的软件漏洞，协议漏洞，甚至是人的某些行为导致，场景非常多而本节主要聚焦 Web 层面的安全问题。如果没有设置过期时间，它的生命周期就是浏览器关闭了就消失了。

TLS 的整个认证还是比较复杂的，OpenSSL 帮我们封装了很多内置算法，即便这样这个过程下来流程还是比较多，需要我们抽丝剥茧慢慢了解。各个服务都需要双向认证，所以每个服务都需要有自己的证书，证书是需要向 CA 申请的，所以我们要先制作 CA 根证书。依然是生成自己的私钥，证书请求CSR文件，后面生成最终的证书需要借助上面的 CA 私钥 和 CA 根证书。生成证书的时候都需要借助 CA ，CA用自己的私钥签名生成证书，把公钥开放出去，供验证者使用。这边一个组件的双向证书都生成了，其它组件就不一一举例。

接收着先用非对称的公钥对签名进行解密得到摘要信息，然后采用发送着相同的 Hash 算法，把收到的信息（请求参数）进行 Hash 计算得到摘要2，将自己生成的摘要和发送过来的摘要相比较，一致就可以证明信息发送者的身份和内容都是正确的，没有被伪造和篡改。所以数字证书是一个权威机构颁发给你的，证书的内容包含了：申请者的身份信息，申请者自己的公钥，证书的有效期等内容。证书的颁发要有权威的颁发机构，这个机构中核心是 CA 证书制作机构，其他职能机构也是围绕证书服务的，所有机构组成 PKI。

SSL 是网景（Netscape）公司设计的主要用于 Web 的安全传输协议，后来致力于互联网标准开发与推动的组织（IETF）认为在 SSL3.0 的基础上将该协议进行升级并标准化（RFC 2246），并命名为 TLS（Transport Layer Security）。TLS 是传输层与应用层之间的加密协议，对于应用层来说他是透明的，也就是不用关心他的具体实现，不管有没有 TLS 对应用层的软件来说都是一样的。目前大家依然比较习惯用 SSL 称呼，但是 SSL 系列的所有版本都已经弃用了。

在前面的章节中我们对 Http 已经有了一个很全面的了解，Http 在满足通信的基本功能外，也提供了很多丰富的交互功能，但是在安全性方面，Http 还有很多不足的地方，Https 就是为了解决这个问题而诞生。证书是由第三方权威的认证机构颁发和维护。大部分的 Web 网站都只要认证服务端即可，当我们访问 https:xxx 开头的网站，浏览器会去 CA 机构校验对方的身份，不符合的就会弹出警告提示，开发环境中经常证书是自己生成的，所以浏览器经常会提示警告，我们如果执意通过继续访问也是可以的。

一个比较友好规范的接口文档，我认为应该是由成功和失败2个独立的部分组成，正常的业务出入参放成功展示，失败的有专门的错误码表查询。错误码是接口文档中很重要的一部分，它是 Http 协议码的补充，错误码并没有固定的格式要求，但是一般由 业务模块+模块下的详细错误信息 组成。Http 定义了 5大类别的错误码，这些错误码是通用的，其中只有 5XX 是表示后台服务的错误。支付宝 / 微信 的接口是开发人员使用度比较广的第三方接口，我们经常会去调用他们的支付，小程序相关的接口，下面着重看看他们的错误码是如何定义的。

服务端不支持当前请求的某些功能，跟客户端异常 405 有点相似，只是 405 的情况侧重在客户端请求 Method 错误，而 501 侧重在，客户端请求的方法没问题，服务端本身有规划这个功能，但是还未实现。软件架构的网关通常指的是靠近用户侧用于分发请求的代理服务，如 Nginx 作为代理接收请求，再分发到后面的具体服务提供者。这是一个很常见的错误码，但这个错误码比较笼统，服务内容异常情况非常多，可能是代码问题，也可能是服务器资源问题等。5XX 指的是请求出错了，而且很有可能是服务端侧的异常。

作为客户端异常的首个状态码，400 代表的意思很泛（错误的请求），一般指的是 4XX 其它状态码没有更合适的情况下就用 400，毕竟客户端出错类型很多，无法准确把情况都定义好。4XX 的状态码指的是请求出错了，而且很有可能是客户端侧的异常。访问被禁止了，401 确切指没有认证，403 范围就更多了，可能是登陆了但是没有这个资源的权限，可能是访问的源 ip 不在相应的白名单中，等所有不被允许的情况。这是一个预留的状态，最初想要实现的是，一些商业网站，用户付费完后可以重复的发送请求，为支付而预留的。

307 跟 302 一样，都是对临时资源的重定向，不同的是 307 明确要求重定向的请求必须跟第一次的请求类型一样。一般是在有缓存的情况下，客户端发起资源获取请求，服务端判断之前的资源未修改过，可以继续使用缓存的资源。被请求的资源必须通过指定的代理才能被访问。请求的资源已经永久性的转移了，新资源 URI 在头部 Location指明，这时候如果浏览器有书签，或者请求地址的缓存，最好都能替换成 Location 对应的值。有多个重定向的值，需要客户端自己选择， Location 的值是服务端建议的值。

请求借助代理服务器访问原始服务器，拿到数据后，代理服务器并没有把原始服务器的头部元数据完全拷贝过来，只是简单的把消息体传给前端的客户。客户端对服务端的资源进行了某一部分的请求，服务端正常执行，响应报文中包含由 Content-Range 指定范围的实体内容。请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随 Location 头信息返回。请求作业耗时比较久的情况，后端可以先返回告诉客户端任务已开始，你可以先去处理别的事情了，而不用一直长时间等待。出现此状态码是表示正常状态。

此时，如果服务器愿意接受，就会返回 100 Continue 状态码，反之则返回 417 Expectation Failed 状态码。场景可以用于，请求体比较大又不确定服务的能不能处理，可以先这样尝试询问下，待服务端接收后才发送正式大请求体。跟 100 Continue 状态类似，只是 100的情况会立即返回，而 102的状态则需要等待比较久的时间，规定一般是超过 20s 以上。Http 协议根据场景约定了一系列请求返回的状态码，方便对请求结果进行细粒度管理。服务器将遵从客户的请求转换到另外一种协议。

Restful 是由 Roy Thomas Fielding 博士在 2000 年所著的博士论文提起的，系统全面地阐述了 REST 的架构风格和设计思想，这位作者同时是 HTTP、URI等 Web 架构标准的主要设计者，因此他提出的 REST 概念得到很多人的关注和响应。上节我们刚了解完 URI ，知道它是一种资源标识，而 URL 是 schema = Http 的子标识，本节要讲的 Restful 从小的讲是对 URL 格式提出了限制，对接口设计规范的倡导，大的说它是一种通信架构的指导。

通过前面我们知道 URI 是网络中用于标识某个对象的规约，URI 包含了多个 ，所以 URL 是 scheme = http 的 URI。有一个统一的格式，这个格式允许我们访问不同类型的资源，即使他们有同样的上下文，并且这个格式是可扩展的，允许后面有新的协议加入。scheme 一般指的是协议，URI 的通用格式并没有太多限制，一般是如下，以 scheme 开头，冒号 “：” 分隔开。资源是任何可标识的东西，文件图片甚至特定某天的天气等，它是一个或者一组实体的概念映射。

响应的头部字段很大一部分跟请求是对应的，客户端提了自己的诉求并根据优先级列举，服务端会根据自身情况选择一种回复客户端，这种过程就叫做内容协商（content negotiation）。内容协商的字段一般请求的首部是 Accept 开头，而响应的首部是 Content 开头。主要是在缓存场景中使用，一般我们都说 URL 是可以唯一定位一个资源的，其实不完全正确，比如 客户端对语言不同需求，同一个 URL 可能得到不同的资源。断点续传中，告知客户端返回的内容范围，字段值以字节为单位。告知客户端实体标识。

后台的开发人员能够从请求头部信息或者到很多有价值的东西，如 User-Agent 获取客户端信息，假设某个客户端一直访问，有可能是爬虫代码来抓取我们网站的资源了。Referer 字段可以知道请求从哪里来，假如别人的网站引用了你的图片，我们是可以从该字段得知的，可以禁用这类请求的响应。它的作用的是告知服务器，指定的请求资源只有在字段值内指定的日期时间之后，未发生更新的情况下，才能处理请求。请求的首部字段主要是客户端用来告知服务端自己能够支持的内容，让服务端尽量根据自己满足的优先级内容来响应。

Http 协议除了我们的请求和响应参数，还包含了很多首部字段，这些字段使 Http 在满足基本接口的请求接收参数之余，还有更多高级丰富的扩展。Trailer 是拖车的意思，正常的报文是 首部字段+回车符+请求体，Trailer 允许在请求体的后面再添加首部信息。如果 Connection 的值是 Upgrade ，通常也需要一个 Upgrade 字段来标明要升级的协议，该值可以是多个的逗号分隔开，服务端会按照顺序查看支持的升级服务。通用的首部字段指的是请求和响应的首部都能使用的字段。

代码中主要是监听连接，客户端连接后，根据 Http 协议进行字符串的拼接返回给客户端，客户端浏览器接收到是标准的 Http 格式就会进行渲染。本节我们将借助 Socket 实现服务的端口监听并根据 Http 协议的请求和响应结构，实现一个简单的 Web 服务器，加深体验 Web 服务和 Http 协议的原理。一般情况下，服务器收到客户端的请求后，就会有一个 Http 的响应消息，Http 响应也由 4 部分组成，分别是：状态行、响应头、空行 和 响应实体。

Nginx 总体使用起来比较简单，它的并发模型有别于一般的 Web 服务端，是用单线程的事件驱动 + IO 复用模型，这种模型适合处理 IO 密集型不适合 CPU 密集型的场景，Httpd 正好相反。与此同时它的高并发处理能力也是很强大的，是 Httpd 强有力的竞争者。前面讲过的 Httpd 和 Tomcat 以及这个小节所讲的 Nginx 都是 Web 服务器，他们三者发展到今天并没有很明显地成为某个产品一枝独秀的强垄断局面，因为他们有各自的特点和适用的场合，在某些场合他们甚至可以共用达到互补的功能。

在我们软件开发的早期，每个公司都是独立的开发自己的软件系统，但是各个系统是有相同的功能的，比如大部分的软件都是要存储数据，后来有了各种数据库，J2ee 给这种数据库连接制定了 Jdbc 规范，Mysql 和 Oracle 这种数据库提供商都是遵从这个规范来实现的，如果我们的代码也是遵从这个标准，那我们的系统假如要从Mysql 换到 Oracle 也是很方便的，不用大量重构代码。除此之外还有大量公用的功能，比如发送邮件等，于是有了建立在 Java 平台的企业级应用解决方案的规范。符合 J2ee 规范的容器。

Httpd 是上面几种服务器诞生最早的一个，所以它的代码经过长时间的修改和生产实际相对来说成熟很多，功能也很丰富，有强大的 rewrite 机制，模块化按需加载，连工作模式都可以根据自己的需要在编译的时候指定，但是因为灵活性比较高，初学者反而不容易掌握。这些模块大都是动态模块，因此可以随时加载。Httpd 作为起步比较早的一个 Web 开源项目，代码的稳定性/社区/文档 都是比较可靠的，他支持的功能非常丰富，并且可以按需地引入自己所需要的模块。不同的工作模式，对应着不同的配置。

而同样知名的淘宝则很难做到这点，这是由于京东在全国的各个城市都有自己的仓库系统，可以做到就近配送，而淘宝上都是独立的商家，每件商品都得从原厂地发货过来。而网络环境越来越复杂，传输数据越来越丰富，对网站的访问响应时间带来了一个比较大的挑战，CDN 就是诞生在这样一个环境中，通过负载均衡算法，为请求提供最靠近的响应资源，达到网站的内容加速。CDN 的发展不断在变更，从早期的静态内容，到后面的支持动态内容的加速，再到后面有了边缘计算的概念（CDN 和边缘计算是一种很好的结合，但是边缘计算的概念不限于此）。

我们知道网络中每台机器都有自己的 IP 地址，才能与外面的网络相互通信，传统的 IP 是由 4 个 8 位的字节组成的数字，这样的标识是不利于记忆的，所以延伸出域名的概念，每个域名可以映射成一个 IP。域名有记录类型的概念，其实就是它的解析规则，一个简单的域名，我们可以根据自己的业务拆解成不同的子域名，并解析到不同服务器去。DNS 是一个记录满了 IP 和域名映射的账本，这个账本非常的大，涉及到了全世界的域名信息，所以它的底层结构是分层和分布式的一个数据库。权威域名服务器：能够决定域名和 IP 的关系。

有一种 slowHttp 的攻击，就是利用 Http 协议的特点，故意制造了一个很长的报文，然后每次发送很少量的数据，使请求一直占用最终耗尽服务器的连接。几乎所有的软件都需要通信，而几乎所有的通信都是基于 Socket 实现的，Socket 从软件的层面屏蔽了传输层的细节，开发人员可以很方便的使用。下面的代码实现了一个 Socket 的服务端服务和一个客户端，服务端在 6000 端口上面监听连接，收到客户端的连接后向客户端发出 hello 问候语，客户端打印出服务端发送过来的消息。

等等问题很多，所以信息的发送不止是简单的电信号转换，还要给我们的数据添加额外的很多标识，让对方机器清楚你是谁，哪里来的，跟我这台电脑的哪个程序交互等信息。计算机的七层网络模型，是整个计算机体系的核心，明确分配了各个层次的功能职责。01 的电频信号在物理介质的传输远不止上面一条横线带过那么简单，想想如果你跟美国的网友进行通信，信号需要跨洋交互，中间经过的设备数量，通信距离有多夸张。为终端应用提供的服务，如我们的浏览器交互时候需要用到的 HTTP 协议，邮件发送的 SMTP，文件传输的 FTP 等。

作为互联网的从业者，我们需要了解这个表现背后的原理，那就是 Http 协议，它帮助我们将远端服务器的数据信息传输到我们浏览器的客户端。但是这家伙最早也是从单细胞慢慢演变而来的，它是诞生于科学家的物理实验室中用于档案的存储，后来慢慢演变成大学里知识交流的一个网络，再后来这个网络的规模越变越大，突破层级构架成了如今的互联网。Http 和 TCP/IP 都是协议，它们的不同之处在于：HTTP 是浏览器和后台服务之间的语言，而 TCP/IP是电脑之间的语言（相同的语言才能互相理解双方要表达的意思）。

在上面的请求内容中，规定了第一个是 method 后面是 url 接着是 protocal/version ，这样的约束就是 http 的协议，服务器收到请求就根据这个规则拆开解析。可能部分同学会有疑问，上面的两段请求内容跟浏览器的截图不一样，原因是我上面的是 Http 协议标准的定义，浏览器毕竟面向的是用户，对请求的信息有做了解析，更人性化地展示了请求的内容。返回了请求的状态，200状态码对应的就是成功，还有一些链接状态，内容的编码，长度，媒体类型等。观察底部 network 栏目的网络请求信息。