传输层 --------- TCP( 二 )

目录

9.流动控制(双方通信控制)

10.滑动窗口

11.交通堵塞管制(多边管制)

12.延迟应答

13.捎带应答

14.面向字节流

15.粘包问题

16.TCP异常

17.TCP小结

18.基于TCP的应用程序层协议

9.流动控制(双方通信控制)

(1)TCP支持根据接收端的接收数据的能力来决定发送端发送数据的速度，这个机制叫做流量控制（Flow Control）。

(二)接收器处理数据的速度有限,如果终端发送太快,使接收器缓冲区填满,此时,发送器继续发送数据,就会造成丢包，这导致一系列链路反应,如丢失数据包的重新传输。因此接收器可以通知发送者自己接收数据的能力,让发送器控制发送数据的速度.

• 接收器将可以接收的缓冲大小插入TCP顶部的“窗口大小”字段,并通过ACK通知发送者。
• 视窗大小越大,网络的吞吐量就越高。
• 一旦接收机发现其缓冲区快满了,它将窗口大小设置为一个较小的值通知给接收机。
• 发送端接收到这个窗口之后，就会减慢自己发送的速度。(如何减慢？ 滑动窗口)
• 如果接收器缓冲区满,则窗口值设置为0,发送者不再发送数据,而是需要定期发送窗口检测数据段,让接收者告诉发送者窗口的大小。

(3)当发送者得知接收者接收数据的能力为零时,发送者停止发送数据,这时发送者会知道什么时候继续发送数据。

• 等待告知。接收端上层将接收缓冲区当中的数据读走后，接收端向发送端发送一个TCP报文，主动将自己的窗口大小告知发送端，发送端得知接收端的接收缓冲区有空间后就可以继续发送数据了。
• 问问自己。 发送器从时到时向接收机发送消息,它不载有有效的数据,只是问发送器关于窗口的大小,直到接收机缓冲区有空间,发送器可以继续发送数据。

16是65535的最大数目,是65535的最大TCP窗口吗?

在理论上,这是正确的,但事实上,TCP头部的40字节选项字段包含窗口扩展因子M,并且实际的窗口大小是从窗口字段左移的M值得到的。

如何知道另一方第一次向另一方发送数据时的窗口大小

双方在进行TCP通信之前需要先进行三次握手建立连接，除了验证两边通讯通道是否平滑,两边还握手。还 交换 了 其他 资料,这包括通知对方是否能够接受,因此,双方在正式沟通之前都知道对方接收数据的能力。因此,双方在发送数据时没有缓冲溢出的问题。

10.滑动窗口

连续发送数据

• 双方在进行TCP通信时可以一次向对方发送多条数据，这样可以将等待多个响应的时间重叠起来，进而提高数据通信的效率
• 尽管双方在TCP通信中可以互相发送大量信息,但它们不能把它们在缓冲区中发送的所有数据包起来发送给对方,考虑到对方在发送数据时的接收能力

滑动窗口

为什么主机不发送所有数据一次?

尽管许多可以同时发送,但考虑接收机的接收能力,即接收缓冲的大小。 当建立连接时,两个窗口(接收缓冲)的大小都会交换。

(2)发送方可以一次发送多个报文给对方，此时也就意味着发送出去的这部分报文当中有相当一部分数据是暂时没有收到应答的。

其实可以将发送缓冲区当中的数据分为三部分，这里发送缓冲区的第二部分就叫做滑动窗口。（也有人把这三部分整体称之为滑动窗口，而将其中的第二部分称之为窗口大小)

(3)窗口协商

• 在TCP头上有一个叫做“窗口”的字段,这个字段是“窗口”的大小。
• 这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。
• 窗口的大小通常由接收机的窗口大小决定。
• 发送者发送的数据大小不能超过接收者窗口的大小,否则接收者无法正常接收数据。

(4)发送数据示例

• A根据B给出的窗口值构造自己的发送窗口。
• 发送窗口意味着A可以连续地发送窗口中的所有数据,而不接受B的确认。
• 发送窗口中的序列显示允许发送的序列。
• 接收窗口:仅允许接收进入窗口的数据。
• 越大窗口,发送者在收到另一方确认之前可以连续发送更多的数据,因此可以实现更多的传输效率。
  

现在假设A发送数据,编号为31-41

描述发送窗口的状态需要三个标记p1,p2,p3;所有标记指的是字符的序列

• P1=后退, P2=当前, P3=边界。
• p1之前的数据已经发送并确认
• p3之后的数据不能发送
• P3 - P1=发送窗口(也称为通知窗口)=20
• P2 - P1 =已发送但未收到的字节数目(可以理解为滑动窗口)
• P3 - P2=允许发送但不发送字节数(也称为可用窗口)

3B接收了第32和33号数据,但没有接收第31号数据。因此,发送的确认消息中的确认号为31(即预期收到的序列)。

4假设B给出了31号数据,将编号31-33的数据提交到顶部应用程序,删除这些数据,向前移动接收机窗口的三个序列,同时向A发送确认,窗口值仍为20,但确认号为34,这表明B在收到序列号34之前已经收到数据。B 还 收到 了 项目 37 、 38 和 40 的 数据,但他们没有按顺序到达,仅在接收窗口中暂时存在。A 收到B的确认后,您可以向前滑动发送窗口的三个序列,但指针P2没有固定,此时A的可用窗口被扩展。

如果A的发送窗口是满的,可用的窗口被减少到0,并且必须停止发送。

• A未收到确认的原因有:① B未发送; ②B已发送，但还未到达A。
• 为了确保可靠的传输,A只能假设B没有收到数据,A在一段时间后(由计时器控制)传输该部分数据,然后重新设置计时器直到B收到确认。
• 如果A在发送窗口中接收一个序列的确认编号,发送窗口会向前滑动并发送新的数据。

(5)缓存和窗口

(6)强调两点

• 虽然A的发送窗口是根据B的接收窗口设置的，但是在同一时刻，A,B的窗口大小并不一样. 因为通过网络传输是有一定的滞后。另外 ，发送方A还可能根据网络当时的拥塞情况适当减小自己的发送数值.
• 未排序数据的TCP标准没有明确定义。如果这些数据被丢弃,那么接收窗口的管理将变得更简单,但网络资源的使用率很低。因此TCP通常先在接收窗口中暂时存储未订购的数据,在接收节点流中丢失的节点后,按顺序提交上级申请.

(7)快重传

①丢ACK

当发送器同时发送多个消息数据时,一些ACK损失较轻,并可以通过后续的ACK确认。

②丢数据包

• 当1001-2000的数据包丢失后，发送端会一直收到确认序号为1001的响应报文，就是在提醒发送端“下一次应该从序号为1001的字节数据开始发送”。
• 如果发送器收到三连串确认序列编号1001的响应消息,则1001-200数据包再次发送。
• 此时,当接收器接收1001-200数据包时,它会发送直接确认序列编号6001的响应消息,因为2001-600数据接收器已经收到数据包。

这种机制被称为“高速重发控制”或“高速再传输”。

需要注意的是，快速的重新传输需要大量数据传输和个人数据传输之间的平衡,事实上,这个例子的发送器不知道1001-200包丢失了,当发送器多次收到确认序列号1001的响应消息时,理论上,发射器应该重新传输所有1001-700的数据,但这会使大量数据重复传输,因此发送者可以先检索1001-200包,然后,根据重新输入后获得的确认序列,继续决定是否重新输入其他包。

由于有快速的再传输,为什么有超时的再传输

快重传是用来解决大量数据发送时，某一块数据未收到的问题，当滑动窗口 < 3时接收的ACK不足3个，就无法触发块重传只能使用超时重传，超时重传是一个兜底的。他俩相互补充

允许发送但尚未发送是什么意思?

• 发送的数据信息是发送的,
• 滑动窗口的大小受拥塞窗口的影响，即网络的状况，如果网络状态差一下子发送太多使网络更差.

11.交通堵塞管制(多边管制)

为什么有交通堵塞控制?

①两个主机在进行TCP通信的过程中，出现个别数据包丢包的情况是很正常的，此时可以通过快重传或超时重发对数据包进行补发。但如果双方在通信时出现了大量丢包，此时就不能认为是正常现象了。

2TCP不仅考虑了双向主机的问题,而且考虑了网络的问题。

• 流量控制:考虑端口接收缓冲区的接收能力,然后控制发送器发送数据的速度,避免端口接收缓冲区的溢出。
• Sliding Window: 考虑的是发送器不会等待ACK发送的最大数据量,从而提高发送器的数据传输效率。
• 拥挤窗口:考虑到双方通信时的网络问题,如果传输的数据超过拥挤窗口的大小,可能造成网络拥挤。

③双方网络通信时出现少量的丢包TCP是允许的，但一旦出现大量的丢包，此时量变引起质变，这件事情的性质就变了，此时TCP就不再推测是双方接收和发送数据的问题，而判断是双方通信信道网络出现了拥塞问题。

(2)如何解决网络拥塞问题?

• 当网络发生大规模瘫痪时,通信的两个方面,作为网络中的两个小主机,似乎无法对此做任何事情,但“没有雪花在雪降时是无辜的”,网络的问题必须是网络中的大多数主机的合作的结果。
• 我们所遵循的协议是,当网络上的情况不足以接收数据时,会发生超时转播,每个人都会重新转播,然后大量数据进入网络,从而进一步加剧网络拥塞。
• 当网络出现拥塞问题时,通信双方都无法提供一个特别有效的解决方案,但两个主机可以不增加网络负担。
• 如果双方通信中出现大量损失,这些消息不应立即重新发送,而是应发送少量数据,甚至没有数据,等待网络状态恢复和双方的传输速度缓慢恢复。
• 应该指出,网络拥塞不仅影响到一个主机,而且影响到网络中的几乎所有主机,所有使用TCP传输控制协议的主机都执行了避免拥塞算法。
• 因此,交通堵塞控制似乎只是谈论一个主机上的通讯策略,事实上,这个策略是所有主机在网络崩溃后遵循的。一旦出现网络拥塞，网络中的所有主机将受到影响,此时所有主机必须避免拥挤,这样可以有效地缓解网络拥塞问题.这样,你就可以保证不会降雪,或在雪降后尽快恢复。

缓慢启动和拥挤的窗口

虽然滑动窗口可以有效地和可靠地发送大量数据,但是如果你一开始发送大量数据,可能有一些问题。因为网络上有许多计算机,可能当前的网络状态已经比较拥挤,因此,在当前网络状况不明确的情况下,我们发送了很多数据,这可能造成网络拥塞问题。

因此,TCP引入了慢启动机制,首先在通信开始时发送少量数据检测路径,确定当前网络拥塞状态,然后决定数据传输的速度。

③拥塞窗口

• 除了具有窗口大小和滑动窗口的概念之外,TCP还有一个称为拥挤窗口的窗口。 拥挤窗口是潜在导致网络拥挤的阈值,如果传输的数据超过拥挤窗口的大小,则可能造成网络拥挤。
• 当您开始发送数据时,拥挤窗口的大小被定义为1,每个接收拥挤窗口的ACK的值为+1(单元是MSS,最大一个消息段长度)
• 当每个数据包被发送时,将拥挤窗口的窗口大小和接收机主反馈的窗口大小进行比较,以实际发送的数据的窗口大小为小值,即滑动窗口的大小。
• 滑窗=最小(对手的接收能力(对手的主机),独立的窗口大小(网络))

每次ACK接收一个与拥挤的窗口相符的值,它都会增加一个,拥挤窗口的增长是指数的, 但指数的增长是非常快的.因此,开始缓慢实际上是开始时更慢的,但越快,就越快。如果拥挤窗口的值继续指数增长,此时, 网络在短时间内可能再次拥挤.

• 首先,确保网络运行顺利,并且在小数据量的情况下,数据包仍然丢失
• 尽快考虑恢复我们的通信速度
• 最后, 在良好的网络条件下进行正常快速通信.

⑤为了避免短时间内再次导致网络拥塞，因此不能一直让拥塞窗口按指数级的方式进行增长。此时就引入了慢启动的阈值，当拥塞窗口的大小超过这个阈值时，就不再按指数的方式增长，而按线性的方式增长。

• 当TCP启动时,慢启动阈值设置为其他窗口的最大大小。
• 在每次超时重复时,慢启动阈值成为当前拥挤窗口的一半,拥挤窗口的值被重新设置为1,从而继续循环。

⑥图示说明：

• 指数增长.TCP通信开始时的拥挤窗口的值为1,并继续指数增长。
• 加法增大。慢启动的阈值初始时为对方窗口大小的最大值，图中慢启动阈值的初始值为16，因此当拥塞窗口的值增大到16时就不再按指数形式增长了，而变成了的线性增长。
• 乘法减小。在拥挤窗口的在线增长过程中,如果网络拥堵在24时发生,此时,慢启动的门槛将是当前拥挤的窗口的一半,也就是12，并将拥挤窗口的值重新设置为1,因此,当指数增长到线性增长时,下一个拥挤窗口的值应该为12。

⑦每台主机拥塞窗口的大小不一定是一样的，即便是同区域的两台主机在同一时刻认为拥塞窗口的大小也不一定是完全相同的。因此在同一时刻，可能一部分主机正在进行正常通信，而另一部分主机可能已经发生网络拥塞了。

⑧示例

• 一旦建立TCP连接,为拥挤窗口设置cwnd为1。在本例中，慢启动门限额的初始值设置为16段报告,Ssthresh = 16.在 slowstart算法的实现阶段,每次往返的RTT时间,拥挤的窗户挤满了双层.当拥塞窗口 cwnd 增长到慢开始门限值 ssthresh时（图中的点①，交通堵塞窗口 cwnd = 16),而不是实施交通堵塞回避算法,拥挤窗口按照线性规则生长.但请注意，避免拥挤并不是完全避免拥挤,相反,让拥挤的窗户变慢,网络不容易拥挤.
• 当拥挤窗口cwnd=24时,网络出现超时(图表第2点),这是网络拥挤的迹象。 然后调整门限值ssthresh=cwnd/2=12,设置拥挤窗口cwnd=1,并执行慢启动算法。
• 按照慢开始算法，每个发送方收到消息的新段落的确认ACK,增加1到拥挤窗口值。当拥挤窗口 cwnd = ssthresh = 12 (图中第3点),这是 ssthresh 第 1 次调整后的数值），而不是实施交通堵塞回避算法,根据线性规则,拥挤窗口增加.
• 有时，个别段落会在网络中被丢失,但事实上,网络并不拥挤。如发件人未能及时收到确认,就会产生超时，认为网络拥挤是错误的。这会导致发送者误启动慢启动,再次设置cwnd为1,因此,传输效率被不必要的降低。
• 当拥塞窗口cwnd=16时（图中的点④），出现了一个新的情况，就是发送方一连收到3个对同一个报文段的重复确认（图中记为3-ACK）。关于这个问题要解释如下。)
• 快速重传算法允许发送者尽可能早地知道消息的各个段落的丢失发生。快速重传输算法首先要求接收机在传输确认之前不要等待自己发送数据。而不是立即发送确认,即使 收到 的 段落 不符 合 时, 应 立即 重新 确认 收到 的 段落 。
• 因此，在图中的点④，发送者刚刚丢失了消息的各个段落。于是不启动慢开始，相反, 执行快速恢复算法.然后发送者再调整门限度,使 ssthresh = cwnd / 2 = 8,同时设置拥挤窗口 cwnd = ssthresh = 8, 开始执行避免拥挤算法.

9TCP堵塞控制流程图

(7)小结

为什么叫做“缓慢启动”,指数增长是快速的?

最初的指数增长缓慢,在网络中解散数据。

为什么中间没有比线性增长更多的指数增长?

指数已经增长到其后半,增长率非常高,你这样做,每个人都这样做,然后网络在短期内被大量数据淹没。

连线性增长也不总是增长?

不会一直增长下去，因为当你的拥塞窗口再增长 >=  流量控制对方的接收能力时，你的拥塞窗口就没有意义了，这时我们看的是对方的接收能力。

12.延迟应答

(1)如果接收机收到ACK响应后立即接收数据,此时返回的窗口可能较小。

• 假设对方接收端缓冲区剩余空间大小为1M，对方一次收到500K的数据后，如果立即进行ACK应答，此时返回的窗口就是500K。
• 然而,实际接收器处理数据非常迅速,在接收缓冲区内消耗500K的数据在10ms以内。
• 在这种情况下,接收器处理远远没有达到其限度,即使窗口放大了一点,也可以处理。
• 如果接收端稍微等一会再进行ACK应答，比如等待200ms再应答，那么这时返回的窗口大小就是1M。

(二)应当指出:延迟 反应 的 目的 不是 确保 可靠性,相反,它给接收缓冲器的数据留了较少的时间,以供上层应用程序尽可能使用,此时,ACK响应完成时,报告的窗口大小可以更大,从而增加网络吞吐量,然后提高数据传输效率.

此外,并非所有包都能延迟响应。

• 数量限制: 每个数据包应一次响应.
• 时间限制:应在最大延迟时间之后再给出答复(这个时间不会使错误在时间上重发)。

响应特定数量和加班时间的延迟取决于操作系统,通常需要N2和加班时间需要200ms。

13.捎带应答

(一)传输响应实际上是TCP通信的最常见的方式,就像A主机向B主机发送消息一样,当主机B接收此消息并需要用ACK响应时,但是如果宿主B在此时收到A号宿主的信息,此时,ACK将能够骑上风车,而不是单独发送ACK响应,此时,由主机B发送的消息已经发送了数据,还完成对收到的数据的答复,这就叫做捎带应答。

(二)传递答复的最直观角度也是发送数据的效率,在这种情况下,双方之间的通信不能再发送简单的确认信息。

(3)此外，由于捎带应答的报文携带了有效数据，因此对方收到该报文后会对其进行响应，当收到这个响应报文时不仅能够确保发送的数据被对方可靠的收到了，同时也能确保捎带的ACK应答也被对方可靠的收到了。

14.面向字节流

(1)当创建一个TCP的socket时，同时在内核中会创建一个发送缓冲区和一个接收缓冲区。

• 调用write函数就可以将数据写入发送缓冲区中，此时write函数就可以进行返回了，接下来发送缓冲区当中的数据就是由TCP自行进行发送的。
• 如果发送的字节数太长，TCP会将其拆分成多个数据包发出。如果发送的字节数太短，TCP可能会先将其留在发送缓冲区当中，等到合适的时机再进行发送。
• 当接收数据时,数据也从网络卡驱动器到内核到达接收缓冲器,并可以通过调用读取函数从接收缓冲器中读取。
• 当读函数调用来读缓冲区的数据时,它也可以通过任意数量的字节读取。

(2)由于缓冲器的存在,TCP程序的读写不需要互相匹配,例如:

• 当写100个字符的数据时,你可以调用一个写字来写100个字符,或者调用100写字来写一次字符。
• 读100个字节数据时，也完全不需要考虑写的时候是怎么写的，既可以一次read100个字节，也可以一次read一个字节，重复100次。

(3)事实上,对于TCP,它不在乎什么数据在缓冲区发送,在TCP中,看起来这些只是数据的碎片,它的任务就是将这些数据准确无误的发送到对方的接收缓冲区当中就行了，至于如何解释这些数据,完全由上层决定,这就叫做面向字节流。

15.粘包问题

(1)什么是粘包？

• 首先,很明显,粘贴包问题中的“包”是指应用程序层数据包。
• 在TCP的协议头条中,没有像UDP那样的“消息长度”字段。
• 从传输层的视角来看,TCP是一个输入的信息,按序列排列,并置于缓冲区。
• 但从应用程序层的视角来看,你看到的只是一系列连续的数据串。
• 所以应用程序会看到这样的数据串,并不知道从哪个部分开始到哪个部分,这是完整的应用程序层包。

如何解决粘贴问题

• 为了解决粘贴问题,关键在于澄清消息与消息(应用程序层)之间的界限。
• 对于长包, 请确保每次读一次以固定大小.
• 对于变长包,可以通过指定包的总长度的字段来确定头部的位置,以便知道包的末端位置。 例如,HTTP头部包含“内容长度”属性,表示一个正规表达式的长度。
• 对于变量包,可以在包和包之间使用一个清晰的分隔器。 因为应用程序层协议是由程序员自己决定的,所以只需要确保分隔器与常规表达式不冲突。

(三)UDP是否存在问题?

• 对于UDP,如果数据没有交付到上层,UDP的报告长度仍然存在,而UDP是一个将数据交付到应用程序层的,具有非常清晰的数据边界。
• 从应用程序层的视角看,当UDP被使用时,要么收到完整的UDP消息,要么没有收到“一半”。
• 因此,UDP并不是一个持久的问题,根本原因在于UDP消息的长度记录在UDP16位元UDP长度中,因此UDP澄清了报告与底部报告之间的界限,TCP的粘结问题是,因为TCP只有读取,TCP消息之间没有明确的界限。

16.TCP异常

(1)进程终止

• 当客户端正常访问服务器时，如果客户端进程突然崩溃了，此时建立好的连接会怎么样？
• 当一个进程退出时，进程使用的文件描述符将自动关闭,所以当客户端进程结束时,相当于自动调用关闭函数关闭相应的文件描述符,此时,底部的两个操作系统通常会完成四个波浪,然后释放相应的连接资源。也就是说，进程终止时将释放文件描述符,TCP底层仍然而,可以发送 FIN,并且没有区别于过程的正常退出。

(2)机器重启

• 当客户端正常访问服务器时,如果客户端主机重新启动并建立了良好的连接,会发生什么?
• 当我们选择重启主机时，操作系统会先杀掉所有进程然后再进行关机重启，因此机器重启和进程终止的情况是一样的，此时双方操作系统也会正常完成四次挥手，然后释放相应的连接资源。

(三)机器停电/断线

• 当客户端正常访问服务器时,如果客户端突然停机,当建立良好的连接时,会发生什么?
• 当客户端关闭时,服务器无法判断客户端在短时间内是否关闭,因此服务器与客户端保持连接,但这种连接不会永远持续,因为TCP是一个备份策略。
• 服务器会定期询问客户端的存在状况，检查对方是否在线，如果连续多次都没有收到ACK应答，此时服务器就会关闭这条连接。
• 此外，客户端也可能会定期向服务器“报平安”，如果服务器长时间没有收到客户端的消息，此时服务器也会将对应的连接关闭。
• 服务器定期询问客户端的存在状态的做法被称为基于备份调度器的心脏跳动机制,该机制由TCP实现。 此外,应用程序层的一些协议也有类似的检测机制,例如基于长连接的HTTP,它们也定期检测彼此的存在状态。

17.TCP小结

(一)保证可靠性机制:

• 检验和。
• 序列号。
• 确认应答。
• 超时重传。
• 连接管理。
• 流量控制。
• 拥塞控制。

(二)提高绩效的机制:

• 滑动窗口。
• 快速重传。
• 延迟应答。
• 捎带应答。

(3)TCP的这些机制有些能够通过TCP报头体现出来的，但还有一些是通过代码逻辑体现出来的。

(4)TCP定时器

• 重新设置计时器:控制丢失或丢弃消息段,即等待消息段的确认时间。
• 持久计时器:为另一方的零窗口通知设置,即向另一方发送的窗口检测间隔。
• 维护时间表:检查闲置连接的存在,即发送检测消息到另一方之间的间隔。
• TIME_WAIT 计时器:当两边波动四次时,启动断电的一方需要等待时间。

(五)了解输送管制议定书

• TCP的各个机制并没有真正谈论数据的实际传输,这些叫做数据传输策略。TCP协议在网络数据传输中作出决定,它提供了理论支持,例如,TCP要求,如果ACK响应在一定时间内没有收到,发送的消息应该被重新发送。实际数据传输实际上是由基础的IP和MAC帧进行的。
• TCP作出决定,IP+MAC执行,我们称之为通讯细节。它们的最终目的是向相反的主机发送数据。数据传输的目的由应用程序层决定。因此,应用层决定通信的意义,传输层及其后层决定了通信方式。

(六)与UDP可靠的交际(经典面试问题)

当前的现场平台使用UDP和TCP混合来避免彼此的缺点

• 介绍序列数目, 确保数据序列;
• 提出确认答复,确保数据被接收到相反的端;
• 引入超时再传输,如没有响应,则再传输数据;
• ......

18.基于TCP的应用程序层协议

(1)基于TCP的通用应用层协议如下:

• HTTP（超文本传输协议）。
• HTTPS（安全数据传输协议）。
• SSH（安全外壳协议）。
• 电话网(远程终端协议)。
• FTP（文件传输协议）。
• SMTP(电子邮件传输协议)。

(2)关于云服务器

• SSH是Xshell的基本协议,当我们使用Xshell时,实际上是ssh客户端使用Xshell连接到我们的云服务器。
• 我们在使用Xshell时，可以通过ssh 用户名@IP地址方式连接云服务器。实际就是因为我们的云服务器当中存在sshd这样的服务。

• 使用netstat命令查看相应的ssh服务

• 我们在云服务器上敲出的各种命令，最终会通过网络套接字的方式发送给服务器，由服务器来对我们的命令进行各种解释，进而执行对应的动作。

本文由 在线网速测试 整理编辑，转载请注明出处，原文链接：https://www.wangsu123.cn/news/29951.html。