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设置时,也支持持续会话这一功能。服务器和浏览器端都可以限定每个连接同时支持的最大请求数,并可限定空闲连接的最大等待时间。 🤙🚠🥣⁉🐡 WEB安全第五课第五节:
帖子热度 1.2万 ℃
|
|
这是一个神奇的年代 小学生自称神和魔 初中生自称宫和朕 高中生自称哥爷爸 大学生自称宝宝#y450:
|
远古时期并无人类,女娲娘娘补天后,用剩下的两块神泥各捏了一个小人,两人一开始并无区别,都是一头四肢,一身一乳,唤名男,女。
只是后来两人不知为何大打出手,女人强悍,把男人的那一乳撕下,据为己有置于胸前,男人几次想抢回,均未成功,于是告到女娲娘娘那里,娘娘见女人这样甚是好看,便没有给她取下,而是在女人两腿之间,不起眼处取泥一小块,搓成圆形送给男人,用以安抚。男人甚喜,如获至宝藏于身下。每每拿出把玩,均感身心愉悦,所以到了今日男人还乐此不疲。 👏🛑🥛🆗🐻女人无时不想把它夺回,所以伤口至今没有愈合,每月均由血流出,但碍于女娲娘娘,不敢造次。多年后想出一法,找男人商量,允许男人抚摸他以前失去的那一乳(男人在抚摸时,实际上比较偏爱一个,因为那个以前就是他的),条件是也要把她原来的东西暂时放回原处,想用体液将其融化,已达到索回的目的,男人不知是计欣然同意,于是交合后两人均感到极大满足。 有了第一次,就有第二次,第三次,每次后都有一小部分被留在女人体内,但多年已过,那已被男人彻底融合,留在体内的自己却融合不了了,经十月孕育还是融合不了,但成了独立的一个生命体,不得不排出。就这样人类开始繁衍生息。。。。。 。。。我是来混熟脸的#y398:#y398: |