网络七层协议
物理层
为数据端设备提供传输数据的通路、传输介质，如光纤、无线信道、终端等
数据链路层
为网络层提供数据传送服务的，可以粗略地理解为数据通道(物理层是长期的，而数据链路层是生存期内的)
1.链路连接的建立，拆除，分离
2.链路层的数据传输单元是帧网络层
当终端增多时，解决任意终端连接问题。称路由或者叫寻径
1.激活,终止网络连接
2.在一条数据链路上复用多条网络连接,多采取`分时复用`技术
3.排序,流量控制传输层
它是源端到目的端对数据传送进行控制从低到高的最后一层
1.传输层也称为运输层.传输层只存在于端开放系统中
2.传输层是两台计算机经过网络进行数据通信时,第一个端到端的层次，具有缓冲作用
3.传输层面对的数据对象已不是网络地址和主机地址,而是和会话层的界面端口
4.采用分流/合流，复用/解复用技术来调节通信子网(如电话交换网,分组交换网,公用数据交换网,局域网等)的差异
端口号是传输层协议的内容，UDP(无连接->短信)/TCP(有连接->电话)协议也是
上述功能的最终目的是为会话层提供可靠的,无误的数据传输
会话层
使应用建立和维持会话，并能使会话获得同步
主要功能流程
1.将会话地址映射为运输地址
2.选择需要的运输服务质量参数(QOS)
3.对会话参数进行协商
4.识别各个会话连接
5.传送有限的透明用户数据
6.传输数据，释放连接表示层
异种机通信提供一种公共语言，以便能进行互操作，前面几层完成了数据传输，之后要实现数据的使用
应用层
应用层向应用程序提供服务
DNS
浏览器输入url后发生的事情：
//
浏览器向 DNS 服务器查找输入 URL 对应的 IP 地址。
DNS 服务器返回网站的 IP 地址。
浏览器根据 IP 地址与目标 web 服务器在 80 端口上建立 TCP 连接。
浏览器获取请求页面的 HTML 代码。
浏览器在显示窗口内渲染 HTML 。
窗口关闭时，浏览器终止与服务器的连接。状态码
1XX：指示信息–表示请求已接收，继续处理
2XX：成功–表示请求已被成功接收、理解、接受。
3XX：重定向–要完成请求必须进行更进一步的操作。
4XX：客户端错误–请求有语法错误或请求无法实现。
5XX：服务端错误-服务器未能实现合法的请求Header中参数定义
request header
GET /sample.Jsp HTTP/1.1 请求行
Host: www.uuid.online/ 请求的目标域名和端口号
Origin: http://localhost:8081/ ？？？
Referer: https:/localhost:8081/link?query=xxxxx 请求的来源域名和端口号
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 浏览器信息
Cookie: BAIDUID=FA89F036:FG=1; BD_HOME=1; sugstore=0 当前域名下的Cookie
Accept: text/html,image/apng 代表客户端希望接受的数据类型是html或者是png图片类型
Accept-Encoding: gzip, deflate 代表客户端能支持 gzip 和 deflate 格式的压缩
Accept-Language: zh-CN,zh;q=0.9 代表客户端可以支持语言 zh-CN 或者 zh (值得一提的是q(0~1)是优先级权重的意思，不写默认为1，这里 zh-CN 是1， zh 是0.9)
Connection: keep-alive 告诉服务器，客户端需要的 tcp 连接是一个长连接response header
|HTTP/1.1 200 OK| 响应状态行|
|Date: Mon, 30 Jul 2018 02:50:55 GMT|服务端发送资源时的服务器时间|
|Expires: Wed, 31 Dec 1969 23:59:59 GMT|较过时的一种验证缓存的方式，与浏览器（客户端）的时间比较，超过这个时间就不用缓存（不和服务器进行验证），适合版本比较稳定的网页|
|Cache-Control: no-cache| 现在最多使用的控制缓存的方式，会和服务器进行缓存验|证，具体见博文 “Cache-Control”
|etag: "fb8ba2f80b1d324bb997cbe188f28187-ssl-df"| 一般是Nginx静态服务器发来的静态文件签名，浏览在没有 “Disabled cache” 情况下，接收到 etag 后，同一个 url 第二次请求就会自动带上 “If-None-Match”|
|Last-Modified: Fri, 27 Jul 2018 11:04:55 GMT|服务器发来的当前资源最后一次修改的时间，下次请求时，如果服务器上当前资源的修改时间大于这个时间，就返回新的资源内容|
|Content-Type: text/html; charset=utf-8|如果返回是流式的数据，我们就必须告诉浏览器这个头，不然浏览器会下载这个页面，同时告诉浏览器是utf8编码，否则可能出现乱码|
|Content-Encoding: gzip|告诉客户端，应该采用gzip对资源进行解码|
|Connection: keep-alive|告诉客户端服务器的tcp连接也是一个长连接|Http中缓存相关的头部
1.Expires
优势：简单易用，以时刻标识失效时间
劣势：服务器发送的时间(UTC)，若服务器和客户端时间不一致就凉凉、存在版本问题(1.0产物，可在1.1使用)
2.Cache-Control
优势：以时间间隔标识失效时间，解决Expires服务器客户端时间不一致问题、比Expires多了很多选项设置
劣势：1.1产物(不适用于1.0)、存在版本问题，到期之前的修改客户端是不可知的
3.Last-Modified
优势：无版本问题，每次进行请求去服务器校验。服务器对比最后修改时间，相同返回304，不同返回200及资源
劣势：
1)只要资源修改(无论资源是否发生实质性的改变)，都会将该资源返回给客户端，例如周期性重写
2)以时刻作为标识，无法识别一秒内进行多次修改的情况，且某些服务器不能精准识别文件最后修改时间
4.ETag
优势：继承Last-Modified优势，解决其劣势，更精准判断资源是否被修改以及一秒内多次修改的情况
劣势：
1)计算ETag值需要性能损耗
2)分布式服务器存储的情况下，计算ETag的算法若不一样，会导致浏览器从一台服务器上获得页面内容后到另外
一台服务器上进行验证时发现ETag不匹配的情况强缓存和协商缓存
强缓存
强缓存是利用 http 头中的 Expires 和 Cache-Control 两个字段来控制的，用来表示资源的缓存时间
强缓存中，普通刷新会忽略它，但不会清除它，需要强制刷新。浏览器强制刷新，请求会带上 Cache-Control:no-cache 和 Pragma:no-cache。通常，强缓存不会向服务器发送请求，直接从缓存中读取资源
在chrome控制台的network选项中可以看到该请求返回200的状态码。分为from disk cache和from memory cache
from disk cache：一般非脚本会存在内存当中，如css，html等
from memory cache：资源在内存当中，一般脚本、字体、图片会存在内存当中强缓存情况下缓存命中和未命中
协商缓存(弱缓存)
协商缓存就是由服务器来确定缓存资源是否可用，所以客户端与服务器端要通过某种标识来进行通信，从而让服务器判断请求资源是否可以缓存访问
普通刷新会启用弱缓存，忽略强缓存，只有在地址栏或收藏夹输入网址、通过链接引用资源等情况下，浏览器才会启用强缓存，这也是为什么有时候我们更新一张图片、一个js文件，页面内容依然是旧的，但是直接浏览器访问那个图片或文件，看到的内容却是新的。
这个主要涉及到两组header字段：Etag和If-None-Match、Last-Modified和If-Modified-Since向服务器发送请求，服务器会根据这个请求的request header的一些参数来判断是否命中协商缓存
弱缓存情况下缓存命中和未命中
流程
浏览器第一次发起请求，本地有缓存情况： 在浏览器第一次发起请求时，本地无缓存，向web服务器发送请求，服务器起端响应请求，浏览器端缓存。过程如下：
在第一次请求时，服务器会将页面最后修改时间通过 Last-Modified 标识由服务器发送给客户端，客户端记录修改时间；服务器还会生成一个Etag，并发送给客户端。
浏览器后续再次进行请求时：
LRU(Least rencently used-最近最少使用)算法
1.原理
根据数据的历史访问记录来淘汰数据-"如果数据最近被访问锅，将来被访问的几率也更高"
Http请求方法
1 GET 请求指定的页面信息，并返回实体主体。
2 HEAD 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
3 POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
4 PUT 从客户端向服务器传送的数据取代指定的文档的内容。
5 DELETE 请求服务器删除指定的页面。
6 CONNECT HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
7 OPTIONS 允许客户端查看服务器的性能。
8 TRACE 回显服务器收到的请求，主要用于测试或诊断。
9 PATCH 实体中包含一个表，表中说明与该URI所表示的原内容的区别。
10 MOVE 请求服务器将指定的页面移至另一个网络地址。
11 COPY 请求服务器将指定的页面拷贝至另一个网络地址。
12 LINK 请求服务器建立链接关系。
13 UNLINK 断开链接关系。
14 WRAPPED 允许客户端发送经过封装的请求。
15 Extension-mothed 在不改动协议的前提下，可增加另外的方法。get和post的区别
get post
点击返回/刷新按钮 没有影响 会重新发送数据包
(浏览器会重新提示"数据被重新提交")
添加书签 可以 不可以
缓存 可以 不可以
编码类型 application/x-www-form-rulencoded application/x-www-form-rulencoded
or multipart/form-data
请为二进制数据使用 multipart 编码
历史记录 有 没有
长度限制 有 没有
数据类型限制 只允许ascii类型 没有限制，允许二进制数据
安全性 查询字符串会直接在url显示 数据没有缓存或保持在历史记录中
但传输敏感数据，还需加密cookie 和 session
三分钟搞定
因为Http协议无状态，在需要识别状态的时候，需要借助外力来辨别，而这个外力就是Cookie与Session
Cookie
存储在用户本地计算机上，用于保存一些用户操作的历史信息，当用户再次访问我们的服务器的时候，浏览器通过HTTP协议，将他们本地的Cookie内容也发到咱们服务器上，从而完成验证
Cookie 是存储在浏览器客户的一小片数据；
Cookie 可以同时被前台与后台操作；
Cookie 可以跨页面存取；
Cookie 是不可以跨服务器访问的；
Cookie 有限制； 每个浏览器存储的个数不能超过300个，每个服务器不能超过20个，数据量不能超过4K；
Cookie 是有生命周期的，默认与浏览器相同，如果进程退出，cookie会被销毁
session
当用户访问我们的网站时，我们的服务器会成一个 Session ID，然后把 Session ID 存储起来，再把这个 Session ID 发给我们的用户，用户再次访问我们的服务器的时候，拿着这个 Session ID就 能验证了，当这个ID能与我们服务器上存储的ID对应起来时，我们就可以认为是自己人
seesion 数据存储在服务器端；
每一个会话分配一个单独的 session_id;
该 session_id 通过 cookie 传送到前台，默认的 session_id 名称是PHPSESSIONID;
前台只能看到 Session 的 ID，而不能修改 Session 值;
使用 Session 之前需要先开启会话;
Session 存储在 Session 数组 $_SESSION ;
Session 存储方式比较安全，但是如果 Session 数量过多，会导致服务器性能下降;
请求报文与响应报文的格式
请求报文
请求报文由请求行、请求头部、请求正文组成
1.请求行
格式： 请求方法 + 空格 + URL + 空格 + 协议版本 + 回车符 + 换行符
例如： GET www.baidu.com HTTP/1.1
2.请求头部-请求头部为请求报文添加了一些附加信息，由"key:value"值对组成
格式： 头部字段名 + 冒号（:） + 值 + 回车符 + 换行符
例如：
Host：接受请求的服务器地址，可以是IP:端口号，也可以是域名
User-Agent：发送请求的应用程序名称
Connection：指定与连接相关的属性，如Connection:Keep-Alive
Accept-Charset：通知服务端可以发送的编码格式
Accept-Encoding：通知服务端可以发送的数据压缩格式
Accept-Language：通知服务端可以发送的语言
3.请求正文-一般用于post请求中
描述：POST 方法适用于需要客户填写表单的场合
与请求数据相关的最常使用的请求头是 Content-Type 和 Content-Length响应报文
响应报文由状态行、响应头部、响应正文组成
1.状态行
格式：协议版本 + 空格 + 状态码 + 空格 + 状态码描述 + 回车符 + 换行符
2.响应头部-与请求头部格式一致，由"key:value"值对组成
格式：头部字段名 + 冒号（:） + 值 + 回车符 + 换行符
例如：
Server：服务器应用程序软件的名称和版本
Content-Type：响应正文的类型（是图片还是二进制字符串）
Content-Length：响应正文长度
Content-Charset：响应正文使用的编码
Content-Encoding：响应正文使用的数据压缩格式
Content-Language：响应正文使用的语言
3.响应正文
响应正文就是html代码了HTTPS
https概况
TTPS = HTTP+TLS/SSL
通常，HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL 和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披 SSL 协议这层外壳的 HTTP
TLS/SSL 的功能实现主要依赖于三类基本算法：散列函数 、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性
1.对称加密-同一密钥实现加解密
2.非对称加密-需要一对公钥and私钥(公钥对数据进行加密，只有用对应的私钥才能解密)
3.散列函数(Hash)-任意长度的输入通过散列算法变换成固定长度的输出(不同的输入可能会散列成相同的输出)
对于Hash中不同输入散列成相同的输出，叫碰撞。即key1≠key2，f(key1)=f(key2)，key1和key2称同义词
典型的散列函数有无线的定义域，有限的值域
Hash算法应用于信息安全
1.文件校验
MD5 Hash算法的"数字指纹"特性，使它成为应用最广泛的一种文件完整性校验和(Checksum)算法
不少Unix系统有提供计算md5 checksum的命令
2.数字签名
由于非对称算法的运算速度较慢，所以在数字签名协议中，单向散列函数扮演了一个重要的角色。
对 Hash 值，又称"数字摘要"进行数字签名，在统计上可以认为与对文件本身进行数字签名是等效的。
3.鉴权协议
在传输信道是可被侦听，但不可被篡改的情况下，这是一种简单而安全的方法
https工作原理
其在http上加了一层处理加密信息的模块，所以传输的数据都是加密后的数据
1.客户端发起HTTPS请求
浏览器里面输入一个HTTPS网址，然后连接到服务端的443端口上。注意这个过程中客户端会发送一个密文族给服务端，密文族是浏览器所支持的加密算法的清单。
2.服务端配置
采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。
这套证书其实就是一对公钥和私钥，可以这么理解，公钥就是一把锁头，私钥就是这把锁的钥匙，锁头可以给别人对某个东西进行加锁，但是加锁完毕之后，只有持有这把锁的钥匙才可以解锁看到加锁的内容。
3.传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构、过期时间等等。
4.客户端解析证书
这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，如颁发机构、过期时间等等，如果发现异常则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值，然后用证书(公钥)对该随机值进行加密。
注意一下上面提到的"发现异常"。证书中会包含数字签名，该数字签名是加密过的，是用颁发机构的私钥对本证书的公钥、名称及其他信息做hash散列加密而生成的。客户端浏览器会首先找到该证书的根证书颁发机构，如果有，则用该根证书的公钥解密服务器下发的证书，如果不能正常解密，则就是"发现异常"，说明该证书是伪造的。
补充：一对公钥、私钥既可公钥加密，对应的私钥解密也可私钥加密，对应的公钥解密。这样，就可以使通信的一方拥有私钥(保守方)，一方(公众)拥有公钥
5.传送加密信息
这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，然后客户端和服务端的通信就可以通过这个随机值来进行加密和解密了。
6.服务端解密信息
服务端用私钥解密后，得到了客户端传过来的随机值，至此一个非对称加密的过程结束，看到TLS利用非对称加密实现了身份认证和密钥协商。然后把内容通过该值进行对称加密。
7.传输加密后的信息
这部分是服务端用随机值加密后的信息，可以在客户端被还原。
8.客户端解密信息
客户端用之前生成的随机值解密服务端传送过来的信息，于是获取了解密后的内容，至此一个对称加密的过程结束，看到对称加密是用于对服务器待传送给客户端的数据进行加密用的。整个过程即使第三方监听了数据，也束手无策
整个过程总结：
1.先发送https请求确认加密算法
2.而后服务端返回一个公钥，客户端确认公钥是否有效
3.客户端产生随机值，通过公钥加密
4.服务端通过对应的私钥解密随机值，并将该随机值用来加密传输的正文(相当于该随机值为公钥-对称加密)
5.客户端用之前自己生成的随机值解密正文
整个过程可理解为先利用非对称加密传输对称加密的公钥https与http的区别
1.https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2.http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3.http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4.http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比 http 协议安全。跨域
跨域，指的是浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的，是浏览器对JavaScript施加的安全限制
同源策略：协议+域名+端口相同才算同源，其限制了以下行为：
1.Cookie、LocalStorage和IndexDB无法获取
2.DOM和JS对象无法获取
3.Ajax请求无法发出
例子：
http://www.a.cn/index.html 调用 http://www.a.cn/server.php 非跨域。
http://www.a.cn/index.html 调用 http://www.b.cn/server.php 跨域，主域不同。
http://abc.a.cn/index.html 调用 http://def.b.cn/server.php 跨域，子域名不同。
http://www.a.cn:8080/index.html 调用 http://www.a.cn/server.php 跨域，端口不同。
https://www.a.cn/index.html 调用 http://www.a.cn/server.php 跨域,协议不同。
localhost 调用 127.0.0.1 跨域
解决方法：
1.jsonp 跨域
2.document.domain + iframe 跨域
3.window.name + iframe 跨域
4.location.hash + iframe 跨域
5.postMessage 跨域
6.跨域资源共享 CORS
7.withCredentials 属性
8.WebSocket 协议跨域
9.node 代理跨域
10.nginx 代理跨域详细解决跨域的方法
参考连接