开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 网络协议 -> 计网第五章-运输层 -> 正文阅读

[网络协议]计网第五章-运输层

来源:学银在线计算机网络（第3期）高军湖南科技大学

物理层,数据链路层和网络层共同解决了主机通过异构网络互联起来所面临的问题,实现了主机到主机的通信
实际上计算机网络中进行通信的真正实体是位于通信两端主机中的进程
运输层的任务就是为运行在不同主机上的应用进程提供直接的通信服务
运输层协议,又称端到端协议
- 面向连接的TCP(Transmission Control Protocol)
- 无连接的的UDP(User Datagram Protocol)

运输层直接为应用进程间的逻辑通信提供服务:运输层向高层用户屏蔽了下面网络平核心的细节(如网络拓扑,所采用的路由选择协议等),是应用进程看见的就好像是在两个运输层实体之间有一条端到端的逻辑通信信道

1.端口号,复用与分用的概念

进程是由进程标识符PID来标识的,不同操作系统使用不同格式的进程标识符,为了使不同操作系统的进程能够进行网络通信,TCP/IP体系的运输层使用端口号来区分不同的应用进程

1.端口号

端口号使用16比特表示,取值范围0~65535
- 熟知端口号:0~1023,指派给TCP/IP体系中重要的协议:FTP使用21或20,HTTP使用80,DNS使用53
- 登记端口号:1024~49151,指派给没有熟知端口号的应用程序使用.使用这类端口号必须在IANA(The Internet Assigned Numbers Authority，互联网数字分配机构)按照规定登记,以防止重复.如:Microsoft RDP使用端口3389
- 短暂端口号:49152~65535,留给客户进程选择暂时使用.当服务器收到客户进程的报文时,就知道客户进程所使用的动态端口号.通信结束后,这个端口号可供其他客户进程以后使用
端口号只具有本地意义,不同计算机中的相同端口号是没有联系的

2.发送方的复用和接收方的分用

在这里插入图片描述

例子:

用户PC,DNS服务器,Web服务器通过交换机进行互联,假设Web服务器的域名是www.zyang.com,DNS服务器中记录有DNS所对应的IP地址(192.168.0.3 $\leftrightarrow$ www.zyang.com)
在用户PC中使用Web浏览器访问Web服务器中的内容,请求到响应的过程:

用户PC在Web浏览器中输入Web服务器的域名.
用户PC中的DNS客户端进程会发送一个DNS查询请求报文.
1. 请求的内容的大体上的意思是:域名www.zyang.com对应的IP地址是什么?
2. DNS查询请求报文需要使用运输层的UDP协议封装成UDP用户数据报:源端口的值在短暂端口号中挑选一个未被占用的用来表示DNS客户端进程,如49152,目的端口为53(DNS服务器端进程使用的熟知端口号)
3. 将UDP用户数据报封装成IP数据报进行发送(IP数据报如何传输的可看:计网第四章-网络层)
DNS服务器端根据收到的IP数据报,从中解封出UDP用户数据报
根据UDP用户数据报中的目的端口53,将DNS查询请求报文本服务器中的DNS服务器端进程
DNS服务器端进程根据DNS查询请求报文本里面的内容查找www.zyang.com对应的IP地址
查到IP地址后,DNS服务器端进程会给用户PC发送DNS响应报文
1. 相应报文的内容大体上的意思是域名www.zyang.com对应的IP地址是192.168.0.3
2. DNS响应报文需要使用运输层的UDP协议封装成UDP用户数据报:源端口的值为53(熟知端口号),目的端口为49152(封装了DNS查询请求报文的UDP用户数据报的源端口的值)
3. 将UDP用户数据报封装成IP数据报进行发送(IP数据报如何传输的可看:计网第四章-网络层)
用户PC中的端口号为49152的DNS客户端进程会解析DNS响应报文的内容,得到Web服务器端域名www.zyang.com对应的IP地址
用户PC向Web服务器发送HTTP请求报文
1. 内容意思是:首页内容是什么?
2. HTTP请求报文需要使用运输层的TCP协议封装成TCP报文段:源端口的值在短暂端口号中挑选一个未被占用的用来表示HTTP客户端进程,如49153,目的端口为80(HTTP服务器端进程使用的熟知端口号)
3. 将TCP报文段封装成IP数据报进行发送(IP数据报如何传输的可看:计网第四章-网络层)
Web服务器端根据收到的IP数据报,从中解封出TCP报文段
根据目的端口80,将HTTP请求报文交付给HTTP服务器端进程
HTTP服务器端进程根据请求的内容,查找到首页内容 ,并封装到HTTP响应报文里面
HTTP响应报文被封装成TCP报文段:源端口号为80,目的端口号为49153
将TCP报文段封装在IP数据报中发送给用户PC
用户PC根据收到的IP数据报,得到TCP报文段
根据目的端口49153,将HTTP响应报文提交给端口号为49153的HTTP客户端进程解析
进程根据解析的内容(首页内容),渲染到浏览器中

2.UDP和TCP的对比

UDP	TCP
无连接,通信双方可以随时发送数据	面向连接,发送数据前,需要通过三报文握手来建立连接,发送数据后还需四报文挥手来关闭连接
支持一对一(单播),一对多(多播),一对全(广播)	支持一对一(单播)
对应用层报文直接打包	面向字节流,将应用层报文看作是字节流,对字节客流的字节进行编号并且储存在TCP缓存中,之后将字节流分块打包成TCP报文段,收到TCP报文段后,将报文段里面的字节存到缓存中,同时将字节按顺序发送给应用层的进程
向上层提供无连接不可靠传输服务,适用于IP电话,视频会议等实时应用	可靠传输,使用的手段是流量控制和拥塞控制
首部开销小,仅8字节	首部最小20字节,最大60字节(比UDP多是因为需要实现可靠传输)

3.TCP的流量控制(Flow control)

一般来说,我们总是希望数据传输更快一些,但如果发送方把数据发送太快,接收方来不及接收,就会造成数据丢失
流量控制就是让发送方的发送速率不要太快,要让接收方来得及接收

TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小
可能导致死锁问题:当发送者收到了一个窗口为0的应答，发送者便停止发送，等待接收者的下一个应答。如果下一个这个窗口不为0的应答在传输过程丢失，发送者一直等待下去，而接收者以为发送者已经收到该应答，等待接收新数据，这样双方就相互等待，从而产生死锁。
- 解决:TCP发送方收到接收到的零窗口通知后,应启动持续计时器.持续计时器超时后,向接收方发送零窗口探测报文以询问接收方的接收窗口大小

4.TCP的拥塞控制

拥塞:某段时间内,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络性能就要变坏
- 网络资源:链路容量(即带宽),交换结点中的缓存和处理机等

在这里插入图片描述

慢开始和拥塞避免

TCP Tahoe版本
在这里插入图片描述

快重传

有时,个别报文段会在网络中丢失,但实际上网络并未发生拥塞,会错误的启动慢开始算法
为了避免这种情况,需要在超时计时器到时前对数据进行重传,就出现了快重传算法
在这里插入图片描述

快恢复

在这里插入图片描述
TCP Reno版本

在这里插入图片描述

5.TCP超时重传的选择

$RTT_S$ 表示为加权平均往返时间
$RTT_D$ 表示为RTT偏差的加权平均
RTO:超时重传时间
在这里插入图片描述

6.TCP的运输连接管理

1.TCP连接的建立(三报文握手)

要解决的问题:
- 使TCP双方能够确知对方的存在
- 使TCP双方能够协商一些参数(如最大窗口值,是否使用窗口扩大选项和时间戳选项以及服务质量等)
- 使TCP双方能够对运输实体资源(如缓存大小,连接表中的项目等)进行分配

在这里插入图片描述

两端TCP进程都处于关闭状态(CLOSED)
TCP服务器进程首先创建传输控制块,用来存储TCP中的一些重要信息,例如TCP连接表,指向发送和接收缓存的指针,指向重传队列的指针
TCP服务器进程准备接收TCP客户进程的连接请求,TCP服务器进程进入监听状态(LISTEN),等待TCP客户进程的连接请求(是被动等待,不能主动发起)
TCP客户进程创建传输控制块,在打算建立TCP连接时,向TCP服务器进程发送TCP连接请求报文段,并进入同步已发送状态(SYN-SENT)
TCP连接请求报文段:首部中的同步位SYN设置为1(表明这是一个TCP连接请求报文段,SYN=1的报文段不能携带数据,但要消耗掉一个序号),序号字段设置为一个初始值x(作为TCP客户进程所选择的初始序号)
TCP服务器进程收到TCP连接请求报文段后,如果同意建立连接,就发送针对TCP连接请求的确认,并进入同步已接收状态(SYN-RCVD)
TCP连接请求确认报文段(同步位SYN=1(不能携带数据,消耗掉一个序号)和确认位ACK=1),seq=y(作为TCP服务器进程所选择的初始值序号),确认号字段ack=x+1(对TCP客户进程所选择的初始序号的确认)
TCP客户进程收到TCP连接请求确认报文段后,还要向TCP服务器进程发送一个普通的TCP确认报文段,并进入连接已建立状态(ESTABLISHED)
普通的TCP确认报文段(可以携带数据,但如果不携带数据就不消耗序号):ACK=1,seq=x+1(TCP连接请求报文段已经消耗了一个序号),ack=y+1(对TCP服务器进程所选择的初始序号的确认)
TCP服务器进程收到这个报文段后已进入连接已建立状态(ESTABLISHED)
连接建立成功,基于建立的TCP连接,双方就可以进行数据传输了

为什么TCP客户进程还要发送一个普通的TCP报文段,这是否多余

在这里插入图片描述
TCP连接请求因为某些原因在网络中滞留了,触发了超时重传,而重传的这个连接请求是正常的,进行了正常的数据传输(连接建立成功,数据传输,连接关闭),如果这时候这个滞留的TCP连接请求到TCP服务器了,服务器针对这个TCP连接请求进行确认,进入连接已建立状态,由于TCP客户进程处于关闭状态,就对这个确认请求不做理会,这时服务器也不知TCP客户进程的请求,只会只要请求确认发出去后,连接建立成功了,就会一直等着客户进程发送数据过来,这样就会造成资源浪费

2.TCP的连接释放(四报文挥手)

在这里插入图片描述
FIN:终止位

FIN=1表示可以携带数据,但是必须消耗一个序号;suq=u表示客户进程已经发送u-1个TCP报文段;ack=v表示服务器进程已经发送v-1个报文段了
服务器进程返回一个普通的TCP确认报文段,表示TCP客户进程不能再向TCP服务器进程发数据了,但是还能接收数据

TCP客户进程在发送完最后一个确认报文后,为什么不直接进入关闭状态,而是进入时长为2MSL的时间等待状态
假设直接进入关闭状态,如果最后一个确认报文丢失了,就会导致服务器进程重传一个TCP连接释放报文段,但是这时客户进程已经处于关闭状态,就不予理会,不会发送确认报文段,就又会导致重传,进而导致一直重传,导致TCP服务器进程一直进入不了关闭状态,等待2MSL是为了服务器进程能够收到最后一个确认报文段