作为架构师#xff0c;我们所设计的系统很少为单机系统#xff0c;因此有必要了解计算机和计算机之间是怎么联系的。

局域网的集群和混合云的网络有啥区别。

系统交互的时候网络会存在什么瓶颈。

既然网络层已经…

作为架构师我们所设计的系统很少为单机系统因此有必要了解计算机和计算机之间是怎么联系的。

局域网的集群和混合云的网络有啥区别。

系统交互的时候网络会存在什么瓶颈。

既然网络层已经能把源主机上发出的数据传送给目的主机,那么为什么还需要加上一个传输层呢?这就需要我们理解主机用户应用层通信的主体位于两台网络主机中真正的数据通信主体并不是这两台主机而是两台主机中的各种网络应用进程。

同一时间一台主机上可能有多个进程同时运行这时候就需要为应用程序提供一个标识那就是端口.而传输层就是为了提供这种端到端的服务而存在的.

端口分为知名端口和动态端口。

有些网络服务会使用固定的端口这类端口称为知名端口端口号范围为0~1023。

比如FTPHTTPTelnetSNMP服务均使用知名端口。

动态端口范围1024~65535这些端口号一般不会固定分配给某个服务也就是说许多服务都可以使用这些端口。

只要运行的程序向系统提出访问网络的申请那么系统就可以从这些端口号中分配一个供该程序使用。

运输层是只有主机才有的层次传输层使用网络层的服务为应用层提供通信服务。

传输层定义了主机应用程序之间端到端的连通性。

传输层中最为常见的两个协议分别是传输控制协议TCPTransmission

Control

UDP是一种面向无连接的传输层协议传输可靠性没有保证。

udp只在ip数据报服务之上增加了很少功能即复用分用和差错检测功能

4.udp无拥塞控制适合很多实时应用

主机A发送数据包时这些数据包是以有序的方式发送到网络中的每个数据包独立地在网络中被发送所以不同的数据包可能会通过不同的网路径叨叨主机B。

这样的情况下先发送的数据包不一定先到达主机B。

因为UDP数据包没有序号主机B将无法通过UDP协议将数据包按照原来的顺序重新组合所以此时需要应用程序提供报文的到达确认排序和流量控制等功能也就是说UDP报文的到达确认排序和流量控制是应用程序来确定的。

通常情况下UDP采用实时传输机制和时间戳来传输语音和视频数据。

TCP协议

TCP是一种面向连接的端到端协议。

TCP作为传输控制协议可以为主机提供可靠的数据传输。

TCP需要依赖网络协议为主机提供可用的传输路径。

TCP允许一个主机同事运行多个应用进程。

每台主机可以拥有多个应用端口每对端口号源和目标IP地址的组合唯一地标识了一个会话。

Repeat-reQuest是OSI模型中数据链路层和传输层的错误纠正协议之一。

它通过使用确认和超时这两个机制在不可靠服务的基础上实现可靠的信息传输。

如果发送方在发送后一段时间之内没有收到确认帧它通常会重新发送。

ARQ包括停止等待ARQ协议和连续ARQ协议拥有错误检测Error

Acknowledgment、超时重传Retransmission

after

由于停止等待ARQ协议信道利用率太低所以需要使用连续ARQ协议来进行改善。

这个协议会连续发送一组数据包然后再等待这些数据包的ACK。

发送方采用流水线传输。

流水线传输就是发送方可以连续发送多个分组不必每发完一个分组就停下来等待对方确认。

如下图所示

连续ARQ协议通常是结合滑动窗口协议来使用的发送方需要维持一个发送窗口如下图所示

图a是发送方维持的发送窗口它的意义是位于发送窗口内的5个分组都可以连续发送出去而不需要等待对方的确认这样就提高了信道利用率。

连续ARQ协议规定发送方每收到一个确认就把发送窗口向前滑动一个分组的位置。

例如上面的图b当发送方收到第一个分组的确认就把发送窗口向前移动一个分组的位置。

如果原来已经发送了前5个分组则现在可以发送窗口内的第6个分组。

接收方一般都是采用累积确认的方式。

也就是说接收方不必对收到的分组逐个发送确认。

而是在收到几个分组后对按序到达的最后一个分组发送确认。

如果收到了这个分组确认信息则表示到这个分组为止的所有分组都已经正确接收到了。

累积确认的优点是容易实现即使确认丢失也不必重传。

但缺点是不能正确的向发送方反映出接收方已经正确收到的所以分组的信息。

比如发送方发送了前5个分组而中间的第3个分组丢失了这时候接收方只能对前2个发出确认。

而不知道后面3个分组的下落因此只能把后面的3个分组都重传一次这种机制叫Go-back-N回退N表示需要再退回来重传已发送过的N个分组。

滑动窗口协议

1凡是已经发送过的数据在未收到确认之前都必须暂时保留以便在超时重传时使用。

2只有当发送方A收到了接收方的确认报文段时发送方窗口才可以向前滑动几个序号。

3当发送方A发送的数据经过一段时间没有收到确认由超时计时器控制就要使用回退N步协议回到最后接收到确认号的地方重新发送这部分数据。

流量控制

一条TCP连接每一侧主机都为该连接设置了接收缓存。

当该TCP连接收到了正确的、按序的字节后他就将数据放入接收缓存。

相关联的应用进程会从该缓存中读取数据。

但不必是数据一到达就立即读取。

事实上接收方也许正忙于其他任务甚至要过很长时间后才读取该数据。

如果某个应用进程读取比较缓慢但是发送方发送的太多、太快发送的数据就会很容易地使该连接的接收缓存溢出。

TCP为它的应用程序提供了流量控制服务(flow-control

service)以消除发送方使接收方缓存溢出的可能性。

流量控制因此是一个速度匹配服务即发送方的发送速率与接收方应用程序的读取速率相匹配。

window)的变量(TCP报文段首部的接收窗口字段)来提供流量控制。

通俗的讲接收窗口用于给发送方一个指示该接收方还有多少可用的缓存空间。

因为TCP是全双工通信在连接两端的发送方都各自维护了一个接收窗口。

拥塞控制

拥塞控制是作用于网络的它是防止过多的数据注入到网络中避免出现网络负载过大的情况常用的方法就是

慢开始、拥塞避免

拥塞窗口:是为了避免发生拥塞而设置的窗口,最终发送的字节数是接收端为发送端设置的发送窗口和拥塞窗口的最小值.

慢启动阈值(SSTHRESH):初始值是64k,即65535个字节,当发生一次数据丢失时,其值变为拥塞窗口大小的一半.

慢启动

主机刚开始发送报文段时先将拥塞窗口的大小设置为一个MSS(该连接上当前使用的最大数据段大小)。

每收到一个报文段的确认后,将拥塞窗口增加最多一个MSS的大小。

以此类推,用这样的方法逐步增大发送端拥塞窗口的大小,使分组注入到网络的速率更加合理直到拥塞窗口的值达到慢启动阈值,这时候拥塞避免就发挥作用了.

该方案不再像慢启动一样以指数速度增长拥塞窗口的大小,而是到达慢启动阈值后,按线性规律增长,是网络比较不容易出现拥塞.

以上两个方案配合使用,可有效减少网络拥塞的影响,但不能完全避免拥塞情况,后来又提出了快速重传和快速恢复机制

快重传和快恢复

快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认。

这样做可以让发送方及早知道有报文段没有到达接收方。

发送方只要一连收到三个重复确认即认为对应确认号上的字段已丢失,TCP不等重传定时器失效,就重传已丢失的数据,此为快速重传同时快速恢复发挥作用,把当前拥塞窗口大小设置为当前慢启动阈值大小的一半以减轻网络负荷,然后再执行拥塞避免。

不难看出快重传并非取消重传计时器而是在某些情况下可更早地重传丢失的报文段。

连接管理

建立连接TCP通常使用IP作为网络层协议这是TCP数据被封装在IP数据包内。

TCP数据段由TCP

Header头部和TCP

Data数据组成。

TCP最多可以有60个字节的头部如果没有Options字段正常的长度是20字节。

1主机A通常也叫客户端发送一个标识了SYN数据段标识期望与服务器A建立连接此数据段的序列号seq为a

2服务器A回复标识了SYNACK的数据段此数据段的序列号seq为b确认序列号为主机A的序列号加1a1以此作为对主机A的SYN报文的确认。

3主机A发送一个标识了ACK的数据段此数据段的序列号seq为a1确认序列号为服务器A的序列号加1b1以此作为对服务器A的SYN报文段的确认。

TCP是一种可靠的面向连接的全双工传输层协议。

TCP连接的建立是一个三次握手的过程。

tcp连接是全双工的数据在两个方向上能同时传递。

所以要确保双方同时能发数据和收数据

第二次握手ack确保了接收方能收数据syn确保了接收方能发数据

实际上是四个维度的信息交换不过中间两步合并为一次握手了。

四次握手浪费两次握手不能保证“双方同时具备收发功能”

因为tcp连接是全双工的数据在两个方向上能同时传递。

同时tcp支持半关闭发送一方结束发送还能接收数据的功能。

因此每个方向都要单独关闭且收到关系通知需要发送确认回复

为什么要支持半关闭

客户端需要通知服务端它的数据已经传输完毕同时仍要接收来自服务端的数据使用半关闭的单连接效率要比使用两个tcp连接更好