文章目录
传输层
传输层:提供应用进程之间的逻辑通信机制,这里“逻辑通信”的意思是:从应用层来看,只要把应用层报文交给下面的运输层,运输层就可以把这报文传送到对方的传输层。但是,好像这种通信就是沿水平方向传送数据。但事实上这两个运输层之间并没有一条水平方向的物理连接。
复用和分用
复用和分用的理解
"复用"指的是发送方在不同的应用进程都可以使用同一个运输层协议传送数据。”分用“是指接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。
多路分用
每个数据报携带IP地址、目的IP地址,每个数据报携带一个传输层的段,每个段携带端口号和目的端口号。
主机收到报文段后,传输层提取IP地址和端口号信息,将报文段导向响应的Socket
无连接多路分用
面向连接的分用
UDP协议
属于无连接协议:UDP发送方和接收方之间不需要握手,UDP尽最大可能交付、面向报文,没有拥塞控制,头部开销少,支持一对一、一对多、多对一和多对多,的交互通信。
**无连接:**发送数据之前不需要建立连接,通信结束也不需要释放连接。
**尽最大努力交付:**不保证可靠交付,不能保证每一个数据都能到达。
**面向报文:**对应用层交下来的报文,既不合并,也并不拆分,只是添加UDP头部
**没有拥塞控制:**网络出现的拥堵不会使源主机的发送速率降低。
支持一对一、一对多、多对一和多对多的交互通信
UDP校验和:检测UDP段在传输中是否发生错误
UDP的首部格式
字段意义:
源端口:源端口号
**目的端口:**目的端口号,在终点交付报文时必须使用。
**长度:**UDP数据报的长度,最小值8
**检验和:**检测UDP用户数据报在传输中是否有错
TCP协议
1.**面向连接的传输层协议:**应用进程在使用TCP协议之前,必须先建立TCP连接。
2.每一条TCP连接只能由两个连接。
3.TCP提供可靠交付的服务。通过TCP连接传送的数据,无差错,不丢失、不重复。
4.TCP提供全双工通信。允许双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存。
5.面向字节流。TCP的”流“**指的是流入到进程从进程流出的字节序列。**这里的含义是虽然应用进程和TCP的交互是一次一个数据块,但TCP把应用程序交下来的数据不仅仅看成一连串的无结构的字节流。
TCP报文段的首部格式
字段意义:
1、源端口和目的端口。
2、序号:范围0~每一个字节都按顺序编号。
一报文段的序号值为301,而携带的数据共有100字节。这就表明:本报文段的数据的第一个字节的序号是301,而最后一个字节段的序号是400,下一个报文段的序号应该从401开始。
3、确认号(4字节):是期望收到下一个报文段的第一个数据字节的序号。
若确认号 =N,则表明到序号N-1为止的所有数据都已正确收到。
4、**数据偏移(占4位):**实际上是首部的长度,由于首部还有长度不确定的选项字段。
5、保留:保留为今后使用,但目前应该置为0
6、紧急(URG):当UGR=1,表明紧急指针有效,系统在知道该报文段有紧急数据时,会尽快传送。
7、确认位ACK:仅当ACK=1时,确认号才有效。
8、推送位(PSH):当收到PSH =1时,系统将不再等到整个缓存填满后再上交
9、复位RST:当RST=1时,表明TCP中出现严重差错。必须释放连接,然后再重新建立运输连接。
10、同步(SYN):在连接时同步序号。SYN 置为1表示这是个连接请求或连接接受报文。
11、终止FIN:用来释放一个连接。
12、窗口:从本报文段首部的确认号算起,接受方目前允许对方发送的数据量。窗口值作为接收方让发送方设置其发送窗口的依据。
13、检验和:检验和字段检验的范围包括首部和数据两部分。
14、紧急指针:当URG =1时才有意义,它指出本报文中的紧急数据的字节数。
TCP三次握手
A主动打开连接,B被动打开连接。B服务器的TCB进程先创建传输控制块TCB,准备接收客户进程的连接请求。
第一次握手:A向B发送请求连接报文段,报文段为SYN =1,seq =x,SYN报文段不携带数据,选择一个序列号。
第二次握手:B服务器收到请求后,同意连接就向A发送确认。将SYN和ACK都置为1,更新确认号ack =x+1;选择一个序号y,服务器的状态更新到SYN-RCVD.
第三次握手:客户端收到B的同意连接的应答后,再向B发送确认,设置ACK=1,序列号更新为x+1,A状态更新为ESTABLISHED。
四次握手
当B给A发送报文时,可以先发送一个确认报文段(ACK=1,ack = x+1),然后再发送一个同步报文段(SYN=1,seq =y)。B发送给A的报文分成两次发送,这就可以叫做四次握手。
TCP四次挥手
我们都知道TCP连接是全双工的,因此在四次挥手中,需要关闭两个方向上的连接。
第一次挥手:A的应用进程先向TCP发送连接释放请求,将释放报文首部的终止位FIN置1,选择一个序列号。更新状态由ESTAB-LISHED到FIN-WAIT-1。
第二次挥手:B的应用进程收到后,发出确认,确认号ack=u+1,然后B的状态由ESTAB-LISHED更新为CLOSE-WAIT,此时TCP连接处于半连接的状态,当第二次挥手完成,A到B方向的连接已经释放,此时A不会发送数据,B不会再接收数据。但是B到A方向的连接还是存在的,B可以继续向A发送数据。A收到B的确认后,状态就更新到FIN-WAIT-2。
第三次握手:B向A发送释放连接请求,FIN=1,ACK=1,seq=w,ack =u+1,然后B就进入LAST-ACK最后确认,等待A的确认
第四次握手:A收到B的请求释放后进行确认,ACK=1,ack =w+1,B进入CLOSED状态,A进入TIME-WAIT(时间等待)状态,然后等待时间等待计时器设置的时间2MSL后,A进入到CLOSED状态。
TCP数据可靠数据传输原理状态
理想情况不错、不丢、不乱
TCP在不可靠的信道上传输双向的
Rdt2.0协议
底层信道利用校验和检测位错误
确认机制(ACK机制)ARQ机制
引入的新机制:差错检测,接收方反馈控制消息:ACK/NAK。
接收方在接收到数据后可以回复ACK和NAK,当收到正确的数据时,即回复ACK,但收到确认号数据和期望收到的数据字段号不一致时,给发送发恢复NAK,要求其重传。
有错误的场景
Rdt3.0
当出现 校验和+序列号+ACK+重传不够用时。比如数据在传输过程中出现错误也丢失分组,就不够用了。
超时重传
当TCP发送一个报文段,就对该报文段设置一个timeer进行计时。当计时器设置的重传时间达到还没收到接收方的回复时,就需要重传这一报文段。
流水线机制
允许发送方在收到ACK之前连续发送多个分组,更大的序列号范围
发送方和或接收方需要大的存储空间以缓存分组
滑动窗口协议,在发送方维持一个一定大小的发送窗口,位于窗口内的分组可以连续发送,不需要等待接收方的的确认,这样就可以提高了传输效率。
注意:发送端的窗口和接收端的窗口不一定一样大。但是发送端的窗口是根据接收端窗口的大小来设定的,
GBN,SR
ACK(N)确认收到前N-1个package
当接收方收到乱序到达的数据时,由于采用的是累计确认机制,乱序到达的数据都会被丢弃,然后发送方就会对错误的数据进行重传。所以就会存在缺陷:会存在重传太多数据,浪费资源。
SR协议
对每个分组进行单独确认,设置缓存机制,缓存乱序到达的分组
只重传那些没有收到ACK的组
接收方和发送方的窗口不同,如果接收方收到同一个序列号,但是pkt不同,这就是SR的困境。
TCP流量控制
发送方发送速率太快,buffer溢出
接收方不能收, 这时候我们增加一个处理,TCP发送方仍可以发送一个小信息。
拥塞控制
理想状况:路由的缓存足够大,在传输过程中不会发生拥塞
当往网络里面不断发数据,可能出现死锁,即网络瘫痪了。
慢开始
判断网络拥堵的依据就是出现了超时。
慢开始算法:当主机开始发送报文段时,由于不清楚网络的复合情况,直接把大量数据注入到网络中的话,网络可能发生拥堵。所以较好的方法是先探测下网络状况,由小到大增大拥塞窗口的数值。
慢开始算法开始后,每经过一个传输轮次,拥塞窗口(cwnd)就加倍,呈指数型增长。
拥塞控制算法
为了防止拥塞窗口增长过快,还需要设置一个慢开始门限(ssthresh)。
当cwnd<ssthresh,使用上述的慢开始算法
当cwnd>ssthresh,停止使用慢开始算法而改用拥塞避免算法。
当cwnd=ssthresh时,既可以使用慢开始算法,也可以使用拥塞避免算法。
拥塞避免算法的思路时让拥堵窗口cwnd缓慢增大,每经过一个往返时间RTT就将发送方的拥塞窗口cwnd加1,而不是像慢开始阶段那样加倍增长。
拥堵处理:只要判断网络出现拥堵,就将ssthresh设为原来的一半,拥堵窗口重新设置为1,执行慢开始算法。
拥塞避免只是把拥塞窗口控制为线性规律增长,使网络比较不容易出现拥塞。
快重传算法
在网络中,个别报文会在网络中丢失,但实际上网络并未发生拥塞,就会产生超时,就会误认为网络发生了拥塞。
快重传:接收方在接收到报文立马就要对已收到的报文段回复确认,就算是失序的报文段也要立即发出对已收到的报文段的重复确认。
比如接收方已经收到M1和M2后,分别给出了确认,但是接收方下一个接收到了M4,按照快重传算法,接收方需要立即发送对M2的重复确认,当发送方一连接收到3个重复确认,就知道接收方没有收到报文,就立刻进行重传。
快恢复算法
我们前面说对拥塞控制,当发生拥堵后,将拥塞窗口设置为1,慢开始上限减半。但是快恢复,是将拥堵窗口设置成慢开始上限即swnd =ssthresh;
总结
本文是在学习时做的笔记,可能写的比较糙,如果有什么问题,可以在评论区吐槽。