上海 网站平台开发咖啡设计网站

当前位置： 首页 > news >正文

上海 网站平台开发,咖啡设计网站,青浦营销型网站建设,如何提高用户和网站的互动性一、传输控制协议#xff08;TCP#xff09; 传输控制协议#xff08;Transmission Control Protocol#xff0c;TCP#xff09;是一种面向连接的、可靠的、基于字节流的传输层通信协议#xff0c;由 IETF 的 RFC 793 定义。 它通过三次握手建立连接#xff0c;确保数…一、传输控制协议TCP 传输控制协议Transmission Control ProtocolTCP是一种面向连接的、可靠的、基于字节流的传输层通信协议由 IETF 的 RFC 793 定义。 它通过三次握手建立连接确保数据的可靠传输并提供顺序控制、流量控制和拥塞控制等功能‌。 在简化的计算机网络 OSI 模型中它完成第四层传输层所指定的功能。用户数据报协议UDP是同一层内另一个重要的传输协议。 在因特网协议族Internet protocol suite中TCP 层是位于 IP 层之上应用层之下的中间层。 1.TCP的特点 TCP 是面向连接虚连接的传输层协议。每一条 TCP 连接只能有两个端点每一条 TCP 连接只能是点对点的。TCP 提供可靠交付的服务无差错、不丢失、不重复、按序到达。TCP 提供全双工通信。TCP 面向字节流 2.TCP报文 源端口Source Port16 bits通过一个端口号告诉 TCP 报文来自于哪个进程。目标端口Destination Port16 bits通过一个端口号告诉 TCP 报文要发给哪个进程。序号Sequence Numberseq32 bits在一个 TCP 连接中传送的字节流中的每一个字节都按顺序编号本字段表示本报文段所发送数据的第一个字节的序号 。确认号Acknowledgment Numberack32 bits 期望收到对方下一个报文段的第一个数据字节的序号。若确认号为N则证明到序号N-1为止的所有数据都已正确收到。数据偏移Data OffsetDOffset 4 bitsTCP 报文段的数据起始处距离 TCP 报文段的起始处有多远以4B位单位即1个数值是4B。保留Reserved Rsrvd6 bits须置0。控制位Flags6 bits 紧急位 URGURG1 时标明此报文段中有紧急数据是高优先级的数据应尽快传送不用在缓存里排队配合紧急指针字段使用。复位 RSTRST1 时表明 TCP 连接中出现严重差错必须释放连接然后再重新建立传输链接。确认位 ACKACK1 时确认号有效在连接建立后所有传送的报文段都必须把 ACK 置为 1。推送位 PSHPSH1 时接收方尽快交付接收应用进程不再等到缓存填满再向上交付。同步位 SYNSYN1 时表明是一个连接请求/连接接受报文。终止位 FINFIN1 时表明此报文段发送方数据已发完要求释放连接。 窗口WindowWIN16 bits指的是发送本报文段的一方的接收窗口即现在允许对方发送的数据量。检验和Checksum16 bits检验首部数据检验时要加上 12B 伪首部第四个字段为6。紧急指针Options 16 bitsURG1 时才有意义指出本报文段中紧急数据的字节数。选项Options 最多40 bits最大报文段长度MSS、窗口扩大、时间戳、选择确认… 3.ACK与ack的区别 大写ACK是确认值(Acknowledgement)为1便是确认连接。 小写ack是确认编号(Acknowledgement Number)即接收到的上一次远端主机传来的seq然后1再发送给远端主机。提示远端主机已经成功接收上一次所有数据。 4.TCP连接过程 TCP 是面向连接的客户端与服务器要建立连接才能进行通信通信后需要断开连接。 1三次握手建立连接 假设运行在一台主机客户上的一个进程想与另一台主机服务器上的一个进程建立一条连接客户应用进程首先通知客户 TCP他想建立一个与服务器上某个进程之间的连接客户中的 TCP 会用以下步骤与服务器中的 TCP 建立一条 TCP 连接 第一次握手客户端把 SYN 标志位置为1随机初始化 “序列号” seqx 的数据包到服务器并进入 SYN-SENT 状态服务器由 SYN1 知道客户端要求建立联机此时服务器进入 LISTEN 状态第二次握手服务器收到请求后随机初始化自己的“序列号” seqy“确认应答号” ackx1把 SYN 和 ACK 标志位置为1把该报文发给客户端此时服务器进入进入 SYN-RECEIVED 状态。第三次握手客户端收到服务端报文后将 ACK 标志位置为1“确认应答号” acky1“序列号” seqx1最后把报文发送给服务端这次报文可以携带客户到服务端的数据之后客户端和服务器处于 ESTABLISHED 状态。 2四次挥手关闭连接 参与一条TCP连接的两个进程中的任何一个都能终止该连接连接结束后主机中的“资源”缓存和变量将被释放。 第一次挥手客户端发送一个 FIN1sequ 的数据包到服务端用来关闭客户端到服务器的数据传送。然后客户端进入 FIN-WAIT-1 状态。第二次挥手服务器收到这个数据包它发送一个 ACK标志为1acku1seqv 的数据包到客户端 。然后服务端进入 CLOSE-WAIT 状态客户端进入 FIN-WAIT-2 状态。第三次挥手服务端发送一个 FIN1ACK1seqwacku1 的数据包到客户端请求关闭连接然后服务端进入 LAST-ACK 状态。第四次挥手客户端发送 ACK1ackw1 的数据包到服务端然后客户端进入TIME-WAIT 状态服务端在收到数据包后进入 CLOSE 状态。 此时如果客户端等待 2MSL 后依然没有收到回复就证明服务端已正常关闭随后客户端也可以关闭连接了。 5.滑动窗口 在TCP通信中每次发送数据都需要等待一次确认应答如果在等待前一个数据包的确认时才发送下一个数据包通信效率会变得很低。 为解决这个问题TCP 引入了滑动窗口这个概念。它允许发送方在不接收确认应答的情况下持续发送数据并根据接收方的反馈及时调整数据发送速率。即使在往返时间较长的情况下它也不会降低网络通信的效率。 TCP 报文里有一个字段叫窗口WindowWIN记录着窗口大小的信息窗口大小。 这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收 端的处理能力来发送数据而不会导致接收端处理不过来。 发送方发送的数据大小不能超过接收方的窗口大小否则接收方就无法正常接收到数据。所以通常窗口的大小是由接收方的窗口大小来决定的。 滑动窗口基本概念 SND.WND发送窗口。SND.UNASend Unacknowledged 指针指向发送窗口的第一个字节。SND.NXTSend Next 指针指向可用窗口的第一个字节。可用窗口大小 SND.UNA SND.WND - SND.NXT 。 1发送窗口的工作原理 发送窗口的工作空间根据处理的情况分成四个部分 已发送并收到 ACK确认的数据、已发送但未收到 ACK确认的数据、未发送但总大小在接收方处理范围内接收方还有空间、未发送但总大小超过接收方处理范围接收方没有空间 其中已发送但未收到 ACK确认的数据的部分方框是发送窗口未发送但总大小在接收方处理范围内接收方还有空间的部分是可用窗口。 下面是发送窗口工作原理的示意图在下图中蓝色部分为已发送并收到 ACK确认的数据的子节绿色部分为已发送但未收到 ACK确认的数据黄色部分为未发送但总大小在接收方处理范围内的数据白色部分为未发送但总大小超过接收方处理范围。 下图以滑动窗口大小为 8 为例子 a: 已发送并收到 ACK确认的数据11 ~ 13字节共3个字节 已发送但未收到 ACK确认的数据0个字节 未发送但总大小在接收方处理范围内接收方还有空间的数据14 ~ 21字节共8个字节 未发送但总大小超过接收方处理范围接收方没有空间的数据22字节以后。 b: 已发送并收到 ACK确认的数据11 ~ 13字节共3个字节 已发送但未收到 ACK确认的数据14 ~ 16字节共3个字节 未发送但总大小在接收方处理范围内接收方还有空间的数据17 ~ 21字节共5个字节 未发送但总大小超过接收方处理范围接收方没有空间的数据22字节以后。 c: 已发送并收到 ACK确认的数据11 ~ 15字节共5个字节 已发送但未收到 ACK确认的数据26 ~ 23字节共8个字节 未发送但总大小在接收方处理范围内接收方还有空间的数据0个字节 未发送但总大小超过接收方处理范围接收方没有空间的数据28字节以后。 d: 已发送并收到 ACK确认的数据11 ~ 19字节共9个字节 已发送但未收到 ACK确认的数据20 ~ 23字节共4个字节 未发送但总大小在接收方处理范围内接收方还有空间的数据24 ~ 27字节共4个字节 未发送但总大小超过接收方处理范围接收方没有空间的数据28字节以后。 2接收窗口的工作原理 接收窗口根据处理的情况划分成三个部分 已成功接收并确认的数据等待应用进程读取、 未收到数据但可以接收的数据、未收到数据并不可以接收的数据 上面发送窗口的图d情况中接收窗口的示意图如下 已成功接收并确认等待应用进程读取数据11 ~ 19字节共9个字节 未收到数据但可以接收的数据20 ~ 27字节共8个字节 未收到数据并不可以接收的数据28字节以后。 二、TCP 保证可靠性机制 可靠保证接收方进程从缓存区读出的字节流与发送方发出的字节流是完全一样的。 前文提到 TCP 是可靠的那么 TCP 靠着哪些机制保证了可靠性呢 TCP 主要通过连接管理、序列号、确认应答、重传机制、流量控制、拥塞控制四个机制来保证可靠性的。 1.序列号与确认应答机制 在TCP中通过序列号与确认应答来实现数据的可靠传输。 TCP将每个字节的数据都进行了编号这就是序列号序列号能够保证可靠性和有序性。 接收方接收数据之后会回传ACK报文报文中带有此次确认的序列号用于告知发送方此次接收数据的情况这就是确认应答。 序列号与确认应答机制就是在发送端将数据传输到接收主机时接收主机会根据收到消息的序列号发送一个确认应答消息以表示已成功接收到数据。

1. 重传机制 在错综复杂的网络数据在传输过程中是有可能丢失的所以 TCP 针对数据包丢失的情况会用重传机制解决。 1超时重传 发送方在发送数据时设定一个定时器使用一个保守估计的时间作为收到 ACK 确认应答报文的超时上限。如果超过这个上限仍未收到对方的 ACK 确认应答报文发送方将重传这个数据包。每当发送方收到确认包后会重置这个重传定时器。 TCP 会在以下两种情况发生超时重传数据包丢失、确认应答丢失。 超时重传时间怎么确定 RTTRound Trip Time往返时间指的是数据发送时刻到接收到确认的时刻的差值也就是包的往返时间。RTORetransmission Time Out重传超时时间即从数据发送时刻算起超过这个时间便执行重传。 RTO 的确定是一个关键问题因为它直接影响到 TCP 的性能和效率。当超时时间 RTO 较大时重发就慢丢了老半天才重发没有效率性能差 当超时时间 RTO 较小时会导致可能并没有丢就重发于是重发的就快会增加网络拥塞导致更多的超时更多的超时导致更多的重发。 因此RTO 应该根据网络的实际状况动态地进行调整。 TCP采用了一种自适应算法它记录一个报文段发出的时间以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间 RTT 。TCP保留了 RTT 的一个加权平均往返时间 RTTS这又称为平滑的往返时间S表示 Smoothed。因为进行的是加权平均因此得出的结果更加平滑。每当第一次测量到 RTT 样本时RTT值就取为所测量到的 RTT 样本值。但以后每测量到一个新的 RTT样本就按下式重新计算一次 RTTS: 1首次计算RTO时 R T T S R 1 RTTSR1 RTTS​R1 R T T d e v R 1 / 2 RTT{dev}R1/2 RTTdev​R1/2 R T O μ × R T T S ∂ × R T T d e v μ × R 1 ∂ × R 1 / 2 RTO μ \times RTTS∂ \times RTT{dev}μ \times R1∂ \times R1/2 RTOμ×RTTS​∂×RTTdev​μ×R1∂×R1/2 其中R1 是第一次测量的 RTT 2迭代计算RTO时 R T T S R T T S α × ( R T T − R T T S ) R T T S α × ( R 2 − R 1 ) RTT_SRTT_S α \times(RTT-RTT_S)RTTS α \times(R2 - R1) RTTS​RTTS​α×(RTT−RTTS​)RTTS​α×(R2−R1) R T T d e v ( 1 − β ) × R T T d e v β × ( R T T − R T T S ) RTT{dev}(1-β) \times RTT_{dev}β \times (RTT-RTT_S) RTTdev​(1−β)×RTTdev​β×(RTT−RTTS​) R T O μ × R T T S ∂ × R T T d e v RTO μ \times RTTS∂ \times RTT{dev} RTOμ×RTTS​∂×RTTdev​ 其中R2 是新测量的 RTT RTTS 是计算平滑的 RTT RTTdev 是计算平滑的 RTT 与 最新 RTT 的差距。 在 Linux 下 α 0.125 α 0.125 α0.125 β 0.25 β 0.25 β0.25 μ 1 μ 1 μ1 ∂ 4 ∂ 4 ∂4。是大量实验中调出来的。 2快速重传Fast Retransmit TCP 还有另外⼀种快速重传Fast Retransmit机制它基于接收端的反馈信息来引发重传而非重传计时器超时。 换言之当数据包未连续到达时接收方会针对可能丢失的最后一个包发送 ack 确认。若发送方连续3次接收到相同的ack便会触发重传机制。快速重传的优势在于它无需等待超时即可进行重传从而提高了数据传输的效率。 如上图的例子发送方发出了 12345 份数据 当发送方依次发送了seq序号为1、2、3、4、5的数据包后接收方首先成功接收了seq1并返回了确认ack2请求下一个包即seq2。然而由于某些原因seq2未能到达接收方。随后seq3、seq4、seq5号包均成功送达但接收方依然只能回复ack2因为它仍然期待seq2的到达。发送方在连续三次收到ack2的反馈后识别出2号包可能丢失于是立即重传2号包。在接收方最终收到seq2后鉴于seq3、seq4、seq5号包均已成功接收它随即发送ack6请求下一个期望的包若存在。 快速重传机制解决了超时时间的问题但是它依然面临着另外一个问题。就是重传的时候是重传一个还是重传所有的问题。 3选择确认重传 Selective AcknowledgmentSACK 改进的方法就是选择确认重传 Selective AcknowledgmentSACK。 在TCP头部的选项Options 字段中添加了选择性确认(SACK)选项。通过SACK接收方可以返回最近收到的报文段的序列号范围使发送方能够准确知道哪些数据包已经成功接收哪些数据包尚未到达。 有了这些信息发送端只需重传丢失的数据包而不是整个数据流从而提高了重传的精确性和效率。 如上图的例子 现在先后发送了5个数据包的数据如果此时发送第2个数据包时数据丢失而其余4个数据包都收到了接收方的确认信息那么此时根据SACK可以判断出只有第二个数据包丢失而第1个、第3个、第4个、第5个数据包已被接收此时可以只重新发送第2个数据包。 4DSACK DSACK即重复 SACKDuplicate Selective Acknowledgment这个机制是在 SACK 的基础上额外携带信息告知发送方有哪些数据包自己重复接收了。DSACK 的目的是帮助发送方判断是否发生了包失序、ACK 丢失、包重复或伪重传。让 TCP 可以更好的做网络流控。
2. 流量控制 为避免触发重发机制和避免网络流量浪费发送方需要考虑接收方的处理能力。如果发送方持续发送数据给接收方而后者无法及时处理将导致重发机制触发进而浪费网络资源。为此TCP引入了流量控制机制。 通过流量控制发送方可以根据接收方当前的接收能力来动态调整发送的数据量避免过载接收方而导致数据丢失或延迟从而优化整个网络通信的效率和可靠性。 一句话总结一下流量控制就是让发送方慢点 要让接收方来得及接收。 1流量控制 TCP利用 滑动窗口 机制实现流量控制。 在通信过程中接收方根据自己接收缓存的大小动态地调整发送方的发送窗口大小即接收窗口rwnd接收方设置确认报文段的窗口字段来将rwnd通知给发送方 发送方的发送窗口取接收窗口 rwnd 和拥塞窗口cwnd 的最小值。 例子如下 A向B发送数据连接建立时B告诉A“我的rwnd400字节”设每一个报文段100B报文段序号初始值为1
   2窗口关闭 TCP 通过让接收方指明滑动窗口的大小来进行流量控制。如果窗口大小为 0 时就会阻止发送方给接收方传递数据直到窗口变为非 0 为止这就是窗口关闭。 当窗口关闭时接收方在处理完数据后会发送一个非0窗口大小的ACK报文通知发送方。然而如果这个通告窗口的ACK报文在网络中丢失可能会导致问题。发送方会继续等待ACK确认无法发送新的数据。如不采取措施这种相互等待的过程会造成了死锁的现象。 为了解决上述的死锁问题TCP为每一个连接设有一个持续计时器只要TCP连接的一方收到对方的零窗口通知就启动持续计时器。 若持续计时器设置的时间到期就发送一个零窗口探测 ( Window probe )报文段 。接收方收到探测报文段时给出现在的窗口值。 若窗口仍然是0那么发送方就重新设置持续计时器如果不是0则发送方可以根据窗口的大小继续发送数据死锁的局面就被打破了。 这样通过定时地进行探测就可以避免死锁的产生。
3. 拥塞控制 在网络拥堵时若持续发送大量数据包可能导致数据包时延和丢失。TCP会进行重传然而重传会增加网络负担导致更大的延迟和丢包。这会形成恶性循环不断放大问题。 为了解决此问题就有了拥塞控制的概念拥塞控制是指防止过多的数据注入网络保证网络中的路由器或链路不致过载。 拥塞控制是通过拥塞拥塞窗口实现的。 拥塞窗口cwnd是发送方维护的一个的状态变量它会根据网络的拥塞程度动态变化的。只要网络中没有出现拥塞cwnd 就会增大 但网络中出现了拥塞cwnd 就减少。 常见的拥塞控制算法有慢启动、拥塞避免、快速恢复。 1慢启动Slow Start 在 TCP 刚刚连接好并开始发送TCP报文段时先令拥塞窗口 cwnd1即一个最大报文段长度 MSS。每收到一个对新报文段的确认后将 cwnd 加1即增大一个 MSS。用这样的方法逐步增大发送方的拥塞窗口 cwnd可使分组注入网络的速率更加合理。 例如 A 向 B发送数据发送时 A的拥塞窗口为 1那么A一次可以发送1个 TCP 报文段经过一个RTT后(也称一个传输轮次)A收到B对刚才1个报文的确认于是把拥塞窗口调整为 2下一次发送时就可一次发送2个报文段。 第二轮数据发送时发送时 A的拥塞窗口为 2那么A一次可以发送2个 TCP 报文段经过一个RTT后(也称一个传输轮次)A收到B对刚才2个报文的确认于是把拥塞窗口调整为 4下一次发送时就可一次发送4个报文段。
   2拥塞避免Congestion Avoidance 慢启动算法发包的个数是指数性的增长这样拥塞窗口的增长速度会过快所以需要拥塞避免算法来降低拥塞窗口的增长速度。 拥塞避免算法的做法如下 发送端的拥塞窗口 cwndCongestion Window 每经过一个往返时延 RTT就增加1个 MSS的大小而不是加倍使cwnd 按线性规律缓慢增长(即加法增大)。 可以通过 慢启动门限 ssthreshslow start threshold状态变量来决定慢启动算法和拥塞避免算法的使用。 当 cwndssthresh 时使用慢开始算法。当 cwndssthresh 时停止使用慢开始算法而改用拥塞避免算法。当cwnd ssthresh 时既可使用慢开始算法又可使用拥塞避免算法(通常做法)。 3拥塞发生的处理 网络出现拥塞时无论是在慢开始阶段还是在拥塞避免阶段只要发送方检测到超时事件的发生未按时收到确认重传计时器超时就要采取激烈的应对措施。具体反应如下 将慢启动阈值sshthresh设置为当前拥塞窗口cwnd的一半即 sshthresh cwnd /2。将拥塞窗口cwnd重置为1即 cwnd1。随后进入慢启动过程以逐步恢复数据传输速率。 这样做的目的是迅速减少主机发送到网络中的分组数使得发生拥塞的路由器有足够时间把队列中积压的分组处理完。 拥塞避免并不能完全能避免拥塞。利用以上措施要完全避免网络拥塞是不可能的。拥塞避免是指在拥塞避免阶段把拥塞窗口控制为按线性规律增长使网络比较不容易出现拥塞。 4快速重传Fast Retransmit与快速恢复Fast Recovery 当拥塞发生时如果将拥塞窗口直接设置为1并重新开始慢启动是会突然减少数据流的。但是这种方式太激进了反应也很强烈会造成网络卡顿。所以提出了快速重传算法。 快速重传 如上文的重传机制当丢包的时候会有两种情况超时重传和快速重传。 在拥塞发生时使用“快速重传算法”进行重传更符合需求。当接收端检测到有中间数据包丢失时会连续三次发送对前一个数据包的确认ack从而促使发送端迅速进行重传无需等待超时。TCP协议认为这种情况下的网络拥塞并不严重因为仅丢失了少量数据包。 在发生此类拥塞时的快速重传流程如下 将拥塞窗口cwnd减半即cwnd cwnd/2。将慢启动阈值ssthresh设置为当前的拥塞窗口值即ssthresh cwnd。随后进入快速恢复算法阶段。 快速恢复 RFC5681文档中描述了快速恢复算法。快速重传与快速恢复算法常被并行运用。快速恢复算法的基本思想是当收到三个重复的ack确认时意味着网络状况尚可并未严重恶化因此无需采取像RTO超时那样的严厉措施来应对。 进入快速恢复之前cwnd 和 sshthresh在快速重传算法执行之前已被进行如下更新 cwnd cwnd /2sshthresh cwnd 快速恢复过程概述如下 将拥塞窗口cwnd设置为慢启动阈值sshthresh加3并确认已收到3个数据包即cwnd sshthresh 3 重传之前丢失的数据包当收到 针对重传数据包的确认ack时那么拥塞窗口增加1即cwnd cwnd 1若收到确认新数据的确认ack表明所有重传的数据包均已被成功接收此时将拥塞窗口cwnd重新设置为慢启动阈值sshthresh即cwnd sshthresh并结束快速恢复过程随后进入拥塞避免阶段。 三、用户数据报协议UDP 用户数据报协议User Datagram ProtocolUDP又称用户数据包协议是一个简单的是一种无连接的、不保证可靠的、面向数据包的传输层通信协议位于OSI模型的传输层。 该协议由 David P. Reed 在1980年设计且在RFC 768中被规范。典型网络上的众多使用 UDP 协议的关键应用在一定程度上是相似的。 在 TCP/IP 模型中UDP 为网络层以上和应用层以下提供了一个简单的接口。UDP 只提供数据的不可靠传递它一旦把应用程序发给网络层的数据发送出去就不保留数据备份所以 UDP 有时候也被认为是不可靠的数据包协议。UDP 在 IP 数据包的头部仅仅加入了复用和数据校验字段。
4. UDP 的特点 UDP是无连接的减少开销和发送数据之前的时延。UDP使用最大努力交付即不保证可靠交付 。UDP是面向报文的适合一次性传输少量数据的网络应用。UDP无拥塞控制适合很多实时应用。UDP首部开销小8BTCP20B。
5. UDP 报文 源端口Source Port16 bits通过一个端口号告诉 TCP报文来自于哪个进程。目标端口Destination Port16 bits通过一个端口号告诉 TCP报文要发给哪个进程。包长度Length16 bits该字段保存了 UDP 首部的长度跟数据的长度之和。校验和Checksum16 bits校验和是为了提供可靠的 UDP 首部和数据而设计防止收到在网络传输中受损的 UDP 包。 四、TCP 与 UDP 区别 1.TCP 与 UDP 区别 面向连接TCP 是面向连接的传输层协议传输数据前先要建立连接。UDP 是不需要连接即刻传输数据服务对象TCP 是一对一的两点服务即一条连接只有两个端点。UDP 支持一对一、一对多、多对多的交互通信可靠传输TCP 是可靠交付数据的数据可以无差错、不丢失、不重复、按序到达。UDP 是尽最大努力交付不保证可靠交付数据但是我们可以基于 UDP 传输协议实现一个可靠的传输协议QUIC 协议拥塞控制、流量控制TCP 有拥塞控制和流量控制机制保证数据传输的安全性。UDP 则没有即使网络非常拥堵了也不会影响 UDP 的发送速率传输效率由于使用 TCP 进行传输的时候多了连接、确认、重传等机制所以 TCP 的传输效率要比 UDP 低很多首部开销TCP首部开销20字节。UDP首部开销8字节传输方式TCP 是流式传输没有边界但保证顺序和可靠。UDP 是一个包一个包的发送是有边界的但可能会丢包和乱序。 2.TCP 与 UDP 应用场景 由于 TCP 是面向连接能保证数据的可靠性交付因此经常用于 FTP 文件传输 HTTP / HTTPS由于 UDP 面向无连接它可以随时发送数据再加上 UDP 本身的处理既简单又高效因此经常用于 包总量较少的通信如 DNS 、SNMP 等 视频、音频等多媒体通信 广播通信