网络协议之TCP、UDP

在讲TCP、UDP协议之前，我们有必要了解一下网络分层模型，目前常见的网络分层模型分为两种：OSI参考模型和TCP/IP模型。

OSI参考模型（七层）

国际标准化组织ISO为了使网络应用更为普及，推出了OSI参考模型，即开放式系统互联（Open
System Interconnect）模型，一般都叫OSI参考模型。OSI参考模型是ISO组织在1985年发布的网络互连模型，其含义就是为所有公司使用一个统一的规范来控制网络，这样所有公司遵循相同的通信规范，网络就能互联互通了。

OSI模型定义了网络互连的七层框架（物理层、数据链路层、网络层、传输层、会话层、表示层、应用层），每一层实现各自的功能和协议，并完成与相邻层的接口通信。OSI模型各层的通信协议，大致举例如下表所示：

名称	支持的协议
应用层	HTTP、SMTP、SNMP、FTP、Telnet、SIP、SSH、NFS、RTSP、XMPP、Whois、ENRP、等等
表示层	XDR、ASN.1、SMB、AFP、NCP、等等
会话层	ASAP、SSH、RPC、NetBIOS、ASP、Winsock、BSD Sockets、等等
传输层	TCP、UDP、TLS、RTP、SCTP、SPX、ATP、IL、等等
网络层	IP、ICMP、IGMP、IPX、BGP、OSPF、RIP、IGRP、EIGRP、ARP、RARP、X.25、等等
数据链路层	以太网、令牌环、HDLC、帧中继、ISDN、ATM、IEEE 802.11、FDDI、PPP、等等
物理层	例如铜缆、网线、光缆、无线电等等

• 应用层（数据）：确定进程之间通信的性质以满足用户需要以及提供网络与用户应用
• 表示层（数据）：主要解决用户信息的语法表示问题，如加密解密
• 会话层（数据）：提供包括访问验证和会话管理在内的建立和维护应用之间通信的机制，如服务器验证用户登录便是由会话层完成的
• 传输层（段）：实现网络不同主机上用户进程之间的数据通信，可靠与不可靠的传输，传输层的错误检测，流量控制等
• 网络层（包）：提供逻辑地址（IP）、选路，数据从源端到目的端的传输
• 数据链路层（帧）：将上层数据封装成帧，用MAC地址访问媒介，错误检测与修正
• 物理层（比特流）：设备之间比特流的传输，物理接口，电气特性等

TCP/IP模型（四层）

TCP/IP协议是Internet互联网最基本的协议，其在一定程度上参考了七层ISO模型。OSI模型共有七层，从下到上分别是物理层、数据链路层、网络层、运输层、会话层、表示层和应用层。但是这显然是有些复杂的，所以在TCP/IP协议中，七层被简化为了四个层次。TCP/IP模型中的各种协议，依其功能不同，被分别归属到这四层之中，常被视为是简化过后的七层OSI模型。

TCP/IP协议与七层ISO模型的对应关系：

TCP/IP协议的应用层的主要协议有HTTP、Telnet、FTP、SMTP等，是用来读取来自传输层的数据或者将数据传输写入传输层；传输层的主要协议有UDP、TCP，实现端对端的数据传输；网络层的主要协议有ICMP、IP、IGMP，主要负责网络中数据包的传送等；链路层有时也称作数据链路层或网络接口层，主要协议有ARP、RARP，通常包括操作系统中的设备驱动程序和计算机中对应的网络接口卡，它们一起处理与传输媒介（如电缆或其他物理设备）的物理接口细节。

• TCP/IP协议的应用层
  应用层包括所有和应用程序协同工作，并利用基础网络交换应用程序的业务数据的协议。一些特定的程序被认为运行在这个层上，该层协议所提供的服务能直接支持用户应用。应用层协议包括HTTP（万维网服务）、FTP（文件传输）、SMTP（电子邮件）、SSH（安全远程登陆）、DNS（域名解析）以及许多其他协议。

• TCP/IP协议的传输层
  传输层的协议，解决了诸如端到端可靠性问题，能确保数据可靠的到达目的地，甚至能保证数据按照正确的顺序到达目的地。传输层的主要功能大致如下：
  1：为端到端连接提供传输服务；
  2： 这种传输服务分为可靠和不可靠的，其中TCP是典型的可靠传输，而UDP则是不可靠传输；
  3：为端到端连接提供流量控制、差错控制、QoS(Quality ofService)服务质量等管理服务。
  传输层主要有两个性质不同的协议：TCP传输控制协议和UDP用户数据报协议。
  TCP协议是一个面向连接的、可靠的传输协议，它提供一种可靠的字节流，能保证数据完整、无损并且按顺序到达。TCP尽量连续不断地测试网络的负载并且控制发送数据的速度以避免网络过载。另外，TCP试图将数据按照规定的顺序发送。
  UDP协议是一个无连接的数据报协议，是一个“尽力传递”和“不可靠”协议，不会对数据包是否已经到达目的地进行检查，并且不保证数据包按顺序到达。
  总体来说，TCP协议传输效率低，但可靠性强；UDP协议传输效率高，但可靠性略低，适用于传输可靠性要求不高、体量小的数据（比如QQ聊天数据）。

• TCP/IP协议的网络层
  TCP/IP协议网络层的作用是在复杂的网络环境中为要发送的数据报找到一个合适的路径进行传输。简单来说，网络层负责将数据传输到目标地址，目标地址可以是多个网络通过路由器连接而成的某一个地址。另外，网络层负责寻找合适的路径到达对方计算机，并把数据帧传送给对方，网络层还可以实现拥塞控制、网际互连等功能。网络层协议的代表包括：ICMP、IP、IGMP等。

• TCP/IP协议的链路层
  链路层有时也称作数据链路层或网络接口层，用来处理连接网络的硬件部分。该层既包括操作系统硬件的设备驱动、NIC（网卡）、光纤等物理可见部分，还包括连接器等一切传输媒介。在这一层，数据的传输单位为比特。其主要协议有ARP、RARP等。

TCP协议

在TCP/IP协议栈中，IP协议层只关心如何使数据能够跨越本地网络边界的问题，而不关心数据如何传输。整体TCP/IP协议栈共同配合一起解决数据如何通过许许多多个点对点通路，顺利传输到达目的地的问题。一个点对点通路被称为一“跳”（hop），通过TCP/IP协议栈，网络成员能够在许多“跳”的基础上建立相互的数据通路。

TCP（Transmission Control Protocol，传输控制协议）是面向连接的，可靠的字节流服务协议。所以，在发送数据前，发送方必须和接收方建立可靠的连接。一个TCP连接必须要经过三次“对话”（也称“三次握手”）才能建立起来，其中的过程非常复杂。

TCP协议的数据帧格式

TCP协议的数据帧格式如下图：

传输层TCP协议的数据帧，大致包含的字段：

• 源端口号
  源端口号表示报文的发送端口，占16位。源端口和源IP地址组合起来，可以标识报文的发送地址。

• 目的端口号
  目的端口号表示报文的接收端口，占16位。目的端口和目的IP地址相结合，可以标识报文的接收地址。
  TCP协议是基于IP协议的基础上传输的，TCP报文中的源端口号+源IP，与TCP报文中的目的端口号+目的IP一起，组合起来唯一性的确定一条TCP连接。

• 序号（Sequence Number）
  TCP传输过程中，在发送端出的字节流中，传输报文中的数据部分的每一个字节都有它的编号。序号（Sequence Number）占32位，发起方发送数据时，都需要标记序号。
  序号（Sequence Number）的语义与SYN控制标志（ControlBits）的值有关。根据控制标志（Control Bits）中的SYN是否为1，序号（SequenceNumber）表达不同的含义：

  • 当SYN = 1时，当前为连接建立阶段，此时的序号为初始序号ISN((Initial Sequence Number)，通过算法来随机生成序号；
  • 当SYN = 0时在数据传输正式开始时，第一个报文的序号为 ISN +1，后面的报文的序号，为前一个报文的SN值+TCP报文的净荷字节数(不包含TCP头)。比如，如果发送端发送的一个TCP帧的净荷为12byte，序号为5，则发送端接着发送的下一个数据包的时候，序号的值应该设置为5+12=17。
    在数据传输过程中，TCP协议通过序号（Sequence Number）对上层提供有序的数据流。发送端可以用序号来跟踪发送的数据量；接收端可以用序号识别出重复接收到的TCP包，从而丢弃重复包；对于乱序的数据包，接收端也可以依靠序号对其进行排序。

• 确认序号（Acknowledgment Number）
  确认序号（Acknowledgment Number）标识了报文接收端期望接收的字节序列。如果设置了ACK控制位，确认序号的值表示一个准备接收的包的序列码，注意，它所指向的是准备接收的包，也就是下一个期望接收的包的序列码。
  举个例子，假设发送端（如Client）发送3个净荷为1000byte、起始SN序号为1的数据包给Server服务端，Server每收到一个包之后，需要回复一个ACK响应确认数据包给Client。ACK响应数据包的ACK
  Number值，为每个Client包的为SN+包净荷，既表示Server已经确认收到的字节数，还表示期望接收到的下一个Client发送包的SN序号，具体的ACK值如下图左边的正常传输部分所示。

• 头部长度
  该字段占用4位，用来表示TCP报文首部的长度，单位是4bit位。其值所表示的并不是字节数，而是头部的所含有的32bit的数目（或者倍数），或者4个字节的倍数，所以TCP头部最多可以有60字节（4*15=60）。没有任何选项字段的TCP头部长度为20字节，所以其头部长度为5，可以通过20/4=5计算得到。

• 预留6位
  头部长度后面预留的字段长度为6位，作为保留字段，暂时没有什么用处。

• 控制标志
  控制标志（Control
  Bits）共6个bit位，具体的标志位为：URG、ACK、PSH、RST、SYN、FIN。6个标志位的说明，如下表所示：

标志位	说明
URG	占1位，表示紧急指针字段有效。URG位指示报文段里的上层实体（数据）标记为“紧急”数据。当URG=1时，其后的紧急指针指示紧急数据在当前数据段中的位置(相对于当前序列号的字节偏移量)，TCP接收方必须通知上层实体。
ACK	占1位，置位ACK=1表示确认号字段有效；TCP协议规定，接建立后所有发送的报文的ACK必须为1；当ACK=0时，表示该数据段不包含确认信息。当ACK=1时，表示该报文段包括一个对已被成功接收报文段的确认序号Acknowledgment Number，该序号同时也是下一个报文的预期序号。
PSH	占1位，表示当前报文需要请求推（push）操作；当PSH=1时，接收方在收到数据后立即将数据交给上层，而不是直到整个缓冲区满。
RST	占1位，置位RST=1表示复位TCP连接；用于重置一个已经混乱的连接，也可用于拒绝一个无效的数据段或者拒绝一个连接请求。如果数据段被设置了RST位，说明报文发送方有问题发生。
SYN	占1位，在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文。对方若同意建立连接，则应在响应报文中使SYN=1和ACK=1。 综合一下，SYN置1就表示这是一个连接请求或连接接受报文。
FIN	占1位，用于在释放TCP连接时，标识发送方比特流结束，用来释放一个连接。当 FIN = 1时，表明此报文的发送方的数据已经发送完毕，并要求释放连接。

在连接建立的三次握手过程中，若只是单个SYN置位，表示的只是建立连接请求。如果SYN和ACK同时置位为1，表示的建立连接之后的响应。

• 窗口大小
  长度为16位，共2个字节。此字段用来进行流量控制。流量控制的单位为字节数，这个值是本端期望一次接收的字节数。

• 校验和
  长度为16位，共2个字节。对整个TCP报文段，即TCP头部和TCP数据进行校验和计算，接收端用于对收到的数据包进行验证。

• 紧急指针
  长度为16位，2个字节。它是一个偏移量，和SN序号值相加表示紧急数据最后一个字节的序号。
  以上十项内容是TCP报文首部必须的字段，也称固有字段，长度为20个字节。接下来是TCP报文的可选项和填充部分。

• 可选项和填充部分
  可选项和填充部分的长度为4n字节（n是整数），该部分是根据需要而增加的选项。如果不足4n字节，要加填充位，使得选项长度为32位（4字节）的整数倍，具体的做法是在这个字段中加入额外的零，以确保TCP头是32位（4字节）的整数倍。
  最常见的选项字段是MSS（Maximum Segment Size最长报文大小），每个连接方通常都在通信的第一个报文段（SYN标志为1的那个段）中指明这个选项字段，表示当前连接方所能接受的最大报文段的长度。
  由于可选项和填充部分不是必须的，所以TCP报文首部最小长度为20个字节。

至此，TCP报文首部的字段，就全部介绍完了。TCP报文首部的后面，接着的是数据部分，不过数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有TCP首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据，比如在处理超时的过程中，也会发送不带任何数据的报文段。

TCP协议的可靠性，主要通过以下几点来保障：

• 应用数据分割成TCP认为最适合发送的数据块。这部分是通过MSS（最大数据包长度）选项来控制的，通常这种机制也被称为一种协商机制，MSS规定了TCP传往另一端的最大数据块的长度。值得注意的是，MSS只能出现在SYN报文段中，若一方不接收来自另一方的MSS值，则MSS就定为536字节。一般来讲，MSS值还是越大越好，这样可以提高网络的利用率。
• 重传机制。设置定时器，等待确认包，如果定时器超时还没有收到确认包，则报文重传。
• 对首部和数据进行校验。
• 接收端对收到的数据进行排序，然后交给应用层。
• 接收端丢弃重复的数据。
• TCP还提供流量控制，主要是通过滑动窗口来实现流量控制。

TCP协议三次握手

三次握手图解：

三次握手过程解析：

1. 第一次握手
   Client进入SYN_SENT状态，发送一个SYN帧（可以当做是请求帧）来主动打开传输通道，该帧的SYN标志位被设为1，同时会带上Client分配好的SN序列号（seq），该SN是根据时间产生的一个随机值，通常情况下每间隔4ms会加1。除此之外，SYN帧还会带一个MSS（最大报文段长度）可选项的值，表示客户端发送出去的最大数据块的长度。
2. 第二次握手
   Server端在收到SYN帧之后，会进入SYN_RCVD状态，同时返回SYN+ACK帧给Client，主要目的在于通知Client，Server端已经收到SYN消息，现在需要Client进行确认。Server端发出的SYN+ACK帧的ACK标志位被设置为1，其确认序号AN（Acknowledgment Number）值被设置为Client的SN+1；SYN+ACK帧的SYN标志位被设置为1，SN值为Server端生成的SN序号；SYN+ACK帧的MSS（最大报文段长度）表示的是Server端的最大数据块长度。
3. 第三次握手
   Client在收到Server的第二次握手SYN+ACK确认帧之后，首先将自己的状态从SYN_SENT变成ESTABLISHED，表示自己一侧的连接通道已经建立成功，Client可以发送数据给Server端了。然后，Client发ACK帧给Server端，该ACK帧的ACK标志位被设置为1，其确认序号AN（Acknowledgment Number）值被设置为Server端的SN序列号+1。还有一种情况，Client可能会将ACK帧和第一帧要发送的数据，合并到一起发送给Server端。
   Server端在收到Client的ACK帧之后，会从SYN_RCVD状态会进入ESTABLISHED状态，至此，Server方向的通道连接建立成功，Server可以发送数据给Client，TCP的全双工连接建立完成。

TCP协议四次挥手

业务数据通信完成之后，TCP连接开始断开（或者拆接），在这个过程中连接的每个端的都能独立地、主动的发起，TCP协议断开的过程使用了四路挥手操作：

四次挥手过程解析：

• 第一次挥手
  主动断开方（可以是客户端，也可以是服务器端），向对方发送一个FIN结束请求报文，此报文的FIN位被设置为1，并且正确设置Sequence Number（序列号）和Acknowledgment Number（确认号）。发送完成后，主动断开方进入FIN_WAIT_1状态，这表示主动断开方没有业务数据要发送给对方，准备关闭SOCKET连接了。

• 第二次挥手
  正常情况下，在收到了主动断开方发送的FIN断开请求报文后，被动断开方会发送一个ACK响应报文，报文的Acknowledgment Number（确认号）值为断开请求报文的Sequence Number（序列号）加1，该ACK确认报文的含义是：“我同意你的连接断开请求”。之后，被动断开方就进入了CLOSE-WAIT（关闭等待）状态，TCP协议服务会通知高层的应用进程，对方向本地方向的连接已经关闭，对方已经没有数据要发送了，若本地还要发送数据给对方，对方依然会接受。被动断开方的CLOSE-WAIT（关闭等待）还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
  主动断开方在收到了ACK报文后，由FIN_WAIT_1转换成FIN_WAIT_2状态。

• 第三次挥手
  在发送完成ACK报文后，被动断开方还可以继续完成业务数据的发送，待剩余数据发送完成后，或者CLOSE-WAIT（关闭等待）截止后，被动断开方会向主动断开方发送一个FIN+ACK结束响应报文，表示被动断开方的数据都发送完了，然后，被动断开方进入LAST_ACK状态。

• 第四次挥手
  主动断开方收在到FIN+ACK断开响应报文后，还需要进行最后的确认，向被动断开方发送一个ACK确认报文，然后，自己就进入TIME_WAIT状态，等待超时后最终关闭连接。处于TIME_WAIT状态的主动断开方，在等待完成2MSL的时间后，如果期间没有收到其他报文，则证明对方已正常关闭，主动断开方的连接最终关闭。
  被动断开方在收到主动断开方的最后的ACK报文以后，最终关闭了连接。

TCP常见问题

问题：为什么连接建立的时候是三次握手，可以改成两次握手吗？
答：三次握手完成两个重要的功能：一是双方都做好发送数据的准备工作，而且双方都知道对方已准备好；二是双方完成初始SN序列号的协商，双方的SN序列号在握手过程中被发送和确认。

如果把三次握手改成两次握手，可能发生死锁。两次握手的话，缺失了Client的二次确认ACK帧。

在假想的TCP建立的连接是二次握手过程中，Client发送Server发送一个SYN请求帧，Server收到后发送了确认应答SYN+ACK帧。按照两次握手的协定，Server认为连接已经成功地建立了，可以开始发送数据帧。这个过程中，如果确认应答SYN+ACK帧在传输中被丢失，Client没有收到，Client将不知道Server是否已准备好，也不知道Server的SN序列号，Client认为连接还未建立成功，将忽略Server发来的任何数据分组，会一直等待Server的SYN+ACK确认应答帧。而Server在发出的数据帧后，一直没有收到对应的ACK确认后就会产生超时，重复发送同样的数据帧，这样就形成了死锁。

问题：为什么关闭连接的需要四次挥手，而建立连接却只要三次握手呢？

答：关闭连接时，被动断开方在收到对方的FIN结束请求报文时，很可能业务数据没有发送完成，并不能立即关闭连接，被动方只能先回复一个ACK响应报文，告诉主动断开方：“你发的FIN报文我收到了，只有等到我所有的业务报文都发送完了，我才能真正的结束，在结束之前，我会发你FIN+ACK报文的，你先等着”。所以，被动断开方的确认报文，需要拆开成为两步，故总体就需要四步挥手。

而在建立连接场景中，Server端的应答可以稍微简单一些。当Server端收到Client端的SYN连接请求报文后，其中ACK报文表示对请求报文的应答，SYN报文用来表示服务端的连接也已经同步开启了，而ACK报文和SYN报文之间，不会有其他报文需要发送，故而可以合二为一，可以直接发送一个SYN+ACK报文。所以，在建立连接时，只需要三次握手即可。

问题：为什么主动断开方在TIME-WAIT状态必须等待2MSL的时间？

答：原因之一：主动断开方等待2MSL的时间，是为了确保两端都能最终关闭。假设网络是不可靠的，被动断开方发送FIN+ACK报文后，其主动方的ACK响应报文有可能丢失，这时候的被动断开方处于LAST-ACK状态的，由于收不到ACK确认被动方一直不能正常的进入CLOSED状态。在这种场景下，被动断开方会超时重传FIN+ACK断开响应报文，如果主动断开方在2MSL时间内，收到这个重传的FIN+ACK报文，会重传一次ACK报文，后再一次重新启动2MSL计时等待，这样，就能确保被动断开方能收到ACK报文，从而能确保被动方顺利进入到CLOSED状态。只有这样，双方都能够确保关闭。反过来说，如果主动断开方在发送完ACK响应报文后，不是进入TIME_WAIT状态去等待2MSL时间，而是立即释放连接，则将无法收到被动方重传的FIN+ACK报文，所以不会再发送一次ACK确认报文，此时处于LAST-ACK状态的被动断开方，无法正常进入到CLOSED状态。

原因之二：防止“旧连接的已失效的数据报文”出现在新连接中。主动断开方在发送完最后一个ACK报文后，再经过2MSL，才能最终关闭和释放端口，这就意味着，相同端口的新TCP新连接，需要在2MSL的时间之后，才能够正常的建立。2MSL这段时间内，旧连接所产生的所有数据报文，都已经从网络中消失了，从而，确保了下一个新的连接中不会出现这种旧连接请求报文。

有关2MSL的补充信息：
2MSL翻译过来就是两倍的MSL。MSL全称为Maximum Segment Lifetime，指的是一个TCP报文片段在网络中最大的存活时间，具体来说，2MSL对应于一次消息的来回（一个发送和一个回复）所需的最大时间。如果直到2MSL，主动断开方都没有再一次收到对方的报文（如FIN报文），则可以推断ACK已经被对方成功接收，此时，主动断开方将最终结束自己的TCP连接。所以，TCP的TIME_WAIT状态也称为2MSL等待状态。
有关MSL的具体的时间长度，在RFC1122协议中推荐为2分钟。在SICS（瑞典计算机科学院）开发的一个小型开源的TCP/IP协议栈——LwIP开源协议栈中MSL默认为1分钟。在源自Berkeley的TCP协议栈实现中MSL默认长度为30秒。总体来说，TIME_WAIT（2MSL）等待状态的时间长度，一般维持在1-4分钟之间。

问题：建立TCP连接后，Client端突然出现故障了怎么办？

答：TCP设有一个保活计时器，Client端如果出现故障，Server端不能一直等下去，这样会浪费系统资源。每收到一次Client客户端的数据帧后，Server端都的保活计时器会复位。计时器的超时时间通常是设置为2小时，若2小时还没有收到Client端的任何数据帧，Server端就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，Server端就认为Client端出了故障，接着就关闭连接。如果觉得保活计时器的两个多小时的间隔太长，可以自行调整TCP连接的保活参数。

问题：三次握手过程中有哪些不安全性？
答：可能会出现SYN洪泛攻击，DOS攻击（拒绝服务攻击），死亡值ping。

TCP粘包、拆包

什么是TCP粘包和拆包

我们知道，TCP传输协议面向流的，没有消息保护边界，并且TCP出于性能的考虑，会将多次间隔较小且数据量小的数据包进行封包后放到发送缓存区一次性发送，这样会使数据传输更高效。但这会出现下面的两种情况：
第一种情况：当发送方连续发送的多个数据量较小的数据包，进行封包发送后，由于TCP的数据包没有边界，这样接收方就很难区分开这些数据包的，这就是粘包
第二种情况当发送方发送了一个较大的数据包（大小超过了发送缓冲区的大小）时，就会对这个数据包进行拆分，然后分多次发送这就是拆包。

TCP拆包和粘包出现的原因

TCP出现粘包、拆包的原因，简单的归纳就是：

• 要发送的数据大于 TCP 发送缓冲区剩余空间大小，将会发生拆包。
• 待发送数据大于 MSS（最大报文长度），TCP 在传输前将进行拆包。
• 要发送的数据小于 TCP 发送缓冲区的大小，TCP 将多次写入缓冲区的数据一次发送出去，将会发生粘包。
• 接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包

详见TCP发生粘包、拆包的原因

TCP拆包和粘包的解决方案

无论是粘包还是拆包，接收端都无法正常的解析出正确的数据包，就是很严重的问题。必须想办法解决。

由于 TCP 本身是面向字节流的，无法理解上层的业务数据，所以在底层是无法保证数据包不被拆分和重组的，这个问题只能通过上层的应用协议栈设计来解决，业界主流协议的解决方案，如下

• 消息定长：发送端将每个数据包封装为固定长度（不够的可以通过补 0 填充），这样接收端每次接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。
• 设置消息边界：服务端从网络流中按消息边界分离出消息内容。在包尾增加回车换行符进行分割，例如 FTP 协议。
• 将消息分为消息头和消息体：消息头中包含表示消息总长度（或者消息体长度）的字段。
• 更复杂的应用层协议比如 Netty 中实现的一些协议都对粘包、拆包做了很好的处理。

问题：为什么TCP有粘包和拆包的问题而UDP没有

答：由上文可知，UDP是基于报文发送的，UDP首部采用了 16bit 来指示 UDP 数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。

而 TCP 是基于字节流的，应用层和TCP传输层之间的数据交互是大小不等的数据块，而TCP并没有把这些数据块区分边界，仅仅是一连串没有结构的字节流。另外，从 TCP 的帧结构也可以看出，在 TCP 的首部没有表示数据长度的字段，基于上面两点，在使用 TCP 传输数据时，才有粘包或者拆包现象发生的可能。

问题：TCP 滑动窗口是什么？
答：窗口是缓存的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。

发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。

接收窗口只会对窗口内最后一个按序到达的字节进行确认，例如接收窗口已经收到的字节为 {31, 34, 35}，其中 {31} 按序到达，而 {34, 35} 就不是，因此只对字节 31 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收。

问题：TCP 如何进行流量控制的？
答：流量控制是为了控制发送方发送速率，保证接收方来得及接收。
接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。
实际上，为了避免此问题的产生，发送端主机会时不时的发送一个叫做窗口探测的数据段，此数据段仅包含一个字节来获取最新的窗口大小信息。

UDP 协议

UDP（User Data Protocol，用户数据报协议），是与 TCP 相对应的协议。它是面向非连接的协议，它不与对方建立连接，而是直接就把数据包发送过去。

UDP协议的特点

• UDP 是无连接的。UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态（这里面有许多参数）。
• UDP 是面向报文的。
• UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低。

TCP协议与UDP协议的比较

TCP协议与UDP协议的区别

• TCP 是面向连接的；UDP 是无连接的。
• TCP 是可靠的；UDP 是不可靠的。
• TCP 只支持点对点通信；UDP 支持一对一、一对多、多对一、多对多的通信模式。
• TCP 是面向字节流的；UDP 是面向报文的。
• TCP 有拥塞控制机制；UDP 没有拥塞控制，适合媒体通信。
• TCP 首部开销(20 个字节)，比 UDP 的首部开销(8 个字节)要大。

UDP 协议和TCP协议的数据首部格式的区别

UDP首部格式：

TCP首部格式：

自己对比区别，不在累述：