1.DNS域名系统
（1）DNS是干嘛的？（通过域名服务器来解析域名）
把域名（计算机主机名）转换成计算机可以识别的IP地址，然后计算机使用IP地址进行通信。
（2）为什么要用DNS?
因为IP地址的长度是32位的二进制数组成，不方便记忆。因此使用主机名更方便记忆。但是计算机由不能识别域名，因此就需要DNS域名系统把方便记忆的域名解析成计算机能识别的IP地址。
（3）顶级域名域名有哪些分类？（域名不区分大小写）
国家域名：cn --> 中国 us --> 美国 uk --英国
通用域名：com -->公司 net --> 互联网服务公司 gov -->政府机构
基础结构域名：略
（4）域名结构
mail.cctv.com <====> 三级域名.二级域名.顶级域名
（5）DNS怎么解析域名的
a.浏览器接收到用户输入的域名后，现在自己的内存中查找（如果浏览器之前访问，而且没有清除记录就能找到对应的ip地址）
b.计算机系统的host文件缓存（host文件会保存着可能常用的域名对应的ip地址）
c.路由器缓存
d.ISP DNS服务器缓存（ISP网络服务运营商，如中国移动、联通等）
e.根域名服务器（返回对应ip地址或者告诉本地域名服务器应该要去哪个顶级域名服务器（把顶级域名服务器的ip地址告诉本地服务器））
f.顶级域名服务器（返回对应ip地址或者告诉本地域名服务器应该去哪个主域名服务器查找（把主域名服务器的ip地址告送本地域名服务器））
g.主域名服务器返回对应ip地址，告诉本地域名服务器应该向下一个主域名服务器去查找，直到查找到对应的ip地址
本地域名服务器找到对应的IP地址后保存到本地缓存，然后把它返回给浏览器，浏览器使用它去连接相应的服务器。
2.统一资源标识符URI、统一资源定位符URL
统一资源标识符URI:服务器上的资源的名称（世界范围内唯一的标识符），它表明了资源的名称和定位资源位置。URL是URI的一种形式，另一种形式是统一资源名URN。
（1）什么是URL？作用是什么？
URL是统一资源定位符，可以定位互联网中的资源的位置和提供操作资源的方法。
系统只要知道资源保存在什么地方，才可以对资源进行相关的操作，比如下载资源、修改信息、上传信息等。
实际上，url就是互联网中相连的主机可以访问的对象的指针。
（2）URL的格式：（url不区分大小写）
协议 ：// 主机名（域名） ：端口号 / 路径
协议：主机以什么协议去获取资源。（最常用的协议是http–超文本传输协议HTTP，其次是ftp–文件传输协议FTP）—不可省略
主机名：指明要访问的文档在互联网的哪个主机上。 —不可省略
端口号：资源所在的位置（相对于主机）。http默认的端口号是80 。—可省略
路径：访问的文件的路径。 --可省略
例如：http：// 页面不存在_百度搜索 --用户输入url时可以省略http：// www不写，浏览器会自动补齐。
http --协议
百度一下，你就知道 --域名
/qq/lcx.html—请求的文件的路径
端口号已经省略。
http：// 百度一下，你就知道 ----省略端口号和路径时，会定位到资源所在的页面。然后可以在主页面上根据相关链接去寻找相应的资源。
（3）URN
URN统一资源名，是特定内容的唯一的名称，与目前资源的所在地没有关系。
（4）浏览器请求资源时，先建立tcp连接，然后浏览器要知道服务器的ip地址和端口号，ip地址（32位二进制数）可以由域名（文本形式）（即主机名）经过DNS域名解析系统解析为ip地址，加上默认的80端口号，就可以向服务器发送资源请求了，
随后服务器把请求的资源返回给浏览器，最后tcp连接断开。
（5）用户在浏览器的地址栏输入一个域名到请求的页面显示经历了那些过程？
浏览器分析url–>把url交给DNS域名系统，DNS域名系统把域名解析成IP地址–>浏览器使用IP地址与服务器建立tcp连接–>浏览器发起http–>浏览器接收http响应–>释放tcp连接 -->浏览器显示请求的内容
3.超文本传输协议HTTP–应用层协议
(1)HTTP是什么？
HTTP是无状态的（无状态：不会记录上一次请求/响应记录，只要客户端有请求，浏览器就会响应，而不管请求是不是相同的）、基于请求和响应的应用层协议（规定浏览器怎么向服务器发送请求和服务器怎么把文档传输给浏览器）。这个协议常基于tcp/ip协议来实现。
(2)HTTP协议实现的原理
域名解析–>发起TCP连接（三次握手）–>客户端发起http请求–>服务器响应http请求–>释放tcp连接（4次挥手）–>浏览器解析文件（和html、css等）–>浏览器显示请求内容。
（浏览器中的某个进程监测到浏览器向服务器发出请求时，立即建立tcp链接，然后浏览器向服务器发送页面请求，随后服务器把请求的文档返回给浏览器，最后释放tcp链接，最后页面显示）
栗子：当鼠标点击页面中的链接（或在地址栏输入url然后按下回车）时会发生以下过程：
a。浏览器分析页面rul
b。浏览器向DNS发出域名解析请求
c。DNS将页面的域名解析为IP地址（加上端口号）
d。建立浏览器与服务器之间的tcp连接
e。浏览器发出GET报文（发送请求http报文）
f。浏览器向服务器读取的响应报文（返回响应http报文）
g。释放tcp连接
h。页面显示请求的内容
HTTP报文类型：请求报文（浏览器向服务器发送的报文）、响应报文（浏览器向服务器读取的报文）
(3)HTTP和HTTPS的区别？
HTTP协议栈
应用层 – HTTP协议
运输层 --TCP协议
网络层 --IP协议
数据链路层 --网络接口
HTTPS协议栈
应用层 --HTTP协议
安全层 --SSL 或 TSL （进行密码加密、认证、保护报文完整性处理）
运输层 --TCP协议
网络层 --IP协议
数据链路层 --网络接口
https比http多了ssl层，这一层在http和tcp之间。“https是披着ssl外壳的http”----《图解HTTPÍ》
(4)http报文—两个类型的报文：请求报文、响应报文（基本格式一样,只有起始行有所不同）
4.1） http报文–组成部分
起始行（请求行/响应行）
首部字段–提供更多的请求/响应的信息，是一个名/值对形式的列表（可以有0个或多个）
实体主体（可选）–是HTTP报文的载荷，就是HTTP要传输的内容。
首部字段：
通用首部：（既可以出现在请求报文中，也可以出现在响应报文中）
Date：创建报文的时间
Transfer-Encodeing：报文主体的传输编码方式
请求首部：提供更多有关请求的信息。
如，Accept：text/gif,客户端可以接受的资源类型
Host：请求的资源所在的服务器
Accept：可处理的资源的类型
Accept-Charset:可以接受的字符集
Accept-Language：可接受的自然语言
响应首部：提供更多有关响应的信息。
Accept-Ranges：可接受的字节范围
Location：让客户端重新定位到的资源的url
Server：http服务器的安装信息
（set-cookie就是在响应的首部中）
实体首部：描述实体的长度、内容，或者资源本身。如，Content-length、Content-type
Allow：资源可以支持的http方法
Content-type：实体主体的类型
Content-lenght：实体主体的字节数
拓展首部：规范中还没有定义的新首部
*栗子：
请求报文：
GET /special/ggg.gif HTTP/1.0 //HTTP请求的方法 url http的版本号
//请求报文的起始行（也称为请求行），说明要干什么
//包括了一个方法–告诉服务器应该执行什么操作，一个url–对哪个资源进行操作，http版本号–告诉浏览器客户端使用哪种HTTP.
Host：www.ppxi.com //请求报文的首部
响应报文：
HTTP/1.0 200 OK //http的版本号 状态码 原因短语–状态码的可读版本 。–状态码方便机器处理，原因短语方便人们识别。状态码和原因短语成对出现
//响应报文的起始行（称为响应行），说明发生了什么
//请求报文中的方法是告诉服务器进行什么操作，响应报文的状态码是告诉客户端发生了什么事。
Content-type：image/gif //响应报文首部
Content-lenght：676 //响应报文首部
具体的图片（可能没有） //响应实体主体（head方法就是只返回报文首部的请求方式）
4.2） http报文–方法（请求方式）
GET–请求服务器发送某个资源
GET方法请求服务器返回的报文会包括报文响应行、报文的首部和报文的实体
HEAD–请求服务器发送某个资源，获取报文首部
HEAD方法请求服务器返回的报文只包括报文的描述和首部，即响应行（包含了使用的http版本 状态码 原因短语）和首部，没有包括资源实体
该方法允许在没有接受资源的情况下，通过状态码来检测资源是否存在、资源是否修改过；通过首部来检测请求的资源的类型。
PUT–向服务器发送数据并把写入服务器的文档
请求报文：
PUT /product-list.txt HTTP/1.1 //请求行 ，在服务器上根据url来创建一个文件并把product-list.txt内容写进去，如果已经这个url已经存在则覆盖原来的内容
HOST:www.ppxi.com //报文首部
Content:text/plain //报文首部
Content-lenght：676 //报文首部
响应报文：
HTTP/1.1 201 Created //响应行， 文件创建成功
Location：http://www.ppxi.com/product-list.txt //报文首部
Content:text/plain //报文首部
Content-lenght：676 //报文首部
http://www.ppxi.com/product-list.txt //资源实体
POST–向服务器发送数据，该数据由服务器来决定怎么处理。
比如，把客户输入的表单数据post给服务器。
表单的数据将作为请求报文的资源实体发送到服务器。
PUT方法是向服务器保存数据，而post是把数据发给服务器。
TRACE–用来检测请求的报文在传达到服务器的过程中，报文发生什么改变–比如，报文是否被修改或增添内容
该请求报文中不能包括请求报文的实体部分。
OPTIONS–用来访问服务器支持什么方法的操作，比如GET、POST、PUT等方法
方便客户在进行请求资源之前选择什么请求方法最合适。
DELETE–要求服务器删除请求报文中的url指定的文件
但是不一定能删除成功，因为http允许不通知客户的情况下撤销这个删除请求。即使服务器收到请求报文了会向客户发送响应报文。
*拓展的其他方法：
LOOCK–在编辑某个资源时锁定资源，以防在编辑的同时别人也在操作
MKCOL–允许用户创建自己的资源
COPY–便于服务器上复制资源
MOVE–在服务器上移动资源
*划重点：GET和POST的区别？
a. GET请求服务器根据url发送对应的资源，而POST是把资源保存到服务器上指定的url中
b. GET请求的资源的url是客户可见的，而POST是不可见的。
c. GET方法向服务器请求的资源数据量小，以为要数据大小受到url长短的限制，而POST可以向服务器发送保存大量数据
d. GET是不安全的，因为它通过地址栏来传数据，是可见的，可能会泄露信息。POST通过体表表单来传输局，相对安全。
e. GET传输的只能是ASCII字符（ask-音译）（字符集共有128个字符），比如传输中文等字符会发生乱码现象；而POST支持的是标准字符集，除了ASCII码之外还能传输其他类新的字符，比如中文字符。
*安全的方法：（http请求不会在服务器产生什么效果，是服务器对请求返回结果）
GET和HEAD方法
安全方法并不是什么动作都不执行，使用安全方法的目的是，允许http开发者通知用户，什么时候会使用某些不安全方法。在网页上点击购买某种产品时，客户会得到正在使用不安全的方式发起请求的提示。
4.3） http报文–状态码–共分为5类，告诉客户端从服务器返回的请求结果，向客户描述请求返回的结果
范围 已经定义的范围
a。100～199 信息提示 100～101
在发送实体之前，检测服务器是否能接受/处理这个实体。没有实体要发送时不应该向服务器发送这个状态码，客户管应该在为了避免发送服务器无法处理的实体的时候才使用 100 continue。 即接收的请求正在处理。
b。200～299 成功 200～206
表示客户端发起的请求时成功的。 即服务器正常处理。
c。300～399 重定向 303～305
表示客户端发起的请求资源不在请求的url上，需要服务器把资源所在的url通过响应报文的首部的location告诉客户端；或者请求的url的资源有多种符合条件的选择，服务器把所有的选择可能反馈给客户端让客户端做出选择。 即客户端需要进行附加操作才能完成请求。
d。400～499 客户端错误 400～415
客户端请求出错，比如，客户端的请求url是不存在的，或者请求报文格式错误。即服务器无法处理请求。
e。500～599 服务器端错误 500～505
服务器错误，比如，客户端发送的请求是没有问题的，但是服务器没有办法向客户端提供服务。比如，服务器的网关出错，服务器使用的协议不支持客户请求使用的协议。 即服务器处理请求时出错。
常见的状态码：
100 Continue ----服务器收到客户端的请求，客户端可以继续发送请求
101 Switching Protocols ----服务器正在切换客户发送的请求所用的协议
200 OK ----请求没有问题，服务器成功处理了请求
201 Created ----在服务器创建好了客户端请求的对象（比如put方法）
202 Accepted ----请求被接受，但是服务器还没有执行任何动作。（不一定会完成这个请求）
204 Not Content ----响应报文只包含状态行和首部，不包含实体主体
206 Partial Content ----成功执行了一部分
300 Multiple Choice ----客户端请求的url只想多个资源（例如有两个版本）
301 Moved Permaanently ----请求的资源已经移除，并通过location告诉客户端现在资源所在的url
302 Found ----请求的资源暂时被移除，并通过location告诉客户端资源所在的url，将来访问还是使用原来的url
303 See Other ----告诉客户端另一个url去获取资源（目的：允许get请求的响应将客户端定位到某个资源上）
304 Not Modified ----最近访问的资源没有被修改，客户端可以访问浏览器记录中的资源
305 Use Proxy ----客户端应该使用代理来访问，并把代理的url通过location告诉客户端
307 Temporary Redirect ----告诉客户端临时的url去请求资源
400 Bad Request ----客户发送错误请求（如请求报文格式错误）
401 Unauthorized ----请求的资源未授权，要先进行验证
403 Forbidden ----客户端的请求被服务器拒绝了
404 Not Found ----找不到请求的url对应的资源
405 Method Not Allowed ----服务器不支持客户端请求的方法，并通过Allow首部告知客户端服务器接受什么操作方法
406 Not Acceptable ----服务器找不到与客户端期望接收的资源的匹配类型
408 Request Timeout ----请求的时间过长，并关连接
409 Conflict ----请求的资源发生冲突
500 Internal Server Error ----服务器内部错误，无法完成请求
503 Server Unavailable ----服务器暂时不可用（比如可能正在进行维护），过后可能继续可以使用
《图解HTTP》常用的14种状态码：
200 OK ----请求没有问题，服务器成功处理了请求
204 Not Content ----请求成功，但没有资源可返回。响应报文只包含状态行和首部，不包含实体主体，也不允许返回任何实体。一般在只需要客户端发送信息时使用。
206 Partial Content ----请求报文提出了范围要求，服务器成功执行了一部分的请求
301 Moved Permanently ----永久性重定向，告诉服务器请求的资源已经移除，并通过location告诉客户端现在资源所在的url
302 Found ----临时性重定向，请求的资源暂时被移除，并通过location告诉客户端资源所在的url，将来访问还是使用原来的url
303 See Other —告诉客户端资源在另一个url上，让客户端以get方法请求资源–与302的区别
（当301 、302、303响应状态码返回时，几乎所有浏览器都会把post改成get方法）
304 Not Modified ----客户端带有附加条件的请求，服务器找到资源但是不符合客户端的请求条件。响应报文也不会包含主体内容。附加条件是指：采用get方法的请求报文中包含If-Match，If-ModifiedSince，If-None-Match，If-Range，If-Unmodified-Since 中任一首部。
304划分到3XX类别，但是和重定向没有关系。
307 Temporary Redirect ----临时重定向，告诉客户端临时的url去请求资源。与302 Found有相同的意义，但是它不会把post方法编程get方法。
400 Bad Request ----客户发送错误请求（如请求报文格式、语法错误），服务器无法处理
401 Unauthorized ----请求的资源未授权，要先进行通过http认证
403 Forbidden ----客户端的请求被服务器拒绝了
404 Not Found ----找不–到请求的url对应的资源，也可以在服务器拒绝请求但是不想说明原因的时候用
500 Internal Server Error ----服务器内部错误，无法完成请求
503 Server Unavailable ----服务器暂时不可用（比如可能正在进行维护、或正在处于超负载），过后可能继续可以使用
(5)缓存
缓存命中：缓存有副本可以给请求提供服务
客户端 <—>缓存 服务器 //请求不会被发送到服务器
缓存未命中：缓存中没有可以副本可以为请求提供服务，而把请求转发给源服务器。
客户端 —> 缓存 —> 服务器 —> 缓存 —> 服务器 //请求先到达缓存，缓存没有副本，将请求发给服务器。服务器将报文发回给缓存，缓存保存副本，并把数据返回给客户端
再验证：缓存是不是向服务器验证副本是否“新鲜”
缓存再验证命中：缓存有副本，但是要先向服务器验证副本是否“新鲜”，若新鲜（服务器会返回304）则直接返回给客户端。再验证未命中–若不“新鲜”，服务器返回200，缓存删除旧的副本，保存新的副本，并把结果返回给客户端。若资源已经被删除，则服务器会返回404，缓存也会将副本删除。
缓存分类：私有缓存、共有缓存
私有缓存–通常会把文档保存在个人电脑的磁盘中
共有缓存–文档保存在一台代理缓存服务器上，多客户端可以访问到缓存的副本
代理缓存的层次结构：缓存分层级，客户端一层一层向上命中缓存
缓存步骤：
缓存接收请求的报文 —> 解析请求报文 —> 查询有无缓存的副本 —> 检测副本新鲜度 —> 创建响应报文 —> 发送给客户端 —> 日志：缓存记录本次操作信息
保持副本的新鲜
可以使用http的Cache-Control和Expires首部向服务器验证副本是否新鲜。
Cache-Control：max-age=时间 //副本保持新鲜的时间长短
Expires：绝对的时间 //副本在该日期前是新鲜的，相当于保质期一样
副本过期了并不意味着它和原始数据现在保存的内容不一样，所以过期的文档向服务器验证后才能决定改副本是否可用。即服务器再验证。
服务器再验证：（缓存并不是每次都要想服务器验证了才可以提供给客户端，只要副本还保持新鲜则可以直接返回给客户端，而不用告诉服务器什么。）
如果验证结果是副本已经发生了变化，缓存会获取新的的副本，保存覆盖原来的副本，然后将文档发给客户端，
如果验证结果没有发生变化，服务器会返回304，说明副本仍然新鲜可以提供给客户端，同时服务器会把新的过期时间发给缓存。
用条件方法进行再验证：
a。用最近修改日期来验证：
If-Modified-Since：日期 --客户端发送的请求包含的请求首部
//该首部会和服务器的Last-Modified配合使用。如果在指定的时间点之后做了修改，则执行请求的方法。
//如果没有修改，则返回304，和一个新的过期时间。不包含新主体。
//如果已经修改，那么get方法执行成功，返回200状态码、新的主体保存在旧的主体的位置上、新的过的日期。
b。用实体标签来验证：
If-None-Macth：实体标签再验证（一个多个）
//对比副本和服务器上的文档标签来验证文档是否进行修改。
//弥补根据文档是否进行修改的日期来判断副本的新鲜的不足：有些做了稍微的修改但是并没有及时更新修改日期、可能是做了信息的周期性输入，但是副本并没有修改
//以上情况，根据实体标签来检查文档是否修改就比较恰当。
Etag是实体标签（可能是文档的版本号、文档的序列号、文档的校验息等），服务器根据If-None-Macth的实体标签名和自身文档的Etag来识别文档是否做了修改。
如果做了修改，服务器会返回新的文档代替旧的文档，并且带上新的Etag给客户端，客户端下次再验证就可以使用这个Etag的名称。
什么时候使用实体标签和最近修改日期？
如果服务器返回Last-Modified值，客户端应该使用If-Modified-Since（最近修改日期）来进行再验证；
如果服务器返回的是一个实体标签，客户端应该使用If-None-Match（实体标签来进行再验证。
如果服务器返回两个，则两种方式都可以用。
重点内容：
服务器控制缓存的能力：
1.服务器可以在响应首部发送以下首部来控制缓存
Cache-Control：no-store //服务器限制缓存复制文档，要求缓存删除副本
Cache-Control：no-cache //缓存可以保存文档副本，只是在向服务器验证副本新鲜度之前不能把副本提供给客户端
Cache-Control：must-revalidated //副本不新鲜不能提供给客户端，保持新鲜的副本仍然可以随意提供给客户端
Cache-Control：max-age=时间 //服务器向缓存表明，从文档在传进来的时间起，副本保持新鲜的秒数
Expires：时间 //副本过期的日期
Cache-Control：max-stale //缓存可以任意向客户端提供过期的副本
Cache-Control：max-stale=s //在s时间内，副本不能过期
Cache-Control： min-fresh =s //至少在s秒内，文档要保持新鲜
Cache-Control：only-if-cached //只有缓存中存在副本时客户端才会收到一份副本
2.no-cache 和 must-revalidated的区别：
no-cache 把副本提供给客户端前，必须先向服务器验证副本新鲜度，才能提供。
must-revalidated是要副本还处于新鲜状态就可以不经过验证就可以发送给客户端，只要不新鲜的副本要经过服务器的验证。
3.试探性过期
试探性过期逻辑：
如果缓存中的文档的距离上一次修改的时间已经很久，那么这个文档可能是比较稳定的，不会突然发生变化，继续保存在缓存中会比较安全。
如果这份文档近期刚刚进行修改，说明它可能会经常发生变化，在向服务器验证之前，应该只把它缓存在内存中比较短的时间。
4.客户端的新鲜度限制
浏览器的refresh和reload按钮操作–可以强指刷新浏览器缓存或者用户代理缓存中过期的内容。
refresh：强制向服务器进行再验证，或者无条件向服务器获取文档。
reload：
设置缓存控制 p222
控制Apache的HTTP首部
通过HTTP-EQUIV控制HTML缓存
(6)HTTPS
(6.1)HTTP的缺点：
通信使用明文（不加密），内容可能被窃听
不验证通信方的身份，有可能遭到伪装
无法验证报文的完整性，有可能已经遭到篡改
通信使用明文（不加密），内容可能被窃听：
http本身不具备加密功能，所以不能对请求报文和响应报文进行加密。–htt以明文（没有进行加密的报文）的方式发送报文
TCP/IP是可能被窃听的网络。在通信的所有线路上都有可能被窥视，即使加密了的报文，在传输过程中也仍然是可见的，只是已经加码需要被解密后才能知道报文的内容。
SSL是什么？
SSL是一种网络安全技术，它独立于http协议。它也不仅仅被http协议所用，其他协议也可以使用。（后面会系统学习）
加密处理防止被窃听：
a。通信的加密—建立安全的通信路线，然后进行通信
http没有加密机制，但是可以通过SSL(安全套接层)和TLS（安全传输协议）组合使用，加密http 的通信内容。
用SSL建立安全通信路线，然后进行HTTP通信（请求，响应）。
与SSL组合使用的HTTP被称为HTTPS（超文本传输安全协议）或HTTP over SSL。
b。内容的加密—对通信路线不做处理，而是加密报文的内容。
http没有加密机制，所以可以对它所传输的内容进行加密。（即把http报文中的内容进行加密）
这时候报文首部不被加密，报文的主体被加密。但是通信本身是不加密的。
这个方式不同于SSL或STL将整个通信路线加密起来防止被窃痛，所以内容还是有被篡改的风险。
不验证通信方的身份就有可能遭到伪装
* http机制不会验证通信方的身份，任何客户端都可以像服务器发送请求，服务器接收到请求就会返响应（除了服务器限制的主机号和端口号以外）。
不验证身份肯能存在隐患：
a 。可能客户端发送的请求被发送到了，已经伪装了的服务器而不是原本url指向的那个真实的服务器。
b 。服务器响应的报文可能发送到了已经被篡改的主机上，而不是请求的主机。
c 。无法确定通信的对方是否有权限访问本服务器的资源
d 。无法判定请求来自哪里，是谁发送的。
e 。即使是无意义的请求，服务器也会响应。没有办法阻止海量请求下的DoS攻击（Denial of Service拒绝服务攻击）
* 查明对手的证书
证书是可靠的第三方机构办法的，用来证明请求/响应方是真实存在的。
确认证书就服务器可以知道通信方的意图，客户端也可以知道通信方是目的的服务器。
使用可靠的第三方提供的证书也可以减少客户端的信息泄漏的风险。
客户端的证书可以完成身份确认，也可以用于网站确认环节。
无法证明报文完整性，收到的就有可能已经被篡改
这里的完整性是指准确性，即客户端发出的报文从发送出去到服务器接收的过程中，是否被篡改无从得知。同样，服务器返回的响应的报文，在中途被篡改了客户端也不知道。
也就是，不能保证报文的完整性，就不能保证报文（请求/响应）是不是原原本本的没有被篡改。
http方法可以验证报文的完整性，但是并不便捷和可靠，所以还是需要用到https，由ssl提供认证和加密、摘要功能。
HTTPS登场！！！！！！！！！！！！！！！！！！！！
(6.2)HTTP + 通信加密 + 认证 + 完整性保护 = HTTPS
6.2.1）即http通信加密、认证身份、保证报文完整性后就是https
6.2.2）“https是披着ssl外壳的http”–通常http 直接与tcp通信，使用ssl之后，http先和ssl通信，然后ssl再去和tcp通信。
采用了SSL之后，http就有了https的加密、认证身份、完整性保护的功能了。
SSl是独立于http协议的，它是一种网络安全技术，其他的协议也可以搭配它使用。
6.2.3）相互交换密钥的公开密钥加密技术
SSL采用的是公开密钥加密技术的加密处理方式。
* 加密和解密都需要密钥，密钥加密种类：
a. 共享密钥加密/对称密钥加密
加密和解密使用同一个密钥
弊端：这种加密方式，在加密后必须将密钥发送给对方，发送的过程又会存在密钥被截取的可能，还有对方收到密钥后没有安全保管，使密钥落入他人之手。任何人拿到密钥就可以破解密码，那么加密的就等于形同虚设，没有意义了。
b. 使用两把密钥的公开密钥密钥加密
公开密钥加密是非对称的密钥，一把是私有密钥，一把是公开密钥。私有密钥自己保留不让后任何人知道（用于解密），公开密钥可以发送给任何人（用于加密）。私有密钥和公开密钥是成对出现的。
解决共享密钥的困境：密钥不送发送给对方，不会被窃取，解密密钥在接收方手上，只有接收方能解密。
(发送发使用接收方的私有密钥进行加密，接收方使用自己的私有密钥进行解密。)
HTTPS使用混合的加密机制–共享密钥加密和公开密钥加密混合加密机制
如果交换密钥环节，密钥可以安全交付。那么交换报文阶段就可以使用对称/共享密钥加密了。对称/共享密钥加密比公开密钥加密密钥的处理速度更快，因为公开密钥加密更加复杂。
混和加密机制的过程：
a. 使用公开密钥加密方式把稍后用到的共享密钥安全的交付给对方。–安全交付密钥
b. 然后使用共享密钥加密方式来处理之后的通信。
6.2.4）证明公开密钥正确性的证书
使用数字证书证明公开密钥是货真价实的密钥。
数字证书由可信赖的第三方认证机构认证：服务器提出认证公开密钥的申请–>认证机构认证申请者的身份，无误后对公开密钥做签名，然后分配这个公开密钥–>将该公开密钥和签名的公约证书绑定在一起–>服务器把密钥和证书一起发给客户端–>客户端验证证书的认证机构是否真实存在和可靠，确认服务器的公开密钥值得信赖。
6.2.5）HTTPS的安全通信机制
建立SSL连接–>发起http请求–>响应http请求–>断开连接
其中建立SSL连接经过“两次握手”：
a.客户端发起SSL连接请求–请求报文中包含SSL版本和加密组件（加密算法、密钥长度等信息）
b.服务器收到建立连接后，发起响应，响应报文中包含SSL版本和加密组件（从客户端发送的组件中筛选出来的）
c.服务器向客户端发送公开密钥证书
d.服务器发送报文通知客户端SSL连接的协商部分结束
（a~d为第一次握手）
e.客户端发起密钥交换报文（已经加密）
f.客户端发送报文通知服务器此报文之后的报文使用什么加密方式
g.客户端向服务器发送finished报文
h.服务器向客户端发送报文，通知客户端该报文之后的报文使用什么加密方式
i.服务器向客户端发送finished报文
（e~i为第二次握手）
问题：
a. ssl和stl有什么毛线关系？
stl是以ssl为原型开发的的协议，有时会统称为ssl。
b. ssl使用有什么影响？
https使用ssl之后会变慢，因为ssl需要时间来建立连接，还需要消耗CPU和内存等计算机资源来为客户端和服务器的加密、解密处理。
使用ssl会使处理变慢：需要时间来建立连接、处理加密解密等工作使通信变慢；耗费CPU和内存等资源，使处理的速度变慢。–可以使用ssl加速器来提速，但是并不能根本解决。
c. 为什么不总是使用https？
加密通信会耗费更多的CPU和内存资源。每次通信都用加密会耗费更多的资源，耗费性能变大。
因此除了传输敏感信息和个人信息时采用https加密通信。非敏感信息用http通信。
而且加密使用的证书也要花钱购买，也是开销之一。
在大量传输数据时，只会给敏感信息进行加密处理，以节省资源。
4.三次握手、四次挥手—三次握手是用来简历tcp连接的，四次握手释放tcp连接。
数据传输经历三个阶段：建立连接、数据传输、释放连接
(1)什么是三次握手？
三次握手就是发送方和接收方一共发送三个包来建立tcp连接。
将服务请求方看作A客户，服务提供方看作B服务器。
第一次握手：A向B发送连接请求，并发送同步SYN=1，设置初始序列号为seq=x。 //这时候SYN报文段还不能携带数据，但是会消耗一个序列号。第一次握手后，A进入SYN-SENT（同步发送状态）。
第二次握手：B收到客户的请求连接后，向A发送同意连接请求ACK=1，确认序号ack=x+1，并且发送SYN=1，设置自己初始序号seq=y。 //这时候SYN报文段还不能携带数据，但是会消耗一个序列号。第二次握手后B进入SYN-RCVD同步收到状态
第三次握手：A收到B的确认后，给B发送确认ACK=1,确认序号ack=y+1，并且设置自己的序号seq=x+1 。 //发送确认后A进入进入连接状态，B收到确认后也进入连接状态
TCP协议规定：SYN=1时的报文不能携带数据，但是会消耗一个序列。
(2)为什么要三次握手？
第三次握手是为了防止数据传输结束断开连接后，失效的连接请求会发送到服务器（客户向服务器发送请求，迟迟没有收到确认就会再次发送请求，而这个请求在数据传输完成后在传到服务器），
而服务器并不知道这是失效的请求，仍向客户发送连接请求确认。如果没有第三次握手，那么就会建立一个新的tcp连接。建立连接却没有数据传输就会浪累网络资源。
(3)什么是四次挥手？
第一次挥手：A向B结束数据传输后，向B发送关闭连接请求：FIN=1,seq=v （v等于最后一次传输数据时的序号+1） //关闭连接请求发送后，A进入FIN-WAIT-1(终止等待1)状态，等待B的确认。
第二次挥手：B收到A关闭连接请求后，向A发送确认，ACK=1,确认序号ack=v+1，seq=w //确认请求发送后，B还有可能继续向A发送数据，因此，第二次挥手完成时，连接时半关闭状态。A收到B的确认后进入FIN-WAIT-2(终止等待2)状态
第三次挥手：当B结束向A发送数据时，向A发送关闭连接请求FIN=1,seq=w（w等于最后传输数据的序号+1），而且重复发送上一次的确认报文ACK=1,ack=v+1s //LAST-ACK状态，等待A的确认
第四次挥手：A收到B的关闭连接请求后，发出确认ACK=1,ack=w+！，seq=v+1 //A发送确认后进入TIME-WAIT状态，B收到A的确认后关闭连接。TIME-WAIT会等待一个时间，保证B已经收确认报文而不再发送关闭连接请求。超过等待时间后A才断开连接。
A进入TIME-WAIT的状态的作用：
防止B没有收到A的确认报文，而重复发送请求释放连接报文。
如果A发送确认报文后直接释放连接，那么如果B恰好没有收到确认释放连接的报文，B就会还会发送释放请求，而不能按照正常状态释放连接。
A会比B晚一点释放连接。
(4)为什么要四次挥手？
第一次，第二次挥手是释放A向B传输数据的连接，第三次，第四次是释放B向A传输数据的连接。
5.TCP
(1)如何连接？
TCP连接是通过两个端点建立起来的一条连接，这两个端点叫做套接字/插口，套接字是由IP地址和端口号拼接而成的。IP地址可以连接到资源所在的主机，而端口号可以定位到资源所在的位置。
即，tcp连接由四个元素构成：源IP地址、源端口号、目的IP地址、目的端口号
两条不同的tcp连接不可能四个元素都相同。
TCP经过三次握手来建立连接，经过四次挥手释放连接。
(2)TCP特点
a。面向连接的运输层协议，在使用该协议前必须先建立连接，使用完毕之后断开连接。
b。只有两个端点（套接字/插口），即只能进行点对点（一对一）的连接，不能一对多的连接。
c。提供的是可靠的、无差错的、不会丢失数据、按序到达的传输服务。
d。提供全双工通信服务，即双方可以同时进行通信
e.面向字节流，从http传输下来的数据，tcp并不知道什么数据，它只会根据数据的大小来怎么把数据发送出去，比如，如果数据过大它就会把数据分成小块数据再发出去，如果数据很小，则会等待其他数据到达了再一起发出去。
(3)提供可靠服务的原理
理想的传输条件可以实现可靠传输：
a。传输的数据不会出错
b。接收方不过发送方以什么速率发送数据，它都能来得及接受和处理。
但是理想的网络传输条件并不真实存在。
TCP报文要交给IP层去传输，但是IP层的传输是尽最大努力的服务，即其传输服务是不可靠的，所以需要运输层的TCP采取措施来保证传输的可靠性。
如何保证可靠传输？
A、B是进行通信的双方，假设A是方法，B是接收方。
A向B发送数据，B收到数据后就给A发送确认。
如果在定时器定时的时间内（这个时间应该大于数据往返传输的时间，即大于两个rtt）没有收到B的确认，A会自动重新发送数据（超时重传）。
B发送的确认A没有收到，A这时候并不知道B是否收到数据，因此也会重传，B会再次收到A发送饿重复的数据，这时候会丢弃重复的数据，然后再次向A发送确认。如果A一直收不到B的确认，说明这个通信路线太差不适合传输数据。
还有一种情况，就是A延时收到B的确认，A会收下确认，然后什么都不做。
这样就可以在不可靠的传输网络上进行可靠传输。
(4)TCP提供的服务：
a。无差错的服务
b。按序传输数据，数据按序到达
c。未分段的数据流