WEB安全第五课 HTTP协议 之四 持续会话

        最开始的时候，HTTP会话都是单次完结的：每个TCP连接发一次请求，断开，再重复。这需要不断重复进行TCP三步握手的消耗（而且在传统Unix服务器设计模式中，就要为此新开一个进程），可想而知这种做法很快就变成了性能瓶颈，所以HTTP/1.1已经规范化了持续会话（keepalive session)的处理。
        
        现有的协议已经能让服务器知道客户端请求在何时结束（遇到空行的时候结束，如果有Content-Length请求头，则在收完Content-Length字节长度的数据后结束），但如果希望继续使用当前连接，客户端也需要知道返回的内容在什么时候结束；因为这时候连接的中断和响应的结束已经没有必然联系了。


🤟⛪🌰⚛🦚‎        因此，使用KeepAlive会话的时候，响应端也要包含一个Content-Length头域，由此判断还有多少数据会传过来。按照这个数值接收完数据之后，客户端就知道可以发送第二个请求和开始等待下一次响应了。
        
        尽管这个机制对性能是大有裨益，但它的设计也加重了HTTP请求和响应里出现拆分漏洞的可能。这对判断客户端和服务器之间是否同步，哪个响应对应哪个请求会产生一定的迷惑性。要说清楚这个问题，我们假设服务器认为自己在发送单个HTTP响应，结构如下：

        HTTP/1.1 200 OK[CR][LF]

👨‍🚒‌📠😳✋

        Set-Cookie:term=[CR]Content-Length:0[CR][CR]HTTP/1.1 200 OK[CR]Gotcha:Yup[CR][LF]
        Content-Length:17[CR][LF]
        [CR][LF]
        Actioncompleted.
        🧑‍🌾‍💎🪟😂🦴
        而另一方面，在客户端看来这可能是两个响应，并把第一个响应和距离现在最近的那个请求相关联起来，第二个响应则对应那个甚至还没有发出的请求(这个请求甚至可能是发往同一个ip但不同主机名的）：
        
        HTTP/1.1 200 OK
        Set-Cookie:term=
        Content-Length:0

👨‍⚕️‎🛍✒😆🦴

        
        HTTP/1.1 200 OK
        Gotcha:Yup
        Content-Length:17
        
✌🏝🍟®🐤‍        Actioncompleted.
        
        如果是HTTP代理服务器收到这个响应，就可能被错误地在全局缓存起来并返回给其他用户，那可真是个坏消息啊。更可靠的持续会话设计应该是同时给出头域部分和消息体部分的数据长度，或用一个随机产生不可预期的边界值作为每个响应之间的分隔符。但很遗憾的是，持续会话的设计里这两种方式都欠奉。
        
        在HTTP/1.1里持续会话是默认的连接方式，除非请求里明确要求不用这个功能（这种情况下请求头域Connection:close)，很多HTTP/1.0服务器在碰到请求头为Connection:keep-alive设置时，也支持持续会话这一功能。服务器和浏览器端都可以限定每个连接同时支持的最大请求数，并可限定空闲连接的最大等待时间。

👄🛑🍟🪰‍