《图解HTTP》读书笔记

前言

这是博文的前言，也是读书笔记的后记。本来只打算草草看看查漏补缺，但是实际上从这本书还是学到了非常多知识点，对HTTP有了比较系统的了解。

这本书本身非常可爱，图很多，有点像Head First系列的书（但是相比来说，还是HF更可爱一点）。

从这本书上，我学到了哪些呢（括号内为对应章节）？

以前不太明白的零碎的知识，比如URL&URI（1.7），网关隧道（5.2），DOM是什么（10.2.2），XML有什么好处（10.4.1）；

HTTPS、SSL的加密过程，如何保证密钥安全传输（7.2）；

HTTP的不足，后续有哪些新技术进行了改进（9.x）

常见的WEB攻击方法（黑客技术总是令人向往，小时候看的一些黑客杂志里面的术语和方法终于了解了）（11.x）

联系之前做的项目，发现了一些改进的地方。比如，对大资源文件（eg，图片）进行客户端缓存（6.x），为什么师兄要把Controller里的代码都try-catch起来（11.3.2）

当然，这只是我个人的感悟，并非什么面经或者热点知识。笔记本身是供自己复习用的，所以会有一些章节觉得不感兴趣直接跳过。书本身十分有趣，希望各位也能从中发现自己想学习的知识。

如果下面的内容能为同看这本书的你提供一些帮助，那再好不过了：）

1.了解WEB和网络基础

1.2 HTTP的诞生

初衷：让远隔两地的研究者们共享知识

3项WWW构建技术：HTML，页面的文本标记语言; HTTP，文档传输协议; URL，指定文档所在地址

HTTP/0.9：于1990年面世，并没有真正的标准，0.9实际上包含着1.0之前版本的意思

HTTP/1.0：1996.5确立，是HTTP的初期标准。

HTTP/1.1：1997.1是现在主流的HTTP协议版本

HTTP/2.0：还在制定中，推广也需要很长时间。

可以看到，HTTP标准已经有二十多年没有更新了。当年的HTTP协议出现主要是为了解决文本传输问题，所以协议本身比较简单。现在的HTTP已经超出了WEB这一框架的局限。

1.3 网络基础 TCP/IP

1.3.2TCP/IP的分层管理

分为应用层、传输层、网络层、数据链路层

应用层：决定了向用户提供应用服务时通信的活动

传输层：提供处于网络连接中的两台计算机（这是书本原话，但是我觉得更应该是两个应用）之间的数据传输，主要有TCP和UDP两种协议

网络层：用来处理网络上流动的数据包，而数据包是网络传输的最小数据单位。该层规定了通过怎样的路径吧数据包传输到对方计算机上。

链路层：硬件相关（那mac地址之类的怎么办？？）

1.4 IP TCP

1.4.1 IP协议

IP，MAC，ARP，路由选择的概念

1.4.2 TCP

位于传输层，提供可靠的字节流服务。可能将大块数据分割成报文段为单位的数据包进行管理。且TCP能够确认数据是否最终送达对方（也就是可靠性）。

三次握手（SYN, ACK）

1.5 DNS（Domain Name System）

DNS也是应用层协议，提供域名到IP地址之间的解析服务。可以提供双向解析服务。

1.6 各个协议与HTTP的关系

1.7 URI & URL

1.7.1 URI（Uniform Resource Identifier）

中文名为统一资源标识符。分为三块：

Uniform：采用统一的格式来处理不同类型的资源，而不用根据上下文环境来识别资源指定的访问方式。体现：开头指明了协议，比如http://

Resource：资源的定义是，可标识的任何东西。可以是文件、服务等；不仅可以是单一的，也可以是多数的集合体。

Identifier：标识符。用于定位唯一的资源对象。

标准的URI协议有30种左右，如http ftp telnet …

URI用字符串标识某一互联网资源，而URL表示资源的地点（互联网上所处的位置），因此URL是URI的子集。

换句话说：URI负责标注一个唯一的资源，它可以是一个自增的主键，可以是一串随机生成的字符串，可以是任何东西……但是URL则是标注如何在互联网上找到这个资源，只要通过这个地址能找到这个资源，那他就是URI。

举个URI/URL的例子：mail: aaa@bbb.com就是一个URI，但是它并不是URL，因为它并不指向任何资源。

再举个例子：有一份美国绝密档案，内部称呼为，“美国绝密档案: 197708125489”，这个名字是对这个档案的称呼，而且不会有第二份文件叫这个，所以他是个URI。某天，维基解密公开了这份档案，放在了某个网址供别人下载，网址为"http://wiki.com/197708125489.pdf"，这是个URL，在互联网上可以访问到这份档案，也是唯一地标识了这份文件，所以也是URI。因此我们说，URL是URI的子集。

从下面开始，所有的URI字样，实际上都可以用URL进行替换，因为我们都是在描述访问网络资源的方法：）

1.7.2 URI的格式

分为三种：绝对URI（涵盖了所有信息，包括可选项） 绝对URL 相对URL。相对URL是指从浏览器的URI基础目录处开始指定的URL，如：/img/aa.gif

绝对URI的格式如下：

各项目的解释如下：

协议方案名：指定了获取访问资源时使用的协议类型，不区分字母大小写，后面跟着冒号

登录信息：可选。指定用户名和密码作为从服务器获取资源时必要的登录信息。

服务器地址：可以是域名，IPV4，IPV6（需要用方括号括起来，如[0:0:0:0:0:0:0:1]）

服务器端口号：可选。如果不填，则使用（协议的）默认端口号

带层次的文件路径：指定服务器上的文件路径来定位特定的资源

查询字符串：可选。针对指定的文件路径内的资源，可用查询字符串传入任意参数。

片段标识符：可选。使用其可以标记出已获取资源种的子资源，但是标准中没有规定其使用方法。

2.简单的HTTP协议

主要对HTTP/1.1进行解析。

2.2 请求和响应格式

HTTP请求是由：请求方法、请求URI、协议版本、可选请求首部字段、内容实体构成的。

响应报文是由：协议版本、状态码、原因短语（产生这个状态码的原因）、响应首部字段、主体构成

以下两张图分别是请求报文和响应报文。

2.3 HTTP不保存状态

HTTP是无状态协议，不对响应和请求之间的通信状态进行保存。

为了保存用户的状态，引入COOKIE技术。

2.6 HTTP请求类型

在这里列举的众多方法中，LINK 和 UNLINK 已被 HTTP/1.1 废弃，不再支持。

2.7持久连接节省通信量

在HTTP初始版本中，每次HTTP通信都要断开一次TCP连接，连接的建立和销毁会增加通信的开销，因此HTTP/1.1和部分的HTTP/1.0想出了“持久连接”属性，也就是HTTP的 keep-alive或connection reuse。其特点是：只要任意一端没有提出断开连接，则保持TCP连接状态。

HTTP/1.0中并未标准化，但是HTTP/1.1是默认采用持久连接的。持久连接需要C/S双方都支持。

持久连接还造成了流水线化技术，不用等待响应即可发送下一个请求，这样就可以并行发送多个请求，提高页面响应速度。

2.8 使用Cookie的状态管理

HTTP本身是无状态的。因此不然每次跳转到新的页面都要再次登录，不然就要在请求报文中附加参数来管理登录状态。

服务器端会发送一个Set Cookie首部字段信息通知客户端保存Cookie；下次客户端往该服务器发送请求时，客户端会自动在请求报文中假如Cookie值后发送出去；服务器会对比客户端报文中的Cookie和服务器上的存储，得到之前的状态信息。

2.9 看一个实际的HTTP请求/响应

这一节是我自己加入的，看看自己项目中的HTTP请求、响应是怎么样的。采用了//的注释方式，可能不那么直观。

登陆界面的响应，可以看到keep-alive，Content-Type，Set-Cookie等响应头。

HTTP/1.1 200
Server: nginx/1.18.0 // 指定Server名称和版本
Date: Sat, 09 Jan 2021 11:40:16 GMT
Content-Type: application/json;charset=utf-8 //内容类型，指示浏览器该如何解析这一帧数据
Content-Length: 238
Connection: keep-alive // 指定保持连接，如果写成close则是关闭，还可以写成timeout=xx的形式
Set-Cookie: JSESSIONID=649F18CA15B68C5BD846B4D22ED58159; Path=/; HttpOnly //设置Cookie
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate //操作缓存的工作机制。no-cache表示强制向源服务器再次验证；no-store表示不缓存请求或响应的任何内容；max-age表示缓存的有效时间（