第二部分：URL（统一资源定位符）
url就是我们经常说的“网址”，功能就是定位网络上某一台主机上的某个资源
服务器地址（域名）：ip地址才是网络上一台主机的标识但是ip地址不容易记忆，所以就设计了域名系统，以便于记忆的字符串作为域名，通过域名上网的时候，先进过域名系统进行域名解析，得到服务器的ip地址，然后通过ip地址进行访问。在win系统下的文件夹记录了域名和ip地址的映射关系，如果将其修改，就无法进行访问。
port：在我们浏览网页的时候，在网址中并没有看到端口，这是因为http服务器默认使用80端口（https：443）
资源路径：是一个相对资源路径，这样用户不能随意访问服务器上的文件，智能访问相对应目录中的所有文件9
urlencode： url编码，目的就是将查询字符串或者资源路径中特殊的字符进行编码转移，编码格式：将特殊字符值转化为16进制的ASCII字符，前缀为 %
(像 / ? : 等这样的字符, 已经被url当做特殊意义理解了. 因此这些字符不能随意出现.比如, 某个参数中需要带有这些特殊字符,
就必须先对特殊字符进行转义.转义的规则如下:将需要转码的字符转为16进制，然后从右到左，取4位(不足4位直接处理)，每2位做一位，前面加上%，编码成%XY格式，urldecode就是urlencode的逆过程;)
ch ：#之后的数据，叫做片段标识符通常用于定位网页中的某个id标签，用于打开网页后直接跳转至指定位置
第三部分：协议版本
Header： 请求的属性，以冒号分隔和空格的键值对，每组属性之间采用\n进行分隔，遇到空行表示Header部分结束，是对于请求的附加描述和正文描述。
请求头部（只会在请求中出现的头部字段，描述请求）
正文头部（在请求和响应中都会出现，主要是对于正文的描述）
响应头部（只会在响应中出现的头部字段，描述响应）
**通用头部（**在请求和响应中都会出现，属于本次通信或者链接的一些描述）
Body：空行后边的内容都是body，body允许空字符串，如果cody存在，那么header中会有一个content—length属性来标识body的长度
HTTP常见Header
connection：keep—alive/close；可以控制长链接还是短链接
Content-Type: 数据类型(text/html等)，就是服务器收到信息后如何进行解析处理
Content-Length: Body的长度
Host: 客户端告知服务器, 所请求的资源是在哪个主机的哪个端口上;
User-Agent: 声明用户的操作系统和浏览器版本信息;
referer: 当前页面是从哪个页面跳转过来的;
location: 搭配3xx状态码使用, 告诉客户端接下来要去哪里访问;
Cookie: 用于在客户端存储少量信息. 通常用于实现会话(session)的功能;
HTTP常见状态码
重定向：最初设计的目的是：一个请求，要请求的资源被移动到了其他位置，重定向到其他链接。比如我们要请求a.png这个文件，但是每个文件都存放在根目录也不行，我们将其放入image/a.png这个文件夹中，想要依然保持原链接有效，我们要进行重定向。
HTTP响应
响应首行是：[版本号] + [状态码] + [状态码解释]http版本各个版本号的区别于介绍
协议切换： 我们经常使用的http协议，我们发一个协议你才能给我进行一个回复，服务器无法主动给客户端发送消息，比如经常使用的网页聊天功能，所以后来就有人设计了一个websocke协议，建立了一个长链接，如果服务器需要给客户端发送消息的话，就会切换到websocket协议。
头部字段中的cookie（请求头）和set-cookie(响应头)
http是一个简单的请求——响应协议，不管是短连接还是长链接，链接都不是一直持续的。
这样就会存在一个问题：比如在网站购物，因为链接不是持续的，导致每次买东西都要重新建立链接进行登录。因此，不管链接是不是原来的，但是都要分辨出用户，为了解决这个问题就提出了一个方案：cookie机制
cookie是一种信息缓存机制，将一些信息保存到客户端主机上，等下一次请求服务器的时候读取出来发送给服务器
第一次登录将用户名等信息缓存至本地，在下次再进行请求的时候就会从本地中取出来，在多次通信中不断维护客户端的状态。但是这样存在缺陷：不安全。很多敏感信息容易被劫持，因此，不能将敏感信息进行传输，所以提出了session（会话）机制。
session会话：就是为客户端和服务器的通信建立一个会话，将会话重要内容保存起来，会话内容被保存在服务器上，通过cookie只需要传输session_id即可，将敏感信息保存起来。session会话机制是在cookie机制的基础上，避免了敏感信息的传输，提高了安全性。
session和cookie简单区别
1.cookie是将关键信息保存在客户端本地，每次通信前发给服务器
2.session是将会话信息保存在服务器，通过session_id进行cookie传输，保存隐私性
本质上来说还是有一些安全隐患的,比如：cookie篡改
HTTPS协议：
https协议：在http协议的基础上进行了一层加密，因此https不是一个新的协议，而是一个加密后的协议。
加密：ssl/tls（安全套接层）加密
为什么要进行加密：
1.身份验证： 在进行网络通信的时候要知道对方是谁，并且还要可以验证通信的就是正确的。第三方权威机构+ca验证。通信前进行解析证书，查看证书中的权威机构是否是自己信任的权威机构，查看证书有没有被修改，确认对方的身份信息
2.加密传输： 对数据的传输进行加密
通信双方进行传输加密，需要进行一个密钥的协商，容易被黑客进行劫持。
3.加密方式
（1）对称加密： 数据的加密和解密使用的是相同的密钥
缺点：进行密钥协商的时候容易被劫持，加密形同虚设
优点：加解密的效率高
（2）非对称加密：数据的加密和解密使用的密钥是不一样的
缺点:加解密的效率是比较低下的
优点：安全，不怕被劫持
思想：通过指定的算法（RSA）,可以生成一对密钥（公钥和私钥），使用公钥进行加密，使用私钥进行解密
流程：链接建立成功之后，将自己的公钥发送给对方，对方使用公钥加密传输的数据，这个数据只能使用私钥进行解密
（3）混合加密： 假设是客户端对服务器进行验证
1.生成一对非对称密钥，链接建立成功，通信前将公钥发送给对方（所以这时候一开始的时候私钥是掌握在服务器的手中的，只有服务器能进行解密）
2.客户端收到后，使用公钥进行加密一个随机数a，以及自己支持的对称加密算法
3.服务器收到之后使用私钥进行解密，得到了随机数a和对方所支持的对称加密算法
4.服务器向客户端发送一个随机数b，以及自己支持的对称加密算法，客户端和服务器，各自根据两个随机数和支持的对称加密算法，计算出一个对称密钥（密钥的协商就完毕了）
5.往后的通信使用堆成密钥进行加密解密
CA证书
在实际的ssl加密中，身份验证和加密传输是聚合在一起的，即包含在CA证书中，CA证书中包含了更多的关于通信方的公钥，机构信息，证书颁发机构信息，失效时间…
整体流程： 单向验证，以服务器验证为主
服务器自己生成了一对密钥，拿着公钥去第三方权威机构颁发证书
权威机构根据服务器的公钥，生成一个CA证书给服务器
客户端与服务器建立链接后，通信前，服务器会将CA证书发送给客户端
客户端收到CA证书，进行解析验证权威机构是否自己信任，在权威机构验证身份后，解析出公钥
客户端随机生成一个随机数，使用公钥对随机数+加密算法进行加密，发送给服务器
服务器收到数据之后，使用私钥进行解密，生成一个随机数，将随机数和加密算法发给客户端
客户端收到数据后，客户端和服务器都有对方的随机数和自己的随机数，以及加密算法，进行计算得到一个对称密钥
往后的通信，使用堆成密钥进行加密传输
