传输层的作用
传输层定义
IP首部中有一个协议字段，用来标识网络层(IP)的 上一层所采用的是哪一种传输层协议。根据这个字段的协议号，就可以识别IP传 输的数据部分究竟是TCP的内容，还是UDP的内容。
同样，传输层的TCP和UDP, 为了识别自己所传输的数据部分究竟应该发给 哪个应用，也设定了这样一个编号。
以包裹为例，邮递员(IP)根据收件人地址（目标IP地址）向目的地（计 算机）投递包裹(IP数据报）。包裹到达目的地以后由对方（传输层协议）根据 包裹信息判断最终的接收人（接收端应用程序）。
如果快递单上只写了家庭地址和姓氏，那该如何是好呢？你根本无法判断快 递究竟应该投递给哪一位家庭成员。同样，如果收件人地址是学校或公司，而 且也只写了一个姓氏，会给投递工作带来麻烦。因此，在日本的投递业务中都会 要求寄件人写清楚接收人的全名。其实在中国，一个人的姓氏不像日本那样复姓 居多，人们也通常不会仅以姓氏称呼一个人。但是也有一种特殊情况，那就是 如果一个收件地址中有多个同名同姓的接收者该怎么办？此时，往往会通过追加 电话号码来加以区分。
在TCP/IP的通信当中也是如此，需要指定“姓氏”，即“应用程序＂。而传 输层必须指出这个具体的程序，为了实现这一功能，使用端口号这样一种识别 码。根据端口号就可以识别在传输层上一层的应用层中所要进行处理的具体 程序。
通信处理
再以邮递包裹为例，详细分析一下传输层的协议工作机制。
前面提到的“应用程序”其实就是用来进行TCP/IP应用协议的处理。因此， TCP/IP中所要识别的＂姓氏”就可以被理解为应用协议。
TCP/IP的众多应用协议大多以客户端／服务端的形式运行。客户端，类似于 客户的意思，是请求的发起端。而服务端，则表示提供服务的意思，是请求的处 理端。另外，作为服务端的程序有必要提前启动，准备接收客户端的请求。否则 即使有客户端的请求发过来，也无法做到相应的处理。
这些服务端程序在UNIX系统当中叫做守护进程。例如HTTP的服务端程序是 httpd (HTP守护进程),而ssh的服务端程序是sshd (SSH守护进程)。在UNIX中并不需要将这些守护进程逐个启动,而是启动一个可以代表它们接收客户端请求的inetd (互联网守护进程)服务程序即可。它是一种超级守护进程。该超级守护进程收到客户端请求以后会创建(fork)新的进程并转换(exec)为sshd等各个守护进程。
确认一个请求究竟发给的是哪个服务端(守护进程),可以通过所收到数据包的目标端口号轻松识别。当收到TCP的建立连接请求时,如果目标端口为22,则转给sshd,如果是80则转给httpd,然后,这些守护进程会继续对该连接上的通信传输进行处理。
传输协议TCP,UDP通过接收数据中的目标端口号识别目标处理程序。传输协议的数据将被传递给HTTP, TELNET以及FTP等应用层协议。
两种传输层协议TCP和UDP
在TCP/IP中能够实现传输层功能的、具有代表性的协议是TCP和UDP。
TCP
TCP是面向连接的、可靠的流协议。流就是指不间断的数据结构，你可以把 它想象成排水管道中的水流。当应用程序采用TCP发送消息时，虽然可以保证发送的顺序，但还是犹如没有任何间隔的数据流发送给接收端。
TCP为提供可靠性传输，实行“顺序控制”或“重发控制”机制。此外还具 备“流控制（流量控制）”、＂拥塞控制”、提高网络利用率等众多功能。
UDP
UDP是不具有可靠性的数据报协议。细微的处理它会交给上层的应用去完 成。在UDP的情况下，虽然可以确保发送消息的大小，却不能保证消息一定会 到达。因此，应用有时会根据自己的需要进行重发处理。
TCP与UDP区分
可能有人会认为，鉴于TCP是可靠的传输协议，那么它一定优于UDP。其实 不然。TCP与UDP的优缺点无法简单地、绝对地去做比较。那么，对这两种协议 应该如何加以区分使用呢？下面，我就对此问题做一简单说明。
TCP用于在传输层有必要实现可靠传输的情况。由于它是面向有连接并具备 顺序控制、重发控制等机制的，所以它可以为应用提供可靠传输。
而在一方面，UDP主要用于那些对高速传输和实时性有较高要求的通信或广 播通信。我们举一个通过IP电话进行通话的例子。如果使用TCP, 数据在传送途 中如果丢失会被重发，但这样无法流畅地传输通话人的声音，会导致无法进行正 常交流。而采用UDP, 它不会进行重发处理。从而也就不会有声音大幅度延迟到 达的问题。即使有部分数据丢失，也只是会影响某一小部分的通话。此外，在 多播与广播通信中也使用UDP而不是TCP。RIP、DHCP等 基于广播的协议也要依赖于UDP。
因此，TCP和UDP应该根据应用的目的按需使用。
套接字(Socket)
应用在使用TCP或UDP时，会用到操作系统提供的类库。这种类库 一般被称为API (Application Programming Interlace , 应用编程接口）。
使用TCP或UDP通信时，又会广泛使用到套接字(socket)的API。
套接字原本是由BSD UNIX开发的，但是后被移植到了Windows的Winsock 以及嵌入式操作系统中。
应用程序利用套接字，可以设置对端的IP地址、端口号，并实现数 据的发送与接收。
端口号
端口号定义
数据链路和IP中的地址，分别指的是MAC地址和IP地址。前者用来识别同 一链路中不同的计算机，后者用来识别TCP/IP网络中互连的主机和路由器。在 传输层中也有这种类似于地址的概念，那就是端口号。端口号用来识别同一台计 算机中进行通信的不同应用程序。因此，它也被称为程序地址。
根据端口号识别应用
一台计算机上同时可以运行多个程序。例如接受WWW服务的Web浏览器、 电邮客户端、远程登录用的ssh客户端等程序都可同时运行。传输层协议正是利 用这些端口号识别本机中正在进行通信的应用程序，并准确地将数据传输。
通过IP地址、端口号、协议号进行通信识别
仅凭目标端口识别某一个通信是远远不够的。①和②的通信是在两台计算机上进行的。它们的目标端口号相同,都是80,例如打开两个Web浏览器,同时访问两个服务器上不同的页面,就会在这个浏览器跟服务器之间产生类似前面的两个通信。在这种情况下也必须严格区分这两个通信。因此可以根据源端口号加以区分。
下图中③跟①的目标端口号和源端口号完全相同,但是它们各自的源IP地址不同。此外,还有一种情况上图中并未列出,那就是IP地址和端口全都一样,只是协议号(表示上层是TCP或UDP的一种编号)不同。这种情况下,也会认为是两个不同的通信。
因此, TCP/IP或UDP/IP通信中通常采用5个信息来识别"一个通信。它们是“源IP地址”、“目标IP地址”、“协议号”、“源端口号”、“目标端口号”。只要其中某一项不同,则被认为是其他通信。
端口号如何确定
在实际进行通信时，要事先确定端口号。确定端口号的方法分为两种：
标准既定的端口号
这种方法也叫静态方法。它是指每个应用程序都有其指定的端口号。但并不 是说可以随意使用任何一个端口号。每个端口号都有其对应的使用目的。
例如，HTTP、TELNET、F1,P等广为使用的应用协议中所使用的端口号就是 固定的。这些端口号也被称之为知名端口号(Well-Known Port Number)。知名端口号一般由0 到1023的数字分配而成。应用程序应该避免使用知名端口号进行既定目的之外的 通信，以免产生冲突。
除知名端口号之外，还有一些端口号也被正式注册。它们分布在1024到 49151的数字之间。不过，这些端口号可用于任何通信用途。
时序分配法
第二种方法也叫时序（或动态的）分配法。此时，服务端有必要确定监听端 口号，但是接受服务的客户端没必要确定端口号。
在这种方法下，客户端应用程序可以完全不用自己设置端口号，而全权交给 操作系统进行分配。操作系统可以为每个应用程序分配互不冲突的端口号。例如， 每需要一个新的端口号时，就在之前分配号码的基础上加l。这样，操作系统就 可以动态地管理端口号了。
根据这种动态分配端口号的机制，即使是同一个客户端程序发起的多个TCP 连接，识别这些通信连接的5部分数字也不会全部相同。
动态分配的端口号取值范围在49152到65535之间。
端口号与协议
端口号由其使用的传输层协议决定。因此,不同的传输协议可以使用相同的端口号。
例如, TCP与UDP使用同一个端口号,但使用目的各不相同。这是因为端口号上的处理是根据每个传输协议的不同而进行的。
数据到达IP层后,会先检查IP首部中的协议号,再传给相应协议的模块。如果是TCP则传给TCP模块、如果是UDP则传给UDP模块去做端口号的处理。即使是同一个端口号,由于传输协议是各自独立地进行处理,因此相互之间不会受到影响。
此外,那些知名端口号与传输层协议并无关系,只要端口一致都将分配同一种程序进行处理。例如, 53号端口在TCP与UDP中都用于DNS服务,而80端口用于HTTP通信。从目前来看,由于HTTP通信必须使用TCP,因此UDP的80端口并未投入使用。但是将来,如果HTTP协议的实现也开始应对UDP协议以及应用协议被相应扩展的情况下,就可以原样使用与TCP保持相同的80端口号了。
UDP
UDP的特点及其目的
UDP是User Datagram Protocol的缩写。
UDP不提供复杂的控制机制，利用IP提供面向无连接的通信服务。并且它是 将应用程序发来的数据在收到的那一刻，立即按照原样发送到网络上的一种机制。
即使是出现网络拥堵的情况下，UDP也无法进行流量控制等避免网络拥塞的 行为。此外，传输途中即使出现丢包，UDP也不负责重发。甚至当出现包的到达 顺序乱掉时也没有纠正的功能。如果需要这些细节控制，那么不得不交由采用 UDP的应用程序去处理"。
UDP有点类似于用户说什么听什么的机制，但是需要 用户充分考虑好上层协议类型并制作相应的应用程序。因此，也可以说，UDP按 照“制作程序的那些用户的指示行事”。
由于UDP面向无连接，它可以随时发送数据。再加上UDP本身的处理既简单又高效，因此经常用于以下几个方面：
- 包总量较少的通信(DNS、SNMP等）
- 视频、音频等多媒体通信（即时通信）
- 限定于LAN等特定网络中的应用通信
- 广播通信（广播、多播）
用户与程序员
此处所使用的“用户”并不单单指“互联网的使用者”。曾经它也表 示为那些编写程序的程序员。因此，UDP的“用户" (User)在现在看来 其实就相当于程序员。也就是说，认为UDP是按照程序员的编程思路在 传送数据报也情有可原。
其他传输层协议
UDP-Lite
UDP-Lite (Lightweight User Datagram Protocol , 轻量级用户数据报协议）是扩 展UDP机能的一种传输层协议。在基于UDP的通信当中如果校验和出现错误， 所收到的包将被全部丢弃。然而，现实操作中，有些应用，在面对这种情况时并 不希望把已经收到的所有包丢弃。
如果将UDP中校验和设置为无效，那么即使数据的一部分发生错误也不会将 整个包废弃。不过，这不是一个很好的方法。因为如果发生的错误有可能是UDP 首部中的端口号被破坏或是IP首部中的IP地址被破坏，就会产生严重后果。因 此，不建议将校验和关闭。为了解决这些问题，UDP的修正版UDP-Lite协议就 出现了。
UDP-Lite提供与UDP几乎相同的功能，不过计算校验和的范围可以由应用 自行决定。这个范围可以是包加上伪首部的校验和计算，可以是首部与伪首部的 校验和计算，也可以是首部、伪首部与数据从起始到中间某个位置的校验和计 算。
有了这样的机制，就可以只针对不允许发生错误的部分进行校验和的检查。 对于其他部分，即使发生了错误，也会被忽略不计。而这个包也不会被丢弃，而 是直接传给应用继续处理。
SCTP
SCTP (Stream Control Transmission Protocol , 流控制传输协议）, 与TCP样，都是对一种提供数据到达与否相关可靠性检查的传输层协议。其主要特点 如下：
以消息为单位收发
TCP中接收端并不知道发送端应用所决定的消息大小。在SCTP中却可以。
支持多重宿主
在有多个NIC的主机中，即使其中能够使用的NIC发生变化，也仍然可以 继续通信。
支持多数据流通信
TCP中建立多个连接以后才能进行通信的效果，在SCTP中一个连接就 可以。
可以定义消息的生存期限
超过生存期限的消息，不会被重发。
SCTP主要用于进行通信的应用之间发送众多较小消息的情况。这些较小的应用消息被称作数据块(Chunk), 多个数据块组成一个数据包。
此外，SCTP具有支持多重宿主以及设定多个IP地址的特点。多重宿主是指 同一台主机具备多种网络的接口。例如，笔记本电脑既可以连接以太网又可以连 接无线LAN。
同时使用以太网和无线LAN时，各自的NIC会获取到不同的IP地址。进行 TCP通信，如果开始时使用的是以太网，而后又切换为无线LAN, 那么连接将会 被断开。因为从SYN到FIN包必须使用同一个IP地址。
然而在SCTP的情况下，由于可以管理多个IP地址使其同时进行通信，因此 即使出现通信过程当中以太网与无线LAN之间的切换，也能够保持通信不中断。
DCCP
DCCP (Datagram Congestion Control Protocol , 数据报拥塞控制协议）是一个 辅助UDP的崭新的传输层协议。UDP没有拥塞控制机制。为此，当应用使用 UDP发送大量数据包时极容易出现问题。互联网中的通信，即使使用UDP也应该 控制拥塞。而这个机制开发人员很难将其融合至协议中，于是便出现了DCCP这 样的规范。
DCCP具有如下几个特点：
- 与UDP一样，不能提供发送数据的可靠性传输。
- 它面向连接，具备建立连接与断开连接的处理。在建立和断开连接上是具 有可靠性。
- 能够根据网络拥堵情况进行拥塞控制。使用DCCP (RFC4340)应用可以根 据自身特点选择两种方法进行拥塞控制。它们分别是＂类似TCP (TCPLike)拥塞控制”和"TCP友好升级控制" (TCP-Friendly Rate Control) "' (RFC4341)。
- 为了进行拥塞控制，接收端收到包以后返回确认应答(ACK)。该确认应 答将被用于重发与否的判断。
本文链接：https://www.pianshen.com/article/76181065276/
标签：协议,UDP,通信,TCP,传输层,端口号 来源： https://blog.csdn.net/daocaokafei/article/details/116137494
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。