NoteDeep




http事务时延:

DNS解析、TCP连接建立、报文传输、处理请求报文、响应报文这些都会产生时延。

a) 新建请求时,发送一个小的tcp分组,并设置一个SYN标记
b)回送一个tcp分组,设置了SYN和ACK标记,说明连接请求已被接受
c) 客户端再次发送ACK标记。而且现代TCP栈都允许在这个确认分组中发送数据

TCP慢启动:TCP连接会随时间调节,起初会限速,如果数据成功传输,会慢慢提高速度。防止网络突然过载。

Nagle算法:试图在发送一个分组之前,将大量的tcp数据绑定在一起,以提高网络效率。但是小的http报文可能无法填满一个分组,所以会产生时延。最好禁用nagle算法,通过设置参数TCP_NODELAY,如果要开启,一定要确认有大块数据写入。

Connection 首部:可以指定哪些首部不被代理转发,是否在本次事务结束之后关闭持久连接,和一些描述此连接的非标准选项。

并行连接:通过多条TCP发起并发的HTTP请求
持久连接:重用TCP连接,消除连接和关闭的时延。在事务结束之后,仍然保持在打开状态。
管道化连接:通过共享的TCP连接发起并发的HTTP请求
复用的连接:交替传送请求和响应报文(实验阶段)

持久连接和并行连接同时使用可能是最高效的方式,现在,很多web程序会打开少量的并行连接,并且每一个都是持久连接。

持久连接的例子:Keep-Alive(属于HTTP1.0,现在已经不再使用)


为了避免代理通信问题:现代的代理都绝不能盲目转发connection首部,以及所有名字出现在connection值中的首部。

HTTP/1.1持久连接

默认是激活的,除非显示添加Connection:close首部。

管道化连接

1.1允许在持久连接的基础上使用请求管道,即在第一条响应到达之前,可将后续的多条请求放入队列,并且发送。
限制:
必须按照请求顺序回送响应。
出错的时候、管道化方式会阻碍客户端了解服务器执行的是一系列管道化请求中的哪一些。



关闭连接的奥秘

所有客户端、服务器或代理,都可以在任意时刻关闭一条TCP传输连接。
如果响应的content-length错误,那么客户端只能依赖服务器发出的连接关闭来说明数据的真实末尾。接受端应该质疑长度的正确性,如果接受端是一个缓存代理,那么它就不应该缓存这条响应。
如果一个事务,不管执行一次还是很多次,得到的结果都相同,那么这个事务就是幂等的。比如GET请求。
POST就是非幂等的,如果是下订单,那么可能重复下多个订单。客户端不应该以管道化的方式传送非幂等的请求。要发送一条非幂等的请求,就需要等待前一条请求的响应状态。

socket的close会将输入和输出的信道都关闭,被称为完全关闭。而shutdown单独关闭输入或输出信道,这称为半关闭。
总之关闭连接的输出信道总是很安全的。另一端将会得知你将连接关闭了。
而关闭连接的输入信道比较危险,除非你知道另一端不打算再发送数据了。




评论列表

    http事务时延:
    HTTP/1.1持久连接
    管道化连接
    关闭连接的奥秘