盘算机网络 | 5.传输层
1.传输层与应用层及网络安全（1）传输层的主要功能
https://i-blog.csdnimg.cn/img_convert/430ba9d4cd5847ec37f53e2ea8d6fa37.jpeg
[*]传输层为应用进程之间提供端到端的逻辑通信（但网络层是为主机之间提供逻辑通信）。
[*]传输层还要对收到的报文举行不对检测。
[*]传输层提供面向毗连和无毗连的服务。
（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个端口（216=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 [端标语]
c.端口与网络安全
[*]1）关掉没有用的服务
[*]将没有用的服务关掉（端口也关掉了）
[*]2）更改服务对应的默认端标语
[*]端标语可以本身更改
[*]人们都知道3306时MySQL的默认端口，3389是全程屏幕的端口。我们更改服务对应的默认端口，可以相对的进步网络安全。
[*]3）关于Windows防火墙
[*]1o Windows防火墙的作用
[*]Windows防火墙将所有端口都关掉了。此时，外网ping不通这台主机。但是这台主机仍旧能够上网，由于端口是动态的，本主机通过一个端口访问外网，外网返回的数据从这个端口返回到该主机。（本主机不自动和外界通信，外界是无法通过端口访问到这台主机） https://i-blog.csdnimg.cn/img_convert/029df162de1ab57d0ec2b5347838d687.jpeg
[*]2o TCPIP筛选
[*]以提供Web服务（80端口）为例。设置Winwods防火墙，担当目的端口为80的数据，只允许向外发送源端口为80的数据包。实现网络安全。 https://i-blog.csdnimg.cn/img_convert/c1e517491ca9fa6feb81492a19ccc03e.jpeg
[*]3o 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）传输层的主要功能
https://i-blog.csdnimg.cn/img_convert/263388a12e180d7622318e827763e06e.jpeg
[*]传输层为应用进程之间提供端到端的逻辑通信（但网络层是为主机之间提供逻辑通信）。
[*]传输层还要对收到的报文举行不对检测。
[*]传输层提供面向毗连和无毗连的服务。
[*]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用户数据报协议
https://i-blog.csdnimg.cn/img_convert/c928d50cb80e607a00ba4101548a4161.jpeg
b.UDP的首部格式
https://i-blog.csdnimg.cn/img_convert/42e3a8a71d266f3d727102ef35844a6e.png
[*]用户数据报UDP有两个字段：数据字段和首部字段。首部字段有8个字节，由4个字段构成，每个字段都是两个字节。
[*]UDP首部中校验和的盘算方法有些特殊。在盘算校验和时,要在UDP用户数据报之前增加12个字节的伪首部。伪首部既不向下传送也不向上递交,而仅仅是为了盘算校验和。与IP数据报的校验和只校验IP数据报的首部差别,UDP的校验和是把首部和数据部门一起都校验。
[*]在盘算检验和时,临时把“伪首部”和 UDP 用户数据报毗连在一起。伪首部仅仅是为了盘算检验和。
[*]盘算校验和举例： https://i-blog.csdnimg.cn/img_convert/c76bba93740da4837bfb0201ca3f17fc.png
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提供全双工通信
[*]面向字节流 https://i-blog.csdnimg.cn/img_convert/5ceb5ce9dfad9e2bd65badf6e33ea809.jpeg
[*]之所以说TCP是面向字节流，是以下原因：
[*]发送端：TCP缓存从文件中拿数据时，可能同时取n个字节，n的巨细不是固定的，每次取数据时，可能n的巨细都不一样。
[*]发送端：TCP缓存中拿到的数据封装时，可能每次封装m个字节，m的巨细不是固定的，每次封装数据时，可能m的巨细都不一样。然后通过毗连发送给接收端。
[*]接收端：TCP缓存接收到数据后，去掉封装部门，拿出数据并按次序拼接，每次向文件中保存时，同时保存q个字节，每次保存时，q的巨细可能都不一样。
[*]都是以字节为单位，因此TCP是面向字节流的。
<2>TCP首部详解
https://i-blog.csdnimg.cn/img_convert/bc10dbbe454b87d8b710ecb6db974a39.png
[*]源端口
[*]占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的毗连创建：三次握手
https://i-blog.csdnimg.cn/img_convert/2f3e889ac0bfeabf212d5f47552f6379.jpeg
[*]第一次握手：
[*]标志位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毗连的开释：四次挥手
https://i-blog.csdnimg.cn/img_convert/c08c899e991bbe84cf3d7bec6aaa394b.jpeg
[*]前两次挥手
[*]数据传输完毕后，通信双方都可以开释毗连。现在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实现可靠传输
[*]理想的传输条件有以下两个特点：
[*]
[*]传输信道不产生不对。
[*]
[*]不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。
a.可靠传输的工作原理：停止等待协议
[*]自动重传哀求ARQ
[*]"停止等待"就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。 https://i-blog.csdnimg.cn/img_convert/3ac67ef3d922cf42afb15b2d8bd63e07.jpeg
[*]无不对环境（图(a)）
[*]A发送分组M1，发完就暂停发送，等待 B 的确认。B收到了M1就向 A 发送确认。 A 在收到了对M1的确认后，就再发送下一个分组 M2。同样，在收到 B 对 M2 的确认后，再发送 M3.
[*]超时重传环境（图(b)）
[*]B接收M1时出现不对。这种环境下，A只要凌驾了一段时间仍旧没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。知道A收到了B对M1的确认，才发送下一分组。
[*]因此，必须留意的事项：第一，A在发送完一个分组后，必须暂时保留已发送的分组的副本(在发生超时重传时使用)。只有在收到相应的确认后才气扫除暂时保留的分组副本。第二，分组和确认分组都必须举行编号。这样才气明确是哪一个发送出去的分组收到了确认，而哪一个分组还没有收到确认。第三，超时计时器设置的重传时间应当比数据在分组传输的均匀往返时间更长-些。
[*]确认丢失（图(c)）
[*]B接收完M1后，返回对M1的确认时，确认包丢失。A在设定的超时重传时间内没有收到确认，并无法知道是本身发送的分组出错、丢失，或者是B发送的确认丢失了。因此A在超时计时器到期后就要重传M1。现在应留意B的动作。假定B又收到了重传的分组 M1。
[*]第一，丢弃这个重复的分组 M1，不向上层交付。
[*]第二，向 A 发送确认。
[*]确认迟到（图(d)）
[*]传输过程中没有出现不对，但B对分组 M1 的确认迟到了。A会收到重复的确认。对重复的确认的处理很简单:收下后就丢弃。B仍旧会收到重复的M1。而且同样要丢弃重复的 M1。并重传确认分组。
[*]一连ARQ协议
进步ARQ的信道利用率 https://i-blog.csdnimg.cn/img_convert/6bf5126fe89fde28927493b0447d0ee6.jpeg
[*]接收方累积确认
[*]接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的末了一个分组发送确认，这就表现:到这个分组为止的所有分组都己精确收到了。
[*]优点：容易实现
[*]缺点：假如发送方发了前5个分组，接收方第3个分组丢失。则返回确认号是3，此时，第3、第4、第5分组都需要重新发送（尽管第4、第5分组接收方收到了）。
[*]发送方滑动窗口
[*]一连ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。
[*]假如收到3个分组的确认，则窗口移动3位。
b.滑动窗口下，TCP可靠传输的实现
[*]以字节为单位的滑动窗口
[*]TCP 的滑动窗口是以字节为单位的。
[*]现假定A收到了B发来的确认报文段，此中窗口是20字节，而确认号是31(这表明B期望收到的下一个序号是31，而序号30为止的数据己经收到了)。根据这两个数据，A就构造出本身的发送窗口。 https://i-blog.csdnimg.cn/img_convert/e98a7e1532d4347f7c6b9fa503e5c24e.jpeg
[*]发送窗口表现:在没有收到B的确认的环境下，A可以一连把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。
[*]发送窗口里面的序号表现允许发送的序号。显然，窗口越大，发送方就可以在收到对 方确认之前一连发送更多的数据，因而可能获得更高的传输服从。但是，A的发送窗口一定不能凌驾 B的接收窗口数值。（还要考虑网络拥塞问题）
[*]滑动窗口与可靠传输 https://i-blog.csdnimg.cn/img_convert/7af7057646d73b5a51dccc04fca46d7f.jpeg
发送端的黑色方框：已经发送；接收端黑色方框：已经接收（不一定按序）。
[*]第一阶段：
[*]发送方：发送了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实现流量控制
流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。
用滑动窗口实现流量控制
https://i-blog.csdnimg.cn/img_convert/ee56319ef99779eb5a4efa7ae85c033f.jpeg
[*]接收方的主机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.拥塞控制所起的作用
https://i-blog.csdnimg.cn/img_convert/e28b5687b323e0f005eb39e3049fabdc.jpeg
[*]无拥塞控制环境：
[*]当网络的吞吐量明显地小于理想的吞吐量时，网络就进入了轻度拥塞的状态。
[*]当提供的负载到达某一数值时，网络的吞吐量反而随提供的负载的增大而降落，这时网络就进入了拥塞状态。
[*]。当提供的负载继续增大到某一数值时，网络的吞吐量就降落到零，网络己无法工作，这就是所谓的死锁。
[*]理想的拥塞控制
[*]理想吞吐量大于负载时，没有拥塞。发送多少分组吞吐量就是多大。
[*]负载大于理想吞吐量时，以最大吞吐量发送分组。
[*]实际的拥塞控制
[*]如图
[*]避免死锁
b.TCP的拥塞控制方法
慢开始 、拥塞避免、快重传、快恢复（留意：由发送方控制，接收方仅恢复确认号）
1）慢开始和拥塞避免
https://i-blog.csdnimg.cn/img_convert/2debf29df1f41c24b46fd76faeea5575.jpeg
拥塞控制也叫做基于窗口的拥塞控制。为此，发送方维持一个叫做拥塞窗口 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的可靠传输是靠“超时重传”提供的，现在，由于引入网络拥塞控制，只要超时，就认为出现了网络拥塞。因此，除非出现网络拥塞环境，正常丢包环境我们是不希望超时！！！因此，引入快重传
https://i-blog.csdnimg.cn/img_convert/a5df291b432acd06b829262ea4501361.jpeg
[*]快重传算法
[*]快重传算法可以让发送方尽早知道发生了个别报文段的丢失。
[*]快重传算法首先要求接收方不要等待本身发送数据时才举行捎带确认，而是要立刻发送确认，纵然收到了失序的报文段也要立刻发出对己收到的报文段的重复确认。
[*]表现图 https://i-blog.csdnimg.cn/img_convert/6b1e4b6af59479627b201e513e51c3b5.jpeg
[*]接收方收到了M1和M2后部门别实时发出了确认。
[*]假定接收方没有收到M3但却收到了M4。（本来什么都不需要做，等待超时重传<等待一个M2确认>即可。但此时不能再使其超时）
[*]按照快重传算法，接收方必须立刻发送对M2的重复确认，以便让发送方及 早知道接收方没有收到报文段M3.
[*]快重传算法规定，发送方只要一连收到 3 个重复确认，就知道接收方确实没有收到报文段M3因而应当立刻举行重传(即“快重传”，这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。
[*]因此，发送方共收到4个对M2的确认。
[*]快恢复算法 https://i-blog.csdnimg.cn/img_convert/abbdfcf4cf4ab9e83b12f3c9a14d6681.jpeg
[*]传输轮次为20时，发出3个ACK。
[*]此时，重新置ssthresh = cwnd(传输轮次20)/2 = 16/2 = 8
[*]同时，设置拥塞窗口cwnd=ssthresh=8，并开始实行“避免拥塞”算法。
[*]有时，设置cwnd=ssthresh + 3 x MSS （由于:既然发送方收到 3 个 重复的确认，就表明有 3 个分组已经脱离了网络。）
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]