http协议，判定请求读取完毕，以及TCP粘包与拆包

最新推荐文章于 2024-06-12 11:16:21 发布

Wondering0

最新推荐文章于 2024-06-12 11:16:21 发布

阅读量3.6k

点赞数 4

文章标签： http tcp

本文链接：https://blog.csdn.net/TNT_wang/article/details/86241745

版权

我们知道，tcp是流协议，我们发送的消息既可能因为一条消息太大被tcp拆分成多个包发送，多个消息也可能被合并到一个包发送，因此在接收端我们要处理tcp的拆包粘包问题。大致有如下几种思路：

消息定长
消息之间添加特定分隔符
显式长度，比如先发送4个字节表示消息的长度，紧接着发送消息
结合上面各种策略

http协议采用的策略

请求头以特定的符号（"\r\n"）结束,符合策略2，如果有请求体，则请求头中会有表示请求体的长度，符合策略3

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

Wondering0

关注关注

4
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫

http协议解决粘包拆包半包的编码解码过程、以及netty 使用http协议的原理

FREEDOM

08-02

9110

本文主要介绍netty对http协议解析原理，着重讲解keep-alive，gzip，truncked等机制，详细描述了netty如何实现对http解析的高性能。 1 http协议 1.1 描述标示 ASCII 描述字符 CR 13 Carriage return (回车) \r LF 10 Line feed character(换行) \n SP 30　　 Horizontal space(...

粘包/拆包问题——如何获取一个完整的网络包？

悟已往之不谏，知来者之可追

11-10

522

本文章开始讲解 Netty 通信过程中的编解码技术。编解码技术是实现网络通信的基础，让我们可以定义任何满足业务需求的应用层协议。在网络编程中，我们经常会使用各种网络传输协议，其中 TCP 是最常用的协议。我们首先需要了解的是 TCP 最基本的拆包/粘包问题以及常用的解决方案，才能更好地理解 Netty 的编解码框架。文章目录为什么有拆包/粘包MTU 最大传输单元和 MSS 最大分段大小滑动窗口Nagle 算法拆包/粘包的解决方案消息长度固定特定分隔符总结为什么有拆包/粘包 TCP 是传输协议是面向流的，

参与评论您还未登录，请先登录后发表或查看评论

HTTP chunked传输如何表示结束

风神韵

07-20

1689

一般服务器响应消息都会在HTTP响应头部加上Content-Length，这样客户端就知道要接收多少数据。这也要求一定要先发送响应头部，再发送响应内容。但并不是所有场景都能事先知道响应包长度，比如动态页面，事先并不知晓响应包大小，这样也无法在响应头部设置Content-Length，这时可通过chunked来进行传输。那么通过chunked方式传输时，客户端如何感知包传输完了呢？一个chunk包有两部分组成：前部分为包大小，后部分为包内容。当包的大小为0时，当客户端收到一个包大小为0的chunk包时，

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

weixin_33827731的博客

10-11

2980

1. http协议有正文大小说明的content-length2. 或者分块传输chunked的话读到0\r\n\r\n 就是读完了 ----------------------------------------------------------------------------------------------- http响应内容比较大的话，会分成多个tcp segment 发...

http1.1长链接通过什么手段判断一个请求已经结束了？

读书就是赚钱

11-21

2707

由状态码决定的没有消息体的请求（1XX，204，304），那么接受到请求头后则结束。 Transfer-Encoding为chunked的时候，接受到一个长度为0的chunked Content-Length描述body长度，但是如果有transfer-length那么这个头就会被忽略，因为这样的话就是使用了以上第二种的方式关闭链接总结：可以理解为判断是否结束为判断是否读取完整个请求 -> 是否拥有请求体，有点的话 -> 判断请求体大小判断 -> 静态判断利用Con.

客户端socket模拟http请求，如何判断http响应结束(http1.1)

热门推荐

大新博客

07-19

1万+

1、如果是短连接，没有启用keepalive，则可以通过是否关闭了连接来判断是否传输结束，即在读取时可判断 read() != -1。 2、如果时长连接，那么一个socket（tcp）可能发送和接收多次请求，那么如何判断每次的响应已经接收? 2-1、先读请求头，一直到\r\n\r\n说明请求头结束，然后解析http头，如果Content-Length=x存在，则知道http响应的长度为x。直接...

TCP、UDP、TCP三次握手与四次挥手、TCP如何保证可靠传输、TCP异常分析、拆包和粘包等

loytuls的博客

03-20

1219

关于计算机网络的面试官最爱问的问题：TCP、UDP、TCP三次握手与四次挥手、TCP如何保证可靠传输、TCP异常分析、拆包和粘包等（必问问题）

socket的长连接、短连接、半包、粘包与分包

墨鱼菜鸡

07-11

2559

socket的半包，粘包与分包的问题和处理代码：http://blog.csdn.net/qq_16112417/article/details/50392463 知乎关于长连接和短连接：https://www.zhihu.com/search?type=content&q=长连接%20短连接 TCP网络通讯如何解决分包粘包问题：http:/...

传输层—详解TCP协议

hlizoo的博客

08-14

350

详解传输层的TCP协议，从特点、协议段格式、各种不同的机制多角度多方面颠覆您对于TCP协议的认知，更深层次更轻松的了解网络

【网络编程】传输层协议——TCP协议

qq_66314292的博客

07-18

1804

TCP协议

Http怎么解决粘包拆包的？

weixin_42002747的博客

04-21

5018

发送端：应用层协议的每个包到达传输层，如果是tcp，会可能出现以下情况: 1)应用层的每个包被拆成多个tcp报文，分别发送，这是拆包； 2)应用层的多个包组成一个tcp报文发送，这是粘包；接收端：发送端的数据通过网络传输到了接受端的tcp缓冲区，不知道如何组成一个应用层的包，这必须由应用层解决，方法如下： 1）定长：应用层指定每个包的长度，如果数据不够，用空格补充，缺点是不够灵活，不能发送超出这个长度的包； 2）分割符：指定分割符，接收端一直读取数据直到读取到指定的分割符； 3）指定长度+数据：比如先

tcp过程，http解决粘包和半包问题

最新发布

jupiter_888的博客

06-12

968

https://www.cnblogs.com/vipstone/p/14239160.html

HTTP 协议中的 Transfer-Encoding

mandagod的博客

11-02

1020

HTTP 协议中的 Transfer-Encoding 文章目录 Persistent ConnectionContent-LengthTransfer-Encoding: chunked 本文作为我的博客「HTTP 相关」专题新的一篇，主要讨论 HTTP 协议中的 Transfer-Encoding。这个专题我会根据自己的理解，以尽量通俗的讲述，结合代码示例和实际场景来

TCP详解（三）

weixin_50080344的博客

07-29

1097

一份数据同时发送给多个主机，UDP自身就支持广播的，但是TCP自身不支持，就只能在应用层程序中通过多个连接，轮询的方式给每个主机发送数据（伪广播）。1.实现确认应答机制，把每个数据接收到之后，大欧要反馈一个ACK（此时这个就不是内核返回的了，而是应用程序自己定义一个ACK包，发送回去）。不管进程是怎么终止的，本质上都会释放对应的PCB，也会释放对应的文件描述符符，一样会触发四次挥手。如果PING包已经发送过去，过了河你局还没有PONG，并且重试几次也不行，此时就认为对方已经挂了。...

TCP协议简单理解

qq_40894047的博客

11-15

418

TCP协议是一种广域网的通信协议，它有以下优点：（1）基于流的方式；（2）面向连接；（3）可靠通信方式；（4）在网络状况不佳的时候尽量降低系统由于重传带来的带宽开销；（5）通信连接维护是面向通信的两个端点的，而不考虑中间网段和节点。同时为了满足以上优点，它在细节上有如下实现： ①数据分片：在发送端对用户数据进行分片，在接收端进行重组，由TCP确定分片的大小并控制分片和重组...

一次完整的http请求全过程（知识体系版）

星海拾遗

12-04

1万+

最差的面试体验面试官评价：除了学历，和培训班出来的没区别。确实，很多东西我只是会用。面完回来，我发现我确实连一个完整的http请求如何发送都不明白。失败并不可怕。但是一定得把失败的悲痛化成力量！我觉得需要把掌握的知识串成一套完整的知识体系。超长文预警一次完整的http请求的全过程域名解析------>tcp建立三次握手过程------>发送http请......

netty tcp粘包和拆包

07-30

Netty中的TCP粘包和拆包问题是由于底层的TCP协议无法理解上层的业务数据而导致的。为了解决这个问题，Netty提供了几种解决方案。其中，常用的解决方案有四种[1]： 1. 固定长度的拆包器（FixedLengthFrameDecoder）：将每个应用层数据包拆分成固定长度的大小。这种拆包器适用于应用层数据包长度固定的情况。 2. 行拆包器（LineBasedFrameDecoder）：将每个应用层数据包以换行符作为分隔符进行分割拆分。这种拆包器适用于应用层数据包以换行符作为结束符的情况。 3. 分隔符拆包器（DelimiterBasedFrameDecoder）：将每个应用层数据包通过自定义的分隔符进行分割拆分。这种拆包器适用于应用层数据包以特定分隔符作为结束标志的情况。 4. 基于数据包长度的拆包器（LengthFieldBasedFrameDecoder）：将应用层数据包的长度作为接收端应用层数据包的拆分依据。根据应用层协议中包含的数据包长度进行拆包。这种拆包器适用于应用层协议中包含数据包长度的情况。除了使用这些拆包器，还可以根据业界主流协议的解决方案来解决粘包和拆包问题[3]： 1. 消息长度固定：累计读取到长度和为定长LEN的报文后，就认为读取到了一个完整的信息。 2. 使用特殊的分隔符：将换行符或其他特殊的分隔符作为消息的结束标志。 3. 在消息头中定义长度字段：通过在消息头中定义长度字段来标识消息的总长度。综上所述，Netty提供了多种解决方案来解决TCP粘包和拆包问题，可以根据具体的业务需求选择合适的解决方案[1][3]。