5 运输层

5 运输层

5.1 运输层概述

  • 计算机网络体系结构中的物理层、数据链路层以及网络层它们共同解决了将主机通过异构网络互联起来所面临的问题,实现了主机到主机的通信。
  • 但实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程。
  • 如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务,运输层协议又称为端到端协议。
  • 运输层向高层用户屏蔽 了下面网络核心的细节(如网络拓扑、所采用的路由选择协议等),它使应用进程看见的就好像是在两个运输层实体之间有一条端到端的逻辑通信信道。
  • 根据应用需求的不同, 因特网的运输层为应用层提供了两种不同的运输协议,即面向连接的TCP和无连接的UDP,这两种协议就是本章要讨论的主要内容。

5.2 运输层端口号、复用和奋勇的概念

  • 运行在计算机上的进程使用进程标识符PID来标志。
  • 因特网上的计算机并不是使用统一的操作系统,不同的操作系统 (windows, Linux, Mac Os)又使用不同格式的进程标识符。
  • 为了使运行不同操作系统的计算机的应用进程之间能够进行网络通信,就必须使用统一的方法对TCP/P体系的应用进程进行标识。
  • TCP/P体系的运输层使用端口号来区分应用层的不同应用进程。
    端口号使用16比特表示,取值范围0~55535;
    • 熟知端口号:0~1023,IANA把这些端口号指派给了TCP/IP体系中最重要的一些应用协议,例如:FTP 使用21/20, HTTP使用80,DNS使用53。
    • 登记端口号:1024~49151,为没有熟知端口号的应用程序使用。使用这类端口号必须在/ANA按照规定的手续登记,以防止重复。例如:Microsoft RDP 微软远程桌面使用的端口是3389。
    • 短暂端口号:49152~65535,留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时,就知道了客户进程所使用的动态端口号。通信结束后,这个端口号可供其他客户进程以后使用。
    • 端口号只具有本地意义,即端口号只是为了标识本计算机应用层中的各进程,在因特网中,不同计算机中的相同端口号是没有联系的。

5.3 UDP和TCP的对比

  1. TCP是面向连接的 ;UDP是无连接的
  2. TCP仅支持单播 ;UDP支持单播、多播和广播
  3. TCP是面向字节流的;UDP是面向应用报文的
  4. TCP可靠传输,使用流量控制和拥塞控制;UDP不可靠传输,不使用流量控制和拥塞控制
  5. TCP报文首部最小20字节最大60字节;UDP报文首部8字节

5.4 TCP的流量控制

  • 流量控制定义:所谓流量控制(flow control)就是让发送方的发送速率不要太快,要让接收方来得及接收
  • 流动窗口:利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
    1. TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小。
    2. TCP发送方收到接收方的零窗口通知后,应启动持续计时器。持续计时器超时后,向接收方发送零窗口探测报文。

5.5 TCP的拥塞控制

  • 拥塞的定义:在某段时间,若对网络中某一资源的需求超过 了该资源所能提供的可用部分,网络性能就要变坏。这种情况就叫做拥塞(congestion)。

  • 四种拥塞控制算法:1. 慢开始 2. 拥塞避免 3. 快重传 4. 快恢复

    • 一些变量:cwnd(拥塞窗口):其值取决与网络的拥塞程度,并且动态变化
      • 拥塞窗口cwnd维护原则:只要网络没有出现拥塞,拥塞窗口就再增大一些;但只要网络出现拥塞,拥塞窗口就减少一些
      • 判断出现网络拥塞的依据:发生超时重传
    • 发送方讲拥塞窗口作为发送窗口swnd,即swnd=cwnd
    • 慢开始门限ssthresh状态变量:
      • 当cwnd < ssthresh时,使用慢开始算法
      • 当cwnd > ssthresh时,停止使用慢开始算法而改用拥塞避免算法
      • 当cwnd = ssthresh时,可用慢开始算法,也可拥塞避免算法

5.6 TCP的超时重传策略

  • 超时重传时间RTO:理论上应该比往返时间RTT略大一点
  • RFC6298建议使用RTO表达式:

\[RTO=RTT_S+4\times RTT_D \tag{1} \]

加权平局你往返时间\(RTT_S\) RTT偏差的加权平均\(RTT_D\)
\(RTT_{S1}=RTT_1\) \(RTT_D1=\frac{RTT_1}{2}\)
新的\(RTT_S=(1-\alpha)\times\)旧的\(RTT_S+\alpha \times\)新的\(RTT\)样本 新的\(RTT_D=(1-\beta)\times\)旧的\(RTT_D+\beta \times\) \(\vert RTT_S-\)新的\(RTT样本\vert\)
\(0\leq\alpha<1\) \(0\leq\beta<1\)
\(\alpha\)推荐值1/8 \(\beta\)推荐值1/4

5.7 TCP可靠传输的实现

  • TCP基于以字节为单位的滑动窗口来实现可靠传输。
    • 发送方在未收到接收方的确认时,可将发送窗口内还未发送的数据全部发送出去;
    • 接收方只接收序号落入发送窗口内的数据;
  • 虽然发送方的发送窗口是根据接收方的接收窗口设置的,但在同一时刻,发送方的发送窗口并不总是和接收方的接收窗口一样大。
    • 网络传送窗口值需要经历一定的时间滞后,并且这个时间还是不确定的。
    • 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。
  • 对于不按序到达的数据应如何处理,TCP并无明确规定。
    • 如果接收方把不按序到达的数据一律丢弃, 那么接收窗口的管理将会比较简单,但这样做对网络资源的利用不利,因为发送方会重复传送较多的数据。
    • TCP通常对不按序到达的数据是先临时存放在接收窗口中,等到字节流中所缺少的字节收到后,再按序交付上层的应用进程。
  • TCP要求接收方必须有累积确认和捎带确认机制,这样可以减小传输开销。接收方可以在合适的时候发送确认,也可以在自己有数据要发送时把确认信息顺便捎带上。
    • 接收方不应过分推迟发送确认,否则会导致发送方不必要的超时重传,这反而浪费了网络的资源。
      TCP标准规定,确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段,则必须每隔一个报文段就发送一个确认[RFC 1122]。
    • 捎带确认实际上并不经常发生,因为大多数应用程序很少同时在两个方向.上发送数据。
  • TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此,每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时,一定要清楚是哪一方的哪个窗口。

5.8 TCP的连接管理

5.8.1 TCP的运输连接管理——TCP的连接建立

  • TCP连接建立需要解决的三个问题

    1. 使TCP双方能确知对方的存在
    2. 使TCP双方嫩巩固协商一些数值(如窗口大小值,时间戳选项以及服务质量等)
    3. 使TCP双方能够对运输实体资源(如缓存大小、连接表中的项目等)进行分配
  • 三次握手建立TCP的连接

    • 一次握手:TCP客户端(发送端)主动打开TCP服务,发送TCP连接请求STN=1,seq=x
    • 二次握手:TCP服务器端(接收端)接收到可无端请求,回复报文SYN=1.ACK=1,seq=y,ack=x+1
    • 三次握手:客户端接收到服务器端的回复报文,此时客户端连接已建立,但还需发送回复报文ACK=1,seq=x+1,ack=y+1,服务器端接收到回复报文,此时服务器端连接建立。
  • 是否能改为二次握手?(第三次握手是否多余?)
    不能改为二次握手(第三次握手不多余)。因为如果第一次握手的请求TCP连接的报文由于网络原因很长时间才送到接收端的情况下,发送端会再次发送TCP连接的请求报文,此时当两端的数据传输结束,连接断开后,此时之前的延误报文送达,则服务器端会认为客户端又发起了TCP连接请求,此时服务器端会认为连接建立,而客户端实则没建立连接,造成资源浪费。

5.8.2 TCP的运输连接管理——TCP的连接释放

  • TCP断开连接 四次挥手

    v 等于TCP之前收到过的数据的最后一个字节的序号加1
    u 等于TCP之前传送过的数据的最后一个字节的序号加1

    • 一次挥手:TCP客户端主动发起关闭连接,发送TCP连接释放,发送报文FIN=1 ACK=1 seq=u ack=v,此时TCP客户端进入FIN-WAIT-1终止等待1状态
    • 二次挥手:TCP服务器端接受到报文后,发送TCP普通确认报文ACK=1 seq=v ack=u+1,此时进入CLOSE-WAIT关闭等待状态此时客户端不能向服务器端传送数据,但反之可以,客户端收到确认报文后。,此时看客户端进入FIN-WAIT-2终止等待2状态
    • 三次挥手:TCP服务器进程发送TCP连接释放报文段,并进入最后确认状态,发送报文FIN=1 ACK=1 seq=w ack=u+1,w是因为可能还有发送一些数据。
    • 四次挥手:TCP客户端收到连接释放报文后,进入TIME-WAIT时间等待状态,并且发送确认报文ACK=1 seq=u+1 ack=w+1,此时服务器端接收到确认报文后进入关闭状态。客户端在结果2MSL(2倍最大报文段寿命)
  • 2MSL的作用:\
    • 避免因为客户端确认报文的丢失而造成服务器端TCP进程不能关闭的资源浪费问题
    • 经过2MSL后,可以使得在本次TCP服务传输过程中的产生的所有报文段都从网络中消失,避免了对下次TCP连接的干扰可能性
  • 保活计时器
    • 作用:避免因为TCP客户端的故障导致TCP服务器端长时间无法关闭服务的资源浪费问题。
    • 具体做法:
      • TCP服务器进程每收到一次TCP客户进程的数据,就重新设置并启动保活计时器(2小时定时)。
      • 若保活计时器定时周期内未收到TCP客户进程发来的数据,则当保活计时器到时后,TCP服务器进程就向TCP客户进程发送一个探测报文段,以后则每隔75秒钟发送一次。若一连发送10个探测报文段后仍无TCP客户进程的响应,TCP服务器进程就认为TCP客户进程所在主机出了故障,接着就关闭这个连接。

5.9 TCP报文段的首部格式

  • 为了实现可靠传输,TCP采用了面向字节流的方式
  • TCP发送数据时,是从发送缓存中取出一部分或者前部字节并给其添加一个首部使之成为TCP报文段后进行发送
    • 一个TCP报文段由首部数据载荷两部分构成
    • TCP的全部功能都体现在它首部中各字段的作用

posted @ 2023-07-24 16:10  mobbu  阅读(23)  评论(0编辑  收藏  举报