初识HTTP协议

SizeTheMoment2024-10-06 20:43

HTTP简介

通过AI可知：

HTTP（HyperText Transfer Protocol，超文本传输协议）是一种用于分布式、协作式、超媒体信息系统的网络协议。它是万维网（World Wide Web）上应用最广泛的协议，用于定义客户端与服务器之间的请求和响应消息格式，以及客户端和服务器之间的交互方式。

HTTP的主要特点包括：

  • 无状态协议：HTTP协议本身不保留之前任何事务的信息，即每次请求都是独立的。
  • 请求-响应模型：客户端发起请求，服务器响应请求。请求和响应都使用统一的格式。
  • 简单快速：HTTP协议简单，使得HTTP服务器的程序可以快速响应客户端请求。
  • 灵活：HTTP支持多种类型的数据传输，包括文本、图片、视频等。
  • 无连接：HTTP协议在每次请求结束后都会关闭连接，或者可以保持连接以便进行持续通信。

HTTP请求和响应的基本格式：

  • 请求行：包括HTTP方法（如GET、POST、PUT、DELETE等）、请求的资源路径和HTTP版本。
  • 请求头：包含客户端环境信息、请求体的大小和类型等。
  • 请求体：（可选）通常用于POST和PUT请求，包含要发送给服务器的数据。
  • 响应行：包括HTTP版本、状态码和状态消息。
  • 响应头：包含服务器信息、返回数据的类型和大小等。
  • 响应体：服务器返回给客户端的内容，如HTML文档、图片或JSON数据。

HTTP状态码：

  • `200 OK`：请求成功。
  • `301 Moved Permanently`：永久重定向。
  • `404 Not Found`：请求的资源不存在。
  • `500 Internal Server Error`：服务器内部错误。

HTTP/1.1是广泛使用的版本，而HTTP/2则引入了头部压缩、多路复用等特性，以提高性能。

为了提高安全性，HTTP通常会配合SSL/TLS协议使用，形成HTTPS（全称：HyperText Transfer Protocol Secure，超文本传输安全协议），它在HTTP的基础上通过SSL/TLS提供了数据加密、完整性校验和身份验证。

HTTP协议是典型的"一问一答"模式的协议

请求和响应是一一对应的

  • 一问一答：上传大文件的时候
  • 多问一答：下载大文件的时候
  • 一问多答：下载大文件的时候
  • 多问多答：下载大文件的时候，远程桌面/游戏串流

像TCP/UDP是完全可以支持上述四种方式的，进一步理解HTTP协议工作过程，以及理解HTTP协议报文格式，需要用到"抓包工具"（能够把网络上传输的HTTP数据获取到，并且显示出来）

抓包工具

相当于一个"代理程序"，找了个跑腿的

代理，可以分为两种角色：

  • 正向代理：帮客户端跑腿的
  • 反向代理：帮服务器跑腿的

所使用的抓包工具，本质上就是代理程序，但是单例不等于抓包工具，还有很多其他的代理程序有别的用途的（fq用到的程序/浏览器插件/加速器也是代理程序），如果你机器上同时运行多个代理程序，可能会冲突，无法正常工作了，因此咱们需要抓包的时候，一定要确保你机器上其他的代理程序都处于关闭状态

HTTP抓包工具分类

浏览器（Chrome内置了抓包工具），这些内容都是bing加载的时候和服务器之间交互的http请求和响应数据，但是Chrome自带的这个工具，看起来不够直观

Wireshark

老牌的抓包工具

计网的时候就会涉及到这个抓包工具的使用，不仅仅能抓到HTTP，也能抓到TCP，UDP，IP，以太网数据帧，功能非常强的专业软件，但是使用门槛比较高，抓HTTP的时候，缺少针对性的优化

fiddler

fiddler也是一个老牌的抓包工具，专门用来抓HTTP

会包含你主机上所有进程的http请求/响应数据，通过这个就能看到机器上是否有程序在后台偷偷搞事情，安装好fiddler，抓到的包非常少，可能是需要你手动开启抓取https的功能

注意事项

勾选过程中，会出现一个弹框，问你是否要安装证书，一定要选择"是"，同意安装证书，否则无法抓取https，如果点了否，就得重装fiddler

这些结果，都是浏览器打开bing网页的时候，给bing发送的http/https的请求数据，浏览器访问http服务器，往往不是只发送一个请求，很可能是发送很多个请求，看蓝色的横幅，这一块就属于body数据比较大的，蓝色的，服务器返回的是HTML数据，黑色的，返回的，返回的是普通的数据，还会有不同的颜色，区分，CSS，JS，图片

右上方是请求的响应，右下方是响应的详情

选择raw，这个是http请求的原始数据

HTTP本来是文本协议，但是如果需要返回的响应比较大，就可能会需要把响应数据压缩再返回，服务器最宝贵的硬件资源就是网络带宽，经过压缩，相当于是用CPU资源置换带宽资源，压缩后的数据到达客户端，再让客户端解压缩，对于浏览器来说，解压缩，就是自动完成的，但是使用fiddler就需要手动的解压缩

HTTP协议是一个"文本"格式的协议，本质上，一个HTTP数据包，就是按照上述HTTP协议的格式，构造出一串文本，写入到tcp socket中，TCP/IP基本结构：报头+载荷

HTTP请求

一个HTTP请求报文，分成4个部分

首行

请求的方法GET

请求的URL（请求的对方的网站）

www.baidu.com

版本号

请求头

空行

最后一个header后面，存在一个空行，类似链表，使用null结尾

正文

可选的，有些情况下有正文，有些情况下没有正文，并不是类似于HTML中的body，这里的内容是任意的，可以是完整的html，也可以是完整的css/js，也可以是json数据，也可以是图片，也可以是文件，也可以是字体（可以方任何你想传输的数据）

html结构的数据，这个数据就包含了客户端（浏览器）要给服务器传输的一些必要的数据

HTTP响应

响应的首行

HTTP/1.1 200 OK

版本号，状态码，状态码描述

响应的报头 header

空行

正文

正文中本来就是保存啥都可以，有空行没有空行都可以，都是表示内容，这些空行没有特定含义，只有http数据包中的第一个空行，才是header结束标记

URL

URL指定规则

URL的详细规则由因特网标准RFC1738进行了约定：RFC 1738 - Uniform Resource Locators (URL)

如果是http协议，端口号使用80，如果是https协议，端口号使用443，如果服务器使用的端口不是443，咱们在url必须显式写出来端口号，但是一般来说，一个网站都会使用默认的端口，大部分网站还是通过80/443来进行部署的

urlencode：下面网址进行encode，在url中，如果你输入的是汉字或者其他语言，遇到这个需要转码的符号，就显示出这个字符原始的编码的十六进制，在这个基础上，加上%，构造http请求，一定要把需要转码的部分，进行url encode，和utf8编码规则，直接相关的，utf8自身的编码就可以方便的区分，从哪里到哪里是一个完整的字符（相当于是巧妙设计的应用层协议，解决了粘包问题）

bash 复制代码 
https://cn.bing.com/search?q=%E4%B8%80%E4%B8%80%E4%B8%80%E4%B8%80%E4%B8%80%E4%B8%80&PC=U316&FORM=CHROMN

方法：

在HTTP协议中，GET和POST描述了，我这次请求要干啥，相当于"语义"，虽然HTTP中的方法有很多种，但是最主要的由两个，分别是GET和POST

  • GET语义：从服务器获取某个数据
  • POST语义：往服务器发送/提交某个数据
  • 实际编程中，这俩方法对应的语义，已经存在一些更模糊的东西了，所以实际开发中，GET也可以用来提交某个数据，POST也能获取某个数据
  • GET通常不会搭配body，有需要传输的数据，通过query string（浏览器给服务器传递的参数，键值对，使用&分割键值对，使用=分割键和值）
  • POST则通常不搭配query string，通过body传输数据
  • 但是GET也可以由body，POST也可以有query string

网络上大部分请求都是GET，通过query string告诉服务器要搜索啥，服务器返回搜索结果完整网页

POST比GET少很多了

登录-GET

上传文件-POST

上传了一个图片，这个url中不含参数，由于HTTP通常是使用文本来进行传输的，此处对图片的二进制数据进行了转码，把二进制数据转成了文本数据，这里只需要一个字节一个字节读取出来就行了，此处要传输的是文本，需要把上述二进制转成文本，这里的转换不是urlencode了，而是通过base64进行转码的

上述这些HTTP请求，都是如何构造的呢？

GET

  • 在浏览器地址栏中，直接输入url，此时就是get请求，点击收藏夹，同理的效果
  • 网页html中可能有一些特殊的标签，img/a/link...这些标签会带有一个url作为属性，页面被浏览器加载之后，解析到这些标签，就会根据url构造出新的http请求
  • 表单，html中的特殊标签form
  • 通过js构造，比如使用原生的ajax api/jquery的ajax api/一些第三方库 axios，fetch等

POST

  • 表单form
  • js

剩下的请求：只有通过js

经典面试题：谈谈GET和POST有啥差别？

第一句话，盖棺定论，GET和POST，从本质讲，没啥差别，GET的应用场景，使用POST也可以，POST的应用场景，GET也可以

从使用习惯的角度来说，还是有区别的

  • GET从语义上来说，通常用来"获取数据"
  • POST从语义上说，通常用来"提交数据"
  • GET传递数据的时候，通常使用query string
  • POST传递数据的时候，通常使用body
  • 服务器对于GET请求的设计，通常是设计成"幂等"的，所谓的幂等就是同一时间，同一搜索结果，所搜索出来的数据一致
  • 而POST请求的设计，则不要求"幂等"
  • GET请求的结果可以被缓存，可以被浏览器收藏夹收藏，POST一般不行，一个网站，通过GET获取到一些图片，浏览器就可以缓存这些图片，下次访问这个网站就不必从网络获取了，直接从之前缓存的数据读取（缓存在硬盘上的）

几种有问题的说法

POST比GET更安全

论据：拿登陆来说，提交登录请求这一下，如果使用GET，GET把参数放到URL中，URL会显示到浏览器地址栏，这个论据其实是不太成立的

POST请求也一样不安全，不是说密码显示到地址栏就不安全，不是说放到body中就安全，安全不安全取决于加密

GET传输的数据量比较有限，比较短，POST传输的数据量比较长，没有限制

HTTP标准中，明确说了一句话，针对GET的URL的长度是不做任何限制的，实践中是可以构造一个很长的URL的

在上古时期，IE浏览器对于URL的长度做出了限制（URL长度超出一定的数值，就会请求失败），这是很早的情况了

GET只能传输文本数据，POST可以传输文本，也能传输二进制

在URL的query string中提供了urlencode机制，二进制数据，也是可以进行encode，得到转义并进行传输的，虽然POST可以直接传二进制，很多时候，也是转义了之后通过文本的方式来传的，base64是文本化的才是更准确的说法

认识请求"报头"（header）

header中的键值对，都是标准规定的内容，主要介绍一些关键的

Host：请求对应的主机的ip和端口

bash 复制代码 
kimi.moonshot.cn/
https://kimi.moonshot.cn/

第一行就是HOST，这俩值在一般情况下是一样的，如果去抓包，看到的大部分情况都是一样的，比如你的代码构造http请求，url写的是IP地址，作为目标服务器，但是host写的仍然是域名，此时就可以跳过一些校验规则了，这也是一些"反爬虫的策略"，

Content-Length：表示body中的数据长度，一旦有body就需要知道，body到底是多长，才能知道一个完整的HTTP请求，粘包问题：分隔符：GET请求，没有body，通过空行；长度：POST请求，有body，，通过空行找到body开始通过Content-Length找到body的结束位置

Content-Type：Content-Type是body的数据类型，通过HTTP协议，传输的数据有很多种类，图片/视频/音频/字体/html/json/css，图片，浏览器要能够显示出来，html要渲染成网页，css，要加载成html的样式，js，要执行里面的代码

对于请求的Content-Type，

bash 复制代码 
application/x-www-form-urlencoded: form
title=test&content=hello

multipart/form-data: form 
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3Trw
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"
title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png
PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA-- 

application/json
{"username":"123456789","password":"xxxx","code":"jw7l","uuid":"d110a05ccde64b16}

使用json的数据格式是最多的，我们要重点掌握

一个请求，可能有body，也可能没有，如果有body，上述两个字段必须存在，如果没有body，上述两个字段，就不存在（Content-Length，Content-Type）

User-Agent（UA）

bash 复制代码 
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36
  • Mozilla是一个开源组织，浏览器里有一个FireFox火狐，现在是Chrome一家独大，Edge也是Chrome换皮版本，在这之前是三国鼎立（IE，Chrome，FireFox）
  • Windows NT是windows的内核 10.0->win10，我这个机器是win11，64位操作系统
  • Safari是苹果手机/苹果电脑自带的浏览器

UA里的信息主要是两个部分：浏览器版本+操作系统版本，描述了用户使用啥样的设备打开你的网页

UA有啥用呢？

通过UA来实现"兼容"，上古时期，浏览器只能显示文字，后来可以显示视频/音频/支持js，实现交互效果，同一时间中，就可能存在多个版本的浏览器，有的用户用的是老版本，只能看文字的，有的用户用的是新版本，支持上述所有功能，此时开发者就可以根据UA判定用户的浏览器和系统是啥水平的，根据这里的老版本进行区分，如果是老版本，就只返回带文字的网页，如果是新版本，就返回各种功能都有的网页

此时可以使用UA来区分，但是使用UA来区分的话意味着网站开发者就需要维护两套代码，程序员发明了一个新的技术"响应式布局（前端）"只写一套代码，这个代码能够根据你设备的尺寸（宽度）设置不同的样式，从而起到很好的适应各种设备的效果

现在UA的效果就是用来区分当前设备是手机还是电脑，如果是电脑，返回一个宽屏的页面，如果是手机，返回一个窄屏，并且按钮都比较大的网页

Referer：表示当前的页面，从哪里跳转来的

bash 复制代码 
Referer: https://kimi.moonshot.cn/

从广告来举例：广告从哪个搜索引擎点过来，那么广告方就要给搜索引擎方发钱，当然两方都要核对结果

那么有没有一种可能，存在某个人，把访问广告主服务器的请求的referer给修改了呢？

在2015年左右，运营商（移动，电信，联通等），运营商相当于用户的上一方，此时运营商就把referer给修改成自己家的广告平台，这在当年叫做运营商劫持，但是在2015，关于互联网商很多东西都缺少相应的法律条文对上述行为做出约定和约束，虽然可以走司法程序，但是赢了官司，输了买卖，所以互联网公司从技术手段上进行反制

HTTPS就应运而生，HTTPS直接针对HTTP请求中的内容，包括这里的header进行加密，这里的加密，不是说不让运营商看，而是能够防止运营商篡改，从根源上解决运营商劫持的问题

Cookie：非常重要的一个header

bash 复制代码 
Cookie: _tea_utm_cache_20001731=
{
%22utm_source%22:%22bing%22%2C%22utm_medium%22:%22%E5%BE%AE%E8%BD%AFbing%22%2C%22utm_campaign%22:%22TR_PbzLg2eV%22
}; 
_ga=GA1.1.585749492.1716896935; 
ntes_utid=tid._.8HQy8ezVOcBAQ0BEQEbCFHesw15t%252FE0k._.0; 
_gcl_au=1.1.281498235.1724681471; Hm_lvt_358cae4815e85d48f7e8ab7f3680a74b=1727763788,1727833005,1727854332,1728194100; Hm_lpvt_358cae4815e85d48f7e8ab7f3680a74b=1728194100; 
HMACCOUNT=130673FC184E616C; 
_ga_YXD8W70SZP=GS1.1.1728194103.75.1.1728194503.0.0.0

键值对格式的内容，和query string类似，都是程序员自定义的，都得是kimi的程序员才知道，换个网站也会有自己的Cookie和搜狗这边的键值对对应的含义也完全不同，Cookie这里的键值对，本质上都是能够在客户端的硬盘上持久化保存的

网页，是运行在浏览器上的，默认情况下，一个网页不能直接访问用户的硬盘（直接操作很危险）

但是有的网站，确实需要在客户端这边存储一些必要的信息，希望持久化存储（写到硬盘是，重启也还在）

浏览器就给网页提供了特定的机制（Cookie）

Cookie机制不是让网页随意访问硬盘，网页对于你的硬盘是没法直接读写的，浏览器对于硬盘操作，做了特殊的封装，相当于提供了一个/一组特殊的文件，只能往这个特殊文件里写，并且你写的内容，也必须是键值对（键和值都得是文本）

Cookie就是浏览器提供给网页的一种能够持久化存储数据的机制

Cookie具体是咋存的呢？

我们无法看到Cookie对应的文件的，浏览器会针对不同的网站（按照域名），每个网站有一份自己的Cookie文件，百度存的Cookie和搜狗村的Cookie不会影响的

Cookie是从哪里来的？

Cookie中的数据都是来自于服务器（服务器返回给浏览器的），你如果是一个新鲜的浏览器，第一次访问某个网站，此时你这个浏览器上对应的Cookie都是空着的，网站的服务器就会返回一些HTTP响应，在这些HTTP响应中，就会包含Set-Cookie这样的Header，就会把一些键值对，保存到浏览器的Cookie中

开发服务器的程序员定义的，在浏览器第一次访问这个服务器的时候就会获取到（也有些Cookie是后续获取的）

http响应中的header

返回多个键值对

Cookie保存到浏览器之后，后续浏览器访问该网站的时候，就会在请求header中，把之前保存的这些Cookie键值对都给代入进去，还要再发回给服务器，Cookie数据本来就是来自于服务器，为啥后续还要发回给服务器，一个服务器是要对应很多很多个不同的客户端的

客户端有很多很多个，每个客户端都有自己的"偏好"此时就需要让每个客户端都保存好这样的数据，以备随时告诉服务器，很多网站，有主题模式：夜间模式/日间模式，我给这个网站设置夜间模式了，此时我关闭浏览器，过一会又打开，当然还是希望继续是夜间模式，形如上述的设置信息，必须是保存在我的浏览器里的，后续请求人家的网站，告诉服务器，我要日间/夜间

  • Cookie是啥：浏览器本地存储数据的一种机制（不是唯一的一种，只是典型的一种，现代的浏览器，还有其他的方式也能本地持久化存储：localStorage，indexDB）
  • Cookie怎么存的：按照不同的域名，分别存储在硬盘上的，不同域名之间的Cookie互不干扰，键值对，存储文本，键和值都是用户自定义的
  • Cookie从哪里来：从服务器来，服务器的HTTP响应header中可以填写Set-Cookie字段，就会带有一些键值对
  • Cookie到哪里去：在后续请求中，通过HTTP请求的header中的Cookie字段，把信息传输给服务器
  • 能够使客户端存储一些必要的"配置"等信息，从而让服务器提供更多的"个性化的"服务

Cookie中虽然很多键值对都是程序员自定义的，但是往往会有一个特殊的键值对，大部分网站都会有的key用来标识用户的身份信息，如果你清除网站Cookie之后，大概率就需要重新登陆

Session

Session是什么：

在HTTP协议中，session（会话）是一种机制，用于在无状态的HTTP连接中维护用户的状态。由于HTTP协议本身无法识别请求之间的关联性，session提供了一种方法来追踪用户在应用程序中的操作和偏好。

  • 什么是Session

Session是一种服务器端的存储机制，它允许服务器将用户的状态信息保存起来，以便在多个页面请求或访问之间保持状态。每个用户都有一个唯一的session，服务器通过session来识别不同的用户。

  • Session的工作原理
  1. 创建Session: 当用户第一次访问Web应用程序时，服务器会创建一个session，并生成一个唯一的session ID。
  2. 传输Session ID: 服务器将这个session ID发送给客户端，通常是通过设置一个Cookie来实现。这个Cookie包含了session ID，客户端浏览器会存储这个Cookie。
  3. 使用Session: 客户端在随后的每个请求中都会发送这个Cookie（包含session ID），服务器通过这个ID来识别用户并获取其session信息。
  4. 存储Session数据: 服务器使用session来存储用户的状态信息，如登录状态、用户偏好、购物车内容等。
  • Session的应用场景

  • 用户认证: 存储用户的登录信息，以便用户在访问网站的不同页面时保持登录状态。

  • 个性化设置: 保存用户的个性化设置，如语言偏好、主题设置等。

  • 购物车: 在电子商务网站中，用于临时存储用户添加到购物车的商品。

Session的优点和缺点
- 优点:

  • 提供了一种在无状态的HTTP协议中维护用户状态的方法。

  • 可以存储复杂的对象，没有大小限制。

  • 存储在服务器端，更加安全。
    - 缺点:

  • 消耗服务器资源，因为每个用户的状态都需要存储在服务器上。

  • 如果有大量用户，可能会占用大量服务器内存。

  • 跨服务器共享session信息可能比较复杂。

  • Session的管理

- 超时设置 : 服务器会为session设置一个超时时间，当用户在一段时间内没有活动时，session会自动过期并被服务器删除。
- 手动管理: 应用程序可以通过调用session的特定方法来手动删除session或更改session中的信息。

  • Session的安全考虑

- 保护Cookie : 应该使用安全的Cookie属性，如设置`HttpOnly`和`Secure`标志，以防止跨站脚本攻击（XSS）和跨站请求伪造（CSRF）。
- Session固定攻击: 防止攻击者通过固定session ID来劫持用户session。

Session是Web应用程序中常用的一种机制，用于提供更加丰富和个性化的用户体验。
Session在哪里：

  • 通过Cookie:

  • 服务器会在HTTP响应中设置一个名为JSESSIONID（或其他名称，具体取决于服务器配置）的Cookie。

  • 客户端浏览器会存储这个Cookie，并在随后的每个请求中自动发送给服务器。

  • 服务器通过这个Cookie中的session ID来识别和检索服务器端的session信息。

  • 通过URL重写:

  • 如果用户浏览器禁用了Cookie，服务器可以通过URL重写的方式将session ID附加在URL路径后面。

  • 客户端在每次请求时，将URL中的session ID发送给服务器，服务器根据这个ID来识别session。

  • 隐藏字段:

  • 在表单提交时，服务器可能会在表单中添加一个隐藏字段来存储session ID。

  • 用户提交表单时，隐藏字段中的session ID被发送到服务器，以便服务器识别session。

  • 通过Session对象:

  • 在服务器端的代码中（如Java EE应用中的`HttpServletRequest`对象），可以通过调用`getSession()`方法来获取当前会话的`HttpSession`对象。

  • 这个对象代表了服务器端存储的session信息，可以用于读写session属性。

  • 服务器端存储:
  • Session数据通常存储在服务器的内存中，但也可能被持久化存储到数据库、文件系统或其他类型的存储系统中，以便在服务器重启后仍然可用。
  • 分布式Session管理:

  • 在大型或分布式的Web应用程序中，可能会使用如Redis、Memcached等分布式缓存系统来存储session数据。

  • 这样可以在多台服务器之间共享session信息，实现负载均衡和故障转移。

开发工具:

  • 使用Web开发工具（如浏览器开发者工具、Fiddler、Charles等）可以查看HTTP请求和响应，从中可以找到Cookie中的session ID。

  • 也可以通过这些工具查看表单提交的数据，检查隐藏字段中的session ID。

HTTP响应的的一些信息

HTTP状态码：

分类 分类描述
1** 信息，服务器收到请求，需要请求者继续执行操作
2** 成功，操作被成功接收并处理
3** 重定向，需要进一步的操作以完成请求
4** 客户端错误，请求包含语法错误或无法完成请求
5** 服务器错误，服务器在处理请求的过程中发生了错误
状态码 状态码英文名称 中文描述
100 Continue 继续。客户端应继续其请求
101 Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议
200 OK 请求成功。一般用于GET与POST请求
201 Created 已创建。成功请求并创建了新的资源
202 Accepted 已接受。已经接受请求，但未处理完成
203 Non-Authoritative Information 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本
204 No Content 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档
205 Reset Content 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域
206 Partial Content 部分内容。服务器成功处理了部分GET请求
300 Multiple Choices 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择
301 Moved Permanently 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302 Found 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303 See Other 查看其它地址。与301类似。使用GET和POST请求查看
304 Not Modified 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305 Use Proxy 使用代理。所请求的资源必须通过代理访问
306 Unused 已经被废弃的HTTP状态码
307 Temporary Redirect 临时重定向。与302类似。使用GET请求重定向
400 Bad Request 客户端请求的语法错误，服务器无法理解
401 Unauthorized 请求要求用户的身份认证
402 Payment Required 保留，将来使用
403 Forbidden 服务器理解请求客户端的请求，但是拒绝执行此请求
404 Not Found 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面
405 Method Not Allowed 客户端请求中的方法被禁止
406 Not Acceptable 服务器无法根据客户端请求的内容特性完成请求
407 Proxy Authentication Required 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权
408 Request Time-out 服务器等待客户端发送的请求时间过长，超时
409 Conflict 服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突
410 Gone 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置
411 Length Required 服务器无法处理客户端发送的不带Content-Length的请求信息
412 Precondition Failed 客户端请求信息的先决条件错误
413 Request Entity Too Large 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息
414 Request-URI Too Large 请求的URI过长（URI通常为网址），服务器无法处理
415 Unsupported Media Type 服务器无法处理请求附带的媒体格式
416 Requested range not satisfiable 客户端请求的范围无效
417 Expectation Failed（预期失败） 服务器无法满足请求头中 Expect 字段指定的预期行为。
418 I'm a teapot 状态码 418 实际上是一个愚人节玩笑。它在 RFC 2324 中定义，该 RFC 是一个关于超文本咖啡壶控制协议（HTCPCP）的笑话文件。在这个笑话中，418 状态码是作为一个玩笑加入到 HTTP 协议中的。
500 Internal Server Error 服务器内部错误，无法完成请求
501 Not Implemented 服务器不支持请求的功能，无法完成请求
502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
503 Service Unavailable 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504 Gateway Time-out 充当网关或代理的服务器，未及时从远端服务器获取请求
505 HTTP Version not supported 服务器不支持请求的HTTP协议的版本，无法完成处理

设置Content-Type不光可以指定相应的类型，还可以指定相应数据的字符集，如果相应数据出现乱码，就可以在这里设置好字符集，确保，响应数据的字符集和界面上显示的方式是编码一致的

除了通过代码的方式来构造请求之外，可以通过专门的工具来构造请求

postman

填写query string

自带了7个参数，你也可以手动创建其他的

HTTP请求里，首行：方法，url，请求头：..，请求正文：...

HTTPS

HTTPS本质上就是HTTP的基础上增加了一个加密层，抛开加密之后，剩下的部分就和HTTP是一样的，S=>SSL（安全相关的协议），HTTPS = HTTP +SSL

正常情况下下载什么软件就是什么软件，但是运营商劫持的情况，淡出的窗口是下载qq浏览器，万一要是把你的钱相关的请求给进行篡改就很麻烦了

HTTPS密码学和数学相关性非常大，密码学几个核心概念：

  • 明文：要传输的真正意思是啥
  • 密文：加密之后得到的数据
  • 密钥：用来加密和解密的重要的道具/数据/方法
  • 加密：将明文转换为密文
  • 解密：将密文转换为明文
  • 对称加密：加密和解密，使用同一个密钥就行了，加密解密速度比较快（DES，AES）
  • 非对称加密：密钥是一对（分别称为公钥和私钥），加密解密速度比较慢，安全性更高，可以使用公钥加密，此时就是私钥解密，或者可以使用私钥加密，公钥解密（RSA）

对称加密

对称密钥：当有多个客户端的时候，是要有一个密钥还是多个密钥，所有客户端使用同一个对称密钥，还是每个客户端有一个自己的呢？

可以让每个客户端，生成自己的密钥，告诉服务器就行了，如果直接把密钥明文传输，那么黑客也就能获得密钥了，此时后续的加密操作就形同虚设了，因此密钥的传输也必须加密传输，但是要想对密钥进行对称加密，就仍然需要先协商确定一个密钥的密钥，这就成了"先有鸡还是先有蛋"的问题了，此时密钥的传输再用对称加密就行不通了，此时就需要引入非对称加密

非对称加密

不是针对后续传输的数据内容展开的，而是只针对对称密钥来进行的，服务器生成公钥和私钥，当客户端连上服务器的时候，服务器就把自己的公钥告诉给客户端（私钥还是自己来持有的），公钥是会告诉所有的客户端（所有的客户端都是同一个公钥），私钥的话还是自己留好，不会告诉任何人

接下来客户端生成对称密钥（每个客户端生成自己的，客户端之间不知道别人的对称密钥是啥），通过服务器拿到的公钥，针对对称密钥，进行加密，再把对称密钥的密文，传输给服务器，黑客拿到对称密钥的数据之后，无法解密的，使用公钥加密，得拿着对应的私钥来解密，黑客能轻松拿到公钥，但是拿不到私钥

⾮对称加密的数学原理⽐较复杂, 涉及到⼀些 数论 相关的知识

这⾥举⼀个简单的⽣活上的例⼦. A 要给 B ⼀些重要的⽂件, 但是 B 可能不在. 于是 A 和 B 提前做出约定: B 说: 我桌⼦上有个盒⼦, 然后我给你⼀把锁, 你把⽂件放盒⼦⾥⽤锁锁上, 然后我回头拿着钥匙来开锁 取⽂件. 在这个场景中, 这把锁就相当于公钥, 钥匙就是私钥. 公钥给谁都⾏(不怕泄露), 但是私钥只有 B ⾃⼰持 有. 持有私钥的⼈才能解密

中间人攻击，黑客可以冒充自己是服务器，不是传递错误信息，而是伪造一些看起来好像正确的信息

解决中间人攻击-CA

最关键的切入点，就是让客户端能够区分出当前的公钥是不是服务器自己的公钥，此时引入第三方公证机构，公正机构会对公钥进行"公证"，此时客户端看到了这个公钥被公证了，就可以认为这是合法的了

CA认证：CA认证_百度百科

客户端收到整数，就会对证书的合法性进行校验

针对证书这些字段，计算校验和

  • 发证机构
  • 整数的有效期
  • 服务器的公钥
  • 证书的所有者
  • 持有者网站的主域名
  • 数字签名

针对数字签名进行解密

数字前面是基于公正机构的私钥来加密的，就需要拿着公正机构的公钥来解密，获取公证机构的公钥，不是通过"网络"的方式获取到的，通过网络的方式，就可能会得到黑客伪造的公钥，而是操作系统会内置公证机构的公钥，公证机构一共没有多少，一个操作系统可以在发布的时候，把市面上的公证机构的公钥都打包放在一起，随着安装操作系统，公钥就有了（系统内置的公钥，一定是正经公钥，不是伪造的）

接下来，就可以使用公证机构的公钥（系统内置）来对数字签名进行解密了，解密之后得到校验和2

客户端来比较校验和1 == 校验和2，相等就说明整个证书，都是没有被篡改过的，此时，证书及然后是有效的，证书中包含的公钥自然就是可信的服务器公钥了

针对公证机构加密的数字签名，进行解密是很容易的，公正机构的公钥是内置到系统中的，用户可以解密，黑客当然也能解密了，黑客很容易能拿到校验和，虽然能拿到，但是无法篡改，也无法伪造

如果黑客修改了证书中的公钥，但是不修改数字签名，客户端校验的时候就会发现，自己算出来的校验和和从数字前面中解密出来的校验和不一致了，客户端就可以判定，证书非法

如果黑客修改了公钥，并且自己重新计算校验和，重新加密得到数字签名？黑客不知道公证机构的私钥是啥，黑客只能拿着自己生成的私钥来加密，客户端收到数据之后，肯定是拿着公证机构的公钥来解密，此时就会出现解密失败，客户端也可以判定，证书非法

黑客无法给系统里添加自己位发证机构，安装fiddler，开启https的时候，会有一个"安装证书"的过程，必须要选同意，这个过程就是给你的系统里新增一个公证机构，fiddler的公证机构，fiddler抓包其实就是在进行中间人攻击，只不过这个过程是咱们用户可信任的，因此咱们主动选择了安装fiddler提供的证书，也就是让系统认可了fiddler来作为一个公正机构，但是黑客无法做到这一点

相关推荐
皮皮学姐分享-ppx5 小时前
政府绿色采购数据库（2015-2024.3）
大数据·网络·数据库·人工智能·制造
W_chuanqi6 小时前
联想M7615DNA网络打印方法
网络·联想·打印机网络连接
HavenlonLabs9 小时前
硬件 + SaaS 产品的工程化路径：从系统架构、PCB 设计到工程样机
网络·安全·架构·系统架构·安全架构
sweet丶11 小时前
MQTT消息通道-基础篇
网络协议
yychen_java13 小时前
当算法成为武器：AI泛滥时代的多维危机透视与治理路径
网络·人工智能·ai
漫途科技13 小时前
精准盯防危房隐患，智守人居安全｜MTB46-4-2A 4G数据采集终端专项应用方案
网络·安全
奥利奥夹心脆芙13 小时前
辅助排查 HTTP 接口代码报错，实操完整案例分享
http
Misnearch13 小时前
抓包Packet Capture
网络·抓包
zhangfeng113314 小时前
ps aux讲解，结合国家超算中心 hpc apptainer
linux·服务器·网络
吠品14 小时前
一次 Nginx 报错 unexpected end of file 的排查记录
网络协议·https·ssl
热门推荐
01《置身钉内》原文-可播放阅读02GitHub 镜像站点03【AI】2026 年具身智能模型和世界模型总结04Claude Code、Codex、Cursor三分天下：2026年AI编程Agent生态全景剖析052026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？06Codex 下载安装指南：Windows 和 macOS 官方版下载072026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf08【踩坑记录 | 第一篇】微软商店无法使用时，如何手动安装 OpenAI Codex？附`.msix`文件系统错误解决方法09AI科技热点日报 | 2026年6月1日10CC-Switch 下载、安装与使用配置指南【2026.5.29】