计算机网络第五章知识点归纳

爱被打了一巴掌 2022-10-10 14:51 276阅读 0赞

# 运输层 #

## 5.1 运输协议概述 ##

### 进程之间的通信 ###

从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。 当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时，只有位于网络边缘部分的主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用到下三层的功能。

*  运输层的作用
    
    为应用进程之间提供端到端的逻辑通信（逻辑通信的意思时：看似这是一个水平方向上的物理连接，传送数据的过程，实际上是经过多个层次结构的传送（重复经过物理层、数据链路层、网络层））
 *  端系统之间通信
    
    严格地讲，两台主机进行通信就是两台主机中的应用进程互相通信,即为端到端的通信。（即从运输层的角度来看，通信的真正端点并不是主机而是主机中的进程）
 *  重要功能
    
     *  复用与分用
        
        基于“端口”的复用与分用 复用：应用层所有的应用进程都可以通过传输层再传送到IP层（网络层） 分用：运输层从IP层收到发送给各应用进程的数据后，必须分别交付指明的各应用进程

### 运输层的主要协议 ###

*  ⭐用户数据报协议UDP
    
    当运输层采用无连接的 UDP 协议时，这种逻辑通信信道是一条不可靠信道。 在传送数据之前不需要先建立连接。对方主机的运输层在受到UDP报文后不需要给出任何确认
 *  ⭐传输控制协议TCP
    
    当运输层采用面向连接的 TCP 协议时，尽管下面的网络是不可靠的（只提供尽最大努力服务），但这种逻辑通信信道就相当于一条全双工的可靠信道 TCP提供面向连接的服务。传送数据前必须先建立连接，结束后再把连接释放掉。并且不通过广播或多播服务。（开销较大）
 *  流控制传输协议SCTP
    
    集合了UDP与TCP的优点
 *  数据报拥塞控制协议DCCP
    
    是TCP的改良

### 运输层端口 ###

*  进程标识符
    
    运行在计算机中的进程是用进程标识符来标志的。 但运行在应用层的各种应用进程却不应当让计算机操作系统指派它的进程标识符。这是因为在互联网上使用的计算机的操作系统种类很多，而不同的操作系统又使用不同格式的进程标识符。 为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须用统一的方法对 TCP/IP 体系的应用进程进行标志。
 *  需要解决的问题
    
    由于进程的创建和撤销都是动态的，发送方几乎无法识别其他机器上的进程。 有时我们会改换接收报文的进程，但并不需要通知所有发送方。 我们往往需要利用目的主机提供的功能来识别终点，而不需要知道实现这个功能的进程。
 *  协议端口号
    
    用于指明、识别互联网上通信的最后终点（目的地址） 虽然通信的终点是应用进程，但我们可以把端口想象是通信的终点，因为我们只要把要传送的报文交到目的主机的某一个合适的目的端口，剩下的工作（即最后交付目的进程）就由 TCP 来完成。 简称为端口（源端口和目的端口）（TCP/IP：16位（允许有65,535个不同的端口号）） 这种协议栈层间的抽象的协议端口是软件端口：应用层各种协议进程于运输实体继续层间交互的一种地址（区别于硬件端口：不同硬件设备继续交互的端口） 只具有本地意义：端口号只具有本地意义，即端口号只是为了标志本计算机应用层中的各进程。在互联网中，不同计算机的相同端口号是没有联系的。（互联网不同计算机中，相同的端口号是没有关联的，所以还要直到IP地址）
    
     *  服务器端的端口号
        
         *  熟知端口号（系统端口号）
            
            0~1023
         *  登记端口号
            
            1024~49151 为没有熟知端口号的应用程序使用的。使用这个范围的端口号必须在 IANA 登记，以防止重复。
     *  客户端的端口号
        
        当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用。
        
         *  短暂端口号
            
            49152~65535 留给客户进程选择暂时使用。
 *  三元组与五元组
    
    因特网中要全局惟一地标识一个进程必须采用一个三元组（半相关） ： （协议，主机地址，端口号）
    
    n网络通信是两个进程之间的通信，两个通信的进程构成一个全相关。这个全相关应该包含两个三元组，由于通信双方采用的协议必须是相同的，可以用一个五元组来描述两个进程的关联： 协议，本地主机地址，本地端口号，远地主机地址，远地端口号

## 5.2 用户数据报协议UDP ##

### UDP概述 ###

*  在IP数据报服务基础上添加的功能
    
     *  复用和分用
     *  差错检测
 *  主要特点
    
     *  无连接的
        
        发送数据之前不需要建立连接，，因此减少了开销和发送数据之前的时延。
     *  使用尽最大努力交付
        
        即不保证可靠交付，因此主机不需要维持复杂的连接状态表。
     *  面向报文的
        
        1.UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。UDP 一次交付一个完整的报文。 （应用层交给 UDP 多长的报文，UDP 就照样发送，即一次发送一个报文。） （接收方 UDP 对 IP 层交上来的 UDP 用户数据报，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文。）
        
         *  效率问题
            
            应用程序必须选择合适大小的报文 1.若报文太长，UDP 把它交给 IP 层后，IP 层在传送时可能要进行分片，这会降低 IP 层的效率。 2.若报文太短，UDP 把它交给 IP 层后，会使 IP 数据报的首部的相对长度太大，这也降低了 IP 层的效率。
     *  没有拥塞控制
        
        因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。很适合多媒体通信的要求。
     *  支持一对一，一对多，多对一和多对多的交互通信
     *  首部开销小
        
        8字节

### UDP首部格式 ###

用户数据报 UDP 有两个字段：数据字段和首部字段。

虽然在 UDP 之间的通信要用到端口号，但由于 UDP 的通信是无连接的，因此不需要使用套接字来建立连接。

*  首部
    
     *  首部格式
        
        首部字段有 8 个字节，由 4 个字段组成，每个字段都是 2 个字节。
        
         *  伪首部
            
            并不是UDP用户数据报真正的首部 不包含在UDP数据报中（不发送）（不向下发送也不向上递交） 仅用于计算检验和 伪首部的引入破坏了分层原则，是根据实际需要所做的折中。
         *  源端口
         *  目的端口
         *  长度
         *  检验和
            
            在计算检验和时，临时把 12 字节的“伪首部”和 UDP 用户数据报连接在一起 把首部和数据部分一起都检验 计算方式：按二进制反码运算求和，将得出的结果求反码
 *  数据部分

## 5.3 传输控制协议TCP概述 ##

### TCP最主要的特点 ###

TCP 是面向连接的运输层协议，在无连接的、不可靠的 IP 网络服务基础之上提供可靠交付的服务。为此，在 IP 的数据报服务基础之上，增加了保证可靠性的一系列措施

*  TCP是面向连接的运输层协议
 *  每一条TCP连接只能有两个端点
    
    每一条 TCP 连接只能是点对点的（一对一）。
 *  TCP提供可靠交付的服务
 *  TCP提供全双工通信
 *  面向字节流
    
    TCP 中的“流”(stream) 指的是流入或流出进程的字节序列。 “面向字节流”的含义是：虽然应用程序和 TCP 的交互是一次一个数据块，但 TCP 把应用程序交下来的数据看成仅仅是一连串无结构的字节流。
    
     *  TCP面向流
        
        TCP 不关心应用程序一次吧多长的报文发送到TCP缓存，根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应该包含多少字节。 但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。 TCP 连接是一条虚连接而不是一条真正的物理连接
        
         *  TCP报文段
            
            TCP 可把太长的数据块划分短一些再传送。 TCP 也可等待积累有足够多的字节后再构成报文段发送出去。

### TCP的连接 ###

TCP 把连接作为最基本的抽象。 每一条 TCP 连接有两个端点。 TCP 连接的端点不是主机，不是主机的IP 地址，不是应用进程，也不是运输层的协议端口。TCP 连接的端点叫做套接字或插口。 端口号拼接到 IP 地址即构成了套接字。

*  套接字
    
    每一条 TCP 连接唯一地被通信两端的两个端点（即两个套接字）所确定。
    
    套接字的格式：套接字=(IP地址：端口号)
 *  TCP连接、IP地址、套接字的关系
    
    TCP 连接就是由协议软件所提供的一种抽象。 TCP 连接的端点是个很抽象的套接字，即（IP 地址：端口号）。 同一个 IP 地址可以有多个不同的 TCP 连接。 同一个端口号也可以出现在多个不同的 TCP 连接中。

## 5.4 可靠传输的工作原理 ##

### 理想传输条件 ###

*  传输信道不产生差错
 *  不管发送方以多块的速度发送数据，接收方都能及时地处理收到的数据

### 差错控制机制 ###

提供可靠性服务的手段 处理： 1、丢失：重传 2、重复：丢弃+重传（确认） 3、乱序：收到确认才发送新的 4、出错：丢弃

*  停止等待协议
    
    “停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。 全双工通信的双方既是发送方也是接收方。 为了讨论问题的方便，我们仅考虑 A 发送数据，而 B 接收数据并发送确认。因此 A 叫做发送方，而 B 叫做接收方。
    
     *  操作
        
         *  分组差错
            
             *  丢弃分组
         *  分组重复
            
             *  丢弃分组，重传确认
         *  分组丢失
            
             *  重传分组
         *  确认重复
            
             *  丢弃确认
     *  信道利用率
        
        可以看出，当往返时间 RTT 远大于分组发送时间 TD 时，信道的利用率就会非常低。 若出现重传，则对传送有用的数据信息来说，信道的利用率就还要降低。
        
         *  U=TD/(TD+RTT+TA)
     *  要点
        
         *  停止等待
         *  编号
         *  自动重传请求
         *  信道利用率低
 *  连续ARQ协议
    
    对停止等待协议的改进 发送方一次可以发出多个分组。 使用滑动窗口协议控制发送方和接收方所能发送和接收的分组的数量和编号。 每收到一个确认，发送方就把发送窗口向前滑动。 接收方一般采用累积确认的方式。 采用回退N的方法进行重传。
    
     *  精髓：滑动窗口机制
     *  方法：连续发送，单独确认
        
         *  改进：连续发送，累积确认
            
            优点：容易实现，即使确认丢失也不必重传。 缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。

## 5.5 TCP报文段的首部格式 ##

### 首部格式 ###

*  源端口和目的端口：各2字节
 *  序号(seq)：4字节
 *  确认号(ack)：4字节
 *  数据偏移：4位
    
     *  首部长度->要乘以4才是真正的首部长度
 *  保留：6位
 *  窗口：2字节
    
     *  设置发送窗口
 *  紧急URG
    
     *  紧急指针有效
 *  确认ACK
    
     *  0的时候确认号无效
 *  推送PSH
    
     *  直接交付数据
 *  复位RST
    
     *  重新建立连接
 *  同步SYN
    
     *  连接请求或连接接受报文
 *  终止FIN
    
     *  释放一个连接
 *  检验和：2字节
    
     *  计算时要加上12字节的伪首部
 *  紧急指针：2字节
    
     *  紧急数据有多少字节
 *  选项：最长40字节（可无）

### 最大报文段长度MSS ###

最好不分片 但也不能太短

*  TCP报文段首部最小长度为20字节

## 5.6 TCP可靠传输的实现 ##

### 序号机制 ###

### 滑动窗口机制 ###

根据 B 给出的窗口值，A 构造出自己的发送窗口。 发送窗口表示：在没有收到 B 的确认的情况下，A 可以连续把窗口内的数据都发送出去。 发送窗口里面的序号表示允许发送的序号。 显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率。 发送窗口不总等于接收窗口（也不能够大于接收窗口）

*  发送缓存
    
    发送缓存用来暂时存放： 1.发送应用程序传送给发送方 TCP 准备发送的数据； 2.TCP 已发送出但尚未收到确认的数据。
    
     *  发送窗口
 *  接受缓存
    
    接收缓存用来暂时存放： 1.按序到达的、但尚未被接收应用程序读取的数据； 2.不按序到达的数据。
    
     *  接收窗口

### 重传定时器 ###

*  超时重传时间的选择
    
     *  报文段的往返时间RTT
     *  加权平均往返时间RTTS
        
        新的RTTS = (1 - a) *(旧的RTTS) + a* (新的RTT样本)  
        a即为权重，a越大RTT的值更新越快 推荐值为：1/8
     *  超时重传时间RTO
        
        RTO = RTTS + 4 \* RTTD
     *  RTTD
        
        RTT的偏差的加权平均值 第一次测量为RTT样本值的一半 新的 RTTD = (1 - b ) \* (旧的RTTD) + b \* |RTTS - 新的 RTT 样本| b的推荐值为1/4
     *  RTTM？
 *  Karn算法
    
    在计算平均往返时间 RTT 时，只要报文段重传了，就不采用其往返时间样本。 这样得出的加权平均平均往返时间 RTTS 和超时重传时间 RTO 就较准确。
    
     *  修正
        
        报文段每重传一次，就把 RTO 增大一些： 新的 RTO = g \* (旧的 RTO) 一般g=2

### 确认及重传机制 ###

*  选择确认SACK
    
    若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，通过选择确认SACK传送缺少的数据而不重传已经正确到达接收方的数据。

## 5.7 TCP的流量控制 ##

### 流量控制 ###

流量控制就是让发送方的发送速率不要太快，让接收方来得及接收

*  对点对点通信量的控制
 *  利用滑动窗口实现流量控制
    
    TCP窗口单位为字节 但是传送的数据单元为报文段
 *  利用可变窗口进行流量控制
 *  防止死锁
    
     *  持续计时器
        
         *  到时间就发送零窗口探测报文段

### TCP的传输效率 ###

*  发送时机
    
     *  第一种机制是 TCP 维持一个变量，它等于最大报文段长度 MSS。只要缓存中存放的数据达到 MSS 字节时，就组装成一个 TCP 报文段发送出去。
     *  第二种机制是由发送方的应用进程指明要求发送报文段，即 TCP 支持的推送 (push) 操作。
     *  第三种机制是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过 MSS）发送出去。
 *  糊涂窗口综合征
    
    每次仅发送一个字节或很少几个字节的数据时，有效数据传输效率变得很低的现象。
    
     *  发送方
        
         *  解决方法
            
            使用Nagle算法——不要发送太小的报文段（累积起来发送）
     *  接收方
        
         *  解决方法
            
            让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段MSS，或者等到接收缓存已有一半空闲的空间。只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小。

## 5.8 TCP的拥塞控制 ##

### 拥塞控制的一般原理 ###

*  拥塞
    
    网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。
    
     *  结果：系统崩溃
     *  原因
        
        1.点缓存的容量太小； 2.链路的容量不足； 3.处理机处理的速率太慢； 4.拥塞本身会进一步加剧拥塞；
 *  拥塞控制
    
     *  对全局的控制
     *  防止过多数据注入，使网络中的路由、链路不过载
     *  分组丢失是征兆不是原因
 *  方法
    
     *  开环控制
        
         *  避免发生拥塞
     *  闭环控制
        
         *  发生拥塞时采取措施控制，消除拥塞
 *  解决拥塞的思路
    
     *  增加可用资源
     *  减少资源需求

### TCP的拥塞控制方法 ###

*  基于窗口的方法
    
     *  拥塞窗口
        
         *  拥塞窗口值=Min（接收方窗口值，拥塞窗口值）
 *  算法
    
     *  慢开始
        
        在每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个 SMSS（门限值） 的数值
        
         *  指数增大
            
            每经过一个RTT就翻倍（乘法增大）
     *  拥塞避免
        
         *  缓慢增大
            
            每个RTT增加1（加法增大）
     *  快重传
     *  快恢复
 *  出现的情况
    
     *  重传计时器超时
        
        1.ssthresh = max (cwnd/2，2)（门限值减为当前拥塞窗口的一半） 2.cwnd = 1 3.执行慢开始算法
     *  三个连续确认
        
        立即进行重传（即“快重传”），这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。 算法： 1.慢开始门限 ssthresh = 当前拥塞窗口 cwnd / 2 ； 2.新拥塞窗口 cwnd = 慢开始门限 ssthresh ； 3.开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。

### 主动队列管理AQM ###

*  对 TCP 拥塞控制影响最大的就是路由器的分组丢弃策略。

## 5.9 TCP的运输连接管理 ##

### TCP的建立 ###

*  方法
    
     *  客户服务器方式
 *  建立过程
    
     *  三报文握手
        
        1、A 的 TCP 向 B 发出连接请求报文段，其首部中的同步位 SYN = 1，并选择序号 seq = x。 2、B 的 TCP 收到连接请求报文段后，如同意，则发回确认。 B 在确认报文段中应使 SYN = 1，使 ACK = 1，其确认号 ack = x + 1，自己选择的序号 seq = y。 3、A 收到此报文段后向 B 给出确认，其 ACK = 1，确认号 ack = y + 1。 A 的 TCP 通知上层应用进程，连接已经建立。
        
        若为四握手则将第二步拆为：发出确认报文（ACK=1,ack=x+1 ）和同步报文(SYN=1,seq=y)

### TCP的释放 ###

*  过程
    
     *  四报文握手
        
        1、现在 A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。 A把连接释放报文段首部的FIN = 1，其序号seq = u，等待 B 的确认。 2、B 发出确认，ACK=1,确认号 ack = u+1，而这个报文段自己的序号 seq = v。 这中间：服务器还能向客户发送数据 3、B向A发送：FIN=1,ACK=1,seq=w,ack=u+1 4、A发送确认：ACK=1,seq=u+1,ack=w+1
 *  时间等待计时器
    
    第一，为了保证 A 发送的最后一个 ACK 报文段能够到达 B。 第二，防止 “已失效的连接请求报文段”出现在本连接中
    
     *  等待时长为2MSL
        
        MSL为最长报文段寿命
 *  保活计时器
    
    通常设为2小时 2小时后，发送探测报文段，75秒一个 十个报文段后关闭连接
    
     *  防止TCP连接长时间空闲

### TCP的有限状态机 ###