使用的工具：fiddler

 一、请求和响应报文的结构

1.请求

1. ⾸⾏: [⽅法] + [url] + [版本]
2. Header: 请求的属性, 冒号分割的键值对;每组属性之间使⽤\n分隔;遇到空⾏表⽰Header部分结束
3. Body: 空⾏后⾯的内容都是Body. Body允许为空字符串. 如果Body存在, 则在Header中会有⼀个Content-Length属性来标识Body的⻓度;

2.响应

1. ⾸⾏: [版本号] + [状态码] + [状态码解释]
2. Header: 请求的属性, 冒号分割的键值对;每组属性之间使⽤\n分隔;遇到空⾏表⽰Header部分结束
3. Body: 空⾏后⾯的内容都是Body. Body允许为空字符串. 如果Body存在, 则在Header中会有⼀个 Content-Length属性来标识Body的⻓度; 如果服务器返回了⼀个html⻚⾯, 那么html⻚⾯内容就是在body中.

二、认识URL

URL 基本格式

平时我们俗称的 "⽹址" 其实就是说的 URL (Uniform Resource Locator 统⼀资源定位符).

互联⽹上的每个⽂件都有⼀个唯⼀的URL，它包含的信息指出⽂件的位置以及浏览器应该怎么处理它. URL 的详细规则由 因特⽹标准RFC1738进⾏了约定. ( https://datatracker.ietf.org/doc/html/rfc1738 )

一个具体的URL：

https://v.bitedu.vip/personInf/student?userId=10000&classId=100

可以看到, 在这个 URL 中有些信息被省略了

1. https : 协议⽅案名. 常⻅的有 http 和 https, 也有其他的类型. (例如访问 mysql 时⽤的 jdbc:mysql )
2. user:pass : 登陆信息. 现在的⽹站进⾏⾝份认证⼀般不再通过 URL 进⾏了. ⼀般都会省略
3. v.bitedu.vip : 服务器地址. 此处是⼀个 "域名", 域名会通过 DNS 系统解析成⼀个具体的 IP 地址. (通过 ping 命令可以看到, v.bitedu.vip 的真实 IP 地址为 118.24.113.28 )
4. 端⼝号: 上⾯的 URL 中端⼝号被省略了. 当端⼝号省略的时候, 浏览器会根据协议类型⾃动决定使⽤哪个端⼝. 例如 http 协议默认使⽤ 80 端⼝, https 协议默认使⽤ 443 端⼝.
5. /personInf/student : 带层次的⽂件路径
6. userId=10000&classId=100 : 查询字符串(query string). 本质是⼀个键值对结构. 键值对之间使⽤ & 分隔. 键和值之间使⽤ = 分隔.
7. ⽚段标识: 此 URL 中省略了⽚段标识. ⽚段标识主要⽤于⻚⾯内跳转. (例如 Vue 官⽅⽂档: https://cn.vuejs.org/v2/guide/#%E8%B5%B7%E6%AD%A5, 通过不同的⽚段标识跳转到⽂档的不同章节)

使⽤ ping 命令查看域名对应的 IP 地址 

关于 query string

query string 中的内容是键值对结构. 其中的 key 和 value 的取值和个数, 完全都是程序猿⾃⼰约定的. 我们可以通过这样的⽅式来⾃定制传输我们需要的信息给服务器

URL 中的可省略部分

1. 协议名: 可以省略, 省略后默认为 http://
2. ip 地址 / 域名: 在 HTML 中可以省略(⽐如 img, link, script, a 标签的 src 或者 href 属性). 省略后表⽰服务器的 ip / 域名与当前 HTML 所属的 ip / 域名⼀致.
3. 端⼝号: 可以省略. 省略后如果是 http 协议, 端⼝号⾃动设为 80; 如果是 https 协议, 端⼝号⾃动设为443.
4. 带层次的⽂件路径: 可以省略. 省略后相当于 / . 有些服务器会在发现 / 路径的时候⾃动访问 /index.html
5. 查询字符串: 可以省略
6. ⽚段标识: 可以省略

三、认识方法

1. GET ⽅法

GET 请求的特点

• ⾸⾏的第⼀部分为 GET
• URL 的 query string 可以为空, 也可以不为空.
• header 部分有若⼲个键值对结构.
• body 部分为空

关于 GET 请求的 URL ⻓度问题

⽹上有些资料上描述: get 请求⻓度最多 1024kb 这样的说法是错误的.

HTTP 协议由 RFC 2616 标准定义, 标准原⽂中明确说明: "Hypertext Transfer Protocol -- HTTP/1.1,"

does not specify any requirement for URL length.

没有对 URL 的⻓度有任何的限制.

实际 URL 的⻓度取决于浏览器的实现和 HTTP 服务器端的实现. 在浏览器端, 不同的浏览器最⼤⻓度

是不同的, 但是现代浏览器⽀持的⻓度⼀般都很⻓; 在服务器端, ⼀般这个⻓度是可以配置的

2. POST ⽅法

POST 请求的特点

• ⾸⾏的第⼀部分为 POST
• URL 的 query string ⼀般为空 (也可以不为空)
• header 部分有若⼲个键值对结构
• body 部分⼀般不为空. body 内的数据格式通过 header 中的 Content-Type 指定. body 的⻓度由 header 中的 Content-Length 指定

get和post的区别：

• 语义不同：get一般用于获取数据，post一般用于提交数据
• get：body一般为空，数据一般通过query string传递，post：query string 一般为空，需要传递的数据通过body传输
• GET 请求⼀般是幂等的, POST 请求⼀般是不幂等的. (如果多次请求得到的结果⼀样, 就视为请求是幂等的).
• GET 可以被缓存, POST 不能被缓存. (这⼀点也是承接幂等性)

补充说明:

• 关于语义: GET 完全可以⽤于提交数据, POST 也完全可以⽤于获取数据.
• 关于幂等性: 标准建议 GET 实现为幂等的. 实际开发中 GET 也不必完全遵守这个规则(主流⽹站都有 "猜你喜欢" 功能, 会根据⽤⼾的历史⾏为实时更新现有的结果.
• 关于安全性: 有些资料上说 "POST ⽐ GET 请安全". 这样的说法是不科学的. 是否安全取决于前端在传输密码等敏感信息时是否进⾏加密, 和 GET POST ⽆关.
• 关于传输数据量: 有的资料上说 "GET 传输的数据量⼩, POST 传输数据量⼤". 这个也是不科学的, 标准没有规定 GET 的 URL 的⻓度, 也没有规定 POST 的 body 的⻓度. 传输数据量多少, 完全取决于不同浏览器和不同服务器之间的实现区别.
• 关于传输数据类型: 有的资料上说 "GET 只能传输⽂本数据, POST 可以传输⼆进制数据". 这个也是不科学的. GET 的 query string 虽然⽆法直接传输⼆进制数据, 但是可以针对⼆进制数据进⾏ url encode.

四、认识请求 "报头" (header)

header 的整体的格式也是 "键值对" 结构.每个键值对占⼀⾏. 键和值之间使⽤分号分割.

报头的种类有很多, 此处仅介绍⼏个常⻅的.

Host

 multipart/form-data：form 表单提交的数据格式(在 form 标签中加上enctyped="multipart/form-data" . 通常⽤于提交图⽚/⽂件. body 格式形如

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:数据为 json 格式. body 格式形如:

{"username":"123456789","password":"xxxx","code":"jw7l","uuid":"d110a05ccde64b16

User-Agent (简称 UA)

表⽰浏览器/操作系统的属性. 形如

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)

Referer

https://v.bitedu.vip/login

六、状态码

301 Moved Permanently