目录
计算机网络TCP与UDP
简要描述TCP与UDP的区别和应用场景?
- 连接方式
- TCP是面向连接的协议。在传输数据前,通信双方要通过三次握手建立连接,就像打电话先拨通号码建立通话链路一样。例如,在网页浏览中,浏览器和服务器之间会先建立TCP连接。
- UDP是无连接的协议。发送数据时不需要提前建立连接,类似发送短信,直接发送即可。比如在简单的实时视频流传输场景中可能会用到UDP。
- 可靠性
- TCP提供可靠的数据传输服务。通过序列号、确认应答、重传机制等来保证数据准确无误地到达。如果发送的数据一段时间没收到确认,发送方会重新发送。
- UDP不保证数据传输的可靠性。它只是尽力发送数据,数据可能丢失、重复或者乱序,接收方也不会反馈数据是否正确接收的信息。例如在网络游戏中玩家位置更新信息传输,偶尔丢失一点数据对游戏体验影响不大。
- 传输效率
- TCP由于要建立连接、维护连接状态和保证可靠传输,开销较大,传输效率相对较低。
- UDP没有这些复杂机制,数据包头较小,传输效率相对较高。
- 数据传输顺序
- TCP:
- 保证数据按照发送的顺序到达接收端。这是通过序列号来实现的,接收方会根据序列号将接收到的数据段按照正确的顺序重新组合。例如,在一个基于 TCP 的数据库查询操作中,查询请求和查询结果的数据包都会按照发送的顺序准确地到达目的地,保证了数据的有序性。
- UDP:
- 不保证数据的顺序。由于 UDP 没有像 TCP 那样的序列号和排序机制,数据在网络中传输的路径不同等因素可能导致数据到达接收端的顺序与发送顺序不一致。例如,在一个实时游戏中,玩家位置更新数据包可能会因为网络状况而乱序到达服务器,但游戏服务器可以根据自己的逻辑来处理这些乱序的数据
- TCP:
- 应用场景
- TCP适用于对数据准确性要求高、传输数据量较大、需要长期稳定连接的应用,如文件传输(FTP)、电子邮件(SMTP、POP3)、网页浏览(HTTP/HTTPS)等。
- UDP适用于对实时性要求高、对数据准确性要求相对较低的应用,如实时视频会议、在线游戏、简单的网络监控系统等。
TCP | UDP | |
---|---|---|
连接方式 | 面向连接 | 无连接 |
可靠性 | 高 | 低 |
传输效率 | 较慢 | 较快 |
数据传输顺序 | 保证顺序 | 不保证顺序 |
应用场景 | 长期稳定连接 | 即时通信 |
TCP的三次握手和四次挥手?
TCP三次握手
TCP三次握手是建立一个可靠的连接的过程,确保双方都能发送和接收数据。这个过程包括三个步骤:
- SYN(同步序列编号):客户端发送一个SYN包(x)到服务器以发起一个新的连接。
- SYN-ACK(同步和确认):服务器回应一个SYN-ACK包(x+1)作为响应,确认客户端的SYN。
- ACK(确认):客户端发送一个ACK包(x+1)作为最后的确认。
图表说明:
客户端 TCP三次握手 服务器
| | |
| SYN (x) | |
|-----------------> | |
| | SYN-ACK (x+1) |
| |<----------------- |
| | ACK (x+1) |
| |----------------> |
TCP四次挥手
TCP四次挥手是终止一个可靠连接的过程,确保双方都能正确地关闭连接。这个过程包括四个步骤:
- FIN(结束):客户端发送一个FIN包(x)到服务器,表示客户端没有更多的数据要发送。
- ACK(确认):服务器回应一个ACK包(x+1),确认客户端的FIN。
- FIN(结束):服务器发送一个FIN包(y)到客户端,表示服务器也没有更多的数据要发送。
- ACK(确认):客户端回应一个ACK包(y+1),确认服务器的FIN。
图表说明:
客户端 TCP四次挥手 服务器
| | |
| FIN (x) | |
|-----------------> | |
| | ACK (x+1) |
| |<----------------- |
| | FIN (y) |
| |-----------------> |
| | ACK (y+1) |
| |<----------------- |
在实际应用中,三次握手和四次挥手确保了TCP连接的可靠性和数据传输的完整性。通过这些步骤,TCP能够建立和终止连接,同时确保数据在传输过程中的顺序和完整性。
TCP是如何保证传输的可靠性?
TCP 通过以下多种机制保证传输的可靠性:
- 确认和重传机制 :
- 序列号 :TCP 传输时会给每个字节的数据都进行编号,这就是序列号。发送方在发送数据时会为每个数据包分配一个序列号,接收方可以根据序列号对接收的数据进行确认、排序以及检测是否有数据丢失或乱序。例如,发送方发送了一系列数据包,每个数据包都有唯一的序列号,接收方根据序列号可以知道哪些数据包已经收到,哪些还没有收到。
- 确认应答:接收方收到数据后会发送==确认应答(ACK)==给发送方,告知发送方已成功接收数据。ACK 报文中带有确认序列号,告诉发送方下一次应该从哪个序列号开始发送数据。如果发送方在一定时间内没有收到接收方的确认应答,就会认为数据丢失或传输出现问题,从而触发重传机制,重新发送未被确认的数据。
- 超时重传 :发送方发送完数据后会启动一个定时器并等待确认信息。如果在定时器超时前数据未能被确认,TCP 就认为报文段中的数据已丢失或损坏,需要对报文段中的数据重新组织和重传。超时时间的设定是动态计算的,通常会根据网络的往返时间(RTT)和抖动情况来确定,一般比 RTT 加上一定的抖动值稍大。
- 校验和:TCP 使用校验和来检测数据在传输过程中是否发生了错误。发送方在发送数据之前会计算校验和,并将其填充到 TCP 首部的校验和字段中。接收方收到数据后,也会按照同样的算法计算校验和,并与接收到的校验和进行比较。如果两者不一致,则说明数据在传输过程中发生了错误,接收方会直接丢弃该数据包,要求发送方重新发送。
- 流量控制 :TCP 使用滑动窗口机制进行流量控制,确保发送方的发送速率不会超过接收方的处理能力。接收方会在确认应答报文中告知发送方自己的接收窗口大小,即接收缓冲区中剩余的空间大小。发送方会根据接收方的窗口大小来调整自己的发送速度,避免发送过多的数据导致接收方缓冲区溢出和数据丢失。例如,如果接收方的接收窗口已满,发送方会暂停发送数据,直到接收方有足够的空间接收新的数据。
- 拥塞控制 :TCP 采用拥塞控制算法来避免网络拥塞。当网络拥塞时,数据包的传输时延会增加,丢包率也会上升,这会严重影响数据传输的可靠性。TCP 的拥塞控制算法主要包括慢开始、拥塞避免、快重传和快恢复等阶段。在连接建立初期,发送方会以较慢的速度发送数据,然后根据网络的状况逐渐增加发送速度,避免一开始就发送大量数据导致网络拥塞。如果发生了丢包现象,发送方会根据拥塞的程度调整发送速度,以保证网络的稳定性和数据传输的可靠性。
- 连接管理 :TCP 使用三次握手机制建立连接,确保双方都已准备好进行通信;使用四次挥手机制断开连接,保证连接的正确释放。在连接建立过程中,双方会交换一些控制信息,如初始序列号等,为后续的数据传输做好准备。在连接断开时,双方需要进行确认,确保所有的数据都已经传输完毕,避免数据丢失。
使用TCP的协议有哪些?
以下是使用TCP协议的一些常见协议的简述表格:
协议名称 | 用途描述 | 常用端口(TCP) |
---|---|---|
HTTP | 超文本传输协议,用于网页数据传输 | 80 |
HTTPS | 安全超文本传输协议,加密的HTTP | 443 |
FTP | 文件传输协议,用于文件的上传和下载 | 21 |
SMTP | 邮件传输协议,用于发送电子邮件 | 25 |
POP3 | 邮局协议第三版,用于接收电子邮件 | 110 |
IMAP | 互联网消息访问协议,用于邮件的访问和管理 | 143 |
SSH | 安全外壳协议,用于安全远程登录 | 22 |
Telnet | 远程登录协议,已逐渐被SSH取代 | 23 |
DNS | 域名系统,用于域名解析为IP地址 | 53 |
TFTP | 简单文件传输协议,用于小文件传输 | 69 |
SFTP | SSH文件传输协议,通过SSH进行文件传输 | 22 |
SMTPS | SMTP over SSL/TLS,加密的SMTP | 465 |
LDAP | 轻量级目录访问协议,用于访问目录信息服务 | 389 |
RDP | 远程桌面协议,用于远程桌面连接 | 3389 |
MySQL | 数据库管理系统,用于数据库操作 | 3306 |
PostgreSQL | 数据库管理系统,用于数据库操作 | 5432 |
请注意,这些端口号是最常见的,但实际使用中可能会有所不同,特别是当服务配置为使用不同的端口时。
使用UDP的协议有哪些?
以下是使用UDP协议的一些常见协议的简述表格:
协议 | 全称 | 默认端口(UDP) |
---|---|---|
DNS | 域名服务(Domain Name Service) | 53 |
TFTP | 简单文件传输协议(Trivial File Transfer Protocol) | 69 |
SNMP | 简单网络管理协议(Simple Network Management Protocol) | 161/162 |
NTP | 网络时间协议(Network Time Protocol) | 123 |
VoIP | 语音传输协议(Voice over Internet Protocol) | 动态 |
DHCP | 动态主机配置协议(Dynamic Host Configuration Protocol) | 67/68 |
RIP | 路由信息协议(Routing Information Protocol) | 520 |
这些协议利用UDP的无连接特性,适用于需要快速传输和可以容忍一定丢包率的场景。
HTTP是基于TCP还是UDP?
HTTP(超文本传输协议)是基于TCP(传输控制协议)的。HTTP协议使用TCP作为其传输层协议,以确保数据的可靠传输。TCP提供了面向连接、可靠的字节流服务,这对于HTTP传输网页内容和维护会话状态是非常重要的。
HTTP/2和HTTP/3是HTTP协议的更新版本,其中HTTP/2仍然基于TCP,而HTTP/3则基于UDP,使用了QUIC(Quick UDP Internet Connections)协议,这是一种基于UDP的传输层安全协议,旨在提供更快的连接建立时间和更好的性能。
为什么DNS协议使用UDP?
-
无连接特性 :UDP是无连接的协议,这意味着在发送和接收数据之前不需要建立连接,从而减少了开销和发送数据前的时延。
-
轻量级 :UDP的首部开销小,只有8个字节,相比之下TCP的首部需要20个字节。这种轻量级的特性使得UDP在处理短小的消息时更加高效。
-
响应速度 :使用UDP可以减少DNS域名解析的时间,因为UDP不需要像TCP那样进行三次握手建立连接,这样可以使得DNS解析更快,从而加快网页的打开速度。
-
面向报文 :UDP是面向报文的协议,它在应用层交下来的报文前增加首部后就向下交付IP层,而不关心报文之间的关联。
-
适用场景 :DNS查询通常是短小的,而且对实时性要求较高,但对数据完整性要求相对较低,这使得UDP成为合适的选择。
-
数据包大小限制:DNS协议使用UDP时,如果响应报文的大小超过512字节,可以只返回前512个字节,这种可截断的特性适合于UDP。
-
效率:由于DNS查询通常涉及的是简短的请求和响应,使用UDP可以更快地完成这些操作,而不需要TCP那样复杂的连接管理和状态维护机制。
综上所述,DNS协议使用UDP主要是因为UDP的无连接、轻量级、快速响应和面向报文的特性,这些特性使得UDP非常适合处理DNS查询这种短小、快速、对实时性要求高的场景。
DNS协议只使用了UDP吗?
DNS(域名系统)协议不仅可以使用UDP,还可以使用TCP。实际上,DNS查询可以通过两种不同的传输层协议进行:
-
UDP(用户数据报协议):
- DNS查询通常使用UDP,因为它是无连接的,可以快速发送和接收查询和响应。
- 由于UDP的简单性,它适用于大多数DNS查询,这些查询通常很小,不需要建立连接。
- UDP用于DNS查询的标准端口是53。
-
TCP(传输控制协议):
- 当DNS响应数据量较大,超过UDP数据报的大小限制(通常为512字节)时,DNS可以使用TCP来传输数据。
- TCP提供了可靠的连接,可以确保数据的完整性和顺序,这对于大型响应是必要的。
- DNS使用TCP时也使用端口53。
在实际应用中,DNS客户端首先尝试使用UDP发送查询。如果响应超过了UDP数据报的大小限制,或者如果UDP查询超时,客户端会回退到使用TCP来重新发送查询。这种机制确保了DNS查询的灵活性和可靠性。