作者
L的存在来源
我是程序员小贱
本文将从以下几个方面进行分享。其中包括HTTP发展史，HTTP缓存代理机制，常用的web攻击，HTTP和HTTPS的流量识别，网络协议学习的工具推荐以及高频HTTP与HTTPS的高频面试题题解等，开工。
提纲
年，蒂姆·伯纳斯-李（TimBerners-Lee）在论文中提出可以在互联网上构建超链接文档，并提出了三点：
URI：统一资源标识符。互联网的唯一ID
HTML：超文本文档
HTTP：传输超文本的文本传输协议
HTTP应用在哪儿
学习一门知识，采用五分钟时间看看这个知识是干啥的可能会更加有目的性。HTTP可谓无处不在，这里例举出几个。
HTTP应用场景
HTTP是什么
HTTP(hypertexttransportprotocol)翻译过来为超文本传输协议，文本可以理解为简单的字符文字组合，也可以理解为更为复杂的音频或者图像等。那么将这个词语拆分为三个部分。
超文本传输协议
超文本和文本相比多了一个字超，这样看来比文本丰富，因为它可以将多种文本/图像等进行混合，更重要的是可以从一个文本跳转到另一个文本(文本连接)。
传输，传输的过程中需要沟通，沟通即可能一对一沟通也可能一对多沟通(进行内容协商)，无论怎么样，参加沟通的人数1，想尽一切一切办法更快更好的完成相应的任务。
协议，无规矩不成方圆，做机密项目之前需要签署保密协议，找工作要签三方协议，三方协议是学校，公司，和个人组成的协议，都是为了让大家受一定的约束，违反了即有相应的惩罚。
三方协议
不同版本的HTTP
1、HTTP/0.9
当时网络资源匮乏，0.9版本相对简单，采用纯文本格式，且设置为只读，所以当时只能使用Get的方式从服务器获得HTML文档，响应以后则关闭。如下图所示：
GET/Mysite.html
响应中只包含了文档本身。响应内容无响应头，无错误码，无状态码，可以说是裸奔。
HTMLHelloworld/HTMLHTTP/1.0
此时HTTP/0.9请求过程如下：
应用层的HTTP建立在传输层的TCP之上并运用TCP可靠性等特性，先三次握手建立连接客户端请求建立连接(此时只有GET)服务端响应请求，数据以ASCII字符流返回给客戶端传输完成，断开连接。
HTTP0.9
2、HTTP1.0
随着时代的进步，仅仅文本的传输无法满足需求，更多情况需要采用图文的方式才能生动的表达出自己的观点。随着年开发出Apache，同时其他的多媒体等技术发展迅速，从而进一步的促使HTTP新功能的出现。HTTP1.0在年诞生，增加了一下几个方面：
之前只有Get方法，现在增加Post(加参数)，Head方法加入协议版本号，同时添加文件处理类型加入HTTPHeader，让HTTP处理请求更加灵活增加响应状态码，标记出错的原因提供国际化(不同语言)支持典型的请求过程：
GET/image.htmlHTTP/1.0User-Agent:Mozilla/5.0(WindowsNT6.1;WOW64)OKDate:Tue,17Nov209:15:31GMTContent-Type:text/htmlHTML一个包含图片的页面IMGSRC=/image.gif/HTML
HTTP1.0通信过程
HTTP1.0
3、HTTP/1.1
年是不平凡的一年，网景公司和微软开启浏览器大战，谁都想当老大。年HTTP/1.1发布并成为标准，写入RFC，以为以后不管是网关还是APP等，只要你要使用HTTP，就得遵守这个标准。
继续增加了PUT等方法允许持久连接随着文件越来越大，图片等信息越来越复杂，如果每一次上传下载文件都需要建立连接断开连接的过程将增加大量的开销。为此，提出了持久连接，也就是一次TCP连接可以具有多个HTTP请求。当然持久连接是可选择的，如果考虑关闭，只需要使用Connecttion:close关闭即可。长连接如下图所示：
长连接
强制要求Host头
我们知道，在电商系统中，经常会因为促销活动导致流量飙升，为了缓解流量，其中有种方法即加缓存或者加服务器。如果是单台服务器负载过大，数据库可能分库分表。数据结构算法中分而治之方法亦是如此。那么HTTP中，同样的道理，如果文件太大，就大文件切分为小文件块发送。
4、HTTP/2
HTTP/1.1的出现，几年间出来大量牛掰的互联网公司，发展实在是太快，但是HTTP1.1中这几点成为诟病：
原因1TCP自带慢启动顾名思义，慢启动从0到1循循渐进。轿车启动不会按下按钮就直接起飞，而是缓慢调节到适合的速度。这不是挺好的？为什么会带来性能问题呢。我们知道一个页面有静态数据，动态页面，很多小文件在加载的过程中就会直接发起请求，这样导致太多的请求都会经历慢启动过程，花费时间太多。
原因2多条TCP连接带宽竞争带宽固定，多条TCP连接同时发起竞争带宽资源，由于各个TCP连接之间没有通信机制，也无法得知哪些资源优先级更高，从而导致想快速下载的资源反而延迟下载。
原因3头部阻塞阻塞，在网络编程中，我们采用异步，多路复用(Epoll)方式尽量让CPU少等待多干事。在HTTP1.1中，虽然大家共用了一条TCP通道，但是第一个请求没有结束，第二请求就可能阻塞等待，也就是说不能同时发送接收数据。那么一个网页很多数据文件，如果能够同时发出请求，让部分数据文件能够得到响应并预处理，这样就大大的利用了带宽和CPU的资源。基于这些因素，在HTTP2中出现了新的方案
如何解决头部阻塞呢？
HTTP是一问一答的模式，大家都在这个队列排队导致堵塞，那就多个队列并发进行，也就是对同一个域名发起多个长连接。举个例子，在火车站排队买票的时候，如果只有一个窗口可用，大家只能苦等，多开几个窗口就可缓解这个问题。
这个时候用户数*并发数(上限6-8)已经不错得效果，但是互联网速度太快，火车站就这么大，窗口也就这么多，怎么办，建新的火车站进行分流(大部分城市都有什么东站西站)。在这里叫做域名分片，使用多个域名，这些域名指向同一服务器。
5、HTTP/3
HTTP/2看似很完美了吧，但是Google轮子哥可不服，其他人在研究HTTP/2的时候，它们就在琢磨QUIC。那QUIC有啥牛掰的地方呢？
QUIC是Google开发的一个基于UDP且能像TCP一样具有可靠性特点的协议。具备像HTTP/2一样的应用数据二进制分帧传输。其主要解决的问题有两个。
进一步解决线头阻塞问题。通过独立不同流，让各个流之间实现相互独立传输，互不干扰切换网络时的连接保持。Wi-Fi和3G/4G经常需要来回切换。基于TCP的协议，会因为网络的切换导致IP地址的改变。而基于UDP的QUIC协议，及时切换也可以恢复之前与服务器的连接。(这里推荐大家可以去看看MPTCP)
HTTP报文详解
客户端与服务端进行交互的信息为报文。客户端为请求报文，服务端为响应报文。我们先用Wireshark抓一个博客看看。
报文层次结构
GET/article/12HTTP/1.1Host: