简单不易懂的Http协议-读书笔记01

学非探其花，要自拔其根。

前言

再就业已然二月有余，在这名为“工作”的生产生活实践中，每每深入，越发觉得心有余而力不足。
前段时间一时兴起，尝试起树莓派，香蕉派，这类的单片机，还入手过香蕉派的路由开发板
兴许是不懂得原因，我看香蕉派的路由板是千兆网口，想当然的认为它读写硬盘的I/O能力应该不会低
然而实际操作下来发现读写硬盘甚至比树莓派3B+还要低个几Mb/s,又遭遇不良商家退货虽是成功但仍和吃了苍蝇一般难受
在这里额外提一点，对这些东西感兴趣，果然还是得去相对大些的店买相对知名，成熟些的产品，以树莓派这类为例，香蕉派只看纸面数据怎么看都比树莓派强
但是用起来，真正能体验到什么叫看上去很美，具体先按下不表，毕竟跑题了...
及此，虽然通常来说，Http协议或者说各种网络相关的知识与前端关系并不大的观点已经深入人心...
然而，我个人在日常的实践中，遇到了些需求，发现，根本无从查起，很多细节根本无法通过快速的查阅资料来领会，全靠基础知识的积累。
可惜，在这方面的储备我无限接近于零，虽然，基本的结构我是明白的，但是，当我遇到诸如在路由器上用iptables来构建NAT转发，实现一个透明代理这种....
即使，我能通过搜索引擎弄明白iptables的基本语法，什么是NAT，什么是透明代理，我依旧华丽的失败了。
因为我只知道它们看起来是什么样子，而不知道它们应该是什么样子。即所谓，识其"花"，而未识其"根"。
及此，我抱起了一本《图解HTTP》，诚然，相较来说诸如《HTTP权威指南》，《TCP/IP详解》这些"圣经"类读物恐怕学下来会更扎实，然而奈何其讲解相对于我来说过于复杂晦涩。
还一个重点是，它们太厚了，于其拿来学习不如用来砸人当字典用更能体现它们的价值。
本笔记，为阅读《图解HTTP》的读书笔记，由于从来没有真正意义上写过所谓读书笔记这类的东西，估计会写的很随性，简单，但是不一定易懂。

综述

部分摘自序言，和译者序。
目前阅读了两章左右，整体给人的感觉与其说是技术书籍，不如说是科普类读物，HTTP协议本身并不复杂，理解起来也不会花费太多学习成本。但是要想将知识转换为技能，则会费点功夫，然当对其有更深入理解之际，兴许能从中得到一些启发开发出更友好的Web应用。
全书有十一章。前六章为基本的HTTP协议知识，包括报文，状态码，首部，一些HTTP服务器相关的简单知识。第七到第九章，设计一些基本的网络安全知识，HTTPS，追加协议，用户认证之类的。第十章Web应用，对于前端来说，这块内容可能往往已经很清楚。最后一章则是常见的Web攻击技术，包括各种网页上的常见的简单的设计缺陷和安全漏洞，常言道知己知彼百战不殆，知道可能被怎么攻击，无疑是利于构建更好的防御的。仅从目录来看，对于网络应用开发人员来说，这本书是很有价值的，那么接下来我们进入内容。

Web及网络基础

Http，通常被译为“超文本传输协议”，虽然有种说法为这不严谨，应该译为“超文本转移协议”，在此我并没有对其有多么深厚的理解，所以不予置评。
1989年3月欧洲核子研究组织（CERN）的蒂姆.伯纳斯。李博士提出了一种能让远隔两地的研究者共享知识的设想，基本理念是：借助多文档之间相互关联形成的超文本，连成可相互参阅的WWW。
1990年11月，CERN成功研发了世界第一台Web服务器和Web浏览器。
这姑且可以分类为诞生，之后的事件虽然很重要，不过略过不表，学前端的话对于浏览器大战之类的事件应该是很熟悉了。这一切都是命运石之门的选择！
在提HTTP协议前，我们得先来看看TCP/IP协议族。通常使用的网络，是在CTP/IP协议族的基础上运作的，而HTTP属于它内部的一个子集。

TCP/IP的分层管理

TPC/IP协议族最重要的一点就是分层。它可以分成四层：应用层，传输层，网络层，数据链路层。
应用层：提供各种应用服务，HTTP协议属于这一层，其它还有诸如FTP服务，DNS服务之类的都属于应用层。
传输层：提供对于网络连接中的两台计算机之间的数据传输，包括TCP协议（传输控制协议）和UDP（用户数据报协议）。
网络层：网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎么样的路径到达对方计算机，并把数据包传送给对方。
链路层：用来处理连接网络的硬件部分。包括控制操作系统，硬件的设备驱动，网卡，及光钎等物理可见部分。属于硬件范畴。

TCP/IP 通信传输流

以一个HTPP请求为例：
客户端：HTTP(应用层)->TCP(传输层)->Ip(网络层)->网络（链路层）
服务器：网络（链路层）->Ip(网络层)->TCP(传输层)->HTTP(应用层)
大概就是这样，首先，客户端发起请求，在TCP协议下把从应用层收到的数据（本例中是HTTP报文）进行分割，并在各个报文上打上标记序号及端口号后转发给IP协议，IP协议增加作为通信目的地的MAC地址后转发给链路层。发送的步骤就齐活了。
接收端同样，一层一层往上传，直到应用层才算是接收到由客户端发送来的HTPP请求。
发送端在层与层之间传输数据时，每经过一层时必定会被打上一个该层所属的信息，反之，接收端在层与层传输数据时，每经过一层时会把对应的首部消去。这种把数据信息包装起来的做法称为封装。

确保可靠性的TCP协议

按层次分，TCP位于传输层，提供可靠的字节流服务(BYte stream Service),它是指为了方便传输，将大块数据分割成以报文段位单位的数据包进行管理。而可靠的传输服务是指，能够把数据准确可靠地传给对方。
为了确保数据无误地送达目标处，TCP协议采用了三次握手策略，首先发送端先发送一个带SYN标志的数据包给对方，接收端收到后回传一个带有SYN/ACK标志的数据包以示传达确认信息。最后发送端回传一个带ACK标志的数据包，代表“握手”结束。
若在握手过程中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包。
大概给人的感觉就是：
客户端：服务端我发送了标着SYN的数据给你。
服务端：客户端我收到了标着SYN的数据。
客户端：服务端我知道你收到标着SYN的数据了（发送ACK）数据包
当然.TCP还有其他各种手段保证通信的可靠性。

负责域名解析的DNS服务

DNS（Domain Name System）服务是和HTTP协议一样位于应用层的协议。它提供域名到IP地址之间的解析服务。
通常来说，计算机在网络中是一串数字标示也就是IP地址，但是对于人类来说，强记IP地址实在谈不上友好，同时也不便于管理。
于是DNS应用而生，它可以将域名对应上IP，平时在浏览器中输入域名，首先会像最近的DNS服务器发起查询，查不到则会一层一层往上去查询，直到搞清楚它对应的一个IP或者，或者一个都查不到位置。
这里就可以玩很多花样了，本地可以缓存IP地址加快访问速度，直接于客户端连接的前几层DNS服务器也可以返回错误的IP地址来重定向（DNS劫持）你想访问的页面，或者反给你不存在的IP来干扰访问。
或者在反给你信息的途中夹杂私货（DNS污染），比如找不到一些网站的时候反给你一个劫持者指定的布满广告的网站来赚取流量，或者在所有的网站里加小广告。
所以其实，作为家庭出口的网关（比如天翼网关），或者自己挂那的路由器一旦被劫持或者动了什么手脚...后果是非常严重的，而如果小区或者区域DNS被劫持，那影响是非常大而恶心的。
在我大青，经常有些区域运营商监守自盗自己搞DNS污染，再加上特色果情可以说所有的通信运营商运营的DNS都是被污染的...只是程度，目的，类型不同，所以有时在自己家中局域网搭建DNS能极大提高上网体验。

从URL到页面加载的过程？

这是一道比较常见的面试题，搞硬件的话你可以从键盘输入到LED展示，从CPU，内存，堆栈说起...
然而我是前端...对前端而言这道题很适合用来描述网络交互过程，进而加深对HTTP协议的理解。
首先让我们略过硬件和网卡交互直接从浏览器看起，众所周知浏览器是多线程的，所以当我们输入一个URL时首先会新建一个网络线程。

/*
    这里额外补充一点浏览器内核知识，浏览器内核包括下面几个部分
1. GUI渲染线程（HTML词法解析生成DOM树，CSS树，合并Render树，layout，painting渲染，回流，重绘，GPU绘制等等...）
2. JS引擎线程（解析，预处理，声明提前，作用域，执行上下文等等..）
3. 事件触发线程（事件绑定坚听）
4. 定时器触发线程（队列）
5. Htpp异步线程（AJAX）
*/

之后，解析URL，开启一个完整的Http请求（本文上面部分）细节来说则是：
1.首先请求DNS服务器查询IP，一层查不到就一层一层往上查，直到根节点
2.开启TCP/IP的三次握手四次挥手
3.服务器端接收信息并响应（展开的话有比如：负载均衡一类的话题）
返回以后就是浏览器渲染基本过程：
1.HTML解析生成DOM树
2.CSS解析
3.合并生成Render树
4.布局Render树
5.渲染Render树
6.浏览器发信息给GPU显示在屏幕上
细节不再展开，需要扩展的话可以看下回流，以及会引起回流的操作，这点对于性能优化也很有帮助。
性能优化的话，就比如防抖，和节流。
然后是JS的解析于预处理。
预处理：
1.补全分号
2.声明提前
可见，块级作用域下将局部变量声明在顶部和良好的分号习惯可以提示一丝丝性能...
之后就是执行和垃圾回收之类的。
这么打完这道题感觉与HTTP的关系似乎并不大？其实不然，从URL解析之后的部分完全可以用上面的Web基础来进行扩展。
当看完这本《图解HTTP》对我来说想必可以答得更全吧，作为课后题姑且算是合格的。

结语

本来是打算记录两章内容的，然而，阅读恐怕只花费的半个小时到一个小时，理解也花不了太多时间。
但是，转换为文字并记录下来，就不一样了，也许我还不熟悉，这篇文字虽然不连续，但也花了差不多快三个小时。
这也许就是了解和掌握的区别吧，将书本用自己的语言转述出来，转述的文字对于他人来说也许并不是什么太好懂得东西。
但是对于输出文字本身的人来说无疑是一种巩固，一种提升。