网络7层协议，4层，5层 概念

一、7层

7层是指OSI七层协议模型，主要是：应用层（Application）、表示层（Presentation）、会话层（Session）、传输层（Transport）、网络层（Network）、数据链路层（Data Link）、物理层（Physical）。

各层的作用及描述，以及对应的协议如下图（好东西啊，不过本文图是盗图，懒得重画了，仅供各位学习使用）：

二、5层

5层只是OSI和TCP/IP的综合，是业界产生出来的非官方协议模型，但是很多具体的应用。实际应用还是TCP/IP的四层结构。为了方便可以把下两层称为网络接口层。五层体系结构包括：应用层、运输层、网络层、数据链路层和物理层。

5层模型不展开讲解，内容和功能参照7层的，这里把3者做一个综合的对应，如下图：

三、4层

4层是指TCP/IP四层模型，主要包括：应用层、运输层、网际层和网络接口层。

4层协议和对应的标准7层协议的关系如下图：

四、数据包

从上往下，每经过一层，协议就会在包头上面做点手脚，加点东西，传送到接收端，再层层解套出来，如下示意图：

————————————————
版权声明：本文为CSDN博主「陈 超」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/cc1949/article/details/79063439

TCP/IP原理

TCP/IP 协议不是 TCP 和 IP 这两个协议的合称，而是指因特网整个 TCP/IP 协议族。从协议分层 模型方面来讲，TCP/IP 由四个层次组成:网络接口层、网络层、传输层、应用层。

网络访问层(Network Access Layer)

网络访问层(Network Access Layer)在 TCP/IP 参考模型中并没有详细描述，只是指出主机 必须使用某种协议与网络相连。

网络层(Internet Layer)

网络层(Internet Layer)是整个体系结构的关键部分，其功能是使主机可以把分组发往任何网 络，并使分组独立地传向目标。这些分组可能经由不同的网络，到达的顺序和发送的顺序也 可能不同。高层如果需要顺序收发，那么就必须自行处理对分组的排序。互联网层使用因特 网协议(IP，Internet Protocol)。

传输层(Tramsport Layer-TCP/UDP)

传输层(Tramsport Layer)使源端和目的端机器上的对等实体可以进行会话。在这一层定义了 两个端到端的协议:传输控制协议(TCP，Transmission Control Protocol)和用户数据报协 议(UDP，User Datagram Protocol)。TCP 是面向连接的协议，它提供可靠的报文传输和对 上层应用的连接服务。为此，除了基本的数据传输外，它还有可靠性保证、流量控制、多路 复用、优先权和安全性控制等功能。UDP 是面向无连接的不可靠传输的协议，主要用于不需 要 TCP 的排序和流量控制等功能的应用程序。

应用层(Application Layer)

应用层(Application Layer)包含所有的高层协议，包括:虚拟终端协议(TELNET， TELecommunications NETwork)、文件传输协议(FTP，File Transfer Protocol)、电子邮件 传输协议(SMTP，Simple Mail Transfer Protocol)、域名服务(DNS，Domain NameService)、网上新闻传输协议(NNTP，Net News Transfer Protocol)和超文本传送协议 (HTTP，HyperText Transfer Protocol)等。

TCP三次握手/四次挥手

TCP 在传输之前会进行三次沟通，一般称为“三次握手”，传完数据断开的时候要进行四次沟通，一般
称为“四次挥手”。

数据包说明

1. 源端口号( 16 位):它(连同源主机 IP 地址)标识源主机的一个应用进程。
2. 目的端口号( 16 位):它(连同目的主机 IP 地址)标识目的主机的一个应用进程。这两个值
   加上 IP 报头中的源主机 IP 地址和目的主机 IP 地址唯一确定一个 TCP 连接。
3. 顺序号 seq( 32 位):用来标识从 TCP 源端向 TCP 目的端发送的数据字节流，它表示在这个
   报文段中的第一个数据字节的顺序号。如果将字节流看作在两个应用程序间的单向流动，则TCP 用顺序号对每个字节进行计数。序号是 32bit 的无符号数，序号到达 2 的 32 次方 - 1 后 又从 0 开始。当建立一个新的连接时， SYN 标志变 1 ，顺序号字段包含由这个主机选择的该 连接的初始顺序号 ISN ( Initial Sequence Number )。
   
4. 确认号 ack( 32 位):包含发送确认的一端所期望收到的下一个顺序号。因此，确认序号应当 是上次已成功收到数据字节顺序号加 1 。只有 ACK 标志为 1 时确认序号字段才有效。 TCP 为 应用层提供全双工服务，这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必 须保持每个方向上的传输数据顺序号。
5. TCP 报头长度( 4 位):给出报头中 32bit 字的数目，它实际上指明数据从哪里开始。需要这 个值是因为任选字段的长度是可变的。这个字段占 4bit ，因此 TCP 最多有 60 字节的首部。然 而，没有任选字段，正常的长度是 20 字节。
6. 保留位( 6 位):保留给将来使用，目前必须置为 0 。
7. 控制位( control flags ， 6 位):在 TCP 报头中有 6 个标志比特，它们中的多个可同时被设置为 1 。依次为:
   • URG :为 1 表示紧急指针有效，为 0 则忽略紧急指针值。
   • ACK :为 1 表示确认号有效，为 0 表示报文中不包含确认信息，忽略确认号字段。
   • PSH :为 1 表示是带有 PUSH 标志的数据，指示接收方应该尽快将这个报文段交给应用层
     而不用等待缓冲区装满。
   • RST :用于复位由于主机崩溃或其他原因而出现错误的连接。它还可以用于拒绝非法的报
     文段和拒绝连接请求。一般情况下，如果收到一个 RST 为 1 的报文，那么一定发生了某些
     问题。
   • SYN :同步序号，为 1 表示连接请求，用于建立连接和使顺序号同步( synchronize )。
   • FIN :用于释放连接，为 1 表示发送方已经没有数据发送了，即关闭本方数据流。
8. 窗口大小( 16 位):数据字节数，表示从确认号开始，本报文的源方可以接收的字节数，即源 方接收窗口大小。窗口大小是一个 16bit 字段，因而窗口大小最大为 65535 字节。

9. 校验和( 16 位):此校验和是对整个的 TCP 报文段，包括 TCP 头部和 TCP 数据，以 16 位字 进行计算所得。这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证。

10. 紧急指针(16位):只有当URG标志置1时紧急指针才有效。TCP的紧急方式是发送端向另 一端发送紧急数据的一种方式。

11. 选项:最常见的可选字段是最长报文大小，又称为MSS(MaximumSegmentSize)。每个连 接方通常都在通信的第一个报文段(为建立连接而设置 SYN 标志的那个段)中指明这个选项，它指明本端所能接收的最大长度的报文段。选项长度不一定是 32 位字的整数倍，所以要加填充 位，使得报头长度成为整字数。

12. 数据: TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报 文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数 据。在处理超时的许多情况中，也会发送不带任何数据的报文段。

    三次握手

    第一次握手:主机 A 发送位码为 syn=1,随机产生 seq number=1234567 的数据包到服务器，主机 B
    由 SYN=1 知道，A 要求建立联机;
    第二次握手:主机 B 收到请求后要确认联机信息，向 A 发送 ack number=(主机 A 的
    seq+1),syn=1,ack=1,随机产生 seq=7654321 的包
    第三次握手:主机 A 收到后检查 ack number 是否正确，即第一次发送的 seq number+1,以及位码
    ack 是否为 1，若正确，主机 A 会再发送 ack number=(主机 B 的 seq+1),ack=1，主机 B 收到后确认seq 值与 ack=1 则连接建立成功。
    

四次挥手

TCP 建立连接要进行三次握手，而断开连接要进行四次。这是由于 TCP 的半关闭造成的。因为 TCP 连 接是全双工的(即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭。这个单 方向的关闭就叫半关闭。当一方完成它的数据发送任务，就发送一个 FIN 来向另一方通告将要终止这个 方向的连接。
1) 关闭客户端到服务器的连接:首先客户端 A 发送一个 FIN，用来关闭客户到服务器的数据传送， 然后等待服务器的确认。其中终止标志位 FIN=1，序列号 seq=u
2) 服务器收到这个 FIN，它发回一个 ACK，确认号 ack 为收到的序号加 1。
3) 关闭服务器到客户端的连接:也是发送一个 FIN 给客户端。
4) 客户段收到 FIN 后，并发回一个 ACK 报文确认，并将确认序号 seq 设置为收到序号加 1。 首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

主机 A 发送 FIN 后，进入终止等待状态， 服务器 B 收到主机 A 连接释放报文段后，就立即 给主机 A 发送确认，然后服务器 B 就进入 close-wait 状态，此时 TCP 服务器进程就通知高 层应用进程，因而从 A 到 B 的连接就释放了。此时是“半关闭”状态。即 A 不可以发送给B，但是 B 可以发送给 A。此时，若 B 没有数据报要发送给 A 了，其应用进程就通知 TCP 释 放连接，然后发送给 A 连接释放报文段，并等待确认。A 发送确认后，进入 time-wait，注 意，此时 TCP 连接还没有释放掉，然后经过时间等待计时器设置的 2MSL 后，A 才进入到close 状态。

【问题】为什么连接的时候是三次握手，关闭的时候却是四次握手？ 答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

HTTP原理

HTTP 是一个无状态的协议。无状态是指客户机(Web 浏览器)和服务器之间不需要建立持久的连接， 这意味着当一个客户端向服务器端发出请求，然后服务器返回响应(response)，连接就被关闭了，在服 务器端不保留连接的有关信息.HTTP 遵循请求(Request)/应答(Response)模型。客户机(浏览器)向 服务器发送请求，服务器处理请求并返回适当的应答。所有 HTTP 连接都被构造成一套请求和应答。

传输流程

如用客户端浏览器请求这个页面:http://localhost.com:8080/index.htm 从中分解出协议名、主机名、
端口、对象路径等部分，对于我们的这个地址，解析得到的结果如下:
协议名:http
主机名:localhost.com
端口:8080
对象路径:/index.htm

1.地址解析

在这一步，需要域名系统 DNS 解析域名 localhost.com,得主机的 IP 地址。

2:封装 HTTP 请求数据包

把以上部分结合本机自己的信息，封装成一个 HTTP 请求数据包

3:封装成 TCP 包并建立连接

封装成 TCP 包，建立 TCP 连接(TCP 的三次握手)

4:客户机发送请求命

客户机发送请求命令:建立连接后，客户机发送一个请求给服务器，请求方式的格式为:统一资源标识符(URL)、协议版本号，后边是 MIME 信息包括请求修饰符、客户机信息和可内容。

5:服务器响应

服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或
错误的代码，后边是 MIME 信息包括服务器信息、实体信息和可能的内容。

6:服务器关闭 TCP 连接

服务器关闭 TCP 连接:一般情况下，一旦 Web 服务器向浏览器发送了请求数据，它就要关闭 TCP 连 接，然后如果浏览器或者服务器在其头信息加入了这行代码 Connection:keep-alive，TCP 连接在发送 后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求 建立新连接所需的时间，还节约了网络带宽。

HTTP 状态

HTTP状态码分类

HTTP状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用。HTTP状态码共分为5种类型：
HTTP状态码分类

HTTP状态码列表

都 2019 年了，还问 GET 和 POST 的区别

摘要： 对比 GET 与 POST。

• 原文：都 9102 年了，还问 GET 和 POST 的区别
• 作者：程淇铭

Fundebug经授权转载，版权归原作者所有。

1. 前言

最近看了一些同学的面经，发现无论什么技术岗位，还是会问到 get 和 post 的区别，而搜索出来的答案并不能让我们装得一手好逼，那就让我们从 HTTP 报文的角度来撸一波，从而搞明白他们的区别。

2. 标准答案

在开撸之前吗，让我们先看一下标准答案长什么样子 w3school: GET 对比 POST。标准答案很美好，但是在面试的时候把下面的表格甩面试官一脸，估计会装逼不成反被*。

注意，并不是说标准答案有误，上述区别在大部分浏览器上是存在的，因为这些浏览器实现了 HTTP 标准。
所以从标准上来看，GET 和 POST 的区别如下：

• GET 用于获取信息，是无副作用的，是幂等的，且可缓存
• POST 用于修改服务器上的数据，有副作用，非幂等，不可缓存

但是，既然本文从报文角度来说，那就先不讨论 RFC 上的区别，单纯从数据角度谈谈。

3. GET 和 POST 报文上的区别

先下结论，GET 和 POST 方法没有实质区别，只是报文格式不同。
GET 和 POST 只是 HTTP 协议中两种请求方式，而 HTTP 协议是基于 TCP/IP 的应用层协议，无论 GET 还是 POST，用的都是同一个传输层协议，所以在传输上，没有区别。
报文格式上，不带参数时，最大区别就是第一行方法名不同
POST 方法请求报文第一行是这样的 POST /uri HTTP/1.1 \r\n
GET 方法请求报文第一行是这样的 GET /uri HTTP/1.1 \r\n
是的，不带参数时他们的区别就仅仅是报文的前几个字符不同而已
带参数时报文的区别呢？ 在约定中，GET 方法的参数应该放在 url 中，POST 方法参数应该放在 body 中
举个例子，如果参数是 name=qiming.c, age=22。
GET 方法简约版报文是这样的

POST 方法简约版报文是这样的

现在我们知道了两种方法本质上是 TCP 连接，没有差别，也就是说，如果我不按规范来也是可以的。我们可以在 URL 上写参数，然后方法使用 POST；也可以在 Body 写参数，然后方法使用 GET。当然，这需要服务端支持。

4. 常见问题

GET 方法参数写法是固定的吗？

在约定中，我们的参数是写在 ? 后面，用 & 分割。
我们知道，解析报文的过程是通过获取 TCP 数据，用正则等工具从数据中获取 Header 和 Body，从而提取参数。
也就是说，我们可以自己约定参数的写法，只要服务端能够解释出来就行，一种比较流行的写法是 http://www.example.com/user/name/chengqm/age/22。

POST 方法比 GET 方法安全？

按照网上大部分文章的解释，POST 比 GET 安全，因为数据在地址栏上不可见。
然而，从传输的角度来说，他们都是不安全的，因为 HTTP 在网络上是明文传输的，只要在网络节点上捉包，就能完整地获取数据报文。
要想安全传输，就只有加密，也就是 HTTPS。

GET 方法的长度限制是怎么回事？

在网上看到很多关于两者区别的文章都有这一条，提到浏览器地址栏输入的参数是有限的。
首先说明一点，HTTP 协议没有 Body 和 URL 的长度限制，对 URL 限制的大多是浏览器和服务器的原因。
浏览器原因就不说了，服务器是因为处理长 URL 要消耗比较多的资源，为了性能和安全（防止恶意构造长 URL 来攻击）考虑，会给 URL 长度加限制。

POST 方法会产生两个 TCP 数据包？

有些文章中提到，post 会将 header 和 body 分开发送，先发送 header，服务端返回 100 状态码再发送 body。
HTTP 协议中没有明确说明 POST 会产生两个 TCP 数据包，而且实际测试(Chrome)发现，header 和 body 不会分开发送。
所以，header 和 body 分开发送是部分浏览器或框架的请求方法，不属于 post 必然行为。

5. talk is cheap show me the code

如果对 get 和 post 报文区别有疑惑，直接起一个 Socket 服务端，然后封装简单的 HTTP 处理方法，直接观察和处理 HTTP 报文，就能一目了然

上面代码就是简单的打印请求报文然后返回 HelloWorld 的 html 页面，我们运行起来

然后从浏览器中请求看看

打印出来的报文

然后就可以手动证明上述说法，比如说要测试 header 和 body 是否分开传输，由于代码没有返回 100 状态码，如果我们 post 请求成功就说明是一起传输的(Chrome/postman)。

又比如 w3school 里面说 URL 的最大长度是 2048 个字符，那我们在代码里面加上一句计算 uri 长度的代码

我们用 postman 直接发送超过 2048 个字符的请求看看

然后我们可以得出结论，url 长度限制是某些浏览器和服务器的限制，和 HTTP 协议没有关系。
到此，我们可以愉快地装逼了 :)

参考

• 99%的人都理解错了 HTTP 中 GET 与 POST 的区别
• 关于 HTTP GET 和 POST
• w3school: HTTP 方法：GET 对比 POST
• wikipedia: 超文本传输协议
• RFC 2068

  关于Fundebug

  Fundebug专注于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java线上应用实时BUG监控。 自从2016年双十一正式上线，Fundebug累计处理了30亿+错误事件，付费客户有阳光保险、达令家、核桃编程、荔枝FM、微脉等众多品牌企业。欢迎大家免费试用！
  

  版权声明

  转载时请注明作者 Fundebug以及本文地址：
  https://blog.fundebug.com/2019/02/22/compare-http-method-get-and-post/

MAC地址已经是唯一了，为什么需要IP地址？

或者可以反过来问：已经有IP地址了，为什么需要MAC地址？？在zhihu上还蛮多类似的问题的：

我来简单总结一下为什么有了MAC(IP)还需要IP(MAC)：

• MAC是链路层，IP是网络层，每一层干每一层的事儿，之所以在网络上分链路层、网络层(…，就是将问题简单化。
• 历史的兼容问题。

已经有IP地址了，为什么需要MAC地址？？

• 现阶段理由：DHCP基于MAC地址分配IP。

MAC地址已经是唯一了，为什么需要IP地址？

• MAC无网段概念，非类聚，不好管理。

  如果有更好的看法，不妨在评论区下留言哦~

参考资料：

• MAC地址唯一，不能满足通信需求吗？为什么需要IP？https://www.wukong.com/answer/6549169419812077827/
• 有了 IP 地址，为什么还要用 MAC 地址？https://www.zhihu.com/question/21546408

  TCP状态

  TCP 每个状态说一下，TIME-WAIT状态说一下

TCP总共有11个状态，状态之间的转换是这样的：

流程图：

下面我简单总结一下每个状态：

• CLOSED：初始状态，表示TCP连接是“关闭着的”或“未打开的”。
• LISTEN：表示服务器端的某个SOCKET处于监听状态，可以接受客户端的连接。
• SYN-SENT：表示客户端已发送SYN报文。当客户端SOCKET执行connect()进行连接时，它首先发送SYN报文，然后随即进入到SYN_SENT状态。
• SYN_RCVD：表示服务器接收到了来自客户端请求连接的SYN报文。当TCP连接处于此状态时，再收到客户端的ACK报文，它就会进入到ESTABLISHED状态。
• ESTABLISHED：表示TCP连接已经成功建立。
• FIN-WAIT-1：第一次主动请求关闭连接,等待对方的ACK响应。
• CLOSE_WAIT：对方发了一个FIN报文给自己，回应一个ACK报文给对方。此时进入CLOSE_WAIT状态。
  • 接下来呢，你需要检查自己是否还有数据要发送给对方，如果没有的话，那你也就可以close()这个SOCKET并发送FIN报文给对方，即关闭自己到对方这个方向的连接
• FIN-WAIT-2：主动关闭端接到ACK后，就进入了FIN-WAIT-2。在这个状态下，应用程序还有接受数据的能力，但是已经无法发送数据。
• LAST_ACK：当被动关闭的一方在发送FIN报文后，等待对方的ACK报文的时候，就处于LAST_ACK 状态
• CLOSED：当收到对方的ACK报文后，也就可以进入到CLOSED状态了。
• TIME_WAIT：表示收到了对方的FIN报文，并发送出了ACK报文。TIME_WAIT状态下的TCP连接会等待2*MSL
• CLOSING：罕见的状态。表示双方都正在关闭SOCKET连接

TIME_WAIT状态一般用来处理以下两个问题：

• 关闭TCP连接时，确保最后一个ACK正常运输(或者可以认为是：等待以便重传ACK)
• 网络上可能会有残余的数据包，为了能够正常处理这些残余的数据包。使用TIME-WAIT状态可以确保在创建新连接时，先前网络中残余的数据都丢失了。

TIME_WAIT过多怎么解决？

如果在高并发，多短链接情景下，TIME_WAIT就会过多。
可以通过调整内核参数解决：vi /etc/sysctl.conf 加入以下内容设置：

• reuse是表示是否允许重新应用处于TIME-WAIT状态的socket用于新的TCP连接；
• recyse是加速TIME-WAIT sockets回收

我们可以知道TIME_WAIT状态是主动关闭连接的一方出现的，我们不要轻易去使用上边两个参数。先看看是不是可以重用TCP连接来尽量避免这个问题(比如我们HTTP的KeepAlive)~
参考资料：

• TCP/IP详解—TCP连接中TIME_WAIT状态过多：https://blog.csdn.net/yusiguyuan/article/details/21445883
• TCP连接的状态详解以及故障排查：https://blog.csdn.net/hguisu/article/details/38700899

• TCP的11种状态：https://www.cnblogs.com/qingergege/p/6603488.html

  TCP滑动窗口

  TCP是一个可靠的传输协议，它要保证所有的数据包都可以到达，这需要重传机制来支撑。
  重传机制有以下几种：

• 超时重传

• 快速重传
• SACK 方法

滑动窗口可以说是TCP非常重要的一个知识点。TCP的滑动窗口主要有两个作用：

• 提供TCP的可靠性
• 提供TCP的流控特性

简略滑动窗口示意图：

详细滑动窗口示意图：

• 1已收到ack确认的数据。

• 2发还没收到ack的。

• 3在窗口中还没有发出的（接收方还有空间）。

• 4窗口以外的数据（接收方没空间）

接受端控制发送端的图示：

拥塞控制

TCP不是一个自私的协议，当拥塞发生的时候，要做自我牺牲。就像交通阻塞一样，每个车都应该把路让出来，而不要再去抢路了

拥塞控制主要是四个算法：

• 1）慢启动，
• 2）拥塞避免，
• 3）拥塞发生，
• 4）快速恢复

拥塞控制的作用：

拥塞的判断：

• 重传定时器超时
• 收到三个相同（重复）的 ACK

强烈建议阅读：

• TCP 的那些事儿（上）：https://coolshell.cn/articles/11564.html
• TCP 的那些事儿（下）：https://coolshell.cn/articles/11609.html

参考资料：

• TCP连续ARQ协议和滑动窗口协议：https://www.cnblogs.com/blythe/articles/7348812.html
• 运输层
• TCP/IP(十一)TCP滑动窗口和拥塞控制：https://blog.csdn.net/endlu/article/details/51140213
• TCP-IP详解：滑动窗口（Sliding Window）：https://blog.csdn.net/wdscq1234/article/details/52444277
• TCP拥塞控制-慢启动、拥塞避免、快重传、快启动：https://blog.csdn.net/jtracydy/article/details/52366461
• TCP协议的滑动窗口具体是怎样控制流量的？https://www.zhihu.com/question/32255109

TCP粘包，拆包

这是在看wangjingxin大佬面经的时候看到的面试题，之前对TCP粘包，拆包没什么概念，于是就简单去了解一下。

什么是拆包粘包？为什么会出现？

在进行Java NIO学习时，可能会发现：如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况。
TCP的首部格式：

• TCP是基于字节流的，虽然应用层和TCP传输层之间的数据交互是大小不等的数据块，但是TCP把这些数据块仅仅看成一连串无结构的字节流，没有边界；
• 从TCP的帧结构也可以看出，在TCP的首部没有表示数据长度的字段

基于上面两点，在使用TCP传输数据时，才有粘包或者拆包现象发生的可能。
一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包

接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包

拆包和粘包的问题导致接收端在处理的时候会非常困难(因为无法区分一个完整的数据包)

解决拆包和粘包

分包机制一般有两个通用的解决方法：

• 1,特殊字符控制
• 2,在包头首都添加数据包的长度

如果使用netty的话，就有专门的编码器和解码器解决拆包和粘包问题了。

tips:UDP没有粘包问题，但是有丢包和乱序。不完整的包是不会有的，收到的都是完全正确的包。传送的数据单位协议是UDP报文或用户数据报，发送的时候既不合并，也不拆分。

参考资料

• https://blog.csdn.net/scythe666/article/details/51996268--->TCP粘包，拆包及解决方法
• https://blog.csdn.net/kong_lev/article/details/74230978
• http://www.ideawu.net/blog/archives/993.html--->关于TCP粘包和拆包的终极解答

原文地址

• https://www.yuque.com/lobotomy/java/hgpeeg