网络基础回顾：IP地址与端口、TCP与UDP协议、HTTP与HTTPS协议、WebSocket协议
各位同学，在正式进入WebRTC的穿透技术之前，我们得先把网络基础打牢。说实话，我见过太多人在ICE、STUN这些高级概念上栽跟头，最后发现是基础没搞明白。这一章，我们就来快速过一遍那些你必须要掌握的网络基础知识。
IP地址与端口：网络世界的门牌号
IP地址是什么？说白了，就是你在网络上的门牌号。IPv4地址像192.168.1.100这样，32位，分四段。IPv6呢？128位，长得多，像2001:db8::1。我个人习惯把IPv4想象成老式小区的门牌号，IPv6则是新式小区的二维码——信息量更大，也够用很久。
端口呢？就是门牌号后面的房间号。一台服务器只有一个IP，但可以同时跑Web服务、邮件服务、数据库服务。怎么区分？靠端口。Web服务默认80端口，HTTPS是443，SSH是22。你想想看，如果没有端口，你访问一个IP，服务器都不知道该把数据交给哪个程序。
重要概念：IP地址 + 端口号 = 套接字（Socket）。这是网络通信的最小单元。我在项目中遇到过一个问题：两台机器明明能ping通，但程序就是连不上。查了半天，发现是防火墙只开放了特定端口，而我的程序用了别的端口。嗯，端口这东西，看似简单，坑不少。
TCP与UDP协议：可靠与效率的博弈
TCP和UDP，这是传输层的两个老大哥。TCP是面向连接的，UDP是无连接的。怎么理解？
TCP就像打电话。你先拨号（三次握手），对方接了才能说话。说话过程中，你没听清可以要求对方重说（重传机制）。挂断时还要说再见（四次挥手）。可靠，但慢。
UDP就像寄明信片。你写好地址扔邮筒里，对方收不收得到，你不管。快，但不可靠。
| 特性 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接（三次握手） | 无连接 |
| 可靠性 | 可靠（重传、确认） | 不可靠（尽力而为） |
| 顺序性 | 保证顺序 | 不保证顺序 |
| 头部开销 | 20-60字节 | 8字节 |
| 典型应用 | HTTP、FTP、SSH | DNS、视频流、游戏 |
WebRTC为什么选UDP？因为实时通信对延迟敏感，对丢包相对容忍。你想想看，视频通话时偶尔丢一帧画面，比卡住等重传要好得多。我曾经调试过一个WebRTC应用，在弱网环境下TCP模式的延迟飙到2秒以上，换成UDP后降到200毫秒。这就是选择的力量。
避坑指南：我曾经在NAT穿透测试中，默认用了TCP，结果死活打不通。后来才发现，很多企业防火墙对UDP的限制比TCP宽松。所以WebRTC默认走UDP，不是没有道理的。
HTTP与HTTPS协议：Web的基石
HTTP，超文本传输协议，是Web的基石。它基于TCP，请求-响应模式。你发一个GET请求，服务器返回一个响应。简单，但够用。
HTTPS呢？就是HTTP + TLS/SSL。说白了，就是在HTTP外面套了一层加密。为什么需要它？因为HTTP是明文传输的。你在咖啡厅连公共WiFi，用HTTP访问网站，旁边的人可以轻松抓包看到你的所有数据——密码、信用卡号、聊天记录。想想都可怕。
HTTPS的工作原理大致是这样的：
- 客户端发起HTTPS连接请求
- 服务器返回数字证书（包含公钥）
- 客户端验证证书合法性
- 客户端生成对称密钥，用公钥加密后发给服务器
- 双方用对称密钥加密通信
这里有个关键点：非对称加密用于密钥交换，对称加密用于实际数据传输。为什么这样设计？因为非对称加密慢，对称加密快。用非对称加密安全地交换对称密钥，然后用对称加密高效地传输数据。这个设计思路，在WebRTC的DTLS-SRTP中也有体现。
注意：WebRTC的信令交换通常走HTTPS，但媒体数据走DTLS-SRTP（基于UDP的加密方案）。不要混淆了。我见过有人试图用HTTP传输媒体数据，结果延迟和安全性都出了问题。
WebSocket协议：全双工通信的利器
WebSocket，很多人以为它和HTTP是竞争关系。其实不是。WebSocket的握手阶段用的是HTTP，握手成功后升级为WebSocket协议。它解决了HTTP的一个痛点：服务器不能主动给客户端发消息。
HTTP是请求-响应模式，客户端不发请求，服务器就不能响应。但很多场景需要服务器主动推送——比如聊天消息、股票行情、游戏状态。以前用轮询（Polling），客户端每隔几秒发一次请求，效率低，浪费带宽。
WebSocket的出现改变了这一切。它建立连接后，客户端和服务器可以随时互相发消息。全双工，低延迟。
// WebSocket 客户端示例
const ws = new WebSocket('wss://example.com/signal');
ws.onopen = () => {
console.log('连接已建立');
ws.send(JSON.stringify({ type: 'join', room: 'webrtc-demo' }));
};
ws.onmessage = (event) => {
const data = JSON.parse(event.data);
console.log('收到消息:', data);
// 处理信令消息，比如SDP交换、ICE候选
};
ws.onclose = () => {
console.log('连接已关闭');
};在WebRTC中，WebSocket常用于信令传输。信令是什么？就是建立连接前的控制信息——比如交换SDP（会话描述协议）、ICE候选地址。这些信息需要可靠传输，所以走WebSocket（基于TCP）是合理的。而媒体数据走UDP，各司其职。
个人经验：我在做WebRTC信令服务器时，一开始用的HTTP轮询，结果发现延迟高得离谱。换成WebSocket后，信令延迟从500毫秒降到了10毫秒以内。对于实时通信来说，这差距是致命的。
知识体系总览
下面这张图，把本章的核心知识点串起来了。你可以看到，从IP/端口到传输层协议，再到应用层协议，每一层都有它的职责。WebRTC站在这些基础之上，用UDP传输媒体，用WebSocket传输信令，用HTTPS保证信令安全。
好了，这一章的内容就到这里。IP地址和端口是基础中的基础，TCP和UDP的选择决定了通信的可靠性与效率，HTTP/HTTPS保障了Web通信的安全，WebSocket则为实时通信提供了全双工通道。这些知识，在后续的NAT穿透、ICE框架中都会反复用到。