如果说网际层解决的是“数据要发到哪台主机”，那么传输层进一步解决的是“数据应该交给主机上的哪个程序，以及多个主机之间如何进行可靠的数据传输”。

TCP/IP 四层模型中的传输层主要包括 TCP、UDP、端口、Socket、可靠传输、流量控制、拥塞控制以及连接管理 等概念。理解这一层之后，才能继续理解 HTTP、DNS、SSH 等应用层协议为什么能够同时运行在同一台主机上。

传输层是什么#

TCP/IP 四层模型：

1
┌────────────────────┐
2
│      应用层        │
3
├────────────────────┤
4
│      传输层        │
5
├────────────────────┤
6
│      网际层        │
7
├────────────────────┤
8
│    网络接口层      │
9
└────────────────────┘

理解传输层时，先区分相邻层的职责：

1
网络接口层
2
↓
3
Ethernet / MAC / Frame / 网卡
4

5
网际层
6
↓
7
IP / IP 地址 / 子网 / 路由 / ICMP / ARP

传输层位于它们之上。

它主要负责：

1
主机
2
 ↓
3
进程之间的通信

也就是说：

IP 地址定位主机，端口定位主机上的服务或通信端点。

例如：

1
192.168.1.10:80

可以拆成：

1
192.168.1.10
2
↓
3
目标主机
4

5
80
6
↓
7
目标端口

因此：

1
IP
2
↓
3
找到哪台主机
4

5
Port
6
↓
7
找到主机上的哪个服务

为什么需要传输层#

假设一台服务器同时运行：

1
Web Server
2
SSH Server
3
DNS Server
4
Database

它们都使用同一块网卡和同一个 IP 地址。

例如：

1
服务器
2
IP = 192.168.1.10

但客户端需要区分：

1
Web
2
SSH
3
DNS
4
Database

这时候就需要：

Port（端口）

可以理解为：

1
             192.168.1.10
2
                    │
3
       ┌────────────┼────────────┐
4
       │            │            │
5
       ▼            ▼            ▼
6
     :22           :53          :80
7
      │             │             │
8
      ▼             ▼             ▼
9
     SSH           DNS           HTTP

因此：

1
IP + Port

共同构成了网络通信中的一个重要寻址概念。

端口#

什么是 Port#

TCP 和 UDP 都使用：

16 bit 端口号

因此端口范围是：

端口号本身只是一个数字。

真正的含义取决于：

1
传输协议
2
+
3
具体应用

例如：

1
TCP 22
2
TCP 80
3
TCP 443
4
UDP 53

并不意味着：

1
80 永远只能用于 HTTP

而是：

某个应用协议通常会约定使用某个端口。

端口范围#

传统上可以把端口大致理解为：

1
0 ~ 1023
2
↓
3
知名端口
4

5
1024 ~ 49151
6
↓
7
注册端口
8

9
49152 ~ 65535
10
↓
11
动态 / 私有端口

其中实际系统、IANA 注册以及具体操作系统分配策略可能存在差异。

IANA 维护官方的 Service Name and Transport Protocol Port Number Registry。

源端口与目标端口#

一次 TCP / UDP 通信通常存在：

1
Source Port
2
Destination Port

例如客户端访问服务器：

1
Client
2
192.168.1.10:50000
3
       │
4
       │
5
       ▼
6
Server
7
192.168.1.20:443

可以理解为：

1
源 IP   = 192.168.1.10
2
源端口  = 50000
3

4
目标 IP = 192.168.1.20
5
目标端口 = 443

于是一个方向上的通信可以表示为：

1
192.168.1.10:50000
2
          ↓
3
192.168.1.20:443

返回方向则相反：

1
192.168.1.20:443
2
          ↓
3
192.168.1.10:50000

TCP 与 UDP#

传输层最重要的两个协议：

1
TCP
2
UDP

它们都属于传输层，但设计目标不同。

可以先概括为：

1
TCP
2
↓
3
面向连接
4
可靠
5
有序
6
字节流
7

8
UDP
9
↓
10
无连接
11
尽力交付
12
数据报
13
开销较小

注意：

“UDP 不可靠”并不是说 UDP 一定会丢包，而是 UDP 协议本身不提供类似 TCP 的可靠传输、排序和重传机制。

UDP#

UDP 是什么#

UDP（User Datagram Protocol）是一种无连接的传输层协议。

RFC 768 定义了 UDP。

其特点可以概括为：

1
简单
2
无连接
3
数据报
4
开销低

UDP 不负责建立一个类似 TCP 那样的连接状态。

UDP Datagram#

UDP 传输的数据单位称为：

UDP Datagram

可以理解为：

1
Application Data
2
      │
3
      ▼
4
UDP Datagram
5
      │
6
      ▼
7
IP Packet

UDP 首部很简单：

1
┌──────────────────┬──────────────────┐
2
│ Source Port      │ Destination Port │
3
├──────────────────┼──────────────────┤
4
│ Length           │ Checksum         │
5
├──────────────────┴──────────────────┤
6
│ Payload                              │
7
└─────────────────────────────────────┘

主要包含：

1
源端口
2
目标端口
3
长度
4
校验和

UDP 的特点#

UDP 不提供 TCP 那样的：

1
连接建立
2
可靠重传
3
顺序保证
4
流量控制
5
拥塞控制

因此它更适合某些强调：

1
低延迟
2
简单通信
3
实时性
4
应用自行控制可靠性

的场景。

常见应用包括：

1
DNS
2
DHCP
3
实时音视频
4
部分游戏通信
5
QUIC 的底层传输

不过具体协议是否使用 UDP 仍然由协议设计决定。

TCP#

TCP 是什么#

TCP（Transmission Control Protocol）是一种：

面向连接的、可靠的、字节流传输协议。

RFC 9293 是当前 TCP 的主要规范之一。

TCP 需要维护通信双方的状态。

可以简单理解为：

1
Client
2
  │
3
  │ 建立连接
4
  ▼
5
Server
6
  │
7
  │
8
  ▼
9
TCP Connection

TCP Segment#

TCP 传输的数据单位通常称：

TCP Segment

可以理解为：

1
Application Data
2
      │
3
      ▼
4
TCP Segment
5
      │
6
      ▼
7
IP Packet

TCP 首部比 UDP 复杂得多。

简化表示：

1
┌─────────────────┬─────────────────┐
2
│ Source Port     │ Dest Port       │
3
├─────────────────┼─────────────────┤
4
│ Sequence Number                   │
5
├───────────────────────────────────┤
6
│ Acknowledgment Number             │
7
├───────┬───────┬───────────────────┤
8
│ Flags │ Window│ ...               │
9
├───────┴───────┴───────────────────┤
10
│ Checksum                           │
11
├───────────────────────────────────┤
12
│ Urgent Pointer / Options ...       │
13
├───────────────────────────────────┤
14
│ Payload                            │
15
└───────────────────────────────────┘

其中非常重要的字段包括：

1
Sequence Number
2
Acknowledgment Number
3
Flags
4
Window
5
Checksum

TCP 三次握手#

为什么要握手#

TCP 是面向连接的，因此通信双方需要首先建立连接状态。

典型过程是：

1
Client                          Server
2
  │                               │
3
  │ -------- SYN ---------------> │
4
  │                               │
5
  │ <------ SYN + ACK ------------ │
6
  │                               │
7
  │ -------- ACK ---------------> │
8
  │                               │
9
  │          Established          │

这就是：

TCP Three-Way Handshake

第一次：SYN#

客户端发送：

1
SYN

表示：

我想建立 TCP 连接。

其中会携带客户端选择的初始序列号等信息。

1
Client
2
   │
3
   │ SYN
4
   ▼
5
Server

第二次：SYN + ACK#

服务器收到 SYN 后：

1
Server
2
   │
3
   │ SYN + ACK
4
   ▼
5
Client

表示：

1
我收到了你的请求
2
+
3
我也愿意建立连接

第三次：ACK#

客户端收到服务器响应后：

1
Client
2
   │
3
   │ ACK
4
   ▼
5
Server

双方就可以进入：

1
Established

状态。

三次握手到底解决什么#

不能简单说：

“三次握手就是为了确认双方都在线。”

它更准确的作用包括：

1
同步双方的初始序列号
2
确认双向通信能力
3
建立双方 TCP 状态

因此：

1
SYN
2
↓
3
建立初始状态
4

5
SYN + ACK
6
↓
7
服务器确认并建立自己的状态
8

9
ACK
10
↓
11
客户端确认服务器响应

TCP 四次挥手#

为什么关闭连接需要四步#

TCP 是全双工通信。

也就是说：

1
A → B
2
B → A

两个方向可以独立关闭。

因此关闭连接通常涉及：

1
FIN
2
ACK
3
FIN
4
ACK

典型流程：

1
Client                          Server
2
  │                               │
3
  │ -------- FIN ---------------> │
4
  │ <-------- ACK --------------- │
5
  │                               │
6
  │ <-------- FIN --------------- │
7
  │ -------- ACK ---------------> │
8
  │                               │
9
  │            Closed             │

因此：

TCP 的连接关闭通常被称为“四次挥手”。

但实际抓包中具体报文可能因为实现和时序有所不同，例如 ACK 可能与其他报文合并，因此不要把“四次”理解成绝对固定的报文数量。

TCP 序列号与确认号#

TCP 的可靠传输非常依赖：

1
Sequence Number
2
Acknowledgment Number

例如：

1
发送方
2
Segment 1
3
Seq = 1000
4
Length = 500

那么接收方如果完整收到：

1
1000 ~ 1499

通常会确认下一个希望收到的位置：

1
ACK = 1500

因此可以理解为：

1
Seq
2
↓
3
“这一段数据从哪里开始”
4

5
ACK
6
↓
7
“我已经收到哪里，并希望下一个从哪里开始”

为什么需要序列号#

因为网络中的数据包可能：

1
乱序
2
丢失
3
重复
4
延迟

例如发送：

1
Segment A
2
Segment B
3
Segment C

网络中可能出现：

1
A
2
C
3
B

TCP 可以利用序列号判断：

1
数据顺序
2
数据范围
3
重复数据
4
缺失数据

从而实现有序的字节流交付。

TCP 重传#

假设：

1
发送：
2

3
A
4
B
5
C

但：

1
B

在网络中丢失。

接收端可能持续确认：

1
ACK

表明自己还缺少某个位置的数据。

发送端检测到丢失后，就可能重新发送对应数据。

可以简化为：

1
A ─────────────►
2
B ─────X
3

4
C ─────────────►
5

6
收到情况：
7
A
8
缺 B
9
C
10

11
        ↓
12

13
重新发送 B
14
        ↓
15

16
B ─────────────►

这就是 TCP 可靠传输的重要基础。

TCP 滑动窗口#

如果发送方：

1
发送一个
2
等待 ACK
3
发送一个
4
等待 ACK

效率会非常低。

因此 TCP 使用窗口机制允许：

在等待确认之前连续发送多个字节的数据。

例如：

1
发送窗口
2

3
┌────┬────┬────┬────┬────┐
4
│ A  │ B  │ C  │ D  │ E  │
5
└────┴────┴────┴────┴────┘

可以同时存在多个尚未确认的数据。

收到确认后：

1
┌────┬────┬────┬────┬────┐
2
│ A  │ B  │ C  │ D  │ E  │
3
└────┴────┴────┴────┴────┘
4
       ↑
5
      ACK

窗口向前滑动：

1
      ┌────┬────┬────┬────┬────┐
2
      │ B  │ C  │ D  │ E  │ F  │
3
      └────┴────┴────┴────┴────┘

因此称为：

Sliding Window（滑动窗口）

TCP 流量控制#

为什么需要流量控制#

假设：

1
发送方很快
2
接收方很慢

如果发送方无限制地发送：

1
发送发送发送发送……

接收方缓冲区最终可能被填满。

因此接收方需要告诉发送方：

我现在还能接收多少数据。

TCP 使用：

Receive Window（接收窗口）

进行流量控制。

接收窗口#

可以简单理解：

1
Receiver
2
   │
3
   │ 告诉 Sender：
4
   │ 我还能接收 N 字节
5
   ▼
6
Sender
7
   │
8
   │ 控制发送量
9
   ▼
10
Receiver

于是：

1
发送速度
2
↓
3
受到接收方处理能力限制

这就是：

Flow Control

核心解决：

1
发送方
2
vs
3
接收方

速度不匹配的问题。

TCP 拥塞控制#

流量控制解决的是：

1
发送方 ↔ 接收方

而拥塞控制关注的是：

1
发送方
2
   ↓
3
网络
4
   ↓
5
接收方

也就是：

网络本身是否拥堵。

为什么需要拥塞控制#

假设：

1
主机 A
2
   ↓
3
路由器
4
   ↓
5
路由器
6
   ↓
7
主机 B

如果大量发送方同时高速发送：

1
A ─┐
2
B ─┼──► Network
3
C ─┘

中间网络设备可能出现：

1
队列堆积
2
丢包
3
延迟增加

TCP 因此需要动态调整发送速率。

拥塞窗口#

TCP 通过：

Congestion Window（拥塞窗口，cwnd）

控制在网络中可以同时维持多少未确认数据。

最终发送端的有效发送窗口通常会受到：

1
接收窗口 rwnd

和：

1
拥塞窗口 cwnd

共同限制。

可以简化理解为：

1
实际可发送范围
2
≈
3
min(rwnd, cwnd)

流量控制与拥塞控制的区别#

这是 TCP 中非常重要的一组概念。

1
Flow Control
2
↓
3
关注接收方
4

5
Congestion Control
6
↓
7
关注网络

可以画成：

1
Sender
2
  │
3
  │
4
  ▼
5
Network
6
  │
7
  │
8
  ▼
9
Receiver
10

11
  ↑
12
  │
13
流量控制
14
关注 Receiver 能不能接住
15

16
拥塞控制
17
关注 Network 能不能承受

因此：

1
接收方太慢
2
↓
3
流量控制
4

5
网络太拥堵
6
↓
7
拥塞控制

TCP 的可靠传输机制#

把前面的概念放到一起，可以理解 TCP 的可靠性来自多个机制共同作用：

1
TCP
2
│
3
├── Sequence Number
4
├── Acknowledgment
5
├── Retransmission
6
├── Sliding Window
7
├── Flow Control
8
├── Congestion Control
9
└── Connection Management

也就是说：

TCP 的可靠性不是由某一个字段提供，而是一整套机制共同实现的。

UDP 与 TCP 的区别#

可以从整体上比较：

特性	TCP	UDP
连接	面向连接	无连接
数据形式	字节流	数据报
可靠传输	提供	不提供
顺序保证	提供	不提供
重传	提供	不提供
流量控制	提供	不提供
拥塞控制	提供	不提供
首部	相对复杂	简单
通信开销	相对较高	相对较低
典型场景	HTTP、SSH 等	DNS、DHCP、实时通信等

这里的：

1
TCP 更可靠
2
UDP 更简单

并不意味着：

1
TCP 一定更快
2
UDP 一定更快

具体性能取决于：

1
网络条件
2
数据规模
3
应用协议
4
延迟要求
5
丢包率
6
实现方式

Socket#

什么是 Socket#

应用程序要使用 TCP / UDP 通信，需要操作系统提供编程接口。

其中最重要的抽象之一就是：

Socket

可以简单理解为：

1
Application
2
    │
3
    ▼
4
  Socket
5
    │
6
    ▼
7
TCP / UDP
8
    │
9
    ▼
10
    IP

应用程序不需要直接操作：

1
Ethernet Frame
2
MAC
3
网卡

而是通常通过 Socket API 与传输层通信。

Socket 地址#

一个 TCP 通信端点可以抽象成：

1
IP + Port + Protocol

例如：

1
TCP
2
192.168.1.10:443

或：

1
UDP
2
192.168.1.10:53

因此：

1
192.168.1.10:443/TCP

和：

1
192.168.1.10:443/UDP

是不同的通信端点。

TCP 连接如何唯一确定#

一个 TCP 连接通常由：

1
源 IP
2
源端口
3
目标 IP
4
目标端口
5
协议

这些信息共同确定。

也常称为：

Four-Tuple（四元组）

例如：

1
192.168.1.10:50000
2
        ↓
3
192.168.1.20:443

对应：

1
Source IP      = 192.168.1.10
2
Source Port    = 50000
3
Destination IP = 192.168.1.20
4
Destination Port = 443
5
Protocol       = TCP

因此同一台服务器：

1
192.168.1.20:443

可以同时与大量客户端建立 TCP 连接：

1
Client A :50000 ──► Server :443
2
Client B :50001 ──► Server :443
3
Client C :50002 ──► Server :443

因为每条连接的四元组不同。

服务器为什么可以同时服务很多客户端#

假设服务器：

1
192.168.1.20:443

客户端：

1
A:50000
2
B:50001
3
C:50002

它们分别建立：

1
A:50000 → 192.168.1.20:443
2

3
B:50001 → 192.168.1.20:443
4

5
C:50002 → 192.168.1.20:443

虽然：

1
目标 IP
2
目标端口

完全一样，但：

1
源 IP
2
源端口

不同。

因此操作系统可以区分这些连接。

可以理解为：

1
                    Server
2
                 192.168.1.20
3
                       │
4
                      :443
5
                       │
6
          ┌────────────┼────────────┐
7
          │            │            │
8
          ▼            ▼            ▼
9
       Client A     Client B     Client C
10
        :50000       :50001       :50002

这就是服务器能够同时接受大量连接的基础之一。

TCP 状态#

TCP 是有状态协议。

一个连接在生命周期中会经历不同状态，例如：

1
LISTEN
2
SYN-SENT
3
SYN-RECEIVED
4
ESTABLISHED
5
FIN-WAIT-1
6
FIN-WAIT-2
7
CLOSE-WAIT
8
CLOSING
9
LAST-ACK
10
TIME-WAIT
11
CLOSED

最重要的可以先掌握：

1
LISTEN
2
↓
3
等待连接
4

5
SYN-SENT / SYN-RECEIVED
6
↓
7
建立连接
8

9
ESTABLISHED
10
↓
11
正常通信
12

13
FIN-WAIT / CLOSE-WAIT 等
14
↓
15
连接关闭过程
16

17
TIME-WAIT
18
↓
19
关闭后的特定状态

可以使用：

1
ss -tan

查看 TCP 连接状态。

LISTEN 是什么#

服务器程序启动 TCP 服务后，通常会：

1
创建 Socket
2
   ↓
3
绑定 IP / Port
4
   ↓
5
进入 LISTEN
6
   ↓
7
等待客户端连接

可以简单表示：

1
Application
2
    │
3
    ▼
4
Socket
5
    │
6
    ▼
7
LISTEN
8
    │
9
    ▼
10
等待 SYN

例如：

1
0.0.0.0:80

表示某个程序正在监听 TCP 80 端口，并等待连接。

ESTABLISHED#

建立连接之后：

1
Client
2
   │
3
   ▼
4
Server

双方进入：

1
ESTABLISHED

表示 TCP 连接已经建立，可以进行正常数据传输。

例如：

1
ss -tan

可能看到：

1
ESTAB

这就是：

Established

的缩写。

TIME_WAIT#

TCP 连接关闭后，主动关闭的一方可能进入：

1
TIME_WAIT

这并不是：

“程序还在运行”。

它属于 TCP 连接管理机制的一部分。

其重要目的之一是：

1
确保网络中旧的延迟报文不会干扰后续新的连接

并确保必要的 ACK 重传机制能够正常工作。

因此：

1
TIME_WAIT

本身并不等于故障。

在高并发服务器中，如果大量连接同时关闭，可能看到大量：

1
TIME_WAIT

这时应该结合实际连接模式和系统资源进行分析，而不是看到它就认为：

“TCP 出问题了”。

TCP 与应用层#

现在可以把 TCP 放回整个协议栈：

1
应用层
2
│
3
├── HTTP
4
├── SSH
5
├── DNS
6
└── ...
7
      │
8
      ▼
9
传输层
10
│
11
├── TCP
12
└── UDP
13
      │
14
      ▼
15
网际层
16
│
17
├── IPv4
18
└── IPv6
19
      │
20
      ▼
21
网络接口层
22
│
23
└── Ethernet

例如访问：

1
https://example.com

可以粗略理解为：

1
HTTP
2
 ↓
3
TCP
4
 ↓
5
IP
6
 ↓
7
Ethernet

每一层负责不同的问题。

一次 TCP 通信的完整过程#

假设：

1
客户端
2
192.168.1.10
3

4
服务器
5
192.168.1.20:80

客户端访问服务器。

完整流程可以简化成：

1
                  Application
2
                      │
3
                      │ HTTP
4
                      ▼
5
                    TCP
6
                      │
7
                Three-Way
8
                Handshake
9
                      │
10
                      ▼
11
               TCP Connection
12
                      │
13
                      ▼
14
                   IP Packet
15
                      │
16
                      ▼
17
              Ethernet Frame
18
                      │
19
                      ▼
20
                    网络
21
                      │
22
                      ▼
23
                  服务器

如果建立连接：

1
SYN
2
 ↓
3
SYN + ACK
4
 ↓
5
ACK
6
 ↓
7
Established

然后开始传输：

1
Application Data
2
 ↓
3
TCP Segment
4
 ↓
5
IP Packet
6
 ↓
7
Ethernet Frame

服务器收到后：

1
Ethernet
2
 ↓
3
IP
4
 ↓
5
TCP
6
 ↓
7
Port 80
8
 ↓
9
HTTP Server

这样一个 HTTP 请求最终才能到达：

1
具体的服务器进程

UDP 通信#

UDP 会简单很多。

例如：

1
Client
2
192.168.1.10:50000
3

4
Server
5
192.168.1.20:53

客户端发送 DNS 查询。

可以理解为：

1
Application Data
2
      │
3
      ▼
4
UDP Datagram
5
      │
6
      ▼
7
IP Packet
8
      │
9
      ▼
10
Ethernet Frame
11
      │
12
      ▼
13
Network
14
      │
15
      ▼
16
Server :53

不需要：

1
TCP Three-Way Handshake

也没有：

1
TCP Connection State

这种连接管理机制。

传输层的整体认知模型#

现在可以把这一层浓缩成：

1
                       传输层
2
                          │
3
             ┌────────────┴────────────┐
4
             │                         │
5
             ▼                         ▼
6
            TCP                       UDP
7
             │                         │
8
      ┌──────┼──────┐                  │
9
      │      │      │                  │
10
      ▼      ▼      ▼                  ▼
11
    连接   可靠性  拥塞控制          数据报
12
      │      │      │                  │
13
      │      │      ├── Flow Control   │
14
      │      │      └── Congestion     │
15
      │      │                         │
16
      ▼      ▼                         ▼
17
  Sequence  ACK                     Port
18
  Number    Retransmission             │
19
      │      │                         │
20
      └──────┴──────────┬──────────────┘
21
                        ▼
22
                      Socket
23
                        │
24
                        ▼
25
                     IP Layer

可以进一步浓缩成：

1
IP
2
↓
3
哪台主机
4

5
Port
6
↓
7
哪个服务 / 通信端点
8

9
TCP
10
↓
11
可靠的字节流通信
12

13
UDP
14
↓
15
简单的数据报通信

而 TCP 的核心机制：

1
连接
2
 ↓
3
序列号
4
 ↓
5
确认
6
 ↓
7
重传
8
 ↓
9
滑动窗口
10
 ↓
11
流量控制
12
 ↓
13
拥塞控制
14
 ↓
15
连接关闭

共同构成了 TCP 的可靠传输体系。

常见传输层排障思路#

当出现：

1
“网络通，但是服务访问不了”

不能只检查：

1
ping

因为：

1
ping
2
↓
3
主要验证 IP 层连通性

而服务访问还需要检查：

1
TCP / UDP
2
+
3
Port
4
+
5
Application

可以形成这样的排障层次：

1
应用层
2
  ↓
3
服务是否正常？
4

5
传输层
6
  ↓
7
端口是否监听？
8
连接是否建立？
9

10
网际层
11
  ↓
12
IP 是否可达？
13
路由是否正确？
14

15
网络接口层
16
  ↓
17
网卡 / 链路是否正常？

例如：

1
ss -lnt

可以查看 TCP 监听端口。

1
ss -nt

可以查看 TCP 连接。

1
ss -lun

可以查看 UDP Socket。

这比单纯执行：

1
ping server

能提供更具体的信息。

TCP/IP 四层模型中的传输层#

到这里，可以把四层模型完整串起来：

1
┌──────────────────────────────┐
2
│          应用层              │
3
│   HTTP / DNS / SSH / ...      │
4
└──────────────┬───────────────┘
5
               │
6
               ▼
7
┌──────────────────────────────┐
8
│          传输层              │
9
│        TCP / UDP             │
10
│        Port / Socket         │
11
└──────────────┬───────────────┘
12
               │
13
               ▼
14
┌──────────────────────────────┐
15
│          网际层              │
16
│    IPv4 / IPv6 / Routing     │
17
│        ICMP / ARP            │
18
└──────────────┬───────────────┘
19
               │
20
               ▼
21
┌──────────────────────────────┐
22
│        网络接口层            │
23
│ Ethernet / MAC / Frame / NIC │
24
└──────────────────────────────┘

可以把每一层的问题分别概括成：

1
网络接口层
2
↓
3
怎么在当前链路上传输？
4

5
网际层
6
↓
7
数据应该到哪个 IP？
8

9
传输层
10
↓
11
应该交给哪个端口？
12
如何传输？
13

14
应用层
15
↓
16
具体业务数据是什么？

因此：

传输层是连接“网络”和“应用”的关键一层。

它把：

1
主机之间的 IP 通信

进一步变成：

1
进程之间的网络通信

同时提供：

1
TCP
2
↓
3
可靠、有序、面向连接的字节流
4

5
UDP
6
↓
7
简单、无连接的数据报

这就是 TCP/IP 四层模型中传输层最核心的内容。

传输层是什么#

为什么需要传输层#

端口#

什么是 Port#

端口范围#

源端口与目标端口#

TCP 与 UDP#

UDP#

UDP 是什么#

UDP Datagram#

UDP 的特点#

TCP#

TCP 是什么#

TCP Segment#

TCP 三次握手#

为什么要握手#

第一次：SYN#

第二次：SYN + ACK#

第三次：ACK#

三次握手到底解决什么#

TCP 四次挥手#

为什么关闭连接需要四步#

TCP 序列号与确认号#

为什么需要序列号#

TCP 重传#

TCP 滑动窗口#

TCP 流量控制#

为什么需要流量控制#

接收窗口#

TCP 拥塞控制#

为什么需要拥塞控制#

拥塞窗口#

流量控制与拥塞控制的区别#

TCP 的可靠传输机制#

UDP 与 TCP 的区别#

Socket#

什么是 Socket#

Socket 地址#

TCP 连接如何唯一确定#

服务器为什么可以同时服务很多客户端#

TCP 状态#

LISTEN 是什么#

ESTABLISHED#

TIME_WAIT#

TCP 与应用层#

一次 TCP 通信的完整过程#

UDP 通信#

传输层的整体认知模型#

常见传输层排障思路#

TCP/IP 四层模型中的传输层#

外部参考#