万字长文拿下HTTP

时间 2020-06-22

标签万字长文拿下 http 栏目 HTTP/TCP 繁體版

原文原文链接

本文将从如下几个方面进行分享。其中包括HTTP发展史，HTTP缓存代理机制，经常使用的web攻击，HTTP和HTTPS的流量识别，网络协议学习的工具推荐以及高频HTTP与HTTPS的高频面试题题解等，开工。html

提纲python

1989年，蒂姆·伯纳斯 - 李（Tim Berners-Lee）在论文中提出能够在互联网上构建超连接文档，并提出了三点.nginx

URI：统一资源标识符。互联网的惟一IDweb

HTML：超文本文档面试

HTTP:传输超文本的文本传输协议redis

1 HTTP应用在哪儿

学习一门知识，采用五分钟时间看看这个知识是干啥的可能会更加有目的性。HTTP可谓无处不在，这里例举出几个。算法

HTTP应用场景docker

2 HTTP是什么

HTTP(hypertext transport protocol)翻译过来为"超文本传输协议"，文本能够理解为简单的字符文字组合，也能够理解为更为复杂的音频或者图像等。那么将这个词语拆分为三个部分。数据库

超文本传输协议编程

"超文本"和"文本"相比多了一个字"超"，这样看来比文本丰富，由于它能够将多种文本/图像等进行混合，更重要的是能够从一个文本跳转到另外一个文本(文本链接)。

"传输"，传输的过程当中须要沟通，沟通便可能一对一沟通也可能一对多沟通(进行内容协商)，不管怎么样，参加沟通的人数>1，想尽一切一切办法更快更好的完成相应的任务。

"协议"，无规矩不成方圆，作机密项目以前须要签署保密协议，找工做要签"三方协议"，三方协议是学校，公司，和我的组成的协议，都是为了让你们受必定的约束，违反了即有相应的惩罚。

三方协议

3 不一样版本的HTTP

HTTP/0.9

当时网络资源匮乏，0.9版本相对简单，采用纯文本格式，且设置为只读，因此当时只能使用"Get"的方式从服务器获的HTML文档，响应之后则关闭。以下图所示

GET /Mysite.html

响应中只包含了文档自己。响应内容无响应头，无错误码，无状态码，能够说是"裸奔"。

<HTML>
Hello world
</HTML>
HTTP/1.0

此时HTTP/0.9请求过程以下

应用层的HTTP创建在传输层的TCP之上并运用TCP可靠性等特性，先三次握手创建链接
客户端请求创建链接(此时只有GET)
服务端响应请求，数据以 ASCII 字符流返回给客戶端
传输完成，断开链接。

HTTP 0.9

HTTP1.0

随着时代的进步，仅仅文本的传输没法知足需求，更多状况须要采用图文的方式才能生动的表达出本身的观点。随着1995年开发出Apache，同时其它的多媒体等技术发展迅速，从而进一步的促使HTTP新功能的出现。HTTP1.0在1996年诞生，增长了一下几个方面：

以前只有Get方法，如今增长Post(加参数)，Head方法
加入协议版本号，同时添加文件处理类型
加入HTTP Header，让HTTP处理请求更加灵活
增长响应状态码，标记出错的缘由
提供国际化(不一样语言)支持

典型的请求过程

GET /image.html HTTP/1.0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64)

200 OK
Date: Tue, 17 Nov 2020 09:15:31 GMT
Content-Type: text/html
<HTML> 
一个包含图片的页面
  <IMG SRC="/image.gif">
</HTML>

HTTP1.0通讯过程

HTTP1.0

HTTP /1.1

1995年是不平凡的一年，网景公司和微软开启浏览器大战，谁都想当老大。1999年HTTP/1.1发布并成为标准，写入RFC，觉得之后无论是网关仍是APP等，只要你要使用HTTP，就得遵照这个标准。

继续增长了PUT等方法
容许持久链接

随着文件愈来愈大，图片等信息愈来愈复杂，若是每一次上传下载文件都须要创建链接断开链接的过程将增长大量的开销。为此，提出了持久链接，也就是一次TCP链接能够具备多个HTTP请求。固然持久链接是可选择的，若是考虑关闭，只须要使用Connecttion:close关闭便可。长链接以下图所示

长链接

强制要求Host头

咱们知道，在电商系统中，常常会由于促销活动致使流量飙升，为了缓解流量，其中有种方法即加缓存或者加服务器。若是是单台服务器负载过大，数据库可能分库分表。数据结构算法中分而治之方法亦是如此。那么HTTP中，一样的道理，若是文件太大，就大文件切分为小文件块发送。

HTTP /2

HTTP/1.1的出现，几年间出来大量牛掰的互联网公司，发展实在是太快，可是HTTP1.1中这几点成为诟病

缘由1 TCP自带慢启动

顾名思义，"慢启动"从0到1循循渐进。轿车启动不会按下按钮就直接起飞，而是缓慢调节到适合的速度。这不是挺好的？为何会带来性能问题呢。咱们知道一个页面有静态数据，动态页面，不少小文件在加载的过程当中就会直接发起请求，这样致使太多的请求都会经历慢启动过程，花费时间太多。

缘由2 多条TCP链接带宽竞争

带宽固定，多条TCP链接同时发起竞争带宽资源，因为各个TCP链接之间没有通讯机制，也没法得知哪些资源优先级更高，从而致使想快速下载的资源反而延迟下载。

缘由3 头部阻塞

阻塞，在网络编程中，咱们采用异步，多路复用(epoll)方式尽可能让cpu少等待多干事。在HTTP1.1中，虽然你们共用了一条TCP通道，可是第一个请求没有结束，第二请求就可能阻塞等待，也就是说不能同时发送接收数据。那么一个网页不少数据文件，若是可以同时发出请求，让部分数据文件可以获得响应并预处理，这样就大大的利用了带宽和cpu的资源。基于这些因素，在HTTP2中出现了新的方案

如何解决头部阻塞呢？

HTTP是一问一答的模式，你们都在这个队列排队致使堵塞，那就多个队列并发进行，也就是"对同一个域名发起多个长链接"。举个例子，在火车站排队买票的时候，若是只有一个窗口可用，你们只能苦等，多开几个窗口就可缓解这个问题。

这个时候用户数 * 并发数(上限6-8)已经不错得效果，可是互联网速度太快，火车站就这么大，窗口也就这么多，怎么办，建新的火车站进行分流(大部分城市都有什么东站西站)。在这里叫作"域名分片"，使用多个域名，这些域名指向同一服务器。

HTTP/3

HTTP/2看似很完美了吧，可是Google轮子哥可不服，其余人在研究HTTP/2的时候，它们就在琢磨QUIC。那QUIC有啥牛掰的地方呢

QUIC是Google开发的一个基于UDP且能像TCP同样具备可靠性特色的协议。具有像HTTP/2同样的应用数据二进制分帧传输。其主要解决的问题有两个。

进一步解决线头阻塞问题。经过独立不一样流，让各个流之间实现相互独立传输，互不干扰
切换网络时的链接保持。wifi和3G/4G常常须要来回切换。基于TCP的协议，会由于网络的切换致使IP地址的改变。而基于UDP的QUIC协议，及时切换也能够恢复以前与服务器的链接。(这里推荐你们能够去看看MPTCP)

4 HTTP报文详解

客户端与服务端进行交互的信息为报文。客户端为请求报文，服务端为响应报文。咱们先用wireshark抓一个博客看看

报文层次结构

GET /article/12 HTTP/1.1
Host: www.xxx.cn
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: SESSION=so9nlsvenminor5abs65sh9dsa

HTTP/1.1 200 OK
Server: nginx
Date: Sun, 17 May 2020 17:04:29 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: blade-2.0.6-BETA
Content-Encoding: gzip

请求报文

请求报文一般由三部分组成：

起始行：描述请求或者响应的基本信息

头部字段集合：key-value形式说明报文

消息正文：实际传输诸如图片等信息。具体以下图试试

1 请求方法：一共有八种方法选择，以下图所示。采用不一样的方法获取不一样的资源

HTTP请求方法详解

说一下很是常见的几种请求方法

Get：从服务器中取资源。能够请求图片，视频等

HEAD:和Get相似，可是从服务器请求的资源不会反悔请求的实体数据，只会反悔响应头

POST/PUT：对应于GET，向服务器发送数据

2 URI

统一资源标识符(Uniform Resource Identifier),严格来讲不等于网址，它包含URL和URN，但是URL太出名了以至于URL="网址"。不管开发，测试运维配置都离不开URI,因此好好掌握。

网络层的IP主要目的是解决路由和寻址。如今的IP地址按照"."分割，总共2的32次方大约42亿。对于计算机来讲比较方便，可是对于人类来讲仍是不容易记忆，此时出现DNS了，他把IP地址映射为咱们平时常见的"redis.org"，按照"."分割域名，从左到右级别越高，最右边为"顶级域名"。以下图所示

域名体系

好了，如今TCP提供可靠(数据不丢失)且字节流(数据完整性)，并且也有方便咱们记忆的域名，可是互联网资源千万种，也不知道访问什么(图片，文字，视频一大堆)，这个时候URI(统一资源标识符)出现了，那长啥样？

URI格式

协议名:HTTP协议，另外还有ftp等协议。告知访问资源时使用什么协议。

紧接着是分隔符:"://"

主机名：标记互联网主机，能够是IP也能够是域名，若是不写端口则使用默认端口，例如HTTP为80，HTTPS为443.

登陆认证信息：登陆主机时的用户名密码(不建议，直接告诉了别人你的隐私信息)

主机名：此处能够是域名也能够是IP，若是不写端口号则是默认端口。好比HTTP默认端口为80，HTTPS默认端口为443

资源所在位置：资源在主机上的位置，使用“/”分隔多级目录，在这里是“/en/download.html”。注意，必须"/"开头

参数：用"?"开始，表示额外的请求要求。一般使用"key=value"的方式存在，若是多个"key=value"则使用"&"相连。

看几个例子

http://nginx.org/en/download.html

file:///E:/Demo/index/

这里注意是三个"///"，由于前面"://"做为分隔符，资源路径按照"/"开头。

既然规则这么多，对于接收方而言须要完成的解析也须要遵照规则，全球用户不少使用HTTP，每一个国家地区所使用语言不一样，HTTP为了能对其进行统一处理，引入了URI编码，方法比较简单，将非ASCII或者特殊字符所有转换为十六进制字节值，同时在前面加入"%"。好比空格被转换为"%20","中国"就编码为"%E4%B8%AD%E5%9B%BD%0A"。

3 请求体

响应报文

状态行----服务器响应的状态

<1> 版本号：使用的HTTP什么版本

<2> 状态码：不一样数字表明不一样的结果，就如咱们在编码时，经过返回不一样的值表明不一样的语义。

状态码一共分为5类。

1××：处于中间状态，还需后续操做

2××：成功收到报文并正确处理

"200 OK"

最多见的成功状态码，表示一切正常，客户端得到期许的处理结果。若是不是Head请求，那么在响应头中一般会有body数据。

"204 No Content"

这个的含义和"200"很类似，不一样之处在于它的响应头中没有body数据。

"206 Partial Content"

是 HTTP 分块下载或断点续传的基础，在客户端发送“范围请求”、要求获取资源的部分数据时出现，它与 200 同样，也是服务器成功处理了请求，但 body 里的数据不是资源的所有，而是其中的一部分。状态码 206 一般还会伴随着头字段“Content-Range”，表示响应报文里 body 数据的具体范围，供客户端确认，例如“Content-Range: bytes 0-99/5000”，意思是这次获取的是总计 5000 个字节的前 100 个字节。

3××：重定向到其余资源位置

"301 Moved Permanently"

“永久重定向”，意思是本地请求的资源以及不存在，使用新的URI再次访问。

“302 Found”

“Moved Temporarily”，“临时重定向”，临时则所请求的资源暂时还在，可是目前须要用另外一个URI访问。

301 和 302 经过在字段Location中代表须要跳转的URI。二者最大的不一样在于一个是临时改变，一个是永久改变。举个例子，有时候须要将网站所有升级为HTTPS，这种永久性改变就须要配置永久的"301"。有时候晚上更新系统，系统暂时不可用，能够配置"302"临时访问，此时不会作缓存优化，次日还会访问原来的地址。

“304 Not Modified”

运用于缓存控制。它用于 If-Modified-Since 等条件请求，表示资源未修改，能够理解成“重定向已到缓存的文件”（即“缓存重定向”）。

4××：请求报文有误，服务器没法处理

"400 Bad Request”

通用错误码，表示请求报文有错误，可是这个错误过于笼统。不知道是客户端仍是哪里的错误，因此在实际应用中，一般会返回含有明确含义的状态码。

“403 Forbidden”

注意了，这一个是表示服务器禁止访问资源。缘由好比涉及到敏感词汇、法律禁止等。固然，若是能让客户端有一个清晰的认识，能够考虑说明拒绝的缘由并返回便可。

“404 Not Found”

这多是咱们都知道且都不想看到的状态码之一，它的本意是想要的资源在本地未找到从而没法提供给服务端，可是如今，只要服务器"耍脾气"就会给你返回 404，而咱们也无从得知后面究竟是真的未找到，仍是有什么别的缘由，

"405 Method Not Allowed"

获取资源的方法好几种，咱们能够对某些方法进行限制。例如不容许 POST 只能 GET；

"406 Not Acceptable"

客户端资源没法知足客户端请求的条件，例如请求须要中文但只有英文；

"408 Request Timeout"

请求超时，服务器等待了过长的时间；

"409 Conflict"：

多个请求发生了冲突，能够理解为多线程并发时的竞态；

413 Request Entity Too Large：

请求报文里的 body 太大；

414 Request-URI Too Long：请求行里的 URI 太大；

429 Too Many Requests：客户端发送了太多的请求，一般是因为服务器的限连策略；

431 Request Header Fields Too Large：请求头某个字段或整体太大；

5××：服务器错误，服务器对请求出的时候发生内部错误。

“500 Internal Server Error”

和400 相似，属于一个通用的错误码，可是服务器究竟是什么错误咱们不得而知。其实这是好事，尽可能少的将服务器资源暴露外网，尽可能保证服务器的安全。

“502 Bad Gateway”

一般是服务器做为网关或者代理时返回的错误码，表示服务器自身工做正常，访问后端服务器时发生了错误，但具体的错误缘由也是不知道的。

“503 Service Unavailable”

表示服务器当前很忙，暂时没法响应服务，咱们上网时有时候遇到的“网络服务正忙，请稍后重试”的提示信息就是状态码 503。

503 是一个“临时”的状态，

暂时比较忙，稍后提供服务。在响应报文中的“Retry-After”字段，指示客户端能够在多久之后再次尝试发送请求。

4 请求体

上面大部分都是涉及到header部分，还有很是重要的body，everybody

头字段注意事项

<1> 字段名不区分大小写，例如“Host”也能够写成“host”，但首字母大写的可读性更好；

<2> 字段名里不容许出现空格，可使用连字符“-”，但不能使用下划线"_"。例如，“test-name”是合法的字段名，而“test name”“test_name”是不正确的字段名；

<3> 字段名后面必须紧接着“:”，不能有空格，而":"后的字段以前能够有多个空格；

<4> 字段的顺序是没有意义的，能够任意排列不影响语义；

<5> 字段原则上不能重复，除非这个字段自己的语义容许，例如 Set-Cookie。

HTTP的body经常被分为这几种的类别

<1> text:超文本text/html,纯文本text/plain

<2> audio/video:音视频数据

<3> application: 多是文本，也多是二进制，交给上层应用处理

<4> image: 图像文件。image/png等

可是带宽必定，数据大了一般考虑使用压缩算法进行压缩，在HTTP中使用Encoding type表示，经常使用的压缩方式有下面几种

<1> gzip:

一种数据格式，默认且目前仅使用deflate算法压缩data部分

<2> deflate:

deflate是一种压缩算法，是huffman编码的一种增强

<3> br:

br经过变种的LZ77算法、Huffman编码以及二阶文本建模等方式进行数据压缩，其余压缩算法相比，它有着更高的压塑压缩效率

使用相应的压缩方法在带宽必定的状况下确实有不错的效果，可是gzip等主要针对文件压缩效果不错，可是对视频就不行了。这个时候是否是可使用数据结构中经常使用的分而治之，大化小再合并的方式呢，

文件拆分

ok，在报文中使用"Transer-Encoding:chunked"表示，表明body部分数据是分块传输的。另外在body中存在一个content-length字段表示body的长度，二者不能共存，另外不少时候是流式数据，body中没有指明content-length，这个时候通常就是chunked传输了。

如今能够经过采用分块的方式加强带宽的利用率，那他的编码规则如何呢

<1> 每个分块包含长度和数据块

<2> 长度头按照CRLF结束

<3> 数据块在长度快后，且最后CRLF结尾

<4> 使用长度0表示结束，"0\r\n\r\n"

咱们仍是看图加深印象

chunked分块

分块解决了咋们一部分问题，可是有的时候咱们想截断发送怎么办呢。在HTTP中提供了使用字段“Accept - Ranges: bytes”，明确告知客户端：“我是支持范围请求的”。那么Range范围是怎样的呢，Range从0开始计算，好比Range:0-5则读取前6个字节，服务器收到了这个请求，将如何回应呢

<1> 合法性检查。好比一共只有20字节，可是请求range：100-200。此时会返回416----"范围请求有误"

<2> 范围正常，则返回216，表示请求数据知识一部分

<3> 服务器端在相应投资端增长Content-Range,格式"bytes x-y/length"。

敲黑板：断点续传怎么操做？

<1> 查看服务器是否支持范围请求并记录文件大小

<2> 多个线程分别负责不一样的range

<3> 下载同时记录进度，即便由于网络等缘由中断也没事，Range请求剩余便可

如今咱们经过MIME-TYPE和Encoding-type能够知道body部分的类型，下一步将是对内容进行协商。HTTP中，请求体中使用Accept告诉服务端须要什么类型数据(我能处理哪些类型数据)，响应头中使用Content代表发送了什么类型数据，具体以下图所示

好了，为了各个国家民族顺利友好的沟通和明确的区分。HTTP请求头中使用"type-subtype"，注意此时分隔符是"-"。好比en-GB表示英式英语，zh-CN表示经常使用的汉语，那对于客户端而言，它经过Accept-Language来标记本身能够理解的天然语言，对应的服务端使用Content-Language代表实体数据使用的语言类型，以下图所示。

字符集和编码

Cookie机制

HTTP是无状态、无记忆的，Cookie机制的出现让其有记忆功能，是怎么个实现呢

从上图咱们能够知道Cookie是由浏览器负责存储，并非操做系统负责，咱们换个浏览器打开一样的网页，服务就认不出来了。

Cookie常见的应用一个是身份识别，一个是广告追踪，好比咱们在访问网页视频或者图片的时候，广告商会悄悄给咱们Cookie打上标记，方便作关联分析和行为分析，从而给我推荐一些相关内容。

HTTP代理

以前介绍的都是一问一答的情景，可是在大部分的状况下都会存在多台服务器进行通讯服务。其中比较常见的就是在请求方与应答方中间增长一个中间代理。

代理

代理做为中间位置，相对请求方为服务端，至关于后端服务端为请求方。代理常见的功能为负载均衡。在负载均衡中须要区分正向代理与反向代理，其中也就会涉及调度算法，好比轮询，一致性哈希等。

正向代理与反向代理

那么问题来了，代理做为隐藏身份，至关于隐藏了真实的客户端与服务端，那在是否是

5 HTTPS

好人占多数，坏人也很多。总有些要搞坏事，由于HTTP是明文，因此须要想办法保护明文，从而出现了https。

安全是什么

安全四要素

机密性

对信息进行保密，只能可信的人能够访问(让我想起时间管理者)。

完整性

数据在传输过程当中内容不被"篡改"。虽然机密性对数据进行保密了，可是有上策也有下策(hack)

身份认证

证实本身的身份是本人，保证其消息发给可信的人

不能否认

君子一言驷马难追，说话算数，说过的话作过的事要有所保证

HTTPS

HTTP和HTTPS

从上图咱们知道HTTPS无非是在传输层和应用层中间加了一层TLS，正是TLS紧跟当代密码学的步伐，尽全力的保障用户的安全。老规矩，咱们用wireshark看看长什么样子。

TLS

能够看出在交互的过程当中多了很多新东西，了解TLS,TLS由SSL握手协议，SSL修改密码规范协议，SSL警报协议，SSL记录协议组成。

TLS组成

SSL握手协议：

相对于三次握手

记录协议

记录为TLS发送接收数据的基本单位。它的自协议须要经过记录协议发出。若是多个纪录数据则能够一个TCP包一次性发出。

警报协议

相似HTTP状态码，经过反馈不一样的消息进行不一样的策略。

变动密码规范协议

告诉对方，今后刻开始，后续的数据将使用加密算法进行加密再传输。

对称加密与非对称加密

对称加密

对称加密，顾名思义，加密方与解密方使用同一钥匙(秘钥)。具体一些就是，发送方经过使用相应的加密算法和秘钥，对将要发送的信息进行加密；对于接收方而言，使用解密算法和相同的秘钥解锁信息，从而有能力阅读信息。

对称加密

非对称加密

在对称加密中，发送方与接收方使用相同的秘钥。那么在非对称加密中则是发送方与接收方使用的不一样的秘钥。其主要解决的问题是防止在秘钥协商的过程当中发生泄漏。好比在对称加密中，小蓝将须要发送的消息加密，而后告诉你密码是123balala,ok,对于其余人而言，很容易就能劫持到密码是123balala。那么在非对称的状况下，小蓝告诉全部人密码是123balala,对于中间人而言，拿到也没用，由于没有私钥。因此，非对称密钥其实主要解决了密钥分发的难题。以下图

非对称加密

其实咱们常常都在使用非对称加密，好比使用多台服务器搭建大数据平台hadoop，为了方便多台机器设置免密登陆，是否是就会涉及到秘钥分发。再好比搭建docker集群也会使用相关非对称加密算法。

混合加密

非对称加密算法，大多数是从数学问题演变而来，运算速度较慢。混合加密所谓取长补短。通讯过程当中使用RSA等解决密钥交换问题，而后使用随机数产生的在对称算法中的会话密钥，最后使用加密。对方使用私钥解密获得的密文取出会话秘钥，这样就实现了密钥交换。

混合加密

经过混淆加密等方式完成了机密性任务，做为Hack只须要伪造发布公钥或者做为之间人窃听密文。可是咱们知道安全是四要素，还须要保证数据的完整性，身份认证等。

摘要

摘要算法能够理解为一种特殊的"单向"加密算法，无密钥，不可逆。在平时项目中，应该你们都是用过MD5，SHA-1。可是在TLS中使用SHA-2。

假设小A转帐5000给小C，小A加上SHA-2摘要。网站计算摘要并对比，若是一致则完整可信。

摘要可信

此时小B想修改小A给的money，这个时候网站计算摘要就会发现不同，不可信

摘要不可信

HTTPS请求创建链接过程

HTTP握手过程

注意：

首先经过非对称加密创建通讯过程
在握手阶段，为何使用3个随机数，一方面防止「随机数 C」被猜出，另外一方增长Session key随机性
Client发出支持的「对称/非对称加密」算法
server返回选用的「对称/非对称加密」算法
Client对算法进行确认
Server对算法进行确认

根据wireshak结果，对TLS进一步剖析。TCP三次握手创建链接，做为礼貌，Client先打招呼"Client Hello"。里面包含了Client的版本号、所支持的密码套件和随机数，以下图所示

Client Hello

Server端表示尊重，回复"Server Hello",同时进行版本校对，给出随机数(Server Random)，从Client算法列表中选择一个密码套件，在这里选择的"
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"。

cipher Suite

这里的"
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"什么意思呢

密码套件选择椭圆曲线加RSA、AES、SHA256

双方经过证书验证身份。由于本机服务器选用了ECDHE算法，为了实现密钥交换算法，它会发送证书后把椭圆曲线的公钥（Server Params）连带"Server Key Exchange"消息发送出去。

Server Key Exchange

意思是，刚才混合加密套件比较复杂，给你个算法参数，好好记住，别弄丢了。

ServerHelloDone

随后服务端回复"hello done"告知打招呼完毕

打完招呼完毕后，客户端对证书进行核实。而后根据密码套件也生成椭圆曲线的公钥，用"Client Key Exchange"消息发给服务器

Client Key Exchange

此时客户端和服务端都有了密钥交换的两个参数(Client Params、ServerParams），而后经过 ECDHE 算法算出了一个新的值，叫“Pre-Master”

有了主密钥和会话密钥，客户端发送“Change Cipher Spec”和“Finished”消息，最后将全部消息加上摘要发送给服务器验证。

服务器一样发送“Change Cipher Spec”和“Finished”消息，握手结束，开始进行HTTP请求与响应

4 初探域名

咱们知道域名的出现让咱们更容易记忆，按照"."分割，越靠近右边级别越高。域名本质是一个名字空间系统，采用多级域名的方式区分不一样的国家，公司等，做为一种身份的标识。

根域名服务器（Root DNS Server）：管理顶级域名服务器，返回“com”“net”“cn”等顶级域名服务器的 IP 地址；

顶级域名服务器（Top-level DNS Server）：管理各自域名下的权威域名服务器，好比com 顶级域名服务器能够返回 apple.com 域名服务器的 IP 地址；

权威域名服务器（Authoritative DNS Server）：管理本身域名下主机的 IP 地址，好比apple.com 权威域名服务器能够返回 www.apple.com 的 IP 地址**

6 HTTP特色小结

写到这里，说它简单是假的，简单的东西一般更具备扩展的可能性。根据需求的变动，愈来愈复杂。

1：灵活且易扩展，他的头部字段不少都是可定制且可扩展

2：应用普遍。各个领域都有涉及。"跨平台，跨语言"

3：无状态。没有记忆功能，少功能即少占用资源。另外无状态更容易搭建集群，经过负载均衡将请求转发到任意一台服务器。缺点是没法支持须要连续步骤的"事务"操做。咱们知道TCP协议有11种状态，不一样状态表明通讯过程当中不一样的含义。一样操做系统中的进程也有执行，就绪，活动阻塞等多种状态。可是HTTP全程都是"懵逼"无状态。好比小华请求服务器获取视频X，服务器以为可行就发给小华。小华还想获取视频Y，这时服务器不会记录以前的状态，也就不知道这两个请求是不是同一个，因此小华还得告诉服务器本身的身份。

4：明文。优势是能让开发人员经过wireshark工具更直观的调试。缺点即裸奔互联网，没隐私可言。

5:可靠传输。HTTP为应用层协议，基于TCP/IP，而TCP为“可靠”传输协议，所以HTTP能在请求应答中"可靠"传输数据。

6：应用层协议。应用层协议不少，其中经常使用的邮件协议SMTP，上传下载文件ftp，默认端口22/23，SSH远程登陆(XSHELL)。这些应用层协议都太专注，而HTTP经过各类头部字段，实体数据的组合，并综合缓存代理等功能，不得不说是网络中的冠希哥。

7 HTTP识别(还原)

这里说的识别，经过代码层面(libpcap封装)实现HTTP的识别，也能进一步体现TCP/IP协议栈的分层特性。先看回忆一下IP头部格式。

IP头部

注意头部中的协议字段，若是此字段值为0x0600则为TCP分组。当知道了是TCP分组后，是否是能够经过TCP头部中端口(80)就能够判断为HTTP呢，不能的，不少状况都会使用动态端口的方式进行部署。此时能够经过HTTP中的关键字进行判断。若是为HTTP，再经过头部字段中的"Content-type"，charset等确认文本信息，编码方式，最后采用解码算法进行还原。

8 HTTPS(密文)识别

方法一也是比较直接的方法是直接经过抓包工具，插件配置便可。这里想给你们分享另外一种思路和在Linux持续捕包的方法。

数据集采集

使用python的dpkt库(pip install dpkt便可)，dpkt库方便对每一层协议进行拆解，同时也能进行流的拆分以及特征的提取。下面举一个经过无头浏览的方式自动化采集流量(ps若是须要较大规模的流量采集则能够考虑使用docker集群的方式)

Read_pcap

根据所提特征生成npz(其实是numpy提供的数组存储方式)
使用开源skearn库进行模型训练并识别预测，此处假设使用SVM(仅使用默认参数)

SVM

识别结果(参数进行适度调整定会更好的效果)

识别结果

9 HTTP面试题测试

但愿你们看完本文，下面的这些面试是否是能够秒杀了

Get和Post区别
HTTP与HTTPS区别
HTTP通讯过程
浏览器输入一个地址。到页面展现中间经历了哪些步骤？
cookies机制和session机制的区别：
HTTP请求报文与响应报文格式
一次完整的HTTP请求所经历的7个步骤
HTTP优化方案
不一样版本的HTTP区别
HTTP优势缺点
URI和URL的区别
如何判断是否为http
HTTP 1.1引入分块传输编码提供了如下几点好处
长链接与短链接的区别，以及应用场景
常见web攻击
站内跳转和外部重定向有何区别
HTTP的keep-alive是干什么的？
关于Http 2.0 你知道多少？
讲讲304缓存的原理
HTTP与RPC异同
从传输协议来讲

RPC既能够基于TCP也能够基于HTTP协议，可是HTTP一般都是基于HTTP

从性能消耗来讲

RPC能够基于thrift实现高效二进制传输。HTTP大部分经过json实现，不管从字节大小仍是序列化耗时都比t'hrift耗时

从负载均衡来讲

RPC基本上自带负载均衡策略，而HTTP须要配置Nginx实现。