计算机网络 | 5.传输层

1.传输层与应用层及网络安全

（1）传输层的主要功能

• 传输层为应用进程之间提供端到端的逻辑通信（但网络层是为主机之间提供逻辑通信）。
• 传输层还要对收到的报文进行差错检测。
• 传输层提供面向连接和无连接的服务。

（2）传输层两个协议及其应用场景

<1>传输层协议TCP、UDP简单介绍

后面会详细介绍

• TCP
  • 可靠传输，差错时重传
  • 分段传输，有编号
  • 流量控制
  • 建立会话（即面向连接）
• UDP
  • 不可靠传输
  • 一个数据包就能完成数据通信
  • 不建立会话（即无连接）
  • 多播

<2>通过QQ聊天、传文件简单理解TCP和UDP

• QQ聊天使用的是UDP协议
  • QQ聊天时，仅仅发送一个很小的数据包（类似：“在吗？”），这一个数据包就完成了通信，并且也不需要一直连接着等待对方的回应。因此是UDP协议。
  • QQ聊天因为使用了UDP协议，因此单次发送的最大字数有限制。
  • 实现较可靠的方式：QQ聊天使用其他方式实现了可靠，当数据包发送不过去时，QQ显示“红色感叹号”
• QQ传文件使用的是TCP协议
  • QQ传文件时，文件比较大，需要将文件按编号分组传输

（3）传输层和应用层及网络安全

<1>端口和服务

简单理解：计算机的每一个端口都可以提供一个服务

• 举例
  • 访问网站时，假如访问网址 47.95.114.177：80
  • 通过IP地址 47.95.114.177 找到要访问的主机
  • 通过 80 端口找到主机上的Web服务

a.端口

• 端口是什么
  • 客户端可以通过ip地址找到对应的目的主机（或服务器端）
  • 端口号类似门牌号，通过端口号找到目的主机上相应的服务（即目的主机上的服务）。
  • TCP和UDP端口地址都是16bit，因此计算机的端口号从0到65535一共65536个端口（2¹⁶=65536）。
  • 服务器端每个应用程序对应一个端口号。通过端口号，客户端才能访问到要访问的服务（如Web服务、邮件服务等）。
• 端口分类
  • 公认端口
    • 这类端口也常称之为"常用端口"。这类端口的端口号从0到1023，它们紧密绑定于一些特定的服务。通常这些端口的通信，明确表明了某种服务的协议，这些端口不可再重新定义它的作用对象。例如：80号端口，实际上总是HTTP通信所使用的；而23号端口，则是Telnet（远程登录协议）服务所专用的。这些端口通常不会被像木马这样的黑客程序所利用。
  • 注册端口
    • 端口号从1024到49151。它们松散地绑定于一些服务，也是说，有许多服务绑定于这些端口，这些端口同样用于许多其他目的。这些端口多数没有明确的定义服务对象，不同程序可根据实际需要自己定义，如一些“远程控制软件”和“木马程序”中都会有这些端口的定义。
  • 动态或私有端口
    • 端口号从49152到65535。理论上，不应把常用的服务分配在这些端口上。实际上，有些较为特殊的程序，特别是一些木马程序就非常喜欢用这些端口，因为这些端口常常不被引起注意，容易隐蔽。

b.服务

• 服务是什么？
  • 服务是一种应用程序类型，在后台运行。
  • 服务应用程序通常可以在本地和通过网络为用户提供一些功能。（如Web服务、邮件服务等）
  • 服务要开相应的端口，每一个端口都可以对应一项服务。
  • 举例：
    • 21端口，提供FTP服务
    • 80端口，提供HTTP服务
    • 3306端口，提供MySQL服务
  • 服务运行后，在TCP或UDP的某个端口侦听客户端请求
    • 也许服务器端没有人访问，但是服务器端一直侦听端口
  • 查看自己计算机侦听的端口
    • netstat -an
  • 测试远程计算机打开的端口
    • telnet [IP] [端口号]

c.端口与网络安全

• 1）关掉没有用的服务
  • 将没有用的服务关掉（端口也关掉了）
• 2）更改服务对应的默认端口号
  • 端口号可以自己更改
  • 人们都知道3306时MySQL的默认端口，3389是全程屏幕的端口。我们更改服务对应的默认端口，可以相对的提高网络安全。
• 3）关于Windows防火墙
  • 1^o Windows防火墙的作用
    • Windows防火墙将所有端口都关掉了。此时，外网ping不通这台主机。但是这台主机仍然能够上网，因为端口是动态的，本主机通过一个端口访问外网，外网返回的数据从这个端口返回到该主机。（本主机不主动和外界通信，外界是无法通过端口访问到这台主机）
      
  • 2^o TCPIP筛选
    • 以提供Web服务（80端口）为例。配置Winwods防火墙，接受目的端口为80的数据，只允许向外发送源端口为80的数据包。实现网络安全。
      
  • 3^o Windows防火墙不放灰鸽子木马程序
    • 我们知道，外部的主机无法主动访问防火墙内的主机，但防火墙内的主机可以通过主动访问防火墙外的其他主机实现通信。
    • 当安装防火墙的主机访问网络时，点击了木马链接，导致主机上安装了灰鸽子木马程序。灰鸽子木马程序主动连接外部放出灰鸽子木马程序的的主机。
    • 灰鸽子木马程序在放出去之前配置的时候，会写上黑客的IP地址。当某台主机不小心安装了灰鸽子木马程序之后，灰鸽子木马程序作为内应，主动连接防火墙外的黑客主机。

<2>传输层和应用层的对应

• 应用层协议 = 传输层协议 + 端口 （默认端口）
  • HTTP = TCP + 80
  • HTTPS = TCP + 443
  • FTP = TCP + 21
  • SMTP = TCP + 25
  • POP3 = TCP + 110
  • RDP = TCP + 3389
  • Windows共享文件 = TCP + 445
  • MySQL = TCP + 3306
  • DNS = UDP + 53 or TCP + 53

2.传输层协议UDP和TCP

（1）传输层的主要功能

• 传输层为应用进程之间提供端到端的逻辑通信（但网络层是为主机之间提供逻辑通信）。
• 传输层还要对收到的报文进行差错检测。
• 传输层提供面向连接和无连接的服务。
• TCP与UDP
  • 传输单元
    • 两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元。
    • TCP传送的协议数据单元是TCP报文段。
    • UDP传送的协议数据单元是UDP报文或用户数据报。
  • TCP与UDP
    • UDP在传送数据之前不需要先建立连接，对方的传输层收到UDP报文后，不需要给出任何确认。虽然UDP不提供可靠交付，但在某些情况下UDP是一种最有效的工作方式。
    • TCP则提供面向连接的服务。TCP不提供广播或多播服务。由于TCP要提供可靠的、面向连接的服务，因此不可避免的增加了许多的开销。这不仅使协议数据单元的首部增大很多，还要占用许多的处理机资源。

（2）UDP协议

<1>UDP协议简介

• UDP中文名是用户数据报协议，是一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务，UDP在IP报文的协议号是17。
• UDP报文没有可靠性保证、顺序保证和流量控制字段等，可靠性较差。但是正因为UDP协议的控制选项较少，在数据传输过程中延迟小、数据传输效率高，适合对可靠性要求不高的应用程序，或者可以保障可靠性的应用程序，如DNS、TFTP、SNMP等。

<2>UDP报文格式

a.UDP用户数据报协议

b.UDP的首部格式

• 用户数据报UDP有两个字段：数据字段和首部字段。首部字段有8个字节，由4个字段组成，每个字段都是两个字节。
• UDP首部中校验和的计算方法有些特殊。在计算校验和时,要在UDP用户数据报之前增加12个字节的伪首部。伪首部既不向下传送也不向上递交,而仅仅是为了计算校验和。与IP数据报的校验和只校验IP数据报的首部不同,UDP的校验和是把首部和数据部分一起都校验。
• 在计算检验和时,临时把“伪首部”和 UDP 用户数据报连接在一起。伪首部仅仅是为了计算检验和。
  • 计算校验和举例：
    

c.UDP的主要特点

• UDP是无连接的，即发送数据之前不需要建立连接。
• UDP使用尽最大努力交付，即不保证可靠交付，同时也不使用拥塞控制。
• UDP是面向报文的。UDP没有拥塞控制，很适合多媒体通信的要求。
• UDP支持一对一、一对多、多对一和多对多的交互通信。
• UDP的首部开销小，只有8字节。

（3）TCP协议

<1>TCP概述

• TCP是面向连接的传输层协议
• 每一条TCP连接只能有两个端点，每一条TCP连接只能是点到点的（一对一）
  • TCP把连接作为最基本的抽象。
  • 每一条TCP连接都有两个端点。
  • TCP连接的是端点，不是主机的IP地址，不是应用进程，也不是传输层的协议端口。TCP连接的端点叫作套接字(socket)
    • 套接字socket = (IP:端口号)
    • TCP连接被通信两端的两个端点确定，即 TCP连接::={socket1,socket2}=
• TCP要有流量控制
  • 假如发送服务器性能优于接受服务器的性能（发的快收的慢）
• TCP要有拥塞控制
  • 链路上许多计算机在通信，网络拥堵，主机A、B要控制自己发送接受的速度
• TCP提供可靠交付的服务
• TCP提供全双工通信
• 面向字节流
  
  • 之所以说TCP是面向字节流，是以下原因：
    • 发送端：TCP缓存从文件中拿数据时，可能同时取n个字节，n的大小不是固定的，每次取数据时，可能n的大小都不一样。
    • 发送端：TCP缓存中拿到的数据封装时，可能每次封装m个字节，m的大小不是固定的，每次封装数据时，可能m的大小都不一样。然后通过连接发送给接收端。
    • 接收端：TCP缓存接收到数据后，去掉封装部分，拿出数据并按顺序拼接，每次向文件中保存时，同时保存q个字节，每次保存时，q的大小可能都不一样。
    • 都是以字节为单位，因此TCP是面向字节流的。

<2>TCP首部详解

• 源端口
  • 占16位，表示源主机的端口号（因此，共65536个端口）
• 目的端口
  • 占16位，表示目的主机的端口号（因此，共65536个端口）
• 序号
  • 占32位。
  • 前面讲TCP面向字节流。
  • 序号表示在传输时，数据包的第一个字节的数据在源文件中的编号。传输数据（字节流的首部）与源文件的关系。
    • 如“面向字节流的图片”中，第一个数据包的序号是1，第二个数据包的序号是4
• 确认号
  • 占32位。
  • 接收端收到数据后，返回一个确认号
    • 假如接收端接收到了前24个字节，则返回的确认号是25，表示前24字节都受到，请发送第25个字节开始的数据包。
    • 发送端收到确认号25之后，将前24个字节在 TCP缓存 中删除掉。
• 数据偏移
  • 占4位。用来记录从第多少个字节之前是TCP首部部分，在多少字节后是数据部分。
  • 4位二进制最多表示十进制的15；而一位二进制表示4个字节，因此首部最大为60个字节；因此选项部分（长度可变）最大为40字节（因为TCP首部固定部分为20字节）。（TCP首部大小）
• 保留
  • 占6位。没有用。
• 6个标志位
  • URG（发送端不排队）
    • 占1位。发送端用来告诉计算机，这个数据段要传的数据优先级高低，需不需要排队。
    • URG=1时，数据包在TCP缓存中不需要排队，直接传输。
  • PSH（接收端保存不排队，对比URG）
    • 占1位。接收端：代表这个数据比较着急，优先从TCP缓存中存到主机上（不排队）。
  • ACK
    • 占1位。当ACK=1时，确认号才有效。（建立连接时，仔细理解ACK）
  • SYN
    • 占1位。同步序列编号，是TCP/IP建立连接时使用的握手信号。（建立连接时，仔细理解SYN）
  • RST
    • 占1位。当RST=1时，TCP释放连接，要想通信，需要重新建立TCP连接。
    • 举例：打开浏览器时，页面没有加载完，此时关闭浏览器。
  • FIN
    • 占1位。在数据通信结束时，释放连接时FIN=1。
• 窗口
  • 占16位。表示接收缓冲区的空闲空间，用来告诉TCP连接的对方自己能够接收的最大数据长度。（流量控制）
  • 假设主机A、B使用TCP通信，主机B的TCP接收缓存大小为65536字节，主机B的TCP接收缓存中有64536字节未来得及向硬盘中存储。此时，发送的数据包中，TCP首部的windows设置为1000，代表接收方最大还可以接收1000字节的数据。（因此，窗口的值不是固定的）
• 校验和
  • 占16位。校验了首部和数据两部分，计算方法类比UDP。
• 紧急指针
  • 只有在URG=1时，紧急指针才发挥作用。它指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据） 。因此，在紧急指针指出了紧急数据的末尾在报文段中的位置。当所有紧急数据都处理完时，TCP就告诉应用程序恢复到正常操作。值得注意的是，即使窗口为0时也可以发送紧急数据。
• 选项（长度可变）
  • 最大报文段长度MSS
  • 时间戳等等

<3>TCP的传输连接管理

• 传输连接的三个阶段：建立连接、数据传送、连接释放。
• TCP连接的建立都是采用客户服务器方式
  • 主动发起连接请求的应用进程叫做客户(client)
  • 被动等待连接建立的应用进程叫做服务器(server)

a.TCP的连接建立：三次握手

• 第一次握手：
  • 标志位SYN=1,ACK=0；序号seq=x；由客户发送给服务器，然后客户端进入SYN_SENT状态。
  • 其中，SYN置1（TCP连接建立时的同步序列），ACK置0（刚开始发，确认号没有用），序号seq=x（随机生成）。
• 第二次握手：
  • 标志位SYN=1,ACK=1;序号seq=y,ack=x+1;由服务器发送给客户，然后服务器进入SYN_RCVD状态。
  • 其中，SYN置1（TCP连接建立时的同步序列），ACK置1（需要确认号ack），序号seq=y（随机生成），确认号ack=x+1（因为服务器接收到的TCP首部的序号是x，因此确认号为x+1，表示前x个字节都已收到，告诉客户开始发送第x+1字节。）
• 第三次握手：
  • 标志位ACK=1；序号seq=x+1,确认号ack=y+1，然后客户端进入ESTABLISHED状态，当服务器接收到之后，也进入到ESTABLISHED状态。
  • 其中，SYN不再需要，ACK置1（需要确认号ack），序号seq=x+1（即第二次握手的确认号），确认号ack=y+1（类比第二次握手）
• 问题：TCP两次握手就可以实现TCP连接的重要功能，那为什么使用三次握手？
  • 答：为了防止己失效的连接请求报文段突然 又传送到了 B，因而产生错误。
    • A 发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达 B。
    • 在滞留期间，A重新发送了连接请求，并收到了确认，建立了连接。数据传输完毕后，就释放了连接。（此时，A的第一个请求仍未到达B）
    • 过了一会儿，B收到A的第一个连接请求。并误认为A要重新建立请求，向A第二次握手。
    • 如果没有第三次握手，至此，连接已经建立，B等待A的数据请求。浪费了B的资源。
    • 有第三次握手，A不会向B的确认发出确认（第三次握手）。B由于收不到确认（第三次握手）**，就知道A并没有要求建立连接。
      **

b.TCP连接的释放：四次挥手

• 前两次挥手
  • 数据传输完毕后，通信双方都可以释放连接。现在A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。
  • A把链接释放报文段首部的FIN=1，其序号seq=u，等待B的确认。
  • B发出确认，确认号ack=u+1，而这个报文段自己的序号seq=v。
  • TCP服务器进程通知高层应用程序。
  • 从A到B这个方向的连接就释放了，TCP连接处于半关闭状态。B若发送数据，A仍要接收。
• 后两次挥手
  • 若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。
  • FIN=1,ACK=1,seq=w,ack=u+1。
  • A收到释放报文段后，必须发出确认。
  • 确认报文段：ACK=1,seq=u+1,ack=w+1。
• 客户A为什么要等待2MSL ？
  • 防止“第四次挥手”的确认报文段，B没有接收到而一直处于“LAST-ACK”状态。（此时，B的TCP连接无法释放）
• 为什么要四次挥手 ？
  • 答：TCP使用全双工通信。前两次挥手结束一个方向的连接，后两次挥手结束另一个方向上的连接。
    • 在三次握手的过程中，SYN和ACK是一起发送的但是在四次挥手的时候FIN和ACK却不是一起发送的而是分开发送的，为什么呢？？？那是因为啊，TCP连接是全双工的也就是说接收到FIN只是说没有数据再发过来但是还是可以发送数据的，也就是接受到一个FIN只是关闭了一个方向的数据传输，另一个方向还可以继续发送数据。在四次挥手的时候也是这样前两次挥手只是确认关闭了一个方向的数据，加上后面两次挥手才真正的关闭了整个全双工连接。
    • 当socket在ESTABISHED状态时，他想主动关闭连接于是向对方发送FIN请求，发送完FIN请求后它处于FIN_WAIT_1状态，当对方确认ACK报文后则处于FIN_WAIT_2状态。FIN_WAIT_2表示半连接，也就是有一方要求关闭连接，另一方收到请求但是告诉她我还有一些数据要发送稍后会关闭。TIME_WAIT状态表示收到对方的FIN并发送出ACK.如果三次挥手可能在关闭后还有一个方向没有关。

<4>TCP实现可靠传输

• 理想的传输条件有以下两个特点：
  • 1. 传输信道不产生差错。
  • 2. 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。

a.可靠传输的工作原理：停止等待协议

• 自动重传请求ARQ
  • "停止等待"就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。
    
  • 无差错情况（图(a)）
    • A发送分组M₁，发完就暂停发送，等待 B 的确认。B收到了M₁就向 A 发送确认。 A 在收到了对M₁的确认后，就再发送下一个分组 M₂。同样，在收到 B 对 M₂ 的确认后，再发送 M₃.
  • 超时重传情况（图(b)）
    • B接收M₁时出现差错。这种情况下，A只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。知道A收到了B对M₁的确认，才发送下一分组。
    • 因此，必须注意的事项：第一，A在发送完一个分组后，必须暂时保留已发送的分组的副本(在发生超时重传时使用)。只有在收到相应的确认后才能清除暂时保留的分组副本。第二，分组和确认分组都必须进行编号。这样才能明确是哪一个发送出去的分组收到了确认，而哪一个分组还没有收到确认。第三，超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长-些。
  • 确认丢失（图(c)）
    • B接收完M₁后，返回对M₁的确认时，确认包丢失。A在设定的超时重传时间内没有收到确认，并无法知道是自己发送的分组出错、丢失，或者是B发送的确认丢失了。因此A在超时计时器到期后就要重传M_{1。现在应注意B的动作。假定B又收到了重传的分组 M1。}
    • 第一，丢弃这个重复的分组 M₁，不向上层交付。
    • 第二，向 A 发送确认。
  • 确认迟到（图(d)）
    • 传输过程中没有出现差错，但B对分组 M₁ 的确认迟到了。A会收到重复的确认。对重复的确认的处理很简单:收下后就丢弃。B仍然会收到重复的M₁。并且同样要丢弃重复的 M₁。并重传确认分组。
• 连续ARQ协议
  提高ARQ的信道利用率
  
  • 接收方累积确认
    • 接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示:到这个分组为止的所有分组都己正确收到了。
    • 优点：容易实现
    • 缺点：假如发送方发了前5个分组，接收方第3个分组丢失。则返回确认号是3，此时，第3、第4、第5分组都需要重新发送（尽管第4、第5分组接收方收到了）。
  • 发送方滑动窗口
    • 连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。
    • 假如收到3个分组的确认，则窗口移动3位。

b.滑动窗口下，TCP可靠传输的实现

• 以字节为单位的滑动窗口
  • TCP 的滑动窗口是以字节为单位的。
  • 现假定A收到了B发来的确认报文段，其中窗口是20字节，而确认号是31(这表明B期望收到的下一个序号是31，而序号30为止的数据己经收到了)。根据这两个数据，A就构造出自己的发送窗口。
    
    • 发送窗口表示:在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。
    • 发送窗口里面的序号表示允许发送的序号。显然，窗口越大，发送方就可以在收到对 方确认之前连续发送更多的数据，因而可能获得更高的传输效率。但是，A的发送窗口一定不能超过 B的接收窗口数值。（还要考虑网络拥塞问题）
• 滑动窗口与可靠传输
  
  发送端的黑色方框：已经发送；接收端黑色方框：已经接收（不一定按序）。
  • 第一阶段：
    • 发送方：发送了31~41共11个分组，暂未获得确认号。
    • 接收方：收到32、33分组，但未收到31分组。因此，确认号仍然是31。
    • 接收方窗口：不变
    • 发送方窗口：不变
  • 第二阶段：
    • 发送方：重新发送31分组。然后收到确认号34
    • 接收方：接收到31分组，并且接收到37、38、40分组。发送确认号34。
    • 接收方窗口：31、32、33分组交付主机窗口，移动3个序号。
    • 发送方窗口：接收到确认号34，因此窗口移动3个序号。
  • 第三阶段：
    • 发送方：将窗口内所有允许发送的分组全部发送。暂未收到确认号。（窗口已满，停止发送）（过一段时间，A重传窗口内的20个分组）
    • 接收方：可能没收到34，也可能全部收到或部分收到，但是确认号在网络上丢失。
    • 接收方窗口：不变
    • 发送方窗口：不变

<5>TCP实现流量控制

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

用滑动窗口实现流量控制

• 接收方的主机B进行了三次流量控制。
  • 第一次把窗口减小到 rwnd = 300,
  • 第二次又减到 rwnd = 100，
  • 最后减到 rwnd = 0，即不允许发送方再发送数据了。
  • 这种便发送方暂停发送的状态将持续到主机 B 重新发出一个新的窗口值为止。我们还应注意到， B 向 A 发送的三个报文段都设置了 ACK= 1 ，只有在 ACK=1 时确认号宇段才有意义。
• 死锁局面
  • 问题的产生：
    • B 向 A 发送了零窗口的报文段后不久， B 的接收缓存又有了一些存储空间。于是 B 向 A 发送了 rwnd = 400 的报文段。然而这个报文段在传送过程中丢失了。 A 一直等待收到 B 发送的非零窗口的通知，而 B 也一直等待 A 发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。
  • 解决：
    • TCP 为每一个连接设有一个持续计时器。只要 TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段(仅携带 1 字节的数据)，而对方就在确认这个探测报文段时给出了现在的窗口值。如果窗口仍然是零，那么收到这个报文段的一方就重新设置持续计时器。如果窗口不是零，那么死锁的僵局就可以打破了。

<6>TCP实现拥塞控制

a.拥塞控制所起的作用

• 无拥塞控制情况：
  • 当网络的吞吐量明显地小于理想的吞吐量时，网络就进入了轻度拥塞的状态。
  • 当提供的负载达到某一数值时，网络的吞吐量反而随提供的负载的增大而下降，这时网络就进入了拥塞状态。
  • 。当提供的负载继续增大到某一数值时，网络的吞吐量就下降到零，网络己无法工作，这就是所谓的死锁。
• 理想的拥塞控制
  • 理想吞吐量大于负载时，没有拥塞。发送多少分组吞吐量就是多大。
  • 负载大于理想吞吐量时，以最大吞吐量发送分组。
• 实际的拥塞控制
  • 如图
  • 避免死锁

b.TCP的拥塞控制方法

慢开始 、拥塞避免、快重传、快恢复（注意：由发送方控制，接收方仅恢复确认号）

1）慢开始和拥塞避免

拥塞控制也叫做基于窗口的拥塞控制。为此，发送方维持一个叫做拥塞窗口 cwnd 的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。

• 慢开始阶段（cwnd < ssthresh时）
  • 思想：
    • 当主机开始发送数据时，由于并不清楚网络的负荷情况，所以如果立即把大量数据字节注入到网络，那么就有可能引起网络发生拥塞。经验证明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。
  • 过程（第一阶段举例，第一阶段，初始ssthresh=16）：
    • 传输轮次为0时，拥塞窗口cwnd=1；cwnd < ssthresh；
    • 传输轮次为1时，拥塞窗口cwnd=2；cwnd < ssthresh；
    • 传输轮次为2时，拥塞窗口cwnd=4；cwnd < ssthresh；
    • 传输轮次为3时，拥塞窗口cwnd=8；cwnd < ssthresh；
    • 传输轮次为4时，拥塞窗口cwnd=16；cwnd = ssthresh；
• 拥塞避免阶段（ssthresh < cwnd）
  • 思想：
    • 拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是像慢开始阶段那样加倍增长。因此在拥塞避免阶段就有"加法增大" AI (Additive Increase)的特点。这表明在拥塞避免阶段，拥塞窗口 cwnd 按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。
  • 过程（第一阶段举例，第一阶段，初始ssthresh=16）：
    • 传输轮次为5时，拥塞窗口cwnd=17；未超时，认为没有拥塞；
    • 传输轮次为6时，拥塞窗口cwnd=18；未超时，认为没有拥塞；
    • 传输轮次为7时，拥塞窗口cwnd=19；未超时，认为没有拥塞；
    • 传输轮次为8时，拥塞窗口cwnd=20；未超时，认为没有拥塞；
    • 传输轮次为9时，拥塞窗口cwnd=21；未超时，认为没有拥塞；
    • 传输轮次为10时，拥塞窗口cwnd=22；未超时，认为没有拥塞；
    • 传输轮次为11时，拥塞窗口cwnd=23；未超时，认为没有拥塞；
    • 传输轮次为12时，拥塞窗口cwnd=24；超时，认为出现网络拥塞；
• 出现超时的情况！！！
  • 出现超时后，将拥塞窗口重新置为1，ssthresh置为上次超时时窗口大小的一半，即ssthresh = cwdn / 2（图中，传输伦茨13时，ssthresh=24/2=12）
  • 开始重复之前的“慢开始”和“拥塞避免”。
• 问题？？？？？？？？？
  • 出现超时，即认为网络拥塞，并把cwnd置为1，这种方式不妥
  • 原因是：个别报文段会在网络中丢失，但实际上网络并未发生拥塞。如果发送方迟迟收不到确认，就会产生超时，就会误认为网络发生了拥塞。这就导致发送方错误地启动慢开始，把拥塞窗口 cwnd 又设置为1，因而降低了传输效率。（上图黑色圆圈4传输轮次21时，3个ACK）
  • 解决方法：快重传、快恢复

2）快重传和快恢复

本来，TCP的可靠传输是靠“超时重传”提供的，现在，由于引入网络拥塞控制，只要超时，就认为出现了网络拥塞。因此，除非出现网络拥塞情况，正常丢包情况我们是不希望超时！！！因此，引入快重传

• 快重传算法
  • 快重传算法可以让发送方尽早知道发生了个别报文段的丢失。
  • 快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对己收到的报文段的重复确认。
  • 示意图
    
    • 接收方收到了M₁和M₂后部分别及时发出了确认。
    • 假定接收方没有收到M₃但却收到了M₄。（本来什么都不需要做，等待超时重传<等待一个M₂确认>即可。但此时不能再使其超时）
    • 按照快重传算法，接收方必须立即发送对M₂的重复确认，以便让发送方及 早知道接收方没有收到报文段M₃.
    • 快重传算法规定，发送方只要一连收到 3 个重复确认，就知道接收方确实没有收到报文段M₃因而应当立即进行重传(即“快重传”，这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。
    • 因此，发送方共收到4个对M₂的确认。
• 快恢复算法
  
  • 传输轮次为20时，发出3个ACK。
  • 此时，重新置ssthresh = cwnd(传输轮次20)/2 = 16/2 = 8
  • 同时，设置拥塞窗口cwnd=ssthresh=8，并开始执行“避免拥塞”算法。
    • 有时，设置cwnd=ssthresh + 3 x MSS （因为:既然发送方收到 3 个 重复的确认，就表明有 3 个分组已经离开了网络。）