├── 第十九章 发布系统 └── readme.md ├── 第十三章 摘要认证 └── readme.md ├── 第十章 HTTP-NG └── readme.md ├── 第二十章 重定向与负载均衡 └── readme.md ├── LICENSE ├── 第十二章 基本认证机制 └── readme.md ├── 第十六章 国际化 └── readme.md ├── 第八章 集成点：网关、隧道及中继 └── readme.md ├── 第十四章 安全HTTP └── readme.md ├── 第二章 URL与资源 └── readme.md ├── 第十八章 Web主机托管 └── readme.md ├── 第一章 HTTP 概述 └── readme.md ├── 第六章 代理 └── readme.md ├── 第十一章 客户端识别与Cookie机制 └── readme.md ├── 第十七章 内容协商与转码 └── readme.md ├── 第九章 Web机器人 └── readme.md ├── 第四章 连接管理 └── readme.md ├── 第五章 web服务器 └── readme.md ├── readme.md ├── 第二十一章 日志记录与使用情况跟踪 └── readme.md ├── 第十五章 实体和编码 └── readme.md ├── 第七章 缓存 └── readme.md └── 第三章 HTTP报文 └── readme.md /第十九章 发布系统/readme.md: -------------------------------------------------------------------------------- 1 | ## 内容提要 2 | 3 | * 略 -------------------------------------------------------------------------------- /第十三章 摘要认证/readme.md: -------------------------------------------------------------------------------- 1 | ### 内容提要 2 | 3 | * 本章提供HTTP官方定义的另外一种认证协议————摘要认证。 4 | 5 | * 摘要认证跟基本认证兼容，但更安全，虽然没有得到广泛应用，但对安全事务来说，这些概念是很重要的。 6 | 7 | #### 摘要认证的改进 8 | 9 | * 与基本认证相比，摘要认证虽不是最安全的认证方式，但却在以下几点上做了一些改进，以此来降低安全事务风险。 10 | 11 | 1、永远不会以明文方式在网络上发送密码 12 | 13 | 2、可以防止恶意用户捕获并重新认证的握手过程 14 | 15 | 3、可以有选择地防止对报文内容的篡改 16 | 17 | 4、防范其他几种常见的攻击方式 18 | 19 | * 用摘要保护密码：永远不在网络上发送密码，而是发送密码的摘要，客户端和服务器端是知道密码的，然后服务端计算从客户端传送过来的摘要看是否和本地的密码摘要相匹配，从而验证用户身份。 20 | 21 | * 单向摘要：摘要是一种单向函数，常见的摘要很是是MD5，会将任意长度的字节序列转换为一个128位的摘要，通常被写成一个32位16进制的字符。 22 | 23 | * 用随机数防止重放攻击：就是服务器发送一个随机数，用于和密码摘要组成新的摘要，这样就能避免重放攻击了。 24 | 25 | #### 后面的内容 26 | 27 | * 略 -------------------------------------------------------------------------------- /第十章 HTTP-NG/readme.md: -------------------------------------------------------------------------------- 1 | ### 内容提要 2 | 3 | * 本章简要介绍了当前http协议的一些局限和不足的地方，并由此引出了正在研讨和优化的版本http-ng协议！ 4 | 5 | #### http发展中存在的问题 6 | 7 | 1、http相当复杂，由此实现http软件是相当复杂的 8 | 9 | 2、扩展性不好 10 | 11 | 3、性能不好，有些造成时延较大 12 | 13 | 4、传输依赖性，http是依赖于tcp/ip协议的 14 | 15 | #### HTTP-NG的活动 16 | 17 | * http-ng的出现正式为了修正http存在的复杂性高、可扩展性差、性能不好、传输依赖性等问题！虽然这个版本尚未被广泛使用（也有可能永远不使用）。 18 | 19 | * http-ng主要有一下几个特点： 20 | 21 | >> 模块化及功能增强 22 | 23 | >> 相关报文模块采用分层设计，更利于扩展（主要有三层：Web应用功能、远程操作调用、报文传输） 24 | 25 | #### 分布式对象 26 | 27 | * 略 28 | 29 | #### 第一层————报文传输 30 | 31 | * 该层关心报文的安全传输 32 | 33 | #### 第二层————远程调用 34 | 35 | * 实现远程调用服务器的接口 36 | 37 | #### 第三层————Web应用 38 | 39 | * 该层是执行语义和应用程序特定逻辑的地方 40 | 41 | #### WebMUX 42 | 43 | * 略 44 | 45 | ####　当前的状态 46 | 47 | * 指出http-ng替换http还为时尚早 48 | 49 | 50 | 51 | -------------------------------------------------------------------------------- /第二十章 重定向与负载均衡/readme.md: -------------------------------------------------------------------------------- 1 | ## 内容提要 2 | 3 | * 本章主要介绍了网站重定向和负载均衡的一些技术，术语网站架构方面的知识！ 4 | 5 | ### 技术概览 6 | 7 | * 重定向技术通常可以用来确定报文是否终结于某个代理、缓存或服务器集群中某台特定的服务器。重定向技术可以将报文发送到客户端没有显示请求的地方去。与此需要涉及到的技术： 8 | 9 | 1、HTTP重定向 10 | 11 | 2、DNS重定向 12 | 13 | 3、任播路由 14 | 15 | 4、策略路由 16 | 17 | 5、IP MAC转发 18 | 19 | 6、IP地址转发 20 | 21 | 7、WCCP（Web缓存协调协议） 22 | 23 | 8、ICP（缓存间通信协议） 24 | 25 | 9、HTCP（超文本缓存协议） 26 | 27 | 10、NECP（网元控制协议） 28 | 29 | 11、CARP（缓存阵列路由协议） 30 | 31 | 12、WRAD（Web代理自动发现协议） 32 | 33 | ### 为什么要重定向 34 | 35 | * 原因如下： 36 | 37 | 1、 可靠地执行HTTP事务 38 | 39 | 2、最小化时延 40 | 41 | 3、节约网络带宽 42 | 43 | 44 | ### 重定向到何地 45 | 46 | * 重定向把URL的每条请求都发送到最佳的Web服务器上去（最靠近客户端的、或负载最轻的或采用其他优化策略选择的服务器） 47 | 48 | ### 通用的重定向方法 49 | 50 | 1、HTTP重定向：原始服务器通过发送重定向响应报文，让客户端去其它可用的资源地点请求资源。常见发送状态码为302的响应报文，有以下缺点：1）原始服务器处理负载较大；2）增加了用户时延，因为需要多一次访问原始服务器；3）如果重定向服务器出现故障，站点就会瘫痪。 51 | 52 | 2、DNS重定向：其实tcp/ip视同ip地址来确定一个连接的，所以DNS重定向的原理就是通过DNS解析器确定合适的ip地址路劲来建立连接的。相关技术有DNS轮转。 53 | 54 | 55 | ### 待续...... 56 | 57 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2017 Jianfeng Li 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /第十二章 基本认证机制/readme.md: -------------------------------------------------------------------------------- 1 | ### 内容提要 2 | 3 | * 本章以及接下来的十三章都是介绍了http验证用户身份的一些机制！本章介绍一下基本认证，首先得这是一种简单的认证，并不能用于复杂、保密的业务逻辑环境中，它只能做到一般的保护，比如防止某个好心人查看你的个人信息！ 4 | 5 | #### 基本认证概述 6 | 7 | * 基本认证描述的就是用户第一次访问服务器的时候，服务器返回401状态码和WWW-Authenticate响应首部，并在首部中描述了密码编码算法和对应要使用密码的安全域，然后客户端弹框，在输入用户名和密码提交后。客户端发送含有Authorization首部的get请求申请验证身份，其中首部中携带了用户名和密码糅合在一起的编码后的验证码给服务器端，如果验证通过，那么服务器返回200的响应，并以Authentication-Info首部携带相关信息，以后用户就可以不用密码访问相关文件了！ 8 | 9 | #### 认证 10 | 11 | * 认证就是给出一种身份证明 12 | 13 | * HTTP的质询/响应认证框架：简单来说就是客户端和服务器端之间通信需要通过不断验证身份的过程来完成一个会话。web第一次发起一条http请求报文时，服务器返回一个“认证质询”响应，要求客户端提供用户信息，用户再次发起请求时，就会附上身份信息证书，如果验证通过，那么就完成会话，否则继续发起质询/认证！ 14 | 15 | * 认证协议与首部：http官方定义了两个官方的认证协议：基本认证和摘要认证。与此有关的报文首部如下： 16 | 17 | >> WWW-Authenticate————发生在服务器向客户端发起质询时，此时服务端返回401状态码,同时此首部定义了服务器端那个域需要验证质询认证 18 | 19 | >> Authorization————发生在客户端发起认证时，携带用户名和密码等信息！ 20 | 21 | >> Authentication-Info————发生在认证成功时，服务器返回200 ok,并以此首部携带一些信息 22 | 23 | 24 | * 安全域：安全域说明了不同的资源需要使用不同的访问权限！说白了你访问服务器不同的路径需要不同的验证方式，也就是说你可能需要重新验证！ 25 | 26 | 27 | #### 基本认证 28 | 29 | * 基本认证实现服务器端可以拒绝一个事务，并要求验证客户端信息，返回401状态码，发起质询/认证！ 30 | 31 | * Base-64用户名/密码编码：是一种编码机制 32 | 33 | * 代理认证：就是代替服务器向客户端发起质询/认证，与服务器端发起的质询/认证主要有几点不同：质询的时候返回的是407状态码，服务器端质询返回的首部是Proxy-Authenticate，客户端认证时发送的是Proxy-Authorizatio首部，认证成功之后返回的是Proxy-Authentication-Info首部。 34 | 35 | #### 基本认证的安全缺陷 36 | 37 | * 基本认证简单快捷，但并不安全，存在以下缺陷： 38 | 39 | 1、基本认证是采用网络以明文的方式发送用户名和密码，容易被别人捕获。 40 | 41 | 2、即使是密文发送 ，也很容易被别人解码 42 | 43 | 3、适用于很简单的会话服务 44 | 45 | 4、没有中间节点的保护措施 46 | 47 | 5、容易假冒服务器骗过基本认证 48 | 49 | #### 注 50 | 51 | * 安全使用基本认证的唯一方式就是将其与SSL配合使用 -------------------------------------------------------------------------------- /第十六章 国际化/readme.md: -------------------------------------------------------------------------------- 1 | ### 内容提要 2 | 3 | * 本章主要讲解了http协议在传输的过程中，如何彼此理解对方发送的内容是采用什么字符集编写的，从而彼此能够进行正确的显示内容！由此介绍了相关的报文首部。 4 | 5 | #### HTTP对国际性内容的支持 6 | 7 | * 服务器通过HTTP协议的Content-Type首部中的charset参数和Content-Language首部告知客户端文档的字母表和语言。 8 | 9 | #### 字符集和HTTP 10 | 11 | * 字符集是把字符转换为二进制码的编码，字符集标记在由IANA维护的MIME字符集注册机构进行了标准化。下面的Content-Type首部告知接收者，传输的内容是一份HTML文件，用charset参数告知接收者使用iso-8859-6阿拉伯字符集的解码算法把内容中的二进制码转换为字符： 12 | 13 | ``` bash 14 | Content-Type: text/html; charset=iso-8859-6 15 | 16 | ``` 17 | 18 | * 把二进制码转换为字符要经过两个步骤： 19 | 20 | 1、文档中的二进制码被转换成字符代码，它表示了特定编码字符集中某个特定编号的字符。 21 | 22 | 2、字符代码用于从编码的字符集中选取特定的元素。如在iso-8859-6中，值255对应阿拉伯字母“FEH”。 23 | 24 | * 不同的字符集相同的字符代码其字符不一定相同：如获得字符代码是225，那么字符集iso-8859-1和字符集iso-8859-2所代表的字符就不一样。 25 | 26 | #### Content-Type首部和Charset首部以及META标志 27 | 28 | * 如果在Content-Type首部中没有指定charset字符集，那么浏览器就会重文档内容的meta标签查找对应的字符集。 29 | 30 | 31 | #### 多语言字符编码入门 32 | 33 | * 字符集术语： 34 | 35 | 1、字符是指字母、数字、标点、表意文字、符号，或其它文本形式的书写‘原子’ 36 | 37 | 2、字形描述字符的笔画图案或唯一的图形化形状 38 | 39 | 3、编码后的字符分配给字符的唯一数字编号，这样我们就可以操作它了 40 | 41 | 4、代码空间：计划用于字符代码值的整数范围 42 | 43 | 5、代码宽度：每个（固定大小的）字符代码所用的位数 44 | 45 | 6、字符库：特定的工作字符集（全体字符的一个子集） 46 | 47 | 7、编码后的字符集：组成字符库（从全球的字符中选出若干字符）的已编码字符集，并为每个字符分配代码空间中的一个代码 48 | 49 | 8、字符编码方案：把数字化的字符代码编码成一系列二进制码的算法 50 | 51 | * MIME中的charset值所命名的是把数据位映射为唯一的字符的一整套算法。它是字符编码方案和编码后的字符集这两种概念的组合。 52 | 53 | * 字符是书写的最基本的构建单元。不要把字符和字形混淆，字符是唯一的、抽象的语言“原子”。字形是画出每个字符时使用的特定方式。根据艺术形式和手法的不同，每个字符可以有很多不同的字形。如果用一种字形替代另一种的时候，文本的意思变了，那这些字形就是不同的字符。否则，它们就是同一个字符的不同风格的表示形式而已。 54 | 55 | * 字符编码方案： 56 | 57 | 1、固定宽度：固定宽度方式的编码用固定数量的比特表示每个编码后的字符。它们能被快速处理，但可能会浪费空间 58 | 59 | 2、可变宽度（无模态）：可变宽度方式的编码对不同的字符代码数字采用不同数量的比特。对于常用字符，这样可以减少需要的位数，而且还能减少需要的位数，而且还能在允许使用多字节来表示国际性字符的同时，保持对传统8位字符集的兼容性。 60 | 61 | 3、可变宽度（有模态）：有模态的编码使用特殊的“转义”模式在不同的模态之间切换。例如，可以用有模态的编码在文本中使用多个互相有重叠的字符集。有模态的编码处理起来比较复杂，但它们可以有效地支持复杂的书写系统。 62 | 63 | 64 | #### 语言标记与HTTP 65 | 66 | * Content-Lenguage首部字段描述实体的目标受众语言。Accept-Language首部描述的是客户端能或优先接收的语言。两个首部都接收多个语言标记。 67 | 68 | #### 更多内容 69 | 70 | * 略 -------------------------------------------------------------------------------- /第八章 集成点：网关、隧道及中继/readme.md: -------------------------------------------------------------------------------- 1 | ### 内容提要 2 | 3 | * 本章主要讲解了： 4 | 5 | >> http和其他协议及应用程序之间起到接口作用的网关； 6 | 7 | >> 允许不同类型的web应用程序互相通信的应用程序接口； 8 | 9 | >> 允许用户在http连接上发送非http流量的隧道； 10 | 11 | >> 作为一种简化的http代理，一次将数据转发一跳的中继。 12 | 13 | #### 网关 14 | 15 | * 网络上的资源种类越来越复杂，单一的应用程序是无法处理这些能想到的资源的，所以才有了网关的概念，网关抽象出了一种能达到资源的方法，从而实现这样一种机制：客户端发送http请求，请求到达服务器端应用程序，应用程序向网关转发请求，网关处理请求并返回响应。其中网关充当了一种“翻译器”的功能，使得http能请求其他非http协议的资源！ 16 | 17 | ##### 客户端和服务器端网关 18 | 19 | * web网关描述了客户端和服务器端使用了不同的协议，使用下面的表示方法来表示： 20 | 21 | ``` javascript 22 | <客户端协议>/<服务器端协议> 23 | ``` 24 | 25 | 26 | * *客户端网关*和*服务器端网关*描述的是说明对话是在那一侧进行的。*客户端网关*是用其他协议来和客户端对话，用http协议来和服务器端通信；*服务器端网关*是用其他协议来和服务器端对话，用http协议来和客户端通信。 27 | 28 | 29 | #### 协议网关 30 | 31 | * 协议网关主要描述了几种架构在客户端和服务器端之间的网关，它们两侧使用了不同的协议来达到通信的目的，主要有：HTTP/*（服务器端web网关）、HTTP/HTTPS（服务器端安全网关）、HTTPS/HTTP（客户端安全网关加速器）。这里主要以HTTP/FTP为例讲解一次http请求在经过FTP网关时网关会去做什么事： 32 | 33 | >> 1、发送USER和PASS命令登录到服务器上去； 34 | 35 | >> 2、发布CWD命令，转移到服务器上合适的目录中去； 36 | 37 | >> 3、将下载类型设置ASCII; 38 | 39 | >> 4、用MDTM获取文档的最后修改时间； 40 | 41 | >> 5、用PASV告诉服务器将有被动数据获取请求到达； 42 | 43 | >> 6、用RETR请求进行对象获取； 44 | 45 | >> 7、打开到FTP服务器的数据连接，服务器端口由控制信道返回；一旦数据信道打开了，就将对象内容回送给网关。 46 | 47 | 48 | #### 资源网关 49 | 50 | * 协议网关描述的是通过网络连接客户端和服务器的网关，而最常见的网关，应用程序服务器，会将目标服务器与网关结合在一个服务器中实现。应用程序服务器是服务器端网关，与客户端通过HTTP进行通信，并与服务器端的应用程序相连。相关概念CGI(Common Programming Interface)和API(Application Programming Interface) 51 | 52 | #### 应用程序接口和web服务 53 | 54 | * 略 55 | 56 | #### 隧道 57 | 58 | * Web隧道允许用户通过HTTP连接发送非HTTP流量，这样就可以在HTTP上捎带其他协议数据了。使用Web隧道最常见的原因就是要在HTTP连接中嵌入HTTP流量，这样，这类流量就可以穿过只允许Web流量通过的防火墙了。 59 | 60 | * Web隧道使用HTTP的CONNECT方法建立起来的。 CONNECT方法并不是HTTP/1.1核心规范的一部分，但却是一种得到广泛应用的扩展。 61 | 62 | * CONNECT连接：除了起始行之外，CONNECT的语法与其他HTTP方法类似。一个后面跟着冒号和端口号的主机名取代了请求URL.主机和端口都比如指定： 63 | 64 | ``` 65 | 请求 66 | CONNECT home.netscape.com:443 HTTP/1.0 67 | User-Agent:Mozilla/4.0 68 | 69 | 响应 70 | HTTP/1.0 200 Connection Established 71 | Proxy-agent:Netscape-Proxy/1.1 72 | ``` 73 | 74 | #### 中继 75 | 76 | * HTTP中继是没有完全遵循HTTP规范的简单HTTP代理。中继负责处理HTTP中建立连接的部分，然后对字节进行盲转发！ 77 | -------------------------------------------------------------------------------- /第十四章 安全HTTP/readme.md: -------------------------------------------------------------------------------- 1 | ### 内容提要 2 | 3 | * 本章主要讲解了一下http的安全版本https,以及对一下编码、解码的原理介绍！ 4 | 5 | #### 保护HTTP的安全 6 | 7 | * http的安全版本应该具有：高效、可移植且易于管理，不但能够适应不断变化的情况而且还应该能满足社会和政府的各项要求。总结如下： 8 | 9 | 1、服务器认证：（客户端知道它们是在与真正的而不是伪造的服务器通话） 10 | 11 | 2、客户端认证：（服务器知道它们是在与真正的而不是伪造的客户端通话） 12 | 13 | 3、完整性：（客户端与服务器的数据不会被修改） 14 | 15 | 4、加密：（客户端和服务器的对话是私密的，无需担心被窃听） 16 | 17 | 5、效率：（一个运行的足够快的算法，以便低端的客户端和服务器使用） 18 | 19 | 6、普适性：（基本上所有的客户端和服务器都支持这些协议） 20 | 21 | 7、管理的可扩展性：（在任何地方的任何人都可以立即进行安全通信） 22 | 23 | 8、适应性：（能够支持当前最知名的安全方法） 24 | 25 | 9、在社会上的可行性：（满足社会的政治文化需要） 26 | 27 | * HTTPS：https是http的安全版本协议，所有现代浏览器和服务器都支持这个协议。用户可以在地址栏那里的看url的方法是https还是http来区分。所有https要求所有数据在进行网络传输前进行加密处理，https是在http和tcp/ip之间加了一个安全传输层SSL（或者TLS，跟SSL区别不大，不作特别声明的情况下，它们可以互指）。大部分困难和复杂的编码和解码算法都在SSL中完成的，所以客户端和服务器在使用https不用做过多的协议处理逻辑！ 28 | 29 | #### 数字加密 30 | 31 | * 首先需要知道以下概念： 32 | 33 | 1、密码：对文本进行编码，是偷窥者无法识别的算法（注意是“算法”） 34 | 35 | 2、秘钥：改变密码行文的数字化参数 36 | 37 | 3、对称秘钥加密系统：编/解码使用相同密钥的算法 38 | 39 | 4、公开秘钥加密系统：一种能够使数百万计算机便捷地发送机密报文的系统 40 | 41 | 5、数字签名：用来验证报文未被伪造或篡改的检验和 42 | 43 | 6、数字证书：由一个可信的组织验证和签发的识别信息 44 | 45 | * 密码：一种（方法）特殊的报文编码方式和一种稍后使用的相应解码方式的结合体。被编码的报文称为密文，被解码的报文称为明文。在一次请求（响应）中过程中，报文的状态为：明文————密文————明文。如果只使用密码的话，其实有很大的安全缺陷的，因为对方只要知道的你的密码算法，就能够解码处明文。 46 | 47 | * 秘钥：正因为密码算法有缺陷，所有才有了秘钥。说的直白一点，你只有密码的话，别人知道了算法，照样能解码，但是除了密码还有秘钥，别人知道密码就不一定能解码出来了，至少有些困难，那么秘钥是什么呢！它就是一个数字参数，有了它就可以实现，每次解码的算法不一样。就好像一个函数，每次传的参数不一样。秘钥就是那个“参数”！ 48 | 49 | * 对称秘钥加密技术：发送端和接受端使用同样的秘钥进行加密的密码算法技术。 50 | 51 | * 枚举攻击：输完所有的可能值来达到解码的一种攻击方案。也就是说如果秘钥的可能方案越多，那么解码所花的代价越大。而秘钥的数量取决于秘钥的位数以及有效位数。所以可以从这些方面来增加密码的安全级别。 52 | 53 | * 公开秘钥加密技术：由于对称秘钥加密技术会有秘钥数目的N*N的问题，所有公开秘钥加密技术要求发送端使用公用的秘钥，在接收端使用私有秘钥的解码。 54 | 55 | * 数字签名：签名就是一种证明身份的机制，是一种校验机制。 56 | 57 | * 数字证书：一种由某官方机构颁发的证书 58 | 59 | #### HTTPS————细节介绍 60 | 61 | * 建立安全传输：https与http的不同就是，中间了增加了一次SSL握手的步骤。具体情况就是，https在建立tcp/ip连接之后还需要进行一次SSL层的传输连接工作连接，同时在关闭tcp/ip连接之前需要增加一次关闭SSL层的通知工作。 62 | 63 | * SSL握手过程中确定了以下工作细节： 64 | 65 | 1、交换协议版本号； 66 | 67 | 2、选择一个两端都了解的密码； 68 | 69 | 3、对两端的身份进行认证； 70 | 71 | 4、生成临时的会话秘钥，以便加密信道。 72 | 73 | * SSL握手步骤为： 74 | 75 | 1、客户端发送可供选择的密码并请求证书 76 | 77 | 2、服务器发送选中的密码和证书 78 | 79 | 3、客户端发送保密信息；客户端和服务端生成秘钥 80 | 81 | 4、客户端和服务器相互告知，开始加密过程 82 | 83 | #### 后续内容 84 | 85 | * 略 86 | -------------------------------------------------------------------------------- /第二章 URL与资源/readme.md: -------------------------------------------------------------------------------- 1 | #### 内容提要 2 | 3 | * 本章讲解了URI（统一标识符）严格来说，这一章是介绍URL(统一资源定位符)的!分别介绍了URL是由那些组件构成、每个组件代表的含义是什么、浏览器是如何解析每个组件的以及从URL的完成性和安全性来说如何进行URL不安全字符进行转义。当然最后还简单介绍了URI的另一个子类URN（统一资源名）。 4 | 5 | #### URI的分类 6 | 7 | * URI（统一资源标识符）由URL（统一资源定位符）和URN（统一资源名）两个子集构成。URL是从资源的位置来定义一个资源的，比如在“中国三东的一只小狗”和在“中国广东的一只小狗”就分别定义了两只不同的狗。而URN是从资源的名字来定义的，比如小明和小李就分别定义了两个人。目前的网络架构来说，大部分都是URL。URL的缺点就是如果资源的位置发生了改变，那么资源也就找不到了，而URN正是解决这个问题的，因为URN不受位置的限制，它只受名字的管理，因为对于URN来说，一个资源的名字是唯一的，所以无论资源移动到什么地方，都能通过名字定位到资源。从某种意义上来说，URN是URI的未来趋势，但是URN的实现需要一个中间架构来满足这种位置到名字的映射，所以要完成从URL到URN的过度，显然是一个工程量的过程，如果不是URL到了不能用的时候，URN的实现需要很长的时间，幸运的是现在URL架构还是很好的满足网络需求的！ 8 | 9 | #### URL的语法 10 | 11 | * URL的语法描述的是URL由哪些组件构成，以及这些组件是怎么组合成一个URL，中间由什么符号连接，每个组件代表什么等！其格式如下： 12 | 13 | ``` 14 | 15 | ://:@:/;?# 16 | 17 | ``` 18 | 19 | 其中： 20 | 21 | >> scheme:方法描述了请求资源时用了什么协议，用“:”与url其它部分隔开； 22 | 23 | >> user:用户名描述了访问是带的用户名； 24 | 25 | >> password:密码描述了用户名后面可能跟的密码，用“:”跟用户名隔开； 26 | 27 | >> host:主机描述了网站主机名或ip地址，如果前面有用户名和密码，用@分开； 28 | 29 | >> post:服务器当前正在监听的端口，http默认为80，https默认为443; 30 | 31 | >> path:路劲描述了资源在服务器上的位置，用‘/’跟前面部分隔开； 32 | 33 | >> params:参数描述了请求需要附加的参数，用“;”与其他部分隔开； 34 | 35 | >> query:查询是用来激活服务器程序去执行某些操作，比如查询数据库等，用“?”与其余部分隔开； 36 | 37 | >> frag:片段只在客户端使用，不发送到服务器端； 38 | 39 | 40 | 41 | 42 | 43 | 44 | #### URL快捷方式 45 | 46 | * url快捷方式描述了一种程序如何通过相对地址解析处绝对地址的过程以及在浏览器地址栏输入部分url浏览器自动补全主机名的一种机制！ 47 | 48 | * 相对地址转换为绝对地址：首先会根据一个基础地址来得出协议、主机名、端口等！基础地址可以通过base标签显示定义，也可以由当前所在资源的地址得出！相关接口通过继承的方式附在相对地址上，最后得到绝对地址。 49 | 50 | * 浏览器扩展地址主要通过主机名扩展和历史扩展等方式实现自动地址补全！ 51 | 52 | 53 | 54 | #### url编码 55 | 56 | Q:为什么需要编码？ 57 | 58 | A:主要从url的一致性、安全性、以及完整性来强调需要对url字符进行编码。比如因为一个url连接的两端可能出现的机器种类很多，为了让大家都能够解析出一个相同的url，所以有必要对某些不安全的url字符进行转义。 59 | 60 | Q:url字符集由什么编码构成？ 61 | 62 | A:早前的url是有US-ASCII码编码，但是随着网络在全世界的流行，有很多字符是US-ASCII不能编码的，因为US-ASCII码最多只能编译127个字符。通过转义序列，就可以用US-ASCII字符集的有限子集对任意字符值或数据进行编码了。 63 | 64 | Q:编码机制？ 65 | 66 | A:为了避开安全字符集表示法带来的限制，人们设计了一种编码机制，用来在URL中表示各种不安全的字符。这种编码机制就是通过一种“转义”表示法来表示不安全字符的，这种转义表示法包含一个百分号（%），后面跟着两个表示字符的ASCII码的十六进制数。 67 | 68 | Q:那些字符不建议在URL里面使用？ 69 | 70 | A:在URL中，有几个字符被保留起来，有着特殊的含义。有些字符不在定义的US-ASCII可打印字符集中。还有些字符会与某些因特网网关和协议产生混淆，因此不赞成使用，比如“%”。 71 | 72 | 73 | 74 | -------------------------------------------------------------------------------- /第十八章 Web主机托管/readme.md: -------------------------------------------------------------------------------- 1 | ## 内容提要 2 | 3 | * 本章主要介绍了关于在一台物理服务器上托管了很多的主机（也就是说一个电脑里面部署了两个或者更多网站），此时，客户端怎么样和服务器端沟通，才能无差错地访问对应资源的主机（用户1访问a网站的资源，那么就不能跑到b网站上获取资源）。以及介绍了一些服务器集群的概念！ 4 | 5 | ### 相关概念 6 | 7 | * Web主机托管：对内容资源的存储、协调以及管理的职责统称为Web主机托管。主机托管是服务器的主要功能之一。 8 | 9 | * 托管者：如果某个公司想建立一个网站，但不想自行管理服务器所需的软硬件，就需要主机托管服务，即托管者。 10 | 11 | ### 主机托管服务 12 | 13 | * 专用托管：一台物理服务器对应一个主机 14 | 15 | * 虚拟主机托管：许多Web托管者通过让一些顾客共享一台计算机来提供便宜的Web主机托管服务，这称为共享主机托管或虚拟主机托管。每个网站看起来是托管在不同的服务器上，但实际上是托管在同一个物理服务器上。————但这并不意味着上千个网站是用一台PC机来提供服务的。托管者可以创建成排同样的服务器，称为服务器集群。 16 | 17 | ### 虚拟服务器请求缺乏主机信息 18 | 19 | * 背景：不幸的是，HTTP/1.0中的一个设计缺陷会使虚拟主机托管者抓狂。HTTP/1.0规范中没有为共享的Web服务器提供任何方法来设别要访问的是哪一个托管的网站。 20 | 21 | * 造成的后果：如果在一台物理服务器上托管了两个网站www.site1.com和www.site2.com。用户1想去获取www.site1.com的主页，于是在它发送了的请求报文为请求行GET /index.html HTTP/1.0，这里并没有发送主机信息，所以很可能服务器返回的是www.site2.com的主页。 22 | 23 | ### 设法让虚拟主机托管正常工作 24 | 25 | * 为了解决HTTP/1.0无法提供主机设别的缺陷，Web托管者需要开发变通的方案和约定来支持共享的虚拟主机托管。主要有四种技术： 26 | 27 | 28 | 1、通过URL路径进行虚拟主机托管：可以通过分配不同的URL路径，用这种笨方法把共享服务器上的虚拟站点隔离开。例如，可以给每个逻辑网站一个专门的路径前缀。 29 | 30 | ``` 31 | Joe的五金商店可以是：http://www.joes-hardware.com/joe/index.html 32 | 33 | Mary的古董拍卖店可以是：http://www.marys-antiques.com/mary/index.html 34 | 35 | ``` 36 | 37 | 当请求到达服务器时，其中并没有主机名信息，但服务器可以通过路径来区分它们。 38 | 39 | ``` 40 | 请求Joe的五金商店的网址是 GET /joe/index.html 41 | 42 | 请求Mary的古董拍卖店的网址是 GET /mary/index.html 43 | 44 | ``` 45 | 46 | 显然这不是一个好方法，/joe和/mary这样的前缀是多余的，并且那种常规输入主机地址显示主页的约定不存在了！ 47 | 48 | 49 | 2、通过端口号进行虚拟主机进行托管：托管者为每个主机提供一个单独的端口号，用来区分每个网站。这个方法也有同样的显著问题，因为终端用户很少去输入端口号的。 50 | 51 | 3、通过IP地址进行虚拟主机托管：一个更常用的、更好的方法是通过IP地址进行虚拟化。每个虚拟网站都分配一个或多个唯一的IP地址。所有虚拟网站的IP地址都绑定到同一个共享的服务器上。服务器可以查询HTTP连接的目的IP地址，并以此来判断客户端的目标网扎。这种方法对大的托管者来说，虚拟IP的主机托管能够工作，但它会带来一些麻烦。1）ip地址是有限制的，服务器上托管成百上千的虚拟站点的服务商不一定能实现愿望。2）IP地址是稀缺资源。3）服务器通过赋值服务器来增加容量时，ip地址短缺的问题就更严重了。 52 | 53 | 4、通过Host首部进行虚拟主机托管：这个方法主要是在请求首部增加Host首部，用来发送目的主机信息和端口。 54 | 55 | #### 解释Host首部 56 | 57 | * 1）如果HTTP请求报文中的URL是绝对的（也就是说，包含方案和主机部分），就忽略Host首部的值。2）如果HTTP请求报文中的URL没有主机部分，而该请求带有Host首部，则主机/端口的值就从Host首部中取。3）如果通过1）和2）步都无法获得有效的主机，就向客户端返回400 Bad Request响应。 58 | 59 | ### 使网站更可靠 60 | 61 | * 出现下列情况，网站是服务运作的。 62 | 63 | 1、服务器宕机 64 | 65 | 2、交通拥塞：服务器过载，甚至使它彻底停机 66 | 67 | 3、网络中断或掉线 68 | 69 | * 常见解决办法： 70 | 71 | 1、镜像的服务器集群，涉及的技术：HTTP重定向：该内容的URL会解析到主服务器的ip地址，然后它会发送重定向到复制服务器。DNS重定向：该内容的URL会解析到四个IP地址，DNS服务器可以选择发送给客户端的IP地址。 72 | 73 | 2、内容分发网络 -------------------------------------------------------------------------------- /第一章 HTTP 概述/readme.md: -------------------------------------------------------------------------------- 1 | ### 内容提要 2 | 3 | * 这一章主要介绍了什么是http以及http是干嘛的，以及与之有关的相关概念，当然了这些概念都是概览式的介绍一些。所以我将采用问答式的方式描述这一章！ 4 | 5 | 6 | **Q:http是干嘛的？** 7 | 8 | A:http是数据传输协议（超文本传输协议），用来沟通客户端和服务器的！ 9 | 10 | 11 | **Q:什么是资源？** 12 | 13 | A:记住一句话，网络上的一切内容皆资源，无论是静态文件，还是动态生成的代码等！ 14 | 15 | **Q:什么是媒体类型？** 16 | 17 | A:其实就是一种数据类型标记，用来告诉接收端，接收到的数据是什么类型，让接收端知道怎么才能处理该文件！常见标记方式就是MIME，MIME描述了文件的主要类型以及特定子类型，例如："Content-Type":"text/html"，其中text描述的文件的主要类型是文本，而其特定类型是html文档！ 18 | 19 | 20 | **Q:怎么理解URI以及它的子集？** 21 | 22 | A:首先URI从其概念来说是*统一资源标识符*，它的作用就是在网络上唯一确定一个资源，就好比，在中国，身份证能唯一确定一个人一样！知道身份证号，就一定能确定一个人姓甚名谁一样！它有两个子集：URL(统一资源定位符)和URN(统一资源名)，首先不特别声明，我们所说的URI就是指URL，URL是跟资源其在网络上的位置有关！而URN是指资源跟其名字有关，URN是未来的趋势，不过貌似具体实施现在还在商讨中！所以短时间之内URN难以取代URL！ 23 | 24 | 25 | **Q:什么是事务？** 26 | 27 | A:说白了事务就是“一次http链接（不包括tcp/ip连接，只包括一次http报文发送与接收）”的整个过程，由请求命令和响应结果组成！中间数据格式是http报文。我们平常打开一个网站，里面包括很多事务！如：请求网页文档、请求某个logo图片及请求某个视频等！ 28 | 29 | **Q:方法指什么？** 30 | 31 | A:方法就是客户端向服务器发起的请求命令！常见方法有：get、post、delete、put、head！ 32 | 33 | 34 | **Q:状态码有什么用？** 35 | 36 | A:状态码对程序有用，便于程序进行相关控制！原因短语对人有用！ 37 | 38 | 39 | **Q:简单介绍一些报文！** 40 | 41 | A:首先报文是http协议一种纯文本的数据格式，分为请求报文和响应报文，两种报文都具有类似的结构，分别由三个部分构成：起始行、首部、主体，起始行描述报文干了什么！首部描述报文传输的具体细节！主体描述传输的实际内容！ 42 | 43 | **Q:什么是TCP/IP？跟HTTP有什么关系？** 44 | 45 | A:tcp/ip是全世界的计算机和网络设备常用的层次化分组交换网络协议集！简单的说，http协议是一个应用层协议，位于tcp/ip协议的上一层，tcp/ip协议的主要作用就是过滤掉每个计算机的差异性，隐藏相关弱点，使得对于http协议来说提供的都是“相同的”接口！ 46 | 47 | **Q:在一次网络请求中，分别经历那些过程？** 48 | 49 | A:步骤如下： 50 | >> (a)浏览器从url中解析处服务器的主机名； 51 | 52 | >> (b)浏览器将服务器的主机名转换成服务器的的ip地址；（可能经过去dns服务器查询） 53 | 54 | >> (c)浏览器将端口号（如果有的话）从url中解析出来； 55 | 56 | >> (d)浏览器建立一条与web服务器的tcp连接； 57 | 58 | >> (e)浏览器向服务器发送一条http请求报文； 59 | 60 | >> (f)服务器向浏览器回送一条http响应报文； 61 | 62 | >> (g)关闭连接，浏览器显示文档 63 | 64 | 65 | Q:http协议有哪些版本？ 66 | 67 | A: 68 | >> http/0.9，这个版本有严重设计权限 69 | 70 | >> http/1.0，广泛使用 71 | 72 | >> http/1.0+ 非官方的http/1.0的扩展版本 73 | 74 | >> http/1.1 目前正在使用的版本，修复的相关设计缺陷，增加的相关特性 75 | 76 | >> http-NG 将来使用与否正在商讨中 77 | 78 | 79 | 80 | **Q:介绍一下web中的一些结构组件？** 81 | 82 | A:主要有代理、缓存、网关以及隧道！分别简介如下： 83 | 84 | - - 代理：代理位于客户端和服务器之间，接收所有客户端的HTTP请求，并把这些请求转发给服务器（可能会对请求进行修改之后转发）。对用户来说，这些应用程序就是一个代理，代表用户访问服务器。代理的主要作用有过滤、屏蔽等！（还有需要注意一点：代理既可以代表服务器对客户端进行响应，又可以代表客户端对服务器进行请求！） 85 | 86 | 87 | - - 缓存：首先说明一下，缓存某种意义上来说也是一种代理服务器。它主要使用代表服务器对客户端进行响应。发送预先缓存好的资源的副本。这样会加快事务响应速度、同时也会减少服务器的负载、减轻带宽等问题！ 88 | 89 | 90 | - - 网关：网关是一种特殊的服务器，面对客户端时好像它就是服务器，而对于服务器，他又充当客户端的角色，它的主要作用是协议转换！例如HTTP/FTP网关。 91 | 92 | 93 | - - 隧道：就是一个连接通道，用于在http信道上发送非http协议的资源。 94 | 95 | 96 | - - Agent代理：说白了就是我们平时所说的浏览器，以及web机器人、爬虫等！ 97 | 98 | 99 | 100 | -------------------------------------------------------------------------------- /第六章 代理/readme.md: -------------------------------------------------------------------------------- 1 | ### 内容提要 2 | 3 | * 本章主要介绍了http代理方面的概念，包括代理的配置、分类、作用等！ 4 | 5 | #### web的中间实体 6 | 7 | * web上的代理服务器是代表客户端对事务请求处理的中间人！分为私有代理（只代理一个客户端）和公共代理（代理多个客户端）。 8 | 9 | * 代理和网关的对比：代理的两端使用相同的协议，而网关的两端使用不同的协议，网关负责协议转换！ 10 | 11 | #### 为什么使用代理 12 | 13 | * 主要使用代理作以下功能使用： 14 | 15 | 1、儿童过滤器：如服务器响应的成人内容进行过滤 16 | 17 | 2、文档访问控制：验证客户端访问某个的文件需要的证书 18 | 19 | 3、安全防火墙：提供一个防火墙保护客户端或服务器 20 | 21 | 4、web缓存（缓存资源的副本）：对客户端响应资源的副本，节省带宽、减少网络拥堵 22 | 23 | 5、反向代理（原始服务的替代物，能访问其他服务器，作服务器加速器使用）：反向代理伪装成原始服务器，不过与服务器不同的是反向代理还可以向其他服务器发送请求，以便实现按需定位所请求的内容！ 24 | 25 | 6、内容路由器：比如网络中实现为了一些付费用户提供更好、更快的网络速度，让请求发往缓存服务器，而没有付费的用户请求则发往更远或原始服务器！ 26 | 27 | 7、转码器（比如改变图片格式，以便更轻巧利于传输） 28 | 29 | 8、匿名者：保护客户端隐私 30 | 31 | 32 | #### 代理去往何处 33 | 34 | * 按部署代理的位置代理可以分为一下几种： 35 | 36 | 1、出口代理：部署在本地网络端，用于保护本地网络或者限制公司带宽 37 | 38 | 2、访问（入口）代理：用于实现提供缓存响应 39 | 40 | 3、反向代理：部署在服务器端本地网络上，用于实现更精确的请求和提供性能 41 | 42 | 4、网络交换代理：部署在网络上，用于检测流浪等 43 | 44 | * 代理层次结构描述的代理的部署层级结构，比如一级代理，二级代理等，这是一种静态层级结构，有父代理和子代理的概念，离原始服务器进的的代理是离服务器远的代理的父代理！但是代理层级不应该静态的，而应该可以是动态的，以保证代理可以根据实际网络负载情况而下发报文到不同的代理！从而产生的动态层级代理概念有**负载均衡**、**地理位置附近的路由**等！ 45 | 46 | * http请求报文是怎么进入代理的，描述的怎么把http请求报文流量导入代理！主要有一下几种方式： 47 | 48 | 1、*修改客户端*：比如现在的客户端都支持收手动和自动配置代理！ 49 | 50 | 2、*修改网络*：网络通过一些技术在客户端不知情的情况揽入流量进入代理！ 51 | 52 | 3、*修改dns命名空间*：把主机名映射为代理的ip地址，比如修改系统的dns映射文件，让代理伪装成原始服务器，从而把web请求导入代理！ 53 | 54 | 4、*修改服务器*：让服务器返回一个重定向有关的代码，把http请求报文导入到代理！ 55 | 56 | 57 | #### 客户端代理设置 58 | 59 | * 主要介绍客户端配置代理的几种常见方式，如下： 60 | 61 | - - 手工配置 : 显示地设置要使用的代理 62 | 63 | - - 预先配置浏览器 : 浏览器厂商或发行商会在将浏览器发送给其客户之前预先对浏览器（或所有其他的Web客户端）的代理设置进行手工配置 64 | 65 | - - 代理的自动配置（Proxy Auto-Configuration,PAC）：一个代理配置的js文件，客户端在请求之前会取回这个js文件，从而判断如何决定使用代理 66 | 67 | - - WPAD的代理发现 : 略 68 | 69 | #### 与代理有关的一些棘手问题 70 | 71 | 1、发送给服务其的url可以是相对路径，而发送给代理的是包含方法、主机名等完整路径！ 72 | 73 | 2、与虚拟主机目录同样存在的问题，可以通过在请求报文的host首部发送确定的主机信息！ 74 | 75 | 3、拦截代理会受到部分url！ 76 | 77 | 4、代理既可以处理代理请求，也可以处理服务器请求！ 78 | 79 | 5、转发过程中对URI的修改 80 | 81 | 6、URI的客户端自动扩展和主机名解析 82 | 83 | 7、没有代理URI的解析 84 | 85 | 8、有显示代理的URI的解析 86 | 87 | 9、有拦截代理的URI的解析 88 | 89 | 90 | #### 追踪报文 91 | 92 | 93 | * 现在代理请求逐步流行的情况下，需要一种机制来追踪我们的报文经过了那些节点。此时报文中via字段就是一个描述报文在代理中逐级传输的过程中所经过代理的方式！如下： 94 | 95 | ``` 96 | GET /index.html HTTP/1.0 97 | Accept: text/html 98 | Host: www.joes-hardware.com 99 | Via: 1.1 proxy-62.irenes-isp.net,1.0 cache.joes-hardware.com 100 | 101 | ``` 102 | via字符告诉我们报文流经了两个代理。这个字符串说明第一个代理名为proxy-62.irenes-isp.net,它实现了HTTP/1.1协议，第二个代理被称为cache.joes-hardware.com,实现了HTTP/1.0。 103 | 104 | * Server响应首部字段对原始服务器使用的软件进行了描述，如下有几个例子： 105 | - - Server: Apache/1.3.14 (Unix) PHP/4.0.4 106 | 107 | - - Server: Netscape-Knterprise/4.1 108 | 109 | - - Server: Microsoft-IIS/5.0 110 | 111 | 注：如果响应报文是通过代理转发的，一定要确保代理没有修改Server首部。Server首部是用于原始服务器的。代理应该添加的是Via首部。 112 | 113 | #### 代理认证 114 | 115 | 略 116 | 117 | #### 代理的互操作性 118 | 119 | 略 -------------------------------------------------------------------------------- /第十一章 客户端识别与Cookie机制/readme.md: -------------------------------------------------------------------------------- 1 | ## 内容提要 2 | 3 | * 本章介绍了http验证用户的一种机制————cookie,以及cookie的一些概念细节！ 4 | 5 | ### 外在原因 6 | 7 | * http最初是一个匿名、无状态的请求/响应协议。服务器处理来自客户端的请求，然后向客户端回送一条响应。web服务器几乎没有什么信息可以用来判定是哪个用户发送的请求，也无法记录来访用户的请求序列。 8 | 9 | ### 能解决的问题 10 | 11 | * 以在线商店为例讲解有了http有了验证身份的机制之后可以实现那些功能，（当然没有这个机制的情况下也可以实现，但是可能会传很多参数来保证身份信息）： 12 | 13 | 1、个性化的问候 14 | 15 | 2、有的放矢的推荐 16 | 17 | 3、管理信息的存档 18 | 19 | 4、记录会话 20 | 21 | #### http报文中承载用户信息的首部 22 | 23 | 1、From:用户的E-mail地址 24 | 25 | 2、User-Agent:用户代理或爬虫标记 26 | 27 | 3、Referer:当前页面是从那个页面跳过来的 28 | 29 | 4、Authoriztion:用户的用户名和密码 30 | 31 | 5、Client-IP : 扩展（请求） 32 | 33 | 6、X-Forwarded-For : 扩展（请求） 34 | 35 | 7、Cookie:扩展（请求） 36 | 37 | 38 | #### 客户端IP地址 39 | 40 | * 早起的web曾以客户端的ip地址信息来作为验证用户的身份机制，但存在很多缺点，如： 41 | 42 | 1、首先ip标记是客户端机器，而不是用户，也就是说多个用户公用一台机器，是无法识别的！ 43 | 44 | 2、很多ip地址是动态的，所以不能在一次会话之间用ip地址来验证一个用户信息 45 | 46 | 3、使用代理的时候，此时发送的ip地址是代理的ip地址，而不是用户的ip地址，虽然代理可以加一个首部来保证最初的ip地址信息，但是不兼容 47 | 48 | 4、ip地址很容伪造，所以不安全 49 | 50 | 51 | #### 用户登录 52 | 53 | * 这种方法的主要原理就是：在初始访问的时候，服务器返回报文并添加WWW-Authorization首部，用以弹出一个窗口要求用户填写用户名和密码等信息！客户端在下次访问的时候就可以传送带有Authorization的首部，并把相关身份信息传输过去以此验证用户信息，以后的每次请求都会带上这个首部！ 54 | 55 | #### 胖URL 56 | 57 | * 把用户信息添加进url的url称为胖url，以此来验证用户身份，但这种机制有以下缺点： 58 | 59 | 1、丑陋的url 60 | 61 | 2、无法共享url,因为用户信息在url里面，共享url同时也会把用户信息共享出去了 62 | 63 | 3、破坏缓存 64 | 65 | 4、额外的服务器负荷 66 | 67 | 5、逃逸口，很容易造成用户不小心跳到另一个网站，返回过来的收用户的信息全部没了，比如购物车里面的东西全部没了 68 | 69 | 6、会话是非持久的 70 | 71 | #### Cookie 72 | 73 | * 分类：会话Cookie（非持久Cookie）和持久Cookie 74 | 75 | * 原理：用户第一次请求服务器时，服务器返回一个带Set-Cookie（Set-Cookie1）首部的报文，值为键值对，描述了cookie的名字、值、域、路径等信息，然后客户端接下来每次访问服务器的时候都会带上一个Cookie首部的报文，它的值刚好是前面响应报文返回的名字键值对，从而达到验证用户身份的信息。 76 | 77 | #### Cookie的属性 78 | 79 | * domain : cookie的域 80 | 81 | * allh : 那些主机可以使用此cookie 82 | 83 | * path ：那些路径能使用cookie 84 | 85 | * secure : 是否在发送https报文的时候使用cookie 86 | 87 | * expires ： 过期时间 88 | 89 | * name ： cookie的名字 90 | 91 | * value : cookie的值 92 | 93 | #### 不同站点使用不同的cookie 94 | 95 | 96 | * cookie不能任意使用，只能在它自己设定的域、主机、路径里面使用 97 | 98 | #### cookie版本 99 | 100 | * cookie机制有个两个版本，一个是网景公司主导的“版本0”，主要是服务器返回“Set-Cookie”首部，而客户端请求发送“Cookie”首部，客户端发送请求时，会将所有与域、路径和安全过滤器相匹配的未过期cookie都发送给这个站点。所有cookie都被组合到一个Cookie首部中，如： 101 | 102 | ``` 103 | Cookie: session-id=002-1145265-8016938; session-id-time=1311313313131 104 | ``` 105 | 106 | cookie机制还有一个版本就是RFC 2965定义的一个cookie的扩展版本。这个版本1标准引入了Set-Cookie2首部和Cookie2首部，但它也能与“版本0”系统进行互操作。“版本1”跟“版本0”的区别就是，提供了更多的属性来描述一个cookie,同时服务器端发送的是“Set-Cookie”首部，而客户端发送的是“Cookie”首部，如： 107 | 108 | ``` 109 | 服务器端 110 | Set-Cookie2: ID="29046"; Domain=".joes-hardware.com" 111 | Set-Cookie2: color=blue 112 | Set-Cookie2: support-pref="L2"; Domain="customer-care.joes-hardware.com" 113 | Set-Cookie2: Coupon="hammer027"; Version="1"; Path="/tools" 114 | Set-Cookie2: Coupon="handvac103"; Version="1";Path="/tools/cordless" 115 | 116 | 客户端 117 | Cookie: $Version="1"; 118 | ID="29046"; $Domain=".joes-hardware.com"; 119 | color="blue"; 120 | Coupon="hammer027"; $Path="/tools"; 121 | Coupon="handvac103"; $Path="/tools/cordless" 122 | ``` 123 | 124 | 另外Cookie2首部是用来沟通支持版本0和版本1的服务器的，它会发送当前客户端支持的最新版本cookie版本，如： 125 | 126 | ``` 127 | Cookie2: $Version="1" 128 | ``` 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | -------------------------------------------------------------------------------- /第十七章 内容协商与转码/readme.md: -------------------------------------------------------------------------------- 1 | ### 内容提要 2 | 3 | * 本章主要讲解了一种机制————同样的url，客户端和服务器之间如何根据客户端的需要发送适当的版本文档给客户端，比如同样在浏览器输入www.baidu.com，那么如果是英国的用户很可能希望收到的收到的是英语版本的网页，而在中国的用户很可能希望收到中文版本的网页，那么服务器是怎么实现根据需要发送不同的版本的呢！于是有了内容协商和转码！所谓内容协商指的是客户端和服务器通过在http报文设置相关首部来告诉对方自己需要什么、可以发送什么等，而转码则是把文档装成其他格式的文档，注意：转码和内容编码及传输编码不一样，后两者是更高层次上的编码！ 4 | 5 | 6 | 7 | #### 相关术语 8 | 9 | * 变体：单一的一个url，根据用户的不同需要，服务器发送不同版本的响应给用户，我们把这种服务器发送的不同版本的响应称为变体。例如一个网页有英语和中文版本，通过内容协商的方法实现精确发送那个版本的给客户端，这两个版本的网页就是变体。 10 | 11 | * 转码：有时根据客户端设备的不同，需要将资源转换成响应的格式的文件以让客户端设备更好的处理资源，这种类似的操作就称作转码。 12 | 13 | 14 | #### 内容协商技术 15 | 16 | * 内容协商技术从实现方式来说有三种： 17 | 18 | 1、客户端驱动实现方式：客户端发起请求，服务器返回资源可用版本的列表，这种方式实现起来简单，但同时有个问题就是至少需要发送两次请求才能得到自己喜欢的响应（第一次获取列表，第二次才是得到资源），显然会造成时延、浪费带宽。 19 | 20 | 2、服务器驱动实现方式：这种方式由服务器通过检测客户端发送过来的内容协商首部来主动决定发送相应版本的资源，涉及到著名q值检测技术。这种方式的问题就是，如果客户端的发送过来的相关首部不明确的话，那么就得服务器自己去判断了。 21 | 22 | 3、透明方式（代理缓存处理）：让代理代替客户端与服务器端进行协商，从而减轻了服务器端的请求压力。 23 | 24 | #### 客户端驱动的协商 25 | 26 | * 这种方式实际上有两种方法为客户端提供选项：一是发送回一个html文档，里面有到该页面的各种版本的链接和每个版本的描述信息；另一种是发送回HTTP/1.1响应式，使用300 Multiple Choices响应代码。不管怎么样，决定权在客户端。这种方式除了增加时延并且对每个页面都要进行繁琐的多次请求之外，还有个缺点就是需要多个url,比如有个资源www.xxxx.com有英语版本好中文版本，那么在把页面分享给朋友的时候就是这种情况：www.xxx.com/en和www.xxx.com/ch。 27 | 28 | #### 服务器驱动的协商 29 | 30 | * 我们知道客户端驱动的协商会增加额外的通信量，那么避免这种情况就是让服务器端主动决定发送什么给客户端。但是为了做到这一点，客户端必须发送有关客户偏好的足够信息。以便能够左春准确的决策。服务器通过客户端请求的首部集来获得这方面的信息。相关客户端可以发送给服务器做判断的首部如下： 31 | 32 | 1、Accept首部集 33 | 34 | 2、User-Agent 35 | 36 | #### 内容协商首部集 37 | 38 | * 客户端通过下列首部来描述自己的偏好信息： 39 | 40 | ``` code 41 | 42 | Accept 告知服务器发送何种媒体类型 43 | 44 | Accept-Language 告知服务器发送何种语言 45 | 46 | Accept-Charset 告知服务器发送何种字符集 47 | 48 | Accept-Encoding 告知服务器采用何种编码 49 | 50 | 51 | ``` 52 | 53 | * Accept首部集和匹配的文档首部集 54 | 55 | ``` 56 | —————————————————————————————————————————— 57 | *Accept首部* *实体首部* 58 | —————————————————————————————————————————— 59 | Accept Content-Type 60 | Accept-Language Content-Language 61 | Accept-Charset Content-Type 62 | Accept-Encoding Content-Encoding 63 | 64 | ``` 65 | 66 | * 质量值：HTTP提供了一种机制，可以让使得客户端足以描述自己的偏好信息，这种机制就是质量值（简称q值）。 67 | 68 | #### 内容协商首部中的质量值 69 | 70 | * http协议中定义了质量值，允许客户端为每种偏好类别列出多种选项，并为每种偏好选项关联了一个优先次序。例如，客户端可以发送下列形式的Accept-Language首部： 71 | 72 | ``` 73 | Accept-Language: en;q=0.5, fr;q=0.0, nl;q=1.0, tr;q=0.0 74 | 75 | ``` 76 | 其中q值的范围从0.0~1.0（0.0是优先级最低的，而1.0是优先级最高的）。上面列出的那个首部，说明该客户端最愿意接收荷兰语（缩写为nl）文档，但英语（缩写为en）文档也行；无论如何，这个客户端都不愿意收到法语（缩写为fr）或土耳其语（缩写为tr）的版本。注意，偏好的排列顺序并不重要，只有与偏好相关的q值才是重要的。如果上面的列表中，服务器没有找到自己匹配的文档，那么服务器将会采取转码等修改文档方式来实现响应。 77 | 78 | #### 随其它首部集而变化 79 | 80 | * 如User-Agent(此方式没有q值机制)实现发送不支持javascript版本的资源给客户端。 81 | 82 | * Vary首部：这个首部告知缓存（还有客户端的和所有下游的代理）服务器根据哪些首部来决定发送响应的最佳版本。 83 | 84 | #### 透明协商 85 | 86 | * 透明协商机制试图从服务器上去除服务器驱动协商所需的负载，并用中间代理来代表客户端以使与客户端的报文交换最小化。假定代理了解客户端的预期，这样就可以代表客户端与服务器协商（在客户端请求内容的时候，代理已经收到了客户端的预期）。为了支持透明内容协商，服务器必须有能力告知代理，服务器需要检查哪些请求首部，以便对客户端的请求进行最佳匹配。HTTP/1.1规范中没有定义任何透明协商机制，但定义了Vary首部。服务器在响应中发送了Vary首部，以告知中间节点需要使用哪些请求首部进行协商。涉及到的首部有Vary。 87 | 88 | #### 转码 89 | 90 | * 如果服务器没有能满足客户端需求的文档会怎么样呢？服务器可以给出一个错误响应。但理论上，服务器可以把现存的文档转换成某种客户端可用的文档。这种选项称为转码。有三种类别的转码：格式转换、信息综合以及内容注入。 91 | 92 | 1、格式转换是指将数据从一种格式转换成另一种格式，使之可以被客户端查看。 93 | 94 | 2、信息综合是从文档中提取关键的信息片段称为信息综合。 95 | 96 | 3、前面描述的两类转码通常会减少Web文档的内容，但还有另一类转换会增加文档的内容，即内容注入转码。 97 | 98 | 此外，转码的替代做法是在web服务器上建立Web页面的不同副本，例如一个是HTML；一个是WML。但这种方式操作起来工程量大，一个小小的改动，所有的相关的页面都要更改，加大了存储空间等。 99 | 100 | 101 | -------------------------------------------------------------------------------- /第九章 Web机器人/readme.md: -------------------------------------------------------------------------------- 1 | ### 内容提要 2 | 3 | * 本章主要讲解了web机器人一些原理和介绍，以及怎样控制机器人的访问和业界的一些关于跟踪机器人的规范，最后需要理解的一点就是机器人跟我们客户端一样遵守http规范，它是某种形式上的客户端。 4 | 5 | #### 概念 6 | 7 | * Web机器人是能够在无需人类干预的情况下自动进行一系列Web事务处理的软件程序。人们根据这些机器人探查web站点的方式，形象的给它们取了一个饱含特色的名字，比如“爬虫”、“蜘蛛”、“蠕虫”以及“机器人”等！ 8 | 9 | #### 爬虫及爬行方式 10 | 11 | * “爬虫”主要采取的爬行方式是获取第一个web页面，然后递归地对各种信息性web站点进行遍历，从而获取相关页面。搜索引擎的爬虫是一些复杂的爬虫，因为他们不仅会爬行web页面，而且会把相关数据拉取回来建立数据库，方便用户搜索！ 12 | 13 | 1. 爬虫会从根集开始爬行 14 | 15 | 2. 爬虫会解析页面所有的url，并把它们转换绝对形式 16 | 17 | 3. 要避免环路的出现，因为这些环路会暂停或减缓机器人的爬行过程 18 | 19 | * 环路对爬虫有害的三个原因： 20 | 21 | 1. 爬虫会陷入循环之中，从而兜圈子，浪费带宽，无法获取新页面！ 22 | 23 | 2. 爬虫无限的请求服务器，从而阻塞了真正的用户去请求服务器，这是可以作为法律诉讼理由的！ 24 | 25 | 3. 爬虫服务器会被重复的数据充斥 26 | 27 | * 网络中两个url表面上看起来不一样，但是指向的是同一资源，那么这两个url就互相称为“别名”，由于别名问题的存在，所以爬虫会爬行重复的数据，所以爬虫有必要把url的进行规范化！从而解决相关数据重复问题。相关规范方法如：没有端口默认为80，把字符转义为等价字符，删除#标签等。 28 | 29 | #### 如何避免环路与重复 30 | 31 | * 规范化URL：将URL转换为标准形式以避免语法上的别名 32 | 33 | * 广度优先的爬行：每次爬虫都有大量潜在的URL要去爬行，如果实行广度URL优先爬行，那么即时碰到环路，机器人也可以回到环路中获取的下一个页面之前，如果采用深度优先方式，那么机器人很容易陷入环路，越陷越深。 34 | 35 | * 节流：限制一段时间内机器人可以从一个web站点获取的页面数量。通过节流来限制重复的页面总数和对服务器的访问总数。 36 | 37 | * 限制URL的大小：机器人可能会拒绝爬行超出特定长度（通常是1KB）的URL。如果环路使URL的长度增加，长度限制就会最终终止这个环路。但要小心，用此种技术肯定会让你错过一些内容，因为现在很多url都绑定了很多状态信息，所以一般情况下，它们长度都会很长。 38 | 39 | * URL/站点黑名单：维护一个与机器人环路和陷阱相对应的已知站点及URL列表，然后像躲避瘟疫一样避开它们。发现新问题时，就将其加入黑名单。 40 | 41 | * 模式检测：文件系统的符号连接和类似的错误配置所造成的环路会遵循某种模式，比如，URL会随着组件的复制逐渐增加。有些机器人会将具有重复组件的URL当作潜在的环路，拒绝爬行带有多于两或三个重复组件的URL。如形如“/dir/dir/dir...”格式的URL，那么机器人就怀疑它是潜在的环路，从而拒绝爬行。 42 | 43 | * 内容指纹：说白了就是机器人对曾经爬行过的内容进行计算从而算出一个校验和，那么继续爬行其他页面时候，如果发现其它页面的“校验和”和前面算的相等，那么机器人就认为此内容已经获取过了，不需要进行重新获取。 44 | 45 | * 人工监视：如题，人工检测，因为设计再好的机器人总是会陷入环路不能出来的时候，那么就需要人工进行干预，比如收集日志什么的。 46 | 47 | 48 | #### 机器人的HTTP 49 | 50 | * 相关首部 51 | 52 | >> User-Agent ：机器人名字 53 | 54 | >> From ：提供机器人管理者的E-mail地址 55 | 56 | >> Accept : 告知服务器可以发送那些媒体类型 57 | 58 | >> Referer ：提供包含了当前请求的URL的文档的URL 59 | 60 | * 虚拟主机需要爬虫带Host首部，要不然会返回错误主机的数据 61 | 62 | * 让爬虫使用条件请求是有意义的，因为有的数据内容没有改变，所以重复抓取是浪费空间的，只有在内容实际改变的时候才重新发起请求，即条件请求。 63 | 64 | #### 行为不当的机器人 65 | 66 | * 失控的机器人，比正常用户的请求速度快很多，当这类爬虫设计出现错误的时候，很容易短时间之内增加服务器的负载，阻止真正用户的访问，原因诸如：编程逻辑错误、陷入环路之中 67 | 68 | * 失效的url，url可能已经失效了，但是爬虫依然取请求它 ，这样会让服务器的日志文档里面增加了很多请求出错的记录。 69 | 70 | * 很长的错误url,同样请求这样一个url，会让服务器日志文档增加一个很杂论的出错记录 71 | 72 | * 爱打听的机器人，访问了一些管理者不允许访问的内容，涉及侵犯隐私 73 | 74 | * 动态网关访问 75 | 76 | 77 | #### 拒绝机器人访问 78 | 79 | * 通过一个叫robots.txt的文件来约束机器人的访问。它的思想就是指定那些部分机器人可以访问，那些部分机器人不能访问 80 | 。如果机器人遵循这个自愿约束标准，那么在请求所有资源之前，它需要获取robots.txt并解析它。 81 | 82 | * 请求robots.txt时针对服务器返回的状态码，爬虫所作的动作： 83 | 84 | >> 如果返回2xx代码，机器人就必须对内容进行解析，并使用排斥规则从那个站点上获取内容 85 | 86 | >> 如果返回404，机器人认为服务器没有激活排斥规则，所以它不受限制 87 | 88 | 89 | >> 如果返回401或403(访问限制)，表示机器人是完全受限的 90 | 91 | >> 如果返回503（服务器临时故障），那么机器人暂时停止访问，知道正常之后继续请求robots.txt 92 | 93 | >> 如果返回重定向代码，那么机器人也应该重定向到相关页面 94 | 95 | * robots.txt文件的格式：包括三种内容注释行、空行、规则行。如： 96 | 97 | ``` javascript 98 | 99 | # this robots.txt file allows Slurp & Webcrawler to crawl 100 | # the public parts of our site,but no other robots... 101 | 102 | User-Agent: slurp 103 | User-Agent: webcraler 104 | Disallow: /private 105 | 106 | User-Agent: * 107 | Disallow: 108 | 109 | ``` 110 | 111 | 112 | #### 简单聊一下搜索引擎 113 | 114 | * 搜索引擎是web机器人用得最多的领域 115 | 116 | * 最初开始的搜索引擎就是一个简单的数据，哪里维护者一个用户可能搜索的信息列表。但如今的搜索引擎确实一个相当复杂的数据库，存储有大量信息，用了很多爬虫去爬取数据。所以对用户来说，搜索引擎的检索信息的速度以及爬虫获取数据的速度是搜索引擎需要必须考虑的问题。 117 | 118 | * 全文检索就是一个数据库，给它一个单词，它可以立即提供包含那个单词的所有文档。创建了索引之后，就不需要对文档自身进行扫描了。 119 | 120 | * 搜索引擎都有自己的排序算法，如相关性排名算法，如某个单词在很多内容都出现了，那么它的相关度就很高，所有与此单词有关的内容都应该排在考前。当然了这样的索引差不多在爬虫去获取内容的时候就已经建立起这种索引了！ 121 | 122 | -------------------------------------------------------------------------------- /第四章 连接管理/readme.md: -------------------------------------------------------------------------------- 1 | ### 内容提要 2 | 3 | * 这一章主要讲解了http的下层协议tcp/ip的一些知识点：tcp/ip建立连接需要做的事情，tcp/ip所带来的时延，以及从http的角度出发，提升网络性能的一些方法，涉及到串行连接、并行连接、持久连接、管道连接等概念！以及介绍了如何关闭连接等概念。 4 | 5 | 6 | #### TCP/IP连接 7 | 8 | * TCP/IP是全球计算机及网络设备都在使用的一种常用的分组交换网络分层协议集，位于http下层。其实常谈论的http连接实际上就是tcp连接加上一些使用连接的规则，tcp为http提供了一条可靠的比特传输管道。一旦连接建立起来，在客户端和服务器的计算机之间交换的报文就永远不会丢失、受损或失序。 9 | 10 | * 通常http事务发生时会经过几个步骤，下面以访问http://www.xxx.com:80/path/index.html为例说明： 11 | 12 | 1. 浏览器从地址栏中解析处域名（主机名），也就是拿到www.xxx.com 13 | 14 | 2. 浏览器根据得到的主机名查询出ip地址，比如算出ip为202.43.78.3，（中间可能经过查找host文件或去查询dns服务器） 15 | 16 | 3. 浏览器解析出端口（http默认为80，https默认为443） 17 | 18 | 4. 浏览器发起一条到202.43.78.3端口为80的链接，（重建需要经过几次确定相关参数的来回“握手”） 19 | 20 | 5. 浏览器发起请求报文 21 | 22 | 6. 服务器返回响应报文 23 | 24 | 7. 浏览器关闭连接（其实浏览器和服务器都可以在不通知对方的情况关闭连接） 25 | 26 | 27 | * TCP流是分段的，由IP分组传输，也就是说最终http报文是以ip分组的形式在网络之间传输。一个ip分组包含的数据信息如下： 28 | 29 | ``` 30 | 1. ip分组首部（通常为20字节） 31 | 2. tcp段首部 （通常为20字节） 32 | 3. tcp数据块 （0个或多个字节，实际http报文数据就在这里） 33 | ``` 34 | 35 | 用一句话描述这个过程就是，http报文流给到tcp，tcp把报文分成一段一段的，然后tcp把每个tcp段交给ip，ip封装成一个ip分组，最后传输的是ip分组。（当然了这里我们忽略了ip下面的数据链路层和物理层） 36 | 37 | **TCP确定一个连接** 38 | 39 | * TCP用四个信息来唯一确定一条连接：源ip地址、源端口号、目的ip地址、目的端口号。只要其中有一个不同，那么就不是同一条连接。在任意时刻计算机都可以有几条tcp连接在打开状态。 40 | 41 | #### 对TCP性能的考虑 42 | 43 | * 首先相对建立tcp连接、发送http请求报文以及响应报文相比，http事务处理的时间相对短很多很多，此时延可不用讨论，除非你的服务器超负载了或正在处理复杂的运算。因此，http事务的时延往往由以下原因组成： 44 | 45 | 1. 首先客户端解析ip地址或者端口号需要时间，如果当前没有访问过相关资源，那么解析还需要查询dns服务器，此操作，造成的时延较多，可能花费数十秒。 46 | 47 | 2. 建立tcp链接会有建立时延，通常2s左右，如果当前的http事务较多，那么会很快叠加上去。 48 | 49 | 3. 传输、处理请求报文需要时间 50 | 51 | 4. 回传响应报文需要时间 52 | 53 | 5. 当然还有其他因素，比如硬件、网络负载，以及报文尺寸等！ 54 | 55 | * **性能聚焦区域** 56 | 57 | 这里简要说明一下，建立tcp链接这个过程可能存在的时延分析，包括：经典三次“握手”、tcp慢启动拥塞控制机制等！ 58 | 59 | * 经典三次“握手”说的就是http事务在建立tcp连接是需要做的相关参数确认过程，大概如下： 60 | 61 | 1. 客户端发送携带“SYN”标记的TCP段说明发起连接请求 62 | 63 | 2. 服务端返回“SYN”和“ACK”的TCP段说明已接受 64 | 65 | 3. 最后客户端发送确认信息以确认连接 66 | 67 | 68 | * tcp慢启动说明了，tcp连接会随着时间的增加进行自我调谐。这个主要目的防止突然的tcp连接增多导致网络瘫痪，所以它会慢慢的调整传输速度，这个机制就叫做TCP慢启动。 69 | 70 | 71 | 72 | #### HTTP连接的处理 73 | 74 | ##### 常被误解的connection首部 75 | 76 | * connection能承载三种字段值： 77 | 78 | ``` 79 | 80 | HTTP首部字段名，列出了只与此有关的首部； 81 | 82 | 任意标签值，用于描述此链接的非标准选项； 83 | 84 | 值close，说明操作完成之后需关闭这条持久连接。 85 | 86 | ``` 87 | 88 | 接收端在收到请求报文之后，对报文进行解析，并查看connection首部中列出的首部列表，并在转发出去之前，删除相关首部，这一行为称为：“对首部的保护”。 89 | 90 | 91 | ##### 串行处理事务时延 92 | 93 | * 此种机制描述了http事务一个一个接着发起，不能同时下载更多的资源，使得界面上用户看不到东西，体验不够好。串行连接没有很好的利用tcp/ip连接的慢启动机制！ 94 | 95 | * 优化方法主要有： 96 | 97 | ``` 98 | 并行连接 99 | 100 | 通过多条TCP连接发起并发的HTTP连接 101 | 102 | 持久连接 103 | 104 | 重用TCP连接，以消除连接及关闭时延 105 | 106 | 管道化连接 107 | 108 | 通过共享的TCP连接发起并发的HTTP请求 109 | 110 | 111 | ``` 112 | 113 | 114 | ##### 并行连接 115 | 116 | * 浏览同时发起过个http事务，因为是并行的，所以时延也并行的，这样总时延较小，页面呈现更快，体验较好。但也不是总是这样，因为如果在网络速度很慢的时候，多个连接会去竞争本来不多的带宽，那么就谈不上加快速度了。还有就是并行连接也是需要付出代价的，比如增加系统内训消耗、服务器负载，比如有一个100客户端同时对服务发起100tcp并行连接的话，那么服务器就得负责10000个处理请求，很快的你的服务器就会爆掉。当然了，并行连接确实能带来视觉上的速度提升，因为相比于串行连接慢慢地显示数据而并行一下子能全部显示完信息，视觉上并行连接会给人速度更快的感觉！ 117 | 118 | ##### 持久连接 119 | 120 | * 持久连接描述的是：如果对同ip、同端口的发起多个http事务连接，那么可以在前一个事务处理完成之后不要关闭tcp连接，以此来减小建立tcp、tcp慢启动所带来的时延。相关概念不再赘述！ 121 | 122 | 123 | ##### 管道化连接 124 | 125 | HTTP/1.1允许在持久连接上可选地使用请求管道。这是在keep-alive连接上的进一步性能优化。在响应到达之前，可以将多条请求放入队列。当第一条请求通过网络流向地球另一端的服务器时，第二条和第三条请求也可以开始发送了。在高时延网络条件下，这样做可以降低网络的环回时间，提高性能。 126 | 127 | * 管道连接的限制 128 | 129 | - - 如果不是持久连接就不要使用管道连接 130 | 131 | - - 接收端必须按收到请求报文的顺序返回响应报文，因为HTTP报文中没有序列号标签。所以必须靠按序发送响应报文来达到“数据对应” 132 | 133 | - - 发送端应该做好数据没有发送完连接就关闭的准备并开始重新发送数据。 134 | 135 | - - HTTP客户端不应该用管道化的方式发送会产生副作用的请求（比如POST）。 136 | 137 | ##### 关闭连接的奥秘 138 | 139 | 略 140 | 141 | 142 | -------------------------------------------------------------------------------- /第五章 web服务器/readme.md: -------------------------------------------------------------------------------- 1 | ### 内容提要 2 | 3 | * 本章简单介绍了web服务器原理、实现以及实现处理http事务的一些细节！ 4 | 5 | #### web服务器 6 | 7 | * 定义：实现提供资源或应答的提供者都可以谓之为服务器！ 8 | 9 | * 从不同形式划分，服务器有以下几种： 10 | 11 | 1. 标准计算机上安装的通用服务器，如apache 12 | 13 | 2. 购买的服务器 14 | 15 | 3. 嵌入式服务器 16 | 17 | #### web服务器应该做些什么 18 | 19 | 1. 接受建立连接请求 20 | 21 | 2. 接受请求 22 | 23 | 3. 处理请求 24 | 25 | 4. 访问报文中指定的资源 26 | 27 | 5. 构建响应 28 | 29 | 6. 发送响应 30 | 31 | 7. 记录事务处理过程 32 | 33 | 34 | #### 第一步————接受客户端连接 35 | 36 | * 客户端收到一条连接之后，那么它将会把新连接添加到现存web服务器连接列表中，用于监视当前连接上的数据传输情况。期间服务器还应该做到通过一定的设备机制阻止未认证或已知恶意黑名客户端的连接，相关设别技术有：客户端主机名设别、通过ident设别客户端用户等！ 37 | 38 | 39 | #### 第二步————接收请求报文 40 | 41 | * 主要经过几个步骤来解析报文： 42 | 43 | 1. 解析请求行，得知方法、url、协议版本，以及crlf符 44 | 45 | 2. 解析得到以crlf结尾的首部 46 | 47 | 3. 得到以crlf结尾，标志首部结束的空行（如果有的话） 48 | 49 | 4. 解析得到主体，（如果有的话） 50 | 51 | * web服务可能还会把请求报文用一种自己能快速处理的内部数据结构来存储请求报文！ 52 | 53 | * 不同的服务器配置预示它能同时处理的事务情况： 54 | 55 | 1. 单线程web服务器：只能处理一个请求，待当前请求处理完成之后才能处理下一个请求！优点：简单已于实现，适用于低负荷服务器。缺点：不能及时处理其他请求，容易引发延迟过长而导致性能问题。 56 | 57 | 2. 多线程及多进程web服务器：能同时处理多个请求！优点：响应及时。缺点：构建复杂，容易快速引起内存消耗过大而死机！最好应该对能同时处理的连接数量进行限制！ 58 | 59 | 3. 复用i/o的web服务器：复用i/o 60 | 61 | 4. 复用i/o和多线程的web服务器：2和3的结合 62 | 63 | 64 | #### 第三步————处理请求 65 | 66 | * 这点留在本书其余章节大篇幅介绍！ 67 | 68 | #### 第四步————对资源的映射及访问 69 | 70 | * 这里介绍了请求资源的一种路径映射关系，说白了就是找到客户端请求资源在服务器的上的目录路径！相关概念有：docroot(文档根目录)、不允许访问根目录的上一级目录。 71 | 72 | 73 | * 虚拟托管的docroot:在一个服务器上挂了几个web站点，那么这样当请求的资源路径相同时，服务器应该从请求报文首部的host、uri字段找出真正的资源目录，这些目录都是可以配置的！ 74 | 75 | * 注：这里对用户配置文件根目录和虚拟目录做一下示例说明，以apache为例： 76 | 77 | ``` 78 | 配置文件根目录 79 | 在配置文件httpd.conf中添加一个DocumentRoot行就可以为Apache Web服务器设置文档的根目录了，如： 80 | 81 | DocumentRoot /user/local/httpd/files 82 | 83 | 84 | 配置虚拟目录 85 | 对大多数Web服务器来说，配置虚拟托管的文档根目录是很简单的。对常见的Apache Web服务器来说，需要为每个虚拟Web 86 | 站点配置一个VirtualHosts块，而且每个虚拟服务器都要包含DocumentRoot，如： 87 | 88 | 89 | ServerName www.joes-hardware.com 90 | DocumentRoot /docs/joe 91 | TransferLog /logs/joe.access_log 92 | ErrorLog /logs/joe.error_log 93 | 94 | 95 | 96 | ServerName www.marys-antiques.com 97 | DocumentRoot /docs/mary 98 | TransferLog /logs/mary.access_log 99 | ErrorLog /logs/mary.error_log 100 | 101 | 102 | ... 103 | 104 | ``` 105 | 106 | #### 第五步————构建响应 107 | 108 | * 构建响应报文：1、正确设置响应主体的长度（content-length）；2、设置报文的mime类型（content-type）,主要通过与一直mime类型文件匹配得到当前的文件的mime类型，还可以通过文件扩展名，以及硬规定特定目录下的文件拥有某个mime类型；3、控制重定向！ 109 | 110 | * 服务器端如何得出文件的MIME类型： 111 | 112 | ``` 113 | 114 | Web服务器要负责确定响应主体的MIME类型。有很多配置服务器的方法可以将MIME类型与资源关联起来。 115 | 116 | 1、MIME类型（mime.types） 117 | Web服务器可以用文件的扩展名来说明MIME类型。Web服务器会为每个资源扫描一个包含了所有扩展名的MIME类型的文件，以确定其MIME类型。这种基于扩展名的类型相关是最常见的！ 118 | 119 | 2、魔法分类（Magic typing） 120 | Apache Web服务器可以扫描每个资源的内容，并将其与一个已知模式表（被称为魔法文件）进行匹配，以决定每个文 121 | 件的MIME类型。这样做可能比较慢，但很方便，尤其是文件没有标准扩展名的时候。 122 | 123 | 3、显示分类（Explicit typing） 124 | 可以对Web服务器进行配置，使其不考虑文件的扩展名或内容，强制特定文件或目录内容拥有某个MIME类型 125 | 126 | 4、类型协商 127 | 有些Web服务器经过配置，可以以多种文档格式来存储资源。在这种情况下，可以配置Web服务器，使其可以通过与用户的协商来是决定使用哪种格式（及相关的MIME类型）“最好”。 128 | 129 | ``` 130 | 131 | 132 | ##### 重定向 133 | 134 | * 有时服务器需要返回重定向报文来构建响应，重定向响应由返回码3XX说明。Location响应首部包含了内容的新地址或优选地址的URL。重定向可用于下列情况。 135 | 136 | - - 永久删除的资源，状态码为301 137 | 138 | - - 临时删除的资源，状态码为303或307 139 | 140 | - - URL增强，状态码为303或307 141 | 142 | - - 负载均衡，主要是减少服务器的压力，让请求跑到一个负载不大的服务器上去，状态码为303或307 143 | 144 | - - 服务器关联，去保存有用户本地信息的服务器上获取用户信息，状态码为303或307 145 | 146 | - - 规范目录名称，客户端请求的URI是一个不带尾部斜线的目录名时，大多数Web服务器都会将客户端重定向到一个加了斜线的URI上，这样相对链接就可以正常工作了！ 147 | 148 | 149 | #### 第六步————发送响应 150 | 151 | * 略 152 | 153 | #### 第七步————记录事务日志 154 | 155 | * 在web服务器日志文件中添加一个条目，以描述当前事务处理情况！ 156 | 157 | 158 | 159 | 160 | 161 | -------------------------------------------------------------------------------- /readme.md: -------------------------------------------------------------------------------- 1 | # 《HTTP权威指南》概念手册 2 | 3 | ## *前言* 4 | 5 | * 需要说明一下，因为一直有在看《HTTP权威指南》，觉得这是一本很值得称赞的一本高质量的书籍，书中内容涵盖很全面，而且配以插图，使得阅读起来很容易理解！无论是对于已经踏足开发领域的老手，还是刚接触相关领域的新手，都可以接触。所以很推荐大家从头到尾过一遍，我相信看过之后对某些概念将会有一个更深层次的理解！当然了，我的建议是对这本书多过几遍，因为这样才能加深映像同时加深理解！毕竟常言道：“书读百遍，其意自见、温故而知新等都说明了书需要多次阅读才能体会其意，才能从中读出更深层次的含义”！ 6 | 7 | * 首先说明一下，这个文档并不是要超越《HTTP权威指南》原书，文档中描述到的所有概念都是基于原书的！因为原书对相关概念介绍的太过仔细，所以原书的篇幅过于太长，而我常常出现的情况是对原书中的一些概念记忆模糊，需要通过再次查看才能回忆起来，可是我发现每次重新去找某些知识点的时候，发现是一个很耗时、复杂的过程，因为得到相关章节一页一页的去找，而我只是对于某个概念“模糊”而已，所以我觉得这个过程是不必要的，同时，我希望通过自己在文档中对原书的一些概念进行提炼性的总结来加深自己的记忆映像！因此才有了这个文档的诞生！ 8 | 9 | * 切记！！此文档是基于原书的，所以希望读者都是看过原书的。所以你没有看过原书，而直接来这里看，那么是没有意义的，因为本文档没有图文并茂的实例，更没有代码供查看，有的只是从原书中copy过来的“提炼过”的文字、概念而已。 10 | 11 | * 最最最后再说一下，由于时间仓促，所以有些地方表达不是很到位的地方，那么请您以原书为主！再次感谢的阅读！ 12 | 13 | 14 | 15 | 16 | ## 目录 17 | 18 | ### *[第一章 HTTP概述](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E4%B8%80%E7%AB%A0%20HTTP%20%E6%A6%82%E8%BF%B0)* 19 | 20 | 21 | ### *[第二章 URL与资源](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E4%BA%8C%E7%AB%A0%20URL%E4%B8%8E%E8%B5%84%E6%BA%90)* 22 | 23 | 24 | ### *[第三章 HTTP报文](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E4%B8%89%E7%AB%A0%20HTTP%E6%8A%A5%E6%96%87)* 25 | 26 | 27 | ### *[第四章 连接管理](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E5%9B%9B%E7%AB%A0%20%E8%BF%9E%E6%8E%A5%E7%AE%A1%E7%90%86)* 28 | 29 | ### *[第五章 web服务器](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E4%BA%94%E7%AB%A0%20web%E6%9C%8D%E5%8A%A1%E5%99%A8)* 30 | 31 | ### *[第六章 代理](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E5%85%AD%E7%AB%A0%20%E4%BB%A3%E7%90%86)* 32 | 33 | ### *[第七章 缓存](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E4%B8%83%E7%AB%A0%20%E7%BC%93%E5%AD%98)* 34 | 35 | ### *[第八章 集成点：网关、隧道及中继](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E5%85%AB%E7%AB%A0%20%E9%9B%86%E6%88%90%E7%82%B9%EF%BC%9A%E7%BD%91%E5%85%B3%E3%80%81%E9%9A%A7%E9%81%93%E5%8F%8A%E4%B8%AD%E7%BB%A7)* 36 | 37 | ### *[第九章 Web机器人](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E4%B9%9D%E7%AB%A0%20Web%E6%9C%BA%E5%99%A8%E4%BA%BA)* 38 | 39 | ### *[第十章 HTTP-NG](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E5%8D%81%E7%AB%A0%20HTTP-NG)* 40 | 41 | ### *[第十一章 客户端识别与Cookie机制](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E5%8D%81%E4%B8%80%E7%AB%A0%20%E5%AE%A2%E6%88%B7%E7%AB%AF%E8%AF%86%E5%88%AB%E4%B8%8ECookie%E6%9C%BA%E5%88%B6)* 42 | 43 | ### *[第十二章 基本认证机制](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E5%8D%81%E4%BA%8C%E7%AB%A0%20%E5%9F%BA%E6%9C%AC%E8%AE%A4%E8%AF%81%E6%9C%BA%E5%88%B6)* 44 | 45 | ### *[第十三章 摘要认证](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E5%8D%81%E4%B8%89%E7%AB%A0%20%E6%91%98%E8%A6%81%E8%AE%A4%E8%AF%81)* 46 | 47 | ### *[第十四章 安全HTTP](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E5%8D%81%E5%9B%9B%E7%AB%A0%20%E5%AE%89%E5%85%A8HTTP)* 48 | 49 | ### *[第十五章 实体和编码](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E5%8D%81%E4%BA%94%E7%AB%A0%20%E5%AE%9E%E4%BD%93%E5%92%8C%E7%BC%96%E7%A0%81)* 50 | 51 | ### *[第十六章 国际化](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E5%8D%81%E5%85%AD%E7%AB%A0%20%E5%9B%BD%E9%99%85%E5%8C%96)* 52 | 53 | ### *[第十七章 内容协商与转码](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E5%8D%81%E4%B8%83%E7%AB%A0%20%E5%86%85%E5%AE%B9%E5%8D%8F%E5%95%86%E4%B8%8E%E8%BD%AC%E7%A0%81)* 54 | 55 | ### *[第十八章 Web主机托管](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E5%8D%81%E5%85%AB%E7%AB%A0%20Web%E4%B8%BB%E6%9C%BA%E6%89%98%E7%AE%A1)* 56 | 57 | ### *[第十九章 发布系统](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E5%8D%81%E4%B9%9D%E7%AB%A0%20%E5%8F%91%E5%B8%83%E7%B3%BB%E7%BB%9F)* 58 | 59 | ### *[第二十章 重定向与负载均衡](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E4%BA%8C%E5%8D%81%E7%AB%A0%20%E9%87%8D%E5%AE%9A%E5%90%91%E4%B8%8E%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1)* 60 | 61 | ### *[第二十一章 日志记录与使用情况跟踪](https://github.com/woai30231/http/tree/master/%E7%AC%AC%E4%BA%8C%E5%8D%81%E4%B8%80%E7%AB%A0%20%E6%97%A5%E5%BF%97%E8%AE%B0%E5%BD%95%E4%B8%8E%E4%BD%BF%E7%94%A8%E6%83%85%E5%86%B5%E8%B7%9F%E8%B8%AA)* -------------------------------------------------------------------------------- /第二十一章 日志记录与使用情况跟踪/readme.md: -------------------------------------------------------------------------------- 1 | ## 内容提要 2 | 3 | * 本章主要介绍了代理缓存和服务器日志记录的一些情况，以及怎么解决代理缓存问题造成日志记录出现遗漏的问题！ 4 | 5 | ### 为什么需要日志记录 6 | 7 | * 几乎所有的服务器和代理都会记录下它们所处理的HTTP事务摘要。这么做出于一系列的原因：跟踪使用情况、安全性、计费、错误检验，等等。 8 | 9 | ### 那些内容该记录 10 | 11 | * 如果把访问的点点滴滴都一五一十的记录下来，是一个很没有意义的过程，暂且不说有的网站的事务量超大到难以计数的问题，把全部信息记录下来，这个日志文件可想而知得有多大。就日志记录对我们统计需求的作用而言，因为有的数据对我们来说意义不大，甚至可能看都不会看一眼，所以有选择性的记录一些内容变得很重要。通常，只记录事务的基本信息就行了。通常会记录下来的几个字段示例为： 12 | 13 | - - HTTP方法：主要记录事务用了什么方法 14 | 15 | - - 客户端和服务器的HTTP版本：给出客户端和服务器有关的提示，比如兼容性提示什么的 16 | 17 | - - 所请求资源的URL：记录Web站点某个资源的访问频率和受欢迎程度 18 | 19 | - - 响应的HTTP状态码：主要说明请求的执行情况成功与否 20 | 21 | - - 请求和响应报文的尺寸（包含所有的实体主体部分）：记录大小 22 | 23 | - - 事务开始时的时间戳：记录发生时间 24 | 25 | - - Referer首部和User-Agent首部的值：主要记录从那个页面跳过来以及用户代理 26 | 27 | ### 日志格式 28 | 29 | * 大部分http程序都支持管理者配置日志格式，以便于更好地利用已有工具对日志进行处理，从而方便汇总。 30 | 31 | #### 常用日志格式 32 | 33 | * 以下是常用格式字段 34 | 35 | ``` 36 | remotehost 请求端机器的主机名或IP地址（如果没有配置服务器去执行反 37 | 向DNS或无法查找请求段的主机名，就使用IP地址） 38 | 39 | username 如果执行了ident查找，就是请求端已认证的用户名 40 | 41 | auth-username 如果进行了认证，就是请求端已认证的用户名 42 | 43 | timestamp 请求的日期和时间 44 | 45 | request-line 精确的HTTP请求行文本，GET /index.html HTTP/1.1 46 | 47 | response-code 响应中返回的HTTP状态码 48 | 49 | response-size 响应主体中的Content-Length,如果响应中没有返回主体，就记录0 50 | 51 | 52 | ``` 53 | 54 | 55 | #### 组合日志格式 56 | 57 | * 组合日志格式与常用日志格式很类似。实际上，它就是常用日志格式的精确镜像，只是添加了两个字段。User-Agent字段用于说明是哪个HTTP客户端应用程序在发起已被记录的请求，而Referer字段则提供了更多与请求端在何处找到这个URL的有关信息。 58 | 59 | * 新加的组合日志格式字段 60 | 61 | ``` 62 | Referer Referer首部的内容 63 | 64 | User-Agent User-Agent首部的内容 65 | 66 | ``` 67 | 68 | #### 网景扩展日志格式 69 | 70 | * 网景的格式是基于NCSA的常用日志格式的，但它扩展了该格式，以支持与代理和Web缓存这样的HTTP应用程序相关的字段。网景扩展日志格式的前7个字段与常用日志格式中的那些字段完全相同。 71 | 72 | * 网景扩展日志格式新加的字段 73 | 74 | ``` 75 | proxy-response-code 如果事务处理经历了某个代理，就是从服务器传往代理的HTTP响应码 76 | 77 | proxy-response-size 如果事务处理经历过了某个代理，就是发送给代理的服务器响应实体 78 | 的Content-Length 79 | 80 | client-request-size 发给代理的客户端请求的所有主体或实体的Content-Length 81 | 82 | proxy-request-size 如果事务处理经历过了某个代理，就是代理发往服务器的 83 | 请求的所有主体或者实体的Content-Length 84 | 85 | client-request-hdr-size 以字节为单位的客户端请求首部的长度 86 | 87 | proxy-response-hdr-size 如果事务处理经过了某个代理，就是以字节为单位的，发送给请求 88 | 端的代理响应首部的长度 89 | 90 | proxy-request-hdr-size 如果事务处理经历过了某个代理，就是以字节为单位的，发送 91 | 给服务器的代理请求首部的长度 92 | 93 | server-response-hdr-size 以字节为单位的，服务器响应首部的长度 94 | 95 | proxy-timetamp 如果事务处理经历过了某个代理，就是请求和响应经过代理 96 | 传输所经过的时间（单位为秒） 97 | 98 | ``` 99 | 100 | #### 网景扩展2日志格式 101 | 102 | * 另一种网景日志格式，网景扩展2日志格式采用了扩展日志格式，并添加了一些与HTTP代理和Web缓存应用程序有关的附加信息。这些附加字段有助于更好地描绘HTTP客户端和HTTP代理应用程序间的交互图景。 103 | 104 | * 附加的网景扩展2日志格式字段 105 | 106 | ``` 107 | route 代理用来向客户端发送请求的路径 108 | 109 | client-finish-status-code 客户端完成状态码。说明了发送给代理的客户端请求 110 | 是成功完成（FIN）了，还是被打断了（INTR） 111 | 112 | proxy-finish-status-code 代理完成状态码，说明代理发送给服务器的请求是成功完成（FIN） 113 | 了，还是被打断了（INTR） 114 | 115 | cache-result-code 缓存结果代码；说明缓存是如何响应请求的 116 | 117 | ``` 118 | 119 | #### Squid代理日志格式 120 | 121 | * Squid日志格式字段 122 | 123 | ``` 124 | timestamp 请求到达时的时间戳，是从格林尼治标准时间1970年 125 | 1月1日开始的秒数 126 | 127 | time-elapsed 请求和响应通过代理传输所经历的时间（以毫秒为单位） 128 | 129 | host-ip 客户端（请求端）主机的IP地址 130 | 131 | result-code/status result字段是Squid类型的，用来说明在此请求过程中代理 132 | 采取了什么动作，code字段是代理发送客户端的HTTP响应代码 133 | 134 | size 代理响应客户端的字节长度，包括HTTP响应首部和主体 135 | 136 | method 客户端请求的HTTP方法 137 | 138 | url 客户端请求中的URL 139 | 140 | rfc931-ident 客户端经过认证的用户名 141 | 142 | hierarchy/from 与网景格式中的route字段一样，hierarchy字段说明了代理向客户端 143 | 发送请求时经由的路径。from字段说明了代理发起请求时的服务器名称 144 | 145 | content-type 代理响应实体的Content-Type 146 | 147 | 148 | ``` 149 | 150 | ### 命中率测量 151 | 152 | * 缓存服务器位于客户端和服务器之间，用于防止服务器同时处理大量访问请求（这正是缓存的目的）。缓存要处理很多HTTP请求，并在不访问原始服务器的情况下满足它们的请求，服务器中没有客户端访问其内容的记录，导致日志文件中出现遗漏。由于日志数据会遗失，所以，内容提供者会对其最重要的页面进行缓存清除（cachebust）。缓存清除是指内容提供者有意将某些内容设置为无法缓存，这样，所有对此内容的请求都会被导向原始服务器。于是，原始服务器就可以记录下访问情况了。不使用缓存可能会生成更好的日志，但会减缓原始服务器和网络的请求速度，并增其负荷。 153 | 154 | * 命中率测量协议是对HTTP的一种扩展，它为这个问题提供了一种解决方案。命中率测量协议要求缓存周期性地向原始服务器汇报缓存访问的统计数据。 -------------------------------------------------------------------------------- /第十五章 实体和编码/readme.md: -------------------------------------------------------------------------------- 1 | ### 内容提要 2 | 3 | * 本章主要介绍了http实际传输的货物————实体。以及与实体有关的一些实体首部及原理，当然了还介绍了为了减小带宽所作的一些编码措施和原理（内容编码和传输编码）！ 4 | 5 | #### HTTP报文应该具备的功能 6 | 7 | * 为了更好的描述http所传输数据的类型、大小、有效性等，http协议应该为主体提供以下描述信息： 8 | 9 | 1、可以被正确的识别（通过Content-Type首部说明媒体格式），以便接收端能够识别并正确处理内容 10 | 11 | 2、是最新的（通过实体验证码和缓存过期控制） 12 | 13 | 3、符合用户的需要（基于Accept系列的内容协商首部） 14 | 15 | 4、在网络上可以快速有效地传输（通过范围请求、差异编码以及其他数据压缩方法） 16 | 17 | 5、完整到达、未被篡改（通过传输编码首部和Content-MD5校验和首部） 18 | 19 | #### 报文是箱子，实体是货物 20 | 21 | * 实体由实体首部和实体主体组成，实体首部是描述货物信息的，实体主体是原始货物。 22 | 23 | * 相关首部如下： 24 | 25 | 1、Content-Type:实体中所承载对象的类型 26 | 27 | 2、Content-Length:所传送实体主体的长度或大小，（注意：如果主体采取了内容编码进行压缩，那么它所指的是压缩后的长度或大小，此首部是描述报文主体结束的关键，尤其在持久连接时对多个报文进行正确分段） 28 | 29 | 3、Content-Language:与所传送对象最相配的人类语言 30 | 31 | 4、Content-Encoding:对象数据所做的任意变换（比如，压缩） 32 | 33 | 5、Content-Location:一个备用位置，请求时可通过它来获得对象 34 | 35 | 6、Content-Range:如果这是部分实体，这个首部说明它是整体的那个部分 36 | 37 | 7、Content-MD5:实体主体内容的校验和 38 | 39 | 8、Last-Modified:所传输内容在服务器上创建或最后修改的日期时间 40 | 41 | 9、Expires:实体主句将要失效的日期时间 42 | 43 | 10、Allow:改资源所允许的各种请求方法，例如，GET和HEAD 44 | 45 | 11、ETag:这份文档特定实例的唯一验证码，ETag首部没有正式定义为实体首部，但它对许多涉及实体的操作来说，都是一个重要的首部 46 | 47 | 12、Cache-Control:指出应该如何缓存该文档。和ETag首部类似，Cache-Control首部没有正式定义为实体首部 48 | 49 | 50 | #### Content-Length:实体的大小 51 | 52 | * http的早期版本采用关闭连接的办法来划定报文的结束，但是，没有Content-Length的话，客户端就无法判别到底是报文结束时正常的连接关闭，还是报文传输中由于服务器崩溃而导致的连接关闭。客户端需要通过Content-Length来检测报文截尾。注意这个后果对于缓存是很严重的，可能造成缓存长时间用不完整的内容来响应客户端。 53 | 54 | * Content-Length与持久连接：拥有Content-Length就能对报文进行正确的分段 55 | 56 | * 内容编码：有时候服务器采用内容编码来压缩实体主体以节省空间，Content-Length描述的是压缩过后的长度或大小 57 | 58 | * 确定实体主体长度的规则，以下规则，谁先匹配到就用谁： 59 | 60 | 1、如果特定的HTTP报文类型中不允许带有主体，那么就忽略Content-Length首部。常见情况有：1XX、204以及304响应，还有HEAD方法的响应。 61 | 62 | 2、如果报文中含有描述传输编码的Transfer-Encoding首部，那么实体就应由一个称为“零字节块”的特殊模式结束。 63 | 64 | 3、如果报文中，有Content-Length首部而无Transfer-Encoding首部，那么Content-Length就是描述首部的长度。如果有Content-Length首部，同时也有Transfer-Encoding首部，那么就必须忽略Content-Length,因为传输编码会改变实体主体的表示和传输方式（因此可能就会改变传输的字节数）。 65 | 66 | 4、如果报文使用了multipart/byteranges(多部分/字节范围)媒体类型，且无Content-Length首部，那么报文长度有报文去自定界。 67 | 68 | 5、如果以上规则都不匹配，实体的长度就是关闭连接时所得到的的主体的长度。这个值实际上由服务器关闭连接得到。客户端关闭连接将使服务器无法响应。 69 | 70 | #### 实体摘要 71 | 72 | * 虽然http建立在tcp/ip这样的可靠传输协议之上，但是还是有很多原因导致报文在传输过程被修改。发送方可以在生成初始的主体时，生成一个数据的校验和。遮掩接收方就可以通过检查这个校验和来捕获所有意外的实体修改了。 73 | 74 | #### 媒体类型和字符集 75 | 76 | * 记住一点：Content-Type首部字段说明了实体主体的MIME类型，其值是标准化的MIME类型，都在互联网号码分配机构中注册。 77 | 78 | 79 | #### 内容编码 80 | 81 | * 编码过程： 82 | 83 | 1、生成原始响应报文，有Content-Type和Content-Length首部。 84 | 85 | 2、编码服务器对报文进行编码，编码之后同样拥有Content-Type和Content-Length首部,但是Content-Length可能不同（比如主体被压缩了），同时增加了Content-Encoding首部，这样接收端就知道怎样去解码了。 86 | 87 | 3、接收端解码，得到原始报文 88 | 89 | * Accept-Encoding首部：该首部描述了接收端能处理的编码方式 90 | 91 | #### 传输编码和分块编码 92 | 93 | * 相关首部：Transfer-Encoding首部告诉接收方自己使用了何种编码。TE首部告诉发送端自己希望收到何种编码。 94 | 95 | * 分块编码：首先分块编码是一种传输编码，其格式大致为：http响应首部块开始，随后就是一系列分块，每个分块包含一个长度值和该分块的数据。长度值是16进制形式并将CRLF与数据分隔开。最后一个块有点特别，它的长度值为0，表示“主体结束”。 96 | 97 | * 分块报文中的拖挂（可选），拖挂中可以包含附带的首部字段，它们的值在报文开始的时候可能是无法确定的（例如，必须要先生成主体的内容）。Content-MD5首部就是一个可以在拖挂中发送的首部。 98 | 99 | #### 验证码和新鲜度 100 | 101 | * 相关语法： 102 | 103 | 1、Expires: 要求客户端和服务器时钟同步。 104 | 105 | 2、Cache-Control: 其相关参数如下（括号中的值表示用在请求报文还是响应报文）： 106 | 107 | >> no-cache(请求)，在重新向服务器验证之前，不要返回文档的缓存版本 108 | 109 | >> no-store(请求)，不要返回文档的缓存版本，不要保存服务器的响应 110 | 111 | >> max-age(请求)，缓存中的文档不能超过指定的试用期 112 | 113 | >> max-stale(请求)，文档允许过期，但不能超过指令中的指定的过期值 114 | 115 | >> min-fresh(请求)，文档的试用期不能小于这个指定的时间与它的当前存活时间之和，换句话说，响应必须至少在指定的这段时间之内保持新鲜 116 | 117 | >> no-transform（请求），文档在发送之前不允许被转换 118 | 119 | >> only-if-cached(请求)，只要当文档在缓存中才发送，不要联系原始服务器 120 | 121 | >> public(响应)，响应可以被任何服务器缓存 122 | 123 | >> private(响应)，响应可以被缓存，但只能被单个客户端访问，换句话说，就是本地缓存。 124 | 125 | >> no-cache(响应)，如果该指令伴随一个首部列表的话，那么内容可以被缓存并提供给客户端，但必须先删除所列出的首部，如果没有指定首部，缓存中的副本在没有重新向服务器验证之前不能提供给客户端。 126 | 127 | >> no-store(响应)，不允许被缓存 128 | 129 | >> no-transform(响应)，响应在提供给客户端之前不能做任何形式的修改 130 | 131 | >> must-revalidate(响应)，响应在提供给客户端之前必须重新向服务器验证 132 | 133 | >> proxy-revalidate(响应)， 共享的缓存在提供给客户端之前必须重新向原始服务器验证，私有的缓存可以忽略这条执行 134 | 135 | >> max-age(响应)，指定文档可以被缓存的时间以及新鲜度的最长时间 136 | 137 | >> s-max-age(响应)，指定文档作为共享缓存时的最长使用时间，私有的缓存可以忽略本指令 138 | 139 | * 有条件的请求与验证码，概念如下： 140 | 141 | 1、有条件的请求，仅当资源改变时才请求副本，这种特殊请求称为有条件的请求。 142 | 143 | 2、验证码，说白一点客户端发送什么条件过去可以获知当前文档不新鲜了，所以常用的验证码就是文档最后修改时间以及实例标记。比如有条件的首部If-Modified-Since测试的是文档实例最后被修改的日期时间，因此我们最后被修改的日期时间就是验证码。 144 | 145 | * 相关首部(括号里面的就是其验证码)： 146 | 147 | 1、If-Modified-Since（Last-Modified）:如果在前一条响应的Last-Modified首部中说明的时间之后，资源的版本发生变化，就发送其副本。 148 | 149 | 2、If-Unmodified-Since(Last-Modified):仅在前一条响应的Last-Modified首部中说明的时间之后，资源的版本没有变化，才发送其副本 150 | 151 | 3、If-Match(ETag):如果实体的标记与前一次响应首部的ETag相同，就发送该资源的副本 152 | 153 | 4、If-None-Match（ETag）:如果实体的标记与前一次响应首部中的ETag不同，就发送该资源的副本 154 | 155 | * 弱验证码和强验证码：弱验证码不一定能唯一标志资源的一个实例，而强验证码能唯一标志一个文档的实例。例如用文档字节数来验证一个文档是否有改变，可能会出现的情况就是，虽然字节数大小没有变，但是内容确实变了，所以字节数验证码是弱验证码，而资源内容的加密校验和（比如MD5）就是强验证码，因为当文档改变时它总是会改变。注：在ETag首部的值前面加上W/，把其标记为弱验证码，此时只是主体发生显著变化时，才会从服务器取资源。 156 | 157 | 158 | #### 范围请求 159 | 160 | * 概念：Range允许客户端实际只请求文档的一部分，或者说某个范围。 161 | 162 | #### 差异编码 163 | 164 | 概念：差异编码是HTTP协议的一个扩展，它通过交换对象改变的部分而不是完整的对象来优化传输性能。 165 | 166 | 相关首部：A-IM(请求)指出接受何种差异编码，IM(响应)指出使用了何种差异编码。 -------------------------------------------------------------------------------- /第七章 缓存/readme.md: -------------------------------------------------------------------------------- 1 | ### 内容提要 2 | 3 | * 本章主要从缓存的架构、优势、节省带宽流量、提升响应及处理步骤等方面阐述了web缓存！ 4 | 5 | #### 使用缓存的优点 6 | 7 | * 缓存减少了冗余的数据传输，因为毕竟每次http事务请求的东西都是一样的时候，多次发送同样的数据是不必要和冗余的！ 8 | 9 | * 缓存缓解了网络瓶颈的问题，不需要更多的带宽就能够更快地加载页面！ 10 | 11 | * 缓存降低了对原始服务器的要求，因为想象一下，从一个性能很差劲的原始服务器和从一个性能和牛逼的缓存服务器请求事务，肯定会弥补服务器的缺点的，同时也会减少服务器过载情况，因为大部分请求都由缓存代劳处理了！ 12 | 13 | * 缓存降低了距离时延，因为从较远的地方加载页面会更慢一些！ 14 | 15 | #### 冗余的数据传输 16 | 17 | * 每次都从原始服务器拿数据，那么带来的后果就是：多次发送重复的数据浪费流量、耗费昂贵的网络带宽从而降低传输速率、加大服务器的负载。而有了缓存之后这些问题都可以迎刃而解！ 18 | 19 | #### 带宽瓶颈 20 | 21 | * 带宽瓶颈说明的问题：很多网络为本地客户端配置的带宽要比远程服务器配置的带宽要宽，如果在这种状况下客户端去请求远程服务器，那么客户端将会以一种的较低的速度去请求服务端，从而没有发挥出客户端带宽宽的长处！如果在客户端方向配置一个高速缓存服务器，那么就可以很快的得到响应，由此也看出带宽对报文传输速率的影响！ 22 | 23 | 24 | #### 瞬间拥塞 25 | 26 | * 瞬间拥塞描述的是这样一种情况：一个爆炸性的新闻和热点事件，如果再没有配置缓存的情况下，那么在短时间之内，服务器将会收到突变的请求增长，负荷会爆炸性增长，肯定会吃不消的！但是有了缓存，可以大大分担服务器的负载数量！ 27 | 28 | 29 | #### 距离时延 30 | 31 | * 距离时延说明的一个问题就是传输数据过程这个过程是需要时间的，而且路程越长，那么需要的时间也会越多，即时延越长。所以在距离客户端较近的地方部署缓存服务器，减小了传输路程，那么就减小了传输时延！ 32 | 33 | #### 命中与未命中的 34 | 35 | * *缓存命中与缓存未命中：*一次http事务请求如果是从得到的响应是从缓存得到的原始响应副本，那么这样的过程就称之为缓存命中。反之，如果缓存没有响应的副本，而要去请求原始服务，那么就把这个过程称之为缓存未命中！ 36 | 37 | * *http再验证:*原始响应内容是在变化的，所以缓存应该在文档“过期时间”之后去验证缓存的副本是不是新鲜的，这个过程就叫做http再验证！如果再验证之后得知缓存副本是新鲜的，那么原始服务器返回304 not modified。此时，称之为*再验证命中*或*缓存慢命中*！如果得知缓存不是新鲜的，那么服务器返回200 ok。此时，称之为*再验证未命中*！如果原始对象已经被删除了，返回404 not found响应。相应地缓存副本要删除。（注：虽然再验证命中需要跟原始服务器沟通一次，但是它与直接请求服务器相比，还是要快一点，因为再验证命中只是返回了一些新的过期时间有关的新首部而已，并没有发送主体对象。） 38 | 39 | 40 | * *命中率*指由缓存返回副本事务在全部事务中所占的比例，称为缓存命中率。这个数据实际中意义不是很大！而*字节命中率*从资源大小总量的角度说明缓存命中所占的比例。因为他从数据流量的角度出发，所以实际中这个数据的意义挺大的！ 41 | 42 | * *区分命中和未命中*，简单来说，http没有相应的机制来告知客户端响应是从缓存得到的还是从原始服务器得到的！但我们可以从http响应报文首部中的date字段得知这一情况：如果这个字段的时间比当前时间更早得多，说明这是从缓存得到的，因为date描述的服务器第一次响应的时间，而缓存是不会对这个字段进行修改的！ 43 | 44 | 45 | #### 缓存的拓扑结构 46 | 47 | * 缓存分为私有缓存（只为一个客户端服务，比如我们给浏览器配置的代理）和共有缓存（为多个客户端服务，现实中是以代理缓存服务器的形式踹出现）。 48 | 49 | * 代理缓存的层级结构：此种结构描述的以父、子层级出现的层次结构，同时离客户端越近的子缓存的命中率较低（较廉价），他们可以把请求上升到父缓存（较昂贵），从而在父缓存那里实现事务处理！ 50 | 51 | * *代理缓存的网状结构*描述的缓存结构并不是很明显呈现父子关系的结构，而是呈无规则的网状！这种结构的思想就是子缓存可以动态选择上一级缓存，从而实现更灵活的缓存控制！ 52 | 53 | #### 缓存的处理步骤 54 | 55 | * 简单概括，即： 56 | 57 | ``` bash 58 | 接收————解析————查询————新鲜度检测————创建响应————发送————记入日志 59 | 60 | ``` 61 | 62 | * 第一步接收：读取网络连接http请求报文 63 | 64 | * 第二部解析：把报文解析为片段，并把首部放入到缓存易操作的数据结构中 65 | 66 | * 第三步查询：查找存下来缓存副本 67 | 68 | * 第四步新鲜度检测：说白了检查缓存副本是不是还有效的 69 | 70 | * 第五步创建响应：缓存服务器用原始服务器的缓存副本实现响应的起点，同时再在此基础上做一些修改，比如协议转换等 71 | 72 | * 第六步发送：发送报文 73 | 74 | * 第七步日志：事务完成之后，在日志文件插入一个条目，用以记录缓存处理情况，以及记录一些与缓存命中率的数据 75 | 76 | 77 | #### 保持副本的新鲜 78 | 79 | * *文档过期*通过特殊的http首部cache-control和expires,http让原始服务器为每个文档设置一个“过期时间”！如： 80 | 81 | ``` bash 82 | 83 | Cache-Control: Max-Age=484200 84 | Expires: Fri, 28 Oct 2016 03:03:47 GMT 85 | 86 | ``` 87 | 88 | 上面的Max-Age是相对时间，以秒为单位，理解为使用期，expires为绝对时间，为到期时间。 89 | 90 | * 服务器在验证，描述的过期的文档并不是就是原始服务器的原始文档不一样了，而是需要向服务器发起新鲜度验证请求。 91 | 92 | * 用条件方法进行再验证：涉及到的两个首部为If-Modified-Since和If-None-Match。格式为： 93 | 94 | ``` bash 95 | 96 | If-Modified-Since: 97 | 98 | ``` 99 | 实际上上面那个date为服务器响应报文里面Last-Modified的时间。 100 | 101 | * If-None-Match:实体标签再验证！此种机制主要跟If-Modified-Since不同在于：If-Modified-Since是根据修改时间来判断文档新鲜度的，但有些情况这样做是不适用的，因为比如我们只是加了注释什么的，其中实际内容是没有变化的，此时我们也应该认为文档是新鲜的！ 102 | 103 | * 强弱验证器：描述的是一种对内容的更改“严不严重，影不影响主要含义”的实体标签验证！ 104 | 105 | #### 缓存控制的能力 106 | 107 | * 缓存控制能力描述的是服务器可以通过设置相关首部来控制文档的缓存过期时间的能力！相关首部如： 108 | 109 | ``` 110 | Cache-Control: no-store //不能缓存 111 | 112 | Cache-Control: no-cache //在没有对服务器验证之前不能提供内容 113 | 114 | Cache-Control: must-revalidate //严格遵守新鲜验证规则 115 | 116 | Cache-Control: max-age //设置多长时间的过期时间（相对时间） 117 | 118 | Expires: //设置多长的过期时间（绝对时间） 119 | 120 | （试探性过期）不设置首部，让缓存来决定，这个方式涉及到一种算法，比如缓存服务器通过查看最后修改时间，从而得到该文档的修改频繁度，从而为其设置缓存过期时间 121 | 122 | ``` 123 | 124 | 上面的优先级从上到下依次降低。 125 | 126 | 127 | * 客户端的新鲜度限制：Web浏览器都有Refresh（刷新）或Reload(重载)按钮，可以强制对浏览器或代理缓存中可能过期的内容进行刷新。Refresh按钮会发布一个附加了Cache-Control请求首部的GET请求，这个请求会强制进行再验证，或者无条件地从服务器获取文档。Refresh的确切行为取决于特定的浏览器、文档以及拦截缓存的配置。客户端可以用Cache-Control请求首部来强化或放松对过期时间的限制，先关首部介绍如下： 128 | 129 | ``` 130 | Cache-Control请求指令 131 | 132 | 指令 目的 133 | 134 | Cache-Control: max-stale 缓存可以随意提供过期的文件。如果指定了参数，在这段 135 | Cache-Control: max-stale = 时间内，文档就不能过期，这条指令放松了缓存的规则 136 | 137 | Cache-Control: min-fresh= 至少在未来秒内文档要保持新鲜。这就使缓存规则更加严格了 138 | 139 | Cache-Control: max-age = 缓存无法返回缓存时间长于秒的文档。这条指令会使得缓存规则更加 140 | 严格，除非同时还发送了max-stale指令，在这种情况下，使用期可能会 141 | 超过其过期时间 142 | 143 | Cache-Control: no-cache 除非资源进行了再验证，否则这个客户端不会接受已缓存的 144 | Pragma: no-cache 资源 145 | 146 | Cache-Control: no-store 缓存应该尽快从存储器中删除文档的所有痕迹，因为其中可能会包含敏感信息 147 | 148 | Cache-Control: only-if-cached 只有当缓存中有副本存在时，客户端才会获取一份副本 149 | ``` 150 | 151 | #### 设置缓存控制 152 | 153 | * 控制Apache的HTTP首部：默认没有开启，需要用到相关模块。如： 154 | 155 | - - mod_headers:加载之后就能对相关首部进行配置了，如： 156 | 157 | ``` 158 | 159 | Header set Cache-control no-cache 160 | 161 | ``` 162 | 163 | - - mod_expires:mod_expires模块提供的程序逻辑可以自动生成带有正确过期日期的Expires首部 164 | 165 | - - mod_cern_meta:略 166 | 167 | * 此外，客户端通过HTTP-EQUIV控制HTML缓存，但是值对html文件有用，这种方法并不是很好！ 168 | 169 | #### 详细算法 170 | 171 | * 描述的与响应报文有关一些过期时间或使用时间的计算，详情请参看原书！ 172 | 173 | #### 缓存广告 174 | 175 | * 因为缓存的存在，导致某些靠用户点击次数收费的广告的请求未达到原始服务，从而服务器很难对用户进行了多少次点击进行计数！一种解决方案就是配置缓存，每次访问时都与原始服务器进行再验证。这样，每次访问时都会将命中推向原始服务器，但通常不会传送任何主体数据。当然，这样会降低事务处理的速度。 176 | -------------------------------------------------------------------------------- /第三章 HTTP报文/readme.md: -------------------------------------------------------------------------------- 1 | ### 内容提要 2 | 3 | 这一章内容较多，介绍了http报文的诸多相关概念，譬如起始行、首部、主体以及它们代表的含义等！同时还介绍了常见的状态码及其含义，常见的首部字段及其含义。本章内容较丰实，所以概念模糊的部分可以参阅原书相关章节！ 4 | 5 | 6 | #### 报文流 7 | 8 | **这是形容http报文的** 9 | 10 | * http报文是以一种类似的流的方式来发送数据的，所以报文流讲述了http报文的一些客观状态，相关术语：流入、流出形容事务处理。http报文任何时候是从上游向下游流入的！其中进过的节点既可能是上游，有可能是下游，如果从某个节点流出，那么相对于此节点流入的那个节点，它就是上游，反过来它就是下游！ 11 | 12 | 13 | #### 报文的组成部分 14 | 15 | * *首先说明，报文由三个部分组成，起始行、首部、主体。起始行和首部都是ascll文本，而主体则可以是任意类型文件，比如二进制，视频等！且起始行和首部都已一个crlf作为结束符，并且首部与主体之间应始终存在一个以crlf序列作为结束的空行。当然了为了兼容老版本的http，这里有时并不是那么严格要求非要crlf同时存在！* 16 | 17 | 18 | * 报文的语法 19 | 20 | http报文分为请求报文和相应报文，其语法分别如下： 21 | 22 | ```html 23 | //请求报文 24 | 25 | 26 | 27 | 28 | 29 | 30 | ``` 31 | 32 | ```html 33 | //响应报文 34 | 35 | 36 | 37 | 38 | 39 | 40 | ``` 41 | 42 | 相关概念分别如下： 43 | 44 | 45 | 方法是客户端希望执行的动作，如GET、POST等 46 | 47 | 请求url是指请求资源的路径 48 | 49 | http版本号，格式为http/.,分别代表主要版本号和次要版本号，其含义应分开理解 50 | 51 | status code其实说白了就是用一个数字表示当前事务处于什么状态，便于开发者处理 52 | 53 | 原因短语，实际意义不大，就是为了方便人看的 54 | 55 | 首部就是一个包含零个或多个的键值对，键值对以crlf隔开，而键、值之间以‘:’隔开，期间包含一个可选的空格 56 | 57 | 主体任意格式组成的数据块，也是实际发送的内容 58 | 59 | 60 | * 起始行 61 | 62 | 分为请求行和响应行，格式前面一个在前面，相关概念不在赘述！ 63 | 64 | * 首部 65 | 66 | 说一下首部分类，主要有五类：通用首部、请求首部、响应首部、主体首部、扩展首部。通用首部就是请求报文和响应报文都可以用，用以说明报文的一般属性；请求首部出现在请求报文中，用于客户端告诉服务器是什么情况，比如能接受什么，不能接受什么等；响应报文用于响应报文中，服务器端用来告诉客户端什么情况；主体首部用来描述主体的信息，比如主体的长度是多少等；扩展报文是非官方的报文，但是http也支持发送。 67 | 68 | 69 | 70 | #### 方法 71 | 72 | * 安全方法 73 | 74 | 能在服务器端有操作的就是非安全方法，比如delete、put、post,不在服务器端有操作的就是安全方法，比如get、head，当然了安全方法并非不能在服务器端有操作，这是开发者可以控制的！ 75 | 76 | * GET方法用于请求服务器端发送某个资源 77 | 78 | * HEAD方法跟GET方法类似，区别就是不返回主体 79 | 80 | * PUT方法用于向服务器端修改、插入数据 81 | 82 | * POST方法用于向服务器端发送数据 83 | 84 | * TRACK方法用于向服务器端请求报文在发送的过程中经过了什么修改，主要用于测试 85 | 86 | * OPTIONS用于请求服务器告知其支持什么功能 87 | 88 | * DELETE用于向服务器删除某个指定的资源 89 | 90 | * 扩展方法其实类似于自定义方法 91 | 92 | 93 | 94 | ####　状态码 95 | 96 | * 100-199 信息性状态码 97 | 98 | * 200-299 成功状态码 （常见200表示请求成功） 99 | 100 | * 300-399 重定向状态码 （常见302重定向） 101 | 102 | * 400-499 客户端错误状态码 （常见404，请求资源不存在） 103 | 104 | * 500-599 服务端错误状态码 105 | 106 | 107 | #### 常见状态码及其含义整理 108 | 109 | ``` 110 | 111 | 状态码 原因短语 含义 112 | 113 | 100 Continue 说明收到了请求的初始部分，请客户端继续，发送了这个状态码之后， 114 | 服务器在收到请求之后必须进行响应。 115 | 116 | 101 Switching Protocols 说明服务器正在根据客户端的指定，将协议切换成Update首部所列的 117 | 协议 118 | 119 | 200 OK 请求没问题，实体的主体部分包含了所请求的资源 120 | 121 | 201 Created 用于创建服务器对象的请求（比如，PUT）。响应的实体主体部分中 122 | 应该包含各种引用了已创建的资源的URL，Location首部包含的则是最具体的引用。 123 | 124 | 202 Accepted 请求已被接受，但服务器还未对其执行任何动作。不能保证服务器会完成这 125 | 个请求；这只是意味着接受请求时，它看起来是有效的。服务器应该在实体的主体部分包含对请求状态的描述，或许还应该有对请求完成时间的估计（或者包含一个指针，指向可以获取此信息的位置） 126 | 127 | 203 Non-Authoritative 实体首部包含的信息不是来自原远端服务器，而是来自于资源的一份副本。 128 | Information 如果中间节点上有一份资源副本，但无法或者没有对它所发送的与资源有关的 129 | 元信息进行验证，就会出现这种情况 130 | 131 | 204 No Content 响应报文中包含若干首部和一个状态行，但没有实体的主体部分。主要用于在 132 | 浏览器不转为显示新文档的情况下，对其进行更新（比如刷新一个表单页面） 133 | 134 | 205 Reset Content 另一个主要用于浏览器的代码。负责告知浏览器清除当前页面中的所有HTML 135 | 表单元素 136 | 137 | 206 Partial Content 成功执行了一个部分或Range(范围)请求。稍后我们会看到，客户端可以通过 138 | 一些特殊的首部来获取部分或某个范围内的文档————这个状态码就说明范围请求成功了。 139 | 140 | 141 | 注：在对那些包含了重定向状态码的非HEAD请求进行响应时，最好要包含一个实体，并在实体中包含描述信息和指向（多个）重定向URL的链接。如： 142 | 143 | HTTP/1.1 301 OK 144 | Location: http://www.gentle-grooming.com/ 145 | Content-Length: 56 146 | Content-Type: text/plain 147 | 148 | Please go to our partner site, 149 | www.gentle-grooming.com 150 | 151 | 152 | 153 | 300 Multiple Choices 客户端请求一个实际指向多个资源的URL时会返回这个状态码，比如服务器 154 | 上有某个HTML文档的英语和法语版本。返回这个代码时会带有一个选项列表；这样用户就可以选择它希望使用的那一项了。有多个版本可用时，客户端需要沟通解决。 155 | 156 | 301 Moved Permanently 在请求的URL已被移除时使用。响应的Location首部中应该包含资源现在所处 157 | 的URL 158 | 159 | 302 Found 与301状态码类似，但是，客户端应该使用Location首部给出的URL来临时定位 160 | 资源。将来的请求仍应该使用老的URL 161 | 162 | 303 See Other 告知客户端应该用另一个URL来获取资源。新的URL位于响应报文的Location 163 | 首部。其主要母的是允许POST请求的响应将客户端定向到某个资源上去 164 | 165 | 304 Not Modified 客户端可以通过所包含的请求首部，使其请求变成有条件的。如果客户端发起 166 | 了一个条件GET请求，而最近资源未被修改的话，就可以用这个状态码来说明 167 | 资源未被修改。带有这个状态码的响应不应该包含实体的主体部分。 168 | 169 | 305 Use Proxy 用来说明必须通过一个代理访问资源；代理的位置由Location首部给出。很 170 | 重要的一点是，客户端是相对某个特定资源来解析这条响应的，不能假定所有请求。甚至所有对持有请求资源的服务器的请求都通过这个代理进行。如果客户端错误地让代理介入了某条请求，可能会引发破坏性的行为，而且会造成安全漏洞。 171 | 172 | 307 Temporary Redireat 与301状态码类似；但客户端应该使用Location首部给出的URL来临时定位资源 173 | 。将来的请求应该使用老的URL 174 | 175 | 176 | 400 Bad Request 用于告知客户端发起了一个错误的请求 177 | 178 | 401 Unauthorized 返回适当的首部，用于获取客户端访问资源的权限 179 | 180 | 402 Payment Required 此状态码未使用，保留 181 | 182 | 403 Forbidden 服务器拒绝请求，可在响应主体中告知原因 183 | 184 | 404 Not Found 用于告知客户端请求的资源在服务器不存在 185 | 186 | 405 Method Not Allowd 告知客户端不支持当前方法，并在Allow首部返回支持的方法 187 | 188 | 406 Not Acceptable 没有客户端支持的资源类型 189 | 190 | 407 Proxy Authentication 跟401类似，不过用户代理服务器 191 | Requireed 192 | 193 | 408 Request Timeout 超时提醒 194 | 195 | 409 Conflict 请求会造成服务器冲突 196 | 197 | 410 Gone 跟404一样，只不过服务器曾经拥有过该请求资源 198 | 199 | 411 Length Required 要求客户端发送Content-Length首部 200 | 201 | 412 Precondition Failed 部分条件验证不通过 202 | 203 | 413 Request Entity Too Large 客户端发送的主体超过了服务器的希望的长度 204 | 205 | 414 Request URL Too Long 客户端请求的时间比服务希望的时间长 206 | 207 | 415 Unsupported Media Type 服务器无法理解客户端请求的主体类型 208 | 209 | 416 Requested Range Not 请求报文所请求的是指定资源的某个范围，而此范围无效或无法满足时 210 | Satisfiable ，使用此状态码 211 | 212 | 417 Expectation Failed 请求中包含Expect首部，服务器无法满足 213 | 214 | 500 Internal Server Error 服务器错误 215 | 216 | 501 Not Implemented 请求超出了服务器能处理的范围 217 | 218 | 502 Bad Gateway 作为代理或网关使用的服务器从请求响应链的下一条链路上收到了一条 219 | 伪响应（比如，它无法连接到其父网关）时，使用此状态码 220 | 221 | 503 Service Unavailable 用来说明服务器现在无法为请求提供服务，但将来可以。如果服务器 222 | 知道什么时候资源会变为可用的，可以在响应中包含包含一个 223 | Retry-After首部。 224 | 225 | 504 Gateway Timeout 与状态码408类似，只是这里的响应来自一个网关或代理，它们在等待另 226 | 一服务器对其请求进行响应时超时了 227 | 228 | 505 HTTP Version Not 服务器收到的请求使用了它无法或不愿支持的协议版本时，使用此 229 | Supported 状态码。有些服务器应用程序会选择不支持协议的早起版本 230 | 231 | 232 | ``` 233 | 234 | 235 | #### 常见首部字段含义介绍 236 | 237 | * 注：首部分为通用首部、请求首部、响应首部、主体首部、扩展首部！ 238 | 239 | * **通用首部** 240 | 241 | ``` 242 | 243 | 通用的信息性首部 244 | 245 | 首部 描述 246 | 247 | Connection 允许客户端和服务器指定与请求/响应连接有关的选项 248 | 249 | Date 提供了日期的时间标志，说明报文是什么时间创建的 250 | 251 | MIME-Version 给出了发送端使用的MIME版本 252 | 253 | Trailer 如果报文采用了分块传输编码方式，就可以用这个首部列出位于报文拖挂部分的首部集合 254 | 255 | Transfer-Encoding 告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式 256 | 257 | Update 给出了发送端可能想要“升级”使用的新版本或协议 258 | 259 | Via 显示了报文经过的中间节点（代理、网关） 260 | 261 | 262 | 通用缓存首部 263 | 264 | 首部 描述 265 | 266 | Cache-Control 用于随报文传送缓存指示 267 | 268 | Pragma 另一种随报文传送指示的方式，但并不专用缓存 269 | 270 | 271 | ``` 272 | 273 | * **请求首部** 274 | 275 | ``` 276 | 277 | 请求的信息性首部 278 | 279 | 首部 描述 280 | 281 | Client-IP 提供了运行客户端的机器的IP地址 282 | 283 | From 提供了客户端用户的E-mail地址 284 | 285 | Host 给出了接收请求的服务器的主机名和端口号 286 | 287 | Referer 提供了包含当前请求URL的文档的URL 288 | 289 | UA-Color 提供了与客户端显示器的显示颜色有关的信息 290 | 291 | UA-CPU 给出了客户端CPU的类型或制造商 292 | 293 | UA-Disp 提供了与客户端显示器（屏幕）能力有关的信息 294 | 295 | UA-OS 给出了运行在客户端机器上的操作系统名称及版本 296 | 297 | UA-Pixels 提供了客户端显示器的像素信息 298 | 299 | User-Agent 将发起请求的应用程序名称告知服务器 300 | 301 | Accept首部 302 | 303 | 首部 描述 304 | 305 | Accept 告诉服务器能够发送那些媒体类型 306 | 307 | Accept-Charset 告诉服务器能够给发送那些字符集 308 | 309 | Accept-Encoding 告诉服务器能够发送那些编码方式 310 | 311 | Accept-Language 告诉服务器能够发送那些语言 312 | 313 | TE 告诉服务器可以使用那些扩展传输编码 314 | 315 | 316 | 317 | 条件请求首部 318 | 319 | 首部 描述 320 | 321 | Expect 允许客户端列出某请求所要求的服务器行为 322 | 323 | If-Match 如果实体标记与文档当前的实体标记相匹配，就获取这份文档 324 | 325 | If-Modified-Since 除非在某个指定的日期之后资源被修改过，否则就限制这个请求 326 | 327 | If-None-Match 如果提供的实体标记与当前文档的标记不相符，就获取文档 328 | 329 | If-Range 允许对文档的某个范围进行条件请求 330 | 331 | If-Unmodified-Since 除非在某个指定日期之后资源没有被修改过，否则就限制这个请求 332 | 333 | Range 如果服务器支持范围请求，就请求资源的指定范围 334 | 335 | 336 | 安全请求首部 337 | 338 | 首部 描述 339 | 340 | Authorization 包含了客户端提供给服务器，以便对其自身进行认证的数据 341 | 342 | Cookie 客户端用它向服务器传送一个令牌————它并不是真正的安全首部，但确实隐含了安全功能 343 | 344 | Cookie2 用来说明请求端支持的cookie版本 345 | 346 | 347 | 348 | 代理请求首部 349 | 350 | 首部 描述 351 | 352 | Max-Forward 在通往源端服务器的路径上，将请求转发给其他代理或网关的最大次数————与TRACE方法一同 353 | 使用 354 | 355 | Proxy-Authorization 与Authorization首部相同，但这个首部是在与代理进行认证时使用的 356 | 357 | Proxy-Connection 与Connection首部相同，但这个首部是在与代理建立连接时使用的 358 | 359 | 360 | ``` 361 | 362 | * **响应首部** 363 | 364 | ``` 365 | 366 | 响应的信息性首部 367 | 368 | 首部 描述 369 | 370 | Age （从最初创建开始）响应持续时间 371 | 372 | Public 服务器为其资源支持的请求方法列表 373 | 374 | Retry-After 如果资源不可用的话，在此日期或时间重试 375 | 376 | Server 服务器应用程序软件的名称和版本 377 | 378 | Title 对HTML文档来说，就是HTML文档的源端给出的标题 379 | 380 | Warning 比原因短语中更详细的警告报文 381 | 382 | 383 | 协商首部 384 | 385 | 首部 描述 386 | 387 | Accept-Ranges 对此资源来说，服务器可接受的范围类型 388 | 389 | Vary 服务器查看的其他首部的列表，可能会使响应发生变化；也就是说，这是一个首部列表， 390 | 服务器会根据这些首部的内容挑选处最合适的资源版本发送个客户端 391 | 392 | 安全响应首部 393 | 394 | 首部 描述 395 | 396 | Proxy-Authenticate 来自代理的对客户端的质询列表 397 | 398 | Set-Cookie 不是真正的安全首部，但隐含有安全功能；可以在客户端设置一个令牌，以便服务器对客户端 399 | 进行标志 400 | 401 | Set-Cookie2 与Set-Cookie类似 402 | 403 | WWW-Authenticate 来自服务器的对客户端的质询列表 404 | 405 | 406 | 407 | ``` 408 | 409 | 410 | * **实体首部** 411 | 412 | 413 | ``` 414 | 415 | 实体的信息性首部 416 | 417 | 首部 描述 418 | 419 | Allow 列出了可以对此实体执行的请求方法 420 | 421 | Location 告知客户端实体实际上位于何处；用于将接收端丁香到资源的位置上去 422 | 423 | 424 | 内容首部 425 | 426 | 首部 描述 427 | 428 | Content-Base 解析主体中的相对URL时使用的基础URL 429 | 430 | Content-Encoding 对主体执行的任意编码方式 431 | 432 | Content-Language 理解主体时最适宜使用的自然语言 433 | 434 | Content-Length 主体的长度或者尺寸 435 | 436 | Content-Location 资源实际所处的位置 437 | 438 | Content-MD5 主体的MD5校验和 439 | 440 | Content-Range 在整个资源中此实体表示的字节范围 441 | 442 | Content-Type 这个主体的对象类型 443 | 444 | 实体缓存首部 445 | 446 | 首部 描述 447 | 448 | ETag 与此实体相关的实体标记 449 | 450 | Expires 实体不再有效，要从原始的源端再次获取此实体的日期和时间 451 | 452 | Last-Modified 这个实体最后一次被修改的日期和时间 453 | 454 | ``` 455 | --------------------------------------------------------------------------------