http响应报文,如果响应的内容比较大,客户端怎么样判断接收完了呢?

1.   http协议有正文大小说明的
content-length

2. 或者分块传输chunked的话  读到0\r\n\r\n 就是读完了

-----------------------------------------------------------------------------------------------

http响应内容比较大的话,会分成多个tcp  segment 发送,不是最后一个segment的话, tcp的payload不会有http header字段,

如果是最后一个tcp segment 的话,就会有http header 字段,同时, 数据的最后会有 "0\r\n\r\n" 这个东西,这个东西就表示数据都发送完了。

如果是最后一个tcp segment 的话,就会有http header 字段,同时, 数据的最后会有 "0\r\n\r\n" 这个东西,这个东西就表示数据都发送完了。

https://osqa-ask.wireshark.org/questions/7268/http-continuation-vs-tcp-segment

2

In fact there are at least three different issues with reassembling considered chunked HTTP transfer encoding and you must check your preferences very carefully, especially if you are dealing with ‘endless‘ server connection sending chunks of messages.

First, the application-level protocol packet, such as HTTP request may fit in single TCP segment, and may not. If the HTTP header is big enough to be split in segments (that‘s a rare issue, but happens if site is sending lots of cookies and optional X-headers), then you will see two or more packets in the wireshark capture, period. The same can happen to HTTP response headers and mostly it does happen to HTTP request/response bodies. Sometimes applications just do send HTTP headers in single TCP segment and HTTP body in next one. But please note, that those segments have nothing in common with chunks, when chunked Transfer-Encoding is used, because that encoding is application level and TCP is the transport level of the OSI model. So, even your single "chunk" can span multiple segments. But that‘s not the whole story. Single TCP segment can either fit in ethernet frame (PDU), but can be split as well. Most of the time this does not happen, but for some badly configured Windows machines the maximum size of TCP frame is bigger then usual maximum of Ethernet switches can handle. To add more fun, transport-level packets must be ACK‘ed by the endpoint, and sometimes ACK is set within next TCP data packet, and sometimes it is sent separately, while still on the same HTTP port.

So, if you try to analyse Web application traffic on TCP level, you‘ll get a loads of useless sh#t most of the time. That‘s why you should use filters.

To help upper-level protocols collect and filter information, the wireshark dissectors have notion of ‘reassembling‘, where higher-level dissector returns special code meaning ‘hey, I need more data to properly dissect this packet‘ and then processing is restarted when more data arrives.

If you turn off ALL reassembling options for TCP and HTTP (and SSL) protocols, then you‘ll see the naked packets as they are on the wire. You‘ll notice that ‘Continuation of HTTP traffic‘ message in Info column when packet is with data, but neither HTTP request nor HTTP response header found within it. And all packets without data will be tagged as plain TCP in Protocol column. Mostly that‘s about ACKs, SYNs and FINs, so you can filter them out.

If you allow TCP to reassemble streams, but leave other options unchecked - the picture won‘t change much, because upper level protocols won‘t request reassembling.

If you allow HTTP to request reassembling the headers spanning multiple segments and bodies then you can already do filtering by application protocol means. E.g. enter ‘http‘ in the Display filter and you‘ll can forget about all [reassembled PDU] infos - they all be marked as being ‘TCP‘ protocol.

Now the dangled part - reassembling application-level chunks. If you analyse protocol that depends upon sending data in chunks, e.g. AJAX chat over HTTP, I‘d suggest leaving that option unchecked. Because reassembling stops when you receive the chunk with ‘0‘ size, which in your case you would never.

However, if your application does encode HTTP bodies with gzip, and use chunked encoding just to send it in streamlined version, you‘d better check option of chunk reassembling, otherwise ungzipping will fail.

That was quite a lot of text above, but hope now everything is clear for you.

Also, if you want more advanced filtering options for HTTP responses, you may find it useful to install following Lua script : Assocating HTTP responses to requests in Wireshark. Should you have any questions about it, feel free to ask.

原文地址:https://www.cnblogs.com/oxspirt/p/9775401.html

时间: 10-11

http响应报文,如果响应的内容比较大,客户端怎么样判断接收完了呢?的相关文章

重温Http协议--请求报文和响应报文

http协议是位于应用层的协议,我们在日常浏览网页比如在导航网站请求百度首页的时候,会先通过http协议把请求做一个类似于编码的工作,发送给百度的服务器,然后在百度服务器响应请求时把相应的内容再通过http协议做一个类似于解码的工作,这样浏览器才能理解这个数据,然后为我们展示出来百度首页. 这相当于是一种规范,网络中数据的传输在位于应用之下的各层(传输层,应用层)来完成的,在tcp/ip协议接收到数据时,我们是不能直接使用和浏览的,需要先通过一种规范来进行梳理,也就是解码,得到浏览器支持的一种格

HTTP 请求报文和响应报文

HTTP报文是面向文本的,报文中的每一个字段都是一些ASCII码串,各个字段的长度是不确定的.HTTP有两类报文:请求报文和响应报文. 1.请求报文一个HTTP请求报文由请求行(request line).请求头部(header).空行和请求数据4个部分组成,下图给出了请求报文的一般格式. (1)请求行 请求行由请求方法字段.URL字段和HTTP协议版本字段3个字段组成,它们用空格分隔.例如,GET /index.html HTTP/1.1. HTTP协议的请求方法有GET.POST.HEAD.

HTTP请求报文和HTTP响应报文

1.一次完整的HTTP请求所经历的7个步骤 HTTP通信机制是在一次完整的HTTP通信过程中,Web浏览器与Web服务器之间将完成下列7个步骤: 1. 建立TCP连接 在HTTP工作开始之前,Web浏览器首先要通过网络与Web服务器建立连接,该连接是通过TCP来完成的,该协议与IP协议共同构建 Internet,即著名的TCP/IP协议族,因此Internet又被称作是TCP/IP网络.HTTP是比TCP更高层次的应用层协议,根据规则, 只有低层协议建立之后才能,才能进行更层协议的连接,因此,首

HTTP响应报文与工作原理详解(转)

超文本传输协议(Hypertext Transfer Protocol,简称HTTP)是应用层协议.HTTP 是一种请求/响应式的协议,即一个客户端与服务器建立连接后,向服务器发送一个请求;服务器接到请求后,给予相应的响应信息. HTTP 请求报文 HTTP 请求报文由请求行.请求头部.空行 和 请求包体 4 个部分组成,如下图所示: 下面对请求报文格式进行简单的分析: 请求行:请求行由方法字段.URL 字段 和HTTP 协议版本字段 3 个部分组成,他们之间使用空格隔开.常用的 HTTP 请求

IOS开发网络篇--HTTP请求报文和HTTP响应报文

HTTP请求报文和HTTP响应报文: HTTP报文是面向文本的,报文中的每一个字段都是一些ASCII码串,各个字段的长度是不确定的.HTTP有两类报文:请求报文和响应报文. HTTP请求报文 一个HTTP请求报文由请求行(request line).请求头部(header).空行和请求数据4个部分组成,下图给出了请求报文的一般格式. or <request-line> <headers> <blank line> [<request-body> 1.请求头

(转)HTTP请求报文和HTTP响应报文

原地址:http://www.cnblogs.com/biyeymyhjob/archive/2012/07/28/2612910.html HTTP报文是面向文本的,报文中的每一个字段都是一些ASCII码串,各个字段的长度是不确定的.HTTP有两类报文:请求报文和响应报文. HTTP请求报文 一个HTTP请求报文由请求行(request line).请求头部(header).空行和请求数据4个部分组成,下图给出了请求报文的一般格式. or <request-line> <headers

HTTP请求报文与响应报文

一.HTTP报文是面向文本的,报文中的每一个字段都是一些ASCII码串,各个字段的长度是不确定的.HTTP有两类报文:请求报文和响应报文. 一个HTTP请求报文由请求行(request line).请求头部(header).空行和请求数据4个部分组成,下图给出了请求报文的一般格式. 网上复制了一个图片(转载自华山大师兄): 给一个更加清晰,明了的图片: 以下逐步分析各个数据部分的作用. 1.请求行 请求行由请求方法字段.URL字段和HTTP协议版本字段3个字段组成,它们用空格分隔. 例如打开路径

Http请求和响应报文基础知识

一 HTTP请求报文(http://en.wikipedia.org/wiki/List_of_HTTP_header_fields) 请求报文由三部分组成:请求行,请求头和请求体. 请求行:请求方法(如POST),请求URL地址(和请求头Host属性组成完整URL),HTTP协议及版本. 请求头:包含若干个属性,格式为“属性名:属性值”. 请求体:以param1=value1&param2=value2的键值对形式编码成的格式化串,承载多个请求参数的数据.除了请求体外,请求URL也可以通过“?

HTTP请求响应报文&amp;&amp;相关状态码&amp;&amp;GET_POST请求方法 总结

HTTP请求报文: 一个HTTP请求报文由四个部分组成:请求行.请求头部.空行.请求数据 1.请求行   请求行由请求方法字段.URL字段和HTTP协议版本字段3个字段组成,它们用空格分隔.比如 GET /data/info.html HTTP/1.1 方法字段就是HTTP使用的请求方法,比如常见的GET/POST 其中HTTP协议版本有两种:HTTP1.0/HTTP1.1 可以这样区别: HTTP1.0对于每个连接都的建立一次连接一次只能传送一个请求和响应,请求就会关闭,HTTP1.0没有Ho

常用http响应报文分析

这是我在使用Asp.Net的时候,整理的的一些关于Http响应报文的分析笔记,零零散散的记录, 现在贴出来,抛砖引玉,如果有什么不对或者不严谨的地方,请各位大神不吝赐教. 一.HTTP响应码响应码由三位十进制数字组成,它们出现在由HTTP服务器发送的响应的第一行. 响应码分五种类型,由它们的第一位数字表示: 1xx:信息,请求收到,继续处理 2xx:成功,行为被成功地接受.理解和采纳 3xx:重定向,为了完成请求,必须进一步执行的动作 4xx:客户端错误,请求包含语法错误或者请求无法实现 5xx