图解OSI参考模型之传输层

关注公众号"知之洲"可以阅读本文全篇和其他优质干货。

        传输层工作在OSI七层参考模型的第4层,提供的是应用进程之间的逻辑通信服务。传输层提供了通用的传输接口,对高层用户屏蔽了下面通信子网的细节,使应用进程之间两个运输层实体之间看起来像是有一条端到端的逻辑通信信道。传输层是负责数据通信的最高层,因为网络层不一定保证服务的可靠,而用户也不能直接对通信子网加以控制,因此在网络层之上,加一层即传输层,对一个进行的对话或连接提供可靠的传输服务。

        因为进程的创建和撤销都是动态的,而通信的一方几乎无法识别对方机器上的进程,因此就要在运输层上使用协议端口号。将报文传输到目的主机的某个端口,剩下的工作,就由TCP来完成。(此处的端口,指的是软件端口,和路由器或交换机上的硬件端口是完全不同的概念。)

        TCP运输层端口号用一个16位的数字表示,分为服务器端使用的端口号和客户端使用的端口号。在服务器端使用的端口号中,从0到1023之间都数字被分配给TCP/IP协议中最重要的一些应用了,其他的端口号从1024到49151之间称之为登记端口号。客户端使用的端口号是留给客户端进程使用的,为从49152到65535之间的数字。

FTP

TELNET

SMTP

DNS

TFTP

HTTP

SNMP

21

23

25

53

69

80

161


        传输层提供了UDP和TCP这两种最常用的传输协议方式。UDP提供基于无连接的,尽力而为的通信服务,只管发送,不管对面有没有收到。TCP协议是面向连接的,它保证了可靠稳定的通信(有重传机制,能纠正乱序),

UDP

        UDP处理数据包的过程非常简单,在原有数据包的基础上加上一些带有标识性的信息段,通过网卡传输,之后就不再关注该数据包的状态了。本质上这些数据包之间没有什么实质性的联系。正是由于它的过程非常简单,对于设备的计算损耗也相对较小,因此可以大大提高数据的传输速率。对于一些对数据完整性要求不高的情况可以采用UDP的方式,比如DNS协议的传输层就是用的UDP。

16位源端口号

16位目的端口号

长度

校验值

数据...

TCP

TCP报文都格式如下:

16位源端口号

16位目的端口号

32位序号seq(随机生成,用于唯一标识当前的报文)

32位确认序号ack(用于对上一条发送的信息进行消息确认)

4位首部长度

保留6位

U
R
G

ACK

确认收到

P
S
H

K
S
T

SYN

发起新连接

FIN

结束连接

16位校验和

16位紧急指针

选项

padding

数据...

        这里特别提醒一下要区别开ACK标志位和确认序号ack。ACK标识位只有1位,要么为0,要么为1,为1时表示确认收到连接请求。ack有32位,一般为上一条seq + 1,用于对上一条发送的信息进行消息确认。SYN标志位为1时,表示发起新的连接。FIN标志位为1时,表示结束连接。

        TCP的超时重传使用TCP协议在发送端每发送一个报文段,就保留一个副本并启动一个定时器并等待确认;接收端成功接收新数据后就会将ACK确认标位置为1返回。若在定时器超时前数据未能被确认,TCP就会重新发送这段报文,直到发送成功为止。

        影响超时重传机制协议效率的一个关键参数是超时时间(RTO,Retransmission TimeOut)。如果RTO设置过大将会使发送端经过较长时间的等待才能发现报文段丢失,降低了数据传输的吞吐量;若RTO设置过小,发送端可能将一些延迟的报文段误认为丢失了,造成不必要的重传。

        TCP的底层网络环境是一个完全异构的互联结构。在实现端到端的通信时,不同端点之间传输通路的性能可能存在着巨大的差异,而且同一个TCP连接在不同的时间段上,也会由于不同的网络状态具有不同的传输时延。 为此,TCP协议使用自适应算法(Adaptive Retransmission Algorithm)去监视每个连接的性能(即传输时延),为每一个TCP连接推算出合适的RTO值,当连接时延性能变化时,TCP也能够相应地自动修改RTO的设定,以适应这种网络的变化。

        TCP协议采用自适应算法记录数据包的往返时延,并根据往返时延设定RTO的取值。一般来说,RTO的取值会略大于输往返时间(RTT,Round Trip Time,所有网络上报文段的数据传输加上确认传输的时间)以保证数据包的正常传输。

        这里将各个报文段的往返时间样本进行加权平均,得到加权平均往返时间(Smoothed RTT),假设 RTTS 为加权平均往返时间,RTTD 是偏差的加权平均值。大致使用下面的算式计算RTO

RTO = RTTS + 4 × RTTD

        第一次测量往返时间时,RTTS 值就取所测量到的RTT样本值,以后每测量到一个新的往返时间样本,就按下面的式子重新计算一次平滑往返时间RTTS 。当不再发生数据包重传时,又会根据上图所示的算式重新计算超时重传时间。

RTTS = α × 旧RTTS + (1-α) × 新RTT样本

        上面算式中0≤α<1 称为平滑因子。若 α 越接近于1,即新计算出的RTTS和原来的值相比变化不大,新的往返时间RTT样本对 RTTS 的影响越小,典型的 α 7/8

        TCP/IP 协议是传输层的面向连接的安全可靠的传输协议,在这个协议中客户端和服务端都要保证自己能够发送数据和收到数据,因此就出现了三次握手和四次挥手。

1. 第一次握手,客户端向服务器发起(申请建立连接)

客户端 — 不知道自己能不能发送数据,不知道自己能不能收到数据

服务端 — 不知道自己能不能发送数据,知道自己能不能收到数据 (服务端收到申请之后)

2. 第二次握手,服务器回复客户端(确认并接受连接请求)

客户端 — 知道自己能发送数据,不知道自己能不能收到数据(客户端收到反馈之后)

服务端 — 不知道自己能不能发送数据,知道自己能收到数据

3. 第三次握手,客户端向服务器发起(确认收到服务器的回复)

客户端 — 知道自己能发送数据,知道自己能收到数据

服务端 — 知道自己能发送数据,知道自己能收到数据(服务端收到反馈之后)

这样保证了客户端和服务端都确认可以发送和接收报文,即所谓的双工

四次挥手可以由任意一方发起,这里以客户端发起举例。

1. 第一次挥手,客户端向服务器发起(申请断开连接)

2. 第二次挥手,服务端回复客户端(确认收到,但是此时不一定可以关闭连接)

3. 第三次挥手,服务端发送给客户端(确认可以关闭连接)

4. 第四次挥手,客户端发给服务端(确认收到)

关注公众号“知之洲”可以获得更多优质干货。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

知之洲

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值