[原创]nginx写日志时机与tcp write写成功是否送达对端疑问解析

原创文章:来自nginx写日志时机与tcp write写成功是否送达对端疑问解析

前些天和另外部门的同事在排查一个网络问题, 问到nginx日志中成功记录了http 200响应码能否证明响应数据就达到了对端? 这个问题涉及nginx在做server功能时写日志是在什么时机? 是client端收到响应数据后才生成, 还是nginx丢出数据就生成了而不管是否client端收到数据?

做上层应用的人员一般对底层网络部分研究的较少,另外针对应用层调用write写TCP数据并返回写入的字节数就认为成功到达了对端这个问题很多人存在误解。涉及的nginx发出响应处理流程和linux系统TCP的处理过程,,简要解释如下:

nginx记录访问日志的时机

通过ngx_http_output_filter()发送响应数据给client
ngx_http_write_filter()会调用c->send_chain()往客户端发送数据,c->send_chain()的取值
在不同操作系统,编译选项以及协议下(https下用的是
ngx_ssl_send_chain)会取不同的函数,典型的Linux操作系统下,它的取值为ngx_linux_sendfile_chain(),这个函数中使用rc = writev(c->fd, header.elts, header.nelts);发送数据;

响应的字节全部发送完成后调用 ngx_http_finalize_request(r, rc);

ngx_http_finalize_request()

-->ngx_http_terminate_request()强制结束请求

或者直接调用-->

-->ngx_http_close_request()

-->ngx_http_free_request()

-->ngx_http_log_request(r);//记录日志

再看一下TCP数据的发送流程

这里定义为数据拷贝到协议栈缓存和缓存数据发送两个阶段。

应用层发送数据时调用TCP数据发送函数可以是write、send、sendmsg 这三个函数参数中携带需要发送的数据,最终在内核层面都是通过调用__sock_sendmsg()实现,对TCP数据来说__sock_sendmsg()函数中会再调用tcp_sendmsg(); 而tcp_sendmsg()函数中根据现有的TCP缓存是否足够会选择将应用层的数据复制到sk_buff中,复制完成的sk_buff挂入到sk_write_queue 队列尾部等待发送; 这个流程的代码中用copied变量代表了真实从应用层已经拷贝到sk_buff中的数据量,下边会走真正的TCP发送流程。但不管下边的流程能否真正的发送出去数据,会返回这个copied到应用层代表写入成功的数量; 而协议栈缓存数据的发送就由我们所熟知的TCP可靠传输机制去保证到达对端了。

协议栈缓存数据的发送通过以下几个函数负责:

-->tcp_push()

-->__tcp_push_pending_frames()

-->tcp_write_xmit()

** 在tcp_write_xmit()中会逐步检查本端的拥塞窗口(拥塞控制算法不断的在调整)设置是否有配额cwnd_quota可以发送报文? 配额不足则跳出;

** 进行发送窗口snd_wnd 检测, 若发送的MSS超过了发送窗口则跳出;

** 若开启了Nagle算法不能立即发送此报文则跳出;

如果能通过以上等的限制则调用tcp_transmit_skb()真正的执行发送数据。

综合所述TCP数据的发送其实是个异步的执行过程,应用层负责把数据写入到TCP缓存中,而缓存中的数据需要靠TCP的可靠传输机制去保证发送到对端,由于TCP的可靠传输机制执行过程中会考虑拥塞窗口、对端接收窗口、MSS、nagle算法等因素,执行完成后返回的copied字节量并不一定就代表对端接收成功了。

上一篇:nginx中session ticket重用Session提高https性能分析


下一篇:[原创]TCP的backlog导致的HBase访问超时问题排查(续)