博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
计算机网络学习4传输层
阅读量:4089 次
发布时间:2019-05-25

本文共 6296 字,大约阅读时间需要 20 分钟。

传输层最重要的两个主要协议就是TCP和UDP。TCP提供可靠的通信传输,UDP常用于让广播和细节控制交给应用的通信传输。要根据通信的具体特征,选择合适的传输层协议。TCP比UDP复杂得多,TCP的各种机制,如面向连接的可靠服务、流量控制、拥塞控制等,以及TCP连接管理和状态图等,必须非常熟。运输层为应用进程之间提供端到端的逻辑通信(不同于网络层,网络层是为主机之间提供逻辑通信)。运输层向高层用户屏蔽了下面网络核心的细节(如网络拓扑、所采用的路由选择协议等),它使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道。

1、运输层的两个主要协议:

(1) 用户数据报协议 UDP(User Datagram Protocol)

(2) 传输控制协议 TCP(Transmission Control Protocol)

几个名词:两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元 TPDU (Transport Protocol Data Unit)。TCP 传送的数据单位协议是 TCP 报文段(segment),UDP 传送的数据单位协议是 UDP 报文或用户数据报。 

2、TCP和UDP的区别和比较:

1、基于连接与无连接。
2、TCP要求系统资源较多,UDP较少。
3、UDP程序结构较简单。
4、流模式(TCP)与数据报模式(UDP)。
5、TCP保证数据正确性,UDP可能丢包。
6、TCP保证数据顺序,UDP不保证。
7、TCP面向连接(如打电话要先拨号建立连接);UDP是无连接的,即发送数据之前不需要建立连接。
8、TCP提供可靠的服务。也就是说,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达;UDP尽最大努力交付,即不保证可靠交付。
9、TCP面向字节流,实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的,UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如IP电话,实时视频会议等)。
10、每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信。

11、TCP首部开销20字节;UDP的首部开销小,只有8个字节。

12、TCP的逻辑通信信道是全双工的可靠信道,UDP则是不可靠信道。

3、端口

在运输层中,通信的真正端点不是主机而是主机中的进程。在一个主机中经常有多个应用进程分别和另一个主机中的多个应用进程通信。为了解决这个问题,运输层有一个重要的功能:复用和分用。前者指的是发送方不同的应用进程都可以使用同一个运输层协议传送数据(当然要加上合适的首部),而分用指接收方运输层在剥去报文的首部后能够把这些数据正确交付到对应应用进程中。因此,给应用层的每个应用赋予一个明确的标志是非常重要的。但是这又带来两个问题:第一,在因特网上不同的操作系统上的应用很多,而不同的操作系统使用不同格式的进程标识符;第二,进程的创建和撤销都是动态的,通信的一方几乎无法识别对方机器上的进程。因此,必须使用一种统一的方法对tpc/ip体系中的应用进程进行标志。这就是协议端口号(简称端口)。注意这里端口号是抽象的协议端口号,不是交换机或者路由器的硬件端口。我们只需要把报文传送到目的主机一个合适的目的端口,剩下的工作(即交付给进程)就有tcp来完成。端口号有16位。由于计算机通信采用客户-服务器模式,因此端口号有两种:

(1)服务器端使用的端口号

这里又分为两类:

1)熟知端口号(又叫系统端口号)

数值一般为0-1023,这些端口号被指派给了tcp/ip中最重要的一些应用程序,让所有用户都知道。没有这个端口号的话无法通信。

2)登记端口号

1024-49151,为给没有熟知端口号的程序使用。必须登记才能使用。

(2)客户端使用的端口号(又叫短暂端口号)

留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时,就知道了客户进程所使用的动态端口号。通信结束后,这个端口号可供其他客户进程以后使用。

4、UDP

UDP 只在 IP 的数据报服务之上增加了很少一点的功能,即端口的功能(也就是复用和分用的功能)和差错检测的功能。

(1)UDP的特点

1)UDP 是无连接的,即发送数据之前不需要建立连接,因此减少了开销和发送数据之前的时延;

2)UDP 使用尽最大努力交付,即不保证可靠交付,因此主机不需要维持复杂的连接状态表;

3)UDP是面向报文的,也就是它对应用程序交下来的报文在添加首部后就向下交付给IP层;

4)UDP没有拥塞控制,因此网络的拥塞不会使源主机发送速率降低,这对IP电话、实时视频会议等要求源主机以恒定速率发送数据,并且允许拥塞时丢失一些数据,却不允许数据有大的时延的应用程序很合适;

5)UDP支持一对一、一对多、多对一和多对多的交互通信;

6)UDP的首部只有8个字节,比TCP的20个字节短,首部开销小。

(2)UDP格式:包含一个首部和伪首部

在计算检验和时,临时把“伪首部”和 UDP 用户数据报连接在一起。伪首部仅仅是为了计算检验和。他既不向下传送也不向上递交,只是为了计算检验和。

5、TCP

(1)TCP的特点

(2)TCP的端点

每一条 TCP 连接有两个端点。TCP 连接的端点不是主机,不是主机的IP 地址,不是应用进程,也不是运输层的协议端口。TCP 连接的端点叫做套接字(socket)或插口。端口号拼接到(contatenated with) IP 地址即构成了套接字。每一条 TCP 连接唯一地被通信两端的两个端点(即两个套接字)所确定。即:

套接字 socket = (IP地址: 端口号) 

TCP 连接 ::= {socket1, socket2} 

                = {(IP1: port1), (IP2: port2)}

注意,同一个IP地址或同一个端口可以有多个不同的TCP连接。另外,Socket有多个不同含义,下面这些含义都和这里的Socket,即端口号拼接到IP地址后面,不同。但是应用程序要使用TCP或UDP,需要用到操作系统提供的Socket API。

(3)可靠传输的工作原理

理想的可靠传输,无非是要有以下两个特点:

1)传输信道不产生差错

2)不管发送方以多快速度发送数据,接收方总是来得及处理收到的数据

为了实现这两点,有以下几种方法。注意,这里说的不是TCP使用的方法,而是一些实现可靠传输的思路。并没有考虑是哪个层次或哪个具体的协议。

1)停止等待协议

全双工通信事实上双发同时是发送方和接收方。但是这里为了方便讨论,A为发送方,B为接收方。停止等待意思就是每次发完一个分组就停止,等待对方确认,收到确认后再发送下一个分组。大致思路是,如果没有差错的情况下,每次B接收到就发送确认,A再发送。如果有差错,B就把收到的分组丢弃,然后不发送确认信息,A超时没有收到确认信息后,就重新发送一次。这个方法的缺点是信道的利用率太低。这种可靠传输协议常称为自动重传请求ARQ (Automatic Repeat reQuest)。ARQ 表明重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组 。

2)连续ARQ协议(流水线传输)

发送方可连续发送多个分组,不必每发完一个分组就停顿下来等待对方的确认。由于信道上一直有数据不间断地传送,这种传输方式可获得很高的信道利用率。 接收方一般采用累积确认的方式。即不必对收到的分组逐个发送确认,而是对按序到达的最后一个分组发送确认,这样就表示:到这个分组为止的所有分组都已正确收到了。累积确认有的优点是:容易实现,即使确认丢失也不必重传。缺点是:不能向发送方反映出接收方已经正确收到的所有分组的信息。例如,如果发送方发送了前 5 个分组,而中间的第 3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落,而只好把后面的三个分组都再重传一次。这就叫做 Go-back-N(回退 N),表示需要再退回来重传已发送过的 N 个分组。可见当通信线路质量不好时,连续 ARQ 协议会带来负面的影响。

(4)TCP报文段格式

下面就是TCP的三个很重要的点:可靠传输、流量控制、拥塞控制,要理解其工作原理

(5)TCP的可靠传输

1)以字节为单位的滑动窗口

窗口大小其实是指无需等待确认应答而可以继续发送数据的最大值。窗口有发送方的发送窗口和接收方的接收窗口。注意,发送方窗口大小是可以更改的,这视乎接收方发送回来的应答数据的要求,可以变大、不变、变小等。TCP不赞成让窗口变小的做法。在这里举得例子中,假设发送和接收窗口的大小都不变。这个机制需要使用大量的缓冲区。在这里,每个字节都给它编号。我们现在来详细分析它的工作过程。我们认为A是发送方,B是接收方

第一步:发送刚开始时。我们假定,31之前的数据已经发送完了,不管了。这个时候,根据B给出的窗口值,构造了一个发送窗口(大小为20)。发送窗口不允许收缩。

第二步:这个时候要开始发送数据了。这个时候,A就不断把数据发送出去,也不管其实没有收到确认。在这里,A已经把31-41发送出去了。这个时候,B也有一个接收窗口。B的接收窗口却只接收到了32和33,没有收到31(也许是滞留在网络的某处堵塞了,也许丢失了,谁知道呢)。这个32和33是未按序到达的数据。由于不是按顺序接收到的数据(正如上一幅图说的,此时B期望接收到的是31,现在却只有32和33),因此B不会给A发送确认。

第三步:现在假定,突然,B收到了31。与此同时,还收到了37,38和40。这个时候,B已经收到了31-33这个连续有序的数据了。B就发送确认信号34给A,让A知道,我已经收到了34之前的所有数据了。于是,A的发送窗口向前滑动3个单位,B的接收窗口也同样向前滑动3个单位。然后不断重复第一到第三步的过程。

第四步:A依旧不断发送数据,如果发送窗口满了,就不发送数据了。

第五步:如果A的发送窗口满了,又过了一段时间,仍然没有收到B的确认信号,那就认为B还没收到这些数据。于是就经过一段时间(由超时计时器控制)就重传这部分数据,并重新设置超时计时器,直到收到B的确认,让A的发送窗口继续向前滑动。至此,就是整个窗口滑动过程。

我们现在来分析A和B的缓存情况。窗口通常只是缓存的一部分。因为涉及到重新发送和把数据交给应用程序,因此:

2)超时重传

TCP
每发送一个报文段,就对这个报文段设置一次计时器。只要计时器设置的重传时间到但还没有收到确认,就要重传这一报文段。超时重传的时间是多少呢?这里不具体叙述,算法非常复杂。主要用的是Karn算法

(6)TCP的流量控制

一般说来,我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快,接收方就可能来不及接收,这就会造成数据的丢失。
流量控制
(flow control)
就是让发送方的发送速率不要太快,既要让接收方来得及接收,也不要使网络发生拥塞。
利用滑动窗口机制可以很方便地在
TCP
连接上实现流量控制。 
(7)TCP的拥塞控制
在某段时间,若对网络中某资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏
——
产生
拥塞
(congestion)
若网络中有许多资源同时产生拥塞,网络的性能就要明显变坏,整个网络的吞吐量将随输入负荷的增大而下降。拥塞控制和流量控制不一样:
拥塞控制是很难设计的,因为它是一个动态的(而不是静态的)问题。从大的方面看,拥塞控制的两种方法:

拥塞控制主要有四种算法:慢开始、拥塞避免、快重传、快恢复。

6、TCP的运输连接管理(这部分是重点中的重点!)。里面的各个位,可以参照前面TCP数据报的格式。

有三个阶段:连接建立、数据传送、连接释放

(1)连接建立。在这里,A是主动打开连接,B是被动打开连接。

TCP
连接的建立都是采用客户服务器方式。
主动发起连接建立的应用进程叫做
客户
(client)
被动等待连接建立的应用进程叫做
服务器
(server)
。 连接建立阶段使用的是三次握手,具体过程如下:
还有很重要的一点:

(2)连接释放

连接释放使用的是所谓四次挥手。

还有一个极端情况:

7、TCP的有限状态机

其实就是TCP所处于的各种状态以及进入路径

(1)CLOSED 状态时初始状态。

(2)LISTEN:被动打开,服务器端的 状态变为LISTEN(监听)。被动打开的概念:连接的一端的应用程序通知操作系统,希望建立一个传入的连接。这时候操作系统为连接的这一端建立一个连 接。与之对应的是主动连接:应用程序通过主动打开请求来告诉操作系统建立一个连接。

(3)SYNRECVD:服务器端收到SYN后,状态为SYN;发送SYN ACK;

(4)SYN_SENTY:应用程序发送SYN后,状态为SYN_SENT;

(5)ESTABLISHED:SYNRECVD收到ACK后,状态为ESTABLISHED; SYN_SENT在收到SYN ACK,发送ACK,状态为ESTABLISHED;

(6)CLOSE_WAIT:服务器端在收到FIN后,发送ACK,状态为CLOSE_WAIT;如果此时服务器端还有数据需要发送,那么就发送,直到数据发送完毕;此时,服务器端发送FIN,状态变为LAST_ACK;

(7)FIN_WAIT_1:应用程序端发送FIN,准备断开TCP连接;状态从ESTABLISHED——>FIN_WAIT_1;

(8)FIN_WAIT_2:应用程序端只收到服务器端得ACK信号,并没有收到FIN信号;说明服务器端还有数据传输,那么此时为半连接;

(9)TIME_WAIT:有两种方式进入 该状态:1、FIN_WAIT_1进入:此时应用程序端口收到FIN+ACK(而不是像FIN_WAIT_2那样只收到ACK,说明数据已经发送完毕)并 向服务器端口发送ACK;2、FIN_WAIT_2进入:此时应用程序端口收到了FIN,然后向服务器端发送ACK;TIME_WAIT是为了实现TCP 全双工连接的可靠性关闭,用来重发可能丢失的ACK报文;需要持续2个MSL(最大报文生存时间):假设应用程序端口在进入TIME_WAIT后,2个 MSL时间内并没有收到FIN,说明应用程序最后发出的ACK已经收到了;否则,会在2个MSL内在此收到ACK报文

8、除了TCP和UDP外的一些其他的传输层协议

(1)UDP-Lite(Lightweight User Datagram Protocol,轻量级用户数据报协议),是扩展UDP机能的一种协议,功能几乎与UDP一样,不同的是通过对校验和计算的改进,如果校验和出了错,它不一定像UDP一样要求重传整个数据报。它可以只针对不允许出错的部分进行校验和计算,如果是某些无关紧要的部分出了错,那就直接传给应用程序使用,不需要重传包,提高效率。

(2)DCCP(Datagram Congestion Control Protocol, 数据报拥塞控制协议),是一个辅助UDP的协议,使得UDP也可以有拥塞控制的作用。

(3)SCTP(Stream Control Transmission Protocol,流控制传输协议),与TCP一样是提供可靠性检查的运输层协议,支持多宿主和多个IP地址。

(参考:谢希仁《计算机网络》)

你可能感兴趣的文章
现在来看,做个普罗米修斯的docker镜像对我而言并不难,对PX4仿真环境配置也熟悉了。
查看>>
删除docker容器和镜像的命令
查看>>
gazebo似乎就是在装ROS的时候一起装了,装ROS的时候选择的是ros-melodic-desktop-full的话。
查看>>
React + TypeScript 实现泛型组件
查看>>
TypeScript 完全手册
查看>>
React Native之原理浅析
查看>>
Git操作清单
查看>>
基础算法
查看>>
前端面试
查看>>
React Hooks 异步操作踩坑记
查看>>
聊聊编码那些事,顺带实现base64
查看>>
TypeScript for React (Native) 进阶
查看>>
React 和 ReactNative 的渲染机制/ ReactNative 与原生之间的通信 / 如何自定义封装原生组件/RN中的多线程
查看>>
JavaScript实现DOM树的深度优先遍历和广度优先遍历
查看>>
webpack4 中的 React 全家桶配置指南,实战!
查看>>
react 设置代理(proxy) 实现跨域请求
查看>>
通过试题理解JavaScript
查看>>
webpack的面试题总结
查看>>
实践这一次,彻底搞懂浏览器缓存机制
查看>>
Koa2教程(常用中间件篇)
查看>>