图解HTTP

书名：图解HTTP 类型：计算机专业书籍 作者简介 ：上野宣，OWASP日本分会会长，TRICORDER株式会社董事长。主要从事安全咨询、风险评估、信息安全教育等工作，著有<今晚我们一起学习邮件协议>、<今晚我们一起学习TCP/IP>、<今晚我们一起学习HTTP>等。 点评： 依稀记得2014年的时候，我曾花费了至少一个星期的时间去系统学习Http的知识，以期待对Http协议有一个全面的认知。一则是因为http协议是一门基础知识，到处会有使用；一则是能够忽悠面试官，不会显得啥都不会。 自以为当时整理的Http知识很全面：有请求报头合适，有响应报头格式，有各种类型的报头以及他们的详细说明，有各种响应状态码及其含义。当然也有考虑到安全的问题，比如Https协议、各种Web攻击等，但是也都是只言片语，写的很浅。 现在读完本书才发现，这本书原来就是我当时希望看到的书，书中所涵盖的内容，比我自己总结的内容更加全面，而且更加浅显易懂。真是相见恨晚，或许这本书在2013年而不是2014年出版，会省去我不少事情。 所有的技术方案都是为了解决特定的问题而存在，问题不在了也就不存在所谓的技术。所以学习技术的首要事情是：了解所面临的问题。 好了，闲话不多扯了，做个笔记，下次看的时候可以更快。 1. http版本 Http于1990年问世，那时的HTTP并没有作为正式的标准被建立。这时的HTTP其实含有HTTP/ 1.0之前版本的意思，因此被称为HTTP/0.9。 HTTP正式作为标准被公布是在1996年的5月，版本被命名为HTTP/1.0，并记载于RFC1945。 1997年1月公布的HTTP/1.1是目前主流的HTTP协议版本。 HTTP2.0是HTTP协议自1999年HTTP 1.1发布后的首个更新，主要基于SPDY协定。它由互联网工程任务组（IETF）的Hypertext Transfer Protocol Bis（httpbis）工作小组进行开发。[2]该组织于2014年12月将HTTP/2标准提议递交至IESG进行讨论[3]，于2015年2月17日被批准。 2. http各个版本之间的区别 方面HTTP协议的出现主要是为了解决文本传输的难题。 HTTP是一种不保存状态，即无状态（stateless）协议。HTTP协议自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个级别，协议对于发送过的请求或响应都不做持久化处理。 HTTP/1.1虽然是无状态协议，但为了实现期望的保持状态功能，于是引入了Cookie技术。有了Cookie再用HTTP协议通信，就可以管理状态了。 HTTP主要有这些不足：通信使用明文（不加密），内容可能会被窃听；不验证通信方的身份，因此有可能遭遇伪装；无法证明报文的完整性，所以有可能已遭。Https就是为了解决这些问题而存在。 HTTP+加密+认证+完整性保护=HTTPS。 HTTP标准的瓶颈： 一条连接上只可发送一个请求。 ●请求只能从客户端开始。客户端不可以接收除响应以外的指令。 ●请求/响应首部未经压缩就发送。首部信息越多延迟越大。 ●发送冗长的首部。每次互相发送相同的首部造成的浪费较多。 ●可任意选择数据压缩格式。非强制压缩发送 为了解决这些问题就出现了SPDY协议。Http2.0基于SPDY协议实现的。 3. http协议格式 请求报文：请求报头+空行+实体 响应报文：响应报头+空行+实体 请求报头：请求行+报头（请求首部+通用首部+实体首部） 响应报头：响应状态行+报头（响应首部+通用首部+实体首部） 报头首部类型：请求首部、响应首部、通用首部、实体首部 有哪些报头，都什么作用，自己看。 请求方法有哪些自己看 响应状态码有哪些自己看 4. 代理、网关、隧道的区别 代理是黄牛，倒买倒卖，手上沾点油。不改动，服务端一定使用的是Http。比如一般的CDN服务器。 网关是一个人工服务员，对外提供统一的服务，客户不用与各种内部接口人一一对接。网关的上游服务器可能使用的是ftp、mail等非http协议。比如三大电影运营商。 隧道也是一个秘密的暗道，其他人没法窥探里面的内容。比如shadowsocket 5. CA认证机构 https协议会使用非对称加密，但非对称加密中公开密钥存在的身份认证问题，即怎么证明我是我的问题。这个时候就出现了第三者：CA认证机构。所有需要使用数字签名的网站，就把身份认证的事情交给CA来完成。 那么CA认证机构也出现一个尴尬的问题。怎么证明自己是自己的问题。你CA是假的怎么办？那么这个时候的解决办法就是将所有顶级的CA的公钥在浏览器里面都内置一份。对的，每个浏览器在出厂的时候，都会存一些CA认证机构的照片，这样就假不了了。 6. 关于SSL SSL技术最初是由浏览器开发商网景通信公司率先倡导的，开发过SSL3.0之前的版本。目前主导权已转移到IETF（Internet Engineering Task Force,Internet工程任务组）的手中。 IETF以SSL3.0为基准，后又制定了TLS1.0、TLS1.1和TLS1.2。TSL是以SSL为原型开发的协议，有时会统一称该协议为SSL。当前主流的版本是SSL3.0和TLS1.0 SSL的慢分两种。一种是指通信慢。另一种是指由于大量消耗CPU及内存等资源，导致处理速度变慢。这个就是SSL鸡肋之处。所以Https的使用就需要考虑成本的问题。 7. 服务器端考虑的几个问题 怎么省流量？怎么减少机器资源的消耗？怎么保证缓存一致性？怎么保证可靠性？怎么保证拓展性，保证各个业务分离？简言之，快、稳、省、准。 8. 关于Web完全 There is a door，there is a way！ 有和外部交互的地方，那么就存在安全问题的可能。只要外部能够把数据送到你服务端，那么就存在安全风险的可能。具体就可能是怎么把数据送进去的问题了。 有的可能是通过在客户端入手，把私货夹带进入；而有的是路上动手，中间人劫持；还有人是直接在服务端动手，破解你root权限；发一份钓鱼邮件，先送到你内网再说，你点开了，那么这个雷就埋好了。 当然上述都是主动劫持，还有被动劫持。那么就是对用户下手。 发一发钓鱼网站，添加XSS跨域攻击，把用户的信息在不知不觉中上传到黑客的网站上。 当然说的很轻巧，这些都是要找到代码的漏洞，必须熟悉各种方式，然后才能知道会存在哪些bug。这条路很长很长。 差点忘了，我原来还是个程序员～

浏览器地址栏输入地址到页面渲染完成发生了什么?  1.浏览器进行地址解析，获取该地址的端口号、域名、协议、路径等信息。  2.将解析的域名进行DNS解析。  3.通过ip地址寻找服务器地址  4.与服务器进行三次握手建立连接  5.浏览器发送数据，等待服务器的响应  6.服务器响应并返回数据  7.浏览器接收到数据  8.浏览器开始渲染页面 URI与URL URI，是uniform resource identifier，统一资源标识符，用来唯一的标识一个资源。  URL是uniform resource locator，统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。 HTTP1.0和HTTP1.1的区别  1.长连接 -- HTTP1.1支持长连接和请求的流水线处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。HTTP1.0每次请求都要创建连接。  2.节约带宽 -- HTTP1.1支持只发送header信息（不带任何body信息），如果服务器认为客户端有权限请求服务器，则返回100，客户端接收到100才开始把请求body发送到服务器；如果返回401，客户端就可以不用发送请求body了节约了带宽。 HOST域 -- 在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名，HTTP1.0没有host域。HTTP1.1的请求消息和响应消息都支持host域，且请求消息中如果没有host域会报告一个错误（400 Bad Request）。  3.缓存处理 -- 在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。  4. 错误通知的管理 -- 在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。  HTTP1.1和HTTP2.0的区别  1.多路复用 --HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。 头部数据压缩 -- HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。  2.服务器推送 -- 服务端推送是一种在客户端请求之前发送数据的机制。网页使用了许多资源：HTML、样式表、脚本、图片等等。在HTTP1.1中这些资源每一个都必须明确地请求。服务器必须等待浏览器做每一个请求，网络经常是空闲的和未充分使用的。为了改善延迟，HTTP2.0引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前，免得客户端再次创建连接发送请求到服务器端获取。这样客户端可以直接从本地加载这些资源，不用再通过网络。 五层体系结构包括：应用层、运输层、网络层、数据链路层和物理层  1.应用层：直接为用户的应用进程（例如电子邮件、文件传输和终端仿真）提供服务。  相关协议：HTTP、FTP、DNS、SMTP、Telnet等  2.运输层：负责向两个主机中进程之间的通信提供服务。由于一个主机可同时运行多个进程，因此运输层有复用和分用的功能  相关协议：TCP、UDP等  3.网络层：在位于不同地理位置的网络中的两个主机系统之间提供连接和路径选择  相关协议：IP、ICMP等  4.数据链路层：定义了如何让格式化数据以进行传输，以及如何让控制对物理介质的访问。这一层通常还提供错误检测和纠正，以确保数据的可靠传输。  相关协议：ARP、RARP等  5.物理层：主要定义物理设备标准，如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的主要作用是传输比特流。 三次握手：  1、第一次握手：客户端给服务器发送一个 SYN 报文。  2、第二次握手：服务器收到 SYN 报文之后，会应答一个 SYN+ACK 报文。  3、第三次握手：客户端收到 SYN+ACK 报文之后，会回应一个 ACK 报文。  4、服务器收到 ACK 报文之后，三次握手建立完成。  四次挥手：  1、第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。 2、第二次握手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态。 3、第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。  4、第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态 5、服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。 DNS域名解析过程：  1.在浏览器中输入域名，操作系统会先检查自己本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。  2、如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。  3、如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/IP参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析。  4、如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析。  5、如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。  6、如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。 http协议格式 请求报文：请求报头+空行+实体 响应报文：响应报头+空行+实体 请求报头：请求行+报头（请求首部+通用首部+实体首部） 响应报头：响应状态行+报头（响应首部+通用首部+实体首部） 报头首部类型：请求首部、响应首部、通用首部、实体首部 资源表述性状态转移 根据数据抽象出来的资源，以某种表现形式，通过某种手段，在网络中发生状态转移，以此来间接实现操作资源的目的。 如果一个架构符合REST原则，就称它为RESTful架构。  1.每一个URI代表一种资源；  2.客户端和服务器之间，传递这种资源的某种表现层；  3.客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。 使用 cookie 时需要考虑的问题:  1.因为存储在客户端，容易被客户端篡改，使用前需要验证合法性  2.不要存储敏感数据，比如用户密码，账户余额  3.使用 httpOnly 在一定程度上提高安全性  4.尽量减少 cookie 的体积，能存储的数据量不能超过 4kb  5.设置正确的 domain 和 path，减少数据传输  6.cookie 无法跨域  7.一个浏览器针对一个网站最多存 20 个Cookie，浏览器一般只允许存放 300 个Cookie  8.移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token  使用 session 时需要考虑的问题:  1.将 session 存储在服务器里面，当用户同时在线量比较多时，这些 session 会占据较多的内存，需要在服务端定期的去清理过期的 session  2.session 是由单个服务器创建的,当网站采用集群部署的时候，会遇到多台 web 服务器之间如何做 session 共享的问题。  3.当多个应用要共享 session 时，除了以上问题，还会遇到跨域问题，因为不同的应用可能部署的主机不一样，需要在各个应用做好 cookie 跨域的处理。 4.sessionId 是存储在 cookie 中的，假如浏览器禁止 cookie 或不支持 cookie,一般会把 sessionId 跟在 url 参数后面即重写 url，所以 session 不一定非得需要靠 cookie 实现  5.移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token  使用 token 时需要考虑的问题:  1.如果你认为用数据库来存储 token 会导致查询时间太长，可以选择放在内存当中。比如 redis 很适合你对 token 查询的需求。  2.token 完全由应用管理，所以它可以避开同源策略  3.token 可以避免 CSRF 攻击  4.移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token HTTP/1.1首部字段 1.首部字段Upgrade用于检测HTTP协议及其他协议是否可使用更高的版本进行通信，其参数值可以用来指定一个完全不同的通信协议。 2.使用首部字段Via是为了追踪客户端与服务器之间的请求和响应报文的传输路径。报文经过代理或网关时，会先在首部字段Via中附加该服务器的信息，然后再进行转发。Via首部是为了追踪传输路径，所以经常会和TRACE方法一起使用。 3.Accept首部字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级 4.Accept-Charset首部字段可用来通知服务器用户代理支持的字符集及字符集的相对优先顺序。 5.Accept-Encoding首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序 6.Accept-Language用来告知服务器用户代理能够处理的自然语言集（指中文或英文等），以及自然语言集的相对优先级 7.Authorization是用来告知服务器，用户代理的认证信息（证书值） 8.Expect来告知服务器，期望出现的某种特定行为。因服务器无法理解客户端的期望作出回应而发生错误时，会返回状态码417 Expectation Failed。 9.From用来告知服务器使用用户代理的用户的电子邮件地址。通常，其使用目的就是为了显示搜索引擎等用户代理的负责人的电子邮件联系方式 10.Host会告知服务器，请求的资源所处的互联网主机名和端口号。Host首部字段在HTTP/1.1规范内是唯一一个必须被包含在请求内的首部字段。 11.Referer会告知服务器请求的原始资源的URI。 12.User-Agent会将创建请求的浏览器和用户代理名称等信息传达给服务器。 13.Content-Type说明了实体主体内对象的媒体类型

今年的读书进度整体偏慢，为完成读书任务，同时也想再系统的学习和回顾下工作相关的知识，对书单进行了调整，融入一些专业相关的书籍，于是打开这本来自岛国的图解http。 从事web开发，了解http协议是基础，这本书的出现也是作者为了弥补市场上http书籍的不足，相对于权威指南，tcp/ip而言这本书显得通俗易懂，这也是作者的初衷。 书的篇幅不短，虽然把涉及http相关的知识点都讲到了，例如它的发展演变、实际应用、安全等，但深度不够，加上配了很多图片，所以读起来很快，比较适合初学者。 看完全书对http又整体回顾了一篇，加深了相关概念的印象，对书里出现的那些单词和代码感觉那么亲切，这就是读这类书所特有的感觉。

优点： 1. 图文并茂，通俗易懂： 该书采用了大量的图解和通俗易懂的语言，使得复杂的HTTP协议变得容易理解。这种方式让读者能够更直观地理解HTTP协议的工作原理和流程。 2. 全面而深入： 作者在书中涵盖了HTTP协议的各个方面，包括请求和响应的格式、状态码、持久连接、安全性等内容，为读者提供了全面深入的了解。 3. 举例生动，实用性强： 书中通过大量的实例来说明HTTP协议在实际应用中的运作方式，这些例子能够帮助读者更好地理解HTTP在不同场景下的应用。 4. 适合不同水平的读者： 无论是初学者还是有一定经验的开发人员，都能从这本书中受益。对于初学者来说，书中的图解和通俗易懂的语言能够帮助他们快速入门；而对于有经验的开发人员来说，书中的深入剖析能够帮助他们更深入地理解HTTP协议。 缺点: 1. 偏向概念解释： 有些读者认为书中对HTTP协议的一些概念解释过于详细，而缺乏一些实际的应用场景和案例，这使得书籍显得有些枯燥。 2. 更新速度慢： 由于HTTP协议的不断演进和发展，书中的内容可能已经有些过时，尤其是在介绍一些新的技术和特性方面。因此，读者在阅读时需要注意结合其他最新资料来获取最新的信息。 3. 深度有限： 虽然书中对HTTP协议进行了全面的介绍，但是对于一些更深层次的技术细节和高级应用场景，书中的涉及可能有些有限。读者可能需要额外的资料来进一步了解这些内容。 结论： 《图解HTTP》作为一本介绍HTTP协议的入门书籍，具有图文并茂、通俗易懂、全面深入的特点，适合各种水平的读者阅读。然而，它也存在一些不足之处，如偏向概念解释、更新速度慢和深度有限等。读者在阅读时应当根据自己的实际需求和水平来选择是否适合。

写得好浅，概念上的理解。 不过配图倒是很用心，不会让人有烦躁的情绪。 本书算是课外书之类，平时翻翻就好。

全书覆盖HTTP核心知识与延伸要点：从HTTP成长发展史切入，基于HTTP 1.1标准，系统讲解通信过程、HTTP方法、协议格式、报文结构等基础内容，同时介绍代理、网关的作用及SPDY等扩展功能；后半部分聚焦Web安全，深入解读HTTPS、加密机制等关键知识，帮助读者构建对HTTP协议的完整认知，满足初学者入门与有经验开发者查漏补缺的双重需求。 一点小小的不足就是有点年份了，现在都出http/3了

作者对http的发展史做了比较详细的介绍，着重介绍了http1.1、https的概念与优缺点，同时对http2.0做了简要介绍，可以作为了解http的读物。个人觉得网络的知识，理解了是真的简单，不理解是真的搞不懂。第一次读的时候，没读下去，后来读了小林图解之后，再回来看，一切又能看懂了。不过有一点是显而易见的：知识点是真的多啊！ 此处推荐学习“计算机网络”的阅读顺序： 1. 《图解tcp/ip》：这本书从计算机网络最基础的知识开始介绍，先介绍发展史，OSI参考模型，然后引出tcp/ip模型。接着按照数据链路层、网络层、传输层、应用层的从下往上的顺序进行介绍。 特点：幽默易懂 缺点：泛泛而谈，对于面试常用知识点介绍不够详细。 2. 小林coding的图解网络：有了基本的网络概念之后，首推小林图解，该图解系列可以在公众号“小林coding”获取。从面试常问问题的角度，按照从应用层、传输层、网络层、数据链路层的自上往下的顺序进行介绍（与《图解tcp/ip》的介绍顺序刚好相反），对http，tcp，udp，ip进行了详细的介绍。读完基本上对网络协议有了一个清晰的认识。 优点：幽默易懂，图解很形象 缺点：木有，哈哈，因为读完我的收获很多，真的好喜欢这本图解。 3. 《图解http》：这本书可以结合小林图解http部分一起阅读，作为补充读物。

这本书推荐值居然降到了68.4，唉～ 这本书我认为是非常适合新手来学习计算机网络的，但这本书也确实有点问题，那就是内容太太太多了，有点太详细了，作为新手很可能抓不住重点，导致弃坑了，没错，说的就是去年第一次读这本书的我🥹 前五章读起来非常轻松，你再在浏览器上玩玩network 选项卡，第六章也差不多了，基本上你英语好也能看出来这些字段是什么意思。 如果你是新手，那么接下来的章节你只要花10分钟速度翻一遍每个篇章的标题和第一句话的，因为接下来的章节内容非常多，多的有点像字典了，但作为新手你其实不用掌握这么多的，你只要知道有这么个名词就行了，之后你学习或工作碰上了这些（很多都大概率碰不上），再去学就行了。 最后，学习计算机网络，如果你只是前端开发，咱们是在应用层玩的，底层的咱别管😋差不多到传输层就是咱的底层了😋

这是HTTP协议的入门级图书，适合对网络协议感兴趣的朋友们阅读，可以俯视浏览到整个HTTP协议的全貌，但是对于不了解网络的朋友会有一点困难。

之前看过纸质版的，于自己而言算是查漏补缺，书中很多东西还是要结合实际场景方能理解更深刻，不推荐新手直接看此书。