一、《图解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模型是历史奋斗的产物，不须要过多关注。

依据模型介绍各层都做了什么？

  1. 应用层：决定为用户提供服务的应用程序相干流动。
  2. 传输层：传输层次要是协定之间的数据传输，蕴含各种丰盛多样的协定，包含然而不限于TCP协定，比方TCP（Transmission Control Protocol，传输控制协议）和 UDP（User Data Protocol，用户数据报协定）。
  3. 网络层：网络层用来解决在网络上流动的数据包，最终转化为网络包的最小单位进行传输。
  4. 数据链路层：也能够认为是看的见的硬件局部，比方网卡，硬件上的领域均在链路层的作用范畴之内。
  5. 物理层：也就是网线和集线器等网络传输反对设施，从粗略角度来看能够间接看作网线。

上面是整个网络数据包的封装过程，如果想要理解整个过程能够查看 《网络是怎么样连贯的》这本书的第二章局部。

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在各大支流网站都有遍及，国内的一些大厂商根本也是第一工夫跟进的。