这里先贴上几位大佬的笔记，我觉得我自己记得笔记肯定没有他们写的好
这个连接写的少点，但关于http走私漏洞的理解已经够了
这个笔记真的是面面俱到，妥妥的大佬
当前的互联网环境
在当前，很多网站为了防止服务器压力太大，往往会设置一个代理服务器，一些静态网页，就直接由代理服务器响应
这么说可能不太好理解，通俗点说就是，如果我们发送请求，每次都往一个服务器发送，然后服务器处理数据，这样一来后服务器压力就太大了。所以服务商就采用了一个代理服务器，我们每次发送请求全都是发给代理服务器，一些简单的请求，代理服务器能够处理，就直接响应了，只有遇到一些需要连接数据库，或者涉及到其他动态页面等操作时，代理服务器没能力解决，就由代理服务器转发给主服务器
这种采用代理服务器的方式在互联网可以说是很普遍了
http基础知识
讲http走私前，先介绍一些相关的名词概念，可能文字篇幅很多，但是都是基础知识必须得深入理解
长连接
正常来说，用户和服务器连接完成TCP连接都需要完成三次握手这个过程，用户只发送一两次请求就不再请求资源了，而当前端服务器向后端服务器转发请求时，前端服务器的身份就变成了用户了，由于只有前端服务器这一个用户，而且前端服务器需要源源不断地转发请求，三次握手这个过程就显得特别多余了，所以就产生了长连接这种方式
长连接就是前端服务器和后端服务器一直保持连接，这样的好处就是，前端服务器只需要一次三次握手就可以一直转发请求，而当后端服务器发现前端服务器有一段时间没有发送请求时，默认为处于空闲期，也就断开连接，减少了服务器的压力，等前端服务器又有转发请求时再重新建立，
Content-length（实体长度）
这个没啥好讲的，请求中数据的长度，大家应该都知道
例如
POST /HTTP/1.1
HOST:127.0.0.1
Content-Length:6
123456
这里面123456就是他传输地数据
Transfer-Encoding: chunked（分块编码）
好了到重点了，如果说Content-length特别特别长怎么办，在http采用了chunked这种方式，也叫分块编码
如果在请求头中加入了Transfer-Encoding: chunked，则代表这个请求采用的时分块编码技术，里面的数据会通过一块一块地传输到服务器，服务器也不会断开连接，直到遇到0时连接结束
POST /HTTP/1.1
HOST:127.0.0.1
Transfer-Encoding:chunked
6
PREFIX
4
ABCD
0
这就是一个通过分块编码传输的请求，这里面6代表长度，后面紧跟的是他的数据，直到遇到0就断开连接了
漏洞原理
再回到当今的互联网环境，由于普遍存在服务商采用代理服务器和后端服务器的方式管理，当代理服务器和后端服务器面对一个http请求时理解不同，就会产生问题(像这种由于两个不同的服务器或是组件对一段内容理解不同从而产生漏洞的现象在web上特别常见)
实例
CL-CL
假如一个http请求中含有两个CL(Content-length)或者是两个TE(Transfer-Encoding: chunked),按照规定本来是应该返回400错误的，但总有一些服务器不按照规定，CL-CL方式的http走私的基础是建立在代理服务器和后端服务器都不遵守该规定的情况(因为双重CL技术在现实中也有应用，但应用特别少)
POST /HTTP/1.1
Host:127.0.0.1
Content-Length:6
Content-Length:5
12345G
上面是一个http请求报文，假设代理服务器和后端服务器都允许两个CL的存在，且前端代理服务器识别第一个CL，而后端代理识别第二个CL，那么就会导致代理服务器识别的是
POST /HTTP/1.1
Host:127.0.0.1
Content-Length:6
//Content-Length:5
12345G
被注释内容没被识别，于是就将这个请求转发给了后端服务器，而后端服务器识别的是
POST /HTTP/1.1
Host:127.0.0.1
//Content-Length:6
Content-Length:5
12345//G
大家可以看到，后端服务器识别时，在数据块只识别5个长度，这个G就没被识别上留在了缓存区，那个这个G也就被走私了，这个漏洞也就是http走私
那么这个G去哪里了呢，他会留在服务器的缓存区，等待下一个请求到来，再二者拼接，假如下一个另一个A用户提交的GET请求，那么本来正常的请求就会变成
GGET /HTTP1.1
HOST:126.0.3.1
此时A用户一定会受到一个没找到GGET请求方式的一个报错
这也就影响到了其他用户体验，但这仅仅是危害之一，也可以通过http走私的方式来攻击服务器，这得在后面在介绍，先介绍完这几种http走私的方式
CL-TE
实际上，由于CL-CL技术用的不多,再加上RFC7230协议规定不允许出现两个CL，所以互联网上绝大数的服务器遇到两个CL都会直接返回400错误
但是RFC 2616规范中说，如果遇到的消息中带一个TE和一个CL，后者必须被忽略，从这点可以看出，规范是允许一个消息同时携带CL和TE头的，所以CL-TE的走私方式就出现了，只要我们将TE隐藏，也就是代理服务器识别不出来这是TE，但是后端服务器识别出来了，就把CL给忽略了，这通常是服务器不同而产生的差异
下面是几种隐藏方式
在实际讲解中我就不使用隐藏TE的方式了
现在假如代理不支持分块编码的方式，而后端服务器是支持的
POST /HTTP/1.1
Host:127.0.0.1
Content-Length:6
Transfer-Encoding: chunked
0
G
这样代理识别时就把整个转发了(一个换行符算2个字节，并且从请求头到请求体中间的会有一个换行符，该换行符不算在CL中)
而在后端服务器就很显然地将G走私了
由于我没有隐藏，所以该报文只适用于代理不支持而后端分块编码的服务器，假如代理和后端都支持，只需要找代理不能够识别而后端能够识别的隐藏方式就可以了，也就是这一小节刚开始的那张图(其他走私方式同理)
TE-CL
有了前面的铺垫，再讲后面就容易很多了。
TE-CL方式，也就是代理支持分块编码技术，而服务器不支持
POST /HTTP/1.1
Host:127.0.0.1
Content-Length:3
Transfer-Encoding: chunked
1
x
0
对于代理服务器而言，他认为数据是x，1是它的长度，0则是结束，符合服务器的规则，于是就转发请求了
而到了后端服务器这里，由于不支持分块编码技术，TE它无法识别，于是他认为数据是1/n/r(/n/r是回车的意思)，那么x就被走私了，下一个A用户一定会收到类似于无法识别x0GET的一个报错
这是后端服务器所识别的
POST /HTTP/1.1
Host:127.0.0.1
Content-Length:3
Transfer-Encoding: chunked
1
//x
//0
TE-TE
关于TE-TE这种走私方式就只能靠隐藏TE头来解决了，主要是利用两边的服务器识别不同，一个能识别隐藏TE头，而另一个不能。这里就不多演示了，原理一模一样
攻击实例
关于攻击实例篇幅也挺长的，都有空我再写一篇，再把连接贴在这里，主要也是写这么多懒得写了
如何防御
- 禁用代理服务器与后端服务器之间的TCP连接重用（长连接）。
- 使用HTTP/2协议。
- 前后端使用相同的服务器。
防御方法基本都这三种，但是就实在性来讲，第一点和第二点实现基本不现实，如果禁止前后端服务器的长链接的话，会极大程度的增加后端服务器的压力，浪费后端服务器的资源，而使用HTTP/2在现在的网络条件下根本无法推广使用，哪怕支持HTTP/2协议的服务器也会兼容HTTP/1.1。
前后端使用相同的服务器，就已经能够解决绝大多数的http走私了，因为从本质是，之所以能走私，根本原因还是前后端关于同一请求内容的理解不一样
学习心得
这篇文章真的是写了很多，还有攻击实例没有写，而且总体来说，文字篇幅确实是非常多，但是没办法，基础内容实在是太多了，不过学的东西也真的是不少。其他大佬都是用BP的环境来学习，而我只能通过代码片面地学习，学习还需要努力啊。