计算机网络基础之传输层

传输层在计算机网络中负责确保数据从发送端传输到接收端。端口号用于识别同一台计算机上的不同应用程序,分为静态和动态分配。UDP协议是不可靠、无连接、面向数据报的,适用于DNS、SNMP、多媒体通信等场景。TCP协议提供可靠传输、面向连接,具有序列号、确认应答、超时重发等机制,适用于HTTP、FTP等应用。TCP的滑动窗口、高速重传、延迟应答等机制平衡了可靠性和性能。

目录

传输层的作用

端口号

UDP协议

TCP协议

TCP协议实现的机制


传输层的作用

        负责数据能够从发送端传输到接收端。


端口号

一、定义

        用来识别同一台计算机中进行通信的不同应用程序,也被称为程序地址。

        TCP/IP或UDP/IP通信中通过5个信息来识别一个通信:源IP地址、目的IP地址、协议号、源端口号、目的端口号。

       

二、使用

 进行实际通信时,要事先确定端口号

         ①静态方法:每个应用程序都有其指定的端口号,每个端口号都有其对应的使用目的。例:知名端口号

         ②动态(时序)分配法:服务端有必要确定监听端口号,但接受服务的客户端没必要确定端口号。

                                               (由操作系统为每个应用程序分配互不冲突的端口号并动态管理:49152~65535)

三、补充

  • 端口号由其使用的传输层协议决定,不同的传输协议可以使用相同的端口号。(端口号的处理是根据每个传输协议的不同而进行的)
  • TCP/UDP协议-->端口号(源端口号/目的端口号)-->根据端口号可以识别在传输层上一层的应用层中所要进行处理的具体程序。    

UDP协议

一、不可靠传输;无连接;面向数据报。(常被用于让广播和细节控制交给应用的通信传输、多播与广播通信)

  • 不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对⽅, UDP协议层也不会给应用层返回任何错误信息;                  
  • 无连接: 知道对端的IP和端口号就直接进行传输, 不需要建⽴连接;   
  • 面向数据报:不能够灵活的控制读写数据的次数和数量。 应用层交给UDP多长的报⽂, UDP原样发送, 既不会拆分, 也不会合并。

二、特点

  • 按照“制作程序的那些用户的指示形式”(用户说什么它就听什么);
  • 网络拥堵时也无法进行流量控制等避免网络拥塞的行为;
  • 若传输过程中丢包,UDP不负责重发(没有重发机制);
  • 本身的处理简单高效;
  • 随时发送数据;

三、适用场景

  • 包总量比较少的通信(DNS、SNMP等)
  • 视频、音频等多媒体通信(即时通信)
  • 限定于LAN等特定网络中的应用通信
  • 广播通信(广播、多播)

四、首部格式

         由源端口号目的端口号包长校验和组成。

        

         UDP协议首部中有⼀个16位的包长度。也就是说⼀个UDP能传输的数据最大长度是64K(包含UDP首部).,然而在当今的互联网环境下, 64K是⼀个非常小的数字,如果我们需要传输的数据超过64K, 就需要在应用层手动的分包,多次发送, 并在接收端手动拼装。

五、基于UDP的应用层协议:

  • NFS: 网络⽂件系统 
  • TFTP: 简单文件传输协议
  • DHCP: 动态主机配置协议 
  • BOOTP: 启动协议(用于无盘设备启动) 
  • DNS: 域名解析协议

六、UDP没有真正意义上的发送缓冲区,但是具有接收缓冲区;UDP的socket既能读也能写,是全双工。

用UDP实现可靠传输:参考TCP的可靠性机制, 在应用层实现类似的逻辑。

例如:

  • 引⼊序列号, 保证数据顺序; 
  • 引⼊确认应答, 确保对端收到了数据; 
  • 引⼊超时重传, 如果隔⼀段时间没有应答, 就重发数据;

    . . .


TCP协议

一、可靠传输;面向连接;字节流服务

二、特点:TCP既要保证可靠性, 同时又要尽可能的提高性能

  • TCP实现可靠性传输:通过检验和、序列号、确认应答、超时重发、连接管理、流量控制、拥塞控制等机制。
  • TCP提高性能:通过滑动窗口、高速重传、延迟应答、捎带应答等机制。 

三、首部格式:

       

  • 源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去。
  • 序列号:指发送数据的位置,每发送一次数据,就累加一次该数据字节数的大小。
  • 确认应答号:指下一次应该收到的数据的序列号。实际上它是指已收到确认应答号减1为止的数据。发送端收到这个确认应答后可以认为在这个序号之前的数据都已经被正常接收。

        序列号是按顺序给发送数据的每一个字节(8位)都标上号码的编号,接收端查询接收数据TCP首部中的序列号和数据的长度,将自己下一步应该接收的序号作为确认应答返送回去

  • 4位TCP首部长度: 表示该TCP头部有多少个32位bit(有多少个4字节),所以TCP首部最大长度是15 * 4 = 60。
  • 6位控制位(标志位): (置1有效 置0无效)
    • URG: 紧急指针是否有效 (插队)
    • ACK: 确认号是否有效(一般置18)
    • PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走(急于发送)
    • RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
    • SYN: 请求建立连接; 标识自己是连接请求的报文。(SYN = 1为连接请求)
    • FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段
  • 16位窗口大小:用于通知从相同TCP首部的确认应答号所指位置开始能够接收的数据大小(8位字节)。TCP不允许发送超过此处所示大小的数据。如果窗口为0,可以发送窗口探测,以了解最新的窗口大小(但这个数据必须是1个字节)。
  • 校验和:发送端填充, CRC校验. 接收端校验不通过时, 则认为数据有问题. 此处的检验和不光包含TCP ⾸部, 也包含TCP数据部分。如果计算校验和字段在内的所有数据的16位和以后,得出的结果"16位全部为1"则说明所收到的数据是正确的。
  • 16位紧急指针:标识出紧急数据的末尾在报文段中的位置。(只有在URG控制位为1时有效)
  • 头部选项:暂时忽略。

四、基于TCP的应用层协议:

        HTTP、HTTPS、SSH、Telnet、FTP、MTP、SMTP

        

五、TCP的粘包问题

  1. 什么是粘包:首先要明确, 粘包问题中的 "包" , 是指的应用层的数据包。在TCP的协议头中, 没有如同UDP⼀样的 "报文长度" 这样的字段, 但是有⼀个序号这样的字段. 站在传输层的角度, TCP是⼀个⼀个报文过来的. 按照序号排好序放在缓冲区中. 站在应用层的角度, 看到的只是⼀串连续的字节数据. 那么应用程序看到了这么⼀连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是⼀个完整的应用层数据包。
  2. 粘包原因:TCP面向字节流。
  3. 解决粘包问题:明确两个包之间的边界。
  4. UDP协议不存在粘包问题。

六、创建⼀个TCP的socket, 同时在内核中创建⼀个 发送缓冲区 和⼀个 接收缓冲区。

TCP与UDP的区别:

  • TCP用于可靠传输的情况, 应用于⽂件传输, 重要状态更新等场景。
  • UDP用于对高速传输和实时性要求较高的通信领域, 例如, 早期的QQ, 视频传输等. 另外UDP可以用于广播。

TCP协议实现的机制

从上面的TCP协议中我们了解到TCP的特点:

        TCP既要保证可靠性, 同时又要尽可能的提高性能。

  • TCP实现可靠性传输:通过检验和、序列号、确认应答、超时重发、连接管理、流量控制、拥塞控制等机制。
  • TCP提高性能:通过滑动窗口、高速重传、延迟应答、捎带应答等机制。 

为此TCP实行了诸多机制来保证这两个特点,接下来我们就来具体分析这些机制:(一到五为保证可靠性,六到九为提高性能)

 

一、通过序列号与确认应答(ACK)提供可靠性:

        确认应答(ACK):当发送端的数据到达接收主机时,接收端主机会返回一个已收到消息的通知,这个消息叫做确认应答。

                                       (例:“收到没?”“嗯!”)   肯定的确认应答:ACK      否定的确认应答:NACK

                                  

        TCP通过肯定的确认应答来实现可靠的数据传输,如果发送端在数据发出之后的一段时间内没收到对端的确认应答,发送端会认为数据丢失并进行重发:

                                      

    未收到确认应答不一定意味着数据丢失,还可能是数据对方已收到,只是返回的确认应答在途中丢失,此时发送端仍会重发:

                                       

        此外还会因为一些其他原因导致确认应答延迟到达,源主机仍会重发数据,但是目标主机就会反复收到相同的数据;此时引入序列号确认应答号识别是否已经接收数据以及判断是否需要接收数据,TCP由此实现可靠传输:

                       

二、 超时重发:

         指在重发数据之前,等待确认应答到来的那个特定时间间隔。 如果超过了这个时间仍未收到确认应答,发送端将进行数据重发。

  • 在BSD的Unix以及Windows系统中,重发超时都是0.5秒的整数倍最初的数据包由于不知道往返时间,所以其重发超时一般设置为6s.
  • 数据被重发之后若还是收不到确认应答,则再次进行发送,此时等待确认应答的时间将会以指数(2倍、4倍)形式延长。 
  • 达到一定重发次数后,若仍没有任何确认应答返回,就会判为网络或对端主机发生异常,强制关闭连接,并通知应用通信异常强行终止。 

 

三、 连接管理:

         TCP提供面向有连接的数据传输,面向有连接是指在数据通信开始之前先做好通信两端之间的准备工作。

  • TCP建立连接:三次挥手    
  • TCP断开连接:四次挥手 

    

TCP以段为单位发送数据:

  • 建立TCP连接的同时,也可以确定发送数据包的单位,称其为“最大消息长度(MSS)”
  • 最理想的情况是:最大消息长度正好是IP中不会被分片处理的最大数据长度。
  • MSS:TCP在传送大量数据时,是以MSS的大小将数据进行分割发送;进行重发时也是以MSS为单位。
  • MSS是在三次握手时,在两端主机之间被计算得出:两端主机在发出建立连接的请求时,会在TCP首部中写入MSS选项,告诉对方自己的接口能够适应的MSS的大小,然后取二者之间的较小值使用
  • MSS与MTU的关系:MTU = MSS + IP报头 + TCP报头.

         

 

四、流量控制:

        为了解决接收双方速度不匹配而导致接收方缓冲区溢出,造成网络流量的浪费问题,TCP提供了一种可以让发送端根据接收端的实际接收能力控制发送的数据量的机制---流控制(流量控制)。

  • 接收端主机向发送端主机通知自己可以接收数据的大小,于是发送端会发送不超过这个限度的数据,该大小限度就是窗口大小。 
  • TCP首部中,专门有一个字段用来通知窗口大小。接收主机将自己可以接受的缓冲区大小放入这个字段中通知给发送端。    
  • 完整的TCP流控制:发送端主机会根据接收端主机的指示,对发送数据的量进行控制。

        

        如上图所示,当接收端收到从3001号开始的数据段后其缓冲区即满,不得不暂停接收数据。之后,在收到发送窗口更新通知后通信才能继续进行。如果这个窗口的更新通知在传送途中丢失,可能会导致无法通信,为避免此类问题的发生,发送端主机会不时的发送一个叫做窗口探测的数据段,此数据段仅含一个字节,用来获取最新的窗口大小信息。     

 

五、拥塞控制:

        虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送⼤量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题。网络上有很多的计算机, 可能当前网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据, 很可能导致整个网络的瘫痪。

        TCP引入“慢启动”机制:先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据。

        

此处引入⼀个概念:拥塞窗口 

  • 发送开始的时候, 定义拥塞窗口大小为1; 每次收到⼀个ACK应答, 拥塞窗口增加1个段;  
  • 每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口

        像上面这样的拥塞窗口增长速度, 是指数级别的。"慢启动" 只是指初始时慢, 但是增长速度非常快. 为了不增长的那么快, 不能使拥塞窗口单纯的加倍. 此处引入⼀个叫做 慢启动的阈值 :当拥塞窗口超过这个阈值的时候,不再按照指数方式增长, 而是按照线性方式增长:

   

  • 少量的丢包,我们仅仅是触发超时重传;大量的丢包,我们就认为网络拥塞。
  • TCP开始通信后,网络吞吐量逐渐上升;随着网络发生拥堵,吞吐量会立刻下降。

拥塞控制,归根结底是TCP协议想尽快的把数据传输给对方,但是又要避免给网络造成太大压力的折中方式。

TCP拥塞控制详解: https://blog.youkuaiyun.com/qq_41431406/article/details/97926927                                        

六、窗口控制:

        TCP以1个段为单位,每发一个段就要进行一次确认应答处理,当包的往返时间变长时,网络的吞吐量会变差,通信性能降低。为了解决上述问题,确认应答不再以每个分段,而是以更大的单位进行确认。

        也就是说:发送端主机在发送了一个段以后不必要一直等待确认应答,而是直接发送。 

 

        窗口大小:指无需等待确认应答而可以继续发送数据的最大值,上图的窗口大小为4个段。

  • 窗口越大,网络的吞吐率越高。
  • 窗口大小由接收端主机决定。

        窗口控制这个机制实现了使用大量的缓冲区,通过对多个段同时进行确认应答的功能。

 

  滑动窗口:  

                  

        操作系统内核为了维护这个滑动窗口,需要开辟一个“发送缓存区”,以此来记录当前还有哪些数据没有应答;只有确认应答过的数据才能从缓冲区清除。

        滑动窗口控制:收到确认应答的情况下,将窗口滑动到确认应答中的序列号的位置,这样可以顺序地将多个段同时发送提高通信性能,这种机制称为滑动窗口控制。

 

七、高速重发控制:

        针对的是某一报文段丢失的情况。(比超时重发更加高效)

        

 

八、延迟应答:

        如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小,因为刚接收完数据,缓冲区所剩无几。假设接收端缓冲区为1M. ⼀次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K; 但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了; 在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大⼀些, 也能处理过来; 如果接收端稍微等一会再应答,比如等待200ms再应答,那么这个时候返回的窗口大小就是1M, 提高了网络利用率, 降低计算机处理负荷:

        

  • TCP文件传输时中,绝大多数是每两个数据段返回一次确认应答。  
  • 那么所有的包都可以延迟应答么? 肯定也不是:数量限制(每隔N个包就应答⼀次)、 时间限制(超过最大延迟时间就应答⼀次)

 

九、捎带应答:

        在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 "⼀发⼀收" 的. 意味着客户端给服务器说了 "How are you", 服务器也会给客户端回⼀个 "Fine, thank you"; 那么这个时候ACK就可以搭顺风车, 和服务器回应的 "Fine, thank you" ⼀起回给客户端。这种机制可以使收发的数据量减少如果没有启用延迟应答就无法实现捎带应答。

        

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值