1. 协议的概念:
2. OSI模型
应用层: 用户的应用程序和网络之间的接口。
表示层: 协商数据交换格式；相当与寄快递时封装的老师B
会话层: 允许用户使用简单易记的名称建立连接；相当于和快递小哥对接的老师C，对数据进行拆解，解析
传输层: 提供终端到终端的可靠连接；相当于快递小哥B，去跑腿的员工小哥
网络层: 使用权数据路由经过大型网络；相当于快递小哥C，决定你的快递要发往哪个地区。
数据链路层: 决定访问网络介质的方式。在此层将数据分帧，并处理流控制。本层指定拓扑结构并提供硬件寻址，相当于最后在飞机上装卸快递的小哥
物理层: 将数据转换为可通过物理介质传送的电子信号 相当于快递中的机长 或者 司机师傅。
示意图
数据流
3. TCP/IP参考模型
TCP(传输控制协议)
IP（网际互连协议）
应用层
表示层
会话层
传输层
网络层
数据链路层
物理层
OSI 七层模型在提出时的出发点是基于标准化的考虑，而没有考虑到具体的市场需求，使得该模型结构复杂，部分功能冗余，因而完全实现 OSI 参考模型的系统不多。而 TCP/IP 参考模型直接面向市场需求，实现起来也比较容易，因此在一经提出便得到了广泛的应用。基于 TCP/IP 的参考模型将协议分成四个层次，如下图所示，它们分别是：网络访问层、网际互联层、传输层、和应用层。
应用层
TCP/IP 模型将 OSI 参考模型中的会话层、表示层和应用层的功能合并到一个应用层实现，通过不同的应用层协议为不同的应用提供服务。例如：FTP、Telnet、DNS、SMTP 等。
传输层
该层对应于 OSI 参考模型的传输层，为上层实体提供源端到对端主机的通信功能。传输层定义了两个主要协议：传输控制协议（TCP）和用户数据报协议（UDP）。其中面向连接的 TCP 协议保证了数据的传输可靠性，面向无连接的 UDP 协议能够实现数据包简单、快速地传输。
网际互联层
网际互联层对应 OSI 参考模型的网络层，主要负责相同或不同网络中计算机之间的通信。在网际互联层， IP 协议提供的是一个可靠、无连接的数据报传递服务。该协议实现两个基本功能：寻址和分段。根据数据报报头中的目的地址将数据传送到目的地址，在这个过程中 IP 负责选择传送路线。除了 IP 协议外，该层另外两个主要协议是互联网组管理协议（IGMP）和互联网控制报文协议（ICMP）。
网络接入层
网络接入层的功能对应于 OSI 参考模型中的物理层和数据链路层，它负责监视数据在主机和网络之间的交换。事实上，TCP/IP 并未真正描述这一层的实现，而由参与互连的各网络使用自己的物理层和数据链路层协议，然后与 TCP/IP 的网络接入层进行连接，因此具体的实现方法将随着网络类型的不同而有所差异。
4. HTTP协议
HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写，是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。HTTP协议定义了客户端和服务器之间进行通信的规则和格式，使得用户可以通过浏览器访问网页、发送和接收数据。
特点
- 支持客户端/服务端模式。
- 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。由于HTTP协议简单，因而通信速度很快。
- 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
- 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。
- 无状态：无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
工作原理
工作原理：HTTP协议工作于客户端-服务端架构上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。 WWW是以Internet作为传输媒介的一个应用系统，WWW网上最基本的传输单位是Web网页。WWW的工作基于客户机/服务器计算模型，由Web 浏览器(客户机)和Web服务器(服务器)构成，两者之间采用超文本传送协议（HTTP）进行通信。HTTP协议是基于TCP/IP协议之上的协议，是Web浏览器和Web服务器之间的应用层协议，是通用的、无状态的、面向对象的协议。
HTTP是基于客户/服务器模式，且面向连接的。
典型的HTTP事务处理有如下的过程：
（1）客户与服务器建立连接；
（2）客户向服务器提出请求；
（3）服务器接受请求，并根据请求返回相应的文件作为应答；
（4）客户与服务器关闭连接。
客户与服务器之间的HTTP连接是一种一次性连接，它限制每次连接只处理一个请求，当服务器返回本次请求的应答后便立即关闭连接，下次请求再重新建立连接。这种一次性连接主要考虑到WWW服务器面向的是Internet中成干上万个用户，且只能提供有限个连接，故服务器不会让一个连接处于等待状态，及时地释放连接可以大大提高服务器的执行效率。
HTTP协议的作用原理包括四个步骤（具体）：
**连接(connect)：**浏览器与服务器建立连接，打开一个称为socket（套接字）的虚拟文件，此文件的建立标志着连接建立成功。
**请求(request)：**Web浏览器通过socket向Web服务器提交请求。HTTP的请求一般是GET或POST命令（POST用于FORM参数的传递）。GET命令的格式为：GET 路径/文件名 HTTP/1.0 文件名指出所访问的文件，HTTP/1.0指出Web浏览器使用的HTTP版本。
**应答(response)：**Web浏览器提交请求后，通过HTTP协议传送给Web服务器。Web服务器接到后，进行事务处理，处理结果又通过HTTP传回给Web浏览器，从而在Web浏览器上显示出所请求的页面。
**关闭连接(close)：**客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户机与服务器断开连接
请求与响应
用于 HTTP 协议交互的信息被称为 HTTP 报文。请求端（客户端）的 HTTP 报文叫做请求报文，响应端（服务器端）的叫做响应报文。HTTP 报文包本身是由多行数据构成的字符串成文本。HTTP 报文大致可分为报文首部和报文主体(body)两块。两者由最初出现的空行来划分.
请求头
客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、请求头部（header）、空行和请求数据四个部分组成，下图给出了请求报文的一般格式。
Host：指定请求的服务器的域名和端口号。
Accept：指定客户端能够接收的内容类型。
Accept-Charset：浏览器可以接受的字符编码集。
Accept-Encoding：指定浏览器可以支持的web服务器返回内容压缩编码类型。
Accept-Language：浏览器可接受的语言。
Accept-Ranges：可以请求网页实体的一个或者多个子范围字段。
AuthorizationHTTP：授权的授权证书。
Cache-Control：指定请求和响应遵循的缓存机制。
Cookie：客户端用它向服务器传送数据
Content-Length：请求的内容长度。
Content-Type：请求的与实体对应的MIME信息。
Date：请求发送的日期和时间。
Expect：请求的特定的服务器行为。
From：发出请求的用户的Email。
Range：只请求实体的一部分，指定范围。
Referer：先前网页的地址，当前请求网页紧随其后,即来路。
Upgrade：向服务器指定某种传输协议以便服务器进行转换（如果支持。
User-Agent：将发起请求的应用程序名称告知服务器
Warning：关于消息实体的警告信息
请求方法
根据 HTTP 标准，HTTP 请求可以使用多种请求方法。
HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD方法。
HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
| 序号 | 方法 | 描述 |
|---|---|---|
| 1 | GET | 请求指定的页面信息，并返回实体主体。 |
| 2 | HEAD | 类似于GET 请求，只不过返回的响应中没有具体的内容，用于获取报头 |
| 3 | POST | 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。 |
| 4 | PUT | 从客户端向服务器传送的数据取代指定的文档的内容。 |
| 5 | DELETE | 请求服务器删除指定的页面。 |
| 6 | CONNECT | HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。 |
| 7 | OPTIONS | 允许客户端查看服务器的性能。 |
| 8 | TRACE | 回显服务器收到的请求，主要用于测试或诊断。 |
| 9 | PATCH | 是对PUT 方法的补充，用来对已知资源进行局部更新 。 |
响应头
HTTP响应也由四个部分组成，分别是：状态行 + 响应头 + 空行 + 响应体。
响应头信息
HTTP请求头提供了关于请求，响应或者其他的发送实体的信息。
在本章节中我们将具体来介绍HTTP响应头信息。
| Allow | 服务器支持哪些请求方法（如GET、POST等）。 |
|---|---|
| Content-Encoding | 文档的编码（Encode）方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。Java的GZIPOutputStream可以很方便地进行gzip压缩，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet应该通过查看Accept-Encoding头（即request.getHeader(“Accept-Encoding”)）检查浏览器是否支持gzip，为支持gzip的浏览器返回经gzip压缩的HTML页面，为其他浏览器返回普通页面。 |
| Content-Length | 表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势，可以把输出文档写入 ByteArrayOutputStream，完成后查看其大小，然后把该值放入Content-Length头，最后通过byteArrayStream.writeTo(response.getOutputStream()发送内容。 |
| Content-Type | 表示后面的文档属于什么MIME类型。Servlet默认为text/plain，但通常需要显式地指定为text/html。由于经常要设置Content-Type，因此HttpServletResponse提供了一个专用的方法setContentType。 |
| Date | 当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦。 |
| Expires | 应该在什么时候认为文档已经过期，从而不再缓存它？ |
| Last-Modified | 文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档才会返回，否则返回一个304（Not Modified）状态。Last-Modified也可用setDateHeader方法来设置。 |
| Location | 表示客户应当到哪里去提取文档。Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302。 |
| Refresh | 表示浏览器应该在多少时间之后刷新文档，以秒计。除了刷新当前文档之外，你还可以通过setHeader(“Refresh”, “5; URL=http://host/path”)让浏览器读取指定的页面。注意这种功能通常是通过设置HTML页面HEAD区的＜META HTTP-EQUIV=“Refresh” CONTENT=“5;URL=http://host/path"＞实现，这是因为，自动刷新或重定向对于那些不能使用CGI或Servlet的HTML编写者十分重要。但是，对于Servlet来说，直接设置Refresh头更加方便。注意Refresh的意义是"N秒之后刷新本页面或访问指定页面”，而不是"每隔N秒刷新本页面或访问指定页面"。因此，连续刷新要求每次都发送一个Refresh头，而发送204状态代码则可以阻止浏览器继续刷新，不管是使用Refresh头还是＜META HTTP-EQUIV=“Refresh” …＞。注意Refresh头不属于HTTP 1.1正式规范的一部分，而是一个扩展，但Netscape和IE都支持它。 |
| Server | 服务器名字。Servlet一般不设置这个值，而是由Web服务器自己设置。 |
| Set-Cookie | 设置和页面关联的Cookie。Servlet不应使用response.setHeader(“Set-Cookie”, …)，而是应使用HttpServletResponse提供的专用方法addCookie。参见下文有关Cookie设置的讨论。 |
| WWW-Authenticate | 客户应该在Authorization头中提供什么类型的授权信息？在包含401（Unauthorized）状态行的应答中这个头是必需的。例如，response.setHeader(“WWW-Authenticate”, “BASIC realm=＼“executives＼””)。注意Servlet一般不进行这方面的处理，而是让Web服务器的专门机制来控制受密码保护页面的访问（例如.htaccess）。 |
状态码
当浏览者访问一个网页时，浏览者的浏览器会向网页所在服务器发出请求。当浏览器接收并显示网页前，此网页所在的服务器会返回一个包含HTTP状态码的信息头（server header）用以响应浏览器的请求。
HTTP状态码的英文为HTTP Status Code。
下面是常见的HTTP状态码：
- 200 - 请求成功
- 301 - 资源（网页等）被永久转移到其它URL
- 404 - 请求的资源（网页等）不存在
- 500 - 内部服务器错误
302，401，403，
状态码分类
HTTP状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用。HTTP状态码共分为5种类型：
HTTP状态码分类
| 分类 | 分类描述 |
|---|---|
| 1** | 信息，服务器收到请求，需要请求者继续执行操作 |
| 2** | 成功，操作被成功接收并处理 |
| 3** | 重定向，需要进一步的操作以完成请求 |
| 4** | 客户端错误，请求包含语法错误或无法完成请求 |
| 5** | 服务器错误，服务器在处理请求的过程中发生了错误 |
HTTP状态码列表
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 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的请求头信息 |
| 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
Content-Type（内容类型），一般是指网页中存在的 Content-Type，用于定义网络文件的类型和网页的编码，决定浏览器将以什么形式、什么编码读取这个文件，这就是经常看到一些 PHP 网页点击的结果却是下载一个文件或一张图片的原因。
Content-Type 标头告诉客户端实际返回的内容的内容类型。
语法格式：
Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something
实例：
常见的媒体格式类型如下：
- text/html ： HTML格式
- text/plain ：纯文本格式
- text/xml ： XML格式
- image/gif ：gif图片格式
- image/jpeg ：jpg图片格式
- image/png：png图片格式
以application开头的媒体格式类型：
- application/xhtml+xml ：XHTML格式
- application/xml： XML数据格式
- application/atom+xml ：Atom XML聚合格式
- application/json： JSON数据格式
- application/pdf：pdf格式
- application/msword ： Word文档格式
- application/octet-stream ： 二进制流数据（如常见的文件下载）
- application/x-www-form-urlencoded ： 中默认的encType，form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据的格式）
另外一种常见的媒体格式是上传文件之时使用的：
- multipart/form-data ： 需要在表单中进行文件上传时，就需要使用该格式
5. 三次握手
TCP协议头展示
1）**序列号seq（Sequence Number）：**占32位，表示这个tcp包的序列号。tcp协议拼凑接收到的数据包时，根据seq来确定顺序，并且能够确定是否有数据包丢失。
2）**确认号ack（Acknowledgment Number ）：**占32位，表示这个包的确认号。首先意味着已经收到对方了多少字节数据，其次告诉对方接下来的包的seq要从ack确定的数值继续接力。
3）标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，
具体含义如下:
- ACK：确认序号有效
- FIN：释放一个连接
- SYN：发起一个新连接。
要注意的是:
不要将确认序号ack与标志位中的ACK搞混了
确认方ack=发起方seq+1，两端配对。
三次握手过程详细说明：
**第一次：**客户端发送建立TCP连接的请求报文，其中报文中包含seq序列号，是由发送端随机生成的，并且将报文中的SYN字段置为1，表示需要建立TCP连接。（SYN=1，seq=x，x为随机生成数值）；
**第二次：**服务端回复客户端发送的TCP连接请求报文，其中包含seq序列号，是由回复端随机生成的，并且将SYN置为1，而且会产生ACK字段，ACK字段数值是在客户端发送过来的序列号seq的基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP建立请求已得到验证。（SYN=1，ACK=x+1，seq=y，y为随机生成数值）这里的ack加1可以理解为是确认和谁建立连接；
**第三次：**客户端收到服务端发送的TCP建立验证请求后，会使自己的序列号加1表示，并且再次回复ACK验证请求，在服务端发过来的seq上加1进行回复。（SYN=1，ACK=y+1，seq=x+1）。
6. 四次挥手
**第一次挥手：**主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不会再给你发数据了(当 然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但此时主动关闭方还可以接受数据。
**第二次挥手：**被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1(与SYN相同，一个FIN占用一个序号)。
**第三次挥手：**被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。
**第四次挥手：**主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。
7. HTTPS协议
7.1 HTTPS 是什么
HTTPS （Hyper Text Transfer Protocol over SecureSocket Layer）：
- HTTPS 是一种应用层协议，是一种透过计算机网络进行安全通信的传输协议。
- HTTPS 经由 HTTP 进行通信，但是在 HTTP 的基础上引入了一个加密层，使用 SSL/TLS 来加密数据包
- HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。
- HTTPS 默认工作在 TCP 协议443端口
7.2 为什么需要加密？
因为http的内容是明文传输的，明文数据会经过中间代理服务器、路由器、Wif热点、通信服务运营商等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是 中间人攻击。所以我们才需要对信息讲行加密。
7.3 HTTPS 的工作过程
要保证数据安全，就需要进行“加密”，即网络传输中不再直接传输明文，而是加密之后的“密文”。加密的方式有很多，但是整体可以分为两大类：对称加密和非对称加密
7.3.1 引入对称加密
基本介绍：
对称加密其实就是通过一个密钥，把要传输的一段信息加密成密文，也能把加密后的信息进行解密
在对称加密中，密钥通常是由一方生成，然后以安全的方式传输给另一方，以便双方在通信过程中使用该密钥来加密和解密数据。密钥的生成和分发通常是由服务端完成，但也可以由客户端完成，具体取决于安全协议和情境。
这里示意图由客户端生成：
也正是因为如此，黑客在获取密文请求的同时，也获取到了密钥，因此只使用对称加密并不能起到数据保护的作用。所以还需要让密钥进行加密，但是使用对称加密的话，是行不通的，故引入了非对称加密
对称密钥存在的问题？
-
如果存在多个客户端怎么办？
- 为所有的客户端都应用同一个秘钥A，这种方式很显然是不合理的，破解了一个用户，所有的用户信息都会被盗取。
-
如果每个客户端都准备一个密钥行不行？
- 也不是很现实，服务端需要维护的太多。
-
对称加密的秘钥也需要传输，密钥在传输过程中会不会被截取？
- 会！
7.3.2 引入非对称加密
基本介绍：
非对称加密简单说是有两个密钥，一个叫做公钥，一个叫做私钥。公钥加密的内容必须用私钥才能解开，反之，私钥加密的内容也只有公钥才能解开，这对密钥由服务器产生。
缺点：
公钥和私钥是配对的，最大的缺点就是运算速度非常慢，比对称加密要慢很多
所以一般会在第一次使用非对称加密，传输一个对称加密的密钥，双方获取到密钥之后，就使用对称加密的方式传输数据。
引入流程：
服务器将公钥直接发送给客户端，将私钥保留。客户端得到公钥后，通过公钥将密钥进行加密，再发送给服务器，服务器通过私钥解密获取到密钥。之后再将收到密钥的消息通过密钥加密后发送给客户端，客户端收到后，就使用该密钥通过对称加密的方式与客户端进行数据传输
引入非对称加密后，为什么还要使用对称加密？
由于对称加密的成本（对机器资源的消耗）远远低于非对称加密，而实际上客户端和服务器之间传输的数据量会很大，如果都使用非对称加密，整体的传输速度就会很慢，因此通过非对称加密，让服务器得到密钥后，再使用对称加密进行传输，能够提高传输的效率
引入非对称加密后还存在的问题：
- 服务器首先生成一对公钥A和私钥A。
- 首先服务器要把公钥A发送给客户端，此时黑客可以当作一个中间人，同样可以获取到公钥A，并且自己生成一对公钥B和私钥B。他会将服务器的信息拦截，并将自己生成的公钥B发送给客户端。
- 当客户端得到公钥B后，就使用公钥B加密自己生成的密钥A并发送给服务器。
- 此时黑客再次截取，通过私钥B解密公钥B，并使用公钥A将密钥进行加密返回给服务器。至此服务器和客户端都确定了密钥A，但黑客也神不知鬼不觉的知道了密钥A。故在之后的数据传输中，黑客就可以直接完全的获取客户端和服务器的明文数据。因此即使引入了非对称机密还是存在两个问题：
- 客户端如何获取到公钥？
- 客户端如何确定这个公钥不是黑客伪造的？
为了解决这两个问题，就引入了证书
7.3.3 引入证书机制
基本介绍：
在客户端和服务器刚建立连接时，服务器就给客户端返回一个证书。这个证书就好比人的身份证，用来作为网站的身份标识。而每搭建一个 HTTPS 网址时都需要在 CA 机构申请一个证书。
证书含有的重要信息：
- 证书发布机构
- 证书有效期
- 公钥
- 证书所有者
- 签名
引入证书流程：
- 首先服务器生成公钥和私钥，去证书颁发机构申请一个证书（证书包含申请者的信息，公钥，数字签名）
- 颁发的证书和私钥需放在服务端
- 客户端默认是存在根证书的，这个根证书是CA机构和客户端厂商合作，出厂自带根证书，作用就是用来验证CA证书，得到公钥
- 在HTTPS握手的时候，客户端请求获取证书
- 然后服务端向客户端发送证书
- 客户端接收道证书之后，使用根证书来验证服务器证书的合法性，验证通过得到公钥
得到公钥之后就直接用公钥和私钥进行数据传输吗？
- 客户端得到公钥之后，会和服务端协商一个会话密钥（协商过程不再展开讲了）
- 协商完成，客户端和服务器都拥有相同的会话密钥，这个密钥用于后续的加密和解密通信。
- 这样客户端和服务器都拥有相同的会话密钥，它们可以使用该密钥进行后续的数据传输
都有公钥和私钥了为什么还要再生成一个会话密钥？
- 对称密钥加密和解密速度更快，因此用于实际的数据传输，这可以确保通信的隐私和完整性。
8. URL&URI
URL：统一资源定位符
URI： 统一资源标识符
所有的 url 都是 uri ，但是反之就是错误的。简单讲就是包含与被包含的关系。
URI是以一种抽象的，高层次概念定义统一资源标识，URI 就是在某一规则下能把一个资源独一无二地标识出来。而URL和URN则是具体的资源标识的方式。
URL的组成
下面是一些URL的示例：
https://developer.mozilla.org
https://developer.mozilla.org/en-US/docs/Learn/
https://developer.mozilla.org/en-US/search?q=URL
协议+域名或IP+路径+参数
协议：https://
域名或IP：developer.mozilla.org
路径：/en-US/docs/Learn/
参数：q=URL
您可以将上面的这些网址输进您的浏览器地址栏来告诉浏览器加载相关联的页面（或资源）。
一个URL由不同的部分组成，其中一些是必须的，而另一些是可选的。让我们以下面这个URL为例看看其中最重要的部分：
http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument
http:// 是协议。它表明了浏览器必须使用何种协议。它通常都是HTTP协议或是HTTP协议的安全版，即HTTPS。Web需要它们二者之一，但浏览器也知道如何处理其他协议，比如mailto:（打开邮件客户端）或者 ``ftp:（处理文件传输），所以当你看到这些协议时，不必惊讶。
www.example.com 是域名。 它表明正在请求哪个Web服务器。或者，可以直接使用IP address, 但是因为它不太方便，所以它不经常在网络上使用。
.
:80 是端口。 它表示用于访问Web服务器上的资源的技术“门”。如果Web服务器使用HTTP协议的标准端口（HTTP为80，HTTPS为443）来授予其资源的访问权限，则通常会被忽略。否则是强制性的。
/path/to/myfile.html 是网络服务器上资源的路径。在Web的早期阶段，像这样的路径表示Web服务器上的物理文件位置。如今，它主要是由没有任何物理现实的Web服务器处理的抽象。
?key1=value1&key2=value2 是提供给网络服务器的额外参数。 这些参数是用 & 符号分隔的键/值对列表。在返回资源之前，Web服务器可以使用这些参数来执行额外的操作。每个Web服务器都有自己关于参数的规则，唯一可靠的方式来知道特定Web服务器是否处理参数是通过询问Web服务器所有者。
#SomewhereInTheDocument 是资源本身的另一部分的锚点. 锚点表示资源中的一种“书签”，给浏览器显示位于该“加书签”位置的内容的方向。例如，在HTML文档上，浏览器将滚动到定义锚点的位置;在视频或音频文档上，浏览器将尝试转到锚代表的时间。值得注意的是，＃后面的部分（也称为片段标识符）从来没有发送到请求的服务器。
Note: 这里是关于URLs的 一些额外的部分和一些额外的规则 , 但它们对于普通用户或Web开发者不是非常重要。 你不必担心这个，要构筑和使用完全实用的URLs不必了解这些。
你可能想到一个URL类似普通信件的地址：协议代表你要使用的邮政服务，域名是城市或者城镇，端口则像邮政编码；路径代表着你的信件所有递送的大楼；参数则提供额外的信息，如大楼所在单元；最后，锚点表示信件的收件人。
常见的协议有这么多：
| 方案 | 描述 |
|---|---|
| http | 超文本传输协议方案，除了没有用户名和密码外其他与通用的URL格式相符。如果省略了端口，就默认为80。格式http//:/
|
| https | 与http基本一样，唯一区别是https使用了SSL（安全套接层），SSL为HTTP连接提供了端到端的加密机制。语法与http一致，默认端口号为443。 |
| ftp | 文件传输协议URL可以用来从FTP服务器上下载/上传文件，并且获取FTP服务器上的目录结构。基本格式：ftp：//:@:/
|
| mailto | E-Mail地址传输协议，基本格式：mailto：;示例： mailto：joe@joes-hardware.com |
| rtsp，rtspu | RTSP URL，是可以通过实时流传输协议解析音频、视频的媒体资源标识符。基本格式：rtsp：//:@:/
|
| files | files表示指定主机（本地磁盘、网络文件系统、）上可以直接访问的文件。如果省略主机名则表示本地主机;基本格式：files：///
|
| news | 方案news用来访问一些特定的文章或新闻组，他有一个独特的性质：news URL本身不足对资源进行定位。基本格式：news: |
| telnet | telnet用于访问交互式业务。他表示的并不是对象自身，而是可通过telnet协议访问的交互时应用程序（资源）。基本格式：telnet：//:@:/ |
URI 详解
我们知道可以使用 URI 可以标记服务器上的资源。
因为它经常出现在浏览器的地址栏里，所以俗称为“网络地址”，简称“网址”。
严格地说，URI 不完全等同于网址，它包含有 URL 和 URN 两个部分，在 HTTP 世界里用的网址实际上是 URL——统一资源定位符（Uniform Resource Locator）。但因为 URL 实在是太普及了，所以常常把这两者简单地视为相等。
URI 的格式
URI 本质上是一个字符串，这个字符串的作用是唯一地标记资源的位置或者名字。
它不仅能够标记万维网的资源，也可以标记其他的，如邮件系统、本地文件系统等任意资源。
下面的这张图显示了 URI 最常用的形式，由 scheme、host:port、path 和 query 四个部分组成，但有的部分可以视情况省略。
URI 的基本构成
URI 第一个组成部分叫 scheme，翻译成中文叫“方案名”或者“协议名”，表示资源应该使用哪种协议来访问。
最常见的当然就是“http”了，表示使用 HTTP 协议。另外还有“https”，表示使用经过加密、安全的 HTTPS 协议。此外还有其他不是很常见的 scheme，例如 ftp、ldap、file、news 等。
在 scheme 之后，必须是三个特定的字符“😕/”，它把 scheme 和后面的部分分离开。
在“😕/”之后，是被称为“authority”的部分，表示资源所在的主机名，通常的形式是“host:port”，即主机名加端口号。
主机名可以是 IP 地址或者域名的形式，必须要有，否则浏览器就会找不到服务器。但端口号有时可以省略，浏览器等客户端会依据 scheme 使用默认的端口号，例如 HTTP 的默认端口号是 80，HTTPS 的默认端口号是 443。
有了协议名和主机地址、端口号，再加上后面标记资源所在位置的 path，浏览器就可以连接服务器访问资源了。
http://nginx.org http://www.chrono.com:8080/11-1 https://tools.ietf.org/html/rfc7230 file:///D:/http_study/www/
可以直接把文件或目录从资源管理器“拖入”浏览器窗口，地址栏就会显示出对应的 URI。
URI 的查询参数
使用“协议名 + 主机名 + 路径”的方式，已经可以精确定位网络上的任何资源了。但这还不够，很多时候我们还想在操作资源的时候附加一些额外的修饰参数。
举几个例子：
获取商品图片，但想要一个 32×32 的缩略图版本；
获取商品列表，但要按某种规则做分页和排序；
跳转页面，但想要标记跳转前的原始页面。
仅用“协议名 + 主机名 + 路径”的方式是无法适应这些场景的，所以 URI 后面还有一个“query”部分，它在 path 之后，用一个“?”开始，但不包含“?”，表示对资源附加的额外要求。这是个很形象的符号，比“😕/”要好的多，很明显地表示了“查询”的含义。
查询参数 query 有一套自己的格式，是多个“key=value”的字符串，这些 KV 值用字符“&”连接，浏览器和服务器都可以按照这个格式把长串的查询参数解析成可理解的字典或关联数组形式。
查询参数 query 也可以不使用“key=value”的形式，只是单纯的“key”，这样“value”就是空字符串。
如果查询参数 query 太长，也可以使用 GET 方法，放在 body 里发送给服务器。
还可以再拿一个实际的 URI 来看一下，这个 URI 是某电商网站的一个商品查询 URI，比较复杂，但相信现在的你能够毫不费力地区分出里面的协议名、主机名、路径和查询参数。
https://search.jd.com/Search?keyword=openresty&enc=utf-8&qrst=1&rt=1&stop=1&vt=2&wq=openresty&psort=3&click=0
你也可以把这个 URI 输入到 Chrome 的地址栏里，再用开发者工具仔细检查它的组成部分。
URI 的完整格式
讲完了 query 参数，URI 就算完整了，HTTP 协议里用到的 URI 绝大多数都是这种形式。
不过必须要说的是，URI 还有一个“真正”的完整形态，如下图所示。
这个“真正”形态比基本形态多了两部分。
第一个多出的部分是协议名之后、主机名之前的身份信息“user:passwd@”，表示登录主机时的用户名和密码，但现在已经不推荐使用这种形式了（RFC7230），因为它把敏感信息以明文形式暴露出来，存在严重的安全隐患。
第二个多出的部分是查询参数后的片段标识符“#fragment”，它是 URI 所定位的资源内部的一个“锚点”或者说是“标签”，浏览器可以在获取资源后直接跳转到它指示的位置。
但片段标识符仅能由浏览器这样的客户端使用，服务器是看不到的。也就是说，浏览器永远不会把带“#fragment”的 URI 发送给服务器，服务器也永远不会用这种方式去处理资源的片段。
URI 的编码
刚才我们看到了，在 URI 里只能使用 ASCII 码，但如果要在 URI 里使用英语以外的汉语、日语等其他语言该怎么办呢？
还有，某些特殊的 URI，会在 path、query 里出现“@&?"等起界定符作用的字符，会导致 URI 解析错误，这时又该怎么办呢？
所以，URI 引入了编码机制，对于 ASCII 码以外的字符集和特殊字符做一个特殊的操作，把它们转换成与 URI 语义不冲突的形式。这在 RFC 规范里称为“escape”和“unescape”，俗称“转义”。
escape 已经被废弃。
encodeURI 方法：把字符（unicode）编码成utf-8，utf-8是用1-4个字节表示的，所以每个字节转换成16进制并在前面用百分号（%）连接，最后并把每个字节转换的结果连接起来。
URI 转义的规则有点“简单粗暴”，直接把非 ASCII 码或特殊字符转换成十六进制字节值，然后前面再加上一个“%”。
例如，空格被转义成“%20”，“?”被转义成“%3F”。而中文、日文等则通常使用 UTF-8 编码后再转义，例如“银河”会被转义成“%E9%93%B6%E6%B2%B3”。
有了这个编码规则后，URI 就更加完美了，可以支持任意的字符集用任何语言来标记资源。
不过我们在浏览器的地址栏里通常是不会看到这些转义后的“乱码”的，这实际上是浏览器一种“友好”表现，隐藏了 URI 编码后的“丑陋一面”，不信你可以试试下面的这个 URI。
http://www.chrono.com:8080/11-1?夸父逐日
先在 Chrome 的地址栏里输入这个 query 里含有中文的 URI，然后点击地址栏，把它再拷贝到其他的编辑器里，它就会“现出原形”：
http://www.chrono.com:8080/11-1?%E5%A4%B8%E7%88%B6%E9%80%90%E6%97%A5
9.代理
在我们进很多工作的时候，会有很多地方需要去设置代理的。
比如: fiddler抓包，burp抓包，jmeter录制脚本等等。
甚至于，在某些公司，去访问某些内部网址的时候，都需要通过连接vpn才能成功访问。
那到底什么是代理? 我们为什么要使用代理呢?
什么是代理?
代理也称网络代理，是一种特殊的网络服务。
它允许客户端通过这个服务与服务器进行连接。
简单的来说，可以把代理理解为一种网络中间商。
为什么要使用代理？
- **正常情况：**我们去访问一个网站，应该是直连的情况，
手机/电脑访问目标网站->目标网站正常显示，如下图：
这种情况，需要建立在你的网络正常，没有任何限制的基础上才能完成的。比如我们在家里使用QQ，玩LOL、PUBG，看爱奇艺，逛淘宝，查百度等等，这些都是这种直连模式
- **特殊的情况：**比如公司内部采用了局域网模式，限制了公司内部直接访问外网的权限，但是呢，你在某些情况下需要去访问外网，那怎么办呢？我们就可以采取非直连的模式，即，
手机/电脑访问目标网站->代理服务器->目标网站正常，如下图：
这种情况，就是我们在本地发送请求的时候，不是直接把请求发到服务器上的，是先把请求发给代理服务器，再由代理服务器进行转发到服务器上的。
正向代理和反向代理
- 正向代理：服务端不知道客户端是谁
- 反向代理：客户端不知道服务端是谁
2516
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
