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,留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时,就知道了客户进程所使用的动态端口号。通信结束后,这个端口号可供其他客户进程以后使用。
端口号只具有本地意义,即端口号只是为了标识本计算机应用层中的各进程,在因特网中,不同计算机中的相同端口号是没有联系的。
发送方的复用和接收方的分用
5.3UDP和TCP的对比
UDP和TCP是TCP/IP体系结构运输层中的两个重要协议
用户数据报协议UDP:
1)无连接的;
2)UDP支持一对一、一对多、多对一、多对多的交互通信(单播 广播 多播);
3)面向报文的;
4)使用尽最大努力交付,即不保证可靠交付;
5)UDP没有拥塞控制;
6)UDP首部开销小;(只有8个字节,比TCP首部20字节的首部要短)
传输控制协议TCP:
1)面向连接的;
2)每一条TCP连接只能有两个端点,每一条TCP连接只能是点对点(一对一)的(TCP仅支持单播);
3)面向字节流;
4)提供全双工通信;(在实际网络中,基于TCP连接的两端,可以同时进行TCP报文段的发送和接收)
5)提供可靠交付的服务;(可靠传输,使用流量控制和拥塞控制)
5.4TCP的流量控制
一般来说,我们总是希望数据传输得快一些,但如果发送方把数据发送得过快,接收方就可能来不及接收,这就会造成数据的丢失。
所谓流量控制,就是让发送方的发送速率不要太快,要让接收方来得及接收。
利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制:
TCP接收方利用自己的接收窗口大小来限制发送方发送窗口的大小。
TCP发送方收到接收方的零窗口通知后,应启动持续计时器。持续计时器超时后,向接收方发送零窗口探测报文。
5.5TCP的拥塞控制
在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络性能就要变坏。这种情况就叫做拥塞。
在计算机网络中的链路容量(即带宽)、交换结点中的缓存和处理机等,都是网络的资源。
若出现拥塞而不进行控制,整个网络的吞吐量将随输入负荷的增大而下降。
TCP的四种拥塞控制算法
①慢开始 ②拥塞避免 ③快重传 ④快恢复
假定如下条件:
数据是单方向传送,而另一个方向只传送确认;接收方总是有足够大的缓存空间,因而发送方发送窗口的大小由网络的拥塞程度来决定;以最大报文段MSS的个数为讨论问题的单位,而不是以字节为单位。
传输轮次是指发送方给接收方发送数据报文段后,接收方给发送方发回相应的确认报文段。一个传输轮次所经历的时间其实就是往返时间。(往返时间并非是恒定的数值)使用传输轮次是为了强调把拥塞窗口所允许发送的报文段都连续发送出去并收到了对已发送的最后一个报文段的确认。
1990年又增加了两个新的拥塞控制算法(改进TCP的性能),这就是快重传和快恢复。
有时,个别报文段会在网络中丢失,但实际上网络并未发生拥塞,这将导致发送方的超时重传,并误认为网络发生了拥塞。发送方把拥塞窗口的cwnd又设置为最小值1,并错误的启动慢开始算法,因而降低了传输效率。
采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。
所谓快重传,就是使发送方尽快进行重传,而不是等超时重传计时器超时再重传:
要求接收方不要等待自己发送数据时才进行捎带确认,而是要立即发送确认;
即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认;
发送方一旦收到3个连续的重复确认,就将相应的报文段立即重传,而不是等该报文段的超时重传计时器超时再重传;
快恢复:
发送方一旦收到3个重复确认,就知道现在只是丢失了个别的报文段。于是不启动慢开始算法,而执行快恢复算法:
发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半;开始执行拥塞避免算法。也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些,即等于新的ssthresh +3;
既然发送方收到3个重复的确认,就表明有3个数据报文段已经离开了网络; 这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中; 可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口扩大些。
5.6TCP超时重传时间的选择
TCP的发送方在规定时间内没有收到确认就要重传已发送的报文段,重传时间的选择是TCP最复杂的问题之一。
由于TCP的下层是互联网环境,发送的报文段可能只经过一个高速率的局域网,也可能经过多个低速率的网络,并且每个IP数据报所选择的路由还可能不同。如果把超时重传时间设置的太短,就会引起很多报文的不必要重传,使网络负荷增大。但若把超时重传时间设置的过长,则又使网络的空闲时间增大,降低了传输效率。
往返时间RTT测量比较复杂
针对出现超时重传时无法测准往返时间RTT的问题,Karn提出来一个算法:在计算加权平均往返时间RTTs时,只要报文段重传了,就不采用其往返时间RTT样本。也就是出现重传时,不重新计算RTTs,进而超时重传时间RTO也不会重新计算。
这又引起了新的问题。设想出现这样的情况:报文段的时延突然增大了很多,并且之后很长一段时间都会保持这种时延。因此在原来得出的重传时间内,不会收到确认报文段。于是就重传报文段。但根据Karn算法,不考虑重传的报文段的往返时间样本。这样,超时重传时间就无法更新。这会导致报文段反复被重传。
因此,要对Karn算法进行修正。方法是:报文段每重传一次,就把超时重传时间 RTO增大一些。典型的做法是将新RTO的值取为旧RTO值的2倍。
5.7TCP可靠传输的实现
TCP基于以字节为单位的滑动窗口来实现可靠传输
虽然发送方的发送窗口是根据接收方的接收窗口设置的,但在同一时刻,发送方的发送窗口并不总是和接收方的接收窗口一样大:
网络传送窗口值需要经历一定的时间滞后,并且这个时间还是不确定的。发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。
对于不按序到达的数据应如何处理,TCP并无明确规定:
如果接收方把不按序到达的数据一律丢弃,那么接收窗口的管理将会比较简单,但这样做对网络资源的利用不利,因为发送方会重复传送较多的数据。TCP通常对不按序到达的数据是先临时存放在接收窗口中,等到字节流中所缺少的字节收到后,再按序交付上层的应用进程。
TCP要求接收方必须有累积确认和捎带确认机制,这样可以减小传输开销。接收方可以在合适的时候发送确认,也可以在自己有数据要发送时把确认信息顺便捎带上:
接收方不应过分推迟发送确认,否则会导致发送方不必要的超时重传,这反而浪费了网络的资源。TCP标准规定,确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段,则必须每隔一个报文段就发送一个确认[RFC 1122]。捎带确认实际上并不经常发生,因为大多数应用程序很少同时在两个方向上发送数据。
TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此,每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时,一定要弄清楚是哪一方的窗口。
5.8.1TCP的运输连接管理-TCP的连接建立
TCP是面向连接的协议,它基于运输连接来传送TCP报文段。
TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。
TCP运输连接有以下三个阶段:
①建立TCP连接("三报文握手");
②数据传送(基于已建立的TCP连接进行可靠的数据传输);
③释放TCP连接("四报文挥手");
TCP的运输连接管理就是使运输连接的建立和释放都能正常地运行。
TCP的连接建立要解决以下三个问题:
①使TCP双方能够确知对方的存在;
②使TCP双方能够协商一些参数(如最大窗口、是否使用窗口扩大选项和时间戳选项以及服务质量等);
③使TCP双方能够对运输实体资源(如缓存大小、连接表中的项目等)进行分配。
TCP使用"三报文握手"建立连接:
注意:TCP的标准规定,SYN=1的报文段不能携带数据,但要消耗掉一个序号。而普通的确认报文段如果不携带数据,则不消耗数据。在这种情况下,下一个数据报文段的序号seq仍是x+1。
发送TCP连接请求的确认的确认是否多余?能否采用两报文握手?
不多余,这是为了防止已经失效的连接请求报文突然又传到了TCP服务器因而导致错误,浪费资源。
5.8.2TCP的运输连接管理-TCP的连接释放
TCP通过"四报文挥手"来释放连接。
注意:TCP规定终止位FIN等于1的报文段即使不携带数据,也要消耗掉一个序号。
时间等待计时器设置的2MSL。
时间等待状态以及处于该状态2MSL时长,可以确保TCP服务器进程可以收到最后一个TCP确认报文段而进入关闭状态。
另外,TCP客户进程在发送完最后一个TCP确认报文段后,再经过2MSL时长,就可以使本次连接持续时间内所产生的所有报文段都从网络中消失,这样就可以使下一个新的TCP连接中,不会出现旧连接中的报文段。
TCP中保活计时器的作用:
5.9TCP报文段的首部格式
为了实现可靠传输,TCP采用面向字节流的方式。
但TCP在发送数据时,是从发送缓存取出一部分或全部字节并给其添加一个首部使之成为TCP报文段后进行发送:一个TCP报文段由首部和数据载荷两部分构成;TCP的全部功能都体现在它首部中各自段的作用。
数据偏移字段以4字节为单位。IPV4中片偏移字段以8字节为单位。
①源端口:占16比特,写入源端口号,用来标识发送该TCP报文段的应用进程。
②目的端口:占16比特,写入目的端口号,用来标识接收该TCP报文段的应用进程。
③序号:占32比特,取值范围0~(2^32)-1,序号增加到最后一个后,下一个序号就又回到0。序号字段的值用来指出本TCP报文段数据载荷的第一个字节的序号。
④确认号:占32比特,取值范围0~(2^32)-1,确认号增加到最后一个后,下一个确认号就又回到0。确认号字段的值用来指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号,同时也是对之前收到的所有数据的确认。
若确认号=n,则表明到序号n-1为止的所有数据都已正确接收,期望接收序号为n的数据。
⑤确认标志位ACK:取值为1时确认号字段才有效,取值为0时确认号字段无效。TCP规定,在连接建立后所有传送的TCP报文段都必须把ACK置1。
⑥数据偏移:占4比特,以4字节为单位。用来指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远。这个字段实际上是指出了TCP报文段的首部长度。首部固定长度为20字节,因此数据偏移字段的最小值为(0101)二进制。首部最大长度为60字节,因此数据偏移字段最大值为二进制1111。
⑦保留字段:占6比特,保留为今后使用,目前应置为0。
⑧窗口字段:占16比特,以字节为单位,指出发送本报文段的一方的接收窗口。窗口值作为接收方让发送方设置其发送窗口的依据。这是以接收方的接收能力来控制发送方的发送能力,称为流量控制。
⑨校验和:占16比特,检查范围包括TCP报文段的首部和数据载荷两部分。在计算校验和时,要在TCP报文段的前面加上12字节的首部。
⑩同步标志位SYN:在TCP建立时用来同步序号。
终止标志位FIN:用来释放TCP连接。
复位标志RST:用来复位TCP连接。当RST=1时,表明TCP连接出现了异常,必须释放连接,然后再重新建立连接。RST置1还用来拒绝一个非法的报文段或拒绝打开一个TCP连接。
推送标志位PSH:接收方的TCP收到该标志位为1的报文段会尽快上交应用进程,而不必等到接收缓存都填满后再向上交付。
紧急标志位URG:取值为1时紧急指针字段有效,取值为0时紧急指针字段无效。
11)紧急指针:占16比特,以字节为单位,用来指明紧急数据的长度。当发送方有紧急数据时,可将紧急数据插队到发送缓存的最前面,并立刻封装到一个TCP报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据,紧急数据之后是普通数据。
12)选项:最大报文长度选项MSS选项:TCP报文段数据载荷部分的最大长度;窗口扩大选项:为了扩大窗口(提高吞吐率);时间戳选项:用来计算往返时间,用于处理序号超范围情况,又称为防止序号绕回PAWS;选择确认选项:用来实现选择确认功能。
13)填充:由于选项的长度可变,因此使用填充来确保报文段首部能被4整除(因为数据偏移字段,也就是首部长度字段,是以4字节为单位的)。
运输层完结 一觉醒来天塌了 我笔记里的字怎么都自动变大了 怎么搞怎么搞😱😱😱 啊啊啊今天不撒花