网络面试-0x12 UDP和TCP的区别以及应用场景

一、 UDP （user datagram protocol）用户数据报协议

①： 一种简单的面向数据报的通讯协议，即：应用层传下来的报文，不合并，不拆分，只是在其上面加上首部后就交给了下面的网络层。无论应用层交给UDP多长的报文，它统统发送，一次发送一个报文。
②： 接收方，接到后直接去除首部，交给上面的应用层就完成任务
③：UDP报头包含4个字段，每个字段占用2个字节，标题段，开销小

特点： 1）UDP不提供复杂的控制机制，利用IP提供面向无连接的通讯服务 —— 连接
2）传输途中出现丢包， UDP也不负责重发 —— 丢包不处理
3）当报的到达顺序出现乱序时，UDP没有纠正的能力 —— 无纠正能力
4）接收方接收到数据的那一刻，立即按照原样发送到网络上的一种机制。即使是出现网络拥堵的情况，UDP 也无法进行流量控制等避免网络拥塞的行为。 —— 网络拥塞无法处理

1、UDP为什么不可靠？ bind和connect对于UDP的作用是什么？

UDP 只有一个socket接受缓冲区，没有socket发送缓存区。 即为：只要有数据就发，不管对方是否可以正确接收。而在对方的 socket 接收缓冲区满了之后，新来的数据报无法进入到 socket 接受缓冲区，此数据报就会被丢弃，因此 UDP 不能保证数据能够到达目的地，此外，UDP 也没有流量控制和重传机制，故UDP的数据传输是不可靠的。

connect: 和 TCP 建立连接时采用三次握手不同，UDP 中调用 connect 只是把对端的 IP 和 端口号记录下来，并且 UDP 可多多次调用 connect 来指定一个新的 IP 和端口号，或者断开旧的 IP 和端口号（通过设置 connect 函数的第二个参数）。和普通的 UDP 相比，调用 connect 的 UDP 会提升效率，并且在高并发服务中会增加系统稳定性。

bind: 当 UDP 的发送端调用 bind 函数时，就会将这个套接字指定一个端口，若不调用 bind 函数，系统内核会随机分配一个端口给该套接字。当手动绑定时，能够避免内核来执行这一操作，从而在一定程度上提高性能。

二、 TCP （Transmissioin Control Protocl）传输控制协议

①：一种可靠、面向字节流的通讯协议，把上面应用层交下来的数据看成无结构的字节流来发送。
②：可以想象成为流水形式，发送方TCP 会将数据放入“蓄水池”（缓存区），等到可以发送的时候发送，不能发送就等着。
③：TCP会根据网络的拥塞状态来确定每个报文段的大小。
④：报文首部有20个字节，额外开销大。

TCP结构 源端口和目的端口：它用于多路复用/分解来自或送往上层应用的数据，其和IP数据报中的源IP与目的IP地址一同确定一条TCP连接。
序号和确认号字段：序号是本报文段发送的数据部分中第一个字节的编号，在 TCP 传送的流中，每一个字节一个序号。例如一个报文段的序号为 100，此报文段数据部分共有 100 个字节，则下一个报文段的序号为 200。序号确保了 TCP 传输的有序性。确认号，即 ACK，指明下一个想要收到的字节序号，发送 ACK 时表明当前序号之前的所有数据已经正确接收。这两个字段的主要目的是保证数据可靠传输。
首部长度：该字段指示了以 32 比特的字为单位的 TCP 的首部长度。其中固定字段长度为 20 字节，由于首部长度可能含有可选项内容，因此 TCP 报头的长度是不确定的，20 字节是 TCP 首部的最小长度。
保留：为将来用于新的用途而保留。
控制位：

URG 表示紧急指针标志，该位为 1 时表示紧急指针有效，为 0 则忽略；
ACK 为确认序号标志，即相应报文段包括一个对已被成功接收报文段的确认；
PSH 为 push 标志，当该位为 1 时，则指示接收方在接收到该报文段以后，应尽快将这个报文段交给应用程序，而不是在缓冲区排队；
RST 为重置连接标志，当出现错误连接时，使用此标志来拒绝非法的请求；
SYN 为同步序号，在连接的建立过程中使用，例如三次握手时，发送方发送 SYN 包表示请求建立连接；
FIN 为 finish 标志，用于释放连接，为 1 时表示发送方已经没有数据发送了，即关闭本方数据流。

接收窗口：主要用于 TCP 流量控制。该字段用来告诉发送方其窗口（缓冲区）大小，以此控制发送速率，从而达到流量控制的目的。
校验和：奇偶校验，此校验和是对整个 TCP 报文段，包括 TCP 头部和 数据部分。该校验和是一个端到端的校验和，由发送端计算和存储，并由接收端进行验证，主要目的是检验数据是否发生改动，若检测出差错，接收方会丢弃该 TCP 报文。
紧急数据指针：紧急数据用于告知紧急数据所在的位置，在URG标志位为 1 时才有效。当紧急数据存在时，TCP 必须通知接收方的上层实体，接收方会对紧急模式采取相应的处理。
选项：该字段一般为空，可根据首部长度进行推算。主要有以下作用：

① TCP 连接初始化时，通信双方确认最大报文长度。
② 在高速数据传输时，可使用该选项协商窗口扩大因子。
③ 作为时间戳时，提供一个 较为精准的 RTT。

数据：TCP 报文中的数据部分也是可选的，例如在 TCP 三次握手和四次挥手过程中，通信双方交换的报文只包含头部信息，数据部分为空，只有当连接成功建立后，TCP 包才真正携带数据。

特点： 1）TCP充分地实现了数据传输时各种控制功能，可以进行丢包时重发控制，还可以对次序乱掉的分包进行顺序控制，而这些在UDP中都没有 —— 丢包处理、纠正处理
2）TCP是面向连接的协议，只有确认通讯对端存在时才会发送数据，从而可以控制通信流量的浪费 —— 可避免拥塞的控制
3）根据TCP这些机制，IPO这种无连接的网络上也能够实现高可靠性的通讯（主要通过：校验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现）—— 基于无连接的IP进行高可靠的协议的需要处理的

1、TCP的定[计]时器

TCP有 7 中计时器：

1. 建立连接定时器：该定时器是在建立TCP连接的时候使用的，在TCP三次握手的过程中，发送方发送SYN时，会启动一个定时器(默认为3秒)，若SYN包丢失了，那么3秒以后会重新发送SYN包直到达到重传的次数。
   
2. 重传定时器：该计时器主要用于TCP超时重传机制中， 当TCP发送报文段时，就会创建特定报文的重传计时器，并可能出现两种情况：

①：若在计时器截止之前发送方收到的ACK报文，则撤销该计时器。
②：若计时器截止时间内并没有收到接收方的ACK报文，则发送方重传报文，并将计时器复位。

3. 坚持计时器：TCP通过让接收方指明希望从发送方接受的数据字节数(窗口大小)来进行流量控制，当接收端的接收窗口满时，接收端会告诉发送端此时窗口已满，请停止发送数据。此时，发送端和接收端的窗口大小均为0，直到窗口变为非0时，接收端将发送一个确认ACK告诉发送端可以再次发送数据，但是该报文有可能在传输时丢失。若该ACK报文丢失，则双方可能会一直等待下去，为了避免这种死锁情况，发送方使用一个坚持定时器来周期性的向结合搜发发送探测报文段，以查看接受方窗口是否变大。 —— 发送方和接收方窗口都是0，若是接收方窗口变成了非0，发送一个ack给发送端，但是丢失了，从而产生了客户端轮询的定时器 ——> 坚持计时器
4. 延迟应答计时器：【又称捎带ACK】， 在延迟应答的时候使用的。 为了提高网络传输的效率，当服务器接收到客户端的数据后，不是立即回ACK给客户端，而是等一段时间，这样如果服务端有数据需要发送给客户端的话，就可以把数据和ACK一起发送给客户端了。
5. 保活定时器：该定时器是在建立 TCP 连接时指定 SO_KEEPLIVE 时才会生效，当发送方和接收方长时间没有进行数据交互时，该定时器可以用于确定对端是否还活着。
6. FIN_WAIT_2定时器：主动请求关闭的一方发送FIN报文给接收端并且收到其对FIN的确认ACK后进入FIN_WAIT_2状态。如果这个时候因为网络突然断掉、被动关闭的一端宕机等原因，到时请求方没有收到接收方发来的FIN，主动关闭的一方回一直等待。—— 该定时器的作用就是为了避免这种情况的发生。当该定时器超时的时候，请求关闭比方将不再等待，直接释放连接。
7. TIME_WAIT定时器：TCP四次挥手中，发送方在最后一次挥手之后回进入TIME_WAIT状态，不直接进入CLOSE状态的主要原因是被动关闭方玩意在超时时间内没有收到最后一个ACK，则还会重发最后的FIN。 —— （1）2MSL等待时间保证了重发的FIN会被主动关闭的一端收到且重新发送以后一个ACK。（2）在这2MSL的时间段内任何迟到的报文段会被接受方丢弃，从而防止老的TCP连接的包在新的TCP连接里面出现。

2、TCP如何保证可靠性的？

1. 数据分块: 应用数据被分割成TCP认为最适合发送的数据块
   
2. 序列号和确认应答：TCP给发送的每个包进行编号，在传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答，即发送ACK报文，这个ACK报文当中带有对应的确认序列号，刚告诉发送方成功接收了哪些数据以及下一次的数据从哪里开始发。除次之外，接收方可以根据序列号对数据进行排序，把有序数据传送给应用层，并丢弃重复的数据。
   
3. 校验和：TCP将保持它首部和数据部分的校验和，目的是检测数据在传输过程中的任何变化。 如果收到报文段的校验和也有差错，TCP将丢弃这个报文段并且不确认收到的此报文
   
4. 流量控制：TCP连接的双方都一个固定大小的缓冲空间，发送方发送的数据量不能够超过接收端缓冲区的大小，当接收方来不及处理发送方的数据，会提示发送方降低发送的速率，防止产生丢包。TCP通过滑动窗口协议来支持流量控制机制。
   
5. 拥塞控制：当网络某个节点发生拥塞时，减少数据的发送
   
6. ARQ协议：也是为了实现可靠传输的，它的基本原理就是每发完一个分组就定制发送，等待对方确认。 在收到确认后，再发下一个分组。
   
7. 超时重传：当TCP发出一个报文段后，它启动一个定时器，等待目的段确认收到这个报文段，如果超过某个时间还没有收到确认，将重发这个报文段。
   

3、TCP超时重传原理？

发送方在发送一次数据后就开启一个定时器，在一定时间内如果没有得到发送数据包的 ACK 报文，那么就重新发送数据，在达到一定次数还没有成功的话就放弃重传并发送一个复位信号。其中超时时间的计算是超时的核心，而定时时间的确定往往需要进行适当的权衡，因为当定时时间过长会造成网络利用率不高，定时太短会造成多次重传，使得网络阻塞。在 TCP 连接过程中，会参考当前的网络状况从而找到一个合适的超时时间。

4、TCP的停止等待协议是什么？

停止等待协议是为了实现 TCP 可靠传输而提出的一种相对简单的协议，该协议指的是发送方每发完一组数据后，直到收到接收方的确认信号才继续发送下一组数据。【在已发送但未确认的报文被确认之前, 发送方的滑动窗口将不会滑动】

四种情形：理解停等协议是人如何实现可靠传输的：

① 无差错传输 ：A 发送分组 Msg 1，发完就暂停发送，直到收到接收方确认收到 Msg 1 的报文后，继续发送 Msg 2，以此类推，该情形是通信中的一种理想状态。
② 出现差错发：送方发送的报文出现差错导致接收方不能正确接收数据，出现差错的情况主要分为两种：

<1> 发送方发送的 Msg 1 在中途丢失了，接收方完全没收到数据。
<2> 接收方收到 Msg 1 后检测出现了差错，直接丢弃 Msg 1。
上面两种情况，接收方都不会回任何消息给发送方，此时就会触发超时传输机制，即发送方在等待一段时间后仍然没有收到接收方的确认，就认为刚才发送的数据丢失了，因此重传前面发送过的数据。

③ 确认丢失 当接收方回应的 Msg 1 确认报文在传输过程中丢失，发送方无法接收到确认报文。于是发送方等待一段时间后重传 Msg 1，接收方将收到重复的 Msg1 数据包，此时接收方会丢弃掉这个重复报文并向发送方再次发送 Msg1 的确认报文。

④ 确认迟到 当接收方回应的 Msg 1 确认报文由于网络各种原因导致发送方没有及时收到，此时发送方在超时重传机制的作用下再次发送了 Msg 数据包，接收方此时进行和确认丢失情形下相同的动作（丢弃重复的数据包并再次发送 Msg 1 确认报文）。发送方此时收到了接收方的确认数据包，于是继续进行数据发送。过了一段时间后，发送方收到了迟到的 Msg 1 确认包会直接丢弃。

5、TCP最大的连接数限制？

Client 最大 TCP 连接数 client 在每次发起 TCP 连接请求时，如果自己并不指定端口的话，系统会随机选择一个本地端口（local port），该端口是独占的，不能和其他 TCP 连接共享。TCP 端口的数据类型是 unsigned short，因此本地端口个数最大只有 65536，除了端口 0不能使用外，其他端口在空闲时都可以正常使用，这样可用端口最多有 65535 个。

Server最大 TCP 连接数 server 通常固定在某个本地端口上监听，等待 client 的连接请求。不考虑地址重用（Unix 的 SO_REUSEADDR 选项）的情况下，即使 server 端有多个 IP，本地监听端口也是独占的，因此 server 端 TCP 连接 4 元组中只有客户端的 IP 地址和端口号是可变的，因此最大 TCP 连接为客户端 IP 数 × 客户端 port 数，对 IPV4，在不考虑 IP 地址分类的情况下，最大 TCP 连接数约为 2 的 32 次方（IP 数）× 2 的 16 次方（port 数），也就是 server 端单机最大 TCP 连接数约为 2 的 48 次方。

然而上面给出的是只是理论上的单机最大连接数，在实际环境中，受到明文规定（一些 IP 地址和端口具有特殊含义，没有对外开放）、机器资源、操作系统等的限制，特别是 sever 端，其最大并发 TCP 连接数远不能达到理论上限。对 server 端，通过增加内存、修改最大文件描述符个数等参数，单机最大并发 TCP 连接数超过 10 万 是没问题的。

6、TCP流量控制与拥塞控制

流量控制
所谓流量控制就是让发送方的发送速率不要太快，让接收方来得及接收。如果接收方来不及接收发送方发送的数据，那么就会有分组丢失。在 TCP 中利用可变长的滑动窗口机制可以很方便的在 TCP 连接上实现对发送方的流量控制。主要的方式是接收方返回的 ACK 中会包含自己的接收窗口大小，以控制发送方此次发送的数据量大小（发送窗口大小）。

拥塞控制
在实际的网络通信系统中，除了发送方和接收方外，还有路由器，交换机等复杂的网络传输线路，此时就需要拥塞控制。拥塞控制是作用于网络的，它是防止过多的数据注入到网络中，避免出现网络负载过大的情况。常用的解决方法有：慢开始和拥塞避免、快重传和快恢复。

拥塞控制和流量控制的区别

1. 拥塞控制往往是一种全局的，防止过多的数据注入到网络之中，而TCP连接的端点只要不能收到对方的确认信息，猜想在网络中发生了拥塞，但并不知道发生在何处
   
2. 流量控制往往指点对点通信量的控制，是端到端的问题。

困惑：滑动窗口和拥塞窗口的不明确：
滑动窗口（协议）：是传输层将进行流量控制的一种措施，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，从而达到防止发送方发送速度过快二人导致自己被淹没的目的。 —— 滑动窗口可以理解为协议、机制、或者服务器滑动窗口大小。 ——> 主要的是：接收方还可以接收的大小通告发送方控制发送的大小。

拥塞窗口【congestion window 简称：cwnd】：可以看做是发送端用来进行流量（拥塞）控制的窗口。拥塞是指一个或者多个交换点的数据报超载而导致时延剧烈增加的现象。为了控制拥塞，TCP使用了第二个窗口限制，即拥塞窗口限制。对于拥塞窗口大小的限制采用慢开始和乘法减小两种技术。
乘法减小的拥塞避免策略：一旦发现报文段丢失，就把拥塞窗口的大小减半（直到减至最小的窗口，窗口中应至少包含一个报文段）。
慢开始恢复：拥塞窗口随着一个确认的到达，拥塞窗口的大小每次增加一个报文段。

拥塞窗口是发送方使用的流量控制，而通告/滑动窗口则是接收方使用的流量控制。

7、如果接收方滑动窗口满了，发送方会怎么做？

基于 TCP 流量控制中的滑动窗口协议，我们知道接收方返回给发送方的 ACK 包中会包含自己的接收窗口大小，若接收窗口已满，此时接收方返回给发送方的接收窗口大小为 0，此时发送方会等待接收方发送的窗口大小直到变为非 0 为止，然而，接收方回应的 ACK 包是存在丢失的可能的，为了防止双方一直等待而出现死锁情况，此时就需要坚持计时器来辅助发送方周期性地向接收方查询，以便发现窗口是否变大【坚持计时器参考问题】，当发现窗口大小变为非零时，发送方便继续发送数据。

8、拥塞控制采用的四种算法

ssthresh: ss阈值
cwnd: Congestion Window 拥塞窗口
rwnd：Receiver Window 接收者窗口 —— 即为：滑动窗口 Sliding window

慢开始的乘以2的原因 网络拥塞 —— 即为超时 快重传示意图，cwnd这个时候应该是不变的 快恢复

1. 慢开始（慢启动） —— 传数据从1快速增加 当发送方开始发送数据时，由于一开始不知道网络负荷情况，如果立即将大量的数据字节传输到网络中，那么就有可能引起网络拥塞。一个较好的方法是在一开始发送少量的数据先探测一下网络状况，即由小到大的增大发送窗口（拥塞窗口 cwnd）。慢开始的慢指的是初始时令 cwnd为 1，即一开始发送一个报文段。如果收到确认，则 cwnd = 2，之后每收到一个确认报文，就令 cwnd = cwnd* 2。
   但是，为了防止拥塞窗口增长过大而引起网络拥塞，另外设置了一个慢开始门限 ssthresh。
   ① 当 cwnd < ssthresh 时，使用上述的慢开始算法；
   ② 当 cwnd > ssthresh 时，停止使用慢开始，转而使用拥塞避免算法
   

2. 拥塞避免 —— 传数量慢慢增加 拥塞控制是为了让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT （往返时间定义为发送方发送数据到收到确认报文所经历的时间）就把发送方的 cwnd 值加 1，通过让 cwnd 线性增长，防止很快就遇到网络拥塞状态。
   当网络拥塞发生时，让新的慢开始门限值变为发生拥塞时候的值的一半,并将拥塞窗口置为 1 ,然后再次重复两种算法（慢开始和拥塞避免）,这时一瞬间会将网络中的数据量大量降低。

3. 快重传 —— 传输缺失的数据 快重传算法要求接收方每收到一个失序的报文就立即发送重复确认，而不要等到自己发送数据时才捎带进行确认，假定发送方发送了 Msg 1 ~ Msg 4 这 4 个报文，已知接收方收到了 Msg 1，Msg 3 和 Msg 4 报文，此时因为接收到收到了失序的数据包，按照快重传的约定，接收方应立即向发送方发送 Msg 1 的重复确认。 于是在接收方收到 Msg 4 报文的时候，向发送方发送的仍然是 Msg 1 的重复确认。这样，发送方就收到了 3 次 Msg 1 的重复确认，于是立即重传对方未收到的 Msg 报文。由于发送方尽早重传未被确认的报文段，因此，快重传算法可以提高网络的吞吐量。

4. 快恢复 快恢复算法是和快重传算法配合使用的，该算法主要有以下两个要点：

① 当发送方连续收到三个重复确认，执行乘法减小，慢开始门限 ssthresh 值减半；

② 由于发送方可能认为网络现在没有拥塞，因此与慢开始不同，把 cwnd 值设置为 ssthresh 减半之后的值，然后执行拥塞避免算法，线性增大 cwnd。

小结： 1）滑动窗口和拥塞窗口大小比较，取小的值。
2) 上面讨论的慢启动和拥塞避免算法都是在 拥塞窗口<滑动窗口的情况下。 否则，就直接使用滑动窗口了。
3) 主要就是：慢启动、拥塞避免、快恢复
4) 判断是使用快恢复/拥塞避免还是慢启动+拥塞避免，要看拥塞当前是超时了，还是快恢复？如果我收到了多次的同一个序列号的ack，那就是快恢复，如果是超时了，那就是拥塞避免。

滑动串口和拥塞窗口的合作：

1. 发送端主机在确认发送报文段的速率时，既要根据接收端的接收能力，又要从全局考虑不要使网络发生拥塞
   
2. 因此，每个tcp连接需要也有以下两个状态变量： a:接收端窗口 b:拥塞窗口
3. 收端窗口：是接收端根据其一目前的接收缓存大小所许诺的最新窗口值，时来自接收端的流量控制。接收端将此值放在TCP报文的首部中的窗口字段，传给发送端
4. 拥塞窗口：是发送端根据自己估计的网络拥塞程度而设置的窗口值，是来自发送端的流量控制
5. 发送端的发送窗口的上限值取自接收端窗口和拥塞窗口两这种较小的一个。

参考： https://blog.csdn.net/weixin_41501074/article/details/110941340

9、TCP粘包问题

为什么会发生TCP粘包和拆包?
① 发送方写入的数据大于套接字缓冲区的大小，此时将发生拆包。
② 发送方写入的数据小于套接字缓冲区大小，由于 TCP 默认使用 Nagle 算法，只有当收到一个确认后，才将分组发送给对端，当发送方收集了多个较小的分组，就会一起发送给对端，这将会发生粘包。
③ 进行 MSS （最大报文长度）大小的 TCP 分段，当 TCP 报文的数据部分大于 MSS 的时候将发生拆包。
④ 发送方发送的数据太快，接收方处理数据的速度赶不上发送端的速度，将发生粘包。

常见解决方法
① 在消息的头部添加消息长度字段，服务端获取消息头的时候解析消息长度，然后向后读取相应长度的内容。
② 固定消息数据的长度，服务端每次读取既定长度的内容作为一条完整消息，当消息不够长时，空位补上固定字符。但是该方法会浪费网络资源。
③ 设置消息边界，也可以理解为分隔符，服务端从数据流中按消息边界分离出消息内容，一般使用换行符。

什么时候需要处理粘包问题？ 当接收端同时收到多个分组，并且这些分组之间毫无关系时，需要处理粘包；而当多个分组属于同一数据的不同部分时，并不需要处理粘包问题。

10、为什么服务端易受到 SYN 攻击

在 TCP 建立连接的过程中，因为服务端不确定自己发给客户端的 SYN-ACK 消息或客户端反馈的 ACK 消息是否会丢在半路，所以会给每个待完成的半开连接状态设一个定时器，如果超过时间还没有收到客户端的 ACK 消息，则重新发送一次 SYN-ACK 消息给客户端，直到重试超过一定次数时才会放弃。

服务端为了维持半开连接状态，需要分配内核资源维护半开连接。当攻击者伪造海量的虚假 IP 向服务端发送 SYN 包时，就形成了 SYN FLOOD 攻击。攻击者故意不响应 ACK 消息，导致服务端被大量注定不能完成的半开连接占据，直到资源耗尽，停止响应正常的连接请求。

解决方法：

1. 直接的方法是提高 TCP 端口容量的同时减少半开连接的资源占用时间，然而该方法只是稍稍提高了防御能力；
   
2. 部署能够辨别恶意 IP 的路由器，将伪造 IP 地址的发送方发送的 SYN 消息过滤掉，该方案作用一般不是太大；

这两种方法虽然在一定程度上能够提高服务器的防御能力，但是没有从根本上解决服务器资源消耗殆尽的问题

下面的方法出发点都是在发送方发送确认回复后才开始分配传输资源，从而避免服务器资源消耗殆尽：

1. SYN Cache：该方法首先构造一个全局 Hash Table，用来缓存系统当前所有的半开连接信息。在 Hash Table 中的每个桶的容量大小是有限制的，当桶满时，会主动丢掉早来的信息。当服务端收到一个 SYN 消息后，会通过一个映射函数生成一个相应的 Key 值，使得当前半连接信息存入相应的桶中。 当收到客户端正确的确认报文后，服务端才开始分配传输资源块，并将相应的半开连接信息从表中删除。和服务器传输资源相比，维护表的开销要小得多。
   
2. SYN Cookies:该方案原理和 HTTP Cookies 技术类似，服务端通过特定的算法将半开连接信息编码成序列号或者时间戳，用作服务端给客户端的消息编号，随 SYN-ACK 消息一同返回给连接发起方，这样在连接建立完成前服务端不保存任何信息， 直到发送方发送 ACK 确认报文并且服务端成功验证编码信息后，服务端才开始分配传输资源。若请求方是攻击者，则不会向服务端会 ACK 消息，由于未成功建立连接，因此服务端并没有花费任何额外的开销。
   

存在缺点：由于服务端并不保存半开连接状态，因此也就丧失了超时重传的能力，这在一定程度上降低了正常用户的连接成功率。 此外，客户端发送给服务端的去人不保温存在传输丢是的可能，当ACK确认报文丢失时，服务端和客户端会对连接的成功与否产生歧义，此时就不需要上层应用采取相应的策略进行处理了。

SYN Proxy：在客户端和服务器之间部署一个代理服务器，类似于防火墙的作用。通过代理服务器与客户端进行建立连接的过程，之后代理服务器充当客户端将成功建立连接的客户端信息发送给服务器。这种方法基本不消耗服务器的资源，但是建立连接时间变长了。

SYN FLOOD 参考： https://zhuanlan.zhihu.com/p/29539671 https://dun.163.com/news/p/69294ba2366f49ae9f21d904f661023c

11、高并发服务器：客户端主动关闭连接 和 服务器主动关闭连接的区别：

服务端主动关闭连接 在高并发场景下，当服务端主动关闭连接时，此时服务器上就会有大量的连接处于TIME-WAIT状态

客户端主动关闭连接 当客户端主动关闭连接时，我们并不需要关心TIME-WAIT状态过多造成的问题，但是需要关注服务端保持大量的CLOSE-WAIT状态时会产生的问题。

无论是客户端还是服务器主动关闭连接，从本质上说，在高并发场景下主要关心的就是服务端的资源占用问题，而这也是采用TCP传输协议必须要面对的我呢提，其问题解决的发出点也是如何处理好服务质量和资源消耗之间的关系。

三 、区别

类型	TCP	UDP
是否面向连接	是	否
是否可靠性	是	否
传输形式	字节流	数据报文段
传输效率	慢	快
所需要资源	多	少
双工性	全双工	1对1、 1对多、多对一、多对多
流量控制	滑动窗口	无
控制拥塞	慢启动、拥塞避免、快重传、快恢复	无
首部字节	20~ 60	8个字节
应用场景	文件传输、邮件传输	即使通讯、域名转换

1. 连接：TCP面向连接，3次握手，4次挥手; UDP是面向无连接，数据传输前后不连接，发送端只负责将数据发送到网络，接收端从消息队列读取。
   
2. 可靠：TCP 提供可靠的服务，传输过程采用流量控制、编号、确认、计时器等手段确保数据误差错、不丢失。 UDP则尽可能传递数据，但并不保证传递给付给对方
   
3. 传输数据：TCP面向字节流，将应用层报文看成一串无结构的字节流，分解为多个TCP报文段传输后，在目的站重新装配； UDP协议面向报文，不拆分应用层报文，只保留报文边界，一次发送一个报文了，接受方去除报文首部，原封不动将报文交给上层应用。
   
4. 双工：TCP只能够点对点双工通信，UDP支持1-1/1-n/n-1/n-n的交互通信。

四、应用场景

TCP 使用对效率要求低，对准确性要求高或要求也有链接的场景
UDP 对效率要求高，对准确性要求低的场景

---

公众号：`技术小难`
[简书](https://www.jianshu.com/u/1851ec413025)
[博客园](https://account.cnblogs.com/blog-apply) 链接需要替换
[CSDN](https://blog.csdn.net/u012496940?spm=1000.2115.3001.5343)
[知乎](https://www.zhihu.com/people/gu-han-90-61)
[掘金](https://juejin.cn/user/1943592286824333)
[segmentfault](https://segmentfault.com/u/natqeeak/articles)

本文由 mdnice 多平台发布