http指南笔记

keepGoing77091
165 阅读11分钟

1.web结构组件

  • 代理 ：位于客户端与服务器之间的http中间实体
  • 缓存：http的仓库，使常用页面的副本可以保存在离客户端更近的地方
  • 网关：连接其他应用程序的特殊Web服务器
  • 隧道：对http通信报文进行盲转发的特殊代理
  • Agent代理：发自动http请求的半智能web客户端

2.报文组成

  • start line 起始行
  • header 首部
  • body 主体

3.TCP

TCP为HTTP提供一条可靠的比特传输管道。tcp会按需、无差错的承载http数据，tcp的数据是通过ip分组的小数据块发送

http要发送一条报文时，会以流的形式将报文数据的内容通过一条打开的tcp链接按需传输。tcp收到数据流后，会将数据流砍成被称为段的小数据块，并将端分装在ip分组中，通过英特网进行传输。

在任意时刻计算机都可以有几条tcp链接处于打开状态。tcp是通过端口号来保持所有这些链接持续不断的运行。tcp链接通过4个值来识别：

<源ip地址、源端口号、目的ip地址、目的端口号>

  • tcp连接的握手延迟

    (B) -->[SYN]-->(S)

    (B) <--[SYN/ACK]<--(S)

    (B) -->[ACK]-->(S)

    SYN: 同步序列编号(Synchronize Sequence Numbers)

    ACK: 确认编号(Acknowledgement Number)

  • 延迟确认

  • tcp慢启动

  • Nagle算法与TCP_NODELAY

  • TIME_WAIT累积与端口耗尽

4.提高http的链接性能

  • 并行连接
  • 持久连接：重用tcp链接，以消除链接及关闭延时
  • 管道化链接: 通过共享的tcp链接发起并发的http请求
  • 交替的链接: 交替传送请求和响应报文(实验阶段)

4.1.Keep-Alive(1.0时代的产物，但任然使用广泛，默认关闭)

1.由于除去了进行连接和关闭连接的开销，所以时间有所缩减。

2.由于除去了慢启动阶段，请求和响应时间可能也有缩短。

http/1.0 keep-alive连接的客户端可以通过包含Connection: Keep-Alive首部请求将一条链接保持打开状态，

如果服务器愿意为下一条请求连接保持在打开状态，就在响应中包含相同的首部，客户端就认为服务器不支持keep-alive，会在发回响应报文之后关闭。

keep-alive首部只是请求将连接保持在活跃状态。客户端和服务端可以在任意时刻关闭空闲的keep-alive，并随意控制keep-alive的数量。

Connection: Keep-Alive

Keep-Alive: max = 5,timeout =120

Keep-alive首部完全可选，上面说明服务器最多还会为5个事物保持连接打开状态，将打开状态保持到连接空闲了2分钟后

4.2keep-alive和哑代理

中继(Relay): 2个交换中心之间的一条传输通路。网络通信交换机的trunk也可以称为中继。

盲中继(bind relay)：很多老的或者简单的代理都是盲中继。

4.3http/1.1持久连接(默认是激活的)

名为持久连接（persistent connection） 的改进型设计取代。

Http/1.1默认情况下是激活状态，要在事物处理结束之后将连接关闭，必须显示的添加一个Contention:close

的首部。但是客户端后服务端任然可以随时关闭空闲的连接。不发送Connection:close并不意味着服务器承诺永远将连接保持在打开状态。

4.4管道化连接

http/1.1允许在持久链接上可选地使用请求管道。相对于keep-alive连接的又一次性能优化。在响应到达之前，可以将多条请求放入队列。当第一条请求通过网络流向地球另外一端的服务器时，第二条和第三条请求也可以开始发送了。在高时延网络下，可以降低网络的环回时间，提高性能。

管道化链接的规则：

  • 如果http客户端无法确认链接是持久的，就不应该使用该管道
  • 必须按照与请求相同的顺序送回http响应。http标签中没有序号标签，因此如果收到的响应失序了，就无法将其与响应配对。
  • http客户端必须做好连接会在任意时刻关闭的准备，还要准备好重发所有未完成的管道化请求。
  • http客户端不应该用管道化的方式发送回产生副作用的请求(比如post请求。)总之，出错的时候，管道化方式会阻碍客户端了解服务器执行的已系列管道化请求中的哪一个，由于无法安全地重试post这样的非幂等请求，所以出错时，就存在某些方法无法永远无法被执行的风险。

http幂等方法：是指无论调用这个url多少次，都不会出现不同的结果的http方法。

4.5缓存

5.代理

1.Via首部：用于记录报文的转发，诊断报文循环，标识请求/响应链上所有发送者的协议能力。

Http/1.1的TRACE方法，用户可以跟踪经代理传输的请求报文，观察报文经过了哪些代理，以及每个代理是如何对请求报文进行修改的。

5.1 CGI

通用网关接口(Common Gateway Interface)

5.2 隧道

web隧道(Web tunnel), 这种方式可以通过http应用程序访问非http协议的应用程序。

web隧道允许用户通过http连接发送非http流量，这样就可以再http上捎带其他协议的数据了。使用web隧道最常见的原因就是要在http连接中嵌入非http流量，这样，这类流量就可以穿过只允许web流量通过的防火墙了。

web隧道就是用http的CONNECT方法建立的，CONNECT方法请求隧道网关创建一条任意目的服务器和端口的tcp连接，并对客户端的数据进行盲转发。

6.cookie

1.会话cookie：临时的，记录了用户访问站点是的设置和偏好，用户退出浏览器，会话cookie就会被删除。

2.持久cookie：储存在硬盘，浏览器退出时，计算机重启任然存在。

区别：过期时间。如果设置了Discard参数，或者没有设置Expires或者Max-Age参数俩说明拓展的过期时间，这个cookie就是一个会话cookie

7.认证

http定义了2个基本的认证协议：1.基本认证 2.摘要认证

7.1 基本认证

在基本认证中，web服务器可以拒绝一个事物，质询客户端，请用户提供有效的用户名和密码。服务器会返回401的状态码，并用WWW-Authenticate响应首部指定要访问的安全域。浏览器收到质询时，会打开一个对话框，请求用户输入这个域的用户名和密码。然后将用户名和密码稍加扰码(Base-64编码)，再用Authorization请求首部发送给服务器

7.2 摘要认证

改进

  • 永远不会以明文方式在网络上发送密码
  • 可以防止恶意用户捕获并重放认证的握手过程
  • 可以有选择地防止对报文内容的篡改
  • 防范其他几种常见的攻击方式

摘要认证并不是最安全的协议，与基于公有密钥的机制相比，摘要认证所提供的认证机制不够强。同样，摘要认证除了保护密码外，并没有提供保护其他内容的方式---请求和应答中的其余部分任然可能被窃听。

摘要认证遵循的箴言是"绝不通过网络发送密码"。而是发送密码的一个"指纹"或密码的"摘要"，这是密码的不可逆扰码。

1.单向摘要

摘要是"对信息主体的浓缩"。摘要是一种单向函数，主要用于将无限的输入值装换为有限的浓缩输出值。常见的摘要函数MD5,会将任意长度的字节序列转换为一个128位的摘要。

MD5:报文摘要的第5版本，是摘要算法系列的一种。安全散列算法(Secure Hash Algorithm SHA)是另外一种常见的摘要函数。

2.用随机数防止重放攻击

为防止截获摘要，重放给服务器，服务器可以向客户端发送一个成为随机数(nonce)的特殊令牌，这个数会经常变化。客户端在计算机摘要之前要将这个随机数令牌附加到密码上去。

在密码中加入随机数就会使摘要要随随机数的每一次变化而变化。记录下的密码摘要只对特定的随机数值有效，而没有密码的话，攻击者就无法计算出正确的摘要，这样就防止重放攻击的发生。

重放攻击(Replay Attacks): 又称重播攻击、回放攻击，是指攻击者发送一个目的主句已接受过的包，来达到欺骗系统的目的，主要是在身份认证过程中，破坏认证的正确性。攻击者利用网络监听或者其他方式盗取凭据，之后再重新发给认证服务器。

3.摘要认证的握手机制

1.(s) ==> WWW-Authenticate(服务器发送域、随机数和算法) ==> (b)

2.(b: 用对应算法，产生响应摘要，产生客户端的随机数) ==> Authorization(响应客户端生成的摘要发送算法) =

=> (s: 服务端对摘要进行认证产生rspauth摘要)

3.(s) ==> Authentication-Info(服务端发送下一个随机数[发送客户端rspauth摘要]) ==> (b：验证rspauth摘要)

8.http安全

1.数字签名流程

1.节点A将边长报文提取为定长的摘要

2.节点A对摘要应用一个"签名"函数，这个函数会将用户的私钥作为参数。只有用户才知道私有密钥，所以，正确的签名函数会说明签名者就是其所有者。

(RSA加密系统将解码函数D作为签名函数使用，是因为D已经将私有密钥作为输入使用了。注意，解码函数只是一个函数，因此，可以讲其用于任意的输入，同样，在RSA系统中，以任意顺讯应用D和E函数时，两者都会互相抵消。因此E(D(stuff)) = stuff,就像D(E(stuff)) = stuff一样)

3.在接收端，节点B需要确认报文确实是节点A所发，而没有篡改过，节点B就可以对签名进行检查。节点B接收经私有密钥扰码的签名，并应用了使用公开密钥的反函数，就可以比对签名，是否有篡改报文了。

9.https

概述：https就是再安全的传输层上面发送http。https没有将未加密的http报文发送给tcp，并通过世界范围内的因特网进行传输，它在将http报文发送给tcp之前，将其发送给了一个安全层，对其进行加密。

http安全层是通过SSL及其现代替代协议TLS来实现的。

9.1 ssl握手
  • 交换协议版本号
  • 选择2端都了解的密码
  • 对2端的身份进行认证
  • 生成临时的会话密钥，以便加密信道

ssl支持双向认证，将服务器证书承载回客户端，再讲客户端的证书送回给服务器。而现在，浏览时并不经常使用客户端证书。大部分用户甚至都没有自己客户端证书。

9.2分块编码

分块编码把报文切割为若干个已知的块,块之间是紧挨着发送,这样就不需要再发送之前知道整个报文的大小了.

需要注意的是,分块编码是一种传输编码,因此是报文的属性,而不是主体的属性.

1.分块编码与持久链接

若客户端与服务器不是持久连接,客户端就不需要知道他正读取的主体的长度,而只需要读到服务器关闭主体连接为止

当为持久连接是,在服务器写主体之前,必须知道它的大小并在Content-Length首部中发送，如果服务器动态创建内容，就可能在发送之前无法知道主体的长度。

分块编码为这种困难提供了解决方案，只要允许服务器把主体逐块发送，说明每块的大小就可以了。因为主体是动态创建，服务器可以缓存它的一部分，发送起对应大小的块，然后主体发送完之前重复这个过程。服务器可以用大小为0的块作为主体结束的信号，这样就可以继续保持连接，为下一个响应做准备。

9.3内容编码

服务器可以对内容进行压缩,如gizp,这样有助于减少传输的时间,服务还可以对内容进行搅乱或者加密.

avatar
文章
阅读
粉丝