标签：协议 报文 确认 TCP 发送 计算机网络 连接 客户端

TCP和UDP的区别

	TCP	UDP
连接	基于连接	基于无连接
资源	消耗多	消耗少
程序结构	复杂	简单
传输形式	流模式（字节流）	数据报模式（数据报文段）
传输效率	慢	快
可靠性	可靠	不可靠（可能丢包）
数据顺序	保证	不保证
首部	20~60字节	8字节

TCP：传输控制协议，是面向连接的，提供可靠交付，有流量控制，拥塞控制，提供全双工通信，面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块），每一条 TCP 连接只能是点对点的（一对一）
UDP：用户数据报协议，是无连接的，尽最大可能交付，没有拥塞控制，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），支持一对一、一对多、多对一和多对多的交互通信

TCP三次握手

图示：

三次握手流程

1. TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了监听（LISTEN）状态
2. TCP客户进程先创建传输控制块TCB，然后向服务器发出连接请求报文，此时报文首部中的同步位SYN=j，同时选择一个初始序列化seq=x，此时TCP客户端进入同步已发送（SYN-SENT）状态。TCP规定，SYN报文段（即SYN=j的报文段）不能携带数据，但需要消耗掉一个序号
3. TCP服务器收到请求报文后，如果同意继续，则发出确认报文。确认报文的ACK=1，SYN=j，确认号ack=x+1，同时自己初始化一个序列号seq=y，此时TCP服务器进程进入同步收到（SYN-RCVD）状态。这个报文也不能携带数据，但同样消耗一个序号
4. TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1。此时TCP连接建立，客户端进入已建立连接（ESTABLISHED）状态。TCP规定，ACK报文段可以携带数据，如果不携带数据则不消耗序号
5. TCP服务器收到客户端的确认后也进入ESTABLISHED状态，至此双方可以开始通信

三次握手的目的

• 第一次握手：客户端无法确认；服务器端确认对方发送正常，自己接收正常
• 第二次握手：客户端确认自己发送、接收正常，对方发送、接收正常；服务器端同上
• 第三次握手：客户端同上；服务器端确认自己发送、接收正常，对方发送、接收正常
• 总体：建立可靠的通信通道，双方确认自己与对方的发送与接收都是正常的。

第二次握手时，为什么需要传回SYN并传ACK？

传回SYN：服务器端传回客户端发送的SYN，是为了告诉客户端，我接收到的消息就是你发送的消息。
传ACK：因为必须确保双方互相发送信息都无误。传回SYN，可以证明客户端到服务器端的通道没有问题；传ACK，可以用来验证服务器端到客户端的通道是否有问题。

三次握手中，为什么TCP客户端最后还要发送一次确认？

主要是为了防止已经失效的连接请求报文突然又传送到了服务器，产生错误。 如果使用两次握手建立连接，那么有这样一种场景：客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

TCP四次挥手

图示：

四次挥手流程

1. 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号
2. 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间
3. 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）
4. 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认
5. 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态
6. 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些

四次挥手的目的

• 第一次挥手：客户端告知服务端自己已发送完毕，要断开连接
• 第二次挥手：服务端确认该告知
• 第三次挥手：服务端发送剩余数据
• 第四次挥手：客户端确认

四次挥手中，为什么TCP客户端最后还要等待2MSL？

MSL，TCP允许不同的实现可以设置不同的MSL值。第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文

TCP三次握手和四次挥手中的知识点

三次握手四次挥手过程中发送的内容

• 序列号seq：占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生，给字节编上序号后，就给每一个报文段指派一个序号，序列号seq就是这个报文段中的第一个字节的数据编号
• 确认号ack：占4个字节，期待收到对方下一个报文段的第一个数据字节的序号，序列号表示报文段携带数据的第一个字节的编号，而确认号指的是期望接受到下一个字节的编号，因此挡墙报文段最后一个字节的编号+1即是确认号
• 确认ACK：占1个比特位，仅当ACK=1，确认号字段才有效。ACK=0，确认号无效
• 同步SYN：连接建立时用于同步序号。当SYN=1，ACK=0表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使用SYN=1，ACK=1.因此，SYN=1表示这是一个连接请求，或连接接收报文，SYN这个标志位只有在TCP建立连接才会被置为1，握手完成后SYN标志位被置为0
• 终止FIN：用来释放连接

为什么TCP建立连接是三次握手，关闭连接却是四次挥手呢?

建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次

如果已经建立了TCP连接，但是客户端突然出现故障怎么办？

TCP设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75s发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

TCP相关面试题

UDP的应用场景

	* 面向数据报方式
	* 网络数据大多为短消息
	* 拥有大量Client
	* 对数据安全性无特殊要求
	* 网络负担非常重，但对响应速度要求高

数据流模式和数据报模式

• 数据流模式

  1. 概念：所谓的“流模式”，是指TCP发送端发送几次数据和接收端接收几次数据是没有必然联系的，比如你通过 TCP连接给另一端发送数据，你只调用了一次 write，发送了100个字节，但是对方可以分10次收完，每次10个字节；你也可以调用10次write，每次10个字节，但是对方可以一次就收完
  2. 原因：这是因为TCP是面向连接的，一个 socket 中收到的数据都是由同一台主机发出，且有序地到达，所以每次读取多少数据都可以

• 数据报模式

  1. 概念：所谓的“数据报模式”，是指UDP发送端调用了几次 write，接收端必须用相同次数的 read 读完。UDP是基于报文的，在接收的时候，每次最多只能读取一个报文，报文和报文是不会合并的，如果缓冲区小于报文长度，则多出的部分会被丢弃
  2. 原因： 这是因为UDP是无连接的，只要知道接收端的 IP 和端口，任何主机都可以向接收端发送数据。 这时候，如果一次能读取超过一个报文的数据，则会乱套

TCP的长连接与短连接

• 短连接
  1. 概念：Client 向 Server 发送消息，Server 回应 Client，然后一次读写就完成了，这时候双方任何一个都可以发起 close 操作，不过一般都是 Client 先发起 close 操作。短连接一般只会在 Client/Server 间传递一次读写操作
  2. 说明：管理起来比较简单，建立存在的连接都是有用的连接，不需要额外的控制手段
• 长连接
  1. 概念：Client 与 Server 完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接
  2. 说明：在长连接的应用场景下，Client 端一般不会主动关闭它们之间的连接，Client 与 Server 之间的连接如果一直不关闭的话，随着客户端连接越来越多，Server 压力也越来越大，这时候 Server 端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致 Server 端服务受损；如果条件再允许可以以客户端为颗粒度，限制每个客户端的最大长连接数，从而避免某个客户端连累后端的服务
• 比较：长连接和短连接的产生在于 Client 和 Server 采取的关闭策略，具体的应用场景采用具体的策略

SYN攻击

• 场景：在三次握手过程中，服务器发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为半连接(half-open connect).此时服务器处于Syn_RECV状态.当收到ACK后，服务器转入ESTABLISHED状态
• 概念：Syn攻击就是 攻击客户端 在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直 至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪

UDP如何实现可靠传输？

1. UDP在传输层无法保证数据的可靠传输，只能通过应用层实现。
2. 实现确认机制、重传机制、窗口确认机制
   • 实现确认机制：接收方收到UDP之后回复个确认包
   • 重传机制：发送方收不到确认包就要重新发送，每个包有递增的序号，接收方发现中间丢了包就要发重传请求
   • 窗口确认机制：当网络太差时候频繁丢包，防止越丢包越重传的恶性循环，有发送窗口的限制，发送窗口的大小根据网络传输情况调整

TCP如何保证可靠传输？

1. TCP把应用数据分割成最适合发送的数据块
2. TCP给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层
3. 校验和：TCP将保持它首部和数据的校验和，检测数据在传输过程中有无变化。如果收到的报文段的检验和有差错，TCP就不确认收到该报文段，并将该报文段丢弃
4. TCP的接收端会丢弃重复的数据
5. 流量控制：TCP连接的每一方都有固定大小的缓存空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议（即TCP利用滑动窗口实现流量控制）
6. 拥塞控制：当网络拥塞时，减少数据的发送
7. ARQ协议：每发送完一个分组就停止发送，等待对方确认，收到确认之后再发送下一个分组。目的是实现可靠传输
8. 超时重传：TCP发出一个报文段后，它就启动一个定时器，等待目的端确认收到这个报文段。若不能及时收到一个确认，就重发这个报文段

ARQ协议

• 概念：自动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议
• 停止等待ARQ协议
  • 说明：停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复ACK）。如果过了一段时间（超时时间后），还是没有收到ACK确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组。在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认
  • 优点：简单
  • 缺点：信道利用率低，等待时间长
• 连续ARQ协议
  • 概念：连续ARQ协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了
  • 优点：信道利用率高，容易实现，即使确认丢失，也不必重传
  • 缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息（例如，发送方发送了5条消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次）

滑动窗口协议

1. “窗口”对应一段可以被发送者发送的字节序列，其连续的范围称之为“窗口”
2. “滑动”是指这段允许发送的范围是可以随着发送的过程而变化的，变化的方式就是按顺序“滑动”
3. 应用层所有需要发送的数据都放在发送者的发送缓冲区中，发送窗口是发送缓冲区的一部分
4. 每次成功发送数据后（发送的数据得到接收方的确认），发送窗口就在发送缓冲区中按顺序移动，将新的数据包含到发送窗口中准备发送
5. TCP建立连接的初始，接收方会告诉发送方自己的接收窗口大小

流量控制

• TCP利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为0，则发送方不能发送数据
• 实现方式：返回的ACK中（确认报文中的窗口字段）会包含自己的接收窗口的大小，利用接收窗口大小来控制发送方的发送速率
• 持续计时器：
  • 应对的情况：如，B已经告诉A自己的缓冲区已满，于是A停止发送数据；等待一段时间后，B的缓冲区出现了富余，于是给A发送报文告诉A我的rwnd大小为400，但是这个报文不幸丢失了，于是就出现A等待B的通知||B等待A发送数据的死锁状态
  • 原理：当A收到对方的零窗口通知时，就启用该计时器，时间到则发送一个1字节的探测报文，对方会在此时回应自身的接收窗口大小，如果结果仍未0，则重设持续计时器，继续等待
• 传递效率：单个发送字节单个确认，和窗口有一个空余即通知发送方发送一个字节，无疑增加了网络中的许多不必要的报文（请想想为了一个字节数据而添加的40字节头部吧！），所以我们的原则是尽可能一次多发送几个字节，或者窗口空余较多的时候通知发送方一次发送多个字节

拥塞控制

• 在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。
• 拥塞窗口：为了进行拥塞控制，TCP发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个
• TCP的拥塞控制采用四种算法：慢开始、拥塞避免、快重传、快恢复
  • 慢开始：当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍
  • 拥塞避免：拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送放的cwnd加1
  • 快重传与快恢复：作用是快速恢复丢失的数据包。如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段
• 算法思路
  1. 发送方维持一个叫做“拥塞窗口”的变量，该变量和接收端口共同决定了发送者的发送窗口
  2. 当主机开始发送数据时，避免一下子将大量字节注入到网络，造成或者增加拥塞，选择发送一个1字节的试探报文
  3. 当收到第一个字节的数据的确认后，就发送2个字节的报文
  4. 若再次收到2个字节的确认，则发送4个字节，依次递增2的指数级
  5. 最后会达到一个提前预设的“慢开始门限”，比如24，即一次发送了24个分组，此时遵循下面的条件判定
     • cwnd < ssthresh， 继续使用慢开始算法
     • cwnd > ssthresh，停止使用慢开始算法，改用拥塞避免算法
     • cwnd = ssthresh，既可以使用慢开始算法，也可以使用拥塞避免算法
  6. 所谓拥塞避免算法就是：每经过一个往返时间RTT就把发送方的拥塞窗口+1，即让拥塞窗口缓慢地增大，按照线性规律增长
  7. 当出现网络拥塞，比如丢包时，将慢开始门限设为原先的一半，然后将cwnd设为1，执行慢开始算法（较低的起点，指数级增长）
• 快重传
  1. 接收方建立这样的机制，如果一个包丢失，则对后续的包继续发送针对该包的重传请求
  2. 一旦发送方接收到三个一样的确认，就知道该包之后出现了错误，立刻重传该包
  3. 此时发送方开始执行“快恢复”算法
     1. 慢开始门限减半
     2. cwnd设为慢开始门限减半后的数值
     3. 执行拥塞避免算法（高起点，线性增长）

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

1. 拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收
2. 流量控制主要针对的是端到端传输中控制流量大小并保证传输可靠性（未收到ack就不滑动）。流量控制往往是指点对点通信量的控制，所要做的是抑制发送端发送数据的速率
3. 拥塞控制主要是一个全局性过程，涉及到所有主机，路由器，以及与降低网络传输性能有关的所有因素。防止过多的数据注入到网络中。如果有发生丢包则通过拥塞控制减小窗口，确定出合适(慢启动 拥塞避免 快重传 快恢复)的拥塞窗口（增性加乘性减）

其他

• OSI七层模型：应用层 表示层 会话层 传输层 网络层 数据链路层 物理层
• TCP/IP五层模型：应用层 传输层 网络层 数据链路层 物理层
• TCP、UDP是传输层协议，IP是网络层协议

标签：协议,报文,确认,TCP,发送,计算机网络,连接,客户端
来源： https://blog.csdn.net/AkimotoManatsu/article/details/118633738

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。