【计算机网络】——运输层

举报
雪月清 发表于 2022/05/19 11:10:51 2022/05/19
【摘要】 详解TCP的三次握手、四次挥手具体过程及原理

 一、运输层概述

计算机网络体系结构中的物理层数据链路层以及网络层它们共同解决了将主机通过异构网络互联

起来所面临的问题,实现了主机到主机的通信

但实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程

为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务,运输层协议又称为端到端协

议。

运输层向高层用户屏蔽了下面网络核心的细节(如网络拓扑、所采用的路由选择协议等),它使应用

进程看见的就好像是在两个运输层实体之间有一条端到端的逻辑通信信道

根据应用需求的不同,因特网的运输层为应用层提供了两种不同的运输协议,即面向连接的TCP

无连接的UDP
 

二、端口号、复用、分用

2.1端口号

运行在计算机.上的进程使用进程标识符PID来标志。 

因特网上的计算机并不是使用统一的操作系统,不同的操作系统(windows, Linux, Mac OS)使用

同格式的进程标识符

为了使运行不同操作系统的计算机的应用进程之间能够进行网络通信,就必须使用统一的方法对

TCP/IP体系的应用进程进行标识。

TCP/IP体系的运输层使用端口号来区分应用层的不同应用进程。

端口号使用16比特表示,取值范围0~65535

  • 熟知端口号:0~1023,INNA把这些端口号指派给了TP/IP体系中最终要的一些协议,例如HTTP使用80,DNS使用53
  • 等级端口号:1024~49151,为没有熟知端口号的应用程序使用,使用这类端口号必须按照IANA规制的手续进行登记,以防止重复
  • 短暂端口号:49152~65535,留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时,就知道了客户进程所使用的动态端口号。通信结束后,这个端口号课供其他客户进程以后使用

端口号具有本地意义,及端口号只是为了标识本计算机应用层中的各进程,在因特网中,不同计算机中的相同端口号是没有联系的


2.2复用和分用

 TCP/IP体系的应用层常用协议所使用的运输层的端口号

 三、UDP与TCP

3.1UDP和TCP的对比

UDP是无连接的,TCP是面向连接的

传输数据的对比

对应用报文的处理对比

 

UDP对应用进程的应用报文既不合并也不拆分,是面向应用报文的

TCP将字节进行编号

UDP

 TCP

 UDP用户数据报首部与TCP数据报首部对比

3.2TCP的流量控制和拥塞控制

3.2.1流量控制

流量控制:控制发送发的发送速率,使得接受方能够接收不会造成数据丢失。

利用滑动窗口机制实现流量控制

 TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小。

seq是TCP报文段首部中的序号字段

seq的值表示TCP报文段数据载荷的第一个字节的序号

ACK是TCP首部中的标志位    ACK  = 1 表示这是一个TCP确认报文段

ack是TCP报文段首部中的确认号字段   取值表示此序号之前的数据已经全部正确接收

rwnd是TCP报文段首部中的窗口字段 取值表示自己的接受窗口大小

当发送窗口被调控为0时就不能发送数据了,这时候如果接受方发送的非零窗口的通知丢失了,就会发生死锁问题。使用持续计时器解决 

TCP发送方收到接收方的零窗口通知后,应启动持续计时器。持续计时器超时后,向接收方 TCP

发送零窗口探测报文。 

 即使接受窗口为0,也必须接收零窗口探测报文段、确认报文段、携带有紧急数据的报文段

当零窗口探测报文段丢失时,也会有重传计时器,若超时则重传

3.2.2拥塞控制

在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分网络性能就要变坏

这种情况就叫做拥塞

若出现拥塞而不进行控制,整个网络的吞吐量将随输入负荷的增大而下降。

 TCP拥塞控制的四种算法

慢开始、拥塞避免、快重传、快恢复

假定如下条件

1.数据是单方向传送,而另一个方向只传送确认。

2.接收方总是有足够大的缓存空间,因而发送方发送窗口的大小由网络的拥塞程度来决定。

3.以最大报文段MSS的个数为讨论问题的单位,而不是以字节为单位。
 

拥塞窗口cwnd   发送窗口swnd   慢开始门限ssthresh

 当重传计时器超时,则判断网络可能出现了拥塞,进行如下工作:

1.将ssthresh值更新为发生拥塞时cwnd值的一半

2.将cwnd值减少为1,并重新开始执行慢开始算法

 个别报文段会在网络中丢失,但实际上网络并未发生拥塞,这个时候执行拥塞避免算法,重新把拥塞窗口cwnd设置为1,会降低传输效率。

采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失

所谓快重传,就是使发送方尽快进行重传,而不是等超时重传计时器超时再重传。

要求接收方不要等待自己发送数据时才进行捎带确认,而是要立即发送确认

即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认

发送方一旦收到3个连续的重复确认,就将相应的报文段立即重传,而不是等该报文段的超时重传

计时器超时再重传。

对于个别的报文段,发送方不会出现超时重传,也就不会误以为出现了拥塞,使用快重传可以使整

个网络的吞吐量提高约20%

 发送方一旦收到3个重复确认,就知道现在只是丢失了个别的报文段。于是不启动慢开始算法

而执行快恢复算法

发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半 开始执行拥塞避免算

法。

也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些,即等于新的ssthresh + 3。

3.2.3TCP超时重传时间的选择

3.3TCP的运输连接管理

 TCP使面向连接的协议,它基于运输连接来传送TCP报文段

TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程

TCP连接有三个阶段

1.建立TCP连接

2.数据传送

3.释放TCP连接

TCP的运输连接管理就是使运输连接的建立和释放都能正常地进行

3.3.1TCP的连接建立

TCP使用“三次握手”建立连接

TCP规定SYN为1的报文段不能携带数据,但要消耗掉一个序号, 则前两次报文段不能携带数据,

是TCP连接请求确认报文段。第三个报文段是普通的TCP确认报文段可以携带数据,也可以不携带

若不携带则不消耗序号。

思考:使用两报文握手是否可以建立连接?

不能,因为假如一个失效的TCP连接请求延迟与TCP服务器建立连接,而此时TCP客户主机是处于连接关闭状态不会理会,则TCP服务器会一直处于连接已建立状态会浪费资源 


3.3.2TCP的通过“四次挥手”来释放连接

FIN终止位 

 第三个报文段的ack = u+1是对第一个报文段的重复确认,seq=w说明第二个报文段可能还有数据进行传输

思考:为什么TCP客户进程在发送完最后一个确认报文段后,为什么不直接关闭而是要等待2MSL时间后才关闭?

因为如果第四个报文段丢失,那么TCP服务器进程会一致进行TCP连接释放的超时重传,但是此时TCP客户进程已经关闭,导致TCP服务器进程一致无法关闭


 保活计时器


【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。