JavaEE初阶（11）HTTP 协议（发展历程、报文格式、URL

• 一些流传的信息认为GET请求的URL长度限制为1024kb，但这是不准确的。
• HTTP协议的RFC 2616标准并未规定URL的最大长度。
• URL的实际长度限制取决于浏览器和服务器的实现。
  • 浏览器端：不同浏览器对URL的长度限制不同。但现代浏览器通常都支持非常长的URL。
  • 服务器端：URL长度通常是可配置的，取决于服务器的设置和实现。

总之，尽管HTTP协议本身没有限制URL的长度，但在实际应用中，浏览器和服务器的具体实现可能会设置一些限制。在设计Web应用时，考虑到跨浏览器和跨平台的兼容性，通常建议不要使用过长的URL。

2、POST 方法

定义与用途：

• POST是HTTP中的一种方法，通常用于将用户输入的数据提交给服务器，例如登录表单。
• 通过HTML的 form 标签，或使用JavaScript的Ajax技术，都可以构造POST请求。

这里我其实最开始没能抓到返回页面的请求，原因是命中了浏览器缓存。

浏览器显示的页面其实都是从服务器这边下载的HTML，它的内容可能比较多，体积比较大，通过网络加载消耗的时间也会比较多。

所以浏览器一般都会自己带有缓存，就把之前加载过的页面保存在本地硬盘上，下次访问可以直接读取本地硬盘的数据。

请求特点：

• 请求行的首部包含“POST”关键字。
• URL的查询字符串通常为空，但也可以包含数据。
• 请求头部分包含一系列的键值对结构。
• POST请求的主体部分通常不为空，主体内的数据格式由请求头中的 Content-Type 指定。
• 主体的长度由请求头中的 Content-Length 指定。

POST方法主要用于将数据传输到服务器，这些数据通常包含在请求主体中。与GET请求不同，POST请求通常用于非幂等操作，例如在服务器上创建新资源，因此具有状态更改的潜力。在POST请求中，主体的数据格式通常由 Content-Type 头部字段指定，可以是表单数据、JSON、XML等格式。

你会发现我上传了一张图片，这里的body非常长，因为此处把图片放到HTTP请求中，往往要进行mb4转码

在HTTP请求中上传一张图片，这可能导致请求主体（body）非常大，因为图像文件通常具有较大的文件大小。如果将图像文件作为HTTP请求的一部分上传，可能需要将二进制数据进行编码，以便在HTTP请求中传输。

常用的图像编码格式包括Base64编码，这将二进制数据编码为文本字符串，使其可以包含在HTTP请求中。具体的编码方法和格式可能因不同的编程语言和HTTP库而异。通常，编码后的图像数据会放在请求的主体中，而请求头会包含有关数据类型（例如Content-Type）和数据长度（例如Content-Length）的信息。

在服务器端，我们需要解码请求主体，以还原图像文件的二进制数据。这可以通过编程语言的库和工具来完成。

注意，虽然可以将图像文件包含在HTTP请求中，但对于大型文件或多个文件的上传，通常更常见的做法是使用多部分表单（multipart/form-data），这样可以更有效地处理文件上传。此外，HTTP服务器通常有文件上传限制，需要根据服务器配置来确定最大请求主体的大小。

GET 和 POST 的区别（面试题）

GET和POST其实并没有本质的区别！！！双方可以替换对方的场景。

但是虽然没有本质区别，但是在使用习惯上还是存在一些差异。

• GET请求通常会把要传给服务器的数据加到URL的 query、string 里面。
• POST请求，经常把要传给服务器的数据加到body里面。

这是习惯上最大的差别。当时上述情况并非绝对，GET也可以使用body，POST也可以使用  query、string ，使用的前提是客户端/服务器都得按照一样的方式来处理代码。 所以一般还是建议大家按照约定俗成的习惯，不要太特立独行~~~

语义不同：

• GET一般用于获取数据，而POST一般用于提交数据。GET请求通常用于从服务器请求资源，而POST请求通常用于将数据提交到服务器，一般都是登录和上传。
• 相比之下，PUT和POST等，语义就比较混乱了。

数据传递方式：

• GET请求的主体通常为空，需要传递的数据通过查询字符串（query string）传递，附加在URL上。
• POST请求的查询字符串通常为空，需要传递的数据通过请求主体（body）传递，通常使用Content-Type头部指定数据格式。

幂等性：

• 幂等是数学概念，即输入相同的内容，输出是稳定的。
• GET请求一般是幂等的，即多次相同的GET请求应该返回相同的结果。
• POST请求一般是不幂等的，如果多次相同的POST请求得到的结果一样，通常不视为请求是幂等的。
• 但是需要注意，这种说法不够准确，但也不是完全出错。GET是否幂等不绝对，RFC上建议GET请求实现为幂等的。一个GET不幂等的情况：搜狗的广告搜索，这背后涉及到一系列复杂的逻辑操作。

缓存：

• GET请求可以被缓存，因为它是幂等的，多次获取相同资源不会对服务器状态产生影响。
• POST请求通常不被缓存，因为它通常用于对服务器状态进行更改。
• 当然，这个说法也和上述幂等有关，是幂等性的延续，如果请求是幂等的，自然就可以缓存。

其他补充说明：

• 关于语义：虽然GET和POST有常见的用途，但实际上，GET也可以用于提交数据，而POST也可以用于获取数据，因为HTTP本身并未强制这些语义。
• 关于安全性：GET和POST在安全性方面并无绝对的不同，安全性主要取决于数据加密和其他安全措施的实施。
• 关于传输数据量：HTTP标准未规定GET的URL或POST的主体的长度限制，因此传输数据量取决于浏览器和服务器的实现。
• 关于传输数据类型：GET虽然不直接传输二进制数据，但可以对二进制数据进行URL编码以传输。

这里我们需要具体解释一下。

网络上经常有一些说法，需要注意：

1、GET请求能传递的数据量有上，POST没有。这个说法是一个历史遗留问题，早期版本的浏览器硬件资源非常匮乏，针对GET请求的URL长度做出了限制。但是实际上RFC标准文档中并没有明确规定URL能有多长，目前的浏览器和服务器的实现过程中，URL可以是非常长的，甚至可以使用URL传递一些图片这样的数据；

2、GET传递数据不安全，POST请求传递数据更安全。依据是：如果使用GET请求进行实现登陆，点击登陆的时候就会把用户名和密码放到URL中，进一步的显示到浏览器的地址栏里，相比之下POST则是在body中，不会在界面上显示出来，所以更安全。但是我们通常说的“安全”指的是传递的数据不容易被黑客获取，或者被获取到之后不容易被破解。所以此处的密码是加密的，即使拿到了也不容易破解。

3、GET只能给服务器传输文本数据，POST可以给服务器传输文本和二进制数据。

• GET也不是不可以使用body，body中是可以直接放二进制的。
• GET也可以把二进制数据进行base转码放到URL中的query和string中。

4、GET请求可以被浏览器收藏夹收藏，POST不能，因为收藏的时候可能会丢失body。这个说法目前是正确的，但是可能和技术关系不大，主要还是看你怎么提需求。

我虽然提供了GET和POST方法之间的主要区别，但是具体的实现和应用还是得取决于浏览器和服务器的配置和要求。

HTTP其他方法

1. PUT:

   • PUT方法用于向服务器上传、更新资源。与POST相似，但具有幂等特性，多次执行相同的PUT请求应该产生相同的结果。
   • 一般用于替换服务器上的资源。

2. DELETE:

   • DELETE方法用于删除服务器上的指定资源。对服务器的状态产生更改。

3. OPTIONS:

   • OPTIONS方法请求服务器返回所支持的HTTP请求方法，通常用于跨域请求中的预检请求（CORS预检请求）。

4. HEAD:

   • HEAD方法类似于GET，但响应中不包含实体主体，只返回响应头信息。通常用于检索资源的元数据而不需要实际内容。

5. TRACE:

   • TRACE方法用于回显服务器端接收到的请求，通常用于诊断和测试。对于安全性考虑，应该谨慎使用。

6. CONNECT:

   • CONNECT方法是预留的，目前很少使用。通常用于建立代理服务器隧道，通常在HTTPS连接时使用。

我们提到这些HTTP方法可以使用Ajax或网络编程语言来构造，任何能进行网络编程的语言都可以构造HTTP请求，实质上就是通过TCP socket发送符合HTTP协议规则的字符串。

这些HTTP的请求最初的初心其实就是未来表示不同的语义。可是在现在的实际使用过程中，这个初心已经被遗忘了。HTTP的各种请求目前来说已经不一定完全遵守自己的规定了，你可以更加随意的使用。

HTTP请求详解

认识请求 “报头” (header)

请求头（header）是HTTP请求中的一部分，用于携带关于请求的元数据和其他信息。

HTTP请求头通常采用键值对的格式，每个键值对占一行，键和值之间使用冒号分隔（而不是分号）。

请求头提供了有关请求的重要信息，包括请求的方法、URL、主机、内容类型、身份验证凭证等等。

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Connection: keep-alive

在上面的示例中，每个键值对表示一个请求头，例如，"Host"头部指定了请求的主机名，"User-Agent"指定了发送请求的用户代理，"Accept"头部指定了接受的内容类型等等。

HTTP请求头是HTTP请求的一部分，它提供了关于请求的元数据信息，它们以键值对的格式表示，而不是使用分号分隔。

报头的种类有很多, 此处我们仅介绍几个常见的。

1、Host:

定义与用途： 指定请求的服务器主机地址和端口。

**示例：**Host: www.example.com

这个信息在URL中也是存在的。但是在使用代理的情况下，Host的内容可能和URL中的内容不同。

2、Content-Length:

定义与用途： 指定请求主体或响应主体的数据长度，以字节为单位。

示例： Content-Length: 1234

非必须，请求里面有body才会有这个属性。通常情况下，GET请求里面就没有，POST就有。

TCP涉及到粘包问题，HTTP在传输层就是基于TCP的。使用同一个TCP连接，传输多个HTTP数据报，此时就会使多个GTTP数据包在TCP接收缓冲区中挨在一起。接收方解析的时候就需要能够清楚HTTP数据包之间的边界。

对于GET这种没有body的请求，直接使用空行作为分隔符；

对于POST这种有body的请求，就需要结合空行和Content-Length。

3、Content-Type:

• 定义与用途： 指定请求或响应主体的数据格式，即body中数据的格式。
• 常见选项和格式：

  • application/x-www-form-urlencoded:

    • 表单提交的标准数据格式。
    • 例如：key1=value1&key2=value2

  • multipart/form-data:

    • 通常用于表单提交，尤其是涉及到文件或图片上传。
    • 数据以边界（boundary）分隔。
    • 例如：

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

    • application/json:
      • 用于传输JSON格式的数据。
      • 例如：{“username”:“123456789”,“password”:“xxxx”}

非必须，请求里面有body才会有这个属性。通常情况下，GET请求里面就没有，POST就有。

请求头部提供了关于请求内容和其他元数据的关键信息，帮助服务器正确解析和响应请求。

HTTP请求和响应的body中的格式可以有多种选择，取决于数据的类型和需求。以下是一些常见的HTTP请求和响应body中的格式：

HTTP请求body中的格式：

1. JSON：常用于向服务器发送结构化的数据，如API请求。
2. from表单的格式（相当于是把query string给搬到body中）：通过application/x-www-form-urlencoded格式，通常用于HTML表单提交。
3. 多部分表单数据，from=data的格式（上传文件的时候会涉及到，当然也不一定，也有可能是from表单，之前的上传图片就是，只是一个key一个value，但是这个value作为图片，非常大）：通过multipart/form-data格式，常用于文件上传。
4. XML：用于传输和接收XML格式的数据。
5. 文本：纯文本数据，无格式。

HTTP响应body中的格式：

1. HTML：通常用于呈现网页内容。
2. JSON：用于API响应，传输结构化数据。
3. 图像：如JPEG、PNG、GIF等，用于传输图像文件。
4. CSS：用于定义页面样式。
5. JavaScript：用于客户端执行脚本。
6. XML：用于传输和接收XML格式的数据。
7. 文本：纯文本数据，无格式。

后续给服务器提交给请求不同的 Content-Type ，服务器处理数据的逻辑也是不同的。服务器返回数据给浏览器们也需要设置合适的 Content-Type，浏览器也会根据不同的 Content-Type做出不同的处理。

其中响应中的HTML、CSS、JavaScript构成网页的主体，HTML表示页面的骨架，CSS表示页面的样式，JavaScript 表示页面的行为。

4、User-Agent（简称 UA）

**定义与用途：**表示发送请求的用户代理的属性，通常是浏览器或其他客户端应用。描述里你使用什么设备上网。

格式与内容：

UA字符串通常包含操作系统、硬件类型、浏览器以及浏览器的渲染引擎等信息。

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36

Windows NT 10.0; Win64; x64 表示操作系统版本信息。

AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36 表示浏览器版本和其使用的渲染引擎信息。

背景与历史：

• User-Agent（UA）字符串的格式和内容常常受到历史遗留问题的影响。在互联网的早期，网站的内容相对简单，而浏览器之间的差异也很大。为了提供最佳的用户体验，网站开发者需要考虑到多个浏览器版本的兼容性。
• 随着时间的推移，网页的内容变得越来越丰富，浏览器更新和升级的速度也加快了。这导致了新旧版本浏览器的并存，因此，开发者既要考虑到老版本浏览器的兼容性，又要确保新版本浏览器用户的体验得到保障。为了解决这个问题，开发者开始使用UA来识别并区分不同的浏览器。UA中记录了浏览器的版本、所支持的特性等信息，这为开发者提供了巨大的帮助。
• 然而，随着各大浏览器厂商争夺市场份额，为了确保网站能够在其浏览器上正确显示，浏览器开始在UA字符串中包含其他浏览器的标识。这导致了UA字符串变得越来越复杂和冗长。
• 现代互联网的发展已经使得大多数浏览器之间的差异变得很小。现在的前端开发技术，如“响应式网页”编程，使得同一个HTML页面能够很好地适应不同的设备和浏览器。因此，UA的重要性已经大大降低，现在它主要被用来识别是PC端还是移动端。
• 由于这种标识的历史原因，现代浏览器的 User-Agent  字符串包含了大量的信息，这有时会导致隐私和安全问题。因此，有一些提议和措施正在考虑修改或简化 User-Agent  字段的内容，以提高用户隐私。
• 现在浏览器的差异已经很小了，此时UA的作用也就没有那么关键了。现在UA主要是用来区分是PC端还是移动端。这样的区分一般只是为了进行统计，而不会返回不同版本的页面。现在前端开发有“响应式网页”编程技术，同一个HTML很好的兼容不同的设备。

总之，User-Agent  请求头部字段提供了关于请求来源的用户代理的详细信息，这有助于服务器为不同的设备、操作系统或浏览器提供适当的响应。

5、Referer

定义与用途：

• Referer表示当前请求的来源页面（是从哪里跳转来的），即引导用户前往当前页面的页面的URL。
• 它用于记录用户从哪个页面跳转到当前页面，以帮助网站分析流量和用户导航。
• 当用户直接在浏览器地址栏中输入URL或者通过点击书签/收藏夹中的链接来访问网页时，通常不会发送Referer头部字段。这是因为Referer字段是由上一个页面传递给当前页面的，但在这种情况下，没有上一个页面。因此，浏览器不会发送Referer信息。 Referer字段通常用于标识从哪个页面跳转过来，以便网站或服务器了解用户的访问来源。但在直接输入URL或使用书签的情况下，没有上一个页面可供标识，因此没有Referer信息发送到目标网页。
• 用户点击广告之后，广告平台每次跳转之前都会先跳转到一个计费服务器，再跳转到广告主的页面。广告主通过记录日志就知道点击情况了。
• 广告主也可能会在很多不同的平台投放广告，广告主的服务器就需要区分出哪些请求是来自A，哪些请求又是来自B？我们通过Referer就可以进行区分（域名不同）
• 是否会存在一种情况？有人把Referer给改了，本来是“搜狗”的广告，结果跳转到了别的广告平台？在早期的互联网中，确实存在运营商或中间人劫持的情况，其中修改HTTP请求或响应中的信息，如Referer，是其中的一种手法。这种行为通常是为了注入广告或跟踪用户活动，甚至可能用于监视和搜集用户的数据。因为网络数据都是通过运营商的设备（路由器/交换机）转发的，运营商通过在路由器上部署一些特定的程序，就很容易能够获取到，也就很容易篡改。所以后面就使用HTTTPS来替代HTTP，HTTP最大的问题在于“明文传输”，这就容易被第三方获取并篡改。而HTTPS对HTTP的数据进行了加密，第三方想要获取并篡改就没那么容易了，通过这个手段就可以有效地遏制运营商劫持。
• HTTPS的广泛采用是一个重要的改进，因为它通过加密通信来保护数据的完整性和隐私，使运营商或其他恶意第三方更难以篡改用户的数据。HTTPS的加密机制通过使用SSL/TLS协议来实现，确保了数据在传输过程中的保密性。

运营商劫持等恶意行为在HTTPS广泛采用后变得更加困难，因为HTTPS通信中的数据在客户端和服务器之间进行端到端的加密，防止了中间人的干预。此外，Web浏览器和网站也会检测证书，以确保与服务器建立安全的HTTPS连接。

尽管HTTPS提供了更高的安全性，但仍然可能存在一些其他安全漏洞和攻击，例如钓鱼攻击、恶意证书颁发等。因此，大家都需要保持警惕，并确保采取适当的安全措施，以降低潜在威胁的风险。同时，不断更新和改进网络协议和安全措施也是网络安全的一部分。

示例：

• Referer: https://www.example.com/previous-page

注意：

• 如果用户直接在浏览器中输入URL、使用收藏夹访问页面，或者通过其他方式访问页面而没有从其他页面跳转过来，Referer字段可能为空或缺失。

6、 Cookie

定义与用途：

• Cookie 字段用于在HTTP请求和响应之间存储和传递数据，可以被认为是浏览器在本地存储数据的一种机制。
• 浏览器的数据来自于服务器，浏览器后续的操作也是要提交给服务器的。服务器这边管理了一个网站的核心数据。但程序运行过程中也会有一些数据需要在浏览器这里储存，并且在后续请求的时候数据可能需要再发给服务器，比如上次登录的时间、上次访问的时间、用户的身份信息、累积的访问次数……这些临时性的数据存储在浏览器中是比较合适的。
• 实际上我们更容易想到的方法是把这样的数据直接存储到本地文件中。但是实际上是不可行的。浏览器为了考虑安全性，禁止网页直接访问你的电脑的文件系统（病毒杀毒），网页代码也就无法直接生成一个硬盘的文件来存储数据了。
• 为了保证安全性，又能进行存储数据，于是就引入了Cookie，也是按照硬盘文件的方式保存的，但是浏览器把操作文件给封装了，网页只能往Cookie里面存储键值对，也就是一些简单的字符串。
• Cookie是一种用于在客户端（通常是浏览器）和服务器之间存储小段数据的机制。这些数据以键值对的形式存储，通常是程序员自己定义的。这些键值对可以包含一些简单的字符串，通常用于存储用户会话信息、首选项、身份验证令牌等。
• 数据通常以键值对的形式存储在Cookie中的，这里的键值对是程序猿自己定义的（和 query string 类似）
• Cookie往往是从服务器返回的数据，可以由服务器返回给客户端，也可以由页面的JavaScript代码自己生成并存储在客户端。服务器通常在HTTP响应头中设置Cookie，而浏览器会将它们存储在客户端的硬盘上。客户端的JavaScript代码可以通过浏览器的Document对象来创建、读取和修改Cookie。
• Cookie存储到浏览器所在主机的硬盘上，并且是按照域名的维度来存储的，每个域名可以在客户端存储自己的Cookie数据，这些Cookie是与特定域名关联的。不同域名之间的Cookie通常是相互隔离的，它们不会互相访问或共享数据。
• 当浏览器再次请求同一服务器时，它会自动将相关Cookie包含在HTTP请求的Cookie头中，发给服务器，服务器可以读取这些Cookie，就会通过Cookie的内容做一些逻辑上的处理，例如身份验证或用户会话跟踪。
• 总的来说就是：Cookie保存了一些给程序员使用的数据。

示例：

• Cookie: username=johndoe; sessionid=123456
• 键值对之间使用 ；分割，键和值使用 = 分割。
• 这些内容就是浏览器本地存储的Cookie，都会在后续请求服务器的时候把这些内容自动代入到请求中，发给服务器，服务器就通过Cookie的内容做一些逻辑上的处理。

关于域名和Cookie：

• 每个不同的域名（网站）可以有自己的Cookie，这些Cookie在不同网站之间不会冲突。
• 通过HTTP响应的Set-Cookie头部字段，服务器可以向浏览器设置Cookie数据。

Referer和Cookie是HTTP请求头部字段的一部分，它们提供了在Web应用程序中进行跟踪和标识的功能，用于了解用户行为和提供个性化服务。

前期准备

通过抓包观察网页登录过程是一种常见的方式来了解网络通信和验证身份的过程。以下是一般的步骤，以观察码云登录过程为例：

1. 安装抓包工具:

   • 首先，你需要安装一个网络抓包工具。一些常见的抓包工具包括Fiddler、Wireshark、Charles等，你可以根据你的需求和操作系统选择一个合适的工具。

2. 启动抓包工具:

   • 启动你选择的抓包工具，并设置它以侦听本地网络流量。

3. 清除浏览器中的Cookie:

   • 打开你的浏览器，登录到码云账户（或你要观察的目标网站）。
   • 在浏览器中，清除之前存在的Cookie。这通常可以在浏览器的设置或开发者工具中找到。你可以通过清除浏览器的Cookie来模拟"未登录"状态，以便观察登录过程。

4. 进行登录:

   • 在浏览器中，输入你的用户名和密码并尝试登录到码云（或目标网站）。

5. 观察抓包工具:

   • 回到抓包工具，你应该能够看到登录请求和响应的细节，包括HTTP头部信息和Cookie。

6. 查看登录请求和响应:

   • 查看抓包工具中的请求和响应数据。你应该能够看到包含用户名和密码的POST请求，以及来自服务器的响应，可能包括登录凭据的Cookie。

7. 分析数据:

   • 通过分析这些数据，你可以了解登录过程的细节，包括请求头部、POST数据、响应头部和Cookie的使用。

这个过程允许你深入了解网站登录的内部工作原理，并可以帮助你识别如何实施身份验证和会话管理等功能。请注意，进行网络抓包时，请遵守相关法律和道德规范，不要滥用这些信息。

登陆操作

登陆请求

POST https://gitee.com/login HTTP/1.1
Host: gitee.com
Connection: keep-alive
Content-Length: 394
Cache-Control: max-age=0
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
sec-ch-ua-mobile: ?0
Upgrade-Insecure-Requests: 1
Origin: https://gitee.com
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/91.0.4472.101 Safari/537.36
Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,imag
e/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://gitee.com/login
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
encrypt_key=password&utf8=%E2%9C%93&authenticity_token=36ZqO9tglSN6EB6pF6f2Gt%2B
dalgkbpTDUsJC5OER7w8%3D&redirect_to_url=%2FHGtz2222&user%5Blogin%5D=HGtz2222&enc
rypt_data%5Buser%5Bpassword%5D%5D=Hy2gjJ60312Ss12jSe21GMLPEb766tAhCygL281FLRMpiz
xJVaWGOPlQF7lZhelab1HS2vBiwfBo5C7BnR5ospoBiK1hR6jNXv1lesaYifv9dP1iRC6ozLLMszo%2F
aRh5j5DeYRyKcE0QJjXRGEDg4emXEK1LHVY4M1uqzFS0W58%3D&user%5Bremember_me%5D=0

这是一个示例的登录请求，采用POST方法，发送到https://gitee.com/login。以下是请求头的详细解释，按照你之前提供的格式：

登录请求头部

1. 请求方法和URL:

   • 请求方法：POST
   • URL：https://gitee.com/login

2. Host:

   • 表示服务器主机的地址和端口。
   • 示例：Host: gitee.com

3. Connection:

   • 指定连接选项，此处为保持连接。
   • 示例：Connection: keep-alive

4. Content-Length:

   • 表示请求主体（body）的长度，以字节为单位。
   • 示例：Content-Length: 394

5. Cache-Control:

   • 控制缓存行为的指令。
   • 示例：Cache-Control: max-age=0

6. User-Agent:

   • 表示用户代理（浏览器和操作系统）的属性。
   • 示例：User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.101 Safari/537.36

7. Accept:

   • 指定客户端可接受的内容类型。
   • 示例：Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

8. Content-Type:

   • 指定请求主体的数据格式，此处为application/x-www-form-urlencoded，表示表单数据。
   • 示例：Content-Type: application/x-www-form-urlencoded

9. Referer:

   • 表示请求的来源页面的URL，通常是登录页面。
   • 示例：Referer: https://gitee.com/login

10. Accept-Encoding:

    • 指定客户端可接受的内容编码。
    • 示例：Accept-Encoding: gzip, deflate, br

11. Accept-Language:

    • 指定客户端接受的语言。
    • 示例：Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

12. 请求主体 (Body):

    • 请求主体包含用户的登录信息，通常以键值对的形式传递，如encrypt_key=password、user[login]=HGtz2222等。

这个请求头部用于将登录信息发送到https://gitee.com/login，以进行用户身份验证。服务器将使用请求主体中的数据来验证用户并进行相应的操作。请注意，登录请求通常包含用户名和密码等敏感信息，应该使用安全的HTTPS连接来保护这些数据的传输。

登陆响应

HTTP/1.1 302 Found
Date: Thu, 10 Jun 2021 04:15:58 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Keep-Alive: timeout=60
Server: nginx
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-UA-Compatible: chrome=1
Expires: Sun, 1 Jan 2000 01:00:00 GMT
Pragma: must-revalidate, no-cache, private
Location: https://gitee.com/HGtz2222
Cache-Control: no-cache
Set-Cookie: oschina_new_user=false; path=/; expires=Mon, 10 Jun 2041 04:16:00 
-0000
Set-Cookie: gitee_user=true; path=/
Set-Cookie: gitee-sessionn=M1Rhbk1QUUxQdWk1VEZVQ1BvZXYybG13ZUJFNGR1V0pSYTZyTllEa21pVHlBUE5QU2Qwdk44NXdEam
11T3FZYXFidGNYaFJxcTVDRE1xU05GUXN0ek1Uc08reXRTay9ueTV3OGl5bTdzVGJjU1lUbTJ4bTUvN1
l3RFl4N2hNQmI1SEZpdmVJWStETlJrdWtyU0lDckhvSGJHc3NEZDFWdHc5cjdHaGVtNThNcEVOeFZlaH
c0WVY5NGUzWjc2cjdOcCtSdVJ0VndzdVNxb3dHK1hPSDBDSFB6WlZDc3prUVZ2RVJyTnpTb1c4aFg1Mm
UxM1YvQTFkb1EwaU4zT3hJcmRrS3dxVFZJNXoxaVJwa1liMlplbWR5QXQxY0lvUDNic1hxN2o0WDg1Wk
E9LS10N0VIYXg4Vm5xdllHVzdxa0VlUEp3PT0%3D-
-2f6a24f8d33929fe88ed19d4dea495fbb40ebed6; domain=.gitee.com; path=/; HttpOnly
X-Request-Id: 77f12d095edc98fab27d040a861f63b1
X-Runtime: 0.166621
Content-Length: 92
<html><body>You are being <a href="https://gitee.com/HGtz2222">redirected</a>.
</body></html>

这是一个示例的登录响应，HTTP响应代码为302 Found，表示重定向。

可以看到, 响应中包含了 3 个 Set-Cookie 属性. 其中我们重点关注第三个. 里面包含了一个 gitee-session-n 这样的属性, 属性值是一串很长的加 密之后的信息。这个信息就是用户当前登陆的身份标识. 也称为 “令牌(token)”

以下是响应头和主体的详细解释：

登录响应头部

1. HTTP版本和状态码:

   • HTTP版本：HTTP/1.1
   • 状态码：302 Found

2. Date:

   • 指定响应的日期和时间。
   • 示例：Date: Thu, 10 Jun 2021 04:15:58 GMT

3. Content-Type:

   • 指定响应主体的内容类型。
   • 示例：Content-Type: text/html; charset=utf-8

4. Connection:

   • 指定连接选项，此处为保持连接。
   • 示例：Connection: keep-alive

5. Keep-Alive:

   • 指定保持连接的超时时间。
   • 示例：Keep-Alive: timeout=60

6. Server:

   • 指定服务器名称和版本信息。
   • 示例：Server: nginx

7. X-XSS-Protection:

   • 启用或禁用浏览器的跨站脚本攻击保护。
   • 示例：X-XSS-Protection: 1; mode=block

8. X-Content-Type-Options:

   • 指定浏览器是否应该嗅探响应中的内容类型。
   • 示例：X-Content-Type-Options: nosniff

9. X-UA-Compatible:

   • 指定浏览器的兼容性模式。
   • 示例：X-UA-Compatible: chrome=1

10. Expires:

    • 指定响应的过期时间。
    • 示例：Expires: Sun, 1 Jan 2000 01:00:00 GMT

11. Pragma:

    • 指定缓存策略，如必须重新验证、不缓存等。
    • 示例：Pragma: must-revalidate, no-cache, private

12. Location:

    • 重定向的目标URL，表示登录成功后用户将被重定向到https://gitee.com/HGtz2222。
    • 示例：Location: https://gitee.com/HGtz2222

13. Cache-Control:

    • 控制缓存行为的指令，此处指示不缓存。
    • 示例：Cache-Control: no-cache

14. Set-Cookie:

    • 设置Cookie，其中包括oschina_new_user和gitee_user等Cookie。
    • 示例：

    Set-Cookie: oschina_new_user=false; path=/; expires=Mon, 10 Jun 2041 04:16:00 -0000
    Set-Cookie: gitee_user=true; path=/
    Set-Cookie: ...
    
    

15. X-Request-Id:

    • 响应中的请求ID。
    • 示例：X-Request-Id: 77f12d095edc98fab27d040a861f63b1

16. X-Runtime:

    • 服务器处理请求的运行时间。
    • 示例：X-Runtime: 0.166621

响应主体

响应主体是一个HTML文档，包含了重定向消息，告诉用户他们将被重定向到https://gitee.com/HGtz2222。这是一个常见的登录成功后的操作，用户将被重定向到他们的个人页面或其他受保护的区域。

这个响应表明登录成功，并且用户的身份验证状态已更新，将被重定向到新的URL。登录后，用户的身份将由gitee_user Cookie来维护，这个Cookie将在登录成功后的响应头中设置。

重定向是常见的用户身份验证操作之一，它允许用户成功登录后被自动导航到他们的目标页面，以提供良好的用户体验。

访问其他页面

登陆成功之后, 此时可以看到后续访问码云的其他页面(比如个人主页), 请求中就都会带着刚才获取到的 Cookie 信息

GET https://gitee.com/HGtz2222 HTTP/1.1
Host: gitee.com
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/91.0.4472.101 Safari/537.36
Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,imag
e/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
sec-ch-ua-mobile: ?0
Referer: https://gitee.com/login
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cookie: oschina_new_user=false; user_locale=zh-CN; yp_riddler_id=1ce4a551-a160-
4358-aa73-472762c79dc0; visit-gitee--2021-05-06%2010%3A12%3A24%20%2B0800=1; 
sensorsdata2015jssdkcross=%7B%22distinct_id%22%3A%22726826%22%2C%22first_id%22%3
A%22175869ba5888b6-0ea2311dc53295-303464-2073600-
175869ba5899ac%22%2C%22props%22%3A%7B%22%24latest_traffic_source_type%22%3A%22%E
7%9B%B4%E6%8E%A5%E6%B5%81%E9%87%8F%22%2C%22%24latest_search_keyword%22%3A%22%E6%
9C%AA%E5%8F%96%E5%88%B0%E5%80%BC_%E7%9B%B4%E6%8E%A5%E6%89%93%E5%BC%80%22%2C%22%2
4latest_referrer%22%3A%22%22%7D%2C%22%24device_id%22%3A%22175869ba5888b6-
0ea2311dc53295-303464-2073600-175869ba5899ac%22%7D; remote_way=svn; 
tz=Asia%2FShanghai; 
Hm_lvt_24f17767262929947cc3631f99bfd274=1622637014,1622712683,1622863899,1623298
442; Hm_lpvt_24f17767262929947cc3631f99bfd274=1623298550; gitee_user=true; giteesessionn=M1Rhbk1QUUxQdWk1VEZVQ1BvZXYybG13ZUJFNGR1V0pSYTZyTllEa21pVHlBUE5QU2Qwdk44NXdEam
11T3FZYXFidGNYaFJxcTVDRE1xU05GUXN0ek1Uc08reXRTay9ueTV3OGl5bTdzVGJjU1lUbTJ4bTUvN1
l3RFl4N2hNQmI1SEZpdmVJWStETlJrdWtyU0lDckhvSGJHc3NEZDFWdHc5cjdHaGVtNThNcEVOeFZlaH
c0WVY5NGUzWjc2cjdOcCtSdVJ0VndzdVNxb3dHK1hPSDBDSFB6WlZDc3prUVZ2RVJyTnpTb1c4aFg1Mm
UxM1YvQTFkb1EwaU4zT3hJcmRrS3dxVFZJNXoxaVJwa1liMlplbWR5QXQxY0lvUDNic1hxN2o0WDg1Wk
E9LS10N0VIYXg4Vm5xdllHVzdxa0VlUEp3PT0%3D-
-2f6a24f8d33929fe88ed19d4dea495fbb40ebed6

这是一个示例的GET请求，用于访问 https://gitee.com/HGtz2222 登陆成功之后的页面。以下是请求头的详细解释，：

GET请求头部

1. 请求方法和URL:

   • 请求方法：GET
   • URL：https://gitee.com/HGtz2222

2. Host:

   • 表示服务器主机的地址和端口。
   • 示例：Host: gitee.com

3. Connection:

   • 表示连接方式，这里是保持连接。
   • 示例：Connection: keep-alive

4. Cache-Control:

   • 控制缓存的行为，这里是不使用缓存。
   • 示例：Cache-Control: max-age=0

5. Upgrade-Insecure-Requests:

   • 表示是否允许不安全的请求升级为安全的请求。
   • 示例：Upgrade-Insecure-Requests: 1

6. User-Agent:

   • 表示浏览器和操作系统的属性，用于标识客户端。
   • 示例：User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.101 Safari/537.36

7. Accept:

   • 表示客户端可以接受的媒体类型。
   • 示例：Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

8. Sec-Fetch-Site:

   • 表示请求目标的站点类型，这里是"same-origin"，表示同源请求。
   • 示例：Sec-Fetch-Site: same-origin

9. Sec-Fetch-Mode:

   • 表示请求模式，这里是"navigate"，表示导航请求。
   • 示例：Sec-Fetch-Mode: navigate

10. Sec-Fetch-User:

    • 表示请求用户，这里是"?1"，表示请求用户已经存在。
    • 示例：Sec-Fetch-User: ?1

11. Sec-Fetch-Dest:

    • 表示请求目标的类型，这里是"document"，表示文档请求。
    • 示例：Sec-Fetch-Dest: document

12. sec-ch-ua:

    • 表示浏览器和操作系统的属性。
    • 示例：sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"

13. sec-ch-ua-mobile:

    • 表示浏览器在移动设备上的属性。
    • 示例：sec-ch-ua-mobile: ?0

14. Referer:

    • 表示请求是从哪个页面跳转过来的。
    • 示例：Referer: https://gitee.com/login

15. Accept-Encoding:

    • 表示客户端可以接受的编码方式，例如gzip、deflate等。
    • 示例：Accept-Encoding: gzip, deflate, br

16. Accept-Language:

    • 表示客户端的语言偏好。
    • 示例：Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

17. Cookie:

    • 表示之前获取到的Cookie信息，用于在服务器端识别用户。
    • 示例：包含多个Cookie键值对，如Cookie: oschina_new_user=false; user_locale=zh-CN; ...

这个GET请求包含了之前登录成功后获取的Cookie信息，用于访问个人主页

请求你中的 Cookie 字段也包含了一个 gitee-session-n 属性， 里面的值和刚才服务器返回的值相 同。 后续只要访问 gitee 这个网站， 就会一直带着这个令牌， 直到令牌过期/下次重新登陆。

理解登陆过程

这个过程和去医院看病很相似：

1. 到医院挂号:

   • 在网站上，这相当于首次访问网站并填写登录信息（如用户名和密码）。
   • 提供身份证等于提供你的用户名和密码。
   • 得到“就诊卡”相当于从服务器收到一个用于后续识别的令牌或Cookie。

2. 后续去各个科室:

   • 当你浏览一个登录后才能访问的页面或进行其他操作时，你不需要再次输入用户名和密码。这是因为你的浏览器会自动发送那个令牌或Cookie，告诉服务器你是谁。
   • 这就像用就诊卡来证明自己的身份，而不是每次都出示身份证。

3. 看完病后注销就诊卡:

   • 在网站上，这类似于点击“注销”或“退出登录”按钮。这通常会使当前的令牌或Cookie失效，这样即使其他人得到了它也不能用它来伪装成你。
   • 如果你的就诊卡丢了，它不会泄露你的身份证信息，因为它只是一个令牌，不包含敏感信息。

4. 再次来医院看病:

   • 如果你想再次访问受限制的内容，你需要重新登录，这时服务器会为你生成一个新的令牌或Cookie。
   • 这就像每次去医院时都需要重新办理一个新的就诊卡。

通过这个比喻，我们可以更容易地理解身份验证的原理，以及令牌和Cookie在其中的作用。这也强调了为什么在使用完后应该注销令牌或Cookie，以保护自己的账户安全。

认识请求 “正文” (body)

正文中的内容格式和 header 中的 Content-Type 密切相关。 上面也罗列了三种常见的情况。

HTTP请求正文（Request Body）是HTTP请求的一部分，它包含了客户端发送给服务器的数据或内容。请求正文的内容格式通常与请求头中的Content-Type字段密切相关，Content-Type字段指定了请求正文的数据类型和格式。

以下是几种常见的请求正文示例，每种示例与不同的Content-Type相关：

1、application/x-www-form-urlencoded：这是一种常见的请求正文格式，通常用于HTML表单提交。数据以键值对的形式编码，并以application/x-www-form-urlencoded格式发送给服务器。示例：

Content-Type: application/x-www-form-urlencoded
user=username&password=pass123

这个请求正文包含了用户的用户名和密码。

2、application/json：JSON格式的请求正文通常用于通过JSON对象发送数据给服务器。示例：

Content-Type: application/json
{
  "name": "John",
  "age": 30,
  "city": "New York"
}

这个请求正文包含了一个JSON对象，描述了用户的名称、年龄和所在城市。

3、multipart/form-data：这种格式通常用于文件上传，允许在请求正文中包含文件数据。示例：

Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="example.jpg"
Content-Type: image/jpeg
(binary data for the file)

这个请求正文包含了一个文件，文件名为"example.jpg"。

HTTP请求正文的内容可以根据应用程序的需求和HTTP请求的目的而有所不同。Content-Type字段用于指定请求正文的数据类型和编码方式，以确保服务器能够正确解释和处理请求的内容。服务器会根据Content-Type的值来解析请求正文，并采取相应的操作，无论是提交表单数据、JSON对象，还是上传文件。

下面可以通过抓包来观察这几种情况：

（1）application/x-www-form-urlencoded，抓取码云上传头像请求

POST https://gitee.com/profile/upload_portrait_with_base64 HTTP/1.1
Host: gitee.com
Connection: keep-alive
Content-Length: 107389
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
Accept: */*
X-CSRF-Token: 6ROfZGr4Y7Qx8td1TuKCnrG8gbODLCSUqUBZSw2b+ac=
X-Requested-With: XMLHttpRequest
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/91.0.4472.101 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: https://gitee.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://gitee.com/HGtz2222
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cookie: oschina_new_user=false; user_locale=zh-CN; yp_riddler_id=1ce4a551-a160-
4358-aa73-472762c79dc0; visit-gitee--2021-05-06%2010%3A12%3A24%20%2B0800=1; 
sensorsdata2015jssdkcross=%7B%22distinct_id%22%3A%22726826%22%2C%22first_id%22%3
A%22175869ba5888b6-0ea2311dc53295-303464-2073600-
175869ba5899ac%22%2C%22props%22%3A%7B%22%24latest_traffic_source_type%22%3A%22%E
7%9B%B4%E6%8E%A5%E6%B5%81%E9%87%8F%22%2C%22%24latest_search_keyword%22%3A%22%E6%
9C%AA%E5%8F%96%E5%88%B0%E5%80%BC_%E7%9B%B4%E6%8E%A5%E6%89%93%E5%BC%80%22%2C%22%2
4latest_referrer%22%3A%22%22%7D%2C%22%24device_id%22%3A%22175869ba5888b6-
0ea2311dc53295-303464-2073600-175869ba5899ac%22%7D; remote_way=svn; 
tz=Asia%2FShanghai; 
Hm_lvt_24f17767262929947cc3631f99bfd274=1622637014,1622712683,1622863899,1623298
442; gitee_user=true; Hm_lpvt_24f17767262929947cc3631f99bfd274=1623298560; giteesessionn=c0hXQ0I5SjR1bWg5M01IR3RYS3hLT0RhelN1aFVuMExKdEdSSmRaQWIwRy9QWFUwV0thdzV1alIzYj
RaOU9ZeDdkZEJZK2RtTVRNeTNFRHNYVW9ha2hEcWJyclIwS1NVRG1EL0xxTmJXSGxvSzh3c28zOHBia1
pIOFQrU3RYeWE0bE13S09DTm5MZWZ5WW5WUVFpSzFiMGFWbHRDQ0xRakc1Um5yY21HQllqeUpNLzBvZF
gxbHVhN09uK2h1VVVmRHZkS3BmVGEwcDhyNjJVb1p0RFRLY0VOem5vNEEvd0FuYzJJYlhZcGlyenZQc3
dSbXBNUWI3UUwrRDBrV2N0UHZRdjFBUXF5b0Y0L1Vrd09pQVBKNkdjZmY5cHlDTCtMWG4ya0tIaW5LcE
tBTkw4cGFGVjhUQ0djMWhkOXI0bUFteUY4VW80RHl2T2Q2YmxwR1d3M3Rad1RhZWhhdnNiTTNrcE1RV2
NyZ1dYeDRoR0dpanh4bERNMTBuenB1NkgxLS16QUdJS3NlZG9mTVBtYlVlREppck1BPT0%3D-
-898d1284181ca494918d29ac44f9a3a79d448a9b
avatar=data%3Aimage%2Fpng%3Bbase64%2CiVBORw0KGgoAAAANSUhEUgAAAPgAAAD4CAYAAADB0Ss
LAAAg......

实际的抓包结果比较长， 此处没有全部贴出。

这是一个通过POST请求上传用户头像的示例。让我们来分析一下这个请求：

1. 请求方法：这是一个HTTP POST请求。

2. 请求目标：请求的URL是https://gitee.com/profile/upload_portrait_with_base64

3. 请求头部：

   • Host: gitee.com 是请求的主机名。
   • Connection: keep-alive 表示要保持长连接。
   • Content-Length: 107389 表示请求正文的长度为107389字节。
   • sec-ch-ua, Accept, X-CSRF-Token, X-Requested-With, sec-ch-ua-mobile, User-Agent, Content-Type, Origin, Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, Referer, Accept-Encoding, Accept-Language, Cookie 这些都是请求头的字段，它们包含了与请求相关的各种信息，包括用户代理信息（User-Agent），请求的来源（Referer），Cookie等。

4. 请求正文（Body）：

   • 这是一个表单形式（application/x-www-form-urlencoded）的请求。请求正文中包含了用户头像的数据。
   • avatar=data%3Aimage%2Fpng%3Bbase64%2CiVBORw0KGgoAAAANSUhEUgAAAPgAAAD4CAYAAADB0SsLAAAg… 是头像数据的一部分。这部分可能包含了用户头像的图像数据，以Base64编码的方式表示。

这个请求的主要目的是将用户头像数据上传到指定的URL。请求头中包含了一些与请求相关的信息，包括用户代理（User-Agent）、来源（Referer）、Cookie等。请求正文中包含了头像数据，可以由服务器来解析和处理。

（2）multipart/form-data 抓取系统的 “上传简历” 功能：

POST https://v.bitedu.vip/tms/oss/upload/file HTTP/1.1
Host: v.CSDN.vip
Connection: keep-alive
Content-Length: 293252
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
Authorization: Bearer 
eyJhbGciOiJIUzUxMiJ9.eyJsb2dpbl91c2VyX2tleSI6IjFiYThjMDM5LWUyN2UtNDdhZS04YTAzLTN
mNWMzY2UwN2YyNSJ9.VQWoqrrgWZpDNc81tYfSvna8A9uZP6QKqucnvGMuY8wbavHF30rx7NG9VxnAo1
78V0nOJBd75QxRvNRgpY6-Iw
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/91.0.4472.101 Safari/537.36
Content-Type: multipart/form-data; boundary=----
WebKitFormBoundary8d5Rp4eJgrUSS3wT
Accept: */*
Origin: https://v.bitedu.vip
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://v.baidu.vip/personInf/student?userId=634
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cookie: rememberMe=true; username=2342412223; AdminToken=eyJhbGciOiJIUzUxMiJ9.eyJsb2dpbleSI6IjFiYThjMDM5LWUyN2UtNDdhZS04Y
TAzLTNmNWMzY2UwN2YyNSJ9.VQWoqrrgWZpDNc81tYfSvna8A9uZP6QKqucnvGMuY8wbavHF30rx7NG9
VxnAo178V0nOJBd75QxRvNRgpY6-Iw
------WebKitFormBoundary8d5Rp4eJgrUSS3wT
Content-Disposition: form-data; name="file"; filename="李星亚 Java开发工程师.pdf"
Content-Type: application/pdf
%PDF-1.7
%³  
1 0 obj
<</Names <</Dests 4 0 R>> /Outlines 5 0 R /Pages 2 0 R /Type /Catalog>>
endobj
3 0 obj
<</Author ( N v~N•) /Comments () /Company () /CreationDate 
(D:20201122145133+06'51') /Creator (   W P S e [W) /Keywords () /ModDate 
(D:20201122145133+06'51') /Producer () /SourceModified (D:20201122145133+06'51') 
/Subject () /Title () /Trapped /False>>
endobj
13 0 obj
<</AIS false /BM /Normal /CA 1 /Type /ExtGState /ca 1>>
endobj

实际的抓包结果比较长， 此处没有全部贴出。

这是一个通过POST请求上传文件的示例，使用的是multipart/form-data格式。让我来分析这个请求：

1. 请求方法：这是一个HTTP POST请求。

2. 请求目标：请求的URL是https://v.CSDN.vip/tms/oss/upload/file。

3. 请求头部：

   • Host: v.CSDN.vip 是请求的主机名。
   • Connection: keep-alive 表示要保持长连接。
   • Content-Length: 293252 表示请求正文的长度为293252字节。
   • sec-ch-ua, Authorization, sec-ch-ua-mobile, User-Agent, Content-Type, Accept, Origin, Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, Referer, Accept-Encoding, Accept-Language, Cookie 这些都是请求头的字段，它们包含了与请求相关的各种信息，包括用户代理信息（User-Agent）、授权信息（Authorization）、请求的来源（Referer）、Cookie等。

4. 请求正文（Body）：

   • 这是一个multipart/form-data格式的请求。请求正文以------WebKitFormBoundary8d5Rp4eJgrUSS3wT开始，然后包含了文件数据。
   • Content-Disposition 字段中的name属性表示字段的名称，filename属性表示上传文件的原始文件名。
   • Content-Type 字段表示上传的文件类型为application/pdf，PDF文件。
   • 接下来是文件内容，这里显示了PDF文件的一些内容。

这个请求的主要目的是将一个文件上传到指定的URL，文件的名称是"李星亚 Java开发工程师.pdf"，文件类型为PDF。请求头中包含了一些与请求相关的信息，包括用户代理（User-Agent）、授权信息（Authorization）、来源（Referer）、Cookie等。请求正文以multipart/form-data格式包含了文件数据。

（3） application/json 抓取系统的 “上传简历” 功能：

POST https://v.bitedu.vip/tms/login HTTP/1.1
Host: v.CSDN.vip
Connection: keep-alive
Content-Length: 105
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/91.0.4472.101 Safari/537.36
Access-Control-Allow-Methods: PUT,POST,GET,DELETE,OPTIONS
Content-Type: application/json;charset=UTF-8
Access-Control-Allow-Origin: *
Accept: application/json, text/plain, */*
Access-Control-Allow-Headers: Content-Type, Content-Length, Authorization, 
Accept, X-Requested-With , yourHeaderFeild
Origin: https://v.CSDN.vip
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://v.CSDN.vip/login
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cookie: rememberMe=true; username=123456789
{"username":"123456789","password":"xxxx","code":"u58u","uuid":"9bd8e09ea27b48cd
acc6a6bc41d9f462"}

这是一个通过POST请求发送JSON数据的示例。下面是对这个请求的分析：

1. 请求方法：这是一个HTTP POST请求。

2. 请求目标：请求的URL是 https://v.CSDN.vip/tms/login 。

3. 请求头部：

   • Host: v.bitedu.vip 是请求的主机名。
   • Connection: keep-alive 表示要保持长连接。
   • Content-Length: 105 表示请求正文的长度为105字节。
   • sec-ch-ua, sec-ch-ua-mobile, User-Agent, Access-Control-Allow-Methods, Content-Type, Access-Control-Allow-Origin, Accept, Access-Control-Allow-Headers, Origin, Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, Referer, Accept-Encoding, Accept-Language, Cookie 这些都是请求头的字段，包含了与请求相关的各种信息，包括用户代理信息（User-Agent）、允许的请求方法（Access-Control-Allow-Methods）、CORS相关信息、来源（Referer）、Cookie等。

4. 请求正文（Body）：

   • 请求正文以JSON格式发送，Content-Type 字段指明了请求的内容类型为application/json;charset=UTF-8，字符编码为UTF-8。
   • JSON数据包含在大括号 {} 内，包含了以下字段：
     • username: “123456789”
     • password: “xxxx”
     • code: “u58u”
     • uuid: “9bd8e09ea27b48cdacc6a6bc41d9f462”

这个请求的主要目的是向 https://v.CSDN.vip/tms/login 发送一个JSON数据，包含了用户名、密码、验证码等信息。请求头中包含了一些与请求相关的信息，包括用户代理（User-Agent）、CORS设置、来源（Referer）、Cookie等。

HTTP 响应详解

HTTP响应是服务器对客户端请求的回复。每次你在浏览器中输入一个URL、点击一个链接或者通过其他方式进行网络请求，都会收到一个HTTP响应。HTTP响应由三部分组成：状态行、响应头和响应正文。

状态行：这是响应的第一行，包含了HTTP版本、状态码和状态描述。例如：“HTTP/1.1 200 OK”。

认识 “状态码” (status code)

HTTP响应的状态码（Status Code）是用于表示请求处理结果的三位数字代码，表示访问一个页面的结果。每个状态码对应一种不同的响应情况，用于通知客户端发出的请求是否成功，或者出现了什么问题。

状态码：状态码是一个三位数，用于表示请求的处理结果。状态码的第一个数字定义了响应的类别：

• 1xx：信息响应。表示请求已接收，继续处理。
• 2xx：成功。表示请求已被成功接收、理解和接受。
• 3xx：重定向。要完成请求，需要进一步操作。
• 4xx：客户端错误。请求包含语法错误或无法完成。
• 5xx：服务器错误。服务器在处理请求时发生错误。

以下是一些常见的HTTP状态码：

1. 200 OK：这是最常见的状态码，表示请求已成功处理。服务器已返回请求的数据。
2. 201 Created：表示请求已经成功，并且服务器创建了一个新的资源，通常在POST请求成功后返回。
3. 204 No Content：表示请求已成功处理，但响应不包含实体主体。通常用于DELETE请求。
4. 400 Bad Request：客户端请求有语法错误，服务器无法理解。
5. 401 Unauthorized：表示需要进行身份验证或者认证信息无效，通常要求用户提供有效的用户名和密码。
6. 403 Forbidden：服务器已经理解请求，但拒绝执行它，通常是因为权限不足。
7. 404 Not Found：请求的资源未找到。
8. 500 Internal Server Error：表示服务器在执行请求时出现了错误，客户端通常无法解决。
9. 502 Bad Gateway：服务器作为网关或代理，从上游服务器接收到无效响应。
10. 503 Service Unavailable：服务器当前无法处理请求，通常是因为服务器过载或正在维护。

这些状态码帮助客户端理解请求的结果，根据不同的状态码，客户端可以采取相应的行动。HTTP协议还有许多其他状态码，每个状态码都有特定的含义。理解这些状态码有助于开发者和系统管理员更好地诊断和解决HTTP请求和响应的问题。

认识重定向

重定向是一种HTTP响应机制，用于将客户端请求从一个URL（通常是A）重定向到另一个URL（通常是B）。重定向是服务器向客户端发出的指令，告诉客户端重新发起请求，但这次请求的目标是新的URL。

HTTP重定向通常用于以下情况：

1. 永久重定向——资源永久移动：HTTP状态码301 Moved Permanently表示资源的位置已永久移动到新的URL，客户端应该将以后的请求直接发送到新的URL。可缓存。
2. 临时重定向——资源临时移动：HTTP状态码302 Found表示资源的位置已临时移动到新的URL，客户端应该发送下一个请求到新的URL。这个重定向可能只是暂时的。不可缓存。
3. 登录或认证：网站可能要求用户登录或提供身份验证信息才能访问某些资源。如果用户尚未登录或未提供必要的身份验证信息，服务器可能返回一个重定向响应，将用户引导到登录页面。
4. URL重写或规范化：有时，服务器将对URL进行规范化或重写，以确保一致性和遵循最佳实践。这可以通过重定向来实现。

很多时候页面跳转也可以通过重定向来实现，还有的时候某个网站/服务器迁移了（IP/域名改变），就可以给旧的地址一个重定向响应，访问地址就会

重定向在Web开发和网站维护中非常常见，用于多种情况，包括页面跳转和处理服务器迁移。以下是一些常见的应用情景：

1. 页面跳转：重定向经常用于实现页面跳转，如从一个URL重定向到另一个URL。这可以用于用户登录后自动跳转到他们的个人资料页面，或者从旧的URL跳转到新的URL以维护网站的结构和导航。
2. 服务器迁移：当网站的服务器或IP地址发生变化时，服务器可以向旧的地址发送重定向响应，将访问者引导到新的地址。这有助于确保旧的链接仍然有效，避免了断裂的链接和丢失的访问者。
3. SEO优化：在搜索引擎优化（SEO）方面，重定向是维护网站的排名和搜索引擎索引的关键工具。当网页的URL结构发生变化时，通过使用301永久重定向，可以将搜索引擎引导到新的URL，以确保排名和索引的连续性。
4. 身份验证和授权：网站可能会使用重定向来引导用户进行身份验证，例如在用户未登录时将他们重定向到登录页面。一旦登录成功，他们将被重定向回原始请求的页面。

重定向是HTTP协议的一个强大特性，它允许网站管理者以一种用户友好的方式维护网站结构，同时确保访问者能够访问所需的内容。这对于提供良好的用户体验和维护网站的可用性至关重要。

总的来说，重定向是HTTP中的一种重要机制，允许服务器将客户端请求引导到新的URL，以实现资源的移动、登录、规范化等目的。客户端收到重定向响应后，会自动向新的URL重新发送请求。

200 OK

这是一个最常见的状态码， 表示访问成功。

抓包抓到的大部分结果都是 200：

例如访问搜狗主页：

HTTP/1.1 200 OK
Server: nginx
Date: Thu, 10 Jun 2021 06:07:27 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Vary: Accept-Encoding
Set-Cookie: black_passportid=; path=/; expires=Thu, 01 Jan 1970 00:00:00 
GMT; domain=.sogou.com
Pragma: No-cache
Cache-Control: max-age=0
Expires: Thu, 10 Jun 2021 06:07:27 GMT
UUID: 80022370-065c-49b0-a970-31bc467ff244
Content-Length: 14805
<!DOCTYPE html><html lang="cn"><head><meta name="viewport" 
content="width=device-width,minimum-scale=1,maximum-scale=1,userscalable=no"><script>window._speedMark = new Date(); window.lead_ip = 
'1.80.175.234';
......

注意：在抓包观察响应数据的时候， 可能会看到压缩之后的数据， 形如：

​

网络传输中 “带宽” 是一个稀缺资源，为了传输效率更高往往会对数据进行压缩。

点击 Fiddler 中的 ​

即可进行解压缩，看到原始的内容。

404 Not Found

HTTP/1.1 404 Not Found
Server: nginx
Date: Thu, 10 Jun 2021 05:19:04 GMT
Content-Type: text/html
Connection: keep-alive
Vary: Accept-Encoding
Content-Length: 564
<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

403 Forbidden

HTTP状态码403表示访问被服务器拒绝，通常由于权限问题或认证问题引起。这表示客户端请求了一个资源，但服务器认为客户端没有足够的权限来访问该资源。

常见的情况包括：

1. 需要身份验证: 服务器上的资源要求用户进行身份验证，例如登录，以便访问。如果客户端没有提供有效的凭据或未登录，服务器将返回403错误。
2. 权限不足: 即使用户已登录，但他们可能没有足够的权限来访问特定资源。这可能是由于角色、许可或其他授权问题引起的。
3. 私有资源: 有些资源被标记为私有，只有特定的用户或组可以访问它们。如果用户不属于这些组，他们将被拒绝访问。
4. IP过滤或防火墙规则: 有时服务器配置了IP过滤或防火墙规则，只允许特定IP地址或范围的IP地址访问资源。如果客户端IP不在白名单中，它将收到403错误。

403 Forbidden与404 Not Found不同，后者表示资源未找到，而前者表示资源存在但不可访问。通常，服务器会在403响应中提供有关拒绝访问的详细信息，以帮助客户端了解拒绝的原因。这有助于维护资源的安全性和访问控制。

例如: 查看码云的私有仓库， 如果不登陆， 就会出现 403。

HTTP/1.1 403 Forbidden
Date: Thu, 10 Jun 2021 06:05:36 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Keep-Alive: timeout=60
Server: nginx
Vary: Accept-Encoding
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-UA-Compatible: chrome=1
Expires: Sun, 1 Jan 2000 01:00:00 GMT
Pragma: must-revalidate, no-cache, private
Cache-Control: no-cache
Set-Cookie: oschina_new_user=false; path=/; expires=Mon, 10 Jun 2041 
06:05:40 -0000
Set-Cookie: gitee-sessionn=ejEvQnYza2RlaXh0KzRaN3QrNWI2TzdLOE03bU5UNjRKdGlqWUFkMlJ2YktWYTRtcEtIVExOZE
dJSFJFSkdiWmcxNmhjSTdneUZFaHFtalNKQUJWcDlUNDZYd2lBaElXNy9FaWRHQkl4d2RsS1RIWn
RCNFphQm5JUjZOdjdsSDh5TlNvZ3hZdTBXNXUrU2c2azN2UVNFOWwyQnJvQzZ6MEluaEFFYnRoV0
luOFlNWEEzWlR0K1g4WDlQRjNkSlNjZ1pUMGc0YkhreVNJMUV4YkVUUk0weXFqbGhQYzN5djA2bF
Jyc3o4MHRVWkkxcHdQVG5abmJ2NmlqV1dEYjlWaUpNNno3UGFpZ3lsb1RqeXAranFHRlE9PS0tdU
5JMGZ3UUpwODRYdjF1MXdyYmFKUT09--52babe9c2dcb63fa02bc32d25bc0e854f4065f5f; 
domain=.gitee.com; path=/; HttpOnly
X-Request-Id: 82a740fb98838c305c4cc597ab6f48c0
X-Runtime: 0.020299
Content-Length: 7092
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>您的访问受限 (403)</title>
......

405 Method Not Allowed

当客户端发送了一个服务器不支持的HTTP请求方法时，服务器会返回405状态码，表示请求方法不被允许或不被支持。

这通常发生在以下情况下：

1. 服务器不支持该方法: 服务器可能只支持特定的HTTP请求方法，例如只支持GET和POST，而不支持PUT或DELETE等其他方法。
2. URL路径不匹配: 有时服务器可能要求特定的URL路径才能使用某些HTTP方法。如果请求的URL路径不匹配要求，服务器也可能返回405状态码。
3. 权限问题: 服务器可能要求用户进行身份验证或授权，以便使用某些HTTP方法，如果客户端未提供有效的凭据或权限不足，服务器会返回405状态码。

客户端应该检查响应中的允许的方法列表（通常包含在响应头中的"Allow"字段）以了解服务器支持哪些HTTP方法。这有助于客户端更好地与服务器互动，并采取适当的措施，以符合服务器的要求。

500 Internal Server Error

这个状态码表示服务器在处理客户端请求时遇到了内部错误，通常是由于服务器的代码执行过程中出现异常、崩溃或其他不可预测的问题导致的。

一般情况下，正常运行的网站不应该频繁返回500错误，因为这意味着服务器出现了问题。然而，偶尔会发生内部错误，例如服务器端的代码错误、数据库连接问题、资源不足等，这些问题都可能导致500错误。对于网站运维团队来说，监控和及时处理500错误是非常重要的，以确保网站的稳定性和可用性。

对于用户来说，500错误通常表示网站暂时无法提供服务，可能需要稍后再次尝试，或者联系网站管理员以报告问题。这些错误通常不是用户引起的，而是服务器端的问题。

504 Gateway Timeout

HTTP状态码504 Gateway Timeout表示当客户端（通常是浏览器）向代理服务器（如反向代理服务器或网关）发送请求时，代理服务器等待服务器的响应，但由于服务器处理时间过长或超负荷，没有及时响应，导致超时。

这种情况经常发生在服务器负载非常高的情况下，例如大规模的促销活动、秒杀事件或其他突发的流量激增。服务器不仅要处理正常的请求，还要应对大量同时到达的请求，这可能导致服务器响应变慢，或者在某些情况下完全无法响应。当代理服务器等待服务器响应的时间超过了特定的超时阈值，就会返回504 Gateway Timeout错误，告知客户端请求超时。

这种情况通常需要网站管理员或开发人员采取措施，以增加服务器的处理能力，优化代码，缓解负载，或使用负载均衡等策略，以确保服务器能够在高负载时仍然提供可靠的服务。

这种情况在双十一等 “秒杀” 场景中容易出现， 平时不太容易见到。

302 Move temporarily

这个状态码表示请求的资源已被临时移到不同的URL，客户端应该使用新的URL来访问资源。与您的手机呼叫转移比喻类似，当客户端访问原始URL时，服务器将向客户端提供一个临时的新URL，客户端应该立即使用这个新URL来获取资源，而不需要告诉其他客户端或用户关于URL的更改。

HTTP状态码302通常用于以下情况：

1. 临时更改: 资源的位置发生了临时更改，但未来可能会再次返回原始URL。这可以是因为维护、重定向到另一个服务器或其他原因。
2. 用户会话管理: 在某些Web应用程序中，302状态码用于管理用户会话。例如，用户登录后，服务器可能会返回一个临时重定向以将用户导向他们的个人资料页面。

客户端收到302状态码后，应该遵循新的URL以获取资源，而不应该保留或缓存原始URL。这有助于确保客户端能够访问到实际的资源位置。

当用户成功登录时，服务器通常会向客户端发送302状态码，并在响应头中包含一个名为"Location"的字段，该字段指示要将客户端重定向到哪个URL。这是一种实现自动跳转到另一个页面的常见方式。

例如，如果用户成功登录，服务器会向客户端发送以下HTTP响应头：

HTTP/1.1 302 Found
Location: https://gitee.com/HGtz2222

客户端（通常是浏览器）会自动遵循这个重定向，向指定的URL发送GET请求，以获取新的页面或资源。在这种情况下，浏览器会自动跳转到"https://gitee.com/HGtz2222"页面，以实现登录后的导航到主页或其他目标页面。

这种重定向机制对于用户体验非常有用，因为它可以使用户无需手动点击链接或输入URL，而是在登录后自动跳转到目标页面。这在许多Web应用程序中都很常见，以提供便捷的用户体验。

301 Moved Permanently

这个状态码表示资源的位置已永久移动到不同的URL，并且客户端应该使用新的URL来访问资源。与HTTP状态码302 Found（临时重定向）不同，301状态码表明资源已永久移动，客户端应该在后续的请求中自动使用新的URL。

当客户端（通常是浏览器）接收到带有301状态码的HTTP响应时，它会将原始URL与新的URL关联起来，并在后续请求中使用新的URL。这意味着即使用户尝试访问原始URL，他们也会被自动重定向到新的URL，无需手动更改或重新输入。

301状态码通常用于以下情况：

1. 永久更改：资源的URL已永久更改，并且以后将不再使用原始URL。
2. SEO和链接更新：网站所有者可能会使用301状态码来通知搜索引擎和其他站点，资源的新位置，以确保旧的链接被正确索引并引导到新的URL。
3. URL重构：当网站重新组织或更改URL结构时，301状态码可用于确保以前的URL仍然引导到新的URL，以维护用户和搜索引擎的可用性。

总之，301 Moved Permanently状态码表示资源的永久重定向，它会在未来的请求中自动使用新的URL，确保用户能够访问到实际的资源位置。

418 I am a teapot!

418这个状态吗是HTTP 的 RFC文档中专门规定的一个状态码，这个状态码并没有实际的意义。

HTTP状态码418 “I’m a teapot” 是一个非常有趣的状态码，它在HTTP RFC文档中被定义为一种"彩蛋"或"愚人节玩笑"。这个状态码的描述是：“这个实体拒绝与一个被用茶壶冲泡咖啡的请求一同工作”。

它实际上没有实际用途，仅仅是HTTP协议的一种有趣的规定。通常情况下，这个状态码不会在正式的Web应用程序中使用，但它确实显示了HTTP规范的灵活性和幽默感。

这个状态码的背后是一种幽默，是HTTP规范中的一种娱乐元素，而不是用于真正的Web开发或通信。

状态码小结

使用不同的数字或代码来表示不同的状态或错误是一种非常常见的做法，不仅在HTTP状态码中，还在许多其他编程领域和协议中。这种做法有以下几个优点：

1. 简单而有效：状态码或错误码的数字表示可以提供清晰而紧凑的信息，不需要冗长的描述。这使得通信更加高效。
2. 标准化：通过使用标准化的状态码或错误码，不同的系统和应用程序可以共享相同的理解，而无需重新定义状态或错误。
3. 易于处理：编程语言通常提供了处理错误码的工具，如C语言中我们接触过的ERROR错误码，有 strerror函数，使得开发人员能够更容易地理解和处理错误。
4. 跨平台和跨语言：数字状态码通常不受特定编程语言或操作系统的限制，因此它们在不同平台和编程语言之间是可移植的。

认识响应 “报头” (header)

响应报头是HTTP响应的一部分，它包含了有关响应的元数据和属性，用于提供关于响应内容、服务器、缓存控制、Cookie等信息。

响应报头的基本格式与请求报头相似，通常由一个或多个键值对组成。这些键值对提供了有关响应的详细信息，如响应的内容类型（Content-Type）、内容长度（Content-Length）、服务器信息（Server）、响应日期（Date）、缓存控制（Cache-Control）、Cookie等等。这些信息对于客户端来说非常重要，因为它们影响着客户端如何处理响应、显示内容和与服务器交互。

以下是一些常见的响应报头属性和它们的含义：

1. Content-Type: 指示响应主体的媒体类型，例如HTML、JSON、XML等。这有助于客户端正确解释响应的内容。
2. Content-Length: 指示响应主体的长度，以字节为单位。客户端使用这个信息来确保完整接收响应。
3. Server: 服务器标识，提供了有关响应的服务器的信息。
4. Date: 响应生成的日期和时间。
5. Cache-Control: 控制响应的缓存策略，如是否可以被缓存、缓存的过期时间等。
6. Set-Cookie: 用于在响应中设置新的Cookie或更新已存在的Cookie。
7. ETag（实体标签）**：**ETag（实体标签）是HTTP协议中的一个响应头属性，通常由服务器在响应中生成。ETag的目的是为了帮助缓存机制，允许客户端在后续请求中向服务器提供一个与之前响应的ETag匹配的标识，以检查资源是否发生了变化。
8. 其他自定义报头：根据需要，可以在响应报头中包含自定义报头，以提供额外的元数据信息。

其中ETag的工作方式如下：

1. 服务器为资源生成一个唯一的ETag标识，通常是资源内容的哈希值或其他标识。
2. 服务器在HTTP响应的头部包含ETag标识。
3. 客户端在后续请求中可以包含一个叫做"If-None-Match"的请求头，其中包含上一次响应的ETag值。
4. 如果服务器接收到包含"If-None-Match"请求头的请求，并且该值与当前资源的ETag匹配，服务器可以返回状态码304（未修改），而不是重新发送资源。这意味着客户端可以使用之前缓存的资源，而不必重新下载。

ETag是一种有效的缓存控制机制，因为它允许服务器告诉客户端是否需要重新获取资源。这对于减少带宽使用和加快页面加载速度很有用。ETag通常用于与"Last-Modified"头一起使用，以提供更精确的缓存控制。

响应报头的内容对于客户端解释响应并采取适当的行动非常重要。不同的报头属性可以告诉客户端如何显示内容、如何缓存响应、如何处理Cookie等等。因此，了解响应报头对于理解和处理HTTP响应非常重要。

Content-Type

Content-Type是HTTP响应头中的一个重要字段，用于指示响应主体（response body）的数据格式。以下是一些常见的Content-Type值和它们的含义：

1. text/html: 表示响应主体包含HTML文本。这通常用于HTML网页的响应，以便浏览器可以正确解释和呈现网页内容。
2. text/css: 表示响应主体包含CSS（层叠样式表）数据，用于定义网页的样式和布局。
3. application/javascript: 表示响应主体包含JavaScript代码，通常用于网页上的客户端脚本。
4. application/json: 表示响应主体包含JSON（JavaScript Object Notation）数据，这是一种常用的数据交换格式，通常在API响应中使用。

这些Content-Type值有助于客户端（通常是浏览器或其他HTTP客户端）正确解释和处理响应主体的内容。当客户端收到响应时，它会查看Content-Type字段，以确定如何呈现或处理响应的数据。例如，如果Content-Type为text/html，则客户端会将内容解释为HTML并显示在浏览器中；如果Content-Type为application/json，则客户端会将内容解释为JSON，以便在JavaScript中处理。

认识响应 “正文” (body)

1. 响应正文：响应正文是响应的主要内容，通常包含HTML文本、JSON数据、图像、视频、文件等。响应正文的内容取决于请求的性质和服务器的响应。
2. Content-Type：响应头中的Content-Type字段告诉客户端如何正确解释和处理响应的正文。根据Content-Type的值，客户端可以呈现文本、解析JSON、显示图像等。

响应头提供了与响应相关的元数据，如状态信息、响应类型和缓存控制。响应正文包含实际的数据或内容，如HTML页面、JSON数据或媒体文件。

正文的具体格式取决于 Content-Type。

（1）text/html

Server: nginx/1.17.3
Date: Thu, 10 Jun 2021 07:25:09 GMT
Content-Type: text/html; charset=utf-8
Last-Modified: Thu, 13 May 2021 09:01:26 GMT
Connection: keep-alive
ETag: W/"609ceae6-3206"
Content-Length: 12806
<!DOCTYPE html><html><head><meta charset=utf-8><meta http-equiv=X-UA-Compatible 
content="IE=edge,chrome=1"><meta name=renderer content=webkit><meta name=viewport 
content="width=device-width,initial-scale=1,minimum-scale=1,maximum-scale=1,user scalable=no"><link rel=icon href=/favicon.ico><title id=bodyTitle>芒果教务网
</title><link href=https://cdn.bootcss.com/jquerydatetimepicker/2.5.20/jquery.datetimepicker.css rel=stylesheet><script 
src=https://cdn.bootcss.com/highlight.js/9.1.0/highlight.min.js></script><script 
src=https://cdn.bootcss.com/highlightjs-line-numbers.js/2.5.0/highlightjs-linenumbers.min.js></script><style>html,
   body,
   #app {
     height: 100%;
     margin: 0px;
     padding: 0px;
}
   .chromeframe {
     margin: 0.2em 0;
     background: #ccc;
     color: #000;
     padding: 0.2em 0;
   }
   #loader-wrapper {
     position: fixed;
     top: 0;
     left: 0;
     width: 100%;
     height: 100%;
     z-index: 999999;
   }
......

提供的示例中，Content-Type为"text/html; charset=utf-8"，表示响应正文的数据格式为HTML，并使用UTF-8字符编码。因此，响应正文包含了HTML代码，用于构建网页的内容。

以下是示例响应正文的一部分，其中包含HTML页面的结构和内容：

<!DOCTYPE html>
<html>
<head>
  <meta charset=utf-8>
  <meta http-equiv=X-UA-Compatible content="IE=edge,chrome=1">
  <meta name=renderer content=webkit>
  <meta name=viewport content="width=device-width,initial-scale=1,minimum-scale=1,maximum-scale=1,user-scalable=no">
  <link rel=icon href=/favicon.ico>
  <title id=bodyTitle>芒果教务系统</title>
  <!-- 其他 HTML 标签和内容 -->
</head>
<body>
  <!-- 页面内容 -->
</body>
</html>

这个响应正文包含HTML标记和内容，可以被浏览器正确解释和显示，以呈现网页的视觉和交互部分。

需要注意的是，根据Content-Type的不同，响应正文的格式和内容也会有所不同。例如，如果Content-Type是"application/json"，那么响应正文将包含JSON数据，如果是"image/jpeg"，那么响应正文将包含图像数据，以此类推。客户端会根据Content-Type来解释和处理响应正文的内容。

（2）text/css

HTTP/1.1 200 OK
Server: nginx/1.17.3
Date: Thu, 10 Jun 2021 07:25:09 GMT
Content-Type: text/css
Last-Modified: Thu, 13 May 2021 09:01:26 GMT
Connection: keep-alive
ETag: W/"609ceae6-3cfbe"
Content-Length: 249790
@font-face{font-family:element-icons;src:url(../../static/fonts/elementicons.535877f5.woff) format("woff"),url(../../static/fonts/elementicons.732389de.ttf) format("truetype");font-weight:400;font-style:normal}
[class*=" el-icon-"], 
......

Content-Type为"text/css"，这表示响应正文的数据格式为CSS（层叠样式表）。响应正文包含CSS样式的定义，这些样式规则用于设置网页的外观和布局。

以下是示例响应正文的一部分，其中包含了CSS样式的定义：

@font-face {
  font-family: element-icons;
  src: url(../../static/fonts/element-icons.535877f5.woff) format("woff"), url(../../static/fonts/element-icons.732389de.ttf) format("truetype");
  font-weight: 400;
  font-style: normal;
}

[class*=" el-icon-"] {
  /* 其他 CSS 样式规则 */
}

这个响应正文包含了字体定义以及CSS样式规则。这些规则用于设置网页上的各种元素的样式，包括字体、颜色、布局等。

浏览器将解释这些CSS规则并应用它们，以呈现页面的外观。CSS在Web开发中是非常重要的，因为它允许开发人员精确控制网页的外观和布局，以提供良好的用户体验。响应的Content-Type告诉浏览器如何正确解释和处理响应正文的内容。

（3） application/javascript

HTTP/1.1 200 OK
Server: nginx/1.17.3
Date: Thu, 10 Jun 2021 07:25:09 GMT
Content-Type: application/javascript; charset=utf-8
Last-Modified: Thu, 13 May 2021 09:01:26 GMT
Connection: keep-alive
ETag: W/"609ceae6-427d4"
Content-Length: 272340
(window["webpackJsonp"]=window["webpackJsonp"]||[]).push([["app"],
{0:function(t,e,n){t.exports=n("56d7")},"00b3":function(t,e,n){},"
......

Content-Type为"application/javascript; charset=utf-8"，这表示响应正文的数据格式为JavaScript，并使用UTF-8字符编码。响应正文包含了JavaScript代码，这是用于客户端脚本的一部分。

以下是示例响应正文的一部分，包含JavaScript代码：

(window["webpackJsonp"] = window["webpackJsonp"] || []).push([["app"], {
  0: function(t, e, n) {
    t.exports = n("56d7");
  },
  "00b3": function(t, e, n) {},
  // 其他 JavaScript 代码
}

这个响应正文包含了JavaScript代码块，其中可能包括不同的模块、函数和变量。这些代码用于在客户端（通常是浏览器）上执行特定的逻辑，例如处理用户交互、修改DOM（文档对象模型）元素、发送HTTP请求等等。

JavaScript是一种广泛用于Web开发的脚本语言，它允许开发人员创建丰富的交互性和动态性的网页。HTTP响应中的JavaScript代码会被浏览器执行，以实现网页的客户端逻辑。浏览器将根据Content-Type 值来正确解释和处理响应正文中的JavaScript代码。

（4）application/json

HTTP/1.1 200
Server: nginx/1.17.3
Date: Thu, 10 Jun 2021 07:25:10 GMT
Content-Type: application/json;charset=UTF-8
Connection: keep-alive
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
vary: accept-encoding
Content-Length: 12268
{"msg":"操作成功","code":200,"permissions":[] }

Content-Type为"application/json;charset=UTF-8"，这表示响应正文的数据格式为JSON（JavaScript Object Notation），并使用UTF-8字符编码。响应正文包含了一个JSON对象，用于传递数据。

以下是示例响应正文的JSON数据：

{
  "msg": "操作成功",
  "code": 200,
  "permissions": []
}

这个JSON对象包含了键值对，其中键是字符串，值可以是字符串、数字、数组等。JSON是一种轻量级的数据交换格式，经常用于API响应，以便客户端和服务器之间传递结构化数据。

在这个示例中，JSON对象描述了一个操作的成功状态，包括一条消息 “操作成功”、状态码 “200”，以及一个空数组 “permissions”。客户端可以解析JSON数据并使用其中的信息，以便在应用程序中采取适当的措施。

JSON作为一种数据格式在Web开发中非常常见，因为它易于阅读、编写和解析，并且通常与JavaScript一起使用，以便在客户端和服务器之间进行数据交换。Content-Type的值告诉客户端如何正确解释和处理响应正文中的JSON数据。

那么我们如何让客户端构造一个HTTP请求？如何让服务器处理一个HTTP请求？

客户端（通常是浏览器）构造HTTP请求是通过向服务器请求资源或执行特定操作的重要过程。下面是不同方式构造HTTP请求的一些方法：

浏览器构造HTTP请求：

1. 手动输入URL：用户可以在浏览器的地址栏中手动输入URL，然后按回车键，这将构造并发送一个GET请求以获取指定资源。
2. HTML标签：某些HTML标签可以触发HTTP请求。例如，标签用于请求和显示图像资源，标签用于导航到链接资源，标签用于获取样式表，

服务器处理HTTP请求（具体的以后介绍）：

服务器接收和处理HTTP请求的过程通常涉及以下步骤：

1. 接收请求：服务器监听指定端口，等待来自客户端的连接。一旦建立连接，服务器会接收HTTP请求。
2. 解析请求：服务器解析HTTP请求的各个部分，包括请求行、请求头和请求正文。这使服务器能够了解客户端的请求类型、所请求的资源、请求头信息等。
3. 路由和处理：根据请求的类型（GET、POST、PUT、DELETE等）和请求的URL，服务器将请求路由到适当的处理程序或控制器。服务器执行所需的操作，可以是检索资源、执行业务逻辑、保存数据等。
4. 生成响应：服务器根据请求的处理结果构建HTTP响应。响应包括响应状态码、响应头和响应正文。
5. 发送响应：服务器将HTTP响应发送回客户端，通常通过与客户端建立的TCP连接。客户端接收并解析响应，然后根据响应的内容执行相应的操作，如渲染页面、显示资源或处理数据。

服务器端的技术和框架（如Apache、NGINX、Node.js、Django、Spring等）通常用于处理HTTP请求，它们提供了路由、中间件、数据存储和业务逻辑执行等功能，以便有效地处理和响应来自客户端的请求。这些服务器端工具和框架可以大大简化服务器端的开发和维护工作。

通过 form 表单构造

HTTP 请求 form (表单) 是 HTML 中的一个常用标签。 可以用于给服务器发送 GET 或者 POST 请求。

注意：不要把 form 拼写成 from！！!

HTML\CSS\JS也是编程语言，他们和C还有Java这些语言的区别就在于它们是运行在浏览器上的，不像C要安装VS、Java要安装JDK。它们有浏览器就可以运行。

编写前端代码开发工具也有很多选择。IDEA是可选项，但是得十专业版才能支持HTML+CSS+JS。社区版只支持HTML。

所以相比之下，VSCode是一个更好的选择。

HTML（Hypertext Markup Language）是一种标记语言，用于创建网页的结构和内容。HTML标签是构成HTML文档的基本元素，它们定义了文档的结构和内容。

<html>
    <head>


    </head>
    <body>
        hello world!!!
    </body>
</html>

1. 成对出现的标签：大多数HTML标签都是成对出现的，例如**<div></div>, <h1></h1>, <p></p>**等。开始标签<>，结束标签</>

2. 单标签：有些HTML标签是单独的，它们通常不需要一个结束标签，例如**<img>, <br>，<input>。**

3. 嵌套标签：HTML标签内容里面还可以嵌套其他标签，以创建更复杂的结构，如**<div><p>**这是一个段落。**</p></div>**。

4. head和body：

   • head：标签中存放的是属性，通常包含元数据（metadata），如文档的字符编码、文档标题、连接的样式表、脚本等。
   • body：标签中包含了用户在浏览器中看到的所有内容，如文本、图像、链接、表单等。

5. 常见的HTML标签：在HTML里面dodou有哪些标签？每个标签的含义是什么？这些都是标准规定好的：

   • <!DOCTYPE>：文档类型声明，定义了文档所遵循的HTML版本和规范。
   • <html>：HTML文档的根元素，包含了整个文档。
   • <head>：包含了文档的元信息，如标题、字符集声明、样式表和脚本等。
   • <title>：定义网页的标题，显示在浏览器标签页上。
   • <meta>：提供关于文档的元信息，如字符集、作者、描述等。
   • <link>：用于链接外部样式表。
   • <style>：用于在文档中嵌入CSS样式。
   • <script>：用于嵌入JavaScript代码。
   • <body>：包含页面上实际显示的内容，如文本、图像、链接等。
   • <h1>, <h2>, <h3>, … <h6>：定义标题，其中<h1>最高，<h6>最低。
   • <p>：定义段落。
   • <a>：创建超链接。
   • <img>：嵌入图像。
   • <ul>：创建无序列表。
   • <ol>：创建有序列表。
   • <li>：定义列表项。
   • <table>：创建表格。
   • <tr>：定义表格的行。
   • <td>：定义表格的数据单元格。
   • <th>：定义表格的表头单元格。
   • <div>：通用的块级容器，用于组织和布局内容。
   • <span>：通用的内联容器，用于包裹文本或内联元素。

HTML中都有那些标签，每个标签的含义是什么，这些都是标准规定的。

**现代浏览器通常具有一定的容错性和鲁棒性，可以尽力解析并显示不规范的HTML代码。这种特性使得即使HTML代码存在一些错误或不规范，网页仍然可以在浏览器中正常显示（浏览器会尽可能的进行显示）。**以下是一些浏览器的容错机制：

1. 标签不闭合或嵌套错误： 浏览器会尝试自动纠正标签的闭合错误或嵌套错误，以便更好地显示内容。
2. 缺失的属性： 如果HTML标签中缺少某些属性，浏览器会尝试使用默认值或进行猜测，以确保元素能够正确渲染。
3. 不支持的标签和属性： 浏览器会忽略它们不理解的标签和属性，而显示它们能够理解的部分。
4. 文档类型不一致： 如果文档声明（<!DOCTYPE>）不正确或缺失，浏览器也会尽力去解析并显示页面。
5. 非法字符： 浏览器通常会忽略或替换文档中的非法字符，以防止它们导致页面解析失败。

尽管浏览器具有这些容错机制，但仍然建议编写符合HTML规范的代码，以确保最佳的跨浏览器兼容性和可维护性。不规范的HTML可能会导致解释不一致或难以维护的问题，因此良好的编码实践仍然非常重要。

还有一种更简单的编写方式：

直接输入“！”再输入，就会自动生成基本的HTML代码模板。

form 发送 GET 请求

用到form标签：

开始标签中可以写属性，就是一些“键值对”，可以有多个属性，多个键值对之间使用空格来分割。键和值之间使用“=”分割。键不需要需要有引号，值需要双引号。

表单form的重要参数

1. action: 这是表单的 action 属性，用于指定HTTP请求的目标URL，即数据将被发送到哪个服务器资源。
2. method: 表单的 method 属性，用于指定HTTP请求的方法，通常是GET或POST。表单只支持这两种方法。

输入字段 input 的重要参数

1. type: 输入字段的type属性，用于定义输入框的类型。例如，"text"表示文本输入框，"password"表示密码输入框，"submit"表示提交按钮。
2. name: 输入字段的name属性，用于指定构造的HTTP请求的查询字符串（query string）中的键（key）。查询字符串的值将是用户在输入字段中输入的内容。
3. value: input标签的value属性，对于类型为"submit"的输入字段来说，value对应了按钮上显示的文本、内容。例如，在一个提交按钮上，value可以设置为"提交"，这将是按钮上显示的文本，但是必须得设置为“submit”类型。

这些参数帮助我们构建HTML表单，定义表单的行为和输入字段的类型。正确使用这些参数将有助于创建有效的HTTP请求表单。

演示一下d如何构建一个GET请求的HTML表单：

<form action="http://abcdef.com/myPath" method="GET">
    <input type="text" name="userId">
    <input type="text" name="classId">
    <input type="submit" value="提交">
</form>

页面展示的效果：

在输入框随便填写数据：

设置成“submit”类型才会是提交按钮，点击 “提交”， 此时就会构造出 HTTP 请求并发送出去。

当前虽然已经把请求构造出来了，但是当前得到的响应是404，因为还需要服务器这边的代码配合。

构造的 HTTP 请求

GET http://abcdef.com/myPath?userId=100&classId=200 HTTP/1.1
Host: abcdef.com
Proxy-Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/91.0.4472.114 Safari/537.36
Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,imag
e/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

注意: 由于我们的服务器的地址是随便写的, 因此无法获取到正确的 HTTP 响应 。

这是一个HTTP GET请求的示例，其中包含了请求头（request headers）和请求行（request line）。这个请求将被发送到目标URL http://abcdef.com/myPath?userId=100&classId=200。

以下是请求的各个部分的解释：

请求行 (Request Line):

• GET http://abcdef.com/myPath?userId=100&classId=200 HTTP/1.1：这是HTTP请求行。它指定了HTTP方法（GET）、请求的URL地址（http://abcdef.com/myPath?userId=100&classId=200），以及HTTP协议版本（HTTP/1.1）。

请求头 (Request Headers):

• Host: abcdef.com：指定了请求的主机名，即请求被发送到哪个服务器。
• Proxy-Connection: keep-alive：表示要保持代理连接保持活跃，以便在同一连接上发送多个请求。
• Upgrade-Insecure-Requests: 1：表示浏览器要升级不安全的请求，以提高安全性。
• User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36：包含了用户代理信息，描述了浏览器和操作系统等信息。
• Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9：表示浏览器可以接受的媒体类型，按优先级排序。
• Accept-Encoding: gzip, deflate：指示浏览器可以接受的内容编码方式，例如gzip和deflate。
• Accept-Language: zh-CN,zh;q=0.9,en;q=0.8：指示浏览器接受的语言首选项，以便服务器返回适合的语言版本。

这个请求是一个HTTP GET请求，它向指定的URL发送请求以获取相应的资源。

体会 form 代码和 HTTP 请求之间的对应关系

HTML中的标签 form 与HTTP请求之间有着紧密的联系。当用户在浏览器中提交一个表单时，背后实际上是发起了一个HTTP请求：

1. form的action属性与HTTP请求的URL：

   • action属性在form 标签中定义了提交表单数据时要发送到的URL。
   • 当用户提交表单时，浏览器就会向此URL发起HTTP请求。例如，如果你的表单中有如下代码：

<form action="http://abcdef.com/myPath" method="GET">

当用户提交表单时，HTTP请求会发送到http://abcdef.com/myPath这个地址。
2. form的method属性与HTTP请求的方法：

* form的method属性指定了HTTP请求的类型（例如GET或POST，form支支持dgett）。
* 这决定了数据是作为URL的一部分（查询字符串）发送还是作为请求的主体发送。

3. input的name属性与查询字符串的key：

   • 每个input字段的name属性值将成为查询字符串中的一个键。例如，以下表单字段：

<input type="text" name="userId">

在用户提交表单后，如果输入了“100”，URL可能会包含userId=100 这样的查询字符串。
4. input的内容与查询字符串的value：

最后的内容

在开头跟大家分享的时候我就说，面试我是没有做好准备的，全靠平时的积累，确实有点临时抱佛脚了，以至于我自己还是挺懊恼的。（准备好了或许可以拿个40k，没做准备只有30k+，你们懂那种感觉吗）

如何准备面试？

1、前期铺垫（技术沉积）

程序员面试其实是对于技术的一次摸底考试，你的技术牛逼，那你就是大爷。大厂对于技术的要求主要体现在：基础，原理，深入研究源码，广度，实战五个方面，也只有将原理理论结合实战才能把技术点吃透。

下面是我会看的一些资料笔记，希望能帮助大家由浅入深，由点到面的学习Java，应对大厂面试官的灵魂追问

这部分内容过多，小编只贴出部分内容展示给大家了，见谅见谅！

• Java程序员必看《Java开发核心笔记（华山版）》

• Redis学习笔记

• Java并发编程学习笔记

四部分，详细拆分并发编程——并发编程+模式篇+应用篇+原理篇

• Java程序员必看书籍《深入理解 ava虚拟机第3版》（pdf版）

• 大厂面试必问——数据结构与算法汇集笔记

其他像Spring，SpringBoot，SpringCloud，SpringCloudAlibaba，Dubbo，Zookeeper，Kafka，RocketMQ，RabbitMQ，Netty，MySQL，Docker，K8s等等我都整理好，这里就不一一展示了。

2、狂刷面试题

技术主要是体现在平时的积累实用，面试前准备两个月的时间再好好复习一遍，紧接着就可以刷面试题了，下面这些面试题都是小编精心整理的，贴给大家看看。

①大厂高频45道笔试题（智商题）

②BAT大厂面试总结（部分内容截图）

③面试总结

3、结合实际，修改简历

程序员的简历一定要多下一些功夫，尤其是对一些字眼要再三斟酌，如“精通、熟悉、了解”这三者的区别一定要区分清楚，否则就是在给自己挖坑了。当然不会包装，我可以将我的简历给你参考参考，如果还不够，那下面这些简历模板任你挑选：

以上分享，希望大家可以在金三银四跳槽季找到一份好工作，但千万也记住，技术一定是平时工作种累计或者自学（或报班跟着老师学）通过实战累计的，千万不要临时抱佛脚。

另外，面试中遇到不会的问题不妨尝试讲讲自己的思路，因为有些问题不是考察我们的编程能力，而是逻辑思维表达能力；最后平时要进行自我分析与评价，做好职业规划，不断摸索，提高自己的编程能力和抽象思维能力。

RL发起HTTP请求。例如，如果你的表单中有如下代码：

<form action="http://abcdef.com/myPath" method="GET">

当用户提交表单时，HTTP请求会发送到http://abcdef.com/myPath这个地址。
2. form的method属性与HTTP请求的方法：

* form的method属性指定了HTTP请求的类型（例如GET或POST，form支支持dgett）。
* 这决定了数据是作为URL的一部分（查询字符串）发送还是作为请求的主体发送。

3. input的name属性与查询字符串的key：

   • 每个input字段的name属性值将成为查询字符串中的一个键。例如，以下表单字段：

<input type="text" name="userId">

在用户提交表单后，如果输入了“100”，URL可能会包含userId=100 这样的查询字符串。
4. input的内容与查询字符串的value：

最后的内容

在开头跟大家分享的时候我就说，面试我是没有做好准备的，全靠平时的积累，确实有点临时抱佛脚了，以至于我自己还是挺懊恼的。（准备好了或许可以拿个40k，没做准备只有30k+，你们懂那种感觉吗）

如何准备面试？

1、前期铺垫（技术沉积）

程序员面试其实是对于技术的一次摸底考试，你的技术牛逼，那你就是大爷。大厂对于技术的要求主要体现在：基础，原理，深入研究源码，广度，实战五个方面，也只有将原理理论结合实战才能把技术点吃透。

下面是我会看的一些资料笔记，希望能帮助大家由浅入深，由点到面的学习Java，应对大厂面试官的灵魂追问

这部分内容过多，小编只贴出部分内容展示给大家了，见谅见谅！

• Java程序员必看《Java开发核心笔记（华山版）》

[外链图片转存中…(img-xj0Nb5Uu-1714324175362)]

• Redis学习笔记

[外链图片转存中…(img-W6hARC92-1714324175363)]

• Java并发编程学习笔记

四部分，详细拆分并发编程——并发编程+模式篇+应用篇+原理篇

[外链图片转存中…(img-kcW1EICO-1714324175363)]

• Java程序员必看书籍《深入理解 ava虚拟机第3版》（pdf版）

[外链图片转存中…(img-xZmGg9Fq-1714324175363)]

• 大厂面试必问——数据结构与算法汇集笔记

[外链图片转存中…(img-tCc2057C-1714324175363)]

其他像Spring，SpringBoot，SpringCloud，SpringCloudAlibaba，Dubbo，Zookeeper，Kafka，RocketMQ，RabbitMQ，Netty，MySQL，Docker，K8s等等我都整理好，这里就不一一展示了。

[外链图片转存中…(img-5t5N0Z9h-1714324175364)]

2、狂刷面试题

技术主要是体现在平时的积累实用，面试前准备两个月的时间再好好复习一遍，紧接着就可以刷面试题了，下面这些面试题都是小编精心整理的，贴给大家看看。

①大厂高频45道笔试题（智商题）

[外链图片转存中…(img-6eWTIcTO-1714324175364)]

②BAT大厂面试总结（部分内容截图）

[外链图片转存中…(img-SadPmsZo-1714324175364)]

[外链图片转存中…(img-YZUcG6ug-1714324175364)]

③面试总结

[外链图片转存中…(img-Sa1lXraK-1714324175365)]

[外链图片转存中…(img-9ieAmq0Q-1714324175365)]

3、结合实际，修改简历

程序员的简历一定要多下一些功夫，尤其是对一些字眼要再三斟酌，如“精通、熟悉、了解”这三者的区别一定要区分清楚，否则就是在给自己挖坑了。当然不会包装，我可以将我的简历给你参考参考，如果还不够，那下面这些简历模板任你挑选：

[外链图片转存中…(img-hDVYr0vV-1714324175365)]

以上分享，希望大家可以在金三银四跳槽季找到一份好工作，但千万也记住，技术一定是平时工作种累计或者自学（或报班跟着老师学）通过实战累计的，千万不要临时抱佛脚。

另外，面试中遇到不会的问题不妨尝试讲讲自己的思路，因为有些问题不是考察我们的编程能力，而是逻辑思维表达能力；最后平时要进行自我分析与评价，做好职业规划，不断摸索，提高自己的编程能力和抽象思维能力。

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录