TCP 和 UDP

一旦 DNS 给你一个 IP 地址，你的设备就可以把数据包发送到正确的目的地。但 IP 只是在网络之间传送独立的数据包——它不会跟踪这些数据包是否到达、是否按正确顺序到达，或者网络是否拥塞。

如果你把一个网页拆成很多数据包，有些可能乱序到达，有些可能延迟，还有些可能完全丢失。没有额外的协调，接收端应用就无法可靠地把原始数据正确重建出来。

传输协议解决四个基本问题：排序（正确重组数据）、可靠性（检测并重传丢失的数据）、多路复用（允许多个应用共享一个 IP 地址）以及拥塞控制（防止网络过载）。

简而言之，IP 回答的是“这个数据包应该去哪里？”
传输协议回答的是“这段通信应该如何表现？”

当数据到达服务器的 IP 地址时，操作系统仍然需要决定由哪个程序来处理它。一台机器可以同时运行 Web 服务器、数据库服务器、SSH 服务以及许多其他应用程序。

这就是端口号发挥作用的地方。端口是由 TCP 和 UDP 等传输协议使用的逻辑通信端点。它允许系统对传入流量进行多路分解，并将其交给正确的应用程序进程。

例如，端口 80 通常用于 HTTP，端口 443 用于 HTTPS，端口 22 用于 SSH。当你访问一个安全网站时，浏览器会连接到服务器 IP 地址上的 443 端口，表示它想要使用 HTTPS 通信。

如果没有端口，一台机器一次只能运行一个网络应用程序。端口允许在单个 IP 地址上同时进行成千上万次会话。

传输控制协议（TCP）专为需要完整且准确数据传递的应用而设计。与原始 IP 不同，TCP 将通信视为连续的字节流，而不是独立的数据包。

每个数据段都会分配一个 sequence number。接收方在将数据交给应用程序之前，会使用这些编号将数据重新排序，以确保顺序正确。如果某个数据段缺失，TCP 会检测到这个缺口并请求重传。

TCP 还包含 flow control，用于防止发送方过快而压垮较慢的接收方。它通过使用滑动窗口机制来限制未确认数据在网络中同时传输的数量。

最后，TCP 实现了 congestion control。它会监控网络状况并调整传输速度，以避免让路由器过载。在条件允许时，这既能保护整体网络稳定性，又能尽可能提高吞吐量。

TCP 是面向连接的，这意味着在数据传输开始之前，双方必须先同意进行通信。这个过程确保客户端和服务器都已准备好并能够交换数据。

首先，客户端发送一个 SYN (synchronize) 数据包。这个数据包提议一个初始序列号，并表示希望打开连接。

其次，服务器返回一个 SYN-ACK。这表示对客户端请求的确认，并提供服务器自己的初始序列号。

最后，客户端发送一个 ACK 来确认已收到服务器的序列号。此时，双方的序列号已经同步，连接正式建立。

只有在这个握手完成之后，TCP 才会开始传输应用数据。

TCP 会为数据流中的每个字节分配一个 sequence number。这使接收方能够检测缺失或乱序的分段，并正确重建原始消息。

接收方会返回 ACK (acknowledgment) 编号，表示下一个期望接收的字节。如果发送方在一定时间内没有收到 ACK，就会认为该分段丢失了。

当检测到丢失时，TCP 会执行 retransmission，再次发送缺失的数据。即使由于拥塞或网络不稳定导致数据包丢失，这种机制也能确保可靠性。

TCP 还使用 sliding window 进行流量控制。发送方不必在每个数据包后都等待 ACK，而是可以在允许的窗口大小内发送多个分段。这提高了效率，同时仍然保持严格的传输保证。

用户数据报协议(UDP)是无连接的。与TCP不同，它在发送数据之前不会执行握手。发送方只是将数据包传输到目标IP和端口。

UDP不会跟踪序列号来保证可靠性，不会等待确认，也不会重传丢失的数据包。如果一个数据包丢失了，它就消失了。

由于 UDP 去除了这些协调机制，它的开销和延迟都显著更低。这使它适用于速度比完美送达更重要的场景，例如直播、在线游戏或 DNS 查询。

简而言之，UDP 更重视性能和简单性，而不是可靠性。

TCP 非常适合那些数据缺失或损坏会破坏功能的应用。网页、API、文件下载和电子邮件都需要完整且顺序正确的数据。即使只缺少一个字节，也可能导致结果损坏。

UDP 更适合可以接受偶尔丢包的应用。实时视频、语音通话、游戏，以及像 DNS 这样的小型无状态查询，都更看重速度而不是完美性。等待重传会带来明显的延迟。

关键的判断标准是：
如果准确性和完整性是必须的，就使用 TCP。
如果响应速度和低延迟至关重要，UDP 可能更适合。

如果目标端口关闭，或者被防火墙阻止，服务器可能会立即返回 connection refused 消息。这表示主机可达，但没有应用程序在该端口上监听。

如果客户端发送了 SYN，但始终没有收到 SYN-ACK，连接尝试最终会 timeout。这通常表示服务器已关闭、无法访问，或者在路径上的某个防火墙处被过滤。

当数据包丢失严重时，TCP 会检测到缺失的确认并执行 retransmissions。虽然可靠性得以保持，但性能会明显下降。

在严重拥塞下，TCP 会通过拥塞控制算法降低发送速率。连接仍然保持活动，但吞吐量下降，延迟增加。