再读http协议

TCP/IP分层协议模型

概述

实质上TCP/IP有七层模型，但我们一般只简化成四层模型讨论即可。

TCP/IP的七层模型

参考

TCP/IP的四层模型(主流)

http协议是TCP/IP协议的一个子集

http协议是构建在TCP/IP协议基础上的，是TCP/IP协议的一个子集；

TCP/IP协议是有四层协议组成度系统：

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

传输层有两个性质不同的协议：

tcp 是有连接的(三次握手)，安全、不过效率低点；
UDP 无连接，不安全，不过效率更快；

下面是数据包封装过程：

四层模型展示http传输过程

图一勘误：浏览器属于应用层，不属于传输层关于四层模型对应的对象，可以参考文中的《四层模型对应的实际对象》

http连接何时结束：

tcp\ip协议与dns服务器关系

浏览器查询IP的过程不是tcp\ip协议

如下图，浏览器访问站点，首先访问dns服务器，获取IP后，
才生成http请求，之后才与服务器建立tcp\ip链接。

访问网页包含查询IP与发送http两个请求

如上图，访问一个页面，要做两个请求

查询dns获取IP
获取IP后，发起http请求

再读四层模型

图示

下图是左侧客户端发送http请求，经过层层加首部信息，
传递给服务器电脑，
再由服务器电脑，经过层层拆包，
获取http数据的过程。

获取http数据后，服务端响应的数据也是经过上面一个循环传递给客户端的。

服务端接收时数据包拆包过程

我们先说服务端：
上图右侧是服务端处理 tcp/ip协议链接的过程：

服务器网卡拆包：
以太网首部内容有服务器mac地址（对应物理网卡地址），若与自己一致，说明是给自己的；
就会把数据包的以太网首部拆掉，把不包含以太网首部的数据包发给网络层；
网络层继续拆包：
经过网卡拆包后，网络层收到的数据包只包含了 IP首部、tcp首部、http数据。
网络层把其中的 IP首部信息拆出来读取其中信息。
IP首部信息中包含了 IP信息，如果IP是本机地址，那么发往传输层；
传输层继续拆包：
拆出 tcp 首部， tcp信息中包含了端口号信息，比如443 80 等，如果本机中有对应端口号的应用程序，
就把只有http数据的数据包给应用程序，比如 apache nginx；
应用层解析 http 数据
nginx 解析 http 数据，然后做出响应，响应的http数据，也会经过层层加数据到达
客户端后，被层层拆包到达客户端内的应用，如浏览器或app；

为了一个http数据传递，加了很多其他信息

如上图，我们为了正确传输一个http数据，最后，给这个http数据加了很多层数据：以太网首部，IP首部、tcp首部：

http数据传递数据层层封装的原因

一个是为了安全，第二个实现隔离，第三个是逻辑分离；
比如，发送一条http请求到服务端；
服务端为了免除一些ip地址的攻击，于是可以在网络层，设置一个ip黑名单，来自某个ip地址的网络请求，直接在网络层就给拒绝掉；
这样信息就到达不了传输层，起到了保护传输层，也是一种隔离效果；
还有一个例子，
例如在我们的电脑软件中，如浏览器、桌面软件程序如qq、微信，他们不需要关注网络层、传输层的事情，不需要关注网络层和传输层的连接或tcp的三次握手连接；
这些软件，只关注于如何应用数据，如何解析和使用http数据。
从这个角度讲，http的数据传输就必须使用分层设计，处于应用层的数据，至于tcp连接的事情，应用层一概不管。

另外一方面，网络层只专注ip地址信息，网络层解析完数据后，为了数据包更加简洁纯净，剔除掉网络层才需要的数据信息，传给传输层；
这就是数据解析时的层层剥离递减；

http数据传递为什么要设计这么多层

参考上面《http数据传递数据层层封装的原因》

传输层理解

电脑中，是通过端口号来确定应用软件的。
所以传输层的首要任务是识别出端口号，识别出端口号，就识别出了对应的应用程序，
这样就知道把数据包传输给下一步的应用程序了。

网络层的理解

一个电脑不一定只有一个IP，很多服务器应用软件可以设置多个虚拟ip，因此物理mac地址能唯一确定电脑地址；

但同一台主机可能多个IP，需要网络层进一步识别。

链路层理解

四层模型中，链路层包含了原来7层模型中的物理层。

tcp/ip分层四层模型理解

四层模型对应的实际对象

四层模型为：链路、网络、传输、应用层；

网络层通过ip进行查询；

IP首部信息中包含了 IP信息，如果IP是本机地址，那么发往传输层；
其理解可参考下面的传输层。
因为物理链路的通道已经打通，可以认为网络层也是设备内的软件系统。
传输层主要用于tcp/ip连接；

拆出 tcp 首部， tcp信息中包含了端口号信息，比如443 80 等，如果本机中有对应端口号的应用程序
由此可以看出传输层，因为物理链路的通道已经打通，传输层应该属于电脑的软件系统层面干的事情，
当然了很多公司做了层层路由器和网络安全等等，传输层也可以属于任意能起到传输作用的设备内的软件系统，包括电脑或路由器或机房等等；
应用层最好理解，就是应用http数据的具体软件，如浏览器、微信等；
应用应用，所谓的应用，就是实际使用数据的层面。
链路层可以抽象的理解为所有硬件通讯支持以及系统控制都属于这个层面，如光纤、设备网卡等等；

四层模型与货物运输的对应关系

tcp/ip分层的主要目的在于一个http数据从服务端传递到客户端的过程，反之一样；
简言之，就是最重要是用来传递http数据的。
那么这个传递过程，好比快递送货的过程，
需要设计一套地址系统、铺设公路、货车运送、货物打包等过程。
我们可以形象理解tcp分层与快递送货的一一对应关系：
设计一套地址系统对应链路、网络层；
铺设公路对应 tcp连接的传输层；
货车运送能力对应 http协议，如http1.1 2.0；
货物打包解包对应 http协议；
显然货车运送属于应用层，货物打包解包也属于应用层；

其实这其中，打交道最多的两层是传输层、应用层；
传输层涉及tcp协议、应用层涉及使用http数据的所有软件如浏览器等；
我们可以形象的认为：
tcp连接就是建设好了传输层，就是修好了货物运输的公路；
应用层只管使用http数据，不管货物运送的问题，因为货运已经运送到，应用层就是我们日常使用的众多软件，我们软件开发就是在应用层搬砖，应用层是我们软件开发的最大天地。

html协议基础

了解http协议

TCP/IP的四层模型

参考上面《TCP/IP协议的分层模型》

无连接(请求完即关闭) 与面向连接(三次握手)

如题。http拥有此特性。

无状态

对于服务器而言，无论第一次还是第几次请求都一样，服务器返回的东西是一样的，服务器不会记住之前的请求情况，
这就是http请求的无状态性

两种保持连接状态的手段：cookie与session

参考《session》

session

概述

如下用户登录，后台生成session，然后将session写入cookie，页面的后续操作都通过cookie读取，对比session。

session 一般于 cookie一起使用

显然无状态性质难以满足某些需求，因此产生了两种保持状态的手段cookie与session；
前者存储于客户端，后者存储于服务端；
比如你之前做过登录的http请求，你就有cookie，第二次请求服务器的时候，虽然请求还是无状态的，
但是通过cookie这种技术手段，可以保存之前的请求信息，为下次服务器响应提供信息。

也称为会话跟踪技术。

session 基本上要与 cookie 一起使用；
如下图，通过session信息设置cookie，通过cookie，每次更新session信息，进而更新cookie。

session与cookie 区别和异同

前者用户服务端，后者客户端；
前者有时效性，可能很短；后者cookie，可以设置无限长时间；

session 也可于 url 一起使用

百分之九十的网站使用cookie 配合 session使用；
也有浏览器禁用了cookie，是不是就不能使用session了呢；
此时可以使用url 配合 session使用；
session本质上是服务端给客户端存储的用户档案；
只要有技术能将客户访问信息传给服务端那么 session就可以发挥档案存储作用；
除了cookie，客户端可通过url把用户信息(session)传给服务端：
一种是给url 添加附加信息(分号隔开)传给服务端：

一种是给url，添加查询信息：

http的长短连接本质是TCP长短连接

概述

http协议是应用层的协议，而连接是传输的意思；
因此http的长短连接，本质上是传输层的TCP协议；

http1.1默认长连接

http1.0默认用短连接；
http1.1默认用长连接；

长连接需要服务端和客户端都支持

如题。

适用场景

长连接适合要频繁请求的；
短连接适合不常请求；

长连接要考虑的

服务端应该要考虑哪些连接如果长时间处于空闲，就应该关闭连接；
或者当一台电脑于服务器长连接超过一定数量时，关闭一些长连接；

代理与抓包

如下为什么很多抓包工具都使用了代理呢，
因为抓包工具都需要抓取请求的入参和返回，只有通过一层抓包工具的代理，所有的请求都发往抓包代理服务器，
进行转发，如此，抓包工具就可以抓取入参和响应，市面上场景抓包工具都有用代理，可以这样验证：
打开一个抓包工具，然后点击浏览器的代理设置，此时应该浏览器走了代理了

网关

网关跟代理相似，不同的是，代理只能转发协议相同的请求；
网关则没有这个限制；
网关是一个协议转换器。

缓存

一般对静态资源缓存

一般页面对请求频率不大的做缓存，比如静态资源，如js、css、图片等；

缓存一般通过请求头与响应头实现

Expires 与 Cache-ConTrol 的 max-age共存时，优先级比 max-age地；

Etag优先级比 Last-Modified 高；

请求场景demo

如果过了Expires时间，但是文件又没有修改呢，此时引入 Last-Modified，如果Expires过期，但Last-Modified没有变化，那么认为文件是同一个，返回304；
Last-Modified优先级比Expires高。

Last-Modified是一个秒或者毫秒单位，也有可能在同一秒甚至毫秒内，文件也被改变的情况，此时引入 Etag 作为文件的唯一标识，
如果 Etag 改变，其他缓存头都无效，Etag优先级最高。
如果Etag未改变，则直接认为 304；

cdn

概述

一个城市只有火车站才能售票，
此时城东、城西、城北、城南的人都只能去火车站买票，
一来加大了买票人购票效率，让购票更加麻烦；
二来加大了火车站承受压力，全城的人都去火车站买票，火车站就这么大，无法扩建，这样火车站就承受了很大的售票压力。
此时火车站在城市各地设置了火车票代售点，既方便了购票人，也减轻了火车站总站的压力；
而cdn就类似这样的火车票代售点。

优点

提高了访问速度；
一个是就近提高了访问速度；
另外一方面，比如北方大多人用联调，南方大多用电信，此时北方人通过联调cdn服务器肯定要比电信cdn服务器快。
减轻了对服务端总站访问的压力；

工作机制

内容协商机制：不同地区访问，返回不同语言页

概述

同一个url，不同地区访问时，可能出现不同语言的页面，
这与服务端与客户端内容协商返回机制有关，
目前主流的内容协商机制是服务端判断请求头信息，进行内容返回，
如下是主要的内容协商的请求头：

近似匹配 q

下图 q用来表示优先级权重，用于近似匹配：

断点续传和多线程下载

Range

断点续传的请求，请求头会包含 Range 请求头：

迅雷的下载暂停与继续下载，或者下载过程网络异常或中断，网络连接后继续下载，这些都是断点续传。

206

断点续传成功后返回的状态码是 206 而不是 200。

断点续传过程

多线程下载(分片下载)

多线程下载与断点续传一样，只是断点续传是被动，一个片段一个片段下载；
多线程下载是主动将下载切割成多个片段，同时进行下载。

请求头

概述

accept

406 响应码：

其他

http协议瓶颈

概述

一个浏览器同一个域名下，一次最多4个http连接请求，后面的将阻塞；根据各个浏览器不同，连接数量不一样。

websocket

websocket的优点：

全双工连接；
减少通信量，如建立ws连接后，后续通讯不用请求头信息等等。

spdy

认识url

www.github.com

www 是主机名，github.com 是域名；

http协议进阶

多种加密方式(https)

对称加密

对称加密也叫密钥加密，加密和解密都使用一个密钥。
如下图，会话开始，小萌把密钥 key1 发给小风；
后面小风每次与小萌通过都通过这个密钥 key1 加密。

这样有个问题，如下图，中间人在一开始就截取了他们的请求，一开始就获取了小萌发的key1密钥，那么中间人就可以解密二者的谈话内容了。

非对称加密

为了解决上面的问题，就要用到非对称加密，非对称加密有个重要特点，有公钥和私钥，可以通过公钥加密，私钥解密；也可以通过私钥加密，公钥解密。
如下图，小萌把自己的公钥 key1 发给小风，小风自己设置好一个密钥key2，同时用key1加密key2得到va3，发给小萌；

小萌收到va3后通过自己的私钥解密va3，也得到了key2。
此时小风和小萌都知道了密钥key2。
他们之间可以像上面对称加密一样，通过key2进行加密对话。
而中间人由于没有小萌的私钥，因此无法解密va3，无法获取key2，就无法解密他们的通话。
上面通过非对称加密来传输对称加密的密钥，保证对称加密的密钥不被盗取；
后期通过对称加密经过通话。

不过这样有个问题，由上面知道，只要能获取小风的对称加密密钥key2，就能解密对话，因此中间人在他们第一次会话时，串改小萌的key1，换一个自己的公钥kex1给小风；
小风通过kex1加密key2得到va3；中间人通过私钥解密va3，获取key2，再用key1加密key2获得va3-1 给小萌，
小萌通过私钥解密va3-1获得key2.
这样三个人都获得了小风的密钥key2.

非对称加密的改进点

非对称加密，比如上面的小萌，使用了一个公钥和私钥，只有他才能解密，因此小风将会话秘钥通过公钥加密后，唯一能够解密出会话秘钥的就是小萌了，
这就解决了会话秘钥被窃取的问题。
但有一个新问题，第三人随意给小风一个公钥，小风毫不犹疑不加怀疑的用这个第三人公钥将会话秘钥加密，发给第三人，第三人通过自己的私钥解密就获取到会话秘钥了。
解决这个问题的关键是让小风知道这个公钥是假的，如果小风知道公钥是假的，就不会使用假公钥来加密会话秘钥并发送，第三人也就无法获取会话秘钥。
此时就需要一个公证机构保管所有网站的公钥，此公钥包含了对应的网站域名信息，网站域名和网站ip都是唯一的，根据网站域名ip等信息制定一一对应的公钥。
这些公钥统一被保管在公证机构，所有的浏览器都有一份这样的公钥字典，浏览器根据域名ip等就能查询到对应的公钥。
这样就杜绝了小风得到假公钥的问题，避免会话私钥被窃取。
而这个公钥就是部署https时候申请的证书中的公钥。

我们在服务器部署https的时候，会去购买证书，就会得到公钥和私钥，然后将公钥和私钥都上传到服务器上，公钥用于对外加密。

证书加密(https)

为了解决上面问题，此时引入了证书，如下图，小萌将key1发给证书机构，证书机构发给小萌一本证书。

小萌将证书发给小风，因为各大浏览器都知道所有机构的证书消息，小风核对证书真假后，因为浏览器知道各个证书的key1，小风获得key1；
小风通过 key1 加密 key2，传给小萌，小萌私钥解密获得key2，后期就通过key2 进行通话。

因为证书的生成包含了服务器地址等一系列信息，基本上无法造假，所有中间人无法伪造证书，解决了上面串改的问题。

因为证书带了一系列服务器地址信息，所有无法针对指定的服务器再伪造一个证书；
而浏览器又有鉴别证书是否为某个服务器的能力；
因此中间人无法再通过自己伪造证书从浏览器端骗来浏览器用于对称加密的密钥了。

https

原理

https 一般是非对称加密传输会话密钥，
会话使用对称加密：

概述

在国内https起源于2014年百度网站的率先使用，到如今不过6年多。

特点

内容加密：保证浏览器发送到客户端的报文是加密的；
这个过程中，非对称密钥交换，对称内容加密：非对称加密用于密钥交换，对称加密用于内容加密，详细参考《多种加密方式(https)》
身份认证：保证你当我的服务器准确性
数据完整性

使用成本

证书费用以及更新维护：其实这个也不算贵；
https降低用户访问速度：其实合理部署，不逊于http速度
消耗cpu资源，需要增加大量机器：比如非对称密钥交换，对称内容加密，这些都消耗cpu等等

https加密的误解

https加密是报文加密，防止的是中间代理窃取报文，防止抓包等等；
因此https加密是相对中间代理、抓包工具而言的加密，如果你用抓包工具抓包 https请求，你会发现报文都是加密的；
但https加密不对浏览器控制台加密，用浏览器查看请求参数，都是未加密的。

也可以这样理解：
根据 tcp/ip经典四层分层结构，https的加密解密都是发生在传输层 TLS（传输层加密协议）；
根据分层隔离的理解，应用层不需要关心传输层加密解密的工作，因此给到应用层的http信息都是传输层已经解密好的信息，所以浏览器、桌面webview、手机webview 这些都是属于应用层，他们的http数据都是未解密的，这也解释了浏览器控制台，用浏览器查看请求参数，都是未加密的。

http2.0

2015年出现；
http2.0 与 spdy渊源很深，很多原来维护spdy的人，后面转而去维护http2.0，某种意义说，http2.0是spdy的升级。

http 0.9与1.1区别

这里只讲述部分区别。

http 1.1 并发6个tcp连接

http 1.1 可以并发建立tcp连接，从而并发http请求，
因浏览器不同，并发连接数量略为不一，一般认为是6个tcp连接。
不过每个tcp连接只能一个一个地进行http请求，无法并发http请求。
由于一次可同时并发6个tcp连接，每个tcp同时只能处理一个http请求，
因此可说 http1.1协议可同时并发 6个http请求。

keep-alive 长连接

1.1默认长连接，tcp连接后，一次http请求完后，不会关闭tcp连接，后期其他操作的http请求可复用tcp通道进行传输。
这从侧面说明了，tcp是类似火车的铁路道路，是传输的道路，http数据包请求是道路上奔跑的火车，关闭铁路，火车就不能传输。

一个tcp连接同时只处理一个http请求

参数上面。

实验-通过浏览器查看(需要设置3G网络)

如下，需要设置网络为3G，不然看的不是很明显，且设置清除缓存：

如果网络速度很快，导致http响应非常快，此时都来不及或者没必要建立新的tcp连接，直接复用上一次tcp连接，此时看到的tcp连接不是很明显的6个：

http 1.1与2.0区别