共计 6686 个字符，预计需要花费 17 分钟才能阅读完成。
一、《图解 HTTP》- WEB 和网络根底
1.1 本章重点
结尾局部是对于 WEB 和网络历史介绍，所以没有多少须要了解和记忆的内容。网络根底 TCP/IP 的局部是整个互联网的外围，倡议多看几遍了解和消化。
WEB 的传输依赖 HTTP（HyperText Transfer Protocol，超文本传输协定 1）的协定作为标准，HTTP 的工作是实现从客户端到服务器端等一系列运作流程，为了保障两台不同的设施能失常沟通，两者须要恪守雷同的规定。
目前 HTTP 曾经倒退到 3.0 了，然而这本书写下来的时候 2.0 还在起草，所以能够认为是一本比拟“老”的书，很多中央须要查阅以后的材料进行纠正。
1.2 HTTP 诞生
1989 年 3 月 HTTP 在少数几个人手中诞生。CERN（欧洲核子钻研组织）的蒂姆 • 伯纳斯 – 李（Tim BernersLee）提出网络通信的构想。
1990 年 11 月，CERN 胜利研发了世界上第一台 Web 服务器和 Web 浏 览器。
1990 年，大家针对 HTML 1.0 草案进行了探讨，因 HTML 1.0 中存在 多处模糊不清的局部，草案被间接废除了。
1993 年 1 月，古代浏览器的先人 NCSA（National Center for Supercomputer Applications，美国国家超级计算机利用核心）研发的 Mosaic 问世了。同年秋天公布 Windows 版和 Macintosh 版面世。
1994 年 的 12 月，时代的眼泪网景通信公司公布了 Netscape Navigator 1.0，1995 年微软公司公布臭名远扬的 Internet Explorer 1.0 和 2.0，随后 IE 折磨开发人员数十年的历史开始。
这里有一个互联网比拟出名的历史，那就是对于微软和网景之间的浏览器抢夺，感兴趣的同学能够查查这一段历史，微软最终凭借 Windows 平台的客户粘性绑定以及收费博得胜利，网景尽管赢了官司然而浏览器市场被 Windows 垄断逐步败落，毕竟 explore 不免费谁奈何的了我。
当初的 FireFox 浏览器前身就是网景，不过浏览器内核却是谷歌一家独大，Edge 在 chrome 内核以及本身优化的加持下也可圈可点，然而微软利用平台强制绑定客户的行为仍旧可见一二，这都是古代的用户能够感知的。
另外值得一提的是 3W 的构建蕴含三种技术：
- SGML（Standard Generalized Markup Language，规范通用标记语言），是现时罕用的超文本格式的最高档次规范，是能够定义标记语言的元语言，甚至能够定义不用采纳 < > 的惯例形式，因为 太简单因此难以遍及。后续的 HTTP 和 XML 都能够看作这个协定的扩大和拆分和简化。
- HTML（HyperText Markup Language，超文本标记语言）。
- URL（Uniform12 Resource Locator，对立资源定位符）。
1.3 HTTP 历史简述
HTTP 倒退到当初也根本所有网站都是 HTTP1.1 版本作为规范，自 1999 年公布的 RFC2616 之后再未进行过订正。
这部分内容在第二章中会再次重点扩大和探讨
RFC2616协定在线浏览：
RFC2616
历史倒退
感兴趣能够点击协定号查看原文。
- HTTP/0.9：HTTP 于 1990 年问世，这个版本能够看作是 1.0 之前的雏形，因为没有作为规范正式版建设，所以被叫做为 0.9。
- HTTP/1.0：HTTP 正式作为规范被颁布是在 1996 年的 5 月，规范号为RFC1945（点击链接查看白皮书）。
- HTTP/1.1：1997 年 1 月颁布，直到现在仍然还有大量的网站在应用，最后规范为 RFC2068，之后公布的修订版 RFC2616 就是以后的最新版本。
-
HTTP/2.0：HTTP/ 2 是 HTTP 协定自 1999 年 HTTP 1.1 的改进版 RFC2616 公布后的首个更新，次要基于 SPDY 协定。
它由互联网工程工作组（IETF）的 Hypertext Transfer Protocol Bis（httpbis）工作小组进行开发。该组织于 2014 年 12 月将 HTTP/ 2 规范提议递交至 IESG（英语：Internet_Engineering_Steering_Group）进行探讨，于 2015 年 2 月 17 日被批准。
HTTP2.0 的规范号：RFC 7540
最初在网上找到一个对于 HTTP 协定的翻译网站，我的项目作者貌似弃坑很多年没有更新，然而对于英语根底较差的同学能够作为参考：
rfc7540-translation-zh_cn
1.3.1 HTTP/2.0 的特点
这部分内容同样会在第二章具体介绍。
HTTP/2.0 的指标是改善用户在应用 Web 时的速度体验。
为了撑持这一实现，官网提出了三种技术：
- SPDY（SPDY HTTP Speed）：谷歌提出用于进步 HTTP 拜访效率以及解决 HTTP1.X 中管道化的缺点，用意是缩短整个申请工夫。
- Mobility Network-Friendly：由微软公司起草，是用于改善并进步挪动端通信时的通信速度和性能的规范。见名知意它是被用来实现手机高速上网的一个协定。
- HTTP Upgrade（Network-Friendly HTTP Upgrade）：
1.3.2 HTTP2.0 题外话
这本书写于 13，14 年左右，HTTP2.0 到当初都快靠近十年了如同到当初才略微恶化不少，所以作为读者必定好奇当初到底遍及多少了，这里找到一个可供参考的网站，从纸面数据来看截止到目前国外的统计目前应用 HTTP/2 的还不到一半也就意味着还有一大半的服务器还在应用 hTTP1.1。
这就引申了下一个话题，3.0都快要进去了为什么 2.0 还没全面遍及？
这就要理解为什么 2.0 的遍及这么难。
首先是 HTTP1.0 中申请十分纯正，一个申请就是一次 HTTP 连贯，申请实现就断开。
于是 HTTP1.X 降级了一下，能够通过 Keep-alive 优化 TCP 的建设和断开，一次连贯也能够对应多个申请。
然而谷歌是不会满足这样的效率的，谷歌推动了 HTTP2.0 的降级，针对 HTTP1.X 的申请响应必须要排队的问题解决，应用多路复用实现整个申请。
所以为什么协定在提高，看起来效率在显著晋升，为什么 HTTP 的降级难以推动？
表层来看
实在的我的项目根本须要依赖框架实现，有一些旧零碎旧版本的框架不是想降级就降级的，或者说压根懒得降级，因为没有显著的带来效益的益处。
更深层次的起因
HTTP2.0 自带 HTTPS，这样实际上就导致一个抵触问题，理论的我的项目大多须要应用 Nginx 反向代理，然而 Ngnix 也能够开启 Http2.0 的反对呀，为什么仍然保持要用 Nginx 做反向代理而不是间接应用 HTTP2.0 呢？
这样的起因可能来自 TCP 长链接，在 Nginx 部署的状况下，实际上申请不须要走一长串的路由而是间接和 Nginx 交互。然而 HTTP2.0 能够通过多点部署以及多个申请程序并行，通过集群和负载平衡能够很好的满足服务器要求。
在框架当中如果把申请发给本地，局限单台机器的核数量，并发效率实际上和 HTTP1.X 差不多，因为工作多起来仍然须要排队。
如果开启 HTTP2.0 并且交给 Nginx 拆分模块并且简化性能，不扭转开发模式的状况下又能够利用集群。
最初 HTTP2.0 尽管解决了 HTTP 多路复用并发申请的问题，然而 TCP 的问题并没有被解决。
从下面的探讨来看，大体上是 TCP 的锅，其次是 Nginx 够强以及框架降级的高老本问题，最初是期待 HTT P3.0 一步到胃。
当然不要认为 50% 普及率很低，从另一个角度来看访问量很大日常应用的网站根本都有 HTT P2.0 的加成。
1.4 TCP/IP
了解 HTTP 必然须要理解 TCP/IP。
HTTP 协定是应用层的协定，如果是金字塔构造它处于模型的顶层，然而实际上金字塔的外围是 TCP/IP，HTTP 是在此基础上做撑持的，古代的网络架构是基于 TCP/IP 模型建设的，HTTP 也只是其中的一部分。
TCP/IP 是互联网相干的各类协定族的总称，这是一种说法，示意他单单只是字面意思的 TCP 协定和 IP 协定。然而另一种说法是只是代表了 TCP 和 IP 这两种协定。
TCP/IP 协定族按档次别离分 为以下 5 层：应用层、传输层、网络层和数据链路层，以及和硬件密切相关的物理层。
层次化的设计意味着便于批改，也就是常说的高内聚低耦合在 TCP/IP 协定失去充分体现，然而实际上这种设计不是齐全没有毛病的，那就是每一层尽管能够降级然而无奈冲破原有的框架，TCP 协定自身也是导致 HTTP 协定难以推动的一个重要起因。
《TCP/IP 详解，卷 1》中结尾介绍了 OSI 模型又是啥？实际上是晚期互联网协议构建者的美妙愿景，希图通过这一个模型实现一个极强扩展性的互联网架构，说好听点就是把规范给齐全垄断掉，让当前的架构无牌可打你们都得听我的。
当然现实和美妙事实很骨感，因为 OSI 模型构造的层级过多并且难以推动和保护，后续被更为精简好了解的 TCP/IP 疾速取代。
所以 OSI 模型是历史奋斗的产物，不须要过多关注。
依据模型介绍各层都做了什么？
- 应用层：决定为用户提供服务的应用程序相干流动。
- 传输层：传输层次要是协定之间的数据传输，蕴含各种丰盛多样的协定，包含然而不限于 TCP 协定，比方 TCP（Transmission Control Protocol，传输控制协议）和 UDP（User Data Protocol，用户数据报协定）。
- 网络层：网络层用来解决在网络上流动的数据包，最终转化为网络包的最小单位进行传输。
- 数据链路层：也能够认为是看的见的硬件局部，比方网卡，硬件上的领域均在链路层的作用范畴之内。
- 物理层：也就是网线和集线器等网络传输反对设施，从粗略角度来看能够间接看作网线。
上面是整个网络数据包的封装过程，如果想要理解整个过程能够查看《网络是怎么样连贯的》这本书的第二章局部。
1.4.1 IP、TCP 和 DNS
依照协定档次划分：IP（Internet Protocol）网际协议位于 网络层 ，TCP 位于 传输层，所以 TCP/IP 协定除了代表一个协定族群之外，TCP 协定和 IP 协定自身其实就不在一个层级，所以不能一概而论。
IP 协定（Internet Protocol）
IP（Internet Protocol）网际协议位于 网络层。
IP 协定的次要工作是确保信息能精确传输，为了保证数据能正确的送达，IP 协定须要确保 MAC 地址和 IP 地址的正确，IP 地址指明了节点被调配到的地址，MAC 地址是指网卡所属的固定地址。
IP 地址因为内外网通信的缘故有可能会存在地址转化，地址转化依赖的是地址转化设施，然而 MAC 地址是从网卡生产之后就固定了世界上惟一的网卡 MAC 地址。
ARP 协定凭借 MAC 地址进行通信，接着便是通过相似快递导航寻找站点的形式进行通信传输，整个外围是通过“查表”形式进行。
ARP 协定（Address Resolution Protocol）：ARP 是一种用以解析地址的协定，依据通信方的 IP 地址就能够反查出对应的 MAC 地址。
TCP 协定
TCP 协定位于传输层，提供字节流服务，所谓字节流服务是指大块数据拆分为报文段，而牢靠服务指的是把数据传输给对方，同时 TCP 为了保障大段数据的传输会进行数据切割。
为了确保数据精确传输，整个 TCP 还须要依赖三次握手，对于三次握手的过程这里也不做过多探讨，能够看《网络是怎么样连贯的》读书笔记内容。
DNS 服务
用户通常应用主机名或域名来拜访对方的计算机，而不是间接通过 IP 地址拜访。DNS 是负责域名和 IP 转化的服务，在申请指标服务器之前，通常须要依据 DNS 服务获取域名对应的 IP 地址。
各协定和 HTTP 关系
留神在书中省略无关 MAC 头部的内容，另外整个图画算是最为入门级的角度，实际上略微深刻就会发现没有那么简略这幅图也是画的过于抽象，简略看看角色的根本职责即可。
1.4.2 URL 和 URI
区别和比照
首先得辨别概念自身：
URL：示意对立资源定位，也就是咱们拜访 WEB 服务器在浏览器顶部的那一串数字。
URI：其实这里蕴含三个组件，URI 全称 是 Uniform Resource Identifier，RFC2396 在标准种的 1.1 别离对于这三个单词进行上面的定义，整体来看 URI 就是由某个协定计划示意的资源的定位标识符。
Uniform：规定对立的格局可不便解决多种不同类型的资源，也就是常说的“习惯优于配置”，具体案例是比方 ftp 是 ftp 结尾申请走协定，http 结尾申请走 http 协定。
Resource：形象定义资源是“任何能够拜访的货色”，比方文档，图片，网络文件等等全都能够看做资源。
Identifier：示意能够标识的对象，也叫做标识符。
URI 属于互联网顶级标准的行列，只有合乎 URI 标准的申请能力被辨认，由隶属于国内互联网资源管理的非营利社团 ICANN（Internet Corporation forAssigned Names and Numbers，互联网名称与数字地址调配机构）的 IANA（Internet Assigned Numbers Authority，互联网号码调配局）治理颁布。
对于标准的相干文本能够参考文末局部
最初是无关 URL 定义的两个直观例子：
hierarchical part
┌───────────────────┴─────────────────────┐
authority path
┌───────────────┴───────────────┐┌───┴────┐
abc://username:password@example.com:123/path/data?key=value&key2=value2#fragid1
└┬┘ └───────┬───────┘ └────┬────┘ └┬┘ └─────────┬─────────┘ └──┬──┘
scheme user information host port query fragment
urn:example:mammal:monotreme:echidna
└┬┘ └──────────────┬───────────────┘
scheme path当然官网在白皮书也给了一些案例：
The following examples illustrate URI that are in common use.
ftp://ftp.is.co.za/rfc/rfc1808.txt
-- ftp scheme for File Transfer Protocol services
gopher://spinaltap.micro.umn.edu/00/Weather/California/Los%20Angeles
-- gopher scheme for Gopher and Gopher+ Protocol services
http://www.math.uio.no/faq/compression-faq/part1.html
-- http scheme for Hypertext Transfer Protocol services
mailto:mduerst@ifi.unizh.ch
-- mailto scheme for electronic mail addresses
news:comp.infosystems.www.servers.unix
-- news scheme for USENET news groups and articles
telnet://melvyl.ucop.edu/
-- telnet scheme for interactive services via the TELNET Protocol最初咱们简略来比照 URL 和 URI，能够看到 URI 划定了 URL 的“分类”，所以 URL 能够看做是 URI 的子集。
URL 格局
这里次要介绍用的比拟少的片段标识符，片段标识符示意 已获取资源中的子资源。
留神互联网中并不是所有的申请都会合乎 RFC 协定的，RFC 指的是 HTTP 协定的意见修改书，这些内容少数状况下应用程序都会恪守，然而凡事总有特例。
如果不参考 RFC 协定进行通信那么就须要本人的协定实现客户端之间的通信，比拟典型的例子比方 RPC 协定就是经典的非 HTTP 协定通信实现，当然这种计划存在不少的问题和争议。
1.5 总结
和少数技术书相似，第一章算是概览的一个章节，大抵介绍了 HTTP 的根底背景，当然这本书的确很老，很多协定和规范到当初其实早就不在应用了，然而从另一个角度来看 IP、TCP、DNS 这些货色根本都是万年不变的，所以不须要放心会过期。
对于 HTTP2.0 的探讨是笔记中的扩大局部，在这一部分大抵探讨了一下为什么 HTTP2.0 难以推动，然而实际上 HTTP2.0 在各大支流网站都有遍及，国内的一些大厂商根本也是第一工夫跟进的。
