这一章进入第十二阶段的第一篇，主题是网络请求入门：先搞懂客户端和服务器。

很多人一听到爬虫、接口、抓网页，就会下意识觉得这是一块很技术、很复杂、很容易劝退的内容。

其实真正让人混乱的，往往不是代码本身。 而是还没先把最底层的通信关系想明白。

你在浏览器里输入一个网址，为什么页面会出来 你点一下登录按钮，账号密码是怎么发出去的 你刷新一次页面，为什么内容会重新加载 你在手机上刷资讯、看天气、点外卖，这些数据到底从哪里来

这些问题，背后都离不开同一件事：

网络请求。

所以这一章非常重要。

从这一章开始，我们要进入一个新阶段。 这个阶段不再只是处理本地数据，而是开始接触程序和外部世界的连接方式。

而在真正写 requests 代码之前，你必须先搞懂两个最核心的角色：

客户端 服务器

这两个概念一旦理顺，后面很多原本看起来发蒙的词，都会一下子变得顺眼很多。

一、什么叫网络请求

先把这个词说得最直白一点。

所谓网络请求，你可以理解成：

一个程序通过网络，向另一个程序要数据，或者提交数据。

比如你打开浏览器，访问某个网页。 浏览器会向远端服务器发出请求，问一句：

这个页面的内容给我。

服务器收到后，会把页面内容返回给浏览器。 浏览器再把这些内容显示成你看到的网页。

这整个过程，就是一次最典型的网络请求。

所以网络请求并不神秘。 它本质上就是程序和程序之间，通过网络进行交流。

一个发请求。 一个收请求并给回应。

你可以把它想成发消息和回消息。 只不过说话的不是人，而是程序。

二、为什么学爬虫之前，必须先理解客户端和服务器

因为后面你写爬虫、调接口、抓数据，所有动作本质上都绕不开这两个角色。

你自己的 Python 程序，在大多数场景下扮演的是客户端。 你要抓数据的网站、接口服务、远程应用，扮演的是服务器。

客户端负责发起请求。 服务器负责接收请求，然后把结果返回回来。

如果你连谁在发、谁在收、谁在回都没搞清楚，那后面看到一堆术语时，就很容易只剩死记硬背。

比如：

请求头是什么 响应体是什么 状态码是什么意思 参数为什么要放在 URL 后面 登录为什么要带 Cookie 接口为什么返回 JSON

这些词看起来很多，但它们全都围绕同一条主线展开：

客户端怎么向服务器说话 服务器又是怎么回应客户端的

所以这一章其实不是技术绕圈子。 而是在给后面所有网络请求相关内容打地基。

三、客户端到底是什么

很多人会误以为，客户端一定是某个专门的软件。

其实不是。

只要一个程序主动向别的服务发起请求，它就可以叫客户端。

最常见的客户端有这些：

浏览器是客户端 手机 App 是客户端 你写的 Python 爬虫脚本，也是客户端 微信小程序、本地桌面软件，很多时候也都是客户端

比如你在 Chrome 浏览器里访问新闻网站。 这时浏览器就是客户端。

比如你用手机打开天气 App，天气数据从服务器拉回来。 这时 App 就是客户端。

比如你后面用 requests.get() 抓一个网页。 这时你的 Python 程序也是客户端。

所以客户端不等于“装在电脑里的某个窗口软件”。 更准确地说，客户端指的是：

主动发起请求的一方。

这一点你一定要记住。 因为它是后面理解整个请求流程的第一块基石。

四、服务器又是什么

如果说客户端是主动开口问问题的一方，那服务器就是负责接收请求、处理请求、返回结果的一方。

例如：

你访问百度，百度背后的机器集群就是服务器 你登录某个网站，校验账号密码的远程服务就是服务器 你点开一条资讯，返回文章内容的后台系统也是服务器

服务器不只是“存文件的电脑”。 它更像一个一直在线、随时待命的服务者。

它的工作通常包括：

接收客户端请求 看客户端想要什么 按规则处理 把结果返回回去

比如你访问一个商品详情页。

客户端会说： 我要看商品 5001 的详细信息。

服务器收到后，就去查数据库、组装内容，然后返回给客户端。

所以服务器的重点不是“机器很大”。 而是它承担了提供服务、处理请求、返回数据的职责。

你也可以简单理解成：

客户端负责提需求 服务器负责给结果

五、先用一个生活类比，把客户端和服务器彻底讲透

为了让这个概念更扎实，我们用餐厅来类比。

你去饭店吃饭。

你是顾客，相当于客户端。 后厨和出餐系统，相当于服务器。

你点一份番茄牛腩饭。 这就是你发出请求。

服务员把你的需求带给后厨。 后厨处理完，再把饭端回来。 这就是服务器响应。

这个过程里，有几个点特别像网络请求：

你要先提出需求 后厨要按你的需求处理 处理完之后才有结果返回 如果菜卖完了，后厨会告诉你没有 如果厨师太忙，你可能要等一会儿

这和网络请求几乎是一个逻辑。

客户端不是自己凭空变出数据。 它得向服务器请求。 服务器也不是无条件全部满足。 它得看资源、规则、权限、当前状态。

所以当你把客户端和服务器理解成“提需求的一方”和“提供结果的一方”，很多事情就自然了。

六、浏览器访问网页时，到底发生了什么

这个问题特别值得你想明白。

假设你在浏览器地址栏里输入一个网址，然后按下回车。

表面上看，你只是打开了一个网页。 但背后其实发生了一整串动作。

第一步，浏览器发现你要访问某个地址。 第二步，它会向对应服务器发出请求。 第三步，服务器收到请求后，开始处理。 第四步，服务器把结果返回给浏览器。 第五步，浏览器把结果解析并显示成页面。

这个返回结果，通常可能包括：

HTML 页面结构 CSS 样式文件 JavaScript 脚本 图片资源 接口返回的数据

所以你眼里看到的是一个完整网页。 但从程序通信角度看，它本质上是客户端和服务器之间的一次次数据交换。

也正因为这样，后面你学爬虫时，才会慢慢明白：

你不是在“偷偷复制网页”。 你其实是在模拟客户端，向服务器发请求，再拿回它返回的数据。

七、什么叫请求，什么叫响应

这是网络请求里最核心的一组词。

请求，就是客户端发出去的话。 响应，就是服务器回过来的话。

举个最简单的例子。

你访问某个网址。

浏览器发出去的是请求。 服务器返回页面内容，这就是响应。

再比如你提交登录表单。

浏览器发出去的是账号和密码。 服务器返回登录成功或失败，这就是响应。

所以请求和响应，本质上是一问一答。

客户端说： 我想访问这个地址 我想提交这些数据 我想查这个用户的信息

服务器说： 可以，这是结果 不行，你没有权限 没找到这个资源 服务器忙，请稍后再试

网络编程里，很多概念看起来复杂，其实都只是在描述这组对话的细节。

八、为什么说一切网页、接口、爬虫，最后都绕不开请求和响应

因为无论形式怎么变，底层逻辑几乎都没变。

你打开网页，是请求和响应。 你调用天气接口，是请求和响应。 你抓商品数据，是请求和响应。 你刷短视频，背后一样是请求和响应。

区别只在于：

请求里带了什么内容 响应里返回了什么内容 服务器愿不愿意给你 客户端能不能正确理解返回结果

所以后面你看到网页源码、JSON 数据、状态码、请求头这些东西时，不要把它们拆开孤立看。 它们其实都只是请求和响应这件事里的不同组成部分。

这也是为什么很多人一旦真正理解了客户端和服务器，后面学网络请求会顺很多。

因为他知道所有新名词，最终都要回到这条主线上。

九、客户端请求服务器时，通常会带上什么信息

这个问题特别重要。

因为请求不是一句模糊的话。 它通常会包含很多具体内容。

最基本的，当然是请求地址。 你总得告诉服务器，你想访问哪一个资源。

除此之外，还可能包含：

请求方法 请求参数 请求头 提交的数据 身份信息

比如你访问一个搜索页，可能会带搜索关键词。 比如你提交登录表单，可能会带用户名和密码。 比如你访问个人中心，可能还要带登录状态相关信息。

虽然这些细节我们后面几章会展开讲，但你现在至少要先建立一个整体印象：

客户端发请求时，并不是只说一句“给我数据”就完了。 它通常还得把自己想要什么、带了什么条件、以什么方式请求，说清楚。

十、服务器收到请求后，通常会做什么

服务器也不是接到请求就机械地回一段文本。

它通常会经历一系列处理过程。

比如：

检查这个地址是否存在 判断请求是否合法 看看用户有没有权限 读取数据库 执行业务逻辑 生成返回内容 最后再把结果发回客户端

举个例子。

你访问订单详情页，服务器可能会做这些事：

先确认这个接口存在 再确认你是不是登录用户 再确认你有没有权限看这个订单 然后去数据库查订单信息 查到之后整理成统一格式 最后返回给客户端

所以服务器并不是简单“放数据”的地方。 它更像一个有规则、有判断、有处理流程的服务中心。

这也是为什么很多请求结果不一样。

有时成功。 有时失败。 有时返回空。 有时提示没有权限。

因为服务器不是死板地吐内容。 它是在按规则处理请求。

十一、为什么同一个网址，有时候你能看到内容，有时候却不行

这也是很多新手刚接触爬虫时特别困惑的事。

明明浏览器能打开。 为什么程序抓的时候却不对。

原因往往就在于：

浏览器发出的请求，比你想象的复杂。 而服务器也会根据请求内容决定怎么回应。

比如浏览器可能自动带上了：

用户代理信息 登录状态 Cookie 请求头 缓存信息 来源页信息

而你最开始写的 Python 脚本，可能只是一个最朴素的请求。 服务器一看，就觉得这不是一个正常用户访问，或者你缺少必要信息，于是返回的内容就不一样。

所以你现在先不要急着深究技术细节。 只要先记住一句话：

不是有网址就一定能得到相同结果。 服务器看的不只是地址，还会看整个请求是什么样。

这个认识会对后面学反爬、请求头、Cookie 特别有帮助。

十二、浏览器和 Python 脚本，为什么本质上都能当客户端

因为它们都可以主动发请求。

浏览器擅长的是： 把返回结果显示给人看。 它会自动渲染网页、执行脚本、加载样式和图片。

而 Python 脚本擅长的是： 把返回结果交给程序处理。 比如提取内容、保存文件、清洗数据、做自动化。

所以从本质上说：

浏览器是面向人使用的客户端。 Python 脚本是面向程序处理的客户端。

后面你写爬虫时，很多动作其实就是在做一件事：

让 Python 去模拟浏览器发请求，然后把服务器返回的结果拿回来。

差别只是： 浏览器拿回来之后显示页面。 Python 拿回来之后由你写代码决定怎么处理。

十三、网络请求和本地程序处理，最大的区别是什么

前面你学的大多数东西，主要处理的是本地世界里的数据。

比如本地列表、本地字典、本地文本文件、本地日志。 数据已经在你手里了。 你要做的是整理、提取、统计。

但从这一章开始，数据很多时候不在你电脑里。 它在远端服务器上。

这意味着程序流程会多出一层新的关系：

你不能直接拿到数据。 你得先通过网络把数据请求回来。

这就是网络请求和本地处理最大的区别。

本地处理更像在自己家收拾东西。 网络请求更像要去别人那里拿资料。

你要先敲门，别人愿意给你，你才能拿到。 别人给你的格式、时间、规则，也不完全由你决定。

所以这一阶段的学习重点，会从“本地数据怎么处理”，慢慢扩展到“远程数据怎么获取”。

十四、URL 为什么是网络请求里的第一入口

虽然后面会详细讲请求地址，但你现在可以先建立一个直觉。

客户端要向服务器发请求，至少要知道去哪里找。

这个地址，通常就是 URL。

比如浏览器地址栏里的网址，本质上就是一个 URL。 它告诉客户端：

我要访问哪个站点 哪个路径 可能还带什么参数

所以每一次网络请求，几乎都是从 URL 开始的。

没有地址，客户端根本不知道往哪发。 地址不对，服务器也可能根本找不到资源。

后面你学 requests.get() 时，第一件事就是传 URL。 这不是语法巧合，而是网络请求的本质决定的。

十五、为什么程序员总强调先理解 HTTP，而不是急着写 requests

因为 requests 只是工具。 HTTP 才是规则。

你用浏览器访问网页，通常走的是 HTTP 或 HTTPS。 你用 Python 的 requests 库，底层主要也是在和 HTTP 打交道。

所以后面你看到：

GET POST 状态码 请求头 响应体

这些词，表面上是 requests 会用到的内容。 但本质上，它们都属于 HTTP 这套通信规则。

所以真正有经验的人，学网络请求时不会只背 requests.get() 怎么写。 他会先想明白：

客户端到底在按什么规则和服务器交流。

你现在不需要把 HTTP 细节全部搞懂。 但至少要先知道：

后面的代码不是魔法。 它只是把客户端和服务器之间的交流规则，用程序写出来而已。

十六、一个最简单的网络请求流程，可以怎么理解

你可以把最基础的流程记成四步：

客户端发请求 服务器收请求 服务器处理请求 服务器返回响应

就这么简单。

但为了让这四步更扎实，我们可以换成一个非常具体的例子。

比如你打开天气页面，想查北京天气。

第一步，客户端发请求： 我要北京的天气。

第二步，服务器收到请求： 知道了，你要的是北京。

第三步，服务器处理请求： 去天气数据库里查北京当前天气。

第四步，服务器返回响应： 北京今天晴，气温 26 度。

这就是网络请求最简化的本质。

后面无论页面多复杂、接口多丰富、反爬多绕，底层都是在这个流程上不断增加细节。

十七、为什么说理解客户端和服务器，比记术语更重要

因为术语是会越学越多的。

后面你会看到：

session cookie header body token json api query string status code

如果你一开始没有一个主线，这些词很容易越学越散。

但如果你心里一直抓着这条线：

客户端在发什么 服务器在收什么 服务器为什么这么回 客户端怎么理解这个回应

那后面的所有术语，其实都只是这条线上不同位置的小零件。

所以不要担心自己现在还没接触代码。 真正打基础的时候，先把关系想透，比急着背函数名更值钱。

十八、再用一个真实互联网场景，帮你彻底建立感觉

假设你在电商 App 里刷商品列表。

你一打开首页，客户端就会请求商品列表数据。 你点某个商品，客户端会请求商品详情数据。 你点加入购物车，客户端会提交购物车请求。 你点支付，客户端又会向服务器提交订单和支付相关信息。

整个过程中，App 始终在扮演客户端。 后台系统始终在扮演服务器。

所以你会发现，我们平时使用互联网产品，本质上就是不断在触发网络请求。 只是这些请求平时被 UI 包住了，你感觉不到而已。

而程序员要做的，就是把这些事情看清楚。

一旦看清楚了，后面写爬虫、调接口、抓数据，其实都没那么神秘。

十九、学这一章时，最容易出现的一个误区

就是总想马上知道：

代码怎么写 怎么抓网页 怎么把数据拿下来

这些问题当然重要，但如果你现在跳过底层关系，直接冲到代码层，后面大概率会出现一种情况：

会抄代码，但不知道为什么这么写。

比如你会写：

requests.get(url)

但你脑子里其实没真正明白： 是谁在请求谁，为什么要传 URL，返回的内容是谁给的。

这种学习方式短期看上手快，长期会越学越虚。

所以这一章的意义，恰恰是让你慢一点。 先把通信关系想明白，再往下走。

这一步看似慢，实际会让你后面快很多。

二十、这一章真正要建立的，是一种网络世界的直觉

你以后只要遇到网页、接口、爬虫、登录、数据抓取这些问题，都可以先在脑子里问自己几句：

谁是客户端 谁是服务器 客户端在请求什么 服务器会返回什么 为什么会成功 为什么会失败 是不是请求里少了什么信息

只要这个思维习惯建立起来，你学网络请求就不再只是记代码，而是在理解系统之间的通信。

这会让你后面学 requests、学接口抓取、学反爬时都轻松很多。

本章小结

网络请求，本质上是程序和程序之间通过网络进行交流。

在这套关系里：

客户端是主动发起请求的一方。 服务器是接收请求、处理请求、返回结果的一方。

浏览器、手机 App、Python 脚本，很多时候都可以是客户端。 网站后台、接口服务、数据服务，很多时候都在扮演服务器。

你打开网页、提交表单、查天气、刷资讯，这些动作背后，本质上都是客户端向服务器发请求，服务器再返回响应。

学这一章，最重要的不是记住多少术语。 而是先建立一个非常清楚的底层认知：

网页不是凭空出来的。 数据不是自动出现在你面前的。 一切内容，几乎都来自一次次客户端和服务器之间的请求与响应。

只要这个认知建立起来，后面学 requests、学抓网页、学接口调用，就会顺得多。

课后思考

第一，试着回想一下你平时打开一个网页、刷新一次页面、提交一次表单，这三种动作背后，客户端和服务器分别在做什么。

第二，试着观察你手机上的一个 App，比如天气、地图、外卖、短视频，想想它在什么时刻一定会向服务器发请求。

第三，试着用自己的话解释这句话： 浏览器和 Python 脚本虽然长得不一样，但很多时候本质上都能当客户端。