传输层功能
- 应用进程间的逻辑通信(即端到端的通信)
- 复用与分用。复用指发送方不同的应用进程都可以使用同一个传输层协议传送数据;分用是指接收方的传输层在剥去报文的首部之后能够把数据正确交付到目的应用进程
- 对收到的报文进行差错检测(首部和数据部分),而网络层只检查IP数据报的首部,不检验数据部分
- 提供两种不同的传输协议:面向连接的TCP和无连接的UDP
传输层的寻址与端口
端口作用:
能够将应用层的各种应用进程通过端口将其数据向下交付给传输层,以及让传输层知道应当将报文段中的数据向上通过端口交付给应用层的对应进程。
端口号:
应用进程通过端口号进行标识,端口号长度为16bit,(65536个不同的端口号),端口号只具有本地意义。
0-49151: 服务器端使用的端口号,又分为熟知端口号(0-1023)和登记端口号(1024-49151)
49152-65535:客户端使用的端口号
套接字:
实际上是一个通信端点。套接字Socket=(IP地址:端口号),套接字能唯一地标识网络中地一台主机和其上的一个应用进程。
UDP协议
UDP是面向报文的。
UDP只在IP数据报的基础上增加两个最基本的服务:复用和分用以及差错检测
UDP优点:
- 无需建立连接,没有建立连接的时延
- 无连接状态所以不需要在端系统维护状态。即不需要维护接收和发送缓存、拥塞控制参数和序号与确认号这些参数;
- 分组首部开销小(TCP 20B,UDP 8B)
- 应用层能更好地控制要发送地数据和发送时间。因为UDP没有拥塞控制,所以网络中的拥塞不会影响主机的发送效率。UDP适合于:要求以稳定的速度发送,能容忍一些数据的丢失但不允许有较大时延的实时应用
- UDP支持一对一、一对多、多对一、多对多的交互通信。
UDP应用
常用于一次性传输较少数据的网络应用,如DNS和SNMP;也适用于多媒体应用,比如IP电话,实时视频会议
TCP协议
TCP是面向连接的传输层协议
特点:
- TCP是面向连接的传输层协议,TCP连接是一条逻辑连接
- 每条TCP连接只能有两个端点,每条TCP连接是端到端的(进程对进程)
- TCP提供可靠交付的服务
- TCP提供全双工通信,允许通信双方任何进程在任何时候都能发送数据,为此TCP连接的两端都设有发送缓存和接收缓存。
- TCP是面向字节流的,虽然应用程序和TCP的交互是一次一个数据块(大小不等),但TCP把应用程序交下来的数据仅视为一连串的无结构的字节流
总结三特点:面向连接、可靠、基于字节流。
TCP连接管理
每个TCP连接都有三个阶段:连接建立、数据传送和连接释放。
TCP连接的建立:
TCP连接的释放:
MSL 是 Maximum Segment Lifetime,报文最大生存时间
为什么需要 TIME_WAIT 状态?
主动发起关闭连接的一方,才会有TIME-WAIT 状态。
需要 TIME-WAIT 状态,主要是两个原因
- 防止旧的重复数据包干扰新连接(TCP/IP协议栈在TIME_WAIT状态期间不会允许使用同一对端口和IP地址的连接重新建立。这是为了确保在当前连接完全终止之前,任何可能在网络中延迟的旧数据包不会干扰后续新的连接。);
- 保证「被动关闭连接」的一方,能被正确的关闭(进入TIME_WAIT状态的一方会等待2倍的最大报文生存时间(MSL, Maximum Segment Lifetime),确保对方能够接收到这个ACK报文。);
TCP可靠传输
- 序号:TCP首部的序号字段用来保证数据能有序提交给应用层。TCP连接传送的数据流中的每个字节都编上一个序号。序号字段的值是指本报文所发送的数据的第一个字节的序号
- 确认: TCP首部的确认号是接收方希望收到的下一个报文段的数据的第一个字节的序号
- 重传: 超时和冗余ACK
TCP流量控制
TCP提供一种基于滑动窗口协议的流量控制机制。
在通信过程中,接收方根据自己接收缓存的大小,动态地调整发送方的发送窗口大小,这称为接收窗口rwnd。
例如,在通信中,有效数据只从A发往 B,而B仅向A发送确认报文段首部的窗口字段来将rwnd 通知给 A。
TCP拥塞控制
拥塞控制是指防止过多的数据注入网络,保证网络中的路由器或链路不致过载。
拥塞控制与流量控制的区别:拥塞控制是让网络能够承受现有的网络负荷,是一个全局性的过程,涉及所有的主机、所有的路由器,以及与降低网络传输性能有关的所有因素。相反,流量控制往往是指点对点的通信量的控制,是个端到端的问题(接收端控制发送端),它所要做的是抑制发送端发送数据的速率,以便使接收端来得及接收。当然,拥塞控制和流量控制也有相似的地方,即它们都通过控制发送方发送数据的速率来达到控制效果。
慢开始;拥塞避免
快重传;快恢复
网络质量不好,丢包率较高的情况下使用UDP还是TCP?
答:优先考虑UDP协议。
因为各种丢包和重传,以及指数退避算法导致的。
指数退避算法
指数退避算法是适用于网络应用的标准错误处理策略,使用这种策略时,客户端会定期重试失败的请求,并不断增加各次请求之间的延迟时间。客户端应对发送到 Memorystore for Redis 且返回 HTTP 5xx 和 429 响应代码错误的所有请求使用指数退避算法。
指数退避算法以指数方式重试请求(不断增加各次重试之间的等待时间,直到达到最大退避时间)。比如说在我们的服务调用过程中发生了调用失败,系统要对失败的资源进行重试,那么这个重试的时间如何把握,使用指数退避算法我们可以在某一范围内随机对失败的资源发起重试,并且随着失败次数的增加长,重试时间也会随着指数的增加而增加。
参考链接
示例如下:
向 Memorystore for Redis 发出请求。
如果请求失败,请等待 1 + random_number_milliseconds 秒后再重试请求。
如果请求失败,请等待 2 + random_number_milliseconds 秒后再重试请求。
如果请求失败,请等待 4 + random_number_milliseconds 秒后再重试请求。
依此类推,等待时间上限为 maximum_backoff。
等待时间达到上限后,您可以继续等待并重试,直到达到重试次数上限(但接下来的重试操作不会增加各次重试之间的等待时间)。