接收上游服务器的响应头部-西门子simatic et200sp数字量输出模块

12.5　接收上游服务器的响应头部 当请求全部发送给上游服务器时，Nginx开始准备接收来自上游服务器的响应。在图12- 3的第7步中设置了由ngx_http_upstream_process_header方法处理上游服务器的响应，而图12-4 的第8步也是通过调用该方法接收响应的，本节的内容就在于说明可能会被反复多次调用的 ngx_http_upstream_process_header方法。 12.5.1　应用层协议的两段划分方式 在12.1.1节我们已经了解到，只要上游服务器提供的应用层协议是基于TCP实现的，那 么upstream机制都是适用的。基于TCP的响应其实就是有顺序的数据流，那么，upstream机制 只需要按照接收到的顺序调用HTTP模块来解析数据流不就行了吗？多么简单和清晰！然 而，实际上，应用层协议要比这复杂得多，这主要表现在协议长度的不可确定和协议内容的 解析上。首先，应用层协议的响应包可大可小，如最小的响应可能只有128B，最大的响应可 能达到5GB，如果属于HTTP框架的ngx_http_upstream_module模块在内存中接收到全部响应内 容后再调用各个HTTP模块处理响应，就很容易引发OutOfMemory错误，即使没有错误也会因 为内存消耗过大从而降低了并发处理能力。如果在磁盘文件中接收全部响应，又会带来大量 的磁盘I/O操作，最终大幅提高服务器的负载。其次，对响应中的所有内容都进行解析并无 必要（解析操作毕竟对CPU是有消耗的）。例如，从Memcached服务器上下载一幅图片， Nginx只需要解析Memcached协议，并不需要解析图片的内容，对于图片内容，Nginx只需要 边接收边转发给客户端即可。 为了解决上述问题，应用层协议通常都会将请求和响应分成两部分：包头和包体，其中 包头在前而包体在后。包头相当于把不同的协议包之间的共同部分抽象出来，不同的数据包 之间包头都具备相同的格式，服务器必须解析包头，而包体则完全不做格式上的要求，服务 器是否解析它将视业务上的需要而定。包头的长度要么是固定大小，要么是限制在一个数值