摘要

介绍

规律 学习每一个知识点都离不开实践，对于网络学习来说，抓包是必不可少的，如TCP三次握手、HTTP报文、ICMP报文抓包等；学习Nginx、Redis源码需要实践调试和写测试代码验证单元功能
问题 如何解析HTTP报文？
一串二进制数据转成文本之后，会通过\r\n来解析，那么报文体中含有\r\n怎么处理
HTTP报文连续传输过来，如何区分上一报文和当前报文头——请求头中的Content-Length？好像请求可以不用Content-Length?
一个基于请求与响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据

• 一种基于文本的传输协议，它位于 OSI 网络模型中的应用层
• 通过客户端和服务器的请求应答来进行通讯，目前协议由之前的 RFC 2616 拆分成立六个单独的协议说明（RFC 7230、RFC 7231、RFC 7232、RFC 7233、RFC 7234、RFC 7235）

  特性

1. 报文都是以明文的方式进行传输，不做任何加密，被中间人进行攻击

   报文格式

   规律 报文首部都是为了给整个业务服务的，不需要去强行记忆
   规律 随着时间而在不断改进优化，所以其中的字段都不是固定的，都是与功能特性相挂钩的
   思路：

2. http是为了获取或上传资源，需要资源地址即目录path-目录

3. http有版本区别：http1.0 http1.1 http2
4. 指明资源的请求方式：get、post
5. http报文是文本协议，需要特定字符”换行符\r\n”进行切分
6. http头部key-value，则指明一些属性
7. 区分头部和body是换行符

思考🤔 如何区分连续不同的HTTP报文
？？每行解析，若格式跟请求行相符则为新的HTTP报文————缺陷：假设body里就含有请求行格式数据呢？？

TODO 用图示来动手制作请求/响应报文的格式

请求报文

• 请求行（request line）、请求头部（header）、空行和请求数据

  • 请求方法
    • GET/POST/HEAD/PUT/DELETE
    • GET与POST的区别
  • 请求地址
    • URL
    • URI
  • 协议版本HTTP1.0

    响应报文

    

• 状态行、响应头部、空行和响应数据

• 首部

  请求方法

  | 类型 | 功能 | 支持版本 | | —- | —- | —- | | GET | 请求获取资源 | | | POST | 上传资源（常用提交表单） | | | HEAD | 请求获取标识的资源的响应消息报头 | | | PUT | 请求服务器存储资源 | | | DELETE | 请求服务器删除资源 | | | TRACE | 请求服务器回送收到的请求信息，主要用于测试或诊断 | | | CONNECT | 保留 | | | OPTIONS | 请求查询服务器的性能，或者查询与资源相关的选项和需求 | |

GET🆚POST

版本历史

响应码

常见类型

首部字段

• Content-Length如果存在且生效, 必须是正确的, 否则会发生异常.(大于实际值会超时, 小于实际值会截断并可能导致后续的数据解析混乱)
• Transfer-Encoding: chunked存在会屏蔽Content-Length

  常用字段

  | 首部字段 | | | | —- | —- | —- | | Accept-Content | | | | Content-Type | | | | Content-Length | | | | Connection | | | | Connection | | |

HTTPS

HTTPS

Wireshark抓包

Wireshark抓包

报文格式

思考：各个字段所在字节数

请求地址
URL
统一资源定位符，是一种资源位置的抽象唯一识别方法
组成：<协议>：//<主机>：<端口>/<路径>（端口和路径有时可以省略，HTTP默认端口号是80）
URI
统一资源标识符
协议版本
格式：HTTP/主版本号.次版本号，如HTTP/1.0、HTTP/1.1
版本的发展历史
为什么是HTTP/2而不是HTTP/2.0
因为不再发展HTTP/2后版本，直接开始HTTP/3.0
发展历程图示
HTTPS从哪位置开始的？
http1.0、http1.1都支持实现为HTTPS，https与版本无明显关系
思路 分析HTTP报文的可能问题，每个版本的改进就是为了解决其中的问题
HTTP/1.0 —— HTTP/1.1
改进

1. 支持长连接即在一个TCP连接中可以多次发送HTTP请求，不再是一对一的请求-应答模式——减少性能开销
2. 支持管道pipeline传输，不用必须等收到上一响应报文后再发送，但仍需按请求报文的顺序接收响应报文，即发送ABC报文后必须按序接收ABC而不能BAC——对头阻塞——减少响应时间
3. 缺陷：对头阻塞——底层原因是什么？

瓶颈

1. 只压缩body，未压缩头部——首部信息越多延迟越大
2. 请求首部冗余——好多请求的首部是相同的
3. 服务器按请求顺序响应——对头阻塞
4. 无请求优先级控制 疑问
5. 服务器只能被动响应

HTTP/1.1 —— HTTP/2
http/2基于HTTPS
todo

1. 头部压缩——HPACK算法，提升速度
2. 二进制帧（头信息帧+数据帧）——增加数据传输效率
3. 数据流——唯一编号标记（客户端奇数、服务端偶数）、优先级
4. 多路复用——并发请求或响应，解决对头阻塞，降低延迟、提高连接利用率
5. 服务器推送（Cache Push）——主动发送，提前主动发送CSS、JS等静态文件，减少延迟等待——

HPACK算法
客户端和服务器同时维护一张头信息表，将所有字段存入该表，生成索引号，并用索引号来代替key-value
HTTP/2 —— HTTP/3.0
todo

1. 增加头部缓存

请求头部
由“名/值”对组成，每行一对，名和值之间使用冒号分隔
是否有哪些字段是必需要填的？哪些字段仅出现请求，哪些字段仅出现在响应
字段都是和具体功能挂钩的。不用孤立记忆
字段的值若是与实际不符会出现什么样的后果，如Content-Length
Content-Type
Content-Length: 服务器必填，客户端选填

Connection: “Keep-Alive” // client长连接
Connection: “close” // 实际在于server是否同意

状态行
组成：协议版本，状态码，状态码描述
状态码
3位数字以及常见状态码
1xx：指示信息–表示请求已接收，继续处理。 基本看不到
2xx：成功–表示请求已被成功接收、理解、接受。 200 201 203
3xx：重定向–要完成请求必须进行更进一步的操作。 301 永久和临时302
4xx：客户端错误–请求有语法错误或请求无法实现。 400 通用 404找不到资源
5xx：服务器端错误–服务器未能实现合法的请求。 500 通用 501

HTTPS
处于HTTP哪些版本
HTTP与HTTPS的区别

1. 端口号：HTTP：80；HTTPS：443
2. 传输数据：HTTP明文，HTTPS密文

背景
规律 为了解决某个问题（增加或优化）
解决HTTP不安全问题：

1. 数据透明————加密
2. 数据篡改————摘要算法
3. 冒充————数字证书

方案
在TCP与HTTP层之间加了SSL/TLS协议
数字证书、数字签名
#思考 以下是方案，具体实施也是可以继续优化的。如非对称加密算法从RSA变？

1. 混合加密

   1. 通信建立前，采用非对称加密交换会话密钥 —— 使用两密钥，公钥公开，私钥保密，但运算速度慢
   2. 通信过程中，采用对称加密加密明文 —— 使用一个密钥，运算速度快，但无法保证安全交换

2. 摘要算法

   1. 客户端通过摘要算法算出明文的指纹，并将指纹和明文一同加密后发送
   2. 服务端解密后，通过相同摘要算法算出明文的指纹，并与接收的指纹比对
   3. 相同则数据完整，未被篡改

3. 数字证书——保证公钥的公正性（正确可信）

   借助第三方权威机构CA（数字证书认证机构），相当于中国人民银行查征信。 将服务器公钥存在数字证书（CA颁发）中——相当于CA做担保。只要证书可信则公钥可信

数字证书的创建过程

命令解析

SSL/TLS协议建立过程
TCP的三次握手，再 TLS的四次握手

1. Client Hello：随机数C、TLS版本号、密码套件列表
2. Server Hello：随机数S、确认TLS版本号、使用密码套件、数字证书
3. 客户端回应：随机数pre-master（服务器公钥加密）

图示

过程描述

1. 客户端发送随机数给服务器

面试 从在浏览器上输入URL到展示页面经历了哪些过程

1. URL编码
2. DNS域名解析
3. TCP三次握手
4. HTTP请求响应

参考文档

1. HTTP 教程 | 菜鸟教程