计算机网络 on 蛋蛋忧桑

httpclient与hertzclient在处理Host header时的差别

Fri, 22 Aug 2025 16:41:32 +0800

本文中的Host header、request.header.host、req.Header[“Host”]都指的是请求头中的“Host”字段。

问题提出

在请求转发的过程中，需要从原请求中拿到一些信息来构造新的转发出去的请求，其中就有Host header的问题。一开始我使用的是httpclient，复制请求头的逻辑就是清除一些字段后直接全部复制过去（Host header不在清除范围内），此时程序正常运行。

c.Request.Header.VisitAll(func(key, value []byte) {
		req.Header.Add(string(key), string(value))
	})

当我将httpclient切换成hertzclient后，发现一模一样的复制请求头的逻辑遇到了404的错误。经过一番排查发现是httpclient和hertzclient两者对于request.header.host的处理方式不同。对于hertzclient来说，正确的方式应该是不复制请求头中的Host字段。

c.Request.Header.VisitAll(func(key, value []byte) {
		if string(key) != "Host" {	 // hertz框架中的client不会更改header.Host，所以不能用原来的Host
			req.Header.Add(string(key), string(value))
		}
	})

httpclient

httpclient请求最终发送的 Host header 并不是取自 req.Header[“Host”]，而是由 req.Host 字段决定，如果 req.Host 为空，则默认为 req.URL.Host。

所以说虽然我一开始直接把原始的、错误的 Host header 复制了过去，但是httpclient对请求的 Host header 进行了替换，没有用我设置的 Host header ，所以并没有出现问题。

hertzclient

hertzclient最后发送的 Host header 就是取自 req.Header[“Host”] 的，所以说当我将原来的 request.header.host 写到新请求中后，hertzclient发送请求直接使用的是我设置的 Host header ，所以出现404的问题。

如果说依然使用完整复制的方法，在最后需要用req.Header.SetHost()替换原始的、错误的 Host header 。注意不是req.SetHost()，这个方法是设置建立连接的主机地址。

Host header作用

那话说回来，为什么使用错误的Host header会出现404的问题呢？Host header究竟是起到什么样的作用呢？

当一个网络请求发出去之后，网址会经过DNS解析为ip地址并建立连接，当连接到服务器后，则会用到 Host header 进行虚拟主机分流。

而虚拟主机（Virtual Host）是一种服务器技术，它允许在同一台物理服务器（同一个IP地址）上运行多个网站。换句话说，你可以用一台服务器托管多个不同域名的网站，而不需要每个网站都分配一个独立的服务器。区分用户到底访问的是哪个网站的方式就是使用 Host header 进行分流。

总体来说，一个请求的流程是：域名 → DNS 解析 → IP 地址 → 建立 TCP/SSL 连接 → 发送 HTTP 请求头 (Host) → 虚拟主机分流。

这里举一个Nginx配置规则进行分流的例子：

server {
 listen 80;
 server_name www.example.com;
 root /var/www/example;
}

server {
 listen 80;
 server_name www.test.com;
 root /var/www/test;
}

listen 80; → 表示监听 HTTP 默认端口 80。
server_name → 表示这个虚拟主机匹配的域名。
root → 表示网站的根目录，也就是请求 / 时返回的文件位置。

Nginx 的分流步骤可以总结为：

根据端口匹配 server 块

这里两个 server 都监听 80，所以都在候选列表中。

根据 Host 匹配 server_name

Nginx 会查找与请求 Host 最匹配的 server 块。

匹配成功 → 使用该 server 块的 root 和配置处理请求
没有匹配 → 使用默认 server

Nginx 会选择 listen 指令中第一个或 default_server 标记的 server 作为默认返回。

在 Golang 中复用 HTTP 连接

Wed, 20 Aug 2025 16:31:52 +0800

问题提出

最近在实现一个转发大模型调用请求的中转功能，涉及到要构造client发送请求的内容，一开始我每次都是新建一个client来发送请求，这样的代码实现存在一些问题——每次都要构造新的client，并且要重新建立连接。后面了解到在Go中使用 HTTP 客户端（http.Client）可以实现连接复用，做到提高性能并减少 TCP 连接的重复建立。

// 原始做法
client := &http.Client{
		Timeout: consts.GetRequestTimeout(), // 设置请求超时时间
	}
	resp, err := client.Do(req)
defer resp.Body.Close()

// 修改后做法
resp, err := sharedHttpClient.Do(req)
defer resp.Body.Close()// 必须关闭 Body 才能复用连接

原理探寻

在 Go 中，HTTP 客户端默认会复用 TCP 连接，只要使用同一个 http.Client 实例，并且服务端支持 Keep-Alive。

原因是 http.Transport 内部维护了一个 连接池。只要满足以下条件就可以进行连接复用：

使用同一个 http.Client。
响应的 Body 被正确关闭。
请求的 Host 相同。

Transport 会根据空闲连接数和超时管理复用，可根据需求调整Transport相关的参数。

流式与非流式有什么区别

Wed, 20 Aug 2025 15:59:58 +0800

问题提出

最近在实现一个转发大模型调用请求的中转功能，因为现在的大模型都支持流式与非流式调用，所以我在实现的时候自然而然的想到了要不要区分两种调用方式，使用不同的代码逻辑。一开始写的时候分开了两个调用方式来写，后来发现这两种方式对于服务端来说实际没有区别，重点在于客户端的使用。

原理探寻

首先看一下两种调用方式实际返回的数据。

==== 非流式调用返回 ====
{
 "choices": [
 {
 "finish_reason": "stop",
 "index": 0,
 "logprobs": null,
 "message": {
 "content": "Hello! How can I help you today?",
 "reasoning_content": "用户现在打招呼说Hello!，我要友好回应。所以回复“Hello! How can I help you today?” 这样友好又开放，邀请用户说明需求。",
 "role": "assistant"
 }
 }
 ],
 "created": 1755675226,
 "id": "021755675225006530d45f3e18d6c5c13bff8621e54f4f6ee920a",
 "model": "doubao-1-5-thinking-vision-pro-250428",
 "service_tier": "default",
 "object": "chat.completion",
 "usage": {
 "completion_tokens": 45,
 "prompt_tokens": 70,
 "total_tokens": 115,
 "prompt_tokens_details": {
 "cached_tokens": 0
 },
 "completion_tokens_details": {
 "reasoning_tokens": 36
 }
 }
}

==== 流式调用返回 ====
data: {"choices":[{"delta":{"content":"","reasoning_content":"用户","role":"assistant"},"index":0}],"created":1755675226,"id":"021755675226374530d45f3e18d6c5c13bff8621e54f4f6ec4025","model":"doubao-1-5-thinking-vision-pro-250428","service_tier":"default","object":"chat.completion.chunk","usage":null}

data: {"choices":[{"delta":{"content":"","reasoning_content":"现在","role":"assistant"},"index":0}],"created":1755675226,"id":"021755675226374530d45f3e18d6c5c13bff8621e54f4f6ec4025","model":"doubao-1-5-thinking-vision-pro-250428","service_tier":"default","object":"chat.completion.chunk","usage":null}

...........

data: {"choices":[{"delta":{"content":"","role":"assistant"},"finish_reason":"stop","index":0}],"created":1755675226,"id":"021755675226374530d45f3e18d6c5c13bff8621e54f4f6ec4025","model":"doubao-1-5-thinking-vision-pro-250428","service_tier":"default","object":"chat.completion.chunk","usage":null}

data: [DONE]

可以看出，两种请求返回的格式是不一样的，非流式请求返回的是完整的json，而流式请求则是返回分块的json。

服务端

在服务端的实现中，实际上我们可以不用在意是流式还是非流式，我们可以统一采用流的方法返回请求体，是否真是流式形式实际上是取决于约定的返回格式以及客户端处理方式。

// 设置响应头
	for k, v := range resp.Header {
		for _, vv := range v {
			c.Header(k, vv)
		}
	}
	// 设置状态码
	c.Status(resp.StatusCode)

	// 流式转发响应体
	_, err = io.Copy(c.Response.BodyWriter(), resp.Body)
	if err != nil {
		// 处理错误
		hlog.CtxErrorf(ctx, "Error copying response body: %v", err)
		c.String(http.StatusInternalServerError, "Error copying response body: %v", err)
		return
	}

当然，由于我们此处是实现转发的功能，因此可以采用统一的方式。在原始的返回代码中，实际上会有些不同。

//----------非流式输出：传统请求处理----------//
app.get('/api/user-data', (req, res) => {
 // 同步获取所有数据（可能造成阻塞）
 const userData = fetchUserDataFromDB();
 const analytics = generateUserAnalytics(userData);
 const preferences = getUserPreferences(userData.id);
 
 // 一次性返回完整JSON
 res.json({ 
 userData, 
 analytics,
 preferences
 });
});

//----------流式输出：实时数据分块传输----------//
app.get('/api/real-time-updates', (req, res) => {
 // 1. 设置流式响应头
 res.setHeader('Content-Type', 'text/event-stream');
 res.setHeader('Cache-Control', 'no-cache');
 res.setHeader('Connection', 'keep-alive');
 
 // 2. 立即发送初始数据
 res.write('event: init\ndata: Connection established\n\n');
 
 // 3. 创建数据流
 const dataStream = createRealTimeDataStream();
 
 // 4. 分块发送数据
 dataStream.on('data', (chunk) => {
 res.write(`data: ${JSON.stringify(chunk)}\n\n`);
 });
 
 // 5. 处理连接关闭
 req.on('close', () => {
 dataStream.destroy();
 res.end();
 });
});

客户端

客户端的处理方式就是有明显分别了。

//----------非流式输出：传统请求处理（传统Fetch API使用）----------//
async function loadUserData() {
 try {
 const response = await fetch('/api/user-data');
 const fullData = await response.json();
 
 // 一次性渲染所有数据
 renderUserProfile(fullData.userData);
 renderAnalytics(fullData.analytics);
 updatePreferencesUI(fullData.preferences);
 
 } catch (error) {
 showErrorToast('Failed to load data');
 }
}

//----------流式输出：实时数据处理技术（使用EventSource）----------//
const eventSource = new EventSource('/api/real-time-updates');

eventSource.addEventListener('init', (event) => {
 showConnectionStatus('Connected to real-time feed');
});

eventSource.onmessage = (event) => {
 const data = JSON.parse(event.data);
 updateLiveDashboard(data);
};

eventSource.onerror = () => {
 showConnectionStatus('Connection lost - attempting to reconnect...');
 eventSource.close();
};

参考资料

流式输出 vs 非流式输出 - 技术栈

DNS与CDN的区别?

Sun, 04 May 2025 00:21:28 +0800

问题起因

在使用Cloudflare的过程中，接触到了DNS的相关内容，于是查找资料。然后在自己的个人网站上因为有使用jsDelivr的CDN服务，于是便有了疑惑——用户在访问网站时，DNS与CDN是怎样的一个解析过程，他们之间有什么区别？

DNS解析

什么是DNS？

DNS（Domain Name System）是互联网的域名解析系统，它的作用是将人们易记的域名（如 www.example.com）转换为计算机可识别的 IP 地址，从而让用户通过域名访问网站。DNS 由多个分层服务器组成，包括根服务器、顶级域服务器和权威服务器，整个解析过程类似查电话号码的过程，是互联网通信的基础服务之一。

为什么需要 DNS？

你可以记住 www.baidu.com，但很难记住 220.181.38.148
网站的 IP 地址可能会变，但域名不会变
DNS 让用户用域名访问网站，而不是记 IP 地址

DNS 的核心工作机制

用户输入域名（如 www.example.com）
浏览器向本地 DNS 服务器请求 IP 地址
如果本地没有缓存，就逐级向上查询：

根 DNS 服务器

顶级域（.com）
权威 DNS 服务器（负责 example.com）
找到 IP 后，返回给浏览器
浏览器用这个 IP 去访问目标服务器

常见 DNS 类型

记录类型	作用
A	将域名解析为 IPv4 地址
AAAA	将域名解析为 IPv6 地址
CNAME	将域名指向另一个域名
MX	邮件服务器地址
TXT	文本记录（比如 SPF、验证用）

CDN加速

什么是CDN？

CDN（Content Delivery Network，内容分发网络）是一种通过分布在全球各地的边缘节点，将网站内容缓存并分发给用户的技术，目的是加快访问速度、降低服务器压力，并提升用户体验。当用户访问网站时，CDN 会将请求引导到距离用户最近的节点，从而实现更快、更稳定的内容加载。

为什么需要 CDN？

CDN 解决的是“距离远、访问慢、负载高”的问题，主要有以下几个方面的需求：

需求	说明
⏱ 提高访问速度	缩短用户与服务器之间的物理距离，减少网络延迟
🌎 提升全球可访问性	跨国/跨地区访问网站时更稳定
📉 减轻源站服务器压力	边缘节点承担大部分访问请求，避免源站过载
🔐 增强安全性	隐藏源站 IP、防御 DDoS 攻击
📶 提升可用性和稳定性	某个节点故障时，可自动切换其他节点不中断服务

CDN 的工作机制

内容分发：

网站将资源（如图片、JS、CSS、视频等）通过 CDN 平台分发并缓存到全球各地的节点（边缘服务器）

DNS 解析调度：

用户访问网站时，CDN 的 DNS 系统会将用户请求调度到最优的 CDN 节点（基于距离、负载、网络状态等）

内容访问：

如果边缘节点已有缓存资源，直接返回

如果没有缓存，则回源站获取后缓存，并返回给用户（下次访问就命中缓存）

CDN 是通过“就近访问 + 智能调度 + 分布式缓存”来提升网站访问速度、稳定性和安全性的加速服务。

完整流程

（1）用户访问域名 www.huawei.com 递归交给本地域名服务器去负责查询。
（2）本地域名服务器经过迭代查询由 huawei.com 的域名服务器返回CNAME解析到的地址 www.huawei.com.akadns.net。
（3）本地域名服务器去迭代查询 www.huawei.com.akadns.net 经过dig +trace 命令追踪发现又经过一次CNAME到 www.huawei.com.lxdns.com ，具体原因没有深究，暂且认为此 www.huawei.com.lxdns.com 为真正的CDN DNS域名服务器地址；本地域名服务器再次去迭代查询 www.huawei.com.lxdns.com 的IP地址。
（4）经过DNS全局负载均衡和区域负载均衡等一系列的智能调度，分配CDN节点，确定 www.huawei.com.lxdns.com 的IP地址。

全局负载均衡设备根据用户IP地址，以及用户请求的内容URL，选择一台用户所属区域的区域负载均衡设备。

区域负载均衡设备会为用户选择一台合适的缓存服务器提供服务，选择的依据包括：根据用户IP地址，判断哪一台服务器距用户最近；根据用户所请求的URL中携带的内容名称，判断哪一台服务器上有用户所需内容；查询各个服务器当前的负载情况，判断哪一台服务器尚有服务能力。基于以上这些条件的综合分析之后，区域负载均衡设备会向全局负载均衡设备返回一台缓存服务器的IP地址。
（5）返回CDN server（CDN节点）的IP地址。
（6）返回CDN域名 www.huawei.com.lxdns.com 的IP地址。
（7）返回 www.huawei.com 对应 CDN域名 www.huawei.com.lxdns.com 的IP地址
（8）用户访问 www.huawei.com.lxdns.com 的IP地址对应的CDN server（CDN 节点），如果有缓存则直接到步骤11返回数据。如果没有则进行步骤9回源，再到步骤10，再到步骤11，返回数据。

一些疑问

如果cdn的记录是cname，是不是还要再解析成ip

CNAME 记录指的是把一个域名指向另一个域名。客户端（比如浏览器）在解析你的域名（如 www.example.com）时，发现它是 CNAME 到另一个域名（如 cdn.vendor.com）。然后，客户端会继续解析 cdn.vendor.com，直到拿到最终的 A记录（IP 地址）。最终访问仍然是通过 IP 地址完成的，只是中间多了一个跳转。

但要注意，解析过程中的所有域名查询（包括 CDN 的 CNAME）都是向 DNS 服务器发出的，而不是向 CDN 本身发出的。

域名解析只与 DNS 服务器打交道，不和 CDN 本身通信。

我没有配置相关DNS解析记录，为什么我的个人网站还能使用了jsDelivr的CDN服务

你不是通过你的域名调用 jsDelivr，而是直接用 jsDelivr 的域名。

举个例子，在 WordPress 的后台或插件里，引用的通常是类似这样的链接：

https:&#47;&#47;cdn.jsdelivr.net/npm/jquery@3.6.0/dist/jquery.min.js

这条链接的域名是：

cdn.jsdelivr.net

也就是说：你根本没有把你自己的网站域名（如 example.com）CNAME 到 jsDelivr，而是直接在代码中使用了 jsDelivr 的 CDN 域名。

访问的流程如下：

你的 WordPress 网站访问 cdn.jsdelivr.net
浏览器向 公共 DNS 服务器 发起解析请求（比如 8.8.8.8）
DNS 服务器向 jsDelivr 的权威 DNS 查询
jsDelivr 返回就近 CDN 节点的 IP（通过它的 DNS 调度）
浏览器拿到 IP → 访问 CDN 节点 → 获取资源

你的网站并没有“配置” DNS，因为：

你只是“调用”了 jsDelivr 提供的链接
域名解析这件事交由浏览器和 jsDelivr 自己去处理了

情况	是否需要你配置 DNS
你用自己的域名接入 CDN（比如 www.example.com CNAME 到 yourcdn.example.net）	✅ 需要配置 DNS
你直接引用 CDN 提供的公共链接（如 cdn.jsdelivr.net）	❌ 不需要配置 DNS

你如果以后想让你自己的网站资源也通过 CDN 加速（比如图片、CSS、JS），那就要配置你自己域名的 CNAME 指向 CDN 节点了。

配置cdn一般都是通过dns吗，还有什么其他方法吗

是的，绝大多数情况下，配置 CDN 是通过 DNS 来实现的，但它并不是唯一的方式。下面是完整的解释和对比：

一、主流方式：通过 DNS 配置 CDN（最常见）

这是目前绝大多数网站接入 CDN 的标准做法。

原理：

你把你自己的网站域名（比如 www.example.com）的 DNS 记录改为：

CNAME → cdn.example.cdnprovider.com

或者如果是根域名（不支持 CNAME）：

A 记录 → CDN 厂商提供的负载均衡 IP（如 Cloudflare 的 Anycast IP）

特点：

适用于大部分 CDN 提供商（如 Cloudflare、阿里云 CDN、腾讯云 CDN、Akamai、jsDelivr 等）
支持智能调度
一般用户看不到 CDN 的存在

二、其他方式（不通过 DNS）也有，但相对少见：

1. 直接使用 CDN 提供的 URL

举例：

适用：

公共库/资源
不想改自己域名的 DNS

缺点：

域名不是你自己的，缓存行为和品牌一致性无法控制

2. 反向代理方式接入 CDN

一些特殊情况，可以让 CDN 厂商作为反向代理直接部署在源站前，但这通常是：

企业内网、私有部署
定制的 CDN 网络
安全/合规特殊场景

这通常不通过 DNS，而是由 CDN 提供的边界设备（比如云防护墙）或专线统一接入。

3. 通过 Web 应用接入（插件或中间件）

例如：

WordPress 安装某个插件后自动为图片加上 CDN 前缀
Web 应用自动切换资源路径，如从 /static/ → https://cdn.yourdomain.com/static/

这种方式不依赖 DNS，而是代码层配置资源路径实现 CDN 加速。

总结：

接入方式	是否通过 DNS	是否常用	说明
修改 CNAME/A 记录	✅ 是	⭐ 非常常用	最标准的接入方式
直接用 CDN 链接	❌ 否	✅ 较常用	用于公共库，不影响你自己的域名
反向代理模式	❌ 否	❗ 少数企业使用	高级部署方式，成本较高
应用层插件/CDN 前缀	❌ 否	✅ 在某些框架中常用	控制静态资源路径即可，不依赖 DNS

参考资料

20分钟理解什么是网络、DNS与CDN - 知乎

DNS解析与CDN加速-CSDN博客

正向代理和反向代理

Sat, 03 May 2025 23:57:34 +0800

正向代理 vs 反向代理：核心区别

特性	正向代理（Forward Proxy）	反向代理（Reverse Proxy）
📌 代理的对象	代理客户端（用户）访问目标服务器	代理服务端（源站）响应外部请求
🎯 主要用途	客户端访问内部或受控网络资源，缓存优化	实现负载均衡、隐藏后端、统一入口、安全防护
🛠 配置位置	客户端或客户端网关	服务器端或网络边缘设备
🌍 真实服务器	用户试图访问的目标服务器（如内部业务接口）	后端应用服务器（如 Web 服务、API 服务等）
🔒 隐藏谁的身份	隐藏客户端身份	隐藏服务端身份
🗺 常见用途	内网访问控制、缓存加速、日志审计、流量统一出口	负载均衡、CDN、服务网关、应用防火墙（WAF）等
🌐 举例	企业出网网关代理、Squid、局域网 Web 缓存服务器	Nginx 反向代理、CDN 边缘节点、WAF 安全设备等

一句话区别：正向代理服务于客户端，反向代理服务于服务端。

正向代理：帮用户访问外部内容

🎯 举例场景：

员工（在公司内网）→ 配置正向代理服务器（如 Squid）→ 访问公司外部业务系统或 API（如 Salesforce）→ 响应数据返回 → 代理服务器转发给员工电脑 ✅ 你是主动用代理“出门”访问别人

📌 常见用途：

控制与审计出网流量
加速常用资源访问（通过缓存）
实现用户访问权限限制

反向代理：帮服务器隐藏/控制外部访问

🎯 举例场景：

用户 → 访问 www.example.com（其实是访问 CDN 或 Nginx）→ 代理判断请求 → 转发到后端服务器处理 → 返回内容 ✅ 你是访问“前台”，它替你决定后面由谁来服务

📌 常见用途：

负载均衡
CDN（其实就是分布式反向代理）
隐藏真实源站 IP
安全过滤（WAF）
HTTPS 统一入口

端口被占用的问题——Hyper-V

Wed, 30 Apr 2025 20:30:51 +0800

问题描述

在端口被占用时，用命令查看占用的程序。但是没有结果输出，代表没有程序在占用。（实际上是“没有程序在此刻占用这个端口，但不排除有程序在随机保留着这个端口”）

netstat -ano | findstr ":7890"

这是因为电脑开启了 Hyper-V ，它会保留一部分 TCP/IP 端口供其虚拟交换机使用，这可能导致某些应用程序无法绑定到这些端口。我们可以用以下命令查看其保留的端口。

# 查看 Hyper-v 启动后的保留端口范围
netsh interface ipv4 show excludedportrange protocol=tcp

临时解决方案——排除单个端口（重启可能失效）

以管理员身份运行 PowerShell 或 CMD
停止 Hyper-V 相关服务：net stop winnat
手动添加端口排除（例如释放 7890）：netsh int ipv4 delete excludedportrange protocol=tcp startport=7890 numberofports=1

protocol=tcp（或 udp）

startport=7890（你要释放的端口）
numberofports=1（只释放 1 个端口）
重启 WinNAT 服务（恢复网络）：net start winnat
验证是否成功：netsh int ipv4 show excludedportrange protocol=tcp | findstr "7890"

如果无输出，说明 7890 已不再被保留，可以正常使用。

⚠️ 注意：

重启后可能失效，因为 Hyper-V 可能会重新占用该端口。
如果仍然无法使用，可能是其他服务占用了该端口（用 netstat -ano | findstr "50000" 检查）。

Socket（套接字）通信原理

Thu, 27 Feb 2025 11:25:14 +0800

一、Socket是什么

Socket 的中文翻译过来就是“套接字”。套接字是什么，我们先来看看它的英文含义：插座。

Socket 就像一个电话插座，负责连通两端的电话，进行点对点通信，让电话可以进行通信，端口就像插座上的孔，端口不能同时被其他进程占用。而我们建立连接就像把插头插在这个插座上，创建一个 Socket 实例开始监听后，这个电话插座就时刻监听着消息的传入，谁拨通我这个“IP 地址和端口”，我就接通谁。

实际上，Socket 是在应用层和传输层之间的一个抽象层，它把 TCP/IP 层复杂的操作抽象为几个简单的接口，供应用层调用实现进程在网络中的通信。Socket 起源于 UNIX，在 UNIX 一切皆文件的思想下，进程间通信就被冠名为文件描述符（file descriptor），Socket 是一种“打开—读/写—关闭”模式的实现，服务器和客户端各自维护一个“文件”，在建立连接打开后，可以向文件写入内容供对方读取或者读取对方内容，通讯结束时关闭文件。

另外我们经常说到的Socket 所在位置如下图：

二、Socket有哪些类型

世界上有很多种套接字（socket），比如 DARPA Internet 地址（Internet 套接字）、本地节点的路径名（Unix套接字）、CCITT X.25地址（X.25 套接字）等。我们只介绍第一种套接字——Internet 套接字，它是最具代表性的，也是最经典最常用的。以后我们提及套接字，指的都是 Internet 套接字。

根据数据的传输方式，可以将 Internet 套接字分成两种类型。

流格式套接字（SOCK_STREAM）

流格式套接字（Stream Sockets）也叫“面向连接的套接字”，是一种可靠的、双向的通信数据流，数据可以准确无误地到达另一台计算机，如果损坏或丢失，可以重新发送。

其特点：

数据在传输过程中不会消失；
数据是按照顺序传输的；
数据的发送和接收不是同步的（有的教程也称“不存在数据边界”）。

可以将 SOCK_STREAM 比喻成一条传送带，只要传送带本身没有问题（不会断网），就能保证数据不丢失；同时，较晚传送的数据不会先到达，较早传送的数据不会晚到达，这就保证了数据是按照顺序传递的。

为什么流格式套接字可以达到高质量的数据传输呢？这是因为它使用了 TCP 协议（The Transmission Control Protocol，传输控制协议），TCP 协议会控制你的数据按照顺序到达并且没有错误。

你也许见过 TCP，是因为你经常听说“TCP/IP”。TCP 用来确保数据的正确性，IP（Internet Protocol，网络协议）用来控制数据如何从源头到达目的地，也就是常说的“路由”。

那么，“数据的发送和接收不同步”该如何理解呢？

假设传送带传送的是水果，接收者需要凑齐 100 个后才能装袋，但是传送带可能把这 100 个水果分批传送，比如第一批传送 20 个，第二批传送 50 个，第三批传送 30 个。接收者不需要和传送带保持同步，只要根据自己的节奏来装袋即可，不用管传送带传送了几批，也不用每到一批就装袋一次，可以等到凑够了 100 个水果再装袋。

流格式套接字的内部有一个缓冲区（也就是字符数组），通过 socket 传输的数据将保存到这个缓冲区。接收端在收到数据后并不一定立即读取，只要数据不超过缓冲区的容量，接收端有可能在缓冲区被填满以后一次性地读取，也可能分成好几次读取。

也就是说，不管数据分几次传送过来，接收端只需要根据自己的要求读取，不用非得在数据到达时立即读取。传送端有自己的节奏，接收端也有自己的节奏，它们是不一致的。

流格式套接字有什么实际的应用场景吗？浏览器所使用的 http 协议就基于面向连接的套接字，因为必须要确保数据准确无误，否则加载的 HTML 将无法解析。

数据报格式套接字（SOCK_DGRAM）

数据报格式套接字（Datagram Sockets）也叫“无连接的套接字”。计算机只管传输数据，不作数据校验，如果数据在传输中损坏，或者没有到达另一台计算机，是没有办法补救的。也就是说，数据错了就错了，无法重传。

因为数据报套接字所做的校验工作少，所以在传输效率方面比流格式套接字要高。

有以下特征：

强调快速传输而非传输顺序；
传输的数据可能丢失也可能损毁；
限制每次传输的数据大小；
数据的发送和接收是同步的

众所周知，速度是快递行业的生命。用摩托车发往同一地点的两件包裹无需保证顺序，只要以最快的速度交给客户就行。这种方式存在损坏或丢失的风险，而且包裹大小有一定限制。因此，想要传递大量包裹，就得分配发送。

另外，用两辆摩托车分别发送两件包裹，那么接收者也需要分两次接收，所以“数据的发送和接收是同步的”；换句话说，接收次数应该和发送次数相同。

总之，数据报套接字是一种不可靠的、不按顺序传递的、以追求速度为目的的套接字。

数据报套接字也使用 IP 协议作路由，但是它不使用 TCP 协议，而是使用 UDP 协议（User Datagram Protocol，用户数据报协议）。

QQ 视频聊天和语音聊天就使用 SOCK_DGRAM 来传输数据，因为首先要保证通信的效率，尽量减小延迟，而数据的正确性是次要的，即使丢失很小的一部分数据，视频和音频也可以正常解析，最多出现噪点或杂音，不会对通信质量有实质的影响。

注意：SOCK_DGRAM 没有想象中的糟糕，不会频繁的丢失数据，数据错误只是小概率事件。

三、Socket通信过程

Socket 保证了不同计算机之间的通信，也就是网络通信。对于网站，通信模型是服务器与客户端之间的通信。两端都建立了一个 Socket 对象，然后通过 Socket 对象对数据进行传输。通常服务器处于一个无限循环，等待客户端的连接。

下面是面向连接的 TCP 时序图：

客户端过程

客户端的过程比较简单，创建 Socket，连接服务器，将 Socket 与远程主机连接（注意：只有 TCP 才有“连接”的概念，一些 Socket 比如 UDP、ICMP 和 ARP 没有“连接”的概念），发送数据，读取响应数据，直到数据交换完毕，关闭连接，结束 TCP 对话。

import socket
import sys

if __name__ == '__main__':
 sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # 创建 Socket 连接
 sock.connect(('127.0.0.1', 8001)) # 连接服务器
 while True:
 data = input('Please input data:')
 if not data:
 break
 try:
 sock.sendall(data)
 except socket.error as e:
 print('Send Failed...', e)
 sys.exit(0)
 print('Send Successfully')

 res = sock.recv(4096) # 获取服务器返回的数据，还可以用 recvfrom()、recv_into() 等
 print(res)
 sock.close()

sock.sendall(data) 这里也可用 send() 方法：不同在于 sendall() 在返回前会尝试发送所有数据，并且成功时返回 None，而 send() 则返回发送的字节数量，失败时都抛出异常。

服务端过程

服务端先初始化 Socket，建立流式套接字，与本机地址及端口进行绑定，然后通知 TCP，准备好接收连接，调用 accept() 阻塞，等待来自客户端的连接。如果这时客户端与服务器建立了连接，客户端发送数据请求，服务器接收请求并处理请求，然后把响应数据发送给客户端，客户端读取数据，直到数据交换完毕。最后关闭连接，交互结束。

import socket
import sys

if __name__ == '__main__':
 sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # 创建 Socket 连接（TCP）
 print('Socket Created')

 try:
 sock.bind(('127.0.0.1', 8001)) # 配置 Socket，绑定 IP 地址和端口号
 except socket.error as e:
 print('Bind Failed...', e)
 sys.exit(0)

 sock.listen(5) # 设置最大允许连接数，各连接和 Server 的通信遵循 FIFO 原则

 while True: # 循环轮询 Socket 状态，等待访问
 conn, addr = sock.accept()
 try:
 conn.settimeout(10) # 如果请求超过 10 秒没有完成，就终止操作

 # 如果要同时处理多个连接，则下面的语句块应该用多线程来处理
 while True: # 获得一个连接，然后开始循环处理这个连接发送的信息
 data = conn.recv(1024)
 print('Get value ' + data, end='\n\n')
 if not data:
 print('Exit Server', end='\n\n')
 break
 conn.sendall('OK') # 返回数据
 except socket.timeout: # 建立连接后，该连接在设定的时间内没有数据发来，就会引发超时
 print('Time out')

 conn.close() # 当一个连接监听循环退出后，连接可以关掉
 sock.close()

conn, addr = sock.accept()

调用 accept() 时，Socket 会进入waiting状态。客户端请求连接时，方法建立连接并返回服务器。accept() 返回一个含有两个元素的元组 (conn, addr)。第一个元素 conn 是新的 Socket 对象，服务器必须通过它与客户端通信；第二个元素 addr 是客户端的 IP 地址及端口。

data = conn.recv(1024)

接下来是处理阶段，服务器和客户端通过 send() 和 recv() 通信（传输数据）。服务器调用 send()，并采用字符串形式向客户端发送信息，send() 返回已发送的字符个数。服务器调用 recv() 从客户端接收信息。调用 recv() 时，服务器必须指定一个整数，它对应于可通过本次方法调用来接收的最大数据量。recv() 在接收数据时会进入blocked状态，最后返回一个字符串，用它表示收到的数据。如果发送的数据量超过了 recv() 所允许的，数据会被截短。多余的数据将缓冲于接收端，以后调用 recv() 时，会继续读剩余的字节，如果有多余的数据会从缓冲区删除（以及自上次调用 recv() 以来，客户端可能发送的其它任何数据）。传输结束，服务器调用 Socket 的 close() 关闭连接。

四、从 TCP 连接的视角看 Socket 过程

TCP 三次握手的 Socket 过程

服务器调用 socket()、bind()、listen() 完成初始化后，调用 accept() 阻塞等待；
客户端 Socket 对象调用 connect() 向服务器发送了一个 SYN 并阻塞；
服务器完成了第一次握手，即发送 SYN 和 ACK 应答；
客户端收到服务端发送的应答之后，从 connect() 返回，再发送一个 ACK 给服务器；
服务器 Socket 对象接收客户端第三次握手 ACK 确认，此时服务端从 accept() 返回，建立连接。

接下来就是两个端的连接对象互相收发数据。

TCP 四次挥手的 Socket 过程

某个应用进程调用 close() 主动关闭，发送一个 FIN；
另一端接收到 FIN 后被动执行关闭，并发送 ACK 确认；
之后被动执行关闭的应用进程调用 close() 关闭 Socket，并也发送一个 FIN；
接收到这个 FIN 的一端向另一端 ACK 确认。

说明：上面的服务端代码只有处理完一个客户端请求才会去处理下一个客户端的请求，这样的服务器处理能力很弱，而实际中服务器都需要有并发处理能力，为了达到并发处理，服务器就需要 fork 一个新的进程或者线程去处理请求。

五、Socket常用函数接口及其原理

图解socket函数：

参考文章

Socket（套接字）通信原理 - codedot - 博客园

Socket技术详解（一篇就够了）-CSDN博客