网络--传输层TCP、UDP、流量控制、拥塞避免、三次挥手
文章目录
- 第五章 传输层
- 5.1 OSI和DoD模型
- 5.2 传输层协议和应用层协议的关系
- 5.3 服务和应用层协议的关系
-
- 5.3.2 如何查看服务侦听的端口
- 5.4 传输层功能和端口范围
-
- 5.4.1 传输层协议和网络层协议的主要区别
- 5.4.2 传输层的主要功能
- 5.4.3 传输层的端口
- 5.5 ==UDP协议==
-
- 5.5.1 UDP的首部格式
- 常用TCP/UDP协议
- 5.6 ==TCP协议==
-
- 5.6.1 TCP的连接
- 5.7 TCP如何实现可靠传输
-
-
-
- (1)可靠传输的工作原理——停止等待协议。
- (2)确认机制
- (3)可靠通信的实现
- (4)流水线传输(发送方)
- (5)连续ARQ协议
- (6)==累计确认==(接收方)
-
-
- 5.8 TCP报文段的==首部格式==
-
- 5.8.1 抓包分析P64
- 5.9 TCP如何实现可靠传输P67
-
- 5.9.1 以字节为单位的==滑动窗口技术==
- 5.9.2 超时重传时间
- 5.10 TCP如何实现==流量控制==P68
-
-
-
- 流量控制
-
-
- 5.11 TCP如何避免==网络拥塞==
-
- 5.11.2 ==慢开始和拥塞避免==
-
-
-
- 慢开始算法的原理
-
-
- 5.11.3 ==快重传和快恢复==
- 5.12 三次握手四次挥手
第五章 传输层
5.1 OSI和DoD模型
下图必须背下来。尤其是传输层和网络层的协议。
传输层最大数据包是65535字节，而网络层数据最大只有1480字节。所以需要分段，但是只要分段，就有可能丢包，因为网络层不负责可靠传输。所以要求服务器和客户端保持会话，直到数据传输完成。
->TCP(Transmission Control Protocol)传输控制协议
应用场景：需要将要传输的文件分段传输时；就需要TCP协议来建立会话实现可靠传输；同时也有流量控制功能。(例如QQ传文件)
查看会话 netstat -n
查看建立会话的进程 netstat -nb
->UDP(User Data Protocol)用户数据报协议
应用场景：一个数据包就能完成数据通信；不需要建立会话和流量控制；多播/广播；是一种不可靠传输。(例如QQ聊天，屏幕广播)
5.2 传输层协议和应用层协议的关系
TCP+端口=应用层协议
(1)TCP和UDP协议和不同的端口即可对应一个应用层的协议。注意，53大部分是与UDP相连。
(2)熟知数值一般为0-1023，登记端口号数值1024-49151，客户端口号数值为49152-65535.
(3)常用的应用层协议使用的端口(号)：
http = TCP + 80
Https = TCP + 443
RDP = TCP + 3389
ftp = TCP + 21
共享文件夹 = TCP + 445
SMTP = TCP + 25发邮件
POP3 = TCP + 110收邮件
telnet = TCP + 23
SQL = TCP + 1433
DNS = UDP + 53
(注意与4.6 的协议号的区别)
5.3 服务和应用层协议的关系
防火墙是基于网卡的，只打开必要的端口，不必要的端口不允许接收数据，不影响服务的运行和监听。
服务使用TCP或UDP的端口侦听客户端请求；
客户端使用IP地址定位服务器，使用目标端口，定位服务；
可以在服务器网卡上设置只开放必要的端口，实现服务器网络安全。
5.3.1 如何在Windows上安装服务
DNS服务
Web服务
SMTP
POP3
5.3.2 如何查看服务侦听的端口
netstat -a
netstat -an 以数字的形式查看端口
netstat -n 查看建立的会话
netstat -nb 查看建立会话的进程
tcp6 1 0 192.168.1.161:33753 222.195.151.170:9013 CLOSE_WAIT
tcp6 1 0 192.168.1.161:38421 222.195.151.170:9013 CLOSE_WAIT
tcp6 1 0 192.168.1.161:50123 222.195.151.170:9013 CLOSE_WAIT
tcp6 1 0 192.168.1.161:44755 222.195.151.170:9013 CLOSE_WAIT
tcp6 1 0 192.168.1.161:37939 222.195.151.170:9013 CLOSE_WAIT
tcp6 1 0 192.168.1.161:42963 222.195.151.170:9013 CLOSE_WAIT
tcp6 1 0 192.168.1.161:39037 222.195.151.170:9013 CLOSE_WAIT
tcp6 1 0 192.168.1.161:38967 222.195.151.170:9013 CLOSE_WAIT
tcp6 1 0 192.168.1.161:37911 222.195.151.170:9013 CLOSE_WAIT
tcp6 1 0 192.168.1.161:51255 222.195.151.170:9013 CLOSE_WAIT
tcp6 1 0 192.168.1.161:53861 222.195.151.170:9013 CLOSE_WAIT
tcp6 1 0 192.168.1.161:38413 222.195.151.170:9013 CLOSE_WAIT
# 如何打开telnet功能：在控制面板--程序 ---启用或关闭windows功能---telnet客户端
telnet 192.168.80.100 3389 测试到远程计算机某个端口是否打开
5.3.3 如何更改服务使用默认端口
可以迷惑病毒，使系统更加安全。
5.3.4 如何设置Windows网络安全
设置本地连接 TCP/IP筛选
windows防火墙：拦入不拦出
5.4 传输层功能和端口范围
5.4.1 传输层协议和网络层协议的主要区别
网络层实现如何把数据包从这个地址(服务器)发送到另一个地址(服务器)。
传输层实现如何让这个应用程序找到对应计算机的应用程序(相对应的应用程序实现逻辑通信)。
5.4.2 传输层的主要功能
(1)传输层为应用进程之间提供了端到端的逻辑通信(但网络层是为主机之间提供逻辑通信)。
(2)传输层还要对收到的报文进行差错检验。
(3)传输层提供面向连接(TCP)和无连接(UDP)的服务。
5.4.3 传输层的端口
(1)TCP的端口
端口用一个16位端口号进行标志。
端口号只具有本地意义，即端口号只是为了标志本计算机应用层的各进程。在Internet中不同计算机的相同端口号是没有联系的(最好不要有冲突)。
用协议号表示是TCP 6 还是UDP 17
5.5 UDP协议
User Datagram Protocol
(1)UDP是无连接的，即发送数据之前不需要建立连接。
(2)UDP使用尽最大努力交付，即不保证可靠交付，同时也不使用拥塞控制。
(3)UDP是面向报文的，适合多媒体通信的要求。
(4)UDP支持一对一，一对多，多对一，多对多交互通信。
(5)UDP首部开销小，只有8个字节。
UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等
5.5.1 UDP的首部格式
UDP只有8个字节的首部开销，比TCP的20个字节的首部要短。但他有12个字节的伪首部。源IP和目的IP在伪首部中，源端口和目的端口在首部中
首部中的长度指的是UDP用户数据报的长度(首部+数据)。
12字节伪首部用于检验和，我的理解是伪首部是IP数据包首部的后部分。
由于UPD没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。很多的实时应用（如IP电话、实时视频会议等）要求源主机以恒定的速率发送数据，并且允许在网络发送拥塞时丢失一些数据，但却不允许数据有太大的时延。UDP正好适合这种要求。
虽然某些实时应用需要使用没有拥塞控制的UDP，但当很多的源主机同时向网络发送速率的实时视频时，网络就有可能发送拥塞，结果大家都无法正常接收。因此UDP不使用拥塞控制功能可能会引起网络产生严重的拥塞问题。
常用TCP/UDP协议
| 应用 | 应用层协议 | 运输层协议 |
|---|---|---|
| 名字转换 | DNS |
UDP |
| 文件传送 | TFTP | UDP |
| 路由选择协议 | RIP | UDP |
| IP地址配置 | BOOTP,DHCP | UDP |
| 网络管理 | SNMP | UDP |
| 远程文件服务器 | NFS | UDP |
| IP电话 | 专用协议 | UDP |
| 流式多媒体通信 | 专用协议 | UDP |
| 多播 | IGMP |
UDP |
| --------------- | --------------- | --------------- |
| 电子邮件 | SMTP | TCP |
| 远程终端输入 | TELNET | TCP |
| 万维网 | HTTP | TCP |
| 文件传送 | FTP | TCP |
5.6 TCP协议
- (1)TCP是面向连接的传输层协议。(三次握手)
- (2)每一条TCP连接智能有两个端点(endpoint)，每一条TCP连接只能时点对点的(一对一)。
- (3)TCP提供可靠交付的服务。(确保不丢包)
- (4)TCP提供全双工通信。(因为需要接收端的反馈，例如如果接收端处理不过来，可让发送端慢一点，流量控制)
- (5)面向字节流。TCP将所要传送的整个报文（这可能包括多个报文段）看成一个个字节组成的数据量，并使每一个字节对应于一个序号。在建立连接时，双方要商定初始序号。
TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这一难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。
下面演示字节流传输（滑动层窗口）
如果要传输一个比较大的数据，首先一次只会传输一小块，这个数据块的大小是没有规律的。加上数据包数据帧的头，发送给接收端，接收端去掉首部，再次拼接。
5.6.1 TCP的连接
(1)TCP把连接作为最基本的抽象。
(2)每一条TCP连接有两个端点。
(3)TCP连接的端点不是主机，不是主机的IP地址，不是应用程序，也不是传输层协议端口，TCP连接的端点叫 套接字(socket).
- 套接字socket = (IP地址:端口号)
- 每一条TCP连接唯一地被通信两端的两个套接字所确定，即：
- TCP连接 ::= {socket1, socket2} = {(IP1:port1), (IP2:port2)}
(4)端口号拼接到IP地址即构成了套接字。
5.7 TCP如何实现可靠传输
TCP 连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口。
TCP 两端的四个窗口经常处于动态变化之中。
TCP连接的往返时间 RTT 也不是固定不变的。需要使用特定的算法估算较为合理的重传时间。
- 应用数据被分割成 TCP 认为最适合发送的数据块。
- TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
- 校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
- TCP 的接收端会丢弃重复的数据。
- 流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）
- 拥塞控制： 当网络拥塞时，减少数据的发送。
- ARQ协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
- 超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
(1)可靠传输的工作原理——停止等待协议。
- 停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组；
- 在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认；
- 在发送完一个分组后，必须暂时保留已发送的分组的副本。
- 分组和确认分组都必须进行编号。
- 超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些。
优点： 简单
缺点： 信道利用率低，等待时间长
1无差错情况:
发送方发送分组,接收方在规定时间内收到,并且回复确认.发送方再次发送。
2 出现差错情况（超时重传）:
停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为 自动重传请求 ARQ 。另外在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。连续 ARQ 协议 可提高信道利用率。发送维持一个发送窗口，凡位于发送窗口内的分组可连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组位置的所有分组都已经正确收到了。
3 确认机制
(2)确认机制
- 确认丢失 ：确认消息在传输过程丢失。当A发送M1消息，B收到后，B向A发送了一个M1确认消息，但却在传输过程中丢失。而A并不知道，在超时计时过后，A重传M1消息，B再次收到该消息后采取以下两点措施：1. 丢弃这个重复的M1消息，不向上层交付。 2. 向A发送确认消息。（不会认为已经发送过了，就不再发送。A能重传，就证明B的确认消息丢失）。
- 确认迟到 ：确认消息在传输过程中迟到。A发送M1消息，B收到并发送确认。在超时时间内没有收到确认消息，A重传M1消息，B仍然收到并继续发送确认消息（B收到了2份M1）。此时A收到了B第二次发送的确认消息。接着发送其他数据。过了一会，A收到了B第一次发送的对M1的确认消息（A也收到了2份确认消息）。处理如下：1. A收到重复的确认后，直接丢弃。2. B收到重复的M1后，也直接丢弃重复的M1。
(3)可靠通信的实现
- 使用上述的确认和重传机制，微秒就可以在不可靠的传输网络上实现可靠的通信。
- 这种可靠传输的协议常称为自动重传请求ARQ(Automatic Repeat reQuest)。
- ARQ表明重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。
- 缺点，信道利用率低。
- 信道利用率U
(4)流水线传输(发送方)
发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。由于信道上一直有数据不间断的传送，这种传输方式可获得很高的信道利用率。
(5)连续ARQ协议
连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。
优点： 信道利用率高，容易实现，即使确认丢失，也不必重传。
缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如：发送方发送了 5条 消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。
如果1确认收到了，则滑动窗口。
如果12收到了，3没有收到，则滑动窗口会会回溯到3位置，重新发送。
(6)累计确认(接收方)
接收方一般采用累计确认的方式。
优点：容易实现，信道利用率高。
缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。
5.8 TCP报文段的首部格式
TCP报文段首部的前20个字节是固定的，后面有4N字节是根据需要而增加的选项，因此TCP首部的最小长度是20字节。
(1)源端口：2个字节16位。
(2)目的端口：2个字节16位。
(3)序号：当前数据的第一个字节在整个文件中的序号。
(4)确认号ack：接收端发送，提示发送端下一次该发的数据在整个文件中的序号。接收端收到后，会把这个序号之前的数据从缓存中删掉。由于TCP连接能提供全双工通信，因此通信中的每一方都不必专门发送确认报文段，而是可以在传送数据时顺便把确认信息捎带传送。这样做可以传输效率。
(5)数据偏移：当前TCP报文段第多少个字节后是TCP的数据部分了（因为首部一般是20B，所以这个值一般是20）。但他的单位不是字节而是32bit，数据便宜占4bit，数据偏移最多表示1111，即15，所以他最多可以表示15乘以4，即60个字节的偏移量，所以选项+填充最多只能是40个字节。
(6)保留：6位，无作用。
(7)URG：urgent，意思是优先级高，发送端优先发送，而不是在缓存中排队。
(8)ACK：acknowledge，1意味着确认建立了会话。1的时候确认号才有效
(9)PSH：1意味着接收端优先读取，而不是在缓存中排队。
(10)RST：reset，1意味着TCP会话出现严重错误，必须释放和重新连接。
(11)SYN：同步。1意味着要发起会话。
(12)FIN：finish，1意味着释放连接。
(13)窗口：允许接收的缓存大小，即控制对方发送的数据量。接收端先发，发送端根据接收端的窗口尺寸确定发送端窗口尺寸。发送方的发送窗口的上限值应当取为接收方窗口 和拥塞窗口 这两个变量中较小的一个。TCP连接的一端根据设置的缓存空间大小确定自己的接收窗口大小，然后通知对象以确定对方的发送窗口的上限。
将TCP连接的两端分别记为A和B，若A确定自己的接收窗口为WIN，则A发送给B的TCP报文段的窗口字段中写入WN的数值。这就是告诉B的TCP，“你（b）在未收到我（a）的确认时所能够发送的数据量的上限就是从本首部中的确认号开始的WIN个字节。”所以A所设定的WIN既是A的接收窗口，同时也就是B的发送窗口的上限值。例如，A在发送给B的报文段的首部中将窗口字段的值WIN置为500，将确认号置为201.这就是告诉B：“你（b）在未收到确认的情况下，最多可向我（a）发送序号从201开始到700共500字节的数据”。B在收到此报文段后，就用此窗口数值500作为B的发送窗口的上限值。但应注意，B向A发送的报文段的首部也有一个窗口字段，但这是根据B的接收能力来确定A的发送窗口上限，一定不要弄混。
(14)检验和：
(15)紧急指针：只有URG为1才有用。
在发送端，TCP是怎样决定一个报文段的时机呢？
TCP有三种基本机制来控制报文段的发送。
- 第一种机制是TCP维持一个变量，它等于最大报文段长度MSS。只要发送缓存从发送进程得到的数据达到MSS字节时，就组装成一个TCP报文段，然后发送出去
- 第二种机制是发送端的应用进程指明要求发送报文段，即TCP支持的推送(push)操作。
- 第三种机制是发送端的一个计时器时间到了，这时就把当前已有缓存数据装入报文段发送出去
5.8.1 抓包分析P64
(1)
第一步，ARP，建立可靠传输
第二步，UDP(DNS同时占用UDP和TCP的53端口)，域名解析
第三步，TCP，识别网关MAC地址
(2)cmd打开控制台如下，当前是建立了2个会话。
(3)浅蓝：请求的数据包；深蓝：得到的结果；
192是我方地址；8是服务器地址；
(4)两个SYN是双方确认建立了会话，MSS意思是最大数据包1460字节，web端(219.148.36.48)最多能缓存win=64240字节，我端(192.168.80.63)最多能缓存win=65535字节,如果某一方发了另一方win字节个数据对方都没有确认，那么就暂停。标记为TCP这三行(12,13,14)，不光是建立对话，还协商了一些参数。
(5)第15行，开始正式通信，HTTP。GET的意思是我要访问这个网站了。白框内写着各个层的数据首部的结构。
目标端口Src Port是80，源端口Dst Port是1057，序号Sep是1，确认号Ack是1，数据部分长度是1-203字节。
(6)219->192是发送网页信息，192->219是确认反馈。注意，16第一次发送数据和19反馈接收是没有数据len=0。
从建立会话，到传输数据到确认反馈的一个过程如下，15-19。
5.9 TCP如何实现可靠传输P67
5.9.1 以字节为单位的滑动窗口技术
A的发送窗口是由B的接受窗口长度决定的。
在没有收到B确认收到之前，A不能删掉滑动窗口内的内容。
A可以持续给B发送，直到A的滑动窗口内数据都发了。
B收到后给A发确认收到的反馈ACK，序号是下一个应该发送的字节的序号，A收到后，就可以滑动窗口到对应的位置。例如B反馈ACK是7，那么A的滑窗可以移动到7位置，1-6删除。21-26可以发送。
B收到1-6之后，也开始滑窗，B的应用程序可以读取1-6的数据。B的滑窗继续接收。
以上是正常状态下的情况。如果出现丢失情况，例如7-9丢失，此时B反馈的ACK=7.因为10-12收到了，因此B发送SACK(选择性确认)，A只发送7-9.
5.9.2 超时重传时间
TCP每发送一个报文段，就对这个报文段设置一次计时器。只要计时器设置的重传时间到了，但是还没有收到数据，那么就重传这一报文段。
由于TCP的下层是一个互连网环境，发送的报文段可能只经过一个高速率的域网，但也可能是经过多个低速率的广域网，并且P数据报所选择的路由还可能会发生变化。图7-17画出了数据链路层和运输层的往返时延概率分布的对比。往返时延就是从数据发出到收到对方的确认所经历的时间。对于数据链路层，其往返时延的方差很小，因此将超时时间设置为如图中的T1即可。但对于运输层来说，其往返时延的方差很大。若将超时时间设置为图中的T2，则很多报文段的重传时间是太早了，给网络增加了许多不应有的负荷。但若将超时时间选为图中的T3，则显然会使网络的传输效率降低很多。
图7-17数据链路层和运输层的往返时延的概率分布的差别
那么，运输层的超时计时器的重传时间究竟应设置为多大？
自适应RTT：
TCP采用了一种自适应算法。这种算法记录每一个报文段发出的时间，以及收到相应的确认报文段的时间。这两个时间之差就是报文段的往返时延。将各个报文段的往返时延样本加权平均，就得到报文段的平均往返时延。每测试到一个新的往返时延样本，就按下式重新计算一次平均往返时延RTT。
RTTs(new) = (1 - alpha) x (旧的RTTs) + alpha x (新的往返时延样本)
超时重传时间应略大于上面得出的加权平均往返时间RTTs。alpha推荐值是0.125.
这个公式的目的是根据网速和带宽的实时情况调整往返时间。
5.10 TCP如何实现流量控制P68
解决通信两端处理时间不一样的问题。通过实时调整滑窗尺寸的大小(尺寸甚至可以是0)来实现流量控制。接收端主动调整滑窗大小，发送端根据接收端发送的报文调整相应的滑窗。发送端也会定时发送报文向接收端确认滑窗信息，避免接收端发送的相关调整滑窗大小的报文丢失带来的影响。
如果确认35，代表35之前的都收到了，所以可以累积确认
发送缓存
接收缓存
流量控制
流量控制(flow control)就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。
利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制。
持续计时器：
发送方和接收方死锁局面的产生
TCP 为每一个连接设有一个持续计时器。
若持续计时器设置的时间到期，就发送一个零窗口探测报文段
若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器。
若窗口不是零，则死锁的僵局就可以打破了。
5.11 TCP如何避免网络拥塞
在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。红线和绿线之间是数据丢失内容。
接收端有接收的窗口容量，同时网络也有他自己的处理能力，拥塞发送在通过网络传输的分组数量开始接近网络对分组的处理能力时。
拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
(1)出现资源拥塞的条件：对资源需求的总和>可用资源。
(2)拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由区，以及与降低网络传输性能有关的所有因素。
(3)流量控制往往指在给定的发送端和接收端之间的点对点通信量的控制，它所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
流量控制是两台机器，拥塞控制是多台
- 接收端窗口rwnd(receiver window)：来自接收端的流量控制
- 拥塞创建cwnd(congestion window)：来自发送端的流量控制
没人会告诉发送端：“你的拥塞创建应设置多大”。发送端确定拥塞创建的原则是这样的：主要网络没有出现拥塞，发送端就使拥塞创建再增大一些，以便更多的分组(IP数据报)发送出去。但只要网络出现拥塞，发送端就使拥塞创建减小一些，以减少注入到网络中的分组数。
发送端又是如何知道网络发送了拥塞呢？我们知道，当网络发生拥塞时，路由器就要丢弃分组。因此只要发送端没有按时收到应当到达的确认报文ACK，就可以认为网络出现了拥塞。
现在通信线路的传输质量一般都很好，因传输出差错而丢弃分组的概率是很小的。
发送创建的上限值=min[rwnd,cwnd]
也就是说接收能力和拥塞限制都会影响发送窗口。
在讨论拥塞控制时需要特别注意以下两点。
第一，我们在网络层观察问题时，经常讲到主机发送分组（或IP数据报）和路由器转发分组（或IP数据报）。但在运输层讨论问题时，我们就说“主机发送报文段”。这两种说法并没有多大实质性差别，因为运输层的报文段就是分组（或数据报的数据部分在讨论网络的各种问题时也经常同时使用“报文段”和分组”这两个名词，但应注意它们是不同层次的数据传送单位。
第二，在每一个运输连接上报文段是断续发送的（因为要受发送窗口的制约，有时要停止发送而等待对方的确认）。这样就有了两种速率。一种是链路层的数据率，另一种是从运输层看到的数据注入速率。例如，主机连接到网络的链路速率是2Mb/s。主机只要发送报文段在链路上的数据传送速率就是2Mb/s。但当主机暂停发送报文段时，则链路处于空闲状态。现在假定主机在1秒钟内发送100个报文段，而每个报文段含有1000字节的数据。从运输层看，这相当于主机在这1秒钟向网络注入了000字节的数据，即0.8Mb/s。实际上，一个报文段除了数据部分还有20字节长的首部通常在运输层观察向网络注入数据时往往不考虑首部的20字节，这是因为运输层只对数据部分的每个字节进行编号，而运输层的窗口大小都是对报文段中的数据部分而言的。实际上从链路层注入到网络的数据量，还必须把运输层和传输层的首部以及链路层的首部和尾部加上去。
慢开始、拥塞避免、快重传、快恢复
5.11.2 慢开始和拥塞避免
发送端的主机在确定发送报文段的速率时，既要根据接收端的接收能力，又要全局考虑不要使网络发送拥塞。
- （1）接收端窗口rwnd（receiver window）是接收端根据其目前的接收缓存大小所许诺的最新的窗口值，是来自接收端的流量控制。接收端将此窗口值放在TCP报文的首部中的窗口字段，传送给发送端。接收端窗口又称为通知窗口（advertised window）
- （2）拥塞窗口cwnd（congestion window）是**发送端根据自己估计的网络拥塞程度而设置的窗口值**，是来自发送端的流量控制。
没有人会告诉发送端：“你的拥塞窗口应设置为多大”。发送端确定拥塞窗口的原则是这样的：
- 只要网络没有出现拥塞，发送端就使拥塞窗口再增大一些，以便将更多的分组发送出去。
- 但只要网络出现拥塞，发送端就使拥塞窗口减小一些，以减少注入到网络中的分组数。
==发送端又是如何知道网络发生了拥塞呢？我们知道，当网络发生拥塞时，路由器就要丢弃分组。因此只要发送端没有按时收到应当到达的确认报文ACK，就可以认为网络出现了拥塞。==现在通信线路的传输质量一般都很好，因传输出差错而丢弃分组的概率是很小的（远小于1%）。下面继续讨论发送端如何具体控制拥塞窗口cwnd的大小。
发送窗口的上限值=min{接收端窗口，拥塞窗口}
慢开始算法的原理
当主机开始发送数据时，如果立即将较大的发送窗口中的全部数据字节都注入到网络，那么由于这时还不清楚网络的状况，因而就有可能引起网络拥塞。经验证明，较好的方法是试探一下，即由小到大逐渐增大发送端的拥塞窗口数值。
通常在刚刚开始发送报文段时刻线将拥塞创建cwnd设置为一个最大报文段MSS的数值。而在每接收一个对新的报文段的确认后，将拥塞创建增加至多一个MSS的数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍。用这样的方法逐步增大发送端的拥塞创建cwnd，可以使分组注入到网络的速度更加合理。（可见慢开始的慢并不是指cwnd的增长速率慢，而是指的开始发送时向网络注入的分组数大大减少）
当 TCP 连接进行初始化时，将拥塞窗口置为 1。图中的窗口单位不使用字节而使用报文段。
慢开始门限的初始值设置为 16 个报文段，即 ssthresh = 16。
发送端的发送窗口不能超过拥塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我们假定接收端窗口足够大，因此现在发送窗口的数值等于拥塞窗口的数值。
-
在执行慢开始算法时，拥塞窗口 cwnd 的初始值为 1，发送第一个报文段 M0。
-
发送端每收到一个确认 ，就把 cwnd 加 1。于是发送端可以接着发送 M1 和 M2 两个报文段。
-
接收端共发回两个确认。发送端每收到一个对新报文段的确认，就把发送端的 cwnd 加 1。现在 cwnd 从 2 增大到 4，并可接着发送后面的 4 个报文段。
-
发送端每收到一个对新报文段的确认，就把发送端的拥塞窗口加 1，因此拥塞窗口 cwnd 随着传输轮次按指数规律增长。
-
当拥塞窗口 cwnd 增长到慢开始门限值 ssthresh 时（即当 cwnd = 16 时），就改为执行拥塞避免算法，拥塞窗口按线性规律增长+1。
-
假定拥塞窗口的数值增长到 24 时，网络出现超时，表明网络拥塞了。
-
更新后的 ssthresh 值变为 12（即发送窗口数值 24 的一半），拥塞窗口再重新设置为 1，并执行慢开始算法。
-
当 cwnd = 12 时改为执行拥塞避免算法，拥塞窗口按按线性规律增长，每经过一个往返时延就增加一个 MSS 的大小。
再循环进行
说明：
- 拥塞避免并非指完全能够避免拥塞。利用以上的措施要完全避免网络拥塞还是不可能的。
- 拥塞避免是说在拥塞避免阶段吧拥塞避免窗口控制为按线性规律增长，使网络比较不容易出现拥塞。
最大报文段长度MSS是什么我们之前提过了，当发送缓存中的字节达到一定数量时，就组成报文段发送出去。（只是MSS的一个作用）
发送窗口的计量单位是MSS，即1个MSS，2个MSS，4个MSS…
第一次时候只发送了1个，收到了1个ACK所以增加1个成2个。
第二次发送了2个，收到了两个ACK，每个ACK都会使cwnd+1，所以体现出来的效果是翻倍
(4)设置慢开始门限状态变量ssthresh
为了防止拥塞窗口的增长引起网络阻塞，还需要另一个状态变量，即慢开始门限。
慢开始门限状态变量ssthresh的用法如下：
当cwnd
当cwnd=ssthresh时，使用慢开始算法或拥塞避免算法均可；
(5)拥塞避免算法的思路
让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1（每个传输轮次才加cwnd+1），而不是每个ack都cwnd+1，使拥塞窗口cwnd按线性规律缓慢增长。比如经过了8个传输轮次，cwnd+8
(6)当网络出现拥塞时对策
无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞(其根据就是没有按时收到确认)，就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口cwnd值的一半(但不能小于2)。
然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。
这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够的时间把队列中积压的分组处理完毕。
(7)慢开始和拥塞避免算法的实现举例
（1）当TCP连接进行初始化时，将拥塞窗口置为1前面已说过，为了便于理解，下图中的窗口单位不使用字节而使用报文段。慢开始门限的初始值设置为16个报文段，即 ssthresh=16发送端的发送窗口不能超过拥塞窗口cwnd和接收端窗口rwnd中的最小值。我们假定接收端窗口足够大，因此现在发送窗口的数值等于拥塞窗口的数值。
（2）在执行慢开始算法时，拥塞窗口cwnd的初始值为1以后发送端每收到一个对新报文段的确认ACK，就将发送端的拥塞窗口加1（这个1是指一个最大报文段长度，因为一次我们发送了多个MSS，所以客户端会收到多个ACK，所以cwnd才会翻倍），然后开始下一次的传输（图7-16的横坐标是传输次数）。因此拥塞窗口cwnd随着传输次数按指数规律增长。当拥塞窗口cwnd增长到慢开始门限值 ssthresh时（即当cwnd=16时），就改为执行拥塞避免算法，拥塞窗口按线性规律增长。
（3）假定拥塞窗口的数值增长到24时，网络出现超时（表明网络拥塞了）。更新后的 ssthresh值变为12（即发送窗口数值24的一半），拥塞窗口再重新设置为1，并执行慢开始算法。当cwnd=12时改为执行拥塞避免算法，拥塞窗口按线性规律增长，每经过一个往返时延就增加一个MSS的大小
在TCP拥塞控制的文献中经常可看见“乘法减小”multiplicative decrease和加法增大”（additive increase）这样的提法。“乘法减小“是指不论在慢开始阶段还是拥塞避免阶段，只要出现一次超时（即出现一次网络拥塞），就将慢开始门限值 ssthresh设置为当前的拥塞窗口值乘以0.5。当网络频繁出现拥塞时， ssthresh值下降得很快，以大大减少注入到网络中的分组数。而“加法增大”是指执行拥塞避免算法后，当收到对所有发送出的报文段的确认就将拥塞窗口cwnd增加一个MSS大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞。
这里要再强调一下，“拥塞避免”并非指完全能够避免了拥塞。利用以上的措施要完全避免网络拥塞还是不可能的。“拥塞避免”是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。
5.11.3 快重传和快恢复
快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认，这样做可以让发送方及早知道有报文段没有到达接收方。
比如接收方收到了456，但是一直没收到3，所以一直响应给发送方的序号是3，告诉发送方我现在想要按序接收3，下一个本来想要3，还没得到
快重传：假定发送端发送了报文段 M1-M4四个报文。接收端每收到一个报文后就要立即发出确认ACK，而不要等待值发送数据时才将ACK捎带上。当接收端收到M1和M2后，就发出确认ACK2和ACK3。假定由于网络拥塞使M3丢失了。接收端后来收到下一个M4，发现其序号不对，但仍收下放到缓存中，同时发出确认，不过发出的是重复的ACK3(不能过后发送ACK5，因为ACK5代表M4和M3已经收到了)。同样发送端知道现在是网络出现了拥塞造成分组丢失，但也可能是报文段尚直流在网络的某处，还要经过较长时延才能到达接收端。发送端接着发送M5和M6。接收端收到M5和M6后，也还要分别发出重复的ACK3。这样发送端共收到了接收端的四个ACK3，其中三个是重复的。快重传算法规定：发送端只要一连收到三个重复的ACK即可判定有分组丢失了，就应立即重传丢失的报文段M3而不必等待为M3设置的重传计时器的超时。不难看出，快重传并非取消重传计时器，而是在某些情况下可重传丢失的报文段。
快恢复：与快重传配合使用的还有快恢复算法。当不使用快恢复算法时，发送端若发现网络出现拥塞就将拥塞窗口cwnd降低为1，然后执行慢开始算法。但这样做的缺点是网络不能很快地恢复到正常工作状态，快恢复算法可以较好地解决这一问题，具体步骤如下：
- (1)当发送端收到连续三个重复的ACK时,就重新按照前面讲过的“乘法减小”重新设置慢开始门限ssthresh，这一点和慢开始算法是一样的。
2)与慢开始不同之处是拥塞窗口cwnd不是设置为1，而是设置为cwnd=ssthresh+3×MSS。这样做的理由是:发送端收到三个重复的ACK3表明有三个分组已经离开了网络，它们不会再消耗网络的资源。这三个分组是停留在接收端的缓存中(接收端发送出三个重复的ACK就证明了这个事实)。可见现在网络中并不是堆积了分组而是减少了三个分组。因此,将拥塞窗口扩大些并不会加剧网络的拥塞 - (3)若收到的重复的ACK为n个(n>3),则将cwmd设置为 ssthresh+ n×MSS
- (4)若发送窗口值还容许发送报文段,就按拥塞避免算法继续发送报文段
- (5)若收到了确认新的报文段的ACK,就将cwnd缩小到 ssthresh
在采用快恢复算法时,慢开始算法只是在TCP连接建立时才使用
采用这样的流量控制方法使得TCP的性能有明显的改进
5.12 三次握手四次挥手
传输连接有三个阶段，即：连接建立，数据传送，连接释放。
TCP连接的建立都是采用客户服务器方式。
主动发起连接建立的应用进程叫做客户(client)。
被动等待连接建立的应用进程叫做服务器(server)。
头两次握手除了确定双方都能联通外，还通知了双方的一些端口信息。 第三次握手原因：假如把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机A和B之间的通信，假定A给B发送一个连接请求分组，B收到了这个分组，并发送了确认应答分组。按照两次握手的协定，B认为连接已经成功地建立了，可以开始发送数据分组。可是，B的应答分组在传输中被丢失的情况下，A将不知道B是否已准备好，A认为连接还未建立成功，将忽略B发来的任何数据分组，这样就形成了死锁。 
连接建立采用的这种过程叫做三次握手 three-way handshake),或三次联络。
为什么要发送这第三个报文段呢?这主要是为了防止已失效的连接请求报文段突然传送到了主机B,因而产生错误。
所谓“已失效的连接请求报文段”是这样产生的。考虑这样一种情况。主机A发出连接请求,但因连接请求报文丢天而未收到确认。主机A于是再重传一次。后来收到了确认,建立了连接。数据传输完毕后,就释放了连接。主机A共发送了两个连接请求报文段,其中的第二个到达了主机B。
现假定出现另一种情况,即主机A发出的第一个连接请求报文段并没有丢失,而是在某些网络结点滞留的时间太长,以致延误到在这次的连接释放以后才传送到主机B,本来这是一个已经失效的报文段。但主机B收到此失效的连接请求报文段后,就误认为是主机A又发出一次新的连接请求。于是就向主机A发出确认报文段,同意建立连接。
主机A由于并没有要求建立连接,因此不会理睬主机B的确认,也不会向主机B发送数据。但主机B却以为运输连接就这样建立了,并一直等待主机A发来数据。主机B的许多资源就这样白白浪费了。
采用三次握手的办法可以防止上述现象的发生。例如在刚才的情况下,主机A不会向主机B的确认发出确认。主机B收不到确认,连接就建立不起来
在数据传输结束后,通信的双方都可以发出释放连接的请求。