概述
5.1运输层概述
物理层、数据链路层、网络层解决主机到主机之间的通信
通信的真正实体是位于通信两端主机中的进程
如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务,运输层协议又称为端到端协议。
运输层直接为应用进程间的逻辑通信提供服务
运输层向高层用户屏蔽了下面网络核心的细节(如网络拓扑、所采用的路由选择协议等),它使应用进程看见的就好像是在两个运输层实体之间有一条端到端的逻辑通信信道。
根据应用需求的不同,因特网的运输层为应用层提供了两种不同的运输协议,即面向连接的TCP和无连接的UDP
5.2 运输层端口号、复用与分用的概念
- 运行在计算机上的进程使用进程标识符PID来标志。
- 因特网上的计算机并不是使用统一的操作系统,不同的操作系统(windows,Linux,Mac OS)又使用不同格式的进程标识符。
- 为了使运行不同操作系统的计算机的应用进程之间能够进行网络通信就必须使用统一的方法对TCP/IP体系的应用进程进行标识。
- TCP/IP体系的运输层使用
端口
号来区分应用层的不同应用进程。 - 端口号使用16比特表示,取值范围0~65535;
- 熟知端口号:0~1023,IANA把这些端口号指派给了TCP/IP体系中最重要的一些应用协议,例如:FTP使用21/20,HTTP使用80,DNS使用53。
- 登记端口号:1024~49151,为没有熟知端口号的应用程序使用。使用这类端口号必须在IANA按照规定的手续登记,以防止重复。例如:Microsoft RDP微软远程桌面使用的端口是3389。
- 短暂端口号:49152~65535,留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时,就知道了客户进程所使用的动态端口号。通信结束后,这个端口号可供其他客户进程以后使用。
- 端口号只具有本地意义,即端口号只是为了标识本计算机应用层中的各进程,在因特网中,不同计算机中的相同端口号是没有联系的。
发送方的复用和接收方的分用
发送方应用进程发送的不同应用报文
在运输层如果用UDP协议封装,称为UDP复用,封装成UDP用户数据报
在运输层如果用TCP协议封装,称为TCP复用,封装成TCP报文段
运输层使用端口号区分不同的应用进程
在网络层,UDP用户数据报和TCP报文段都是用IP协议封装成IP数据报
,称为IP复用
IP数据报首部中小协议字段的值,用来表明IP数据报的数据载荷部分封装的是何种协议数据单元
协议字段=6
:表示IP数据报的数据载荷部分封装的是TCP报文段
协议字段=17
:表示IP数据报的数据载荷部分封装的是UDP用户数据报
接收方的网络层收到IP数据报后进行IP分用
协议字段=6
:将IP数据报的数据载荷部分封装的TCP报文段上交给运输层的TCP
协议字段=17
:将IP数据报的数据载荷部分封装的UDP用户数据报上交给运输层的UDP
运输层对UDP用户数据报进行UDP分用
运输层对TCP报文段进行TCP分用
也就是根据端口号将他们交付给上层的应用进程
TCP/IP体系的应用层常用协议所使用的运输层熟知端口号
举例:输入网址到得到网页的过程
用户PC,DNS服务器,web服务器通过交换机互联,处于同一个以太网中,web服务器有一个域名,DNS服务器记录该域名的IP地址,我们在用户PC中使用浏览器访问web服务器的内容。客户端跟服务端交互不认域名,认IP地址
当我们在浏览器输入网址,首先会查询本地DNS缓存有没有对应域名的IP地址,如果没有,用户PC中的DNS客户端进程
会发送一个DNS查询请求报文
DNS查询请求报文则会通过运输层的UDP协议,封装成一个UDP用户数据报
(请求域名的IP地址),随机生成一个数据报首部源端口(短暂端口号:49152~65535之间选择未被占用的
),用来表示DNS客户端进程
.数据报首部目的端口是DNS的端口53(53是DNS服务端进程
使用的熟知端口号)
UDP用户数据报加上IP头后封装成IP数据报
通过以太网传送给DNS服务器,DNS服务器端收到该数据报后,解封出UDP用户数据报,因为UDP用户数据报的首部中目的端口的值是53,这表明应该将UDP用户数据报的数据载荷部分(也就是DNS查询请求报文)交付给本服务器中的DNS服务器进程。DNS服务器进程解析DNS查询请求报文的内容,然后按要求查找对应的IP地址
然后,DNS服务器进程给用户PC发送DNS响应报文
,DNS响应报文使用运输层的UDP协议,封装成一个UDP用户数据报
,然后封装在IP数据报中,通过以太网发送给用户PC。
用户PC收到该数据报后,从中解析出UDP用户数据报,根据udp用户数据报首部中的目的端口号49152将udp用户数据报的数据载荷部分发送给DNS客户端进程
,DNS客户端进程解析DNS响应报文的内容,就能知道自己之前请求的web服务器的域名所对应的IP地址192.168.0.3
拿到IP地址后,用户PC的HTTP客户端进程
就可以向web服务器发送HTTP请求报文
,将请求报文使用TCP协议封装成TCP请求报文段,首部中的源端口也是随机生成的(短暂端口号:49152~65535之间选择未被占用的
),用来表示HTTP客户端进程。目的端口是80,这是HTTP服务端进程
的熟知端口号
之后,将TCP报文段封装在IP数据报中,通过以太网发送给web服务器,web服务器收到该数据报后,从中解封出TCP报文,根据目的端口号80,将该TCP报文段的数据载荷部分(也就是HTTP请求报文)交付给本服务器中的http服务器端进程
.http服务器端进程解析HTTP请求报文的内容,然后按其要求查找首页内容
之后,给用户PC发送HTTP响应报文
,其内容是HTTP客户端请求的首页内容,通过运输层的TCP协议封装成TCP报文段,之后将TCP报文段封装在IP数据报中,通过以太网传送给用户PC,用户PC解封出TCP报文段,根据目的端口号将TCP报文段的数据载荷部分发给http客户端进程
http客户端进程解析http响应报文段的内容,并在网页浏览器中显示
5.3TCP和UDP的区别
见参考文https://blog.csdn.net/ningmengshuxiawo/article/details/115413766
5.4 TCP的流量控制
一般来说,我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快,接收方就可能来不及接收,这就会造成数据的丢失。所谓流量控制
(flow control)就是让发送方的发送速率不要太快,要让接收方来得及接收。利用滑动窗口
机制可以很方便地在TCP连接上实现对发送方的流量控制。
死锁:
零窗口探测报文段丢失还能打破死锁的局面吗?
能,因为零窗口探测报文段也有重传计时器,重传计时器超时后,零窗口探测报文段会被重传
小结
利用滑动窗口机制
可以很方便地在TCP连接上实现对发送方的流量控制
。
TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小。
TCP发送方收到接收方的零窗口通知后,应启动持续计时器。持续计时器超时后,向接收方发送零窗口探测报文。
5.5拥塞控制
“慢开始”是指一开始向网络注入的报文段少,并不是指拥塞窗口cwnd增长速度慢;
“拥塞避免”并非指完全能够避免拥塞,而是指在拥塞避免阶段将拥塞窗口控制为按线性规律增长,使网络比较不容易出现拥塞;
慢开始
和拥塞避免
算法是1988年提出的TCP拥塞控制算法(TCP Tahoe版本)。
1990年又增加了两个新的拥塞控制算法(改进TCP的性能),这就是快重传
和快恢复
(TCP Reno版本)。
有时,个别报文段会在网络中丢失,但实际上网络并未发生拥塞。这将导致发送方超时重传,并误认为网络发生了拥塞;发送方把拥塞窗口cwnd又设置为最小值1,并错误地启动慢开始算法,因而降低了传输效率。
采用快重传
算法可以让发送方尽早知道发生了个别报文段的丢失。
所谓快重传,就是使发送方尽快进行重传,而不是等超时重传计时器超时再重传。要求接收方不要等待自己发送数据时才进行捎带确认,而是要立即发送确认;即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
发送方一旦收到3个连续的重复确认,就将相应的报文段立即重传,而不是等该报文段的超时重传计时器超时再重传。
发送方重传M3,接收方收到M3后,给发送方发回针对M6报文段的确认,表明M6之前的报文段都正确接收了
对于个别丢失的报文段,发送方不会出现超时重传,也就不会误认为出现了拥塞(进而降低拥塞窗口cwnd为1)。使用快重传可以使整个网络的吞吐量提高约20%。
快恢复
发送方一旦收到3个重复确认,就知道现在只是丢失了个别的报文段。于是不启动慢开始算法,而执行快恢复算法;
- 发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半;开始执行拥塞避免算法。
- 也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些,即等于新的ssthresh + 3。
- 既然发送方收到3个重复的确认,就表明有3个数据报文段已经离开了网络;这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中;可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口扩大些。
注意下图红框中快恢复阶段使用的是拥塞避免算法,拥塞窗口的值线性加1
5.6超时重传时间的选择
5.7 TCP可靠传输的实现
5.8.1 TCP连接建立
TCP的连接建立要解决以下三个问题:
使TCP双方能够确知对方的存在;
使TCP双方能够协商一些参数(如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等);
使TCP双方能够对运输实体资源(如缓存大小、连接表中的项目等)进行分配。
三次握手的过程
服务器端首先创建传输可控制块,包含以下内容
SYN=1表示这是一个TCP连接请求报文段
为什么不能是两次握手?
小结
5.8.2 TCP连接释放
TCP服务器进程
TCP客户端进程
为什么要经过2MSL?
保活计时器
小结
5.9 TCP报文段的首部格式
源端口:占16比特,写入源端口号,用来标识发送该TCP报文段的应用进程。
目的端口:占16比特,写入目的端口号,用来标识接收该TCP报文段的应用进程。
序号:占32比特,取值范围[0,232 -1],序号增加到最后一个后,下一个序号就又回到0。
指出本TCP报文段数据载荷的第一个字节的序号。
确认号:占32比特,取值范围[0,232-1],确认号增加到最后一个后,下一个确认号就又回到0。
指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号,同时也是对之前收到的所有数据的确认。
若确认号=n,则表明到序号n-1为止的所有数据都已正确接收,期望接收序号为n的数据。
确认标志位ACK:取值为1时确认号
字段才有效;取值为0时确认号字段无效。
TCP规定,在连接建立后所有传送的TCP报文段都必须把ACK置1
数据偏移:占4比特,并以4字节为单位。用来指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远。
保留:占6比特,保留为今后使用,但目前应置为0。
窗口:占16比特,以字节为单位。指出发送本报文段的一方的接收窗口。
窗口值作为接收方让发送方设置其发送窗口的依据。
这是以接收方的接收能力来控制发送方的发送能力,称为流量控制。
校验和:占16比特,检查范围包括TCP报文段的首部和数据载荷两部分。
在计算校验和时,要在TCP报文段的前面加上12字节的伪首部。
终止标志位FIN:用来释放TCP连接。
复位标志位RST:用来复位TCP连接。
当RST=1时,表明TCP连接出现了异常,必须释放连接,然后再重新建立连接。
RST置1还用来拒绝一个非法的报文段或拒绝打开一个TCP连接。
推送标志位PSH: 接收方的TCP收到该标志位为1的报文段会尽快上交应用进程,
而不必等到接收缓存都填满后再向上交付。
紧急标志位URG:取值为1时紧急指针字段有效;取值为0时紧急指针字段无效。
紧急指针:占16比特,以字节为单位,用来指明紧急数据的长度。
最后
以上就是大意面包为你收集整理的计算机网络课程学习笔记(第五章)运输层的全部内容,希望文章能够帮你解决计算机网络课程学习笔记(第五章)运输层所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复